上下文并行（Context Parallelism, CP）

3 秒看懂

一句话： 把一整条超长文本序列切成多段，分给多张 GPU 各算一块，再通过通信把注意力计算”拼”回来——让单机装不下的超长上下文，在集群上跑起来。

3 分钟产业解释

为什么需要它？

大模型训练/推理面临一个根本矛盾：序列越长，注意力计算量呈 O(n²) 增长，显存占用也线性增长。当上下文窗口从 4K 扩展到 128K、甚至百万级 token 时，单张 GPU 无论算力还是显存都扛不住。

传统的三维并行——张量并行（TP）、流水线并行（PP）、数据并行（DP）——分别切模型的宽度、深度和数据样本维度，但没有切”序列”这个维度。上下文并行（CP）就是补上这第四刀。

核心直觉

把一句话比作一根长面条：

• TP 是把面条竖着切薄（切模型头/层内维度）
• PP 是把面条横着一段段切（切模型层）
• DP 是给不同厨师各发一根面条（不同样本）
• CP 是把同一根面条切成 N 段，N 个厨师各煮一段，最后把汤底味道对齐（交换注意力所需的 K/V 信息）

谁在用？

• Meta FAIR：训练 Llama 3 系列长上下文版本时引入 Context Parallelism，是该术语的主要推动者
• NVIDIA：在 Megatron-Core 框架中集成了 CP 支持，与 TP/PP/DP 组合成四维并行
• Google DeepMind：TPU Pod 上的长序列训练方案包含类似的序列切分思路（具体实现细节未充分披露）
• DeepSpeed：提出 Ulysses 方案，属于 CP 的一种通信模式变体

15 分钟专家深入

基本机制

CP 的核心挑战在于：注意力计算天然需要所有 Q 与所有 K/V 的交互。你把序列切开了，每张卡只有一段 Q 和对应的 K/V，但要算完整注意力，就必须拿到其他卡上的 K/V（或等价信息）。

目前主流有两种通信拓扑来解决这个问题：

方案一：Ring Attention（环形注意力）

源自 Liu et al. 2023 的论文 Ring Attention with Blockwise Transformers for Near-Infinite Context。

原理示意（4 张 GPU 的环）：

GPU0 ──→ GPU1 ──→ GPU2 ──→ GPU3 ──→ GPU0
 (Q0,K0,V0)  (Q1,K1,V1)  (Q2,K2,V2)  (Q3,K3,V3)

每一步：
  - 每张 GPU 用本地 Q 与当前持有的 K/V 块算一个 partial attention
  - 然后把 K/V 块沿环发给下一张 GPU
  - 经过 N-1 步后，每张 GPU 都"见过了"所有 K/V 块

优点： 通信与计算可以流水线重叠——在算当前块注意力的同时，下一块 K/V 已经在路上。带宽需求是点对点（P2P），通信量随并行度线性增长。

缺点： 环上步数 = 并行度 - 1，延迟随 GPU 数线性增加；需要精细的调度来保证计算和通信的 overlap。

方案二：All-to-All（全交换）

DeepSpeed Ulysses 采用的方案，思路是：

步骤 1: All-to-All 通信，把各 GPU 上的 Q/K/V 从"按序列切分"重排为"按注意力头切分"
步骤 2: 每张 GPU 负责若干头的完整序列注意力（此时又回到了 TP 的计算模式）
步骤 3: All-to-All 通信，把结果重排回"按序列切分"

优点： 只需两步 All-to-All，延迟不随并行度线性增长（取决于集合通信拓扑）。

缺点： All-to-All 在大规模跨节点时通信开销可能较大；需要在单次通信中交换更多数据。

因果掩码的特殊处理

在自回归（causal）模型中，每个 token 只能看到它前面的 token。CP 切分后，处于序列前段的 GPU 完全不需要后面 GPU 的 K/V（因果掩码会把它们置零）。利用这个特性，实际通信量可以大幅减少——这是一种”掩码感知”的优化。

具体来说：如果将序列等分为 N 段，GPU i 只需要 GPU 0 到 GPU i 的 K/V（因果方向），因此：

• GPU 0 不需要任何远端 K/V
• GPU N-1 需要所有 GPU 的 K/V

这对 ring attention 的调度有显著优化空间——部分环步可以直接跳过或标记为零计算。

与其他并行维度的组合

CP 在实践中几乎从不单独使用，而是嵌入到四维并行中：

总 GPU 数 = TP × PP × DP × CP

典型配置示例（训练 70B 级长上下文模型）：
  TP=8（节点内 NVLink 带宽高）
  PP=2（跨节点流水线）
  DP=若干（数据并行组数）
  CP=若干（上下文并行组数）

CP 的通信模式主要是跨节点 P2P（ring）或 All-to-All，对互连带宽的要求低于 TP（TP 需要在前向/反向每层都做 AllReduce），但高于纯 DP。

技术原理

数学基础

