流式预测必须用@tf.function包装模型推理逻辑，避免Python开销；禁用tf.data.Dataset.from_generator；统一用SavedModel格式部署；需限制GPU内存并固定输入shape以防碎片化。
流式预测必须用 tf.function 包装模型推理逻辑
直接调用 model.predict() 或 model(x) 在流式场景下会触发 Python 解释器开销，每次调用都走完整图构建+执行路径，延迟高且不可控。TensorFlow 的流式预测核心是把前向传播固化为静态计算图。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
@tf.function装饰一个只接收tf.Tensor输入的纯函数，内部调用model(x, training=False) - 确保输入张量 shape 已知（如
[1, 128]），避免None维度导致图重追踪（retracing）——这是流式延迟突增最常见原因 - 首次调用该函数后，后续同 shape 输入将复用编译好的图，端到端延迟可压到毫秒级
输入数据不能依赖 tf.data.Dataset.from_generator 实时喂入
虽然名字带“generator”，但该 API 在默认配置下仍会预取、缓存、批处理，且无法响应外部事件（如 Kafka 消息到达、socket 数据就绪）。它适合离线 pipeline，不适合低延迟流式。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用原生 Python 线程或 asyncio 接收原始数据（如从
socket.recv()、kafka.Consumer.poll()获取 bytes） - 在接收线程内完成：bytes → numpy array →
tf.convert_to_tensor()→ 调用已装饰的@tf.function函数 - 避免跨线程传递未完成的
tf.Tensor，尤其不要把 tensor 丢进queue.Queue——TensorFlow 张量不是线程安全的普通对象
model.save(..., save_format='saved_model') 是唯一推荐的部署格式
流式服务要求模型能被快速加载、无 Python 依赖、支持版本灰度。HDF5（.h5）格式保存的模型含 Python 闭包和自定义层代码，无法脱离训练环境加载；Keras JSON + weights 方式则需手动重建模型结构，易出错。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 训练完立刻用
model.save('my_model', save_format='saved_model')导出 - 流式服务启动时用
tf.keras.models.load_model('my_model')加载——它自动恢复计算图、变量、甚至@tf.function编译状态 - 若需 C++ 或 TensorFlow Serving 部署，
saved_model是唯一兼容格式；Python 侧也应统一用此方式加载，避免行为不一致
GPU 内存常驻与显存碎片是流式服务崩溃主因
TensorFlow 默认启用内存增长（memory_growth=True），但流式预测中频繁的小张量分配/释放会导致显存碎片，最终触发 ResourceExhaustedError: OOM when allocating tensor，即使总显存充足。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 服务启动前强制设置 GPU 内存限制：
gpus = tf.config.experimental.list_physical_devices('GPU')<br>if gpus:<br> tf.config.experimental.set_memory_limit(gpus[0], 4096) # 单卡 4GB - 对输入做固定 batch size（如始终
[1, ...]），避免动态 shape 导致不同大小 tensor 交替分配 - 监控
nvidia-smi中memory-usage是否持续上涨却不回落——这是碎片化信号，需重启服务
真正难处理的是跨 batch 的状态依赖（比如需要滑动窗口统计），那已超出纯“预测”范畴，得引入外部状态存储或改用 tf.keras.layers.RNN 类有状态层，但这就不再是简单流式预测了。
