What kind of chip is needed for LLM inference?

Latest update time：2024-03-03

Reads：

????If you want to see each other often, please mark it as a star???? and add it to your collection~

Source : Content Observed by Semiconductor Industry (ID: i c bank ) Reposted from Zhihu blogger Mackler , thank you.

The world's fastest large model inference service launched by Groq can output 500 tokens per second. What do you think of this technology? The answer to this question is further extended. Instead of discussing groq itself, we will discuss the basic logic of chip and system architecture design under LLM reasoning requirements. Like previous articles, my views are generally quite radical, and I mainly hope to have clear views and collisions. Please read at your own discretion.

The requirements of LLM itself have been elaborated in the answer. The core needs to be considered are actually two parts: weight and KV-Cache corresponding to the context.

The weight part is completely consistent with the past NN, so I won’t go into details. It is a fixed size and carries the large model’s understanding of the world. It is static during reasoning. The KV-Cache corresponding to the context is a brand new part, which carries the dynamic weight of this user and the understanding of the context. Each user request is unique, and it is also the basis of LLM's unique meta-learning ability. This part It is something that traditional NN does not have. I wrote three years ago in Why Do You Think Full Artificial Intelligence is Achievable? I have written about the ways and possibilities of this dynamic weighting for implementing AGI.

At the tactical level, neural Turing machines are actually an idea with great potential. Human learning actually does not correspond to the training process of deep learning, but a small step of inference. A person's life is an inference process, obtaining input, extracting experience, then accepting new input, and quickly drawing conclusions based on the previously extracted experience. . "Experience" is actually similar to the weight in the attention mechanism. It is dynamically generated during the inference process and used to weight other data, while the neural Turing machine stores experience.

However, I overcomplicated the problem at the time and felt that the weight dynamically generated by this kind of attention needs to be managed as complex and delicate as a neural Turing machine to be able to be used. I didn’t expect that OpenAI relied on the belief that “Scaling is all you need” to combine the complex and delicate Algorithm management has become a simple algorithm like Self Attention + hardware violent stacking. It can be done by directly calculating the context relevance in O(n^2) way. There is no need for any fine structure to extract from the vast number of contexts. Relevant parts are carefully selected, so a large part of the problem of implementing AGI is simplified into the scaling problem of chip and system design. It becomes much simpler all of a sudden, and the chip industry is precisely the one with the best scaling skills among all human industrial systems. Damn it, it’s still my old profession. I don’t even dare to think to what extent AGI can be expanded once the context length is scaled.

Within ten years, the chip industry will be turned upside down.

I wrote a series of articles last year explaining the potential huge changes in the chip industry (mackler: A new decade of chip arms race), the impact on NV (mackler: NVIDIA’s flaws), and blind guesses about each company’s next move (mackler: Blind Guess NV’s next step, Mackler: Blind guess AMD’s next step), mainly emphasizes that memory bandwidth and interconnect bandwidth have become core competitiveness that exceeds the importance of computing power. There is already a certain industry consensus on this point . However, through the discussion of the groq issue, in fact, the more detailed trade-off logic is still relatively confusing in the industry.

The cost of Token is actually the cost of memory bandwidth. Strictly speaking, the memory here refers to the "full" storage medium that stores these weights and KV. It is not necessarily the most conventional DRAM memory. SRAM can also be used as memory like Groq. It completely depends on the chip and system design expectations. storage location.

The memory access characteristics of LLM are not complicated. The weight is shared by all tokens in all requests. It is also a fixed size of memory usage, usually in the order of 1GB~100GB, depending on the model scale. The memory usage of KV is related to the model. , is also proportional to the context length, and each request is independent. The more concurrent requests, the larger the storage KV needs to occupy. Today, the limit in the 100GB~1TB range is to achieve a context length of 100K. At this time, the concurrency is often single digits or even 1. This is very scary, because if the concurrency is increased by an order of magnitude, or the context length is increased by an order of magnitude, the required KV storage will also be directly increased by an order of magnitude, running towards 1TB~10TB. Today, the demand for improving context length is exponential to a certain extent.

