大模型推理动态批处理调度深度调研报告

调研主题： 大模型推理动态批处理调度 所属域： 大模型框架 调研日期： 2026-03-12 版本： 1.0

目录

1. 第一部分：概念剖析
2. 第二部分：行业情报
3. 第三部分：方案对比
4. 第四部分：精华整合
5. 参考资料

第一部分：概念剖析

1. 定义澄清

通行定义

大模型推理动态批处理调度（Dynamic Batching Scheduling for LLM Inference）是指在大型语言模型推理服务中，根据实时请求到达模式、模型计算特性和系统资源状态，动态地将多个推理请求组合成批次（batch）进行并行处理，并通过智能调度算法优化请求执行顺序和资源分配的技术体系。

其核心目标是在保证服务质量（延迟 SLA）的前提下，最大化 GPU 利用率和系统吞吐量，降低单位 token 的推理成本。

常见误解

边界辨析

2. 核心架构

┌──────────────────────────────────────────────────────────────────────┐
│                    大模型推理动态批处理调度系统                        │
├──────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  ┌─────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────┐   │
│  │ 请求接入 │ →  │  调度决策层  │ →  │  执行引擎层  │ →  │ 输出生成 │   │
│  │ Request │    │  Scheduler  │    │   Executor  │    │ Output  │   │
│  │  Queue  │    │   Manager   │    │   Engine    │    │  Stream │   │
│  └─────────┘    └──────┬──────┘    └──────┬──────┘    └─────────┘   │
│         │               │                   │                        │
│         ▼               ▼                   ▼                        │
│  ┌─────────────────────────────────────────────────────────────┐    │
│  │                      KV Cache 管理层                          │    │
│  │  ┌───────────┐  ┌───────────┐  ┌───────────┐  ┌───────────┐ │    │
│  │  │ Paged     │  │ Prefix    │  │  Eviction │  │  Swapping │ │    │
│  │  │ Attention │  │ Caching   │  │  Policy   │  │  Manager  │ │    │
│  │  └───────────┘  └───────────┘  └───────────┘  └───────────┘ │    │
│  └─────────────────────────────────────────────────────────────┘    │
│         │               │                   │                        │
│         ▼               ▼                   ▼                        │
│  ┌─────────────────────────────────────────────────────────────┐    │
│  │                      资源监控层                              │    │
│  │  ┌───────────┐  ┌───────────┐  ┌───────────┐                │    │
│  │  │ GPU       │  │ Memory    │  │  Load     │                │    │
│  │  │ Util      │  │ Usage     │  │  Predictor│                │    │
│  │  └───────────┘  └───────────┘  └───────────┘                │    │
│  └─────────────────────────────────────────────────────────────┘    │
│                                                                      │
└──────────────────────────────────────────────────────────────────────┘

组件职责说明：

3. 数学形式化

公式 1：动态批处理延迟模型

其中 $b$ 为 batch size，$T_{\text{queue}}$ 为等待批处理形成的排队时间，$T_{\text{schedule}}$ 为调度开销，$T_{\text{prefill}}(b)$ 为 prefill 阶段计算时间（随 batch size 线性增长）。

解释： 首 token 延迟由排队等待、调度决策和预填充计算三部分组成，batch size 越大，prefill 时间越长但单位请求的调度成本越低。

公式 2：吞吐量优化目标

其中 $\bar{L}$ 为平均序列长度，$T_{\text{decode}}$ 为单 token 解码时间。

解释： 吞吐量优化的目标是在预填充时间和解码时间之间找到平衡，使得单位时间内生成的 token 总数最大化。

公式 3：KV Cache 显存约束

其中 $L_i$ 为第 $i$ 个请求的序列长度，$H$ 为注意力头数，$D$ 为每头维度，$\text{Memory}_{\text{available}}$ 为可用显存。

解释： KV Cache 显存占用是所有请求序列长度的线性函数，这限制了最大 batch size，PagedAttention 通过分页管理缓解此问题。

