企业官网建设流程全解析

做AI推理服务的人应该都有过这种经历：压测报告写得漂漂亮亮，平均延迟只有几毫秒，结果一上线，P99直接飘到几十毫秒，同一个请求有时候8毫秒返回，有时候要等40多毫秒。GPU算力明明很猛，但调度器、缓存一致性、内存带宽竞争这些底层机制，让深度学习推理的延迟变得像猜天气。做了几年AI基础设施之后，我越来越觉得：深度学习模型在推理阶段的结构其实是完全确定的，那为什么我们还要让芯片像处理随机动态任务一样，在运行时做一堆调度决策？Groq的TSP（Tensor Streaming Processor）就是冲着这个矛盾去的，这篇论文把方案拆得很彻底——把芯片按功能切片，每个slice独立工作，用数据流把整个计算过程编排成一张精确到周期的时刻表，让加速从"尽力而为"变成"确定性"。这篇文章我会分几块把功能切片、数据流编排、确定性带来的部署红利和架构边界一次讲透。

1. 为什么GPU的推理延迟没法预测：这是Groq要解决的"病根"

1.1 延迟不确定性藏在三个地方

我们在生产环境里遇到的GPU推理延迟抖动，通常不是算力不够，而是资源管理方式导致的。首先，GPU的核心调度在运行时发生，一个kernel启动之后，内部怎么分配SM、怎么抢占执行单元，硬件调度器有自己的策略，外部程序很难精确预知。其次，多个kernel之间通过显存交换中间结果，kernel A写完的数据要等着kernel B来读，中间一有访存冲突，整个流水就堵住了。第三，现代GPU有复杂的缓存层级和一致性协议，同一个数据可能在L2缓存里被多个SM同时访问，谁先谁后、谁命中谁缺失，这些都会影响单次请求的耗时。

这三个因素叠加起来的效果是：延迟分布非常宽。这在大规模离线训练场景还能接受，毕竟训练关心的是吞吐，多等几十毫秒看不出来。但到了自动驾驶、工业控制、实时语音交互这种场景，延迟的不确定性直接决定系统敢不敢用。你没法跟安全系统说"平均延迟5毫秒"，对方要的是"最坏情况也不超过10毫秒"。

1.2 确定性的思路翻转

Groq TSP论文开篇就点了一个很本质的问题：深度学习推理阶段，模型结构、算子顺序、张量形状全部是已知的，整个计算是被张量依赖关系严格约束的方向无环图。既然一切都已知，为什么还要让芯片在运行时做那么多动态决策？按理说，这种完全确定的工作负载应该能像工厂流水线一样，从原料进去到成品出来，每一步都在预定时间点发生。

所以Groq做了一个大胆的取舍：放弃通用处理器那套动态调度机制，把整个芯片改造成一个"预先编排好的并行机器"。所有指令的发射时间、数据搬运路径、SRAM占用窗口，都在编译期算清楚。运行的时候，芯片不需要判断，只需要按节奏执行。这就是论文核心概念"确定性加速"的来源。它不是某一条指令跑得更快，而是整个系统的行为变得可预测。

1.3 "快"不是唯一目标，可预测才是

很多人看AI芯片只盯着TOPS、TFLOPS这些峰值性能，但Groq这篇论文更强调的可预测性，其实是另一个维度的性能。传统GPU的峰值利用率往往只在理想的连续大矩阵乘法上才能达到，真实模型里因为kernel切换、访存竞争，实际利用率打到30%都算不错。而确定性架构从设计目标上就让编译器精确安排每个资源，尽可能让每一个执行单元在每一个周期都有活干。论文里提到，编译器能够计算出整个网络精确的执行周期数，任何一次推理的执行时间，在运行之前就是一个确定数。这种"运行前就知道耗时"的能力，比单纯堆算力要有价值得多。

2. 功能切片的物理与逻辑设计：每个slice都是一个小型处理器

2.1 把大芯片切成一排独立的小处理器

Groq TSP最关键的结构决策，就是"功能切片"。简单说，整块芯片不是按"几个大核+共享缓存"来组织，而是被切成一排相对独立的功能切片（functional slice），每个切片都有自己的指令取指、解码、执行单元和局部SRAM。你可以把它想象成一个大型中央厨房被拆成几十个独立小厨房，每个小厨房有自己完整的灶台、备菜区和出菜口，彼此之间不需要去争抢同一个冰箱。

