Docker部署TensorFlow Serving推理速度慢于Flask直跑如何调优？

你测到的1-2秒延迟差基本不是TF Serving本身的性能问题，绝大多数情况是默认配置适配高吞吐场景、和你的低延迟单请求场景不匹配导致的，先按下面的步骤调完参数再压测对比，再做选型。

TF Serving低延迟场景配置调整 #

• 第一优先级关掉批处理：官方提供的部分TF Serving Docker镜像默认开启了batching攒批逻辑，这个功能是为了高QPS场景下攒多个请求合并计算提吞吐量的，单请求场景下会等待固定的攒批窗口超时才会执行推理，平白增加几百毫秒到1秒多的空等延迟。启动容器时去掉--enable_batching启动参数，或者显式追加--enable_batching=false即可关闭。
• 对齐线程数配置：TF Serving默认会按宿主机总CPU核数设置算子内、算子间并行线程数，如果Docker容器做了CPU资源限制，会出现线程数远大于实际可用核数的问题，上下文切换开销会陡增。启动时追加和Flask服务分配核数一致的线程参数即可，比如分配2核就加：--tensorflow_intra_op_parallelism=2 --tensorflow_inter_op_parallelism=2。
• 关闭无用后台任务：如果不需要模型热更新，直接追加参数--file_system_poll_wait_seconds=0关掉模型文件轮询，避免后台定期扫描文件占用计算资源。
• 校准测试环境：如果测试时TF Serving走的是跨主机网卡、甚至公网请求，Flask走的是本地进程内函数调用，本身网络序列化、传输的开销就会带来明显延迟差。同机部署测试时优先用本地回环gRPC接口调用，不要走跨网络链路，测出来的数值才具备参考性。

正常调完上述参数后，同硬件环境下TF Serving的单请求推理延迟只会比本地Flask加载模型高10-50ms，不会出现秒级的差距。

最终选型参考 #

• 如果调优后TF Serving的延迟还是比本地加载高200ms以上，且你的业务场景是单实例部署、QPS很低、不需要模型版本管理/多版本灰度/多模型统一调度，直接选Flask本地加载模型即可，架构更简单，少一层服务调用开销，问题排查也更直接。
• 如果后续需要扩容多实例、支撑高QPS、需要做模型滚动更新、A/B测试、多模型服务化，还是建议用调优后的TF Serving，它原生的批处理能力在高并发场景下能把吞吐量拉到Flask本地部署的数倍到十倍，长期运维成本更低。

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