DeepSpeed

DeepSpeed 是一个基于 PyTorch 构建的深度学习优化库，由 Microsoft 开发，并于 2020 年在 Apache 2.0 许可证下公开发布。它解决了一个特定的难题：让训练和运行因体积过大而无法容纳在任何单个 GPU 或单个节点上的语言模型成为可能，且无需团队从零开始构建自定义分布式系统。凭借超过 42,000 颗 GitHub 星标以及延续至 v0.18.9（2026 年 3 月）的版本更新历史，它是开源机器学习领域应用最广泛的通用分布式训练框架。

DeepSpeed 的旗舰技术是 ZeRO 优化器（Zero Redundancy Optimizer，零冗余优化器），它消除了模型状态在数据并行 GPU 之间复制时通常会出现的内存冗余。ZeRO Stage 1 在 GPU 之间对优化器状态进行分片，Stage 2 增加了梯度分片，而 Stage 3 则对模型参数本身进行分片。ZeRO-Infinity 通过将数据卸载到 CPU RAM 和 NVMe SSD 进一步扩展了这一功能，使得在原本远远不够的硬件上微调万亿参数模型成为可能。除了 ZeRO 之外，DeepSpeed 还提供流水线并行、自动张量并行（AutoTP，2025 年 3 月推出）、混合专家（Mixture of Experts）训练、针对数百万 Token 上下文的序列并行，以及带有内核融合和量化功能的推理引擎。它原生集成了 Hugging Face Transformers 和 Accelerate、PyTorch Lightning 以及 EleutherAI GPT-NeoX 技术栈。

DeepSpeed 在 2026 年 5 月的实际功能

DeepSpeed 是一个与 PyTorch 一起安装的 Python 库。你需要向其传递一个 JSON 配置文件（ds_config.json），指定要使用的 ZeRO 阶段、是否将优化器状态或参数卸载到 CPU、是否使用混合精度，以及数十个其他微调参数。然后，你使用 DeepSpeed 引擎包装你的训练循环。此时，DeepSpeed 会自动处理跨 GPU 的参数分片、梯度通信、内存管理和检查点保存。

ZeRO 优化器是该系统的核心。在 ZeRO 出现之前，以 float16 精度训练一个 13B 模型，每个 GPU 仅模型权重就需要大约 26GB 内存，加上优化器状态（Adam 的动量估计大约会增加 3 倍的模型大小）和梯度，使得单个副本的每 GPU 总内存需求达到 80GB 或更多。ZeRO Stage 3 将所有这些内容分片到 N 个 GPU 上，因此在 8 个 40GB A100 上运行的 13B 模型，每个 GPU 仅需约 5GB 的参数内存，从而为批大小（batch size）和激活值腾出了空间。正是这种机制，使得 GPU 预算有限的团队能够运行以前需要专用基础设施才能完成的预训练和微调任务。

2021 年 5 月发布的 ZeRO-Infinity 展示了通过卸载到 NVMe 在 32 个 GPU 上训练 32 万亿参数模型的能力。这仍然是该系统能够协调的理论上限。在实践中，大多数生产用户在 8 到 256 个 GPU 的集群上运行带有 CPU 卸载的 ZeRO-2 或 ZeRO-3，用于 7B-70B 范围的模型。

最近新增的功能包括 DeepCompile（2025 年 4 月），它将编译器级别的优化应用于分布式训练图；Arctic Long Sequence Training（2025 年 6 月），用于支持数百万 Token 的序列；AutoTP，用于 Hugging Face 模型的自动张量并行（2025 年 3 月）；以及 ZenFlow 无停顿卸载引擎（2025 年 8 月）。SuperOffload 的相关工作在顶级系统会议 ASPLOS 2026 上获得了荣誉提名（Honorable Mention）。

2023 年 4 月 12 日发布的 DeepSpeed-Chat 具有里程碑意义：这是一个端到端的 RLHF 流水线，涵盖了监督微调、奖励模型训练和 PPO，所有这些都在一个脚本中完成。该系统在单个 A6000 GPU 上用 1.25 小时训练了一个 13B 模型，在 64 个 GPU 上用一天时间训练了一个 175B 模型，声称其吞吐量是 trlX 和 trl 的 15 倍。2023 年 4 月 Hacker News 上的发布帖引来了数百条评论，争论开源 RLHF 是否能真正达到 GPT-4 的质量：

