深度学习推理服务怎么选：HTTP只是入口，模型生命周期才是核心

先判断模型应该靠近谁

端侧推理降低网络依赖并保护本地数据，但受算力、内存与更新约束；服务端推理集中管理模型和加速器，却增加网络、容量与隐私责任；同进程嵌入最简单，模型升级会与业务发布绑定。部署选择由延迟、吞吐、离线、成本和数据边界共同决定。

HTTP适合跨语言、代理、鉴权和观测，REST/JSON易调试，二进制或gRPC更适合大张量与高吞吐。协议只定义传输；请求验证、模型加载、并发、超时、批处理、版本和资源隔离仍要实现。Python标准库的示例服务器不适合直接承担公网生产流量。

FastAPI等框架可以处理模式、鉴权和异步I/O，但CPU/GPU推理仍是阻塞计算，需要线程池、进程或独立服务。多worker会各自加载模型，可能重复占用显存。不要因为接口是async就假设模型计算能够并行。

TensorFlow Serving等系统提供模型版本、REST/gRPC、批处理和监控配置。官方TensorFlow Serving指南强调稳定服务器架构与模型迭代解耦。选型仍要检查框架格式、预后处理、硬件后端和维护状态。

无限排队不是高可用。容量不足时快速拒绝并给出可重试信号，通常比让所有请求最终超时更健康。

模型权重、预处理、词表、输出标签和阈值组成一个发布单元。新版本先离线回归，再影子流量、灰度和逐步扩量；旧版本保留快速回滚。启动探针与就绪探针分开，模型预热完成后才接流量。

最好的部署方式只存在于明确场景中。小服务可以从受控Python进程开始，流量与模型数量增长后再拆分专用推理层；无论哪种技术，版本、背压、观测和回滚都不能省略。

客户端发来的 JSON 只是入口。服务还要完成鉴权、大小限制、反序列化、预处理、排队、批处理、设备执行、后处理和响应编码。每一段都可能失败，也都应有独立计时。只记录总延迟会把模型变慢、队列拥堵和图片解码异常混在一起；按阶段暴露指标，才能知道扩容 GPU 还是优化 CPU 前处理。

模型生命周期应脱离单个请求。进程启动时加载并预热经过校验的版本，请求处理只读取不可变模型引用；切换版本时先让新实例完成健康检查，再逐步接流量。若每个请求都尝试载入权重，不仅吞吐极低，还可能在并发下耗尽内存。模型、预处理代码、标签表和阈值必须作为同一发布单元，不允许只替换其中一个文件。

当输入速度超过处理能力，服务需要限定队列长度与等待时间。队列已满时返回可识别的错误或建议稍后重试，比让所有请求最终超时更容易恢复。对可合批任务，可设置很短的批次等待窗口并同时约束最大批量；窗口过长会损害低流量延迟，批量过大会挤占显存。

上线验证至少包含正常样本、超大输入、无效格式、模型异常、客户端中途断开和实例被终止。监控 P50/P95/P99 延迟、队列深度、批量分布、设备利用率、显存与错误类型，并用请求标识串起日志。HTTP 让系统可访问，受控的生命周期与过载行为才让它可运营。

请求契约应声明字段类型、尺寸上限、编码方式、超时和幂等语义；响应契约除结果外，还要提供模型版本、可定位的错误码和必要的质量信息。内部从通用 Web 框架迁移到专用服务器，或从单模型改为多模型路由时，只要契约稳定，客户端就不必跟着频繁改造。

契约测试不需要真实大模型即可运行。用轻量替身返回固定结果，先验证鉴权、限流、格式校验与错误映射；再在少量真实请求上验证预处理和数值结果。这样，网络层故障不会被误认为模型回归，模型更新也不会掩盖接口兼容性变化。

涉及异步任务时，提交接口只承诺接收，不应假装已经完成。任务状态需要明确的过期策略、取消语义和结果保留时间。把这些边界写进文档与自动测试，推理框架才可以在不破坏上层工作流的前提下演进。

为服务定义可被业务理解的目标，例如在指定输入上 95% 请求于某时限内完成、过载时多久返回明确拒绝、版本切换允许多少错误。指标连续越界时触发降级或回滚，而不是等平均 GPU 利用率看起来异常。容量规划由真实到达率、批量效率和尾部延迟共同驱动。