第1章 AI Infra 概述

本章界定 AI Infra 的定义与核心资源域，梳理从单机到万卡集群的演进脉络，以 Scaling Law 解释算力需求增长的根源， 并给出技术栈全景、核心设计原则与全书阅读路径。硬件参数与工程实践细节不在本章展开。

1.1 AI Infra 定义

AI Infra（AI Infrastructure）是支撑人工智能模型从开发、训练到推理部署全过程的基础软硬件技术栈的总称。其基础设 施资源涵盖计算（Compute）、网络（Network）和存储（Storage）三大核心域——计算提供算力、网络连接节点、存储 承载数据——在此之上由平台层进行统一调度与编排，纵向则按能力抽象层次组织为五层技术栈。

1.1.1 三大资源域

•计算域：AI Infra 的核心。涵盖 GPU（NVIDIA H100/B200/GB200）、TPU（Google TPU v5p/v6）、NPU（华为昇腾 910B）等 AI 加速器，以及配套的 CUDA、ROCm、oneAPI 等编程框架。核心指标是算力密度（FLOPS/Watt）和利用 率（MFU，Model FLOPs Utilization）。实际训练中，即使硬件理论算力高达 1979 TFLOPS（H100 FP8 稠密），千卡训 练 Llama-70B 时 MFU 通常也只在 40%-55% 之间。 •网络域：万卡集群的核心瓶颈。大模型训练的高效通信需求催生了 NVLink（900 GB/s 双向，H100）、NVSwitch（7.2 Tbps 全双工 / 约 0.9 TB/s，3rd gen）、InfiniBand NDR400（400 Gbps 单端口）等专用互联技术。网络拓扑设计 （Rail-Optimized、DragonFly+）直接影响 AllReduce 等集合通信操作的性能。 •存储域：面临海量小文件（训练数据集中的图片/文本片段）与高吞吐 Checkpoint 写入的矛盾。一个 GPT-175B 模型 的 Checkpoint 大小约 2.1 TB，在千卡集群上每两小时保存一次，要求存储系统提供 TB/s 级别的聚合写入带宽。该体 积来源于 BF16 参数（175B × 2 Bytes ≈ 350 GB）、FP32 梯度（700 GB）以及优化器动量与方差状态（700 GB + 700 GB），加上其他元数据合计约 2.1 TB。并行文件系统（Lustre、GPFS、WekaFS）和对象存储（MinIO、Ceph）的混 合部署是主流方案。

1.1.2 五层技术栈与平台层

AI Infra 技术栈自下而上分为硬件层、系统软件层、AI 框架层、平台层与应用服务层，每一层对上提供能力抽象、对下驱 动硬件资源，各层构成与典型组件如图1-1所示。 Application & Service Layer Training Platform Inference Service Model Registry Data Pipeline Platform Layer Kubernetes/K8s SLURM/HPC Scheduler Ray/Volcano Kubeflow/MLflow AI Framework Layer PyTorch/JAX Megatron-LM/DeepSpeed vLLM/TensorRT-LLM Triton/XLA System Software Layer CUDA/ROCm NCCL/RCCL cuBLAS/cuDNN GPU Operator/MIG Hardware Layer GPU/TPU/NPU NVLink/InfiniBand/RoCE Parallel File System Cooling/Power/Rack 图1-1 AI Infra五层技术栈架构 在三大资源域之上，平台层提供资源调度与开发工具体系。调度系统解决算力资源的池化与分配问题——区别于传统 Web 服务的无状态调度，AI 训练作业具有 All-or-Nothing 的特点，作业要么获得完整的多卡资源组，要么等待，Gang Scheduling 是核心能力；推理服务则需弹性伸缩应对波动的请求负载。平台工具提供统一的应用门户，集成数据集管 理、实验追踪、模型版本控制、CI/CD 流水线等功能，MLflow、Weights & Biases、Kubeflow 是典型组件。

1.1.3 价值定位

从业务视角看，AI Infra 的直接价值体现在三个层面： •训练成本优化：Meta 训练 Llama 3-405B 使用了 16000 张 H100 GPU，按公开价格估算训练成本约 6000-7000 万美 元。若通过通信优化将 MFU 从 40% 提升至 50%，等效节省约 1200 万美元的算力费用。 •推理延迟与吞吐：对于实时对话应用（如 ChatGPT），用户感知的 TTFT（Time To First Token）需控制在 200ms 以 内，TPOT（Time Per Output Token）需控制在 30ms 以内。不合理的 KV Cache 管理或批处理策略会直接导致终端用 户体验劣化。 •资源利用率：根据 2024 年公开的云厂商数据，GPU 集群的平均利用率普遍在 30%-60% 区间。通过混合调度训推任 务、GPU Bin Packing、MIG 切分等手段，可将利用率提升至 70%-80%，显著降低单位算力成本。 AI Infra 的工程难度在于其作为“放大器”的定位——基础设施质量的差异，在千卡/万卡级别会被成百上千倍地放大。

1.1.4 MoE 架构对基础设施的挑战

