GPU가 아닌 모델 라우팅이 진정한 AI 인프라의 핵심 동력이다

요약 — 대부분의 팀은 더 저렴한 GPU나 더 나은 양자화(quantization)를 추구하며 AI 인프라 비용을 최적화하지만, 가장 큰 핵심 동력은 아키텍처적인 부분입니다. 모든 것을 하나의 거대한 모델로 서비스하는 대신 계층화된 모델군에 걸쳐 요청을 라우팅하는 것입니다. 저렴한 모델들을 순차적으로 사용하고 불확실성이 있을 때만 점진적으로(escalating) 사용하는 방식은 중요한 요청의 품질을 건드리지 않으면서 추론 비용(inference spend)을 극적으로 절감할 수 있습니다. 에이전트 기반 워크로드(Agentic workloads)는 기본적으로 이 문제를 악화시키지만, 동시에 설계상으로 더 좋게 만듭니다. 왜냐하면 모든 추론 단계가 별도의 청구 가능한 추론 호출(billable inference call)이기 때문입니다.

AI 인프라 비용에 대한 사후 분석(postmortem)은 항상 같은 지점에서 끝납니다: GPU 활용률(GPU utilization). 팀들은 배치 크기(batch sizes)를 감사하고, 양자화를 추구하며, 예약 인스턴스 가격을 재협상하고, 어떤 가속기(accelerator)가 토큰당 최고의 비용 효율성을 갖는지 논쟁합니다. 이 모든 것이 중요합니다. 하지만 그 어느 것도 가장 큰 핵심 동력은 아닙니다.

가장 큰 핵심 동력은 대부분의 프로덕션 시스템이 요청이 실제로 무엇을 필요로 하는지와 관계없이 모든 요청을 동일한 모델로 서비스한다는 점입니다. 한 줄짜리 FAQ 조회와 여러 단계에 걸친 계약 분석이 동일한 가중치(weights)를 가진 동일한 순방향 전달(forward pass)을 거칩니다. 이것은 추론 문제가 아닙니다. 아키텍처 문제입니다. 그리고 오늘날 AI 인프라에서 가장 비용이 많이 드는 설계 결정입니다.

평면적인 서비스 방식의 기본값은 선택이 아닌 비용 사고다**

아무도

그러면 청구서가 도착하고, 본능적으로 서비스 계층(serving layer)을 공격하게 됩니다: 더 나은 배치 처리(batching), 연속 배치 처리(continuous batching), 추측 디코딩(speculative decoding), 저렴한 하드웨어. 이것들은 실제로 존재하는 최적화입니다. 일반적으로 20~40%의 개선 효과를 가져다줍니다. 하지만 라우팅(Routing)은 다른 차원의 크기(order of magnitude)의 개선을 가져옵니다. 왜냐하면 이는 모델이 요청에 응답하는 방식을 효율적으로 바꾸는 것이 아니라, 애초에 어떤 모델이 그 요청에 응답할지 자체를 변경하기 때문입니다.

불편한 진실은 대부분의 프로덕션 트래픽(production traffic)이 현재 서비스하고 있는 모델을 필요로 하지 않는다는 것입니다. 분류(Classification), 추출(extraction), 짧은 형식의 질의응답(Q&A), 포맷팅, 의도 감지(intent detection) — 실제 세계 LLM 트래픽의 상당 부분은 작고, 저렴하며, 빠른 모델만으로 충분히 처리할 수 있습니다. 플래그십 모델(flagship model)은 소수의 요청에서만 비용을 정당화합니다: 모호한 추론(ambiguous reasoning), 긴 컨텍스트 합성(long-context synthesis), 그리고 잘못되었을 때 비용이 많이 드는 모든 경우입니다. 모든 것을 플래그십 모델로 서비스한다는 것은, 하루 종일 매일 인턴 수준의 작업에 대해 플래그십 가격을 지불하고 있다는 의미입니다.

