LLM 서빙 최적화가 끝나지 않을 때, Runpod Overdrive

모델도 GPU도 그대로였고, max length만 늘렸습니다. 그런데 워커는 요청을 받기도 전에 OOM으로 종료됐습니다. 최대 길이가 늘어난 만큼 KV 캐시가 GPU 메모리를 먼저 차지했기 때문입니다.

vLLM과 SGLang으로 모델을 서빙하다 보면 이런 장면은 낯설지 않습니다. 서빙 엔진을 띄우는 일과, 실제 트래픽에 맞는 설정을 계속 찾아가는 일은 서로 다른 문제기 때문입니다.

긴 컨텍스트를 지원해 달라는 요구는 기능 요청처럼 들립니다. 하지만 실제로 운영하는 입장에서는 GPU 메모리 예산을 다시 짜야 한다는 뜻에 가깝습니다.

특히 max length를 늘리면 KV 캐시도 함께 커지는데요. 여기에 캐시 크기, 양자화 방식, CUDA 버전, 동시성 파라미터, 콜드 스타트 워밍업까지 고려해야 합니다. 각 값의 의미는 문서에서 찾을 수 있어도, 어떤 조합이 맞는지는 모델과 트래픽에 따라 달라지죠.

제가 직접 운영하며 어려웠던 것도 설정 방법 자체는 아니었습니다. 모델이 바뀌고 입력과 출력 토큰 비율이 달라질 때마다 이전 조합을 다시 의심해야 했기 때문입니다. 튜닝이 끝났다고 생각할 만하면 다음 워크로드가 옵니다.

물론 이 반복을 내부에서 계속 맡는 것이 틀린 선택은 아닙니다. 레이턴시 목표가 타이트하거나 커스텀 런타임을 직접 통제해야 하는 팀이라면 오히려 필요한 역량이죠.

다만 제품 개발과 모델 개선보다 서빙 최적화에 쓰는 시간이 더 많아지기 시작하면 이야기가 달라집니다. 그때부터는 “누가 이 최적화를 계속 맡을 것인가”로 바뀌기 때문입니다.

Runpod Overdrive는 Runpod Serverless 위에서 동작하는 추론 최적화 엔진입니다. Runpod은 모델, 컨텍스트 길이, 트래픽 패턴과 현재 엔드포인트 성능을 바탕으로 워크로드별 구성을 찾는다고 설명합니다.

저는 Overdrive를 직접 사용해 보지는 않았습니다. 아래 제품 설명과 성능 수치는 Runpod이 공개한 자료를 기준으로 살펴봤습니다.

어떤 것들을 최적화하는지 확인해 보면, 모델별 EAGLE3 speculative decoding, 워크로드를 고려한 메모리 관리, 트래픽에 맞춘 스케줄링 등이 포함됩니다. 같은 모델이라도 챗봇처럼 입력 비중이 큰 워크로드와 장문 생성처럼 출력 비중이 큰 워크로드에는 서로 다른 구성이 필요하다는 접근이죠.

Overdrive는 기존 Pod, Serverless와는 조금 다른 점도 있는데요. 현재 공식 안내상 Runpod Serverless 위에서 제공되지만, 기존 기능처럼 바로 사용할 수 있는 제품은 아닙니다. 먼저 워크로드 평가를 요청해야 합니다. 세부 최적화 레시피와 평가 기간, 가격은 공개 페이지에서 확인하기 어렵습니다. 실제 워크로드를 기준으로 Runpod과 별도로 논의해야 하는 항목입니다.

Runpod은 공식 벤치마크에서 baseline vLLM과 Overdrive 구성을 비교했습니다. H100 SXM 80GB, 동일한 인프라와 워커 수, 고정 시드 조건에서 4개 모델과 4개 워크로드 프로필을 조합했고, 각 프로필에 300개 요청을 보냈습니다.

이 실험에서 Runpod은 Qwen3 8B의 장문 생성 워크로드 처리량이 최대 2.45배, Llama 3.1 8B의 토큰 간 지연시간이 최대 3.5배 개선됐다고 보고했습니다. 출력 비중이 높은 워크로드일수록 처리량 개선 폭이 커졌다는 것이죠.

그렇다고 모든 지표에서 성능이 좋아졌다고 볼 수는 없습니다. 예를 들어 Llama 3.1 8B 코드 생성 조건에서는 첫 토큰까지 걸리는 시간인 TTFT가 278ms 늘어난 반면, 전체 응답 시간은 4.4초 줄었거든요.

대화형 서비스라면 첫 토큰이 늦어지는 278ms가 더 중요할 수 있습니다. 반대로 긴 결과를 끝까지 생성하는 작업이라면 4.4초 단축에 더 큰 의미를 둘 수 있죠. 도입하려는 워크로드에 따라 Overdrive가 적합한지 아닌지를 따져봐야 하는 이유입니다.

직접 최적화를 계속할지 Overdrive를 도입할지는 다음 세 가지 질문으로 확인해 볼 수 있습니다.

첫째, 현재 워크로드를 재현할 수 있어야 합니다. 평균값만으로는 부족한데요. 입력·출력 토큰 분포, 동시성, 컨텍스트 길이, 요청 유형이 실제 트래픽을 반영해야 비교가 성립합니다.

둘째, 무엇을 개선으로 볼지 정해야 합니다. TTFT, 토큰 간 지연시간, 전체 응답 시간, 처리량, 출력 토큰당 비용 가운데 우선순위를 먼저 정하지 않으면 의미 없는 변경이 될 수도 있기 때문입니다.

셋째, 최적화 비용도 측정해야 합니다. 엔지니어가 직접 최적화해서 더 나은 결과를 얻더라도, 엔지니어가 반복 실험에 쓰는 시간이 실제 제품 개발 작업을 늦춘다면 의미가 없어지지 않을까요?

Overdrive가 모든 것을 해결해 준다고는 할 수 없습니다. 반복 실험을 Runpod에 맡겼을 때 확보되는 엔지니어링 시간이 제품 개발에 쓸 만한 수준인지 비교해 볼 수 있습니다.

지금 필요한 일은 운영 중인 엔드포인트의 조건과 베이스라인을 정리해 두는 것입니다. 그래야 직접 최적화를 계속하거나 외부 평가를 받았을 때 실제로 개선됐는지 확인할 수 있습니다.