Google인프라와 비용

llm-d 1.0 출시, 자체 GPU·TPU에서 분산 추론 운영 지원

Google, Red Hat, IBM 등이 쿠버네티스 기반 오픈소스 분산 추론 스택 llm-d 1.0을 내놨다. 다중 사용자 우선순위 제어, 무중단 업그레이드, 에이전트용 라우팅이 추가됐다.

루카스 ·

오픈소스 분산 추론 프레임워크 llm-d의 1.0 버전이 공개됐다. IBM, IBM 자회사 Red Hat, Google 등 여러 기여자가 함께 개발한 프로젝트로, Google은 PyTorch Conference에서 1.0을 냈다고 밝혔다. SiliconANGLE는 이번 발표가 샌호제이에서 열리는 PyTorch Conference North America를 앞두고 이뤄졌다고 전했다. 쿠버네티스 위에서 동작하며, Google은 자체 운영하는 GPU와 TPU 환경에서 대규모 언어 모델을 서비스하려는 조직을 대상으로 내세웠다. 이번 버전은 여러 사용자의 요청 우선순위를 조절하는 서비스 품질 제어, 무중단 업데이트, 에이전트에 맞춘 서빙 기능을 담았다.1,2

구글의 텐서 처리 장치(TPU) 3.0 기기를 찍은 사진. 기판과 방열 구조가 보인다.
Google TPU 3.0 하드웨어 사진Zinskauf / Wikimedia Commons · CC BY-SA 4.0 · 원본 · 크기 조정

Google Cloud에서는 검증된 Helm 차트로 GKE에 배포할 수 있다. 기존 vLLM 배포 앞에 접두사 인식 라우팅을 먼저 붙이고, 이후 흐름 제어와 KV 캐시 오프로딩, 분리 서빙을 차례로 더하는 방식을 Google은 권했다.1

Red Hat CTO실 부사장 Stephen Watt는 llm-d가 기업이 이미 아는 운영 모델 안에서 고성능 분산 추론을 제공한다고 평가했다.2

1.0에서 추가된 기능

Google은 에이전트가 추론 트래픽의 성격을 바꾸고 있다고 설명했다. 1년 전에는 대부분 질문 하나에 답 하나인 채팅이었지만, 지금은 여러 단계를 밟는 에이전트와 강화 학습 롤아웃이 도구를 호출하고 긴 접두사를 공유하며 한꺼번에 몰린다는 것이다. 이런 부하를 단순 라운드로빈 로드 밸런서 뒤에서 처리하면 복제본마다 같은 프롬프트를 다시 계산하고, 가속기 메모리에 중복 상태가 쌓이며, 급증한 에이전트 루프 하나가 일반 사용자 응답을 막을 수 있다고 Google은 밝혔다.

  • 다중 사용자 품질 관리: 흐름 제어로 우선순위와 공정성을 고려해 라우팅하며, 지연에 민감한 요청과 급증하는 에이전트 작업이 한 클러스터를 나눠 쓴다.
  • 안정성: v1 API와 보강한 요청 경로를 여러 클라우드와 가속기에서 검증했다.
  • 안전한 업그레이드: 라우터 고가용성과 무중단 업데이트를 지원한다. DisaggregatedSet은 프리필과 디코드 풀을 함께 롤링 업데이트하며 맥락과 활성 세션을 유지한다.
  • 에이전트 인식 서빙: 세션 인식 라우팅, 턴 우선순위 스케줄링, 네이티브 Responses API 상태를 제공한다.
  • TPU 통합 확대: TorchTPU의 협력적 시분할로 TPU 처리량과 활용도를 높인다.1

IBM 연구소의 Carlos Costa는 이번 버전이 안정적인 API, 경쟁하는 우선순위를 가진 여러 테넌트의 인프라 공유, 운영을 끊지 않는 업그레이드를 갖춰 다른 핵심 서비스처럼 운영할 수 있게 한다고 말했다. Costa는 프로젝트 공동 창립자이자 주관 개발자다.2

구성 요소는 필요한 것만 골라 조합하도록 설계됐다. 엔진, 모델, 클러스터는 그대로 두고 필요한 서빙 구성만 도입하면 된다고 Google은 설명했다.1

작동 방식

llm-d는 가속기 풀 전체를 하나의 엔드포인트 뒤에 두고, 라우터 하나와 KV 캐시 색인 하나, 흐름 제어 정책 하나로 관리한다. 에이전트는 API 하나만 호출하고, 라우터가 단계마다 복제본을 고르며 세션의 맥락을 이미 가진 복제본에 계속 보낸다. 용량을 늘리거나 가속기 세대를 섞거나 모델을 다른 풀로 옮기는 일은 에이전트 수정 없이 플랫폼 변경으로 끝난다. TorchTPU는 모델을 고쳐 쓰지 않고 업스트림 vLLM과 SGLang 안에서 PyTorch 모델을 TPU에서 직접 돌린다.1

라우터는 Gateway API Inference를 기반으로 하며, 캐시된 접두사를 보유한 복제본을 추적하고 부하와 예측 지연 시간을 함께 따져 고른다. GKE에서는 GKE Inference Gateway가 이 라우터를 관리형 서비스로 실행하고 리전을 넘어 라우팅한다. 가속기 메모리가 차면 vLLM의 OffloadingConnector, Mooncake, SGLang의 HiCache로 KV 캐시를 호스트 메모리, 다시 SSD나 Google Cloud Managed Lustre로 옮긴다. SiliconANGLE는 GPU 메모리, CPU 메모리, 저장장치 사이로 캐시를 옮겨 GPU 용량이 부족해져도 재사용 가능한 정보를 보존한다고 전했다.1,2

