GKE Inference Gateway + llm-d 실전 가이드: AI 추론팀이 이제 모델 서버보다 라우팅 계층부터 설계해야 하는 이유

2026년 들어 추론 병목은 단순히 GPU 수량 문제가 아니라, 긴 프롬프트·KV 캐시·급격한 트래픽 변동을 어떤 라우팅 규칙으로 다루느냐의 문제로 옮겨갔습니다. 이 글은 Google Cloud Next ’26에서 공개한 GKE Inference Gateway와 llm-d 조합을 중심으로, 쿠버네티스 기반 추론 스택을 운영하려는 팀이 무엇을 먼저 설계해야 하는지 정리합니다. 대상은 자체 모델 서빙을 검토하는 플랫폼 엔지니어와 MLOps 팀입니다. 반대로 Bedrock 같은 완전관리형 API만 쓰는 팀이라면 이 글의 설계 복잡도는 과할 수 있습니다.

1. 한 줄 문제 정의

요약: 추론 비용은 모델 자체보다도 요청을 어느 인스턴스로 보내고, KV 캐시를 어디에 두고, 언제 확장할지를 잘못 정할 때 더 빠르게 새어 나갑니다.

기존 LLM 서빙 글은 모델 서버를 vLLM로 할지 SGLang으로 할지에 집중하는 경우가 많았습니다. 그런데 실제 운영에서는 라우팅 계층이 더 먼저 무너집니다. 같은 모델이라도 긴 시스템 프롬프트가 반복되면 KV 캐시를 재사용한 인스턴스로 보내야 하고, 짧은 응답 위주 트래픽과 긴 응답 위주 트래픽을 같은 규칙으로 처리하면 TTFT와 처리량이 동시에 흔들립니다.

즉, 지금 문제는 “모델을 띄울 수 있느냐”가 아니라 “실제 요청을 운영 가능한 방식으로 분배할 수 있느냐”입니다. 이 글은 GKE Inference Gateway와 llm-d가 이 문제를 어떻게 풀려 하는지, 그리고 어디까지 믿고 어디서부터는 직접 검증해야 하는지 설명합니다.

2. 먼저 결론

요약: 자체 GPU/TPU 운영권이 있고 쿠버네티스 역량이 있는 팀이라면 검토 가치가 높지만, 작은 팀이나 초기 제품에는 완전관리형 API가 더 현실적입니다.

• 잘 맞는 팀: 동일 프롬프트 패턴이 많고, 긴 컨텍스트나 멀티테넌트 추론을 직접 최적화해야 하며, 비용·지연시간을 세밀하게 통제하려는 팀
• 과한 팀: 아직 하루 트래픽이 작고, GPU 운영보다 기능 출시 속도가 더 중요한 팀
• 제 판단: GKE Inference Gateway의 핵심 가치는 “쿠버네티스 위에서 추론 라우팅을 운영 개념으로 끌어올린 것”에 있습니다. 다만 이것이 곧바로 범용 정답은 아닙니다. 라우팅 규칙, 캐시 계층, 오토스케일링까지 이해할 운영팀이 없다면 Bedrock·Vertex의 관리형 추론 API가 더 안전합니다.

3. 핵심 구조 분해

요약: 이 스택은 모델 서버 하나가 아니라, 모델 서버 위에 라우터·스케줄러·캐시 계층을 겹쳐서 추론을 조율하는 구조입니다.

구조를 단순화하면 아래 네 층입니다.

1. 모델 서버 층: vLLM 같은 엔진이 실제 토큰 생성을 담당합니다.
2. 추론 라우팅 층: GKE Inference Gateway가 요청을 어느 백엔드로 보낼지 판단합니다.
3. 오케스트레이션 층: llm-d가 prefix-cache-aware routing, predicted latency scheduling, prefill/decode 분리 같은 고급 서빙 패턴을 제공합니다.
4. 인프라 층: GKE, GPU/TPU, Local SSD, GCS/Lustre, HPA가 실제 자원과 확장을 책임집니다.

중요한 점은 Google이 llm-d를 “모델 서버 대체재”로 밀지 않는다는 점입니다. llm-d는 vLLM 위에 얹는 상위 제어 계층에 가깝습니다. 그래서 이 조합의 경쟁 상대는 단순한 모델 서버가 아니라, 직접 만든 로드밸런서 + 캐시 정책 + 오토스케일링 스크립트 묶음입니다.

4. 설계 의도 해설

요약: 설계 목표는 최고 성능 자체보다 “SOTA 성능에 도달하는 시간”을 줄이는 데 있습니다.

Google과 llm-d가 반복해서 강조하는 문구는 time to SOTA입니다. 이 말은 팀마다 수개월씩 하던 추론 튜닝 작업을, 검증된 가이드와 스케줄러로 압축하겠다는 뜻입니다. 이는 두 가지 현실을 반영합니다.

