<?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>Serving on 我的技术博客</title><link>https://cybersecurityerial.github.io/echo_blog/tags/serving/</link><description>Recent content in Serving on 我的技术博客</description><generator>Hugo</generator><language>zh-cn</language><lastBuildDate>Sun, 10 May 2026 12:46:00 +0800</lastBuildDate><atom:link href="https://cybersecurityerial.github.io/echo_blog/tags/serving/index.xml" rel="self" type="application/rss+xml"/><item><title>LLM System: PD 分离 00 - 学习地图</title><link>https://cybersecurityerial.github.io/echo_blog/posts/llm-system-pd-00-roadmap/</link><pubDate>Tue, 05 May 2026 10:30:00 +0800</pubDate><guid>https://cybersecurityerial.github.io/echo_blog/posts/llm-system-pd-00-roadmap/</guid><description>&lt;blockquote&gt;
&lt;p&gt;这篇文章是 LLM System 系列里 PD 分离子专题的第 0 篇，也是这个主题的学习入口。是笔者让gpt-5.5通过联网搜索帮自己制定的系统性学习方案。笔者会根据这个方案来确定如何学习PD分离的整套机制。目标不是先把所有论文细节读完，而是先建立一张可以持续填充的地图：该读什么、该推导什么、该写什么代码、最后应该能回答什么问题。&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;这个系列暂时围绕一个问题展开：&lt;strong&gt;为什么现代 LLM serving 系统越来越关心 prefill/decode disaggregation，也就是 PD 分离？&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;我希望自己最后能回答四个问题：&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"&gt;&lt;code class="language-text" data-lang="text"&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;1. 为什么 prefill 和 decode 要分离？
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;2. 一个 workload 到底该配多少 P worker、多少 D worker？
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;3. KV cache 从 P 到 D 传输到底传了什么、代价多大？
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;4. vLLM / SGLang / Mooncake 里这件事具体怎么落地？
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;先说一个结论：**PD 分离不是一个“拆进程就能变快”的魔法优化。**它真正解决的是服务系统里的资源解耦问题：prefill compute、decode iteration、KV cache 生命周期、网络传输和调度策略，本来在 colocated serving 里被绑在一起；PD 分离试图把它们拆开，让不同阶段按照不同目标优化。&lt;/p&gt;
&lt;h2 id="0-心智模型"&gt;0. 心智模型&lt;/h2&gt;
&lt;p&gt;LLM 推理一个请求大致分成两段。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Prefill&lt;/strong&gt;：一次性吃掉 prompt，生成整段 prompt 的 KV cache，并产出第一个 token。长输入时它更像大 GEMM，通常更容易把 GPU 算力吃满。它最直接影响的是 &lt;strong&gt;TTFT&lt;/strong&gt;，也就是 time to first token。&lt;/p&gt;</description></item><item><title>LLM System: KV Cache 查询 01 - PagedAttention 原理</title><link>https://cybersecurityerial.github.io/echo_blog/posts/llm-system-kvcache-01-pagedattention-principle/</link><pubDate>Sun, 10 May 2026 12:46:00 +0800</pubDate><guid>https://cybersecurityerial.github.io/echo_blog/posts/llm-system-kvcache-01-pagedattention-principle/</guid><description>&lt;blockquote&gt;
&lt;p&gt;TODO: 这里写 PagedAttention 的核心抽象：block/page、block table、逻辑 token 到物理 KV block 的映射。&lt;/p&gt;
&lt;/blockquote&gt;
&lt;h2 id="基础tensor-级拆请求的形状大量细节"&gt;基础：tensor 级拆请求的形状（大量细节）&lt;/h2&gt;
&lt;p&gt;定义符号：$B$ 是 batch size，$T$ 是 seq_len，$D$ 是 token_dim，$d_q$ 是把 embedding token 投影到 $Q$ 后的维度。&lt;/p&gt;
&lt;p&gt;推理框架拿到的请求是：\(R \in \mathbb{R}^{B \times T}\)。&lt;/p&gt;
&lt;p&gt;$R_{b,t}$ 是一个最最基本的 token id 标量。&lt;/p&gt;
&lt;p&gt;raw 请求经过 embedding lookup，做的操作是把这个 token 标量映射成一个高维向量。假设原先 token 是 &lt;code&gt;1234&lt;/code&gt; 这个标量，现在就把 token 映射成 &lt;code&gt;[0.1, 0.2, 0.3, 0.4]&lt;/code&gt; 这样的向量。&lt;/p&gt;
&lt;p&gt;所以 $R$ 经过 embedding lookup 之后，得到：\(X \in \mathbb{R}^{B \times T \times D}\)。&lt;/p&gt;
&lt;p&gt;因为我们目前只考虑推理场景，所以把 $W_Q$、$W_K$、$W_V$ 之类的矩阵当成固定的模型参数。&lt;/p&gt;
&lt;p&gt;然后很多博客会直接写：\(Q = XW_Q\)。&lt;/p&gt;</description></item></channel></rss>