做推理成本对比这件事，我踩过的坑比吃过的盐还多。刚开始我以为把几个大模型的API价格拉个表格就算“对比”了，结果被财务和工程团队同时追问：显存成本算进去了吗？长上下文的溢价怎么处理？汇率波动算不算？那一刻我才意识到，所谓“每百万token成本”根本不是一张价目表能说清的事。它背后横跨硬件采购、集群调度、供应商定价策略、甚至合同里的SLA条款。所以咱们别急着比价格，先把“成本”这个词的边界划清楚，否则后面所有对比都是空中楼阁。
这一章我想干的事很朴素——把大参数模型推理成本对比这件事的“口径”定下来。哪些算成本，哪些只是你感觉的成本；按什么单位比才有可比性；闭源API、开源云托管、自建集群这三类对象各自藏着什么隐性账本；还有上下文长度、并发量、SLA这些变量怎么把成本数字搅得天翻地覆。不把这些问题聊透，你去跟老板汇报“我们每个月推理花了20万”的时候，心里是没有底的。
1.1 大参数模型推理成本的定义与构成：算力、显存带宽、存储、网络、运维与合规成本
我经常跟团队里新来的同学讲，推理成本这个东西，你得先搞明白钱到底花在哪儿。很多人脑子里的模型是“GPU小时×电价”，这个理解太窄了。大参数模型推理真正的成本大头，分布在算力、显存带宽、存储、网络、运维和合规这六个池子里。算力成本好理解，就是GPU/NPU跑矩阵乘法和注意力计算消耗的机时。但显存带宽成本经常被忽略——大模型推理是典型的显存带宽密集型任务，你把权重和KV Cache在HBM里搬来搬去的次数，直接决定了单token的延迟和每瓦算力能换回多少吞吐。带宽上不去，GPU再贵也跑不满，单位token成本自然高得吓人。
存储和网络这两块，我在自建集群的时候感受最深。模型权重动辄几十上百GB，多副本部署要给每个推理节点配本地高速存储，冷启动加载模型的时间直接变成成本。网络这边更隐蔽，多卡多机推理时all-reduce和集合通信吃掉的时间，换算成钱就是白花花的GPU小时。还有运维成本——监控、扩缩容、故障恢复、版本迭代、安全补丁，这些人力开销在自建方案里占比不小，很多对比文章压根不提。合规成本也越来越重，数据驻留要求、审计日志、内容安全过滤，每一项都要单独的算力和存储资源。
我把这些摊开说，是想让大家建立一个“全成本”视角。你去对比API和自建的时候，如果只看API每百万token多少钱、自建每小时GPU多少美元，最后算出来的拐点一定是偏的。完整口径应该把同样一个token在不同部署方式下触发的全部资源消耗都折算进去，哪怕运维这些“软成本”只能粗略估算。粗略但完整，好过精确但残缺。
1.2 按每百万token对比的意义：单位成本口径、输入输出差异与适用边界
为什么是“每百万token”？这个问题我问过自己很多遍。答案其实不复杂：token是大模型推理最贴近业务的最小计量单位，按这个口径对比，不同模型、不同供应商之间才有了可换算的基准。你按请求数对比，长上下文请求和短对话请求完全不是一个量级；你按小时对比，业务量波动大的场景会被平均值严重误导。每百万token相当于给推理成本找了一个“每公里油耗”式的指标，便于横向拉平。
但口径统一之后，还有一层坑叫输入输出差异。主流API的定价都是输入token便宜、输出token贵，有时差好几倍。输入是预填充阶段，能在一次前向里并行处理，效率高；输出是解码阶段，一个token一个token往外蹦，显存带宽几乎全程吃满。所以你在做对比的时候，必须把输入输出分开计成本，再用业务实际的输入输出比例加权。拿一个输入输出七三分的场景去套五五分的价格表，算出来的数字能差出两三成。我见过太多对比文章直接拿输出价格当统一单价，这就是在误导决策。
适用边界也得说清楚。“每百万token成本”这个口径适合模型调用层面的对比，不适合用来回答“我这套业务该不该自建”。因为自建的成本曲线是非线性的——吞吐利用率低的时候，每百万token的摊薄成本高得离谱；利用率拉满之后又可能反超API。这个口径适合做单位经济性的敏感性分析，不适合做拍板决策的唯一依据。用对了是标尺，用错了是锤子。
1.3 对比对象与范围：主流闭源API、开源模型云托管、自建推理集群
我们日常说的“大模型推理成本对比”，落到对象上其实就是三大类。第一类是主流闭源API，OpenAI、Anthropic、Google，以及国内的几家大厂。它的特点是价格透明、按token计费、无需自己运维，但单价里含着供应商的算力溢价和服务利润，长上下文和高级功能还有额外加价。第二类是开源模型云托管，比如把Llama、Qwen、DeepSeek部署在AWS SageMaker、火山引擎、阿里云百炼这类平台上，按实例时或者按token付费。它比自建省心，比纯API灵活，但你要自己调推理框架、自己扛扩缩容策略，成本里揉进了工程能力这个变量。
第三类是自建推理集群，买卡、租卡、建集群，自己跑vLLM、TensorRT-LLM这些推理引擎。这一类成本最不透明，但也最有优化空间。硬件型号、批处理策略、量化方案、集群利用率，每一个都能让每百万token成本翻倍或者腰斩。我自己的经验是，自建在业务量稳定且规模足够大时才有成本优势，量小的时候运维和闲置成本会把账面优势吃干净。
把这三类放在同一个坐标系里对比，要注意它们提供的“东西”并不完全等价。闭源API卖的是模型能力加服务保障，开源托管卖的是灵活性加可控性，自建卖的是自主权加长期成本曲线。所以我在做对比矩阵的时候，会同时列单价维度和能力维度，避免拿一个便宜的弱模型去跟贵但强的模型单纯比价格。范围划清楚了，后面的数字才有讨论价值。
1.4 成本对比的约束条件：上下文长度、输出长度、并发量、SLA、区域定价与汇率税费
这一节我想重点聊聊那些“让对比失真”的约束条件，因为它们才是真实世界里成本差异的主要来源。先说上下文长度，长上下文对成本的拉动不是线性的。注意力计算量随上下文长度增长，KV Cache的显存占用也线性上涨，很多供应商对超过一定长度的请求直接加价，自建场景下长上下文会把批处理空间挤掉，吞吐直接掉一个台阶。你拿8K上下文的均价去估128K场景的成本，误差能到好几倍。
输出长度和并发量是一对孪生变量。输出token越贵这件事前面说过了，并发量这边更微妙——高并发能摊薄固定成本，但也会推高显存压力和排队延迟，迫使你预留更多冗余容量。SLA是另一个隐形加价项，99.9%可用性和99%可用性背后是完全不同的冗余架构和成本结构。区域定价和汇率税费这层，做跨境业务的同学应该有体会，同一个模型在不同区域的API价格能差出百分之二三十，算上汇率波动和增值税，年度成本预算能漂移一大截。
我自己的做法是，做任何成本对比之前先列一张约束条件清单：上下文分布、输出长度分布、峰值并发、SLA等级、部署区域、结算币种。然后针对核心场景做加权，而不是拿标价直接比。这些约束条件不是给对比添麻烦的，它们恰恰是对比有价值的原因——脱离约束谈成本，就跟脱离路况谈油耗一样，数字再精确也没法用。
聊到这里，第1章的任务差不多完成了：把成本的定义、单位口径、对比对象和约束条件这四件事立起来。后面几章我们会拿着这套口径，去拆API计费结构、算单次请求成本、分析差异驱动因素，再落到优化方案和选型建议上。口径一旦统一，后面所有的数字才能互相说话，而不是各说各话。
说实话，我一开始以为“比价”这件事是最简单的——打开各家官网定价页，把输入输出价格拖进Excel，拉个平均值，完事。后来被现实狠狠上了一课。同一个模型，我在两个不同场景下跑出来的真实每百万token成本能差出三倍多。原因很简单：我一开始比的是“标价”，而业务花的是“有效成本”。这俩之间的鸿沟，藏着缓存命中率、批处理折扣、长上下文溢价、重试浪费，还有那些定价页上用小字标注的“超出部分另行计费”。
这一章我想把API成本对比这件事从“看价目表”拉到“算真实账”的层面。咱们先把计费结构一层层剥开，看看供应商到底在哪些维度上向你收钱；再聊聊怎么把五花八门的标价换算成可比的统一口径；然后设计一套对比矩阵，把模型档位、上下文窗口、模态能力这些变量框进去；接着落到具体业务负载上——短对话、长文档、RAG、Agent多轮，每一种场景下的成本排序会怎么变；最后说说对比结果怎么呈现才有决策价值，而不是一堆漂亮但没用的数字。
2.1 API计费结构拆解：输入token、输出token、缓存命中、批处理与长上下文溢价
我习惯把API账单当成一个多层蛋糕来拆。最底下那层是输入token计价，这是最基础也最容易被低估的部分。主流供应商的输入价格通常只有输出的五分之一到三分之一，但输入token量大啊——系统提示词、few-shot示例、RAG检索回来的文档块、历史对话，全都算输入。我一个做客服系统的朋友，单次请求平均输入2400 token、输出180 token，比例超过13:1，他一开始只盯着输出价格看，结果成本大头全在输入那边。
输出token是第二层，也是最贵的一层。解码阶段逐token生成，显存带宽几乎全程满载，供应商在这上面加价加得理直气壮。我观察各家的定价策略，输出通常是输入的3到5倍，有些旗舰模型能到6倍以上。做成本估算的时候，输出token的单价必须单独拎出来乘以实际输出长度，千万别用均值糊弄过去。
第三层是缓存命中，这是近两年才普及的计价维度。Anthropic的prompt caching、OpenAI的自动缓存折扣、DeepSeek的上下文硬盘缓存，各家叫法不同但逻辑类似——如果你上一次请求的提示词前缀跟这次一样，供应商可以直接复用KV Cache，省掉预填充的算力，于是给你打个折。缓存命中的输入价格通常是正常输入价的十分之一到四分之一。这个机制对RAG和Agent场景影响巨大，系统提示词固定、多轮对话历史逐轮追加，缓存命中率能做到百分之七八十。我见过有人完全没注意这个维度，按无缓存价格做预算，结果实际账单只有预算的六成，反过来也有人缓存失效了却没发现，成本悄悄翻倍。
批处理接口是第四层。OpenAI的Batch API给五折，Anthropic的Message Batches也是五折，代价是延迟放宽到24小时以内。这个折扣对离线任务太香了——文档分类、数据清洗、批量摘要，这些场景根本不需要实时响应，走批处理直接腰斩成本。但很多团队做预算时压根没把批量任务单独拆出来算，全按实时价格估，预算自然虚高。
长上下文溢价是最顶上那层，也是最容易被忽略的隐性加价。不少供应商对超过128K或200K上下文的请求直接翻倍计价，有的按阶梯加价，有的干脆限制并发。我拿一份200页的PDF做测试，128K上下文以内的部分按标准价走，超出的部分单价直接跳档，单次请求成本是普通对话的十几倍。你做长文档分析场景的成本模型，如果拿标准上下文价格去套，算出来的数字能差出一个数量级。
2.2 每百万token成本换算方法：标价换算、折扣规则、隐藏成本与统一口径
把各家定价换算成“每百万token成本”，听起来像小学算术，做起来全是坑。第一步是标价换算，你得先搞清楚各家的计价单位。OpenAI按每百万token标美元价，Anthropic也是，Google Gemini按每百万字符或每百万token两种口径都出现过，国内几家大厂有的按千token标价，有的按百万token标价，还有的把输入输出打包成一个“资源包”卖。我吃过一次亏，拿千token单价直接当百万token单价填进表格，差了三个数量级，被同事笑了半个月。
折扣规则是第二步，也是最容易算错的地方。批处理五折、缓存命中折扣、预留容量折扣、初创企业优惠、阶梯用量折扣，这些规则叠加起来能让你算出来的有效单价跟标价差出一半以上。我的做法是建一个折扣因子表，每个模型每一档用量配一个系数，算有效成本的时候直接乘上去。批处理因子0.5、缓存命中因子0.1到0.25（按命中率加权）、长上下文溢价因子1.5到2.0，这些数字不用很精确，但必须显式地放进模型里，不能让标价“裸奔”进预算表。
隐藏成本这一块我单独拎出来说，因为它最容易被忽略、又最伤预算。重试失败的成本算不算？流式输出中途断连重新生成的那部分token，供应商照收不误。速率限制导致的排队和降级，逼着你多买配额或者做多供应商冗余，这层成本在定价页上根本看不到。还有区域定价差异，同一个模型在美东、欧洲、亚太的单价能差百分之二三十，跨境业务还要叠汇率波动和增值税。我现在的习惯是，做API成本对比时先列一张“隐藏成本清单”，把重试率、降级率、汇率缓冲、税费都写成百分比加成，统一乘到标价换算结果上。粗糙但诚实，比精确但漏项强得多。
统一口径的最终形态应该是一个加权有效成本公式：有效每百万token成本 = Σ(各token类型用量 × 该类型有效单价 × 折扣因子) / 总token量 × (1 + 隐藏成本加成率)。这个公式不完美，但它把输入输出差异、缓存、批处理、长上下文溢价、隐藏成本全都显式化了。你用这个口径去比，比出来的差异才是业务真正会感受到的差异。
2.3 主流大模型API成本对比矩阵设计：模型档位、上下文窗口、模态能力与服务等级
单纯拉一条价格排名毫无意义，因为旗舰模型和轻量模型本来就不是一个物种。我的做法是设计一个多维对比矩阵，行是模型档位，列是成本相关的关键属性。档位我一般分四层：超旗舰（GPT-4o、Claude 3.5 Sonnet、Gemini 1.5 Pro这个级别）、主力旗舰（GPT-4o mini、Claude 3 Haiku、国内几家的大参数主力）、轻量模型（7B到30B级别）、专用模型（embedding、rerank、代码专用）。每一档内部的比价才有意义，跨档比价只能用来找“降档替代”的空间。
上下文窗口这一列我放的是“标准价覆盖的上下文长度”和“超出后的溢价系数”。有的模型标称128K但32K以上就加价，有的标称200K全程一口价，有的把长上下文做成独立的高价SKU。我拿同一个长文档任务去跑不同供应商，成本能差四五倍，原因全在这一列上。模态能力这一列影响的是“能不能用”而不是“贵不贵”，但很多时候为了省成本去用纯文本模型处理带图任务，最后靠OCR和额外的工程管线补回来，综合成本反而更高。
服务等级这列容易被忽略，但它对成本的影响是结构性的。标准SLA和宽松SLA的单价可能一样，但前者逼着你做冗余部署和容量预留，后者允许你在高峰期降级排队。我见过一个团队为了省API单价选了便宜但SLA宽松的供应商，结果高峰期延迟飙到十几秒，业务侧被迫加了一层本地缓存和请求重试，工程成本远超省下来的那点token钱。矩阵里把SLA等级和对应的冗余成本系数标出来，决策时才有全局视角。
这个矩阵我一般用表格呈现，行是模型，列是：输入单价、输出单价、缓存命中折扣、批处理折扣、标准上下文长度、长上下文溢价、SLA等级、区域可用性。每一列都填有效值而不是标价，看起来密密麻麻，但比一张只有价格的排名表有用十倍。
2.4 不同业务负载下的成本排序变化：短对话、长文档、RAG、Agent多轮与批量任务
这一节是我觉得整章最有意思的部分，因为同一个模型在不同负载下的成本排名会剧烈翻转。短对话场景——比如客服机器人、语音助手——输入输出比例接近，单次请求token量小，缓存命中率取决于系统提示词是否固定。这个场景下轻量模型往往碾压旗舰模型，因为任务简单、对模型能力要求低，成本差异主要体现在单价上。但如果你为了省成本把旗舰换成轻量，结果回答质量下降导致人工兜底率上升，综合成本反而更高。这种隐性成本在纯API账单里看不到，得把人工成本折算进去才能看清。
长文档分析是另一个极端。输入动辄几十万token，输出可能只有几百token的摘要或结构化结果。输入输出比例能到100:1甚至更高。这个场景下输入单价和长上下文溢价是决定性因素，输出价格几乎可以忽略。缓存命中在这里也很微妙——同一份文档如果被多次追问，前缀缓存能把重复输入的成本打下来；但如果每次都是新文档，缓存基本失效。我做过一个合同审查的成本测算，同一套模型组合，开缓存和不开缓存的每百万token成本差了将近一半。
RAG场景的成本结构更复杂。检索回来的文档块拼进prompt，输入token量取决于检索策略和上下文裁剪策略。top-5检索和top-20检索的成本能差三倍。缓存在这里的命中率取决于系统提示词和检索模板是否固定，如果检索结果排序稳定、模板固定，前缀缓存命中率能到六七成。Agent多轮场景则是另一个故事——每一轮都要带上历史对话，输入token量随轮次线性增长，输出token虽然不多但每轮都有。多轮场景下缓存命中率是关键变量，历史对话如果被缓存复用，成本曲线会平缓很多；如果每轮都重新计算，第10轮的成本可能是第1轮的五倍以上。
批量任务场景最直接，走批处理接口拿五折，成本排序基本跟实时场景一致，但绝对值全部腰斩。我一般建议团队把离线可延迟的任务全部拆出来走批处理，别跟实时流量混在一个预算池里，不然你永远看不清实时推理的真实单位成本。
2.5 API成本对比的呈现方式：单价对比、有效成本对比与场景化成本对比
对比结果怎么呈现，决定了它能不能推动决策。我见过太多对比报告只放一张单价排名表，老板看完只说一句“那就选最便宜的”，然后工程团队在后面擦屁股。单价对比有它的价值——快速筛掉明显贵得离谱的选项——但它只适合做初筛，不适合做终选。
有效成本对比是第二层，把输入输出分开、把缓存和批处理折扣算进去、把长上下文溢价和重试率加成算进去，得到一个加权后的每百万token成本区间。我一般会画一个区间图而不是单点值，因为有效成本本身有不确定性——缓存命中率会波动、流量结构会变化、汇率会漂移。给老板看单点数字是不负责任的，给区间才是诚实的。
场景化成本对比是第三层，也是最接近决策的语言。与其说“模型A每百万token 8美元、模型B 12美元”，不如说“在你们的客服场景下，模型A月成本4.2万、模型B月成本5.8万，模型B的首次解决率高8个百分点，折算人工节省后综合成本反而低1.1万”。这种呈现方式把API成本跟业务指标挂上钩，决策者才能判断贵出来的部分值不值。我现在的习惯是每个对比报告至少给三个场景的测算：实时对话、离线批量、高价值长文档。三个场景的成本排序往往不一样，决策者看到这种分化，才会认真去问“我们的负载到底偏哪一类”。
呈现工具上，我偏好两张表加一张图：第一张表列标准单价和折扣规则（给采购看），第二张表列三个场景下的加权有效成本和月成本估算（给业务和财务看），一张图画有效成本随请求量变化的曲线（给架构决策用，顺便标出API和自建的交叉点）。别小看这个交叉点图，它能把“什么时候该换方案”这个战略问题变成一条可视化的曲线，比任何文字论证都有说服力。
说到这里，第2章的核心就立起来了：API计费不是一个数字而是一套结构，换算不是算术而是加权，对比不是排名而是分场景的矩阵。有了这套框架，下一章我们才能往下钻，去算单次请求里预填充和解码各花了多少钱、KV Cache到底吃掉了多少显存带宽、自建集群的TCO怎么跟API成本做真正可比的对照。口径和对比方法定下来之后，后面的数字才靠得住。
上一章我们把API价目表拆成了有效成本，用的是外部视角——供应商收了你多少钱。这一章得换个视角，从内部看：一次推理请求跑在GPU上，钱到底烧在了哪个环节。说实话，这个视角的转变是我做成本优化以来最有收获的一次。以前我盯着账单发愁，不知道该从哪儿省；后来学会了拆解单次请求的算力消耗，才发现省钱的抓手其实藏在预填充和解码的配比里、藏在KV Cache的显存占用里、藏在批处理填充率里。
这一章我想把“每百万token成本”从一个报价数字还原成一道工程计算题。先从单次请求拆起，看看预填充和解码各花了什么资源；然后推导每百万token的计算公式，把参数量、吞吐、硬件利用率、电价这些变量串起来；再聊TTFT、TPOT、QPS这些性能指标跟成本之间的拉扯关系；接着把视角拉到总拥有成本TCO，算清楚API、自建、云托管、混合部署各自的账；最后讲成本归因和监控怎么落地，让每一笔推理开销都有处可查。
3.1 单次请求成本拆解：预填充阶段、解码阶段与KV Cache开销
我把一次推理请求掰成两段来看，这个习惯帮我省了很多钱。第一段叫预填充，模型把你的输入prompt一次性编码成KV Cache，这个阶段是矩阵乘法密集型——GPU的Tensor Core吃得很饱，算力利用率高，但显存带宽不是瓶颈。第二段叫解码，模型逐token生成输出，每生成一个token都要把全部KV Cache读一遍，这个阶段是显存带宽密集型——算力单元大量闲置，带宽被榨干。这两段的资源画像完全不同，成本结构也完全不同。
预填充的成本大头在算力。计算量大致正比于输入token数乘以参数量的平方再乘以2（前向传播的FLOPs估算），对一个大参数模型来说，一段8K token的输入预填充就要消耗可观的GPU时间。但预填充有个好处：它天然可并行，所有输入token的注意力计算可以同时做，批处理效率高。我实测过一个70B模型在A100 80G上跑预填充，吞吐能到每秒上万token，也就是说处理一段8K输入只要不到一秒的GPU时间。
解码的成本大头在显存带宽。每生成一个token，GPU要把模型权重和整个KV Cache从显存读到计算单元，这个数据搬运量跟参数量成正比。70B模型以FP16精度存储，权重就有140GB，单张A100 80G放不下，得用多卡或者量化。每解码一个token，光读权重就要搬140GB的数据，A100的显存带宽是2TB/s，理论上一秒最多读十几遍权重，也就是十几token每秒——这是单请求的解码上限，实际因为KV Cache和注意力计算还要再打折。这就是为什么解码阶段贵：它的吞吐天花板被硬件带宽锁死了，不像预填充能靠并行拉高吞吐。
KV Cache的显存开销是第三块成本，也是多轮对话和长上下文场景的隐形杀手。KV Cache大小跟层数、注意力头数、头维度、序列长度、批大小、精度都相关。我常用一个粗略公式：每token的KV Cache字节数约等于2（K和V）×层数×隐藏维度×精度字节数。一个70B模型（80层、隐藏维度8192、FP16）每token的KV Cache大约2×80×8192×2≈2.6MB。听起来不大，但32K上下文就是85GB——比模型权重还大。这意味着长上下文请求会挤占显存，逼着你减小批大小或者加卡，单位token成本自然就上去了。
3.2 每百万token推理成本计算公式：参数量、吞吐、硬件利用率与单位电价
我推导过一个自用的每百万token成本公式，不追求学术精确，但求把关键变量都装进去。公式长这样：每百万token成本 =（硬件小时成本 / 每小时token吞吐）× 1,000,000 + 存储和网络摊销。硬件小时成本包括GPU折旧或租赁费、电费、机房分摊、运维人力。每小时token吞吐等于理论峰值吞吐乘以实际利用率。这个公式粗糙，但它把成本驱动因子全暴露出来了。
理论峰值吞吐怎么估？预填充和解码得分开算，因为瓶颈不同。预填充的峰值吞吐受算力约束：峰值FLOPs除以单token预填充FLOPs。解码的峰值吞吐受显存带宽约束：显存带宽除以单token解码的数据搬运量。实际吞吐再乘以一个利用率系数，这个系数跟批处理填充率、请求长度分布、调度策略强相关。我见过有的集群利用率只有三成，有的能做到七成以上，同样的硬件，单位token成本能差一倍多。
单位电价这一项容易被忽略，但对大规模自建集群来说不是小数。一张A100满载功耗约400W，加上CPU、内存、网络、制冷，整机柜功率可能到10kW以上。按工业电价0.6元每度算，一台8卡A100服务器一年电费就是五万多。这个数跟GPU折旧比不算大，但如果你算的是边际成本——多跑一个请求多耗的那点电——在高利用率场景下它就变得显著了。我给客户做自建测算时，电费一般按硬件成本的15%到25%做年度摊销，制冷效率差的机房要往上取。
公式里还有个隐藏变量：硬件利用率的时间维度。GPU不是24小时满负荷的，业务有高峰低谷。低谷期GPU闲置，但折旧和电费照付，这部分成本要摊到高峰期的token上。我一般用一个“有效利用率”来修正——把全年token总量除以“GPU满载等效小时数”乘以峰值吞吐，得出的有效利用率往往只有四到六成。这个系数直接决定了自建的单位成本能不能打得过API。很多团队自建测算做出来很漂亮，一上生产就发现成本翻倍，问题全出在没算这个时间维度的利用率。
3.3 关键性能指标与成本关系：TTFT、TPOT、QPS、并发利用率与吞吐延迟权衡
TTFT（首token延迟）和TPOT（每输出token延迟）这两个指标，表面看是体验指标，骨子里是成本指标。TTFT主要取决于预填充耗时和排队时间。你把批大小调大，吞吐上去了单位成本下来了，但排队变长TTFT就飙了。我调过一个在线客服系统，批大小从8加到32，每百万token成本降了四成，TTFT从300毫秒涨到1.2秒，用户投诉率跟着上来了。最后折中在16，成本降两成半，TTFT控制在600毫秒以内。
TPOT则跟解码阶段的批大小强相关。解码是带宽密集的，批大小越大，每读一遍权重能服务越多请求，带宽利用越充分，单位成本越低。但批大小受显存限制——KV Cache随批大小线性增长。长上下文场景尤其吃紧，32K上下文的请求批大小可能只能到4到8，解码带宽利用率上不去，单位成本自然高。这就是长上下文溢价的工程根源：不是供应商想多收你钱，是硬件资源真的被占住了。
QPS和并发利用率是另一对拉扯关系。系统按峰值QPS设计容量，但峰值只出现在一天里的少数时段。我把这个叫“容量成本陷阱”：为了扛住峰值，你买了十台机器的算力，平时只用了三台，七台的折旧和电费白白摊在token成本里。API供应商能靠规模效应和多租户混布把这个问题消化掉，自建团队很难。我见过最极端的案例，一个团队按双十一峰值建集群，全年平均利用率不到两成，算下来每百万token成本是API价格的三倍多。
吞吐和延迟的权衡没有标准答案，得看业务场景。离线批处理场景延迟不敏感，批大小拉满、吞吐优先，单位成本能压到最低。实时对话场景延迟敏感，批大小受限，单位成本就得往上走。我的经验值是：实时场景按P95 TTFT小于800毫秒、TPOT小于50毫秒做约束反推最大批大小，然后在这个批大小下算有效吞吐和单位成本。别先算成本再倒推延迟，那样很容易做出账面上漂亮、体验上灾难的方案。
3.4 总拥有成本TCO计算：API费用、自建GPU集群、云托管与混合部署
TCO这件事，我吃过只看单价的亏。API的TCO相对简单——token费用加上集成开发、监控告警、多供应商冗余的工程成本。自建集群的TCO就复杂多了，我一般分五块算：GPU服务器采购或租赁（三年折旧）、机房和电力、网络带宽、存储、运维人力。这五块里最容易被低估的是运维人力——一个像样的推理集群至少要半个到一个专职SRE，加上模型部署、版本升级、故障排查，人力成本一年几十万跑不掉。
云托管GPU介于两者之间。它省掉了机房和硬件采购，但单价高，而且长期跑下来总价可能超过自建。我做过一个对比：同样跑一个70B模型、日均十亿token的量，自建三年TCO折合每百万token大约X元（含折旧、电、运维），云托管按需实例大约2.5X，云托管预留实例大约1.4X，API调用按有效成本算大约1.1X到1.8X（看模型档位和折扣）。这个结果说明一件事：中等规模以下，API往往更划算；大规模且负载稳定，自建或预留实例才有优势。
混合部署是很多团队的现实选择。核心高频请求走自建或预留实例保底，峰值溢出和长尾模型走API。这种模式的关键是设计好路由策略和成本归因——哪些请求走哪条路、每条路的单位成本多少、溢出比例控制在多少以内。我一般建议把溢出比例控制在总请求量的15%以内，超过这个数说明预留容量估少了，或者负载结构变了。混合部署的TCO要把路由层和归因系统的开发维护成本也算进去，这部分经常被漏掉。
算TCO的时候还有个坑：自建集群的残值和技术贬值。GPU三年后残值可能只剩三成，而且新一代芯片出来后旧卡的单位算力成本会被迅速拉开。我一般按三年直线折旧、残值率20%到30%来算，同时假设每年有10%到15%的算力性价比提升被新一代硬件吃掉。这个假设保守，但能防止你把自建账算得太乐观。
3.5 成本归因与监控：按模型、租户、场景、token类型和请求状态核算
成本归因这件事，做不做差别巨大。不做归因，你只知道这个月花了多少钱，不知道钱花在谁身上、花在哪个环节、该从哪儿省。我接手过一个成本失控的项目，账单三个月翻了一倍，团队完全说不清涨在哪儿。上了归因系统之后一周就定位到了——某个Agent场景的重试率从5%涨到了30%，失败重试的token全按正常价计费，白白烧掉了四成预算。
我设计的归因维度一般有五层。第一层按模型分，不同模型单价不同，混在一起看总数没有意义。第二层按租户或业务线分，内部结算和预算管控都需要这个粒度。第三层按场景分，客服、RAG、代码生成、Agent，每个场景的token结构完全不同。第四层按token类型分，输入、输出、缓存命中、缓存未命中，这层的归因精度直接决定优化方向。第五层按请求状态分，成功、失败重试、超时中断、降级响应，失败请求的成本经常被忽略，但它可能占总成本的10%到30%。
监控指标我盯三个：单位token成本趋势、缓存命中率、重试率。单位token成本趋势是最顶层的健康指标，它涨了说明要么负载结构变了、要么效率降了、要么供应商调价了。缓存命中率是RAG和Agent场景的命门，掉十个点成本可能涨两三成。重试率是隐形杀手，它不动声色地翻倍你的账单。我给这三个指标都设了告警阈值，单位token成本周环比涨15%、缓存命中率跌破50%、重试率超过8%，任何一个触发都得当天排查。
归因系统落地的时候有个现实问题：API供应商的账单粒度往往不够细。有的只给日汇总，有的不区分缓存命中和未命中，有的重试请求跟正常请求混在一起。我的做法是在应用层埋点，自己记录每次请求的模型、场景、token数、缓存状态、请求结果，然后跟供应商账单做对账。对不上的部分就是“不可归因成本”，一般控制在总成本的5%以内算健康，超过这个数说明埋点有遗漏或者计费口径有偏差。
写到这里，这一章把推理成本从“报价”还原成了“工程计算”。预填充烧算力、解码烧带宽、KV Cache吃显存，三个环节的资源画像不同，优化抓手也不同。每百万token成本公式把参数量、吞吐、利用率、电价串起来，算出来的数才经得起推敲。TTFT、TPOT、QPS这些指标不是体验的装饰品，它们直接约束着批大小和单位成本。TCO把API、自建、云托管、混合四种形态拉到同一个时间尺度上比较，避免被月账单的短期数字误导。归因和监控让成本变得可观测、可追责、可优化。
下一章我们往外走一步，去看大参数模型推理成本差异到底由什么驱动——模型架构、硬件型号、推理策略、上下文模式、供应商定价，这些因素怎么把成本拉开几倍甚至十几倍的差距。这一章算清楚了自己的账，下一章才看得懂别人的价。
上一章把成本拆成了一道工程计算题，算的是“自己跑一次请求要花多少钱”。这一章换个问法：同样是大参数模型，为什么A供应商报一个价，B供应商报另一个价，价差能到三五倍？为什么同一个模型，短对话场景和长文档场景的有效成本能差出一倍？我刚开始做对比的时候，以为价差主要是供应商想赚多少的问题。后来把模型架构、硬件、推理策略、请求形态、定价规则这几层剥开，才发现价差的根子大多埋在工程细节里，商业定价只是最外面那层皮。
这一章我按五个驱动因素来拆：模型本身长什么样、跑在什么硬件上、推理服务怎么调度、请求长什么样、供应商怎么定价。每一层都能把成本拉开差距，叠加起来就是市面上看到的几倍价差。理解这些驱动因素，比记住某家今天的单价更有用。单价会变，驱动因素不会。
4.1 模型规模与架构差异：参数量、MoE结构、注意力机制与量化精度
先看模型规模。参数量对成本的影响最直观，也最容易被简化成一句“越大越贵”。这里头有个细节值得掰开：参数量主要影响解码阶段的权重读取量。解码每生成一个token，GPU得把权重从显存搬到计算单元，搬运量跟参数量成正比。70B模型FP16权重140GB，7B模型14GB，同样是A100 80G，前者得四卡张量并行才放得下，后者单卡就行。四卡并行的通信开销、显存冗余、批处理效率损失加在一起，单位token成本不是简单的十倍，可能到十二三倍。我测过一个7B和70B的对比，短输出场景下70B的单位成本是7B的十一倍左右，长上下文场景拉到十五倍。MoE结构是这两年绕不开的变量，它的巧妙之处在于总参数和激活参数分开了。一个总参数几百B的MoE，每个token只激活其中一小撮专家，解码时读的权重少了，吞吐能上去。我实测过某开源MoE模型，激活参数只有总参数的十分之一左右，解码成本比同等总参数的稠密模型低三四成。MoE的账没那么好算：显存里得装下全部专家，显存占用没降；路由网络和负载均衡有额外开销；批处理时不同请求激活的专家不一样，专家并行通信会成为瓶颈。小批量、长上下文场景下，MoE的成本优势会被吃掉不少。
注意力机制的演进对成本的影响被低估了。MHA、MQA、GQA、MLA这几种变体，核心差异在KV Cache的大小。MHA每个注意力头都有独立的K和V，KV Cache最大；GQA把KV头分组共享，缓存能降几倍；MLA用低秩压缩，缓存更小。KV Cache小了，长上下文请求占的显存少，批大小能开大，单位成本跟着降。我做长文档场景选型时，会专门看模型用的哪种注意力机制，这个参数比标称参数量更能预测长上下文成本。
量化精度是第四个变量，也常被当成免费的午餐。FP16降到FP8或INT8，权重读取量减半，解码吞吐理论上翻倍，单位成本降三四成。INT4更激进，精度损失得认真评估。量化不是免费的：校准需要数据，低比特量化在某些任务上掉点明显，业务质量兜不住的话省下的钱不够赔。我的做法是先在小流量上做A/B，质量指标掉不超过两个点才全量。做API对比时，我会看供应商有没有公开模型的量化方式，一个标称70B的API，底层可能是FP8也可能是INT4，实际成本结构和输出质量都不一样。
4.2 硬件与部署形态差异：GPU型号、显存带宽、互联能力与集群利用率
硬件这一层，我习惯先看显存带宽再看算力。解码阶段是带宽密集的，显存带宽几乎线性决定了解码吞吐上限。A100的带宽是2TB/s，H100拉到3.35TB/s，理论解码吞吐高六成多。H100单价也高，按每元带宽算，不同采购渠道和租赁方式差别挺大。云上按需实例的H100每小时价格可能是A100的一点五到两倍，折算到每百万token，谁更划算得看实际利用率和批处理填充率，不能只看卡的名义性能。国产卡和推理专用芯片也在进场，单价低、带宽规格各异，适合的场景还得靠实测，别被峰值算力的标称值带偏。
显存容量决定部署形态。70B模型FP16要140GB，单张80G卡放不下，得两卡或四卡张量并行。多卡并行引入卡间通信，解码阶段每生成一个token都要做一次全reduce，通信延迟直接压在TPOT上。NVLink和PCIe的差距在这个环节会被放大，PCIe机器跑张量并行的解码吞吐可能只有NVLink机器的六七成。这也是为什么同样标称算力的机器，实际单位token成本能差出一截。互联能力还影响多机推理的可行性：单机八卡能放下的模型，跨机就要走InfiniBand或高速以太网，跨机张量并行的通信开销比机内高一个数量级。多数团队会把模型控制在单机可容纳的范围内，宁可量化也不跨机，这个约束反过来影响模型选型。
集群利用率是硬件层最容易被忽略的驱动因素。同样一批A100，一个团队做到七成有效利用率，另一个团队只有三成，单位token成本差一倍多。利用率的差距来自负载结构、调度策略、机型混杂程度。自建集群常见的问题是机型不统一，新卡旧卡混布，调度器为了兼容性牺牲填充率。云上按需实例的问题是启停开销和冷启动，频繁伸缩的集群有效利用率上不去。我见过一个团队为了省钱用竞价实例，中断率太高，重试和迁移的成本把省下的钱全吃回去了。后来他们改成基线用预留实例、峰值用按需，利用率回到五成以上，单位成本才稳下来。
4.3 推理服务策略差异：动态批处理、连续批处理、前缀缓存与投机解码
推理服务策略这一层，是我认为性价比最高的优化空间。动态批处理是最基础的手段：把多个请求攒成一个批次一起算，提高GPU利用率。攒批有代价，排在后面的请求得等，TTFT变长。批处理填充率是关键指标，padding的token也在消耗算力，填充率低的批次等于白烧钱。我调过的一个系统，批大小从8加到32，填充率从六成掉到四成，单位成本只降了一成半，没达到预期。后来改成按长度分桶再攒批，填充率回到七成，成本降了三成。这个例子说明批处理不是把数字调大就行，请求长度分布决定了实际收益。
连续批处理是更大的跳跃。传统静态批处理要等一批请求全部生成完才能接下一批，短请求被长请求拖住，GPU在批次尾部大量空转。连续批处理让请求在解码步之间进出，一个请求生成完立刻腾出位置给新请求。vLLM的PagedAttention配合连续批处理，把吞吐提升了好几倍。这个策略对单位成本的影响是数量级的，也是自建和云托管拉开成本差距的关键工程能力。我选推理框架时会把连续批处理的支持程度当作硬指标。有的托管服务看着便宜，底层没有连续批处理，并发一上来单位成本就失控。
前缀缓存对特定场景是成本杀手。系统提示词、RAG的共享文档、Agent的工具描述，这些前缀在大量请求里重复出现。缓存住它们的KV，命中时预填充成本几乎归零。客服场景的系统提示词动辄两三千token，缓存命中率做到八成以上，整体成本能降两三成。缓存容量和淘汰策略是工程活，缓存太小命中率上不去，缓存太大挤占KV Cache空间。我一般按业务的前缀重复度来定缓存预算，重复度高的场景给到显存的两三成。投机解码是另一个有意思的策略：用小模型先草拟几个token，大模型一次性验证，验证通过的草稿直接采纳，解码步数减少。收益取决于草稿接受率，接受率高的时候吞吐能提两三成，接受率低的时候草稿模型的开销反而成了负担。这个策略适合延迟敏感、输出可预测的场景，代码补全和格式化输出是典型；批量离线任务用它的性价比一般，草稿模型也占显存和算力。
4.4 上下文与输出模式差异：长上下文、流式输出、多轮会话与重试失败成本
请求形态对成本的影响，做对比时最容易被平均掉。长上下文是最大的变量。KV Cache随序列长度线性增长，32K上下文的缓存占用是4K的八倍。缓存占显存，批大小就得压下来，解码带宽利用率跟着降。预填充的算力消耗也随输入长度线性涨。两个因素叠在一起，长上下文请求的单位token成本可能是短请求的两到三倍。供应商对长上下文收溢价，底层原因就在这里。我对比API价格时会专门看长上下文档位的定价，那个数字才反映真实成本结构。有些供应商把长上下文单独列价，有些把溢价藏在输入单价里，口径得统一后再比。
输出长度的影响跟输入不一样。输出token走解码路径，带宽密集，单位成本通常比输入token高。多数API把输出定价定得比输入贵两到四倍，这个价差有工程依据。流式输出本身不改变token总量，它改变的是连接占用和调度方式。流式请求的连接保持时间长，对网关和并发连接数有压力，对GPU成本的影响反而小。我做成本归因时会把流式和非流式分开看，差异主要在基础设施层，不在算力层。多轮会话的成本结构跟单轮差别很大。每轮都要把历史对话重新作为输入发过去，输入token随轮次累积。十轮对话下来，输入token可能是首轮的五六倍。前缀缓存能缓解这个问题，缓存住历史部分的KV，只算新增内容。缓存没做好的系统，多轮场景的输入成本会失控，Agent场景尤其明显，工具调用的返回结果也要进上下文，上下文膨胀速度快，重试和纠错还会额外增加轮次。
重试和失败的成本是隐形的大头。超时重试、限流重试、格式解析失败重试、工具调用失败重试，每一次重试的token都照常计费。我见过一个Agent应用，重试率从5%涨到30%，当月账单涨了四成，团队一开始完全没往重试上想。失败请求里最冤的是预填充成本：输入都编码完了，生成到一半超时，钱花了没拿到结果。做成本对比时，我会把重试率作为一个显式参数放进去，重试率高的场景有效成本可能比标价高两三成。这个参数在POC阶段经常被忽略，上生产后才暴露出账单的狰狞面目。
4.5 供应商定价与规模效应：API溢价、批处理折扣、预留容量与区域价格差异
供应商定价这一层，得把“推理成本”和“商品价格”分开看。闭源API的价格里不只有GPU成本，还有模型研发摊销、对齐和安全投入、品牌溢价、利润空间。同样一个开源模型，自托管和某家API的价差能到三到十倍。这个价差不能简单说API贵，它买的是免运维、弹性、合规背书和持续升级。我对比时会算一笔账：自托管的GPU、人力、运维、可靠性投入加起来，能不能覆盖这个价差。中小规模团队往往覆盖不了。批处理折扣是供应商给的一类明确让利，离线任务走batch接口，价格打五折，代价是延迟从秒级变成小时级。日志分析、批量翻译、数据清洗这类场景用批处理，成本直接砍半。很多团队不知道有这个选项，或者嫌接入麻烦不用。我一般建议把业务请求按延迟敏感性分两档，不敏感的全走批处理，这一刀下去能省三成总预算。
预留容量和承诺折扣是另一类。云厂商的一年或三年承诺用量，折扣三到六成，适合负载稳定、可预测的业务。承诺用量的风险是锁死了灵活性，业务结构变了或者模型换代了，预留容量可能变成包袱。我的经验是只对基线负载做预留，基线以上的波动部分走按需或API，基线比例控制在总负载的六到七成比较稳妥。区域价格差异和汇率税费在跨境业务里不能忽略。同样一张H100，不同区域的按需价格能差两三成，电价和机房成本是底层原因。跨境调用还涉及网络延迟、数据出境合规、汇率波动。我做全球部署的成本模型时，会把区域价差、汇率缓冲、合规审计成本单独列项，不混进单位token单价里，混在一起看容易做出错误决策。
规模效应在定价里处处可见。大客户谈判有阶梯折扣，缓存命中的输入定价可能是正常输入的一到两成，批处理和预留叠加还能再降。这些规则叠在一起，同样的模型，不同客户的实付单价能差出一倍。做成本对比时只看官网标价会失真，得把能拿到的折扣规则套进去算有效成本。这也是我上一章强调有效成本的原因：标价是给散客看的，有效成本才是你实际要付的钱。还有一个常被忽略的隐性成本是供应商锁定，换模型的迁移成本、重新调优的工程投入、以及谈判时缺少备选方案带来的议价劣势，这些不写在账单上，但会实打实地影响三年TCO。
把五个驱动因素摆在一起看，价差的来源就清楚了。模型架构决定了单位token的算力底账，硬件和集群利用率决定了这些算力值多少钱，推理策略决定了算力被浪费了多少，请求形态决定了有效工作量有多少，供应商定价决定了这笔账怎么分。任何一层出问题，成本都可能翻倍。反过来，优化空间也藏在这五层里：换注意力机制、上连续批处理、做前缀缓存、压重试率、谈批处理折扣，每一招都有明确的成本杠杆。
下一章讲优化方案，会把这些驱动因素对应的抓手一个个展开。这一章先建立一张地图：看到一家供应商的报价，能大致判断它贵在哪一层；看到一个场景的成本异常，能顺着五层往下定位。这个判断力比记住具体数字有用得多。
上一章结尾我说优化空间藏在五个驱动因素里，这一章就把这些抓手一个个抠出来。写这一章我有点私心：过去一年我帮三个团队做过推理成本优化，省下来的钱从三成到六成不等，踩过的坑和尝到的甜头都攒了一肚子。这六个小节按“从模型到工程到业务到账单到部署形态再到场景”的顺序走，每一层都有具体能落地的招。有些招立竿见影，改一行配置账单就能掉两成；有些招得搭进去两周工程投入，回本周期得算清楚再动手。
我先把话撂这儿：优化不是把每一层都拉到最满。各层优化之间有耦合，过度优化某层，别的层会付出代价。量化压得太狠，输出质量掉点，业务侧重试率上去，省下的算力钱翻倍赔在重试token上。提示词压得太短，上下文信息不够，模型答非所问，用户体验崩了。真正有效的优化组合得看场景，得算总账。这一章我会在每一节里标出对应的代价和适用边界，别照搬。
5.1 模型选型优化：大参数模型与小模型、蒸馏模型、专用模型的分层路由
模型选型是优化空间最大的一刀，也是我最先动手的地方。很多团队一上来全量请求都走旗舰模型，觉得保险。我扒过一个客服系统的日志，六成以上的请求是“查订单状态”“改收货地址”这类标准化意图，70B旗舰模型处理这类请求的准确率和小模型拉不开差距，成本却差八到十倍。后来做了分层路由：意图明确、槽位固定的请求走7B微调模型，复杂咨询和投诉升级走70B，整体成本掉了五成多，用户满意度指标没动。分层路由的关键在路由器本身，用规则、小分类器还是让模型自己判断路由，得看请求的可预测性。规则路由便宜但脆，分类器路由灵活但得维护训练集，我一般从规则起步，跑两周看误路由率再迭代。
蒸馏模型是另一个选项。用大模型生成高质量回答，蒸馏到小模型上，推理成本降一个数量级，质量保留七八成。蒸馏的账得算清楚：蒸馏训练本身要花GPU钱，数据生成和标注要人力，蒸馏后的小模型在长尾请求上的表现会掉。我做过一个代码补全的蒸馏项目，小模型在常见语法模式上跟大模型几乎没差，遇到生僻库和复杂类型推导就开始胡编。最后是按场景切分：常规补全走蒸馏模型，复杂重构建议走大模型，成本降了六成，接受率只掉了三个点。专用模型这条路更窄也更省：OCR、意图分类、实体抽取这类任务用专用小模型，成本是通用大模型的几十分之一，准确率反而更高。前提是任务边界清晰，别指望专用模型处理开放域对话。
分层路由的代价是工程复杂度。多模型意味着多套部署、多套监控、多套评测集，版本管理也麻烦。我的经验是把模型数量控制在三到四层，超过五层运维成本会吃掉优化收益。路由策略要能回退：小模型置信度低的时候自动升级到大模型，别硬扛。回退率要监控，回退率涨了说明小模型覆盖的场景在漂移，得重新训练或调整路由规则。还有一点容易忽略：分层路由之后，成本归因得按路由层拆开看，不然你不知道省下来的钱是哪一层贡献的，也没法判断下一刀往哪儿切。
5.2 推理工程优化：量化、KV Cache复用、批处理、缓存与投机采样
推理工程这一层，我按投入产出比排序：连续批处理排第一，量化排第二，前缀缓存排第三，投机采样排最后。连续批处理是自建推理的入场券，没有它，GPU利用率上不去，别的优化都是小打小闹。vLLM、TensorRT-LLM、SGLang这几个框架都支持，选哪个看团队技术栈。我见过用原生HuggingFace transformers直接上生产的，QPS一到二十GPU就满载，换成vLLM之后同样硬件扛到一百五，单位成本直接除三。这个差距不是调参能弥补的，是架构级的。
量化我一般从FP8起步，A100和H100都支持，精度损失小，吞吐提升明显。INT8在多数场景能稳住，INT4得看任务：分类和抽取任务能扛，生成和推理任务掉点风险大。量化的A/B测试别只看评测集分数，得看业务指标。我做过一个摘要任务，INT4量化后ROUGE分数只掉了一个点，人工抽检发现长文档的细节遗漏率涨了不少，业务方不接受，退回INT8。量化校准数据的分布要贴近真实流量，拿评测集校准、拿生产流量跑，掉点概率高。还有个小坑：不同推理框架对量化的支持程度不一样，有的只支持权重量化不支持激活量化，选框架时得对着量化方案看。
KV Cache复用和前缀缓存是一回事的两面。系统提示词、few-shot示例、RAG的共享文档块，这些前缀在请求间重复，缓存住KV能省掉大量预填充算力。我帮一个RAG客服系统做优化，系统提示词加检索模板有两千多token，缓存命中率做到七成五之后，整体成本降了四成。缓存的工程细节不少：缓存容量按业务前缀重复度来定，重复度高的给到显存三成，重复度低的给一成；淘汰策略用LRU还是LFU看访问分布；缓存key的设计要能区分租户和场景，别串了。投机采样我放在最后，因为它对场景挑剔。代码补全、格式化输出、模板化回答这类可预测性强的场景，草稿接受率能到七成以上，吞吐提两成多。开放域对话接受率低，草稿模型白烧算力。上投机采样之前先跑一周统计接受率，低于五成不值得上。
批处理的调优细节我在上一章提过一嘴，这里补两句。批大小不是越大越好，填充率会随批大小上升而下降。按请求长度分桶再攒批，填充率能稳住。动态调整批大小比固定批大小省心，框架根据队列深度自动伸缩。还有一点：批处理对TTFT的影响要业务方确认。批大小从8加到32，TTFT可能从200毫秒涨到600毫秒，实时客服场景用户能感知到卡顿。延迟敏感的业务得设TTFT上限，批处理策略在上限内做优化。
5.3 业务层优化：提示词压缩、RAG上下文裁剪、输出长度控制与结果缓存
业务层的优化经常被工程师忽略，觉得那是产品经理的活。我不同意。提示词里塞了多少废话、RAG检索回来多少无关片段、输出让模型啰嗦了多少，这些直接决定token量，省钱效果不比工程优化差。我做过的项目里，提示词压缩的投入产出比最高：把系统提示词从一千五百token压到六百，删掉重复的格式说明和冗余的示例，模型表现没掉，输入成本直接砍六成。压缩不是瞎删，得按“模型是否真的需要这段信息”来审。很多提示词是历史迭代堆出来的，里面藏着过期的业务规则和互相矛盾的指令，删掉反而让模型更稳定。
RAG上下文裁剪是另一个大头。检索回来十个片段，模型实际用到的可能就两三个。把无关片段塞进去，不光浪费输入token，还稀释了关键信息的注意力权重，回答质量反而降。我的做法是加一道重排序，用交叉编码器给片段打分，只保留Top3到Top5。再狠一点，做句子级裁剪，把片段里跟问题无关的句子剔掉再拼上下文。一个法律文档问答系统做完这两步，平均输入从六千token降到两千八，回答准确率涨了两个点，成本降了一半多。输出长度控制靠提示词和停止条件。提示词里明确“回答不超过三句话”“用要点列出”这类约束，输出token能压三到五成。停止条件设好，别让模型在答案后面加“希望以上回答对您有帮助”这种废话。流式输出场景下用户能感知到模型在啰嗦，体验也受影响。
结果缓存放业务层，命中直接返回，零推理成本。适合缓存的是高频重复查询：FAQ、商品参数、政策条款。缓存key的设计要考虑用户上下文，个性化推荐的结果不能跨用户缓存。缓存有效期按内容更新频率定，政策类内容按天刷，商品库存得实时。我见过一个团队做了语义缓存，相似问题命中同一答案，命中率做到三成，成本降了两成多。语义缓存的坑在阈值调参，阈值松了答非所问，紧了命中率上不去，得拿业务日志调。
5.4 API使用优化：输入输出分离计费、批处理接口、缓存计价与预算告警
用API的团队，账单优化第一刀砍在计费规则上。多数API的输入和输出是分开计价的，输出单价通常是输入的两到四倍。这意味着控制输出长度比控制输入长度更值钱。我对比过两个提示词版本，一个让模型详细解释，一个让模型给结论加三点理由，输出token差了四倍，账单差了六成。业务方要的是答案不是论文，提示词里把输出格式卡死，这笔钱就省下来了。长上下文溢价也得盯，有的API对超过32K的输入单独加价，把长文档切块处理、只把相关段落送进去，比整篇塞进去便宜得多。
批处理接口是明确的价格洼地，离线任务走batch能打五折甚至更低。日志分析、批量翻译、数据清洗、评测跑分，这些对延迟不敏感的任务全走批处理。我帮一个团队梳理过API账单，发现他们每天有三十万次异步内容审核请求走的是实时接口，改成批处理之后这部分成本降了五成五。接入成本就是改个SDK调用方式，加个任务队列，两天工作量。很多团队不用批处理纯粹是不知道有这个选项，或者历史代码懒得改。缓存计价是另一个容易被忽略的规则：多数API对命中缓存的输入token收一到两成的价格。把系统提示词和固定上下文标记成可缓存，成本立降。缓存有写入成本，得算命中率划不划算，命中率低于三成可能不划算。
预算告警和配额管理是兜底手段。按项目、按租户、按模型设预算阈值，超了告警或限流。我见过一个Agent应用因为死循环重试，一晚上烧掉一个月预算，有告警的话能拦住。API侧的重试策略也要优化：指数退避加最大重试次数，别让失败请求无限重试。失败请求的预填充成本是纯浪费，能省则省。还有个小技巧：把不紧急的请求路由到低价区域或低价时段，有些供应商的定价按时段浮动，错峰调用能省一成多。
5.5 自建与API成本拐点分析：何时API更优、何时自建或混合部署更优
自建还是用API，这个问题我被问过不下二十次。答案取决于四个变量：月token量、延迟要求、数据合规要求、团队工程能力。单看token单价，自建在规模上去之后肯定便宜，但把人力、运维、GPU折旧、闲置成本算进去，拐点会往后推很多。我按实际项目算过一笔账：一个中等规模的对话应用，月消耗三十亿token，用旗舰API月账单大概六万美元；自建八卡H100集群跑开源70B模型，云上按需实例月租约两万四，加一个半人力运维，加推理框架调优的工程投入，折算下来月成本三万多。拐点大概在月消耗十到十五亿token之间，低于这个量API更划算。
这个拐点不是死的，几个因素会让它移动。模型迭代速度快的业务，自建的GPU集群可能半年就面临模型换代，硬件折旧还没走完。API供应商降价频繁，去年一年主流API降了两到三轮，自建的成本优势窗口会收窄。数据合规要求高的业务，比如金融和医疗，自建的溢价有合规价值，拐点得按合规成本重新算。延迟要求极端的业务，比如实时语音交互，API的网络往返加排队延迟兜不住，自建或者边缘部署是刚需。我的建议是先从API起步，把业务跑起来，用量和成本结构稳定了再算自建账。一上来就自建，模型选型和流量预估都容易错。
混合部署是多数团队的终态。基线负载走预留实例或自建集群，峰值和突发走API。基线比例控制在六到七成，上面那一层用API兜。这样既有规模效应，又保留弹性。混合部署的工程复杂度主要在流量调度和成本归因，得有一个统一网关做路由和计量。我帮一个团队搭过这套，网关按模型版本、租户等级、实时负载三个维度路由，月度成本比纯API降了四成，比纯自建降了两成多。混合部署的运维要盯两套系统，人力投入比单模式高，小团队得掂量。
5.6 场景化优化组合与ROI评估：实时客服、长文档分析、代码生成与Agent应用
优化方案落到场景里，组合方式完全不一样。实时客服的核心矛盾是延迟和成本的平衡。我的组合是：小模型加规则路由处理标准意图，大模型兜底复杂咨询，前缀缓存吃掉系统提示词，输出长度卡在三句话以内，语义缓存接高频FAQ。这套组合下来单位成本降五到六成，TTFT控制在500毫秒以内。实时客服里最忌讳的是为了省钱把TTFT拉到两秒以上，用户等不了，转人工率上去，人工成本比省下的token钱贵得多。
长文档分析的成本大头在输入。我的组合是：文档预处理做段落切分和相关性打分，只送Top片段给模型，输入token压到原来的三成；用支持长上下文的模型但别真塞满，32K窗口塞8K比塞30K便宜一半多；输出要求结构化要点，控制长度；批量文档走批处理接口。一个合同审查系统做完这套，单份文档成本从一块二降到三毛五，审查准确率没掉。长文档场景还有个细节：分块处理会丢失跨段落的逻辑关系，涉及条款交叉引用的任务得分块加全局摘要，别一刀切。
代码生成场景对延迟敏感，对输出质量要求高。组合是：补全任务走蒸馏小模型加投机采样，接受率能到七成；复杂生成走大模型；代码库的上下文用RAG检索相关函数签名，别把整个文件塞进去；缓存常用库的文档片段。Agent应用的优化最复杂，成本失控通常出在多轮上下文膨胀和重试上。我的组合是：历史对话做摘要压缩，只保留关键状态；工具调用结果做结构化裁剪，别把原始JSON全塞回去；重试加最大轮次限制和失败快速降级；用便宜模型做工具选择，贵模型做最终生成。Agent的成本监控要细到每轮每一步，不然你不知道钱烧在哪个环节。
ROI评估得算三笔账：省下的推理成本、投入的工程人力、以及质量变化带来的业务影响。工程投入按人天折算，回本周期超过六个月的优化项优先级往后放。质量影响最难量化但最不能忽略，我一般做小流量A/B，业务指标掉超过两个点就回滚。优化是个持续过程，不是一次性项目。我习惯每季度做一次成本复盘，看单位token成本、各层优化项的贡献、以及有没有新的优化空间。模型和工具在变，上季度最优的组合这季度可能不是了，复盘得跟上。
写到最后一章，我想把前面五章散落的线索收一收。这一章不再是单纯的成本数字对比，更多是我这几年做选型顾问时攒下来的决策直觉和踩坑记录。有朋友问我，你把每百万token成本算那么细，最后选型到底看什么。我的答案永远是：看场景、看总账、看未来十二个月的变化方向。这一章五个小节，从决策流程到常见误区，从合规安全到趋势判断，最后落到持续优化的闭环上。有些判断带我的主观偏见，你读的时候结合自己业务校验。
6.1 按业务场景的推理成本对比选型清单与决策流程
选型这件事我习惯先画一张表，把候选模型按场景维度打分。表格左边列场景类型，右边列指标权重，成本只占其中一列。我做过一个内容平台的选型，他们一开始只比每百万token单价，我硬拉着产品和技术一起重新排权重。实时客服场景里延迟权重给到三成，成本只占两成，因为用户等两秒就转人工了，人工成本是token成本的十几倍。长文档分析场景里上下文窗口权重拉高，输出质量其次，单价反而排第三。代码生成场景里补全接受率是第一权重，接受率掉五个点，开发者手动改的时间成本远超省下的API账单。
我的选型决策流程分四步走。第一步按场景切分请求类型，把延迟敏感度、输出长度分布、上下文长度分布、质量容忍度四个维度标出来。第二步用这些小样本跑基准测试，别只看公开评测集，拿自己业务日志里的真实请求跑，每个候选模型跑五百到一千条，记录准确率、延迟分位数和实际token消耗。第三步算场景化有效成本，把重试率、缓存命中率、输出长度分布都折算进去，很多模型标价便宜但输出啰嗦或者重试率高，有效成本反而贵。第四步做小流量灰度，按百分之五到十的流量切过去跑两周，盯业务指标和账单两条线。
选型清单我一般列这几项：模型档位与参数规模、每百万token输入输出单价、上下文窗口与长上下文溢价规则、批处理与缓存计费规则、TTFT和TPOT的P95实测值、SLA承诺与历史可用性、数据合规认证、供应商锁定风险、以及最近六个月的降价频率。每一项打分完加权汇总，得分最高的不一定是最终选择，得看有没有一票否决项。金融业务的数据出境限制就是一票否决，价格再低也不能选。我见过一个团队选了家便宜供应商，结果对方突然调整计费规则，长上下文溢价翻倍，迁移成本又高，只能咬牙续着。选型时把供应商的定价历史和调价公告翻一翻，频繁调价的要留个心眼。
决策流程里有个环节容易被跳过：让业务方参与权重打分。技术团队自己拍权重，选出来的模型技术指标好看，业务方用起来觉得回答太啰嗦或者太简略。我现在的做法是拉业务方做盲测，同一批请求不同模型的回答混在一起打分，打分结果换算成质量权重填进选型表。盲测花半天时间，能避免后面两个月的扯皮。还有一点，选型不是一次性的，我一般设一个复审触发条件：单位成本波动超过两成、业务场景发生重大变化、或者供应商有重大调价，就重新跑一遍选型流程。
6.2 成本对比中的常见误区：只看单价、忽略输出token、忽略重试与运维成本
只看单价是头号误区，我每个月都能碰到。有人拿A模型每百万token五美元跟B模型三美元比，说B便宜四成。我让他把最近一周的请求日志拉出来按实际计费规则重算，结果A模型的有效成本反而低一成五。原因在输出长度分布：A模型回答简洁，平均输出一百八十token，B模型啰嗦，平均输出四百二十token，输出单价还是输入的三倍。算上输出差异，B模型的单次请求成本比A高出一截。这个坑太常见了，我建议所有做成本对比的人先把“每百万token单价”这个字段从表格里删掉，换成“每千次典型请求成本”。
忽略输出token是第二个高频错误。多数API输出单价是输入的两到四倍，输出长度控制不住，单价再低也白搭。我做过一个提示词对比实验，同一个模型，一个提示词让模型“详细解释”，另一个让模型“给结论加一句话理由”，输出token差了三点八倍，单次请求成本差了近三倍。很多团队选型时拿标准测试集的输出长度算成本，实际业务流量里模型输出长度波动很大，长尾请求的输出能占到总输出的三成以上。选型评估必须用真实流量的输出长度分布来算，别用平均值糊弄。
重试成本是隐形杀手。API调用失败重试，失败请求的预填充成本不退，重试又产生新的输入输出token。一个可用性百分之九十九点五的API，理论上每两百次请求有一次失败，实际业务里因为超时、限流、格式错误触发的重试率能到百分之三到五。我见过一个Agent应用重试率百分之十二，账单里有近两成是重试烧掉的。选型时得把重试率乘进有效成本公式，不同供应商的限流策略和超时行为不一样，实测两周再下结论。
运维和工程投入最容易被低估。用API不是零运维，提示词版本管理、评测流水线、成本监控、供应商对接都是活。自建更重，推理框架调优、GPU驱动升级、模型版本迁移、故障排查，一个半人力是起步配置。我帮一个团队算过自建TCO，硬件和云资源只占六成，剩下四成是人力。选型对比时把运维人力按市场价折算进去，很多“自建更便宜”的结论会翻过来。还有个细节：模型版本升级带来的评测和回归测试工作量，API供应商升版本你至少得跑一轮回归，自建升版本还得做兼容性测试和回滚预案。
6.3 合规、数据安全与供应商锁定对综合成本的影响
合规成本在选型表里经常被塞进“其他”一栏，我觉得这栏得单独拉出来算。金融、医疗、政务类业务的数据出境限制直接砍掉一批海外API选项，剩下的选项里能过等保三级和密评的更少。过合规的供应商有溢价，这个溢价你没法用技术手段绕过去。我接触过一个医疗问答项目，本来选了一家便宜的海外API，法务介入后发现患者数据不能出境，换成本地合规供应商，单价贵了六成，项目预算重新批了一轮。合规评估要在选型第一步做，别等合同快签了才发现过不了。
数据安全对成本的影响有两层。显性层是加密传输、私有部署、审计日志这些功能要不要额外付费，有的供应商把审计日志和VPC部署放在企业版里，企业版单价是标准版的一点五倍。隐性层是数据泄露风险对应的保险和应急成本，这个没法精确算，但得在选型时有意识。我一般建议敏感数据的业务走私有化部署或者专有实例，贵是贵，省下来的风险敞口值这个钱。
供应商锁定是慢性成本。API用久了，提示词工程、评测集、监控看板都围着这家供应商的接口特性建，迁移成本随时间涨。锁定的代价在平时看不见，等到供应商涨价、服务降级或者合同到期谈不拢的时候就冒出来了。我见过的锁定重灾区是那些用了供应商专有功能的应用，比如特定格式的函数调用、供应商独有的缓存接口、绑定供应商SDK的Agent框架。减少锁定的做法是抽象一层适配层，把模型调用、提示词模板、工具调用格式都做一层封装，切换供应商时改适配层不改业务代码。适配层本身有开发成本，业务量小的时候可以先不做，月token消耗过五亿之后值得投。
还有个隐蔽的成本是合规审计的持续性。用API的团队每年要做供应商合规复审，自建的团队要做等保测评和渗透测试，这些都是真金白银。我在选型清单里加了一栏“年度合规维护成本”，按供应商规模和认证齐全程度估个数。认证齐全的大供应商这部分省心，小供应商可能得你自己补材料。锁定风险和合规成本这两项在选型打分表里权重不用太高，但得一票否决项里备着。
6.4 趋势展望：推理芯片、模型压缩、MoE、缓存计价与单位token成本下降
推理芯片的格局在变，这个变量对成本曲线影响最大。英伟达的迭代节奏依然快，B200和GB200的推出一度让H100的租赁价格往下走了一截。AMD的MI300X在部分推理场景开始有像样的份额，价格比同代英伟达卡低两到三成，软件生态的差距在缩小。云厂商自研芯片走专用路线，谷歌TPU和亚马逊Trainium对自家云上推理的成本优化明显，缺点是绑定云平台。我的判断是未来两年推理硬件的选择会从“英伟达默认”变成“按任务选卡”，小模型推理和量化模型跑在便宜卡上的性价比会越来越突出。
模型压缩的进展比预期快。量化从FP16到FP8再到INT4的落地路径越来越成熟，INT4在多数生成任务上的质量损失已经能控制在可接受范围。蒸馏和剪枝的工具链也在完善，开源社区有现成的蒸馏框架，小模型的能力天花板在往上抬。我去年做的一个蒸馏项目，七B模型在特定任务上达到七十B模型九成二的准确率，成本只有十五分之一。这个趋势往下走，分层路由里的“小模型层”会越来越厚，旗舰模型只处理长尾复杂请求。
MoE架构对推理成本的影响是结构性的。稀疏激活让单次推理只用到部分参数，同样参数量级下推理成本比稠密模型低不少。DeepSeek和Mixtral这些开源MoE模型把这条路走通了，云厂商和自建集群都在跟进。MoE的代价是显存占用高，部署门槛比同参数稠密模型高，批量推理的收益明显，小批量低并发的场景优势打折扣。我预期MoE会成为中大型模型的主流架构，稠密模型往小参数和专用方向走。
缓存计价在2024年从附加功能变成标配。主流API都推了提示词缓存，命中缓存的输入token收一到两折。这个趋势往下走，缓存粒度会更细，从整段前缀缓存到片段级缓存，缓存的生命周期管理和跨租户共享机制也会成熟。对用API的团队来说，提示词工程的重心会从“压缩提示词”部分转向“设计可缓存的提示词结构”。自建侧的前缀缓存和KV Cache复用已经是标配能力，下一步的优化空间在跨请求的语义级缓存。
单位token成本往下走的长期趋势没变，但速度会分化。旗舰模型的单价下降会趋缓，因为训练成本和推理硬件的投入还在涨。中小模型和专用模型的单价下降会更快，竞争激烈加上硬件适配成熟。我的建议是成本模型按年更新，别拿今年的单价做三年预算。还有个趋势值得盯：按任务结果计费的模式在冒头，部分供应商开始试水按成功调用或按业务结果收费，这对成本可预测性是好事，对用量波动大的业务可能不友好。
6.5 建立持续成本对比与优化闭环：基准测试、A/B验证、季度复盘与动态调优
成本优化不是一次性项目，我把它当成一个持续运转的闭环。闭环有四个环节：基准测试、A/B验证、季度复盘、动态调优。基准测试是地基，得有一套固定的评测集和负载生成器。评测集按业务场景分，每个场景两百到五百条真实请求，覆盖短查询、长文档、多轮对话、工具调用这些模式。负载生成器模拟并发和请求分布，跑出来的指标包括每千次请求成本、TTFT的P50和P95、TPOT、吞吐和错误率。这套东西搭一次能用很久，每次候选模型或配置变更都跑一遍。
A/B验证是上线前的最后一道闸。小流量切百分之五到十，跑一到两周，对比实验组和对照组的业务指标、成本指标和延迟指标。业务指标看场景定，客服看解决率和转人工率，代码生成看接受率和修改率，文档分析看人工抽检准确率。成本指标看每千次请求成本和每活跃用户成本。延迟指标看P95而不是平均值，尾部延迟决定用户体验。A/B跑完做统计显著性检验，样本量不够的延长周期，别拍脑袋下结论。我见过一个团队A/B只跑了三天就全量切，结果周末流量模式跟工作日不一样，周一才发现成本涨了两成。
季度复盘是我强制自己做的动作。复盘看四样东西：单位token成本的变化曲线、各优化项的贡献拆解、新出现的成本异常点、以及外部价格和技术变化。单位成本曲线按模型和场景拆开画，涨了要找到原因，降了要知道是哪一层优化的功劳。贡献拆解用归因工具做，按模型、租户、场景、token类型四个维度切。成本异常点看账单的环比波动，突然涨的模块拉出来单独查。外部变化扫一遍供应商调价公告、新模型发布、硬件租赁价格波动，评估要不要触发选型复审。复盘输出一份两页的备忘录，记录结论和下一步动作，发给相关方。
动态调优是把复盘结论落回系统。调优动作分三类：配置类、路由类、架构类。配置类最快，改批大小、缓存容量、量化精度这些参数，当天能生效。路由类改分层路由规则和流量分配比例，需要跑一轮A/B。架构类动模型选型或部署形态，周期按月算。我的经验是每季度至少落地一个配置类和一个路由类调优，架构类调优一年一到两次就够，动太频繁团队受不了。调优要有回滚预案，每个变更记录变更前后的指标对比，出问题十分钟内能切回去。闭环跑顺了之后，成本优化从救火变成例行公事，单位成本每年降两到三成是能做到的，再往上就得等外部技术变化给机会了。