"如果没有更大的基础模型和广泛的优化，微调将无法达到 GPT-4 的质量。" —— valine，Hacker News，2023 年 4 月 12 日

那场辩论很有先见之明。DeepSpeed-Chat 极大地降低了 RLHF 训练的门槛，使得以前因成本过高而被拒之门外的团队能够进行迭代。自 2023 年以来，与前沿模型之间的差距已大幅缩小，部分原因正是得益于此类基础设施工具。

DeepSpeed 与 PyTorch FSDP 和 Megatron-LM 的定位对比

DeepSpeed 并非孤立存在。有两个框架在相同的训练工作负载上与其竞争，关于应该使用哪一个，诚实的答案在很大程度上取决于模型大小、硬件以及团队的熟悉程度。

PyTorch FSDP（Fully Sharded Data Parallel，完全分片数据并行）从 1.12 版本开始内置于 PyTorch 核心中，并在运行时内部原生实现了 ZeRO 风格的参数分片。FSDP 的优势在于中等规模下的简单性和原始吞吐量。独立基准测试表明，对于 100M-1B 范围内的模型，FSDP 每次迭代的运行速度比 DeepSpeed ZeRO-3 快 5 倍，因为原生的 PyTorch 集成避免了 Python 级别的开销，并使用了优化的融合 reduce-scatter 路径。FSDP 的配置存在于 Python 代码中，无需外部 JSON 文件。实际的权衡是：FSDP 无法卸载到 NVMe，因此它受限于 GPU+CPU 的总 RAM。对于适合该范围的模型（在配置良好的节点上，float16 精度下大约低于 30B），FSDP 越来越成为 Hugging Face Trainer 和 TorchTitan 的默认选择。当需要 NVMe 卸载或 ZeRO-Infinity 级别的内存时，以及在 10B+ 参数规模下（此时其成熟的 ZeRO-3 实现和流水线并行再次变得具有竞争力），DeepSpeed 则更胜一筹。

Megatron-LM 是 NVIDIA 的研究框架，用于使用手工调优的张量并行内核在极端规模下训练 Transformer 模型。Megatron-LM 的张量并行（TP）实现针对配备 NVLink 的 NVIDIA A100/H100 硬件进行了最彻底的优化。其模型架构（GPT、BERT、T5）专为 TP 构建；每个注意力头和 MLP 权重矩阵都通过自定义 CUDA 内核在 GPU 之间进行拆分。其局限性在于紧密的架构耦合：通过 Megatron 运行新颖的模型架构需要大量的工程努力。相比之下，DeepSpeed 的 AutoTP 能够更自动地处理 Hugging Face 模型的张量并行。关键在于，Megatron-LM 和 DeepSpeed 并非严格的竞争对手：Megatron-Turing NLG 530B 模型（公开记录中最大的密集模型训练运行）在节点内使用 Megatron-LM 进行张量并行，并在节点间使用 DeepSpeed ZeRO 进行数据并行。需要 NVIDIA 特定吞吐量绝对上限的用户通常会将两者结合使用。

如果你使用 Anyscale 或 Ray Train 处理分布式工作负载，DeepSpeed 可通过 Ray-DeepSpeed 接口进行集成，团队在 2025 年 10 月的联合聚会上演示了这一点。为了在训练的同时进行实验跟踪和模型版本控制，团队通常将 DeepSpeed 与 MLflow 搭配使用。对于训练后模型的推理服务，vLLM 是主流选择，尽管 DeepSpeed 自己的推理引擎在离线批处理方面仍然具有竞争力。微调 LLaMA 系列模型是开源社区中最常见的 DeepSpeed 工作负载之一。

训练工作流的真实情况

文档与运行 DeepSpeed 的日常体验之间确实存在差距，任何诚实撰写关于此工具的人都必须正视这一点。

从零开始设置 ZeRO-3 训练运行需要编写一个包含数十个参数的 ds_config.json 文件：ZeRO 阶段、卸载设备（CPU 或 NVMe）、allgather 桶大小、reduce 桶大小、stage3_gather_16bit_weights_on_model_save、overlap_comm 等等。参数名称并不总是直观的。一个放错位置的逗号、一个拼错的字段，或者配置中的优化器类型与 Python 中实例化的优化器不匹配，都会悄无声息地阻止训练开始，或者更糟的是，开始训练后在 epoch 中途崩溃。这是 DeepSpeed GitHub issues 中最常见的支持请求类别。

