根本原因是python进程资源未释放，主要表现为gpu显存碎片、tf.function频繁retracing导致cpu飙升、tf.data缓存膨胀；应固定input_signature、启用memory_growth、落盘cache并避免无限数据集缓存。
不是模型“老化”，而是 Python 进程里累积了未释放的资源或状态，最常见的是 GPU 显存碎片、TensorFlow 的 ConcreteFunction 多次 retracing、以及 tf.data pipeline 缓存膨胀。
tf.function 频繁 retracing 导致 CPU 占用飙升
每次输入 shape 或 dtype 变化（比如 batch size 动态调整、图像 resize 不统一），@tf.function 就会重新 trace 生成新图，旧图不自动回收。反复几十次后，内存里堆满相似但不复用的图对象，CPU 持续做 tracing 而非计算。
- 检查日志是否频繁出现
Retracing is expensive—— 这是明确信号 - 用
@tf.function(input_signature=[tf.TensorSpec(shape=[1,224,224,3], dtype=tf.float32)])强制固定输入规格，禁用动态 trace - 避免在
@tf.function内部调用tf.py_function或依赖 Python 全局变量
GPU 显存碎片让后续分配越来越慢
TensorFlow 默认不释放中间 tensor 占用的显存块，尤其在变长输入、多分支推理（如 early exit）场景下，显存被切成小块，新 kernel 启动时找不到连续大块，被迫等待或降频运行。
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
- 启动时显式设
tf.config.set_memory_growth(tf.config.list_physical_devices('GPU')[0], True)，禁用内存预分配 - 避免在循环中反复创建新
tf.Variable或tf.keras.Model实例 —— 复用已有对象 - 若必须动态 shape，改用
tf.function(jit_compile=True)触发 XLA，它对碎片更友好（但不支持所有 op）
tf.data pipeline 缓存没清理，越跑越卡
dataset.cache() 若没指定路径，默认缓存在内存；长时间服务后，缓存数据量暴涨，shuffle 和 batch 步骤要遍历更大内存块，延迟肉眼可见上升。
- 小数据集：用
dataset.cache()+ 定期重启服务进程 - 大数据集：改用
dataset.cache('/tmp/my_cache')落盘，但确保/tmp是裸 SSD 分区（非 APFS 加密卷或 NFS） - 永远不要在无限 dataset（如
from_generator）上用cache()—— 它会无限制吃光内存
真正难排查的点在于：这些退化通常不报错，只表现为 latency 逐小时爬升、nvidia-smi 显示 GPU-util 波动加剧、ps aux --sort=-%mem 看到 Python 进程 RSS 持续增长 —— 这时候别急着换模型，先 dump 出内存快照，查 ConcreteFunction 和 cache 对象的引用链。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
