요청마다 다른 정밀도로 서빙하기, 프리시전 티어 라우팅이 LLM 서빙 비용을 줄이는 방식

H200 같은 고성능 GPU 위에서 대규모 언어모델을 서빙하고 있고, 양자화 정밀도를 어느 수준으로 잡을지 고민해본 적이 있다면 이 글이 도움이 될 것입니다. 대부분의 추론 서비스는 정밀도를 한 번 정하면 모든 요청에 똑같이 적용합니다. 이 논문은 그 관행 자체가 낭비라고 주장합니다. 같은 체크포인트를 세 가지 정밀도로 동시에 띄워 놓고 요청 난이도에 따라 트래픽을 배분하면, 품질을 지키면서도 비용을 줄일 수 있다는 것이 핵심 논지입니다. 그리고 그 절감폭이 정확히 언제 크고 언제 0으로 사라지는지를 수식으로 보여줍니다.

왜 모든 요청을 같은 정밀도로 서빙하는가

4비트 양자화는 30B급 MoE 체크포인트의 메모리 사용량을 세 배 넘게 줄일 수 있습니다. GPU에 몇 개의 시퀀스를 동시에 올릴 수 있는지, 디코딩 한 스텝마다 얼마나 많은 대역폭을 쓰는지, 결과적으로 가속기 한 장이 초당 몇 개의 요청을 처리하는지가 전부 이 선택에 달려 있습니다. 그런데도 대부분의 운영자는 전체 요청 스트림에 정밀도 하나를 균일하게 적용합니다. 서빙 스택이 그렇게 만들어져 있고, 공격적인 양자화가 정확도에 미치는 영향을 전체 트래픽 단위로 가늠하기가 어렵기 때문입니다.

문제는 이 균일함이라는 전제 자체입니다. 실제 프로덕션 요청 분포는 균질하지 않습니다. 코딩 어시스턴트를 예로 들면, 짧은 자동완성이나 상용구 생성, 심볼 조회, 포맷 수정처럼 모델 출력이 문맥에 강하게 제약된 요청이 압도적으로 많고, 그 사이사이에 멀티파일 리팩터링이나 정교한 알고리즘 추론처럼 모델이 자기 능력의 경계에서 작동하고 양자화 오차가 쌓여 오답으로 이어지는 어려운 요청이 소수 섞여 있습니다. 전체를 BF16으로 돌리면 다수를 차지하는 쉬운 요청에서 낼 필요 없는 비용을 계속 치르는 셈이고, 전체를 NVFP4로 내리면 정작 실패가 사용자 눈에 가장 잘 띄는 소수의 어려운 요청에서 품질이 깎입니다.

같은 체크포인트, 세 개의 정밀도 티어

이 논문이 제안하는 것은 프리시전 티어 라우팅입니다. 파라미터와 아키텍처, 토크나이저가 동일한 하나의 체크포인트를 BF16, W4A16, NVFP4 세 단계로 숫자 인코딩만 바꿔서 나란히 서빙하고, 가벼운 난이도 분류기가 요청이 도착하는 시점에 어느 티어로 보낼지 판단합니다. 여기서 강조할 대목은 이것이 흔히 말하는 크로스모델 캐스케이드, 즉 작은 모델과 큰 모델 사이를 라우팅하는 방식과 근본적으로 다르다는 점입니다. 캐스케이드는 모델 자체의 능력이 다르기 때문에 관측되는 정확도 격차에 파라미터 규모, 학습 데이터, 정렬 방식이 뒤섞여 들어갑니다. 반면 프리시전 티어 라우팅은 모든 티어가 파라미터를 공유하므로, 정확도 격차를 오직 수치 정밀도 하나에만 귀속시킬 수 있습니다.

