7.4 分离式推理与多模态/Agent 推理：架构级的优化与未来

7.4 分离式推理与多模态/Agent 推理：架构级的优化与未来

当单个节点的优化做到极致，下一步就是把架构「拆开」——把 Prefill 与 Decode 分到不同节点、把多模态编码与文本生成解耦、把多轮 Agent 的 KV Cache 跨调用复用。PD 分离（Prefill/Decode Disaggregation）是 2024 年以来 LLM 推理最前沿的架构级创新。

7.4.1 从节点优化到架构优化

第 6-7 章的前三节（PagedAttention、Chunked Prefill、量化、Speculative）都是「节点内优化」——让单个推理节点更高效。但当单个节点的优化接近物理极限时，下一步的突破必须来自「架构级」：

• PD 分离：把 Prefill 与 Decode 拆到不同节点，各自优化。
• 多模态推理优化：让 LLM 高效处理图像、音频等非文本输入。
• Agent 推理的 KV 复用：让多轮 Agent 调用的 KV Cache 跨轮复用。

本节讲清这三个方向，它们是 LLM 推理的前沿，也是未来 1-2 年的工程热点。

7.4.2 PD 分离：Prefill 与 Decode 解耦

PD 分离（Prefill/Decode Disaggregation） 的核心思想：把 Prefill 与 Decode 这两个特性截然不同的阶段（回顾 6.2 节）拆到不同节点，各自最优。

回顾两阶段的不对称：

• Prefill：计算密集，需要大算力（H100 这种强卡）。
• Decode：内存密集，需要大显存带宽（也是强卡，但用法不同）。

传统「PD 混合部署」（Prefill 与 Decode 在同一节点）的问题：

• 资源错配：Prefill 时算力满载但显存带宽空闲；Decode 时显存带宽满载但算力空闲。同一节点的两阶段负载不均衡。
• 互相干扰：Prefill 与 Decode 共享同一 batch 时，长 Prefill 阻塞 Decode（Chunked Prefill 7.1 节缓解但不能完全消除）。
• 难以独立扩缩：Prefill 与 Decode 流量不同步，混合部署难以分别扩缩。

PD 分离的解决方案：

• P 节点（Prefill Pool）：专门处理 Prefill，配大算力卡，承担首 token 延迟（TTFT）。
• D 节点（Decode Pool）：专门处理 Decode，配大显存带宽卡，承担吞吐。
• 跨节点 KV 传输：Prefill 完成后，把 KV Cache 从 P 节点传到 D 节点，由 D 节点继续 Decode。

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 880 340" font-family="sans-serif" font-size="12">
  <text x="440" y="22" text-anchor="middle" font-size="15" font-weight="bold">PD 分离架构</text>

  <!-- 客户端 -->
  <rect x="380" y="50" width="120" height="40" rx="6" fill="#fef9c3" stroke="#ca8a04"/>
  <text x="440" y="75" text-anchor="middle">客户端请求</text>

  <!-- 路由 -->
  <rect x="350" y="110" width="180" height="40" rx="6" fill="#dbeafe" stroke="#2563eb"/>
  <text x="440" y="135" text-anchor="middle">Router</text>

  <!-- P 池 -->
  <rect x="40" y="180" width="280" height="100" rx="8" fill="#dcfce7" stroke="#16a34a"/>
  <text x="180" y="205" text-anchor="middle" font-weight="bold" fill="#15803d">P 池（Prefill）</text>
  <text x="180" y="225" text-anchor="middle" font-size="11">配大算力卡（H100）</text>
  <text x="180" y="245" text-anchor="middle" font-size="11">承担 TTFT</text>
  <text x="180" y="265" text-anchor="middle" font-size="11">计算密集优化</text>

  <!-- D 池 -->
  <rect x="560" y="180" width="280" height="100" rx="8" fill="#fce7f3" stroke="#db2777"/>
  <text x="700" y="205" text-anchor="middle" font-weight="bold" fill="#9d174d">D 池（Decode）</text>
  <text x="700" y="225" text-anchor="middle" font-size="11">配大显存带宽卡</text>
  <text x="700" y="245" text-anchor="middle" font-size="11">承担吞吐</text>
  <text x="700" y="265" text-anchor="middle" font-size="11">内存密集优化</text>

  <!-- 跨节点 KV 传输 -->
  <line x1="180" y1="150" x2="180" y2="180" stroke="#16a34a" stroke-width="2" marker-end="url(#arr8)"/>
  <line x1="700" y1="180" x2="700" y2="150" stroke="#db2777" stroke-width="2" marker-end="url(#arr8)"/>
  <line x1="180" y1="150" x2="440" y2="110" stroke="#475569" stroke-width="1.5"/>
  <line x1="700" y1="150" x2="440" y2="110" stroke="#475569" stroke-width="1.5"/>

  <!-- KV 传输说明 -->
  <rect x="320" y="180" width="240" height="40" rx="6" fill="#fed7aa" stroke="#ea580c"/>
  <text x="440" y="205" text-anchor="middle" font-weight="bold" fill="#9a3412">跨节点 KV 传输</text>
  <text x="440" y="220" text-anchor="middle" font-size="10">Prefill 完成后传 KV 到 D 节点</text>
  <line x1="320" y1="200" x2="280" y2="200" stroke="#ea580c" stroke-width="2" marker-end="url(#arr8)"/>
  <line x1="560" y1="200" x2="600" y2="200" stroke="#ea580c" stroke-width="2" marker-end="url(#arr8)"/>

  <text x="440" y="310" text-anchor="middle" font-size="11" fill="#475569">P 池与 D 池独立扩缩、独立优化，跨节点 KV 传输是关键挑战</text>

  <defs>
    <marker id="arr8" markerWidth="10" markerHeight="10" refX="8" refY="3" orient="auto">
      <path d="M0,0 L8,3 L0,6 z" fill="#475569"/>
    </marker>
  </defs>
