夜雨聆风系列：从零开始的 AI Infra 之路
位置：第 14/18 篇 · 卷四「可观测性与成本」
难度：⭐⭐⭐⭐（1-5 星）
前置知识：GPU 计费、容量规划、推理服务指标
配套资料：关注公众号，回复「AIInfra成本」领取：AI成本归因表、推理容量与成本估算器
前后关系：上一篇「LLM 系统的可观测性」；这一篇聚焦「AI 系统的成本治理」；下一篇「AI 系统的 SRE 实践」。
01. GPU 账单不是财务问题，先是工程问题
一个 LLM 应用刚上线时，团队通常关注两个问题：能不能答，答得快不快。等流量上来，第三个问题会突然变得尖锐：为什么账单这么高。更麻烦的是，账单经常只告诉你某个 GPU 节点池花了多少钱，却不告诉你是哪个功能、哪个模型、哪个租户、哪类请求把钱花掉了。
这时很多讨论会滑向“省钱技巧”：换便宜 GPU、用 INT4、开 prefix caching、上 Spot、把大模型换成小模型。每个建议都有价值，但如果没有统一度量和归因，技巧很容易变成拍脑袋。量化可能降低显存却伤害复杂任务质量；小模型路由可能省钱但让人工客服兜底成本上升；Spot 可能便宜但让在线推理在中断时雪崩；批处理可能提升吞吐但把用户等待时间推高。
AI 成本治理先要承认一件事：不度量的成本无法治理，不归因的账单无法优化，不拆分的成本无法让业务做理性决策。GPU 账单最终落到财务系统，但它的形状由工程系统决定：模型大小、token 长度、并发策略、KV cache 命中、路由策略、批处理窗口、SLO 冗余、节点池类型、失败重试和产品定价。
AI 成本治理不是找几个省钱技巧，而是一套工程纪律。先建立单位成本公式，再把成本归因到功能、模型、租户和用户类型，然后按收益量级、质量风险和可靠性边界排序优化手段。成本优化不能脱离质量和延迟，否则账单下降可能只是把成本转移给用户、人工审核或后续修复。
02. 先把推理成本拆成公式
推理成本最小的可计算口径是每 1K tokens 成本。一个保守估算公式可以写成：GPU 每小时价格 × GPU 数量 ÷ 有效利用率 ÷ tokens/s × 1000 ÷ 3600。这个公式不完美，没有覆盖存储、网络、工程人力和外部 API，但它足以把最核心的变量拆开。
公式里每个变量都对应一个工程问题。GPU 每小时价格取决于供应商、型号、地域、购买方式和是否使用 Spot 或预留容量。GPU 数量取决于模型大小、tensor parallel、热副本、峰值冗余和多可用区策略。有效利用率取决于流量曲线、批处理、调度、冷启动、空转和 SLO 冗余。tokens/s 取决于模型、量化、推理引擎、batch、上下文长度、KV cache 和硬件。1000 ÷ 3600 只是把秒级吞吐换算到每 1K tokens。
一个简单例子能说明量级。假设某模型服务使用 4 张 GPU，每张 2 美元/小时，有效利用率 40%，实际吞吐 800 tokens/s。那么每小时 GPU 成本是 8 美元，按有效利用率折算为 20 美元/小时，800 tokens/s 等于每小时 288 万 tokens，单位成本约 0.0069 美元/1K tokens。若利用率下降到 20%，其他不变，单位成本翻倍；若吞吐提升到 1600 tokens/s，单位成本减半。GPU 单价没变，账单口径已经完全不同。
这个估算还没有加入冗余和失败。在线服务为了低延迟常常保留热副本，低峰时空转；长请求可能占用 KV cache 拖慢短请求；失败重试会消耗额外 token；外部模型 API 可能按输入输出分别计费；RAG 还会有 embedding、rerank、向量库和存储成本。公式不是为了精确到财务小数点，而是让团队知道每个工程决策怎样改变成本。
成本治理的危险做法是只看月账单总额。总额上升可能是用户增长，可能是 token 变长，可能是利用率下降，可能是小模型路由失效，也可能是某个功能被滥用。没有单位成本和分解变量，任何“优化成功”都说不清楚是流量变化还是工程改进。
03. 账单必须归因到功能、模型和用户
云厂商账单通常按资源给出：实例、磁盘、网络、负载均衡、对象存储。AI 产品团队需要回答的问题却是另一组：客服问答多少钱，摘要功能多少钱，代码助手多少钱；大模型花了多少，小模型花了多少；免费用户消耗多少，付费用户消耗多少；哪个租户的长上下文请求正在拖高成本。
这就是成本归因。没有归因，团队只能对着总账单争论；有了归因，才能做产品和工程决策。比如免费用户的长文档总结占了 35% GPU 成本，但转化率很低，产品可以限制长度或改成异步；某个内部搜索功能使用大模型生成长答案，但用户只看引用摘要，工程可以改成小模型或模板；某个付费租户成本高但收入也高，优化策略就不应该和免费试用一样。
成本归因需要三类数据合流。第一类是资源账单：GPU 小时、节点池、实例类型、存储、网络、地域、购买方式。第二类是服务指标：模型服务、replica、engine、tokens/s、GPU 利用率、input/output tokens。第三类是请求元数据：request_id、tenant、feature、model、prompt_version、user_type、route、token 数。资源账单告诉你钱花在哪些机器上，服务指标告诉你机器服务了哪些模型，请求元数据告诉你模型服务了哪些业务。
归因不一定一开始就做到请求级财务精算。可以先按模型服务和功能模块分摊，再逐步细化到租户和用户类型。关键是口径稳定。比如同一 GPU 服务上跑多个模型，就按 token 或 GPU 时间估算分摊；同一功能走多个模型，就按 route 记录分别聚合；共享 embedding 服务可以按请求数、token 数或 batch 任务量分摊。口径可以有误差，但不能每周变。
标签治理是成本归因的基础。节点池要有 cost_center、gpu_type、purchase_type；部署要有 service、model、owner；请求要有 feature、tenant、user_type；prompt 和路由要有 version。缺少标签的成本应该进入“未归因”桶，并设置比例目标。未归因成本长期超过 10-20%，说明成本治理还没有进入工程系统。
04. 降本优先级要看收益量级和副作用
常见降本手段可以分成五类：量化、prefix caching、请求路由、批量合并、Spot 或抢占式资源。它们不是同一类优化，作用变量和风险完全不同。把它们放在一张表里比较，能避免“看到一个技巧就立刻上”的冲动。
量化主要降低显存占用，并可能提升吞吐。INT8、INT4、NF4、GPTQ、AWQ、bitsandbytes 等路径各有边界。显存下降 40-70% 是常见目标区间，但具体收益取决于模型、硬件 kernel、上下文长度和推理引擎。量化的副作用是质量和兼容性风险：复杂推理、多语言、代码、数字计算、长上下文任务更需要评测门禁。不能只看困惑度，必须看目标任务。
Prefix caching 复用共享 prompt 前缀的 KV cache，适合 system prompt 很长、RAG 前缀重复、模板化请求高的场景。它节省的是重复 prefill 计算，不是魔法压缩。若请求前缀分散、用户上下文高度个性化，命中率就低。它还需要监控 cache 命中率、命中带来的 TTFT 改善、显存占用和失效策略。
请求路由把简单任务送到小模型，把复杂或高价值任务送到大模型。收益可能很高，因为模型大小和单位成本差距可以达到数倍。但路由最怕错：小模型处理复杂任务会降低质量，大模型处理简单任务会浪费成本。路由必须有质量反馈、兜底升级和阈值校准。
批量合并适合离线摘要、批量 embedding、离线评测、报表生成。它通过提高 GPU 利用率降低单位成本，但会增加等待时间。实时对话、代码补全、客服辅助不能盲目扩大 batch；离线任务则应该尽量集中处理，用队列吸收波峰。
Spot 或抢占式 GPU 适合训练、离线批处理和可恢复任务。它降低的是采购价格变量，代价是中断风险。没有 checkpoint、幂等重试和容量兜底，Spot 只是把成本风险换成稳定性风险。在线推理可以把低优先级或内部异步任务放到 Spot，但核心实时服务应有按需容量兜底。
05. 量化不是只把 bit 数调小
量化经常被当成降本第一反应，因为它直观：权重从 fp16 变成 int8 或 int4，显存更小，单卡能放更大模型或更高并发。但这里要谨慎，bit 数只是结果，决定线上表现的是量化方法、校准数据、运行时 kernel、任务质量和回滚能力。
对推理服务来说，量化收益主要来自三处。第一，模型权重显存下降，给 KV cache 留出更多空间。第二，同样显存下可以提高 batch 或并发上限。第三，若硬件和 kernel 支持，低 bit 计算或内存带宽压力下降可能提高吞吐。注意第三点不是必然成立。某些格式显存省了，但 kernel 不匹配，速度未必更快。
量化评测要按任务分层。客服问答、代码生成、数学推理、摘要、分类、RAG 忠实度，对量化误差的敏感度不同。一个模型在通用 benchmark 上变化很小，不代表业务场景无损。尤其是需要严格格式、数字、引用、工具调用参数的任务，要看结构化错误率和人工 review，而不只是平均分。
量化还会改变成本归因。模型变小后，单卡可容纳更多并发，单位 token 成本可能下降；但如果质量下降导致用户追问次数增加、人工客服接管增加、fallback 到大模型增加，真实成本可能回升。因此量化上线要同时看 $/request、TTFT、TPOT、失败率、用户反馈和 fallback 比例。
推荐的落地方式是先做离线评测，再做小流量灰度。离线评测覆盖固定回归集和线上失败样本；灰度阶段按 route 或 tenant 切一小部分流量，比较质量和成本；保留原模型回滚；确认不同长度、不同语言、不同任务类型的指标。量化是强工具，但不是免费午餐。
06. Prefix caching 省的是重复前缀，不是所有请求
很多 LLM 应用都有长 system prompt：角色、格式、工具说明、安全规则、业务背景。RAG 应用还会把召回文档拼进上下文。如果大量请求共享相同前缀，重复 prefill 会浪费计算。Prefix caching 的思路是复用相同前缀对应的 KV cache，让后续请求少做一部分 prefill。
它最适合三类场景。第一，固定 system prompt 很长，用户问题较短。第二，RAG 检索结果高度重复，比如同一批政策文档被频繁问。第三，批量任务模板一致，只是变量不同。对这些场景，cache 命中能降低 TTFT 和 GPU 计算，进而改善单位成本。
它不适合被夸大。若每个用户的历史对话都不同、RAG 召回文档高度分散、prompt 模板频繁变更，命中率会低。若 cache 占用显存过多，也可能挤压正常 KV cache，影响并发。若前缀中包含用户敏感信息，还要保证 cache key 和隔离策略不会跨租户复用不该复用的上下文。
Prefix caching 的监控指标至少包括 cache hit rate、命中请求的 TTFT 改善、未命中请求比例、cache 占用显存、按 prompt_hash 的命中分布、按 tenant 的隔离情况。只打开功能不看命中率，就无法判断它是在省钱，还是只是在占显存。
Prompt 版本管理会直接影响 prefix caching。system prompt 每改一次，hash 变化，cache 命中可能下降。RAG 文档排序不稳定，也会让前缀不同。为了提高命中率，团队可以稳定模板、规范文档拼接顺序、把高频共享说明放在前缀、避免把无关动态字段塞进前缀。但这些优化不能牺牲正确性，尤其不能为了命中率跨用户共享敏感上下文。
07. 请求路由是成本治理的控制平面
在多模型系统里，最大浪费之一是所有请求都走同一个大模型。分类、格式转换、短摘要、模板回复、低风险内部工具，常常不需要最强模型。相反，复杂推理、高价值客户、合规风险高、需要长上下文忠实回答的请求，不能为了省钱盲目走小模型。请求路由的目标是：把每次调用送到足够好的最小模型。
路由器的输入不能只有 token 数。token 数能反映上下文长度，但不能充分反映任务难度。更合理的特征包括功能模块、任务类型、用户等级、是否需要引用、检索分数、历史失败率、prompt 复杂度、是否需要工具调用、是否有严格格式要求、延迟预算。特征要可解释，否则质量事故时无法复盘“为什么当时走了小模型”。
路由策略可以从简单规则开始。短文本分类走小模型；高价值付费租户的复杂问答走大模型；离线批量摘要进入批处理队列；小模型低置信或用户追问时升级大模型；安全或合规高风险任务进入保守路径。规则不如学习型路由器灵活，但容易审计，适合早期建立基线。
路由错误有两种代价。保守错误是本该小模型处理的请求走了大模型，成本变高但质量通常有保障。激进错误是本该大模型处理的请求走了小模型，成本下降但质量风险上升。不同业务对两种错误的容忍度不同。客服、法律、财务、医疗类场景更怕激进错误；内部低风险工具可以更激进。
路由上线必须记录 route、score、decision_reason、fallback_reason、model、cost、quality_signal。没有这些字段，路由策略无法迭代。比如小模型路径的 thumbs down 比例上升，要能看到是哪个任务类型、哪个阈值、哪个 prompt 版本导致。大模型占比上升，要能判断是流量真的变复杂，还是路由器阈值漂移。
成熟的路由不是一次配置，而是持续校准。每周用线上采样和固定评测集比较不同路径的质量和成本；对边界样本做人工 review；根据预算和质量目标调整阈值；保留兜底模型和快速回滚。请求路由是成本治理的控制平面，也是质量风险的放大器，不能只交给成本看板。
08. 批处理和排队要按场景分开
批量合并能提高 GPU 利用率。推理引擎通过 continuous batching 等机制把多个请求合到同一轮计算里，离线任务也可以通过队列集中处理，提高 tokens/s，摊薄 GPU 成本。问题是，批处理经常用等待时间换吞吐。对延迟敏感场景，过度批处理会把 TTFT 推高。
实时对话的优化目标是体感延迟。用户在聊天窗口等第一个 token，TTFT 过长会直接破坏体验。这里可以使用适度 batching，但要给队列等待设置硬边界，按请求优先级处理长短请求，避免长上下文请求拖垮短请求。实时服务的成本优化更多来自路由、量化、prefix caching 和合理热容量，而不是无限增大 batch。
代码补全比对话更敏感。很多补全场景要求极低 TTFT，用户正在输入代码，延迟超过几百毫秒就会感到打断。对这类场景，成本治理要优先使用小模型、缓存、模型裁剪和局部上下文，而不是排队等 batch。
离线摘要、批量 embedding、文档重建、离线评测则完全不同。它们可以排队，可以按小时批量处理，可以用 Spot，可以把吞吐最大化。这里要关注的是任务幂等、重试、输出校验、队列积压和完成时间 SLA。把离线任务混进在线推理热容量，是成本和稳定性双重浪费。
批处理的监控指标包括队列长度、等待时间、批大小分布、tokens/s、失败重试、任务完成时间、GPU 利用率、单位任务成本。对在线服务，还要把 batch 策略和 TTFT/TPOT 同时看。只看吞吐，容易把用户等待藏在平均值里。
09. Spot 适合可恢复任务，不适合盲目省在线推理
Spot 或抢占式实例的吸引力很直接：同样 GPU，价格可能显著低于按需实例。云厂商文档也明确这类容量可能被回收或中断。对 AI 成本治理来说，Spot 是有用工具，但它解决的是采购价格变量，不解决系统可恢复性。
训练任务适合 Spot，前提是 checkpoint 可靠。一次训练跑几十小时，中断不可避免时，只要 checkpoint 频率合理、存储可靠、恢复脚本经过验证，就能把损失控制在最近一个 checkpoint 之后的计算量。checkpoint 太稀，省下的钱会被重算吞掉；checkpoint 太频繁，会增加存储和 I/O 成本。这里也要算账。
离线批处理也适合 Spot。批量 embedding、离线评测、索引重建、报表生成，只要任务分片幂等、失败可重试、输出可校验，就可以利用低价容量。队列系统负责吸收中断，任务系统负责恢复进度。
在线推理不适合盲目放到 Spot。用户请求正在生成时，实例被回收会导致中断；新 Pod 冷启动慢；容量缺口会推高队列；如果所有副本都在抢占式节点上，节省的成本会变成可用性事故。可以把低优先级内部工具、异步任务或非核心流量放到 Spot，但核心实时服务应有按需容量兜底，并配合 PodDisruptionBudget、优先级、连接排空和快速回退。
Spot 的治理指标包括中断次数、恢复时间、checkpoint 损失步数、重试成本、任务完成 SLA、按需兜底比例。只比较实例单价是不完整的。应该比较的是“考虑中断和恢复后的单位有效产出成本”。
10. Budget 和异常告警要进入产品机制
成本治理如果只停留在月末报表，就太晚了。LLM 成本有很强的实时性和长尾性：少数长上下文用户、错误的循环调用、异常重试、被滥用的 API key、某次 prompt 改动导致输出变长，都可能在短时间内拉高成本。预算和异常告警应该进入产品机制。
预算要按功能设置，而不是只按团队设置。比如对话功能月度 token 预算、摘要功能每日 GPU 时间预算、免费用户每月 token 上限、单租户突发上限、外部模型 API 调用预算。功能预算能逼迫产品和工程一起讨论：这个功能的用户价值是否配得上推理成本，是否需要定价、限额、降级或异步化。
异常告警要有多种口径。单用户 input_tokens 或 output_tokens 突然异常，可能是滥用或循环调用；某 feature 的 $/request 上升，可能是 prompt 变长或路由失效；某 model 的单位 token 成本上升，可能是利用率下降或 batch 策略变化；外部 API 成本斜率异常，可能是 fallback 激增。
成本告警的动作要提前设计。对单用户异常，可以限流、要求确认、切换异步、暂停 API key；对功能预算燃烧过快，可以降低 max_tokens、调整路由、关闭高成本增强功能、提高缓存；对模型服务成本异常，可以扩容、缩容、调整 batch、回滚配置。没有动作的预算提醒，只会变成财务噪声。
成本和质量要绑定看。预算超了不能简单砍模型，预算没超也不代表健康。一个小模型路径成本很低，但用户追问率和差评率升高，说明成本被转移到了用户时间和人工支持。一个高价值客户成本高，但收入和留存也高，未必需要压低成本。成本治理的目标不是最低成本，而是单位价值下的可持续成本。
11. 一条可落地的成本治理路线
第一步，建立成本基线。按模型服务记录 GPU 小时、tokens/s、input/output tokens、TTFT、TPOT、利用率、空转时间。计算 /request、$/session。先不急着优化，连续观察一到两周，确认流量周期、峰谷、长尾请求和未归因成本比例。
第二步，补齐归因字段。所有请求带上 feature、tenant、user_type、model、route、prompt_version、input_tokens、output_tokens。节点池和部署带上 owner、cost_center、gpu_type、purchase_type。把未归因成本单独显示。字段不齐时，成本优化很容易误伤。
第三步，做低风险优化。清理空转副本，调整低峰容量；把离线任务迁出在线节点池；为批处理建立队列和 Spot 恢复机制；对高重复前缀场景开启 prefix caching 并监控命中率；限制明显异常的单用户长请求。这些动作通常质量风险较低。
第四步，做中高收益优化。评估量化、小模型路由和批量合并。每个优化都要同时设质量门禁和成本目标。量化看任务评测和 fallback；路由看小模型命中率、质量分和升级比例；批处理看等待时间和完成 SLA。不要只用“成本下降百分比”宣布成功。
第五步，把预算嵌入发布流程。新功能上线前估算 token 和 GPU 成本；prompt 改动比较输出长度和拒答率；模型升级比较质量、延迟和单位成本；RAG 索引更新观察召回质量和上下文长度；路由策略变更保留回滚。成本不再是月底复盘，而是发布门禁的一部分。
第六步，形成治理节奏。每周看成本归因和异常样本，每月看功能单位经济性，每次事故复盘都问“为什么监控没提前发现成本斜率变化”。基础设施团队在这里的价值不是单纯省钱，而是让业务知道每个 AI 能力的真实成本结构，从而做出清醒选择。
12. 延伸资料
我整理了一份《配套资料包》，这一篇对应「AIInfra成本」资料：AI成本归因表、推理容量与成本估算器和推理服务SLO模板。关注公众号后回复「AIInfra成本」领取。
13. 参考资料
• vLLM Production Metrics：推理服务 token、延迟和队列等运行指标，https://docs.vllm.ai/en/latest/usage/metrics.html • vLLM Automatic Prefix Caching：prefix caching 的工作方式和适用前提，https://docs.vllm.ai/en/latest/features/automatic_prefix_caching.html • OpenTelemetry GenAI Semantic Conventions：模型、请求和 token 元数据的语义约定，https://opentelemetry.io/docs/specs/semconv/gen-ai/ • FinOps Foundation Allocation Capability：云成本分配、标签和责任归属框架，https://www.finops.org/framework/capabilities/allocation/ • Hugging Face Transformers bitsandbytes Quantization：8-bit/4-bit 加载和量化工作流说明，https://huggingface.co/docs/transformers/main/en/quantization/bitsandbytes • AWS EC2 Spot Instances：Spot 实例折扣容量和中断风险说明，https://aws.amazon.com/ec2/spot/ • Google Cloud Spot VMs：Spot VM 可被抢占、适合容错工作负载的说明，https://cloud.google.com/compute/docs/instances/spot • Azure Spot Virtual Machines：Azure Spot VM 的容量和驱逐机制说明，https://learn.microsoft.com/en-us/azure/virtual-machines/spot-vms • Modal Pricing：GPU 按型号和时间计费的价格页，用于说明 GPU-hour 是成本变量，https://modal.com/pricing
