第3章 加速器与异构计算

3.1 AI 加速器产业全景

AI加速器市场是当前半导体产业增长最快的细分领域。全球AI加速器市场规模已达数千亿美元量级，NVIDIA仍占据约80% 的市场份额，但竞争格局正在加速演变。

3.1.1 市场格局

Tier 3 Meta MTIA v2 Tier 2 Recommendation inferenc e Internal use AMD MI300X/MI325X/MI350X/MI Tier 1 355X ROCm ecosystem catchin Open ISA / Emerging g up NVIDIA Huawei Market share ~5% GPU: H100/H200/B200/B3 RISC-V AI extensions Ascend 910B/910C 00/Rubin R100 Tenstorrent, Ventana China market CUDA ecosystem dominan CANN ecosystem t Market share ~80% Intel Gaudi 3 OpenAI 'Stargate' custom c oneAPI + Gaudi hip Cerebras Market share ~2% (TSMC partnership, 2025+) WSE-3 Google

                                       Wafer-scale chip                                       TPU: v5p/v6e/v7 Ironwood
                                        CS-3 system                                                Cloud exclusive
                                                                                                    Internal + GCP

AWS Trainium2/Inferentia2 Neuron SDK Groq AWS exclusive LPU Extreme low-latency infere nce SRAM-only 图3-1 AI加速器产业竞争格局

3.1.2 NVIDIA 的霸权根基

NVIDIA的统治地位源于三个难以复制的壁垒： •CUDA 生态护城河：CUDA是NVIDIA最强大的护城河。自2006年发布CUDA 1.0以来，18年的持续投入积累了： •数百万CUDA开发者 •数千个CUDA加速的库和应用（cuBLAS、cuDNN、NCCL、TensorRT、CUTLASS…） •3000万+行的CUDA SDK和工具链代码 •几乎所有主流AI框架的第一支持对象（PyTorch、JAX、TensorFlow的CUDA后端） 竞争对手即使造出硬件超过NVIDIA，也会因软件栈不兼容而无法被市场接受。 •硬件-系统的垂直整合：NVIDIA从芯片（H100）、基板（HGX）、节点（DGX）到集群（SuperPOD）提供端到端的完整 方案。这种垂直整合保证了硬件交付时软件已完成适配和性能调优，大幅降低了用户部署成本。 •全栈 AI 软件平台：NVIDIA不仅是芯片公司，更是AI软件平台公司： •NVIDIA AI Enterprise：相当于AI领域的Red Hat（企业级软件订阅） •NVIDIA NeMo Framework（含Megatron Core）：大模型训练框架 •NVIDIA Inference Microservices (NIM)：容器化推理服务 •CUDA-X AI：从cuDNN到TensorRT的全套加速库

3.1.3 市场趋势

•推理市场已超越训练：训练和推理的算力支出比例已发生根本性转变。根据行业估计，2025年推理算力消耗已超过训 练，成为GPU数据中心收入的主要来源。推理时扩展（Inference-Time Scaling），即让模型“思考更久”以提升质量 （Chain-of-Thought、Best-of-N 等），进一步放大了这一趋势：单次推理请求的计算量从几百tokens膨胀至数千乃至 数万tokens，推理集群的GPU需求因此持续激增。 •软件定义芯片的趋势：高昂芯片流片成本（3nm/5nm工艺流片一次500M −800M）推动产业转向“软件定义的系统集 成”： •通过Chiplet技术组合已有的计算和I/O Die，降低新品开发成本 •AMD的MI300系列是典型代表（3D Chiplet，12个有效Die：8个XCD计算Die + 4个IOD I/O Die） •专用化与通用化的拉锯：AI芯片设计存在“GPGPU更好还是专用ASIC更好”的持续争论： •GPU派（NVIDIA）：通用可编程性保留灵活，Tensor Core提供专用加速 •ASIC派（Google TPU、Cerebras）：极致能效和面积效率，牺牲灵活性 •当前结论：在Transformer为主流的时代，专用化（如NVIDIA Transformer Engine的FP8）红利显著，但架构需保持 足够通用以应对算法变革 •地缘政治驱动的区域供应链：2023年以来，美国芯片出口管制持续加码，中国市场加速形成独立生态：H100/H200及 Blackwell高端GPU无法对华出货，NVIDIA推出算力受限的合规版H20，国产加速器成为替代主力。国产芯片的完整产 品线与生态独立成节展开。

3.1.4 训练与推理硬件差异

表3-1 训练与推理硬件差异 维度 训练 推理 算力密度 极致高（TFLOPS） 中等（TOPS） 内存带宽 高（3+ TB/s） 极高（KV Cache IO密集） 显存容量 大（80-288GB/卡） 大（模型权重+KV Cache） 精度 FP16/BF16/FP8 INT4/INT8/FP8/FP4 互联带宽 极高（NVLink+InfiniBand（IB）） 中（PD分离架构需节点间KV传输） 可靠性要求 中（容忍失败恢复） 高（SLA，不能中断） 典型硬件 H100/B200/GB200集群 H100/L40S/B200/AMD MI350X

3.2 AMD Instinct 与 ROCm 生态

AMD Instinct系列是NVIDIA在AI GPU领域最有力的竞争者。凭借CDNA架构的持续升级和ROCm开源生态的努力，AMD在 MLPerf基准测试中逐渐缩小与NVIDIA的差距。

3.2.1 MI 系列架构演进

MI250X（CDNA2, 2021） 表3-2 MI250X 规格 参数 MI250X 对比NVIDIA A100 计算单元 220 CU (2×110 Die) 108 SM FP64 Tensor 47.9 TFLOPS 19.5 TFLOPS FP32 Vector 47.9 TFLOPS 19.5 TFLOPS FP16/BF16 Tensor 383 TFLOPS 312 TFLOPS HBM 128GB HBM2e (双Die) 80GB HBM2e HBM带宽 3.2 TB/s 2.0 TB/s 互联 Infinity Fabric 3.0 NVLink 3.0 MI250X在原始算力上超越A100，但在AI训练MFU上明显落后（受限于ROCm的NCCL等价库RCCL的通信效率）。在 MLPerf Training 2.1基准中，8×MI250X训练BERT的性能约为8×A100的70-80%。 MI300X（CDNA3, 2023） MI300X是AMD的革命性产品，采用先进的3D Chiplet封装（12个有效Die：8个XCD计算Die + 4个IOD I/O Die，HBM3直 接堆叠于封装基板上层）： 表3-3 MI300X 规格 参数 MI300X 对比NVIDIA H100 晶体管数 153B 80B FP16 Tensor 1307 TFLOPS 990 TFLOPS FP8 Tensor 2615 TFLOPS 1979 TFLOPS HBM 192GB HBM3 80GB HBM3 HBM带宽 5.3 TB/s 3.35 TB/s 互联 AMD Infinity Architecture Gen4 NVLink 4.0 TDP 750W 700W MI300X在算力和显存容量上都领先H100。192GB的HBM3使其成为大模型推理（尤其是405B参数以上模型）的有力竞争 方案。2024年，Meta在Llama-405B推理评估中测试了MI300X，证实单卡即可容纳INT4量化后的405B模型权重。 MI325X（CDNA3 refresh, 2024年10月）： MI325X将HBM升级为HBM3e，容量提升至288GB，带宽达6 TB/s。这是NVIDIA B200正式量产前的最大显存GPU，定位 为大模型推理首选。 数据来源：AMD 官网（2026-01） MI350X（CDNA4, 2025年6月）： MI350X采用全新CDNA4架构，TSMC 3nm工艺，是AMD对标Blackwell的正面竞争产品： 表3-4 MI350X 规格 参数 MI350X（官网） 对比 NVIDIA B200 工艺 TSMC 3nm (N3) + N6 IOD TSMC 4NP 计算单元 256 CU (8×XCD) — 晶体管 1850亿 2080亿 FP16/BF16算力 2300 TFLOPS（稠密）/ 4600 TFLOPS（稀疏） 2250 TFLOPS（稠密） OCP-FP8算力 4600 TFLOPS（稀疏 9200 TFLOPS） 2250 TFLOPS（稠密） MXFP6/MXFP4算力 9200 TFLOPS 4500 TFLOPS（FP4 稠密） FP32算力 144.2 TFLOPS — FP64算力 72.1 TFLOPS — HBM 288GB HBM3e 192GB HBM3e HBM带宽 8.0 TB/s 8.0 TB/s 内存位宽 8192-bit 8192-bit TBP 1000W 1000W CDNA4原生支持FP4和FP6低精度格式，进一步拓宽了推理优化空间。MI350X的显存容量（288GB）是B200（192GB） 的1.5倍，在单卡容纳超大模型推理方面有显著优势。 CDNA4是AMD第4代CDNA架构，基于TSMC 3nm工艺，集成1850亿晶体管，原生支持OCP Microscaling格式的 MXFP4/MXFP6/MXFP8低精度格式，对标NVIDIA Blackwell的FP4/FP6支持。架构层面，CDNA4提供全片ECC、Page Retirement、Page Avoidance与SR-IOV等硬件级RAS增强。互联上采用Infinity Fabric第4代，含7条153 GB/s的scale-up 链路与1条128 GB/s的scale-out链路。 数据来源：AMD 官网（2026-01） MI355X（CDNA4 高性能版，2025 年 6 月发布）：同样搭载 288GB HBM3e、8 TB/s 带宽，FP16/BF16 算力达 2.5 PFLOPS（稀疏 5 PFLOPS），OCP-FP8 为 5 PFLOPS（稀疏 10.1 PFLOPS），MXFP6/MXFP4 达 10.1 PFLOPS，FP32 为 157.3 TFLOPS，峰值频率 2400 MHz，TBP 提升至 1400W，定位高端训练场景。 数据来源：AMD 官网（2026-01）

3.2.2 ROCm 技术栈