每个slice内部包含足够多的运算单元，能独立完成向量运算、矩阵运算等深度学习核心操作。多个slice横向排列，通过片上网络连接，数据可以在slice之间直接传递。这种设计最直接的好处是去掉了"全局共享资源"这个瓶颈。传统芯片里所有计算单元共享L2缓存和内存控制器，一旦并发量上去，共享资源就是天然的战争爆发点。功能切片从物理上把战场切开了，每个slice的资源是私有的，不需要中央协调。

2.2 没有缓存一致性协议，反而更快

常规多核芯片都要处理缓存一致性问题——核A改了数据，核B的缓存里的旧值就得失效，这些协议开销在不规则访问模式下非常昂贵。Groq干脆不搞缓存一致性。每个slice的SRAM只接受编译器显式的数据搬运指令，数据什么时候写入、什么时候读出、什么时候传给隔壁slice，全部由指令流控制。你可能会问：没有一致性，协同计算时数据错了怎么办？答案是：编译器保证不会错。因为所有数据依赖在编译阶段已经分析清楚，指令的顺序就是依赖的顺序，硬件不需要用一致性协议去"猜测"哪些数据需要同步。

这种设计很像CPU里的显式流水线编程，但规模完全不同。我自己的理解是，Groq把"同步"这件事从硬件原语升级成了编译期调度问题。硬件不再负责协调，只负责执行。省下来的芯片面积和功耗，全部让给了计算资源。

2.3 和TPU脉动阵列的区别：专用和泛化

提到数据流架构，很多人会想到Google TPU的脉动阵列（systolic array）。TPU是把大量乘加单元排成阵列，数据像波浪一样在单元之间传递，每个单元只做固定操作，优点是非常节省指令开销，缺点是整个阵列只为有限的算子形状调优。Groq TSP的功能切片则不一样，每个slice是完整可编程的处理器，能执行通用向量指令，但组织方式又保留了数据流的节奏。如果把TPU比作一条只做固定型号零件的专用机床，Groq更像一组可编程的机器人工作站，工作站之间用传送带串联，传什么零件、什么时候传、在哪站加工，都由中央调度提前定好。

这个设计取舍意味着Groq对算子的适应性比TPU强。只要编译器能把算子分解成slice能执行的指令序列，就能跑。静态脉动阵列常见的"矩阵形状不匹配导致大量空闲"问题，在功能切片架构里通过指令级流水编排来缓解。

3. 数据流编译：把神经网络换算成一张精确到周期的时刻表

3.1 为什么编译器能算出精确执行时间

Groq TSP的逻辑是，每个基础指令在硬件上的执行延迟是固定的。向量加、向量乘、数据搬运、SRAM读写，这些指令的周期数都能在芯片设计阶段就确定下来。因为芯片内部没有动态分支预测、没有乱序执行、没有缓存未命中重试，所以一条指令从进入到完成，时间就是恒定的。这给了编译器一个非常重要的能力：它可以把整个计算图画成一张有向无环图，每个节点标上执行周期，然后像做项目排期一样，推算出每一条指令应该在哪一个周期发射。

这种静态排期有一个很直观的类比：高铁时刻表。每条线路的出发和到达时间是固定的，列车严格按照时刻表运行，不需要临时判断"前面车快不快、要不要超车"。传统GPU的任务调度更像城市道路，每个路口都有红绿灯（硬件调度器），车多了就得排队等待，没人能提前算出精准到秒的到达时间。

3.2 数据流在整个芯片上怎么流动

要理解数据流执行，你得先改变"数据是放在内存里给所有核随便读"的想法。在Groq TSP里，数据从加载到片上的那一刻起，就有一个明确的"居住地"——某一块特定的SRAM。计算发生时，数据从SRAM被送到同一slice的执行单元，计算完的结果又被写回另一块指定的SRAM。如果下一步计算在相邻slice，数据就通过片上网络直接传过去，完全不经过外部DRAM。

