동일한 GPU 16개로 두 배의 사용자 지원: LLM 클러스터를 위한 추론 인식 라우팅

요약: 동일한 GPU 16개로 두 배의 사용자를 지원합니다. GPU 비용은 그대로 유지하면서 용량은 두 배로 늘어납니다. 동시 사용자 20명을 처리하던 클러스터가 이제 200명을 처리합니다. 이러한 수치는 모든 노드, 대기열, 캐시에 대한 가시성을 바탕으로 분산 클러스터 전반에서 모든 요청을 라우팅하도록 설계된 llm-d의 추론 스케줄러를 통해 가능합니다. 대규모 언어 모델(LLM) 요청은 느리고 일정하지 않으며 비용이 많이 듭니다. 추론 스케줄러는 바로 이러한 문제를 해결하기 위해 구축되었습니다.

다른 모든 환경에서 적용되는 패턴

모든 GPU 시간당 비용이 발생하므로, 중요한 것은 이를 통해 얼마나 많은 작업을 수행하느냐입니다.

쿠버네티스는 분산 서비스를 대규모로 구축, 배포, 운영하는 방식입니다. 표준 쿠버네티스 구성에서는 배포를 정의하고 복제본 수를 설정하면 쿠버네티스 서비스가 모든 포드(Pod)에 걸쳐 라운드 로빈 부하 분산 기능을 제공합니다. REST API, 웹 서비스, 마이크로서비스의 경우 이 패턴은 거의 완벽합니다. 요청은 빠르고 균일하며, 각 요청을 완료하는 데 1초 미만의 거의 동일한 시간이 소요됩니다.

하지만 Llama, Mistral 또는 GPT급 오픈소스 모델과 같은 대규모 생성형 모델을 대규모로 서비스하기 시작하면 이러한 가정은 더 이상 유효하지 않습니다.

라운드 로빈 방식이 한계에 부딪히는 지점

LLM 추론 요청은 일반적인 HTTP 요청과 다르며, 이러한 차이로 인해 표준 부하 분산이 제대로 작동하지 않습니다.

• 시간 가변성: 모델이 수행해야 하는 작업에 따라 요청 처리에 1초 미만이 걸릴 수도, 1분 이상이 걸릴 수도 있습니다. 라운드 로빈은 실제 작업량이 아닌 요청 건수를 분산합니다. 하나의 복제본에 길고 비용이 많이 드는 요청이 연달아 들어오면 병목 현상이 발생하는 반면, 다른 복제본은 대부분 유휴 상태로 남게 됩니다.
• 형태 가변성: 응답이 긴 짧은 프롬프트는 응답이 짧은 긴 프롬프트와 다르게 작동합니다. 컴퓨팅 프로필, 메모리 부하, 완료 시간 등이 모두 다릅니다.
• 단계 가변성: 모든 추론 요청에는 두 가지 내부 단계가 있습니다. 전체 입력 프롬프트를 한 번에 병렬로 처리하는 사전 채우기(prefill)와 응답을 한 번에 1토큰씩 생성하는 디코딩(decode)입니다. 이 두 단계는 리소스 프로필, 소요 시간, 부하에 대한 민감도가 서로 다릅니다. 이를 구분하지 못하는 시스템은 어느 쪽도 최적화할 수 없습니다.

라운드 로빈은 요청이 일시적이고 균일하며 비용이 적게 드는 워크로드를 위해 고안되었습니다. 요청 내부를 파악하지 못하는 스케줄러는 모든 요청을 동일하게 취급합니다.

그림 1: 라운드 로빈은 작업량이 아닌 요청 수만을 분산합니다. 크기와 컴퓨팅 비용이 서로 다른 5개의 동일한 요청이 포드 간에 고르지 않게 배분됩니다. 하나의 포드가 2개의 긴 요청을 처리하느라 과부하가 걸리는 동안 다른 포드는 대부분 유휴 상태를 유지합니다. 추론 인식 라우팅은 형태, 규모, 부하를 파악하여 실제 작업량의 균형을 맞춥니다.

잘못된 포드의 캐시 히트: 사실상 캐시 미스인 이유