Each request actually corresponds to a series of Token generation, and this series of Tokens is generated serially. The process of each Token generation requires the weight and the KV corresponding to the request to participate in the calculation. This memory access amount has nothing to do with the hardware architecture and is only related to the model and context length. How quickly the hardware can complete this memory access determines the lower limit of the time for Token generation.

Reuse is the prerequisite for all the bells and whistles. A system concurrently handles a large number of such requests at the same time. All tokens in the weight part of the memory access can be reused, while in the KV part only tokens of the same request are shared, but the generation of these tokens is serial and cannot be shared. So in fact, from the perspective of hardware and system design, there are only two types of bells and whistles:

Expand the degree of concurrency, increase the batch size, and allow tokens of different requests to reuse the weighted portion of the cache. However, more concurrent requests mean more corresponding KV storage occupancy, which further means that the proportion of KV storage occupancy will increase significantly, resulting in an actual decrease in the proportion of reusable weights, ultimately leading to a marginal reuse of weights. Earnings dropped sharply. After all, after forming a larger batch, although the weight reuse is increased, more KVs corresponding to this batch need to be read and processed together. In the end, the bulk of the KVs are read and cannot be reused.

Speculative execution, executes serial Tokens in the same request in parallel through prediction, and reuses the memory access of the KV part. This actually has a certain effect, but the prediction accuracy is far inferior to the CPU's branch prediction. After all, it is not a two-branch prediction but a 30,000-branch prediction (depending on the vocabulary size). It is good to be able to accurately predict 3 to 5 steps. The upper limit of reusability is only of this magnitude.

All other bells and whistles are close to the upper limit of this memory access amount, and the reusability of the conventional Memory Hierarchy to capture the locality of memory access is almost useless at this level. In the end, what the hardware competes for is the bandwidth cost of the memory medium that can fully put down all weights and concurrent requests for KV.

Token的质量取决于访存量。 其实Token/$这种指标欺骗性很大，毕竟Token和Token的差异太大了。本质上我们需要的是相同质量的Token的成本。Token生成的质量其实抛开纯算法层面的因素，主要是取决于参与计算的权重和参与计算的KV，分别对应模型对世界的静态认知以及对当前请求上下文的感受野，从芯片和系统设计的角度看，在一定的时间尺度内，算法的差异还是噪音，整体上Token质量还是取决于上述两部分对应的访存量。以Token/$作为芯片设计的优化指标很容易带进通过降低Token的访存量来降低Token/$的歧途。如果我们可以固定Token的访存量来作为Token的质量，从而滤掉算法对质量的影响，实际上完全可以以TBps/$作为更好的量化指标，也就是带宽成本。

当然反过来也简化了算法层面的花里胡哨对推理成本的影响，硬件的TBps/$固定的情况下，提高Token质量的方式就是更精细地利用访存量，让参与到Token计算的模型权重和KV更重要，除了量化压缩这些在质量和访存量上取平坦斜率的玄学外，这里面最显著的花里胡哨也就是稀疏化。

MOE算是稀疏化了权重，每个Token只访问了可能和这个请求更相关的权重，这样用更少的访存量就可以获得接近的权重质量，因为Token感受野里的世界理解以及上下文相关度更高。

KV的稀疏化未来大概率也会爆发，当上下文长度飙升到M甚至G量级的时候，只访问其中相关度更高的子集来减少访问量，其实一定程度类似于我最前面写的几年前对于神经图灵机这种精细化管理的理念。

稀疏化带来的影响是达到相同的模型质量，总的权重和KV存储量相比稠密模型会大幅度提升，同时每个Token访问量相比稠密模型会有所下降。那么对于芯片的需求就是更大的内存以及适当放缓了对于内存带宽成本的需求。当然如果稀疏度极速提升，一定程度也会对架构选择产生很多质变，例如稀疏度如果达到了2个数量级以上，并且不同权重和KV被请求到的频次呈现出显著的长尾和热点时，Memory Hierarchy可能又会重新派上用场。当然，目前距离这种状况还很遥远。

