무엇인가: AMD는 ATOM + ATOMesh를 출시했습니다. 이는 ROCm 네이티브 LLM 서빙 스택으로, 핵심 기술은 **prefill/decode 분리 (disaggregation)**입니다. 이는 추론의 두 단계를 하나의 GPU 풀에 몰아넣는 대신, 별도의 GPU 풀로 나누어 처리하는 방식입니다.

이유: Prefill과 decode는 **서로 반대되는 병목 현상 (bottlenecks)**을 가집니다. Prefill은 연산 중심 (compute-bound)인 반면, decode는 메모리 대역폭 중심 (memory-bandwidth-bound)입니다. 따라서 이를 동일한 워커(worker)에서 실행하면 하드웨어 자원이 낭비되며, 하나의 긴 프롬프트가 **다른 모든 사용자의 토큰 스트림을 지연 (stall)**시킬 수 있습니다.

이전 방식과의 차이: **동일 위치 서버 (기존의 단일 풀 vLLM)**는 동일한 GPU에서 prefill과 decode를 교차하여 실행합니다. 반면, 분리 (disaggregation) 방식은 각 단계를 해당 병목 현상에 최적화된 자체 풀에서 실행하며, 그 대가로 인터커넥트 (interconnect)를 통해 KV 캐시 (KV cache)를 전송해야 합니다.

비유하자면

재료 준비 구역(prep station)과 배식 라인(plating line)이 분리된 레스토랑 주방과 같습니다.

   주문 (프롬프트)
        │
        ▼
...

• prefill = 준비 담당 요리사가 한 번의 연산 집약적인 폭발적 작업으로 주문 전체의 재료를 손질하는 것
• decode = 배식 담당 요리사가 접시마다 냉장고를 오가며 요리를 하나씩 완성해 나가는 것
• KV cache = 모든 접시가 재료를 꺼내 쓰는 준비된 재료가 담긴 냉장고
• disaggregation = 준비와 배식에 각각의 구역과 인력을 배정하여 각자의 업무에 최적화하는 것
• KV-cache transfer = 준비 카트를 복도 끝 배식 라인까지 밀고 가는 것
• KV-aware scheduling = 각 주문을 해당 재료가 이미 들어있는 냉장고를 가진 라인으로 보내는 것

용어 사전

Prefill — 추론의 첫 번째 단계입니다. 모델이 전체 프롬프트를 병렬로 한 번에 읽어 KV 캐시를 구축합니다. 접촉하는 메모리 바이트당 많은 수학 연산을 수행하므로, 연산 중심 (compute-bound)입니다.

Decode — 두 번째 단계입니다. 모델이 한 번에 하나의 출력 토큰을 생성하며, 각 단계마다 해당 단일 토큰을 생성하기 위해 전체 KV 캐시와 모든 가중치 (weights)를 읽어야 합니다. 적은 연산량에 비해 많은 메모리를 이동시키므로, 메모리 대역폭 중심 (memory-bandwidth-bound)입니다.

KV cache (KV 캐시) — 이미 처리된 모든 토큰에 대해 저장된 **키(keys)와 값(values)**으로, 모델이 이를 다시 계산하지 않도록 합니다. 이는 추론(inference)에서 지배적인 메모리 비용을 차지하며, 분리된(disaggregated) 스택에서는 prefill 풀에서 decode 풀로 이동해야 하는 요소입니다.

연산 중심(Compute-bound) vs 메모리 중심(Memory-bound) — 루프라인(roofline) 모델의 구분입니다: GPU의 연산 유닛이 한계가 될 때 해당 작업은 연산 중심(compute-bound)이며, 메모리 대역폭이 한계가 될 때 메모리 중심(memory-bound)입니다. Prefill과 decode는 이 경계선의 반대편에 위치하며, 이것이 바로 두 과정을 분리하는 근본적인 이유입니다.

분리 (Disaggregation) — prefill과 decode를 하나의 공유된 풀이 아닌 별도의 워커(worker) 풀에서 실행하여, 각 풀이 각자의 병목 현상(bottleneck)에 맞춰 크기가 조정되고 스케줄링될 수 있도록 하는 방식입니다.

KV 인식 스케줄링 (KV-aware scheduling) — KV 캐시 블록이 이미 어디에 존재하는지를 파악하여 요청을 라우팅하는 스케줄러입니다. 이를 통해 캐시된 접두사(prefix caching)를 재사용하거나, 데이터 전송을 피할 수 있도록 요청을 적절한 워커로 유도할 수 있습니다.