ROCm（Radeon Open Compute）是AMD对标NVIDIA CUDA的开源软件栈： ROCm architecture layers: ROCm Runtime:

     - rocBLAS: BLAS library, equivalent to cuBLAS
     - rocSOLVER: LAPACK library
     - rocFFT: FFT library
     - MIOpen: Deep learning primitives library, equivalent to cuDNN
     - RCCL: Collective communication library, equivalent to NCCL
     - rocPRIM: Parallel primitives library, equivalent to CUB/Thrust
     - Hipify: CUDA-to-HIP automatic conversion tool

HIP programming model:

     - HIP C++: Equivalent to CUDA C++, nearly identical syntax
     - hipify-perl: Automatic CUDA-to-HIP conversion
     - Python HIP: PyTorch RCCL backend

ROCm toolchain:

     - rocprof: GPU Profiler, equivalent to ncu
     - rocgdb: GPU Debugger, equivalent to cuda-gdb
     - rocminfo: GPU info query, equivalent to deviceQuery

HIP编程示例： // HIP code is nearly identical to CUDA C++ #include <hip/hip_runtime.h> global void vec_add(float* a, float* b, float* c, int n) { int idx = blockIdx.x * blockDim.x + threadIdx.x; if (idx < n) c[idx] = a[idx] + b[idx]; } int main() { // ... use hipMalloc / hipMemcpy / hipFree (replace cudaMalloc etc.) hipMalloc(&d_a, size); hipMemcpy(d_a, h_a, size, hipMemcpyHostToDevice); vec_add<<<grid, block>>>(d_a, d_b, d_c, n); hipDeviceSynchronize(); hipFree(d_a); } CUDA到HIP的迁移：

 # Auto-convert CUDA code
 hipify-perl cuda_kernel.cu > hip_kernel.cpp
 # Or use hipify-clang
 # Detect ROCm availability in PyTorch
 python -c "import torch; print(torch.cuda.is_available())"
 # True (ROCm backend registers as 'cuda' device)
 # Install PyTorch ROCm version

pip install torch torchvision torchaudio \

3.2.3 ROCm 的挑战与现实

 --index-url https://download.pytorch.org/whl/rocm6.0

尽管AMD在硬件上追赶NVIDIA的步伐很快，ROCm生态仍有显著差距： •库的成熟度： •rocBLAS在某些矩阵形状上性能仅为cuBLAS的70-85% •MIOpen对FlashAttention等新算法的支持滞后约3-6个月 •RCCL的AllReduce带宽利用率在千卡规模下落后NCCL约10-15% •PyTorch支持： •PyTorch官方ROCm支持自PyTorch 1.13起（FP64 enable），但功能完备性不如CUDA后端 •某些较新的PyTorch特性（如torch.compile、CUDA Graphs）在ROCm上支持较晚 •DeepSpeed/Megatron-LM对ROCm的支持往往滞后数月 •操作符覆盖度： •部分自定义CUDA Kernel需要使用hipify转换后再手动适配 •某些使用PTX（底层汇编）的Kernel无法直接转换

3.2.4 MI300X 集群性能验证

AMD ROCm environment setup

Install ROCm 6.0

wget https://repo.radeon.com/amdgpu-install/6.0.2/ubuntu/jammy/amdgpu-install_6.0.60202-1_all.deb

 dpkg -i amdgpu-install_6.0.60202-1_all.deb
 amdgpu-install -y --usecase=rocm
 # Check GPU topology
 rocm-smi --showtopo
 # Output: GPUs connected via Infinity Fabric links
 # Run RCCL AllReduce test

git clone https://github.com/ROCm/rccl-tests.git cd rccl-tests && make

 mpirun -np 8 ./build/all_reduce_perf -b 1M -e 4G -f 2 -g 1
 # MLPerf Inference test
 # Reference: https://github.com/mlcommons/inference

git clone https://github.com/mlcommons/inference.git cd inference && make setup python tools/submission/trunk/run_mlperf_inference.py
--backend=rocm --device=mi300x --model=llama2-70b 关键性能数据（MI300X vs H100）： 表3-5 MI300X 集群性能对比 基准 MI300X H100 比例 训练 Llama2-70B (MFU) 约42% 约52% 0.81× 推理 Llama2-70B (tokens/s) 约7500 约9500 0.79× AllReduce 8GPU (BusBw) 约80% 理论 约92% 理论 0.87×

3.3 Google TPU 与 Pathways

Google TPU（Tensor Processing Unit）是AI ASIC方向的旗舰产品，自2015年秘密研发以来，已历经七代迭代。TPU代 表了与GPU通用性迥异的“专用计算”设计哲学。

3.3.1 TPU 架构演进

表3-6 TPU 代际演进 代际 年份 特性 算力 (BF16) 显存 互联 TPU v1 2015 仅推理，INT8 92 TOPS (INT8) — — TPU v2 2017 训练+推理，FP16/BF16 46 TFLOPS 16GB HBM ICI v1 TPU v3 2018 液冷，更大HBM 123 TFLOPS 32GB HBM ICI v2 TPU v4 2021 光电交换，TPU Pod 275 TFLOPS 32GB HBM ICI v3 TPU v5p 2023 训练优化，更大集群 459 TFLOPS 95GB HBM ICI v4 TPU v5e 2023 推理优化，具成本优势 197 TFLOPS 16GB HBM ICI v4 TPU v6e (Trillium) 2024 2.5× v5e算力，SparseCore升级 918 TFLOPS 32GB HBM ICI v5 TPU v7 (Ironwood) 2025 双Chiplet，9216芯片Pod 2307 TFLOPS 192GB HBM ICI v5

3.3.2 脉动阵列架构

TPU的核心计算单元是MXU（Matrix Multiply Unit），采用脉动阵列（Systolic Array）架构——这与GPU的SIMT+Tensor Core设计根本不同： TPU v1 MXU architecture (conceptual): 256x256 systolic array = 65536 MAC units Each MAC: 1 8-bit multiply-accumulate per clock Operation: data "systolically" flows left-to-right (Weight) and top-to-bottom (Activation) Per clock: 65536 INT8 MAC = 131K INT8 OPS TPU v4 MXU: 128x128 BF16 systolic array (or 128x128 INT8) Paper claims peak BF16 ~275 TFLOPS/chip 脉动阵列的优势：

1. 确定性延迟：每个Tile的执行周期数固定（无GPU的Warp Divergence问题）
2. 极高能效：无指令取指/译码开销，数据流模式固定，功耗远低于同等算力的GPU
3. 面积效率高：MAC阵列比通用计算单元更密集 脉动阵列的劣势：
4. 稀疏性支持差：GPU的结构化稀疏（2:4 Masked GEMM）在脉动阵列上难以高效实现
5. 不规则算子慢：LayerNorm、Attention Softmax等非GEMM操作效率低
6. 灵活性受限：新算法（如Mamba、RetNet等非标准Transformer注意力架构）需要专门的编译器适配

3.3.3 TPU v5/v6 细节

TPU v5p（训练优化版）：

 Per-chip parameters:
 - 4 large compute chips + unified HBM pool
 - 459 TFLOPS BF16 (single TPU chip)
 - 95GB HBM (high bandwidth, theoretically suitable for 70B+ model training intermediates)
 - Inter-chip bandwidth: 4.8 Tbps (ICI v4)

TPU v5p Pod (max config):

 - 8,960 chips (TPU v5p)
 - Matrix: 112x80 2D-Torus topology
 - Total BF16 compute: ~4.1 EFLOPS (ExaFLOPS)
 - Optical routing: OCS (Optical Circuit Switch) dynamic topology reconfiguration

TPU v5e（推理/训练优化版）： 经济性优化的TPU，芯片设计侧重能效比而非绝对算力。16GB HBM限制了单芯片的批处理能力（Batch Size），但单芯 片的推理每Token成本更低。对于需要大规模并行推理的场景，多v5e芯片切分模型（流水线并行）是更经济的方案。 TPU v6e (Trillium)： 2024年发布，BF16算力达918 TFLOPS（较v5e提升2.5倍）。关键创新是SparseCore的升级版——支持从推荐的 Embedding表到稀疏Attention的多种稀疏运算，使TPU在推荐系统和MoE（Mixture of Experts）等场景中更高效。 TPU v7 (Ironwood)： 2025年发布，是迄今算力最强的 Google TPU，采用双Chiplet设计（每Chiplet含1个TensorCore + 2个SparseCore + 96GB HBM，两Chiplet通过6×速度的Die-to-Die ICI互联）： TPU v7 (Ironwood) per-chip specs:

 - BF16 compute: 2,307 TFLOPS (FP8: 4,614 TFLOPS)
 - HBM: 192 GiB per chip
 - HBM bandwidth: 7,380 GB/s (~7.37 TB/s)
 - ICI bidirectional bandwidth: 1,200 GB/s per chip
 - Data center network: 100 Gbps per chip

TPU v7 Pod (max config):

 - 9,216 chips (8×16×72 = 9,216 3D-Torus)
 - Total BF16 compute: ~21.3 EFLOPS
 - Total HBM: ~1.8 PB

对比v5p到v7的代际跃升：算力约5×，HBM容量约2×，HBM带宽约2.7×，ICI带宽相同（1,200 GB/s）。每Chiplet的 Die-to-Die互联带宽是单条ICI链路的6倍，显著降低了双Chiplet内的通信开销。

3.3.4 ICI 互联与光电路由

ICI（Inter-Chip Interconnect）是TPU的芯片间互联技术，不同于NVIDIA的NVLink（电互联）+ InfiniBand（光互联） 混合方案，Google采用了独特的光电混合方案。 TPU v5p ICI v4:

 - Per-chip bidirectional bandwidth: 4.8 Tbps (~5.3x NVLink 4.0)
 - Topology: 3D Torus (2D Torus between TPUs + inter-layer via OCS)
 - Optical Circuit Switch (OCS): MEMS micro-mirror based optical switching
   - Dynamically reconfigurable TPU interconnect topology
   - Physical fiber switching latency: ~10ms
   - Advantage: optimize topology per training task (e.g., All-to-All for AllReduce vs Hierarchical for TP (Tensor Para

llelism) / PP (Pipeline Parallelism)) OCS的拓扑可重构是Google的独门秘笈——在NVIDIA使用固定网络拓扑的情况下，Google可以在软件层面切换TPU Pod 的“物理”互联模式。这种灵活性在训练异质化的MoE模型或异构并行策略时相当有用。