公式 4：调度收益函数

其中 $S$ 为候选请求集合，$\text{Priority}(r)$ 为请求优先级，$\text{Urgency}(r, t)$ 为紧急度函数，$\lambda$ 为公平性权重。

解释： 调度决策通过最大化收益函数来平衡优先级、紧急度和公平性，避免低优先级请求饿死。

4. 实现逻辑

class DynamicBatchScheduler:
    """
    动态批处理调度器核心实现
    体现 LLM 推理调度的关键抽象和算法逻辑
    """

    def __init__(self, config):
        # 请求管理组件：维护等待队列和运行中请求
        self.request_queue = PriorityQueue()  # 按优先级/到达时间排序
        self.running_requests = {}  # {request_id: RequestState}

        # KV Cache 管理组件：显存分配和回收
        self.kv_cache_manager = PagedKVCacheManager(
            total_blocks=config.kv_cache_blocks,
            block_size=config.block_size
        )

        # 调度策略组件：决定何时触发批处理
        self.scheduling_policy = AdaptiveSchedulingPolicy(
            max_batch_size=config.max_batch_size,
            latency_budget=config.latency_sla
        )

        # 执行引擎：实际模型推理
        self.executor = ModelExecutor(
            model=config.model_path,
            tensor_parallel_size=config.tp_size
        )

        # 监控组件：实时指标收集
        self.metrics = MetricsCollector()

    def core_operation(self, incoming_requests):
        """
        核心调度循环，体现动态批处理的关键逻辑
        """
        # 步骤 1: 将新请求加入等待队列
        for req in incoming_requests:
            self.request_queue.push(req)
            self.metrics.record_request_arrival()

        # 步骤 2: 检查是否有请求完成，释放资源
        completed = self.executor.poll_completed()
        for req_id in completed:
            self._release_request_resources(req_id)

        # 步骤 3: 调度决策 - 决定是否触发新一轮批处理
        if self.scheduling_policy.should_schedule(
            queue_size=len(self.request_queue),
            gpu_util=self.metrics.get_gpu_utilization(),
            latency_pressure=self.metrics.get_p99_latency_pressure()
        ):
            # 步骤 4: 选择批次中的请求
            batch_requests = self._select_batch_requests()

            # 步骤 5: 分配 KV Cache 资源
            allocation = self.kv_cache_manager.allocate(batch_requests)

            if allocation.success:
                # 步骤 6: 执行模型推理
                outputs = self.executor.execute_batch(
                    requests=batch_requests,
                    kv_blocks=allocation.blocks
                )

                # 步骤 7: 处理输出并更新状态
                self._process_outputs(outputs)

        return self._generate_responses()

    def _select_batch_requests(self):
        """
        批次选择策略：平衡吞吐和延迟
        """
        selected = []
        total_seqlen = 0

        # 优先处理高优先级和长等待请求
        while not self.request_queue.is_empty():
            req = self.request_queue.peek()

            # 检查显存约束
            if total_seqlen + req.expected_seqlen > self.kv_cache_manager.max_capacity:
                break

            # 检查 batch size 约束
            if len(selected) >= self.scheduling_policy.max_batch_size:
                break

            # 加入批次
            selected.append(self.request_queue.pop())
            total_seqlen += req.expected_seqlen

        return selected

    def _release_request_resources(self, request_id):
        """
        请求完成后的资源回收
        """
        if request_id in self.running_requests:
            req_state = self.running_requests.pop(request_id)
            # 释放 KV Cache 块
            self.kv_cache_manager.free(req_state.kv_blocks)
            # 更新指标
            self.metrics.record_request_completion(req_state)


