#추론 최적화는 왜 엔진 층부터 손대야 하는가 — 4층 우선순위

← 전체 목차 · 이전: GPU가 남아도는데 왜 서비스가 먼저 무너지는가 · 다음: 추측 디코딩은 왜 빨라지면서 답은 바뀌지 않나

"양자화, 증류 말고 또 뭐가 있나?"라는 질문에 온도를 낮추고 KV 캐시를 쓰고 투기적 디코딩을 건다고 답하면 그럴듯해 보인다. 그러나 이 답은 모델을 작게, 빠르게 만드는 것만 말할 뿐 비용·고동시성·꼬리 지연·장애 대응은 건드리지 않는다. 이런 답변은 "파라미터 튜너" — 모델 파라미터만 만지는 사람 — 로 분류된다.

모델 압축은 단일 요청의 비용을 낮출 뿐, 이용률·대기열·OOM은 전체 비용과 안정성을 결정한다. 이 둘을 같은 것으로 여기는 순간 답은 표층에 머문다.

#핵심 답변: 4층 체계, 그리고 층 사이의 우선순위

모델 최적화 = 모델 층 + 엔진 층 + 서비스 층 + 업무 층

우선순위: 엔진 층 > 서비스 층 > 모델 층 > 업무 층
（먼저 엔진과 스케줄링을 손보고, 그다음에야 모델 압축을 논한다）

양자화는 이 네 층 중 모델 층의 한 수단일 뿐이며, 순수 양자화만으로는 프로덕션급 최적화를 지탱하지 못한다. 가성비 순서를 지키지 않으면 병목이 아닌 곳에 복잡도만 더하게 된다.

#네 가지 생산 치명 함정

"양자화 절감 + 스케줄링 최적화"가 합쳐져야 진짜 절감이다. 양자화만으로는 이용률·대기·OOM 중 어느 것도 고치지 못한다.

#1층 (마지막 순서): 모델 층 — 등급별 정밀도 + 투기적 디코딩

전 요청에 동일 정밀도를 쓰지 않고 시나리오별로 등급을 나눈다.

여기에 투기적 디코딩(소형 모델이 후보 token을 미리 생성 → 대형 모델이 한 번에 검증)을 더하면 속도 2~3배, 정밀도 손실은 미미하다.

#2층: 엔진 층 — KV 캐시·프리필·배치의 삼중 협업

세 기술이 협업할 때만 메모리 파편 감소 → 차단 감소 → 처리량 상승이라는 사슬이 완성된다.

엔진 최적화는 단일 지점 가속이 아니라 메모리·스케줄링·배치의 협업이다. 이 층이 가성비 1위인 이유는 모델 구조를 바꾸지 않고도 이용률과 꼬리 지연을 한 번에 끌어올리기 때문이다.

#3층: 서비스 층 — 지능형 스케줄링

1. 지능형 모델 라우팅: 경량 분류기로 질문 복잡도를 먼저 판정 — 단순 질의는 소형 모델(7B), 복잡 추론은 대형 모델(32B/70B). 전체 비용 60% 이상 절감.
2. 시맨틱 캐시: 고빈도 정형 질문은 캐시에서 즉시 반환, 매번 전 링크를 태우지 않는다.
3. 동적 배치 전략: 한산할 때는 모아서 배치, 바쁠 때는 우선 처리 — 처리량과 지연을 함께 잡는다.

**"라우터는 가벼워야 한다"**는 전제가 있다 — 복잡도 판정 자체가 대형 모델을 호출한다면 절감분을 스스로 잡아먹는다.

#4층: 업무 층 — 비용·효과 이중 통제

입력을 짧게 → 출력을 정확하게 → 소모를 가시화 → 품질을 통제 가능하게

• 프롬프트 정제: 불필요한 지시를 걷어내 입력 길이를 통제한다.
• 신뢰도 조기 종료: 핵심 질문에 답이 완결되면 자동 중단. 무효 출력 25~40% 감소.
• 비용 매립점 가시화: 요청·모델·시나리오별 token 소모를 관측 가능하게 만든다.
• 효과 검증 체계: 비용과 품질을 연동해 감축이 효과를 갉아먹지 않도록 막는다.

#핵심 통찰