混合专家（Mixture of Experts，MoE）架构已成为超大规模模型的主流设计选择。与稠密模型每个 token 激活全部参数 不同，MoE 模型通过 Top-K 门控（通常 K=2-8）每次仅激活少量专家子网络，使总参数量大幅扩展的同时控制计算量： DeepSeek-V3 总参数 671B，但每 token 仅激活 37B（约为总量的 5.5%）。MoE 架构对 AI Infra 带来两个独特挑战： •专家并行引入 All-to-All 通信：在分布式 MoE 训练中，每个 token 被路由到分布于不同 GPU 的专家，每个 MoE 层需 执行两次 All-to-All 通信（dispatch 和 combine），而非稠密模型的 AllReduce。通信量正比于 GPU 数 × 激活专家数 × token 维度，在千卡规模下对节点间 InfiniBand 带宽极度敏感——DeepSeek-V3 将专家并行度设为 64，节点间通信 带宽成为训练效率的首要瓶颈。 •负载不均衡：若门控网络的 token 路由分布不均（某些专家过热、某些闲置），GPU 利用率会显著下降。为此需要引入 辅助损失（Auxiliary Loss）或 Expert Choice 路由等技术约束路由均匀性，这进一步增加了训练监控和调度系统的复 杂度。

1.2 单机到万卡集群演进史

AI Infra的演进史，本质上是对算力规模的持续追求史。从2012年的一张消费级显卡到2026年的百万算力集群时代，计算 规模膨胀了约100万倍。

1.2.1 单机时代

2012年，Alex Krizhevsky使用两块NVIDIA GTX 580 GPU（每块仅3GB显存）训练了AlexNet，在ImageNet竞赛中以压倒 性优势击败传统方法，开启了深度学习时代。这一时期的典型配置是单机4卡或8卡GPU，训练数据可完全放入单机内 存，无需分布式通信。 2014-2016年，NVIDIA相继发布Kepler和Pascal架构GPU，深度学习框架Caffe、Theano、TensorFlow（2015）、 PyTorch（2016）相继成熟。ResNet（2015）的残差连接设计使得训练数百层网络成为可能。这一阶段，单机8卡V100 （2017）成为事实标准，32GB显存和NVLink 2.0（300 GB/s）满足了绝大多数研究需求。

1.2.2 分布式训练萌芽

2017年，Google在论文《Attention Is All You Need》中提出Transformer架构，标志着NLP领域的范式变革。 Transformer的全注意力机制天然适合并行化，但也对显存和通信提出了更高要求。 2018-2019年，OpenAI相继发布GPT-1（1.17亿参数）和GPT-2（15亿参数）。BERT（3.4亿参数，2018）引爆了预训练 范式的普及。此时，单机8卡已经无法容纳大模型的训练内存需求（参数、梯度、优化器状态）。数据并行（Data Parallelism）成为首个规模化方案，通过AllReduce同步梯度，使训练扩展到数十卡规模。 2019年，NVIDIA发布Megatron-LM，提出了张量并行（Tensor Parallelism）和流水线并行（Pipeline Parallelism），使 得训练上千亿参数模型成为可能。

1.2.3 千卡时代

2020年6月，OpenAI发布GPT-3（1750亿参数），在微软定制的V100集群上训练，算力需求约3640 Petaflop/s-days。同 年，Kaplan等人在论文《Scaling Laws for Neural Language Models》中系统阐述了模型规模与性能的幂律关系，直接 推动了大模型军备竞赛。 2022年，DeepMind在论文《Training Compute-Optimal Large Language Models》中提出Chinchilla缩放定律，指出 在给定计算预算下，模型参数与训练Token数应等比例缩放。这一发现影响了后续模型的训练策略。 2022年11月ChatGPT发布，引发全球AI浪潮。同期的A100 GPU（80GB HBM2e）成为千卡集群标配。Meta在2023-2024 年分两批部署了24000张H100 GPU用于开源Llama系列训练。

1.2.4 万卡时代

2023年，NVIDIA发布H100 GPU，单卡FP8算力达1979 TFLOPS（稠密）。H100搭配Quantum-2 InfiniBand（NDR 400Gbps）和NVLink 4.0（900 GB/s），使万卡GPU集群在技术上成为可行。 2024年12月，DeepSeek发布DeepSeek-V3，使用2048张H800 GPU训练了约两个月，训练成本约557万美元（仅为Meta Llama 3-405B的约1/11）。其技术创新包括：MoE架构（671B总参数，37B激活参数）、多头潜注意力（MLA）、FP8混合 精度训练、DualPipe流水线并行等，展示了算法与系统协同优化的巨大空间。 2025年，NVIDIA正式交付Blackwell架构的B200（单卡FP16稠密算力1125 TFLOPS，FP16稀疏2250 TFLOPS，FP8稠密 2250 TFLOPS，192GB HBM3e，8 TB/s）和GB200 NVL72机柜（72颗B200 + 36颗Grace CPU，合计13.4TB HBM3e， 576 TB/s总带宽），配套Quantum-X800 InfiniBand交换机（NDR 400Gbps×2端口，即800Gbps）和NVLink 5.0（1.8 TB/s）。GB200 NVL72的FP8算力达720 PFLOPS（稠密），十万卡规模集群方案成为现实。

1.2.5 百万算力时代