라우터는 프롬프트 길이나 복잡도, 작업 유형 같은 요청 표면 특징만 보고 난이도를 추정합니다. 이 점수는 K-1개의 isotonic regression으로 보정을 거쳐 확률로 변환되고, 라우팅 규칙은 가장 싼 티어부터 순서대로 확인해 보정된 확률이 임계값을 넘는 첫 티어에 요청을 배정합니다. 이 전체 설계는 결국 한 줄로 요약됩니다. 각 요청을 정확도에서 비용에 가격을 매겨 뺀 값이 최대인 티어로 보내는 것입니다.

Qwen3-Coder-30B-A3B에서 실제로 측정된 W4A16 압축률입니다. BF16 61.0GB가 W4A16에서 16.9GB로, 약 3.6배 줄어듭니다. 다만 이 W4A16 산출물에는 전문가 10.16%를 가지치기한 결과가 섞여 있어 순수하게 정밀도만 바꾼 수치는 아니며, NVFP4는 이번 분석에서 직접 측정되지 않아 그래프에는 표시하지 않았습니다.

얼마나 절약되는가

논문은 이 문제를 정확도 하한 α를 만족하면서 기대 비용을 최소화하는 제약 최적화로 정식화합니다. 쌍대 형태로 보면 비용 예산 B 아래에서 기대 정확도를 최대화하는 문제와 같고, 둘 다 하나의 라그랑주 승수로 묶여 같은 파레토 프런티어를 그립니다.

이 절감폭이 정확히 어떤 조건에서 커지는지 보이기 위해, 논문은 요청을 두 가지 유형으로 단순화한 모델을 씁니다. 확률 p로 쉬운 요청이 오고, 나머지 1-p로 어려운 요청이 옵니다. 쉬운 요청은 가장 싼 티어에서도 정확도 손실이 작은 값 ε에 그치지만, 어려운 요청은 훨씬 큰 손실 δ를 입습니다. δ가 ε보다 크기 때문에, 추가 예산은 항상 어려운 요청을 먼저 비싼 티어로 올리는 데 쓰는 것이 최적입니다. 이렇게 나오는 라우팅 프런티어는 꺾인 점이 하나뿐인 구간별 선형 오목 곡선이 되고, 이 곡선은 단순히 트래픽 일부를 무작위로 비싼 티어에 섞는 정적 분할 방식이 그리는 직선보다 항상 같거나 더 낫습니다.

최대 절감폭은 다음 식으로 정리됩니다.

ΔC* = p(1-p)(δ-ε) / (pε+(1-p)δ) × Δc

이 식이 말하는 바는 명확합니다. 절감은 난이도 분포의 분산 p(1-p)와 두 유형 간 손실 격차 δ-ε에 비례하고, 트래픽이 극단적으로 쉬운 쪽이나 어려운 쪽으로 쏠리면(p가 0이나 1에 가까워지면) 0으로 사라집니다. 즉 트래픽이 이미 균질하다면 라우팅할 것이 없다는 뜻이고, 논문은 이것을 이 기법을 만들 가치가 있는지 판단하는 정직한 사전 테스트로 제시합니다. 절감폭을 셈할 때 비교 기준도 최상위 티어가 아니라 운영자의 정확도 기준을 이미 만족하는 가장 싼 균일 티어로 잡는데, 이는 라우팅 없이도 전역 정밀도만 낮추면 얻을 수 있는 이득을 라우팅의 공으로 돌리지 않기 위한 장치입니다.

위 절감폭 식에서 p에 대한 의존성만 따로 그린 것으로, 실측이 아니라 해석적 모델입니다. 막대는 정규화된 분산 항 2p(1-p)를 보여주며 p=0.5에서 정점을 찍고 양쪽 극단에서 사라집니다. 세로축은 절감 비율이 아니라 형태만 보여주는 단위 없는 값이며, ε이 0보다 크면 실제 절감폭은 이보다 항상 작습니다.

ThakiCloud와 더 넓은 커뮤니티에 주는 의미

