AWS Trainium 3/4架构深度解析：性能优势与未来AI基础设施演进趋势

基本上每年的AWS Re:invent大会后，技术圈都会对其发布的新品进行深度分析。今年，我们聚焦于AWS最新发布的AI训练芯片Trainium 3/4，详细剖析其架构设计、性能提升点，并在此基础上，结合算法与业务趋势，探讨未来AI基础设施可能的演进方向。

1. AWS Trainium 3 架构分析

1.1 Overview

本次发布的最大亮点之一是AWS宣布整个Neuron软件栈（NKI）将在未来几个月内完全开源。

Trainium 3芯片在结构上与Trainium 2相似，依旧采用双Die封装，但使用了更先进的TSMC N3P工艺。单芯片可提供2.52 PFLOPS的FP8算力，并集成了4颗总计144GB的HBM3e显存，带宽达到4.9TB/s。

从系统层面看，Trn3支持OCP MXFP8/MXFP4数据格式，其ScaleUP域的规模扩大至双机柜并联144卡。最显著的变化是ScaleUP互连带宽翻倍，并放弃了原有的Torus拓扑，引入了交换机，这使得All-to-All通信带宽大幅提升，对MoE（混合专家）模型更为友好。

AWS在session《AWS re:Invent 2025 - AWS Trn3 UltraServers: Power next-generation enterprise AI performance(AIM3335)》[1]中详细介绍了架构细节。

其设计思路非常清晰：单纯的峰值FLOPS性能并非关键，重点在于在实际工作负载中维持稳定且高效的性能。

为实现这一目标，Trn3采取了多种手段：

1. 降低精度：支持OCP的MXFP8/MXFP4格式。
2. 加速Softmax计算：随着Tensor Engine算力提升，需同步加速Attention中的Softmax（向量）计算，避免计算单元空闲。（这也是Nvidia B200的缺陷，而在B300中得以修复）
3. 近内存累加（Near-Memory Accumulation）：对集合通信中的Reduce操作帮助巨大。
4. Tensor Dereference：对MoE模型中的GroupGEMM操作有极大帮助，无需预先进行Shuffle处理。
5. 流量整形（Traffic Shaping）：在传输/通信过程中采用流量整形技术，避免多种并行策略及PD分离下KVCache传输中突发流量造成的干扰，使整机性能更稳定。
6. 后台转置（Background Transpose）：通过新增硬件指令在后台处理常见的矩阵转置操作，避免额外开销。
7. MMCastMode：资料暂缺，推测“MM”指Matrix Multiply，可能在矩阵乘法中根据张量维度决定Cast模式。
8. 内存地址喷洒（Spray）：基于哈希函数的内存地址分布，在简单的交织（Interleave）基础上增加了类似Swizzle的硬件处理能力。

接下来，我们将分组件进行详细分析。

1.2 Trainium3 芯片架构

芯片整体架构与Trainium 2类似，如下图所示：

同样采用双Die及4颗HBM，计算核心从NeuronCore-V3升级到NeuronCore-V4，浮点性能从1,299 FP8 TFLOPS提升至2,517 MXFP8 TFLOPS，接近翻倍。

显存带宽从Trn2的2.9TB/s提升至4.9TB/s，容量从96GB提升至144GB。片内SRAM容量也从28MB升级到32MB，8个NeuronCore-V4的总SRAM容量达到256MB。

ScaleUP互连从NeuronLink-V3升级到NeuronLink-V4，带宽再次翻倍。

DMA引擎性能也同步升级，以匹配4.9TB/s的HBM带宽。

1.3 NeuronCore

微架构上延续了NeuronCore设计。相较于Trainium 2的NeuronCore-V3，SRAM容量扩大至32MB，并新增了Near-Memory Accumulation能力。在Nvidia GPU上，类似功能通过NVSwitch的NVLS（Nvlink SHARP）或TMA指令实现。而Trn3可直接在SRAM上完成，能显著降低对HBM带宽的冲击。关于SRAM和互连的详细信息将在下节讨论。

计算引擎依然包括：

• Tensor Engine：用于GEMM/卷积/转置操作。
• Vector Engine：处理向量计算。
• Scalar Engine：处理标量计算。
• 通用SIMD引擎（GPSIMD Engine）：可用C++编程，用于补全特殊算子。