完全按内存带宽计价得出的结论往往很反直觉，但并没有什么问题。 因为半导体世界的存储介质基本都是带宽越高的容量越小（本质是因为容量又小带宽又小的废柴材料都被淘汰了，容量和带宽总得占一个），按照容量计价往往越高速越贵，但如果按照带宽计价有可能是反而是更便宜的，所以我们有一定动力选择传统意义上按容量计价更贵的介质。

很多人觉得hbm很贵，实际上hbm的带宽性价比很高，同样groq采用的sram很贵，但sram的带宽性价比更高，甚至我们极端一点用寄存器算带宽性价比，性价比简直起飞了，所以这一点上groq是没问题的，但问题出在容量上。

紧耦合的容量很重要。 我们首先要保证“全量”的权重和KV都能放进去。由于推理硬件的总吞吐是可以无限复制跑一个完整模型的最小单元，所以我们对“全量”的定义可以简单理解为完整部署一份模型所需的权重存储和对应并发度所占据的存储量。其实每个请求对应的kv访存量是没有那么夸张的，一般常见的百亿模型4k上下文也就是每个请求100MB~1GB这个量级，当然长上下文以及千亿模型肯定成比例起飞，提高一两个数量级轻轻松松，但无论如何百亿模型权重总归是10GB~100GB量级。因此一个请求跨越的访存至少会覆盖到100GB这个量级的存储介质。如果大量请求并发，kv数量急剧膨胀，这个最小单元的尺寸还需要再增加一个数量级。容量可以堆，但这个最小单元必须是紧耦合的。

我们本质上是要的100GB~1TB量级内存容量下的紧耦合系统的内存带宽性价比，当然这个紧耦合体系的容量需要随着算法发展以及长上下文的需求水涨船高。

而内存性价比高的小容量介质应对100GB~1TB量级的紧耦合内存容量需求，需要更高数量级的介质紧耦合地连到一起。

互联是耦合性的瓶颈。 本质上我们前面的讨论都是围绕一个巨大的统一内存讨论的，如果我们可以无限堆料，把内存带宽性价比高的介质用独立的内存通道挂到一个统一的巨大内存下，让一个中央的计算单元可以拿到全部这些带宽，上面所有高速介质都是最美妙的选择。但巨大的统一内存不难，CPU内存可以做到这个当量，但没有独立内存通道，带宽没有同步堆料，性价比就会急剧下滑，现实的系统往往只能退而求其次，寻求分布式计算下的内存堆料，类似NVidia的单机8卡，或者groq的500+芯片，cebras的单个wafer上的海量sram。

例如groq一个芯片sram是230MB+80TB/s，如果想把500+个这样的sram挂到一个统一的计算部件上，容量扩大到100+GB是没啥问题，但带宽也扩大到40PB/s几乎是不可能的，有这天顶星的技术还有啥memory wall呀，所以只能诉诸于分布式的计算部件。但实际上把500多个80TB/s带宽的节点连起来达到互联不瓶颈，对互联系统的挑战仍然是巨大的。

分布式场景下的互联要求取决于分布式并行的模式。infra层面经常讨论的pipeline并行、tensor并行、expert并行都有不同的适用范围和对互联的要求，进而由于现实的互联所能实现的带宽延迟，并行度永远不可能无限扩展，一定会限制在一定尺度内，甚至非常有限的尺度内。

Pipeline并行的优点在于对互联带宽要求不高，缺点是延迟巨大，而且需要相当多的用户请求来填满流水。因为实际上每个时间段服务一个请求的只有pipeline的一个stage所覆盖的内存带宽。本质上不利于groq去刷那个单用户500token/s的指标，但这是互联带宽太低，而sram太小导致并行尺度又得做得巨大无奈选择。实际上按照sram的容量带宽比，吞吐刷到几万都有可能。

Tensor并行的优点在于吞吐和延迟都很好，缺点是带宽要求很高。互联带宽的要求至少需要匹配单节点的内存带宽，否则节点内计算时间按照节点内的内存带宽计算，互联通信时间按照节点间的互联带宽计算。如果通信带宽远小于内存带宽，通信会直接成为新的bound。

这些是Infra层面在NVidia GPU的尺度找到的比较好的并行pattern，实际上还有更多的选择，只不过在这个尺度下效果太差就被淘汰了。