举一个卷积层的例子：输入特征图的一个分块被提前切分好，放在slice 0到slice 7的SRAM里，权重矩阵经过数据复用后存储在相邻的一排slice里。编译器排好时间表之后，每个slice在同一周期各取各的数据、各做各的乘加，然后把部分和像接力棒一样传给下一个slice。整个过程里没有人为的kernel边界，没有任何一个周期在等锁或等同步。论文里形容这种状态为"数据持续流动"——数据不是被取到寄存器里用完就丢，而是一直在计算单元和SRAM之间形成稳定流。这种流水线式的执行模式能把执行单元的利用率拉得很高。

3.3 SRAM容量不够的时候，编译器还会做溢出调度

当然，深度学习模型动辄几百MB的权重，不可能全塞进片上的SRAM里。Groq解决这个问题的方法是分层管理：最热的数据常驻SRAM，冷数据存放在外部DRAM，编译器在时刻表里安排特定的周期把冷数据搬进来、把废弃数据搬走。这个DRAM搬移过程也是完全可预测的，因为它以显式DMA指令的形式嵌在时刻表里。你可以把SRAM想象成一个精确控温的冷柜，库里的大件物品什么时候补货、什么时候调走，库管员的排班表提前一年就排好了。片上SRAM的利用率因此变得非常高，编译器会尽量把数据复用窗口拉长，避免频繁片上片下搬运。

从操作系统的角度看，这有点像软件流水加显式缓存管理。区别在于，操作系统做的是宏观资源调度，误差容忍度高；Groq的编译器做的是微架构级排期，误差必须为零。这也是为什么Groq的软件栈极其重要——没有一套能把任意神经网络映射成这种精密时刻表的编译器，芯片就只能是一堆高性能但闲置的Slice。

4. 确定性换来的系统红利：部署、多模型、能效都跟着受益

4.1 P99延迟从"靠运气"变成"照着算"

部署过在线推理服务的同学都懂P99三个字母的杀伤力。很多模型平均延迟不错，但P99总是高得离谱。原因就是运行时不可控的访存冲突和kernel调度。Groq TSP的确定性执行改变的是整个系统的性质：因为一次推理的周期数在编译期已经是定值，你在代码里算出来的执行时间是"板上钉钉的时间"。即使系统里跑了多个任务，每个任务占用的slice资源和时间窗口也是提前分割好的，互相干扰被控制在极小范围。这在自动驾驶、金融风控、工业质检这种对"最坏情况"有硬性要求的场景，价值不是优化性能，而是让系统能够通过安全认证。

4.2 多模型共存的容量规划变得简单

做过多模型推理平台的人还会遇到一个头疼问题：同一个GPU上放10个模型，你怎么保证每个模型的延迟不互相影响？传统方案是MIG或者时间分片，但粒度粗、配置复杂。Groq TSP按slice隔离，不同的模型可以分配到不同的slice组合上，每个slice的SRAM和计算资源是固定的，另一个模型占用的流量不会挤占你的资源。当然，片上网络作为共享介质还是存在一定的抢带宽可能，但相比GPU那种全芯片缓存共享的方式，隔离性已经好了一个量级。

这种隔离带来的直接好处是容量规划简化了。你可以像算虚拟机规格一样，按"每个模型需要几个slice、占多少SRAM、峰值带宽多少"来规划整个节点能放多少路推理请求。而不用再去做繁琐的压测——测出来的数字下次换个模型又失效了。

4.3 能效比的隐性提升

前面提到，去掉缓存一致性协议和硬件动态调度器，节省了大量芯片面积和功耗。这部分省下来的资源都转化成了计算单元，所以在同样工艺下，Groq TSP的TOPS/W表现通常比通用GPU更优。另外，数据流执行模式下，数据在片上停留的时间被拉长，DRAM访问次数大幅减少。深度学习推理是典型的访存密集任务，能少一次DDR读写，就是实打实的功耗节省。我见过不少团队为了降功耗去优化kernel算法，其实很多时候最大的浪费就藏在无意义的片上片下数据搬迁里。

5. 数据流架构的边界：哪些场景会让编译器难以下手

5.1 动态形状和动态控制流是静态调度的天敌

