大模型推理成本拆解：KV Cache、显存与互连的场景边界

同一个模型，单人短对话跑得很轻松，一批长文档同时进入服务，显存却可能迅速吃紧。差别不仅在模型参数量，还在于每个会话都要保存一份不断增长的KV Cache，也就是注意力机制的键值缓存。

本文采用一张能够复算的显存账，而不是“某张显卡一定装不下”的结论。下面用一组公开机制下的教学参数，拆开容量、带宽与并发，说明什么时候该优化缓存，什么时候该先查算力或通信。

输入处理与逐字生成，压力并不相同

常见自回归大模型推理分为两个阶段：prefill先处理输入，decode再逐步生成输出。前者可以并行处理较多输入位置；后者需要沿着已经生成的序列继续计算，常见小批量场景对内存数据搬运更敏感。来源：NVIDIA推理优化说明。

但“decode常受带宽约束”，不等于任何模型、任何批量都只缺带宽。批量变大、上下文变长、并行方式改变之后，计算量、缓存读取和通信开销的比例都会变化，应当用实际负载测量。

产品侧也有两种不同体验：首字等多久，以及开始回答后每个字出来多快。如果只报整机每秒生成多少词元，可能掩盖部分请求长时间排队的问题。

先把权重和会话缓存分开

模型权重是已经训练好的参数，多个请求可以共用；KV缓存保存各请求的注意力历史状态，通常随上下文和同时活跃的请求数增加。除此之外，显存还需要给激活、运行工作区和分配器预留空间。

因此，“模型权重放得进显存”和“服务能稳定承载目标并发”不是同一个验收结果。一个系统可以顺利加载模型，却在长请求集中到达时出现排队、缓存回收或容量不足。

Hugging Face文档给出的常规缓存张量，包含批量、头数、序列长度和每头维度。对标准全注意力、未压缩键值缓存，可以据此推导容量；滑动窗口、潜变量缓存或特殊实现需要另算。来源：Hugging Face缓存说明。

一组能自己按计算器的容量例子

假设某个教学模型有32层，采用8个KV头，每头维度128，每个缓存元素占2字节。这里的8是KV头数，不能拿查询头数替代；以下也没有声称对应某款商业模型的实测配置。

每个词元所需缓存为：2 × 32 × 8 × 128 × 2 = 131072字节，即128 KiB。开头的2来自键和值两份张量，最后的2来自每元素字节数。

表中使用二进制单位，1 GiB等于2的30次方字节；上下文长度包括已经保留的输入与输出历史。假设所有序列等长、没有跨请求共享，也不含权重、工作区、碎片和多卡分片影响。

这组计算说明的是放大机制：长上下文和高并发相乘，可能比参数量更早推高服务的显存需求。它不能证明一张标称141GB的GPU在所有场景都装不下，也不能把GiB与厂商GB规格直接混为一谈。

容量紧张和带宽紧张，要用不同办法治

容量决定同时保留多少状态；带宽决定一定时间能搬动多少数据。如果请求还没占满显存就已经生成缓慢，盲目加大可用容量未必解决问题；如果频繁因为缓存不足而排队，更大的缓存预算又可能直接改善并发承载。

工程排查可以先做两组控制实验：固定并发、逐步增加输入长度；再固定输入长度、逐步增加并发。观察显存占用、首字延迟、逐词延迟与吞吐量如何一起变化，而不是只看单个利用率数字。

还要记录长度分布，而不仅是平均长度。少量超长请求可能改变队列尾部体验，平均吞吐看似很好，交互用户仍会感到系统卡顿。

缓存优化有几条路，不能混成一个百分比

第一类是减少管理浪费。PagedAttention论文处理动态缓存分配中的碎片和重复占用问题；其意义在于更有效地使用已有内存，并非把模型理论上的每词元缓存凭空消除。来源：PagedAttention原论文。

第二类是改变缓存结构。GQA减少需要独立保存的KV头数；DeepSeek-V2采用MLA压缩缓存表示，论文给出的缓存降幅比较对象是DeepSeek 67B，不能当作所有模型都可直接获得的通用收益。来源：DeepSeek-V2原论文。

第三类是复用和精度调整。可复用的公共前缀能减少重复工作，但命中率取决于请求是否真的共享前缀；降低缓存精度需要验证质量与实现支持，不能只对照显存占用就宣布优化成功。

这些方法还会相互影响。缓存更省之后，服务可能选择承接更大并发，最终总显存占用并不下降；真正改善的是同一预算下能满足要求的请求数量。

缓存读取便宜九成，不等于总账单降九成

以2026年9月17日读取的Anthropic官方价格表为例，Sonnet 4.6标准输入为每百万词元3美元，5分钟缓存写入3.75美元，命中读取0.30美元，输出15美元。这里“便宜九成”比较的是命中读取与普通输入两项单价。来源：Anthropic官方定价。

