Llm-D - 태그 - lee's bloghttps://ken-0913.github.io/myblog/tags/llm-d/Llm-D - 태그 - lee's blogHugo -- gohugo.ioko-krhyeonjae0913@gmail.com (ken-0913)hyeonjae0913@gmail.com (ken-0913)Fri, 18 Sep 2026 00:40:00 +0900LLM 스터디 7주차 - llm-d P/D Disaggregation — prefill과 decode를 떼어놓는 이유https://ken-0913.github.io/myblog/posts/llm/llm-d-pd-disaggregation/Fri, 18 Sep 2026 00:40:00 +0900ken-0913https://ken-0913.github.io/myblog/posts/llm/llm-d-pd-disaggregation/

LLM 추론은 성격이 전혀 다른 두 단계로 이루어진다. 이 둘을 같은 GPU에서 돌리면 서로를 방해한다.

P/D Disaggregation은 그 둘을 아예 다른 서버로 떼어놓는 방식이다. llm-d는 이 기능을 개념편에서 정리한 EPP에 기본으로 내장하고 있다.

이 글은 llm-d 공식 가이드와 저장소의 실제 매니페스트를 근거로 구조를 정리한다. 가이드의 기준 구성은 GPU 16장이지만, 마지막 절에서는 RTX 3050 6GB 한 장을 논리적으로 둘로 나눠 실제로 띄워본 결과를 함께 싣는다.

용어 쉬운 설명
Prefill 입력 프롬프트 전체를 한 번에 읽어서 이해하는 단계
Decode 답변을 한 글자씩 만들어내는 단계
ISL / OSL Input/Output Sequence Length. 입력이 10,000 토큰, 출력이 1,000 토큰이면 10:1
TTFT 첫 글자가 나오기까지 걸린 시간. 주로 prefill이 좌우한다
ITL 글자와 글자 사이 간격. 주로 decode가 좌우한다
Prefill Decode
하는 일 프롬프트 전체를 한 번의 forward pass로 처리 KV 캐시에서 토큰을 하나씩 생성
병목 연산(compute-bound) GPU flops 메모리 대역폭(memory-bandwidth-bound) HBM에서 on-chip으로 데이터를 얼마나 빨리 옮기는가
성격 짧고 폭발적 길고 지속적
영향 지표 TTFT ITL

한 GPU에 섞어두면 문제가 생긴다. 긴 프롬프트의 prefill이 들어오는 순간 GPU 연산이 거기에 묶이고, 이미 답변을 뱉고 있던 decode 요청들이 그동안 멈춘다.

]]>LLM 스터디 7주차 - llm-d Flow Control 실측 — TTFT는 사라지지 않고 옮겨간다https://ken-0913.github.io/myblog/posts/llm/llm-d-flow-control-lab/Fri, 18 Sep 2026 00:30:00 +0900ken-0913https://ken-0913.github.io/myblog/posts/llm/llm-d-flow-control-lab/

개념편에서 EPP의 파이프라인을 정리하며 Flow Control을 문서 수준으로만 다뤘다. 이번에는 실제로 켜고 부하를 넣어 큐가 어디에 쌓이는지 를 눈으로 확인했다.

GPU는 RTX 3050 6GB 한 장, vLLM replica는 1개다. 작은 GPU가 오히려 유리하다. Flow Control의 동작은 전부 “풀이 포화됐을 때” 나타나는데, GPU가 작을수록 포화를 만들기 쉽다.

가장 중요한 결과부터 적는다. Flow Control을 켜도 총 대기시간은 줄지 않는다. 기다리는 장소가 GPU에서 게이트웨이로 옮겨갈 뿐이다. 공식 문서도 같은 말을 한다 — “controlling where and for whom TTFT is accrued”.

]]>LLM 스터디 7주차 - kind에 llm-d 올리기 — 배포부터 게이트웨이 오버헤드 실측까지https://ken-0913.github.io/myblog/posts/llm/llm-d-prefix-cache-lab/Thu, 17 Sep 2026 22:00:00 +0900ken-0913https://ken-0913.github.io/myblog/posts/llm/llm-d-prefix-cache-lab/

개념편에서 llm-d가 요청마다 목적지를 다시 고른다는 구조를 정리했다. 그 구조에는 값이 붙는다. 매 요청마다 Envoy가 EPP에게 물어보고 답을 기다린다면, 그 대기는 몇 ms인가.

RTX 3050 한 장이 꽂힌 데스크톱에 kind로 클러스터를 만들고 llm-d를 올려 직접 쟀다. 결론은 TTFT 기준 +2.36 ms, prefix cache 적중률 84.5% 다.

공식 가이드의 기준 구성은 Qwen3-32B / H100 80GB / GPU 16장이다. 이 글은 그것을 GPU 1장 6GB로 줄여 올리는 과정과, 그렇게 줄인 환경에서 무엇을 잴 수 있는지를 함께 다룬다.

]]>LLM 스터디 7주차 - llm-d 아키텍처 — KV 캐시를 아는 게이트웨이https://ken-0913.github.io/myblog/posts/llm/llm-d-architecture/Wed, 16 Sep 2026 21:00:00 +0900ken-0913https://ken-0913.github.io/myblog/posts/llm/llm-d-architecture/

성능관점에서 vLLM 파드 중 “어느 파드로 보낼 것인가” 가는 중요한 요소이다. llm-d는 이를 해결 하는  Kubernetes 네이티브 추론 서빙 스택이다.

CNCF 샌드박스 프로젝트이며, vLLM이나 SGLang 같은 엔진을 래핑하여 확장한다. 이 글은 llm-d 공식 문서를 읽고 구조를 정리한 개념편이다.

Kubernetes Service는 L4 로드밸런서다. kube-proxy는 TCP 연결 단위로 목적지를 무작위 배정하고, 그 뒤로는 keep-alive 때문에 같은 파드에 고착된다.

일반 요청이라면 문제가 없다. 하지만 LLM 추론은 두 가지 이유로 다르다.

]]>