<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Pd-Disaggregated on Wilson Wu</title><link>https://wilsonwu.me/zh/tags/pd-disaggregated/</link><description>Recent content in Pd-Disaggregated on Wilson Wu</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Mon, 22 Dec 2025 00:00:00 -0500</lastBuildDate><atom:link href="https://wilsonwu.me/zh/tags/pd-disaggregated/index.xml" rel="self" type="application/rss+xml"/><item><title>大语言模型（LLM）推理加速：预填充（Prefill）和解码（Decode）解耦（PD 分离）</title><link>https://wilsonwu.me/zh/blog/2025/llm-pd-disaggregated/</link><pubDate>Mon, 22 Dec 2025 00:00:00 -0500</pubDate><guid>https://wilsonwu.me/zh/blog/2025/llm-pd-disaggregated/</guid><description>&lt;p&gt;随着大语言模型（LLM）在对话系统、智能助手和 Agent 场景中的广泛落地，推理系统面临的核心挑战已从“能不能跑”转向“&lt;strong&gt;如何以更低延迟、更高吞吐、更稳定的方式运行&lt;/strong&gt;”。在这一背景下，&lt;strong&gt;PD Disaggregated（Prefill / Decode 解耦）&lt;/strong&gt; 逐渐成为大规模在线推理系统中的关键架构思想。&lt;/p&gt;</description><content:encoded><![CDATA[<p>随着大语言模型（LLM）在对话系统、智能助手和 Agent 场景中的广泛落地，推理系统面临的核心挑战已从“能不能跑”转向“<strong>如何以更低延迟、更高吞吐、更稳定的方式运行</strong>”。在这一背景下，<strong>PD Disaggregated（Prefill / Decode 解耦）</strong> 逐渐成为大规模在线推理系统中的关键架构思想。</p>
<p>本文将不依赖任何具体推理框架，从 <strong>模型推理执行流</strong> 的角度，系统阐述什么是 PD Disaggregated、为什么需要它，以及它为 LLM 推理系统带来的核心优势。</p>
<h2 id="llm-推理的两个本质阶段">LLM 推理的两个本质阶段</h2>
<p>所有自回归大语言模型的推理过程，本质上都可以拆解为两个阶段：</p>
<p><img alt="两个阶段" loading="lazy" src="/zh/blog/2025/llm-pd-disaggregated/1-inference-2-phase.png"></p>
<h3 id="prefill预填充阶段">Prefill（预填充阶段）</h3>
<p>Prefill 阶段负责处理用户输入的完整 Prompt，其主要任务包括：</p>
<ul>
<li>对输入序列进行一次完整前向计算；</li>
<li>构建上下文对应的 KV Cache；</li>
<li>生成第一个输出 Token。</li>
</ul>
<p>这一阶段具有如下特征：</p>
<ul>
<li><strong>计算密集型（Compute-bound）</strong></li>
<li>大规模矩阵乘法（GEMM）占主导</li>
<li>序列长度通常较长</li>
<li>对批处理（Batching）高度友好</li>
</ul>
<h3 id="decode解码阶段">Decode（解码阶段）</h3>
<p>Decode 阶段进入逐 Token 生成过程，每一步都会：</p>
<ul>
<li>输入上一个生成的 Token；</li>
<li>读取历史 KV Cache；</li>
<li>生成下一个 Token，直到结束条件满足。</li>
</ul>
<p>其特征与 Prefill 明显不同：</p>
<ul>
<li><strong>访存密集型（Memory-bound）</strong></li>
<li>计算规模小，但 KV Cache 访问频繁</li>
<li>强延迟敏感</li>
<li>执行步数随生成长度线性增长</li>
</ul>
<h2 id="问题根源prefill-与-decode-的异构性">问题根源：Prefill 与 Decode 的“异构性”</h2>
<p>Prefill 与 Decode 并非同一类工作负载，它们在多个维度上呈现出<strong>显著异构性</strong>：</p>
<table>
	<thead>
			<tr>
					<th>维度</th>
					<th>Prefill</th>
					<th>Decode</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td>计算模式</td>
					<td>大算子、密集计算</td>
					<td>小算子、频繁访存</td>
			</tr>
			<tr>
					<td>批处理需求</td>
					<td>大 batch 效果最好</td>
					<td>batch 过大反而增加延迟</td>
			</tr>
			<tr>
					<td>延迟容忍度</td>
					<td>相对较高</td>
					<td>极低</td>
			</tr>
			<tr>
					<td>资源瓶颈</td>
					<td>算力</td>
					<td>显存带宽 / KV Cache</td>
			</tr>
	</tbody>
</table>
<p>如果将这两种阶段<strong>混合部署、统一调度</strong>，就会导致资源使用上的结构性低效。</p>
<h2 id="什么是-pd-disaggregated">什么是 PD Disaggregated</h2>
<p><strong>PD Disaggregated（Prefill / Decode 解耦）</strong>，指的是在推理系统架构层面：</p>

<blockquote>
  <p><strong>将 Prefill 与 Decode 视为两类不同的工作负载，并在调度、资源分配甚至部署拓扑上对它们进行解耦设计。</strong></p>

