@tf.function需输入稳定才能加速，否则反复追踪反增开销；TFLite需正确转换与warm up；GPU须设memory_growth避免初始化阻塞；绕过predict()直调model(x,training=False)并确保图内预处理。
为什么 tf.function 不能直接套在模型预测函数外就生效
很多人把整个 predict() 函数用 @tf.function 包一层，结果延迟没降多少，甚至更慢。这是因为 @tf.function 的加速依赖「图构建稳定」——如果输入 shape、dtype 或控制流每次都不一样，它会反复重新追踪（tracing），反而增加开销。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 确保推理时输入
shape固定（比如统一 pad 到[1, 224, 224, 3]），避免动态 batch 或变长序列直接进图 - 用
input_signature显式声明，防止隐式重追踪：@tf.function(input_signature=[tf.TensorSpec(shape=[1, 224, 224, 3], dtype=tf.float32)])
- 别对单次调用加
@tf.function，它适合高频重复调用；首次运行含编译开销，要测稳态延迟（warm up 至少 5–10 次）
使用 tf.lite.Interpreter 时如何避免常见加载/执行陷阱
TFLite 是降低移动端和边缘端延迟最直接的路径，但默认设置下容易踩坑：模型加载慢、每次 invoke() 都卡住、输出解析错位。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 转换时启用
experimental_new_converter=True和experimental_enable_resource_variables=True，否则某些 Keras 层（如 BatchNorm）会退化为慢速解释执行 - 加载后立刻调用一次
interpreter.allocate_tensors()，再 warm up 调用invoke()—— 否则首帧延迟可能高出 3–5 倍 - 输入 tensor 要用
interpreter.tensor(interpreter.get_input_details()[0]["index"])()获取可写引用，别直接赋值给input()返回的只读数组
GPU 推理中 tf.config.set_memory_growth 和 allow_growth 的实际影响
设不设这个，延迟能差 20% 以上。不是因为显存占多占少，而是因为它决定 CUDA 上下文初始化时机和内存分配策略。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 必须在
import tensorflow后、任何模型创建前设置：gpus = tf.config.list_physical_devices("GPU")<br>for gpu in gpus:<br> tf.config.experimental.set_memory_growth(gpu, True) -
set_memory_growth=True不等于“按需分配”——它只是禁用默认的 95% 显存预占，让 TensorFlow 在首次__call__时才申请所需显存，减少上下文初始化阻塞 - 若同时跑多个模型实例，建议配合
tf.device("/GPU:0")显式绑定，避免设备争抢导致 kernel 启动延迟突增
为什么 model.predict() 比手动 model(x, training=False) 慢一倍
predict() 是高层封装，自带 batch 拆分、数据管道、回调钩子、进度条等开销。生产环境做低延迟推理，这些全是累赘。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 绕过
KerasModel.predict()，直接调用model(x, training=False)，且x必须是tf.Tensor（不是 numpy 或 list），否则触发隐式转换 - 批量推理时，用
tf.concat拼接输入，别用 Python list + for 循环——TensorFlow 对张量批处理做了大量底层优化 - 如果模型含自定义
call()逻辑，确认里面没有tf.print、tf.py_function或未被@tf.function覆盖的 Python 控制流
tf.image.resize 替代 cv2.resize，用 tf.cast 替代 .astype()。只要有一处掉出图，整条链路就退化为 eager 模式，延迟立马回到原始水平。 