2026年，NVIDIA推出Blackwell Ultra（B300/GB300）和下一代Rubin架构（R100），进一步拉升算力天花板： •GB300 NVL72（Blackwell Ultra）：同样封装72颗B300 GPU，总显存达20 TB HBM3e（较GB200提升约50%），FP4算 力提升至1080 PFLOPS（稠密），是GB200的1.5倍，发布于2025年底。 •Vera Rubin NVL72：采用Rubin架构，GPU代号R100，内含338亿晶体管，配备HBM4，TDP高达2300W/卡；搭配第六 代NVLink和ConnectX-9 SuperNIC（1600 Gb/s），机柜级系统于2026年下半年进入市场。 与此同时，模型前沿也持续推进：Claude Opus 5、GPT-5系列、Kimi K3、Qwen3等在推理基准上持续突破，推理时扩 展（Inference-Time Scaling）成为算法与系统协同优化的核心战场，推理集群的算力消耗首次超过训练集群。全貌演进 如图1-2所示。 Milestones in AI Training Scale Evolution 2012 2017 2018 2020 2022 2023 2024 2025 2026 图1-2 AI训练规模演进时间线

1.2.6 关键趋势总结

各时期的关键节点演进如表1-1所示。 表1-1 AI训练规模演进关键趋势 时期 GPU型号 典型集群规模 关键创新 2012-2016 GTX580/K40/P100 1-8卡 深度学习框架成熟 2017-2019 V100 8-128卡 NVLink, Tensor Core, 分布式框架 2020-2022 A100 256-4096卡 MIG, multi-instance GPU 2023-2024 H100/H800 2048-16384卡 FP8训练, Transformer Engine, NVSwitch 3 2025 B200/GB200 10000-100000卡 FP4, 液冷, NVLink 5, GB200 NVL72机柜 2026+ B300/GB300/Rubin R100 100000+卡 Blackwell Ultra, HBM4, ConnectX-9 1600Gbps

1.3 Scaling Law 与需求

Scaling Law（缩放定律）是理解AI Infra需求增长的根本性理论框架。它不仅解释了为什么要不断扩建更大规模的计算集 群，也指导着硬件资源如何配置才能达到最优的投入产出比。

1.3.1 Kaplan 缩放定律

2020年，OpenAI的Jared Kaplan等人在论文《Scaling Laws for Neural Language Models》中通过大量实验（模型参数 量从百万级跨越至15亿级，训练Token量从千万级跨越至千亿级）拟合出了著名的幂律关系： •模型性能L与模型参数量N的关系：L(N ) ∝ N （模型越大，Loss越低） −0.076 •模型性能L与训练数据量D的关系：L(D) ∝ D （数据越多，Loss越低） −0.095 •模型性能L与计算量C的关系：L(C) ∝ C （计算越多，Loss越低） −0.050 Kaplan定律的核心推论是：在计算预算固定的情况下，应当优先增加模型规模（参数量），而非训练数据量。这一结论直 接引导了2020-2022年间“模型越大越好”的军备竞赛。 从基础设施视角看，Kaplan定律意味着：要获得更低的Loss，就必须投入更多的GPU小时。该关系是幂律的（而非线性 的），意味着Loss从2.0降到1.9需要的算力增量，远大于从3.0降到2.9。这解释了为什么大模型训练成本存在“边际效用 递减”现象。

1.3.2 Chinchilla 缩放定律

2022年，DeepMind在论文《Training Compute-Optimal Large Language Models》中对Kaplan定律提出了重要修正。 他们在更系统的实验后（训练了超过400个不同规模的模型）得出结论： 对于给定的计算预算C，应当使模型参数量N与训练Token数D近似等比例增长，即 N ∝ C ，D ∝ C 。 0.5 0.5 这推翻了Kaplan的“优先扩大模型”结论。以Chinchilla（70B参数，1.4T训练Token）为例：它使用与Gopher（280B 参数，300B Token）相同的计算预算，但性能显著优于Gopher——因为它在更多数据上训练了一个更小的模型。 Chinchilla定律对基础设施的影响： •对显存的需求没有缓解：虽然模型“相对更小”，但训练完整的大规模Token仍然需要高效的分布式并行 •对I/O带宽的需求加剧：更多数据意味着DataLoader效率更加关键，数据预处理流水线可能成为新的瓶颈 •计算细分更精细：训练Token量增大，使得多阶段训练（从短序列到长序列逐步扩展上下文长度）变得更加普遍

1.3.3 推理时计算的范式变革

