推理为什么总卡顿？前谷歌 TPU 架构师拆解：算力之外，显存带宽、KV Cache 与并发才是关键

导语：算力堆满仍卡顿？前谷歌 TPU 架构师拆解推理瓶颈的真实原因。

在大模型应用里，“为什么我多付钱，响应就更快？”“为什么硬件越强，单个用户还是会卡？”这些问题看似属于产品体验，背后却是非常硬核的工程约束。前谷歌 TPU 架构师、MatX 创始人 Reiner Pope 在一次深度访谈中，把大模型推理的速度、成本与系统调度逻辑讲得非常透彻：很多时候，推理卡顿并不是算力不够，而是显存带宽、批处理方式和上下文缓存把系统“锁死”了。

一、更贵的 API，为什么通常更快？

访谈一开始就讨论了一个很现实的问题：为什么像 Claude、Codex、Cursor 这类平台会提供“快速模式”，而且用户愿意支付更高的费用？Reiner Pope 的解释很直接——本质上，这是在买更低的并发、更小的批处理，以及更少的排队等待。

根据大模型推理基准平台的定义，Streaming speed 指的是每个并发用户的解码 Token 生成率，也就是文本或代码在屏幕上“冒出来”的速度。所谓“快速模式”，通常意味着服务商把同一时间服务的用户数减少，让单个请求更快被处理。

• 用户支付更高费用，换来更低排队延迟。
• 服务商牺牲并发，换取更好的单用户体验。
• 这种模式在体验上更好，但在经济上并不划算。

Reiner Pope 指出，低并发模式会让硬件利用率急剧下降，甚至比高并发打包处理时差上几百倍到上千倍。也就是说，用户看到的是“更快”，服务商看到的却是“更贵”。

二、推理速度的真正上限，不是 FLOPS，而是显存带宽

很多人直觉上会认为：芯片算力越强，推理就越快。但在低并发的自回归生成场景里，真正的瓶颈往往不是浮点计算，而是显存带宽。

原因在于，自回归生成是逐 Token 输出的。模型每生成一个新 Token，都要读取一遍参数，并结合已有上下文继续计算。对于单个请求来说，单次计算量其实并不大，真正耗时的是把模型权重从显存里不断读出来的过程。换句话说，当系统没有足够并发去摊薄成本时，速度上限就被“读内存”的速度锁住了。

Reiner Pope 用 Roofline 模型解释了这一点：推理总延迟的下界，由计算耗时和访存耗时中更慢的那个决定。只要模型在某个阶段处于“计算很轻、读内存很重”的状态，那么即使你继续堆更多算力，单用户响应也不会有明显改善。

图中推导的核心结论可以概括为一句话：当单次生成的运算量不足以把计算单元“喂饱”时，整个系统的速度主要受显存带宽限制，而不是受芯片峰值算力限制。

三、为什么“堆算力”仍然消不掉推理卡顿？

这也是很多人对大模型基础设施的误解所在。大家看到 GPU、TPU 数量增加，就会默认延迟一定下降。但如果请求是单用户、低批处理，算力再多也只是“闲着”。因为系统真正需要的是把大量请求合并起来，让同一轮权重读取服务尽可能多的用户，从而摊薄那次读取权重的固定成本。

Reiner Pope 在访谈中给出一个非常形象的结论：如果不通过高并发去分摊单次读取模型权重的刚性耗时，系统经济效率会比打包处理时差出巨大数量级。推演显示，一个理想的平衡点大约与模型的稀疏比例相关，接近“300 乘以稀疏比例”的数量级。

这背后反映的是数据中心的调度逻辑：服务商必须持续提高并发，直到系统处在计算与访存相对平衡的最优点。低于这个点，硬件闲置；高于这个点，延迟上升，但吞吐和成本效率更优。

四、为什么输入阶段和输出阶段，价格逻辑完全不同？

Reiner Pope 还特别解释了大模型服务中一个常见现象：同样是处理 Token，输入和输出的成本并不一样。原因是两者的计算形态完全不同。

1. 输入提示词预处理：更像并行矩阵计算

在输入阶段，系统主要处理用户提交的提示词。这个过程可以被高度并行化，矩阵运算占比较高，硬件更容易吃满。因此，输入阶段的单位成本通常更低，效率也更高。

2. 输出逐字生成：更像显存驱动的串行过程

而在输出阶段，模型是一个 Token 一个 Token 地往外吐。每一步都要结合上下文重新读取状态，依赖显存带宽，因此更容易进入瓶颈区。这就是为什么很多服务会把“输入价”和“输出价”分开定价，或者对输出 Token 设定更高的费率。

