vLLM V1 深度拆解：当一个 LLM 推理引擎决定「从零重写」——PagedAttention、分离式推理与 LMCache 如何重新定义大模型服务的性能天花板

2026 年 8 月，vLLM V1 引擎正式成为默认架构。从 PagedAttention 到 Disaggregated Serving，从 KV Connector 到 LMCache，这个伯克利团队用一场「引擎革命」重新定义了 LLM 推理的性能边界。

一、引言：为什么 vLLM 需要一次「推倒重来」？

如果你在 2024 年部署过大模型推理服务，你大概率用过 vLLM。这个由 UC Berkeley 团队开发的开源推理引擎，凭借 PagedAttention 技术一举解决了 LLM 推理中 KV Cache 的显存碎片化问题，成为生产环境中最主流的推理框架之一。

但到了 2026 年中，vLLM 面临着一个尴尬的处境：V0 架构的天花板已经触顶。

1.1 V0 的三大结构性瓶颈

瓶颈一：Prefill 与 Decode 的耦合调度

在 V0 架构中，Prefill（预填充）和 Decode（解码）共用同一个调度器和同一个执行引擎。这导致了一个根本性问题：Prefill 阶段是计算密集型的（需要处理整个 prompt 的 attention），而 Decode 阶段是访存密集型的（逐 token 生成，瓶颈在 KV Cache 的读取带宽）。将两种截然不同的计算模式硬塞进同一个执行路径，就像让一个短跑运动员和一个马拉松选手共用同一双鞋——谁都不舒服。

瓶颈二：KV Cache 的单机束缚

V0 的 KV Cache 完全绑定在本地 GPU 显存中。当你的推理服务需要跨节点扩展时，KV Cache 无法在节点间共享或迁移。这意味着 Prefill 和 Decode 必须在同一个 GPU 上完成，无法实现真正的分布式推理。在长上下文场景下（如 128K token），单个请求的 KV Cache 就能吃掉数十 GB 显存，严重限制了并发能力。

瓶颈三：引擎扩展性不足

V0 的架构设计中，Model Runner 直接管理 KV Cache 的物理层，调度器负责逻辑层的 block 分配。这种紧耦合设计使得新增功能（如 MLA 注意力支持、结构化输出、多模态推理）需要侵入式修改核心代码，开发和维护成本急剧上升。

1.2 V1 的设计哲学：解耦、分层、可插拔

V1 引擎的核心设计哲学可以用三个词概括：

• 解耦（Decouple）：将 Prefill 和 Decode 分离为独立的执行路径，允许它们在不同的硬件上运行
• 分层（Layer）：引入 KV Connector 抽象层，将 KV Cache 的管理从引擎核心中剥离出来
• 可插拔（Pluggable）：通过标准化接口，让外部 KV Cache 存储系统（如 LMCache）可以无缝接入

这不仅仅是代码重构，而是对 LLM 推理架构的一次根本性重新思考。

二、PagedAttention：从操作系统虚拟内存到 GPU 显存管理

要理解 vLLM 的核心竞争力，必须先理解 PagedAttention。这项技术是 vLLM 的「灵魂」，也是它区别于 TensorRT-LLM、SGLang 等竞品的关键所在。

2.1 传统 KV Cache 的显存灾难

在 Transformer 的自回归生成过程中，每生成一个新 token，都需要与所有历史 token 的 Key 和 Value 向量做 attention 运算。为了避免重复计算，这些 K/V 向量被缓存在 GPU 显存中，这就是 KV Cache。

传统实现中，KV Cache 的显存分配采用预分配策略：为每个请求预留 max_seq_len 大小的连续显存空间。以 Llama 3 70B 为例：

KV Cache 显存占用 = 2 × n_layers × n_heads × head_dim × seq_len × dtype_size
= 2 × 80 × 8 × 128 × 4096 × 2 bytes (FP16)
= 671 MB / 请求

当 max_seq_len 设为 128K 时，单个请求就需要 21 GB 显存。但实际使用中，大多数请求远达不到最大长度，导致大量显存被浪费。这种「宁可错杀不可放过」的分配策略，显存利用率通常只有 30%-50%。

2.2 PagedAttention 的分页思想

PagedAttention 借鉴了操作系统虚拟内存的分页机制，将 KV Cache 划分为固定大小的逻辑块（Logical Block），每个块存储固定数量的 token 的 K/V 向量。通过**块表（Block Table）**建立逻辑块到物理块的映射关系，实现了 KV Cache 的按需分配和动态增长。