캐스케이드(Cascades)는 모델 선택을 런타임 결정으로 바꾼다

캐스케이드 아키텍처(cascade architecture)는 기본 설정을 뒤집습니다. 요청이 먼저 작고 빠른 모델에 도달합니다. 만약 그 모델의 출력이 신뢰도 기준선(confidence bar)을 통과하면, 그것을 반환합니다. 그렇지 않다면, 더 큰 모델로 에스컬레이션(escalate)하고, 오직 그 소수의 요청만이 더 큰 모델의 비용을 지불하게 됩니다. 작은 모델은 모든 것을 위한 최종 답변 생성기가 아니라 필터 역할을 합니다.

어려운 부분은 에스컬레이션 로직(escalation logic) 자체가 아닙니다. 그것은 임계값(threshold)과 폴백 경로(fallback path)에 불과합니다. 어려운 부분은 '이 출력이 배포하기에 충분히 좋다'는 신뢰할 수 있는 시그널을 구축하는 것입니다. 토큰 단위의 신뢰도 점수(confidence scores)는 노이즈가 많습니다. 모델이 자체적으로 보고하는 확신도는 신뢰할 수 없습니다. 캐스케이드(cascade)를 작동하게 만드는 시스템들은 보통 여러 가지 저렴한 신호들을 결합합니다: 출력 길이 및 구조 건전성 검사, 응답을 점수 매기는 경량 검증기 모델(lightweight verifier model), 두 개의 소형 모델 샘플 간의 일치 여부, 또는 도메인별 검증기(추출된 JSON이 파싱되는지, SQL이 실행되는지, 답변에 실제로 검색된 컨텍스트 정보가 포함되어 있는지 등). 이 중 어느 것도 생소한 것은 아닙니다. 이는 당신이 완전히 신뢰하지 못하는 다른 모든 확률적 시스템에 적용할 엄격함과 같습니다. 왜냐하면 그것 자체가 그러하기 때문입니다.

잘 구현된다면, 캐스케이드 시스템은 트래픽의 70~90%를 저가형 계층(cheap tier)으로 라우팅하고, 비싼 계층(expensive tier)은 실제로 그만한 가치를 입증하는 요청에만 남겨둡니다. 비용 곡선이 더 이상 트래픽에 선형적이지 않습니다. 그것은 '난이도(difficulty)'에 선형적이며, 이것이야말로 당신이 실제로 비용을 지불하고 싶은 것입니다.

에이전트가 문제를 증폭시키고 — 기회 또한 증폭시킨다

에이전트 워크로드(Agentic workloads)는 양방향으로 모두 위험 부담을 훨씬 높입니다. 에이전트 루프(agent loop)는 단일 추론 호출(inference call)이 아닙니다. 그것은 계획하고, 도구를 호출하고, 결과를 해석하고, 다음 단계를 결정하며, 어쩌면 또 다른 도구를 호출하고, 요약하는 일련의 체인입니다. 만약 이 루프의 모든 단계가 동일한 대규모 모델을 거친다면, 비용은 단계 수에 따라 증가하며, 에이전트 루프는 예상보다 더 많은 단계를 거치는 것으로 악명이 높습니다. 플래그십 가격(flagship pricing)으로 수행하는 5단계 에이전트 작업은 10개의 단일 호출 요청을 합친 것보다 더 비쌀 수 있으며, 팀들은 예산 책정을 요청당이 아닌 단계당으로 했기 때문에 이 점에 대해 습관적으로 놀라곤 합니다.

하지만 바로 이 지점에서 계층적 라우팅(tiered routing)이 가장 큰 효과를 발휘합니다. 에이전트 루프(agent loop)의 모든 단계가 동일한 중요도를 갖는 것은 아니기 때문입니다. 짧고 잘 정의된 목록에서 어떤 도구(tool)를 호출할지 결정하는 것과 다섯 가지 도구 출력물로부터 최종 답변을 종합하는 것은 다른 문제입니다. 함수 호출을 유효한 JSON 형식으로 만드는 것이 계획이 실패하여 수정되어야 하는지 여부를 결정하는 것과는 또 다른 문제입니다. 모든 단계를 동일하게 어렵다고 취급하고 같은 모델로 라우팅하는 것은 플랫 서빙(flat-serving) 기본값의 에이전트 버전이며, 루프 구조가 매 반복마다 실수를 누적시키기 때문에 훨씬 더 낭비적입니다.

