1. 项目概述此TSP非彼TSPGroq做了什么1.1 一篇什么样的论文又是什么样一颗芯片看到“Groq TSP”这个标题第一反应建议各位先别往旅行商问题上想。虽然TSP在算法圈子里更常见的是Traveling Salesman Problem也就是那个经典NP-hard组合优化问题但今天要聊的是完全不同的东西Groq公司的Tensor Streaming Processor张量流处理器。论文标题其实已经把核心思路讲得很直白——把芯片“切开”按功能切片用数据流给深度学习打开一条确定性加速的路。这里说的论文是2020年HPCAIEEE International Symposium on High-Performance Computer Architecture上的那篇《Think Fast: A Tensor Streaming Processor (TSP) for Accelerating Deep Learning》作者是Dennis Abts等人背后团队来自Groq公司核心人物里包括前Google TPU架构师Jonathan Ross。它不是什么跑分软文也不像常见的那种“又出了一颗AI芯片”的商业发布稿更像是一份体系结构宣言把复杂度从硬件搬到编译器把深度学习推理做成一条刚性流水线。我把这篇论文翻来覆去读了几遍又翻了不少后续的白皮书和配套材料最直观的感受是Groq不是在做另一颗“更快一点的GPU”而是在回答一个更尖锐的问题——当计算图静态已知、张量形状基本固定、执行行为高度规律的时候这颗芯片为什么还要像一个通用处理器那样做乱序执行、动态调度、缓存一致性这些事TSP的答案是不做。它把这些功能全部砍掉把算力资源纵向切成一条条功能切片functional slice再用数据流方式把计算喂进去。1.2 这篇解读适合谁能解决什么问题如果你是做AI基础设施、推理引擎优化、编译器后端或者纯粹对体系结构感兴趣这篇文章值得认真看完。即便你只是用PyTorch训练模型、用TensorRT做推理部署也建议了解一下Groq的设计因为它在很多方面代表了另一种思考AI芯片的范式不去凑CUDA生态不依赖HBM高带宽而是靠静态编译和片上SRAM来保证性能与确定性。聊一个很实际的痛点同样的模型同一个输入用GPU跑两次推理结果不一定按位一致。小细节的浮点累加顺序不同、reduce操作在多个SM上分配方式不同都会让结果在低精度位数上产生差异。对普通图片分类、物体检测场景这点误差可能无伤大雅可对金融风控、自动驾驶数据回放、医疗辅助诊断、合规审计这些需要结果可追溯的领域这种“随机性”就很麻烦。Groq把“每次跑出来的结果都一样”做成了硬件级别的硬性质论文里叫temporal determinism和数值可复现。这篇解读接下来就围绕功能切片、数据流、确定性三个关键词展开。2. 功能切片把芯片“切开”到底是什么意思2.1 别误解成物理切割它其实是把硬件资源纵向切成流水线工位标题里说“把芯片‘切开’按功能切片”这句话容易产生误导。Groq并没有在物理上把一颗芯片切成几个不同功能的独立模块比如你切一块专门做卷积、切一块专门做矩阵乘。真正含义是芯片在架构设计上被纵向划分成一大堆完全相同的功能切片functional slices每一片都是一条自包含的、极简的运算流水线拥有自己私有的SRAM存储和算术执行单元。我查到的公开资料显示一颗TSP里大概有200个这样的功能切片。每个切片内部不是一个大而全的通用核而是一组高度专用的向量计算单元。所有切片共享同一条指令流也就是指令广播同一时刻所有切片执行同一条指令里对应自己那部分的操作。这种“单指令流、多数据流”的组织方式本质上是一种大规模SIMD架构只是以前你在GPU里见到的SIMD更强调通用寄存器堆和线程调度而Groq这里没有线程、没有Block、没有待调度队列只有编译器早就安放好的数据位置。打个比方。传统GPU像一家随时接散客的快递站每进来一包货都要现查地址、现分路线调度器忙得不可开交。Groq更像一条预制好的环形流水线200个工位一字排开每个工位只做自己那一小步操作物料从上游工位传到下游工位。工位之间不需要大喊大叫问“下一步该给谁”因为整个节拍在开工之前就已经写在计划表上了。2.2 为什么用大容量SRAM代替HBM还省掉了缓存层次TSP一个非常反直觉的地方是它不依赖HBM那样的大容量外部显存而是把大量存储直接放到片上。多个公开资料里提到一颗TSP的片上SRAM总量在200MB量级每个功能切片拥有自己独立的一块SRAM空间。在深度学习推理场景下模型权重可以被完整地“摊”进片上。权重常驻数据在芯片内流动最大的好处是避免了每做一次计算都要去外部显存拉数据的漫长路径。GPU虽然也有L1、L2缓存但缓存天然解决的是“局部性”问题硬件并不知道后面的指令到底要用哪块数据只能猜测。一旦猜不中cache miss就得从HBM读数据延迟在几百个周期以上。Groq直接把这个机制砍了没有传统意义的缓存层级片上的SRAM不是“缓存”而是编译器可以显式管理的可寻址片上存储。编译器在编译阶段就决定好每个张量放在哪个切片的哪块SRAM里数据什么时候该走哪条路径搬到哪个邻居切片。硬件层面不需要任何一致性协议不需要监听总线不需要决定“这个数据要不要缓存”。这个选择背后其实是成本博弈。HBM协议复杂、控制器占面积、功耗高而且访问延迟并不低。Groq把省下来的复杂度换成高密度SRAM虽然片上存储量远不如HBM但对推理这种权重可静态放置的场景反而更有效率。当然代价也很明显模型一旦超出片上容量就要做分块tiling处理编译器要处理跨块通信这会显著增加编译复杂度。这也是为什么Groq这种芯片特别依赖编译器的表现力。3. 数据流与确定性执行硬件让位编译器说了算3.1 指令广播与横向纵向的数据搬运机制TSP的数据流执行方式可以说是整套体系结构最核心的部分。每个周期芯片取出一条很宽的指令这条指令里同时编码了所有功能切片需要执行的操作再通过广播机制同步派发到200个切片上。由于所有切片执行同一指令指令本身不会去指定“第3个切片做加法、第7个切片做乘法”而是规定了“每个切片对自己SRAM地址A里的数据做某个运算然后把结果放到地址B”。至于每个切片地址A到底是什么内容在编译阶段就已经摆放好了。不同切片之间的数据交互则依赖芯片上内置的数据搬运网络。相邻切片可以直接横向传递数据一个周期把数据从切片i传送到切片i1也可以纵向传递同一切片的SRAM中的数据跨多个周期持续保留并被后续指令读取。这种“横向广播加纵向传递”的组合让数据呈现出在芯片上流动的形态从切片的某个SRAM出发经过一系列计算逐步往下游移动最后汇聚到输出切片。这跟CPU里的“取指-译码-执行”是两种完全不同的心智模型。CPU关心的是指令怎么快点跑完数据放在寄存器里还是内存里它不关心Groq关心的是数据怎么摆放、怎么流动指令只是给这条流动过程打节拍。编程模型也更像在编排一张“列车时刻表”每个张量是一趟列车每条指令是一个站台编译器得保证列车在正确的时间出现在正确的站台否则数据冲突流水线就堵了。3.2 确定性到底怎么来数值误差为什么可复现那“确定性加速”的确定性到底指什么两个方面。第一是时间上的确定性也就是执行时钟周期数固定。论文里明确强调这种“temporally deterministic”特性一旦模型编译完成从启动信号发出到最终结果输出所需的时钟周期数是完全固定的不管运行多少次都一样。因为芯片没有乱序执行、没有动态分支预测、没有Cache Miss这种会让延迟抖动的事件所有操作都是事先排好的硬管线。第二是数值上的确定性体现在浮点累加顺序固定。深度学习里有大量求和操作比如规约reduction、矩阵乘的累加、BatchNorm的均值方差计算。浮点加法不满足结合律也就是说(ab)c和a(bc)的结果在低位上可能有差异。GPU在并行reduce时数据怎么分组、各组结果怎么合并受调度顺序影响可能每次不一样。Groq就不同了编译器生成的指令顺序是固定的哪个切片接收哪部分中间结果、最后谁来做累加都是固定的因此两次运行得到的结果在bit级别一致。这里要澄清一个重要概念确定性不等于更准确。它只保证误差路径可复现不保证误差更小。你用低精度量化后出现的数值误差该有还是有。但“可复现”本身就是一大利器至少让你能调试、能审计、能追溯。这对生产环境的价值非常实际。我之前调训练脚本的时候就遇到过这种情况同一个推理请求间隔一小时再跑一次输出张量低几位变了导致后续业务对账出现偏差查了半天才发现是GPU多卡reduce顺序不同导致的。如果底层硬件能给出“每次完全一致”的承诺这类问题的排查成本能省下一大截。4. 编译栈与性能实测算得快但代价都压给了编译器4.1 编译器如何把一层层网络变成一条条硬指令没有强大的编译器TSP这种架构就是一块砖。因为硬件放弃了动态调度所有调度决策都必须在编译期完成。Groq的软件栈和目前常见的CUDA深度学习生态不太一样。公开资料里经常看到Groq用b→p这样一个看起来不太像编程语言的说法来描述上层编程范式大意是程序员先用一种张量级的流式语言描述计算图然后编译器逐步降级到Coral IR和底层指令。编译器要同时解决好几个问题把张量分配到不同功能切片的SRAM上决定数据在哪个时钟周期写入哪块地址规划数据从一个切片到另一个切片的搬运路径再把运算操作和搬运操作编码进超长指令字的各个槽位。这里面任何一步出错程序就无法正确运行。所以Groq的编译更像一次“三维俄罗斯方块”求解空间上要摆进200个slice各自的SRAM时间上要保证每个周期所有slice.operation不冲突网络路径上还要避免数据包碰撞。这带来一个很有意思的工程权衡。GPU程序员的直觉是“把kernel写对调度交给驱动和硬件”Groq程序员的直觉是“把数据流写清楚把排列和时序交给编译器”。因此编译时间可能不会特别乐观特别是复杂模型或大batch场景下的全局排布可能需要较长时间。但编译完成后运行阶段的性能和功耗都非常可预期这对线上推理服务是一个很大的优势。4.2 论文里的性能对比以及一颗专攻推理的芯片有多夸张论文里给出了多个经典模型在Groq TSP上的对比测试包括ResNet-50、BERT这类具代表性的视觉和语言模型。和同期NVIDIA V100相比论文展示的推理延迟和吞吐数据普遍提升明显有些场景甚至接近一个数量级。这里我就不把具体数字当绝对公式背了毕竟对比环境、精度、batch、框架版本差异都很大但结论方向是一致的在固定计算图、固定shape的推理任务里Groq能把硬件利用率压得非常高。为什么能这么快还得回到架构。GPU动辄几千个CUDA核心每个核心都要独立取指、访存执行单元在等待数据的时候经常空转Groq则是把数据预先摆在面前算完一个数立刻传给下一个工位几乎没有等待。更重要的是TSP可以采用软件流水线的方式把多个层叠在一起第1层还没算完第2层的前半部分已经开始处理第1层吐出的头部数据这种跨层重叠在传统GPU上不是不行但要靠框架和驱动精细配合难度高不少。不过话也要说回来。这种极致性能是“做减法”换来的。训练场景中模型结构频繁变化、梯度计算有反向传播的依赖关系、大规模分布式训练还要频繁同步通信TSP这种刚性数据流就不太契合。所以Groq的定位更多在推理侧尤其是对延迟和确定性要求较高的场景。不是它不够强是设计目标本来就不一样。5. 常见误区与踩坑记录5.1 此TSP非彼TSP标题撞车的坑先把这个最简单也最容易踩的坑说清楚。如果你拿“TSP”去搜索引擎里找资料大概率先看到的是旅行商问题的各种解法遗传算法、模拟退火、强化学习一搜一大把。这不是Groq的问题而是缩写撞车。旅行商那个TSPTraveling Salesman Problem是组合优化领域最经典的NP-hard问题之一和本文的主题没有任何关系。想找芯片相关的资料建议直接搜“Groq TSP”或“Tensor Streaming Processor”千万别被困在算法题的讨论里。5.2 功能切片不是物理切开也不是“异构计算”第二个容易误读的地方是“把芯片切开按功能切片”这个标题表述。我在开篇就强调了功能切片不是把芯片切成“一个负责卷积、一个负责池化”的异构模块。TSP的200个功能切片在硬件上是同构的每个都能执行各类向量运算。它们的差异不在功能而在数据和时序安排上。编译器让切片A在这一段算卷积让切片B在另一段算矩阵乘但切片A和切片B本身是完全一样的单元。如果非要类比可以想象成一条路上并排20条车道每条车道都能跑各种车型交警根据每个路口的车流量决定哪批车走哪条车道而不是把某条车道永久划为公交车专用道。5.3 上手的真实体会软件Pipeline、动态Shape与编译等待最后从实际操作层面说几点经验。如果你有机会在Groq的模拟器或真机上部署模型我的建议是第一件事不要跑大模型先拿一个像ResNet-18这样的小模型完整走一遍编译到部署的流程看看编译时间、看看流水线展开后的指令数、看看单次推理的延迟分布是不是真的完全没有抖动。动态shape会是最大的拦路虎。TSP的数据流设计要求张量形状在编译期完全已知因为SRAM里的摆放、数据搬运路径、指令时序都是跟着shape走的。模型里只要出现一个动态维度比如NLP里的变长序列编译器就可能要为不同shape生成多个编译产物运行时再做切换。实测下来这种切换存在开销如果你指望像PyTorch那样model.eval()之后随意喂任意长度输入恐怕要调整预期。数据流架构还容易遇到一个资源碎片问题。片上SRAM是按slice来划分的一个大矩阵很可能被切成很多小块分布到不同slice但每个slice的SRAM空间有限某几个slice塞得很满而另外几个slice空闲的情况经常会出现。好的编译器会做全局优化来缓解但模型结构太怪、中间tensor太碎的时候内存利用率下降会直接限制可支持的batch大小。这时候与其去抠模型代码不如考虑调整数据layout或拆分算子反而更快出效果。还有一个容易被忽视的点是低精度数值的确定性收益。Groq因为浮点累加顺序固定所以不管跑多少次结果都一样这非常方便做线上A/B测试和版本回归。但确定性不等于精度安全在Int8、BF16等低精度格式下数值溢出的风险依旧存在。建议在上线前还是要做定点的数值校验。可以说数据流架构把“优化得对不对”这个问题从运行期搬到了编译期代价是调试手段也要跟着变。我自己在看完论文和上手相关模拟工具之后最大的体会是AI芯片的竞争不是只有“堆算力”一条路。GPU把通用性做到极致Groq把确定性和可预测性做到极致它们是同一道题目的两种不同解法。对很多线上的推理业务来说比峰值算力更稀缺的其实是可预期的延迟和可复现的结果。把这种思路放进自己的技术选型里哪怕不用Groq也能帮你重新审视当前部署方案里到底有多少时间花在了硬件的“不确定性”上。