Tensor Engine

主要升级在于支持MXFP8/MXFP4格式，并延续了对结构化稀疏（Structured Sparsity）运算的支持，模式包括4:16, 4:12, 4:8, 2:8, 2:4, 1:4, 1:2等。

Vector Engine

为配合Tensor Engine，支持将BF16/FP16数据快速量化为MXFP8格式。最关键的是进一步提升了指数函数等计算能力，确保在Attention等计算过程中，避免Tensor Engine因等待Vector Engine而空闲。

注：这一点比同期的Nvidia Blackwell B200完善得多。Nvidia仅在B300中通过削减TensorCore FP64算力来换取SM更大面积以增强SFU性能。B200到B300的修复预计能使Attention运算性能提升近20%。

Scalar Engine

无显著变化。

GPSIMD Engine

这是Trainium系列的一大创新，允许执行通用C/C++编译的代码，以弥补DSA架构在可编程灵活性上的不足。特殊算子可通过GPSIMD高效实现，并能完全访问SRAM。

1.4 ComputeTray架构

整个ComputeTray采用模块化设计，除液冷管路外，类似Nvidia Rubin，采用无线缆（Cableless）模块，便于安装维护。

在Trn3的ComputeTray中，后半部放置了4颗Trn3芯片。其背面的NeuronLink接口通过CableTray连接到整个机柜，同时板载了一颗NeuronLink Switch连接这四颗芯片。

ComputeTray前半部两侧各放置了两块Nitro-V6网卡、一颗Graviton 4 CPU并配置了12通道DDR。这些组件应统一连接到PCIe Switch上，不确定是否也复用了NeuronLink Switch来连接CPU和网卡。

前面板还预留了4个NeuronLink接口，用于两个72卡机柜的并联。

1.5 内存子系统和ScaleUP互连

一个显著变化是，Trn3放弃了Trn2采用的3D Torus Mesh拓扑，引入了NeuronLink Switch。并且据称在Trn4中，将进一步引入相对开放的NVLink Fusion或UALink。

1.5.1 内存子系统

脱离微架构和内存子系统讨论互连是没有意义的。 从内存层次结构看，Trainium、TPU这类DSA与GPGPU有显著区别：

DSA架构通常在每个核心内配置大容量SRAM（如Trn3单个NeuronCore有32MB），并且需要显式进行内存管理和预取。而GPGPU架构延续SIMT抽象，在原有SMEM+RF基础上引入TensorCore，并为更好的异步内存访问引入TMA，同时为缓解寄存器溢出压力在Blackwell中引入TMEM，并为优化局部内存访问引入CGA sub-NOC。

可以看到，Nvidia为维持CUDA生态，内存子系统变得越来越复杂。单个SM内的SMEM容量相对较小，从Little‘s Law角度看，访问延迟和带宽受限，因此SMEM-to-SMEM访问仅限CGA范围内。大量空间留给L2 Cache，但L2 Cache无法手动管理。因此，来自其他ScaleUP节点的读写请求无法直接进入SM内部的SMEM，只能存放在HBM上，并由L2 Cache部分缓冲。

而像Trn3这样的DSA架构，单个NeuronCore的On-Chip SRAM达32MB，带宽延迟积（BDP）更优，因此它支持SRAM通过NeuronLink直接读写另一颗Trn3的SRAM。总体来看，在集合通信，特别是MoE的Dispatch/Combine操作上，此类架构对HBM的压力显著小于GPGPU架构。

架构选择本质上是权衡。DSA内存层次看似简洁，但编程难度也更大，具体将在软件架构部分分析。

1.5.2 Near-Memory Accumulation

Nvidia可通过NVSwitch上的SHARP功能或TMA指令加速Reduction操作。AWS则允许DMA引擎通过单次传输，直接对SRAM中已有数据执行 read-add-write 运算。

从微观角度看，在Nvidia GPU上，Reduction操作对其他计算Kernel的内存访问干扰很大，通常这些Partial SUM Reduction或EP Combine操作都需要写回HBM，同时造成L2 Cache污染，影响其他Kernel性能。

相比之下，Trn3在EP Combine阶段，应能从Expert卡直接Combine加回到本地的SRAM上，端到端延迟可能更低，编程也更容易。

1.5.3 ScaleUP互连

