llm-d 1.0 발표: Google Cloud TPU 및 GPU의 에이전트를 위한 개방형 분산 추론

*이 콘텐츠는 AI 번역 도구를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역에는 오류나 누락이 포함될 수 있습니다. 정확한 정보는 영문 원본을 참고해 주시기 바랍니다.

캐시 인식 라우팅, 멀티 테넌트 트래픽 제어, 계층형 KV 캐시, 고가용성을 갖추어 Google Cloud에서 프로덕션에 즉시 사용 가능한 개방형 Kubernetes 네이티브 서빙 스택

오늘 PyTorch 컨퍼런스에서 Google은 분산형 LLM 추론을 위한 오픈소스 Kubernetes 네이티브 스택인 llm-d 1.0을 발표했습니다. Google이 Red Hat, IBM 등과 공동으로 설립한 Cloud Native Computing Foundation(CNCF) 샌드박스 프로젝트에는 25개 이상의 조직에서 500명이 넘는 인원이 참여했습니다. 이 프로젝트에서는 vLLM과 SGLang이 모델을 서빙하는 PyTorch와 분산 시스템이 프로덕션에서 실행되고 확장되는 Kubernetes라는 중요한 두 커뮤니티를 하나로 통합합니다.

llm-d 1.0은 에이전트가 추론의 본질을 바꾸고 있는 시점에 출시되었습니다. 1년 전만 해도 대부분의 추론 트래픽은 프롬프트 하나를 입력하면 대답 하나를 출력하는 채팅이었습니다. 오늘날 워크로드는 여러 도구로 분산되고, 긴 프리픽스를 공유하며, 갑자기 급증하는 다단계 에이전트 및 강화 학습(RL) 롤아웃으로 전환되고 있습니다. 단일 머신에서 또는 일반적인 라운드 로빈 부하 분산기 뒤에서 이를 서빙하면 금방 서비스가 중단되고 맙니다. 복제본은 동일한 프롬프트를 다시 계산하고, 가속기 메모리는 중복 상태로 가득 차며, 갑자기 급증한 에이전트 루프 하나가 대화형 사용자의 서비스를 지연시킬 수 있습니다.

llm-d는 모델 서버 클러스터를 조정된 서빙 풀로 전환하여 자체 모델을 서빙하는 팀에서 이러한 문제를 해결하도록 도와줍니다. PyTorch Conference 기조연설에서 Google은 GKE의 Agent Substrate에서 1,000개의 샌드박스 처리된 에이전트가 vLLM, SGLang, Google Cloud TPU 및 GPU가 혼합된 Fleet 전반의 단일 llm-d 엔드포인트에 접속하는 과정을 시연했습니다. 아래 3단계에 걸쳐 트래픽이 확장됨에 따라 캐시 인식 라우팅과 계층형 KV 캐시를 통해 각 에이전트의 단계가 컨텍스트를 가진 복제본에서 계속 처리되도록 했고, 흐름 제어로 급증한 에이전트 루프를 큐에 추가하여 대화형 요청의 속도를 빠르게 유지했습니다.

1.0에서 제공하는 기능

llm-d는 이미 Google Cloud TPU 및 GPU 전반에 걸쳐 프리픽스 및 부하 인식 라우팅, KV 캐시 오프로드, 사전 입력/디코딩 분리, 광범위한 전문가 병렬 처리, 일괄 추론을 제공하고 있습니다. 이러한 기능으로 얻는 이점은 다음과 같습니다.

• 멀티 테넌트 서비스 품질. llm-d 흐름 제어를 통한 우선순위 및 공정성 인식 라우팅 덕분에 지연 시간에 민감한 요청과 급증한 에이전트 워크로드가 리소스 고갈 없이 Fleet을 공유하여 SLO를 충족할 수 있습니다.
• 안정적인 기반. 여러 클라우드 및 가속기 유형에서 검증된 v1 API와 강화된 요청 경로가 지원됩니다.
• 더욱 안전한 업그레이드. 라우터 고가용성 및 다운타임 없는 업데이트가 지원될 뿐만 아니라 DisaggregatedSet를 통해 컨텍스트 손실이나 활성 세션 중단 없이 사전 입력/디코딩 인식 순차적 업데이트를 조정합니다.
• 에이전트 인식 서빙. 세션 인식 라우팅, 턴 우선순위 스케줄링, 네이티브 Responses API 상태를 통해 에이전트가 턴 전반에서 컨텍스트를 재사용할 수 있습니다.
• 확장된 TPU 통합. TorchTPU 협력적 타임 슬라이싱을 이용한 네이티브 PyTorch 모델 서빙으로 Google Cloud TPU Fleet 전반의 처리량과 사용률을 높입니다.