회사 관점에서 이 결과는 Metis, 즉 AI Inference 계층의 실행 경제성과 직접 맞닿아 있습니다. 서빙 비용은 결국 Paxis가 자동화하는 업무 하나하나를 얼마에 실행할 수 있는지를 결정하는 밑단이기 때문에, 토큰 단가를 구조적으로 낮추는 이런 연구는 Paxis 워크플로 전체의 실행 신뢰성과 경제성을 함께 끌어올립니다. 이 논문은 ThakiCloud가 앞서 진행한 라우터 인지 선택적 NVFP4 양자화 연구와 가지치기된 30B MoE 모델의 메모리 경량화 W4A16 양자화 연구의 산출물을 그대로 사다리의 한 칸으로 재사용합니다. 즉 파라미터 단위 양자화 연구와 요청 단위 라우팅 연구가 서로 다른 축에서 맞물려 쌓이는 구조이고, 이 논문은 그 축을 서빙 정책까지 확장한 결과입니다.

사회적으로 보면, 같은 품질의 답을 더 적은 GPU 시간과 대역폭으로 만들어낸다는 것은 곧 추론 1건당 에너지 소비가 줄어든다는 뜻이고, 이는 강력한 오픈 웨이트 모델을 자본이 풍부하지 않은 사업자도 호스팅할 수 있게 만드는 방향입니다. 30B급 모델을 서빙하는 데 가장 큰 걸림돌은 대개 가중치 자체가 아니라 이를 지속적으로 돌릴 가속기 비용이기 때문입니다.

과학적으로는, 이 논문이 라우팅 문헌에 더하는 것은 정밀도 축을 처음 제안한 공로가 아니라(그 공로는 스텝 단위로 정밀도를 조정하는 선행 연구에 있습니다) 요청 단위, K단계 사다리, 해석적 파레토 프런티어 특성화라는 조합입니다. 특히 모든 티어가 파라미터를 공유한다는 가정을 명시적으로 세움으로써, 기존 크로스모델 캐스케이드 문헌이 안고 있던 모델 능력 교란 요인을 제거했다는 점이 방법론적으로 가장 또렷한 기여입니다.

한계

이 논문은 스스로를 분석적이고 입장을 제시하는 포지셔닝 논문으로 규정하며, 실제 H200 서빙 트래픽에 대한 실증 검증은 아직 수행하지 않았습니다. 논문에 등장하는 수치 중 실측값은 W4A16이 61.0GB에서 16.9GB로 줄어든다는 압축률 하나뿐이고, 이마저도 전문가 10.16%를 가지치기한 산출물에서 나온 값이라 순수하게 정밀도만 바꾼 결과가 아니라는 점을 논문 스스로 지적합니다. 즉 3.6배라는 수치는 정밀도가 기여한 압축의 상한일 뿐 그 자체가 정밀도 효과의 정확한 측정치는 아닙니다. 절감폭 식에 들어가는 p, δ, ε을 비롯해 본문에 등장하는 대부분의 값은 해석적 모델을 설명하기 위한 예시 파라미터이며, 실제 트래픽에서 관측되는 값이 아닙니다.

난이도 분류기 자체의 정확도도 아직 측정되지 않았습니다. 특히 논문은 어려운 요청을 싼 티어로 잘못 보내는 오탐률이 사업자의 비용 절감에는 유리한 방향으로 작동한다는 점을 명시적으로 경고합니다. 마진 압박을 받는 운영자에게는 이 오탐률을 몰래 높일 유인이 구조적으로 존재한다는 뜻입니다. 두 유형으로 단순화한 요청 난이도 모델도 실제로는 연속적인 분포를 거칠게 근사한 것이고, 검증 사례 역시 코딩 특화 MoE 모델 하나에 국한되어 있어 다른 아키텍처나 작업 분포에도 같은 결론이 적용되는지는 아직 열린 질문입니다.

논문 상세 페이지는 다음에서 확인할 수 있습니다: https://huggingface.co/datasets/thaki-AI/daily-paper-2026-08-08-precision-tier-llm-routing