当前的NeuronLink-V4基于PCIe Gen6修改，带宽较基于PCIe Gen5的V3版本翻倍。最大变化是引入交换机提升All-to-All性能，但似乎又未做彻底。从拓扑看，每颗Trn3芯片有3条NeuronLink，构成不同连接：

1. ComputeTray内部交换机：单个ComputeTray内有一个NeuronLink Switch连接四颗Trn3。
2. 机柜级交换机：每个72卡的机柜，每颗Trn3有一条NeuronLink连接到柜内NeuronLink Switch。
3. 机柜间直连：剩余的NeuronLink用于两个机柜间一一对应的直连。

这种复杂约束主要源于交换机芯片Radix的限制。初期可能采用基于Asteralabs Scorpio-X 160lane的PCIe Gen6交换芯片，后续会升级到320Lane的Scorpio-X或支持UALink的交换芯片方案。若采用新方案，可能实现全部挂接到机柜级的Switch Tray上。SemiAnalysis的预测图可供参考：

三种互连的带宽也不对等：连接机柜级交换机的链路支持80 Lane，而两个机柜间同Rank Trn3互连的仅16 Lane。SemiAnalysis的内部互连图如下：

从实际并行策略看，最省事的方案是通过Rack-Level Switch实现大EP并行。ComputeTray内部交换机可用于承载TP并行需求，也可利用双机柜间的带宽，在两个机柜上进行TP2部署。

1.5.4 ScaleUP未来演进

整体看，AWS的ScaleUP正从封闭、基于PCIe定制的NeuronLink，逐渐转向开放的NVLink Fusion和UALink标准。

有趣的是，在Trainium 4上，AWS同时押注NVLink和UALink，采用I/O Chiplet方式，通过UCIe与计算Die互连。对于使用NVLink ScaleUP的Trn4，可采用NVLink Fusion Chiplet。

对于UALink，则更换相应的I/O Chiplet即可。

1.6 ScaleOut/FrontEnd网络

Trainium 2的ComputeTray采用4颗Trn2芯片，并使用8块200Gbps的Nitro v5网卡构建1.6Tbps的ScaleOut网络。

另有独立的CPU Tray和200Gbps FrontEnd Nitro网卡（100Gbps用于VPC流量，80Gbps用于EBS/S3存储）。一个CPU Tray包含2颗Intel SPR处理器，连接8个Trn2 Compute Tray，CPU与GPU配比为1:8。

在Trainium 3上，分为Gen1和Gen2两个版本。Gen1为双机柜构建的64卡配置，整体结构与Trn2类似，有独立的CPU Tray和Trn3 Compute Tray。Trn3 Compute Tray支持2颗Trn3芯片，可配置一或两张400Gbps的Nitro v6网卡。CPU Tray与Trn2相同，采用x86架构和独立的FrontEnd Nitro，CPU与GPU配比仍为1:8。

而在Gen2机柜架构上，CPU和GPU整合在同一ComputeTray内，CPU采用Graviton 4，CPU与GPU配比变为1:4。从ComputeTray构建看，FrontEnd和ScaleOut似乎产生了融合，没有独立的FrontEnd Nitro。这是否意味着在该平台上实现了ScaleOut和FrontEnd的融合？

同时，据SemiAnalysis消息，Trn3 Gen2 72x2机柜的ComputeTray支持两种部署：

1. 2个Trn3共享一块Nitro-V6，平均每卡带宽200Gbps。
2. 2个Trn3各独占一块Nitro-V6，平均每卡带宽400Gbps。

现场展示的是每个Trn3独立配置Nitro-V6的方案，且未给CPU配置专用Nitro-V6，而是让CPU与其他4个Nitro-V6共享带宽，中间仅有一根绿色RJ45线缆用于带外管理，两侧有4根400Gbps光纤。

这实质上走向了ScaleOut和FrontEnd的融合路线，即Trn3配置的Nitro-V6也具备通过VPC连接存储的能力。

1.7 软件架构

AWS在软件架构设计上思路清晰，类似TileLang，将开发者分为三类：