• 첫째, 최신 LLM 서빙은 모델 자체보다 운영 파라미터가 더 어렵습니다. KV 캐시 오프로드 위치, 긴 프롬프트 처리 방식, prefill/decode 분리 여부에 따라 체감 성능이 크게 달라집니다.
• 둘째, 쿠버네티스 팀은 이미 Gateway API, HPA, 관측 도구를 갖고 있으므로, 새로운 폐쇄형 추론 플랫폼보다 기존 운영 체계에 얹히는 방식을 선호합니다.

대신 포기한 것도 있습니다. 완전관리형 서비스처럼 클릭 몇 번으로 끝나는 단순성은 버렸습니다. 운영 자유도를 얻는 대신, 라우팅 정책과 벤치마크 해석 책임을 사용자 팀이 더 많이 집니다.

5. 근거 및 비교

요약: 비교 기준은 제어권, 초기 속도, 비용 최적화 여지, 운영 난이도입니다.

선택지	장점	약점	적합한 상황
GKE Inference Gateway + llm-d	라우팅·KV 캐시·오토스케일링을 세밀하게 조정 가능, 쿠버네티스와 잘 맞음	구성 요소가 많고 운영 난이도가 높음	대규모/반복형 추론, 멀티테넌트, 긴 컨텍스트 최적화가 중요한 팀
vLLM 단독 운영	구조가 단순하고 시작이 빠름	고급 라우팅·분산 최적화는 직접 붙여야 함	단일 모델, 단일 테넌트, 초기 PoC
Amazon Bedrock 같은 관리형 API	빠른 출시, 인프라 운영 부담 낮음, 용량 관리 단순	세밀한 라우팅·캐시 최적화 제어권이 제한됨	제품 초기, GPU 운영 인력이 적은 팀

Google은 Predictive Latency Boost로 TTFT를 70% 이상 줄일 수 있다고 밝혔고, KV 캐시를 RAM으로 오프로드하면 10K 시스템 프롬프트에서 TTFT 40% 이상 감소, Local SSD 오프로드 시 50K 시스템 프롬프트에서 처리량 약 70% 개선을 제시했습니다. 다만 이 수치는 특정 벤치마크 조건에서 나온 값이므로 그대로 예산표에 넣으면 위험합니다. 반대로 AWS Bedrock은 2026년 4월 Claude Opus 4.7 공개와 함께 ‘새 추론 엔진’, 최대 10,000 RPM 즉시 사용 가능, 수요 급증 시 대기열 기반 처리 같은 관리형 강점을 내세웠습니다. 즉, Google 쪽은 최적화 여지, AWS 쪽은 운영 단순성이 강점입니다.

6. 실제 동작 흐름 / 단계별 실행 방법

요약: 이 스택은 모델 선택보다 먼저 지연시간 목표와 프롬프트 길이 분포를 정의해야 제대로 동작합니다.

1. 요구사항 수집: 목표 TTFT, output tokens/sec, 대표 프롬프트 길이, 멀티테넌트 여부를 수치로 적습니다. 예: TTFT 1200ms 이하, 평균 입력 8K tokens, P95 입력 40K tokens.
2. Inference Quickstart로 후보 조합 탐색: GKE Inference Quickstart에서 모델·가속기·서빙 스택 조합을 비교해 비용/성능 프로파일을 고릅니다.
3. 기본 스택 배포: 가장 단순한 baseline은 vLLM + GKE Inference Gateway입니다. 이때는 아직 llm-d의 고급 기능을 다 켜지 않습니다.
4. 트래픽 특성 확인: 긴 프롬프트 재사용이 많으면 prefix-cache-aware routing을 검토하고, 초장문 입력이면 prefill/decode 분리나 KV 오프로드를 붙입니다.
5. 오토스케일링 임계값 정의: CPU나 메모리 대신 queue, TTFT, 토큰 처리량 같은 추론 지표를 기준으로 HPA를 잡습니다.
6. 실부하 검증: inference-perf 또는 자체 리플레이로 실제 프롬프트 분포를 재현합니다. Google 기본 벤치마크는 입력/출력 분포가 고정되어 있으므로, 우리 서비스 패턴과 다르면 결과가 달라집니다.

# 예시 사고 흐름
1) gcloud container ai profiles list
2) 후보 프로파일의 benchmark 확인
3) kubectl apply 로 최적화된 manifest 배포
4) 실트래픽 리플레이로 TTFT/TPOT/P95 비용 재측정
5) 필요 시 llm-d의 cache-aware routing, tiered KV cache 적용

초보 팀이 가장 많이 놓치는 부분은 2단계입니다. 하드웨어를 먼저 정하면 대부분 과투자합니다. 먼저 입력 길이와 지연시간 목표를 수치화해야 어떤 캐시 계층이 필요한지 판단할 수 있습니다.

7. 실수/함정(Pitfalls)

요약: 이 스택은 “기능을 많이 켤수록 무조건 좋아지는” 구조가 아닙니다.

• 실수 1: 벤치마크 수치를 그대로 도입 예산에 사용
  예방: Google과 llm-d가 공개한 수치는 기준점으로만 쓰고, 반드시 자체 프롬프트 분포로 재측정합니다.
  복구: 실제 로그 기반 샘플셋을 만들어 TTFT·TPOT·$/token을 다시 계산합니다.
