Google Cloud ML Engine在线推理耗时过长问题咨询

首先明确说：ML Engine绝对不会在每次请求时重新部署模型——模型部署完成后会持续加载在运行的实例中，除非实例被自动缩容到0或者出现异常重启。你遇到的10秒耗时，大概率是其他几个常见因素导致的，下面给你一步步排查和优化的方向：

1. 先排查冷启动问题 #

如果你的服务长时间没有收到请求，ML Engine会自动把实例数缩容到0来节省成本。当新请求过来时，需要重新启动实例、加载模型，这个冷启动过程刚好会消耗几秒到十几秒的时间，完全符合你描述的情况。

解决办法很简单：创建版本时设置最小实例数，强制保持至少一个实例运行：

gcloud ml-engine versions create SEM_V0 --model SEM --origin "MY_BUCKET_PATH" --runtime-version=1.6 --machine-type=n1-highmem-2 --min-instances=1

这样即使长时间没请求，实例也不会被回收，后续请求就能直接处理，不会有冷启动延迟。

2. 升级实例配置与runtime版本 #

你本地用的是游戏本、Datalab用的是n1-highmem-2，但ML Engine默认的在线预测实例是n1-standard-1（1vCPU + 3.75GB内存），配置比你测试的环境差很多，这肯定会拖慢推理速度。

• 升级实例类型：对于图像语义分割这类计算密集型任务，建议用更高配置的CPU实例（比如n1-highmem-4），或者直接用带GPU的实例（比如n1-standard-4搭配Tesla K80），创建版本时加上--machine-type参数指定即可。
• 升级TensorFlow runtime版本：你用的1.6版本太老旧了，后续的TensorFlow版本对SavedModel的加载、推理性能做了大量优化，建议升级到1.15（LTS稳定版），能显著提升模型运行效率。

3. 优化输入数据处理流程 #

你的输入处理链是「图像数组→Base64编码→网络传输→Base64解码→图像resize→归一化」，这里面有几个可以优化的点：

• 检查array_to_base64_websafe_resize函数，是否可以把resize操作移到本地完成？避免在ML Engine实例上重复做resize，节省计算资源。
• 尝试跳过Base64编码，直接发送原始图像字节流——ML Engine的在线预测支持直接接收bytes类型数据，你可以调整ServingInputReceiver的输入占位符为tf.uint8，减少编码解码的开销。
• 确保所有预处理操作都整合到TensorFlow计算图中，不要在Python层面做循环处理，避免GIL锁导致的性能瓶颈。

4. 验证模型导出的合理性 #

有时候导出的SavedModel会包含多余的计算节点，或者没有正确优化，也会拖慢推理速度：

• 用saved_model_cli show --dir YOUR_SAVED_MODEL_PATH --all命令检查模型的输入输出签名，确保没有不必要的节点被包含。
• 导出模型时，使用tf.estimator.export.build_raw_serving_input_receiver_fn替代自定义的serving_input_fn_web，确保导出的计算图是最优的。

5. 测试批量请求的耗时 #

如果单请求耗时高，试试一次发送多个图像实例，看平均每个实例的耗时是否下降。如果批量请求的平均耗时明显降低，说明单请求的 overhead 占比高，这时候可以考虑把多个单请求合并成批量请求发送，提升整体效率。

按照上面的步骤逐一排查，应该能把耗时降到和Datalab接近甚至更快的水平。

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