模型服务的下一站：从 API 暴露到平台能力内化

模型服务的下一站从 API 暴露到平台能力内化一、一个 API Key 解决不了的问题2024 年到 2025 年初大多数团队的 AI 基础设施是这样建的申请一个 OpenAI 兼容的 API Key封装一个 HTTP Client业务代码里调用client.CreateChatCompletion()完事。简单、快速、成本透明——至少最初三个月是这样。但当业务线的调用从每天几百次涨到几十万次时模式开始崩塌。API Key 模式至少暴露出四个无法回避的问题第一网络延迟不可控。公网 API 的 P99 延迟可以轻松超过 2000ms且你无法干预——不知道是对端限流了、GC 了、还是在跨数据中心传输。第二数据安全审计缺失。业务代码里的 prompt 和返回内容全部走外部 API内容审计完全失控。第三成本非线性增长。月消费从 ¥800 涨到 ¥23,000 只用了两个月但这不是最危险的——最危险的是没人能回答谁花了多少钱、为什么花了这么多。第四也是最重要的一点模型服务的可靠性不在你的控制范围内。供应商宕机时整个业务线停摆除了等没有其他办法。二、从 API 消费者到平台能力提供者这张图表达了一个核心观点模型服务的发展方向不是更好地调用 API而是把推理能力变成平台的基础能力像计算、存储、网络一样——它就在那里用户不需要关心它跑在哪里。能力一推理网关推理网关是整个平台能力内化的第一层。它的上游对接多个模型实例包括自建的 vLLM 实例和外部 API 的 fallback下游暴露统一的 OpenAI 兼容接口。网关的核心职责不是转发请求而是做三件事请求路由根据请求特征token 长度、优先级、业务标签将请求分发到最优的模型实例。比如代码补全请求的 token 很短对延迟要求高路由到 T4 集群文档总结的 token 很长但对延迟容忍度高路由到大显存的 A100 实例的批处理队列。鉴权与配额每个业务线分配独立的 API Key绑定 GPU 配额和 QPS 限制。配额用完后请求直接拒绝不影响其他业务线。全链路打点记录每个请求的 token 数、推理耗时、GPU 型号、排队时长为成本归因提供原始数据。能力二GPU 资源池化自建推理服务的核心挑战不是部署而是资源利用率的平衡。一卡 A100 如果只跑一个模型显存利用率通常在 60% 以下但把多个模型塞到一张卡上资源争抢又会导致推理延迟不可预测。资源池化的核心逻辑是将 GPU 按模型特性分为不同的池子每个池子有自己的调度策略和扩缩容规则。能力三成本归因这是平台能力内化中最不性感但最有价值的能力。API Key 模式下的成本是一笔糊涂账——账单汇总到部门没人能拆分到具体业务线。在自建平台上成本归因的粒度可以做到请求级别。每个推理请求在网关层被打上business_line、model、gpu_type三个标签GPU 耗时乘以对应的实例单价就是这笔请求的成本。月结时按业务线、按模型、按 GPU 型号三维下钻哪条业务线是成本大户一目了然。成本透明之后神奇的事情发生了业务线开始自觉优化 prompt 长度、控制调用频率、甚至主动询问有没有更便宜的模型可以替代。当成本从技术团队的事变成了业务团队的事优化就是自驱的。三、能力内化的阶段性策略能力内化不是一个一步到位的工程。我们的实施路径分了三个阶段第一阶段当前推理网关 GPU 池化 成本归因。这三项覆盖了模型服务的核心链路解决的是能不能跑稳和知不知道花了多少钱的问题。第二阶段未来 3-6 月模型版本管理 灰度发布 A/B 评估。当平台上跑的模型超过 5 个时模型更新就变成了一个高频操作。没有灰度发布能力的平台一次错误的模型更新可以让整个业务线瘫痪半小时。第三阶段未来 6-12 月多集群联邦 跨区域调度 GPU Spot 实例大规模应用。当一个集群的 GPU 资源枯竭时自动将请求路由到另一个集群的 GPU 节点。这部分依赖 K8s Federation v2 和 GPU Topology-aware Scheduling。四、不适用场景平台能力内化有明确的适用边界。如果你的团队模型调用频率很低日均低于 1 万次、模型种类单一、且对延迟波动有一定容忍度直接使用公有云 API 是更经济的选择。自建推理平台的管理成本不可忽略——至少需要一个 0.5 人力的运维投入、持续的 GPU 节点维护和定期的推理框架升级。另一个边界是团队能力。自建推理平台要求团队同时具备 Kubernetes 运维能力、Go/Python 开发能力和模型推理框架的使用经验。如果团队在这三个维度上都是短板强行自建只会制造一个新的事故源。五、总结模型服务的下一站不是更好的 API而是把推理能力变成像计算和存储一样的基础设施——它应该是透明的、可靠的、可度量的。从 API 消费者转向平台能力提供者意味着从“用别人的服务”变成“管理自己的服务”。随之改变的是责任边界推理服务不稳定时团队需要依赖供应商响应还是能通过自己的监控定位根因基础设施不需要漂亮话。把推理能力内化就是把可靠性的控制权拿回自己手里。资料说明本文中的协议、版本、性能、成本和行业趋势应以可核验的一手资料为准。未标注统计口径的比例、时间表和预测仅作工程讨论不应视为行业事实。可参考 0731 资料来源索引并在发布前将具体来源贴到对应断言之后。