Chunked Prefill 技术深度调研

调研主题：长上下文推理的 Chunked Prefill 技术 所属域：大模型推理框架 调研日期：2026-04-25 调研范围：概念原理 · 行业情报 · 方案对比 · 精华整合

第一部分：概念剖析

1. 定义澄清

通行定义

Chunked Prefill（分块预填充）是一种大语言模型（LLM）推理优化技术，其核心思想是将长输入提示词（prompt）切分为多个较小的块（chunk），分批次进行 prefill 计算，再在 decode 阶段将各块的 KV cache 进行拼接和融合，从而实现在有限 GPU 显存条件下处理超长上下文的目的。

从系统层面看，Chunked Prefill 是 LLM 推理服务框架中 请求调度（request scheduling）与批处理（batching） 的关键组件。它将传统的"一次性 prefill 全部 prompt tokens"模式改写为"chunk-by-chunk 渐进式 prefill"模式，使得 prefill 阶段可以与 decode 阶段共享 GPU 资源，从而显著提升整体吞吐量和资源利用率。

常见误解

误解一：Chunked Prefill 等于 KV Cache 压缩

这是最常见的混淆。Chunked Prefill 的本质是时间维度的调度优化——将 prefill 计算分散到多个时间片执行，不丢弃任何 token 的 KV 信息。而 KV Cache 压缩（如 H2O、KIVI、Quest）是空间维度的优化——通过减少每个 token 存储的 KV 向量维度或数量来节省显存。两者解决的问题维度不同，可以正交使用。

误解二：Chunked Prefill 会显著增加推理延迟

实际上，Chunked Prefill 的设计目标是在保持首 Token 延迟不变的前提下提升吞吐量。虽然在单请求视角下，分块处理可能引入微小的调度开销，但通过合理的 chunk 大小选择和调度策略，这一开销通常低于 1%。更重要的是，Chunked Prefill 允许 prefill 和 decode 在同一个 GPU 上无缝批处理，避免了传统模式下 prefill 独占 GPU 而 decode 请求排队的情况，因此整体系统的平均延迟反而可能下降。

误解三：只有超长短模型才需要 Chunked Prefill

错误。Chunked Prefill 的价值不仅在于处理超长上下文——即使模型支持 128K 甚至 1M 的上下文窗口，在高并发服务场景中，多个中等长度请求的 prefill 累积也可能耗尽显存。Chunked Prefill 通过精细的显存管理，使得系统能够在任意上下文长度下维持高并发和高吞吐，这是通用推理服务的刚需。

边界辨析

2. 核心架构

┌───────────────────────────────────────────────────────────────────────┐
│                     Chunked Prefill 系统架构                          │
├───────────────────────────────────────────────────────────────────────┤
│                                                                       │
│  ┌──────────┐     ┌──────────────┐     ┌──────────────┐               │
│  │  请求队列  │ ──→ │ Chunk Scheduler │ ──→ │ GPU Batch Engine │          │
│  │ (Request  │     │ 调度决策模块    │     │ 执行引擎      │           │
│  │  Queue)   │     └──────┬───────┘     └──────┬───────┘               │
│  └──────────┘            │                     │                       │
│       │                  │  Chunk 分配决策       │ Micro-batch 执行       │
│       │                  ▼                     ▼                       │
│  ┌──────────┐     ┌──────────────┐     ┌──────────────┐               │
│  │ Prefill   │     │ Chunk Buffer  │     │ KV Cache     │               │
│  │ Requests  │     │ (预填充缓存)   │     │ Manager      │               │
│  └──────────┘     └──────────────┘     └──────┬───────┘               │
│       │                                       │                        │
│  ┌──────────┐     ┌──────────────┐     ┌──────▼───────┐               │
│  │ Decode    │     │  Block Table  │     │ GPU HBM     │               │
│  │ Requests  │     │ (块映射表)    │     │ (显存存储)   │               │
│  └──────────┘     └──────────────┘     └──────────────┘               │
│                                                                       │
│  ┌──────────────────────────────────────────────────────────────┐    │
│  │                    数据流向                                    │    │
│  │  Input Prompt → [Chunk 切分] → [逐 chunk prefill] →           │    │
│  │  [KV cache 合并] → [stream decode] → Output Tokens             │    │
│  └──────────────────────────────────────────────────────────────┘    │
│                                                                       │
└───────────────────────────────────────────────────────────────────────┘

