LPU芯片架构揭秘：编译器驱动的LLM推理加速新路径

聊到AI芯片架构，这两年最绕不开的三个字母其实是GPU，但如果你只盯GPU，大概率会漏掉一个挺有意思的反例——LPU（Language Processing Unit，语言处理单元）。这不是什么PPT概念，Groq已经把它做成实物，在LLM推理场景里跑出了不输甚至超过传统加速器的成绩。这篇文章想用尽量直白的方式把LPU芯片架构的底拆一遍：它为什么靠编译器吃饭、为什么死磕SRAM、跟GPU和通用SoC到底差在哪，以及如果你打算做AI基础设施选型或芯片设计，能从中借鉴什么。

1. 先搞清楚：LPU到底在解决什么问题

1.1 LLM推理的真正瓶颈是“内存墙”

先说结论：大语言模型在推理阶段，卡住性能的早就不再算力，而是内存带宽。很多人一听说AI芯片就以为比的是每秒能算多少次浮点运算，这其实是训练时代的思维。到了推理，尤其是LLM这种自回归模型，情况完全不一样。

LLM生成一个字（token）的时候，需要把整个模型的权重从存储里读一遍。以现在主流的7B模型为例，如果用FP16存，静态权重就是约14GB。读这14GB需要多少时间，直接决定了你每秒能不能多吐出几个token。我们拿HBM高带宽内存举例，主流水准大概3TB/s到5TB/s的带宽，就算给它4TB/s，理论上一秒也只能把这14GB读约280次，也就是280个token/s。这个数字看着还行，但这是把带宽全部让给权重读取的“白送版”理论值，现实里还有KV Cache读写、Attention计算、激活值搬运，再好的供应商也只能做到理论值的六到七成。

反过来看算力，一个7B模型每生成一个token，真正需要的数学运算量其实才几十GFLOPs，而现代GPU的算力动辄几百TFLOPS，差了二十倍以上。也就是说，LLM推理这块负载天生就是“算力用不完、带宽不够用”，业内管这个叫memory-bound。所以谁能在单位时间里把更多字节喂给计算单元，谁才是推理场景里的真王。

1.2 为什么GPU在推理任务上有点“有劲使不出”

GPU不是不能跑LLM，它训练和推理都能扛，只是架构本身就是给“大规模并行矩阵计算”设计的，天然偏向把算力堆满、把并发拉满。为了做到这一点，GPU内部塞进了复杂的线程调度器、巨大的寄存器文件、多层Cache、分支预测、乱序执行这类通用处理器该有的东西。

这套体系在训练场景很划算，因为训练时batch很大，一个batch里几十万甚至上百万个样本一起算，矩阵乘法的规模足够大，所有核心都能塞满。但推理阶段，尤其是面向用户实时交互的场景，batch通常很小，很多生产服务为了控制延迟甚至只跑batch=1。这时候你会发现一个尴尬现象：每次只生成一个token，每个token只经历一个瘦长的矩阵乘和Attention，GPU里大量SM是半空闲的，硬件控制逻辑和缓存占了不少芯片面积，却没法帮FLOPs落地成token数。

这不是GPU不行，而是架构失配。GPU的设计目标从来不是我每秒生成多少个token，而是“我尽可能提高算力利用率”。LPU恰恰选择了另一条路：不去追求算力上限，而是把每一个时钟周期都花在刀刃上，让数据从存储到计算单元的流动路径变得极短、极确定。

1.3 LPU的解法：把调度从硬件挪到软件

我第一次接触LPU架构的时候，感觉最颠覆的一点是：它把传统处理器里最引以为傲的硬件调度机制几乎全部干掉了。没有乱序执行、没有分支预测、没有复杂的线程调度，硬件只做一件事：按编译好的指令执行。

这种设计思路可以概括成三个关键词：显式存储、静态调度、专用计算。硬件不猜未来，不临时分配资源，你在编译阶段就把所有事情定死：哪块数据放在哪个SRAM地址，哪个周期进入哪条流水线，计算完成后结果搬去哪里，全部提前安排。

