GPU部署环境下为何建议将num_batch_threads设置为CPU核心数

num_batch_threads是TensorFlow Serving中控制批处理调度线程数的核心参数，负责完成请求接收、输入预处理、请求攒批、推理任务下发的全流程调度。
官方建议将其设置为CPU核心数，是基于高吞吐优先的满负载场景推导的最优值：

• 高RPS场景下请求源源不断涌入，多线程可以并行处理CPU侧的请求解析、张量格式化等预处理任务，避免CPU成为整个推理链路的瓶颈
• 更多的调度线程可以快速收拢大量请求，攒出更大的batch，充分利用GPU的高并行算力，将整体吞吐拉到最高
• 满负载场景下，多线程的上下文切换、锁竞争开销占总延迟的比例极低，完全可以被吞吐提升的收益覆盖

你的测试结果完全符合低负载场景的调度特性：

• 200RPS属于极低负载范畴，请求到达间隔长，攒批等待时间占总延迟的比例很高。多线程带来的锁开销、上下文切换开销在总延迟中的占比会被放大，反而拉高了整体延迟
• 多线程调度会将请求分散到不同的队列，反而难以攒出合适大小的batch，容易出现多个小batch频繁下发GPU的情况，既没有提升GPU利用率，还额外增加了调度开销
• 单线程调度时所有请求进入同一队列，攒批效率更高，也没有多线程竞争的额外开销，自然能拿到更低的延迟

结合你12核CPU + 单V100的硬件配置，可以按照以下优先级选择参数：

• 若核心需求是最大化吞吐（如离线批量推理、高峰时段RPS超过GPU承载能力的70%），直接沿用官方建议，设置num_batch_threads=12即可
• 若核心需求是最低延迟（如平峰时段RPS低于GPU承载能力的30%，业务对P99延迟要求极高），优先设置num_batch_threads=1，可在1~4的范围内小范围调整压测，选延迟最优的取值
• 若业务负载波动较大，不想做动态参数切换，可以取折中值2~4，兼顾高低负载下的延迟和吞吐表现
• 所有取值都建议结合你自身的业务请求大小、模型计算量做实际压测验证，重点观测P99延迟、GPU利用率两个核心指标，最终选择符合业务要求的取值

内容的提问来源于stack exchange，提问作者salpal