class ContinuousBatchingExecutor:
    """
    Continuous Batching 执行器
    支持在迭代级别动态加入/退出请求
    """

    def execute_iteration(self, active_requests):
        """
        执行单个解码迭代
        关键特性：每个迭代后检查请求完成状态，动态调整批次
        """
        # 收集所有活跃请求的当前 token
        input_tokens = [req.get_current_token() for req in active_requests]

        # 执行单步前向传播
        logits = self.model.forward(input_tokens)

        # 采样生成下一个 token
        next_tokens = self.sampler.sample(logits)

        # 更新请求状态，移除已完成的请求
        still_active = []
        for req, next_token in zip(active_requests, next_tokens):
            req.append_token(next_token)
            if not req.is_completed():
                still_active.append(req)
            else:
                self.notify_completion(req)

        return still_active, next_tokens

5. 性能指标

6. 扩展性与安全性

水平扩展

垂直扩展

安全考量

第二部分：行业情报

1. GitHub 热门项目（17 个）

数据来源：GitHub 公开数据，截至 2026-03-12

2. 关键论文（12 篇）

3. 系统化技术博客（10 篇）

4. 技术演进时间线

2020 ─┬─ GPT-3 发布，静态批处理成为标准做法
      │
2021 ─┼─ NVIDIA Triton 引入动态批处理支持
      │
2022 ─┼─ HuggingFace TGI 项目启动，Rust 重写推理服务
      │
2023 ─┼─ Orca (Microsoft) 提出 Continuous Batching 概念
      │  ├─ vLLM 发布 PagedAttention，显存管理革命
      │  └─ DeepSpeed-MII 推出 Zero-Inference 优化
      │
2024 ─┼─ SGLang 提出 RadixAttention 前缀缓存
      │  ├─ DistServe 实现 Prefill/Decoding 解耦
      │  ├─ Mooncake 提出 KVCache 中心化架构
      │  └─ TensorRT-LLM 正式开源，NVIDIA 全面投入
      │
2025 ─┼─ INFERMAX 自适应批处理预测
      │  ├─ Llumnix 多实例动态调度
      │  └─ DeepSeek-V3 MoE 推理优化
      │
2026 ─┴─ 当前状态：动态批处理成为标配，研究重点转向多机协同、长上下文优化、MoE 调度

第三部分：方案对比

1. 历史发展时间线

2020 ─┬─ 静态批处理 → 简单凑批，延迟不可控，GPU 利用率低
      │
2021 ─┼─ 动态批处理 v1 → 请求级调度，支持超时触发，延迟有所改善
      │
2022 ─┼─ 动态批处理 v2 → 加入优先级、支持流式输出，生产可用性提升
      │
2023 ─┼─ Continuous Batching → 迭代级调度里程碑，吞吐提升 2-4 倍
      │
2024 ─┼─ PagedAttention → KV Cache 分页管理，显存利用率提升 4 倍
      │
2025 ─┼─ RadixAttention → 前缀缓存优化，重复查询场景吞吐再提升
      │
2026 ─┴─ 当前状态：智能调度成为核心竞争力，支持多目标优化和自适应预测

2. 六种方案横向对比

3. 技术细节对比

4. 选型建议

成本说明： 成本估算基于 2026 年云厂商 GPU 实例价格（A100 80GB 约 $1.5-2.5/小时），含基础运维和电力成本，未计入模型授权费用。

5. 选型决策流程

                    ┌─────────────────┐
                    │   评估需求规模   │
                    └────────┬────────┘
                             │
              ┌──────────────┼──────────────┐
              │              │              │
              ▼              ▼              ▼
       ┌──────────┐   ┌──────────┐   ┌──────────┐
       │ QPS<100  │   │ QPS 100- │   │ QPS>500  │
       │ 小规模   │   │ 500 中型  │   │ 大规模   │
       └────┬─────┘   └────┬─────┘   └────┬─────┘
            │              │              │
            ▼              ▼              ▼
       ┌──────────┐   ┌──────────┐   ┌──────────┐
       │   TGI    │   │   vLLM   │   │  vLLM +  │
       │ FastChat │   │ SGLang   │   │  Mooncake│
       └──────────┘   └──────────┘   └──────────┘

第四部分：精华整合

