企业官网建设流程全解析

1. 为什么需要一张AI Infra知识全景图

搞AI Infra的人大概都有过这种体验：面试时被问到“一个千亿参数模型训练时显存怎么分布”，脑子里能蹦出七八个知识点，但就是串不成一条线；工作中遇到训练吞吐上不去，排查了半天发现是数据加载的IO瓶颈，但之前一直盯着GPU利用率在看。这种“知识点散落一地、连不成网”的状态，几乎是每个AI Infra从业者都会经历的阶段。

我自己是从传统后端转过来的，刚开始接触分布式训练的时候，光是Megatron的并行策略就啃了快两周，TP、PP、DP、EP这几个概念单独看都懂，但放到一个真实的训练任务里，它们怎么组合、怎么互相影响、通信开销怎么算，完全是懵的。后来踩了不少坑，也跟不少同行聊过，发现大家的问题都差不多：不是缺资料，而是缺一张能把所有东西串起来的“全景图”。

这份学习笔记就是干这个的。它不打算把每个知识点都讲透——那是教科书的事——而是要把AI Infra这个领域的知识骨架搭出来，让你知道每个模块在整体中的位置、它解决什么问题、跟其他模块怎么交互。适合谁看？如果你是刚转行做AI Infra的工程师，或者做算法想往Infra方向靠，又或者面试前需要快速梳理知识体系，这份笔记应该能帮上忙。如果你已经是资深Infra工程师，也可以拿它当个checklist，看看有没有遗漏的角落。

2. AI Infra知识体系的整体拆解

2.1 从训练到推理的完整链路

AI Infra说到底就是一件事：让模型能在硬件上高效地跑起来。这个“跑”分两个阶段——训练和推理，两者的优化目标完全不同。训练追求的是吞吐量和收敛速度，推理追求的是延迟和成本。但它们的底层依赖是共通的：计算、存储、通信、调度。

我习惯把AI Infra的知识体系分成五层来看。最底层是硬件层，包括GPU、NPU、TPU这些加速器，以及它们之间的互联方式（NVLink、NVSwitch、InfiniBand、RoCE）。往上是通信层，集合通信库（NCCL、HCCL、Gloo）和通信原语（AllReduce、AllGather、ReduceScatter、AlltoAll）。再往上是并行策略层，数据并行、张量并行、流水线并行、专家并行，以及它们的组合方式。然后是框架与引擎层，训练框架（Megatron-LM、DeepSpeed、FairScale）和推理引擎（vLLM、TensorRT-LLM、SGLang）。最上面是平台与调度层，Kubernetes、Slurm、Ray，以及资源调度、容错、弹性伸缩这些。

这五层不是孤立的。举个例子，你选了什么并行策略，直接决定了通信层的压力分布；通信层的瓶颈又反过来限制并行策略的选择。再比如，推理引擎的PagedAttention机制，本质上是在存储层做文章，但它对上层调度的影响是巨大的——显存利用率上去了，单卡能跑的并发数就多了，调度策略就得跟着调。

2.2 训练与推理的核心差异

很多人会把训练和推理混在一起学，结果越学越乱。我的建议是先分开理解，再找共通点。

训练的核心矛盾是“显存墙”和“通信墙”。显存墙指的是单卡显存放不下整个模型的状态（参数、梯度、优化器状态），所以需要切分。通信墙指的是切分之后卡间需要同步数据，通信开销可能吃掉计算收益。这两个矛盾催生了各种并行策略和显存优化技术（ZeRO、梯度检查点、混合精度）。

推理的核心矛盾是“延迟”和“吞吐”的权衡。延迟要求你尽快返回结果，吞吐要求你同时服务尽可能多的请求。这两个目标天然冲突——batch size大了吞吐高但延迟也高。所以推理引擎的核心工作就是在这两者之间找平衡点，PagedAttention、Continuous Batching、投机解码这些技术都是围绕这个展开的。

但两者也有共通的地方。比如量化技术，训练里有FP8训练，推理里有INT8/INT4量化，底层都是数值精度的取舍。再比如算子优化，FlashAttention在训练和推理里都用得上，只是侧重点不同。

2.3 知识全景的构建逻辑

我构建这张全景图的逻辑是“以问题为导向”。不是按技术分类来罗列，而是按“你会遇到什么问题”来组织。

比如显存不够了，你能想到哪些手段？切分（并行策略）、压缩（量化、梯度检查点）、卸载（Offload到CPU/NVMe）、复用（PagedAttention、显存池）。再比如训练慢了，排查思路是什么？先看GPU利用率，如果低就看是数据加载瓶颈还是通信瓶颈，如果高就看是不是算子效率问题。这种问题导向的组织方式，比按技术分类更贴近实际工作场景。

下面这张表是我整理的AI Infra核心模块与对应问题的映射关系，可以当作一个速查表来用。