从系统角度看，这不是营销策略，而是硬件利用方式不同带来的必然结果。

五、长上下文为什么越来越贵？KV Cache 才是大头

随着对话轮次变多、上下文越来越长，另一个瓶颈就出现了：KV Cache。它保存了历史上下文的键值缓存，方便模型在后续生成时快速回看过去内容。但问题是，这部分缓存会迅速占满高带宽内存（HBM），让系统的存储层级压力越来越大。

Reiner Pope 提到了一个很关键的物理基准：不同存储介质的“排空时间”差异极大。也就是，如果按总容量除以读写带宽来估算数据能停留多久，不同层级的介质差别非常夸张。

• HBM 的排空时间约为 20 毫秒。
• 主机 DDR 内存约为 1 到 10 秒。
• Flash 闪存约为 1 分钟。

这意味着，系统不能把所有上下文都长期堆在最昂贵、最快的 HBM 里，否则成本会迅速失控。更合理的做法，是把长时间不活跃的上下文向下疏散到更便宜的内存或闪存层级，用存储分级来对冲 HBM 的高昂占用成本。

这也是为什么某些厂商会对超长上下文收取更高费用。上下文一旦拉长到某个阈值，读取 KV Cache 的时间就可能超过计算权重的时间，系统重新陷入访存瓶颈。访谈中提到，以 Gemini 3.1 为例，当上下文超过 20 万 Token 时，价格会出现明显上浮，幅度约 50%。

换句话说，长上下文的成本并不是“多记一点内容”这么简单，而是缓存、带宽、存储层级和调度策略共同作用的结果。

六、稀疏模型为什么“算得快，却传得慢”

在讨论混合专家模型（MoE）时，Reiner Pope 提到了另一个大模型系统设计中的经典矛盾：模型越稀疏，计算越省；但模型越大，跨卡通信越难。

以 DeepSeek V3 等稀疏架构为例，它每次只激活少部分参数，因此单次推理的计算量明显降低。但问题在于，模型总参数量依然很大，很多模块无法塞进单卡，只能跨 GPU、跨服务器放置。这样一来，Token 动态“路由”到不同专家时，就会产生大量跨节点传输。

于是出现了一个非常典型的工程困境：

• 本地看，稀疏激活让计算很轻。
• 系统看，跨卡通信和路由开销却非常重。
• 模型越大，通信墙越容易吞噬稀疏带来的收益。

这就是为什么“只看参数规模”并不能判断一个 MoE 架构是否高效。真正决定性能的，是它能否把专家尽量放在同一个扩展域里，减少跨节点搬运。

七、为什么 Pipeline Parallelism 并不总是灵药？

当单节点显存容量已经到达极限时，很多人第一反应是做流水线并行，把模型切分到多个卡、多个服务器上按阶段运行。但 Reiner Pope 的观点提醒我们：这种方法并不总能解决问题，甚至有时候只是把瓶颈从计算搬到了通信。

原因很简单：流水线并行依赖多个阶段串接，虽然能让模型“装下去”，但每一层切分都会增加同步、转发和等待。如果 Token 路由本身就很复杂，再叠加跨节点传输，通信墙会让原本希望获得的收益大打折扣。

尤其在稀疏模型里，专家分布不均、激活路径动态变化，导致系统不只是“切开”这么简单，而是还要处理路由一致性、数据对齐以及跨机房延迟等一系列问题。结果就是：模型虽然更大了，理论吞吐也可能更高，但实际体验未必更顺滑。

八、这场访谈给大模型行业的三个启示

综合这次讨论，可以把 Reiner Pope 的核心观点浓缩为三条：

• 第一，推理速度不是单纯靠堆算力解决的。 单用户低并发场景下，显存带宽和访存效率往往比峰值算力更重要。
• 第二，成本结构决定产品定价。 输入、输出、长上下文之所以价格不同，本质上是硬件利用率和缓存占用不同。
• 第三，模型越大，系统工程越重要。 MoE、流水线并行、存储分级、调度策略，任何一项处理不好，都会让“理论上的快”变成“实际上的卡”。

从这个意义上说，大模型时代最稀缺的能力，已经不只是训练更强的模型，而是更聪明地组织算力、内存和通信。谁能更好地跨过显存带宽、KV Cache 和通信墙这三道坎，谁才更有可能把“快”和“便宜”同时做到位。