Groq TSP的确定性建立在"编译时就知道一切"的基础上，所以它最怕的就是运行时才知道的东西。比如变长输入的NLP模型，Prompt的长度在推理时才确定，张量形状是一个动态值。传统GPU可以在运行时根据当前shape选择不同的kernel，但Groq的编译器无法为一个未知形状提前生成精确时刻表。论文和实际资料也提到，大量动态shape场景需要用到padding、分桶这类技巧，把动态问题转化成静态问题，代价是额外计算量和内存浪费。这件事在LLM推理里尤其明显，每次请求的序列长度都不同，如果不做妥善处理，要么浪费算力在padding上，要么频繁重编译导致延迟飙升。

5.2 稀疏化和不规则计算需要额外的编译器魔法

深度学习模型里的稀疏操作，比如MoE（Mixture of Experts）里的按需激活专家网络、推荐系统里的海量稀疏特征嵌入，这些操作的数据访问模式高度依赖于输入内容。编译器很难在运行前确定"这次请求会激活哪些专家、访问哪些特征表"，因此只能采用保守策略，把可能用到的数据都留在SRAM里，或者干脆把稀疏数据稠密化。前者浪费容量，后者浪费计算。虽然可以通过特殊编译技巧缓解，但相比处理规则稠密张量，编译器的工作量和生成的指令效率都打了折扣。如果你要部署的模型里含有大量动态条件分支、稀疏查找，数据流架构可能不是最优解。

5.3 编译器质量决定一切：软件栈是隐性门槛

功能切片把哈德维尔维特从调度器手里交给了编译器，这意味着软件栈的成熟度直接决定芯片的实际表现。如果模型里出现一个编译器无法高效映射的算子，你面临的可能不是性能下降，而是"能否运行"的问题。传统GPU上你还可以写CUDA Kernel、写Triton去手调适配；Groq这套模型里，普通开发者几乎不可能绕过编译器去手工调整slice级指令，只能依赖厂商的工具链。这种高度依赖编译器的模式，在标准卷积、Transformer结构上问题不大，但凡是需要自定义算子的团队，都要在项目初期把"编译支持范围"当作第一评估项，否则很容易陷入产能危机。

6. 选型前我会问自己的几个问题：Groq TSP适合谁

6.1 你的场景真的需要确定性吗

在决定Groq TSP这类数据流加速器之前，我会先问团队：我们的痛点到底是"算力不够"还是"延迟不稳定"？如果是前者，传统GPU加更大力度的算子优化已经能解决大部分问题；只有当你反复被P99抖动折磨、被实时性要求卡住，确定性才有真正的价值。做离线的批量推理、训练任务，完全不需要为确定性付出生态上的代价。

6.2 你的模型结构能被静态编译驯服吗

我需要审视模型的每一个算子：是否有动态shape？是否有运行时控制流？是否有稀疏查找？如果都有，我会慎重。反过来，如果模型是标准的CNN、Transformer、固定batch的推理服务，那么Groq TSP的数据流架构几乎是量身定做。对于大模型推理场景，它的大SRAM和高带宽思路很有吸引力，但变长prompt、连续批处理（continuous batching）带来的动态调度需求，可能会成为一个棘手的问题。

6.3 团队能接受"重编译"开发流吗

数据流架构的开发流程和GPU生态完全不同。在GPU上，你换个库版本、改个算子手写实现，直接运行就能看到效果。在Groq上，任何模型结构的修改都得重新走一遍编译，生成新的时刻表。这个编译过程是否快、是否好用，只有实际用了才知道。对一个把迭代速度看得很重的团队来说，这个变化可能远比你想象的大。如果在选型阶段能拿到评估板，我一定要做的第一件事就是测：从拿到模型到首次跑到满负荷推理，到底需要多久。

我自己判断，Groq TSP这类确定性数据流架构的价值，已经不止于芯片本身。至少它把"延迟可预测"重新拉回了AI基础设施的设计目标清单，而不是永远跟在算子优化后面追各种峰值性能。全部算下来，我不认为它会全面取代GPU，但它在实时推理、边缘控制、确定性SLA这些特殊角落，确实打开了一条不一样的路。后面如果有机会拿到实际芯片或者更细颗粒度的仿真数据，我会再补一篇实测向的解读。