其他的还有类似数据流并行，吹数据流的人很多，和Pipeline并行也有些许关系，狭义的数据流本质上还是一种局部贪心策略，对硬件拓扑和带宽也缺乏感知。广义的数据流希望通过图编译找到全局最优策略，本质上是一种把编译器当万金油的惰性做法，深度学习框架在系统调度这种比较粗放的尺度围绕数据流做了这么多年的自动并行化，最后业界主流实际上的并行策略还是预设的这些Pipeline、Tensor并行的组合，而不是编译器搜出来的自动化的并行策略，一定程度也是一种印证。而如果面对的是颗粒度更细，延迟带宽更敏感的芯片内等场景，最后肯定瓶颈就是硬件互联了，当然可以甩锅给编译器。

互联的重点还是带宽。 和传统CPU的NoC对延迟有苛刻需求不同，LLM对互联系统的核心诉求还是带宽，本质上是为了把分散的内存带宽能够发挥出来，不要因为互联系统的带宽阻塞了内存带宽。

知乎上有很多做芯片的人吹dojo和tenstorrent那一类mesh互联，觉得对称性无与伦比，而且可以无限扩展铺满整个平面。但mesh根本不是个什么新东西，教科书上几十年的老黄历了。mesh在高带宽需求也是个相当糟糕的互联，除了物理走线短之外几乎一无是处，尤其在LLM这种带宽优先的场景下，连极其规整的集合通信都没法把宝贵的互联带宽资源打满。对称性也无从谈起，毕竟不是一个无穷大平面，边界和中央的流量是完全不均衡的，简直是并行策略的噩梦。

拓扑层面ring、torus、fat-tree、dragonfly等等都是对称性好得多的拓扑，对宝贵的物理带宽资源也都能更好地利用起来。对应的并行模式，Tensor并行也优于Pipeline并行进一步由于数据流并行的策略。

互联带宽层面，无论如何都逃不掉一个接近内存带宽级别的物理带宽。

所以事实上又和前面形成了一个反过来的取舍逻辑，高速低容量的存储介质具有更好的内存带宽性价比，但因为容量小了，要形成一个LLM可以运行的紧耦合体系，需要的分布式节点就更多了，而节点多，单节点带宽高，都对于互联系统的拓扑和带宽提出了极端的要求，实际上又反过来促使我们使用低速高容量的存储介质，因为可以用更少的节点达成LLM可以运行的紧耦合体系，同时单节点带宽又不是那么高，互联系统还是比较容易达成的。而且互联世界的光谱也是节点越多，空间尺度越大，带宽越小，带宽成本越高。

这种相反的取舍逻辑最终会达成一个平衡点。本质上取决于内存体系的带宽容量和成本的光谱与互联体系的带宽与成本的综合考量，这两个都是非常庞大的光谱，架构选择的空间非常宽泛。

但总体来讲，内存和互联这两个光谱有一些基本的交点：

同一个物理尺度下，局部的互联带宽上限通常还是小于内存带宽上限的。 这里“内存”同样是广义的，芯片内部的sram与芯片内部的互联、芯片间的互联和片外内存带宽等等。毕竟同一个物理尺度下如果计算节点之间的带宽都能飙起来了，计算节点和存储介质之间的带宽为啥不能也用这种技术飙起来呢？所以groq这种选择一个很尴尬的地方在于，内存带宽选择的sram是芯片内的尺度，而互联又不可避免走向更低速的芯片间、甚至板卡间、服务器间的尺度，互联自然远远跟不上内存带宽，从而把内存的优势打回原形。

进一步讲，100GB~1TB这个容量尺度的系统，互联大体上肯定是在芯片&板卡间这个级别的物理层的，那么内存大概率还是选择这个层级，也就是DRAM更合适，当然了，DRAM的形态光谱也非常宽，芯片&板卡间的互联光谱也非常宽。

