上一篇跟着一个 token 走完了整条链路：请求进网关，文本切成 token，Prefill 一次读完题，Decode 一个字一个字往外吐，最后落回你的屏幕。这一篇把同一条链路翻过来看：它值多少钱。

模型公司为什么想做推理芯片，最后都要回到一笔账——生产一百万 token，到底花多少。这笔账算不清楚，后面谈调度、谈 KV Cache、谈推理服务系统，就不知道省下的是哪一项。

先划范围。这里的推理芯片，指数据中心里跑大模型的那类加速器及其配套系统，不算手机、汽车、摄像头里的端侧 NPU。

图｜一百万 token 的成本从哪来

一、四个数字，四种含义

这个问题看着简单：查一张卡的租金，除以每秒生成的 token 数，答案就出来了。

真算过一遍就知道不行。同一款模型，输入 200 个 token 和 20 万个 token，成本结构完全不同；同一张卡，服务 2 个用户和服务 200 个用户，吞吐和延迟是两个世界；同样记成“一百万 token”，缓存命中的输入、重新算过的输入、真正交付出去的输出、超时重试白跑的 token，根本不是同一种产出。

所以先得把四个常被混着用的数字分开。

API 售价。你在模型平台看到的每百万 token 价格，是商业售价。里面装着硬件、软件、网络、研发、运营、渠道、税费和利润，也可能掺着获客补贴、缓存折扣和分时定价。售价可以低于阶段性成本，也可以远高于边际成本。它能说明市场竞争，说明不了芯片成本。

2026 年 7 月 10 日那天，DeepSeek 官方价格页把输入拆成缓存命中和未命中，输出单独计价。V4-Flash 是每百万输入 0.0028 美元命中、0.14 美元未命中，输出 0.28 美元；V4-Pro 对应 0.003625、0.435、0.87 美元。同一张价目表上，命中与否差了五十倍。

这组数字真正的信息不在谁更便宜。同样叫“输入 token”，缓存命中与否就是两条计算路径。三种 token 混在一起，连售价都解释不通，更别说反推芯片成本。

云实例租金。它比 API 价更靠近基础设施，但仍然是云厂商的售价。一个实例里还装着 CPU、主机内存、虚拟化、网络、运维和云厂商的利润；按需还是预留、放在哪个地域、签多长的约，都能把价格拉开。

芯片峰值性能。参数表上的 FLOPS、TOPS、HBM 带宽，每个都带着前提：某个数据类型、某个频率、某个条件。模型能不能接近这个上限，要看矩阵形状、批量、数据复用、内核、编译器和内存访问。Decode 每一步只出一个 token，宽大的矩阵单元根本来不及喂饱。

生产成本。这才是模型公司真正的账：一段时间内整个推理集群的全口径支出，除以同期真正交付、并且符合服务标准的 token。自研芯片要降的是这一个数。

再往下，还得把 token 拆成四个计数器：缓存命中的输入、缓存未命中的输入、成功交付的输出，以及因为超时、取消、重试、安全拦截消耗掉却没形成交付的那部分。前三个决定收入和体感，最后一个决定系统损耗。只看日志里的总数，成本会被摊薄；只看成功请求，又会漏掉生产环境里最真实的浪费。

二、一次请求，两张成本表

图｜Prefill 与 Decode 的资源瓶颈不同

用户提交一段话，模型不是从头到尾一种算法跑到底。

Prefill 是读题。一次处理整段提示，算出每一层的中间状态，顺手把 KV Cache 建起来。这一步矩阵大，算术强度高，容易把矩阵单元喂饱。输入越长，要处理的 token 越多，首字延迟越高。长文档、代码库、多轮 Agent 的上下文，会把 Prefill 变成账上的一项。系统提示词和共享文档能命中前缀缓存，有一部分可以复用；上下文每次都不一样，就只能重算。

Decode 是答题。每轮读一遍权重和全部历史 KV，只生成一个新 token，再把新的 KV 写回去。单个请求的矩阵很窄，计算单元吃不满；权重和 KV 却要从 HBM 里反复搬出来。并发低的时候，Decode 卡的是带宽，不是算力。

把并发拉起来，一次权重读取可以摊给更多请求，每个 token 分摊的权重流量就降下去。但并发不是越高越好：排队变长、KV 占用上去，首字延迟和字间延迟一起恶化。

所以输入 token 和输出 token 必须分开计量。混成一个“平均每百万 token 单价”，两种完全不同的瓶颈就被抹平了。

三、公式：分子算全，分母算有效

每百万输出 token 成本 ＝ 全口径集群小时成本 × 1,000,000 ÷（满足 SLA 的输出 token/s × 3,600 × 可用时间比例）

