MoE 模型里，专家路由会带来 稀疏 all-to-all 通信（dispatch / combine）。这类通信如果和前后计算 串行，GPU 会在等网络上空转。
DBO 的目标：在 DP + EP（数据并行 + 专家并行） 部署下，把 MoE 层的 通信与周围计算重叠（overlap），提高设备利用率、降低端到端延迟。文档明确写：这套机制 目前只面向 DP+EP。

## **怎么做到重叠**

1.在 model runner 里把当前 batch 切成两个 microbatch（ubatch / µ-batch）
2.起两个 CPU worker 线程，各跑一半 batch 的前向
3.在 FusedMoEModularKernel 里设置 yield 点（dbo_yield）：
     线程 A 跑到 yield → 挂起
     唤醒线程 B 继续跑 → 再到 yield → 再切回 A
     形成 ping-pong，让 一边在做计算时，另一边可以在等/跑通信（配合 dbo_register_recv_hook / dbo_maybe_run_recv_hook 等钩子）

## **源码解读**

源码位置：https://github.com/vllm-project/vllm/blob/v0.17.0/vllm/v1/worker/gpu_ubatch_wrapper.py 、https://github.com/vllm-project/vllm/blob/v0.17.0/vllm/v1/worker/ubatching.py 
gpu_model_runner.py 179–184 行：引入 UBatchSlices、maybe_create_ubatch_slices、split_attn_metadata 等，供 scheduler 输出的本步 batch 被切成多段，并把 attention 元数据按段拆开。
不开 ubatch 时，每层 attention 元数据是一个 dict；开 ubatch 时，变成 按 microbatch 索引的 list，和 ubatch_slices 一一对应。

gpu_ubatch_wrapper.py 第 356 行附近：_make_ubatch_metadata 对每个 ubatch_slice 已经建好了 forward context 和 UBatchContext（ubatch_ctxs[i]）。356 行是在把 当前 microbatch 对应的输入张量（input_ids、positions、inputs_embeds、intermediate_tensors）按 token_slice 切出来后，封装成 UbatchMetadata
每个 microbatch 一份 UbatchMetadata，里面既有 该段的 tensor 视图，也有 UBatchContext（用于多流、barrier、与 runnable 的协作）。后面 UBatchWrapper.__call__ 里若 forward_context.ubatch_slices 非空，就会走 分 microbatch 执行 / CUDA graph 等路径，而不是整批一次 runnable(*args, **kwargs)。

## **两个 microbatch 之间是怎么「切换」的？**

靠模型里显式调用的 DBO 原语 + 两个 Python 线程之间的握手。
1.执行模型：UBatchWrapper._run_ubatches 会为每个 microbatch 起一个 threading.Thread，每个线程在自己的 UBatchContext 里跑同一份 model(...)（输入是已按 token_slice 切好的张量）。主线程在 barrier 上对齐后，通过 ubatch_metadata[0].context.cpu_wait_event.set() 启动这套握手。
2.线程间切换：UBatchContext 里为每个 microbatch 配了一对 threading.Event：cpu_wait_event 属于自己，cpu_signal_event 指向下一个 microbatch 的 cpu_wait_event（环形）。dbo_yield / yield_and_switch_* 最终会走到 _cpu_yield()：先 cpu_signal_event.set() 唤醒下一个线程，再在自己这边 cpu_wait_event.wait() 睡下去。这样同一时刻只有一个 DBO 相关线程在跑 forward 里的这段逻辑（代码里也写了要保证单线程）。
3.和 CUDA 的配合：除了 CPU 事件，还有 torch.cuda.Stream 上的 torch.Event：gpu_compute_done_event / gpu_comm_done_event 在对应 stream 上 record，在另一条 stream 上 wait_event，用来保证 comm 与 compute 的顺序（例如 switch_to_comm_sync 会先 record compute 完成，再切到 comm stream 并 wait）。
所以「切换」= 在两条 stream 之间换当前 stream + 用 GPU event 定序 + 用两个线程 + CPU event 做协作式让出（yield）。

## **使用了哪些cuda机制？**

Stream：全局上每个 UBatchWrapper 有 comm_stream 和 compute_stream 各一条（在 make_ubatch_contexts 里传给每个 UBatchContext，大家共用这两条），通过 torch.cuda.set_stream 和 dbo_switch_to_comm / dbo_switch_to_compute 等切换当前 stream。
Event：用 torch.Event 在两条 stream 之间建立 happens-before。
协作式多 microbatch：用 threading.Barrier + threading.Event 让两个（或多个）线程轮流推进，并在模型代码里通过 dbo_yield* 主动让出。
因此：重叠主要靠多 stream + GPU event；microbatch 之间的推进/互斥主要靠同进程多线程 + CPU event（以及 barrier 对齐），不是单靠 CUDA 自动把两个 microbatch 并行跑满。

MoE 模型里，专家路由会带来 稀疏 all-to-all 通信（dispatch / combine）。这类通信如果和前后计算 串行，GPU 会在等网络上空转。DBO 的目标：在 DP + EP（数据并行 + 专家并行） 部署下，把 MoE 层的 通信与周围计算重叠（overlap），提高设备利用率、降低端到端延迟。文档明确写：这套机制 目前只面向 DP+EP。

Dual Batch Overlap

从源码角度理解vLLM的Dual Batch Overlap机制

AI Infra工程师

人工智能

DBO技术通过将MoE模型batch切分为microbatch，利用多线程和CUDA流实现计算与通信重叠。核心机制包括：1) 双线程交替执行microbatch；2) 通过yield点实现线程切换；3) CUDA事件确保计算与通信顺序。该方案有效提升GPU利用率，降低端到端延迟，专为DP+EP并行部署设计。

路由

Python

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Dual Batch Overlap-腾讯云开发者社区-腾讯云

Dual Batch Overlap

Dual Batch Overlap

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