核心数据结构如下：

class KVCacheBlock:
    """KV-cache block metadata - vLLM V1"""
    block_id: int          # 块的唯一标识
    ref_count: int         # 引用计数（支持 prefix sharing）
    hash: int              # 内容哈希（用于 prefix caching）
    prev_block: Optional[int]  # 双向链表：前驱块
    next_block: Optional[int]  # 双向链表：后继块

每个请求在调度时，只需要分配当前实际需要的 token 数量对应的块数，而不是预留整个 max_seq_len。当请求生成结束时，块被释放并返回空闲池。这种方式将显存利用率从 30%-50% 提升到了 90%+。

2.3 V1 中 PagedAttention 的演进

V1 对 PagedAttention 进行了三个关键升级：

升级一：融合块表（Fused Block Table）

V0 中，块表的管理在 CPU 端完成，每次调度都需要 CPU-GPU 数据传输。V1 将块表直接放在 GPU 上，通过 CUDA Kernel 实现高效的块表查询和更新，消除了 CPU-GPU 之间的通信瓶颈。

升级二：前缀树缓存（Prefix Tree Cache）

V1 引入了基于前缀树的 KV Cache 缓存机制。当多个请求共享相同的 system prompt 或前缀时，它们可以复用同一份 KV Cache，无需重复计算。这在多轮对话和批量处理场景下能带来显著的性能提升。

# V1 Prefix Cache 的核心逻辑
class PrefixCacheManager:
    def __init__(self, block_manager):
        self.block_manager = block_manager
        self.prefix_tree = PrefixTree()
    
    def lookup(self, token_ids: List[int]) -> Optional[KVCacheBlock]:
        """查找最长公共前缀，返回可复用的 KV Cache"""
        return self.prefix_tree.find_longest_prefix(token_ids)
    
    def insert(self, token_ids: List[int], kv_block: KVCacheBlock):
        """将新计算的 KV Cache 插入前缀树"""
        self.prefix_tree.insert(token_ids, kv_block)

升级三：抢占与恢复（Preemption & Recovery）

当 GPU 显存不足时，V1 支持将低优先级请求的 KV Cache 换出到 CPU 内存，待显存释放后再换入。这种「显存虚拟化」机制通过 PagedAttention 的块级管理天然支持——只需要将块表中的物理地址从 GPU 内存改为 CPU 内存即可。

三、分离式推理：Prefill 与 Decode 的「分家」

V1 最重要的架构变革是引入了分离式推理（Disaggregated Serving），将 Prefill 和 Decode 分离为独立的执行阶段，允许它们运行在不同的 GPU 甚至不同的物理节点上。

3.1 为什么需要分离？

Prefill 和 Decode 在计算特性上的差异是根本性的：

将两种模式混合执行，会导致：

• Prefill 的大矩阵运算会抢占 Decode 的访存带宽，导致 TPS 下降
• Decode 的小粒度运算无法充分利用 GPU 的计算单元，导致 Prefill 阶段的 TTFT 增加
• 在长上下文场景下，单个请求的 Prefill 就能占用整个 GPU 数秒，严重阻塞其他请求

3.2 KV Connector：连接 Prefill 和 Decode 的桥梁

V1 引入了 KV Connector API，这是一个标准化的 KV Cache 传输接口。通过这个接口，Prefill 阶段计算出的 KV Cache 可以高效地传输到 Decode 阶段，无论两者是否在同一台机器上。

# KV Connector 接口定义（简化版）
class KVConnector:
    """vLLM V1 KV Connector API"""
    
    def send_kv_cache(
        self,
        request_id: str,
        kv_cache: torch.Tensor,
        target_node: str,
    ) -> bool:
        """将 KV Cache 发送到目标节点"""
        pass
    
    def recv_kv_cache(
        self,
        request_id: str,
        source_node: str,
    ) -> torch.Tensor:
        """从源节点接收 KV Cache"""
        pass
    
    def get_transfer_latency(
        self,
        kv_size_bytes: int,
        target_node: str,
    ) -> float:
        """估算 KV Cache 传输延迟"""
        pass

KV Connector 支持多种传输后端：

• NVLink/NVSwitch：同一节点内多 GPU 之间的高速传输（带宽 900 GB/s）
• RDMA/RoCE：跨节点的低延迟传输（带宽 100-400 Gbps）
• 共享存储：通过 LMCache 等外部存储系统实现持久化 KV Cache

3.3 分离式推理的调度策略