• 上层ML开发者：更关注如何调用推理引擎加载优化好的模型，与第三方库整合。通常仅涉及推理框架和模型部署应用，例如使用 Java 或Python编写的后端服务调用模型API。
• 中层算法研究员：关注研发新模型和算子，需要快速迭代。通常以原生PyTorch/Jax为主，追求流畅的开发体验而非极致性能。
• 底层性能优化工程师：与底层硬件紧密结合，负责算子编写、性能剖析（Profiling）等工作，旨在充分打满算力芯片。

AWS为Trn提供了Neuron Kernel Interface（NKI）进行算子编程，以及Neuron Explorer作为性能剖析工具。

NKI与近期的CuTile/TileLang类似，都是基于Python的DSL，支持Tile级编程。据称其编译器将完全开源。

另一方面，Re:invent的session演示了Neuron Explorer。由于高频trace可存于SRAM，它能以硬件指令集粒度展现NeuronCore执行过程，精度达纳秒级，且开启后对性能影响很小。后处理能将trace串联，形成详尽的设备级/系统级性能报告。

例如，对于集合通信中的离群值也能很好地进行可视化：

2. 未来AI基础设施的演进

2.1 前置技术背景

关于以Nvidia为代表的GPGPU路线，已有详细分析。对于TPU/Trn这类ASIC架构，前一章已做剖析。关于ScaleUP和ScaleOut互连，也可参考相关技术文章。

2.2 从业务的视角分析

从业务视角，需先找准AI下一步规模化（Scaling）的方向：

AI Scaling的重心正逐渐转向RL后训练（RLHF/RLPF）、推理模型（Reasoning Model）及相应的深度研究（DeepResearch）处理，以及智能体（Agentic）与具身智能路线。对于RL后训练，Rollout阶段占比极大，而后两者也以推理为主。AWS Re:invent也提出了类似的业务视角：

AWS得出的AI基础设施需求总结为4点：

1. Reasoning模型和Agentic需要更长的上下文（Context），对Attention block的复杂度提出了新要求（如Sparse-Attn和Linear-Attn），同时产生了PD分离及超长Context下KVCache存储的需求。
2. 支持MoE模型繁重的通信需求。
3. 训推一体，支持预训练、后训练和推理在同一系统运行。
4. 支持超大规模并发的Agent执行和独立操作，这要求租户间隔离，且AI基础设施需与通用CPU计算集群更好互连和弹性结合。

2.2.1 预训练业务

首先，预训练阶段的模型参数规模受训练数据量约束正在放缓。从信息压缩视角粗略估算，人类数据规模约30T Tokens，按10:1压缩比，模型参数规模上限约3T。因此，模型参数规模增长在放缓。

当采用超节点机型后，TP和EP流量可尽量限制在ScaleUp域内，ScaleOut仅承载PP和DP流量，且这些流量通常能很好重叠。这就引出一个问题：是否可以适当缩减ScaleOut带宽，或直接将其并入FrontEnd网络？

正方观点

从业务视角看，FrontEnd配合层次化集合通信和基础设施层的Overlap，并适当扩大带宽应能满足需求。避免使用专用ScaleOut网络可降低10%~20%的整体成本和电力开销。

但FrontEnd承载RDMA业务本身有难度，特别是与VPC内其他TCP流量、存储流量混跑时，面临网络哈希冲突、拥塞控制等问题。Nvidia的RoCE网卡在此有较大局限，这也是NV一直宣传FrontEnd承载南北流量、ScaleOut承载东西流量，且存储独立组网的原因。

事实上，工业界能较好解决此问题的可能仅有三家：AWS SRD、Google Falcon和阿里云的CIPU eRDMA。AWS SRD不支持标准RDMA Verbs接口，Google Falcon多路径算法有缺陷且不支持跨Scale-Access长传，实际上可能只剩一家。我们看到AWS在Trn3 Gen2上已有融合FrontEnd和ScaleOut的解决方案，并提供相对低带宽（每卡200Gbps）的实例。

反方观点

对算法和基础设施工程师而言，一个简单逻辑是：只要有带宽，就会设法调度通信将其打满。另一个观点来自云服务商（CSP）视角：不希望训练和推理分池。当训练与推理比例大于1:5时，省去ScaleOut成本很有吸引力，但可能导致训练集群无法开出，影响整体售卖率。此外，通常用最新卡训练，老卡推理。因此ScaleOut成本摊销不能简单按整生命周期计算。对于一个5年生命周期的集群，ScaleOut网络成本摊销到推理上时，应以某种残值计算。

