大模型时代的新roofline

作者：mackler

地址：https://zhuanlan.zhihu.com/p/2029981166191780212

经授权发布，如需转载请联系原作者

最近大模型推理需求已经到了爆炸式增长阶段，推理infra的重要性不言而喻，memory bound、compute bound的分析也让现在infra层面乐此不彼地折腾各种PD分离、AF分离的各种异构方案，芯片层面同样乐此不彼地折腾prefill芯片、attention芯片和ffn芯片。不过memory bound、compute bound的划分实际上还是经典计算访存比的roofline视角划分。

今天其实还有一个日渐变得重要的视角，是显存的容量带宽比。

memory bound通常指的是memory bandwidth bound，与之对应的是memory capacity bound。只是在大模型之前的整个计算机发展历史上，memory capacity bound几乎不会发生。过去这么多年一直都处于内存假设无限大，影响性能的往往是访存带宽和计算性能，因此经典的roofline都是讨论计算访存比。大模型实在是有史以来第一个顶着显存容量极限来发展的应用，实际上bandwidth bound和capacity bound在今天的大模型推理系统里起着结构性的作用。

大模型推理系统由于涉及权重和kvcache两部分容量需求巨大的组成部分，而这两部分存储在推理计算的过程中又要被大量读取，而推理decode又是对计算时间及其苛刻的要求。因此在有限的时间内，存多少读多少就变得至关重要。

大模型的稀疏化和slo诉求

会深刻影响应用的固有容量带宽比

无论权重还是kvcache，在特定场景下，如果存1份，稀疏读是n，读1/n，每秒钟需要读取m次，那么必要的带宽就是m/n。如果单个设备容量虽然大，能存的下，但带宽不足，也就不能在slo时间内读完，此时只能少存点，把其他部分存到其他设备上，利用多卡加起来更高的带宽来满足slo的要求，此时就是容量过剩，bandwidth bound。反过来，如果存储容量太小导致需要多卡分布式存放，此时整个系统被动享有多张卡加起来更高的带宽，此时带宽过剩，capacity bound，如果每张卡容量大一点，就可以少用几张卡，仍然能达成slo要求。因此在给定稀疏度和slo要求的情况下，应用的容量带宽比需求属于固有属性。

因此，所谓capacity bound和bandwidth bound并不是绝对的容量不足，或者绝对的带宽不足，今天大模型分布式信手拈来的情况下，绝对值不足基本都可以加卡解决，所谓bound都是比例的问题。

而带宽容量比是存储介质的固有属性，一个内存基本颗粒具有多大的容量和多少带宽通常是固定的，和roofline类似，只要对比显存的带宽容量比，和应用固有的带宽容量比（姑且叫做访存强度，参考计算访存比的计算强度）进行对比，即可得到第一性原理的capacity bound还是bandwidth bound的结论。

容量带宽比的选择深刻影响着

今天推理系统的成本

在大模型这种贴着显存容量极限的应用下，今天memory的成本已经成为任何一个大模型计算系统成本结构中绝对意义上的大头。而memory选型众多，无数ai芯片公司也正是在算各种$/GB或者$/GBps来精挑细选最具性价比的方案。而存储行业的基本规律显然是要容量性价比就没有带宽性价比，反过来要带宽性价比也就没有容量性价比。

原因很简单，同时具有容量性价比和带宽性价比的存储介质会淘汰掉所有同时不如它的容量性价比和带宽性价比的介质，剩下的一定要么容量性价比更高，要么带宽性价比更高

因此，把$/token推导成单一的$/GBps或者$/GB都是片面的，因为有容量带宽比的roofline。$/GBps最优往往直接撞上capacity bound，导致有效带宽锐减，从而造成有效的$/GBps急剧降低。

今天数据中心的agentic推理

已经逐渐滑向严重的

memory capacity bound

去年deepseek震撼的DeepEP实现了token成本的大幅度下降，把大模型ffn推向了计算bound，在集群层面实现了很高的均摊单卡并发。

但这是基于平均每个并发4k上下文的假设，这是chatbot场景的假设，而今天agent场景，这个假设已经完全不成立了，给openclaw或者claude code发个“你好”都有接近10k上下文。在agent场景下，人均几十k甚至上百k上下文才是常态。即使按照mla压缩过的kvcache存储，100k左右的上下文差不多要10GB级别的kvcache，一张141GB的计算卡，也就只能支持14个并发度，token成本显然会急剧飙升。

因此，从降本的角度。稀疏attention和混合注意力，一个降低带宽容量比，一个降低kvcache容量需求，才有机会把成本一定程度拉回来一些。

