为什么大模型推理的真正瓶颈,不是算力,而是“搬运记忆”
Hatched by Kevin Di
May 04, 2026
1 min read
7 views
87%
先问一个反直觉的问题
如果一台芯片的算力翻倍,但它访问记忆的方式没有改变,它真的会更快吗?在大模型推理里,这个问题比听起来更重要。很多人直觉上会以为,模型越大,芯片越强,速度就越取决于每秒能做多少次乘法;但真正卡住系统的,往往不是“算”,而是把过去的信息及时拿出来。
大模型生成文本时,看上去像是在做连续思考,实际上却是一种极其机械的循环:读入一个 token,更新状态,预测下一个 token,再重复。这个循环有一个残酷的事实,它无法并行化成无限快的“整段生成”,因为每个下一步都依赖前一步。于是,推理速度不再只是一个“计算密度”问题,而变成了一个记忆组织问题。
这也是为什么今天围绕推理芯片的竞争,正在从“谁的峰值算力更高”转向“谁能更便宜、更快地把模型需要的上下文喂给计算单元”。换句话说,真正的战场不是 FLOPS,而是记忆带宽、片上存储和数据移动成本。
在大模型推理里,速度不是把数学做得更快,而是把答案材料送到数学面前的速度。
大模型推理的本质,不是思考,而是访问历史
要理解这个问题,先把语言模型想成一个函数:它接收当前 token,输出词表里每个 token 的概率分布,然后采样出下一个 token。这个过程一轮只产出一个 token,所以它天然是串行的。模型不能像做矩阵乘法那样,把整段未来一次性算完,因为未来每个 token 都取决于前面已经生成的内容。
更关键的是,模型每一步都要“回看”之前所有 token 的内部状态。这个历史被存进 KV cache,也就是每个历史位置对应一组 Key 和 Value 向量。当前 token 会生成一个 Query 向量,然后和所有历史位置的 Key 做点积,再把得到的权重作用到历史 Value 上,形成新的表示。
这意味着,推理的每一步都像在一家超大图书馆里找书,不是因为书写得难,而是因为你每次都要把旧书重新调出来。模型越长上下文,图书馆越大,找书的成本越高。于是,一个看似“语言理解”的任务,悄悄变成了一场围绕历史状态的物流战。
可以把它想成一家餐厅后厨。烹饪本身固然重要,但如果厨师每做一道菜,都要跑到仓库最深处取一次调料,那厨房再强也会慢。大模型推理也是如此:真正贵的不是算,而是反复去仓库拿料。
为什么“更高算力”常常救不了推理速度
这就引出了一个长期被误解的地方。我们总容易把芯片性能理解成“谁的峰值更高,谁就更快”。但在推理场景里,尤其是大模型解码阶段,芯片往往被内存访问和数据搬运限制住,而不是被纯计算限制住。
原因很简单。矩阵乘法确实重要,但它通常可以被做得很快,尤其在专门的矩阵单元上。真正拖慢流程的是,模型每次都要读取大量历史 Key 和 Value,而这些数据通常不在最靠近计算单元的地方。只要数据必须跨越芯片内部或芯片外部的距离,延迟和能耗就会迅速上升。
这就是为什么片上 SRAM 变得如此珍贵。SRAM 越多,能装下的历史状态越多,越少需要访问慢得多的外部 DRAM。对推理芯片来说,这不是一个小优化,而是一个结构性杠杆。因为在 AI 芯片中,DRAM 访问常常是最贵的延迟和能耗瓶颈。
很多基准测试会让人误以为,只要某芯片在“性能模式”下能跑出惊艳数字,就能在真实部署中稳赢。但真实世界更苛刻。客户关心的不是峰值时刻的漂亮数字,而是长期运行下的每 token 成本、吞吐稳定性和部署约束。一个架构如果在实验室里很猛,但需要极端条件才能成立,它就未必适合生产环境。
这里的核心张力在于:推理不是单次算得快,而是连续地、稳定地、经济地算得快。一辆赛车的极速再高,如果油箱太小、进站太频繁,也很难赢完整场比赛。推理芯片也是同样道理。
PIM 为什么会让人兴奋:把仓库搬到厨房旁边
数字内存中处理,简称 PIM,本质上是在改造这套物流系统。传统芯片像是在中央厨房里做全部运算,然后再去远处仓库取食材。PIM 的思路则更激进:把一部分计算放到内存附近,甚至直接放进内存结构里。这样一来,数据不用反复穿越长距离路径,很多计算可以在“数据所在之处”完成。
这件事的意义不是抽象的,而是很物理。芯片面积是有限的。如果你把更多面积花在大寄存器、ALU 和复杂的数据通路上,就会挤压掉 SRAM。反过来,如果你削减不必要的数据搬运与控制开销,就能把更多面积留给片上存储。片上存储一多,访问 DRAM 的次数就少,延迟和能耗就会下降。
因此,PIM 的吸引力并不只是“更新颖”,而是它在结构上正面对抗推理的根本瓶颈。它不是试图把算术做得更华丽,而是试图让计算和记忆之间的距离缩短。这就像把仓库搬到厨房门口,甚至让调料直接长在灶台边上。
不过,兴奋不等于胜利。新架构往往有一个诱人的幻觉:实验室里峰值很高,海报上数字很好看,于是人们以为商业化自然会跟上。但现实中,最难的部分恰恰不是发明,而是在真实约束下保持这些优势。如果一个架构的优势只能在特定模式下成立,一旦进入部署就迅速缩水,那它的经济价值就会被大幅折扣。
这提示我们一个更深层的判断标准:对于推理芯片,不能只问“它快不快”,而要问“它快的原因,是否正好击中持续成本最大的那一层”。如果快来自边角优化,它可能只是暂时领先;如果快来自消灭系统性瓶颈,它才可能真正改变格局。
真正的分水岭:从“算力思维”转向“数据重力思维”
大模型时代最值得更新的一条认知,是我们应该用数据重力思维替代纯粹的算力思维。所谓数据重力,就是数据会因为体积、位置和访问频率而产生“重量”,把整个系统拖向更慢、更贵的路径。模型越大,KV cache 越庞大,历史状态越沉重,重力越强。
在这种视角下,推理系统的设计目标就不再只是“算得更快”,而是“让数据少移动、让热点数据更近、让历史状态更容易被复用”。这会直接改变架构选择、内存层级设计,甚至软件栈的调度方式。
我们可以把它总结成一个简单但很有用的框架:推理性能 = 计算速度 × 数据就地率 × 访问稳定性。只看计算速度,就像只看发动机马力,不看变速箱和轮胎。真正跑得快的系统,往往不是马力最高的,而是每一个环节都没有明显短板的系统。
这个框架也解释了为什么不同芯片路线会呈现出不同的商业结果。有些方案更擅长把峰值做高,有些则更擅长把单位成本压低。对于训练来说,计算能力可能更占主导;但对于推理,尤其是在线服务推理,每 token 成本和延迟一致性可能比峰值更重要。客户不会为一块偶尔跑得很快、平时却不稳定的芯片长期买单。
于是,推理芯片的竞争最终不是“谁更像超级计算机”,而是“谁更像高效的物流系统”。这听起来不够浪漫,但它更接近现实。
当模型变大,最先逼近极限的常常不是数学本身,而是把历史带到当前这一刻的能力。
可以立即应用的几个判断标准
如果你正在评估 AI 推理芯片、云服务方案,或者只是想更准确地理解这场技术变革,可以用下面这几个问题过滤掉大量噪音。
1. 它优化的是计算,还是数据移动?
如果一项优化只提升矩阵运算峰值,却没有显著减少内存访问次数,那它对真实推理收益可能有限。优先看它是否降低了对外部 DRAM 的依赖。
2. 它的性能是在什么模式下测出来的?
很多漂亮数字只在理想模式下成立。要追问它是否能在真实部署条件下维持吞吐和延迟,尤其是在长上下文、高并发、持续运行时。
3. 片上存储有多大,够不够装下“热历史”?
推理里最宝贵的不是原始算力,而是能否把最常访问的 KV cache 留在更近的位置。片上 SRAM 越大,系统越不依赖慢内存。
4. 它的优势是否来自结构性瓶颈的消除?
如果优势来自一个局部技巧,可能很快被追平。如果优势来自架构层面对数据路径的重构,护城河会更深。
5. 你是在为峰值付费,还是为稳定的每 token 成本付费?
商业部署最在意的是长期账单,而不是单次演示。真正值钱的是持续低成本地产生 token,而不是偶尔刷出惊人数字。
Key Takeaways
-
大模型推理的核心瓶颈往往不是算力,而是数据搬运。 每生成一个 token,都要访问历史状态,KV cache 让“记忆”成为性能关键。
-
片上 SRAM 比峰值 FLOPS 更接近真实竞争力。 更多片上存储意味着更少 DRAM 访问,而 DRAM 通常是延迟和能耗的大头。
-
PIM 的真正价值在于缩短计算与记忆之间的距离。 它不是单纯让算术更快,而是重构数据路径,让计算更接近数据。
-
评估推理芯片时,要看真实部署条件,而不是实验室峰值。 许多性能数字只在特定模式下成立,商业价值取决于是否能稳定复制。
-
把“算力思维”升级为“数据重力思维”。 未来系统的胜负,越来越取决于谁能让数据少移动、让热数据更近、让历史状态更容易复用。
结尾:我们其实不是在让机器更会算,而是在让机器更会记
大模型时代带来的最大认知变化之一,是我们终于开始看清:智能系统的瓶颈,不只在思考本身,更在记忆如何被组织、存放和调用。推理速度之争看似是芯片之争,实则是记忆架构之争。谁能把历史状态放得更近、调得更快、搬得更少,谁就更可能在真实世界里占据优势。
这会彻底改变我们看待“更快”的方式。更快不再只是更大的算力数字,而是更聪明的数据路径,更少的无效移动,更低的访问代价。未来真正优秀的 AI 基础设施,未必是最喧哗的那种,但一定是最懂得尊重物理限制的那种。
所以,下次当你看到一个推理芯片的宣传数字时,不妨先问一句:它到底是在做更强的计算,还是在做更少的搬运?很多时候,答案会决定这项技术究竟是未来,还是只是一个漂亮的演示。
Sources
Hatch New Ideas with Glasp AI 🐣
Glasp AI allows you to hatch new ideas based on your curated content. Let's curate and create with Glasp AI :)
Start Hatching 🐣