企业把大模型接入统一 API 网关后，常见的问题不是调用失败，而是没人说得清钱花在哪里。财务只看到一个账单数字，团队也只看到一个端点；哪个团队消耗了 40% 预算、哪个用例在增长、哪个实验跑了六周还没关，都隐藏在总账单里。Dev.to AI 的一篇工程复盘把解决办法放在 LLM Gateway：在网关层完成 Token 计量，把模型成本拆到团队、产品和环境。
计量点为什么要放在网关
普通 REST API 可以按请求数计费，但大模型调用的成本单位是 token。一次聊天请求可能只消耗 5 tokens，也可能消耗 5000 tokens；一个整夜循环运行的 prompt injection 测试，可能在 8 小时内花掉超过一个产品团队整月预算。更关键的是，token 数量通常写在响应里。Azure OpenAI 会在 usage 字段中返回 prompt_tokens、completion_tokens 和 total_tokens，例如 1240、312、1552。如果网关不当场捕获，后续只能从日志重建。
该团队没有让各业务在自己的应用代码里埋点。原因是网关是唯一必经层，不依赖语言、框架或团队；如果靠各团队自行实现，在好的月份也可能只覆盖 60% 流量。他们的做法是：请求进入网关时，打上订阅、产品、环境等元数据；响应离开网关时，解析 usage，提取 token 数，并把事件发送到分析管道。调用方看不到请求或响应被修改，网关只负责观察和上报。
- 归属信息：subscription id、product、environment；
- 模型信息：model；
- 消耗指标：prompt_tokens、completion_tokens、latency；
- 状态信息：响应码，失败请求单独归类但计入总消耗。
失败请求也要算钱，告警要先于硬停
第一版计量只统计成功调用，两周后便暴露问题：有人对已弃用的模型部署跑批量任务，整天返回 400。单次失败请求便宜，但累计达到数十万次，供应商仍会对输入 tokens 收费。失败请求、限流请求、触发内容过滤的请求，同样会消耗输入 tokens。如果只统计 200，看板和账单必然不一致，而财务只会相信账单。于是，团队记录所有响应码，失败请求单独展示，但不从总成本中剔除。第一次有团队看到自己在 400 上花了多少钱后，当天下午就修复了客户端代码。
成本展示也需要落到具体团队。一个月 50,000 美元的公司级 LLM 账单很难推动行动；但一个团队看到自己在某个模型上花了 9,000 美元、环比增长 40%，就会迅速改变行为。该团队按团队、模型、日期展示 tokens 和估算成本，并用一份模型价格表把 tokens 换算成金额。估算并不完美，但足以支持决策。
随后，他们加入预算告警和硬停。预算达到 50%、80%、100% 时，告警会发送到团队频道；多数团队在 50% 时就会自我纠正。对仍未收敛的调用，网关才限流，直到有人提高预算。团队刻意先告警、后硬停，因为硬停应主要用于失控循环，而不是让工程师在紧急 demo 中把网关当成敌人。
三个经验教训
如果重新开始，该团队会做三项调整。第一，从第一天就计量流式响应。流式响应的 token 数在结束时返回，第一版实现因此漏掉了数据，而流式使用普及速度超出预期。第二，更早标准化元数据。早期允许团队自由添加属性，导致同一个项目名出现过三个不同 key，后续统一字段很繁琐。第三，把价格表纳入版本控制，并加入审查流程。模型价格会变化，旧估算会失真；现在，价格表像代码一样通过 pull request、reviewer 和 changelog 管理。
这套做法的核心不是财务对账，而是建立反馈回路。当团队能看见每次调用花了多少钱，模型消耗就从财务黑箱变成工程变量。LLM Gateway 也从流量入口，变成成本归因、配额管理和工程审计的第一道关口。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/dang-da-mo-xing-zhang-dan-bian-cheng-tuan-dui-ke-jian-de
