DeepSeek-671B-SFT-Guide
ScienceOne-AI/DeepSeek-671B-SFT-Guide加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
——让满血版 671B 大模型微调从"不可能"变为"可操作"
图1：DeepSeek-V3 全参数微调训练 loss 收敛曲线。起始 loss 约 3.5，经过 1 epoch 后收敛至 1.2，证明训练流程有效。
2024年底，DeepSeek 团队相继发布 DeepSeek-V3（632B 参数）和 DeepSeek-R1（671B 参数）两款重磅模型，凭借 MoE（混合专家）架构和超长上下文能力，在多项评测中逼近 GPT-4o 和 Claude-3.5。然而，这两款模型的"满血版"——即 671B 参数量、BF16 精度的原始版本——对任何 AI 开发者来说都像是"珠穆朗玛峰"：参数太多、显存太大、普通硬件根本塞不进去，更别说在其基础上做全参数微调（Full Parameter SFT）了。
ScienceOne-AI 团队直面这一痛点，推出了一套完整的 DeepSeek-V3/R1 671B 满血版全参数微调解决方案，将原本需要超算集群才能完成的工程任务，梳理为可复现的脚本和代码。截至目前，该项目已在 GitHub 获得 809 Stars、98 Forks，成为大模型微调领域最热门的工程参考项目之一。
理解这个项目的价值，需要先了解技术难点在哪。
第一，参数规模巨大。 DeepSeek-V3/R1 采用 MoE 架构，总参数量达 671B，其中每个 Token 激活的专家约为 37B 参数。但"满血版"的 MoE 实现是每个专家都完整存储在显存中，相比"蒸馏版"或"量化版"需要 2-3 倍的显存。一张 H100 GPU（80GB 显存）只能放下极小一部分，必须靠多卡甚至多机并行。
第二，序列长度超长。 该项目支持最高 32768 Token 的上下文长度，对注意力机制的显存占用提出了极高要求。标准的多头注意力（MHA）在 32k 上下文下单卡必然 OOM，必须引入 Flash Attention 和序列并行（Sequence Parallel）。
第三，中间 checkpoint 体积庞大。 在 32 节点、每节点 8 GPU 的配置下，单个训练中间 checkpoint 约需 7.4TB 硬盘空间。存储策略和格式转换是工程落地的关键环节。
本项目提供了一套从数据准备 → 训练 → 权重转换 → 推理部署的完整工具链，开发者无需自行拼接其他工具。
项目定义了标准的多轮对话数据格式（JSONL），每条记录包含 messages 数组，每个消息有 role（system/user/assistant）和 content 字段，assistant 消息可通过 loss: false 控制是否参与 Loss 计算。这与 OpenAI 的 ChatML 格式高度兼容，可直接使用标准数据处理流水线。训练时，项目会根据 DeepSeek-V3/R1 的专用模板自动转换为特殊格式，包含特殊 Token。
项目的核心训练代码基于 xtuner（OpenMMLab 开源的大模型微调框架）进行深度定制。训练配置文件 sft_deepseek.py 包含完整的超参数设置：最大序列长度 32768、单卡 batch_size=2、学习率 2e-7（MoE 模型常用极小学习率）、AdamW 优化器 + bf16 混合精度 + 梯度裁剪 max_norm=1。
关键代码路径中，项目使用了自定义的 DeepseekV3ForCausalLM 模型类，其中包含 moe_implementation='shard' 参数，控制 MoE 专家的分布式实现方式。项目自带的 model/modeling_deepseek.py（约 80KB）相比 HuggingFace 原版进行了定制修改以适配 MoE 分布式训练和 DeepSpeed ZeRO-3，另有 modeling_deepseek_origin.py 保留原始版本供对照。
这是本项目最具工程价值的地方。项目使用了 DeepSpeed ZeRO-3 + Offload 显存优化技术，配合序列并行（Sequence Parallel），在 32 节点 × 8 GPU = 256 张 GPU 上完成 671B 模型的全参数微调。实测数据（训练数据约100k，上下文32k）：
结论非常清晰：ZeRO-3 Offload 是唯一可行的方案——关闭 Offload 必然 OOM，降低序列并行度（sp=1）也会 OOM。推荐配置为 32 节点、序列并行度=4、batch_size=2。启动方式通过 pdsh 实现多节点并发。
训练产生的中间 checkpoint 以 PyTorch 分布式格式（.pth）存储，需要转换为 HuggingFace 格式才能被 vLLM、Transformers 等主流推理框架使用。单个 .pth checkpoint 约 7.4TB，转换过程对 CPU 内存需求极高，项目建议创建 8TB Swap 交换分区来避免 OOM。
转换后的权重可通过 vLLM 进行高性能推理。项目提供了完整的 Ray 集群部署脚本，支持多节点多 GPU 推理，关键参数：tensor-parallel-size=8、pipeline-parallel-size=4、max-model-len=32768、enable-reasoning、reasoning-parser=deepseek_r1。
| 类别 | 技术 |
|---|---|
| 训练框架 | PyTorch 2.6.0 + DeepSpeed 0.16.4 + xtuner（MMEngine） |
| 模型 | HuggingFace Transformers 4.43.0 + 自定义 MoE 实现 |
| 优化 | Flash Attention 2.7.4 + bf16 混合精度 + bitsandbytes |
| 并行 | DeepSpeed ZeRO-3 Offload + 序列并行 + 梯度累积 |
| 推理 | vLLM 高性能推理 + Ray 分布式集群 |
| 数据 | datasets 3.3.2 + HuggingFace Hub |
| 环境 | Streamlit + JupyterLab + TensorBoard |
门槛定位：极高。 这是一个面向有大规模 GPU 集群资源的研究团队的工程参考项目，不适合个人开发者。
| 维度 | 评估 |
|---|---|
| 硬件门槛 | 必须有 16-32 节点 × 8 GPU 的集群（≥128 张 H100/A100） |
| 网络要求 | 多节点高速互联（项目使用 NCCL，依赖 InfiniBand 或高速以太网） |
| 存储要求 | 每个 checkpoint 约 7.4TB，需要 100TB+ NVMe SSD |
| 技能要求 | 熟悉 DeepSpeed、分布式训练、NCCL 配置、Slurm/pdsh 作业调度 |
| 软件要求 | Miniconda + Python 环境 + 完整 CUDA/cuDNN 驱动 |
对于没有集群资源的开发者，更推荐使用 LoRA/QLoRA 等参数高效微调方法。
1. 部署门槛极高，普通团队无法复现。 项目 README 坦言"实验结论仅供参考"，800+ Stars 更多代表参考价值而非开箱即用的可用性。
2. moe_implementation='shard' 的实现细节未完全公开。 有经验的工程师可能需要深入 modeling_deepseek.py 才能理解 MoE 专家分片的逻辑。
3. 数据格式说明略显简略。 关于数据量、数据质量要求、清洗流程等实践经验的分享较少。
4. 权重转换的 CPU 内存需求存在隐患。 8TB Swap 的要求在生产环境中实现成本不低，且未提供更优雅的分布式转换方案。
ScienceOne-AI/DeepSeek-671B-SFT-Guide 的出现，代表了大模型微调领域的几个重要趋势：
全参数微调正在走向工程化：曾经只有少数大厂才能完成的 671B 全参数微调，如今有了可参考的开源工程流程，降低了研究门槛。
MoE 训练工程是下一个主战场：随着 Qwen、GLM、DeepSeek 等相继开源 MoE 模型，如何高效训练和部署 MoE 模型成为行业焦点，项目提供了有价值的实践参考。
DeepSpeed ZeRO-3 Offload 的成熟：实测数据证明 ZeRO-3 + Offload 可以在有限硬件下完成超大模型训练，这对整个 LLM 训练基础设施生态具有参考意义。
开源社区对"超级模型"工程难题的集体攻关：800+ Stars 说明大量团队正在或计划进行类似尝试，社区对这类工程参考有强烈需求。
总体而言，这是一个工程价值极高、门槛极高的精品项目，适合有集群资源且需要深度定制 DeepSeek-V3/R1 的研究团队参考。对于个人开发者，它更像是一扇了解超大规模 LLM 训练工程的窗口。