작은 모델로 내려도 되는지 판단하는 법

지난 글에서 작은 모델이 무엇을 잘하고 무엇을 못하는지를 봤다면, 남는 것은 결정이다. 지금 큰 모델로 처리하는 이 기능을 작은 모델로 내려도 되는가.

이 판단이 어려운 이유는 재는 값이 하나가 아니어서다. 비용은 확실히 내려가고, 지연은 대개 내려가지만 항상은 아니며, 품질은 작업에 따라 거의 그대로일 수도 있고 절반으로 떨어질 수도 있다. 세 축을 따로 재지 않으면 "싸졌는데 왜 불만이 늘었지"라는 상태에 도착한다.

비용은 폴백을 넣고 계산해야 한다

작은 모델의 단가가 큰 모델의 10분의 1이라고 해서 비용이 10분의 1이 되지는 않는다. 실제 구성은 대개 작은 모델이 먼저 처리하고 미덥지 못하면 큰 모델로 넘기는 형태이기 때문이다. 이때 요청당 기대 비용은 이렇다.

$C = c_s + p \cdot c_l$

$c_s$는 작은 모델 단가, $c_l$은 큰 모델 단가, $p$는 큰 모델로 넘어가는 비율이다. 작은 모델이 실패해도 그 호출 비용은 이미 나갔다는 점이 핵심이다. 이 값이 큰 모델만 쓰는 비용 $c_l$보다 작으려면 이렇게 된다.

$p^{*} = 1 - \frac{c_s}{c_l}$

$c_s$가 $c_l$의 10%라면 $p^{*}$는 0.9다. 즉 열 번 중 아홉 번을 큰 모델로 넘겨도 비용만 놓고 보면 여전히 이득이다. 비용은 사실 이 결정에서 가장 관대한 축이다. 그래서 비용을 근거로 내렸다가 다른 축에서 발목이 잡히는 일이 잦다.

주의할 점 하나. 위 식은 단가 비만 본 것이고, 작은 모델을 직접 서빙한다면 사용량과 무관한 고정비가 붙는다. GPU를 항상 띄워 둬야 하므로 트래픽이 적으면 요청당 실효 단가가 API보다 비싸질 수 있다.

$c_s^{\text{실효}} = \frac{\text{시간당 인스턴스 비용}}{\text{시간당 요청 수}}$

하루 몇천 건짜리 기능을 위해 GPU를 상시 띄우는 구성은 이 식에서 대개 손해로 나온다. 작은 모델의 비용 이점은 호출량이 많을 때 나온다.

지연은 한 번에 끝날 때만 이득이다

작은 모델은 빠르다. 다만 폴백이 붙으면 기대 지연은 이렇게 된다.

$T = t_s + p \cdot t_l$

폴백이 걸린 요청은 작은 모델의 시간을 쓰고 큰 모델의 시간을 또 쓴다. $p$가 0.3만 돼도 상위 백분위 지연은 큰 모델 단독보다 나빠진다. 평균은 좋아졌는데 느린 요청은 더 느려지는 형태다.

그래서 지연이 중요한 기능이라면 볼 값은 평균이 아니라 p95다. 그리고 이 경우 폴백보다 라우팅이 낫다 — 미리 갈래를 나눠 한 번만 호출하는 구성이다. 판정을 먼저 하면 두 번 도는 요청이 사라진다.

기기 안에서 도는 경우는 계산이 또 다르다. 네트워크 왕복이 통째로 사라지므로 짧은 응답에서는 서버의 큰 모델보다 체감이 빠를 수 있다. 반대로 긴 출력에서는 초당 토큰 수가 낮아 뒤집힌다.

품질 격차는 작업 유형이 정한다

세 축 중 가장 크게 갈리는 것이 여기다. 같은 모델 쌍이라도 무엇을 시키느냐에 따라 격차가 거의 없기도 하고 쓸 수 없을 만큼 벌어지기도 한다.