V1 的调度器需要在 Prefill 和 Decode 之间做出复杂的资源分配决策：

class DisaggregatedScheduler:
    """分离式推理调度器"""
    
    def __init__(self, prefill_gpus, decode_gpus, kv_connector):
        self.prefill_pool = GPUPool(prefill_gpus)
        self.decode_pool = GPUPool(decode_gpus)
        self.kv_connector = kv_connector
        self.pending_requests = deque()
    
    def schedule(self) -> SchedulerOutput:
        """分离式调度：先分配 Prefill，再分配 Decode"""
        
        # 1. 为 Prefill 阶段分配 GPU
        prefill_assignments = []
        for req in self.pending_requests:
            gpu = self.prefill_pool.acquire(req.estimated_kv_size)
            if gpu:
                prefill_assignments.append((req, gpu))
        
        # 2. Prefill 完成后，通过 KV Connector 传输到 Decode GPU
        for req, prefill_gpu in prefill_assignments:
            decode_gpu = self.decode_pool.acquire(req)
            if decode_gpu:
                # 异步传输 KV Cache
                self.kv_connector.send_kv_cache(
                    req.id, 
                    prefill_gpu.get_kv_cache(req.id),
                    decode_gpu.node_id
                )
                # 切换到 Decode 调度队列
                self.decode_queue.append(req)
        
        return SchedulerOutput(...)

3.4 性能对比：分离 vs 混合

在 Llama 3 70B（8×H100）上的实测数据：

特别是在长上下文场景下，分离式推理的优势更加明显——Prefill 阶段的 GPU 可以专注于计算，不受 Decode 请求的干扰，TTFT 可以降低 3-4 倍。

四、LMCache：KV Cache 的「外部记忆」

如果说 PagedAttention 解决了 KV Cache 的显存碎片化问题，分离式推理解决了 KV Cache 的跨节点传输问题，那么 LMCache 解决的就是 KV Cache 的持久化与复用问题。

4.1 KV Cache 为什么需要外部存储？

在传统的 LLM 推理架构中，KV Cache 有几个痛点：

痛点一：冷启动开销

当推理服务重启或扩容时，所有已缓存的 KV Cache 都会丢失。用户需要重新发送 prompt，等待 Prefill 完成。对于长上下文场景（如 128K token），冷启动可能需要数十秒。

痛点二：无法跨引擎复用

不同的推理引擎（vLLM、SGLang、TensorRT-LLM）有不同的 KV Cache 格式。即使运行相同的模型，一个引擎计算出的 KV Cache 也无法被另一个引擎直接使用。

痛点三：存储效率低

KV Cache 的原始数据量非常大。以 Llama 3 70B 的 128K 上下文为例，单个请求的 KV Cache 约为 21 GB。如果需要持久化存储大量 KV Cache，存储成本会急剧上升。

4.2 LMCache 的三层架构

LMCache 是一个专门面向 LLM 推理的 KV Cache 管理层，其架构分为三层：

┌─────────────────────────────────────────────┐
│              Application Layer              │
│   (vLLM / SGLang / TensorRT-LLM / ...)      │
├─────────────────────────────────────────────┤
│              LMCache SDK Layer              │
│   ┌───────────┬──────────┬──────────────┐  │
│   │ Cache     │ KV       │ Observability│  │
│   │ Manager   │ Transform│ & Metrics    │  │
│   └───────────┴──────────┴──────────────┘  │
├─────────────────────────────────────────────┤
│              Storage Layer                  │
│   ┌───────────┬──────────┬──────────────┐  │
│   │ GPU HBM   │ CPU DRAM │ Remote Store │  │
│   │ (L1 Hot)  │ (L2 Warm)│ (L3 Cold)    │  │
│   └───────────┴──────────┴──────────────┘  │
└─────────────────────────────────────────────┘

L1 Hot Cache（GPU HBM）：存放最近使用的 KV Cache，访问延迟 < 1μs

L2 Warm Cache（CPU DRAM）：存放可能被复用的 KV Cache，访问延迟 ~10μs

L3 Cold Cache（远程存储）：存放历史 KV Cache，支持跨节点复用，访问延迟 ~100μs-1ms

4.3 KV Cache 变换：压缩与量化

LMCache 内置了 KV Cache 变换引擎，支持在存储前对 KV Cache 进行压缩和量化，大幅降低存储开销：

from lmcache import KVCacheTransformer

# FP16 → INT4 量化，存储空间压缩 4 倍
transformer = KVCacheTransformer(
    method="groupwise_int4",
    group_size=128,  # 每 128 个元素一组量化
    symmetric=True,
)