互联带宽没有显著高于内存带宽时，任何网络拓扑都没法扩展到非常多节点的紧耦合。 简单来讲，如果没法达成互联带宽没有显著高于内存带宽时，分布式节点太多一定会造成带宽问题。NVidia创造的紧耦合系统目前主流的尺度是单机8卡，当然也做过16卡的形态。大力出奇迹的规格是256卡的GH200，但是对应的全局带宽堆得相当夸张，否则只是个松耦合系统，松耦合系统自然无所谓，现在的千卡互联万卡互联都是全局带宽收敛的，不在我们讨论范围，之前写过一篇mackler：AI云还是AI大型机？讨论过这个紧耦合系统的问题。这个并行尺度对于其他物理尺度下仍然适用。这个尺度对LLM芯片的影响实际上还是如何实现紧耦合的100GB~1TB这个量级。这个量级下紧耦合分布式的碎片化程度不能太高，如果搞到几百甚至上千的分布式，互联带宽根本做不上去。

这两个交点一定程度上能帮我们收敛出大致的量级范围。

单节点统一内存10~100GB量级，节点数量1~10量级，互联带宽接近单节点带宽的形态，此时系统的总内存带宽和总成本的比例越高越好。

在这个范围内，还是有大量空间的。当然了，毫无疑问，NVidia的诸多选择也在这个范围内，其实这是必然的，因为上面说的很多尺寸规模都是算法在英伟达的互联、容量、带宽规格下筛选出来的，毕竟今天NV的紧耦合节点就是DGX，所以LLM的紧耦合尺寸基本都在围绕在DGX的总显存带宽量级。而NV的DGX总带宽性价比是16~25TB/s / $200k~350k。

内存带宽与互联的配平比内存性价比更重要。 当然比较这个指标的前提其实是上面讲的范围尽量落在这个范围内，否则一系列严重的互联问题会直接直接打崩所有内存性价比的优势。而落在这个范围之后，实际上NV的利润率是比HBM性价比富余得多的空间。所以今天其实对于LLM架构设计而言，这方面的配平远比单纯介质的性价比重要得多。

一定程度上讲，大多数芯片架构师都是微架构背景出生，对微架构或者架构形态的重视程度更高，很多对微架构技术形态或者工艺技术的重视程度更高。其实大家不要太过技术思维的从技术路径和技术形态的角度选择自己的屁股，体系结构最重要的是tradeoff，是尺度范围。一个架构形态在合理的tradeoff下可能惊为天人，在另外的场景下某些数字超出了合理量级就会产生严重的问题，不可能有永远完美的架构形态，选择架构形态作为屁股是很危险的。

无论是存算一体、数据流还是sram、3d dram等等都不是LLM芯片最关键的东西，而是架构的配平，这个配平在传统NN上是一种，在今天的LLM上又是另一种，尺度的数量级非常重要和敏感。

Groq就是单节点做太小，并行度太高，互联带宽太低，当然第一性原理的内存带宽性价比肯定是OK的。数据流存算一体架构在传统NN时代虽然软件层面还是有太多问题暂时不讨论，但硬件架构选择层面还是有不错的竞争力的，无数公司例如graphcore、cerebras、tenstorrent等等都一起涌入了靠SRAM干掉内存访问的路径。但graphcore的CTO去年就公开表示了这个架构不适合LLM了，也表达过类似DSA已死的观点。

除了groq这种激进的方案外，目前的常见的柔和改良方案基本都是考虑在这样一个mesh众核的架构基础上搞3D DRAM来解决sram太小的问题。但实际上除了软件层的问题外，互联配平的问题仍然非常严重。因为靠很多人觉得优雅的mesh网络是完全没法匹配3D DRAM的内存带宽的，同时因为众核的数量往往是100~1000量级，虽然是一颗DRAM芯片，但实际上是大量容量很小的小DRAM bank通过mesh网络连起来，mesh网络糟糕的带宽利用率以及100~1000这种夸张的碎片化程度，实际上对mesh网络上全局带宽提出了极其变态的要求，即使是芯片内部也很难达到。最后大概率只能回退到糟糕的pipeline并行面对和groq类似的内存带宽利用率问题或者回退到更糟糕的数据流并行并且把问题丢给“万金油”编译器，我之前在mackler：专用架构与AI软件栈（6）中详细讨论过这类架构的软件问题，其实软件的困难在今天LLM上不仅有耦合性的老问题，还有物理带宽事实上完全不够的问题。