2024-2026年，传统的“仅在训练时Scaling”范式被打破。Inference-Time Compute Scaling（推理时计算扩展）成 为新焦点： •o1/o3/o3-mini模型（OpenAI）：通过Chain-of-Thought推理和多次采样，让模型在推理时“思考更久”，从而显著提 升推理质量 •DeepSeek-R1/R2：展示了通过强化学习激励模型进行长时间推理的价值，且以极低成本实现了o1级推理能力 •Claude 3.5/4/Opus 5，Gemini 2.5 Pro，GPT-5：2025-2026年各主要前沿模型均集成推理时扩展，长链思维 （Extended Thinking）成为标配 •Inference Scaling Law：在推理时投入更多计算（如采样更多候选、进行更长的Rollout）可稳定提升推理质量，这一 规律已被多项研究验证 这对基础设施带来三方面挑战： •训练集数据需要包含高质量的多步推理轨迹 •推理服务不再是简单的“一次前向传播”，可能需要支持大规模并行采样和树搜索等复杂推理策略 •推理延迟从毫秒级扩展到秒级甚至分钟级，对资源调度和并行策略提出了新要求 推理时计算扩展（Inference-Time Compute Scaling）不仅是算法范式变革，更直接重塑了推理集群的设计参数。以 OpenAI o1/o3 类思维链（Chain-of-Thought）模型为例，单次请求的输出 token 数可从普通对话的 200-500 tokens 膨 胀至数千乃至数万 tokens，对应的 KV Cache 显存占用同步线性增长。以 Llama-3-70B（BF16，context 8192）为例， 单请求 KV Cache 约占 2.5 GB（计算公式：2 × 80 × 8 × 128 × 8192 × 2 字节 ≈ 2.5 GB）；当长链路需要 64K tokens 时， KV Cache 膨胀至约 20 GB，而 70B BF16 模型权重本身约 130 GB 需多卡承载，各卡可用显存余量因此十分有限。 在架构层面，以并行采样（Best-of-N，N 通常取 4-64）为核心的推理扩展策略，要求推理服务在同一请求的多条生成路 径之间高效共享 Prefill 阶段的 KV Cache——SGLang 的 RadixAttention 和 vLLM 的前缀共享缓存（Prefix Caching）正是 应对这一需求的技术响应，可将 N 路并行采样的 KV Cache 开销从 O(N × prompt_len) 降低至 O(prompt_len + N × output_len)。 更深层的架构变革是 Prefill-Decode（PD）分离：Prefill 阶段（处理输入 prompt，Arithmetic Intensity 高达数百，计 算密集型）和 Decode 阶段（逐 token 生成，Arithmetic Intensity 通常低于 10，内存带宽密集型）的计算特征截然不 同，将两阶段分配到不同节点执行，可将整体推理吞吐提升 1.5-3 倍，同时将 TTFT 与 TPOT 之间的干扰解耦。 Mooncake、DistServe、Sarathi-Serve 等工业级系统已验证了 PD 分离的有效性，意味着推理侧基础设施不再是均质 GPU 池，而需要支持异构算力的精细化调度，并在 Prefill 节点和 Decode 节点之间高效传输 KV Cache（典型带宽需求约 10-50 GB/s per request slot）。

1.3.4 实验验证

 # Requires Python 3.9+, numpy, scipy
 # Scaling Law verification example:
 import numpy as np
 from scipy.optimize import curve_fit
 def chinchilla_loss(C, A, alpha):
     """Chinchilla Loss formula: L(C) = E + A * C^{-alpha}"""
     E = 1.69 # irreducible error (intrinsic entropy of text)
     return E + A * C**(-alpha)
 # Computational cost estimation for public models (synthetic demo values)
 # (params_B, compute): C values are scaled for demonstration of curve fitting
 models = {

'LLaMA-7B': (7, 1e4), 'LLaMA-13B': (13, 2e4), 'LLaMA-33B': (33, 5e4), 'LLaMA-65B': (65, 1e5), 'Chinchilla': (70, 6e5), 'GPT-3': (175, 3.6e3),

 }
 # Fit Chinchilla scaling law to (compute, loss) observations
 # Using synthetic loss values derived from published benchmarks
 compute_values = np.array([v[1] for v in models.values()])
 # Approximate reported loss values (perplexity proxy, lower is better)
 reported_loss = np.array([1.95, 1.91, 1.85, 1.81, 1.76, 2.05])

popt, _ = curve_fit(chinchilla_loss, compute_values, reported_loss, p0=[500, 0.05], maxfev=10000) A_fit, alpha_fit = popt

 print(f"Fitted: A={A_fit:.1f}, alpha={alpha_fit:.4f}")
 for name, (params, C) in models.items():
     predicted = chinchilla_loss(C, A_fit, alpha_fit)
     print(f" {name:12s} C={C:.1e} predicted_loss={predicted:.4f}")

上述代码展示了如何验证Chinchilla定律的核心公式：L(C) = E + A ⋅ C ，其中 E ≈ 1.69 是语言建模的不可约误差 −α （irreducible loss），反映了自然语言本身的固有不确定性。

1.3.5 基础设施需求推导

Scaling Law的工程推论可总结为： •算力需求年增速>5x：Epoch AI的统计显示，训练顶级AI模型的计算量约3-5个月翻倍，远超摩尔定律 •显存是首要限制：模型参数和优化器状态必须在训练期间常驻显存，决定了分布式策略选择 •网络比计算更昂贵：在千卡以上规模，通信开销占比可超过50%，远超计算本身的成本 •故障率随规模线性增长：万卡集群上，每天都有GPU/网络故障发生，自动恢复机制是必须的

1.4 AI 技术栈全景

AI Infra 的技术栈沿五层组织，本节按训练、推理、平台编排与数据存储四个维度展开各层的典型技术方案。层间通过标 准化接口（如 NCCL 通信原语、CUDA 计算 API）实现互操作；对同一层的不同技术选择（如 PyTorch vs JAX， InfiniBand vs RoCE），需结合规模、成本和生态兼容性综合评估。