프리필은 연산 부담이 크고 디코드는 메모리 병목이어서 같은 복제본에서 돌리면 서로 기다린다. llm-d는 프리필, 디코드, 멀티모달 인코드를 별도 풀로 나누고 대형 전문가 혼합 모델은 넓은 전문가 병렬로 여러 노드에 분산한다. DisaggregatedSet은 다중 호스트 추론용 쿠버네티스 API인 LeaderWorkerSet 위에서 이 풀들을 하나로 관리한다.

새로 들어온 llm-d-async-processor는 Google Cloud Pub/Sub나 Redis 같은 큐에서 요청을 가져와 실시간 트래픽과 함께 라우팅한다. 남는 용량을 확인하고 엄격한 우선순위 레인과 할당량을 적용해 배치 작업이 대화형 사용자를 밀어내지 않게 한다. 강화 학습 중에는 롤아웃 생성이나 가중치 갱신 때문에 가속기가 40~60% 시간 놀기도 하는데, 시분할로 이 틈에 비동기 추론을 끼워 넣어 가속기 집계 가동률을 약 40% 기준선에서 70% 초과로 올린다고 Google은 밝혔다.

성능 분석 도구 Prism은 공개된 벤치마크를 둘러보는 오픈소스 대시보드다. 표준화된 llm-d-benchmark 레시피와 inference-perf 워크로드를 바탕으로 하며, 자기 클러스터의 실행 결과를 올려 처리량, 지연, 비용 곡선을 비교할 수 있다.1

공개된 수치와 사용 사례

Google이 밝힌 수치는 다음과 같다. Ironwood TPU(TPU 7x)의 에이전트 코딩 워크로드에서 접두사 인식 라우팅과 호스트 메모리 오프로드를 쓰자 일반 쿠버네티스 Service 대비 첫 토큰 시간 중앙값이 85% 넘게 줄고 전체 처리량은 2.4배가 됐다(2026년 10월 기준). Gemini 플랫폼(옛 Vertex AI)은 GKE Inference Gateway로 운영 트래픽을 처리하며 접두사 캐시 적중률을 35%에서 70%로 두 배로 높였다. 코딩 에이전트의 첫 토큰 시간은 35% 넘게, 급증하는 채팅 트래픽의 P95 첫 토큰 시간은 50% 넘게 줄었다.

미국과 유럽에 걸친 17,000노드 다중 리전 GKE에서 전문가 혼합 모델을 서빙한 벤치마크에서는 클러스터 세 곳으로 처리량이 2.9배 늘었고, 성공률은 99.9%, 라우팅 오버헤드는 1% 미만이었다. A3 Mega 클러스터에서 700억 매개변수 모델에 5만 토큰 프롬프트를 넣은 시험에서는 호스트 CPU 램에 더해 Managed Lustre까지 쓰는 다중 커넥터 오프로딩이 CPU 램만 쓸 때보다 첫 토큰 시간을 약 40%, 종단 지연을 30% 줄였고 GPU 시간 요구량은 60% 가까이 낮췄다.1

IBM은 최근 에이전트 코딩 시험에서 llm-d 라우터가 가능한 캐시 재사용의 97%를 확보했다고 밝혔다. IBM과 Red Hat은 별도 시연에서 소프트웨어 엔지니어링 에이전트 3,000개를 자체 호스팅 인프라에서 동시에 돌렸고, 같은 오픈 모델을 호스팅 서비스로 쓸 때보다 비용이 5~10배 낮았다고 말했다. IBM 연구소 수석 과학자이자 IBM Fellow인 Ruchir Puri는 이메일 코멘트에서 오픈 LLM과 llm-d가 연산 집약 문제의 추론 비용을 크게 낮출 수 있다고 말했다. 양자 오류 정정용 하드웨어 설계에서는 11.8배 효율 이점을 얻는 데 기여했다는 취지다.2

Snap의 Vinay Kola는 접두사 캐시 인식 라우팅으로 캐시 적중률이 최대 75~80%에 이르렀고, Envoy 기반 서비스 메시와도 쉽게 통합된다고 말했다. ZenteiQ 창업자 Sashikumaar Ganesan 교수는 자체 과학 파운데이션 모델의 합성 데이터 생성에 GKE Inference Gateway를 쓰면서 TPU v6e 1,000개당 하루 토큰 생성 용량을 14억 7천만 개에서 59억 7천만 개로 늘렸다고 밝혔다. 4배를 넘는 처리량 증가다. Mistral의 추론 엔지니어들은 유료 등급별로 엄격한 우선순위 대역을 적용하고, 풀이 포화되면 낮은 우선순위 요청을 보류하거나 버려 지연 목표를 지킨다고 설명했다. 이들은 llm-d와 DisaggregatedSet에 계속 기여하겠다고 했다.1

프로젝트 구성

SiliconANGLE에 따르면 llm-d는 지난해 IBM, IBM 자회사 Red Hat, Google이 CoreWeave, NVIDIA와 함께 공동 창립했고 IBM, Red Hat, Google이 주관 개발을 맡는다. AMD, Cisco, Hugging Face, Intel, Mistral AI도 기여하며, 현재 CNCF 샌드박스 프로젝트다. Google은 Red Hat, IBM 등과 공동 창립했고, 25개가 넘는 조직의 500명 넘는 기여자가 참여했다고 밝혔다. vLLM, SGLang 같은 추론 엔진과 함께 동작하며 모델 서버 둘레에 분산 라우팅과 운영 기능을 제공한다.1,2

댓글

기사에 대한 의견이나 틀린 내용 제보를 남겨 주세요.

댓글을 불러오고 있습니다.