聊到AI芯片架构这两年最绕不开的三个字母其实是GPU但如果你只盯GPU大概率会漏掉一个挺有意思的反例——LPULanguage 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通常很小很多生产服务为了控制延迟甚至只跑batch1。这时候你会发现一个尴尬现象每次只生成一个token每个token只经历一个瘦长的矩阵乘和AttentionGPU里大量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 bankKV 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乱序执行、分支预测、动态调度多层Cache DRAM少量核心单线程延时优化通用计算、逻辑控制、低延迟小并发GPU硬件线程调度、SIMT并发HBM 多层Cache大规模数据并行成千上万核心大矩阵运算、高吞吐训练与推理LPU编译期静态调度硬件按序执行片上SRAM显式管理无HBM脉动阵列 向量单元流水线LLM推理、固定结构的生成式负载通用SoCCPU GPU/NPU异构协同调度DRAM 片内SRAM/Cache多核异构并行系统级调度端侧AI、嵌入式场景、整机功耗敏感负载从表里能看出来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确实给出了一个非常漂亮的架构答案。
LPU芯片架构揭秘：编译器驱动的LLM推理加速新路径
聊到AI芯片架构这两年最绕不开的三个字母其实是GPU但如果你只盯GPU大概率会漏掉一个挺有意思的反例——LPULanguage 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通常很小很多生产服务为了控制延迟甚至只跑batch1。这时候你会发现一个尴尬现象每次只生成一个token每个token只经历一个瘦长的矩阵乘和AttentionGPU里大量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 bankKV 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乱序执行、分支预测、动态调度多层Cache DRAM少量核心单线程延时优化通用计算、逻辑控制、低延迟小并发GPU硬件线程调度、SIMT并发HBM 多层Cache大规模数据并行成千上万核心大矩阵运算、高吞吐训练与推理LPU编译期静态调度硬件按序执行片上SRAM显式管理无HBM脉动阵列 向量单元流水线LLM推理、固定结构的生成式负载通用SoCCPU GPU/NPU异构协同调度DRAM 片内SRAM/Cache多核异构并行系统级调度端侧AI、嵌入式场景、整机功耗敏感负载从表里能看出来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确实给出了一个非常漂亮的架构答案。