1.4.1 训练技术栈

当前主流的LLM训练技术栈以PyTorch + Megatron-Core/DeepSpeed + NCCL + CUDA为核心： •PyTorch：占据95%以上的研究市场份额。其 FSDP （Fully Sharded Data Parallel）和 torch.distributed 模块提 供了从单机到多机的分布式训练抽象。 •JAX：Google主导，在TPU生态中占主导地位。其函数式编程范式（jit + vmap + pmap/shard_map）天然适合编译器 优化，Google 的 PaLM、Gemini 等模型均基于 JAX 训练。 •Megatron-LM（NVIDIA）：提供了张量并行（TP）、流水线并行（PP）和数据并行（DP）的3D并行实现，是千卡以上 规模训练的事实标准。 •DeepSpeed（Microsoft）：其ZeRO优化器系列（ZeRO-1/2/3）是显存优化的标杆方案。ZeRO-3将模型参数、梯度和 优化器状态分割到所有GPU，每个GPU仅保存其分配的部分，使训练万亿参数成为可能。

1.4.2 推理技术栈

推理领域的技术栈迭代更快，2023-2025年涌现了多个高性能方案，主流推理引擎的对比如表1-2所示： 表1-2 主流推理引擎对比 推理引擎 核心优化技术 适用场景 vLLM PagedAttention、Continuous Batching 通用大模型推理服务 TensorRT-LLM Kernel融合、量化（INT4/INT8/FP8） H系列GPU极致吞吐 SGLang RadixAttention、Structured Outputs 复杂LLM应用（Agent、多轮对话） LMDeploy TurboMind引擎、W4A16/W8A8量化 服务端大模型推理部署 端侧与边缘推理更常见的选择是 llama.cpp、MLC-LLM、ONNX Runtime Mobile 等轻量方案。 vLLM的PagedAttention技术（借鉴操作系统虚拟内存分页思想）将KV Cache分割为固定大小的Block，解决了KV Cache 内存碎片化问题，将推理吞吐提升了2-4倍。 FlashAttention（Dao et al., 2022）是 AI Infra 领域影响最深远的算法级内核优化，已成为几乎所有主流训练和推理框架 的标准组件。其核心思想是 IO 感知的 Attention 计算重排：将 Q/K/V 分块加载到片上 SRAM，避免实体化完整的 N×N Attention 中间矩阵，使 HBM 读写量从 O(N²) 降至 O(N)，从而降低 Attention 对 HBM 带宽的依赖、更充分地利用 Tensor Core 算力。这一优化使长序列训练在显存上成为可行，也是提升 MFU 的关键手段。

1.4.3 平台与编排

•Kubernetes + Volcano：Volcano提供了Gang Scheduling、Queue管理、Fair-share等批调度能力，弥补了K8s原生 调度器对AI作业支持的不足。 •Ray：Anyscale开源的分布式计算框架，在RLHF训练（强化学习人类反馈）和超参数搜索中广泛使用。 •Slurm：传统HPC调度器，在学术超算中心和部分大厂的AI集群中仍广泛使用。

1.4.4 数据与存储

大规模训练的数据I/O流水线同样复杂：

Typical training data pipeline

data_source:

   - raw_corpus: WebText ▶ Cleaning ▶ Dedup ▶ Tokenization
   - storage: Ceph/MinIO Object Storage (raw) ▶ Parallel File System (training data)
   - format: .bin (Binary MMAP) / .arrow / .parquet

data_loading:

   - DataLoader: PyTorch DataLoader + Distributed Sampler
   - prefetch_and_cache: Local NVMe SSD as data cache layer
   - throughput: 1000-card training requires GB/s level data read

Checkpoint:

1.4.5 海外集群方案

   - format: PyTorch Distributed Checkpoint / DeepSpeed Checkpoint
   - size: GPT-175B ≈ 2.1TB, Llama-405B ≈ 4-5TB
   - frequency: Usually saved every 1-2 hours
   - requirement: TB/s aggregate write bandwidth