</svg>
​

7.4.3 PD 分离的收益

PD 分离带来的收益：

收益一：独立优化

• P 节点可以最大化 Prefill 吞吐（如用 Tensor Parallel 拆大模型、用 FP8 加速）。
• D 节点可以最大化 Decode 吞吐（如大 batch、KV Cache 量化）。

收益二：独立扩缩

• Prefill 流量增加（用户发起新请求多）→ 扩 P 池。
• Decode 流量增加（生成长回复多）→ 扩 D 池。
• 不再被迫「按总流量等比扩」，资源利用率更高。

收益三：消除 PD 干扰

• Prefill 不再阻塞 Decode（二者分在不同节点）。
• 不需要 Chunked Prefill 的妥协（虽然二者可叠加）。

收益四：更好的 SLO 保障

• TTFT 由 P 池保障（专用算力，不被 Decode 占用）。
• TPOT 由 D 池保障（专用带宽，不被 Prefill 占用）。

7.4.4 PD 分离的核心挑战：跨节点 KV 传输

PD 分离的最大挑战是「跨节点 KV 传输」——Prefill 完成后，KV Cache 要从 P 节点传到 D 节点。这个 KV Cache 可能高达几 GB（回顾 6.2 节），跨节点传输本身可能成为瓶颈。

挑战与解决：

业界已有几种 PD 分离实现：

• DistServe（学术原型）：最早系统化提出 PD 分离。
• Mooncake（Moonshot/月之暗面）：KV Cache 中心的 PD 分离架构，生产部署。
• DeepSeek 的 PD 分离：DeepSeek-V3 的生产架构，用 PD 分离大幅降本。
• vLLM/SGLang 的 PD 分离支持：开源引擎逐步支持。

💡 判读：PD 分离是「用网络带宽换架构灵活性」——用跨节点 KV 传输的代价，换取 Prefill 与 Decode 的独立优化。这个权衡在「高并发、长上下文」场景下特别划算，因为混合部署的 PD 干扰问题在这些场景被放大。但对中小流量场景，混合部署可能更简单经济。

7.4.5 多模态推理：让 LLM 处理图像/音频

多模态 LLM（如 GPT-4V、Gemini、Qwen-VL、LLaVA）能处理图像、音频、视频等非文本输入。多模态推理的工程挑战与纯文本不同：