1. The One 公式

用一个"悖论式等式"概括动态批处理调度的核心本质：

解读： 最优的批处理调度是在迭代级并行（最大化吞吐）和分页显存管理（最大化容量）之间取得平衡，同时最小化调度决策本身带来的延迟开销。

2. 一句话解释

大模型推理动态批处理调度就像是一个"聪明的餐厅后厨"：不是等所有顾客点完菜再一起做饭（静态批处理），而是根据订单紧急程度和厨师空闲情况，灵活安排每道菜的烹饪顺序，让出餐速度最快同时保证每桌等待时间合理。

3. 核心架构图

┌─────────────────────────────────────────────────────────────┐
│                    动态批处理调度核心架构                     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   请求流 → ┌─────────┐ → ┌─────────────┐ → ┌─────────┐    │
│            │ 优先级  │   │ Continuous  │   │  KV     │    │
│            │  队列   │   │  Batching   │   │  Cache  │    │
│            └─────────┘   │  迭代调度   │   │  管理   │    │
│                 │        └─────────────┘   └─────────┘    │
│                 │               │                │         │
│                 ▼               ▼                ▼         │
│           等待时间<SLA     GPU 利用率>80%    显存碎片<10%   │
│                                                             │
│                            ▼                                │
│                   ┌─────────────────┐                       │
│                   │   流式输出生成   │                       │
│                   └─────────────────┘                       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

4. STAR 总结

5. 理解确认问题

问题： 为什么 Continuous Batching 相比请求级动态批处理能显著提升吞吐量，但在某些场景下反而会增加延迟？请从技术原理和调度行为角度分析。

参考答案：

Continuous Batching 的核心优势在于迭代级调度：它不是等整个请求完成后再更新批次，而是在每个解码迭代后检查哪些请求已完成、哪些新请求可以加入，从而保持 GPU 始终处于满载状态。相比请求级批处理（批次一旦开始执行就不能变更），这种方式避免了"快请求等慢请求"的问题，GPU 利用率显著提升。

但在以下场景会增加延迟：

1. 短文本场景：Continuous Batching 的调度开销（每轮迭代都要检查完成状态、更新批次）在短文本场景下占比更高，可能抵消并行收益。
2. 高优先级插队：如果高优先级请求需要快速响应，Continuous Batching 可能需要等待当前迭代完成才能处理，而请求级批处理可以立即触发新批次。
3. 显存压力：频繁的批次变更可能导致 KV Cache 分配/释放频繁，增加显存管理开销。

因此，Continuous Batching 最适合生成长文本、对吞吐敏感的场景；而对延迟极度敏感的场景可能需要更保守的调度策略。

参考资料

GitHub 项目

1. vLLM - https://github.com/vllm-project/vllm
2. SGLang - https://github.com/sgl-project/sglang
3. Text Generation Inference - https://github.com/huggingface/text-generation-inference
4. TensorRT-LLM - https://github.com/NVIDIA/TensorRT-LLM
5. LMDeploy - https://github.com/InternLM/lmdeploy

学术论文

1. Orca (OSDI 2023) - https://www.usenix.org/conference/osdi23/presentation/yu
2. vLLM (SOSP 2023) - https://arxiv.org/abs/2309.06180
3. DistServe (OSDI 2024) - https://www.usenix.org/conference/osdi24/presentation/zhong
4. Mooncake (arXiv 2024) - https://arxiv.org/abs/2407.00079
5. RadixAttention (arXiv 2024) - https://arxiv.org/abs/2406.02666

技术博客

1. vLLM Blog - https://blog.vllm.ai
2. Eugene Yan - https://eugeneyan.com
3. Chip Huyen - https://chip-c.com
4. NVIDIA Developer Blog - https://developer.nvidia.com
5. 美团技术团队 - https://tech.meituan.com

报告完成时间： 2026-03-12 报告字数： 约 8500 字 数据新鲜度： 所有情报数据基于 2024-2026 年最新信息