TF默认按物理核心数自动设线程，设为逻辑线程数会引发超线程争抢与高上下文切换开销；手动调整需设为物理核心数、重启进程生效，且仅对反复调用函数用tf.function并配input_signature，CPU推理优先用model()而非model.predict()。
直接改线程数、关 eager、预热模型这三步做完，CPU 推理延迟通常能降 30%～60%，但设错线程数反而更慢。
为什么 tf.config.threading.set_intra_op_parallelism_threads 设了没用
TF 默认会根据物理核心数自动设线程，手动设成逻辑线程数（比如 16 线程 CPU 设 16）就等于开了超线程争抢，上下文切换开销盖过并行收益。
- 先查默认值：
tf.config.threading.get_intra_op_parallelism_threads()，多数情况已是合理值 - 真要调优，设为物理核心数（不是
nproc输出的逻辑数），例如 8 核 CPU 就设8 - 别碰
inter_op_parallelism_threads，除非你明确在跑多模型并发，否则默认值更稳 - 设完必须重启 Python 进程才生效，
tf.config不支持运行时热更新
tf.function 加了反而变慢？这是典型误用
首次调用要 tracing + compilation，小模型或单次推理场景下，这个开销远超执行时间本身；而且输入 shape 变动会触发重复 trace，内存和延迟都崩。
Secure Python Code Sandbox
下载
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
- 只对**被反复调用的函数**加
@tf.function，比如服务中每请求一次就 call 的predict_step() - 务必加
input_signature，例如：@tf.function(input_signature=[tf.TensorSpec(shape=[1,224,224,3], dtype=tf.float32)]) - batch size 固定比用
None更稳，避免 trace 爆炸；图像类任务提前 resize，NLP 务必 pad 到max_len - 首次调用必须 warmup：在服务启动后、接收请求前，用真实数据跑一次
predict_step()
model.predict() 在 CPU 上为什么比 model() 慢一倍
model.predict() 是 Keras 高层封装，自带数据 batching、进度条、回调、类型检查等冗余逻辑，纯 CPU 推理时这些全是负担。
立即学习“Python免费学习笔记（深入）”；
- 部署服务一律用
model(inputs, training=False)直接调用，跳过 Keras wrapper - 输入
inputs必须是tf.Tensor，别传numpy.ndarray或 Python list，否则每次隐式转换都拖慢 - 如果输入来自文件或网络，用
tf.convert_to_tensor()提前转好，别在推理函数里现场转 - 批量大小不是越大越好：CPU 缓存有限，batch_size=16 可能比 32 延迟更低，建议从 4/8/16 开始压测
还有三个容易被忽略的硬伤点
它们不显眼，但经常让前面所有优化白做。
-
tf.config.set_soft_device_placement(True)必须开，否则 tensor 放错设备（比如 CPU tensor 被误调度到 GPU）会静默卡死 - 禁用 eager mode：
tf.compat.v1.disable_eager_execution()，TF 2.x 默认 eager，CPU 上解释开销大 - 模型加载后立刻调用一次
model(tf.zeros([1,224,224,3]))，强制初始化所有变量和图结构，避免首请求触发懒加载延迟