这张表不是让你背的，而是让你在遇到问题时能快速定位到相关模块。比如你发现训练时GPU利用率只有30%，查表就知道该往“存储与IO”和“通信优化”两个方向去排查。

3. 核心模块深度解析与实操要点

3.1 并行策略：怎么切模型才合理

并行策略是AI Infra里最核心也最容易让人晕的部分。我刚开始学的时候，把TP、PP、DP的定义背得滚瓜烂熟，但一到实际配置就不知道该怎么选。后来总结了一个简单的判断逻辑：先看模型能不能单卡放下，放不下就考虑TP或PP；再看单卡能不能算得过来，算不过来就加DP；如果模型有MoE结构，再考虑EP。

数据并行（DP）是最简单的，每张卡持有完整模型副本，处理不同的数据batch，梯度通过AllReduce同步。优点是实现简单、扩展性好，缺点是显存冗余——每张卡都要存一份完整的模型状态。所以DP适合模型能单卡放下、但计算量大的场景。

张量并行（TP）是把单个算子（比如矩阵乘）切到多张卡上。比如一个[4096, 4096]的权重矩阵，可以按列切成两份，每张卡存[4096, 2048]。TP的优点是单层内的计算和显存都被切分了，缺点是通信频繁——每层前向和反向都需要AllReduce。所以TP通常限制在单机内（NVLink带宽高），跨机TP通信开销太大。

流水线并行（PP）是把模型按层切分，不同卡负责不同的层。比如32层的模型切成4段，每张卡负责8层。PP的优点是通信量小（只在层边界传激活值），缺点是存在流水线气泡——前面的卡在算的时候后面的卡在等。为了减少气泡，需要配合微批处理（micro-batch）和调度策略（1F1B、Interleaved 1F1B）。

专家并行（EP）是针对MoE模型的，把不同的专家分配到不同的卡上。EP的难点在于路由——每个token需要根据门控网络的结果发送到对应的专家卡上，这涉及AlltoAll通信。EP的通信模式比TP和PP都复杂，调优难度也更大。

实际配置时，我常用的组合是：单机内用TP=8（NVLink全互联），跨机用PP=2~4，DP根据总卡数除一下。比如64卡训练一个70B模型，可以配TP=8、PP=4、DP=2。这个配置不是最优的，但通常是个合理的起点。

注意：TP和PP的切分维度是模型维度，DP的切分维度是数据维度。配置时总卡数 = TP × PP × DP。如果用了EP，总卡数还要乘以EP的倍数（但EP通常和DP共享卡）。

3.2 通信优化：别让卡间同步拖后腿

通信是分布式训练的隐形杀手。我见过太多案例，GPU利用率上不去，排查半天发现是通信在等。通信优化的核心思路就两个：减少通信量和隐藏通信开销。

减少通信量的手段包括：梯度压缩（比如只传Top-K的梯度）、通信量化（FP16转INT8）、通信调度（把多个小通信合并成一个大通信）。隐藏通信开销的手段主要是通信重叠——在计算的同时进行通信，让通信时间被计算时间覆盖。

NCCL是NVIDIA的集合通信库，也是目前最常用的。它支持Ring AllReduce、Tree AllReduce、NVLS（NVLink SHARP）等多种算法，会根据拓扑自动选择。但自动选择不一定最优，特别是在跨机场景下。我遇到过跨机AllReduce慢的问题，后来手动指定了Ring算法并调整了chunk size，性能提升了30%。

调NCCL有几个关键环境变量：NCCL_ALGO指定算法，NCCL_PROTO指定协议（LL、LL128、Simple），NCCL_BUFFSIZE调整缓冲区大小，NCCL_NTHREADS调整线程数。这些参数没有万能配置，需要根据实际拓扑和消息大小来调。一般来说，小消息用LL128协议延迟低，大消息用Simple协议带宽高。

实操心得：调NCCL之前先用nccl-tests跑一遍AllReduce基准测试，了解当前拓扑下的理论带宽和实际带宽差距。如果实际带宽只有理论值的50%以下，说明配置有问题。

3.3 显存优化：把每一MB都用在刀刃上

显存是训练里最稀缺的资源。一个70B模型的训练状态（参数+梯度+优化器状态）在FP32下需要70×4×3=840GB，加上激活值轻松超过1TB。单卡80GB的A100/H100根本放不下，所以必须做显存优化。

显存优化的手段我按“性价比”排个序：混合精度训练（FP16/BF16）是最简单也最有效的，直接把显存占用砍半；梯度检查点（Gradient Checkpointing）用计算换显存，把激活值从O(n)降到O(√n)，代价是增加30%左右的计算量；ZeRO把优化器状态、梯度、参数分片到多卡上，ZeRO-1只分片优化器状态，ZeRO-2加分片梯度，ZeRO-3加分片参数；Offload把暂时不用的数据放到CPU内存或NVMe上，代价是PCIe带宽成为瓶颈。

