百万序列 Prefill：vLLM 如何解决 + 仍开放的难题

0. Executive Summary

1. 物理墙：为什么百万 Prefill 是难题

1.1 三条物理约束

1.2 Prefill vs Decode 的本质差异

2. Chunked Prefill：时间换空间

2.1 机制

vLLM v1 默认启用 Chunked Prefill (enable_chunked_prefill=True)。核心思想：将长 prefill 切成多个 chunk，与 decode 请求交错执行，避免长 prefill 阻塞 decode 的 TTFT。

# vllm/config/scheduler.py:70-74
long_prefill_token_threshold: int = Field(default=0, ge=0)
"""For chunked prefill, a request is considered long if the prompt is
longer than this number of tokens. 0 disables the cap (default)."""

enable_chunked_prefill: bool = True
"""If True, prefill requests can be chunked based
on the remaining `max_num_batched_tokens`."""

# scheduler.py:504-511 — schedule() 主循环中的 chunk 截断
num_new_tokens = (
    request.num_tokens_with_spec
    + request.num_output_placeholders
    - request.num_computed_tokens
)
if 0 < self.scheduler_config.long_prefill_token_threshold < num_new_tokens:
    num_new_tokens = self.scheduler_config.long_prefill_token_threshold
num_new_tokens = min(num_new_tokens, token_budget)

2.2 调度哲学

2.3 关键参数与权衡

3. Context Parallelism：多卡切序列

3.1 vLLM 的 CP 体系

vLLM 实现了两种 Context Parallelism，分别针对 prefill 和 decode 阶段：

# parallel_state.py:1392-1445 — DCP/PCP group 访问器
_DCP: GroupCoordinator | None = None
def get_dcp_group() -> GroupCoordinator:
    assert _DCP is not None, "decode context model parallel group is not initialized"
    return _DCP

_PCP: GroupCoordinator | None = None
def get_pcp_group() -> GroupCoordinator:
    assert _PCP is not None, "prefill context parallel group is not initialized"
    return _PCP

3.2 DCP：Ring Attention for Decode

DCP 是 vLLM 对 Ring Attention 的实现——将 KV Cache 按序列维度切分到 N 张卡，每张卡只存储 1/N 的 KV，通过 ring-all-gather 通信实现完整 attention。

vLLM 实现了两种 DCP 通信后端：

# flash_attn.py:392-400 — DCP 初始化
try:
    from vllm.distributed.parallel_state import get_dcp_group
    self.dcp_world_size = get_dcp_group().world_size
    self.dcp_rank = get_dcp_group().rank_in_group
except AssertionError:
    self.dcp_world_size = 1
    self.dcp_rank = 0

# flash_attn.py:556-616 — DCP context attention 核心
if self.dcp_world_size > 1:
    query_lens = query_start_loc[1:] - query_start_loc[:-1]
    context_kv_lens = seq_lens - query_lens
    local_context_kv_lens = get_dcp_local_seq_lens(
        context_kv_lens,
        self.dcp_world_size,
        self.dcp_rank,
        self.cp_kv_cache_interleave_size,
    )
    # ...
    num_partitions = self.dcp_world_size * self.cp_kv_cache_interleave_size
    max_dcp_context_kv_len = (
        (max_seq_len + num_partitions - 1) // num_partitions
    ) * self.cp_kv_cache_interleave_size

3.3 PCP 的退场

3.4 CP 的物理极限

4. MLA：KV Cache 压缩的范式革命

4.1 机制

Multi-head Latent Attention (MLA) 是 DeepSeek-V2/V3 的核心创新——通过低秩压缩将 KV Cache 从 $O(n_h \times d_h)$ 压缩到 $O(d_{lora} + d_{rope})$。

# deepseek_v2.py:449-475 — DeepseekV2Attention (MLA) 初始化
class DeepseekV2Attention(nn.Module):
    def __init__(self, ..., num_heads, qk_nope_head_dim, qk_rope_head_dim,
                 v_head_dim, kv_lora_rank, ...):
        self.qk_nope_head_dim = qk_nope_head_dim  # 128
        self.qk_rope_head_dim = qk_rope_head_dim  # 64
        self.v_head_dim = v_head_dim              # 128
        self.kv_lora_rank = kv_lora_rank          # 512
        self.num_heads = num_heads                # 128

4.2 压缩率计算

4.3 vLLM 的 MLA 后端生态

vLLM 为 MLA 实现了 20+ 后端变体，覆盖不同硬件和场景：

4.4 MLA 的解压开销

5. KV Offload：层级存储

5.1 vLLM 的 Offload 子系统

vLLM v1 构建了完整的 KV Cache Offload 框架，支持 GPU HBM → CPU DRAM → 远程 P2P 三级存储。