3.3.5 Pathways 系统设计

Pathways是Google为TPU v4+集群设计的分布式编排系统，核心思想是“单控制器 → 多Worker”的MPMD（多程序多 数据）执行模型，允许单个控制器将不同程序分发到不同加速器子集，突破了传统SPMD（所有设备运行相同程序）的限 制：

 # Pathways programming paradigm (pseudocode)
 import jax
 # Declare sharding strategy across TPU
 mesh = jax.sharding.Mesh(
     devices=jax.devices(), axis_names=('data', 'model')

)

Define Sharding

partition_spec = jax.sharding.PartitionSpec( 'data', 'model' # Data parallel on 'data' axis, model parallel on 'model' axis )

JAX automatically handles cross-device sharding and communication

@jax.jit

 def train_step(params, batch):
     # JAX's pjit/pmap handles Sharding at the frontend
     return jax.grad(loss_fn)(params, batch)

Pathways的架构特点：

1. 程序级SPMD执行模型：每个子任务在其分配的加速器子集上以SPMD方式运行（同一程序在所有设备上执行，类似 MPI），通过collective通信同步，与PyTorch FSDP的SPMD理念一致
2. 动态资源分配：支持在训练进行中增/减TPU数量，利于集群碎片整理（但实践中很少使用）
3. GSPMD（Generalized SPMD）编译器：自动推断跨程序分区的Sharding，减少人工指定并行策略的工作量

3.3.6 TPU 与 GPU 对比

优势（TPU优于GPU）： •集群扩展性：光电路由（OCS）使TPU Pod的跨芯片通信比IB+H100更简洁，在4096 chip规模下仍可保持约75%+的弱 扩展效率 •能效比：TPU v5p的TFLOPS/W ≈ 4.0，H100 ≈ 1.4 — TPU约3倍能效优势（来自ASIC的功耗效率） •成本：Google Cloud定价中，TPU v5p的每TFLOPS/H价格通常比H100低30-40% 劣势（TPU劣于GPU）： •生态锁定：TPU无法离开Google Cloud运行（不存在本地部署TPU的可能性） •框架限制：仅JAX提供最佳TPU支持，PyTorch/XLA的TPU体验仍有显著差距 •灵活性：某些算法（如Tree-of-Thought推理、动态Batch、自定义Attention变种）在TPU上难以高效实现 •工具链成熟度：Profile工具、调试器、可视化工具等配套远不如NVIDIA Nsight

3.3.7 谷歌内外部用例

Google内部几乎全部AI训练和推理工作负载都在TPU上运行，包括Gemini系列模型（Ultra/Pro/Flash/Nano）、Gemma 开源模型、PaLM 2等。根据Google公开的论文，Gemini Ultra使用TPU v4 Pod训练，训练成本估计为数亿美元级别。 外部客户方面： •Anthropic（Claude系列）：使用TPU v5p训练（Google是其主要投资者） •Midjourney：部分推理负载迁移到TPU v5e •初创公司（HuggingFace, Cohere等）：通过Google Cloud的TPU Spot实例低成本使用

3.4 海外自研芯片

除了面向通用市场的 AMD 与 Google，AWS、Microsoft、Meta 等海外云厂商与互联网巨头也在走自研芯片路线。它们的 动机与挑战高度相似：海量 AI 推理负载需要极致 TCO，依赖单一供应商（NVIDIA）意味着巨大的供应链风险和成本压 力。华为昇腾属于国产替代路线，其规格与生态由国产芯片生态一节专门展开。

3.4.1 Trainium2 与 Inferentia2

AWS拥有最悠久的自研AI芯片历史，从2018年推出Inferentia v1至今已到第二代。Neuron SDK是整个生态的软件入口。 表3-7 Inferentia2 规格 参数 Inferentia2 (1 chip) 对比 NVIDIA T4 NeuronCore-v2 2 per chip — FP16 算力 190 TFLOPS 65 TFLOPS HBM 32GB 16GB 内存带宽 820 GB/s 300 GB/s 互联 NeuronLink-v2 PCIe Gen4 Inferentia2是推理专用芯片，单颗芯片的成本约为T4的1.5-2倍，但推理吞吐约为T4的4-6倍（针对BERT/Transformer模 型优化），TCO优势明显。 表3-8 Trainium2 规格 参数 Trainium2 (1 chip) 对比 NVIDIA H100 NeuronCore-v3 2 per chip — BF16 训练算力 650 TFLOPS 990 TFLOPS (FP16) FP8 算力 1300 TFLOPS 1979 TFLOPS HBM 96GB HBM3 80GB HBM3 内存带宽 4.6 TB/s 3.35 TB/s 互联 NeuronLink-v3 (768 GB/s) NVLink 4.0 (900 GB/s) Trainium2的定位是中端训练和高端推理的“甜点”（Sweet Spot）。96GB HBM使其天然适合405B大规模稠密模型的推 理（通过张量并行分布在2-4个芯片上）。 Trn2 Ultra（2025）：64颗Trainium2通过NeuronLink-v3互联为一个机柜级系统，提供约42 PFLOPS BF16算力和6TB统 一HBM，是AWS对标NVIDIA GB200 NVL72的竞争产品，已于2025年正式发布。 Neuron SDK：

 # Neuron SDK programming model
 # No model code changes needed
 import torch
 import torch_neuronx
 from transformers import LlamaForCausalLM
 # Compile model to Trainium
 model = LlamaForCausalLM.from_pretrained("meta-llama/Llama-2-7b-hf")
 model.eval()
 # Compile to Neuron executable
 neuron_model = torch_neuronx.trace(

model, example_inputs, # Example inputs for tracing # Compilation options compiler_workdir="./neuron_compile_cache" )

Inference

with torch.no_grad(): output = neuron_model(input_ids) Neuron SDK的核心是Neuron Compiler——将标准PyTorch模型编译为在Trainium/Inferentia上高效执行的二进制。编 译器自动处理并行、数据流水线、内存布局优化。 表3-9 Neuron 优势与限制 方面 表现 Llama/BERT推理 优秀（与H100相当或更优的每美元吞吐） 训练大模型 中等（支持但MFU低于H100约10-15%） 非Transformer架构 中等（编译器需要时间适配新算子） 动态Shape支持 较差（编译器偏好静态Shape） 与AWS服务集成 极佳（SageMaker/Bedrock原生支持） 生态自由度 完全锁定AWS（无法在本地或其他云使用）

3.4.2 Microsoft Maia 100

Microsoft于2023年发布Maia 100 AI加速器，是自研芯片领域的后来者。 架构特点： •5nm TSMC工艺，约120B晶体管 •与OpenAI深度合作设计（针对GPT系列模型优化） •专为Azure AI负载定制，尤其关注推理吞吐和延迟 •支持FP8/INT8推理，MX (Microscaling) 数据格式 Maia 100的核心优势不在芯片本身而在系统层——作为Azure的“第一方硬件”，配合Microsoft自有的液冷方案和网络方 案，Maia在Azure内部部署时可获得更优的机柜密度和功耗效率。OpenAI已确认在Azure上使用Maia 100进行部分推理负 载。

3.4.3 Meta MTIA v2

Meta的AI推理规模冠绝全球：每天处理数万亿次推荐模型推理和数十亿次内容理解推理。MTIA（Meta Training and Inference Accelerator）是Meta为这些推理工作负载定制设计的芯片。 表3-10 MTIA v2 规格 参数 MTIA v2 (1 chip) 备注 工艺 TSMC 5nm — 晶体管数 约60B — 矩阵乘法引擎 256×256 systolic + 4-wide 矢量 专用推荐模型加速 BF16 算力 354 TFLOPS INT8: 708 TOPS LPDDR5内存 128GB 非HBM（成本考虑） 内存带宽 1.6 TB/s LPDDR5 8500 MT/s TDP 约100W 功耗远低于H100的700W 互联 2× 200GbE Ethernet RDMA 封装 单Die 无Chiplet，控制封装成本 MTIA v2的设计哲学与NVIDIA GPU完全不同： •低算力、低功耗、高显存容量：针对推荐推理场景（Embedding Lookup + 少量MLP层），算力需求远低于 Transformer训练，但权重和Embedding表对显存容量要求巨大 •LPDDR5 vs HBM：通常HBM是AI芯片的“标配”，但Meta选择LPDDR5，牺牲内存带宽（1.6 vs 3.35 TB/s），但容量更 大（128GB vs 80GB）且成本更低。这个选择对推荐推理是合理的（推荐模型计算密集度低，带宽要求相对低） •Ethernet RDMA互联：不用NVLink/InfiniBand，直接走RoCE RDMA，这是Meta网络团队的已有基础设施，无需为 MTIA单独建立互联网络 性能定位： Meta确认MTIA v2主要用于推荐系统的推理（News Feed + Instagram Reels + 广告），不参与大模型训练。据测算， MTIA v2在推荐推理场景的每Watt性能是H100的3-4倍，每成本（含制造成本）性能是H100的6-8倍。 与GPU的共存： Meta并非用MTIA替代GPU，而是按负载划分： •训练：H100/B200 GPU（标准化CUDA生态） •大模型推理：H100/AMD MI300X •推荐推理（海量低延迟）：MTIA v2 这种“多加速器”架构需要有统一的调度和路由层。

3.4.4 海外自研芯片的动机与启示

云厂商与互联网巨头自研AI芯片的趋势给出了几个重要信号： •GPU不再等同于AI计算：AWS和Microsoft的成功证明了自研AI芯片在某些场景下提供更优的性价比 •软件生态比硬件更重要：Neuron SDK和Maia成功的关键在于它们能让用户“无痛”地从PyTorch模型迁移，这是AMD ROCm迄今未能完全做到的 •推理是主战场：自研芯片在推理场景的TCO优势更为明显（推理对灵活性要求低，对能效要求高） •锁定是双刃剑：使用自研芯片意味着无法迁移到其他云，这对企业的多供应商策略构成挑战 表3-11 海外自研芯片动机分析 公司 核心动机 替代目标 差异化场景 AWS 推理成本+云生态锁定 GPU推理 云原生训练+推理 Microsoft 推理成本+Azure差异化 GPU推理 云推理，与OpenAI协同 Meta 推理成本（约数亿美元/年） GPU推理 推荐模型（低算力高显存） 对于互联网公司，自研芯片的决策公式可简化如下： Custom chip NPV = (GPU procurement cost saved + energy efficiency electricity savings) - (R&D cost + tape-out cost + s oftware stack build cost + maintenance cost) Meta 之所以走这条路，是因为其AI推理年支出已达数十亿美元级别，自研芯片的规模效应足以覆盖研发和流片的固定成 本。

3.5 国内自研芯片

华为昇腾 910B/910C 与百度昆仑芯为国产 AI 芯片的头部方案。本节从整体生态视角，梳理国产 AI 芯片的两条技术路 线、代表性厂商与芯片规格，以及软件栈、互联与集群层面的工程现状。需要说明的是，除明确标注为官方规格的数据 外，本节大量指标来自厂商发布会与第三方公开报道，各来源数字存在分歧，引用前应交叉核实。

3.5.1 国产芯片格局与两条路线

1. 政策背景：美国出口管制自 2023 年 10 月起持续升级，2024 年 12 月再度加码，H100/H200/B200 等高端 GPU 无法对 华出货，NVIDIA 合规版 H20 算力受限严重。国产 AI 芯片由此成为训练与推理场景的替代主力，头部云厂商与各地智算中 心大规模采购国产方案。各地智算中心在招标与交付中普遍要求一定比例的国产算力，训练、微调与推理负载被逐步迁移 到国产芯片上。对云厂商与科研机构而言，国产芯片的采购决策不再是单纯的技术选型，而是供应链安全、TCO 与生态 兼容性的综合权衡。 国产 AI 芯片总体可归为两条技术路线： •专用AI芯片：围绕矩阵与矢量计算单元定制设计，通用性弱但能效与面积效率高。代表厂商与产品为寒武纪 MLU 思元 系列、燧原云燧系列、天数智芯天垓系列 •GPGPU路线：采用通用 GPU 架构，强调与 CUDA/HIP 编程模型的兼容性以复用既有生态。代表厂商为海光 DCU 深算 系列、摩尔线程 MUSA 系列、沐曦曦云系列、壁仞壁砺系列 两条路线并非互斥。专用 AI 芯片在固定形态的 Transformer 训练与推理中能效更优，但算法结构变化时调整成本高； GPGPU 路线牺牲部分能效换取可编程性与生态兼容，可平滑承接存量 CUDA 代码。工程实践中，团队通常以算子覆盖 度、框架兼容性和部署工具成熟度作为首要筛选条件，而非只看峰值算力。
2. 安可认证：据公开报道，2026 年安全可靠（安可）认证中，9 款国产 AI 芯片获批进入政府采购目录，覆盖昇腾、寒武 纪、海光等多家厂商。数据来源：公开报道（2026-01），最终以主管部门正式清单为准。
3. 资本化加速：2025 年国产芯片公司密集走向资本市场，标志国产算力进入产业化成熟阶段。寒武纪（688256）、海光 信息（688041）此前已分别于 2020、2022 年在科创板上市；2025 年摩尔线程（688795）、沐曦（688802）先后登陆科 创板，壁仞（06082.HK）于 2025 年 12 月登陆港交所，成为港股首家 GPU 概念股。上市使这些公司的财务数据与产能 进度公开可查，为后续扩产与研发提供资金支持，是评估国产算力产业实际进展的权威窗口。数据来源：上市公司公告 （2025-12）。 各厂商关键规格汇总如表3-12所示。 表3-12 国产AI芯片关键规格对比 厂商 型号 路线 主要精度算力 显存 卡间互联 数据来源 华为 昇腾910C 专用NPU FP16 约800 TFLOPS 128GB HBM3e HCCS 公开报道 华为 昇腾950DT 专用NPU FP16 最高547 TFLOPS 96GB HBM 未公布 官方白皮书 寒武纪 思元590 专用MLU FP16 256-345 TFLOPS 96-128GB HBM3 MLU-Link 公开报道 海光 深算三号Z110 GPGPU FP16 约192 TFLOPS 未公布 未公布 公开报道 摩尔线程 MTT S5000 GPGPU 全精度FP8-FP64 未公布 OAM模组 官方发布 沐曦 曦云C600 GPGPU 未公布 未公布 MetaXLink-E 公开报道 壁仞 壁砺166C GPGPU 未公布 未公布 OAM模组 公开报道 国产AI芯片产业全景 专用AI芯片路线 GPGPU路线 寒武纪 MLU 思元系列 燧原 云燧系列 天数智芯 天垓系列 海光 DCU 深算系列 摩尔线程 MUSA 系列 沐曦 曦云/曦思系列 壁仞 壁砺系列 图3-2 国产AI芯片产业全景分类树 如图3-2所示，两条路线在训练与推理场景均有覆盖，关键差异体现在软件兼容路径与生态迁移成本上。

3.5.2 华为昇腾

1. 910B/910C 规模出货：昇腾 910B/910C 自 2024 年四季度起向国内云厂商批量供货，2025 年大规模部署于华为云、 移动云、芜湖数据中心等。910C 芯片级规格（FP16 约 800 TFLOPS、128GB HBM3e）为公开报道口径，官方仅公布产 品级与集群级指标。数据来源：公开报道（2025-06）。
2. 昇腾910B 规格： 表3-13 昇腾910B 规格 参数 昇腾910B 对比 NVIDIA A100 对比 NVIDIA H100 工艺 7nm SMIC (自研) TSMC 7nm TSMC 4nm 架构 Da Vinci (达芬奇) Ampere Hopper FP16 算力 320 TFLOPS 312 TFLOPS 990 TFLOPS INT8 算力 640 TOPS 624 TOPS 1979 TOPS HBM 64GB HBM2e 80GB HBM2e 80GB HBM3 内存带宽 1.6 TB/s 2.0 TB/s 3.35 TB/s 互联 HCCS 480GB/s NVLink 600GB/s NVLink 900GB/s NPU间互联 HCCS 8卡互联 NVSwitch NVSwitch 3 TDP 约310W 400W 700W 910B 的实测性能（2024 年华为与百度联合评测）： •训练 LLM（7B-13B 参数）：910B 集群 MFU 约 35-42%（对比 A100 集群约 48-55%） •推理 LLM（7B-70B 参数）：同等 Batch Size 下每 Token 时延约为 A100 的 120-150%（性能约 65-80%） •910B 价格仅为 A100 的 60-70%，每元人民币的算力产出较为接近
3. CloudMatrix 384 超节点：2025 年 4 月发布，由 384 颗 910C 与 192 颗鲲鹏 CPU 组成，MatrixLink 全对等互联。密 集算力约 300 PFLOPS（官方发布会口径），单卡推理吞吐约 2300 tokens/s，官方对标 NVL72，演进目标为 8192 卡规 模。数据来源：华为官方发布会（2025-04）。
4. 昇腾950 系列：当前华为在售的旗舰 NPU 产品线： •950PR ：对应 Atlas 350 卡，FP16/BF16 算力 425 TFLOPS、MXFP4 算力 1561 TFLOPS、112GB HBM（带宽 1.4TB/s） •950DT：FP16 最高 547 TFLOPS、MXFP4 最高 2007 TFLOPS、96GB HBM（带宽 4TB/s） 数据来源：华为官方《昇腾950 NPU架构白皮书》、华为官网（2026-01）。
5. Atlas 950 SuperPoD：最大规模 1024×950DT，FP8 峰值 1 EFLOPS、MXFP4 峰值 2 EFLOPS，256TB 全局内存，总 互联带宽 1.72PB/s。数据来源：华为官方（2026-01）。
6. 软件栈：CANN 8.0/8.1 与 MindSpore、torch_npu 适配器构成全栈方案；PyTorch 2.1 起上游原生支持昇腾 NPU； DeepSeek R1/V3 等主流模型已完成适配。工程上，昇腾方案覆盖从 TBE 自定义算子、Ascend Graph 图编译到 MindIE 与 vllm-ascend 推理引擎的全链路。CANN 8.x 的算子融合与内存优化对长序列推理收益明显。对训练团队而言，从 CUDA 迁移到昇腾的主要成本集中在分布式通信库与集合通信原语的重写，以及自定义算子的算子级重写。

 # PyTorch on Ascend NPU via torch_npu
 import torch
 import torch_npu
 device = torch.device("npu:0")
 model = model.to(device)
 x = torch.randn(1, 128).npu()
 y = model(x)

CANN 与 CUDA 的软件栈对照： 表3-14 CANN 与 CUDA 对照 特性 CANN (Ascend) CUDA (NVIDIA) PyTorch支持 torch_npu适配器 原生支持 算子库规模 约1000+ (快速增加中) 约3000+ 自定义算子 TBE (Tensor Boost Engine) CUDA C++ / PTX Tensor Core Da Vinci Cube Unit Tensor Core Profiler msprof Nsight 成熟度 2-3年 18年

3.5.3 百度昆仑芯

百度昆仑是百度自研的AI推理芯片（昆仑芯2代，7nm工艺），已在百度搜索、小度、百度云等业务中大规模部署。具体架 构信息公开较少，定位为低功耗推理加速。昆仑芯 P800（2024 发布）是百度面向训练与推理场景的第三代产品，公开技 术细节有限，最新型号信息以百度官方披露为准。

3.5.4 寒武纪

•思元370 系列：MLU370-X8 训练卡官方规格为 FP16 96 TFLOPS、INT8 256 TOPS、48GB LPDDR5、MLU-Link 卡间互 联 200GB/s。数据来源：寒武纪官网（2026-01）。 •思元590（MLU590）：2024 年发布，2025 年起成为主力放量型号。第三方报道 FP16 算力 256-345 TFLOPS、96- 128GB HBM3。需注意各报道数字存在分歧，官方未公布完整规格。数据来源：公开报道（2025-12）。 •思元690：2026 年量产传闻，报道 FP16 算力 700+ TFLOPS。该数据未获官方证实。数据来源：公开报道（2026- 01）。 软件栈：Cambricon NeuWare 与 MagicMind 编译器提供算子库与图编译能力，支持 PyTorch、TensorFlow 前端。寒武 纪的产品线横跨云端训练与边缘推理：训练侧以思元 370/590 覆盖集群训练，推理侧有思元 220、270 等边缘产品。 MagicMind 负责将训练好的模型做图优化与量化编译，支持 INT8/INT4 量化部署，这是其在推理落地上的主要优势。对 迁移团队而言，寒武纪 SDK 对 PyTorch 的适配程度，以及 MLU-Link 在集群规模下的集合通信表现，是评估的关键项。

3.5.5 海光与摩尔线程

1. 海光 DCU 深算系列：走 GPGPU 路线，兼容 HIP/CUDA 编程模型，CUDA 代码迁移成本低。 •深算二号（Z100）：2023 年发布，报道 FP16 约 180 TFLOPS。数据来源：公开报道（2023-08）。 •深算三号（Z110）：2025 年发布并量产，报道 FP16 192 TFLOPS、INT8 392 TOPS、CUDA 兼容率超过 95%。官方未 公布完整规格。数据来源：公开报道（2025-06）。
2. 摩尔线程：基于 MUSA 架构的 GPGPU 方案。 •MTT S4000：2023 年发布，48GB GDDR6、MTLink 卡间互联 240GB/s。数据来源：摩尔线程官网（2026-01）。 •MTT S5000：2026 年发布，采用 PH100 芯片，支持全精度 FP8-FP64，OAM 模组形态，Llama3-70B 训练 MFU 超过 60%，单卡 Prefill 不低于 4000 tokens/s、Decode 不低于 1000 tokens/s，万卡线性度 95%。数据来源：摩尔线程官 方发布（2026-01）。 •夸娥 KUAE 智算集群：千卡线性加速比 91% 以上。数据来源：摩尔线程公开评测（2025）。 海光与摩尔线程都强调 CUDA 兼容以降低迁移成本。海光 DCU 通过兼容 HIP 语言实现 CUDA 源码的自动迁移，开发者改 动集中在少数不兼容 API；摩尔线程提供配套的 CUDA 代码迁移工具，将源码转换为 MUSA 后编译运行。这种策略的直接 收益是模型仓库与训练脚本的复用，但性能上限取决于算子优化深度，单纯翻译的算子往往达不到原生 CUDA 的利用效 率。

3.5.6 壁仞/燧原/天数/沐曦

1. 壁仞：BR100 于 2022 年发布，官方发布口径 INT8 2048 TOPS、BF16 1024 TFLOPS，BR104 为衍生型号。当前现售 的壁砺（Bili）166 系列按官方产品页分为三款：壁砺166M（风冷）与壁砺166L（液冷）为数据中心训推一体 AI 加速 OAM 模组，壁砺166C 为高性能推理 AI 加速卡，功耗 550W，算力未公布。壁砺系列主打训推一体与低成本部署，OAM 形态便于在标准服务器中插拔，其实际落地以运营商与智算中心项目为主。特色技术方面，壁仞在国内首次实现 GPU 与 OCS（光交换机）的通信连接并完成商用落地，配套 BIRENSUPA 自主软件开发平台。公司于 2025 年 12 月在港交所上市 （06082.HK），为港股首家 GPU 概念股。数据来源：壁仞官网、公开报道（2026-01）。
2. 燧原： •云燧 i20：2021 年发布，FP32 32 TFLOPS、INT8 256 TOPS、32GB HBM2E。数据来源：燧原官网（2026-01）。 •燧原 S60：2024-2025 年推理卡，基于 GCU320（邃思320）芯片的第三代推理加速卡，PCIe 5.0 接口，适配 200 余款 模型，面向大语言模型与搜广推场景。数据来源：燧原官网、公开报道（2025）。 •云燧 T20：训练卡，报道 FP16 约 200 TFLOPS。数据来源：公开报道（2024）。 •云燧超节点：以云燧 OGX 与云燧超节点为形态的整柜训练方案，配套云燧智算集群交付。数据来源：燧原官网（2026- 01）。 燧原较早转向纯推理市场，S60 依托 PCIe 5.0 与低功耗定位，在私有化与边缘推理场景出货较多；云燧 T20 面向训练， 市场声量弱于昇腾与寒武纪。
3. 天数智芯： •天垓100（BI-V100）：2021 年发布，32GB HBM2，为国内首款全自研云端训练 GPU。数据来源：天数智芯官网 （2026-01）。 •天垓150：64GB HBM、功耗 350W。数据来源：公开报道（2024）。 •智铠100：推理卡，32GB HBM2E。数据来源：天数智芯官网（2026-01）。 天垓系列以训练为主要定位，官方强调全自研 IP；智铠系列面向推理，承接模型服务与边缘应用。
4. 沐曦： •曦云 C 系列：训练卡，含 C500/C550（64GB 显存）、C588 与旗舰 C600（OAM2.0 形态，功耗 1000W，MetaXLink-E 互联最高支持 128 卡超节点）。数据来源：沐曦官网、公开报道（2026-01）。 •曦思 N 系列：推理卡，含 N100/N260/N300，面向云端推理场景。数据来源：沐曦官网（2026-01）。 •曦索 X 系列：X206/X301/X302，覆盖推理加速与工作站形态。数据来源：沐曦官网（2026-01）。 •超节点方案：曦云 C550 Shanghai Cube 液冷整机柜、曦云 C550 3D Mesh 超节点、曦云 C500X 光链超节点，以整机 柜形态交付。数据来源：沐曦官网（2026-01）。 沐曦在智算中心项目中标较多，其超节点方案强调以 128 卡为最小集群单元，降低大规模组网的调度与通信复杂度。公 司于 2025 年在科创板上市（688802），并持续维护 vLLM 的 MetaX 后端镜像（vllm-metax）与 PyTorch 适配层，佐证 其推理生态进展。数据来源：上市公司公告、沐曦开发者社区（2026-01）。

3.5.7 国产芯片生态挑战与趋势

1. 软件栈成熟度：CANN 与类 ROCm 生态在算子覆盖、框架适配、调试工具三方面与 CUDA 仍有代差。算子库规模从数 百到一千多，明显小于 CUDA 生态的数千规模；框架适配以 PyTorch 为主，多数厂商依赖适配层（torch_npu 及各类 torch 插件），而非上游原生支持。调试与性能分析工具的差距尤为明显：CUDA 生态的 Nsight 系列可对核函数、显存、 通信做细粒度剖析，国产软件栈的 profiler 在算子级以下的可观测性普遍不足，导致性能问题定位困难。算子覆盖方面， MoE 路由、多模态编解码等长尾算子常需厂商跟进或用户自研。
2. 互联与集群：如表3-15所示，卡间互联带宽（MLU-Link 200GB/s、MTLink 240GB/s、HCCS 约480GB/s）显著低于 NVLink 5 的 1.8TB/s，万卡集群扩展性受限。华为 CloudMatrix 与沐曦 MetaXLink-E 正通过超节点形态弥补互联差距。 表3-15 国产卡间互联与超节点对比 互联技术/超节点 厂商 规格 说明 NVLink 5 NVIDIA 1.8TB/s 参考基线 HCCS 华为 约480GB/s 昇腾910系列 MLU-Link 寒武纪 200GB/s 思元370系列 MTLink 摩尔线程 240GB/s MTT S4000 MetaXLink-E 沐曦 未公布 曦云C600 CloudMatrix 384 华为 384×910C，约300 PFLOPS 对标NVL72 Atlas 950 SuperPoD 华为 1024×950DT，FP8 1 EFLOPS 2026年发布
3. 制程与产能约束：先进制程依赖与 HBM 供应是普遍瓶颈。晶圆代工良率与产能爬坡、HBM 采购均受供应链约束，限 制下一代芯片的规模化量产。
4. 推理生态进展：DeepSeek R1/V3 等主流模型已完成昇腾等多平台适配；vLLM、SGLang 等推理引擎对国产芯片的后 端支持逐步完善，推理部署成本持续下降。开源推理栈已把昇腾等国产芯片纳入支持范围，部署团队通常先在主流推理引 擎上验证 P99 时延与吞吐，再决定是否深入算子级调优。MXFP4 与 FP8 精度的引入表明国产芯片正跟随国际主流路线， 把量化算力作为新的竞争维度。
5. 演进趋势：如图3-3所示，竞争焦点正从 FP8/FP16 峰值算力，转向 HBM3E 容量与带宽，再转向对标 NVL72 的超节点 级集群竞争。 2021 2022 2023 2024 2025 2026 云燧i20、天垓100 壁仞BR100、思元370 深算二号、MTT S4000 910C放量、思元590 CloudMatrix 384、深算三 昇腾950、MTT S5000 号 图3-3 国产AI芯片演进时间线 如图3-3所示，国产芯片密集放量始于 2023-2024 年出口管制升级之后；昇腾950、MTT S5000 等新一代产品相继发布， 头部厂商进入超节点与下一代架构的竞争阶段。

3.5.8 国产算力模型迁移适配

前述小节梳理了国产芯片的规格与生态现状，本小节补充从 NVIDIA/CUDA 迁移到国产芯片的实践方法，不重复规格数 据。端到端迁移按框架适配、算子适配、精度对齐、性能调优四步推进，每步都以量化指标验收，最终以与 NVIDIA 基线 的精度与性能双对标作为收尾。

1. 迁移总体流程 CUDA 模型 框架适配 算子适配 精度对齐 性能调优 生产部署 PyTorch 代码 torch_npu 等适配层 算子映射与长尾自研 逐层对比与基准测试 MFU 与吞吐对标 图3-4 模型迁移到国产芯片的端到端流程 如图3-4所示，四步之间有强依赖：框架适配决定模型能否跑起来，算子适配决定算子覆盖度，精度对齐决定结果正确 性，性能调优决定实际可用性。每步都应产出可量化结果，而不是停留在「能跑」的判断。
2. 框架适配层 PyTorch 接入国产后端的标准路径是适配层插件：昇腾 torch_npu、寒武纪 torch_mlu、海光 torch_dcu、摩尔线程 torch_musa。适配层在 PyTorch 的 ATen 分发机制上注册目标设备后端，把 aten 算子派发到厂商算子库，模型代码只需 把 model.cuda() 改为目标设备调用（ .npu() 、 .mlu() 等）。GPGPU 路线的海光与摩尔线程还可通过 HIP/MUSA 的 CUDA 兼容接口直接编译存量源码，降低框架层改动，但算子级审计不可省。 框架适配的验收重点是算子覆盖度与设备一致性： •算子覆盖度：跑代表性前向与反向，统计未映射或回退到 CPU 的算子清单 •设备一致性：前向过程中所有中间张量应停留在目标设备，任何张量回退 CPU 都意味着算子缺失或 dtype 不匹配 •不支持算子回退：适配层对未实现算子默认回退 CPU，训练因 CPU-GPU 反复拷贝而严重降速，需通过设备检查尽早暴 露

 # Detect ops whose intermediate tensors fall back to CPU
 import torch
 def check_device(model, sample, target):
     off = []
     def hook(module, inp, out):
         tensors = out if isinstance(out, (tuple, list)) else [out]
         for t in tensors:
             if torch.is_tensor(t) and t.device != target:
                 off.append((module.__class__.__name__, str(t.device)))
     for m in model.modules():
         m.register_forward_hook(hook)

with torch.no_grad():

         model(sample)
     return off
 # Usage: audit a model moved to Ascend NPU, Cambricon MLU or MUSA device
 # off = check_device(model, sample, torch.device("npu"))

3. 算子适配 算子级迁移以映射表为起点，把 CUDA 的运行时 API 与算子逐项对应到目标平台接口，如表3-16所示。 表3-16 CUDA 到国产平台的算子与 API 映射 能力 CUDA 昇腾 CANN 寒武纪 海光 ROCm 摩尔线程 MUSA 显存分配 cudaMalloc aclrtMalloc cnrtMalloc hipMalloc musaMalloc 流管理 cudaStreamCreate aclrtCreateStream cnrtCreateStream hipStreamCreate musaStreamCreate 集合通信 NCCL HCCL MLU-Link 通信库 RCCL MUSA 通信库 矩阵乘 cuBLAS GemmEx CANN 算子库 CNNL hipBLAS MUSA 算子库 内核编写 CUDA kernel AscendC/TBE BANG HIP kernel MUSA kernel 映射后的处理逻辑： •高频算子：GEMM、LayerNorm、Softmax、FlashAttention 应落在厂商算子库，映射完成后逐算子做精度与性能基准 •长尾算子：MoE 路由、多模态编解码、量化反量化等算子库未必覆盖，需用厂商内核语言自研，昇腾用 AscendC/TBE、寒武纪用 BANG，或通过 PyTorch 自定义算子注册（torch::Library）接入 •自研验收：自研算子与映射算子采用同一验收口径，输出对比加性能记录，避免「能跑但慢」的隐性退化
4. 精度对齐 迁移后精度验证分两层，方法与精度评测方法论一致： •逐层输出对比：同一权重、同一输入下，逐层对比目标平台与 CUDA 参考的隐状态或激活值，用余弦相似度与最大相 对误差定位偏差算子 •模型级基准对比：在标准能力基准上运行目标平台模型，与 CUDA 结果对比任务分数与困惑度；分数差在基准单次运 行波动（约 1-2%）内视为达标，显著下降则下钻到算子级定位 精度差异来源集中在三处： •数值格式：各平台对 BF16/FP16 的尾数位宽与累加精度支持不同，中间累加从 FP32 退化为低精度会放大误差 •算子实现：GEMM 累加顺序、FMA 融合、FlashAttention 变体、RMSNorm 实现差异都会引入可测偏差，同精度下不 同实现天然不等位，需区分允许偏差与越界偏差 •损失缩放：FP16 训练场景下 loss scaling 阈值设置不同会改变梯度分布
5. 性能调优 迁移后的性能瓶颈按优先级排查： •算子覆盖：未映射算子回退 CPU 是最大的性能杀手，先保证算子覆盖度再谈优化 •显存管理：国产栈的显存分配与碎片处理不同，峰值显存与缓存复用需按平台 profiler 调整 •通信库：HCCL、RCCL 等集合通信库在集群规模下的带宽利用与 NCCL 存在差距，需对齐互联拓扑（如昇腾 HCCS 与 超节点形态）并配合梯度累积降低通信频率 •图编译：CANN、NeuWare 的图编译与算子融合对性能影响显著，开启后需复测算子级与模型级指标 性能对标方法：与 NVIDIA 基线的对比必须控制变量，同一模型、同一精度位宽、同一 batch 与序列长度、同一评测口 径，分别记录 MFU、训练吞吐与推理 P99 时延，形成国产与 NVIDIA 的双栏报告；MFU 差距按算子、通信、显存三部分 分项归因，而不是停留在总体数字上。 迁移适配是国产算力落地中比硬件规格更关键的环节，四步验收标准都应是量化指标。

3.6 架构创新芯片

除了GPU和ASIC的传统路线之争，近年来涌现了一批以颠覆性架构为目标的新型AI芯片公司。它们挑战的是NVIDIA“好 的足够用”的GPGPU设计范式，试图在特定维度实现数量级的效率提升。

3.6.1 Groq LPU 确定性调度

Groq（注意，不是Elon Musk的Grok AI）的LPU（Language Processing Unit）采用了完全不同的设计哲学： 架构核心： “编译器主导的确定性调度” + “全SRAM、无HBM” Groq芯片的关键指标： 表3-17 Groq LPU 规格 参数 Groq LPU 对比 NVIDIA H100 片上SRAM 230MB (GroqChip v1) 约60MB (L1+L2) 外部内存 无（全SRAM） 80GB HBM3 内存带宽 约80 TB/s (片上SRAM) 3.35 TB/s (HBM) 峰值算力 188 TOPS (INT8) / 94 TFLOPS (FP16) 990 TFLOPS (FP16) 互联 芯片间 Fabric (多LPU) NVLink + IB TDP 约300W 700W Groq的核心理念——确定性执行： 与GPU通过Warp调度、缓存、分支预测等运行时决策来应对动态性不同，Groq将所有调度决策在编译时完成： Traditional GPU execution:

1. Compiler generates machine code -> 2. Runtime Warp Scheduler dynamic dispatch -> 3. Runtime handles Cache Miss, Bra nch prediction, divergent Warps -> High latency, unpredictable timing Groq LPU execution:
2. Compiler statically schedules all instructions -> 2. Hardware executes strictly on clock cycles (no scheduler, no c ache) Advantages:

 - 0% scheduling overhead (GPU has ~5-10%)
 - Precise latency prediction
 - No cache needed (all data movement determined at compile time)

全SRAM的代价与收益： Groq为何放弃HBM全用SRAM？以Llama2-70B为例做定量分析： Data requirements for Llama2-70B single Token inference:

 - Model weights: ~140GB (FP16)
 - KV Cache (seq_len=2048, FP16): ~640MB (GQA, 8 KV heads) / ~5.4GB (full MHA, 64 KV heads)
 - Total data per Token: ~3-5MB (depends on Attention window size)

Groq approach (230MB SRAM/chip):

 - Entire model distributed across ~600-800 LPUs (140GB / 230MB ≈ 609)
 - Each LPU's SRAM stores partial weights + KV Cache
 - Inference latency: Token data flows within SRAM, no HBM latency

H100 approach (80GB HBM + 60MB on-chip):

• Entire model needs ~2 H100 GPUs (70B model 140GB / 80GB)
• Each inference Token needs weight read from HBM (~3-5MB), latency ~2-4ms Groq的极致低延迟源自“无外部内存访问”，数据永远在SRAM中，不存在HBM的400-800 cycle延迟。 LPU的优势与困境： 表3-18 Groq LPU 评估 维度 Groq LPU 评估 推理延迟 极佳（<50ms TTFT for 70B model） 核心卖点 推理吞吐 中等（受限于跨芯片通信带宽） 需要大量芯片 训练 不支持 确定性调度无法处理训练的动态反向传播 成本/Token 高昂（需约600+ chips跑一个70B模型） 极致低延迟的代价 适用场景 实时对话/AI Agent/低延迟API 小众但有价值 Groq在2024年的演示中展示了以接近人类阅读速度（约500 tokens/s）进行70B参数模型推理的能力，这是任何HBM- based GPU目前无法达到的。但其成本结构使其更适合低延迟要求极高的场景（如企业级的实时AI客服），而非高吞吐的 批量推理。

3.6.2 Cerebras 晶圆级芯片

Cerebras走的是另一个极端——不做小芯片，而是做超大型单芯片。WSE-3（Wafer Scale Engine 3）是迄今为止最大的 半导体芯片： 表3-19 WSE-3 规格 参数 WSE-3 对比 NVIDIA H100 芯片面积 46,225 mm² 814 mm² 晶体管数 约4万亿 (4T) 800亿 (80B) 核心数 90万个计算核心 16896 CUDA Core + 528 Tensor Core 片上SRAM 44GB 约60MB (L1+L2) 内存带宽 21 PB/s (片上SRAM) 3.35 TB/s (HBM) 外部内存 MemoryX (外挂HBM盒子) 80GB HBM3 onboard FP16 峰值 约100 PFLOPS 990 TFLOPS TDP 约23kW (CS-3系统) 700W/GPU 晶圆级集成的优势： WSE-3的最大创新是“不切割Wafer”，通常一片300mm晶圆可切割约60-80块H100芯片，但Cerebras干脆不切割，将整 片晶圆做成一个巨型芯片。 Advantage 1 - Extreme memory bandwidth: 21 PB/s on-chip SRAM bandwidth vs 3.35 TB/s HBM -> Data movement is no longer the bottleneck -> No frequent Checkpoints needed during training (data always on-chip) Advantage 2 - Ultra-low communication latency: All 900K cores on the same chip, communication latency <1ns (cross-core) -> No GPU cluster NVLink/IB latency (microseconds) -> Orders of magnitude better for "communication-intensive" tasks (e.g., specific GNN topologies) Advantage 3 - Trainable model scale: Single WSE-3 has 44GB SRAM + external MemoryX (1.2TB HBM) Theoretically can train models with trillions of parameters (via unique "weight streaming" architecture) 实用性挑战： •良率：面积越大缺陷概率越高。Cerebras采用“冗余核心”设计，多余的“备用核心”（约1.5%）在制造缺陷后路由替 代 •功耗密度：23kW/系统，需要专用液冷方案 •成本：CS-3系统约$2-3M（与高端GPU集群可比，但软件生态差距大） •生态：基于专有编译器和框架（Cerebras Software Platform），PyTorch兼容性好但不完美 Cerebras的主要客户包括美国国家实验室和药企（用于分子动力学、蛋白质折叠、气候模拟等HPC+AI负载），商业AI应用 也较少。

3.6.3 Graphcore 与 SambaNova

Graphcore IPU (Intelligence Processing Unit)： IPU采用 MIMD (Multiple Instruction, Multiple Data) 架构，与GPU的SIMT从根本上不同： •每个核心有独立内存和独立程序计数器 •适合稀疏图结构、不规则数据访问模式 •在GNN（图神经网络）和知识图谱推理中表现优于GPU •但被大模型Transformer的算力需求碾压，公司于2023–2024年间因市场竞争和融资困难陷入财务危机，进行大规模裁 员并寻求战略出路；软银此前已是其主要投资方 SambaNova RDU (Reconfigurable Dataflow Unit)： RDU是可重构数据流处理器，介于FPGA和ASIC之间： •编译器决定每个操作在芯片上的物理位置和数据流路径 •适合细粒度的稀疏计算和低精度（INT4/FP8）推理 •在特定Transformer模型上每Watt性能优于H100 •总成本较高，同样面临GPU生态的竞争压力

3.6.4 架构创新的十字路口

表3-20 架构创新芯片对比 公司 架构创新 核心优势 核心挑战 Groq 确定性调度 + 全SRAM 极致低延迟 成本极高，不支持训练 Cerebras 晶圆级芯片 海量片上带宽 良率风险，成本，生态 Graphcore MIMD架构 不规则计算 大模型算力不足 SambaNova 可重构数据流 高能效 通用性不足 这些公司的共同困境是：NVIDIA每年的架构迭代速度和CUDA生态的巨大惯性，使得任何新架构即使在某维度领先，也极 难在整体解决方案上超越GPU。大模型训练当前首先看“单卡/单系统能跑多少参数”，而在这个指标上晶圆级芯片领先， 但在软件的生态完备性上仍需追赶。

3.7 异构计算编程模型对比

AI Infra工程师面临的核心挑战之一是“如何让同一套训练/推理代码在NVIDIA GPU、AMD GPU、Intel GPU、TPU、 Ascend NPU上高效运行”。本章系统对比主要的异构编程模型，帮助读者建立移植决策框架。

3.7.1 编程模型代际关系

CUDA (NVIDIA, 2006) OpenCL (2009) C++ extensions + PTX asse First cross-platform standa OpenMP 5.0+ mbly rd GPU Offloading support Market share 85%+, most Per-vendor implementatio Compiler directive style mature n, verbose API HIP (AMD, 2016) SYCL/DPC++ (Intel, 2019) CUDA-compatible model Khronos standard, multi-v hipify auto-conversion too endor l C++17 + Khronos SYCL Kokkos (C++ abstraction la yer) US National Labs RAJA (LLNL) 图3-5 异构编程模型的关系与演进

3.7.2 跨模型实现对比

以“向量相加”为例，对比各模型的编程风格： CUDA (NVIDIA 原生)： // CUDA C++: most concise, most mature #include <cuda_runtime.h> global void vec_add(const float* a, const float* b, float* c, int n) { int idx = blockIdx.x * blockDim.x + threadIdx.x; if (idx < n) c[idx] = a[idx] + b[idx]; } int main() { const int N = 1 << 20; float d_a, d_b, d_c; cudaMalloc(&d_a, N * sizeof(float)); cudaMalloc(&d_b, N * sizeof(float)); cudaMalloc(&d_c, N * sizeof(float)); vec_add<<<(N+255)/256, 256>>>(d_a, d_b, d_c, N); cudaDeviceSynchronize(); cudaFree(d_a); cudaFree(d_b); cudaFree(d_c); } HIP (AMD)： // HIP: syntax nearly identical to CUDA (hip prefix replaces cuda) #include <hip/hip_runtime.h> global void vec_add(const float a, const float* b, float* c, int n) { int idx = blockIdx.x * blockDim.x + threadIdx.x; if (idx < n) c[idx] = a[idx] + b[idx]; } int main() { const int N = 1 << 20; float *d_a, *d_b, *d_c; hipMalloc(&d_a, N * sizeof(float)); // cuda ▶ hip hipMalloc(&d_b, N * sizeof(float)); hipMalloc(&d_c, N * sizeof(float)); vec_add<<<(N+255)/256, 256>>>(d_a, d_b, d_c, N); hipDeviceSynchronize(); hipFree(d_a); hipFree(d_b); hipFree(d_c); } SYCL/DPC++ (Intel, 跨厂商)： // SYCL 2020: standard C++17, no language extensions #include <sycl/sycl.hpp> int main() { const int N = 1 << 20; sycl::queue q(sycl::gpu_selector_v); // Select GPU device

     float* d_a = sycl::malloc_device(N, q);
     float* d_b = sycl::malloc_device(N, q);
     float* d_c = sycl::malloc_device(N, q);
     q.parallel_for(sycl::range<1>(N),

[=](sycl::id<1> idx) { d_c[idx] = d_a[idx] + d_b[idx]; } ).wait(); sycl::free(d_a, q); sycl::free(d_b, q); sycl::free(d_c, q); } OpenCL (最古老跨平台标准)： // OpenCL 1.2: verbose, error-prone, still used in some HPC scenarios const char* kernel_src = "__kernel void vec_add(__global const float* a," " __global const float* b," " __global float* c, int n) {" " int idx = get_global_id(0);" " if (idx < n) c[idx] = a[idx] + b[idx];" "}";

3.7.3 迁移策略对比

 // Requires explicit management: cl_platform_id, cl_device_id, cl_context,
 //              cl_command_queue, cl_program, cl_kernel ...
 // Code volume about 3-5x that of CUDA

表3-21 迁移策略对比 策略 方法 优势 劣势 源码转译 hipify / dpct 自动化程度高，适合大量代码 不100%覆盖，需人工修正 宏封装 #define cudaMalloc hipMalloc 单代码库编译多目标 仅覆盖API级别，Kernel语法可能不同 策略 方法 优势 劣势 抽象层 Kokkos, RAJA 标准化跨后端，性能可移植 学习成本高，社区小 框架复用 仅用PyTorch/JAX 100%由框架处理 失去底层优化控制

1. CUDA 到 HIP 自动转换

 # Use AMD's hipify
 # Install: comes with ROCm
 # Convert single file
 hipify-perl cuda_kernel.cu > hip_kernel.cpp
 # Batch convert entire project

find . -name ".cu" -o -name ".cuh" | xargs -I {} hipify-perl {} > {}.hip.cpp

 # Common issues requiring manual handling
 # 1. warp synchronous operations: __syncwarp
 # 2. CUDA Cooperative Groups -> use HIP cooperative groups (limited support)
 # 3. texture memory: cudaTextureObject_t
 # 4. CUDA Graphs -> not supported in HIP

2. PTX 内联汇编重构 // Problematic code: uses inline PTX (NVIDIA GPU only) asm volatile("mma.sync.aligned.m16n8k16.row.col.f16.f16.f16.f16" " {%0,%1,%2,%3}, {%4,%5,%6,%7}, {%8,%9}, {%10,%11,%12,%13};" : "=r"(d0), "=r"(d1), "=r"(d2), "=r"(d3) : "r"(a0), "r"(a1), "r"(a2), "r"(a3), "r"(b0), "r"(b1), "r"(c0), "r"(c1), "r"(c2), "r"(c3)); // Solution: replace PTX with WMMA API wmma::fragment<wmma::matrix_a, 16, 16, 16, half, wmma::row_major> a_frag; wmma::fragment<wmma::matrix_b, 16, 16, 16, half, wmma::col_major> b_frag; wmma::fragment<wmma::accumulator, 16, 16, 16, float> c_frag; wmma::mma_sync(c_frag, a_frag, b_frag, c_frag); // WMMA is CUDA C++ standard API, each backend can provide equivalent implementation
3. Kokkos 可移植抽象层

#include <Kokkos_Core.hpp> // Kokkos portable implementation: CUDA/HIP/SYCL/OpenMP auto-selection void vec_add_kokkos(int N) { Kokkos::View<float*> a("a", N), b("b", N), c("c", N); Kokkos::parallel_for("vec_add", N, KOKKOS_LAMBDA(const int i) { c(i) = a(i) + b(i); } );

3.7.4 框架异构支持现状

 }
 // Compile options determine backend: -DKokkos_ENABLE_CUDA / -DKokkos_ENABLE_HIP / -DKokkos_ENABLE_SYCL
 # PyTorch 2.4+ device abstraction
 import torch
 # NVIDIA CUDA - default backend
 device = torch.device('cuda')
 # AMD ROCm
 device = torch.device('cuda')     # ROCm also reports as 'cuda' (in HIP code)
 # Intel XPU
 import intel_extension_for_pytorch as ipex
 device = torch.device('xpu')
 # Apple MPS
 device = torch.device('mps')
 # Heterogeneous detection
 def get_device():
     if torch.cuda.is_available():
         return torch.device('cuda')
     elif hasattr(torch, 'xpu') and torch.xpu.is_available():
         return torch.device('xpu')
     elif torch.backends.mps.is_available():
         return torch.device('mps')
     return torch.device('cpu')