用一个生活化类比来说，GPU像一个高峰期的商场，每一层都有店长临时调度导购员去应付顾客；LPU则更像一场输出拉满的演唱会，所有灯光、音响、演员的走位都在排练时定死，现场只需要按时间轴执行。演员不需要思考，导演不需要现场指挥，效率自然高得离谱。

2. LPU芯片架构的核心构成

2.1 计算单元：脉动阵列与向量引擎

LPU里最核心的计算单元不是通用ALU，而是一堆脉动阵列（Systolic Array）配合向量引擎。脉动阵列这个词听着玄，拆开看其实特别朴素。做矩阵乘法的时候，数据不再从内存一个个抓过来算，而是一个数据借给旁边的单元算完，顺手再向后传，像血液在血管里一脉一脉地往前涌。

好处有两个。第一，同一份数据可以被多个计算单元复用，访存次数大幅减少，等于变相提高了有效带宽；第二，每个计算单元结构极其简单，只需要做乘累加和传递数据，芯片面积小、功耗低，可以塞进去几十上百个。向量引擎负责处理那些不是矩阵乘法但又绕不开的活，比如LayerNorm、Softmax、RoPE位置编码、逐元素乘加这类的操作。这些算子虽然占FLOPs比例不大，却是每个token都要走的必经之路，放在专用向量单元上执行比硬塞进脉动阵列高效得多。

有一类很常见的误区是把LPU当成“一块装满SRAM的GPU”，它的算力设计其实非常克制。脉动阵列的位宽、数量、频率都是按LLM推理的典型算子形状来做平衡的，目的不是让单块芯片的TOPS数字好看，而是让每个时钟周期的数据和计算刚好接续上，不空跑。

2.2 存储体系：SRAM堆料背后的带宽逻辑

LPU在存储上做了一个看起来很激进的选择：大面积堆片上SRAM，而不是像GPU那样外挂HBM。公开资料显示，Groq的单颗加速器片上SRAM容量在一两百MB这个量级，不同型号和批次会有差异。这个容量和动辄几十GB的显存比起来确实小得可怜，但存储的指标有两条，一个是容量，另一个是带宽和延迟。

SRAM的速度比DRAM快一到两个数量级，单颗芯片的SRAM总带宽可以达到几十TB/s量级，而且延迟在纳秒级别，不需要像HBM那样走几个时钟周期的复杂协议。更重要的是，SRAM不做自动缓存，所有的数据生命周期都由编译器显式管理，这意味着存储访问是确定性的，不会出现cache miss这种让人无法预估的尖峰延迟。

LPU的逻辑很简单：模型在推理场景下，只要权重和KV Cache能放进片上SRAM，那么每个token生成时所有访存都发生在片内，速度极快；如果模型太大放不下，才需要考虑多芯片切分。这个取舍在特定场景下非常实用，因为今天大量商用的7B、8B、14B模型，在INT8或FP8量化后，完全放得进一两百MB的SRAM容量范围。容量和带宽本来就是鱼与熊掌，LPU选择了把“单位算力对应带宽”这个比值做到极致。

2.3 互连与多芯片扩展：单芯片不够就拼起来

单颗LPU装不下超大模型怎么办？答案是多颗拼成阵列。LPU芯片之间用高带宽互连组成拓扑网络，可以理解为把多颗芯片直接连成一张高吞吐的通信网。编译器会把模型切到不同芯片上，张量并行、流水线并行都可以做，但要遵守一个纪律：跨芯片搬运数据的次数越少越好。

片间互联通常比片内总线带宽低一个量级，所以编译器切模型时会把通信量大的操作尽量放在同一颗芯片内完成，比如把整层Transformer塞进一颗芯片，不同层流水线式分布在多颗芯片上；只有当单层都无法容纳时，才被迫做张量切分。这个约束听起来和普通分布式训练很相似，但LPU的优势在于片间通信同样是静态调度的，哪个周期发数据、哪个周期收数据、走哪条物理链路，全部提前规划。