# base.py:76-82 — Offload 策略
class OffloadPolicy(Enum):
    # 只 offload 新计算的 block (prefix-hit 跳过)
    BLOCK_LEVEL = "block_level"
    # offload 所有 block (需要完整 KV 上下文的 tier)
    REQUEST_LEVEL = "request_level"

# base.py:129-153 — OffloadingManager 核心原语
"""
OffloadingManager class for managing KV data offloading in vLLM v1

This class runs in the scheduler, tracks which blocks are offloaded
and their address.

Primitives:
    lookup() - check whether a single block is offloaded and ready.
    prepare_load() - prepare given blocks to be read.
    touch() - marks the given blocks as recently used (LRU).
    complete_load() - mark blocks as done loading (re-allow eviction).
    prepare_store() - prepare the given blocks to be written.
    complete_store() - marks a previous store as completed.
"""

5.2 Async Batch Queue：Prefill 与 Decode 重叠

vLLM v1 的 step_with_batch_queue() 实现了异步 batch 队列——prefill 和 decode 在不同 batch 中并行执行，隐藏 prefill 延迟：

# engine/core.py:622-694 — async batch queue
step_with_batch_queue():
    if batch_queue not full:
        schedule new batch (non-blocking)
    if queue full or no requests:
        wait for result

这是"prefill 不阻塞 decode"的系统级实现——即使一个 1M token 的 prefill 需要数十秒，decode 请求仍可在并行 batch 中持续执行。

5.3 CPU Offload 实现

# config.py:36-53 — OffloadingParallelConfig
class OffloadingParallelConfig:
    rank: int
    world_size: int
    tp_size: int
    pp_size: int
    pcp_size: int      # Prefill CP size
    dcp_size: int      # Decode CP size
    data_parallel_index: int
    is_parallelism_agnostic: bool

5.3 Tiering 架构

vLLM 的 tiering 框架支持多级存储：

• Tier 0: GPU HBM (最快, 最贵, 最小)
• Tier 1: CPU DRAM (中速, PCIe 5.0 ~64 GB/s)
• Tier 2: 远程 P2P (Mooncake/Nixl, RDMA ~100 Gbps)
• Tier 3 (规划): NVMe SSD (~7 GB/s)

5.4 Tier 类型全景

vLLM 的 tiering 框架已注册 4 种二级存储后端：

所有二级 tier 的数据必须经过 CPU (primary) tier 中转——"All data transfers must go through the CPU (primary) tier"。

5.5 MoRIIO：异构 TP↔DP 路由

最新合并的 MoRIIO (Multi-Objective Routing for Interleaved Input-Output) 解决了 prefill 和 decode 节点使用不同 TP 大小时的 KV 路由问题：

• get_moriio_remote_tp_rank 映射本地 → 远程 TP rank
• 支持 replicated KV heads（当 TP 大小不同时）
• Expected-ack counting 处理多对一 consumer→producer 场景

5.6 Offload 的物理极限

6. Prefill-Decode Disaggregation

6.1 机制