另外，生命周期早期的新卡溢价高。若一个无ScaleOut的集群，其首年收入相比竞争对手的折扣，可能导致节省ScaleOut的成本优势丧失，这需要精细核算。

注意到从GB200开始，Nvidia的叙事逻辑已转向推理。未来部署的新卡中，用于推理的比例是否会超过70%？整体ROI模型需重估。据分析，明年美国新建卡总规模近1600万卡，新卡的训推比分布，以及Neocloud/CSP是否会构建无需ScaleOut的实例，答案可能很快揭晓。

2.2.2 RL后训练

对RL后训练而言，Rollout时间占比远高于训练，是重推理业务。推理本身更侧重EP通信流量，因此构建超节点几成刚需。在超节点集群上，训练参数更新等可在ScaleUP上完成，或通过层次化集合通信实现。理论上，省去ScaleOut网络的端到端性能差异会很小。

2.2.3 Reasoning模型与Agentic

对于大量Reasoning模型，特别是配合DeepResearch任务时，常需调用外部工具和并发Agent执行（如WideResearch）。另一方面，大规模Agent并发执行和多租户服务要求客户可能将Agent置于自有VPC内，与现有系统/应用融合。

这进一步提升了对FrontEnd高并发的需求。此外，这类工作负载通常需要更长context，因此对PD分离和KV-Cache提出更高要求，层次化KVCache将成刚需。

最后，Agentic对通用计算的弹性需求更高。复杂Agent任务涉及多步业务调用，某些应用对延迟要求严苛。链路上的长尾延迟对SLA影响巨大。因此，对Agent执行环境的安全隔离、快速拉起及高并发能力提出新挑战。在Agentic时代，一个模型可能同时操作数百台设备完成任务，通用计算规模将伴随业务成熟而成倍增长。对于仅建有GPU集群的算力中心，在通用计算资源和存储资源的池化与弹性供给上面临巨大挑战。

粗略估算，一个日活2000万的Agentic业务，每日写入数据量可能超过200PB，并发Agent执行环境可能需要数百万台VM。

2.2.4 小结

总体来看，对于纯推理平台（Reasoning+Agentic）和RL后训练，对ScaleOut这个后端孤岛的需求似乎不强烈。但对于预训练场景，仍存在业务争议。

1. EP并行：确定需要支持基于内存语义的ScaleUP网络构建超节点，不确定的仅是EP规模和超节点规模。
2. FrontEnd网络需求：模型推理结果需传输到部署在用户VPC内的Agent节点。
3. PD分离：EP类业务在ScaleOut RDMA消息语义上本就不友好，与PD流量混跑干扰大。而KVCache有接入存储构建HiCache的需求，通常放入FrontEnd网络。FrontEnd与ScaleOut融合还可通过GDA/GDS直接将KVCache加载至GPU显存。

2.3 算法演进

首先从算法基础阐述：智能是什么？一个简单观点是：它是超高维度空间内，按照某种结构压缩的低维流形（low-dimensional manifold）。

2.3.1 从物理的视角

从物理世界看，Demis Hassabis有一个假设：自然界的许多规律无需显式方程，可通过在图灵机上以数据压缩方式学习。例如AlphaFold预测蛋白质折叠结构。蛋白质理论涉及10^300空间，无法穷举或物理模拟，但自然界中蛋白质能在毫秒内完成折叠，这正是超高维空间中按结构压缩的低维流形。因此，自然行为模式在高维空间中稀疏分布、结构清晰、路径稳定——它们集中在一种可压缩、可调度的结构空间中，构成低维流形。AlphaFold本质亦然，它用深度神经网络从数据中提取低维流形，并在此结构压缩空间中完成调度和推理，无需理解全部物理机制，而是掌握“自然允许的路径”。具身智能底层逻辑也类似。

2.3.2 从数学的视角

从数学角度看，相关工作一直在进行。一个简单结论是：本轮人工智能革命的数学基础是范畴论、代数拓扑、代数几何这些二十世纪的数学首次登上商用计算舞台。

如前所述，智能是超高维空间中按结构压缩的低维流形。而代数拓扑/代数几何是描述结构化压缩的良好工具。例如代数拓扑通过代数不变量区分和分类不同拓扑空间，从而在算法层面描述“自然允许的路径”，其背后逻辑是从高维空间构造代数不变量，再赋予流形结构化约束。