视觉编码器 + LLM 的两段式架构

大多数多模态 LLM 是「视觉编码器 + LLM」两段式：

1. 视觉编码器（如 ViT、CLIP visual encoder）：把图像编码为一系列视觉 token（如 256-1024 个 token）。
2. 投影：把视觉 token 投影到 LLM 的 embedding 空间。
3. LLM：把视觉 token 与文本 token 拼接，正常做注意力。

多模态推理的优化挑战

• 视觉 token 数量大：一张图像编码后是数百 token，相当于增加几百 token 的 Prefill 负载。
• 视觉与文本交互：注意力要让视觉 token 与文本 token 充分交互，计算量增加。
• 编码器与 LLM 解耦：编码器通常较小（如 ViT 1B），LLM 较大（如 70B），可以分别部署、分别扩缩。

多模态推理的优化方向

• Token 压缩：减少视觉 token 数量（如 Token Merging、Patch Dropping、Q-Former）。
• 编码器量化：视觉编码器也可量化。
• 缓存视觉特征：同一张图像被多次提问时，缓存视觉 token 的 KV Cache。
• 视觉编码器专用节点：把视觉编码器单独部署，与 LLM 分离（类似 PD 分离思想）。

7.4.6 Agent 推理：多轮调用的 KV 复用

Agent（智能体） 是 LLM 应用的下一形态——LLM 不再是「单轮问答」，而是「多轮调用工具、规划任务、执行操作」。Agent 的推理特性给优化带来新挑战与新机会。

Agent 的多轮特性

一个典型的 Agent 任务：

用户："帮我订一张明天去上海的机票"
LLM：
  - 轮 1：思考 + 调用工具 search_flights(date="2026-07-20", to="上海")
  - 工具返回：航班列表
  - 轮 2：思考 + 调用工具 book_flight(flight_id="CA1234")
  - 工具返回：预订成功
  - 轮 3：回复用户"已为您预订 CA1234 航班"
​

每一轮 LLM 调用都要重新跑一次推理，但前几轮的对话历史会反复出现在后续每一轮中。如果不优化，每轮都要重新计算前几轮的 KV Cache。

Agent 推理的 KV 复用

Agent 推理的核心优化是 KV Cache 跨轮复用：

• 第 N 轮的输入 = 第 N-1 轮的输入 + 第 N-1 轮的输出 + 工具返回。
• 第 N-1 轮的输入部分的 KV Cache 完全没变，可以复用！
• 只需为「第 N-1 轮输出 + 工具返回」这部分新内容计算 KV。

这与第 6 章 6.3 节的 Prefix Caching 是同一思想——多轮 Agent 是「不断增长的前缀」，每轮只增加少量内容。Prefix Caching 让 Agent 推理的成本随轮次增加而线性降低（而非每轮全算）。

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 880 260" font-family="sans-serif" font-size="12">
  <text x="440" y="22" text-anchor="middle" font-size="15" font-weight="bold">Agent 推理的 KV Cache 跨轮复用</text>

  <!-- 轮 1 -->
  <rect x="40" y="60" width="800" height="40" rx="4" fill="#dbeafe" stroke="#2563eb"/>
  <text x="50" y="85" font-size="11">轮 1：[System Prompt + 用户问题] → KV Cache 1（全算）</text>

  <!-- 轮 2 -->
  <rect x="40" y="110" width="800" height="40" rx="4" fill="#dcfce7" stroke="#16a34a"/>
  <rect x="40" y="115" width="600" height="30" fill="#16a34a" opacity="0.3"/>
  <text x="50" y="135" font-size="11">轮 2：[KV1 复用 ✓] + [轮1输出 + 工具返回]（新算）→ KV Cache 2</text>

  <!-- 轮 3 -->
  <rect x="40" y="160" width="800" height="40" rx="4" fill="#fef9c3" stroke="#ca8a04"/>
  <rect x="40" y="165" width="700" height="30" fill="#ca8a04" opacity="0.3"/>
  <text x="50" y="185" font-size="11">轮 3：[KV2 复用 ✓] + [轮2输出 + 工具返回]（新算）→ KV Cache 3</text>

  <text x="440" y="230" text-anchor="middle" font-size="11" fill="#16a34a" font-style="italic">每轮只算新增部分，前缀 KV 复用 → 多轮 Agent 成本随轮次线性下降</text>
