大模型推理成本治理：从量化、缓存到 FinOps 的完整账本

算力账单正在成为云上最大的一笔支出

很多团队的云账单里，GPU 推理的费用已经超过 CPU 业务集群。「模型跑起来了，账单也跑起来了」是普遍现状。更麻烦的是，推理成本不像 CPU 那样好预测——同样的模型，prompt 长短、并发形态、缓存命中率不同，成本能差出三倍。

推理成本治理不是一个技术优化问题，而是一套预算、计量、优化、复盘的 FinOps 循环。本文按这个框架展开，重点讲三个性价比最高的优化手段。

一、先说账怎么算：三个计量单位

治理成本的第一步是能回答「钱花在哪了」。推理成本由三部分组成：

Token 消耗：输入 token（prompt + 上下文）和输出 token 分开计量。RAG 类应用里，输入 token 常常占总消耗的 80%——这是优化空间最大的地方。

GPU 时间：按卡时计费。同样的 token 量，服务端批处理（vLLM 的 continuous batching）能让 GPU 利用率翻倍，账单直接对半。

显存占用：模型权重 + KV Cache 决定你能用多大的并发。显存不足会直接限制批大小，间接推高单 token 成本。

把这三个数接到你的成本看板（Prometheus + 计费 API 都行），是 FinOps 的前提。

二、三个性价比最高的优化手段

1. 量化：INT8/FP8 是白捡的钱。主流 70B 以下模型，INT8 量化（AWQ 或 GPTQ）质量损失几乎不可感知，显存占用直接减半，推理速度提升 30%~50%。FP8 在 H 系列卡上更优。行动顺序：先量化再谈其他——这是投入产出比最高的一步。

注意两个坑：一是量化后要重跑评测集（量化对长上下文和推理类任务的损伤略大）；二是 KV Cache 量化（FP8 KV）单独做，别和权重量化混为一谈。

2. Prompt 缓存：重复上下文是隐形的钱坑。RAG 应用里，每个问题都要把「知识库片段 + 系统提示词」重新编码一遍——这些内容可能占了输入 token 的 70% 以上，而它们几乎从不变化。

解法是 prompt caching（各家云服务都有，如 Anthropic 的 prompt caching、vLLM 的 prefix cache）。把系统提示词和知识库前缀固定，命中缓存的输入 token 费用降到 1/10 甚至免费。一个 RAG 应用实测：开启前缀缓存后，输入成本降了 60% 以上。

3. 批处理与弹性：别让 GPU 闲着。在线服务用 vLLM 的 continuous batching 是标配，把并发请求的 KV 共享、token 级调度，吞吐可以提升数倍。离线任务（批量总结、评测、数据清洗）用弹性实例按需拉起，跑完即释放，不要常驻 GPU。队列削峰：把非实时任务排队，峰谷错开，避免为了 1% 的尖峰流量买 100% 的常驻算力。

三、FinOps 闭环：预算、归因、复盘

技术优化做完，还要有治理机制防止回退：

1. 预算与告警：按服务设 token/成本预算，超 80% 告警、超 100% 熔断降级（切小模型或限流）。没有预算的优化，三个月后一定会悄悄回归。

2. 成本归因：按业务线、按功能、按 prompt 模板拆分成本。归因到模板的意义是：一个「每次调用都带 2000 token 历史记录」的功能，成本可能是一个轻量版的三倍。

3. 月度复盘：看三件事——单 token 成本是否下降（优化有没有生效）、token 总量是否上升（用量是否失控）、模型是否「大材小用」（简单的分类任务是否该用小模型，复杂任务才用大模型）。

一个被低估的杠杆是模型分层：把请求按难度路由到不同规格模型。80% 的请求可能只需要小模型，大模型只处理复杂子集——综合成本能再降 40%。

四、踩过的坑清单

- 只优化在线不优化离线：离线批处理才是 token 消耗大户，优先压它。

- 量化后不验证：上线前必须重跑评测，否则出问题你分不清是量化还是业务变更。

- 缓存命中率不看：缓存上了但命中率只有 20%，等于没上。查前缀不一致（比如提示词里混了时间戳、用户 ID）。

- GPU 利用率不看就扩卡：先看利用率，低于 50% 优先调批处理，而不是买新卡。

结语

推理成本治理的路径很清晰：计量先行（token、卡时、显存三本账），量化 + 缓存 + 批处理三招把单价打下来，FinOps 闭环防止回退。模型跑起来不难，让账单跑得可控，才是架构师的本事。