이 구성요소는 자체 맞춤 프로덕션 환경으로 구성할 수 있도록 설계되었습니다. 엔진, 모델, 클러스터를 유지한 채 필요한 서빙 구성요소와 구성만 적용하면 됩니다.

llm-d 내부 작동 방식

Google 엔지니어들은 아래 영역 전반에서 llm-d 커뮤니티와 협력하여 업스트림 Kubernetes 기본 요소, PyTorch 서빙 엔진, 가속기 인식 스케줄링을 구성 가능한 스택으로 통합했습니다.

하나의 엔드포인트에서 다양한 가속기 지원

에이전트 Fleet은 하나의 워크로드로 정의할 수 없습니다. 대화형 턴에는 짧은 지연 시간이 필요하고, 백그라운드 루프와 강화 학습(RL) 롤아웃에는 높은 처리량이 요구되며, 수요는 분 단위로 변동합니다. llm-d는 전체 Fleet 전면에 하나의 라우터, 하나의 KV 캐시 색인, 하나의 흐름 제어 정책을 두고 가속기 풀을 단일 엔드포인트 뒤에 배치합니다. 에이전트는 하나의 API를 호출하며, 라우터가 각 단계의 복제본을 선택하고 이미 컨텍스트를 보유한 복제본으로 세션 컨텍스트를 유지합니다. 에이전트를 재작성하지 않고 플랫폼을 변경하는 것만으로 용량을 추가하고, 여러 세대의 가속기를 혼용하고, 모델을 다른 풀로 이동할 수 있습니다. TorchTPU는 이러한 Fleet에 Google Cloud TPU를 도입하여 모델 재작성 없이 업스트림 vLLM 및 SGLang 내에서 기본적으로 PyTorch 모델을 실행합니다. 자세한 내용은 Google Kubernetes Engine(GKE) TPU의 llm-d 가이드를 참고하세요.

컨텍스트를 기억하는 라우팅

llm-d 라우터는 Google에서 추론 최적화 라우팅을 위해 출시한 Kubernetes 프로젝트인 Gateway API Inference를 기반으로 합니다. GKE에서 GKE Inference Gateway는 llm-d 라우터를 관리형 서비스로 실행하여 설치 및 관리를 간소화하고 리전 간 라우팅을 확장합니다. 이 라우터는 캐시된 각 프리픽스를 보유한 복제본을 추적하고, 복제본을 선택할 때 부하와 예상 지연 시간을 고려합니다. 가속기 메모리가 가득 차면 llm-d는 이를 삭제하는 대신 vLLM의 OffloadingConnector, Mooncake 또는 SGLang의 HiCache를 사용하여 KV 캐시를 호스트 메모리로 옮긴 후 SSD 또는 Google Cloud Managed Lustre로 이동시킵니다. 이 설정은 TPU와 GPU가 혼합된 Fleet에서 긴 컨텍스트의 멀티턴 대화 부하가 대규모로 발생할 때 프리픽스 제거 폭풍을 방지하는 데 도움이 됩니다.

Ironwood TPU(TPU 7x)에서 에이전트형 코딩 워크로드를 실행할 때 프리픽스 인식 라우팅과 호스트 메모리 오프로드를 함께 사용하면 일반 Kubernetes 서비스에 비해 첫 번째 토큰까지의 시간(TTFT) 중앙값이 85% 넘게 단축되고 총 처리량이 2.4배 증가했습니다(출처, 2026년 10월 기준).

안전한 업그레이드를 위한 분리

사전 입력은 컴퓨팅 집약적이고 디코딩은 메모리 제한이 있기 때문에 동일한 복제본에서 두 작업을 모두 실행하면 서로 대기하는 상황이 발생합니다. llm-d는 사전 입력, 디코딩, 멀티모달 인코딩을 별도의 풀로 실행하며, 광범위한 전문가 병렬 처리를 통해 대규모 전문가 혼합 모델을 여러 노드에 분산합니다. 1.0에서는 Google이 최초로 개발한 멀티 호스트 추론용 Kubernetes API인 LeaderWorkerSet를 기반으로 빌드된 DisaggregatedSet가 이러한 풀을 하나의 단위로 관리합니다. 순차적 업데이트에서 사전 입력과 디코딩이 일치 버전으로 함께 전환되며 각 단계는 독립적으로 확장됩니다. 자세한 내용은 분리형 서빙 가이드를 참고하세요.

실시간 추론과 함께 실행되는 비동기 추론