</svg>
​

Agent 推理的优化技术

• Prefix Caching：跨轮复用 KV Cache（vLLM 默认支持）。
• Session Affinity：同一会话的请求路由到同一节点（命中 KV Cache）。
• 长上下文优化：Agent 轮次多了上下文会很长，需要高效长上下文推理。
• 工具调用的延迟隐藏：LLM 等工具返回时空闲，可以做其他请求。

Agent 推理的架构变化

Agent 流行推动了 LLM 推理服务的架构变化：

• Session 概念：从「无状态请求」转向「有状态会话」。
• KV Cache 持久化：会话级别的 KV Cache 跨请求持久化。
• 会话路由：会话亲和路由，保证命中缓存。
• 长上下文支持：支持数十万 token 的上下文（KV Cache 量极大）。

这些变化让 LLM 推理服务从「HTTP API」向「有状态推理平台」演进，是 2024 年以来的重要趋势。

7.4.7 长上下文推理：从 4K 到 1M

LLM 的上下文长度从早期的 2K、4K 一路增长到 128K、1M（如 Gemini 1.5 Pro）。长上下文推理的工程挑战：

• KV Cache 极大：1M token 的 KV Cache 可达数十 GB，单卡装不下。
• 注意力计算 O(n²)：朴素注意力对长序列计算量爆炸，需要 FlashAttention 等优化。
• Prefill 极慢：长 prompt 的 Prefill 耗时极长。

优化方向：

• FlashAttention：分块计算注意力，减少显存读写，是长上下文的基础。
• 稀疏注意力：只算部分注意力对（如 Sliding Window Attention、Longformer），降低 O(n²)。
• Ring Attention：跨节点分片计算长序列注意力。
• KV Cache offload：把 KV Cache 卸载到 CPU 内存或 NVMe（vLLM 的 CPU offload）。
• KV Cache 压缩：丢弃不重要的 KV（如 H2O、StreamingLLM 的 attention sink）。

长上下文是 LLM 推理的前沿，许多技术仍在快速演进。

7.4.8 第 7 章小结与第 8 章预告

到这里，第 7 章完成了「高效交付层」的进阶内容：

1. Chunked Prefill（7.1）：调度层优化，平衡 Prefill 与 Decode。
2. 模型量化（7.2）：降本第一性武器，INT4/INT8/AWQ/GPTQ。
3. Speculative Decoding（7.3）：无损加速，草稿-校验。
4. PD 分离与多模态/Agent 推理（7.4）：架构级创新。

加上第 6 章的基础（服务化架构、PagedAttention），第 6-7 章合起来回答了「LLM 怎么高效交付」的完整问题。第 8 章将进入最后一层——「稳定运行层」，讲清这些推理服务上线后如何监控、扩缩容、保障稳定性。

本节小结

• PD 分离把 Prefill 与 Decode 拆到不同节点，各自最优，独立扩缩，消除 PD 干扰。
• PD 分离的核心挑战是跨节点 KV 传输，需要 RDMA/IB 高速网络、KV 压缩、异步传输。
• 多模态 LLM 是「视觉编码器 + LLM」两段式，视觉 token 数量大、与文本交互。
• 多模态优化：Token 压缩、编码器量化、视觉特征缓存、编码器专用节点。
• Agent 推理是多轮调用，KV Cache 跨轮复用是核心优化（Prefix Caching）。
• Agent 推理推动 LLM 服务从「无状态 API」向「有状态会话平台」演进。
• 长上下文（128K-1M）的挑战：KV Cache 极大、注意力 O(n²)、Prefill 极慢。
• 长上下文优化：FlashAttention、稀疏注意力、Ring Attention、KV offload、KV 压缩。
• 这些方向是 LLM 推理的前沿，未来 1-2 年的工程热点。

第 7 章完结。下一章《第 8 章 可观测性、弹性扩缩容与大流量稳定性》将进入最后一层——稳定运行层。