公式只有一行，做错的通常是分子和分母。

分子要装下这些东西：加速器折旧或云实例租金；CPU、主机内存、本地盘和网卡；机内、机架内、机架间三层交换网络；加速器、CPU 和网络设备的 IT 电费；被 PUE 放大的配电、制冷和其他机房能耗；机柜、配电、液冷和建筑的摊销；驱动、编译器、推理软件、监控和运维人力；备件、故障、扩缩容和高峰冗余；还有采购预付款、资金成本和设备闲置。

自建和租云是两种口径，不能相加。自建自己算折旧和资金成本，租云直接用实例价。

分母要装下这些：新算的输入 token、命中 Prefix cache 的输入 token、成功返回给用户的输出 token、草稿模型提出来但被目标模型拒绝的 token、用户取消或超时或故障没交付的 token、安全检查和格式修复以及失败重试产生的 token。

一个系统可以生成很多 token，但如果大部分请求都超时了，这些计算进了成本，产出却进不了“有效”。

SLA 得写在公式前面。至少四项：首字延迟、字间延迟、P95 或 P99 尾延迟、错误率和模型精度。没有这几项约束，最快的提速方式就是无限排队、把 batch 拉到天上去——总吞吐很好看，用户等不到第一个字。

四、把峰值吞吐还原成有效吞吐

图｜峰值吞吐怎样变成有效吞吐

宣传页上的吞吐不能直接进分母。更接近生产的算法是这样一层层往下剥：

有效输出 token/s ＝ 离线峰值 × 流量形状效率 × 调度与批处理效率 × SLA 达标比例 × 请求成功交付比例

离线能跑 4,000 token/s，真实的长短请求混在一起只剩 75%，调度和通信再留 80%，其中 90% 的 token 满足延迟门槛，最后成功交付 98%，有效吞吐就只剩 2,117 token/s。链条上任何一项被漏掉，成本都会被低估。

这些系数不能拍脑袋。流量形状来自输入输出的长度分布；调度效率来自 batch、KV 和网络监控；SLA 达标比例要逐请求看 TTFT、ITL 和尾延迟；成功比例来自取消、超时、重试和故障日志。

算一遍情景账。一个服务池的全口径成本每小时 120 元，有效输出吞吐 1,800 token/s，可用时间比例 92%，代入就是 120 × 1,000,000 ÷（1,800 × 3,600 × 92%），约 20.13 元。

硬件不动，但长请求变多、KV 吃紧、排队把有效吞吐压到 900 token/s，可用比例掉到 85%，单价变成约 43.57 元。分子一分没动，成本贵了 116%。

反过来，量化、缓存和调度把有效吞吐提到 2,800 token/s，可用比例升到 95%，单价约 12.53 元。

同一批机器，三张不同的账单。芯片省不省钱，得看这条链路整体走完的结果，而不是峰值算力谁高。

五、规格表能给两个下界

参数表给不出最终成本，但能给两个下界，够用来判断方向。

第一个是权重带宽。假设一次 Decode 要读的有效权重是 W 字节，HBM 可持续带宽是 B，一次并行生成 N 个请求，那么 Decode 总吞吐上界约等于 N × B ÷ W。

它说明三件事：权重越大、位宽越高，每轮搬得越多；带宽越高，Decode 的天花板越高；并发起来，一次权重读取能摊到更多 token 上。

但这仍是理想值。KV Cache、算子空洞、MoE 路由、跨卡通信、采样和软件开销，都会继续把这个数往下压。

第二个是 KV 容量。标准注意力下，每个 token 的 KV 占用近似为 2 × 层数 × KV 头数 × 每头维度 × 存储字节数，那个 2 是 Key 和 Value。上下文越长、并发越高，占得越多。GQA、MQA、KV 量化、DeepSeek 的 MLA 会改写这个式子，但不会让问题消失，只是把容量、计算和精度重新做一次交换。

再往上一层：每个 token 占 K 字节，平均在场上下文 L 个 token，同时活跃 Q 条序列，光 KV 就要 K × L × Q。

这就解释了为什么“平均长度”不够用。大部分请求很短、少数极长时，决定会不会 OOM 的是 P95 上下文。对外承诺 128K，内部按 4K 平均值规划，流量稍微一偏，就是抢占、换出、重算。PagedAttention 那篇论文讲的就是这件事：连续预留带来的内部碎片、外部碎片、给未来 token 留位造成的浪费，改用逻辑块到物理块的映射，按需分配。

