Google과 참여 커뮤니티가 Kubernetes 기반 분산 LLM 추론 스택인 llm-d 1.0을 공개했습니다. 요청을 단순 순환 배분하는 대신 기존 문맥 캐시와 서버 부하를 고려하고, 여러 사용자의 요청이 자원을 나눠 쓰도록 구성합니다. Google Cloud 공식 발표
긴 프롬프트를 여러 서버에서 매번 다시 계산하면 가속기를 추가해도 낭비가 남습니다. llm-d의 방향은 모델 서버들을 하나의 조정된 풀로 묶는 것입니다. 캐시에 남아 있는 문맥을 활용할 수 있는 서버에 요청을 보내는 설계가 여기에 포함됩니다.
이 글의 목차
LLM 서버는 앞선 계산을 기억할 수 있습니다
언어 모델은 입력 문맥을 처리하는 prefill 단계와 다음 토큰을 차례로 만드는 decode 단계를 거칩니다. 이 과정에서 재사용할 수 있는 중간 계산을 보관하는 것이 KV 캐시입니다. 매 요청이 같은 긴 안내문이나 문서를 포함한다면 앞부분의 계산을 재사용할 여지가 있어요. 다만 캐시는 메모리를 사용하며, 어느 서버에 남아 있는지가 중요합니다.
일반적인 순환 배분은 서버에 요청을 번갈아 보내지만 그 서버가 어떤 문맥을 기억하는지는 고려하지 않습니다. 같은 대화가 여러 복제본으로 흩어지면 비슷한 계산을 반복할 수 있습니다. 캐시를 고려한 라우팅은 유용한 문맥이 남은 복제본을 선택하려는 접근입니다. 그렇다고 캐시가 있는 서버로만 몰면 부하가 쏠리므로 대기열과 현재 부하도 함께 봐야 합니다.
처리량을 높이는 일과 대기 시간을 줄이는 일
밤에 문서를 일괄 요약하는 작업은 전체 완료량이 중요하지만, 사람이 대화하는 서비스는 첫 응답을 기다리는 시간이 중요합니다. 같은 가속기 풀을 공유하면 한쪽의 긴 작업이 다른 쪽의 대기 시간을 늘릴 수 있어요. 그래서 분산 추론에서는 서버 수뿐 아니라 어떤 요청을 먼저 받고 얼마나 기다리게 할지도 운영 정책이 됩니다.
prefill과 decode를 다른 자원 풀로 나누면 각 단계의 특성에 맞춰 확장할 수 있지만, 중간 상태를 전달하는 통신과 장애 처리도 필요합니다. 모델 크기와 문맥 길이, 서버 간 네트워크 조건에 따라 효과가 달라집니다. 작은 서비스에 분산 구성을 한꺼번에 넣기보다 현재 병목이 계산인지 메모리인지 대기열인지 먼저 구분하는 편이 좋습니다.
캐시 효과를 확인하는 비교 실험
평가 입력을 공통 문서가 반복되는 묶음과 서로 관련 없는 문서 묶음으로 나눠 봅니다. 두 묶음에서 같은 요청 수와 동시성을 유지하고 첫 토큰 지연, 전체 응답 시간, 실패율을 비교합니다. 공통 문맥이 있는 경우에만 좋아진다면 그 조건을 결과에 함께 적어야 해요. 공급자가 제시한 특정 성능 수치를 모든 트래픽의 예상값으로 사용하지 않습니다.
추가로 복제본 하나가 사라지거나 라우터를 갱신하는 상황을 시험합니다. 평소의 캐시 적중률이 높아도 장애 때 재계산이 몰리면 응답이 크게 늦어질 수 있습니다. 운영에 넣기 전에는 캐시가 비어 있는 시작 상태와 정상 상태를 모두 확인하고, 단순한 기존 경로로 돌아가는 방법을 남겨 둡니다. 이는 실험 설계이며 이 글에서 재현한 벤치마크는 아닙니다.
분산 추론 평가에 넣을 지표
- 첫 토큰 지연과 전체 응답 시간을 나눠 측정합니다.
- 캐시 적중률과 GPU·TPU 메모리 사용량을 함께 봅니다.
- 대화형 요청이 배치 작업 때문에 오래 기다리지 않는지 확인합니다.
1.0이라는 버전만으로 모든 구성의 운영 적합성을 판단하지 않습니다. 필요한 구성 요소부터 제한적으로 도입하고 장애 시 돌아갈 경로를 남깁니다.
발표문 기준일: 2026-10-21 · 확인일: 2026-10-24