ROCm / AITER / MORI / Instinct — ROCm은 AMD의 CUDA 대응 소프트웨어 스택이며, Instinct는 AMD의 데이터센터 GPU 라인업입니다. AITER는 최적화된 ROCm 커널(CUDA 커널의 대응물)을 제공하며, MORI는 텐서/전문가 병렬성(tensor/expert parallelism)을 위한 분산 RDMA 방식의 통신을 처리합니다 (AMD 자체의 컬렉티브 라이브러리인 RCCL이 NCCL의 더 가까운 대응물입니다).

뉴스. 2026년 6월 16일, AMD는 Instinct GPU를 위한 ROCm 네이티브 LLM 서빙 스택인 ATOM + ATOMesh를 초기 (알파) 프리뷰로 공개했습니다. ATOM은 AITER로 최적화된 추론 엔진(AITER를 통한 커널 가속, MORI를 통한 분산 통신)이며, ATOMesh는 그 상위의 오케스트레이션 레이어입니다. ATOMesh는 OpenAI 호환 API를 제공하고, 여러 엔진 백엔드를 관리하며, **prefill/decode 분리 (disaggregation) 및 KV-aware 스케줄링 (KV-aware scheduling)**을 적용하여 Instinct 하드웨어에서 DeepSeek-V4-Pro를 서빙하는 성능을 평가했습니다. AMD의 설명에 따르면, 이는 vLLM/SGLang의 설계를 의도적으로 반영한 것으로, 동일한 서빙 프리미티브 (serving primitives)를 이제 AMD 실리콘에서 사용할 수 있게 된 것입니다. 릴리스 읽기 →

한 명의 요리사가 모든 일을 다 하는 레스토랑 주방을 상상해 보세요. 먼저 요리사는 주문을 위해 **재료 준비 (prep)**를 합니다. 요리에 필요한 모든 재료를 한꺼번에 썰고, 자르고, 섞으며 격렬하게 칼질을 합니다. 그다음에는 **플레이팅 (plate)**을 합니다. 요리를 구성 요소별로 하나씩 조립하며, 각 재료를 가져오기 위해 냉장고를 계속 왔다 갔다 합니다. 재료 준비는 손이 쉴 새 없이 움직이는 작업인 반면, 플레이팅은 냉장고를 자주 들락날락할 뿐 칼질은 별로 없습니다. 이 두 가지 일을 한 명의 요리사에게 몰아넣으면 충돌이 발생합니다. 대량의 재료 준비 주문이 들어오면 기다리는 모든 접시가 식어버리고, 느린 플레이팅 과정 중에는 칼이 놀게 됩니다. 과부하가 걸린 이 한 명의 요리사가 바로 LLM을 실행하는 하나의 GPU이며, 두 가지 작업은 prefill과 decode입니다.

모델이 답변할 때, 먼저 prefill을 실행합니다. 이는 전체 프롬프트를 한 번의 병렬 패스 (parallel pass)로 읽어 들여, 밀집 행렬 연산 (dense matrix math)을 수행하고 KV 캐시 (KV cache)를 채웁니다. 그다음 decode를 실행합니다. 이는 단계마다 토큰을 하나씩 (one token per step) 출력하며, 매 단계마다 단 하나의 토큰을 생성하기 위해 전체 KV 캐시와 모든 가중치 (weights)를 메모리에서 불러옵니다. Prefill은 연산 제한적 (compute-bound) — GPU의 연산 유닛에 의해 제한됨 — 인 반면, decode는 메모리 대역폭 제한적 (memory-bandwidth-bound) — 캐시를 메모리에서 얼마나 빨리 스트리밍할 수 있는지에 의해 제한됨 — 입니다. 이들은 재료 준비 담당 요리사와 플레이팅 담당 요리사와 같습니다. 서로 상반된 요구 사항을 가졌음에도 하나의 스테이션을 공유하도록 강제된 상태입니다.

