매달 OpenAI 인보이스를 열 때마다 같은 생각이 스쳤다. "이 돈이면 GPU 사서 직접 돌리는 게 낫지 않나." 우리 팀도 결국 그 유혹에 넘어갔고, vLLM으로 자체 서빙을 구축하는 데 한 달 반을 썼다. 결과부터 말하면, 반만 맞았다.
계산은 맞았다, 숫자만 보면
월 API 비용이 600만 원을 넘기기 시작했다. 하루 토큰 처리량이 800만에서 1200만 사이를 오갔는데, 업계에서 자주 인용되는 기준이 있다 — 하루 1000만 토큰을 넘기면 12-18개월 내에 자체 인프라가 손익분기를 넘긴다는 분석. 우리는 딱 그 경계에 있었다.
vLLM을 고른 건 자연스러운 선택이었다. PagedAttention으로 KV 캐시 관리가 효율적이고, OpenAI 호환 API 엔드포인트를 바로 내려주니까 기존 코드를 거의 안 건드려도 됐다. 목표는 Llama 3 70B를 올려서 핵심 태스크를 전환하는 것.
VRAM 앞에서 겸손해지는 순간
첫 번째 벽은 허무할 정도로 빨리 왔다. GPU 스펙을 비교할 때 사람들이 TFLOPS를 보는데, 추론 서빙에서 진짜 병목은 메모리 용량이다.
70B 모델을 FP16으로 올리면 가중치만 140GB. A100 80GB 한 장으로는 당연히 안 된다. 두 장을 텐서 병렬로 묶어도 KV 캐시까지 고려하면 동시 요청 수가 처참했다.
양자화로 방향을 틀었다. GPTQ 4bit를 적용하니 모델 크기가 약 35GB로 줄어들어 A100 한 장에 올라갔다. 여기까지는 좋았다. 문제는 품질이었다. 우리 서비스의 핵심인 한국어 문서 요약에서 미묘한 차이가 나타났다. 긴 계약서의 앞부분 조건을 요약에서 빠뜨리는 빈도가 올라갔고, "대략적으로 맞지만 신뢰하기엔 불안한" 결과물이 나왔다. AWQ로 바꿔봐도 비슷한 양상.
결국 INT8로 타협했다. 그런데 그러면 다시 A100 두 장이 필요하고, 원래 절감 계획이 흔들리기 시작했다. 양자화 레벨 선택이 단순한 용량 문제가 아니라 품질-비용-하드웨어의 3차원 트레이드오프라는 걸 몸으로 배웠다.
도커 없이 시작한 대가
GPU 준비됐으니 모델 올리면 끝이라고 생각했다면 순진한 거다.
CUDA 12.4에서 멀쩡하던 게 스테이징 서버의 12.2에서 segfault를 뱉었다. PyTorch 빌드가 특정 cuDNN 버전을 기대하고 있었는데 시스템에 깔린 건 다른 버전. 이 의존성 충돌을 잡는 데만 이틀을 날렸다. 처음부터 컨테이너로 갔어야 했다. "나중에 도커로 감싸지 뭐"라는 생각은 "나중"이 오기 전에 환경 디버깅에 파묻힌다.
버전 관리의 범위가 폭발한다
셋째 주에 운영 이슈가 터졌다. 프롬프트를 수정했더니 eval 점수가 달라졌는데, 이전 버전의 프롬프트가 어딘가에 사라져 있었다. 양자화 설정을 바꿨더니 지난주 평가와 비교가 불가능해졌다.
API를 쓸 때는 모델 버전 하나만 신경 쓰면 됐다. 자체 인프라에서는 관리 대상이 폭발한다:
모델 가중치 + 양자화 방식
시스템 프롬프트와 생성 파라미터 (temperature, top_p 등)
평가 데이터셋과 기준 점수
서빙 설정 (max_num_seqs, gpu_memory_utilization 등)
이것들 중 하나라도 바뀌면 "같은 모델"이 아니다. MLflow를 붙여서 추적하기 시작했는데, 세팅하고 팀 온보딩하는 것 자체가 또 하나의 프로젝트가 됐다. API 시절에는 존재하지 않던 운영 레이어가 통째로 생긴 셈이다.
최종 착지: 하이브리드
완전히 API로 돌아가지는 않았다. 지금 운영 중인 구조는 워크로드 성격에 따라 갈라진다.
자체 인프라가 맡는 건 일일 배치 리포트 생성, 내부 데이터 라벨링, 대량 임베딩 처리 같은 지연 시간에 관대한 작업이다. 고객이 직접 마주하는 실시간 기능 — 채팅, 즉석 요약, 검색 보강 — 은 API를 유지했다. 실시간 쪽은 새 모델이 나왔을 때 바로 적용해야 하는데, 자체 환경에서는 호환성 검증에 최소 1-2주가 걸린다. 그 사이에 경쟁사는 이미 새 모델로 서비스하고 있다.
비용만 따지면 배치 처리 쪽이 자체 인프라로 30% 정도 싸다. 하지만 엔지니어 시간, 장애 대응, 모델 업데이트 지연을 총비용에 포함하면 계산이 많이 달라진다.
자체 서빙을 검토 중이라면 하나만 자문해보라. 팀에 GPU 인프라를 전담할 사람이 있는가. 없으면 API 비용을 더 내는 게 총소유비용 기준으로 이득일 수 있다. 우리는 전담자가 있어서 반쪽은 성공했지만, 그 "반쪽"에 도달하는 과정이 스프레드시트 위의 숫자와는 전혀 다른 종류의 일이었다.