存算一体有一个很大的缺陷就是对互联的重视程度太弱了。 其实存算一体的架构我在学校的时候也做过很多研究，存算一体听起来很美好，数据在哪里就在存储数据的地方计算。但问题是计算不一定只有一个操作数，很多时候有多个操作数，这些操作数不在一起的时候还是需要通过通信来传递数据。最后发现通过存算一体搞出了实际上最极致的内存带宽，但是互联完全跟不上，mesh对于大带宽需求的互联真的太糟糕了。我之前在ASPLOS上发表的一篇关于存算的架构设计最后甚至是用FPGA芯片架构里面的可编程连线这种暴力的方式来实现尽可能高的互联带宽来配平。

其实你不能说这是存算一体的问题，因为这个概念是很模糊的，NVidia把HBM和GPU合封到一个芯片里其实也算某种意义上的存算一体，当然不用纠结是存算一体还是近存，都是文字游戏（2.5D合封不算的话3D合封算不算？SRAM和ALU也是分开的算存算一体还是近存？）但NVidia是实打实把NVLink的带宽实打实打到显存带宽量级。而现在大量mesh众核的互联瓶颈也是实实在在的。

未来长远来看，MOE和KV稀疏化是加速AGI Scaling从算法层面最有效的途径，其实也是从粗放式逐渐过渡到精细化管理静态和动态权重，从而可以创造在芯片Scaling基础上进一步更快加速超长上下文和超大模型的低成本Scaling，而对于硬件的容量需求会进一步扩大，同时随着稀疏化程度提高，使得Memory Hierarchy可能重新变得在系统层级更有意义。

上一篇主要围绕groq的token/s探讨了LLM推理需要的芯片形态，最重要的是内存带宽和互联带宽，无比粗暴的100GB~1TB级别的scan模式访问，内存系统的噩梦，拒绝一切花里胡哨的复用特征。倒逼大家只能以第一性原理去考虑内存带宽和互联带宽的问题，然而这只是LLM推理最基础的噩梦。包括groq在内的很多芯片方案实际上在实操层面还有非常多的瓶颈。

除了decode阶段，LLM推理还包含prefill阶段，而这是个计算密集的阶段。 LLM的prefill和decode分别用来处理用户输入的token和产生模型输出的token。prefill阶段是一次性输入全部token进行一次模型推理即可，期间生成用户输入对应的KV补充到整个KV-cache中供decode阶段使用，同时也生成输出的第一个token供decode启动自回归。这个一次的模型推理实际上和绝大多数传统NN非常类似，算力需求巨大。

如果和decode阶段比较，prefill无论计算多少token的用户输入都是一次模型的inference，权重和更前面的KV理论上只要访问一次就可以，但计算量随着用户输入token长度增加成正比增加，绝大多数情况是算力bound。而decode阶段因为每个token都需要对模型进行一次inference，并对权重和KV进行一次访问，总的访存量和用户输入token数成正比，计算量也是一样成正比。所以相同token长度下，prefill和decode计算量一致，decode阶段访存量远远大于prefill阶段的，正比于token长度。

decode阶段上篇文章已经分析过了，无比变态的内存带宽和通信带宽需求，而一次用户请求实际上是即包含prefill，也包含decode。一个是计算密集型，一个是访存密集型，对硬件的要求更夸张了，但这还只是开始。

prefill（用户输入）和decode（模型输出）的token量在不同场景下也是不一样的。 如果是简单对话场景，通常模型的decode输出会更多一些，而如果是超长上下文场景，用户先上传一本几十万字的书再进行问答，这本书的prefill会直接起飞。在Agent场景下，大量预设的prompt也会占据非常多的prefill，不过prompt的prefill有不少机会可以提前算好KV而无需每个用户请求单独重复计算。

可以看到prefill和decode的组合在不同用户请求下是非常灵活和混乱的，其实比较难按照一个静态的比例去假设每个用户请求的prefill量和decode量。prefill的计算访存比也直接取决于prefill的token序列长度，同样不是一个静态预设的值，这其实给芯片的计算灵活度带来了很强的诉求。