我见过有人把多芯片LPU系统类比成“没有缓存一致性协议的大集群”，这个说法基本到位。正因为它不需要一致性协议，不需要硬件动态路由，芯片间的通信开销才能压得这么低，整个系统的性能模型才能做得精确到时钟周期。

3. 软件与硬件的配合逻辑：编译器驱动的确定性执行

3.1 从计算图到静态指令序列

LPU真正难啃的其实是软件栈，又或者说，它的硬件只是软件策略的执行者。开发者通常会用PyTorch或ONNX定义模型，然后把模型交给LPU的编译器。编译器做的事情大致分四步：解析计算图、把算子映射到脉动阵列和向量引擎、给每一块数据和中间结果规划SRAM地址、生成一条条预先排布的指令序列。

很多芯片也做计算图优化，但LPU的编译器做得更绝对。它不仅要保证功能正确，还要保证每一个时钟周期里数据和计算单元刚好对上。如果某个周期数据还没从SRAM搬到阵列，编译器宁可插入空泡，也不会让硬件去“碰运气”动态协调。这种设计在训练阶段会很痛苦，因为反向传播的算子形态太多，编译时间会爆炸；但推理阶段模型结构固定，静态编译的好处能完全释放出来。

所以你会发现，LPU每次升级模型支持或者新增算子，重点不是改芯片，而是升级编译器。它的交付物本质上是“编译器和芯片的联合系统”，这也解释了为什么LPU生态的迭代节奏和传统GPU不同。

3.2 “没有cache”背后的语言艺术

很多资料都说LPU没有cache，这其实是一种带引号的说法。更准确地说，LPU没有传统意义上对用户透明的自动缓存和缓存一致性协议，但芯片里当然有SRAM存储，而且这些SRAM是显式管理的。

在GPU上，写代码的时候不需要关心变量到底在哪个缓存层，硬件会自动搬数据。LPU则反着来，编译器必须显式管理每一个buffer的分配、使用和回收。比如模型权重放在哪些SRAM bank，KV Cache预留多大区域，中间结果放在哪个临时buffer，都要在编译时定死。

这种设计最大的好处是没有缓存一致性开销，没有cache miss惩罚，所有访存的延迟都是已知的。最大的代价是软件门槛高，如果模型里有动态条件分支，比如根据输入决定走哪个子网络，在LPU上就非常麻烦，因为编译期无法穷举所有路径，只能预先分配最坏情况的内存，或者动态重编译。

我个人的看法是，“没有cache”不应该被理解为LPU的缺点，它只是把解决问题的方法从硬件搬到了软件，相当于把存储这件事从“自动挡”换成了“手动挡”；你少了一些便利，但换来的是完全可控的性能上限和极低的访存延迟。

3.3 数据流执行与可预测的延迟

当模型经过编译，进入稳定状态后，你会看到一种非常漂亮的执行画面：权重从SRAM按固定节奏流出，进入脉动阵列做乘累加，结果流向向量引擎做归一化和激活函数，最终写回SRAM，整个过程像一条有节奏的流水线。

这种数据流执行模式让延迟变得可以精确计算。一个token经过整个模型要多少个时钟周期，编译器自己就能算出来，不需要等硬件跑起来才知道。对做服务的人来说，这一点极其珍贵——你可以直接根据模型结构评估峰值QPS、首token延迟和排队时间，不需要靠压测慢慢摸。

不过这种可预测性是有前提的：模型必须是静态的。如果你在服务里动态改batch、动态改输入长度、动态开关某个模块，编译器可能就被迫重新规划或者生成一份很保守的执行计划，性能优势会大幅缩水。这就是为什么LPU特别适合固定形态的生成式应用，而没那么适合探索性、灵活性极高的研究代码。

4. LPU与GPU、通用SoC架构的一次正面对比

4.1 一张表看懂CPU、GPU、LPU和SoC的姿态差异

为了把这四类东西的定位讲清楚，我整理了一张对比表，主要看调度方式、存储体系、并行模式和擅长负载这几项。

从表里能看出来，CPU和GPU都把调度复杂度放在硬件里，追求通用性；LPU把调度复杂度挪到了编译器，追求极致效率；通用SoC则介于之间，既要兼容不同任务，又不能像服务器芯片一样堆面积。