框架级的异构支持成熟度（2025年中）： 表3-22 框架异构支持成熟度 框架 CUDA ROCm SYCL/XPU Ascend PyTorch 完全 主流支持 (2.0+) Beta (2.4+) 通过torch_npu JAX 完全 实验性 不支持 不支持 TensorFlow 完全 基本 基本 通过CANN DeepSpeed 完全 部分 不支持 不支持 Megatron-LM 完全 实验性 不支持 不支持 结论：在2025年的技术生态下，NVIDIA CUDA仍是唯一对全层级（硬件→编译器→库→框架→模型）完全支持且不存在 实质短板的平台。跨平台迁移的现实策略是“主流代码使用CUDA，通过PyTorch API抽象保留可移植性；需要极限优化 的地方使用后端原生实现”。

3.8 硬件选型与 TCO 对比

AI硬件的选型是最具挑战性的基础设施决策之一。错误的选择可能导致高达数百万美元的效率损失。本节提供一套系统 性、数据驱动的选型框架。

3.8.1 TCO 评估框架

AI硬件的TCO（Total Cost of Ownership）不应仅考虑采购价格，而应覆盖完整生命周期： TCO_3yr = CapEx + OpEx_3yr + OpportunityCost Where:

 CapEx = GPU server cost + network (switch/optical) cost + storage cost + facility modification cost
 OpEx_3yr = (power cost + cooling cost + ops labor + software License + network bandwidth) x 3yr
 OpportunityCost = (time-to-market delay from training time difference) + (user churn from excessive inference latency)