vLLM은 LLM의 사실상 표준 추론 엔진입니다. 모든 주요 하드웨어 가속기가 이에 최적화되어 있으며, 새로운 모델은 출시 당일부터 vLLM을 지원합니다. vLLM은 단일 노드에서의 추론 메커니즘을 매우 효율적으로 처리합니다.

vLLM은 동일한 프롬프트 접두사를 반복해서 재처리하는 추론의 고비용 문제를 해결하기 위해 접두사 캐싱을 도입했습니다. 여러 요청이 공통 접두사(시스템 프롬프트, 문서, 대화 기록 등)를 공유하는 경우 vLLM은 첫 번째 계산의 키-값(KV) 상태를 캐시하여 후속 요청에 재사용할 수 있습니다. 캐시가 적중하면 사전 채우기 단계가 완전히 생략됩니다. 첫 번째 토큰까지의 시간(TTFT)은 이미 캐시된 프롬프트의 비율에 비례하여 단축되지만, 이는 요청이 해당 캐시를 보유한 특정 복제본에 도달할 때만 가능합니다.

특정 복제본에서 거의 비용 없이 처리될 수 있는 요청이 다른 복제본으로 라우팅되어 처음부터 다시 시작하게 되는 경우가 발생합니다. 최적화 기능이 존재하더라도 라운드 로빈 라우팅은 이를 활용하지 못합니다.

트래픽이 적을 때는 단순히 기회를 놓치는 것에 불과합니다. 하지만 규모가 커지면 동일한 계산에 대해 두 번 비용을 지불하게 됩니다.

노드 단위를 넘어 클러스터 수준으로 확장

각 vLLM 포드가 메모리를 관리하고 효율적으로 배치 처리하며 하드웨어 성능이 허용하는 한 빠르게 토큰을 제공하여 요청을 잘 처리하더라도, 각 포드는 자기 자신의 상태만 확인할 수 있습니다. 다른 포드에서 무엇을 처리 중인지, 어떤 복제본에 부하가 걸려 있는지, 또는 클러스터 전체에서 접두사 캐시 상태가 어디에 위치하는지 알지 못합니다. 

조정 문제는 노드 상위 계층에서 발생하며 쿠버네티스는 대규모 분산 인프라 및 오케스트레이션을 위한 최적의 플랫폼입니다. 따라서 llm-d는 이 문제를 정확히 해결하기 위해 처음부터 쿠버네티스 네이티브 방식으로 구축되었습니다. 

실제로 이는 Inference Gateway(IGW)를 통해 구현됩니다. IGW는 HTTP뿐만 아니라 LLM 워크로드를 이해하는 Envoy 및 쿠버네티스 게이트웨이 API를 기반으로 구축된 트래픽 계층입니다. 그 이면에서 추론 스케줄러는 InferencePool의 모든 포드 상태(대기열 깊이, KV 캐시 상태, 부하 등)를 실시간으로 모니터링하고, 각 요청을 단순히 순서대로 보내는 것이 아니라 가장 적합한 인스턴스로 라우팅합니다.

그림 2: Inference Gateway(IGW)는 각 요청을 수신하고 ext_proc를 통해 Inference Scheduler(EPP)를 참조합니다. 스케줄러는 두 가지 실시간 신호(KV 캐시 상태 및 부하)를 기반으로 InferencePool의 모든 포드 점수를 산출하여 선택된 엔드포인트를 IGW에 반환하며, IGW는 해당 요청을 전달합니다. 캐시 적중 시 사전 채우기의 캐시된 부분이 재사용되어 디코딩이 즉시 시작됩니다. 캐시 누락 시에는 사전 채우기 단계가 전체 실행됩니다.

대규모 환경에서의 추론 스케줄링: 동일한 하드웨어에서 두 배의 용량 구현

추론 스케줄러(llm-d의 Inference Scheduler 또는 EPP)는 클러스터 수준의 조정을 구체적으로 실현합니다. 모든 파드(pod)를 동일하게 다루는 대신 KV 캐시 상태, 대기열(큐) 깊이, 부하 등 실시간 신호를 기반으로 각 요청을 라우팅합니다. 이를 통해 매번 모든 요청이 가장 적절한 인스턴스로 전달됩니다.