4.2 LPU本身就是一种极端专用的SoC

说到SoC（片上系统），这两年圈里聊得很多的是“soc芯片架构”怎么把CPU、GPU、NPU、音视频编解码器都集成到一颗芯片上，比如手机SoC、汽车座舱SoC、边缘AI SoC。物理形态上LPU也是一颗SoC，它内部有控制单元、脉动阵列、向量引擎、SRAM、互连网络和外部IO接口。但区别在于，普通SoC的每一部分都可以独立处理不同种类的任务，LPU几乎把所有资源都喂给LLM推理这一条通路。

这种极端专用带来的直接收益是能效比和确定性。如果把一颗GPU和一颗LPU都跑在Llama类模型上，单看每秒生成的token数和每瓦特能生成的token数，LPU往往能有明显优势，尤其是在低并发、小batch的在线推理场景。

缺点也很明显：通用性差。你要不要学新技术、新算子，完全取决于编译器支持；你想换一个非Transformer模型跑，基本等于重新做适配。所以LPU和通用SoC不是替代关系，而是两个方向的探索：SoC追求“什么都能跑”，LPU追求“把一件事跑到极致”。

4.3 通用与专用之间的边界正在移动

一个值得注意的趋势是，通用芯片正在悄悄吸收LPU的设计思想。无论是NVIDIA在Hopper、Blackwell架构里强化Tensor Core和显存布局控制，还是各种数据中心SoC里加入可编程数据流引擎，本质都是在向“显式数据放置+编译器感知”的方向靠。

反过来，LPU这种极专用架构也在向更通用的边界试探，比如支持更多算子、提供更灵活的内存分配接口。未来我们不太会看到LPU变成通用CPU，但完全可能看到“LPU式的计算单元”作为一个IP核，被集成进更大的SoC体系，专门负责生成式推理加速。

如果你正在做SoC架构规划，我认为最该抄LPU的作业不是抄SRAM容量，而是抄它的调度哲学：先把最核心的几类算子和数据流定死，再让编译器针对这些路径做极致优化。这个顺序不能反，否则就会出现一块面积很大、资源不少但有效利用率低的加速器。

5. 实操视角：如果我要评估LPU或借鉴LPU思路

5.1 LPU真正能打和明确不行的场景

先泼一盆冷水：LPU不是什么万能芯片。它真正能打的场景有三个特征：模型结构固定、推理负载为主、低延迟要求高。典型例子是聊天机器人、代码补全、文档摘要这类在线生成服务，用户敲完提示词以后，等一两百毫秒出第一个字和每秒吐几百个token，体验差异会非常明显。

明确不行的场景包括：模型训练和微调，因为反向传播需要大量随机访问和动态梯度调度，LPU的静态调度优势反而变成束缚；超大模型推理，当单颗芯片SRAM装不下权重，必须大规模跨芯片切分时，通信开销会吃掉很多优势；对稀疏激活或者动态树搜索这类执行路径不固定的任务，LPU的编译器也会很头疼。

对普通开发者和创业团队来说，我甚至不建议一上来就自购LPU硬件。更稳妥的思路是先到Groq的公有API上跑一跑真实负载，搞清楚你的模型结构、输入长度分布、请求并发曲线到底适不适合确定性执行架构，再决定是否要为它投入工程资源。

5.2 给开发者的三条调优建议和一条劝退提醒

如果决定在LPU上部署模型，有三个习惯要提前改。第一，固定input shape和batch size，哪怕发布环境，也应该把最大序列长度写死，给编译器一个稳定的优化空间；第二，KV Cache要预留充足，LPU不像GPU那样靠大显存动态兜底，序列变长导致SRAM不足时，性能会断崖式下跌；第三，别用你熟悉的Python动态控制流写推理逻辑，把条件分支尽量拉平成张量运算，否则编译器很可能生成一份很保守的实现。