更实用的简化为每GPU-Hour的有效成本： GPU-Hour total cost = (CapEx / lifetime GPU hours) + per GPU-Hour power cost + platform overhead Lifetime GPU hours = 8760 hours/yr x 3yr x utilization 利用率的影响被严重低估： Scenario comparison (H100, $35K/unit, electricity $0.10/kWh):

 - 30% utilization: ($35K/3yr+$0.07/h power) / (8760x0.30)h = ~$4.85/GPU-h
 - 50% utilization: ($35K/3yr+$0.07/h power) / (8760x0.50)h = ~$2.99/GPU-h
 - 70% utilization: ($35K/3yr+$0.07/h power) / (8760x0.70)h = ~$2.21/GPU-h

That is, raising utilization from 30% to 70% reduces per GPU-hour cost by 56%

3.8.2 硬件规格与价格速查

表3-23 硬件规格与价格速查 GPU/加速卡 价格 (估算, 美元) FP16 (TFLOPS) 显存 互联带宽 NVIDIA H100 $30K-40K 990 80GB HBM3 NVLink 900GB/s NVIDIA H200 $35K-45K 990 141GB HBM3e NVLink 900GB/s NVIDIA A100 $15K-20K 312 80GB HBM2e NVLink 600GB/s NVIDIA L40S $8K-12K 362 48GB GDDR6 PCIe Gen4 AMD MI300X $25K-35K 1307（稀疏） 192GB HBM3 IF 4.0 AMD MI250X $12K-18K 383 128GB HBM2e IF 3.0 Intel Gaudi 3 $20K-25K 1835 (BF16) 128GB HBM2e 24×200GbE AWS Trainium2 云按需 ($3-4/h) 650 (BF16) 96GB HBM3 NeuronLink Google TPU v5p 云按需 ($4-5/h) 459 (BF16) 95GB HBM ICI 4.8Tbps Google TPU v5e 云按需 ($1.5-2/h) 197 (BF16) 16GB HBM ICI 华为昇腾910B ¥80K-120K (约$12-17K) 320 64GB HBM2e HCCS 480GB/s 完整规格见附录B。

