추론 최적화

추론 최적화는 이미 학습된 LLM은 그대로 두고, 답을 만들 때 더 빠르고 싸게 돌아가게 하는 기술을 통틀어 부르는 말이다. 모델을 직접 띄워 서비스하거나 로컬에서 돌릴 때 메모리를 아끼고 GPU가 노는 시간을 줄이려고 양자화, 추측적 디코딩, KV 캐시 최적화, 배치 처리를 함께 쓴다.

토큰을 하나씩 만들어서 느리다

ChatGPT 답이 글자 단위로 나타나는 그 순간이 추론이다. LLM은 앞 토큰이 나와야 다음 토큰을 만들 수 있어서 하나씩 차례로 생성한다. 그동안 GPU는 메모리에서 가중치를 읽어 오느라 계산 능력 대부분을 쓰지 못한다.

이 낭비를 줄이면 같은 GPU로 더 많은 요청을 처리할 수 있고, 더 싼 GPU로도 큰 모델을 돌릴 수 있다.

로컬은 양자화 모델, 서버는 vLLM

로컬에서는 Ollama나 llama.cpp로 4비트 양자화 모델을 받아 쓰는 게 가장 쉽다. 16비트를 4비트로 줄이면 가중치 메모리가 4분의 1이 되어 일반 PC에서도 모델이 돈다.

서비스용 서버라면 vLLM 같은 추론 엔진을 쓴다. KV 캐시를 운영체제의 가상 메모리처럼 페이지 단위로 나눠 관리하는 PagedAttention과 요청 묶음 처리가 기본으로 들어 있다. AWQ 양자화 모델은 --quantization awq로 불러오고, 같은 시스템 프롬프트를 반복해서 보낸다면 --enable-prefix-caching으로 앞부분 계산을 재사용한다. Hugging Face Transformers에서는 generate()에 작은 모델을 assistant_model로 넘기면 추측적 디코딩이 켜진다.

문제에 맞는 기법부터 고른다

여러 기법은 함께 쓸 수 있다. 4비트 모델을 vLLM으로 띄우고 접두사 캐싱까지 켜면 메모리와 반복 계산을 한 번에 줄일 수 있다.

직접 재 보고, 너무 줄이지 않는다

2비트처럼 양자화를 너무 세게 하면 답의 품질이 눈에 띄게 떨어진다. 추측적 디코딩도 초안 모델의 예측이 자주 틀리면 빨라지는 효과가 줄어든다. 효과는 모델과 작업마다 다르니, 실제로 보낼 요청으로 속도와 품질을 직접 재 보고 정한다.

API만 쓴다면 이런 최적화는 제공사가 서버에서 알아서 한다. 사용자는 반복되는 프롬프트 앞부분을 고정해서 프롬프트 캐싱 혜택을 받는 정도만 챙기면 된다.

모델을 직접 띄우는 곳이면 거의 다 쓴다

가장 흔한 건 양자화 모델을 받아 내 PC에서 돌리는 방식과, 추론 엔진으로 오픈 모델을 서버에 띄워 여러 사람이 함께 쓰는 방식이다. API만 쓰는 앱도 프롬프트 캐싱으로 간접적인 혜택을 본다.