• 실수 2: KV 캐시 오프로드를 만능으로 착각
  예방: 짧은 요청 위주 서비스라면 오프로드 계층 추가가 오히려 운영 복잡도만 늘릴 수 있습니다.
  복구: 프롬프트 길이 구간별로 캐시 계층을 분리해 A/B 테스트합니다.
• 실수 3: 모델 서버 문제와 라우팅 문제를 구분하지 못함
  예방: p95 지연 상승 시 vLLM 자체 병목인지, 스케줄러 선택 실패인지 지표를 분리합니다.
  복구: gateway decision log, queue depth, cache hit rate를 함께 수집합니다.
• 실수 4: 운영팀 역량 없이 하이퍼클러스터급 아키텍처를 먼저 설계
  예방: 단일 리전·단일 모델 baseline부터 시작합니다.
  복구: 멀티리전, 멀티모델, RL 워크로드를 단계적으로 분리 도입합니다.

8. 강점과 한계

요약: 강점은 통제력, 한계는 복잡성입니다.

강점

• 쿠버네티스 기반 운영 체계에 자연스럽게 녹아듭니다.
• 긴 프롬프트, 반복 prefix, 멀티테넌트 같은 현실 문제를 라우팅 정책으로 다룰 수 있습니다.
• Inference Quickstart 덕분에 “무엇을 기준으로 시작해야 하나”를 수치화하기 쉽습니다.

한계

• 팀이 관측 체계와 성능 검증 문화를 갖추지 않으면 오히려 운영 난이도만 올라갑니다.
• Google 중심 스택이라 다른 클라우드나 단순 서버리스 추론 전략과는 결이 다릅니다.
• 공개 수치가 좋아도, 작은 제품에서는 Bedrock 같은 관리형 API가 총비용 면에서 더 나을 수 있습니다.

제 판단은 명확합니다. 월간 사용량이 아직 작고 모델 차별화보다 제품 학습 속도가 중요한 팀이라면 이 아키텍처는 시기상조입니다. 반대로 하루 종일 반복되는 enterprise prompt, 긴 컨텍스트, 멀티테넌트 비용 압박을 겪는 팀이라면 지금부터 라우팅 계층을 설계하지 않으면 GPU 추가 구매만 반복하게 됩니다.

9. 더 깊게 공부할 포인트

요약: 공부 순서는 모델 서버보다 라우팅·캐시·벤치마크 해석입니다.

1. GKE Inference Quickstart 문서에서 NTPOT, TTFT, throughput curve가 어떻게 추천값으로 바뀌는지 이해합니다.
2. llm-d의 optimized baseline, predicted latency scheduling, tiered prefix cache 가이드를 읽습니다.
3. vLLM 단독 운영과 llm-d 상위 오케스트레이션의 역할 차이를 구분합니다.
4. 관리형 대안으로 Bedrock이나 Vertex AI의 추론 API가 얼마나 운영 부담을 줄이는지 비교합니다.
5. 실제 서비스 로그로 프롬프트 길이 분포와 응답 길이 분포를 먼저 뽑아봅니다.

10. 실행 체크리스트 + 작성자 관점

요약: 이 스택은 ‘좋은 모델’을 찾는 작업이 아니라 ‘좋은 운영 기준’을 세우는 작업입니다.

• 우리 서비스의 P50/P95 입력 토큰 길이를 알고 있는가?
• TTFT와 TPOT 목표를 숫자로 정의했는가?
• 반복 prefix 비율이 높아 cache-aware routing 이점이 있는가?
• GPU/TPU 비용보다 운영 인건비가 더 큰 상황은 아닌가?
• 실제 트래픽 리플레이용 샘플셋과 관측 대시보드가 준비되어 있는가?
• 관리형 API와 자체 운영의 총소유비용(TCO)을 비교했는가?
• 장문 입력과 단문 입력을 같은 서빙 정책으로 묶지 않았는가?

Definition of Done: 실제 프롬프트 분포 기준으로 baseline·cache-aware·KV offload 세 구성을 비교해 P95 지연과 비용이 모두 문서화되어야 도입 검토가 끝난 것입니다.

작성자 관점: 저는 이 조합을 “추론을 쿠버네티스에서 진짜 운영하기 시작한 팀”에게 추천합니다. 반대로 아직 모델 호출량이 적고, 실험 속도가 더 중요한 스타트업 초기 단계라면 관리형 API를 먼저 쓰는 편이 맞습니다. 자체 운영은 자유도가 아니라 책임까지 함께 가져옵니다.

참고자료

• What’s new in GKE at Next ’26 (Google Cloud, 2026-04-22)
• AI infrastructure at Next ’26 (Google Cloud, 2026-04-22)
• Analyze model serving performance and costs with GKE Inference Quickstart (Google Cloud Docs, accessed 2026-04-23)
• llm-d GitHub repository and guides (llm-d, accessed 2026-04-23)
• Introducing Anthropic’s Claude Opus 4.7 model in Amazon Bedrock (AWS, 2026-04-16)