지연 시간에 민감하지 않은 트래픽을 위해 llm-d 1.0에서는 Google Cloud Pub/Sub 또는 Redis와 같은 큐에서 요청을 가져와 실시간 트래픽과 함께 라우팅해주는 llm-d-async-processor를 도입합니다. 이 프로세서는 큐 및 풀-디스패치 게이트를 사용하여 가용 용량을 확인하고 엄격한 우선순위 레인과 할당량을 적용합니다. 덕분에 백그라운드 작업이 대화형 사용자의 리소스를 고갈시키지 않으면서 여유 용량 내에서 실행됩니다.

타임 슬라이싱을 통해 유휴 RL 용량 활용

RL 학습 중에는 롤아웃 생성 또는 가중치 업데이트가 진행될 때 가속기가 전체 시간의 40%~60% 동안 유휴 상태로 있는 경우가 많습니다. llm-d는 Google Cloud TPU 및 GPU 타임 슬라이싱을 지원하여 이러한 유휴 주기에 비동기 추론을 인터리브 처리하여 최대 40%(기준)인 총 가속기 가동 주기를 70% 이상으로 향상시킵니다(출처).

신뢰할 수 있는 벤치마크

라우터, KV 캐시 계층, 사전 입력/디코딩 풀 전반에서 분산 추론 스택을 조정하려면 현실적인 멀티턴 부하 환경에서 반복 가능한 측정이 필요합니다. Prism은 llm-d에서 검증한 경로 전반의 공개 벤치마크를 탐색할 수 있는 llm-d의 오픈소스 분석 대시보드로, 표준화된 llm-d-benchmark 레시피와 inference-perf 워크로드를 기반으로 작동합니다. 수치 뒤에 숨겨진 정확한 구성을 검사하거나 자체 클러스터의 실행 결과를 업로드하여 처리량, 지연 시간, 비용 곡선을 나란히 비교할 수 있습니다.

Google Cloud에서 llm-d 1.0 실행

llm-d는 Gateway API, LeaderWorkerSet, 동적 리소스 할당, Prometheus, OpenTelemetry 등 이미 많이 실행되고 있는 Kubernetes 구성요소를 기반으로 빌드됩니다. Google Cloud에서 llm-d를 실행하면 다음과 같은 요소를 관리형 인프라와 함께 통합할 수 있습니다.

• GKE Inference Gateway는 게이트웨이 모드에서 작동하는 llm-d 라우터로, L7 프록시 및 부하 분산을 처리하고 요청마다 llm-d 엔드포인트 선택기를 호출하는 관리형 GKE 게이트웨이입니다. 설치 및 관리를 간소화하므로 프록시를 직접 실행할 필요가 없습니다. 무엇보다도 GKE Inference Gateway를 사용하면 전역 장애 조치와 Model Armor 안전 확인을 통해 클러스터와 리전 전반에서 llm-d를 확장할 수 있습니다.
• 추론 신호 기반 자동 확장. KEDA와 수평형 포드 자동 확장 처리(HPA)는 큐 깊이, 포화도, 예측 지연 시간을 기준으로 풀을 확장하고, Kueue는 공유 가속기에 모델별 할당량을 적용합니다.
• 혼합 가속기 노드 풀. Google Cloud TPU 및 GPU 풀은 동일한 llm-d 엔드포인트 뒤에서 실행되며 검증된 Helm 차트를 사용하여 배포됩니다.
• 레이어 전반의 KV 캐시 오프로드. Google Cloud Managed Lustre는 로컬 TPU 및 GPU HBM과 호스트 CPU RAM 아래에 공유 원격 계층을 제공하므로 긴 컨텍스트 워크로드가 가속기 메모리를 소진하지 않고 실행됩니다.

프로덕션 환경에서의 성과

이 GKE llm-d 스택은 프로덕션 트래픽을 전달하며 Fleet 규모의 테스트를 마쳤습니다.