还有一条劝退提醒：如果你的团队没有专门的性能工程角色，不建议自己维护LPU算子库。LPU的优势高度依赖编译器和算子支持矩阵，厂商有没有跟进你用的模型版本、新算子是否已经适配，这些都需要专人盯。否则你就是买了块好硬件，却天天在给底层工具链填坑。

5.3 借鉴LPU思路做自己的SoC设计，最该抄什么

如果你像我一样平时关注soc芯片架构，可以从LPU身上抄三样东西。

第一，先定数据流再定算力。很多芯片规划一上来就拍一个算力目标，然后堆MAC阵列，结果真实负载跑不满。LPU的做法是先想清楚每个周期需要搬多少字节进计算单元，反推SRAM带宽和阵列尺寸，算力是最后才确定的。

第二，编译器团队地位要比硬件团队还高。LPU把硬件机制砍到什么程度，完全取决于编译器能不能兜住。做SoC里的AI加速器时，如果编译器团队预算不够，我建议放大缓存和调度器兜底，不要学LPU做得那么激进。

第三，把性能可预测性当产品卖点。LPU打市场的核心从来不单是快，而是“稳定地快”。如果你的SoC能向客户承诺P99延迟上界，而不是只能给一个峰值TOPS，那才是真正吃透了LPU架构的精髓。

6. 常见问题与避坑实录

6.1 “LPU没有缓存”是不是营销话术？

严格来说不是。LPU确实有SRAM，只是没有传统意义上的透明Cache和Cache一致性协议。所有数据放置都由编译器显式控制，所以不存在cache miss，也不用担心多核之间同步缓存数据。

有人在讨论里纠结“没有缓存不就等于没有存储吗”，这就理解反了。LPU的SRAM就是它唯一的存储，模型权重、中间激活、KV Cache全放这里。它不需要GPU那种“显存+多级缓存”的层级结构，因为SRAM的访问延迟已经足够低，没必要再做一层缓存来藏延迟。

6.2 模型放不进SRAM怎么办？

这是LPU最现实的瓶颈。当你部署的模型量化后超过单颗芯片SRAM容量时，就必须做多芯片切分。切分方案通常是模型并行，每一颗芯片只保存一部分权重，token生成过程中需要跨芯片拿数据的地方，通信开销就来了。

这里有一个关键认知：LPU堆多芯片的办法能缓解容量问题，但解决不了“模型大到每个token都要大量跨片通信”的场面。所以在选型时，要做一次简单估算：模型大小、量化精度、单芯片SRAM容量、每层权重分布，提前判断数据局部性好不好。局部性好的模型上LPU是享受，局部性差的模型上LPU是受罪。

6.3 我踩过和见过的几个坑

第一个坑是拿算力利用率评估LPU。传统GPU上我们习惯看算力有没有跑满，但在LPU上，限制性能的通常是SRAM带宽和编译器调度质量，算力利用率数字参考价值不大。更直接的指标是每秒生成token数、每瓦每秒token数，以及P99延迟。

第二个坑是忽略编译耗时。在GPU上，模型改个结构重新部署可能几分钟搞定；LPU上，大模型重新编译可能要花很久，迭代节奏完全不一样。如果业务需要频繁更新模型，一定要提前验证编译流程能不能跟上发布节奏。

第三个坑是把LPU当通用加速卡来买。有位朋友买了一批LPU，结果团队跑的是语音识别Stable Diffusion这类的模型，最后发现算子支持不全，只能含泪吃灰。买前先拉一份算子支持矩阵，拿真实模型做POC，别被宣传里的峰值指标冲昏头脑。

我最早听到LPU的时候，第一反应也是“这不就是一块超大的SRAM吗”，真正深入以后才意识到，它最值钱的不是存储也不是脉动阵列，而是让软件替硬件扛下复杂度的这套协同设计方法。对做AI基础设施的人来说，这个思路比任何单点参数都值得抄作业：先把目标负载切成清晰的数据流，再决定需要什么硬件，最后让编译器把所有资源排成一张精确到周期的时刻表。它不一定适合所有场景，但对“固定结构、高吞吐、低延迟”这类生成式推理任务，LPU确实给出了一个非常漂亮的架构答案。