大模型推理成本治理从量化、缓存到 FinOps 的完整账本算力账单正在成为云上最大的一笔支出很多团队的云账单里GPU 推理的费用已经超过 CPU 业务集群。模型跑起来了账单也跑起来了是普遍现状。更麻烦的是推理成本不像 CPU 那样好预测——同样的模型prompt 长短、并发形态、缓存命中率不同成本能差出三倍。推理成本治理不是一个单纯的技术优化问题而是一套预算、计量、优化、复盘的 FinOps 循环。这篇文章按这个框架展开重点讲三个性价比最高的优化手段以及让优化效果不回退的治理机制。先算账三个计量单位治理成本的第一步是能回答钱花在哪了。推理成本由三部分组成。Token 消耗输入 tokenprompt 上下文和输出 token 分开计量。RAG 类应用里输入 token 常常占总消耗的 80%——这是优化空间最大的地方。GPU 时间按卡时计费。同样的 token 量服务端批处理vLLM 的 continuous batching能让 GPU 利用率翻倍账单直接对半。显存占用模型权重加 KV Cache 决定你能用多大的并发。显存不足会直接限制批大小间接推高单 token 成本。把这三个数接到成本看板Prometheus 加计费 API 都行是 FinOps 的前提——没有计量一切优化都是空谈。三个性价比最高的优化手段手段一量化——白捡的钱主流 70B 以下模型INT8 量化AWQ 或 GPTQ质量损失几乎不可感知显存占用直接减半推理速度提升 30%~50%。FP8 在 H 系列卡上更优。行动顺序是先量化再谈其他——这是投入产出比最高的一步。但有两个坑必须注意。一是量化后要重跑评测集量化对长上下文和推理类任务的损伤略大上线前必须验证。二是 KV Cache 量化FP8 KV要单独做别和权重量化混为一谈——权重量化解决模型装不下的问题KV Cache 量化解决并发撑不住的问题两者不是一回事。手段二Prompt 缓存——重复上下文是隐形的钱坑RAG 应用里每个问题都要把知识库片段 系统提示词重新编码一遍——这些内容可能占了输入 token 的 70% 以上而它们几乎从不变化。解法是 prompt caching各家云服务都有如 Anthropic 的 prompt caching、vLLM 的 prefix cache。把系统提示词和知识库前缀固定命中缓存的输入 token 费用降到十分之一甚至免费。一个 RAG 应用实测开启前缀缓存后输入成本降了 60% 以上。需要注意缓存命中率——缓存上了但命中率只有 20%等于没上。查前缀不一致比如提示词里混了时间戳、用户 ID这些细节会悄悄破坏缓存命中。手段三批处理与弹性——别让 GPU 闲着在线服务用 vLLM 的 continuous batching 是标配把并发请求的 KV 共享、token 级调度吞吐可以提升数倍。离线任务批量总结、评测、数据清洗用弹性实例按需拉起跑完即释放不要常驻 GPU。队列削峰把非实时任务排队峰谷错开避免为了 1% 的尖峰流量买 100% 的常驻算力。FinOps 闭环预算、归因、复盘技术优化做完还要有治理机制防止回退——没有预算的优化三个月后一定会悄悄回归。预算与告警按服务设 token/成本预算超 80% 告警、超 100% 熔断降级切小模型或限流。熔断机制尤其重要它保证在最坏情况下成本不会失控。很多团队忽略这一点直到月底账单爆炸才想起来。成本归因按业务线、按功能、按 prompt 模板拆分成本。归因到模板的意义是一个每次调用都带 2000 token 历史记录的功能成本可能是一个轻量版的三倍——归因数据会直接暴露这类问题让优化有的放矢。月度复盘每个月看三件事单 token 成本是否下降优化有没有生效、token 总量是否上升用量是否失控、模型是否大材小用简单的分类任务是否该用小模型复杂任务才用大模型。一个被低估的杠杆模型分层把请求按难度路由到不同规格模型。80% 的请求可能只需要小模型大模型只处理复杂子集——综合成本能再降 40%。实现上需要一个路由层根据任务类型、输入长度、历史成功率判断难度把请求分派给合适的模型。模型分层和量化、缓存一样都是低成本高回报的杠杆却常常被忽略。踩过的坑清单结合团队实战整理几条高频踩坑记录。只优化在线不优化离线离线批处理才是 token 消耗大户优先压它。量化后不验证上线前必须重跑评测否则出问题你分不清是量化还是业务变更。缓存命中率不看缓存上了但命中率只有 20%等于没上。GPU 利用率不看就扩卡先看利用率低于 50% 优先调批处理而不是买新卡。不设预算就上线没有预算告警成本失控是必然的只是时间问题。还有一条容易被忽视的在线服务的延迟指标TTFT、TPOT、P99与成本是联动关系——盲目加大 batch 虽然降成本但可能把 P99 延迟顶破 SLA。优化要放在延迟约束内做而不是孤立地追求吞吐。结语让账单跑得可控推理成本治理的路径很清晰计量先行token、卡时、显存三本账量化加缓存加批处理三招把单价打下来FinOps 闭环防止回退。模型跑起来不难让账单跑得可控才是架构师的本事。最后想强调一点成本优化不是一次性的项目而是持续的过程。模型在更新、负载在变化、业务在增长每个月都要重新审视这三本账。把成本治理嵌入到日常的发布流程和监控体系里比任何一次性的降本冲刺都更有价值。成本测算实例一个 70B 模型服务怎么算账光讲原则容易虚用一个具体例子把账算清楚。假设你用 Llama-3-70B 部署一个在线服务BF16 精度下权重约 140GB一张 H10080GB放不下需要双卡时租约 7 美元/小时吞吐约 890 token/s——按这个配置每百万 token 的成本约 2.18 美元。开始优化后数字会发生戏剧性变化。第一步量化AWQ 4-bit 把权重压到约 35GB双卡变成单卡时租直接砍半吞吐还因为内存带宽压力下降而提升。第二步上连续批处理batch 上来之后 GPU 利用率从不到一半拉到 80% 以上每百万 token 成本再降一半。第三步做前缀缓存和模型分层简单请求走小模型、复杂请求才上 70B综合下来每百万 token 成本能压到 0.55 美元以下——同样的模型四倍的成本差距全部来自工程手段而非模型本身。这个例子说明三件事一是量化和批处理永远是优先级最高的两件事二是成本优化的收益是乘性叠加的每做一步都在前面的基础上再降一截三是延迟约束下的优化才是有效的——如果用户的 SLA 要求 P99 小于 500ms有些吞吐优化就不能做成本会相应抬高。生产环境的优化永远是在约束内求最优而不是孤立地追最低成本。落地节奏三步走成本治理不宜一上来就大动干戈按三步走的节奏更稳。第一步先计量后动手。花一周时间把 token、卡时、显存三个计量维度接到看板上摸清现状——哪些服务花钱最多、哪些 prompt 模板最浪费、GPU 利用率是多少。没有这份账单地图优化就是无的放矢。第二步三招齐下打单价。量化、缓存、批处理这三件事同时推进。量化优先做权重 INT8/FP8见效最快缓存优先做系统提示词和知识库前缀RAG 类应用收益最大批处理检查在线服务的连续批处理是否开启、离线任务是否用了弹性实例。这一步通常能把单价降 50% 以上。第三步FinOps 闭环防回退。预算告警、成本归因、月度复盘三个机制建立起来让优化效果长期保持。特别注意模型分层这个杠杆它不像量化那样一步到位但持续收益最大值得在第二步之后专门投入。常见问题与 FAQ针对高频疑问做一组简答。问量化会不会让模型变笨答主流 70B 以下模型 INT8 量化质量损失几乎不可感知INT4AWQ/GPTQ损失约 2%~4%但前提是量化后重跑评测集验证。量化对长上下文和复杂推理的损伤略大这类任务建议保留高精度部署。问用了云厂商的 prompt caching还需要自建前缀缓存吗答不需要重复建设。云服务的 prompt caching 通常已经覆盖前缀复用的场景自建前缀缓存更多是本地私有化部署时的选择。关键是确认缓存命中率在 50% 以上否则等于没开。问小模型够用吗什么时候必须上大模型答判断标准不是模型大小而是任务难度。简单分类、抽取、格式化用 7B~14B 完全够多步推理、复杂指令遵循、长文本理解才需要 70B 级。先用评测集验证小模型能否达标达标就用小的——这是成本治理里最朴素的道理。问弹性算力会不会影响在线服务的稳定性答要区分在线和离线。在线服务用固定资源池保障 SLA离线批处理用弹性实例按需拉起。混合策略是最优解把可延迟的任务排队到低谷期执行既省钱又不牺牲用户体验。