这些手段可以叠加使用。我常用的组合是：BF16 + 梯度检查点 + ZeRO-2。这个组合在大多数场景下能平衡显存和速度。如果还不够，再上ZeRO-3或Offload。

注意：ZeRO-3和TP同时使用时需要小心，因为两者都在切分参数，可能导致通信量爆炸。实践中通常ZeRO-3配合PP使用，而不是TP。

3.4 推理引擎：延迟与吞吐的平衡术

推理引擎的优化目标跟训练完全不同。训练可以慢慢跑，推理必须快。但“快”有两个维度：单请求延迟低（TTFT和TPOT小）和整体吞吐高（每秒处理的token数多）。这两个目标往往冲突。

vLLM是目前最流行的开源推理引擎，它的核心创新是PagedAttention。传统推理引擎为每个请求预分配连续的KV Cache显存，导致碎片化严重，实际利用率可能只有20%-40%。PagedAttention把KV Cache切成固定大小的block，按需分配，显存利用率能到90%以上。显存利用率上去了，单卡能同时服务的请求数就多了，吞吐自然就高了。

Continuous Batching是另一个关键优化。传统静态batching要等一个batch里所有请求都完成才能开始下一批，导致短请求等长请求。Continuous Batching在每次迭代时动态加入新请求、移除已完成请求，GPU利用率大幅提升。

投机解码（Speculative Decoding）是降低延迟的手段。用一个小的草稿模型先猜几个token，然后用大模型验证。如果猜对了就跳过这些token的计算，相当于用小的计算量换大的计算量。实测下来，在代码生成等确定性强的任务上，投机解码能带来2-3倍的加速。

实操心得：vLLM的gpu_memory_utilization参数很关键，默认0.9，但如果你的模型有较大的激活值峰值，可能需要降到0.85甚至0.8。另外max_num_seqs和max_num_batched_tokens需要根据实际请求长度分布来调，不是越大越好。

3.5 调度与编排：让资源利用率最大化

调度层是AI Infra里最容易被忽视但影响最大的部分。一个训练集群的GPU利用率，很大程度上取决于调度策略。

Kubernetes是目前最主流的容器编排平台，但原生K8s对AI训练的支持并不好。训练任务通常需要gang scheduling（所有Pod同时启动），而K8s默认是逐个调度的，容易导致死锁。所以通常需要配合Volcano、Kueue等调度器。

弹性伸缩是另一个关键能力。训练任务可能因为各种原因中断（硬件故障、抢占），如果能自动恢复并继续训练，能大幅减少人工干预。这需要checkpoint机制和故障检测的配合。

注意：弹性伸缩不是万能的。如果任务频繁中断，checkpoint的开销可能超过收益。实践中通常设置一个阈值，比如中断超过3次就暂停任务并告警。

4. 实操过程与核心环节实现

4.1 从零搭建一个分布式训练环境

假设你手头有4台机器，每台8张A100 80GB，通过InfiniBand互联。目标是训练一个13B参数的模型。下面是我会走的完整流程。

第一步：环境检查。先确认GPU驱动、CUDA版本、NCCL版本一致。用nvidia-smi topo -m查看拓扑，确认NVLink和IB的连接情况。用ibstat确认IB链路状态。这一步很关键，我遇到过因为一台机器NCCL版本不一致导致训练随机hang住的情况，排查了两天才发现。

第二步：安装依赖。PyTorch、Megatron-LM或DeepSpeed、Apex（可选）、FlashAttention。版本兼容性是个大坑，建议用NGC容器或者conda锁定版本。我通常用nvcr.io/nvidia/pytorch:23.10-py3这个镜像，里面已经配好了大部分依赖。

第三步：配置并行策略。13B模型在BF16下参数占26GB，梯度26GB，优化器状态（Adam）52GB，合计104GB。单卡80GB放不下，所以需要切分。我选TP=4、PP=2、DP=4，总卡数=4×2×4=32，刚好4台机器。TP=4在单机内（NVLink），PP=2跨机（IB），DP=4跨机。

第四步：启动训练。用torchrun或mpirun启动。关键参数包括--tensor-model-parallel-size 4、--pipeline-model-parallel-size 2、--micro-batch-size 4、--global-batch-size 512。global batch size = micro batch size × DP × gradient accumulation steps。这里512 = 4 × 4 × 32，所以gradient accumulation steps=32。

第五步：监控与调优。启动后先看GPU利用率，如果低于80%就要排查。用nvidia-smi dmon看GPU利用率，用nsys或py-spy做profiling。常见瓶颈包括数据加载慢（用DALI或WebDataset加速）、通信慢（调NCCL参数）、算子效率低（用FlashAttention替换原生Attention）。