대규모로 에이전트를 운영하는 팀들은 이제 루프 자체를 분리하기 시작했습니다. 작고 빠른 모델은 라우팅, 형식 지정(formatting), 도구 호출 구성(tool-call construction)을 처리하고; 더 큰 모델은 계획 수립(planning), 실패 복구(failure recovery), 최종 종합(final synthesis)에만 호출됩니다. 인프라 측면의 함의는 더 이상 하나의 모델을 서빙하는 것이 아니라, 단일 논리적 요청 내에서 각 계층별로 다른 지연 시간(latency), 배치 처리(batching), 확장성 특성을 가진 여러 모델 풀(fleet)을 서빙한다는 것입니다.

이것이 실제로 인프라 복잡성 측면에서 비용으로 다가오는 것

라우팅은 공짜가 아닙니다. 이는 추론 비용(inference cost)을 운영 복잡성(operational complexity)과 교환하는 것이며, 이 트레이드오프는 명확히 인식하고 이루어져야 합니다. 이제 하나의 모델 대신 여러 개의 모델 풀을 배포하고 유지해야 하므로, 더 많은 자동 확장 정책(autoscaling policies), 더 많은 콜드 스타트(cold-start) 예외 사례, 그리고 계층 간 버전 드리프트(version drift)를 위한 더 넓은 표면적을 갖게 됩니다. 요청당 지연 시간과 토큰 비용뿐만 아니라 에스컬레이션율(escalation rate)을 추적하는 관측 가능성(observability)이 필요합니다. 만약 작은 모델이 95%의 확률로 에스컬레이션하고 있다면, 당신의

또한, 더 어려운 평가 문제도 물려받게 됩니다. 이제는 거대 모델(big model)의 품질만 평가해서는 충분하지 않습니다. 에스컬레이션 결정 자체에 신뢰도가 있는지 확인해야 합니다. 즉, 소형 모델(small model)이 말하는 '확신한다'라는 것이 벤치마크가 아닌 실제 트래픽 환경에서 정확도와 실제로 상관관계가 있는지를 알아야 합니다. 이것을 잘못 판단하면 모든 요청을 에스컬레이션하면서 과지출하게 되거나, 혹은 저렴한 등급(cheap tier)의 확신에 찬 오답을 배포하는 결과를 낳게 됩니다. 후자는 과지출보다 더 나쁜 실패 모드인데, 왜냐하면 조용히 발생하기 때문입니다.

진정한 절감 효과가 발생하는 지점

하드웨어 수준 최적화에는 한계가 있습니다. 비용-토큰(cost-per-token)을 아무리 줄이려 해도 결국 물리 법칙과 통제할 수 없는 벤더 가격 책정 방식에 부딪히게 됩니다. 라우팅은 비교할 만한 상한선이 없습니다. 왜냐하면 레버리지 포인트가 효율성이 아니라 수요 형성(demand shaping)이기 때문입니다. 비싼 모델 자체를 더 저렴하게 만드는 것이 아닙니다. 그저 해당 모델이 필요로 하는 요청의 수를 줄이는 것입니다.

이것이 시니어 팀들이 수렴하고 있는 관점의 전환입니다. 질문은 '어떻게 하면 우리 모델을 더 효율적으로 서비스할까?'가 아니라, '왜 모든 요청이 같은 모델을 거쳐야 할까?'라는 것입니다. 대규모 인프라 비용 문제는 주로 GPU 문제가 아닙니다. 그것은 GPU 청구서를 위장한 라우팅 문제입니다.