跨库版本的性能衰退是一个有记录的担忧。GitHub issue #7499 记录了在 8x A100 设置上，从 v0.13.1 到 v0.15.4 直至 v0.16.9，ZeRO-3 的训练吞吐量下降了 10%，而 ZeRO-1 和 ZeRO-2 配置未受影响：

"升级 DeepSpeed 后，当使用 DeepSpeed Zero3 配置时，训练性能与 0.13.1 版本相比下降了约 10%。" —— frozenleaves，GitHub deepspeedai/DeepSpeed issue #7499，2024 年

这种衰退对于依赖稳定吞吐量的生产流水线来说是一个严重的问题。大多数团队使用的缓解措施是依赖项锁定（dependency pinning），但这又带来了自身的维护负担。

DeepSpeed 中的流水线并行（PP）需要修改模型架构代码以明确定义层边界。对于任何非标准 GPT 风格的 Transformer 来说，这都不是一件容易的事。相比之下，ZeRO-3 是与架构无关的，这就是为什么大多数团队在考虑 PP 之前会优先选择 ZeRO-3 + 数据并行。

在小模型或小集群上使用 ZeRO-3 时，GPU 利用率可能很差。GitHub 讨论 #5488 记录了在较小模型的多节点运行中，碎片化的 all-gathers 无法与计算重叠的问题。补救措施通常是使用 ZeRO-2 或在该规模下切换到 FSDP，但首先诊断利用率问题需要使用具有自身学习曲线的分析工具（如 Nsight、PyTorch Profiler）。

当它运行良好时，它确实具有变革性。使用 ZeRO-3 在 8 个 A100-80GB GPU 上运行 70B 参数模型，与五年前研究人员可用的任何功能相比，在能力上有着质的区别。摩擦确实存在，但它与该工具所能实现的规模是成正比的。

DeepSpeed 是为谁构建的

DeepSpeed 专为需要在多 GPU 基础设施上训练或微调大型语言模型（7B+）的机器学习工程师和研究人员而构建。典型用户具备 PyTorch 的应用知识，在使用朴素的数据并行训练时遇到了 GPU 内存限制，并愿意投入 1-2 天的时间进行配置和调试，以解锁原本不可能实现的规模化训练。

研究机构的团队（EleutherAI 将其用于 GPT-NeoX，BigScience 将其用于 BLOOM）、大型科技公司（LinkedIn 记录了在 2025 年 11 月使用 ZeRO++ 进行推荐系统 LLM 蒸馏）以及资金充足的从事指令微调、RLHF 或预训练的初创公司都属于这一类。Hugging Face Accelerate 的集成意味着你可以通过极少的代码更改将 DeepSpeed 添加到许多现有的训练脚本中，这在一定程度上扩大了其可访问性。

DeepSpeed 不是什么

DeepSpeed 不适合 1B 参数以下的模型。在该规模下，FSDP 配置更简单，实际运行速度更快，并且内置于 PyTorch 中。当模型已经可以容纳在两三个标准 GPU 上时，设置 ds_config.json 的开销以及与版本相关的衰退风险是不值得的。

它不是托管服务或云平台。没有 DeepSpeed SaaS。你需要自带计算资源。Azure、AWS、GCP 或本地集群都可以工作，但运营责任完全由你承担。

它不是用于实时 API 流量的推理服务系统。DeepSpeed 的推理引擎专为吞吐量优化的批处理推理而设计，而非用于低延迟请求服务。对于生产推理 API，vLLM 是主流选择。DeepSpeed Inference 适用于离线批处理作业，在这些作业中，连续批处理基础设施的成本是不合理的。

它不是一个对初学者友好的工具。文档虽然详尽，但假定用户熟悉分布式系统概念（NCCL、集合通信操作、内存层次结构）。对于刚接触分布式训练的研究人员来说，最好从 Hugging Face Accelerate 更简单的界面开始，然后在理解参数含义后再添加 DeepSpeed 配置。

在极端规模的 NVIDIA 硬件上，它也不是 Megatron-LM 的直接替代品。对于 500B+ 的密集模型，当 FLOP 吞吐量成为约束条件时，Megatron-LM 的张量并行内核是难以超越的。当内存灵活性和跨硬件可移植性比峰值吞吐量更重要时，DeepSpeed 则更具优势。