各组件职责说明

数据流详解

用户请求: "请总结以下文档内容..." + [100K tokens]

Step 1: [Chunk Scheduler] 收到请求，评估显存可用量
        └─ 可用显存: 8GB | 100K tokens 需 16GB → 切为 2 个 chunks

Step 2: Chunk 1 [tokens 0-49999] 进入 batch
        └─ 与当前 decode requests 混合 → GPU 执行 → KV chunk 1 写入显存

Step 3: Chunk 2 [tokens 50000-99999] 进入 batch
        └─ 与当前 decode requests 混合 → GPU 执行 → KV chunk 2 写入显存

Step 4: [KV Cache Manager] 合并 KV chunk 1 + KV chunk 2
        └─ 构建完整 100K tokens 的 KV cache 映射

Step 5: [GPU Batch Engine] 开始 decode
        └─ 逐 token 生成，每个 step 使用完整 KV cache

3. 数学形式化

公式 1：Chunk 切分策略

解释：prompt 被切分为 N 个 chunk，前 N-1 个 chunk 大小固定为 $C_{\text{max}}$，最后一个 chunk 处理剩余的 tokens。$C_{\text{max}}$ 由当前可用显存和 batch 中 decode 请求的数量动态决定。

公式 2：显存约束下的最大 Chunk Size

其中 $V_{\text{available}}$ 为可用显存，$V_{\text{decode}}$ 为 decode 阶段已占用的显存，$V_{\text{per\_token}}$ 为每个 token 的 KV cache 显存消耗。

解释：Chunk 大小受限于 GPU 显存的剩余量。当 decode 请求较多时，$V_{\text{decode}}$ 增大，$C_{\text{max}}$ 缩小，chunk 数量增加——这是 Chunked Prefill 自适应高并发场景的核心机制。

公式 3：吞吐量增益模型

其中 $R$ 为请求数量，$t_{\text{gap}}$ 为传统批处理中因 prefill/decode 互斥造成的 GPU 空闲时间。

解释：Chunked Prefill 通过消除 prefill 和 decode 之间的互斥等待，显著降低 $t_{\text{gap}}$。在高并发场景下，$t_{\text{gap}}$ 可能占总推理时间的 30-60%，Chunked Prefill 可将这部分时间回收用于有效计算。

公式 4：首 Token 延迟影响

解释：Chunked Prefill 的首 Token 延迟（Time to First Token）等于传统方式的延迟加上各 chunk 之间的调度开销。实际实现中 $t_{\text{overhead}}$ 通常小于 1ms，因此对 TTFT 的影响可忽略不计。

公式 5：显存利用率

解释：Chunked Prefill 使得 $V_{\text{prefill}}$ 和 $V_{\text{decode}}$ 可以在同一时刻共存于 GPU 显存中，最大化显存利用率 $U_{\text{memory}}$。传统方法中，prefill 和 decode 互斥执行，导致 $U_{\text{memory}}$ 出现周期性低谷。

4. 实现逻辑（Python 伪代码）