4.2 推理服务的部署与压测

推理部署比训练简单，但坑也不少。以vLLM部署一个7B模型为例。

第一步：模型转换。如果模型是HuggingFace格式，vLLM可以直接加载。如果是自定义格式，需要先转换。注意dtype的选择——FP16通常比BF16快，但BF16数值稳定性更好。

第二步：启动服务。python -m vllm.entrypoints.openai.api_server --model /path/to/model --tensor-parallel-size 2 --gpu-memory-utilization 0.9。tensor-parallel-size根据模型大小和卡数来定，7B模型单卡就能跑，但为了吞吐可以TP=2。

第三步：压测。用vllm.benchmarks.benchmark_serving或locust做压测。关键指标是TTFT（首token延迟）、TPOT（每token延迟）、吞吐（tokens/s）。压测时要模拟真实的请求长度分布，不要只用固定长度。

第四步：调优。如果TTFT高，可能是prefill阶段慢，可以调大max_num_batched_tokens。如果TPOT高，可能是decode阶段慢，可以调大max_num_seqs。如果吞吐低，可能是显存不够导致batch size上不去，可以降低gpu_memory_utilization或启用量化。

实操心得：vLLM的--enable-prefix-caching对多轮对话场景效果很好，能缓存系统prompt的KV Cache，减少重复计算。但要注意，如果系统prompt经常变，缓存命中率会很低，反而增加开销。

4.3 性能瓶颈的定位与解决

性能瓶颈的定位有一套通用的方法论。我通常按这个顺序排查：先看GPU利用率，再看显存占用，再看通信开销，最后看算子效率。

GPU利用率低（<70%）通常意味着有等待。等待可能来自数据加载（CPU瓶颈）、通信（网络瓶颈）、或者同步（锁竞争）。用nvidia-smi dmon看利用率波动，如果周期性波动，可能是数据加载；如果持续低，可能是通信。

显存占用高但利用率低，可能是batch size太小。这时候要检查是不是显存碎片化严重，或者KV Cache分配不合理。

通信开销大，用nccl-tests确认实际带宽。如果实际带宽远低于理论带宽，检查拓扑配置和NCCL参数。

算子效率低，用nsys做profiling，看哪个kernel耗时最长。常见的低效算子包括LayerNorm、Softmax、Attention。用融合算子或FlashAttention替换。

5. 常见问题与排查技巧实录

5.1 训练类问题速查

5.2 推理类问题速查

5.3 独家避坑技巧

技巧一：训练前先跑一个mini batch。用1/100的数据跑一遍完整流程，确认没有shape错误、没有OOM、没有通信问题。这个习惯帮我省了无数时间。

技巧二：checkpoint要存优化器状态。只存模型参数不存优化器状态，恢复训练后loss会跳变。我见过有人为了省空间只存参数，结果恢复后训练效果差很多。

技巧三：推理服务要设max_model_len。不设的话，vLLM会按模型的最大长度预分配KV Cache，显存浪费严重。根据实际业务需求设一个合理的值，比如4096或8192。

技巧四：NCCL超时要设长一点。默认的NCCL超时是30分钟，但在大规模训练中，一次AllReduce可能超过这个时间。设成NCCL_TIMEOUT=1800（30分钟）或更长。

技巧五：用wandb或tensorboard记录一切。loss、学习率、梯度范数、GPU利用率、显存占用、通信时间。出问题的时候，这些日志是唯一的线索。

6. 知识全景的持续更新与扩展

AI Infra这个领域变化太快了。去年还在讨论ZeRO-3和TP的组合，今年MoE和EP就成了热点。去年vLLM还是唯一选择，今年SGLang和TensorRT-LLM就追上来了。所以这张全景图不是静态的，需要持续更新。

我自己的做法是每季度做一次知识梳理，看看有没有新的技术点需要加进来。关注几个核心来源：顶会论文（NeurIPS、ICML、OSDI、NSDI）、开源项目更新（Megatron-LM、DeepSpeed、vLLM）、以及一线工程师的博客和分享。

另外，知识全景的价值在于“连接”而不是“罗列”。我见过很多人收集了一堆资料，但都是孤立的点。真正的理解是知道TP和PP为什么不能随便组合、知道PagedAttention为什么能提升吞吐、知道NCCL的Ring和Tree算法分别适合什么场景。这种“知道为什么”的能力，才是AI Infra工程师的核心竞争力。

最后分享一个我自己的学习习惯：每学一个新知识点，就试着把它挂到已有的知识树上。比如学PagedAttention的时候，我会想它跟操作系统的虚拟内存分页有什么相似之处，跟ZeRO的显存分片有什么不同。这种类比和对比，能让知识记得更牢，也更容易在需要的时候调用出来。