GKE LLM 서빙 비용 2026, GPU 추론 비용 줄이기 전 확인할 운영 기준

GKE LLM 서빙 비용 최적화를 위한 GPU 서버와 비용 대시보드 검토 장면 — LLM 추론 비용은 GPU 단가보다 처리량, 지연, 유휴 시간, 로그 정책을 함께 봐야 한다.

GKE LLM 서빙 비용을 볼 때 가장 먼저 꺼내야 할 숫자는 GPU 시간당 단가가 아니다.

같은 GPU를 쓰더라도 토큰 처리량, 첫 토큰 지연, 큐 길이, 유휴 시간, 로그 보존 정책에 따라 실제 답변 하나의 원가가 달라진다.

Google Cloud가 Ray Serve와 GKE 조합에서 throughput과 latency 개선을 공개한 이유도 이 지점에 있다.

모델 서버가 같은 하드웨어를 더 잘 쓰면 GPU 증설 없이 요청을 더 많이 처리하고, 반대로 라우팅 병목이 있으면 비싼 노드가 놀게 된다.

이 글은 원문 벤치마크를 그대로 옮기지 않는다.

GKE에서 LLM 추론 API를 직접 운영하려는 팀이 비용, 보안, 운영 기준을 어떤 순서로 검증해야 하는지에 초점을 둔다.

결론부터 말하면 실서비스 전에는 “GPU 노드 수”보다 “성공 답변 1천 건당 GPU 시간”과 “p95 지연을 지킨 상태의 최대 처리량”을 먼저 계산해야 한다.

핵심 요약

GKE LLM 서빙 비용은 GPU·TPU 단가, pod replica, queue length, token streaming, log ingestion을 함께 본다.
Ray Serve, vLLM, GKE Inference Gateway 같은 구성 요소는 성능 기능이 아니라 비용 통제 지점으로 봐야 한다.
오토스케일링은 최대 노드 수보다 scale-down 조건, cold start 허용 범위, 야간 유휴 GPU 차단이 핵심이다.
발행 전 기준은 5,000자 분량보다 실무 기준이다. 파일럿은 부하 테스트, 보안 로그, 예산 알림, 장애 롤백까지 통과해야 한다.

이 글이 필요한 사람

GKE 위에서 사내 RAG 챗봇이나 LLM API를 직접 운영하려는 ML 플랫폼 팀
Vertex AI API와 자체 서빙 중 어느 쪽이 비용상 맞는지 비교해야 하는 CTO 또는 플랫폼 리드
GPU 노드 유휴 시간과 Cloud Logging 비용 때문에 월말 청구서를 설명해야 하는 FinOps 담당자
Ray Serve, vLLM, GKE Inference Gateway를 조합하기 전 운영 책임 범위를 정하려는 SRE
프롬프트 로그, 모델 응답 로그, 권한 분리를 점검해야 하는 보안팀

1. GKE LLM 서빙 비용의 단위는 GPU 시간이 아니라 성공 답변이다

GPU node hour만 보면 단순하다.

그러나 운영자는 실제로 “몇 개의 답변을 얼마의 지연으로 처리했는가”를 설명해야 한다.

GKE LLM 서빙 비용은 최소 네 조각으로 나눈다.

accelerator 비용, Kubernetes 노드와 제어 비용, 네트워크와 로드밸런서 비용, 로그와 모니터링 비용이다.

여기에 모델 서버 레이어가 붙는다.

Ray Serve, vLLM, TensorRT-LLM, custom FastAPI wrapper처럼 어떤 서버를 쓰느냐에 따라 batching, streaming, cache, replica 배치 방식이 달라진다.

비용 항목	실제 질문	측정 지표	위험 신호
GPU·TPU	피크에 맞춘 노드가 평시에도 계속 켜져 있는가	gpu_hours, gpu_utilization, idle_minutes	평균 GPU 사용률은 낮은데 p95만 높다
모델 서버	batching과 streaming이 하드웨어를 충분히 쓰는가	tokens_per_second, ttft, queue_length	replica는 늘었지만 처리량이 비례하지 않는다
Kubernetes	pod request와 node pool 크기가 맞는가	pending_pods, node_scale_events	GPU quota 부족으로 scale-out이 실패한다
네트워크	외부 호출과 streaming 응답이 비용을 만들고 있는가	egress, load_balancer_bytes	내부 서비스인데 외부 LB 경유가 남아 있다
로그·관측	프롬프트와 응답을 너무 많이 남기고 있는가	log_gib, trace_sample_rate	민감 데이터와 긴 응답이 로그에 섞인다

이 조건이면 자체 GKE 서빙 검토가 맞다.

트래픽이 일정하고, 모델 서버 튜닝 인력이 있으며, 답변당 원가와 지연을 직접 줄일 여지가 크다면 파일럿 가치가 있다.

