1. 从一颗芯片说起为什么AI芯片架构值得每个从业者吃透过去两年我身边做模型训练、推理部署、集群运维的朋友聊得最多的话题之一就是卡从哪来、怎么选、怎么用满。大模型参数量从几十亿冲到万亿级算力需求几乎是每几个月翻一番而支撑这一切的底层硬件——AI芯片成了整个行业最硬的瓶颈。NVIDIA、Google TPU、AMD、Cerebras、AWS Trainium、Groq 这几家基本代表了当下AI芯片架构的几条主要技术路线。搞懂它们的差异不只是硬件工程师的事做算法、做平台、做成本预算的人都得心里有数。这篇内容我想干一件事把这几家主流AI芯片的架构思路、设计取舍、适用场景和背后的趋势掰开揉碎讲清楚。不是那种罗列参数的新闻稿而是从为什么这么设计的角度切入让你看完能自己判断——手上这个训练任务或者推理服务到底该往哪种架构上放。适合谁看做AI基础设施的、搞模型部署的、负责算力采购和成本优化的以及单纯想搞明白GPU和TPU到底差在哪的技术爱好者。我会尽量用生活化的类比把复杂概念讲透同时把关键参数和实操要点给足让你能直接拿去参考。先说一个贯穿全文的核心判断AI芯片的竞争本质上是计算单元、存储层次、互连带宽这三者之间的平衡艺术。谁能在特定负载下把这三者的配比调得最合适谁就能在那一类任务上跑出性价比。下面我们逐个拆。2. 六大AI芯片架构的核心设计思路拆解2.1 NVIDIA通用GPU路线的生态护城河NVIDIA的AI芯片核心是GPU这条通用并行计算路线。从Volta架构引入Tensor Core开始NVIDIA就把通用性和专用加速做了结合——SM流式多处理器负责通用并行计算Tensor Core专门啃矩阵乘加这类深度学习最吃算力的操作。到了HopperH100和BlackwellB200/GB200这一代架构演进的逻辑非常清晰把越来越多的专用单元塞进通用GPU里同时用超高速互连把成千上万颗芯片连成一个逻辑上的大芯片。为什么NVIDIA能一直领跑我的理解是三点。第一是CUDA生态十几年积累下来的算子库、编译器、调试工具、社区文档形成了极高的迁移成本你换芯片容易换生态难。第二是NVLink和NVSwitch这套互连方案让多卡通信带宽远超PCIe训练大模型时通信不再是致命瓶颈。第三是产品迭代节奏稳几乎每两年一代制程、显存、带宽同步升级客户能预期。具体到架构细节以H100为例它搭载了第四代Tensor Core支持FP8精度这对大模型训练和推理都很关键——FP8相比FP16能把显存占用和带宽需求砍半精度损失在多数场景可接受。H100的HBM3显存带宽约3.35TB/s这个数字决定了它能多快地把数据喂给计算单元。而Blackwell进一步把单卡显存推到HBM3e带宽和容量再上一个台阶同时GB200这种超级芯片把两颗GPU和一颗Grace CPU用NVLink-C2C连在一起本质是在单封装内解决CPU-GPU数据搬运的延迟问题。提示很多人只盯着算力TFLOPS选卡其实对Transformer类模型显存带宽和互连带宽往往比峰值算力更能决定实际吞吐。选型时先算你的模型显存占用和通信量再看算力。2.2 Google TPU为矩阵运算而生的 systolic arrayGoogle TPU走的是完全不同的路子——专用集成电路ASIC。TPU从第一代开始就围绕一个核心结构systolic array脉动阵列。你可以把它想象成一条流水线数据像血液一样在计算单元阵列里脉动流过每个单元做一次乘加就把结果传给下一个极大减少了数据搬运。这种结构对矩阵乘法极其高效而矩阵乘法正是神经网络里占比最高的运算。TPU的设计哲学是够用就好专款专用。它不像GPU那样什么都能算但凡是它能算的矩阵密集型的深度学习负载单位功耗和单位成本的效率往往更高。TPU的另一个特点是围绕它构建了完整的软件栈——XLA编译器和JAX/PyTorch的对接让模型能自动映射到TPU的硬件结构上。Google自己用TPU训练Gemini这类大模型等于用真实超大负载在打磨这套软硬件。TPU的互连也很有特色Pod级别的光互连OCS让成千上万颗TPU能组成一个超大集群Google在数据中心层面做了很多网络创新。这套方案的优势是规模化能力强缺点是生态相对封闭你基本得在Google Cloud上用迁移自由度不如GPU。2.3 AMD用开放生态撬动GPU市场的挑战者AMD的AI芯片Instinct系列如MI300X走的是GPU路线和NVIDIA正面竞争。它的核心策略可以概括为硬件参数对标甚至局部超越软件生态用开放标准追赶。MI300X在显存容量和带宽上给得很足HBM3192GB级别对需要大显存跑大模型的场景很有吸引力——单卡能装下的模型更大需要切分的卡就更少通信开销自然下降。AMD的关键变量是ROCm软件栈。早期ROCm的成熟度确实和CUDA有差距算子覆盖、框架适配、调试体验都有坑。但这两年进步明显PyTorch对ROCm的支持越来越完善很多主流模型能比较顺地跑起来。AMD还推了统一的内存架构如MI300A里的APU设计把CPU和GPU共享内存减少数据拷贝。我个人的观察是AMD的机会在于不想被单一供应商绑定的客户需求以及大显存场景的性价比。如果你的团队有一定底层调优能力愿意在ROCm上投入AMD是值得认真评估的选项。但如果追求开箱即用、生态无缝短期内NVIDIA仍是默认选择。2.4 Cerebras把整片晶圆做成一颗芯片Cerebras的路线最激进——晶圆级引擎WSE。传统芯片是把一整片晶圆切割成很多小芯片Cerebras反过来直接把整片晶圆做成一颗超大芯片。WSE-3有几十万个核心片上SRAM容量达到几十GB级别内存带宽高得离谱。这么做的逻辑是什么消除片外内存访问的瓶颈。传统GPU算力再强数据也得从HBM里搬来搬去这个搬运过程既慢又耗电。Cerebras把大量内存直接放在片上SRAM计算单元和内存挨得极近带宽和延迟都大幅改善。对那些内存带宽受限的模型这种架构优势明显。代价也很明显晶圆级芯片制造难度极高、良率挑战大、成本高而且它是个大件部署和散热都需要专门设计。Cerebras主要面向超大规模训练和特定高性能计算场景不是通用普及型产品。但它的存在证明了AI芯片架构还有很大的创新空间不一定非得沿着GPU的老路走。2.5 AWS Trainium云厂商自研的降本利器AWS Trainium是亚马逊自研的训练芯片逻辑很直接云厂商最大的成本之一就是买GPU自研芯片能把这块成本降下来同时和自家云服务深度整合。Trainium配合Neuron SDK目标是让客户在AWS上以更低的单位算力成本训练模型。Trainium的架构针对训练负载做了优化支持BF16等训练常用精度通过NeuronLink做芯片间互连。它的优势是和AWS生态绑定——S3、EC2、SageMaker这些服务能比较顺地对接对已经在AWS上的团队迁移成本相对可控。劣势同样是生态Neuron SDK的算子覆盖和社区活跃度和CUDA不在一个量级遇到冷门模型或自定义算子可能要自己动手。这类自研芯片的趋势值得注意云厂商正在从卖别人的算力转向卖自己设计的算力因为这样才能在价格和利润上有主动权。对用户来说好处是多了低价选项坏处是又多了一套要学的软件栈。2.6 Groq为推理延迟而生的确定性架构Groq的芯片LPU主打的是推理场景的超低延迟和确定性。它的架构叫TSP张量流处理器特点是取消了传统GPU里复杂的调度和缓存机制用编译器在编译期就把数据的流动路径规划好运行时几乎不需要动态调度。这带来一个关键好处延迟可预测。对很多实时推理场景比如对话、语音、推荐延迟的稳定性比峰值吞吐更重要。GPU在高负载下延迟会抖动而Groq这种确定性架构能给出比较稳的响应时间。它的代价是灵活性——编译器要提前知道整个计算图动态性强的模型适配起来麻烦而且片上内存有限超大模型需要多芯片协同。Groq代表了一个重要趋势推理专用芯片正在从训练芯片的附属品变成独立赛道。随着推理需求超过训练需求专门为推理优化的架构会越来越多。3. 关键架构参数对比与选型逻辑3.1 一张表看清六家的定位差异厂商架构路线核心优势主要短板典型场景NVIDIA通用GPU Tensor Core生态最成熟、互连强价格高、供应紧张训练推理全场景Google TPUASIC 脉动阵列矩阵运算效率高、规模化强生态封闭、绑定GCP大规模训练AMD通用GPU 开放生态大显存、性价比ROCm成熟度待提升大模型推理、训练Cerebras晶圆级引擎片上带宽极高成本高、部署特殊超大模型训练AWS Trainium云自研ASIC云内成本低、整合好生态较窄AWS内训练Groq确定性推理架构低延迟、延迟稳定灵活性受限实时推理这张表不是让你背而是帮你建立按场景选架构的思维。没有绝对最好的芯片只有最适合你负载和约束的芯片。3.2 选型时真正该算的三个账第一个账是显存账。你的模型参数量、激活值、优化器状态加起来需要多少显存如果单卡装不下就要考虑切分切分就意味着通信。粗略估算训练时显存需求约是参数量的16-20倍FP16混合精度优化器状态推理时约是参数量的2倍FP16。这个数字直接决定你要几张卡、要不要上大显存方案。第二个账是带宽账。对推理尤其是自回归生成瓶颈往往在显存带宽——每生成一个token都要把模型权重读一遍。所以推理吞吐 ≈ 显存带宽 / 模型大小。这就是为什么大显存高带宽的卡在推理上吃香。第三个账是通信账。多卡训练时梯度同步的通信量和模型参数量成正比。互连带宽不够算力再强也得等通信。NVLink、TPU的OCS、Trainium的NeuronLink本质都是在解决这个账。注意别被峰值算力忽悠。厂商标的TFLOPS通常是理想条件下的稀疏或低精度峰值实际能跑到多少取决于你的模型结构、batch size、软件栈优化程度。实测永远比标称重要。3.3 精度选择背后的取舍FP32、TF32、BF16、FP16、FP8、INT8、INT4——这些精度不是随便选的。精度越低算力和显存效率越高但数值稳定性和模型质量风险越大。我的经验是训练优先用BF16动态范围大不容易溢出推理可以大胆试FP8甚至INT8/INT4但一定要做精度验证。NVIDIA从Hopper开始原生支持FP8TPU和Trainium也各有自己的精度策略选型时要把目标精度下能不能高效跑作为硬指标。4. 实操如何评估和上手不同架构的芯片4.1 从一次真实的选型评估说起假设你手上有个70B参数的模型要做推理服务预算有限怎么选我的实操流程是这样的第一步算显存。70B参数FP16约140GB单张80GB卡装不下至少两张。如果用INT8量化约70GB单张80GB卡勉强能装。这一步就筛掉了显存不足的方案。第二步算吞吐需求。假设你要支撑每秒100个并发请求每个请求平均生成200个token那总吞吐需求是20000 token/s。用显存带宽/模型大小估算单卡吞吐上限再乘以卡数看能不能满足。第三步看软件栈。你的模型有没有现成的部署方案vLLM、TensorRT-LLM对NVIDIA支持最好对AMD、TPU的支持程度要逐个确认。冷门架构可能要自己写kernel。第四步算总拥有成本。不只看卡价还要算电费、机房、运维人力、迁移成本。自研芯片往往卡价低但迁移成本高要综合看。4.2 环境搭建的通用套路不管你用哪家芯片环境搭建的套路大同小异我总结成一套可复用的流程# 1. 确认驱动和固件版本匹配 # NVIDIA示例 nvidia-smi # 查看驱动版本、CUDA版本、卡型号 # 2. 安装对应版本的运行时和工具链 # 以CUDA为例注意版本要和框架匹配 # 3. 安装框架PyTorch/TensorFlow/JAX # 4. 跑一个最小验证脚本确认能识别设备import torch print(torch.cuda.is_available()) # NVIDIA/AMD(ROCm) print(torch.cuda.device_count()) print(torch.cuda.get_device_name(0))对TPU用JAX的话是jax.devices()对Trainium用Neuron SDK的torch_neuron对Groq用它的SDK。核心都是先确认设备能被识别再谈性能。4.3 性能压测该关注哪些指标上手之后别急着跑业务先做压测。我通常关注这几个指标首token延迟TTFT从请求发出到第一个token返回的时间对话场景体验的关键。每token延迟TPOT生成每个后续token的平均时间。吞吐tokens/s单位时间能生成多少token决定成本。显存占用峰值决定能不能加batch、加并发。多卡扩展效率从1卡到N卡吞吐是不是线性增长掉多少。这些指标用vLLM、TensorRT-LLM这类框架自带的benchmark就能测。测的时候一定要用你自己的真实模型和真实输入长度分布别用官方demo的数据否则结论会偏。提示压测时注意区分计算受限和内存受限。小batch时通常是内存受限大batch时转为计算受限。找到拐点才能配出最优的batch size。4.4 多卡互连的实操要点多卡训练最容易踩的坑是互连配置。以NVIDIA为例NVLink和PCIe的带宽差好几倍如果拓扑没配好卡间通信走了PCIe性能直接腰斩。实操中要确认卡之间的NVLink拓扑用nvidia-smi topo -m看NCCL的配置NCCL_DEBUGINFO看通信走的是哪条路是否启用了GPUDirect RDMA跨节点通信时对TPUPod内的互连是Google管好的你主要关注切片slice的拓扑。对TrainiumNeuronLink的配置要看AWS文档。核心原则一样让通信走最快的路径别让数据绕远路。5. 常见问题与排查技巧实录5.1 驱动和环境的经典坑做AI芯片相关的工作驱动问题能占掉一半的排查时间。我整理了几个高频问题问题现象常见原因排查思路设备识别不到驱动未装/版本不匹配查驱动版本重装匹配版本框架报CUDA版本错误框架编译版本与运行时不一致对齐CUDA/torch版本多卡通信慢拓扑没走NVLink查topo配NCCL显存OOM但看着没满碎片化/缓存未释放调batch清缓存性能远低于预期精度/算子未优化查是否走了慢路径驱动这块我的建议是锁定版本别追新。生产环境用经过验证的稳定版本组合驱动CUDA框架升级前先在测试环境验证。很多人图省事直接装最新版结果框架不兼容反而耽误事。5.2 生态迁移的真实成本从NVIDIA迁到其他架构最大的成本不是改代码而是踩那些没人踩过的坑。CUDA上遇到问题搜一下基本有答案ROCm或Neuron上遇到问题可能得自己啃源码或提issue。我的经验是迁移前先做小规模验证挑一个代表性模型跑通全流程评估工作量再决定要不要大规模迁。别一上来就全量迁移容易翻车。5.3 成本优化的几个实操技巧混合精度能上FP8/INT8就上先验证精度再上线。量化推理场景量化收益巨大但要注意量化方法和校准数据。批处理合理增大batch能提升吞吐但要平衡延迟。KV Cache优化长上下文场景KV Cache能占大量显存用PagedAttention这类技术优化。按需选卡不是所有任务都需要顶配卡推理用小卡、训练用大卡别浪费。5.4 一个我踩过的坑早期我做过一次跨架构迁移模型在NVIDIA上跑得好好的迁到另一家架构后精度掉了。排查了很久才发现是某个算子在目标架构上的实现精度策略不同导致累积误差。后来我养成了一个习惯迁移后一定要做逐层输出对比把关键层的输出和原架构对齐定位精度偏差出在哪一层。这个习惯帮我省了很多返工时间。6. 趋势判断AI芯片接下来往哪走6.1 训练和推理的分化会越来越明显过去大家用同一批卡既训练又推理现在这个界限在模糊。训练追求极致算力和互连推理追求低延迟和高吞吐性价比。Groq这类推理专用芯片的崛起以及各家纷纷推出推理优化版本说明市场正在细分。对从业者来说意味着选型时要更明确地区分训练集群和推理集群别用一套方案硬套。6.2 内存墙是共同敌人不管哪家架构都在和内存墙作斗争——算力增长快内存带宽增长慢数据搬运成了瓶颈。Cerebras用片上SRAM、NVIDIA用HBM3e、各家都在堆带宽本质都是在缓解这个问题。未来谁能更好地解决数据搬运谁就能占先机。这也是为什么HBM产能成了整个行业的卡脖子环节。6.3 软件生态的竞争才刚开始硬件参数可以追生态壁垒难破。NVIDIA的CUDA护城河短期内难以撼动但开放标准如OpenXLA、ROCm和云厂商自研栈正在形成各自的势力范围。对用户来说多掌握一套软件栈就多一份议价能力和选择自由。我建议至少深入了解两家的栈别把鸡蛋放一个篮子里。6.4 云厂商自研芯片会持续加码AWS Trainium、Google TPU的成功会激励更多云厂商自研。逻辑很简单算力是云的核心成本自研能降本、能差异化、能绑定客户。未来几年云上可选的芯片种类会更多价格战也会更激烈。对用户是好事但选型复杂度也上去了。6.5 精度和算法的协同设计低精度FP8、INT4的普及不只是硬件的事还需要算法配合——量化感知训练、混合精度策略、数值稳定性处理。未来芯片和算法的协同设计会越来越紧密做算法的人也得懂点硬件做硬件的人也得懂点模型。7. 我个人的一些实操体会折腾了这么多架构我最深的体会是别迷信任何单一方案也别被参数表牵着走。真正决定成败的是你的负载特性、团队能力和成本约束三者的匹配度。NVIDIA生态最省心但最贵TPU规模化强但绑定深AMD性价比有吸引力但要投入调优Cerebras和Groq在特定场景有奇效但不通用Trainium在AWS内很香但出了云就难说。我的建议是先把手上的负载摸清楚——显存、带宽、通信、延迟这四个数算明白了选型自然清晰。然后小规模验证别一上来就 all in。最后保持学习这个领域变化太快今天的最优解明天可能就变了。最后分享一个小技巧评估新架构时我会先跑一个三件套——一个矩阵密集的算子、一个内存密集的算子、一个通信密集的算子分别看性能。这三个数基本能勾勒出这颗芯片的性格比看任何宣传材料都靠谱。 六大AI芯片架构深度拆解：从NVIDIA到Groq的选型逻辑与实操指南
1. 从一颗芯片说起为什么AI芯片架构值得每个从业者吃透过去两年我身边做模型训练、推理部署、集群运维的朋友聊得最多的话题之一就是卡从哪来、怎么选、怎么用满。大模型参数量从几十亿冲到万亿级算力需求几乎是每几个月翻一番而支撑这一切的底层硬件——AI芯片成了整个行业最硬的瓶颈。NVIDIA、Google TPU、AMD、Cerebras、AWS Trainium、Groq 这几家基本代表了当下AI芯片架构的几条主要技术路线。搞懂它们的差异不只是硬件工程师的事做算法、做平台、做成本预算的人都得心里有数。这篇内容我想干一件事把这几家主流AI芯片的架构思路、设计取舍、适用场景和背后的趋势掰开揉碎讲清楚。不是那种罗列参数的新闻稿而是从为什么这么设计的角度切入让你看完能自己判断——手上这个训练任务或者推理服务到底该往哪种架构上放。适合谁看做AI基础设施的、搞模型部署的、负责算力采购和成本优化的以及单纯想搞明白GPU和TPU到底差在哪的技术爱好者。我会尽量用生活化的类比把复杂概念讲透同时把关键参数和实操要点给足让你能直接拿去参考。先说一个贯穿全文的核心判断AI芯片的竞争本质上是计算单元、存储层次、互连带宽这三者之间的平衡艺术。谁能在特定负载下把这三者的配比调得最合适谁就能在那一类任务上跑出性价比。下面我们逐个拆。2. 六大AI芯片架构的核心设计思路拆解2.1 NVIDIA通用GPU路线的生态护城河NVIDIA的AI芯片核心是GPU这条通用并行计算路线。从Volta架构引入Tensor Core开始NVIDIA就把通用性和专用加速做了结合——SM流式多处理器负责通用并行计算Tensor Core专门啃矩阵乘加这类深度学习最吃算力的操作。到了HopperH100和BlackwellB200/GB200这一代架构演进的逻辑非常清晰把越来越多的专用单元塞进通用GPU里同时用超高速互连把成千上万颗芯片连成一个逻辑上的大芯片。为什么NVIDIA能一直领跑我的理解是三点。第一是CUDA生态十几年积累下来的算子库、编译器、调试工具、社区文档形成了极高的迁移成本你换芯片容易换生态难。第二是NVLink和NVSwitch这套互连方案让多卡通信带宽远超PCIe训练大模型时通信不再是致命瓶颈。第三是产品迭代节奏稳几乎每两年一代制程、显存、带宽同步升级客户能预期。具体到架构细节以H100为例它搭载了第四代Tensor Core支持FP8精度这对大模型训练和推理都很关键——FP8相比FP16能把显存占用和带宽需求砍半精度损失在多数场景可接受。H100的HBM3显存带宽约3.35TB/s这个数字决定了它能多快地把数据喂给计算单元。而Blackwell进一步把单卡显存推到HBM3e带宽和容量再上一个台阶同时GB200这种超级芯片把两颗GPU和一颗Grace CPU用NVLink-C2C连在一起本质是在单封装内解决CPU-GPU数据搬运的延迟问题。提示很多人只盯着算力TFLOPS选卡其实对Transformer类模型显存带宽和互连带宽往往比峰值算力更能决定实际吞吐。选型时先算你的模型显存占用和通信量再看算力。2.2 Google TPU为矩阵运算而生的 systolic arrayGoogle TPU走的是完全不同的路子——专用集成电路ASIC。TPU从第一代开始就围绕一个核心结构systolic array脉动阵列。你可以把它想象成一条流水线数据像血液一样在计算单元阵列里脉动流过每个单元做一次乘加就把结果传给下一个极大减少了数据搬运。这种结构对矩阵乘法极其高效而矩阵乘法正是神经网络里占比最高的运算。TPU的设计哲学是够用就好专款专用。它不像GPU那样什么都能算但凡是它能算的矩阵密集型的深度学习负载单位功耗和单位成本的效率往往更高。TPU的另一个特点是围绕它构建了完整的软件栈——XLA编译器和JAX/PyTorch的对接让模型能自动映射到TPU的硬件结构上。Google自己用TPU训练Gemini这类大模型等于用真实超大负载在打磨这套软硬件。TPU的互连也很有特色Pod级别的光互连OCS让成千上万颗TPU能组成一个超大集群Google在数据中心层面做了很多网络创新。这套方案的优势是规模化能力强缺点是生态相对封闭你基本得在Google Cloud上用迁移自由度不如GPU。2.3 AMD用开放生态撬动GPU市场的挑战者AMD的AI芯片Instinct系列如MI300X走的是GPU路线和NVIDIA正面竞争。它的核心策略可以概括为硬件参数对标甚至局部超越软件生态用开放标准追赶。MI300X在显存容量和带宽上给得很足HBM3192GB级别对需要大显存跑大模型的场景很有吸引力——单卡能装下的模型更大需要切分的卡就更少通信开销自然下降。AMD的关键变量是ROCm软件栈。早期ROCm的成熟度确实和CUDA有差距算子覆盖、框架适配、调试体验都有坑。但这两年进步明显PyTorch对ROCm的支持越来越完善很多主流模型能比较顺地跑起来。AMD还推了统一的内存架构如MI300A里的APU设计把CPU和GPU共享内存减少数据拷贝。我个人的观察是AMD的机会在于不想被单一供应商绑定的客户需求以及大显存场景的性价比。如果你的团队有一定底层调优能力愿意在ROCm上投入AMD是值得认真评估的选项。但如果追求开箱即用、生态无缝短期内NVIDIA仍是默认选择。2.4 Cerebras把整片晶圆做成一颗芯片Cerebras的路线最激进——晶圆级引擎WSE。传统芯片是把一整片晶圆切割成很多小芯片Cerebras反过来直接把整片晶圆做成一颗超大芯片。WSE-3有几十万个核心片上SRAM容量达到几十GB级别内存带宽高得离谱。这么做的逻辑是什么消除片外内存访问的瓶颈。传统GPU算力再强数据也得从HBM里搬来搬去这个搬运过程既慢又耗电。Cerebras把大量内存直接放在片上SRAM计算单元和内存挨得极近带宽和延迟都大幅改善。对那些内存带宽受限的模型这种架构优势明显。代价也很明显晶圆级芯片制造难度极高、良率挑战大、成本高而且它是个大件部署和散热都需要专门设计。Cerebras主要面向超大规模训练和特定高性能计算场景不是通用普及型产品。但它的存在证明了AI芯片架构还有很大的创新空间不一定非得沿着GPU的老路走。2.5 AWS Trainium云厂商自研的降本利器AWS Trainium是亚马逊自研的训练芯片逻辑很直接云厂商最大的成本之一就是买GPU自研芯片能把这块成本降下来同时和自家云服务深度整合。Trainium配合Neuron SDK目标是让客户在AWS上以更低的单位算力成本训练模型。Trainium的架构针对训练负载做了优化支持BF16等训练常用精度通过NeuronLink做芯片间互连。它的优势是和AWS生态绑定——S3、EC2、SageMaker这些服务能比较顺地对接对已经在AWS上的团队迁移成本相对可控。劣势同样是生态Neuron SDK的算子覆盖和社区活跃度和CUDA不在一个量级遇到冷门模型或自定义算子可能要自己动手。这类自研芯片的趋势值得注意云厂商正在从卖别人的算力转向卖自己设计的算力因为这样才能在价格和利润上有主动权。对用户来说好处是多了低价选项坏处是又多了一套要学的软件栈。2.6 Groq为推理延迟而生的确定性架构Groq的芯片LPU主打的是推理场景的超低延迟和确定性。它的架构叫TSP张量流处理器特点是取消了传统GPU里复杂的调度和缓存机制用编译器在编译期就把数据的流动路径规划好运行时几乎不需要动态调度。这带来一个关键好处延迟可预测。对很多实时推理场景比如对话、语音、推荐延迟的稳定性比峰值吞吐更重要。GPU在高负载下延迟会抖动而Groq这种确定性架构能给出比较稳的响应时间。它的代价是灵活性——编译器要提前知道整个计算图动态性强的模型适配起来麻烦而且片上内存有限超大模型需要多芯片协同。Groq代表了一个重要趋势推理专用芯片正在从训练芯片的附属品变成独立赛道。随着推理需求超过训练需求专门为推理优化的架构会越来越多。3. 关键架构参数对比与选型逻辑3.1 一张表看清六家的定位差异厂商架构路线核心优势主要短板典型场景NVIDIA通用GPU Tensor Core生态最成熟、互连强价格高、供应紧张训练推理全场景Google TPUASIC 脉动阵列矩阵运算效率高、规模化强生态封闭、绑定GCP大规模训练AMD通用GPU 开放生态大显存、性价比ROCm成熟度待提升大模型推理、训练Cerebras晶圆级引擎片上带宽极高成本高、部署特殊超大模型训练AWS Trainium云自研ASIC云内成本低、整合好生态较窄AWS内训练Groq确定性推理架构低延迟、延迟稳定灵活性受限实时推理这张表不是让你背而是帮你建立按场景选架构的思维。没有绝对最好的芯片只有最适合你负载和约束的芯片。3.2 选型时真正该算的三个账第一个账是显存账。你的模型参数量、激活值、优化器状态加起来需要多少显存如果单卡装不下就要考虑切分切分就意味着通信。粗略估算训练时显存需求约是参数量的16-20倍FP16混合精度优化器状态推理时约是参数量的2倍FP16。这个数字直接决定你要几张卡、要不要上大显存方案。第二个账是带宽账。对推理尤其是自回归生成瓶颈往往在显存带宽——每生成一个token都要把模型权重读一遍。所以推理吞吐 ≈ 显存带宽 / 模型大小。这就是为什么大显存高带宽的卡在推理上吃香。第三个账是通信账。多卡训练时梯度同步的通信量和模型参数量成正比。互连带宽不够算力再强也得等通信。NVLink、TPU的OCS、Trainium的NeuronLink本质都是在解决这个账。注意别被峰值算力忽悠。厂商标的TFLOPS通常是理想条件下的稀疏或低精度峰值实际能跑到多少取决于你的模型结构、batch size、软件栈优化程度。实测永远比标称重要。3.3 精度选择背后的取舍FP32、TF32、BF16、FP16、FP8、INT8、INT4——这些精度不是随便选的。精度越低算力和显存效率越高但数值稳定性和模型质量风险越大。我的经验是训练优先用BF16动态范围大不容易溢出推理可以大胆试FP8甚至INT8/INT4但一定要做精度验证。NVIDIA从Hopper开始原生支持FP8TPU和Trainium也各有自己的精度策略选型时要把目标精度下能不能高效跑作为硬指标。4. 实操如何评估和上手不同架构的芯片4.1 从一次真实的选型评估说起假设你手上有个70B参数的模型要做推理服务预算有限怎么选我的实操流程是这样的第一步算显存。70B参数FP16约140GB单张80GB卡装不下至少两张。如果用INT8量化约70GB单张80GB卡勉强能装。这一步就筛掉了显存不足的方案。第二步算吞吐需求。假设你要支撑每秒100个并发请求每个请求平均生成200个token那总吞吐需求是20000 token/s。用显存带宽/模型大小估算单卡吞吐上限再乘以卡数看能不能满足。第三步看软件栈。你的模型有没有现成的部署方案vLLM、TensorRT-LLM对NVIDIA支持最好对AMD、TPU的支持程度要逐个确认。冷门架构可能要自己写kernel。第四步算总拥有成本。不只看卡价还要算电费、机房、运维人力、迁移成本。自研芯片往往卡价低但迁移成本高要综合看。4.2 环境搭建的通用套路不管你用哪家芯片环境搭建的套路大同小异我总结成一套可复用的流程# 1. 确认驱动和固件版本匹配 # NVIDIA示例 nvidia-smi # 查看驱动版本、CUDA版本、卡型号 # 2. 安装对应版本的运行时和工具链 # 以CUDA为例注意版本要和框架匹配 # 3. 安装框架PyTorch/TensorFlow/JAX # 4. 跑一个最小验证脚本确认能识别设备import torch print(torch.cuda.is_available()) # NVIDIA/AMD(ROCm) print(torch.cuda.device_count()) print(torch.cuda.get_device_name(0))对TPU用JAX的话是jax.devices()对Trainium用Neuron SDK的torch_neuron对Groq用它的SDK。核心都是先确认设备能被识别再谈性能。4.3 性能压测该关注哪些指标上手之后别急着跑业务先做压测。我通常关注这几个指标首token延迟TTFT从请求发出到第一个token返回的时间对话场景体验的关键。每token延迟TPOT生成每个后续token的平均时间。吞吐tokens/s单位时间能生成多少token决定成本。显存占用峰值决定能不能加batch、加并发。多卡扩展效率从1卡到N卡吞吐是不是线性增长掉多少。这些指标用vLLM、TensorRT-LLM这类框架自带的benchmark就能测。测的时候一定要用你自己的真实模型和真实输入长度分布别用官方demo的数据否则结论会偏。提示压测时注意区分计算受限和内存受限。小batch时通常是内存受限大batch时转为计算受限。找到拐点才能配出最优的batch size。4.4 多卡互连的实操要点多卡训练最容易踩的坑是互连配置。以NVIDIA为例NVLink和PCIe的带宽差好几倍如果拓扑没配好卡间通信走了PCIe性能直接腰斩。实操中要确认卡之间的NVLink拓扑用nvidia-smi topo -m看NCCL的配置NCCL_DEBUGINFO看通信走的是哪条路是否启用了GPUDirect RDMA跨节点通信时对TPUPod内的互连是Google管好的你主要关注切片slice的拓扑。对TrainiumNeuronLink的配置要看AWS文档。核心原则一样让通信走最快的路径别让数据绕远路。5. 常见问题与排查技巧实录5.1 驱动和环境的经典坑做AI芯片相关的工作驱动问题能占掉一半的排查时间。我整理了几个高频问题问题现象常见原因排查思路设备识别不到驱动未装/版本不匹配查驱动版本重装匹配版本框架报CUDA版本错误框架编译版本与运行时不一致对齐CUDA/torch版本多卡通信慢拓扑没走NVLink查topo配NCCL显存OOM但看着没满碎片化/缓存未释放调batch清缓存性能远低于预期精度/算子未优化查是否走了慢路径驱动这块我的建议是锁定版本别追新。生产环境用经过验证的稳定版本组合驱动CUDA框架升级前先在测试环境验证。很多人图省事直接装最新版结果框架不兼容反而耽误事。5.2 生态迁移的真实成本从NVIDIA迁到其他架构最大的成本不是改代码而是踩那些没人踩过的坑。CUDA上遇到问题搜一下基本有答案ROCm或Neuron上遇到问题可能得自己啃源码或提issue。我的经验是迁移前先做小规模验证挑一个代表性模型跑通全流程评估工作量再决定要不要大规模迁。别一上来就全量迁移容易翻车。5.3 成本优化的几个实操技巧混合精度能上FP8/INT8就上先验证精度再上线。量化推理场景量化收益巨大但要注意量化方法和校准数据。批处理合理增大batch能提升吞吐但要平衡延迟。KV Cache优化长上下文场景KV Cache能占大量显存用PagedAttention这类技术优化。按需选卡不是所有任务都需要顶配卡推理用小卡、训练用大卡别浪费。5.4 一个我踩过的坑早期我做过一次跨架构迁移模型在NVIDIA上跑得好好的迁到另一家架构后精度掉了。排查了很久才发现是某个算子在目标架构上的实现精度策略不同导致累积误差。后来我养成了一个习惯迁移后一定要做逐层输出对比把关键层的输出和原架构对齐定位精度偏差出在哪一层。这个习惯帮我省了很多返工时间。6. 趋势判断AI芯片接下来往哪走6.1 训练和推理的分化会越来越明显过去大家用同一批卡既训练又推理现在这个界限在模糊。训练追求极致算力和互连推理追求低延迟和高吞吐性价比。Groq这类推理专用芯片的崛起以及各家纷纷推出推理优化版本说明市场正在细分。对从业者来说意味着选型时要更明确地区分训练集群和推理集群别用一套方案硬套。6.2 内存墙是共同敌人不管哪家架构都在和内存墙作斗争——算力增长快内存带宽增长慢数据搬运成了瓶颈。Cerebras用片上SRAM、NVIDIA用HBM3e、各家都在堆带宽本质都是在缓解这个问题。未来谁能更好地解决数据搬运谁就能占先机。这也是为什么HBM产能成了整个行业的卡脖子环节。6.3 软件生态的竞争才刚开始硬件参数可以追生态壁垒难破。NVIDIA的CUDA护城河短期内难以撼动但开放标准如OpenXLA、ROCm和云厂商自研栈正在形成各自的势力范围。对用户来说多掌握一套软件栈就多一份议价能力和选择自由。我建议至少深入了解两家的栈别把鸡蛋放一个篮子里。6.4 云厂商自研芯片会持续加码AWS Trainium、Google TPU的成功会激励更多云厂商自研。逻辑很简单算力是云的核心成本自研能降本、能差异化、能绑定客户。未来几年云上可选的芯片种类会更多价格战也会更激烈。对用户是好事但选型复杂度也上去了。6.5 精度和算法的协同设计低精度FP8、INT4的普及不只是硬件的事还需要算法配合——量化感知训练、混合精度策略、数值稳定性处理。未来芯片和算法的协同设计会越来越紧密做算法的人也得懂点硬件做硬件的人也得懂点模型。7. 我个人的一些实操体会折腾了这么多架构我最深的体会是别迷信任何单一方案也别被参数表牵着走。真正决定成败的是你的负载特性、团队能力和成本约束三者的匹配度。NVIDIA生态最省心但最贵TPU规模化强但绑定深AMD性价比有吸引力但要投入调优Cerebras和Groq在特定场景有奇效但不通用Trainium在AWS内很香但出了云就难说。我的建议是先把手上的负载摸清楚——显存、带宽、通信、延迟这四个数算明白了选型自然清晰。然后小规模验证别一上来就 all in。最后保持学习这个领域变化太快今天的最优解明天可能就变了。最后分享一个小技巧评估新架构时我会先跑一个三件套——一个矩阵密集的算子、一个内存密集的算子、一个通信密集的算子分别看性能。这三个数基本能勾勒出这颗芯片的性格比看任何宣传材料都靠谱。