llm-d v0.5의 벤치마크 결과는 이러한 방식이 실제로 어떤 효과를 주는지 보여줍니다.

추론 스케줄링(Qwen3-32B, vLLM 포드 8개, NVIDIA H100 16개):

• 기본 쿠버네티스 서비스 대비 처리량이 최대 109% 향상되었습니다. 동일한 16개의 GPU로 서비스 수준 목표(SLO)를 유지하면서 약 두 배 더 많은 동시 사용자를 수용할 수 있습니다.
• 동일한 부하에서 첫 번째 토큰까지의 시간(TTFT)이 최대 99% 단축되었습니다. 벤치마크 결과에 따르면 높은 부하 환경에서 기본 TTFT는 약 80초까지 급증합니다. 반면 지능형 스케줄링을 사용하면 이를 약 150ms 수준으로 유지할 수 있습니다. 이것이 바로 제대로 작동하지 않는 것처럼 느껴지는 서비스와 즉각적으로 반응하는 서비스의 차이입니다.
  • 벤치마크 결과 16개의 GPU에서 초당 약 11,000개의 출력 토큰을 안정적으로 처리합니다. 응답당 약 1,000토큰, 활성 사용자당 분당 약 3회의 요청을 가정할 때, 이는 기본 쿠버네티스 서비스가 20명을 넘기기 힘든 하드웨어에서 SLO를 준수하며 약 200명의 동시 사용자를 처리할 수 있음을 의미합니다.

모든 결과는 버전 관리되며 재현 가능한 특정 가이드와 연계되어 있습니다.

그림 3: llm-d 추론 스케줄링과 기본 쿠버네티스 비교 — QPS 대비 평균 TTFT 및 총 처리량 토폴로지: vLLM 포드 8개, NVIDIA H100 16개(TP=2) 워크로드: 공유 접두사 합성, 150개 그룹 × 5개 프롬프트, 6k/1.2k/1k 시스템/질문/출력 길이 결과: P50 TTFT 136~157ms, 출력 토큰 4.5~11k/s, 기본 대비 처리량 최대 109% 향상 및 TTFT 99% 단축 출처: llm-d v0.5

vLLM은 노드를 최적화하고, llm-d는 클러스터를 최적화

vLLM과 llm-d는 상호 보완적으로 작동하도록 설계되었으며, 두 솔루션을 함께 사용할 때의 성능 차이는 매우 뚜렷합니다. 동일한 하드웨어에서 사용자 수는 2배로 늘리고 부하 시 대기 시간은 99% 개선하며, 동시 사용자 250명 환경에서도 20명일 때와 다름없는 안정적인 클러스터 성능을 유지합니다.

현재 2개 이상의 복제본을 운영 중이라면 지능형 추론 스케줄링을 즉시 워크로드에 적용할 수 있습니다. 이러한 성능 차이는 단순히 수치가 조금 나아지는 수준이 아니라, 원활하게 확장되는 클러스터와 어려움을 겪는 클러스터를 가르는 결정적인 차이입니다. 

이것이 바로 분산 추론의 시작입니다.

직접 대규모 확장을 경험해 보세요

이 블로그 포스트의 모든 수치를 뒷받침하는 llm-d 가이드와 벤치마크 구성은 공개되어 있으며 언제든 재현할 수 있습니다. llm-d v0.5 릴리스를 살펴보는 것부터 시작해 보세요.

Red Hat AI Enterprise에는 엔터프라이즈 지원 버전의 llm-d가 포함되어 있으며, Red Hat AI Enterprise 60일 무료 체험판을 통해 이용해 보실 수 있습니다. 자체 인프라에서 이를 실행해 보려는 경우 여기서 시작하는 것이 좋습니다.

스케줄러가 실제로 어떻게 작동하는지 먼저 확인하고 싶다면 llm-d 인터랙티브 데모 소개를 통해 요청 라우팅 과정을 살펴보시기 바랍니다.

저자 참고 사항: 벤치마크 데이터는 llm-d v0.5 릴리스를 기반으로 합니다. 모든 결과는 llm-d 가이드에 게시된 버전 관리 구성을 사용하여 재현할 수 있습니다.