2단계 머신: LLM 요청은 트렌치코트 속의 두 가지 작업

LLM에 보내는 모든 API 호출은 사실 붙어 있는 두 개의 작업을 비밀리에 수행합니다. 첫 번째 작업은 전체 프롬프트를 거대한 행렬 곱셈으로 읽어 들입니다. 이는 컴퓨팅 바운드(compute-bound)이며, GPU가 최대 속도로 작동합니다. 두 번째 작업은 토큰을 하나씩 흘려보내는데, 각 단계마다 전체 대화 기록을 메모리에서 다시 읽습니다. 이는 메모리 대역폭 바운드(memory-bandwidth-bound)이며, GPU는 대부분 유휴 상태입니다. 이 둘을 같은 GPU에서 실행하면 서로를 방해합니다. 6개 연구소에서 독립적으로 도달한 업계의 2026년 해답은 이것입니다: 이들을 같은 GPU에서 실행하지 마십시오. 프리필(prefill)과 디코드(decode)를 분리하면, GPU당 처리량(throughput)이 대략 두 배가 됩니다.

초등학생도 이해하는 설명: 주방과 배달 트럭

식당을 생각해 보세요. 주방(prefill)은 전체 주문을 한 번에 요리합니다. 빠르고 배치 처리에 유리하며, 오븐이 가득 차 있습니다. 배달 트럭(decode)은 한 번에 하나의 상자를 운반합니다. 속도 제한은 얼마나 빨리 트럭을 싣느냐에 달려있지, 얼마나 빨리 운전하느냐가 아닙니다. 이제 이 둘의 역할을 모두 해야 하는 차량을 상상해 보세요. 배달 스케줄이 요리를 망치고, 요리가 배달을 망칩니다.

과거에는 모든 서비스 엔진이 이런 형태였습니다. 짧은

