<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>PD Disaggregation - 태그 - lee's blog</title><link>https://ken-0913.github.io/myblog/tags/pd-disaggregation/</link><description>PD Disaggregation - 태그 - lee's blog</description><generator>Hugo -- gohugo.io</generator><language>ko-kr</language><managingEditor>hyeonjae0913@gmail.com (ken-0913)</managingEditor><webMaster>hyeonjae0913@gmail.com (ken-0913)</webMaster><lastBuildDate>Fri, 18 Sep 2026 00:40:00 +0900</lastBuildDate><atom:link href="https://ken-0913.github.io/myblog/tags/pd-disaggregation/" rel="self" type="application/rss+xml"/><item><title>LLM 스터디 7주차 - llm-d P/D Disaggregation — prefill과 decode를 떼어놓는 이유</title><link>https://ken-0913.github.io/myblog/posts/llm/llm-d-pd-disaggregation/</link><pubDate>Fri, 18 Sep 2026 00:40:00 +0900</pubDate><author><name>ken-0913</name></author><guid>https://ken-0913.github.io/myblog/posts/llm/llm-d-pd-disaggregation/</guid><description><![CDATA[<div class="featured-image">
                <img src="images/banners/llm-d-pd-disaggregation-d97a078e.png" referrerpolicy="no-referrer">
            </div><p>LLM 추론은 성격이 전혀 다른 두 단계로 이루어진다. <strong>이 둘을 같은 GPU에서 돌리면 서로를 방해한다.</strong></p>
<p>P/D Disaggregation은 그 둘을 아예 다른 서버로 떼어놓는 방식이다. llm-d는 이 기능을 <a href="../llm-d-architecture/" rel="">개념편</a>에서 정리한 EPP에 기본으로 내장하고 있다.</p>
<p>이 글은 llm-d 공식 가이드와 저장소의 실제 매니페스트를 근거로 구조를 정리한다. 가이드의 기준 구성은 <strong>GPU 16장</strong>이지만, 마지막 절에서는 <strong>RTX 3050 6GB 한 장을 논리적으로 둘로 나눠 실제로 띄워본 결과</strong>를 함께 싣는다.</p>
<h2 id="1-용어정리" class="headerLink">
    <a href="#1-%ec%9a%a9%ec%96%b4%ec%a0%95%eb%a6%ac" class="header-mark"></a>1. 용어정리</h2><table>
	<thead>
			<tr>
					<th>용어</th>
					<th>쉬운 설명</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td><strong>Prefill</strong></td>
					<td>입력 프롬프트 전체를 <strong>한 번에</strong> 읽어서 이해하는 단계</td>
			</tr>
			<tr>
					<td><strong>Decode</strong></td>
					<td>답변을 <strong>한 글자씩</strong> 만들어내는 단계</td>
			</tr>
			<tr>
					<td><strong>ISL / OSL</strong></td>
					<td>Input/Output Sequence Length. 입력이 10,000 토큰, 출력이 1,000 토큰이면 10:1</td>
			</tr>
			<tr>
					<td><strong>TTFT</strong></td>
					<td>첫 글자가 나오기까지 걸린 시간. 주로 <strong>prefill</strong>이 좌우한다</td>
			</tr>
			<tr>
					<td><strong>ITL</strong></td>
					<td>글자와 글자 사이 간격. 주로 <strong>decode</strong>가 좌우한다</td>
			</tr>
	</tbody>
</table>
<h2 id="2-prefill과-decode비교" class="headerLink">
    <a href="#2-prefill%ea%b3%bc-decode%eb%b9%84%ea%b5%90" class="header-mark"></a>2. Prefill과 Decode비교</h2><table>
	<thead>
			<tr>
					<th></th>
					<th>Prefill</th>
					<th>Decode</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td>하는 일</td>
					<td>프롬프트 전체를 한 번의 forward pass로 처리</td>
					<td>KV 캐시에서 토큰을 하나씩 생성</td>
			</tr>
			<tr>
					<td>병목</td>
					<td><strong>연산(compute-bound)</strong> GPU flops</td>
					<td><strong>메모리 대역폭(memory-bandwidth-bound)</strong> HBM에서 on-chip으로 데이터를 얼마나 빨리 옮기는가</td>
			</tr>
			<tr>
					<td>성격</td>
					<td>짧고 폭발적</td>
					<td>길고 지속적</td>
			</tr>
			<tr>
					<td>영향 지표</td>
					<td>TTFT</td>
					<td>ITL</td>
			</tr>
	</tbody>
</table>
<p><strong>한 GPU에 섞어두면 문제가 생긴다.</strong> 긴 프롬프트의 prefill이 들어오는 순간 GPU 연산이 거기에 묶이고, 이미 답변을 뱉고 있던 decode 요청들이 그동안 멈춘다.</p>]]></description></item></channel></rss>