同一个batch的prefill和decode长度也不一样。 考虑到我们搭建这样一个庞大的大模型推理系统需要服务大量用户，每个用户的prefill和decode长度很难保持一致。考虑到prefill和decode截然相反的计算访存特性，再考虑到芯片系统里面的内存资源异常宝贵，其实此时对Infra层面的调度设计已经开始爆炸了，而芯片设计同样需要考虑给Infra层面提供什么样的设计空间。

用户请求之间相互等待prefill和decode阶段的同步完成会产生很强的QoS问题，但如果同时进行prefill和decode硬件算力资源、内存资源、带宽资源的分配以及每一阶段的性能优化策略产生很强的扰动和不确定性，甚至产生内存不足等一系列问题。此外，面对不等长输入输出的更加复杂和精细的资源调度，也进一步产生大量更精细的算子编写和优化的工作量，对于芯片的可编程性进一步提出了变态要求。

但这还没完，用户请求的响应和退出进一步对系统对外的IO能力提出了变态要求。

海量用户的KV-cache需要频繁从高速内存中切入切出。 当整个推理系统服务几千万用户时，一个batch的几十个用户请求支持开胃菜。每个用户会不间断地和大模型进行交互，发出大量请求，但这些请求的间隔时间短则几秒，长则几分钟几小时。因此我们上一章讲的占用内存空间巨大的KV-cache实际上只考虑了当前系统正在处理的用户请求总量，还有大量用户正在阅读大模型返还的文字，正在打字输入更多的请求。考虑人机交互的频率，一个用户请求结束后，对应的KV-cache继续常驻在高速内存中实际意义不大，需要赶紧把宝贵的高速内存资源释放出来。而其他已经发送到系统的新用户请求也需要把对应的KV-cache赶紧加载到高速内存中来开启对该用户请求的处理。每个用户聊天的KV-cache都是100MB~100GB量级的IO量（取决于模型和上下文长度，跨度比较大）。

这个IO带宽要求也不小，因为要匹配系统内部的吞吐率，每个请求要进行一次完整的KV导入和导出，而系统内部的内存带宽需要读取的次数正比于token数，所以两者带宽差距取决于请求输出的文本长度，通常在100~1000左右，注意这里的带宽是芯片系统的总内存带宽，例如groq的是80TB/s * 500+ = 40PB/s，那么这个IO的总带宽需要飙升到40TB/s~400TB/s才能满足sram的吞吐要求。当然groq早就已经卡再互联上了，这部分暂时也不太用考虑。

当然也可以考虑重计算，但这个重计算的代价一定是超过prefill的，因为聊天历史记录一定比当前这一次的输入长度要长的多，尤其对于超长上下文，用户上传一个文件后进行多轮对话，对文件的prefill进行一次即可，后续的交互中仅仅对用户提问进行prefill而无需对文件重复prefill，但需要将前面prefill的结果从外部IO倒腾进来，并在回答后将增量部分及时倒腾出去。

虽然倒腾到高速内存系统外部了，但面对几千万用户时，每个用户的每个聊天对应的KV-cache量也是天文数字一样的存储，实际上也不需要都存，但确实需要综合考虑效率的问题。一个用户在看到大模型回复之后，可能在几秒钟内回复，也可能几分钟后回复，也有可能就离开电脑永远不回复了。此时已经是一个大规模集群层面的调度和存储资源、计算资源、带宽资源的综合管理了。

多模态进一步加剧复杂程度。不同模态的流量潮汐、计算特点以及计算、内存、带宽资源占用情况，都会进一步加剧整个系统对于弹性的需求。

今天的Infra层面还远没有演进到对硬件系统如此高效的程度，但硬件系统设计的实际上是Infra层面的上限，在设计的时候当然也需要对Infra层面的问题和空间往前多想好几步。

实际上大模型推理对于算力、内存容量、内存带宽、互联带宽、IO带宽、灵活性、可编程性都提出了极其变态的需求，像groq这种只摸到单点冲到极限的做法自然会被其他多个方面的综合需求把产品竞争力拉回地板。抛开软件问题不谈，首先对于整个系统的方方面面算力、容量、带宽的配平其实也是针对LLM推理芯片最重要的取舍。