그러한 상반된 요구 사항(opposite-appetites) 문제는 왜 단일 공유 워커(worker)가 하드웨어를 낭비하게 만드는지를 설명해 줍니다. Prefill(프리필)과 Decode(디코드)를 함께 묶어두면, 긴 프롬프트의 prefill 버스트(burst)가 그 뒤에 대기 중인 decode 단계들의 큐를 차단하는 Head-of-line stall(선두 차단) 현상이 발생하며, 동시에 메모리 대역폭에 제한을 받는(memory-bound) decode 작업은 값비싼 연산 유닛(compute units)을 유휴 상태로 방치하게 됩니다. 하나의 머신을 두 작업 모두에 동시에 적합하도록 설계하는 것은 결코 불가능합니다.

Disaggregation(분리)이 바로 그 해결책입니다. 준비 담당과 플레이팅 담당에게 각각의 전용 스테이션을 제공하는 것입니다. Prefill은 연산 집약적인(compute-heavy) 버스트를 위해 스케줄링된 하나의 GPU 풀에서 실행되며, Decode는 대규모 배치(batch)와 함께 안정적인 메모리 대역폭 기반 스트리밍(memory-bound streaming)을 위해 스케줄링된 별도의 풀에서 실행됩니다. 요청이 prefill을 마치면, prefill 워커는 인터커넥트(interconnect)를 통해 자신의 KV 캐시(KV cache)를 decode 워커로 전달하고, 그러면 decode 워커가 토큰을 스트리밍하여 출력합니다. 이제 각 풀은 실제로 직면한 병목 현상에 맞춰 크기가 조정되고 최적화됩니다. 그리고 AMD의 ATOMesh는 ROCm 상에서 정확히 이러한 라우팅을 수행하는 오케스트레이션(orchestration) 레이어입니다. 이는 vLLM과 SGLang이 표준으로 만든 것과 동일한 플레이북(playbook)이며, ATOM + ATOMesh는 AMD가 이를 위한 ROCm 네이티브 경로를 구축하고 있음을 보여줍니다.

하지만 Disaggregation은 공짜가 아니며, 그 비용은 핸드오프(handoff, 전달) 시점에 발생합니다. Prefill 이후, KV 캐시는 prefill 풀에서 decode 풀로 물리적으로 이동해야 합니다. 2,048개 토큰의 프롬프트를 가진 70B급 모델의 경우, 해당 캐시의 크기는 2 × 80 layers × 8 KV-heads × 128 dim × 2,048 tokens × 2 B ≈ 0.67 GB 입니다 (예시 수치, Grouped-query attention을 사용하는 Llama-3.1-70B 기준). 이를 PCIe 4.0을 통해 이동하면 약 **21 ms**가 소요되지만, NVLink를 통하면 약 **0.75 ms**가 소요됩니다 — 약 28배의 차이가 발생합니다 (세 수치 모두 예시임: 크기는 위 공식에 따른 것이며, 시간은 각 인터커넥트의 대역폭에 의해 설정되었고, ATOM에서 측정된 것은 아님). 이러한 격차 때문에 분리된 스택(disaggregated stacks)의 성패는 인터커넥트에 달려 있으며, KV-aware 스케줄링이 전송을 완전히 피하기 위해 요청을 해당 접두사(prefix)를 이미 보유하고 있는 워커로 유도하려는 이유이기도 합니다.

솔직한 주의 사항: ATOM + ATOMesh는 초기 (alpha) 프리뷰 형태로 제공되며, AMD의 게시물은 직접적인 성능 비교 수치가 아닌 **메커니즘 (mechanism)**을 설명하고 있습니다. 해당 게시물은 ATOMesh가 vLLM/SGLang 설계를 반영하며 DeepSeek-V4-Pro 서빙을 평가했다는 점을 보고하고 있으나, 본문 텍스트 내에 활용 가능한 수치적 처리량(throughput)이나 지연 시간(latency) 수치를 제공하지 않으므로, 모든 성능 관련 주장은 여기서는 아직 정량화되지 않은 것으로 간주하고 벤치마크를 위해 출처를 확인하시기 바랍니다. 위의 KV 전송 수치는 ATOM에서 측정된 것이 아니라 대표적인 모델의 규모에 맞춘 예시용입니다. 하지만 변하지 않는 교훈은 명확합니다: 프리필(prefill)과 디코딩(decode)이 루프라인(roofline)의 정반대 편에 위치한다는 것을 알게 되는 순간, "하나의 GPU가 둘 다 수행한다"는 방식은 더 이상 효율적으로 보이지 않게 됩니다. 서빙 스택의 진정한 역할은 이 두 단계를 분리하고 그 사이에서 KV 캐시를 저렴하게 이동시키는 것입니다.

