链载Ai

标题: DeepSeek-V3.2 128K 推理秒开?百度百舸开源 CP 上下文并行方案 [打印本页]

作者: 链载Ai    时间: 5 天前
标题: DeepSeek-V3.2 128K 推理秒开?百度百舸开源 CP 上下文并行方案

随着大语言模型(LLM)长上下文推理需求飙升至 128K Tokens,首字延迟(TTFT)和显存压力已成为制约工业化落地的核心瓶颈。在处理数万字的法律合同或长篇技术手册时,过高的 TTFT 往往让用户面临漫长的等待。

2025 年 12 月 23 日,SGLang 社区官方宣布:百度百舸 AIAK 团队为 DeepSeek V3.2 开发的上下文并行(Context Parallelism, CP)方案已正式合入 SGLang 主分支。实测数据显示,该方案在 32K 序列长度下实现了高达 80% 的 TTFT 降幅,成功将长文本推理推向秒级响应时代。

开源代码地址:

图片

1. DSA 架构的挑战与并行策略的进化

在超长上下文应用场景中,DeepSeek V3.2 引入了 DSA (DeepSeek Sparse Attention) 架构。这一架构旨在通过算法创新降低计算复杂度,但在工程落地中,传统的并行策略遇到了冲突。

传统策略:TP + SP 加速长序列的原理

在 DeepSeek V3.2 出现之前,张量并行(TP)与序列并行(SP) 的组合是加速长文本推理的行业标准方案:

DSA 的核心机制:打破O(L^2)限制

传统注意力机制的计算量随序列长度平方级增长(O(L^2))。在 128K 级别的超长序列场景下,这种二次方的增长使得推理时间过长。DeepSeek V3.2 通过 DSA 架构中的 Indexer(索引器) 机制打破了这一限制:

DSA 部署面临的工程难题

尽管有了 Indexer 的稀疏化优化,单张 GPU 在面对 128K 序列时仍不堪重负:

因此,Context Parallelism (CP) 成为破解这一难题的关键:它避开了对H轴的切分,转而沿序列长度L维度进行任务分摊。

2. CP 核心原理:计算分摊与负载均衡

百度百舸设计的 CP 方案通过切分输入数据,从根本上分摊了每张 GPU 的计算与显存压力。

计算分摊与 TTFT 缩减

CP 策略将输入序列沿着L维度切分成N份(N为并行度/CP 大小),让多张卡共同协作处理一个请求。如架构图所示,通过cp_split_tokens模块,每个 Rank 只接收1/N的 Query 片段。

这直接将 QKV 投影计算量和 Indexer 的O(L^2)筛选负荷分摊给N张卡,将单卡计算量降至O(L^2/P)级别,实现了近线性的 TTFT 缩减

2N块重排负载均衡

由于因果注意力机制的特性,序列不同位置的 Token 计算量并不均等。为解决此问题,方案引入了负载均衡序列切分(Load-balanced sequence splitting):

3. 深度解析:高效混合并行流水线

该方案不仅是简单的切分,而是一套与 DeepSeek 特色架构(如 MLA、MoE)深度融合的精密流水线。

根据架构图,数据在系统中的流动遵循以下高效路径:

4. 算法与工程的深度协同,共筑 AI Infra 基石

DeepSeek V3.2 的 DSA 架构是算法效率的创新探索,而 CP 方案则是其在长文本场景下必不可少的 AI Infra 协同组件。DSA 通过动态稀疏机制降低了整体计算量,CP 使多卡能协同、均衡地分摊显存与计算负载,从而实现长文本的 TTFT 显著降低。
目前,该 CP 方案已经在百度百舸 AI 计算平台落地,并支持了百度千帆大模型平台的 DeepSeek V3.2 高性能长文本推理服务。
百度百舸正持续将经生产验证的方案开源至 SGLang 社区。我们期待在算法创新与系统工程深度协同的交汇点上,与全球开发者共筑 AI Infra 基石。







欢迎光临 链载Ai (https://www.lianzai.com/) Powered by Discuz! X3.5