1. "최적화"는 명사 나열이 아니라 계층 구분 능력을 묻는 시험이다 — "양자화·증류 말고 또 뭐가 있나"라는 질문의 진짜 의도는 추론 서비스를 하나의 시스템으로 본 적이 있는지를 재는 것이다. 모델 측 명사를 더 대는 것은 제자리에서 단어만 바꾸는 것이고, 엔진·서비스·업무 세 층으로 문제를 쪼갤 수 있어야 비로소 분수령을 넘는다.
2. 양자화는 "단일 지점 절감", 스케줄링과 메모리 관리가 "시스템 상한"을 결정한다 — 대부분은 모델 압축을 절감의 주경로로 여기지만, 압축은 단건 비용만 낮춘다. 이용률·대기·OOM이 전체 장비 비용과 안정성을 결정하므로 순수 양자화만으로는 프로덕션급 최적화가 성립하지 않는다.
3. 평균 지연은 거짓말을 하는 지표이고, P99가 체감 지표다 — 장문 프리필이 GPU를 통째로 점유해도 평균 속도는 여전히 좋아 보일 수 있다. 막힌 꼬리 요청의 첫 글자 지연이 수 초로 치솟는 순간이 바로 이탈률로 직결된다.
4. 반대편 검증이 없는 감축은 보이지 않는 손실로 바뀐다 — 저정밀 양자화가 비용 곡선을 누르는 동시에 오류율 곡선을 밀어 올린다. 품질 기준선·사실 검사·오류율 모니터링이라는 역방향 사슬이 없으면 팀은 보이지 않는 곳에서 환각의 대가를 치르게 된다.
5. 정밀도는 전역 상수가 아니라 시나리오 변수여야 한다 — INT4 / INT8·FP8 / 전정밀도를 "단순 문답 — 복잡 추론 — 핵심 업무"에 배분하는 것은 하나의 엔지니어링 파라미터를 업무 판단으로 바꾸는 일이다. 시나리오별 등급화가 전면 고정밀도보다 이득이다.
6. 처리량 문제는 흔히 대기열 문제이지 연산력 문제가 아니다 — 정적 배치의 나무통 효과(짧은 요청이 긴 요청을 기다림)와 허술한 KV Cache 관리는 "더 강한 카드"로 풀리지 않는다. Continuous Batching과 PagedAttention이 GPU 이용률을 30%에서 85% 이상으로 끌어올리는 이유는 연산자가 아니라 대기열과 메모리 배치를 고쳤기 때문이다.
7. 우선순위 배열 자체가 실행 가능한 결론이다 — 엔진 층 > 서비스 층 > 모델 층 > 업무 층이라는 순서는 자원이 제한적일 때 무엇을 먼저 손댈지 알려준다. 처음부터 투자 대비 효율이 가장 낮은 모델 압축에 뛰어드는 것을 막아준다.
8. 가시성은 모든 비용 논의의 전제조건이다 — 요청·모델·시나리오별 token 매립점이 없으면 비용 최적화는 감으로 할 수밖에 없다. 매립점이 있어야 비용과 품질을 같은 표 안에서 연동할 수 있다.

#엔지니어링 실전 Tips

• "대기열"부터 묻고 그다음 "연산력"을 물을 것: 처리량이 오르지 않으면 먼저 짧은 요청이 긴 요청을 기다리는 정적 배치 나무통 효과인지 확인하고, 그다음에야 카드 증설을 고려할 것.
• 장대화는 메모리의 만성 살인자다: 장대화 시나리오에서 KV Cache는 계속 증가하므로 "대화 길이에 따른 메모리 점유 곡선"을 OOM 경보보다 먼저 모니터링에 넣을 것.
• 각 층마다 검수 수치를 정해둘 것: 메모리 −3050%, P99 −510배, GPU 이용률 30%→85%, 라우팅 절감 60%+, 무효 출력 −25~40% — 수치 없는 최적화는 하지 않은 것과 같다.
• 절감 동작은 반드시 짝을 이뤄 나와야 한다: 양자화·조기 종료·캐시 같은 절감 수단을 올릴 때마다 오류율·사실 검사·품질 기준선 같은 품질 지표를 동시에 올릴 것. 그러지 않으면 비용 곡선은 좋아 보이지만 업무가 어둠 속에서 피를 흘린다.
• 캐시는 두 종류를 섞어 말하지 말 것: KV 캐시는 단일 생성 내부의 중복 계산을, 시맨틱 캐시는 요청 간 중복 질문을 해결한다. 전자는 엔진 층, 후자는 서비스 층에 속한다.
• 라우터는 가벼워야 한다: 복잡도 판정 자체가 대형 모델을 부른다면 절감분을 스스로 잡아먹는다.
• 면접이든 설계든 답변 순서를 우선순위 그대로 따를 것: 추론 최적화를 물으면 "엔진 층 → 서비스 층 → 모델 층 → 업무 층" 순으로 전개하고 층마다 정량 수익 하나씩을 붙이는 편이 기술 명사 열 개를 나열하는 것보다 설득력이 있다.