</blockquote>
<p>需要强调的是：</p>
<ul>
<li>这并不是模型结构的拆分；</li>
<li>也不是参数的拆分；</li>
<li>而是<strong>推理执行路径与资源使用方式的解耦</strong>。</li>
</ul>
<p>PD Disaggregated 的核心思想是：
<strong>让 Prefill 为吞吐服务，让 Decode 为延迟服务。</strong></p>
<h2 id="为什么必须进行-pd-解耦">为什么必须进行 PD 解耦</h2>
<h3 id="gpu-利用率的结构性浪费">GPU 利用率的结构性浪费</h3>
<p>混合执行时常见现象包括：</p>
<ul>
<li>Decode 阶段算子太小，GPU 算力无法被充分利用；</li>
<li>Prefill 阶段的大算子又会阻塞 Decode；</li>
<li>结果是整体 GPU 利用率“看起来不低，但效率很差”。</li>
</ul>
<p>PD 解耦后，可以针对不同阶段采用不同的调度和批策略，显著改善有效算力利用。</p>
<h3 id="延迟不可预测尾延迟恶化">延迟不可预测，尾延迟恶化</h3>
<p>在在线推理场景中，Decode 阶段直接决定用户体验：</p>
<ul>
<li>首 Token 延迟（TTFT）</li>
<li>单 Token 延迟（TPOT）</li>
<li>P99 / P999 延迟</li>
</ul>
<p>如果 Decode 被 Prefill 阻塞，哪怕吞吐提升，用户体验也会显著下降。
PD Disaggregated 能从架构层面<strong>隔离延迟敏感路径</strong>。</p>
<h3 id="扩展性受限">扩展性受限</h3>
<p>在混合架构下：</p>
<ul>
<li>Prefill 和 Decode 只能按同一比例扩容；</li>
<li>无法根据实际负载特征独立扩展某一阶段。</li>
</ul>
<p>而真实业务中：</p>
<ul>
<li>Chat、Agent 场景 Decode 占比极高；</li>
<li>离线生成、批处理 Prefill 占比更高。</li>
</ul>
<p>PD 解耦使得 <strong>按阶段独立扩展成为可能</strong>。</p>
<h2 id="pd-disaggregated-的典型架构形态">PD Disaggregated 的典型架构形态</h2>
<p>在工程实践中，PD Disaggregated 通常体现为以下形式之一：</p>
<h3 id="调度级解耦soft-disaggregation">调度级解耦（Soft Disaggregation）</h3>
<ul>
<li>Prefill 与 Decode 共享模型参数；</li>
<li>但在调度层面对二者区别对待；</li>
<li>Decode 拥有更高优先级。</li>
</ul>
<p>这是最轻量、最容易落地的形态。</p>
<h3 id="资源级解耦resource-disaggregation">资源级解耦（Resource Disaggregation）</h3>
<ul>
<li>Prefill 与 Decode 使用不同的 GPU 资源池；</li>
<li>Prefill GPU 偏向算力型；</li>
<li>Decode GPU 偏向显存带宽与 KV Cache 容量。</li>
</ul>
<p>该模式在大规模集群中尤为常见。</p>
<h3 id="服务级解耦service-disaggregation">服务级解耦（Service Disaggregation）</h3>
<ul>
<li>Prefill 与 Decode 成为独立服务；</li>
<li>中间通过 KV Cache 或状态句柄连接；</li>
<li>可独立伸缩、独立调度。</li>
</ul>
<p>这是 PD Disaggregated 的“完全形态”，也是复杂度最高的一种。</p>
<h2 id="pd-disaggregated-带来的核心优势">PD Disaggregated 带来的核心优势</h2>
<h3 id="更高吞吐与更低延迟并存">更高吞吐与更低延迟并存</h3>
<p>传统架构往往需要在吞吐与延迟之间取舍，而 PD 解耦允许：</p>
<ul>
<li>Prefill 极致批量化；</li>
<li>Decode 极致低延迟。</li>
</ul>
<h3 id="更稳定的尾延迟">更稳定的尾延迟</h3>
<p>Decode 不再被大规模 Prefill 阻塞，P99 / P999 延迟显著改善，这对生产系统至关重要。</p>
<h3 id="更合理的资源利用">更合理的资源利用</h3>
<p>不同阶段匹配不同资源类型，避免“用算力型 GPU 跑访存密集任务”这类结构性浪费。</p>
<h3 id="更强的系统演进能力">更强的系统演进能力</h3>
<p>PD Disaggregated 为后续优化打开空间，例如：</p>
<ul>
<li>KV Cache 分层存储；</li>
<li>Decode 专用硬件；</li>
<li>面向 Agent 的长时会话优化。</li>
</ul>
<h2 id="总结">总结</h2>
<p>PD Disaggregated 并不是某个框架的特性，而是<strong>对 LLM 推理本质的抽象与再设计</strong>：</p>
<ul>
<li>Prefill 和 Decode 在计算形态上天然异构；</li>
<li>强行混合只会掩盖效率问题；</li>
<li>解耦是走向规模化、高质量推理服务的必经之路。</li>
</ul>
<p>可以预见，随着模型规模继续增长、应用形态日益复杂，<strong>PD Disaggregated 将从“高级优化”演变为 LLM 推理系统的默认架构假设</strong>。</p>
]]></content:encoded></item></channel></rss>