围绕大型语言模型（LLM）的工程学科，已从早期的零散实验脚本拼凑，演变为一套严谨、分层的软件技术栈。时至 2025 年末，这一生态系统已形成了清晰的三段式生命周期：预训练（Pre-training）、后训练（Post-training/Fine-tuning） 和 推理（Inference/Deployment）。本文将对主导各个阶段的框架进行详尽的专家级剖析。我们将深入探讨从 NVIDIA 庞大的 Megatron-LM 到敏捷通用的 ms-swift 等工具背后的架构决策、硬件优化及技术权衡。
第一部分：预训练框架 (Pre-training Frameworks)
预训练是 LLM 生命周期的“热力学巅峰”。这一阶段的特征是巨大的算力需求，其核心工程目标是在数千张 GPU 上最大化模型 FLOPs 利用率（MFU）。此类框架负责管理复杂的分布式计算编排，以支持像 Qwen 3 和 DeepSeek-V3 这样的大规模 MoE（混合专家）架构。
1.1 张量并行巨擘：NVIDIA Megatron-LM
代码仓库： https://github.com/NVIDIA/Megatron-LM
Megatron-LM 是当前最大规模模型的基石参考实现。由 NVIDIA 开发，它与其说是一个用户友好的库，不如说是极端规模计算的蓝图。其架构哲学以 张量并行（Tensor Parallelism, TP） 为核心，将单个矩阵乘法拆分到多个 GPU 上，以最大限度地减少节点间的通信延迟。
规模化的架构设计
2025 年的 Megatron-LM 已超越了简单的 TP。Megatron Core (MCore) 的引入代表了一次重大的代码重构，它将分布式原语与模型定义解耦。这种转变是为适应 Qwen 3 等稠密-MoE 混合架构日益增长的复杂性而必须进行的。另一项关键创新是 Context Parallelism (CP)。随着上下文窗口扩展至 1M+ Token（受长文本 Qwen 变体驱动），标准的序列并行（SP）已显捉襟见肘。CP 拆分了注意力计算本身，允许 KV Cache 和注意力分数在 GPU 间分布，避免了灾难性的通信开销。
硬件共生：Transformer Engine
Transformer Engine (TE) 进一步巩固了 Megatron-LM 的统治地位。TE 在 NVIDIA Hopper 和 Blackwell 架构上实现了原生的 FP8（8位浮点）训练。通过在 FP8 和 BF16 之间动态转换张量，TE 使 Megatron-LM 的矩阵乘法吞吐量得以翻倍。
1.2 显存优化大师：Microsoft DeepSpeed
代码仓库： https://github.com/microsoft/DeepSpeed
如果说 Megatron-LM 专注于计算并行化，那么微软的 DeepSpeed 则致力于攻克 显存墙（Memory Wall）。其核心贡献 Zero Redundancy Optimizer (ZeRO) 将优化器状态、梯度和参数切分到所有可用 GPU 上。
MoE 时代：DeepSpeed-MoE
随着 Qwen 3 和 DeepSeek-V3 采用重型混合专家架构，标准的数据并行已显得效率低下。2025 年的更新重点在于 DeepSpeed-MoE，它优化了将 Token 路由至对应专家所需的 “all-to-all” 通信原语，显著降低了专家并行的开销。
1.3 极简主义挑战者：Hugging Face Nanotron
代码仓库： https://github.com/huggingface/nanotron
随着 Megatron-LM 等框架变得日益僵化，Nanotron 为需要快速迭代架构的研究人员应运而生。Nanotron 的哲学是“极简主义 3D 并行”。它通过清晰、Pythonic 的 API 暴露分布式原语（TP, PP, DP），避免了老旧框架的“配置地狱（config hell）”。
1.4 原生进化：PyTorch FSDP2 & Torchtitan
代码仓库： https://github.com/pytorch/torchtitan
PyTorch 团队通过 Fully Sharded Data Parallel 2 (FSDP2) 缩小了差距。与初代 FSDP 不同，FSDP2 在张量级别（通过 DTensor）管理分片，允许对内存布局进行细粒度控制。Torchtitan 是其旗舰实现，证明了原生 PyTorch 结构利用 异步检查点（Async Checkpointing） 也能扩展至数千张 GPU。
预训练技术对比分析
| 特性集 | Megatron-LM | DeepSpeed | Nanotron | PyTorch FSDP2 |
|---|---|---|---|---|
| 核心并行策略 | 张量 (TP) + 流水线 (PP) | 数据 (ZeRO) + 流水线 | 3D (TP+PP+DP) | 分片数据 (类 ZeRO) |
| 状态管理 | 复制 (TP) / 切分 (PP) | 分区 (ZeRO 1/2/3) | 混合模式 | 每参数分片 |
| MoE 支持 | 原生 (MCore) | DeepSpeed-MoE (优化版) | 基础支持 | 原生 (通过 DTensor) |
| 开发者体验 | 高复杂度 / 僵化 | 中等复杂度 | 高可魔改性 (Hackability) | 原生 / Pythonic |
| 最佳适用场景 | Qwen 3 / DeepSeek 预训练 | 异构集群 | 研究 / 原型开发 | 原生 PyTorch 用户 |
第二部分：后训练框架 (Post-Training Frameworks)
后训练（SFT 和偏好对齐）是将原始预测引擎转化为产品的过程。2025 年的格局由 参数高效微调（PEFT） 主导，且出现了向专门支持 Qwen 和 DeepSeek 架构工具大规模迁移的趋势。
2.1 Qwen 专精者：ms-swift (ModelScope)
代码仓库： https://github.com/modelscope/ms-swift
Swift 已迅速成为微调领域的“瑞士军刀”，特别是对于在 Qwen 和 DeepSeek 生态系统中工作的工程师而言。它由 ModelScope 团队开发，为 Qwen 3 中的最新架构特性（如 tie-embedding 问题、VLM 中的动态分辨率）提供了最稳健的支持。
“Tuners” 抽象层
Swift 引入了高级的 “Tuners” 抽象，超越了标准的 LoRA，支持 Res-Tuning（视觉语言）、NEFTune（噪声嵌入）和 LoRA+。Swift 的独特之处在于其“一键部署（Push-to-Deploy）”工作流，在 Swift 中微调的模型可以无缝导出到容器化的推理引擎中。
2.2 配置引擎：Axolotl
代码仓库： https://github.com/axolotl-ai-cloud/axolotl
Axolotl 仍然是生产级流水线的标杆。它作为一个统一的封装器，通过单个 YAML 配置文件屏蔽了训练的复杂性。
- 多样本打包 (Multipacking): Axolotl 对 Sample Packing 的实现对效率至关重要，它将序列拼接以确保 GPU 为每个 Token 位置计算有效梯度。
- 2025 更新: Axolotl 全面支持 FSDP 和 DeepSpeed Zero-3 后端，使得在消费级硬件上微调 70B+ 参数模型成为可能。
2.3 算子优化者：Unsloth
代码仓库： https://github.com/unslothai/unsloth
Unsloth 使用 手写的 Triton 算子（Kernels） 替换了标准的 PyTorch Transformer 层实现。它手动推导反向传播步骤，将显存占用最高降低了 60%。这使得在单张高端消费级 GPU 上微调 Qwen-3-72B（量化版）成为现实，是本地微调的不二之选。
2.4 统一工作流：LLaMA-Factory
代码仓库： https://github.com/hiyouga/LLaMA-Factory
LLaMA-Factory 是一个支持超过 100 种模型的通用框架。它以 WebUI (LLaMA Board) 闻名，可实时可视化训练指标。它实现了 GaLore (Gradient Low-Rank Projection) 和 DoRA 等高级适配器，并将 SFT、DPO 和 PPO 统一到了一个可视化流水线中。
微调技术对比分析
| 框架 | 架构模式 | 优化重心 | 最佳适用场景 | 交互接口 |
|---|---|---|---|---|
| ms-swift | 原生封装 | Qwen/DeepSeek 生态 | 多模态 / 中文模型 | CLI / Python / UI |
| Axolotl | 封装器 (HF/Peft) | 吞吐量 (Multipack) | 生产级流水线 | YAML 配置 |
| Unsloth | 算子替换 | 显存 / 速度 | 消费级硬件 | Python 库 |
| LLaMA-Factory | 封装器 (统一) | 算法多样性 | 实验 / UI 操作 | WebUI / CLI |
| HuggingFace TRL | 原生库 | 对齐 (DPO/ORPO) | 研究 / 自定义 RLHF | Python 库 |
第三部分：推理与部署框架 (Inference & Deployment Frameworks)
推理阶段引入了一组新的约束：首字延迟（TTFT） 和 Token 间延迟（ITL）。2025 年的技术格局致力于对抗长上下文交互中 KV Cache 造成的“显存墙”。
3.1 吞吐量标杆：vLLM
代码仓库： https://github.com/vllm-project/vllm
vLLM 凭借解决 KV Cache 碎片的 PagedAttention 定义了现代服务框架。2025 特性： vLLM 增加了对 FP8 KV Caching 的稳健支持，这对于在有限硬件上运行 Qwen 3-72B 至关重要。它还支持 投机解码（Speculative Decoding） 和 分块预填充（Chunked Prefill），确保处理长系统提示词（System Prompt）时不会阻塞其他请求的生成。
3.2 结构化专才：SGLang
代码仓库： https://github.com/sgl-project/sglang
SGLang (Structured Generation Language) 专为 DeepSeek-V3 常见的复杂 Agent 工作流进行了优化。它使用 基数树（Radix Tree / RadixAttention） 来管理 KV Cache。
- 机制: 当 Agent 思考、规划和行动时，它会重用历史记录。SGLang 将这些前缀缓存在树结构中。
- 性能: 对于“推理-回答”循环，SGLang 的吞吐量可达 vLLM 的 5 倍。
3.3 企业级编译器：NVIDIA TensorRT-LLM
代码仓库： https://github.com/NVIDIA/TensorRT-LLM
TensorRT-LLM 本质是一个 编译器。它将模型编译为针对特定 GPU（如 H100）优化的二进制引擎。它激进地进行层融合（Layer Fusion），是 Hopper GPU 上 FP8 推理 的黄金标准。然而，它需要静态编译，意味着无法动态更换适配器。
3.4 4-Bit 急速先锋：LMDeploy
代码仓库： https://github.com/InternLM/lmdeploy
LMDeploy 拥有 TurboMind 引擎。其独特之处在于对 W4A16（4位权重，16位激活）推理的极致优化。它针对中文模型生态（Qwen, DeepSeek, InternLM）进行了高度优化，在单用户延迟场景下通常优于 vLLM。
3.5 边缘端普及者：llama.cpp
代码仓库： https://github.com/ggerganov/llama.cpp
当数据中心运行 vLLM 时，llama.cpp 凭借一己之力实现了高性能推理在消费级硬件（特别是 Apple Silicon）上的普及。其“杀手级应用”是 GGUF 文件格式，支持高效的内存映射和异构计算，允许将层无缝切分到 CPU 和 GPU 之间。“K-Quant” 优势： llama.cpp 利用复杂的量化方法（如 Q4_K_M），在压缩模型的同时保留关键权重矩阵的高精度。这使得在 MacBook Pro 上以可接受的速度本地运行 DeepSeek-V3 或 Qwen-3-Instruct 等大模型成为可能，驱动了 Ollama 和 LM Studio 等整个本地 AI 工具生态。
推理技术对比分析
| 引擎 | 核心机制 | 缓存策略 | 最佳用例 | 量化重心 |
|---|---|---|---|---|
| vLLM | PagedAttention | 块表 (Block Table) | 通用服务 / 高 QPS | AWQ / GPTQ / FP8 |
| SGLang | RadixAttention | 基数树 (LRU) | Agents / 推理循环 | AWQ / FP8 |
| TensorRT-LLM | 编译器 / 融合 | 静态分配 | 企业级 / H100 集群 | FP8 / INT8 |
| LMDeploy | TurboMind | 持久化 Batch | Qwen 4-bit 服务 | AWQ / W4A16 |
| llama.cpp | GGUF / Metal | 线性 / Mmap | 边缘端 / CPU / Apple Silicon | GGUF (K-Quants) |
第四部分：技术栈的未来
2025 年末的趋势是边界的消融。我们看到训练框架增加了推理能力（例如 DeepSpeed-MII），而推理引擎也在增加训练功能。当前业界追逐的“圣杯”是 端到端 FP8 流水线。目标是从 Qwen 3 的第一步预训练到 vLLM 中的最后一次 Token 生成，让模型始终保持在 FP8 格式，从而统一技术栈并大幅降低智能成本。对于 2026 年的工程师来说，选择是战略性的：
- 基石: Megatron-LM（追求规模）或 DeepSpeed（追求异构）。
- 微调: ms-swift（Qwen/多模态）或 Axolotl（生产配置）。
- 部署: vLLM（通用 API）或 SGLang（Agent/推理）。
2025 年末的 LLM 技术栈已超越了工具的“寒武纪大爆发”，进入了由架构专业化定义的整合阶段。在该领域的成功不再需要编写自定义的分布式训练循环，而是掌握这些成熟框架的编排。制胜的工程策略在于针对特定的瓶颈约束选择正确的工具：用 Megatron-Core 克服预训练的算力瓶颈，用 ms-swift/Axolotl 驾驭后训练的算法细节，用 vLLM/SGLang 解决推理的显存带宽瓶颈。随着 Qwen 3 和 DeepSeek-V3 不断推高上下文长度和逻辑能力的边界，这些层级之间的摩擦将逐渐减少，最终演化为一个由编译器驱动的、统一的人工智能操作系统。