LLM 서빙, 띄우는 것과 잘 띄우는 것 사이

토스증권의 ML 엔지니어링 팀이 오픈소스 LLM과 자체 튜닝 모델을 서비스에 올리면서 겪은 운영 문제와 해결 과정을 다룬다. 단순히 모델을 배포하는 것과 효율적으로 서빙하는 것 사이의 간극을 모니터링 체계 구축과 세 가지 실제 사례로 보여준다.

핵심 포인트

LLM은 토큰을 순차 생성하므로 기존 ML 지표(단건 응답시간, 초당 처리량)보다 TTFT(첫 토큰까지 시간)와 초당 생성 토큰 수가 더 적합한 지표다.
Grafana + Kibana 기반 중앙화 대시보드로 vLLM·SGLang의 LLM 특화 지표를 통합 수집해 이상 탐지 속도를 높였다.
Prefix Cache 비활성화 하나로 TTFT가 20초였던 것이 1/10 수준으로 줄고 캐시 히트율이 90% 이상으로 개선됐다.
vLLM 버그로 리즈닝 모델에서 불필요한 토큰이 계속 생성되는 문제를 워크어라운드로 에러율 0.2% → 0.02%로 낮췄다.
KV 캐시 사용률 1% 미만인 채로 증설 요청이 왔지만, 테스트로 동시성 20까지 수용 가능함을 확인해 파드 증설 없이 4배 트래픽 처리 여지를 찾았다.

상세 정리

초기 문제: 타임아웃 에러 알림이 와도 어느 모델·경로에서 발생했는지 알 방법이 없었다. 각 팀이 개별 모니터링하는 분산 체계라 대응이 느렸다.
지표 재정의: 기존 단건 응답시간·초당 처리량은 LLM처럼 토큰을 순차 생성하는 모델에 변동성이 심해 맞지 않는다. TTFT와 초당 생성 토큰 수로 전환.
플랫폼 구축: vLLM·SGLang의 내장 메트릭 엔드포인트를 Grafana로 중앙화하고, 개별 요청 로그는 Kibana로 분석. 팀 공통 대시보드로 이상 신호 탐지.
사례 1 - Prefix Cache 비활성화: 특정 모델에서 TTFT가 20초로 치솟았다. 대시보드에서 Prefix Cache Hit Rate가 0임을 확인, 해당 모델 설정에 Prefix Caching이 기본 OFF였음을 발견. 활성화 후 TTFT 약 1/10, 히트율 90% 이상으로 개선.
사례 2 - vLLM 버그: 리즈닝 모델에서 finish_reason이 length로 계속 나타났다. 로그 분석 결과 리즈닝 종료 토큰 </think>가 잘못된 시점에 삽입되는 vLLM의 알려진 버그였다. 공개 워크어라운드 적용으로 에러율 0.2% → 0.02%로 감소.
사례 3 - GPU 활용 최적화: 트래픽 증가에 파드 증설 요청이 왔으나 KV 캐시 사용률이 1% 미만이었다. 부하 테스트로 동시성 20까지 수용 가능함을 확인, 증설 없이 4배 트래픽을 수용할 수 있다는 판단으로 비용 절감.
운영 프로세스: 발견(중앙화 모니터링으로 신호 탐지) → 관찰(메트릭·로그 상세 분석) → 가설·검증(테스트 환경에서 확인) → 반영·롤백(빠른 대응 체계). LLM 생태계의 빠른 변화에서 모든 것을 미리 파악하는 것은 불가능하므로 빠른 관찰·대응 체계가 핵심.

왜 읽나vLLM·SGLang 기반 LLM 서빙을 운영하거나 도입 중인 ML 엔지니어·인프라 팀에게 모니터링 체계 설계와 실제 장애 디버깅 패턴의 실전 레퍼런스를 제공한다.

토스 SLASH 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청