모델 배포와 추론 최적화

좋은 모델도 운영 조건을 통과해야 한다

파인튜닝 모델의 품질 점수가 높아도 응답이 느리고 비용이 크면 서비스에서 오래 버티기 어렵다. 배포 단계에서는 세 가지를 함께 봐야 한다. 첫째, 검증 세트에서 품질 기준을 통과했는가. 둘째, 실제 트래픽에서 지연시간이 허용 범위 안에 있는가. 셋째, 토큰당 비용이 지속 가능한가.

배포 전에는 검증 세트 기반 자동 평가를 먼저 돌리고, 대표 샘플은 사람이 다시 확인해야 한다. 고객 상담, 의료 보조, 법률 문서처럼 실패 비용이 큰 업무라면 사람 평가를 생략하지 않는다. 성공 기준에는 정확도뿐 아니라 형식 준수율, 금지 응답 비율, P95 지연시간, 토큰당 비용을 함께 넣는다.¹

AI 생성 이미지

지연시간은 prefill과 decode로 나누어 본다

LLM 추론은 크게 두 단계로 나뉜다. prefill은 입력 프롬프트 전체를 한 번에 처리해 첫 토큰 생성을 위한 KV 캐시를 만드는 단계다. 병렬 처리가 잘 되므로 GPU 활용률이 높다. 반면 decode는 답변 토큰을 하나씩 순서대로 생성한다. 이전 토큰이 나와야 다음 토큰을 만들 수 있으므로 병목이 되기 쉽다.²

그래서 평균 응답시간 하나만 보면 원인을 놓친다. 긴 시스템 프롬프트나 RAG 문서가 문제라면 TTFT, 즉 첫 토큰까지의 시간이 길어진다. 답변이 길거나 동시 요청이 많다면 토큰당 지연시간과 tokens/sec가 나빠진다. 운영 대시보드에는 TTFT, 토큰당 지연시간, 전체 지연시간, tokens/sec, P95 지연시간을 따로 둔다. P95는 전체 요청 중 느린 5%의 경험을 보여주므로 실제 사용자 불만을 찾는 데 유용하다.

추론 서버는 병목에 맞게 고른다

vLLM, TGI, llama.cpp는 모두 좋은 선택지가 될 수 있지만 용도가 다르다. 동시 요청이 많은 GPU 서버라면 연속 배칭, KV 캐시 관리, PagedAttention 같은 기능이 중요한 vLLM을 우선 검토한다. Hugging Face 생태계와의 통합, 컨테이너 기반 운영, 스트리밍 API가 중요하면 TGI가 편하다. 작은 모델을 로컬, CPU, 엣지 환경에서 돌려야 한다면 llama.cpp가 단순하고 비용이 낮다.

선택 기준은 명확해야 한다. 모델 크기, GPU 또는 CPU 배포 여부, 연속 배칭 지원, 양자화 지원, LoRA 어댑터 서빙 방식, 모니터링·오토스케일링 연동성을 비교한다. "가장 빠른 서버"를 찾기보다 우리 트래픽에서 병목을 줄이는 서버를 고르는 것이 맞다.

비용 최적화는 GPU 활용률에서 시작한다

LLM 운영 비용의 핵심은 GPU를 얼마나 놀리지 않는가이다. GPU 활용률이 낮으면 같은 서버 비용으로 처리하는 토큰 수가 줄어 토큰당 비용이 급격히 나빠진다. 확장 기준도 CPU 사용률이나 일반 메모리 사용률만 보면 안 된다. 요청 큐 길이, GPU utilization, P95 latency, 초당 생성 토큰 수를 기준으로 오토스케일링해야 한다.³

최적화 기법도 병목별로 구분한다. 양자화는 가중치 표현을 8비트나 4비트로 줄여 메모리와 비용을 낮춘다. 배칭은 여러 요청을 묶어 처리량을 높인다. KV 캐시 활용은 이전 토큰 계산을 재사용해 반복 계산을 줄인다. speculative decoding은 작은 초안 모델이 후보 토큰을 만들고 큰 모델이 검증해 decode 단계의 체감 지연시간을 낮춘다. 단, 모든 기법은 품질 저하와 지연시간 변화를 실제 업무 프롬프트로 확인해야 한다.

캐싱은 두 종류로 설계한다

캐싱은 단순한 부가 기능이 아니라 비용 절감 장치다. 프롬프트 캐싱은 긴 시스템 프롬프트, 고정 지침, few-shot 예시, 반복되는 RAG 문서처럼 자주 재사용되는 prefix에 적합하다. 같은 앞부분을 다시 계산하지 않아 TTFT와 입력 토큰 비용을 줄일 수 있다.

요청-응답 캐싱은 동일하거나 거의 같은 요청에 이전 답변을 재사용하는 방식이다. FAQ, 분류, 정형 안내처럼 답이 자주 바뀌지 않는 업무에 잘 맞다. 의미 기반 캐싱을 쓰면 표현이 조금 다른 질문도 처리할 수 있지만, 임베딩 계산과 유사도 기준 관리가 추가된다. 캐시에는 반드시 TTL을 둔다. 오래된 정책이나 가격 정보를 빠르게 답하는 것보다, 최신 정보로 다시 생성하는 것이 더 안전한 경우가 많다.⁴

LoRA 배포는 유연성과 성능의 균형이다

LoRA나 QLoRA로 학습했다면 배포 방식은 두 가지다. 하나는 베이스 모델을 한 번 올리고 어댑터를 동적으로 로드하는 방식이다. 여러 고객, 언어, 업무별 모델을 하나의 베이스 위에서 운영하기 좋다. 대신 어댑터 전환 로직과 메모리 관리가 복잡해질 수 있다.

다른 하나는 어댑터를 베이스 모델에 병합해 별도 모델로 배포하는 방식이다. 운영은 단순하고 추론 경로도 예측하기 쉽다. 하지만 변형 모델마다 저장 공간과 배포 단위가 늘어난다. 실험 단계에서는 어댑터 분리 배포가 유연하고, 트래픽이 크고 모델 버전이 안정되면 병합 배포가 관리하기 쉽다.

배포의 목표는 가장 큰 모델을 가장 빠른 GPU에 올리는 것이 아니다. 필요한 품질을 만족하면서, 사용자가 기다릴 수 있는 시간 안에, 감당 가능한 비용으로 답하게 만드는 것이다.

참고

¹A Practical Guide to LLM Fine Tuning

²Mastering LLM Techniques: Inference Optimization

³The LLM Inference Optimization Stack: A Prioritized Playbook for Enterprise Teams

⁴Optimize LLM response costs and latency with effective caching