做一个理想化账单例子：同一段10万词元前缀，在缓存有效期内请求10次，第一次写入，后面9次全部命中。只计算这段前缀，无缓存是3美元，有缓存是0.375＋9×0.03＝0.645美元，节省78.5%。

这还没有计入每次新增输入、输出、未命中或其他服务费用。输出越多，前缀节省在总账单中的比例越小；这个例子更不能用来反推服务商的GPU成本降低了多少。

互连是否值钱，取决于系统有没有在等它

把prefill与decode分到不同资源池，有机会分别匹配计算与生成需求，但也增加了KV状态传输和调度协调。DistServe研究同时考虑首字、逐词延迟要求与集群带宽，说明这种拆分需要联合优化，不能只看到“分离”两个字就判断必然省钱。来源：DistServe原论文。

对一个能在少量GPU上高效运行的服务，升级大规模互连不一定优先。对需要跨设备通信或传输大量缓存的服务，则应测量通信等待时间、有效带宽和拥塞，确认它是不是实际瓶颈。

采购和架构决策最终要回到同一个口径：在相同模型、质量要求、输入输出长度分布与延迟目标下，每单位成本能完成多少合格请求。只比较峰值算力、显存容量或网络标称带宽，都不足以回答这个问题。

验证清单是：先固定负载，再记录缓存占用与命中率，同时测首字延迟、逐词延迟、吞吐和尾部延迟，最后算合格请求成本。 如果优化后只是平均吞吐更高、用户等待却更久，就不能直接宣称服务效率改善。

把“瓶颈”与“成本占比”分开讨论

一个环节限制了性能，并不意味着它在采购账单上占比最高。网络等待可能让昂贵GPU闲置，此时解决通信瓶颈的价值很大，但不能据此宣称网络已经成为整套系统最主要的支出。

同理，缓存不足导致并发受限，说明当前资源配置约束了服务能力；要进一步判断显存相关成本是否成为重心，还需要硬件报价、折旧年限、租赁价格、利用率和运维费用等数据。公开产品规格并没有提供这张完整的账单。

因此，本文能支持的是条件判断：长上下文、高并发或特定多卡架构下，缓存容量、带宽及通信可能更早限制服务。本文不将其提升为全行业成本结构已经发生某种固定变化的结论。

一张可用于评测的成本表

对自建服务，可以先计算一定观测期内的资源与运行总成本，再除以满足质量和延迟要求的请求数量。若以每百万词元为单位，则必须说明输入输出比例和模型分词方式，否则跨任务、跨模型数字未必可比。

对API使用方，应另算缓存写入、命中读取、普通输入、输出和附加服务的费用。API账单可用于采购比较，但还混合了服务商定价策略，不能直接反解其基础设施成本。

以文章前面的缓存示例为例，高复用率让一段长前缀的成本下降，但如果后续任务需要更长输出，总账单未必按同样比例变化。比较两种方案时，应保持任务成功标准一致，而不是只拿其中最优惠的计费项比较。

测试应该怎样设计，才能找到反例

先建立短输入短输出、长输入短输出、短输入长输出、长输入长输出四组负载。在每组内部逐步增加活跃请求数，观察系统从低负载到饱和的过程，避免只报告最容易获得漂亮数字的一个点。

测试缓存复用时，再分别构造高重复前缀与低重复前缀两类请求。若优化只在高度重复的输入下有效，应把这个条件写进结论，不能将其泛化为所有交互任务的降本幅度。

对量化或压缩方案，要加入与业务相关的质量任务。显存节省很容易计量，但如果长文档中的关键事实丢失、答案准确性下降，节省的资源可能被人工复核和重试抵消。

对多卡与分离式架构，要记录数据实际流经哪些链路。设备内部、同一机柜以及跨服务器的通信条件不同，不能把某一级互连的标称数字当成整个部署路径上的保证值。

最后观察尾部请求。平均延迟下降并不保证最慢的一部分请求变好；面向交互服务时，应同时报告分位延迟、超时比例与拥塞持续时间。只有在预先声明的服务目标下统计，优化收益才有可比较的意义。

如果提高批量后吞吐上升、逐词延迟却超过用户可以接受的范围，这个结果应写成吞吐与延迟的取舍。如果更换架构后缓存需求明显降低，则原先依据缓存规模推导的硬件需求也应下调，而不能保留旧需求结论只引用新的性能成绩。

这种评测方式也给产业研究提供了约束：在没有实际成本分解和代表性负载数据之前，不能从一项缓存技术或某台设备的规格，直接推导HBM、先进封装或网络设备的确定性收入增量。需要把技术指标、采购决策和商业兑现逐步连起来。

本文的容量和价格计算均为明示假设下的教学测算，不是产品性能测试或服务商成本披露。本文不构成投资建议。