반대로 요청량이 낮고 운영 인력이 없으며, 보안 검토가 API 사용 조건만으로 충분한 팀이라면 관리형 API나 Vertex AI 계열을 먼저 비교하는 편이 현실적이다.

2. Ray Serve와 GKE 조합은 성능 개선이 아니라 병목 제거로 읽어야 한다

Google Cloud Blog는 Ray Serve LLM on GKE 개선에서 HAProxy 기반 라우팅, direct token streaming, vLLM Ray executor backend 개선을 언급한다.

이 표현을 “무조건 빠르다”로 받아들이면 위험하다.

실무에서는 세 개선점이 어디 비용으로 연결되는지 봐야 한다.

라우팅 overhead가 줄면 같은 GPU replica가 더 많은 요청을 받고, token streaming path가 짧아지면 사용자가 느끼는 첫 응답 지연이 줄어든다.

vLLM 쪽 executor 개선은 scheduling과 data path의 병목을 줄이는 방향으로 해석하는 것이 안전하다.

다만 블로그의 벤치마크 조건과 우리 모델, 입력 길이, 출력 길이, replica 수가 같다고 보면 안 된다.

구성 요소	비용 관점의 의미	파일럿에서 볼 지표	보류 기준
Ray Serve	Python 기반 서비스 조합과 replica 관리를 한 레이어에서 다룬다.	replica별 queue, error, autoscaling event	운영팀이 Ray 상태와 Kubernetes 상태를 함께 못 본다
vLLM	연속 batching과 토큰 생성 효율이 GPU 사용률에 직접 영향을 준다.	tokens/sec, KV cache hit, p95 latency	입력 길이가 길어질 때 지연이 급격히 흔들린다
GKE Inference Gateway	AI inference에 맞춘 routing과 관측 기준을 Gateway 레이어에 둔다.	request queue, accelerator utilization, routing decision	표준 Ingress와 운영 책임 경계가 불명확하다
GKE autoscaling	GPU 노드를 필요할 때 늘리고 필요 없을 때 줄이는 비용 장치다.	scale-up time, scale-down delay, pending pod	피크 한 번 때문에 하루 종일 GPU가 켜져 있다

실무 시나리오 하나.

사내 RAG 챗봇이 오전 9시와 오후 2시에만 몰린다면 max node를 키우기 전에 scale-down 시간을 줄이고 warm pool이 필요한지 확인해야 한다.

실무 시나리오 둘.

고객지원 봇이 항상 일정한 트래픽을 받는다면 spot 위주의 비용 절감보다 replica 안정성, queue length, 장애 시 fallback 응답을 먼저 본다.

3. 벤치마크는 throughput이 아니라 원가표로 바꿔야 한다

벤치마크 숫자는 좋은 출발점이지만 구매 결정을 대신하지 않는다.

모델 크기, context length, batch policy, streaming 여부, region, quota, driver 버전이 달라지면 같은 구성도 다른 비용을 만든다.

GKE Inference Quickstart 문서는 performance와 cost requirement로 구성을 탐색하는 흐름을 제공한다.

이 접근은 “어떤 GPU가 빠른가”보다 “우리 목표 지연에서 가장 싸게 버티는 조합이 무엇인가”를 묻는 방식에 가깝다.

측정값	왜 비용과 연결되는가	수집 위치	판단 기준
TTFT	첫 토큰 지연이 높으면 사용자는 느리다고 느끼고 replica 증설 압박이 커진다.	gateway trace, model server metric	목표 이하에서 GPU 사용률이 안정적인지 확인
p95 latency	평균이 좋아도 긴 요청이 몰리면 scale-out 비용이 커진다.	APM, load test report	업무 SLA 기준으로 p95와 p99를 분리
tokens/sec	같은 GPU 시간으로 처리한 token 수가 답변 원가를 좌우한다.	vLLM/Ray metric, custom exporter	모델별·prompt 길이별로 따로 계산
success per GPU hour	성공 답변 기준으로 비용을 설명할 수 있다.	billing export + request log aggregate	실패 요청과 재시도 비용을 별도 표시
log GiB	긴 prompt와 response 로그는 관측 비용과 보안 위험을 동시에 키운다.	Cloud Logging, sink metric	샘플링과 redaction 적용 후 재측정

파일럿 표에는 모델별 단가 추정치를 적지 않는 편이 낫다.

공개 가격과 계약 조건이 바뀌기 때문에 “실제 단가”는 Cloud Billing export와 가격표 확인일을 남겨 계산해야 한다.

대신 답변 1천 건당 GPU 시간, 1만 output token당 평균 지연, 에러율이 오른 날의 재시도 비용처럼 바뀌어도 비교 가능한 단위를 만든다.