全球主要 AI 玩家的集群技术栈选型如表1-3所示，其组合方式是各层方案在真实大规模场景中的对照样本，也是本书后续 章节选型讨论的事实基础。 表1-3 海外集群方案对比 Meta Llama xAI Google Microsoft 维度 3/4 Colossus TPU Azure NVIDIA Eos OpenAI Anthropic v5p GPU/芯 H100 H100 + TPU H100 → H100 H100/A1 Trainium2, TPUs, NVIDIA 片类型 H200 + v5p GB200 (4,608 张) 00 Grace Blackwell GB200 NVL72 集群规 2×24,576 GPU（单集 200,000 GPU（全规 8,960 芯 未公开（以十 万为单位部 4,608 GPU 25,000+ >1M Trainium2 芯片, 220K+ NVIDIA GPU (SpaceX), 1M 模 群） 模） 片/Pod 署） GPU TPUs planned Scale- Grand Teton 标准节点 + ICI 3D Up 方 (OCP) NVLink Torus NVL72 机架 DGX SuperPOD Azure ND Trainium2 Trn2 Ultra servers, 系列 TPU v5p ICI 案 Scale- RoCEv2 为主 NVIDIA OCS 光 InfiniBand Quantum-2 InfiniBan AWS EFA, Google ICI/OCS, Out 网 + IB 对比 Spectrum-X 交换机 （推测 NDR） IB d InfiniBand 络 调度平 自研 (FBLearner 未公开 Borg + Slurm + 自研 K8s AKS + Run:ai Base Amazon EKS + Google GKE 台 Flow + K8s) GKE Command Operator 训练框 PyTorch (FSDP + 自 未公开（推 JAX + DeepSpeed + Megatron- PyTorch JAX on TPU, PyTorch on 测 (自研优 Trainium 架 研) Megatron） GSPMD PyTorch LM 化) 存储方 Tectonic (自 GPUDirect Colossu Azure Managed DDN Lustre Azure AWS S3 + FSx for Lustre, Blob + Google Cloud Storage 案 研) Storage s/Ceph Lustre Lustre 监控方 GCM (开源) 未公开 自研 Azure DCGM + 自研 Multi-platform 案 Monitor NVSentinel (Trainium/TPU/GPU) 从中可归纳四条技术路线： •NVIDIA 全栈生态（Eos、Colossus）：硬件、网络、软件全栈由 NVIDIA 提供，端到端优化、开箱即用，代价是成本 高、供应商锁定 •自研开放生态（Meta）：GPU 外购，网络、调度、存储、监控大量自研或使用开源方案，成本可控但需庞大工程团队 •云原生混合生态（Microsoft、Google、CoreWeave）：以 Kubernetes 为统一底座，弹性可移植，需整合多个开源组 件 •多平台异构路线（Anthropic）：同时使用多家云厂商的异构芯片，以跨平台严格等价性保障模型质量，供应链安全但 软件栈兼容与性能对齐极其复杂

1.5 核心设计原则

AI Infra的设计需要遵循五项核心原则——可扩展性（Scalability）、高效性（Efficiency）、可靠性（Reliability）、成本效 益（Cost-Effectiveness）与可管理性（Manageability），并在它们之间做出审慎的权衡。理解和实践这些原则，是区分 初级工程师和资深架构师的关键。

1.5.1 五大设计原则

1. 可扩展性 可扩展性是最核心的设计原则。一个AI系统必须具备从单机到千卡再到万卡的线性扩展能力。评价指标是弱扩展效率 （Weak Scaling Efficiency）和强扩展效率（Strong Scaling Efficiency）。 •弱扩展：保持单GPU的Batch Size不变，增加GPU数量。理想情况下，总吞吐线性增长。实际限制来自通信开销增大。 •强扩展：保持总Batch Size不变，增加GPU数量。每个GPU处理更小的Micro-batch。限制来自通信开销和有效Batch Size过小导致的收敛问题。 在H100万卡集群上，通过Rail-Optimized拓扑、全8卡互联的NVSwitch域设计、NCCL NVLS（NVLink Sharp）等技术， AllReduce操作可达到约90%的理论带宽利用率。
2. 高效性 高效性体现在算力利用率（MFU）和能效比（FLOPS/Watt）两个维度。典型值方面，Llama 2-70B 单机（8 GPU）MFU 约 55%，千卡规模训练约 40%-52%，DeepSeek-V3（2048 H800, DualPipe）约 43%。MFU 损失主要来自： •计算-通信重叠不足（约15-20%损失） •不同并行维度间的Bubble（约5-10%损失） •核函数启动开销和内存带宽限制（约3-5%损失） •热节流（Thermal Throttling）导致的降频
3. 可靠性 万卡集群上，MTBF（Mean Time Between Failures）以小时计。Meta在训练Llama 3-405B期间，16000张H100的集群 平均每天发生约8次非计划故障（Meta公开报告：54天窗口内共466次中断，其中计划维护47次、意外中断419次，平均 约7.6次/天）。故障来源分布： •GPU硬件故障（Xid Errors/Ecc Errors）：约40% •HBM内存错误（Uncorrectable ECC）：约25% •NVLink/PCIe链路故障：约15% •InfiniBand链路故障：约10% •电源/散热故障：约5% •其他（OS/驱动）：约5% 容错设计包括：自动化故障检测与隔离、从最新Checkpoint快速恢复、分钟级的节点热替换、Graceful Degradation （部分GPU故障后降级运行）。
4. 成本效益 AI Infra是典型的资本密集型投入。一个万卡H100集群的建设成本约为2-3亿美元（含服务器、网络、存储、机房电力改 造）。TCO（Total Cost of Ownership）需综合考虑： •CapEx：GPU服务器（约70%）、网络设备（约12%）、存储（约8%）、机房改造（约10%） •OpEx：电力（约5-8 USD/Watt/年，含冷却）、运维人力、软件License DeepSeek-V3以557万美元训练出一个SOTA级别的671B MoE模型，证明了算法创新可以大幅降低基础设施需求，重新定 义了成本效益的边界。
5. 可管理性 万卡规模的可管理性包括：统一的资源编排、可观测性（Metrics/Logs/Traces）、自动化运维、权限与多租户隔离。 Prometheus + Grafana + DCGM（Data Center GPU Manager）是常用的GPU监控方案。

