LLM 的并行策略
LLM 的并行化策略是支撑超大规模模型训练与高效推理的核心技术。下面从训练与推理两个阶段，系统梳理目前主流的并行化策略及其实现方式：
训练阶段并行策略
| 策略类型 | 核心思想 | 并行粒度 | 通信方式 | 优点 | 缺点 | 适用场景 | 工业实现 | ||
|---|---|---|---|---|---|---|---|---|---|
| 数据并行 (DP) | 复制模型参数到多个设备，拆分数据进行计算，梯度同步更新参数。 | 数据维度（样本） | AllReduce（梯度聚合） | 1. 提高训练吞吐量，简单易实现； 2. 适合小模型或数据量大时。 | 1. 显存占用高（冗余存储模型副本）； 2. 通信开销大（AllReduce）。 | 模型较小、数据量大时使用。 | PyTorch DDP、DeepSpeed DP、FSDP | ||
| 张量并行 (TP) | 将模型张量（如权重矩阵）分块，分配到不同设备上计算，减少单设备内存压力。 | 张量维度（矩阵/层） | AllReduce（梯度聚合）、点对点通信（前向/反向） | 1. 降低单设备内存占用； 2. 支持超大模型训练。 | 1. 实现复杂（需协调计算和通信，通信频繁，需高带宽）； 2. 参数切分需保证数学一致性。 | 大模型训练（如千亿参数模型）。 | Megatron-LM、DeepSpeed Tensor Parallelism | ||
| 流水线并行 (PP) | 将模型按层划分到不同设备，分阶段处理数据（如前向/反向），类似流水线作业。 | 层级（模型深度） | Pipeline 通信（数据分段传输） | 1. 高效利用设备资源； 2. 支持超大规模模型训练。 | 1. 调度复杂（需处理数据依赖）； 2. 设备利用率可能不均衡。存在“气泡”延迟，需调优 micro-batch 数 | 模型层数极多时（如数百层以上）。 | DeepSpeed ZeRO-Offload、Megatron-LM、GPipe、PipeDream、DeepSpeed PP | ||
| Zero 系列 (ZeRO) | 通过分片优化器状态、梯度、参数，减少冗余存储，降低内存占用。 | 参数维度（优化器/梯度/参数） | AllReduce（梯度聚合）、点对点通信（分片同步） | 1. 显存利用率高（适合超大模型）； 2. 支持 100B+ 参数模型训练。 | 1. 通信开销大（AllReduce 频繁）； 2. 实现复杂（需分片管理）。 | 显存受限时（如单卡显存不足）。 | DeepSpeed ZeRO-1/2/3 | ||
| 4D 并行 | 结合 TP、PP、CP（上下文并行）、DP，综合分片模型、数据和序列，最大化资源利用率。 | 多维度（张量/层/序列/数据） | 复合通信（AllReduce + Pipeline + 点对点） | 1. 极致扩展性； 2. 支持万亿参数模型训练。 | 1. 实现复杂（需协调多种并行策略）； 2. 依赖高性能通信硬件（如 InfiniBand）。 | 万亿参数模型训练（如 Llama 3.1-405B）。 | Llama 3.1-405B 训练框架 | ||
| 序列并行 (SP) | 将输入序列分段处理，降低长序列的内存瓶颈，与 TP 结合使用。 | 序列维度（输入长度） | 点对点通信（序列分段传输） | 1. 降低长序列计算时的显存占用； 2. 提升内存效率。 | 1. 实现复杂（需与 TP 协同），需处理注意力机制跨设备通信； 2. 依赖 TP 的分片策略。 | 超长序列输入（如文档级任务）。 | HuggingFace Transformers、DeepSpeed | ||
| 专家并行 (EP) | 将混合专家模型（MoE）中的专家模块分配到不同设备，动态路由输入数据，仅激活部分专家模块。 | 专家模块（子模型） | AlltoAll（专家间数据传输）、点对点通信（路由） | 1. 显著提升模型容量（适合万亿参数模型）； 2. 计算效率高（仅激活部分专家）。 | 1. 通信开销大（AlltoAll 通信复杂）； 2. 路由机制设计复杂（需负载均衡）。 | MoE 模型训练（如 Switch Transformer、MoE-LLM）。 | DeepSpeed-MoE、Megatron-LM | ||
| 全分片数据并行（FSDP） | 分片模型参数、梯度、优化器状态，仅在计算时聚合必要参数 | 模型状态（参数 + 梯度等） | 参数 all-gather + 梯度 reduce-scatter | 显存线性节省（随 GPU 数量增加），支持超大规模 | 超大模型，流水线阶段负载不均或词表较大 |
- 流水线并行（PP）优化
- GPipe 调度：将 batch 切分为 micro-batch，降低 bubble 比例。
- 1F1B 调度（One-Forward-One-Backward）：优先执行反向传播，减少空闲时间。
- 交错调度（Interleaved Pipeline）：DeepSpeed 支持，进一步减少 bubble。
- 序列并行（SP）
- Megatron-LM SP：将序列维度切分到多 GPU，注意力计算通过
All-Gather通信。 - DeepSpeed Ulysses：结合 TP 与 SP，支持超长序列训练与推理。
推理阶段并行策略
| 策略类型 | 核心思想 | 并行粒度 | 通信方式 | 优点 | 缺点 | 适用场景 | 工业实现 |
|---|---|---|---|---|---|---|---|
| 张量并行 (TP) | 推理阶段将模型权重分片到不同设备，协同计算输出结果，减少单设备负载。 | 张量维度（矩阵/层） | AllReduce（结果聚合）、点对点通信（激活传输） | 1. 降低单设备内存压力； 2. 支持超大模型推理。 | 1. 实现复杂（需协调计算和通信）； 2. 参数切分需保证数学一致性。 | 大模型部署（如千亿参数模型）。 | vLLM、TensorRT-LLM、DeepSpeed Inference、Megatron-LM |
| 序列并行 (SP) | 将输入序列分段处理，减少长序列的内存占用，与 TP 结合使用。 | 序列维度（输入长度） | 点对点通信（序列分段传输） | 1. 降低长序列推理时的显存占用； 2. 提升内存效率。 | 1. 实现复杂（需与 TP 协同）； 2. 依赖 TP 的分片策略。 | 超长序列输入（如文档级任务）。 | HuggingFace Transformers |
| 上下文并行 (CP) | 将输入上下文分段处理，减少单设备内存压力，适用于长上下文场景。 | 序列维度（上下文长度） | 点对点通信（上下文分段传输） | 1. 支持超长上下文推理（如数万 token）； 2. 降低显存占用。 | 1. 实现复杂（需管理上下文分段）； 2. 依赖 TP/SP 的分片策略。 | 长上下文任务（如代码生成、长文档理解）。 | Llama 3.1-405B 推理框架 |
| 模型并行 | 根据硬件资源手动划分模型（如将不同层分配到不同设备），避免单设备内存溢出。 | 层级（模型深度） | 点对点通信（层间数据传输） | 1. 灵活适配硬件资源； 2. 支持超大模型部署。 | 1. 调度复杂（需处理层间依赖）； 2. 通信开销大（层间数据传输）。 | 显存受限但计算资源充足时。 | 自定义部署方案（如 ONNX Runtime） |
| 批处理并行 | 将多个请求合并为批次处理，提高设备利用率。 | 数据维度（样本） | 无通信（独立处理） | 1. 提高吞吐量； 2. 降低单位请求的延迟。 | 1. 延迟波动（凑批可能导致 P99 时延不稳定）； 2. 显存占用高（需缓存 KVCache）。 | 高并发场景（如 API 服务）。 | HuggingFace Transformers、vLLM |
其他加速策略
| 策略类型 | 策略名称 | 核心思想 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|---|
| 模型优化 | KV Cache 量化 | 将 KV 缓存（Key/Value 缓存）从 FP16 压缩为 INT4/INT2，减少显存占用。 | 显存需求降低 50%-75%，支持更长上下文长度。 | 精度可能下降（INT2 效果差），需权衡精度与性能。 | 大模型推理（如 Llama2-7B、Gemma-27B）。 |
| 算法加速 | Flash Attention | 分块计算 Attention，减少 HBM 访问次数，融合中间结果避免存储开销。 | 显著降低内存占用，提升计算吞吐量（30%-100%）。 | 实现复杂，依赖硬件支持（如 GPU 的 SRAM）。 | 长序列 Attention 计算（如 Transformer 层）。 |
| 算法加速 | 投机解码 Speculative Decoding | 用小模型（Draft Model）生成候选 Token，大模型（Target Model）并行验证。 | 推理速度提升 2-4 倍，保持输出质量。 | 需额外训练/微调 Draft Model，增加系统复杂性。 | 高并发低延迟场景（如在线服务）。 |
| 算法加速 | PD 分离（Pre-Fill/Decode 分离） | 将预填充（Pre-Fill）和解码（Decode）阶段分离，独立调度。 | 避免预填充阶段阻塞解码，提升任务吞吐率。 | 需复杂调度策略（如 MLFQ），增加系统开销。 | 混合请求场景（短回复与长回复共存）。 |
| 模型优化 | 模型结构优化（如 GQA/MQA） | 减少 KV 头数量（如 MQA 仅保留 1 个 KV 头），降低 KV Cache 内存占用。 | 显存占用减少，计算效率提升。 | 可能牺牲部分模型性能（如多样性）。 | MoE 模型（如 Switch Transformer）。 |
| 分布式部署 | 分布式 GPU Offload | 将模型部分层卸载到 CPU/低端 GPU，动态切换计算任务。 | 支持超大模型（如 27B 参数）在有限显存下运行。 | 计算延迟增加（数据迁移开销），需高效内存管理。 | 资源受限场景（如消费级 GPU）。 |
| 分布式部署 | 模型并行（TP/PP/SP） | 将模型拆分到不同设备（张量并行 TP、流水线并行 PP、序列并行 SP）。 | 显存利用率高，支持超大规模模型训练/推理。 | 通信开销大（AllReduce/AlltoAll），实现复杂。 | 万亿参数模型训练（如 Llama3）。 |
| 模型压缩 | 量化（Quant） | 将模型权重从 FP32/FP16 压缩为 INT8/INT4，减少计算复杂度。 | 显存需求降低 50%-75%，推理速度提升。 | 精度可能下降（需后量化校准），INT4 效果优于 INT2。 | 边缘部署（如手机、IoT 设备）。 |
| 内存管理 | 块状预填充（Chunked Pre-Fill） | 将预填充请求拆分为块，构建批次，减少 Pipeline Bubbles。 | 提升预填充阶段的并行效率，减少资源浪费。 | 需动态调整块大小，增加调度复杂性。 | 多任务混合场景（预填充与解码共存）。 |
| 硬件加速 | 专用 LLM 加速器（LPU/NPU） | 使用专用硬件（如 Groq TSP、NPU）优化 Transformer 架构计算。 | 能效比提升 15-30 倍，延迟降低 50%+。 | 成本高，需专用开发工具链，生态支持有限。 | 高性能计算（如数据中心推理）。 |
KV Cache 量化
- 核心思想：通过量化技术（如 INT4）压缩 KV 缓存，减少显存占用。例如，Llama2-7B 处理 10,000 词元时，KV 缓存可从 5GB 压缩至 1.25GB（INT4）。
- 实现方式：使用
transformers库的cache_implementation="quantized"选项，结合quanto或bitsandbytes后端。
Flash Attention
- 关键技术：
- 分块计算：将 Attention 矩阵分块加载到 SRAM，减少 HBM 访问。
- 融合计算：合并 Attention 计算步骤，避免中间结果存储。
- 性能提升：Llama2-7B 推理吞吐量可提升 30%-100%，具体取决于显存带宽和分块策略。
Speculative Decoding
- 三步流程：
- Draft Model 生成候选 Token：快速生成多个 Token。
- Target Model 并行验证：批量验证候选 Token 的准确性。
- 输出结果：保留验证通过的 Token。
- 典型效果：IBM 实验显示，推理速度提升 2-4 倍，质量损失可忽略。
PD 分离（Pre-Fill/Decode 分离）
- 调度策略：
- MLFQ（多级反馈队列）：轮转执行预填充和解码阶段。
- SRPT（最短剩余时间优先）：优先执行剩余时间最短的任务。
- 优势：解决预填充阶段阻塞解码的问题，提升整体吞吐率。
分布式 GPU Offload
- 典型工具：
- LM Studio：基于 llama.cpp，支持 iGPU 加速和 VGM（可变显存）扩展。
- BigDL-LLM：适配低显存设备，动态卸载模型层到 CPU。
- 效果：AMD 锐龙 AI 300 系列处理器在 Meta Llama 3.2 1B 模型中，性能提升可达 60%（结合 VGM）。
- 对比与选择建议
| 策略 | 适用场景 | 推荐优先级 | 硬件依赖 |
| ------------------------ | ---------------------------- | --------- | --------------------- |
| KV Cache 量化 | 长上下文推理（如文档生成）| 高 | GPU（支持 INT4/INT2 量化）|
| Flash Attention | 长序列 Attention 计算（如 Transformer）| 高 | GPU（NVIDIA A100/H100）|
| Speculative Decoding | 高并发低延迟服务（如聊天机器人）| 中 | GPU（需并行计算能力）|
| 分布式 GPU Offload | 资源受限场景（如消费级 GPU）| 中 | CPU+GPU 混合设备（如 AMD 锐龙 AI）|
| 模型并行（TP/PP） | 万亿参数模型训练（如 Llama3）| 高 | 多 GPU 集群（InfiniBand 网络）|
工业实现对比
| 框架名称 | 核心特点 | 适用场景 | 优势 | 工业应用案例 |
| ------------ | --------------------------------------------------------------------------------------------- | --------------------------------------------------- | ----------------------------------- | ------------------------------------------------- |
| DeepSpeed | 推理加速子系统，通过 Transformer Kernel Fusion、自动精度混合、KV 缓存优化、多流调度等技术提升性能，支持 ZeRO 推理、Tensor Parallel 推理 | 适用于大模型推理场景，尤其是对延迟和吞吐有要求的场景 | 无需开发者手动改模型结构，降低工程门槛，可大幅提升大模型推理性能 | 可用于各类基于大模型的在线服务推理加速 |
| Megatron-LM | 支持模型并行、数据并行、流水线并行等多种分布式训练技术，结合混合精度训练和激活检查点等优化策略 | 主要用于大规模语言模型的训练，适合学术研究和企业开发定制化 NLP 模型 | 能在数百甚至数千个 GPU 上高效训练超大模型，降低训练时间和资源需求 | 训练了 Megatron-Turing NLG 530B，为 GPT-3 等模型提供分布式训练参考 |
| vLLM | 利用 PagedAttention 技术智能管理 KV 缓存页，结合动态批处理和异步调度机制，支持多 GPU 分布式部署和量化优化 | 适用于高并发在线服务，如金融交易、智能客服和文档处理等，对延迟和吞吐量要求极高的场景 | 可在低延迟下稳定处理海量并发请求，低首次响应时间表现出色 | 金融、医疗等领域的高并发实时响应场景 |
| HuggingFace | 提供丰富的预训练模型和工具，有成熟稳定的生态系统，TGI 组件可提供生产级稳定推理服务 | 企业级云端服务和 API 推理平台，适合需要快速调用多种模型进行推理的场景 | 生态丰富，模型资源多，易于使用和部署 | 各类基于云端的 NLP 应用，如文本生成、情感分析等 |
| Colossal-AI | 可降低大模型训练 / 微调成本，提升模型容量和推理速度，提供端到端解决方案，支持多种硬件 | 适用于大模型的训练、微调与推理，可用于构建高质量 AI 大模型及应用，尤其在国产硬件环境有优势 | 可在千卡集群预训练私有化千亿参数大模型，推理速度可提升 10 倍 | 为企业提供私有化训推一体机解决方案，优化多模态推理性能 |
| TensorRT-LLM | 基于 NVIDIA TensorRT 的深度优化引擎，通过核融合、量化感知编译等技术，实现低延迟和超高吞吐量推理，支持分布式推理 | 适用于大规模实时响应系统、在线服务和需要极致性能优化的企业级应用，尤其是金融、政府等对安全有要求的场景 | 将硬件性能压榨至理论极限，有模型加密等安全特性 | 金融风控系统、医疗影像报告生成等场景 |
核心挑战
LLM 并行策略（无论训练或推理）的共性挑战可从 “任务分解与负载均衡”“通信开销和同步”“内存管理和资源竞争”“硬件限制与架构适配”“算法设计和工程实现” 五个维度展开，具体如下：
一、任务分解与负载均衡
所有并行策略的核心是 “将任务拆解到多个设备”，但拆解逻辑稍有偏差就会导致负载失衡，核心挑战包括：
- 分解粒度难把控
- 过粗：如模型并行仅按 “层” 切分（而非张量级），可能导致某几层计算量极大（如注意力层），对应设备持续满负载，其他设备空闲。
- 过细：如张量并行将矩阵拆分为过多小块，虽负载更均匀，但会增加通信次数（每次计算都需小数据交互），反而抵消并行收益。
- 任务特性导致天然失衡
- 输入动态性：如推理时用户请求长度差异大（短问答 vs 长文档），数据并行的 “动态批处理” 中，长序列计算耗时是短序列的数倍，设备负载随输入波动。
- 结构特殊性：如 MoE 的 “专家并行” 中，路由器倾向于选择少数 “优质专家”，导致 80% 的计算集中在 20% 的专家上，其他专家设备长期空闲。
- 静态分配不适应动态场景
多数并行策略（如流水线并行按 “层数固定分配设备”）是静态的，但 LLM 训练 / 推理中任务需求会变（如训练时批次大小调整、推理时请求量突增），静态分配无法实时适配，易出现 “设备资源浪费” 或 “某设备过载”。
二、通信开销和同步
并行的本质是 “设备协同”，而协同依赖通信，通信成本是并行效率的核心瓶颈：
- 通信量随并行规模递增
- 数据并行的 “梯度同步”（All-Reduce）中，通信量与模型参数规模成正比，当模型达千亿参数时，单轮同步需传输数十 GB 数据，跨节点（非 NVLink 连接）时耗时可能超过计算本身。
- 张量并行的 “矩阵分片交互” 中，每次矩阵乘法都需传递中间结果（如切分后的矩阵块），通信频率随计算步骤增加，小批量场景下 “通信耗时＞计算耗时”。
- 同步机制导致等待
- 同步并行（如数据并行的 “梯度平均后再更新”）中，所有设备必须等最慢的设备完成计算才能进入下一步（“木桶效应”），某一设备因临时负载波动（如内存卡顿）会拖慢整体。
- 异步并行（如部分数据并行优化）虽可避免等待，但可能因参数更新不同步导致模型收敛变慢（训练）或推理精度下降。
- 通信拓扑适配难
- 设备间通信能力差异大（如单机多 GPU 用 NVLink 带宽达 300GB/s，跨机用以太网仅 10GB/s），但并行策略通常默认 “通信链路均匀”，实际中跨节点通信会成为瓶颈（如多机数据并行中，跨机节点的梯度同步耗时是单机内的 10 倍以上）。
- 数据一致性：共享内存或分布式存储中，需通过缓存一致性协议（如 MESI）或软件锁机制保证数据正确性。
三、内存管理和资源竞争
并行虽通过 “拆分” 降低单设备负载，但会引入额外内存开销，且多设备共享资源时易引发竞争：
- 额外内存占用抵消并行收益
- 数据并行需在每个设备保存完整模型副本，千亿级模型单副本占 100GB + 显存，8 卡数据并行就需 800GB + 总显存，远超普通集群能力。
- 流水线并行需暂存 “激活值”（前层输出供后层使用），长序列（如 128K 上下文）训练时，单批次激活值可占数十 GB，若设备内存不足，需频繁 “内存 - 磁盘” 交换，速度骤降。
- 显存/内存占用：大规模模型（如 LLM）的 KV 缓存、激活存储需求极高，需通过量化、卸载等技术优化。
- 资源竞争导致效率波动
- 多设备共享存储 / 带宽：如推理时多卡同时读取模型权重文件，存储 IO 成为瓶颈；训练时多节点争用网络带宽，通信延迟从稳定的 1ms 飙升至 10ms+。
- 内存碎片化：并行计算中频繁的 “通信缓存申请 / 释放”（如暂存中间结果）会导致内存碎片化，实际可用内存低于标称值，甚至触发 OOM（内存溢出）。如 KV 缓存管理中的碎片问题（vLLM 的 PagedAttention 通过分块优化缓解）。
四、硬件限制与架构适配
并行策略的性能依赖硬件特性，若脱离硬件能力，并行效率会大幅缩水：
- 通信硬件瓶颈
- 专用硬件依赖：低带宽设备无法支撑细粒度并行，如张量并行依赖设备间高带宽（需 NVLink 或 InfiniBand），若用普通 PCIe GPU 集群（带宽仅 NVLink 的 1/10），矩阵分片交互会卡死。
- 并行策略需匹配硬件拓扑（如单机多 GPU 用 NVLink，多机用 InfiniBand），通用策略在异构硬件（如 GPU+TPU）上效率骤降.
- 计算硬件适配性：如 TPU 擅长 “脉动阵列计算”，但现有并行策略（如 MoE 专家并行）多为 GPU 设计，直接迁移到 TPU 会因 “专家调度与 TPU 计算单元不匹配” 导致效率下降。
- 硬件规模与策略绑定
- 部分策略对设备数量有强依赖：如流水线并行需设备数≥模型层数（否则某层需重复部署），若硬件集群只有 4 卡，但模型有 8 层，只能 “2 卡跑 1 层”，反而增加通信。
- 异构硬件难协同：混合 GPU（如 A100+V100）或 GPU+CPU 集群中，并行策略需区分设备能力（如让 A100 承担计算密集层，V100 承担轻量层），但现有策略多假设设备同构，适配逻辑复杂。不同 GPU（NVIDIA vs AMD）、NPU、CPU 的指令集和内存架构差异，导致优化策略需定制化。
- 能效比与功耗：高并行计算可能带来高能耗（如边缘设备部署需兼顾低功耗）。
五、算法设计和工程实现
并行策略需算法层面兼容模型结构，且工程上能稳定实现，核心挑战包括：
- 算法与并行逻辑的兼容性
- 模型结构限制：如 LLM 的 “残差连接”“层归一化” 需全局信息，张量并行拆分后需额外通信（如 All-Gather）才能完成计算，增加实现复杂度。
- 动态策略难设计：如推理时 “根据输入长度动态选择并行粒度”（短序列用数据并行，长序列用张量并行），需算法层面实时决策，易引入判断延迟。
- 并行算法设计：需针对特定任务（如 Attention 计算、Diffusion 模型）设计高效并行算法（如 Flash Attention、Speculative Decoding）。
- 动态调整需求：如流水线调度中需动态平衡子序列数量与 Pipeline Bubbles（SPPO 框架）。
- 精度与性能权衡：量化、剪枝等压缩技术可能牺牲模型精度，需权衡优化效果。
- 工程实现的复杂度
- 通信逻辑嵌套：混合并行（如数据 + 张量 + MoE）中，通信算子（All-Reduce、Send/Recv、Gather）需按计算步骤严格排序，调试时难以定位 “通信死锁” 问题。
- 框架适配限制：现有深度学习框架（如 PyTorch）的分布式接口对部分并行策略（如序列并行）支持不完善，需手写底层 CUDA 代码，开发成本高。并行逻辑需深度嵌入模型代码（如层切分、通信算子），对框架兼容性要求高（如 PyTorch/TensorFlow 的并行 API 支持度）.
- 可扩展性与鲁棒性
- 扩展上限：当设备数超过某阈值（如数据并行 1000 卡），通信协调成本会超过计算收益，并行效率骤降（“边际效益为负”）。
- 容错性差：某设备故障（如 GPU 掉卡）会导致整批任务失败，而 LLM 训练 / 推理任务周期长（小时级），容错机制（如 Checkpoint 恢复）会额外消耗资源。
总结
所有并行策略的挑战本质是 “并行收益与额外成本的平衡”—— 并行通过 “拆分任务” 提升效率，但会引入 “通信、内存、负载、硬件适配” 等额外成本。实际应用中需根据模型规模（如 10B vs 1000B）、硬件条件（如单机 8 卡 vs 100 机集群）、场景需求（如训练速度 vs 推理延迟）选择策略，尽可能让 “收益＞成本”。
优化器
分布式优化器
Zero 系列 (Zero Redundancy Optimizer) 通过分片优化器状态（如 Adam 的动量、方差），减少显存占用，支持超大规模模型训练：
- ZeRO-1：优化器状态分片（每个设备存储不同参数的优化器状态）。
- ZeRO-2：优化器状态 + 梯度分片（进一步减少冗余）。
- ZeRO-3：优化器状态 + 梯度 + 参数分片，通信量略增显存利用率最高。
- ZeRO-Offload：将参数/优化器状态卸载到 CPU 或 NVMe，进一步降低显存占用。
- 动态获取机制：参数使用时通过 AllGather 临时重构完整层。
- 通信优化：使用 Reduce-Scatter 替代 AllReduce，降低通信量。
- 计算通信重叠：在反向传播时同步梯度，减少等待时间。
ZeRO-R（剩余状态优化）
- 目标：优化未被 ZeRO 覆盖的剩余状态（如激活值、临时缓冲区）。
- 技术：
- 激活值分区：按模型并行度分片存储激活值，降低内存占用（代价：增加 AllGather 通信）。
- 恒定缓冲区：使用固定大小的环形缓冲区，抑制内存波动。
- 内存整理：预分配 + 动态内存池管理，减少碎片化（碎片减少 80%+）。
ZeRO-Infinity（突破物理限制）
- 核心思想：将异构内存（GPU 显存 → CPU 内存 → NVMe 存储）统一管理，按需迁移参数。
- 工作流程：
- 前向传播时：按需从 NVMe→CPU→GPU 迁移参数。
- 计算完成后：立即将数据回传至 NVMe。
- 梯度更新时：仅保留当前层参数在 GPU。
- 关键技术：
- 智能预取（Prefetching）：重叠数据传输与计算。
- 异步流水线：CPU-GPU-NVMe 三级流水。
- 带宽优化：参数聚合传输（减少小数据包）。
优缺点
| 优点 | 缺点 |
|---|---|
| 1. 显存利用率极高（支持万亿参数模型）。 2. 灵活适配异构内存（GPU/CPU/NVMe）。 3. 通信与计算重叠，提升效率。 | 1. 实现复杂（需精细管理分片和通信）。 2. 依赖高性能网络（如 InfiniBand）。 3. ZeRO-Infinity 计算效率低于纯 GPU 训练（约 45% vs 70%）。 |