KV 캐시(The KV cache). 디코딩 과정에서 모델은 프롬프트에 대한 어텐션(attention)을 재계산하지 않습니다. 대신 키/값 벡터(key/value vectors)를 캐싱하고 매 스텝마다 이를 읽어옵니다. 8k 토큰짜리 프롬프트는 모든 토큰마다 GPU 메모리에서 읽어야 하는 8k 개의 상태 벡터가 됩니다. 디코딩은 수학 문제가 아니라 메모리 문제입니다. 이 사실 하나만으로도 다운스트림(downstream)의 거의 모든 것을 설명할 수 있습니다.
PagedAttention (vLLM). 이전에는 KV 캐시를 요청당 하나의 연속된 청크로 할당했습니다. 마치 각 차량을 자체 전용 주차장에 주차하는 것과 같았습니다. 내부 단편화(Internal fragmentation)가 VRAM의 최대 80%까지 낭비했습니다. PagedAttention은 가상 메모리(virtual memory)의 OS 트릭을 차용합니다: 고정 크기의 블록, 비연속적이며 요청 간 공유됩니다. 낭비율이 ~80%에서 4% 미만으로 떨어졌습니다. 같은 GPU로 다섯 배의 동시 요청 처리가 가능해졌습니다.
지속 배치(Continuous batching) (Orca). 이전 서버들은 배치 내 가장 느린 요청이 완료될 때까지 기다렸다가 새로운 것을 시작했습니다. 마치 모든 승객이 목적지에 도착할 때까지 떠나지 않는 버스와 같습니다. 지속 배치는 반복마다 요청을 추가하고 제거합니다: 완료된 요청의 슬롯은 즉시 재활용됩니다. 후미(tail) 부분에 유휴 시간이 없습니다.
청크형 프리필(Chunked prefill) (Sarathi-Serve). 32k 토큰짜리 프롬프트의 프리필(prefill)이 디코딩을 몇 초 동안 지연시킬 수 있습니다. 이를 청크로 나눕니다: 프리필을 조각으로 나누어 각 조각을 디코딩 반복에 태워나갑니다. 레이턴시 스파이크가 완만해지고, GPU는 디코딩의 메모리 제한 단계에서도 컴퓨팅 포화 상태를 유지합니다.
접두사 캐싱(Prefix caching) (SGLang's RadixAttention). 에이전트들은 동일한 4,000 토큰짜리 시스템 프롬프트를 하루에 수백 번 재전송합니다. 라딕스 트리(radix tree)는 계산된 접두사를 저장하고 이를 재사용하며, 따뜻하게 준비된 요청의 첫 토큰까지 걸리는 시간이 거의 0에 가깝게 줄어듭니다. Dynamo는 나중에 이 동일한 데이터 구조를 클러스터 수준으로 끌어올려 라우팅 결정에 사용했습니다.

최신 기술 동향: 분산화 물결(the disaggregation wave)

수렴 지점은 **분산 서비스(disaggregated serving)**입니다: 프리필(prefill)과 디코드(decode)를 위한 물리적으로 분리된 GPU 풀을 사용하며, KV 캐시는 이들 사이로 스트리밍됩니다. 연구 경로는 Splitwise → DistServe → Mooncake이며, 실제 제품 패키징은 NVIDIA Dynamo입니다. 이는 엔진(vLLM, SGLang, TensorRT-LLM 등) 위에 위치하는 오픈소스 오케스트레이션 레이어입니다 (엔진을 대체하는 것이 아니라, 이를 조정합니다). v0.8.0 설계 문서를 기준으로 이 장치들은 다음과 같습니다:

분산된 프리필/디코드 풀: 독립적으로 크기가 결정되고 확장됩니다. 각 단계별로 다른 SLO(Service Level Objective)가 적용됩니다: TTFT(time to first token, 첫 토큰까지 걸리는 시간) 대 TPOT(time per output token, 출력 토큰당 시간).
KV 인식 스마트 라우터: 전역 레딕스 트리 레지스트리(global radix-tree registry)를 백업으로 사용하여 요청을 캐시 적중률이 가장 높은 워커로 라우팅합니다. 이는 클러스터 전체의 접두사 재사용성을 의미합니다.
다단계 KV 블록 관리자: GPU → CPU → SSD → 오브젝트 스토리지까지 지원합니다. 왜냐하면 많은 경우 KV 블록을 전송하는 것이 다시 계산하는 것보다 빠르기 때문입니다.
NIXL: 동기화 감소를 통해 KV 캐시를 풀 사이로 이동시키는 전송 엔진입니다.
플래너(planner): SLA 신호에 따라 자동 확장됩니다. 지연 시간이 초과되기 전에, 긴 입력 트래픽의 급증이 프리필 풀을 늘립니다.

실제 워크로드에서 문서화된 결과를 보면, 주목할 만한 수치들이 있습니다. KV 인식 라우팅만으로도 TTFT가 약 3배 향상되고 평균 지연 시간이 약 2배 개선되었습니다. 이는 H100에서 100,000개의 실제 DeepSeek R1 쿼리를 측정했을 때의 결과입니다. 분산 서비스는 Llama-70B-FP8에 대해 GPU당 처리량을 30%에서 2배 이상 향상시킵니다. 그리고 실제 배포 환경에서는: GB200에서 DeepSeek R1이 GPU당 7배의 처리량으로, Kimi K2가 10배의 추론 속도 향상을 보여줍니다. 두 가지 작업, 두 개의 플릿(fleet), 그리고 수학적으로 마침내 맞아떨어집니다.

병렬적인 돌파구는 **추측 디코딩 (speculative decoding)**입니다. 이는 출력 결과가 동일하다는 공식적인 보장을 제공하는 유일한 가속 기법입니다. 작은 초안 모델(draft model)이 여러 토큰을 제안하면, 큰 모델(big model)이 이를 단 한 번의 병렬 순방향 패스(parallel forward pass)로 검증합니다. 거부 샘플링(rejection sampling)은 최종 분포를 타겟 모델만 사용했을 때와 수학적으로 동일하게 유지합니다. 현재 지배적인 아키텍처인 EAGLE-3는 Llama-3.1-8B 모델을 단일 H100에서 158.34 토큰/초에서 373.25 토큰/초로 끌어올렸습니다 (EAGLE-2: 244.10). 이는 MT-Bench 기준으로 2.36배의 향상입니다. NVIDIA의 P-EAGLE(병렬 초안 작성, 2026년 3월)은 GPT-OSS-20B에 대해 순수 EAGLE-3 대비 낮은 동시성(low concurrency)에서 추가로 55–69%를 더했습니다. 이는 병렬적으로 모든 초안 토큰을 한 번의 순방향 패스로 생성하기 때문에, 자기회귀적(autoregressively)으로 생성하는 방식보다 효율적이기 때문입니다.

벤치마크가 보여주는 두 가지 솔직한 주의사항이 있습니다. 첫째, 성능 향상은 배치 크기(batch-size)에 따라 달라집니다. vLLM에서 EAGLE-3의 배치 크기 2에서의 1.75배 증가는 배치 크기 56에서는 1.01배로 감소합니다. 즉, 포화 상태(saturation)에서는 검증 오버헤드가 초안으로 얻은 이득을 상쇄합니다. 추측 디코딩은 처리량(throughput)이 아닌 낮은 동시성 워크로드에 대한 지연 시간(latency) 기법입니다. 둘째, 수용률(acceptance rate)이 올바른 평가 기준이 아닙니다. SPEED-Bench에서 75%의 수용률을 가진 블록 초안 작성기가 88%의 순차적 작성기보다 1.8배 더 빨랐습니다. 이는 블록 내 모든 토큰이 동일한 병렬 패스에서 계산되기 때문에, 거부 비용이 거의 들지 않기 때문입니다. 또한 성능 향상은 워크로드에 따라 다릅니다. 코딩 및 수학 프롬프트는 단계당 약 3개의 토큰을 수용하는 반면, 다국어 역할극(multilingual roleplay)은 겨우 1.7개 수준입니다. 만약 사용 트래픽이 코드라면 공격적으로 추측하고, 다국어 채팅이라면 먼저 자체 트래픽으로 측정해야 합니다.

시사점 (Takeaways)

LLM 요청은 상반된 병목 현상을 가진 두 가지 작업으로 구성됩니다. 프리필(Prefill) 단계는 컴퓨팅 바운드(compute-bound)이고, 디코드(decode) 단계는 메모리 대역폭 바운드(memory-bandwidth-bound)입니다. 서비스 스택의 모든 것은 이 분할에서 파생됩니다.
OS 플레이북이 승리했습니다. 가상 메모리(PagedAttention), 이벤트 루프 스케줄링(continuous batching), 그리고 콘텐츠 주소 지정 캐싱(content-addressed caching, RadixAttention)은 GPU 서비스를 시스템 엔지니어링으로 탈바꿈시켰습니다.
디분산화(Disaggregation)가 아키텍처의 최종 목표입니다. Splitwise, DistServe, Mooncake, 그리고 이제 NVIDIA Dynamo까지 모두 수렴했습니다: 별도의 플릿(separate fleets), RDMA를 통한 KV 캐시, 독립적인 스케일링이 가능해졌습니다. GPU당 2배의 처리량(throughput)이 현재 표준입니다.
추측 디코딩(Speculative decoding)은 유일하게 비용 없는 속도 향상 기법입니다 — 형식적으로 동일한 출력을 내며, 낮은 동시성에서 일반적으로 2~3.5배의 이득을 얻습니다. 하지만 이는 배치에 민감하고 워크로드 형태에 따라 달라지므로, 포화(saturation) 도구라기보다는 지연 시간(latency) 도구입니다.
데모가 아닌 경제성을 주시해야 합니다. GPU당 처리량과 토큰당 에너지 소비량(추측 디코딩은 토큰당 에너지를 30~55% 절감함)이 가격을 움직이는 요소입니다. 지난 2년간 API 가격에서 발생한 모든 $/M-토큰 하락은 이러한 변화 중 하나이며, 이는 보도 자료가 한 발 늦게 도착하는 형태를 띱니다.

참고 문헌: llm-inference-optimization-and-scaling — balakreshnan/samples2026 (2026-05-28) · NVIDIA Dynamo design docs v0.8.0 — abuabdurahman82/llm-systems-wiki · P-EAGLE benchmark (GPT-OSS-20B) — vllm-project.github.io, 2026-03-13 · SPEED-Bench (Llama 3.3 70B + EAGLE3, 8×H100, 2,518 tok/s) — huggingface.co/blog/nvidia/speed-bench · Speculative Decoding in 2026: From EAGLE to DFlash to XPress — dev.to/monuminu (Sep 2026) · SPECULATIVE SPECULATIVE DECODING — ICLR 2026 (openreview.net) · The 2026 Playbook for Scaling LLM Inference — GPUYard, Medium (Sep 2026).