1. 从一张算力账单说起为什么现在必须看懂AI芯片架构去年帮一个团队做推理集群的成本优化他们拿着一张云厂商的账单来找我说训练和推理的月度开销比预期高了将近三倍。我打开账单一看问题特别典型他们把大量中小规模的推理任务跑在了通用GPU上而这些任务其实用专用加速器能省掉一大半成本。更麻烦的是他们选型的时候只看了一个指标——峰值算力完全没考虑显存带宽、互联拓扑、软件栈成熟度这些真正决定实际吞吐的东西。这件事让我意识到AI芯片这个领域光看参数表是远远不够的。NVIDIA、Google TPU、AMD、Cerebras、AWS Trainium、Groq这几家每一家的架构选择背后都对应着一套完全不同的设计哲学而这些哲学直接决定了你在什么场景下该用谁。这篇文章就是想把这件事讲透不是罗列规格而是拆解每家芯片为什么这么设计以及这些设计在实际落地时会带来什么后果。如果你正在做模型训练或推理的硬件选型或者单纯想搞清楚这几年AI算力格局到底在发生什么变化那这篇内容应该能帮你建立一套判断框架。我会从架构原理讲到实际部署中的坑尽量把每个技术决策背后的权衡说清楚。2. NVIDIA的护城河到底建在哪一层2.1 从CUDA到Tensor Core软件生态才是真正的壁垒很多人讨论NVIDIA的优势第一反应是GPU性能强。这个说法对但没说到点子上。NVIDIA真正的护城河不在硅片而在CUDA这套软件生态上。你可以把CUDA理解成一个翻译层它把开发者写的并行计算逻辑翻译成GPU能高效执行的指令。这套东西从2006年就开始积累到现在几乎所有主流深度学习框架——PyTorch、TensorFlow、JAX——底层都深度依赖CUDA。这就带来一个很现实的问题你换芯片不只是换硬件而是要重写大量底层代码。我见过一个团队尝试把训练任务从NVIDIA迁移到另一家加速器结果发现光是自定义算子就要重写几十个调试周期拉长了好几倍。所以NVIDIA的壁垒是迁移成本而不是单纯的算力数字。再说Tensor Core。这是从Volta架构开始引入的专用矩阵运算单元专门加速混合精度矩阵乘法。它的核心思路是深度学习里绝大部分计算是矩阵乘那就把这个操作做成硬件电路一次算一整个矩阵块而不是一个元素一个元素算。到了Hopper架构Tensor Core已经支持FP8精度配合Transformer Engine能动态选择用FP8还是FP16在保持精度的前提下把吞吐拉上去。2.2 NVLink与互联拓扑多卡扩展的隐形天花板单卡性能再强大模型也装不下。这时候卡间互联就成了瓶颈。NVIDIA的NVLink就是干这个的它让GPU之间直接通信不走PCIe总线。你可以把它想象成PCIe是普通公路NVLink是专用高速。在训练千亿参数模型时梯度同步的数据量极大如果互联带宽不够GPU算得再快也得等着数据传过来。到了Hopper和Blackwell这一代NVLink的带宽已经做到卡间几百GB/s级别配合NVSwitch能组成一个大的互联域。这也是为什么NVIDIA能卖整机柜方案——它不只是卖芯片而是卖一整套互联好的计算单元。实际部署时如果你的模型并行策略没设计好比如张量并行跨了太多节点互联开销会直接吃掉算力收益。我一般建议能放在同一个NVLink域里的通信尽量别跨域。2.3 实际选型中的NVIDIA陷阱说几个我踩过的坑。第一别只看峰值算力。A100的FP16峰值和某些竞品比可能不占优但实际训练吞吐往往更高因为显存带宽和互联更均衡。第二注意显存容量和带宽的匹配。有些卡算力强但显存小跑大模型时频繁换入换出实际效率反而低。第三驱动和CUDA版本兼容性。我遇到过好几次因为CUDA版本和框架不匹配导致训练崩溃的情况建议在环境搭建阶段就把版本矩阵固定下来别频繁升级。3. Google TPU为Transformer而生的专用路线3.1 脉动阵列的取舍逻辑Google TPU最核心的设计是脉动阵列Systolic Array。这个概念说起来有点抽象我打个比方普通计算单元像是一个个独立的工人各自去内存取数据、算完再放回去脉动阵列则像一条流水线数据从一端流入经过一排排计算单元每个单元做一小步乘加结果自然流向下一站。这样数据复用率极高不需要反复访问内存。这个设计的代价是灵活性。脉动阵列特别适合规则的矩阵运算但遇到不规则的计算图就会效率下降。所以TPU从诞生起就是冲着神经网络来的尤其是Transformer这类结构规整的模型。到了TPU v4、v5这一代Google还引入了光互联OCS把多个TPU芯片组成一个可重构的超级计算域。这个思路和NVIDIA的NVLink域类似但规模更大适合超大规模训练。3.2 XLA编译器TPU的隐形操作系统TPU的软件栈核心是XLAAccelerated Linear Algebra。它和CUDA的定位不同CUDA更像底层指令集XLA则是图级别的编译器。你用JAX或TensorFlow写模型XLA会把整个计算图编译成TPU能执行的指令序列过程中做大量算子融合和内存优化。这个模式的好处是对于标准模型XLA能自动优化出很高的效率开发者不用手写太多底层代码。坏处是一旦你的模型有XLA不支持的算子或者动态形状特别多编译就会失败或者效率骤降。我见过有人用TPU跑自定义注意力变体结果因为动态控制流太多性能还不如GPU。3.3 什么场景下TPU真的划算TPU的性价比优势主要体现在大规模、结构规整的训练任务上。如果你的模型是标准Transformer训练规模又大TPU集群的单位算力成本往往比GPU低。但如果你做的是研究型工作模型结构频繁变动或者需要大量自定义算子TPU的调试成本会很高。另外TPU基本只在Google Cloud上可用这意味着你的技术栈要和GCP绑定。对于已经在GCP上的团队这是加分项对于多云策略的团队就要考虑锁定风险。我的建议是先用小规模TPU做验证确认模型能顺利编译且效率达标再考虑大规模迁移。4. AMD的追赶策略开放生态能不能撬动格局4.1 ROCm与CUDA的差距到底在哪AMD的MI系列加速器在硬件参数上已经很有竞争力比如MI300X的显存容量和带宽都很能打。但软件生态是短板。ROCm是AMD对标CUDA的开放计算平台这几年进步很快但和CUDA比仍有差距。差距主要体现在几个方面一是算子库覆盖度CUDA有cuDNN、cuBLAS这些高度优化的库ROCm对应的库在部分算子上还不够成熟二是框架支持PyTorch对ROCm的支持已经不错但一些第三方库和自定义CUDA算子迁移起来还是麻烦三是社区积累遇到问题时CUDA的解决方案一搜一大把ROCm相对少。不过AMD走的是开放路线ROCm是开源的这对一些有强工程能力、希望避免单一供应商锁定的团队有吸引力。我认识一个团队就是看中这点投入人力做ROCm适配长期看确实降低了成本。4.2 MI300系列的架构亮点MI300X采用Chiplet设计把多个计算芯粒和内存芯粒封装在一起。这个思路的好处是良率高、成本可控而且能灵活组合不同数量的芯粒。它的显存容量做得很大单卡能装下更大的模型减少卡间通信。对于推理场景这意味着可以用更少的卡跑同样的模型降低互联开销。实际使用中MI300X在显存密集型任务上表现不错比如大模型推理、长上下文处理。但在需要极致算力密度的训练任务上和NVIDIA最新代际比还有差距。选型时要看你的瓶颈到底在算力还是在显存。4.3 迁移到AMD的实操建议如果你考虑用AMD我的建议是分三步走。第一步先做算子兼容性扫描把模型里用到的所有算子列出来逐个确认ROCm是否支持。第二步在小规模集群上跑通训练流程重点看收敛性和稳定性。第三步做性能对比别只看峰值要看端到端的训练时间。有个细节容易被忽略ROCm的版本和PyTorch版本有严格的对应关系装错版本会导致各种奇怪的问题。建议用官方推荐的Docker镜像起步别自己从源码编译除非你确实需要定制。5. Cerebras与Groq把大和快做到极致的两种极端5.1 Cerebras的晶圆级引擎一颗芯片装下整个模型Cerebras的做法非常激进直接把整片晶圆做成一颗芯片WSEWafer Scale Engine的尺寸远超普通芯片。这么做的好处是片上内存极大模型可以完全放在芯片内不需要频繁访问外部显存。你可以理解为普通GPU是厨房小、冰箱大做菜要不停跑冰箱Cerebras是厨房就是冰箱所有食材伸手就能拿到。这个设计对某些场景特别有优势比如需要超大内存带宽的稀疏模型训练、长序列处理。但代价是制造难度极高成本也高而且芯片坏了整片报废。它的目标客户主要是超大规模训练和特定科研场景不是通用市场。5.2 Groq的确定性执行把延迟压到极致Groq走的是另一条路LPULanguage Processing Unit采用确定性执行架构没有传统GPU那种复杂的调度和缓存层次。它的思路是既然推理任务的算力需求相对固定那就把执行流程做成完全可预测的数据流动像流水线一样精确。这个设计让Groq在推理延迟上表现非常突出特别适合对响应时间敏感的场景比如实时对话、在线服务。但它的内存容量相对有限跑超大模型需要多卡组合而且生态还在建设中。我实测过一些推理任务Groq的吞吐和延迟确实亮眼但模型适配需要花功夫。5.3 这两类芯片适合谁Cerebras和Groq都不是通用替代品而是针对特定痛点的专用工具。Cerebras适合那些被内存带宽卡住、模型大到普通集群装不下的训练任务Groq适合推理延迟是核心指标的在线服务。选它们之前先问自己我的瓶颈到底是算力、显存、带宽还是延迟如果答案是前三个可能通用GPU更合适如果是延迟Groq值得评估。6. AWS Trainium云厂商自研芯片的算盘6.1 为什么要自研AWS做Trainium的逻辑很直接云上大量AI负载如果都用NVIDIA GPU成本大头被上游拿走而且供应受制于人。自研芯片能把成本压下来还能和自家云服务深度整合。Trainium配合Neuron SDK目标是让用户在AWS上训练和推理时有一个更便宜的选项。这个模式和Google TPU类似都是云厂商自研芯片专用软件栈的组合。区别在于AWS的生态更开放一些Trainium支持PyTorch等主流框架迁移成本相对可控。6.2 Neuron SDK的实际体验Neuron SDK是Trainium的软件入口它负责把框架层的模型编译成芯片能执行的指令。实际用下来标准模型迁移比较顺但自定义算子还是需要额外工作。它的编译过程有点像XLA对静态图友好动态控制流多了会麻烦。成本方面Trainium的单位算力价格确实比同代GPU有优势尤其适合长期、稳定的训练任务。但如果你需要频繁试验新结构或者对生态成熟度要求高GPU还是更稳妥。6.3 云厂商自研芯片的共同挑战不管是TPU还是Trainium都面临同一个问题软件生态的成熟度需要时间积累。硬件可以一代追上来但开发者习惯、算子库、社区支持这些软实力不是砸钱就能快速补齐的。所以这类芯片目前的定位更多是在特定场景下提供性价比选项而不是全面替代。对使用者的建议是如果你的负载高度标准化、规模大、成本敏感值得认真评估云厂商自研芯片如果你的负载多变、需要快速迭代通用GPU的灵活性更值钱。7. 架构对比一张表看清六家的设计取舍厂商核心架构思路优势场景主要短板软件栈NVIDIA通用GPU Tensor Core NVLink训练推理全场景成本高、供应紧张CUDA最成熟Google TPU脉动阵列 光互联大规模标准Transformer训练灵活性低、绑定GCPXLA/JAXAMDChiplet 开放ROCm显存密集型推理生态成熟度不足ROCm进步中Cerebras晶圆级集成超大模型、内存带宽瓶颈成本极高、场景窄专用编译栈Groq确定性执行低延迟推理内存有限、生态早期专用工具链AWS Trainium云自研 Neuron成本敏感的标准化训练生态建设中Neuron SDK这张表不是让你直接照着选而是帮你建立判断维度。实际选型时我一般会按这个顺序问第一我的瓶颈是什么算力/显存/带宽/延迟/成本第二我的模型结构稳定吗第三我的团队工程能力如何第四我能不能接受供应商锁定这四个问题的答案基本就决定了方向。8. 落地时的几个真实教训第一个教训别被峰值算力忽悠。我见过太多选型报告只列TFLOPS但实际训练吞吐取决于显存带宽、互联、软件效率的综合。建议做POC时直接跑自己的模型看端到端时间别信纸面参数。第二个教训软件栈的坑比硬件深。硬件不行可以换软件不兼容会让你连跑都跑不起来。选型时一定要确认框架版本、算子支持、调试工具是否齐全。第三个教训互联拓扑决定多卡效率。大模型训练不是单卡游戏卡间通信设计不好加卡反而可能变慢。选型时要看互联带宽和拓扑是否匹配你的并行策略。第四个教训成本要算总账。芯片单价只是其中一项还要算上迁移成本、运维成本、电力成本、机会成本。有些方案芯片便宜但迁移贵总体未必划算。第五个教训别把鸡蛋放一个篮子。供应链波动这几年很常见有条件的话至少保持两条技术路线的能力避免被单一供应商卡住。9. 我个人的判断框架这几年看下来我的体会是AI芯片选型没有最好只有最合适。NVIDIA强在生态和通用性适合大多数团队作为主力TPU和Trainium在特定云环境下有成本优势适合标准化大规模负载AMD是值得关注的开放选项适合有工程能力、想降低锁定的团队Cerebras和Groq是专用工具解决特定瓶颈。如果你刚开始做选型我的建议是先用NVIDIA把流程跑通建立基线然后再评估其他方案能不能在特定环节降本增效。别一上来就追求最优解先把能跑通这件事解决再谈优化。最后分享一个小技巧做芯片对比时别只看厂商给的benchmark去找和你模型结构相近的公开案例看实际吞吐和成本。厂商的测试往往用最优配置真实场景的差距可能很大。多问几个用过的人比看十份白皮书都有用。