• Gemini 플랫폼(이전 명칭: Vertex AI)은 GKE Inference Gateway를 통해 프로덕션 트래픽을 처리하여 프리픽스 캐시 적중률을 35%에서 70%로 두 배 향상시키고, 코딩 에이전트의 TTFT를 35% 넘게 단축하며, 급증하는 채팅 트래픽에서 P95 TTFT를 50% 이상 줄입니다(출처).
• 미국과 유럽에서 전문가 혼합 모델을 서빙하는 17,000개 노드 규모의 멀티 리전 GKE 배포를 대상으로 한 공개 벤치마크에서 멀티 클러스터 GKE Inference Gateway와 llm-d 라우터는 3개 클러스터에서 99.9%의 성공률과 1% 미만의 라우팅 오버헤드를 유지하며 처리량을 2.9배 확장시켰습니다(출처).
• 700억 개의 파라미터 모델을 서빙하는 A3 Mega 클러스터에서 진행된 공개 벤치마크에서, 호스트 CPU RAM 외에도 Google Cloud Managed Lustre에 대한 멀티 커넥터 KV 캐시 오프로드를 사용하는 llm-d는 CPU RAM 오프로드만 사용하는 경우에 비해 TTFT를 약 40% 개선하고 토큰 50,000개 규모의 프롬프트에 응답하는 엔드 투 엔드 지연 시간을 30% 단축하는 동시에 GPU-시간 요구사항을 거의 60%나 줄였습니다(출처).

Google Cloud에서 llm-d를 실행하는 조직은 캐시 적중률을 높이기 위한 프리픽스 인식 라우팅, 기존 서비스 메시와 호환되는 개방형 인터페이스, 트래픽 급증 시 우선순위 등급의 지연 시간을 유지하기 위한 흐름 제어 등 다양한 방식으로 이러한 기능을 활용하고 있습니다.

"Snap은 대규모 고성능 추론을 촉진하기 위해 llm-d를 프로덕션 AI 인프라에 통합하고 있습니다. 프리픽스 캐시 인식 라우팅을 사용한 결과 최대 75~80%에 달하는 프리픽스 캐시 적중률을 얻었습니다. llm-d의 오픈소스 특성 덕분에 Envoy 기반 서비스 메시와 원활하게 통합할 수 있었습니다." - Vinay Kola, Snap Inc. 소프트웨어 엔지니어링 부문 선임 관리자

"ZenteiQ에서는 llm-d 기반의 GKE Inference Gateway를 사용하여 자체 주권 과학용 파운데이션 모델을 위한 합성 데이터 생성을 가속화하고 있습니다. 부하 인식 및 프리픽스 캐시 인식 라우팅을 활용하여 총 추론 처리량을 4배 이상 높였으며, 일일 생성 토큰 용량을 TPU v6e 가속기 1,000개당 14억 7천만 개에서 59억 7천만 개로 늘렸습니다. GKE와 통합된 llm-d의 오픈소스 기반 덕분에 커스텀 추론 스케줄러를 개발하고 유지보수할 필요 없이 대규모의 여러 모델 제품군을 효율적으로 서빙할 수 있게 되었습니다.” - Sashikumaar Ganesan 교수, Zenteiq.ai 설립자 

“대화형 애플리케이션과 대용량 API 전반에서 프런티어 모델을 서빙한다는 것은 갑자기 몰리는 워크로드로 인해 우선순위 고객의 지연 시간이 저하되지 않도록 하면서 급증하는 트래픽을 처리해야 한다는 것을 의미합니다. llm-d의 프리픽스 캐시 인식 라우팅, 흐름 제어, 분리형 서빙 지원을 사용하면 상용 등급 전반에 엄격한 우선순위 대역을 적용하고, 풀이 포화 상태가 되었을 때 우선순위가 낮은 요청을 자동으로 보류하거나 차단하여 유료 트래픽이 지연 시간 SLO를 충족하도록 할 수 있습니다. Mistral은 오픈소스 소프트웨어를 적극 지원하며, 앞으로도 llm-d 및 DisaggregatedSet 프로젝트에 계속 참여할 것입니다.” - Mathis Felardos, Lucas Fernandes-Martins, Nikhil Thomas, Mistral, 추론 엔지니어 겸 llm-d 참여자

자체 모델을 서빙하는 여러 팀에서 프로덕션에 필요한 캐시 인식 라우팅, 트래픽 제어, 업그레이드 제어 기능을 포함하고, 분해하여 자체 인프라에 맞게 조정할 수 있는 개방형 스택을 요청해 왔습니다. llm-d 1.0은 이러한 니즈를 충족함은 물론 공동 개발을 위한 커뮤니티도 제공합니다.

시작하기

1. PyTorch Conference가 진행되는 동안 Google Cloud 부스에서 TPU 기반의 llm-d에 대한 전체 데모를 확인하세요.
2. 검증된 Helm 차트를 사용하여 GKE에 llm-d 1.0을 배포하세요. GKE의 llm-d 문서를 참고하세요.
3. 먼저 기존 vLLM 배포 앞에 프리픽스 인식 라우팅을 적용한 다음 흐름 제어, KV 캐시 오프로드(SGlang, vLLM), 분리를 추가하세요.
4. Prism에서 결과를 비교하고 GitHub를 통해 개발에 참여하세요.