自建 LLM 网关的成本排查实录：$199 的虚高账单与 48% 的失踪流量

# 自建 LLM 网关的成本排查实录：$199 的虚高账单与 48% 的失踪流量 ## 背景：账单突然吓人，账还对不上 为了统一管理多家 LLM 渠道（DeepSeek、Kimi、智谱等），我自建了 new-api 网关，所有模型请求都从网关走。某天查看 token 消耗报表，吓了一跳：**一天消耗折算 $199.21**。而同一时间，我在 DeepSeek 官方控制台拉取的消费明细却和网关日志对不上——**官方显示 782 次请求，网关只记录了 403 条，将近一半的流量"失踪"了**。 两个问题叠加：钱花得莫名其妙，账还对不上。于是做了一次完整的成本排查。 ## 第一层：价格没配置，默认计价率虚高 100-280 倍 最先查的是网关的计价配置。排查发现，新增渠道时**没有配置上游价格**，网关落到了默认计价率（rate=37.5）上，把成本虚高了 **100-280 倍**。也就是说，$199.21 这个数字本身就是"价格未配置"的产物——真实成本远没有这么多。 修复方式：不再手工填价格，改用 **models.dev 的公开预设**一键同步上游价格（之前尝试直接从上游官方接口同步，但接口鉴权不稳定，models.dev 的公开数据更省事）。同时写了价格同步脚本，定期把渠道价格与上游对齐，避免再次出现"新渠道忘配价"的隐患。 ## 第二层：凌晨重试风暴与上下文膨胀 价格修好后再看，当天实际只花了 $0.90，看起来正常了。但 token 消耗量仍然异常：**峰值约 314 万 tokens/小时**。继续往下挖，发现三个叠加因素： 1. **凌晨重试风暴**：容器重启导致在途请求批量重试，一次就触发 101 组重试； 2. **手机端会话上下文膨胀**：一个 API 客户端会话的上下文膨胀到了约 12 万 tokens，每轮对话都要全量携带； 3. **工具调用全量重发**：一轮对话里 Agent 连续调用 33 次工具，每次调用都把整个上下文重新发送一遍。 这三个因素叠加，token 消耗量就指数级放大了。但好消息是：**网关缓存命中率很高，实际产生计费的部分极少**——看着 314 万 tokens/小时的数字吓人，真实花费只有 $0.06。典型的"数字吓人，钱包没事"。 ## 第三层：对账揪出 48% 的"失踪"流量 最关键的发现来自对账。把 DeepSeek 官方控制台的每日明细（按 UTC 对齐）和网关日志逐条比对，结论是：**官方 782 次 vs 网关 403 条，缺了 379 条（约 48%）**。前两天差异更大（官方 3000+ 次 vs 网关 66 条）。 为什么网关会漏记？根因找到了：**Hermes 的 fallback 配置里 `fallback_providers[0]` 直连了 DeepSeek 官方**。当主渠道（网关）请求失败时，请求会 fallback 到官方直连，**完全绕过网关**——流量走了，但网关的记账、缓存、限流全都没生效。之前的对账数据（7/31-8/2 官方 flash 消费 $46.3）也印证了这一点：这笔钱根本没进网关的账。 修复方向：把 fallback 从"官方直连"改为"走网关的备用渠道"，让所有流量都落在网关内，账才能对得上。 ## 结论与经验清单 这次排查的收获，按优先级排： 1. **价格配置是第一优先级**。渠道新增后不配价格，默认计价率会把成本虚高上百倍。用公开预设（models.dev）自动同步，并加脚本定期对齐。 2. **fallback 也要走网关**。任何绕过网关的直连都会造成流量"失踪"：记账、缓存、配额、限流全部失效。网关的意义在于"所有流量一条道"，fallback 也不例外。 3. **上下文膨胀是 token 消耗的大头**。手机端会话上下文膨胀到 12 万 tokens、一轮 33 次工具调用全量重发，比模型本身的消耗更可怕。长会话该新开就新开，别硬撑。 4. **缓存命中是救命稻草**。同样的请求反复发，缓存命中后实际计费几乎为零。网关的缓存机制值得配置好。 5. **对账是发现问题的唯一可靠手段**。官方控制台明细 vs 网关日志，按 UTC 对齐逐条比对——数字对不上，一定是哪里绕了路。定期对账能揪出所有"隐形通道"。 最后补一句：**账单吓人的时候先别慌**。价格未配置、重试风暴、上下文膨胀，这些都是配置问题而不是真实消耗——先把计价配置查一遍，再谈优化。而真正要警惕的，是那些"对不上账"的流量：它们往往意味着有请求走了你管不到的路。