当然，软件问题也不能抛开不谈。 实际上LLM推理系统远不是transformer模型怎么硬件实现最高效，软件就可以丢到一边不管或者丢给编译器就能了事的。我们也可以看到实际上LLM的推理对Infra层面的调度设计的复杂性压根不在transformer本身，而是在“大”模型产生的各自带宽流量问题，精细化利用高速内存和带宽资源催生的潜在的算子需求也已经开始爆炸，甚至复杂度是远高于原先的朴素算子的。这些算子和调度分别是在微观层面和宏观层面对硬件资源的极致利用，在今天这种对算力、带宽、容量、互联需求全都拉爆的应用上，这种极致利用会变得更加重要。

软件的问题其实机遇与挑战并存，复杂的软件系统对LLM系统的设计增加了巨大的难度和工作量，似乎给所有NVidia的竞争者设置一层层障碍。

但反过来，这些爆炸的需求催生了无数Infra层面的创新来解决今天LLM推理的效率问题。这个层面未来也一定会催生出一个绝大的生态位，这是深度学习框架的竞争烟消云散之后又一次最大的机会。

今天在Infra的调度设计层面实际上在标准体系上还没有事实标准。 这是无数Infra从业者又一次巨大的机会。同时，Infra对事实标准的竞争之下还有一条暗线，就是LLM芯片和系统形态的竞争。实际上NVidia就是借着深度学习框架的竞争，成功用CPU+GPU的异构形态干掉了CPU集群的形态。通过CPU+GPU的异构形态为所有深度学习框架的竞争者创造了一种更高的上限和更极致的设计空间，从而使得所有深度学习框架事实上都在CPU+GPU的异构形态下竞争。

我之前写过一篇探讨芯片生态的竞争逻辑（mackler：芯片生态的竞争逻辑），里面关于生态竞争最重要的点是生态位的竞争，详细阐述过这背后的逻辑。而当今这一波造轮子其实也是新生态位的最大机会。

所以实际上NVidia对大模型推理这种对算力、内存容量、内存带宽、互联带宽、IO带宽、灵活性、可编程性都提出了极其变态的需求的场景应对方案就是在这些维度都做到第一，以一种统一的芯片形态保证了在综合维度的竞争力，当然这也是NVidia对于所有场景的统一策略，这个策略当然没错，NVidia今天大力提升显存带宽也是为了绞杀AMD在这两个维度的短期优势。

其实这是个历史性的机遇。NVidia实际上目前的解决方案就是单机多卡，以及多机组成一个同构的超级系统，同时维持各个维度的指标都冲到第一。今天在这种物理层面都拉到极致的需求下，在大模型复合的workload极其割裂的需求下，实际上异构的系统是具有更高的上限，也更能打破NVidia塑造的全方位第一的神话。

当然了能否把握这样的机遇取决于多方面因素，第一性原理的内存带宽性价比甚至已经是最不重要的一环了，芯片和系统级的配平，上述一系列问题的解决思路，以及对生态竞争逻辑的把控，对当今体系的亲和性，以及对Infra层面的折腾空间都环环相扣。

但无论如何，芯片行业的Scaling已经开始，支撑LLM朝着AGI更快地低成本Scaling。Scaling is all we need！

原文链接

https://zhuanlan.zhihu.com/p/683359705?utm_campaign=shareopn&utm_medium=social&utm_oi=28074288611328&utm_psn=1747573931849158656&utm_source=wechat_session

https://zhuanlan.zhihu.com/p/683908169?utm_campaign=shareopn&utm_medium=social&utm_oi=28074288611328&utm_psn=1747573971460153344&utm_source=wechat_session

Click here to follow and lock in more original content

END

*Disclaimer: This article is original by the author. The content of the article is the personal opinion of the author. The reprinting by Semiconductor Industry Watch is only to convey a different point of view. It does not mean that Semiconductor Industry Watch agrees or supports the view. If you have any objections, please contact Semiconductor Industry Watch.

Today is the 3693rd issue of "Semiconductor Industry Observation" shared with you. Welcome to pay attention.