更基础的研究在范畴论上展开：如何在计算范式上构造合理的代数系统，并在算法研究中从代数结构上排除不必要的探索。一个简单做法是将Attention视为范畴论中的态射，那么预训练的实质是在构造一个Presheaf。核心结论来自Yoneda Lemma：你无需知道对象的“内部构造”，只需知道它如何与外界“交互”（即所有射向其他对象的箭头集合），就能完全理解它。这与“超高维空间中按结构压缩的低维流形”本质相同。

进一步通过Nerve构造引入更高维范畴，从而引入模空间（Moduli space）概念。模空间是代数几何核心概念，是一个几何空间，其上每一点对应一类代数几何对象的同构类。模空间研究旨在为几何对象分类提供统一框架，并通过研究模空间本身的几何和拓扑性质来理解这些对象。模空间的核心思想是“为对象建立几何目录”。例如语言中的同义词、不同语言对相同含义的描述，都可视为背后知识的同构类。当对象间存在复杂等价关系（同构）时，模空间本身就成了复杂的“空间”。神经构造正是处理这种复杂“等价关系网”的系统性工具。

2.3.3 从计算机体系结构的视角

从计算机体系结构视角看，算力易扩展，内存访问难扩展。因此算法路径上需要合理的、可训练的稀疏化方式。

另一方面，低维流形实质是在经典图灵机上以数据压缩方式学习。那么，如何让模型结构本身构成一个高并行的图灵机结构？这个视角解释了Transformer架构的有效性。

如果说早期的token-by-token推理是顺序纸带图灵机，那么Reasoning模型的出现更像一个完备的图灵机，但似乎缺少纸带回退和擦除能力。这些回退和擦除或许是推理阶段节省复杂度的好方法。毕竟解决问题时不需要无限大的草稿纸，大模型亦然。

当试图通过大模型架构构造一个能自生成代码运行的通用计算机架构（即token as instruction）时，思路便豁然开朗。大模型可能从自回归走向自生成指令。那么，构造大模型的冯·诺伊曼架构大致如下：

即Attention作为图灵机的计算控制单元，MoE作为存储器。接下来分述算法中的两个模块。

2.3.4 Attention

关于Attention演进，此前有分析指出，实质性问题仍是稀疏化。从自然选择看，Sparse Attention中按Block处理对于Agent任务拼接context可节省大量Prefill算力，相比Linear Attention有优势。

当然，Linear Attention某些类似RNN的属性仍有价值，但不妨碍在Sparse Attention中引入递归循环处理，在内存访问未显著增加的情况下提升计算规模是可行的。明年开源模型中可能会出现真正变化。

2.3.5 MoE

另一个重要问题是MoE的未来规模。部分网络背景的超节点厂商认为需一卡一专家，因此追求极大超节点规模。但我们看到Nvidia Rubin最大144卡，Trn3实际EP并行单柜72卡。对于当前常见的256专家、TopK=8的MoE模型，在GB200上EP32通常足够。

关键问题是：专家数是否会超过256/384，达到1024/2048，TopK达到64？答案是否定的。实际决策流程如下：

首先，从模型训练角度看，进一步增加专家数提升稀疏性会导致训练崩塌及后训练任务中训推不一致问题加剧，因此单层专家总数最大可能维持在512以内。

假设极限稀疏情况：专家数M=512，K=8，batchsize N=32，需访问的专家数为202个。若专家数扩至1024，需访问专家数227个，带来巨大内存访问瓶颈。通过EP并行（如每卡8个专家），访问专家参数的带宽可降至原来的3%。此时EP规模为128卡。

结论：从并行策略分析，满足交换机单层组网Radix规模（如最大512卡）即可。实际部署考虑弹性伸缩，可能进一步降低ScaleUP规模。即使如Rubin Ultra NVL576，其Kyber机柜背面显示单个ScaleUP域仅144卡，且NV选择铜互连。同样，AWS Trn3、AMD MI450x也在做类似决策。

即便Google号称通过OCS连接了9216卡的ScaleUP域，那也仅是调度域，实际单实例规格也是8x8x8=512卡。Google未来是否维持3D-Torus拓扑仍是变数。