# 压缩前：21 GB（FP16，128K 上下文）
compressed = transformer.compress(kv_cache_fp16)
# 压缩后：5.25 GB（INT4），质量损失 < 0.5%

# 还原时反量化
kv_cache_restored = transformer.decompress(compressed)

实测压缩效果：

4.4 LMCache + vLLM V1 集成

V1 通过 KV Connector 与 LMCache 深度集成。当 Prefill 阶段完成时，KV Cache 可以自动写入 LMCache：

# 启动 vLLM V1 with LMCache
from vllm import LLM, SamplingParams

llm = LLM(
    model="meta-llama/Llama-3-70B-Instruct",
    kv_cache_type="lmcache",           # 使用 LMCache 作为 KV Cache 后端
    lmcache_config={
        "chunk_size": 256,              # 每 256 个 token 一个 chunk
        "remote_url": "redis://cache-server:6379",  # 远程存储地址
        "enable_compression": True,     # 启用压缩
        "compression_method": "int4",   # 压缩方法
        "enable_prefill_caching": True, # 启用 Prefill 缓存
    },
    tensor_parallel_size=8,
)

# 请求 1：首次计算，KV Cache 写入 LMCache
output1 = llm.generate("Explain quantum computing...", sampling_params)

# 请求 2：相同前缀，直接从 LMCache 读取 KV Cache
output2 = llm.generate("Explain quantum computing in detail...", sampling_params)
# TTFT 降低 80%+

五、结构化输出：从「Prompt 调教」到「约束解码」

V1 引入了基于 xgrammar 的结构化输出支持，这是生产环境中最实用的功能之一。

5.1 传统结构化输出的痛点

让 LLM 输出结构化 JSON 是最常见的需求，但传统方法有诸多问题：

方法一：Prompt 约束

System: 你必须且只能输出 JSON 格式，不要输出任何其他内容。

这种方式完全依赖模型的「自觉性」，实际输出中经常夹杂解释文字、多余的引号、格式错误。

方法二：后处理解析
用正则表达式或 JSON parser 从模型输出中提取 JSON。这种方式在输出格式偏移时容易失败，且无法保证 100% 成功。

5.2 Constrained Decoding：在解码时约束

V1 采用的 constrained decoding 技术，在每一步 token 生成时，根据预定义的 JSON Schema 动态计算合法 token 集合，将非法 token 的概率设为 0。

JSON Schema: {"type": "object", "properties": {"name": {"type": "string"}, "age": {"type": "integer"}}}