4. GPU 노드 풀과 오토스케일링은 비용 차단선부터 정한다

GKE GPU 문서는 Autopilot과 Standard에서 GPU를 요청하는 방식이 다르다는 점을 설명한다.

비용을 직접 통제하려는 팀은 이 차이를 운영 책임 차이로 봐야 한다.

Standard node pool은 세밀한 제어가 가능하지만 capacity, driver, node pool lifecycle 책임이 커진다.

Autopilot은 운영 부담을 줄일 수 있지만 workload 요청과 지원 범위를 더 꼼꼼히 확인해야 한다.

결정 지점	Standard 쪽 질문	Autopilot 쪽 질문	비용 차단선
GPU 선택	노드 타입과 GPU 개수를 직접 고를 근거가 있는가	workload 요청 방식으로 필요한 accelerator가 지원되는가	검증 없는 최고 사양 GPU 사용 금지
scale-down	야간과 주말에 node pool이 0까지 내려가도 되는가	cold start가 사용자 경험을 깨지 않는가	업무 시간 외 유휴 GPU 알림
quota	region별 GPU quota와 장애 대체 region이 있는가	quota 부족 시 fallback 경로가 있는가	scale-out 실패 알림 필수
spot 사용	중단되어도 되는 batch 또는 비핵심 endpoint인가	재시작과 graceful drain을 감당하는가	실시간 고객 API에는 단독 사용 금지
관측 비용	prompt 로그를 어느 수준까지 남길 것인가	trace sampling과 redaction을 적용했는가	민감 prompt 원문 로그 금지

이 조건이면 Standard가 맞다.

GPU 종류, driver, node pool, spot 혼합, custom metric autoscaling을 직접 다룰 인력이 있고, 그 제어가 비용 절감으로 돌아온다는 근거가 있을 때다.

이 경우는 Autopilot이나 관리형 경로를 검토한다.

팀이 모델 품질과 애플리케이션 로직에 집중해야 하고, GPU 인프라 운영을 맡을 SRE가 부족하면 낮은 단가보다 낮은 운영 부담이 더 중요하다.

5. 비용 절감은 모델 경량화보다 라우팅과 캐시에서 먼저 나온다

모델을 작게 바꾸면 비용은 줄 수 있다.

그러나 품질 저하를 감수하지 않고 먼저 볼 수 있는 지점은 routing, batching, cache, request shaping이다.

GKE Inference Gateway는 inference workload에 맞춘 routing과 관측 개념을 제공한다.

이 레이어를 검토할 때는 제품 이름보다 request queue, accelerator utilization, KV cache 관련 metric을 실제로 볼 수 있는지가 중요하다.

짧은 Q&A와 긴 문서 요약을 같은 endpoint에 섞지 않는다.
입력 길이와 출력 길이 기준으로 traffic class를 나눈다.
긴 context RAG 요청은 별도 queue와 replica 정책을 둔다.
streaming 응답은 사용자 경험을 개선하지만 connection 점유와 LB 비용을 함께 본다.
캐시 hit가 가능한 system prompt, retrieval result, embedding result를 분리해서 측정한다.

실무 시나리오 셋.

개발자용 코드 설명 봇은 긴 context와 높은 출력 길이가 많다.

이 트래픽을 일반 고객 FAQ 봇과 섞으면 짧은 요청까지 긴 queue에 갇혀 p95가 흔들린다.

먼저 traffic class를 나누고, 긴 요청에는 별도 quota와 timeout을 둔다.

그 다음 모델 경량화나 GPU 변경을 검토해야 원인과 효과가 섞이지 않는다.

6. 보안과 로그 정책을 비용 정책과 같이 써야 한다

LLM 서빙에서 로그는 비용이자 보안 위험이다.

prompt, retrieval document, response, trace를 모두 원문으로 남기면 Cloud Logging 비용도 늘고 민감 데이터 노출 면적도 커진다.

운영팀은 로그를 줄이면 장애 분석이 어려워진다고 걱정한다.

그래서 “무엇을 남기지 않을지”와 “무엇을 집계값으로 남길지”를 나눠야 한다.

로그 대상	원문 저장 여부	대신 남길 값	운영 이유
사용자 prompt	기본 금지	길이, 언어, traffic class, redaction 결과	개인정보와 영업 비밀 노출 차단
retrieval 문서	기본 금지	문서 ID hash, top-k, score bucket	RAG 품질 분석과 정보 보호 균형
모델 응답	샘플링 또는 비저장	token 수, finish reason, policy flag	긴 응답 로그 비용 억제
trace	샘플링	TTFT, p95, route, replica ID	장애 분석에 필요한 구조만 유지
billing 집계	저장	gpu_hours, request_count, log_gib	월간 비용 리뷰와 예산 알림

보안팀이 먼저 확인할 것은 외부 노출 여부만이 아니다.