2.4 从商业模式的视角分析

对于NeoCloud业务模式存在的风险已有详细阐述，实质是计算资源弹性供给和流动性管理。近期部分NeoCloud和Oracle已逐渐陷入流动性风险。未来一年，北美新建卡规模达1600万张，充足供应下流动性风险将更突出。

对CSP而言，弹性训练和推理业务模式在GPU资源池规模足够大时将成刚需。例如AWS在Re:invent上讨论了Checkpointless和弹性训练。

对于峰谷效应明显的推理业务，构建更具弹性的MaaS推理平台对成本管理有极大优势。实质性技术问题是：存算分离和多租户隔离。

支持存算分离和多租户隔离的GPU实例，实质上完成了算力“证券化”过程。

2.5 从基础设施视角分析

前面从应用、算法、经营角度分析了一系列需求，最终需落在基础设施实现上。

2.5.1 算力芯片微架构

核心问题是：选择DSA还是GPGPU路线？

从体系结构视角，通常解决方法有四个方向：

1. 提高并行性
2. 降低数值精度
3. 更好的数据局部性（Data Locality）
4. DSL（领域特定语言）

对于提高并行性，DSA和GPGPU都演进至Tensor Core + Vector Core + Scalar Core架构。对于数值精度，MXFP8/MXFP4/NVFP4等基于块缩放（block scaling）的低精度压缩均获支持。

本质区别在最后两点。在数据局部性处理上，DSA需更底层管理内存和排布流水，对编译器要求比GPGPU更高。而DSL则在易用性上解决数据局部性复杂问题，这是近期竞争激烈的方向（如cutlass-dsl/cuda-tile/tilelang）。

关于数据局部性的对比如前所述：DSA通常配备大块SRAM，而GPGPU有更深内存层次。

实际上，追求极致性能的基础设施工程师对DSL依赖不大，有时不如内联指令方便。在Tile-Based DSL架构下，受众是配合算法开发的基础设施工程师，他们有提升数据局部性的需求，但不极致追求性能。通常一个实验需跑半个月，算法研究员不会给基础设施工程师长达一个月的算子开发时间。开发周期可能仅几天，此时DSL是很好选择，即使DSL代码无法打满性能，获得峰值70%也很有价值。

因此，唯一剩下的区别在于内存子系统设计。实际上，对于CUDA编程，伴随TensorCore引入，即使Hopper/Blackwell有更好的异步MBarrier处理能力，对SMEM/TMEM的内存分配、管理、访问的编程复杂度和用户心智负担仍很大。特别是在Blackwell上，跨物理Die引入近400 Cycle延迟差异，对小Kernel运算也有显著影响。

在Tile-Based DSL下，DSA和GPGPU架构在内存管理复杂度上均有显著降低，两者区别正逐渐模糊。唯一区别可能在算力调度上：GPGPU指令发射/Warp调度在加速器内部实现，但也逐渐面临问题。例如TMA/TensorCore的异步指令发射仅需一个线程，却不得不调度一个Warp到CUDA Core上执行。而Warp执行时为保证吞吐，许多指令发射带Stall Control-bits。因此对于低延迟业务存在显著缺陷。

这也是RDMA不适合GPU微架构的根本原因，主要包括：构造WQE对SIMT CUDA Core低效且延迟大；完成事件通知机制上，RDMA无法直接通知并更新SMEM中的MBarrier，需CUDA Core轮询GMEM，每次轮询带来巨大延迟和Warp调度开销；完成队列数据结构对GPU消耗巨大。RDMA对DSA架构也有类似问题。

这也是MoE等EP并行处理需采用ScaleUP总线的原因。实质性需求是使用对GPU和DSA微架构友好的内存语义。

2.5.2 系统互连架构

一个直接结论（2023年底内部资料也写过）：GPGPU/DSA等算力芯片需在整个系统互连体系中成为一等公民。简言之，要构建GPU Direct Everything（GDE）。

朴素观点是：GPU作为算力芯片，正替代CPU成为新一代算力中心，理应成为数据中心一等公民。作为一等公民，需直接访问数据中心内一切资源，避免额外开销。例如直接访问KVCache存储、直接控制CPU-Agent实例、直接访问云存储处理数据和checkpoint。因此GPU Direct Everything成刚需。最后，云的弹性经营逻辑推导出云需多租安全隔离和存算分离以实现弹性调度。