例如deepseek v3.2和glm5.x使用的dsa（稀疏attention），用1/10大小的稠密index cache辅助kvcache做到几乎稀疏到可以忽略不计的固定2k的稀疏度，如果把index cache和kvcache放在一起看，差不多就是1/10的稀疏度，如果把index cache和kvcache分开看，index cache仍然是稠密的，而kvcache的稀疏度已经到了访存强度可以把PCIe offload作为一个选项的临界点。

最合适的带宽容量比是什么？

这个事情没有一个终极答案，但大的趋势可以从几个第一性原理的需求推出。

推动带宽容量比提高的因素包括更强的slo需求，推动带宽容量比降低的因素包括稀疏化，这些都是具体细节层面的需求，细节层面的需求还是最终还是要回到更加第一性原理的需求上来判断。

大模型最重要的还是体验和成本

智能体验 > 成本 > 速度体验

其中智能的体验比成本更重要，没有人喜欢用笨的模型，笨的模型价值很容易归零，再便宜也不值。但反过来价格太贵，只要模型足够聪明，体验和价值到位了咬咬牙还是能上的。今天的模型能力和体验仍然有巨大的提升空间，体验的提升仍然会是AI最重要的叙事。

模型的智能体验很大程度来自更强的模型以及更长的高质量上下文，这两部分也分别锚定了今天对显存需求最极端的权重和kvcache。

稀疏化是不影响模型质量的有效降本手段，也会推动模型带宽比的下降

稀疏化本质上是用更大的容量需求换更少的带宽和算力需求，从而不需要牺牲算力。在今天基准的显存介质都是偏向于高带宽容量比的昂贵介质的情况下，稀疏化也能额外带来显存大幅度降本的巨大空间。

而速度体验的需求会进一步拉高token的成本，也会反过来推动模型容量带宽比的提升。

今天agent把decode的slo要求提高到50tps以上，因为人不再需要阅读agent的输出，更快完成任务成为了速度体验的一部分。

那我们需不需要为高得多的tps付出高得多的token成本呢？

今天agent层面其实面临工具调用时间逐渐超过token处理时间的情况，从提高agent完成时间的体验上来讲，单纯提高tps的边际收益会无限归零，但推高带宽容量比产生的硬件系统成本则会指数级飙升。

同时，agent层面提速除了单纯提高单个session执行效率外，用agent把任务拆解成大量并行的session，用agent集群并行解决问题的空间仍然非常巨大，也能平等地扩展token效率和工具调用效率。毕竟即使可以加钱改善串行token的效率，也很难加钱改善工具调用的串行效率，但并行可以。

这些趋势实际上最终大体上会推动着带宽容量比更低的方向演进。而今天很多芯片设计在pd分离和经典roofline模糊的memory bound指引下，走向了memory bandwidth优先，实际上会造成严重的memory capacity bound。

其实在agent爆发之后，去年deepep爆火时候尚不严重的capacity bound在今天hbm为核心的GPU算力上已经成为显著的问题。

包括因为NV收购groq并产品化而倍受关注的lpu，由于绝对容量也确实太小了，capacity bound尤其显著，导致在今天nv关于lpu的故事里，极其扯淡地把lpu这个以带宽为核心优势的芯片放在了甚至不memory bandwidth bound的moe层，感觉也是没有办法硬上了。

pd分离也好，af分离也好，主要还是在经典roofline下计算访存比等差异化带来的异构计算芯片的玩法，实际上如果站着带宽容量比的roofline视角下去拆分，仍然有巨大的异构存储芯片的玩法，前面提到的index cache和kvcache的异构化也算是算法infra和系统协同方式，实际上类似lpu这一类的结构作为在容量带宽比视角下也有局部发挥价值的空间，但远不是今天无论是简单memory bound或者nv奇葩的ffn用法。

当然大的趋势上，大模型推理系统逐渐走向带宽容量比更低的方向，实际上也走进存储产业更甜点的成本区间，也能给大模型产业带来一个更加普惠的可能性。

END

✦

2026中国AI智能体大会

✦

智猩猩主办的2026中国AI智能体大会7月2-3日杭州举行，大会设有开幕式，企业级AI智能体、AI智能体产品创新2场论坛，以及Coding Agent、自进化智能体、深度研究智能体、Computer-Use Agent、多智能体协同、Agent Skills、Agent Harness7场技术研讨会。天津大学郝建业教授，复旦肖仰华教授，阿里巴巴通义实验室算法专家李晨亮，腾讯Frontier团队专家研究员王琰，美团通用Agent团队负责人顾奇将出席演讲。

点击下方名片即刻关注我们