GPU 是 AI 时代最不缺关注度的硬件但真正把它用在生产环境的人心里多少都有点别扭。它的渲染基因带来了大量你根本用不到的逻辑数据必须从全局内存搬到片上缓存再搬回内存像一条单行道一样只能按固定路线走。于是在这个路口上清微智能和 Groq 不约而同地选择了另一条路数据流架构。这篇文章我不打算复述发布会上的 PPT而是把这两家放在一起拆开看它们到底想怎么改变 GPU 这条单行道以及这事为什么不是简单意义上“再做一块更好的 GPU”。1. GPU 的“单行道”困局你的加速卡到底卡在哪1.1 从流水线说起为什么说 GPU 是单行道要理解“单行道”这个比喻得先回到 GPU 最基本的执行模型。无论是渲染游戏画面还是执行深度学习算子GPU 本质上是一条超宽、超深的流水线取指、解码、发射、执行、写回数据沿着这条固定的流水线方向向前移动。这条路设计得非常宽可以同时处理上千个线程但方向是固定的你得跟着它的规则走。我把这种架构叫做“单行道”是因为在 GPU 眼里所有数据都是一样的“车”不管你是来算卷积的还是来算光照贴图的都要从流水线的入口进入经过调度器分配、共享内存暂存、计算单元执行再绕回寄存器或缓存层。问题在于AI 推理任务根本不需要这么复杂的“交通管理”。你给 GPU 一个已经固定的计算图数据从张量 A 和张量 B 进来结果是个确定性的矩阵运算没有分支跳转没有乱序执行可 GPU 依然要走这套完整的管控流程。这里就出现一个错配一个为海量并发但充满分支逻辑设计的引擎被用来执行一种全天下最规律的重复计算。正如一条八车道的单行道上跑着一队自动驾驶卡车所有的控制指令、交通调度、红绿灯全是为随机汇入的车流设计的但对于固定编队行驶的卡车来说这些机制只会增加油耗不会带来任何通行效率。1.2 三大瓶颈控制开销、内存墙和低利用率我把 GPU 在 AI 推理中真正难受的问题归成三类这三类加起来就是“单行道”走不下去的核心原因。第一类叫控制开销。GPU 的硬件资源里有一大批晶体管是拿来干“管事儿”的取指令、译码、分配寄存器、处理分支预测、维护缓存一致性。这些组件在游戏渲染里功不可没因为像素着色器会遇到大量随机的渲染分支需要灵活应对。但在深度学习推理里计算图是编译好并且固化的一行 if 都没有指令序列完全可预测。控制逻辑越复杂浪费的电和面积就越多这就是控制开销的由来。第二类叫内存墙。这是最要命的一道墙。AI 算子的本质是“把权重搬过来和数据做乘加计算”搬运的速度主导了整个算子的执行时间。你可以把 GPU 想象成一个巨大的收费站计算单元是收费窗口内存系统是通向窗口的引道。GPU 的数据要穿过全局显存、L2 缓存、共享内存、寄存器才能到达计算单元。这一路上每一级存储之间的带宽都不一样但最低的那一级决定了整体速度。实际算力再高只要数据搬不过来ALU 也是空转的。第三类表现为低利用率。你可能在调优时用软件看过显卡的占用率如果你跑的是实时语义分割或者大模型推理占用率常常只有三成到五成剩下的时间就是在等数据。你可以把计算单元看成出租车司机大多数时候车是空的但引擎还在怠速运转油没少烧乘客没多拉。我见过不少同行在优化 GPU 推理性能时把数据排布、算子和 CUDA 流都折腾到极致最终卡住的往往是某个内存访问没对齐、某个合批太小、调度太频繁这些都是控制开销和内存墙在应用层的具体表现。换个说法GPU 不是不能算而是在 AI 这件事上绕了太多路。2. 换一条路数据流架构如何绕过“单行道”2.1 指令驱动与数据驱动本质差别在哪里GPU 或者说 CPU本质上都属于“指令驱动”的计算模型程序是一条一条指令处理器按照指令流的顺序去取数据、做计算。而数据流架构完全是另一种玩法计算不是被指令拉起来的而是被数据到达这个动作直接推起来的。我帮你打个比方。传统架构像一家餐厅顾客数据进门领位员调度器把他带到桌位缓存服务生加载指令去后厨取菜内存后厨做菜执行单元。每一次接待都要走完整套流程。而数据流架构像一家自助分拣流水线传送带把食材推到第一站第一站自动处理立刻送到第二站第二站又自动处理食材在路上就是指令本身。指令化身为数据的流向没有“取指令”这一步也没有“分配线程”这一步。这个差别放到 AI 推理里就是降维打击。因为 AI 推理天然是一个数据流程序卷积层把特征图算出来直接喂给池化层池化层结果给激活函数激活函数再给全连接层。你为这个算子链预先铺好一条物理通路互联关系在编译期就固定下来数据来了就直接从第一层流到最后一层全程不需要调度器插手。这比让 GPU 一遍遍从指令缓存去拿“下一步干什么”要直接得多。2.2 清微智能的可重构数据流把算法直接“铺”在硬件上清微智能走的是可重构计算路线核心思路是让硬件的互联和功能能在一定程度内按需重组。如果只从现象看它是把 AI 算子映射成一张数据流图然后把这张图用硬件的方式“印”在计算阵列上。也就是说同一个芯片跑卷积神经网络时计算单元之间呈现一种连接方式跑到 Transformer 时计算单元又重组成另一种连接方式。这就是“可重构”三个字的意义。为什么不干脆搞成固定硬连线因为 AI 算法还在演进。固定一个算子比如只加速卷积那 Transformer 类模型来了就浪费一大半硬件。可重构阵列的优势是它保留了一条“重新布线的能力”让计算单元按照当前模型的计算图动态调整互联关系。这在电路层面等价于一个可编程的数据交换网络做通用点的表述就是你给它一张和芯片结构对应的数据流描述文件它就能在下一个周期变成适配新模型的机器。在实操层面清微智能把重点放在了边缘 AI 场景。边缘场景功耗预算非常有限往往只有一两瓦甚至几百毫瓦。GPU 那一套复杂调度和控制逻辑在这种功耗约束下几乎无从发挥。数据流架构没有取指开销算力几乎都花在刀刃上所以能效比非常突出。我观察到的实际选型中很多做智能摄像头、工业质检、机器人控制的团队都开始把可重构数据流芯片列为替代方案因为对时延和功耗的要求GPU 都很难填平。当然可重构也有它的代价。互联网络的晶体管占用率比固定互连更多配置切换本身需要耗时所以它不可能在所有算法上都做到单算子最强它的优势是指令级开销低、能效均衡。一句话概括清微智能的方案更像一个“随算法变形的高效流水线工厂”而不是一个固定流程的流水线。2.3 Groq 的 TSP把调度提前到编译期的激进打法再来看 Groq它的打法比清微智能更极致。Groq 做了一个叫做张量流处理器Tensor Streaming ProcessorTSP的架构核心特点是运行时无所谓调度一切都在编译期被安排得明明白白。你怎么理解这句话在 GPU 里调度器是根据当前时刻可用的计算资源动态决定哪个线程接着跑TSP 则完全不用“决定”。编译器在生成代码时就知道每一个 ALU 在哪个周期计算哪一笔数据、数据从哪个 SRAM 读取、什么时候写回相当于开一场事先完全彩排好的大型演出每个演员每一个节拍都知道自己该站哪。TSP 的另一张王牌是存储策略。它不需要像 GPU 那样依赖全局显存做大规模数据中转而是把数百 MB 的 SRAM 直接堆在芯片上计算单元之间通过极宽的片上网络传输数据。SRAM 的带宽比 DRAM 高好几个数量级延迟也低得多这让单芯片推理延迟能做到非常惊艳的水平。Groq 早期展示过很多低时延推理场景根本不是靠把 GPU 超频超上去的也不是靠塞更多的核心堆出来的纯粹就是从“数据在路上花的时间”这个根上砍掉了大半。但立硬币都有正反面。TSP 的代价是“静态调度”非常依赖编译器的提前布局一旦运行时的模型有动态形状、条件分支、稀疏计算比如 NLP 里按句子长度做 Padding、推荐系统里稀疏特征查询编译器的日子就会非常难过生成的调度可能远不是最优。而且 SRAM 虽然快但它单位面积贵TSP 很难把片上容量做到几十 GB所以跑超大模型时要么把模型切成好几块放到多个芯片上要么就得跟外部高带宽存储做配合这时芯片与芯片之间的互联带宽又成了新的瓶颈。3. 为什么“打补丁”救不了 GPU 单行道3.1 硬件补丁的物理尽头有人会说GPU 厂商不是一直在改吗加 Tensor Core加更大的 L2 缓存提升 HBM 带宽甚至搞出直接访问存储的方案。这些都在缓解内存墙但为什么说解不了因为内存墙的本质是物理布局和功耗问题。数据在片外 DRAM 和片上缓存之间每搬运一次要消耗远超于算一次乘加的能量。你加宽 HBM 通道加多缓存容量本质上只是把单行道扩宽成双车道、四车道但方向还是那条固定的路。数据从权重到执行单元之间穿越的层级并没有变少。GPU 的市场定位决定了它必须兼容大量工作负载所以它内部的数据路径必然是一个折中方案这个折中方案对 AI 推理来说就是绕远路。我比较喜欢拿生活里的情况来类比GPU 的改良像把一条城市的城市快速路从四车道改成八车道但所有车仍然要经过同一个高架出口去往同一个园区。你得在高峰期等红绿灯因为所有数据仍然要在同一套调度逻辑的指挥下按顺序前进。数据流芯片则是在隔壁直接修了一条高架直连园区绕开了整座城市的红绿灯。前者再宽后者依然更短。3.2 生态是另一堵更硬的墙改硬件难改软件生态难上加难。GPU 最核心的护城河其实不是硬件性能而是生态。全世界搞深度学习的开发者几乎都在用某个深度学习框架写模型框架底层又自动接好 GPU 厂商提供的算子库推理优化工具链也早已成熟。你训练、调优、部署一条龙都有配套的调试器和性能分析器遇到性能问题社区里随手一搜就有前人踩过的坑。而数据流架构的芯片每做一个算子都得自己去写编译器规则、算子映射、量化支持、推理框架的对接。别人用 GPU跑一个动态尺寸的模型调一下库里的一个参数就行用数据流芯片可能要改模型结构、改数据路径、重写优化逻辑。这种用户层面的割裂感很容易让项目负责人放弃选择。哪怕芯片性能再亮眼只要不能让团队在三天内跑通一个现有模型采购价值就会大打折扣。这也是为什么我一直强调数据流芯片能不能生存下来不只看硬件参数更要看编译器和一个足够完善的算子库能够支撑多少业务实际要跑的模型。所谓“改变 GPU 单行道”不是你把一条路修得更窄更直就完了还要让人愿意搬家过来。3.3 游戏基因对 AI 路线的拖累再往深一层看GPU 的晶体管预算里混进了太多游戏渲染专用的东西。光线追踪单元、纹理单元、光栅化器、顶点着色器这些模块在 AI 推理里基本属于“睡大觉”的驻场员工。你会发现哪怕是最顶级的显卡你把 AI 推理跑到满血也是很难把每个晶体管都激活的因为那些渲染核心根本不在 AI 这条工作流里。数据流架构的晶体管规划则是另一种逻辑它可以集中全部面积做乘加运算、片上存储和互联网络。同一个工艺节点下数据流芯片的“有效算力密度”会有明显优势。正因为 GPU 要考虑太多负载它才成为一条谁都能走的单行道数据流芯片却可以为了 AI 这个“特定方向”把路修成专门的高架。但要公平补一句单行道也不是一无是处。GPU 在训练任务上依然是统治级的存在因为训练意味着大量动态分支、梯度回传、稀疏激活、动态形状所有这些都对数据流架构不友好。你不能拿推理的优势去否定训练领域 GPU 的优势。所谓改变单行道准确说是“在 AI 推理这条具体道路上存在更直接的路径”。4. 改变的可能性三条最可能的突破口4.1 推理部署数据流架构的主场推理任务有一个让数据流架构极其舒服的特性计算图固定、算子确定、没有动态控制流。你在部署前已经把模型结构全部定下来了数据流芯片完全可以提前把整个计算图“焊”在硬件上。这个特性让它能实现极低时延和极高的吞吐稳定性而且部署时几乎不需要考虑运行时调度抖动。云端推理供应商对“P99 时延”极度敏感。传统 GPU 因为线程调度的随机性时延抖动是客观存在的同一批请求某些请求可能会因为等缓存行而多走几条弯道。数据流架构的静态调度保证了每个 token 的处理路径完全一致时延分布极其集中。我在接触一些做 AI 推理服务架构的朋友时发现他们对时延方差的重视频率远高于平均时延因为这直接关系到花钱买计算力的用户如何评估服务稳定性。从这个角度说Groq 把静态调度当作核心卖点方向是对的。4.2 边缘与端侧低功耗场景不需要 GPU 的复杂度边缘智能设备的需求和云端很不一样。它们没有充足的电量去养一张功耗三百瓦的显卡也不可能靠液冷散热去压住“性能怪兽”它们真正需要的是极低的功耗、可预测的延迟、以及“模型固定后长期稳定运行”的可靠性。数据流架构在这方面天然友好因为它没有取指开销没有复杂的分支预测和调度电路绝大多数能量都直接贡献给有效计算。比如做工业质检的摄像头需在 50 毫秒内完成缺陷判定整机功耗被限制在 5 瓦以内。用传统 GPU 方案要费大力气调优才能实现还要牺牲摄像头模组和散热预算。换用可重构数据流的 AI 芯片把卷积模型映射成硬件数据流图之后可以在更低功耗下跑完相同推理任务。清微智能选择以这里为切入场景踩中的就是 GPU 在低功耗边缘区间“使不上劲”的结构性空白。我还想多说一句边缘市场的碎片化恰恰匹配“可重构”的特性。不同客户的模型结构、传感器输入格式、算子组合差异极大固定硬件的 NPU 往往只能适配其中一部分而可重构阵列在同一款芯片上可以通过切换配置支持不同模型形态这对边缘企业的供应链简化是很有吸引力的。4.3 大模型推理从“单行道”变“多车道立交桥”大模型推理让内存墙的问题被推到聚光灯下。生成一个 token要快速拿到几百 GB 的权重GPU 必须一遍遍从高带宽显存里搬数据。延迟大量消耗在搬运过程中而不是计算过程里。如果能把权重尽量放到离计算单元更近的地方就能成倍缩短“搬运时间”。Groq 的方式就是用巨型 SRAM 把权重装进片上SRAM 的延迟比 DRAM 低一个数量级以上这让单芯片的 token 生成时延非常好看。但大模型动辄几百 GB你不可能全部塞进片上 SRAM于是只能做模型切分把不同层放到不同芯片上让 token 在一块块 TSP 之间流动。这相当于立交桥的匝道设计问题从“内存墙”转化成了“芯片间互联带宽墙”。清微智能在近存计算路径上也有自己的布局即把存储和和计算阵列靠得更近减少数据搬运路径。这些方案没有一家是灵丹妙药但每一家都在尝试打破“数据必须路过大内存体系”的单向路径。如果你的业务是高频调用大模型接口你会发现时延排序里GPU 不一定永远赢数据流芯片在低时延场景往往会有更好的表现。前提是你能接受它的生态尚未完全成熟。5. 常见质疑与现实挑战数据流不是万能钥匙5.1 是“只能做 AI”还是“暂时只做 AI”一个经常被质疑的点数据流芯片是不是只能跑神经网络的固定计算流一碰通用计算就瘫痪我理解的更准确说法是数据流架构是一种通用计算模型而不是 AI 专用硬件。任何能被表示成数据依赖图的计算理论上都可以映射上去。只是现阶段各家的编译器、工具链都优先把算力能力提供给 AI 算子因为这是市场最疼的点。你让一个数据流芯片去跑字符串处理这种不规则的控制逻辑密集型程序编译器很难生成高效的调度图所以从实际效果看短期内确实“只能做 AI”。这就像一条新修的高架快速路当年设计时只开了到产业园区的出口不代表它不能修出口到市区只是眼下的车流需求决定了它先服务产业区。后续如果生态有精力数据流架构做通用计算的边界会慢慢拓宽但那个过程会非常漫长。5.2 编译器与工具链才是真正的硬骨头我反复提到编译器因为这个领域里硬件只占半壁江山。芯片厂商必须交付一个能让开发者无缝使用的编译工具链要把 PyTorch 和 ONNX 框架下的算子无缝映射到自己的数据流图上。算子融合、内存分配、并行调度、量化感知每一步的取舍都会直接反映在最终性能上。你说一个卷积映射到数据流阵列能跑出多高性能答案往往取决于编译器有没有把卷积拆成足够合适的数据通路而不只是硬件本身。我观察过的行业项目里芯片硬件团队常常花一年半出芯片编译器团队可能还要花两年才让这张芯片的可用算子库和调试体验达到及格线。这个时间差会直接拖慢商业落地的节奏。清微智能和 Groq 都意识到了这个问题的严重性投入了大量工程资源在编译链路上。但作为外部观察者我依然会把“工具链成熟度”当成评估这两家潜力的第一指标而不是光看极致的峰值指标。5.3 成本、制造、互联与生态的漫长战斗最后说点更现实的物理和商业约束。Groq 选择大 SRAM 来换速度和可预测性但 SRAM 单元面积远大于 DRAM同样容量下芯片面积大、良率压力大、成本高。跑大模型需要多卡拼起来卡间互联成为新的性能窗口如果互联总线和协议不够高效所有优势都会被“跨芯片搬运”吞掉。清微智能的可重构阵列也面临配置开关的尺寸和延时问题以及工具链映射不同网络的复杂工程量。它瞄准边缘市场目标功耗低单芯片成本控制要求高这要求芯片设计必须在“可重构灵活性”和“面积/成本”之间找到精准平衡。商业上两家都不太可能直接“掀翻”GPU 这个庞然大物。更现实的路径是在 AI 推理这个 GPU 相对不擅长或者功耗预算严苛的细分领域里先长出几万个装机量的根据地再逐步扩展。生态的滚雪球效应也从来不是一蹴而就当年的 GPU 也是花了二十年才从图形卡变成计算卡。我个人的体会是GPU 这条“单行道”短期内不会消失但它已经出现了越来越多可以被绕开的点。数据流架构不是要“推翻”谁而是在 AI 推理、边缘计算和大模型低延迟服务这些场景里提供一条更直接、更高效的路径。如果你正在做 AI 部署或者芯片选型我建议你把“编译器成熟度”和“算子覆盖度”当成比峰值算力更重要的指标多去实际跑一跑业务模型再决定是否要入局。毕竟真正决定单行道能否被改变的不是一两个芯片跑分而是背后那套完整的工具链能不能让更多人轻松走上这条新路。