tf.function 降延迟需满足反复调用、静态输入等条件，否则启动开销反致变慢；tensorrt 转换失败主因是动态图或shape，需固化图并设固定batch；model.predict()比直接调用慢因封装开销；cpu线程数应设为物理核心数，而非逻辑线程数。
为什么 tf.function 能降延迟，但加了反而变慢？
直接套用 @tf.function 不一定提速，尤其在小模型或单次调用场景下。它本质是把 Python 函数编译成静态图，启动开销（tracing + compilation）可能远超执行收益。
实操建议：
- 只对**被反复调用的推理函数**加
@tf.function，比如服务中每请求一次就 call 一次的predict_step() - 用
input_signature显式声明输入 shape 和 dtype，避免多次 tracing：@tf.function(input_signature=[tf.TensorSpec(shape=[None, 224, 224, 3], dtype=tf.float32)])
- 首次调用会触发 tracing，务必在 warmup 阶段预跑一次，否则首请求延迟畸高
TensorRT 加速时 trt.convert.TrtGraphConverterV2 报错怎么办？
常见报错如 Conversion failed for node xxx: Unsupported operation 'Switch'，本质是 TF 图里含控制流或动态 shape，TRT 不支持。
实操建议：
- 确保模型已用
@tf.function固化，且输入 shape 完全静态（不能含None维度，batch size 也得固定） - 优先用 TF 2.10+ 和对应版本 TensorRT（如 TRT 8.6 + TF 2.12），旧版本兼容性差
- 转换后务必用
converter.build()而非convert()，后者不执行实际优化 - 若仍失败，临时改用
precision_mode='FP16'或'INT8'（需校准数据），有时能绕过某些算子限制
多 batch 推理时 model.predict() 比手动 model() 慢一倍？
model.predict() 是 Keras 高层封装，自带数据 batching、进度条、回调等开销，纯推理场景纯属冗余。
实操建议：
- 服务部署一律用
model(inputs, training=False)直接调用，跳过 Keras wrapper - 输入 tensor 必须提前 on GPU（
.to('GPU:0')），避免每次调用触发隐式 copy - 批量大小不是越大越好：显存够但超出 GPU 计算单元吞吐时，延迟反而上升；建议从
batch_size=8开始压测，观察 latency plateau 点
为什么 CPU 推理启用了 intra_op_parallelism_threads 却没提速？
TF 默认会自动设线程数，手动设错反而引发争抢。典型错误是把 intra_op_parallelism_threads 设成物理核数的 2 倍，导致上下文切换开销盖过并行收益。
实操建议：
- 先用
tf.config.threading.get_intra_op_parallelism_threads()查默认值，多数情况无需改 - 若要调优，设为物理核心数（非逻辑线程数），例如 16 核 CPU 就设
16，别碰inter_op_parallelism_threads（留给图级调度） - CPU 推理真正瓶颈常在内存带宽，换
tf.float16输入 +tf.keras.mixed_precision.set_global_policy('mixed_float16')收益往往比调线程更显著
model() 那一行，用 tf.profiler 抓完整 trace 才能看出真瓶颈在哪。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