3.8.3 各场景硬件 TCO 对比

场景1: 训练 Llama2-70B（新模型，需数千GPU小时） 表3-24 训练场景 TCO 对比 硬件 训练时长 (估算) 硬件成本 MFU 有效性能 64×H100 2.5 天 $35K×64 = $2.24M 约50% 基准 64×A100 5天 $18K×64 = $1.15M 约48% 1.0× (20%成本) 64×MI300X 3.5 天 $30K×64 = $1.92M 约38% 0.86× 128×昇腾910B 7天 $15K×128 = $1.92M 约35% 0.67× 结论：在上述价格与 MFU 假设下，H100 在训练场景综合表现最佳（最快的上市时间 + 最好的 MFU）。A100 性价比最高 但如果算力紧张（排队），时间损失超过收益。MI300X 和昇腾在生态成熟度上仍有差距，训练场景需结合生态与工具链评 估。 场景2: 推理 Llama2-70B（SLA: p99 TTFT <200ms, TPOT <30ms） 表3-25 推理场景 TCO 对比 硬件 所需卡数 硬件成本 推理吞吐 (tokens/s/卡) 评估 2×H100 1节点 $70K 约12,000 性能标杆 2×H200 1节点 $80K 约15,000 最佳吞吐 1×MI300X 1节点 $30K 约11,000 最高性价比（大显存） 2×A100 1节点 $36K 约8,000 经济选项 3×L40S 1节点 $30K 约9,000 (总计) 低成本选项 4×昇腾910B 2节点 $60K 约7,500 (总计) 国产唯一选择 Groq 约600 LPU 约$1.2M+ 约100,000 (超低延迟) 极致低延迟用例 关键洞察： •MI300X因其192GB HBM3（是H100的2.4倍），是70B模型推理的单一最优性价比硬件——一张卡即可容纳整个量化的 70B模型权重，省去NVLink通信开销 •H200在大显存（141GB）和更好的工具链之间提供了平衡 •L40S在吞吐成本上具竞争力，但GDDR6内存限制了KV Cache容量，导致长序列推理性能恶化 场景3: 大模型推理（Llama-405B，Dense，需4+张卡张量并行） 表3-26 大模型推理 TCO 对比 硬件 所需节点 硬件成本 推理吞吐 (估) 评估 8×H100 DGX 1 $300K 约10K t/s 工业标准 4×MI300X 1 (4 GPU) $120K 约9K t/s 性价比极优 TPU v5p (8 chips) 云 约$38/h 约8K t/s 云原生最佳 16×A100 2 (2 node) $288K 约7K t/s 存量设备可用