1.5.2 核心工程挑战

1. 内存墙 GPU HBM带宽的增长速度（H100: 3.35 TB/s, H200: 4.8 TB/s）远跟不上模型规模的膨胀速度（从7B到405B再到1.7T参 数）。这迫使工程师采用张量并行、流水线并行、ZeRO优化器状态分片等方法将模型“拆散”到多张GPU上，代价是引入 通信开销。
2. 通信瓶颈 训练中的AllReduce/Gather/Scatter操作需要多GPU之间频繁交换梯度数据。以Llama 2-70B为例，单步训练需 AllReduce 的梯度数据约 140 GB（70B 参数 × 2 字节 BF16），在 400 Gbps InfiniBand 网络上约需 4-5 秒量级完成，通 信开销不容忽视。
3. 异构硬件的复杂性 单一集群中可能存在不同型号的GPU（存量A100与新增H100），甚至不同厂商的加速器。PyTorch的 torch.device 抽象 虽然统一了接口，但不同硬件在内存布局、对齐要求、算子实现上的差异仍需要在系统层精心处理。
4. 功耗与热管理 一张H100的TDP为700W，一张B200的TDP高达1000W。GB200机柜的功率密度超过120kW/rack（传统数据中心为5- 10kW/rack），必须采用直触式液冷（Direct-to-Chip Liquid Cooling）或浸没式液冷（Immersion Cooling），对数据中 心设计和运维提出了全新挑战。

1.6 AI Infra 知识体系

AI Infra 的知识体系横跨系统工程、机器学习原理与 GPU 编程三大技术域。本节按知识领域组织全景，先给出技术域构 成，再展开各领域的核心技术要点与进阶学习路线。

1.6.1 知识领域全景

AI Infra 知识体系由 Systems、Compute 与 ML 三个技术域构成，各域的重点如图1-3所示。 ML Expertise Compute Systems Training Pipeline/Converg CUDA/C++ Programming Linux Kernel/Driver ence Theory GPU Microarchitecture Un Network Protocol/TCP-RD Parallel Strategy Design derstanding MA Model Compression/Quan Performance Profiling/Opt Container Orchestration/K tization imization 8s Inference Optimization Triton Kernel Writing Distributed Storage 图1-3 AI Infra 知识领域全景

1.6.2 核心技术领域

AI Infra 的核心技术可归为八个领域，覆盖从算子、训练、推理到集群与存储的全栈环节：

1. 计算与算子 •CUDA 编程模型：Grid/Block/Thread 层次，Warp 与 SM 调度，Shared Memory 与 Bank Conflict •高性能 Kernel：GEMM、FlashAttention •计算图优化：CUDA Graph，PyTorch C++ Extension/Fuser •自定义算子：Triton/TVM 开发
2. 分布式训练 •PyTorch DDP/FSDP 多卡训练，torch.distributed 通信原语（AllReduce 等） •3D 并行（TP+PP+DP）方案设计 •Megatron-Core 与 DeepSpeed 大规模训练框架 •混合精度训练（AMP/BF16/FP8）、梯度累积与梯度裁剪 •训练任务的容错恢复机制
3. 性能优化 •Nsight Systems/Compute 端到端性能分析 •Roofline Model 指导 Kernel 优化 •MFU 分析（如从 40% 提升到 50%+ 的优化路径） •NCCL Ring/Tree 集合通信算法 •InfiniBand/RoCE 测速（ib_write_bw 等工具） •AllReduce Micro-benchmark 分析
4. 推理优化 •vLLM/TensorRT-LLM 的使用与调优 •PagedAttention 与 KV Cache 管理 •Continuous Batching 策略设计 •训练与推理的统一架构（训推一体）
5. 系统与网络 •Docker 容器与 K8s 编排（Pod YAML、nvidia-smi/dcgmi 工具） •NCCL 实现细节：内存注册、NVLS、SHARP •GPU Pooling 与弹性调度 •异构集群的故障隔离
6. 存储与数据 •EB 级存储系统设计 •PB 级数据流水线 •checkpoint 策略与自动恢复流程
7. 运维与可观测 •GPU 集群可观测性体系（DCGM + Prometheus + Grafana） •告警规则设计与故障自愈 •GPU-Hour 成本模型 •混部与 Spot 实例降本手段
8. 集群架构 •万卡集群架构设计：网络拓扑、存储方案、调度策略 •机房选址与电力规划 •异构 GPU 集群统一调度 •芯片级系统设计：与硬件厂商协同定义下一代 AI 加速器需求

1.6.3 进阶学习路线

进阶学习沿三条主线展开：系统基础、训练栈与推理引擎源码、通信与网络。按阶段递进：

1.7 本书结构与阅读指南

 # Phase 1: Foundation Building
 #   - Read CSAPP (Computer Systems: A Programmer's Perspective)
 #   - Study the CUDA programming model and write basic kernels
 #   - Implement a simple PyTorch training loop from scratch
 # Phase 2: Core Competency
 #   - Deep dive into Megatron-LM and DeepSpeed source code
 #   - Master performance analysis with Nsight Systems and Nsight Compute
 #   - Study the vLLM scheduler implementation and continuous batching
 # Phase 3: System Vision
 #   - Read NCCL source code to understand collective communication
 #   - Learn InfiniBand network operations and RDMA programming
 #   - Study distributed storage and checkpoint design at scale