MoE 要单独说一句。每个 token 只激活部分专家，矩阵计算量可以低于同等总参数的稠密模型，但没被激活的专家权重也得放在某个地方；专家并行还会带来 router、top-k、token dispatch、all-to-all、负载不均和跨卡等待。所以 MoE 的成本至少四份：激活专家的计算、全部或局部专家权重的驻留、token 重排的通信、热点专家造成的空闲。只拿“激活参数量 × token 数”去估，后三份全漏了。

六、同一张卡，为什么跑出不同成本

图｜四个变量怎样推高单位成本

先是长度分布。两个系统的平均输入都可能是 4K，一个全部贴着 4K，另一个由大量短请求和少量超长请求拼出来。后者更容易队头阻塞、KV 突增、尾延迟爆炸。成本模型至少要保留 P50、P95 和最大值，不能只放一个平均数。

然后是 batch。太小，矩阵单元和 HBM 都用不满；太大，请求等得久，KV 压力也上来。最佳 batch 不是芯片常数，是流量、SLA 和模型一起决定的。

量化也不保证按位宽等比例省钱。FP16 换 INT8，权重体积理论上减半，但硬件没有高效 INT8 路径、内核要频繁反量化、部分算子回退高精度、或者精度回归不过，实际收益会小一大截。量化有没有效，得同时看模型质量、吞吐、延迟、显存和功耗。

缓存命中率是业务决定的，不是芯片能力。固定系统提示、共享知识库、重复前缀适合缓存；完全个性化、上下文频繁变化的场景根本复不了。测算时先假定一个漂亮的命中率，等于提前给自己发奖金。

生产利用率更不是实验室利用率。线上流量有峰谷，为了高峰不排队，低谷必然有空；为了扛故障，还得留冗余。负载不够稳定的公司，自研芯片省下的单次计算成本，可能抵不过闲置和研发摊销。

能耗同理。有研究把 Prefill 和 Decode 分开测量后发现，低精度并不必然按计算时长同比例降低每个 token 的能耗：内存受限或者内核之间有空档时，计算是变快了，系统仍在等待中耗电。PUE 只能放大 IT 功耗，替代不了实测。一套设备平均 IT 功率 8 千瓦、机房 PUE 1.30，设施侧就是 10.4 千瓦，其中 2.4 千瓦来自制冷和配电。Google 披露过成熟数据中心 2024 年全年平均 PUE 1.09，那是它那套运营体系的结果，搬到别的机房不成立。

七、三类服务，三本账

短问答：输入短、输出相对长，Decode、并发和字间延迟更重要。提高 batch 和 HBM 带宽通常最值钱，但交互延迟这条线不能破。

长文档问答：输入很长，Prefill、首字延迟和 KV 容量顶在前面。Chunked Prefill、Prefix cache、Prefill 与 Decode 解耦，都可能明显改写成本。

长链路 Agent：会多轮调模型和工具，上下文一路增长，中间夹着等待、取消、重试和结果回填。表面上只输出一段答案，内部可能跑了好几轮 Prefill 和 Decode。这类服务只按最后展示的 token 估硬件工作量，一定估少。

八、算完账，才轮得到芯片

图｜算账前先要填完的八项

模型公司比通用芯片厂商更清楚自己的模型结构、请求长度、缓存命中、精度容忍和高频算子。如果每天有足够多、足够稳的 token，这些信息就能换成硬件取舍：砍掉用不上的通用能力，把面积让给受约束的 HBM、SRAM、互联和特定算子，再靠编译器和调度把成本压下去。

但这条路有前提，一条都不能少：负载足够大，摊得薄芯片 NRE 和软件团队；模型结构在芯片周期内相对稳定；制程、HBM、封装和服务器都能量产；软件栈在新模型出现后还能持续适配；省下来的钱大于供应链、闲置和迁移风险。

还要把一次性投入摊回 token。设设计、流片、软件和验证的总投入是 NRE，生命周期内预计交付的有效 token 是 T，那么仅研发摊销就是 NRE × 1,000,000 ÷ T。

需求低于预测、芯片延期一年、模型架构提前变了，分母都会缩水。报表上看着便宜的 ASIC，可能因此失去经济性。

一百万 token 没有一个脱离场景的统一成本。

能比的口径只有一个：把模型、长度分布、精度、并发和 SLA 固定住，看一个系统要花多少全口径小时成本，最后交付多少有效 token。

这也是判断推理芯片的最终标准。参数再漂亮，如果芯片在等数据、等请求、等网络，或者大量 token 因为超时和故障根本没交付，它就没有把成本降下来。

同一块芯片跑出完全不同的账单，答案通常不在规格表里，而在调度器、KV Cache 和 Prefill 与 Decode 之间。