给定输入序列长度 $S$，总注意力头数 $H$，head dimension $d$。

标准注意力： \text{Attn}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d}}\right) V

其中 Q, K, V \in \mathbb{R}^{S \times H \times d}。

CP 切分后（以 $N$ 张 GPU 为例）：

每张 GPU $i$ 持有：

• Q_i \in \mathbb{R}^{(S/N) \times H \times d}
• K_i \in \mathbb{R}^{(S/N) \times H \times d}
• V_i \in \mathbb{R}^{(S/N) \times H \times d}

要计算 Q_i 的完整注意力，需要与所有 K_j, V_j（j = 0, \ldots, N-1）交互：

\text{Attn}_i = \text{OnlineSoftmax}\left(\frac{Q_i [K_0; K_1; \ldots; K_{N-1}]^T}{\sqrt{d}}\right) [V_0; V_1; \ldots; V_{N-1}]

在线 Softmax（Online/Flash Softmax）

直接拼接所有 K/V 再算 softmax 需要把完整 S \times S 矩阵放在内存里，这正是我们要避免的。实际实现依赖 FlashAttention 的分块 softmax 技巧：

算法：Ring Attention + FlashAttention 分块计算

对每张 GPU i:
  初始化: O_i = 0, m_i = -inf, l_i = 0    # 输出、最大值、softmax 分母

  for j = 0 to N-1:    # 遍历环上的 K/V 块（含本地块）

    # 当前持有的 K/V 块为 K_j, V_j

    # 分块计算（内层 FlashAttention 分块循环，此处省略）
    S_ij = Q_i @ K_j^T / sqrt(d)           # (S/N) × (S/N)

    # 因果掩码：如果 j > i，mask 掉无因果关系的部分
    # （具体掩码形状取决于段的相对位置）

    m_ij = rowmax(S_ij)
    P_ij = exp(S_ij - m_ij)
    l_ij = rowsum(P_ij)

    # 在线合并
    m_new = max(m_i, m_ij)
    O_i = O_i * exp(m_i - m_new) + P_ij @ V_j * exp(m_ij - m_new)
    l_i = l_i * exp(m_i - m_new) + l_ij * exp(m_ij - m_new)
    m_i = m_new

    # 环通信：把 K_j, V_j 发给下一张 GPU，同时接收 K_{j+1}, V_{j+1}
    ring_send_recv(K_j, V_j)

  O_i = O_i / l_i    # 最终输出

关键点：

• 数值稳定：通过维护 running max（m_i）和 running sum（l_i）来实现在线 softmax 合并，避免溢出
• 显存友好：任意时刻只需持有一个 K/V 块，显存占用为 O(S/N) 而非 O(S)
• 通信-计算重叠：ring_send_recv 与 P_ij @ V_j 计算可以异步并行

通信量分析

注：以上为定性量级分析，具体通信字节数取决于实现细节（如是否压缩、是否 FP8 传输等）。

反向传播

CP 的反向传播需要对注意力计算求梯度。由于 softmax 的分块在线计算特性，反向时同样需要遍历环上的 K/V 块。这导致 CP 的反向通信量约为前向的 2-3 倍（需要传回梯度相关的 K/V 块，以及可能的重新计算）。

实践中常结合 梯度检查点（activation checkpointing）：前向时只保存少量中间状态，反向时重算部分注意力，以换回显存节省。

技术演进史

注：以上时间线基于公开论文/博客/会议演讲梳理，部分日期为近似。

技术路线对比

注：通信量为每层前向的量级估算，实际取决于实现配置。

上下游

上游依赖

硬件层：
  ├── 高带宽互连（NVLink/NVSwitch 节点内，InfiniBand/RoCE 跨节点）
  ├── 大容量 HBM（存放 K/V 缓存）
  └── 高算力 GPU（Tensor Core 加速矩阵运算）

算子层：
  ├── FlashAttention / FlashAttention-2/3（分块注意力核心算子）
  ├── NCCL（集合通信库，支持 P2P 和 All-to-All）
  └── CUDA Graph / Stream（异步通信-计算 overlap）

框架层：
  ├── Megatron-Core（NVIDIA 官方四维并行）
  ├── DeepSpeed（微软 Ulysses 方案）
  └── PyTorch FSDP2 / DTensor（分布式张量抽象）

下游应用

长上下文训练：
  ├── Llama 3 128K 上下文训练
  ├── 长文档理解 / 代码仓库级理解
  └── 多模态长序列（视频帧 + 文本）

长上下文推理：
  ├── 128K+ 上下文推理服务（vLLM 等推理框架考虑类似思路）
  └── KV Cache 分布式管理

科学计算：
  └── 超长序列 DNA/蛋白质序列建模

关键指标

注：以上量级为基于算法分析的估算，具体数值取决于模型规模、序列长度、硬件配置和实现优化程度。

供需与市场数据

供给侧

CP 的落地推动了以下硬件/软件需求：

需求侧