작업	격차	이유
정해진 항목 추출	거의 없다	답이 입력 안에 있다
갈래 분류	거의 없다	선택지가 유한하다
짧은 요약	작다	잘못돼도 알아보기 쉽다
근거 문서를 준 질의응답	중간	문서를 얼마나 잘 읽는지에 달렸다
도구를 골라 호출	중간	도구가 많아지면 흔들린다
여러 단계 계획	크다	앞 단계 오류가 쌓인다
근거 없는 지식 질문	크다	담긴 사실의 양 차이다

위 세 줄은 대체로 내려도 되고, 아래 두 줄은 대체로 안 된다. 가운데 두 줄이 판단이 필요한 자리이고, 이 자리는 재 보지 않으면 알 수 없다. 남의 벤치마크 점수로는 안 된다 — 우리 문서, 우리 도구 목록, 우리 사용자의 말투에서 어떻게 되는지가 다르다.

평가 묶음은 크지 않아도 된다. 실제 요청 200건 정도를 뽑아 두 모델에 같이 돌리고, 답이 갈리는 것만 사람이 보는 방식이면 반나절에 끝난다. 중요한 것은 그 200건이 실제 분포를 닮는 것이다. 잘 되는 예제만 모으면 언제나 통과한다.

내리기 전에 통과할 네 관문

지금까지의 값을 모으면 판단은 이렇게 정리된다.

세 번째 관문이 특히 중요하다. 작은 모델의 실패는 대개 조용하다 — 형식은 맞고 문장도 자연스러운데 내용이 틀린 형태다. 그래서 실패를 자동으로 가려낼 방법이 있는 자리가 유리하다.

• 스키마 검증에 걸리는가
• 반환한 값이 원문에 실제로 있는가
• 고른 도구가 목록에 있는 것인가
• 모델이 스스로 낮은 확신을 표시했는가

이런 검사가 가능한 작업이라면 실패를 잡아 폴백으로 넘길 수 있고, 그러면 품질 위험이 비용 문제로 바뀐다. 반대로 답이 맞았는지 사람이 읽어야만 아는 작업이라면, 격차가 작아 보여도 내리는 위험이 크다.

숨은 비용을 같이 센다

마지막으로 계산에서 빠지기 쉬운 항목들이다.

항목	내용
평가 유지	모델을 바꿀 때마다 다시 돌릴 묶음이 필요하다
두 경로 운영	작은 모델과 큰 모델의 프롬프트가 갈라져 관리 대상이 둘이 된다
모델 갱신	작은 모델은 교체 주기가 짧다
직접 서빙	배포·모니터링·GPU 자원 관리가 새로 생긴다

두 번째 줄이 은근히 크다. 같은 프롬프트를 두 모델에 그대로 쓰면 대개 작은 쪽이 손해를 본다 — 작은 모델은 짧고 명시적인 지시, 좁은 선택지, 예시 한둘을 좋아한다. 그래서 실제로는 프롬프트를 따로 관리하게 되고, 규칙이 바뀔 때 두 곳을 고쳐야 한다.

그래서 권할 순서는 이렇다. 먼저 큰 모델로 기능을 완성해 정답에 가까운 출력을 모은다. 그것이 곧 평가 묶음이자 작은 모델을 다듬을 재료가 된다. 그다음 그 묶음으로 작은 모델을 재고, 격차가 작으면 그림자 배포로 실제 트래픽에 얹어 답만 비교한다. 사용자에게 나가는 것은 그대로 큰 모델의 답이므로 위험이 없다. 며칠치 비교가 쌓이면 그때 전환한다.

정리하면 작은 모델로 내리는 결정은 비용 계산이 아니라 위험 관리다. 비용은 거의 항상 이득이 나오므로 그것만 보면 언제나 답이 "내리자"가 된다. 실제로 물어야 할 것은 셋이다. 이 일이 격차가 작은 유형인가. 실패를 그 자리에서 알아챌 수 있는가. 아니었을 때 되돌릴 경로가 있는가. 셋 다 예라면 내려도 되고, 하나라도 아니면 그 하나를 먼저 만드는 것이 순서다.

---

읽어주셔서 감사합니다. 😊