더 자세한 내용: LLM Serving → Prefill/Decode Disaggregation → Disaggregation

관련 설명

• SGLang v0.5.12 — TokenSpeed MLA backend — SGLang은 ATOMesh가 미러링하는 vLLM/SGLang 설계의 절반을 차지합니다. 이는 ATOM과 같은 풀(pool)
  _내부_에 존재하는 엔진 레벨의 최적화입니다.
• HuggingFace — Async continuous batching — 디코드 워커(decode worker)를 계속 가동시키기 위한 또 다른 레버입니다. 분리(disaggregation)와 연속 배치(continuous batching)는 동일한 메모리 대역폭 제한(memory-bound) 디코드 문제를 해결하기 위한 상호 보완적인 방법입니다.
• Tangram — Per-head KV cache budgets — KV 캐시(KV cache) 자체를 축소하며, 이는 분리된 스택(disaggregated stack)이 풀 사이에서 전송해야 하는 실제 페이로드(payload)입니다.
• Spec-decode latency — Load-dependent latency model — 단계적 분리(phase disaggregation)를 통해 별도의 풀로 격리되는 디코드 지연 시간(decode latency)이 부하(load)에 따라 어떻게 변하는지를 모델링합니다.

FAQ

Prefill/Decode 분리(disaggregation)란 무엇인가요?

이는 LLM 추론의 두 단계를 별도의 GPU 풀에서 실행하는 서빙(serving) 설계입니다. 전체 프롬프트를 한 번의 병렬적이고 연산 집약적인 패스로 읽어들이는 Prefill(프리필)은 하나의 풀에서 실행되며, 메모리 대역폭(memory bandwidth)에 의해 병목 현상이 발생하는 한 번에 하나의 토큰씩 출력을 생성하는 Decode(디코드)는 다른 풀에서 실행됩니다. Prefill이 완료되면 요청의 KV 캐시(KV cache)가 인터커넥트(interconnect)를 통해 디코드 워커로 전송됩니다. 이들을 분리함으로써, 하나의 공유된 머신에서 타협하는 대신 각 풀을 각자의 병목 지점에 맞춰 크기를 조정하고 스케줄링할 수 있습니다.

왜 Prefill과 Decode를 별도의 GPU로 분리하나요?

두 단계의 병목 지점이 서로 반대이기 때문입니다. Prefill은 연산 중심적 (compute-bound, GPU의 연산 유닛에 의해 제한됨)인 반면, Decode는 메모리 대역폭 중심적 (memory-bandwidth-bound, KV 캐시와 가중치를 메모리에서 얼마나 빠르게 스트리밍하느냐에 의해 제한됨)입니다. 하나의 공유된 워커(worker)에서 실행할 경우, 긴 Prefill 작업은 그 뒤에 대기 중인 Decode 단계를 지연시키고, 메모리 중심적인 Decode 작업은 연산 유닛을 유휴 상태로 만듭니다. 각 단계를 해당 제한 사항에 맞춰 최적화된 하드웨어에서 실행하면, 두 풀(pool) 사이에서 KV 캐시를 이동시켜야 하는 비용이 발생하지만 상호 간섭은 피할 수 있습니다.

AMD의 ATOM과 ATOMesh는 무엇을 추가하며, vLLM 및 SGLang과는 어떤 관계인가요?

ATOM은 ROCm 네이티브 추론 엔진 (AITER를 통한 최적화된 커널, MORI를 통한 GPU 간 통신)이며, ATOMesh는 그 위의 오케스트레이션 계층(orchestration layer)입니다. 이는 Prefill/Decode 분리(disaggregation)와 KV 인지 스케줄링(KV-aware scheduling)을 적용하는 OpenAI 호환 API입니다. AMD는 이것이 vLLM/SGLang의 설계를 의도적으로 미러링(mirroring)한 것이라고 설명합니다. 따라서 이들의 기여는 새로운 알고리즘을 제시하는 것이 아니라, LLM 서빙(LLM Serving) 트랙에서 가르치는 동일한 현대적 서빙 프리미티브(serving primitives)를 AMD Instinct GPU로 가져온 것입니다. 즉, 해당 스택에 대한 두 번째 벤더의 구현체라고 할 수 있습니다.

원문은 Learn AI Visually에 게시되었습니다.