3.8.4 决策树

Need to train large model? Yes No Sufficient budget? Inference workload type? Yes No Large-scale online Small/batch/offline H100/H200/B200 A100 (used cluster) L40S / A100 MIG CUDA ecosystem dominan or cloud H100 Spot Model size? Cost priority t Balance cost and performa Low latency not critical Highest training MFU nce <13B 13B-70B >70B / MoE H100 / L40S Strict latency requirement Single card sufficient s? Supplier strategy? Cloud H100 on-demand Yes (<50ms TTFT) No (200ms TTFT OK) Multi-vendor NVIDIA only Cloud native H100/H200 + vLLM H100/H200 + MI300X mixe H200 DGX / GB200 NVL (lar AWS Trainium2 / Google T PagedAttention optimized MI300X (best value VRAM) d inference ge scale) PU v5p or Groq LPU (extreme low l or H200 (balanced) Avoid single vendor lock-in Full NVLink domain optimi Cloud vendor managed inf atency) zation erence 图3-6 AI硬件选型决策树 按场景（预训练/微调/推理/科学计算）的 GPU 推荐分层如图3-7所示，可快速锁定候选硬件。 图3-7 GPU 场景推荐决策树 Scenario -> GPU recommendation: LLM pretraining (>100B params, >=1000 GPUs): ├── Flagship: B200 (highest compute, largest memory) ├── Mainstream: H100 SXM5 (stable, mature ecosystem, easy to procure) └── Value: MI300X (perf close to H100, ROCm ecosystem maturing) LLM fine-tuning (10-100B params, 64-256 GPUs): ├── Flagship: H100/H200 SXM5 ├── Economy: L40S (if memory is sufficient) └── Cloud: A100 80GB (commonly available on clouds) LLM inference (high concurrency): ├── Extreme: H200 (141GB memory holds larger KV Cache) ├── Mainstream: H100 (low latency, high throughput) ├── Value: L40S (slightly higher TTFT, good price/perf) └── Hyperscale: GB200 NVL72 (130 TB/s aggregate NVLink per rack) Vision model training (CNN/ViT): ├── Flagship: H100 (FFT convolution support) ├── Value: L40S (vision models need less memory) └── Non-NVIDIA: MI300X + ROCm 6.0+ Scientific computing (double precision): ├── Flagship: H100 (67 TFLOPS FP64) ├── AMD edge: MI300X (81.7 TFLOPS FP64, slightly ahead of H100) └── Top-tier: Grace-Hopper Superchip (tightly-coupled CPU+GPU) Constrained environments (power/thermal limits): ├── Low power: L40S (300W) └── Inference: L4 (72W, 24GB) 数据来源：截至2026年1月，各厂商官方数据表和MLPerf公开结果。实际性能可能因软件栈版本和配置不同而 异。

3.8.5 选型决策的核心原则

•训练优先选 CUDA 生态：训练是 AI 工作流中最大的固定成本与时间风险，“H100/B200 + CUDA 生态”目前无可替代。 •推理可以多元化： •H100/H200（通用）：标准方案 •MI300X（大显存）：70B+ 模型的最佳性价比 •L40S（低成本）：延迟要求宽松的场景 •Groq/Cerebras：特定场景的极致低延迟 •供应商锁定与成本权衡： •训练 100% 用 NVIDIA，当前无需考虑替代 •推理可分配 15-20% 给 AMD/MI300X 实现供应商多元化 •云端可混合 Trainium/TPU 做特定负载优化 •总成本优先于单价： •利用率从 30% 提升到 50%，节省的 GPU 采购费用超过任何硬件折扣 •训练平台、调度与运维能力决定利用率上限 •优先级：利用率提升 > 硬件价格谈判 > 替代硬件