一、项目背景

去年我们这套 AI 能力平台接入的业务方从最初的两个内部系统快速扩张到十几个部门。最开始大家调用模型都是各自写 SDK、各自申请 key，谁用了多少、花了多少钱，财务和技术都算不清。等到月底账单出来，一行"AI 推理费用"就是一大笔，却没人能说清楚这笔钱究竟是被哪个业务线、哪个应用、哪类场景吃掉的。

我们当时采用的 AI 网关技术平台还没把计量层真正用起来，多数团队是直连底座推理服务的，限流靠各业务自己在客户端凑合做，熔断基本没有，遇到上游模型实例抖动就整片超时。更麻烦的是，成本完全是个黑盒：大模型按 token 计费，小模型按调用次数，多模型混合调用后根本拆不开。

这个背景下，我们决定把全公司的 AI 调用统一收口到网关，把计量、限流、熔断、可观测当成一盘棋来打，先把钱花在哪看清楚，再谈优化。

二、落地场景

落地后，所有业务方不再直连底座推理服务，而是统一走我们采用的 AI 网关技术平台。网关的接入层做鉴权和协议归一化，路由层按成本和延迟选模型，计量层对每一次调用做 token 级与耗时级计量，并按部门、应用、用户三个维度沉淀配额和账单。

底座推理服务通过 Prometheus 暴露吞吐、延迟、GPU 利用率等指标，网关把调用链、错误率、路由命中情况也上报，最终在统一看板上打通。运维第一次能在同一个界面里看到"哪个部门昨天烧了多少 token""哪个应用的大模型调用占比异常偏高""某张 GPU 卡是不是在空转"。

我们在接入层还前置了一层语义相似缓存：对进入网关的请求先算 embedding，命中近邻就直接返回历史答案，根本不进底座。这一层上线后，纯重复类咨询（如"怎么查物流""退换货政策"）几乎不再消耗大模型 token。

具体场景上，财务按月拉部门账单做内部结算；平台组按应用维度设配额和预算告警；SRE 用延迟分布和错误率曲线判断是不是该触发底座弹性扩容。网关的限流信号还会反向驱动底座弹性扩缩容，形成算力—流量联动闭环。更重要的一点是，过去业务方直连底座时，谁超量谁抖动只能靠互相甩锅，现在所有锅都落在同一张看板上，定位责任从"拉群吵架"变成"点开链路看一眼"。

三、关键技术挑战与解决思路

第一个挑战是 token 级计量分部门账单。网关接入的请求必须带上部门与应用标识，但早期很多业务把标识写死在 header 里，容易漏。我们的做法是网关在接入层做一次"租户上下文"注入：调用方只传一个应用 app_key，网关从注册表反查出部门归属，再在计量层落一条带 dept_id、app_id、user_id、model、input_tokens、output_tokens、cost 的明细。账单按天聚合，月底再 rollup。

案例片段（已脱敏）：某月部门级计量账单样例（JSON 片段）json {  "period": "2026-05",  "dept": "智能客服部",  "app": "cs-knowledge-qa",  "model_mix": {    "self-72b-instruct": {"calls": 184230, "in_tokens": 91234560, "out_tokens": 20567430, "cost_cny": 1842.3},    "self-7b-chat":     {"calls": 521144, "in_tokens": 78321000, "out_tokens": 9981200,  "cost_cny": 312.5}  },  "total_cost_cny": 2154.8 }

第二个挑战是成本归因下钻。光有总量不够，得能定位到"是哪类 prompt 在烧钱"。我们在编排层对请求打语义标签（意图分类、是否走 RAG、是否多轮），计量记录里多存一个 scene_tag 字段。下钻时按 scene_tag 聚合，很快就发现某金融客户的知识库问答里，长文档摘要类请求平均输出 token 是普通问答的 7 倍，是降本重点。顺着这条线，我们给编排层加了一条路由改写规则：摘要类请求默认先走小模型抽关键段、再让大模型基于浓缩内容作答，输出 token 直接砍掉约六成，质量评测上几乎无感知。

第三个挑战是可观测。延迟和错误率相对好办，真正难的是把网关侧和底座侧打通：一次超时，到底是网关路由慢、还是底座 GPU 排队。我们统一了 trace_id，网关 span 与推理框架的排队 span 串成一条链，Grafana 上同时叠 GPU 利用率曲线。当 GPU 利用率持续高于 92% 且 P99 延迟抬升，就自动触发底座扩容，而不是等告警再人工处理。这里有个坑要提：很多团队只看 QPS 不看排队深度，结果 GPU 利用率看着不高、延迟却一路涨，根因是推理框架的 continuous batching 队列堆满了。我们后来把队列长度也作为扩容前置信号，比单纯看利用率灵敏得多。

第四个挑战是配额预算告警。我们给每个应用设月度预算和硬性配额，网关在计量层做实时累计。限流不是简单一刀切，而是分级：软限流（逼近预算时降速并告警）、硬限流（超配额直接 429）。限流规则下发到接入层，示例如下：

案例片段（已脱敏）：网关限流与预算告警规则片段yaml rate_limit:  app: cs-knowledge-qa  monthly_budget_cny: 2600  soft_limit:    threshold: 0.85        # 预算用尽 85% 触发降速告警    action: throttle_and_alert  hard_limit:    quota_rpm: 1200        # 单应用每分钟请求硬上限    action: reject_429 alert:  channel: ["sre-pager", "fin-ops"]  cooldown_min: 30

四、效果数据

统一收口并跑满一个季度后，我们拉了改造前后的对比。以下均为脱敏示意值。

缓存命中率提升是最直接的降本来源，不需要买更多卡，只把重复问题挡在网关层。

五、可复用经验总结

第一，先看见再优化。在没把计量和看板做起来之前，所有降本建议都是拍脑袋。把 token 级账单和场景标签打通后，优化方向自己就跳出来了。

第二，缓存是性价比最高的降本手段。我们在网关接入层加了语义相似缓存（embedding 近邻命中即返回），几乎零底座成本，却把近一半重复流量挡在了大模型之外。

第三，限流熔断要分级且与底座联动。软限流保体验、硬限流保系统，限流信号反向驱动底座扩容，比纯人工运维响应快一个数量级。

第四，客户数据务必脱敏、可审计。计量层天然带了部门和用户维度，我们同步做了字段脱敏和访问审计，避免内部账号越权看别人账单。

第五，计量要算准流式输出。大模型普遍走 SSE 流式返回，用户中途断开时已经吐出的 token 仍要计入账单，否则财务对账会差一截。我们在网关侧按实际 flush 的 chunk 累加计费，而不是按请求结束时的总量，这样断流、超时、被限流的各种边界情况都能对平账。