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

LLM 서빙 생태계는 빠르게 바뀌고 있습니다. 불과 수년 전만 해도, LLM을 배포하는 것 자체가 허들인 경우가 많았어요. 하지만, 지금은 다양한 곳에서 On-premise LLM을 다양하게 사용하고 있습니다. 토스증권도 마찬가지로 다수의 오픈 소스 LLM, 직접 튜닝한 모델을 서비스에 활용하고 있습니다. 이런 상황에서, LLM을 단순히 서빙하는 것보다, 잘 띄우는 것이 더 중요해졌습니다.평소에는 조용하던 팀의 알림 채널이 어느 날 갑자기 알림이 쏟아지는 날이 있습니다. 이 알림들은 여러 에러가 함께 묶여서 온 거예요. 100건 가까운 에러고, 대부분 타임아웃이라는 것까지는 알 수 있지만 이 알림만으로는 왜 이런 일이 생겼는지 알 수 없어요.“어떤 지표를 봐야 이 알림의 원인을 알 수 있을까?”이 질문에 답을 하기 위해서는 2년 전, LLM을 처음으로 서빙했던 때로 돌아가야 합니다. 그 때 풀어야 했던 문제는 두 가지였습니다.1. 지표가 달라졌어요기존 머신러닝 모델은 입력을 받아 한 건의 출력을 내놓는 구조였어요. 그래서 단 건의 응답 시간, 초당 몇 건의 트래픽을 처리하는지가 핵심 모니터링 지표였습니다.하지만 LLM은 토큰을 순차적으로 생성해요. 단 건의 응답 시간이나 처리량은 무엇을 생성하는지에 따라 변동성이 심하고, 통제할 수 있는 영역이 아닙니다. 그래서 모니터링이 필요한 지표가 달라졌습니다.2. 서빙 자체가 어려웠어요토스증권은 쿠버네티스, Argo CD 같은 여러 기술 스택 위에서 움직여요. 그 위에 각자의 플랫폼을 얹어 모델을 서빙하고, 거기서 나온 로그와 메트릭을 자체 대시보드로 관찰하곤 했습니다.문제는 이게 전부 서비스 개발자 개인의 역량에 의존했다는 점이에요.이런 문제를 해결하기 위해, MLHub이라는 플랫폼을 직접 구축했어요. 어려운 부분은 줄이고, 로그와 메트릭을 정규화해서 하나의 패널에서 볼 수 있게요. 서버 모니터링은 두 갈래로 나눴어요.Grafana: 메트릭을 수집해 추이와 이상을 탐지Kibana: 단건 로그를 확인여기까지 만들고 나서, 대부분의 문제를 미리 예상하고 쉽게 해결할 수 있을 거라고 생각했습니다.그런데 예상하지 못한 문제들이 생겼어요모델에서 문제가 발생해도, 앞서 구축한 모니터링만으로는 그 문제가 ‘왜’ 생겼는지 알 수 없었어요. 우리에게는 다음 문제가 남아있었어요. 조사해보니 vLLM이나 SGLang 같은 서빙 프레임워크가 제공하는 지표들이 있었어요. 예전엔 헬스 상태, ...