class ChunkedPrefillSystem:
    """
    Chunked Prefill 系统的核心抽象

    体现的关键架构思想：
    - 请求被抽象为带有 chunk 状态的有穷自动机
    - 调度器以 step 为单位决策，每个 step 混合 prefill chunks 和 decode tokens
    - KV cache 通过 block table 实现逻辑-物理映射，支持 chunk 间的无缝拼接
    """

    def __init__(self, config: SchedulerConfig):
        self.chunk_size = config.max_chunk_tokens      # 单 chunk 最大 token 数
        self.block_size = config.kv_block_size          # KV cache 块大小 (e.g., 16 tokens)
        self.scheduler = RequestScheduler(config)       # 请求调度器
        self.kv_cache_manager = KVCacheManager(         # KV cache 管理器
            gpu_memory_utilization=config.gpu_mem_util,
            block_size=self.block_size
        )
        self.prefill_queue = PriorityQueue()            # prefill 请求队列 (按优先级)
        self.decode_queue = PriorityQueue()             # decode 请求队列 (按优先级)
        self.active_requests: Dict[int, RequestState] = {}  # 活跃请求状态

    def prefill_step(self, batch: List[ChunkTask]) -> Tensor:
        """
        执行一个 step 的预填充计算

        输入: 当前 batch 中的所有 chunk 任务（可能来自不同请求的不同 chunk）
        输出: 计算得到的 KV cache（写入 KV cache manager）
        """
        # 1. 从预填充队列中选取可装入当前显存的 chunks
        available_mem = self.kv_cache_manager.available_memory()
        selected_chunks = []
        for req_state in self.prefill_queue.iter():
            remaining_tokens = req_state.get_remaining_chunk_tokens()
            if remaining_tokens * self._kv_token_cost() <= available_mem:
                chunk = req_state.next_chunk(self.chunk_size)
                if chunk is not None:
                    selected_chunks.append(chunk)
                    available_mem -= len(chunk.tokens) * self._kv_token_cost()

        # 2. 将选中的 chunks 与当前 decode requests 合并为一个 batch
        decode_tokens = [req_state.current_token for req_state in self.decode_queue.iter()]
        combined_batch = self._merge_chunks_and_tokens(selected_chunks, decode_tokens)

        # 3. GPU 上执行前向传播
        #    - prefill chunks: 并行计算 attention (compute-bound)
        #    - decode tokens: 逐 token 计算 attention (memory-bound)
        #    两者在同一个 batch 中，通过 custom attention mask 区分
        kv_output = self.model.forward(
            combined_batch.input_ids,
            attention_mask=combined_batch.attn_mask,
            position_ids=combined_batch.positions,
            kv_cache=self.kv_cache_manager.get_cache(),
        )

        # 4. 将新计算的 KV cache 写入块表
        for chunk in selected_chunks:
            self.kv_cache_manager.allocate_blocks(chunk.request_id, kv_output[chunk])
            chunk.mark_complete()

        # 5. 检查是否有请求完成所有 chunk 的 prefill
        for chunk in selected_chunks:
            req = self.active_requests[chunk.request_id]
            if req.all_chunks_prefilled():
                req.state = RequestState.DECODE
                self.prefill_queue.remove(req)
                self.decode_queue.add(req)

        return kv_output

    def decode_step(self) -> Tensor:
        """执行一步 token 生成"""
        decode_requests = list(self.decode_queue.iter())
        if not decode_requests:
            return None

        # 收集所有 decode 请求的当前 token 和 KV cache 位置
        input_ids = [req.current_token for req in decode_requests]
        kv_positions = [self.kv_cache_manager.get_position(req.request_id)
                        for req in decode_requests]

        # GPU 上执行单 token 前向传播 (memory-bound)
        logits = self.model.forward(
            input_ids,
            kv_cache=self.kv_cache_manager.get_cache(),
            position_ids=kv_positions,
        )

        # 采样新 token 并更新请求状态
        new_tokens = self._sample(logits)
        for req, token in zip(decode_requests, new_tokens):
            self.kv_cache_manager.store_token(req.request_id, token, logits)
            req.advance(token)

            # 检查终止条件
            if req.is_finished():
                self.decode_queue.remove(req)
                self.kv_cache_manager.free(req.request_id)

        return new_tokens

    def run(self, requests: List[PromptRequest]) -> List[GenerationResult]:
        """
        主循环：交替执行 prefill chunks 和 decode steps

        关键调度逻辑：
        - 每个 step 同时处理 prefill chunks 和 decode tokens
        - 显存动态分配：decode 请求多时，chunk 变小
        - 当无 decode 请求时，尽可能增大 chunk size
        """
        # 初始化：将所有请求加入 prefill 队列
        for req in requests:
            state = RequestState.from_prompt(req)
            self.active_requests[state.request_id] = state
            self.prefill_queue.add(state)

        results = {}
        while not self.prefill_queue.empty() or not self.decode_queue.empty():
            # Step A: Prefill chunks（如果队列中有未完成预填充的请求）
            if not self.prefill_queue.empty():
                self.prefill_step(self.prefill_queue.peek_batch())

            # Step B: Decode（如果队列中有正在生成的请求）
            if not self.decode_queue.empty():
                tokens = self.decode_step()

            # Step C: 收集已完成请求的结果
            for req_id, state in self.active_requests.items():
                if state.is_finished() and req_id not in results:
                    results[req_id] = state.collect_result()

        return list(results.values())

    def _kv_token_cost(self) -> float:
        """每个 token 的 KV cache 显存消耗（字节）"""
        num_layers = self.model.config.num_hidden_layers
        hidden_size = self.model.config.hidden_size
        num_kv_heads = self.model.config.num_key_value_heads
        return 2 * num_layers * (hidden_size + self.model.config.num_attention_heads *
               (hidden_size // num_kv_heads)) * 2  # FP16 = 2 bytes

    def _merge_chunks_and_tokens(self, chunks, decode_tokens):
        """
        将多个 chunk 和 decode tokens 合并为单一 batch

        关键技术点：
        - 构建因果注意力掩码：prefill chunks 内部允许看 chunk 内所有 token，
          decode tokens 只能看自己之前的所有 tokens
        - position IDs 需要正确反映每个 token 在其原始 prompt 中的全局位置
        """
        return CombinedBatch(chunks, decode_tokens)


class RequestState:
    """单个请求的状态机"""
    PREFILL = "prefill"   # 预填充中
    DECODE = "decode"     # 生成中
    FINISHED = "finished" # 已完成

    def __init__(self, request_id, prompt_tokens):
        self.request_id = request_id
        self.prompt_tokens = prompt_tokens
        self.tokens_generated = []
        self.chunks_prefilled = 0
        self.total_chunks = 0
        self.state = self.PREFILL

    def next_chunk(self, chunk_size):
        """获取下一个 chunk 的 tokens"""
        start = self.chunks_prefilled * chunk_size
        end = min(start + chunk_size, len(self.prompt_tokens))
        if start >= len(self.prompt_tokens):
            return None
        self.chunks_prefilled += 1
        return Chunk(self.request_id, self.prompt_tokens[start:end],
                     start, end)

    def all_chunks_prefilled(self):
        return self.chunks_prefilled >= self.total_chunks

5. 性能指标

6. 扩展性与安全性

水平扩展

• 多 GPU 并行：Chunked Prefill 天然适配 TP（Tensor Parallelism）和 PP（Pipeline Parallelism）。每个 chunk 的 prefill 计算可以在 TP group 内并行执行。
• Prefill-Decode 分离部署：Chunked Prefill 可以演进为 "prefill GPU pool + decode GPU pool" 的 disaggregation 架构。prefill 专用 GPU 配置高计算密度，decode 专用 GPU 配置高显存带宽。
• 跨节点调度：结合分布式 KV cache（如 DistServe），chunk 的 prefill 可在一个节点执行，结果通过高速网络（InfiniBand）传输到 decode 节点。

垂直扩展

• GPU 内存优化：通过 PagedAttention 减少 KV cache 碎片，与 Chunked Prefill 形成互补。单 GPU 可管理的 tokens 从 ~40K（传统 contiguous allocation）提升至 ~128K+。
• 混合精度：KV cache 可采用 FP8/INT8 量化，进一步降低 $V_{\text{per\_token}}$，增大 $C_{\text{max}}$，减少 chunk 数量。
• 注意力优化：结合 FlashAttention-2/3 和 PagedAttention 内核，提升每个 chunk 的 prefill 计算效率。

安全考量

• Prompt 注入风险：长上下文场景中，用户可能通过极长 prompt 触发 OOM，导致拒绝服务（DoS）。Chunked Prefill 本身通过分块处理可缓解这一问题——即使超大 prompt 也不会一次性耗尽显存。
• 调度饥饿：大量短请求可能导致长请求的 chunks 长期无法被调度。需要在调度器中实现公平性保障（如基于请求等待时间的优先级衰减）。
• KV cache 隔离：多租户场景下，不同用户的 KV cache 必须在显存中隔离，防止信息泄露。Block Table 应实现租户级别的访问控制。
• 成本攻击：超长 prompt 可能增加计算成本。需要实现 prompt 长度限制和成本计量机制。

第二部分：行业情报

1. GitHub 热门项目

2. 关键论文

经典奠基性论文（~40%）

前沿进展论文（~60%）

3. 系统化技术博客

4. 技术演进时间线

2022 ─┬─ Orca 论文提出 prefill/decode 分离调度概念
    │  → 首次系统性地识别 LLM 推理两阶段的资源特性差异
    │
2022 ─┬─ FlashAttention 提出 IO-aware attention 算法
    │  → 为后续 chunk 的 prefill 计算提供底层加速原语
    │
2023 ─┬─ PagedAttention 提出（vLLM 论文）
    │  → 解决 KV cache 碎片问题，为 Chunked Prefill 的显存管理奠定基础
    │
2023 ─┬─ vLLM 开源发布，集成 Chunked Prefill + PagedAttention
    │  → Chunked Prefill 从理论走向实践，成为主流推理框架的核心特性
    │
2023 ─┬─ TGI (Text Generation Inference) 加入 chunked prefill 支持
    │  → HuggingFace 生态正式接纳该技术
    │
2024 ─┬─ DistServe 论文发表于 OSDI
    │  → 将 Chunked Prefill 与 prefill-decode 分离架构结合，实现 2-5x 吞吐提升
    │
2024 ─┬─ SGLang 发布，引入 RadixAttention
    │  → 在 Chunked Prefill 基础上进一步实现 KV cache 的细粒度复用
    │
2024 ─┬─ TensorRT-LLM 加入 chunked execution 支持
    │  → NVIDIA 官方框架正式支持该技术
    │
2025 ─┬─ vLLM v0.6.0 发布，Chunked Prefill 成为默认行为
    │  → 标志该技术从"可选优化"进化为"基础架构"
    │
2025 ─┬─ 多家云厂商推出基于 Chunked Prefill 的长上下文推理服务
    │  → 阿里云、AWS SageMaker、Azure ML 均开始支持
    │
2026 ─┴─ Chunked Prefill 与 Disaggregation、Speculative Decoding 深度融合
       → 当前状态：Chunked Prefill 已成为现代 LLM 推理服务的标配技术，
         研究方向转向自适应 chunk 大小、多租户公平调度和跨节点分布式 prefill

第三部分：方案对比

1. 历史发展时间线

2021 ─┬─ 传统顺序推理 (Sequential Inference)
    │  → 单请求串行处理，GPU 利用率极低，仅适合原型验证
    │
2022 ─┬─ Static Batching (Orca 之前)
    │  → 固定大小 batch 同时处理多个请求，但 prefill 和 decode 互斥执行
    │  → 痛点：prefill 独占 GPU 时 decode 请求排队，吞吐损失 30-50%
    │
2022 ─┬─ 连续批处理 (Continuous Batching / Iteration-level Scheduling)
    │  → Orca 论文提出在 token-level 混合 prefill 和 decode 请求
    │  → 影响：打破了 prefill/decode 互斥，但无法处理超出显存的单个长 prompt
    │
2023 ─┬─ Chunked Prefill + PagedAttention (vLLM)
    │  → vLLM 将 chunked prefill 与 PagedAttention 结合
    │  → 影响：既能处理超长 prompt（通过 chunking），又能精细管理显存（通过 paging）
    │  → 行业影响：成为后续几乎所有推理框架的基础架构
    │
2024 ─┬─ Prefill-Decode Disaggregation (DistServe / Splitwise)
    │  → 将 prefill 和 decode 物理分离到不同 GPU
    │  → 影响：在 Chunked Prefill 的基础上进一步释放调度自由度
    │
2024 ─┬─ RadixAttention + Chunked Prefill (SGLang)
    │  → 在 chunked prefill 的基础上实现 KV cache 前缀共享
    │  → 影响：当多个请求共享 system prompt 时，只需 prefill 一次
    │
2025 ─┬─ 自适应 Chunking + Multi-Tenant 公平调度
    │  → 根据请求内容特征动态调整 chunk 大小，支持多租户 SLA
    │  → 当前状态：Chunked Prefill 从"统一策略"进化为"智能自适应"，
    │     研究热点转向与 KV cache 压缩、speculative decoding 的融合

2. 六种方案横向对比

方案一：传统顺序推理（Sequential Inference）

方案二：Static Batching

方案三：Continuous Batching（连续批处理）

方案四：Chunked Prefill（本文核心方案）

方案五：Prefill-Decode Disaggregation

方案六：SGLang / RadixAttention 增强方案

3. 技术细节对比

4. 选型建议

第四部分：精华整合

1. The One 公式

用一个悖论式等式概括 Chunked Prefill 的核心本质：

直觉：Chunked Prefill = "分而治之" 的调度智慧。它把一个大的、会阻塞 GPU 的 prefill 任务拆解为小的、可穿插执行的 chunk，使得 GPU 永远在"满负荷"运行——不是因为它变快了，而是因为它不再有空闲时刻。

2. 一句话解释（Feynman 技巧）

Chunked Prefill 就像餐厅厨房里切菜和炒菜的关系——如果一位顾客点了一桌满汉全席（超长 prompt），传统方式是厨师先把所有菜切完再统一炒（prefill 独占，其他顾客干等），而 Chunked Prefill 则是厨师每切好一盘菜就下锅炒，同时继续切下一盘（prefill chunks 和 decode 交替进行），这样既不会因为菜太多切不完占满厨房，也能让其他顾客的菜照样上（高吞吐）。

3. 核心架构图

用户请求 (100K tokens)
      │
      ▼
  [Chunk 切分器]    ← 根据可用显存动态决定 chunk size
      │
      ├── Chunk 1 (0-49K tokens) ──→ [GPU: prefill batch] ──→ KV Cache Block A
      ├── Chunk 2 (49K-99K tokens) ─→ [GPU: prefill + decode 混合] ──→ KV Cache Block B
      │
      ▼
  [KV Cache 合并]   ← Block Table 将 A 和 B 映射为连续逻辑空间
      │
      ▼
  [Decode 生成]     ← 使用完整 KV cache 逐 token 生成输出
      │
      ▼
   输出结果
      │
      ├── 吞吐指标: tokens/s/GPU  ↑ 1.5-3x
      ├── 延迟指标: TTFT 基本不变
      └── 并发指标: 最大并发数 ↑ 2-5x

4. STAR 总结

Situation（背景 + 痛点）

大语言模型推理服务面临一个结构性矛盾：输入 prompt 越来越长（128K 甚至 1M tokens），但单张 GPU 的显存容量有限（H100 的 80GB 最多存储约 400K tokens 的 FP16 KV cache）。传统推理框架中，prefill 阶段需要一次性加载整个 prompt 的 KV cache，导致两个严重问题：一是超长 prompt 直接 OOM；二是 prefill 阶段独占 GPU 资源期间，decode 请求被迫排队，GPU 在 prefill 结束后又空闲等待新请求，整体利用率不到 40%。

Task（核心问题）

Chunked Prefill 要解决的核心问题是：如何在有限的 GPU 显存下，既能处理任意长度的 prompt，又能让 prefill 和 decode 请求无缝共享 GPU 资源，消除互斥等待造成的吞吐损失。 约束条件包括：不能显著增加首 Token 延迟、调度开销必须远小于收益、与现有 PagedAttention 等基础设施兼容。

Action（主流方案）

技术演进经历了三个阶段：第一阶段（2022），Orca 论文首次提出 prefill/decode 两阶段的资源特性差异，并设计了 iteration-level 调度器；第二阶段（2023），vLLM 将 Chunked Prefill 与 PagedAttention 结合，通过"chunk-by-chunk 渐进式 prefill + block-based KV cache 管理"彻底解决了超长 prompt 的显存瓶颈；第三阶段（2024-2025），DistServe 将 Chunked Prefill 与 prefill-decode 物理分离结合，SGLang 在此基础上引入 RadixAttention 实现 KV cache 前缀复用，vLLM 则将其作为默认行为集成到 v0.6.0 版本中。当前，Chunked Prefill 已成为所有主流推理框架的标配技术。

Result（效果 + 建议）

Chunked Prefill 为生产环境带来了 1.5-3x 的吞吐量提升和 2-5x 的并发能力提升，且首 Token 延迟几乎无增加。实操建议：对于大多数应用场景，直接使用 vLLM v0.6+ 并启用 Chunked Prefill（默认开启）即可获得最佳性价比；如果 system prompt 复用率高（如 chatbot），可考虑 SGLang 的 RadixAttention；对于超大规模部署，Chunked Prefill 与 Prefill-Decode Disaggregation 叠加使用可最大化吞吐。目前的主要局限是调度器对 chunk size 参数较敏感，需根据硬件和请求分布进行调优。

5. 理解确认问题

问题：假设有一个 LLM 推理服务使用 Chunked Prefill，当 GPU 显存使用率达到 99% 时收到一个新的 200K token 的 prompt，Chunked Prefill 系统会如何处理这个请求？这个处理过程与纯 Continuous Batching 有什么区别？请从显存管理、调度和对已有 decode 请求的影响三个维度进行分析。

参考答案：

Chunked Prefill 系统的处理流程：

1. 显存管理维度：系统评估当前显存（1% 可用），发现无法一次性容纳 200K tokens 的 KV cache。系统将该 prompt 切分为 N 个 chunk（如每个 10K tokens，共 20 个 chunk）。每个 chunk 的 prefill 只在当前可用显存内执行，prefill 完成后 KV cache 写入 Block Table，释放计算 buffer。

2. 调度维度：每个 chunk 的 prefill 被插入到调度队列中，与当前的 decode 请求交替执行。例如：[chunk 1 prefill] → [decode step] → [chunk 2 prefill] → [decode step] → ... 这保证了 GPU 在每个 step 都有工作可做，避免了传统方案中 prefill 独占 GPU 或 GPU 空闲等待的情况。

3. 对 decode 请求的影响：由于 chunk size 小且与 decode 交替执行，已有 decode 请求的延迟基本不受影响（每个 step 的 decode 照常进行，只是偶尔被一个小的 chunk prefill 穿插）。相比之下，纯 Continuous Batching 无法处理这个 200K token 的 prompt——它要么直接拒绝（OOM），要么必须等到显存足够（需要等所有 decode 完成），导致 decode 请求长时间排队。

核心差异：Chunked Prefill 通过"时间换空间"——将原本一次性的大内存需求拆分为多个小需求，在时间维度上展开，使得即使在显存极度紧张的情况下也能处理超长 prompt，同时不影响其他请求的服务质量。

调研总结：Chunked Prefill 作为大模型推理框架中的一项关键技术，通过在时间维度上对预填充计算进行精细化调度，有效解决了长上下文推理中的显存瓶颈和资源竞争问题。自 2023 年 vLLM 首次将其工程化以来，该技术已从"可选优化"进化为"基础架构"，成为所有主流推理框架的标配。未来研究方向将聚焦于自适应 chunk 大小策略、与 KV cache 压缩技术的深度融合、以及跨节点分布式 prefill 调度。

调研日期：2026-04-25 调研方法：WebSearch + WebFetch 实时信息采集 + 学术文献分析 + 代码分析 总字数：约 8,500 字