DistServe (OSDI'24) 提出的范式：将 prefill 和 decode 部署到不同的 GPU 节点，通过 KV Cache 传输连接。vLLM 通过 kv_transfer 框架支持此模式。

# engine/core.py:459-464 — KV transfer 参数检查
if request.kv_transfer_params is not None and (
    not hasattr(vllm_config, 'kv_transfer_config') or
    vllm_config.kv_transfer_config is None
):
    # Got kv_transfer_params, but no KVConnector found.
    # Disabling KVTransfer for this request.

6.2 为什么分离有帮助

6.3 传输开销

6.4 D 卡缓冲内存分配：全流程传输的容量分析

当 P 节点完成 1M token prefill 后，需要将 KV Cache 全量传输到 D 节点。D 端的缓冲内存分配涉及多个层次：

6.4.1 核心结论：KV Cache 即 Buffer

# nixl/base_worker.py:968-998 — 注册 KV Cache 到 NIXL
total_size = storage.nbytes()           # 整个 KV Cache 的大小
block_stride = total_size // self.num_blocks
base_addr = storage.data_ptr()          # KV Cache 的 GPU 内存地址

# 注册整个 KV Cache 为 NIXL 可写区域
caches_data = [(base_addr, total_size, self.device_id, "")]
descs = self.nixl_wrapper.get_reg_descs(caches_data, self.nixl_memory_type)
self.nixl_wrapper.register_memory(descs, backends=self.nixl_backends)

6.4.2 D 端缓冲区分层清单

6.4.3 1M token 单请求 D 端缓冲精确计算

=== 1. KV Cache (主缓冲) ===
  tokens_per_block = 128
  num_blocks = 1,000,000 / 128 = 7,813 blocks
  kv_bytes_per_token_per_layer = (512 + 64) × 2 = 1,152 bytes
  kv_bytes_per_block = 128 × 1,152 = 147,456 bytes
  KV Cache (单 TP rank) = 7,813 × 147,456 = 1.15 GB
  KV Cache (8 TP ranks, 每 rank) = 1.15 GB (MLA 共享, 不随 TP 膨胀)
  ★ 单请求 D 端 KV Cache = 1.15 GB (MLA, 8 TP)

=== 2. Block Table ===
  num_blocks × 8 bytes = 7,813 × 8 = 62.5 KB (可忽略)

=== 3. NIXL Transfer Descriptors ===
  num_blocks × ~64 bytes = 7,813 × 64 = 500 KB (可忽略)

=== 4. Decode Workspace (per step) ===
  batch=1, heads=128, dim=128, 4 bytes(fp32 acc) = 1 × 128 × 128 × 4 = 64 KB/层

=== 5. 总 D 端缓冲 (单请求) ===
  KV Cache: 1.15 GB
  Block Table + Metadata: ~1 MB
  Decode Workspace: ~1 MB
  ★ 总计 ≈ 1.15 GB (KV Cache 占 99.9%)

6.4.4 多请求并发场景

# scheduler.py:919-931 — 传输前预分配全部 block
if load_kv_async:
    # An async load holds its blocks for the whole transfer with
    # no forward progress and isn't preemptible here. Admit it
    # only if it fits in (free - other in-flight reservations)
    reserved_blocks = self._inflight_prefill_reserved_blocks()

new_blocks = self.kv_cache_manager.allocate_slots(
    request, num_new_tokens,
    num_external_computed_tokens=num_external_computed_tokens,
    delay_cache_blocks=load_kv_async,  # ← 延迟缓存标记
    ...
)

6.4.5 kv_buffer_device 的关键影响

# nixl/base_worker.py:376-380
self.host_xfer_buffers: dict[str, torch.Tensor] = {}
if self.device_type == "cpu":
    self.use_host_buffer = False
else:
    self.use_host_buffer = self.kv_buffer_device == "cpu"  # ← CPU 模式

6.4.6 Mooncake vs NIXL 缓冲对比

6.4.7 传输时序与缓冲生命周期

时间轴 ──────────────────────────────────────────────────────►

[P 节点]
  ┌──────── Prefill 1M token ────────┐
  │ 计算 KV Cache (34.6 GB)          │
  │ 写入 P 端 KV Cache               │
  └──────────────────────────────────┘
           │
           │ RDMA WRITE (NIXL) / batch_put (Mooncake)
           │ 传输量 = 1.15 GB (MLA, 单 TP rank)
           │ 耗时 = ~23ms (400Gbps RDMA)
           ▼
[D 节点]
  ┌─ allocate_slots ─────────────────┐  ← 预分配 KV Cache (1.15 GB)
  │ 标记 block 为 "pending load"    │
  │ delay_cache_blocks = True       │
  └──────────────────────────────────┘
           │
           │ NIXL RDMA WRITE 写入 KV Cache
           │ (直接写入预分配的 GPU 内存)
           ▼
  ┌─ complete_load ──────────────────┐
  │ 标记 block 为 "cached"          │
  │ 更新 request.num_computed_tokens │
  └──────────────────────────────────┘
           │
           ▼
  ┌─ Decode 开始 ────────────────────┐
  │ 读取 KV Cache 进行 attention     │
  │ KV Cache 持续占用直到请求结束    │
  └──────────────────────────────────┘

6.4.8 结论：D 端缓冲的工程权衡

7. Sparse Attention：跳过不相关

7.1 vLLM 的 Sparse 支持

vLLM 通过 FlashMLA 和 FlashAttention 的 sparse 模式支持硬件级 sparse attention：

7.2 vLLM 的 Sparse MLA 生态

vLLM 为 Sparse MLA 实现了 6+ 后端：

关键优化：indexer 跨层共享 (skip_topk)，第一层计算 top-k 索引后后续层复用，减少 indexer 计算开销。

7.3 Sparse 的物理极限

8. Ascend 的长上下文适配

8.1 DSA-CP：Ascend 的 Ring Attention

Ascend 通过 DSA-CP (Dynamic Sparse Attention - Context Parallel) 实现多卡序列切分：

# dsa_v1.py:203-224 — DSA-CP 启用条件
from vllm_ascend.utils import enable_dsa_cp
if enable_dsa_cp():
    from vllm_ascend.attention.context_parallel.dsa_cp import AscendDSACPMetadataBuilder
# ...
if enable_dsa_cp():
    from vllm_ascend.attention.context_parallel.dsa_cp import AscendDSACPImpl

DSA-CP 支持两种压缩比：compress_ratio=4 和 compress_ratio=128，对应不同的 KV Cache 布局。最近 commit [Performance][DSA-CP] Optimize local token metadata computation with fused Triton kernel and caching (#12193) 将元数据计算融合为单个 Triton kernel。每个 rank 计算本地 attention 后，通过 all_to_all_single 恢复完整 head 布局。

8.2 SFA + DCP：Sparse Flash Attention

Ascend 独有的 SFA (Sparse Flash Attention) 结合 DCP 实现 sparse + CP 双优化：

# sfa_v1.py:551-653 — SFA C8 sparse 配置
self.sfa_qsfa_tile_size = SFA_QSFA_TILE_SIZE
self.use_sparse_c8_sfa = self.use_sparse_c8_indexer or (
    # ... C8 sparse 条件
)
if self.use_sparse_c8_sfa:
    self.sfa_qsfa_packed_kv_head_dim = get_sfa_qsfa_packed_kv_head_dim(
        ..., self.sfa_qsfa_tile_size, ...
    )

8.3 Chunked Prefill 拆分

Ascend 特有的优化：将 mixed batch 中的 decode 和 prefill 拆分成两次独立的 FIA (Fused Infer Attention) 调用，避免互相干扰：

# attention_v1.py:1402-1417 — _forward_fia_chunked_prefill_split
def _forward_fia_chunked_prefill_split(self, query, key, value,
        current_key, current_value, block_size, block_table,
        attn_metadata, output):
    """ChunkedPrefill with mixed prefill/decode: run decode and prefill in
    separate FIA calls. split_decodes_and_prefills has reordered the batch
    so decodes occupy [0, num_decode_tokens) and prefills the rest"""

8.4 MLA Chunked Prefill Workspace

Ascend 的 MLA chunked prefill 使用预分配 workspace 来分批处理长上下文：

# utils.py:134-159 — workspace 大小计算
def ascend_chunked_prefill_workspace_size(vllm_config):
    chunked_prefill_workspace_size = min(
        # 8 个全长请求 或 4 pages/请求
        max(8 * max_model_len, 4 * max_num_seqs * block_size),
        # 长上下文上限 128K tokens
        # 2*(576)*(128*1024) = 288 MB (MLA, fp16)
        # 2*(192*128)*(128*1024) = 6 GB (up-projected)
        128 * 1024,
    )
    return chunked_prefill_workspace_size

# mla_v1.py:501-505 — max_context_chunk 计算
self.max_context_chunk = self.chunked_prefill_workspace_size // num_prefills_with_context_cpu
self.max_context_chunk = round_down(self.max_context_chunk, self.block_size)
self.num_chunks = cdiv(max_context_len_cpu, self.max_context_chunk)

8.5 Ascend 独有：Sleep Mode + Recompute

Ascend 还实现了两种 vLLM 上游没有的长上下文机制：

9. 开放难题与物理极限

9.1 vLLM 上游最新长上下文 Commit (2026-07)

9.2 根本性难题 (物理墙)

9.3 工程级难题 (可解决但未解决)

9.4 vLLM 社区正在讨论的 RFC

10. 综合对比与未来路线

10.1 六条路线的物理画像

10.2 组合策略：vLLM 的"全栈"方案

10.3 未来路线判断

11. References & 溯源

11.1 代码锚点索引

11.2 外部参考

• DeepSeek-V2: arXiv:2405.04434 (2024) — MLA 原始论文
• DeepSeek-V3: arXiv:2412.19437v1 (2024-12) — MLA 生产级报告
• Ring Attention: arXiv:2310.01889 (Liu et al. 2023) — 527 citations
• DistServe: arXiv:2401.09670 (OSDI'24) — P/D 分离范式, 974 citations
• vLLM KV Offloading: vllm.ai/blog (2026-01-08)
• Chunked Prefill RFC: vllm-project/vllm#3130
• TransMLA: arXiv:2502.07864 (2025) — MLA 后续研究
• RingX: ACM 2025 — 可扩展 Ring Attention
• LeoAM: arXiv:2506.20187v1 (2025) — 自适应 KV 管理
• Prefill-as-a-Service: arXiv:2604.15039v1 (2026-04)

11.3 完整 URL 清单

所有调研中访问的 URL（含搜索页、论文、博客、文档）共 70+ 条，完整保存在：
_raw/prefill_research_urls.txt

报告生成: 2026-07-27 · vLLM ffc4f08c8 (461 commits since 2026-07-01) · Ascend 39d1cf9b3 · 调研方法: 3 agent 并行 (vLLM 上游 + Ascend + Web) + 核心代码深读 · 关键过程记录: _raw/prefill_research/notes.md