当前GPU架构通常由三张网络构建：

• Type1: Front-End Network：用于VPC互联和访问存储业务。
• Type2: Scale-Out Network：基于RDMA网卡的多机扩展互联网络。
• Type3: Scale-Up Network：基于NVLink等私有总线构建的多GPU机内互联网络。

从云基础设施和弹性调度视角看，GPU在FrontEnd作为加速器挂载到CPU下，是二等公民。从经营弹性调度视角看，GPU需接入存储并支持多租户连接。从业务视角看，Agentic/RL等业务也需要更大FrontEnd带宽，更长Context需要GPU连接到层次化KV-Cache池，且该HiCache池也需弹性多租模式以提升资源利用率。同时，弹性部署需要更快模型加载速度，Nvidia也建议构建东西向存储集群。

实质性结论也是：GPU需在接入存储方面成为一等公民。

关于EP并行

当前变化是，对于EP类流量，需支持内存语义的超节点。ScaleOut承载EP并行仍有限制。在超节点演进中，单个超节点通常包含64~144卡，可视为GPU已在单机柜内完成基于内存语义的ScaleOut从8卡扩展到64~144卡。对GPU而言，算力所需网络带宽有上限，毕竟它不是网络交换芯片，大量计算/内存访问瓶颈决定了上限。因此在超节点机型上，ScaleOut是否还需如此大带宽存在争议。相反，对于维持8卡架构的B200/B300服务器，随着算力提升，对ScaleOut带宽需求仍在增加，ScaleOut是刚需。

关于PD分离

从业务视角还需考虑PD分离部署的技术选择。对于Rubin CPX方案，它分两种部署：一是在NVL144机柜内将Rubin CPX串接在ScaleOut网卡和Vera CPU之间；二是采用VR CPX + VR NVL144双机柜部署，利用ScaleOut网络互连。

官方两种方案中，VR CPX NVL144采用固定配比，丧失了ScaleOut GDR能力；而双机柜方案虽天然支持xPyD，但会导致ScaleOut上KVCache传输和EP并行流量相互干扰，且多了许多Vera CPU和CX9网卡。通常一张CX9网卡售价约2000美元，一张Rubin CPX估计3000~5000美元，再摊销ScaleOut光纤和交换网络成本到Rubin CPX，Nvidia “Buy More, save More”是否成立？

另一种成本核算视角是采用FrontEnd承载PD分离流量，并引入层次化KVCache缓存。但对于PD分离流量，GPU需通过PCIe Switch连接到CPU，再通过CPU直连的DPU传输KVCache。此路径中，PCIe Switch有天然收敛比，且CPU内存子系统也会受大带宽冲击。

那么，FrontEnd和ScaleOut融合，直接将GPU作为一等公民，是否能避免此问题？

FrontEnd和ScaleOut融合

一个简单的权衡：对于超节点集群，适当提升FrontEnd带宽能否承载ScaleOut流量？实质性目的是将GPU提升为一等公民，符合业务演进逻辑。

业务逻辑朴素，但技术挑战巨大。特别是RDMA/RoCE本身是不完善的可靠传输协议，商用RDMA/RoCE与其他流量混跑时，相互干扰导致的性能下降非常明显。因此，独立构建RDMA专用ScaleOut网络有业务收益。

但这个技术挑战已被解决。无论是AWS SRD还是Google Falcon都有完善方案。而阿里云CIPU eRDMA更在所有8代以上通用计算实例上基于VPC构建了RDMA能力。RDMA与TCP混跑，甚至与存储流量并网，技术上已实现。因此，将GPU作为一等公民在技术上成立。

---

参考资料

[1] AWS re:Invent 2025 - AWS Trn3 UltraServers: Power next-generation enterprise AI performance(AIM3335):https://www.youtube.com/watch?v=c_1FhdXNUSE&list=PL2yQDdvlhXf-UqnINCmXu-dDZJm_B3bbJ&index=26

[2] AWS re:Invent 2025 - SageMaker HyperPod: Checkpointless & elastic training for AI models (AIM3338):https://www.youtube.com/watch?v=r9J10L2K0F4&list=PL2yQDdvlhXf-UqnINCmXu-dDZJm_B3bbJ&index=6