• 128K+ 上下文已成标配趋势：GPT-4 Turbo (128K)、Claude (200K)、Gemini (1M+)、Llama 3.1 (128K)
• 长上下文训练不是可选项而是必选项，CP 是实现手段之一
• 推理侧也在探索类似的序列切分（如 Prefill 阶段的 CP），以支持长上下文低延迟推理

市场数据

• 长上下文模型训练所需 GPU 集群规模通常在 [厂商未充分披露] 数千至数万卡级别
• CP 不直接创造独立市场，而是 “卖水人”逻辑——推动高速互连和大容量 HBM 的消耗量增长

注：具体训练集群规模和成本数据属于各厂商机密，上文为行业公开信息推断。

代表公司与资本映射

投资逻辑

核心链条

长上下文成为标配
    ↓
训练 128K+ 上下文需要 CP
    ↓
CP 需要：① 大量 GPU  ② 高速互连  ③ 大容量 HBM
    ↓
受益标的：NVDA（GPU+互连） > AVGO（网络） > HBM 三巨头 > 训练云厂商

边际变化判断

风险点

• 算法替代风险：线性注意力、状态空间模型（Mamba 等）如果在长上下文任务上追平 Transformer 性能，CP 需求可能下降
• 通信技术突破：如果芯片互连带宽大幅提升（如光学互连），CP 的通信瓶颈消失，其”推高硬件需求”的逻辑减弱
• 推理侧趋势：推理更多依赖 KV Cache 压缩/稀疏注意力，不一定用 CP，投资逻辑更偏训练侧

常见误读纠偏

误读 1：“Context Parallelism 就是 Megatron-LM 的 Sequence Parallelism”

纠偏： 这是最常见的混淆。两者不同：

Megatron-Core 中两者共存：SP 负责非注意力部分的序列维度优化，CP 负责注意力部分的序列切分。将二者混为一谈会导致对通信模式和并行策略的根本性误解。

误读 2：“CP 让任何模型都能无限扩展上下文长度”

纠偏： CP 只解决了注意力计算的算力和显存瓶颈。但长上下文还有其他卡点：

• 位置编码外推：RoPE 等位置编码在超出训练长度后性能衰退，这不是 CP 能解决的
• 注意力稀释：即使算力够了，模型在超长上下文中能否有效”注意到”远处信息，取决于架构和训练策略
• 通信延迟的硬约束：Ring Attention 的延迟随并行度线性增长，存在实际上限

误读 3：“Ring Attention 的通信开销一定小于 All-to-All 方案”

纠偏： 取决于并行度和互连拓扑。Ring 的累积通信量随环长线性增长，当 CP 并行度较大时，每张卡的通信累积量可能超过 All-to-All 的两步通信。特别是在高带宽全连接拓扑（如 NVSwitch 连接的节点内）下，All-to-All 的效率可能更优。方案选择是 “通信模式 × 互连拓扑 × 并行度” 的联合优化问题，没有绝对优劣。

学习路径

入门（1-2 小时）

1. 阅读 Vaswani et al. Attention Is All You Need 中注意力机制部分（理解 Q/K/V 和 O(n²) 问题）
2. 阅读 Tri Dao 的 FlashAttention 博客/论文简介（理解分块注意力和 IO-aware 计算）

进阶（3-5 小时）

3. 精读 Liu et al. Ring Attention with Blockwise Transformers for Near-Infinite Context（2023）—— CP 的理论基础
4. 阅读 DeepSpeed 团队关于 Ulysses 的博客文章和论文
5. 阅读 Megatron-Core 文档中关于 CP 的部分

深度（动手实践）

6. 在 NVIDIA Megatron-Core 代码中找到 CP 相关实现，理解 ContextParallel 和 SequenceParallel 的具体区别
7. 阅读 FlashAttention-2/3 源码中与 CP 兼容相关的改动
8. 模拟计算：给定模型大小、序列长度、GPU 数量，推算 CP 的通信量和预期 MFU

推荐资源

• 论文：Ring Attention (Liu et al., 2023)、FlashAttention (Dao et al., 2022/2023)
• 代码：NVIDIA/Megatron-LM（GitHub）、microsoft/DeepSpeed（GitHub）
• 博客：NVIDIA 技术博客关于 Llama 3 训练基础设施的文章、Meta 工程博客关于 Llama 长上下文训练的内容
• 演讲：GTC/Talks 中关于四维并行策略的 session

一句话总结

上下文并行（CP）是训练超长上下文大模型的第四个并行维度——切序列、换 K/V、拼注意力——它不改变模型架构，但让 Transformer 的注意力计算在集群上实现了序列维度的近线性扩展，是 128K+ 时代训练基础设施的关键拼图。

延伸阅读与来源

注：本页技术细节基于公开论文、框架文档和行业公开信息整理。涉及的具体配置参数和效率数据，凡无明确来源标注的，均为基于算法分析的估算或定性描述，不代表任何厂商的实际实现规格。