本书力求在理论与实战之间取得平衡，既覆盖AI Infra的底层原理（硬件微架构、通信协议、编译优化），也提供可直接操 作的工程实践（集群搭建、性能调优、故障排查）。

1.7.1 全书结构

本书共分为四个层次，涵盖从硬件到实践的全栈知识： Part 1: Hardware & Software (Chapters 1-5) ├── Chapter 1 AI Infra Overview ├── Chapter 2 GPU Microarchitecture ├── Chapter 3 Accelerators and Heterogeneous Computing ├── Chapter 4 High-Performance Kernels └── Chapter 5 Compilers and Frameworks Part 2: Training & Inference (Chapters 6-11) ├── Chapter 6 Distributed Training Fundamentals ├── Chapter 7 Advanced Parallelism Strategies ├── Chapter 8 Collective Communication and Networking ├── Chapter 9 Training Systems Engineering ├── Chapter 10 Inference Optimization and Serving └── Chapter 11 Model Quantization and Compression Part 3: Data & Platform (Chapters 12-15) ├── Chapter 12 RAG and Vector Retrieval ├── Chapter 13 Storage and Data Engineering ├── Chapter 14 Cluster Architecture and Scheduling └── Chapter 15 Cloud-Native MLOps Part 4: Measurement & Practice (Chapters 16-18) ├── Chapter 16 Performance and Cost Optimization ├── Chapter 17 AI Infra Computation └── Chapter 18 AI Infra Practice Appendix: Glossary, GPU Specs, Paper Index

1.7.2 按角色推荐阅读路径

1. 训练系统工程师（Training Infra Engineer） Chapter 1 (All) ▶ Chapter 2 ▶ Chapter 3 (Optional) ▶ Chapter 4 ▶ Chapter 5 ▶ Chapter 6 (Core) ▶ Chapter 7 ▶ Chapter 8 重点掌握：GPU微架构（理解为什么特定的Kernel快/慢）、NCCL通信原理、3D并行策略设计、大规模训练的性能剖析和 故障恢复。
2. 推理系统工程师（Inference Infra Engineer） Chapter 1 (All) ▶ Chapter 2 (Optional 2.1, 2.4, 2.5) ▶ Chapter 4 (Section 4.6 FlashAttention) ▶ Chapter 9 (Core) ▶ Cha pter 10 重点掌握：GPU内存层次与KV Cache管理、Tensor Core推理加速、PagedAttention和Continuous Batching、推理服务 的弹性伸缩和负载均衡。
3. 平台与调度工程师（Platform/SRE Engineer） Chapter 1 (All) ▶ Chapter 2 (Optional 2.7, 2.8) ▶ Chapter 13 (Core) ▶ Chapter 14 重点掌握：GPU拓扑与亲和性调度、Gang Scheduling和Bin Packing、GPU集群监控和故障自愈、MLflow/Kubeflow平 台搭建。
4. 技术管理者（Tech Lead/Manager） Chapter 1 (All, especially 1.1, 1.3, 1.5, 1.6) ▶ Chapter 3 (AI Accelerators) ▶ Appendix A (Glossary) 重点掌握：AI Infra的整体价值定位、Scaling Law的产业影响、TPU/自研芯片/GPU的TCO对比、AI Infra 的技术领域全 景。

1.7.3 前置知识

阅读本书建议具备以下基础： •编程能力：熟练使用Python和C/C++；了解CUDA C++语法（建议预先阅读CUDA Programming Guide前5章） •机器学习基础：理解神经网络的前向传播和反向传播原理；使用过PyTorch训练简单模型 •系统知识：了解Linux操作系统基本原理（进程、内存管理、文件系统）；了解网络基础（TCP/IP、带宽/延迟概念）

1.7.4 如何使用本书

•边读边练：标注为“实战”的章节（如第2、7、13章的实战小节）配有可直接运行的命令和配置，建议在读完后在实 际GPU环境（可申请云上的单卡H100实例，约$2-3/小时）中动手验证。 •知识关联：本书在章节间建立了概念关联，这些关联旨在帮助读者建立知识之间的联系，而非必需的线性阅读顺序。 •代码来源注释：正文中的代码块均标注了来源（如 ），方便读者回溯原始代码深入学习。 •图表阅读：本书大量使用Mermaid图表（架构图、时序图、流程图）辅助理解复杂概念。如果某些图表在终端中显示 不佳，建议使用支持Mermaid渲染的Markdown阅读器（如Typora、GitHub Markdown Preview）查看对应 .md 文 件。 版本信息 本书内容基于以下组件版本编写（截至2026年8月）： •NVIDIA CUDA 13.0+, Driver 580+ •PyTorch 2.x •NCCL 2.27+ •TensorRT-LLM 1.x •vLLM 1.0+ •Kubernetes 1.33+ 由于AI Infra领域迭代极快，建议读者关注各开源项目的Release Notes和Changelog以获取最新变化。