当前生成状态: {"name": "John"
下一步合法 token: ":" 或 "}" 或 ","

模型 logits: [0.1, 0.3, 0.05, ...]  (所有 token)
掩码后 logits: [-inf, 0.3, -inf, ...] (只保留合法 token)
→ 采样结果: 必然是合法 token

5.3 xgrammar：高效的约束解码引擎

xgrammar 是一个专门为 LLM 结构化输出设计的约束解码引擎，其核心创新在于将 JSON Schema 编译为有限状态自动机（FSA），实现 O(1) 复杂度的合法 token 查询：

from xgrammar import GrammarCompiler, TokenizerWrapper

# 编译 JSON Schema 为 FSA
json_schema = {
    "type": "object",
    "properties": {
        "name": {"type": "string"},
        "age": {"type": "integer", "minimum": 0},
        "skills": {"type": "array", "items": {"type": "string"}}
    },
    "required": ["name", "age"]
}

compiler = GrammarCompiler()
fsa = compiler.compile_json_schema(json_schema)

# 在每一步生成时查询合法 token
tokenizer = TokenizerWrapper.from_model("meta-llama/Llama-3-70B-Instruct")

# 掩码计算：O(1) 复杂度
def compute_mask(fsa, current_state, tokenizer):
    """根据当前 FSA 状态计算合法 token 掩码"""
    valid_tokens = fsa.get_valid_tokens(current_state)
    mask = torch.full((tokenizer.vocab_size,), float('-inf'))
    mask[valid_tokens] = 0.0
    return mask

性能数据：

六、性能调优实战：从部署到极致

6.1 硬件选型建议

不同场景下的最优硬件配置：

6.2 关键参数调优

# V1 推荐启动参数
python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-3-70B-Instruct \
    --tensor-parallel-size 8 \
    --max-model-len 32768 \
    --gpu-memory-utilization 0.92 \
    --enable-prefix-caching \
    --enable-chunked-prefill \
    --max-num-batched-tokens 8192 \
    --max-num-seqs 256 \
    --kv-cache-dtype fp8 \
    --enable/disaggregated-prefill \
    --disaggregated-prefill-gpu 4 \
    --disaggregated-decode-gpu 4

参数说明：

• --enable-prefix-caching：启用前缀树缓存，复用相同 system prompt 的 KV Cache
• --enable-chunked-prefill：将长 prompt 分块处理，避免 Prefill 阶段阻塞 Decode
• --kv-cache-dtype fp8：使用 FP8 存储 KV Cache，显存占用减半
• --enable/disaggregated-prefill：启用分离式推理

6.3 监控与告警

V1 内置了 Prometheus metrics，建议监控以下关键指标：

# prometheus.yml
scrape_configs:
  - job_name: 'vllm'
    static_configs:
      - targets: ['vllm-server:8000']
    metrics_path: '/metrics'

# 关键告警规则
groups:
  - name: vllm_alerts
    rules:
      # TTFT 过高
      - alert: HighTTFT
        expr: vllm:e2e_request_latency_seconds{quantile="0.99"} > 5
        for: 5m
        labels:
          severity: warning
      
      # GPU 显存接近满载
      - alert: HighGPUMemory
        expr: vllm:gpu_cache_usage_perc > 0.95
        for: 2m
        labels:
          severity: critical
      
      # 请求排队时间过长
      - alert: HighQueueTime
        expr: vllm:num_requests_waiting > 50
        for: 3m
        labels:
          severity: warning

七、竞品对比：vLLM vs SGLang vs TensorRT-LLM

7.1 架构差异

7.2 性能对比（Llama 3 70B, 8×H100）

7.3 选型建议

• 追求易用性和生态兼容 → vLLM V1
• 追求极致 TPS 和前缀缓存 → SGLang
• 追求极致推理速度和 NVIDIA 生态深度整合 → TensorRT-LLM
• 需要跨引擎 KV Cache 复用 → vLLM V1 + LMCache
• 需要分离式推理 → vLLM V1（唯一支持）

八、生产部署最佳实践

8.1 Docker Compose 部署示例

version: '3.8'
services:
  vllm-prefill:
    image: vllm/vllm-openai:latest
    runtime: nvidia
    environment:
      - NVIDIA_VISIBLE_DEVICES=0,1,2,3
    command: >
      --model meta-llama/Llama-3-70B-Instruct
      --tensor-parallel-size 4
      --role prefill
      --kv-cache-dtype fp8
      --enable-prefix-caching
      --port 8001
    ports:
      - "8001:8001"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 4
              capabilities: [gpu]

  vllm-decode:
    image: vllm/vllm-openai:latest
    runtime: nvidia
    environment:
      - NVIDIA_VISIBLE_DEVICES=4,5,6,7
    command: >
      --model meta-llama/Llama-3-70B-Instruct
      --tensor-parallel-size 4
      --role decode
      --kv-cache-dtype fp8
      --enable-prefix-caching
      --port 8002
      --prefill-url http://vllm-prefill:8001
    ports:
      - "8000:8002"  # 外部端口映射到 decode
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 4
              capabilities: [gpu]

  lmcache:
    image: lmcache/lmcache-server:latest
    ports:
      - "8003:8003"
    volumes:
      - lmcache-data:/data
    environment:
      - LMCACHE_CHUNK_SIZE=256
      - LMCACHE_REMOTE_URL=redis://redis:6379

  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"
    volumes:
      - redis-data:/data

volumes:
  lmcache-data:
  redis-data:

8.2 Kubernetes 部署

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-prefill
spec:
  replicas: 2
  selector:
    matchLabels:
      app: vllm-prefill
  template:
    metadata:
      labels:
        app: vllm-prefill
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        args:
          - "--model"
          - "meta-llama/Llama-3-70B-Instruct"
          - "--tensor-parallel-size"
          - "8"
          - "--role"
          - "prefill"
          - "--kv-cache-dtype"
          - "fp8"
        ports:
        - containerPort: 8000
        resources:
          limits:
            nvidia.com/gpu: 8
          requests:
            memory: "160Gi"
            cpu: "32"
        env:
        - name: NVIDIA_VISIBLE_DEVICES
          value: "all"

8.3 性能基准测试

使用 vllm bench 命令进行标准化基准测试：

# 延迟测试
vllm bench latency \
    --model meta-llama/Llama-3-70B-Instruct \
    --num-prompts 100 \
    --input-len 1024 \
    --output-len 128

# 吞吐量测试
vllm bench throughput \
    --model meta-llama/Llama-3-70B-Instruct \
    --num-prompts 1000 \
    --input-len 512 \
    --output-len 256 \
    --concurrency 64

# 结构化输出测试
vllm bench latency \
    --model meta-llama/Llama-3-70B-Instruct \
    --num-prompts 50 \
    --input-len 256 \
    --output-len 512 \
    --guided-decoding-backend xgrammar

九、常见问题排查

9.1 OOM（显存不足）

症状：torch.cuda.OutOfMemoryError: CUDA out of memory

排查步骤：

1. 检查 --gpu-memory-utilization 参数，建议设为 0.90-0.95
2. 使用 --kv-cache-dtype fp8 将 KV Cache 显存减半
3. 降低 --max-num-seqs 限制并发请求数
4. 启用 --enable-chunked-prefill 分块处理长 prompt

9.2 TTFT 过高

症状：首 token 延迟超过 3 秒

排查步骤：

1. 启用 --enable-prefix-caching 复用前缀 KV Cache
2. 启用分离式推理，将 Prefill 和 Decode 分离到不同 GPU
3. 检查 prompt 长度，超长 prompt 需要分块处理
4. 检查 GPU 温度和频率，过热会导致降频

9.3 结构化输出格式错误

症状：JSON 输出缺少字段或格式不对

排查步骤：

1. 确认使用了 --guided-decoding-backend xgrammar
2. 检查 JSON Schema 是否正确（特别是 required 字段）
3. 对于复杂嵌套结构，考虑简化 Schema 或增加 max_tokens
4. 使用 --guided-decoding-frontend openai 兼容 OpenAI 格式

十、总结与展望

vLLM V1 的发布标志着 LLM 推理引擎进入了一个新的阶段。从 PagedAttention 的显存革命，到分离式推理的架构创新，再到 LMCache 的外部记忆系统，vLLM 正在重新定义「如何高效运行大模型」这个问题的答案。

10.1 核心创新回顾

• PagedAttention V2：融合块表 + 前缀树缓存，显存利用率 90%+
• 分离式推理：Prefill/Decode 分离，TTFT 降低 3-4 倍
• KV Connector API：标准化 KV Cache 传输，支持跨引擎复用
• LMCache 集成：三层存储架构，KV Cache 压缩 4-8 倍
• xgrammar 结构化输出：100% 格式正确率，O(1) 掩码计算

10.2 未来方向

方向一：硬件感知调度

V1 的下一步是实现硬件感知的智能调度——根据 GPU 的显存带宽、计算单元利用率、温度等实时状态，动态调整 Prefill/Decode 的资源分配比例。

方向二：跨集群 KV Cache

随着推理集群规模的扩大，KV Cache 需要跨越更大的物理范围。V2 可能会引入分布式 KV Cache 一致性协议，实现跨数据中心的 KV Cache 共享。

方向三：推理-训练融合

V1 的架构设计天然支持推理过程中的在线学习。未来可能出现「边推理边学习」的范式——推理时收集的反馈数据可以实时更新模型，形成持续学习的闭环。

10.3 给开发者的建议

如果你正在构建 LLM 推理服务：

1. 新项目直接用 V1：V1 已经稳定，新功能（如 MLA、xgrammar）都只在 V1 中支持
2. 长上下文场景优先考虑分离式推理：Prefill/Decode 分离在长上下文场景下的收益是数量级的
3. 生产环境必须启用 LMCache：冷启动优化和跨节点复用是生产环境的刚需
4. 监控 TTFT 和 TPS：这两个指标是推理服务质量的核心衡量标准
5. 关注 KV Cache 压缩：INT4 量化可以在几乎无损的情况下节省 4 倍显存

vLLM V1 不仅是一个推理引擎的升级，更是 LLM 基础设施从「能跑」到「跑得好」的标志性事件。当显存管理、分布式调度和外部存储三大技术栈融合在一起，我们看到的不仅是性能数字的提升，更是大模型工程化落地的一个新起点。

参考资源：

• vLLM GitHub: https://github.com/vllm-project/vllm
• vLLM V1 Release Notes: https://github.com/vllm-project/vllm/releases/tag/v0.8.5
• LMCache 文档: https://docs.lmcache.ai/
• xgrammar 项目: https://github.com/mlc-ai/xgrammar
• PagedAttention 论文: https://arxiv.org/abs/2309.06180