Workload Identity, private endpoint, image provenance, secret 주입 방식, dev/prod 프로젝트 분리도 GKE LLM 서빙 비용 판단에 들어간다.

보안 통제가 약하면 비용 절감 실험도 멈춰야 한다.

prompt 로그에 개인정보가 섞이면 log sampling을 줄이는 것이 아니라 redaction과 저장 금지 정책을 먼저 적용해야 한다.

7. GKE LLM 서빙 비용 점검 스켈레톤

아래 YAML은 실제 배포 파일이 아니라 비용 검토 항목을 고정하기 위한 운영 메모 예시다.

단가를 하드코딩하지 않고, 측정 위치와 차단 조건을 남기는 구조로 쓴다.

# gke-llm-serving-cost.yaml
# 목적: GKE LLM 서빙 비용을 GPU 시간만이 아니라 처리량, 지연, 오류율, 로그 비용으로 함께 본다.
# 실제 단가와 machine type은 Google Cloud 가격표와 조직 계약 기준으로 다시 채운다.

service:
  name: rag-chat-api
  platform: gke-standard
  model_server: ray-serve-vllm
  model_family: open-model-or-private-model
  data_classification: internal

traffic_assumption:
  peak_rps: 12
  average_rps: 2
  target_ttft_ms: 900
  target_p95_latency_ms: 4500
  monthly_input_tokens: estimate_from_gateway_logs
  monthly_output_tokens: estimate_from_gateway_logs

capacity:
  node_pool:
    accelerator: gpu-or-tpu-profile
    min_nodes: 0
    max_nodes: 4
    preemptible_or_spot: evaluate_for_noncritical
  serving:
    replicas: 2
    max_ongoing_requests_per_replica: verify_by_load_test
    kv_cache_policy: monitor_hit_ratio
    autoscaling_metric:
      - gpu_utilization
      - request_queue_length
      - p95_latency

cost_controls:
  hard_block_if:
    - no_budget_owner
    - no_scale_down_after_hours
    - no_error_budget_for_latency
    - logs_include_prompt_or_personal_data
    - no_quota_limit_for_gpu_region
  review_weekly:
    - gpu_idle_minutes
    - failed_request_ratio
    - tokens_per_successful_answer
    - cache_hit_ratio
    - log_ingestion_gib
    - egress_and_load_balancer_cost

security:
  require_private_endpoint: true
  redact_prompt_logs: true
  separate_dev_prod_projects: true
  workload_identity: required
  image_provenance_check: required

월간 리뷰 때는 billing export와 gateway 집계를 붙이면 더 정확해진다.

아래 스크립트는 최소 컬럼만으로 GPU 시간, 성공 요청, 지연, 오류율, 로그 GiB의 위험 신호를 표시하는 예시다.

#!/usr/bin/env python3
# gke_llm_cost_guard.py
# Cloud Billing export나 gateway 집계 CSV를 넣기 전, 최소한의 위험 신호를 로컬에서 확인하는 예시다.

import csv
from pathlib import Path

path = Path('gke_llm_serving_daily.csv')
required = ['date', 'gpu_hours', 'successful_requests', 'p95_latency_ms', 'error_rate', 'log_gib']

if not path.exists():
    raise SystemExit('gke_llm_serving_daily.csv 파일을 먼저 준비하세요')

with path.open(newline='', encoding='utf-8') as f:
    rows = list(csv.DictReader(f))

if not rows:
    raise SystemExit('CSV에 데이터가 없습니다')

missing = [column for column in required if column not in rows[0]]
if missing:
    raise SystemExit('필수 컬럼 누락: ' + ', '.join(missing))

for row in rows:
    gpu_hours = float(row['gpu_hours'] or 0)
    success = float(row['successful_requests'] or 0)
    p95 = float(row['p95_latency_ms'] or 0)
    errors = float(row['error_rate'] or 0)
    log_gib = float(row['log_gib'] or 0)
    gpu_per_1k = gpu_hours / max(success / 1000, 1)
    warnings = []
    if gpu_per_1k > 1.5:
        warnings.append(f'GPU hour per 1k requests high: {gpu_per_1k:.2f}')
    if p95 > 5000:
        warnings.append(f'p95 latency high: {p95:.0f}ms')
    if errors > 0.02:
        warnings.append(f'error rate high: {errors:.2%}')
    if log_gib > 50:
        warnings.append(f'log ingestion high: {log_gib:.1f}GiB')
    if warnings:
        print(row['date'] + ' | ' + ' / '.join(warnings))

이 스켈레톤의 목적은 자동 최적화가 아니다.

비용 논쟁을 “GPU 비싸다”에서 “어느 traffic class가 목표 지연을 못 지키고 GPU 시간을 태우는가”로 바꾸는 것이다.