本文定位：面向企业 AI 平台和平台工程团队，讨论模型推理服务上线后的入口路由、版本灰度、弹性伸缩和可观测治理，不展开单一框架安装教程。
模型推理服务的挑战，往往在模型部署成功之后才显现：请求从哪里进入，版本如何灰度，负载升高时怎么扩容，延迟异常时该看模型、网关还是 GPU。企业平台不能只看模型是否启动，还要补齐入口、版本、弹性和观测治理链路。
图1：模型推理服务从入口、版本到推理运行时的请求治理链路
模型推理服务不是单个 Deployment
KServe 官方文档将 InferenceService 作为声明式推理服务接口，用于描述 predictor、transformer、explainer 等推理组件[1]。把模型封装成一个容器并暴露 Service，只能完成最基础的服务化；生产场景中的模型推理服务通常还包含模型仓库、推理运行时、模型版本、入口网关、认证鉴权、弹性策略、观测指标和发布流程。
平台团队需要同时回答四个问题：
- 谁能调用：API Key、Token、租户、项目或应用身份如何校验。
- 调到哪里：不同模型、版本、灰度组和地域如何路由。
- 如何扩缩：按 QPS、并发、延迟、队列长度还是 GPU 指标触发弹性。
- 如何定位：请求失败时能否关联调用方、模型版本、实例、运行时和资源指标。
这也是推理治理与训练调度的差异。训练任务更关注作业排队、GPU 占用和完成时间；推理服务还要面对在线流量、接口可用性目标、灰度版本和多租户调用。相关资源治理差异可参考站内的 AI 训练调度与推理服务的资源治理差异 。
路由治理要覆盖入口、版本和租户
模型推理路由不只是把 URL 转发到某个服务。一个平台可能同时运行通用大模型、行业模型、Embedding 模型、重排序模型和传统机器学习模型，每类模型又可能有多个版本、多个资源池和不同调用权限。
| 路由层级 | 典型对象 | 治理重点 | 常见风险 |
|---|---|---|---|
| 入口层 | API 网关、Ingress、Service Mesh | 认证、限流、租户识别 | 调用方不清、入口策略分散 |
| 服务层 | InferenceService、Service、Revision | 灰度、版本、流量比例 | 旧版本无法回退或被误删 |
| 运行时层 | Triton、TorchServe、自研 Runtime | 协议、批处理、模型加载 | 运行时能力与模型需求不匹配 |
| 资源层 | GPU、CPU、节点池、队列 | 隔离、配额、扩缩 | 在线推理被离线任务挤占 |
灰度策略要和观测指标绑定
灰度发布如果只看流量比例，很容易把异常延迟或错误率放大。推荐把模型版本、请求标签、调用方和响应指标同时写入观测系统，确保灰度组出现问题时能快速回退到稳定版本。
图2：入口策略、模型版本、租户和运行时之间的灰度路由矩阵
弹性伸缩要区分冷启动和稳定吞吐
Knative Serving 面向无服务器工作负载，支持按请求驱动的自动伸缩能力[2]。在模型推理场景中，这类弹性能力很有价值，但也要正视模型加载、GPU 预热和大模型冷启动带来的特殊成本。
设计弹性策略时要拆开三个阶段：
- 冷启动阶段。实例从 0 到可服务需要加载镜像、模型权重和运行时，延迟可能明显高于普通微服务。
- 扩容阶段。流量上升后，平台要判断是增加实例、增加并发，还是切到更大的资源池。
- 稳定阶段。持续请求下更关注 P95/P99 延迟、错误率、批处理效率和 GPU 利用率。
Triton Inference Server 支持多框架模型推理、HTTP/gRPC 协议以及模型仓库等能力[3]，但运行时能力并不等同于平台弹性策略。平台仍需要决定模型预热、最小副本数、批处理窗口、队列长度和资源隔离规则。
可观测性要围绕一次请求建立关联
推理服务的观测不能只看容器指标。一次推理请求可能经过网关、鉴权、路由、模型服务、运行时、GPU 和下游业务系统。没有统一关联字段，排查时就会在网关日志、模型日志和资源指标之间来回跳转。
图3：模型推理服务按请求 ID 关联网关、模型、运行时和资源指
建议至少保留这些观测维度：
- 请求维度：调用方、租户、接口、模型名、模型版本、请求 ID。
- 性能维度：首 token 延迟、总延迟、P95/P99、超时、排队时间。
- 质量维度：错误码、拒绝原因、降级结果、灰度组差异。
- 资源维度：GPU 利用率、显存、实例副本、批处理大小、队列长度。
- 变更维度：模型版本发布、配置变更、镜像更新和回滚记录。
指标要能支持治理动作
如果一个指标不能推动限流、扩容、回滚、降级或资源调整，它可能只是展示信息。推理服务观测的目标，是让异常能被定位，并能触发明确治理动作。
落地时先建最小治理闭环
模型推理服务治理可以从“一个入口、一套版本规则、一组核心指标”开始。不要一开始就追求所有运行时、所有协议和所有灰度模式都纳入统一平台。
上线前至少检查：
- 入口是否统一经过网关或受控 Ingress。
- 模型版本是否能灰度、回滚和追踪。
- 弹性策略是否说明冷启动、最小副本和资源池边界。
- 推理日志、指标和链路是否带模型版本与请求 ID。
- 高优先级在线推理是否与训练 / 批量任务隔离。
- 调用失败是否有错误码、限流和降级策略。
小结
模型推理服务治理的核心，不是选择某一个推理框架，而是建立从入口到模型运行时、从流量路由到弹性伸缩、从请求观测到风险处置的闭环。KServe、Knative 和 Triton 分别解决声明式推理服务、请求驱动弹性和高性能推理运行时的一部分问题，平台团队要把这些能力组织成可运营的服务体系。
先把请求链路画清楚，再定义版本、弹性和观测字段，往往比先堆运行时更有效。
参考资料
- [1] KServe Documentation
- [2] Knative Serving Documentation
- [3] NVIDIA Triton Inference Server User Guide
常见问题
1. 模型推理服务一定要使用 KServe 吗？
不一定。KServe 适合需要声明式推理服务、模型版本和平台化治理的 Kubernetes 场景。如果团队只有少量模型、调用链简单，也可以先用普通 Deployment 和网关起步，但要提前保留版本、观测和回滚能力。
2. 推理服务弹性伸缩应该看 QPS 还是 GPU 利用率？
两者都不应单独决定。QPS 能反映入口压力，GPU 利用率能反映资源占用，但模型延迟、队列长度、批处理效率和冷启动时间同样重要。在线推理更建议以延迟和错误率为核心，再结合资源指标做扩缩策略。
3. API 网关和模型网关有什么区别？
API 网关更关注通用入口治理，例如认证、限流、路由和审计；模型网关还需要理解模型版本、推理协议、灰度组、调用配额和降级策略。小规模场景可以先复用 API 网关，大规模平台通常需要补充模型语义。
4. 模型推理服务治理最容易遗漏什么？
最容易遗漏版本和观测关联。模型升级后如果没有版本标签、请求 ID 和调用方信息，延迟升高或结果异常时很难判断是模型、数据、资源还是入口策略变化导致的问题。
