[arXiv 2604.09377] 태스크 인식 LLM 라우팅: 콜드스타트 환경을 위한 다단계 태스크 프로파일 기반 데이터 합성

Task-Aware LLM Routing with Multi-Level Task-Profile-Guided Data Synthesis for Cold-Start Scenarios

https://arxiv.org/abs/2604.09377

Hui Liu, Bin Zou, Kecheng Chen, Jie Liu, Wenya Wang, Haoliang Li | City University of Hong Kong, The University of Hong Kong, Nanyang Technological University | arXiv:2604.09377 | 2026년 4월 | ACL 2026 Main 채택

---

1. 서론: 콜드스타트 LLM 라우팅이 왜 지금 중요한가

이 논문은 LLM 라우팅이라는 이미 익숙한 문제를 다루지만, 관점을 아주 선명하게 바꿔 놓는다. 기존 라우터 논문들이 주로 묻는 질문은 “이미 충분한 학습 로그가 있을 때 어떤 작은 모델이 최적의 상용 모델을 골라 줄 수 있는가”였다. 반면 이 논문은 실제 제품 출시에 더 가까운 질문을 던진다. 아직 로그가 없고, 사용자 질의도 쌓이지 않았고, 도메인별 정답 레이블도 없는 시작 시점에 어떻게 라우터를 학습할 것인가가 핵심이다. 다시 말해 이 논문의 진짜 문제는 단순한 모델 선택이 아니라, 데이터가 없는 상태에서 모델 선택기를 만드는 방법이다.

이 문제의식은 오늘날 멀티모델 서비스를 운영하는 거의 모든 팀과 연결된다. 기업은 보통 하나의 LLM만 쓰지 않는다. 같은 벤더 안에서도 고성능 모델, 경량 모델, 저가형 플래시 모델, reasoning 모델이 섞여 있고, 다른 벤더 모델까지 조합하는 경우도 흔하다. 사용자는 어떤 질의에서는 빠른 응답을 원하고, 어떤 질의에서는 비용을 아끼고 싶어 하며, 또 어떤 질의에서는 가장 높은 품질을 원한다. 이때 라우터는 단순한 편의 기능이 아니라 비용 구조, 사용자 체감 품질, 응답 지연을 동시에 결정하는 운영 계층이 된다.

하지만 현실에서는 라우터를 학습시킬 인도메인 데이터가 처음부터 존재하지 않는 경우가 많다. 새로운 고객지원 챗봇을 출시하거나, 특정 산업용 문서 질의응답 시스템을 막 만들거나, 개인 사용자를 대상으로 한 실험적 에이전트를 처음 배포할 때는 더 그렇다. 기존 연구는 보통 질문-정답 쌍이 충분하고, 후보 모델들을 모두 돌려 성능과 비용 레이블을 수집할 수 있다는 전제를 둔다. 이 논문은 바로 그 전제가 실제 배포 초기에는 자주 깨진다고 본다. 그래서 cold-start라는 단어가 제목과 방법론의 핵심 축을 이룬다.

저자들이 제안하는 해법은 크게 두 단계다. 첫째, 실제 사용자 질의 분포를 근사할 수 있도록 다단계 task-profile-guided data synthesis로 합성 QA 데이터를 만든다. 둘째, 이 합성 데이터에서 유도된 태스크 구조를 활용해, 질의의 표면 임베딩만 보는 기존 회귀형 라우터보다 더 구조적인 TRouter를 학습한다. 여기서 TRouter는 질의에서 바로 비용과 성능을 예측하는 대신, 먼저 그 질의가 어떤 태스크 유형 분포를 갖는지 추정하고, 그 태스크 유형이 각 후보 모델의 비용과 성능에 어떤 영향을 주는지 합성해서 최종 효용을 계산한다.

이 아이디어가 흥미로운 이유는, 최근의 라우팅 논문들이 대체로 두 갈래로 흘러가기 때문이다. 하나는 성능-비용 절충을 위한 query-to-model routing이고, 다른 하나는 [arXiv 2604.02319]처럼 오픈엔디드 생성에서 다양성을 가장 잘 내는 모델을 고르는 routing이다. 전자가 운영 효율을, 후자가 생성 폭을 겨냥한다면, 이 논문은 전자를 유지하면서도 “그 전제 데이터가 없는 시작점”을 정면으로 다룬다. 즉 라우팅 목적함수를 바꾸는 논문이 아니라, 라우팅 학습 조건을 바꾸는 논문이라고 보는 편이 정확하다.

또 하나 눈에 띄는 점은 이 논문이 단순히 “강한 모델이 비싼 만큼 좋다”는 상식을 자동화하려는 데서 멈추지 않는다는 것이다. 저자들은 비용과 성능이 단지 모델 크기만으로 설명되지 않고, 질의가 요구하는 태스크 종류와 난이도에 따라 달라진다고 본다. 예를 들어 산술이나 상식 분류처럼 쉬운 태스크에서는 작은 모델이 충분할 수 있지만, 고난도 수학이나 긴 reasoning이 필요한 질의에서는 더 큰 모델이 진짜 가치를 보일 수 있다. 결국 라우팅은 “큰 모델이냐 작은 모델이냐”의 문제가 아니라, 어떤 태스크에 어떤 모델이 어느 정도의 추가 비용 대비 성능을 주는가의 문제로 재정의된다.

이 관점은 최근 많이 회자되는 advisor-model-orchestration 개념과도 닿아 있다. strongest model을 항상 최전선 실행자로 두는 대신, 필요한 순간에만 강한 모델을 쓰거나, 질의 성격에 따라 다른 모델을 부르는 식의 오케스트레이션이 운영 전략으로 중요해지고 있기 때문이다. 다만 그 개념이 주로 실행 단계의 sparse advisor 설계에 집중한다면, 이 논문은 그보다 앞선 단계인 사전 라우팅 정책을 학습 가능한 형태로 정식화한다. 다시 말해 “누가 마지막에 도와줄까”가 아니라, “애초에 누구에게 이 질의를 보낼까”를 더 정교하게 배우는 셈이다.

결론부터 말하면, 논문은 두 가지 메시지를 동시에 전달한다. 첫째, 도메인 설명만으로도 꽤 그럴듯한 합성 라우팅 데이터셋을 만들 수 있다. 둘째, 그 합성 데이터에서 얻은 태스크 계층을 잠재변수로 이용하면, cold-start에서도 기존 라우터보다 높은 효용을 얻을 수 있다. 아래에서는 이 논문이 어떤 문제를 formalize했고, 왜 task type이 핵심 매개변수인지, 그리고 실제 실험에서 어느 정도의 개선을 얻었는지 순서대로 정리해 보겠다.

Figure 1: 기존 인도메인 데이터 준비 방식과, 논문이 제안한 LLM 기반 합성 데이터 준비 방식의 비교

Figure 1은 이 논문의 문제의식을 가장 직관적으로 보여준다. 왼쪽은 실제 테스트 분포와 동일한 학습 데이터를 미리 모은 뒤 모든 후보 모델을 평가해 라우터를 학습하는 전통적 경로이고, 오른쪽은 도메인 설명만으로 태스크 taxonomy와 QA 쌍을 합성해 cold-start용 학습 신호를 만드는 경로다. 핵심은 라우팅 문제 자체보다 라우팅 데이터를 준비하는 비용과 불가능성에 초점을 옮겼다는 점이다. 이 그림 하나만으로도 왜 저자들이 data synthesis를 라우터 연구의 중심으로 끌어왔는지 이해할 수 있다.

2. 배경 및 관련 연구: 기존 라우터가 놓친 분포 이동과 태스크 구조

2.1 LLM 라우팅 연구의 두 축: 분류형과 회귀형

기존 LLM routing 연구는 크게 두 계열로 나뉜다. 하나는 classification-based router다. 이 계열은 질의마다 “가장 좋은 모델”이라는 정답 라벨을 붙인 뒤, 그 모델 인덱스를 직접 맞히는 분류 문제로 푼다. RouterDC나 GraphRouter 같은 방법은 이 범주에 들어가며, 질의와 모델의 관계를 분류 또는 그래프 에지 예측으로 다룬다. 장점은 직관적이라는 점이지만, 사용자 선호가 바뀔 때마다 최적 모델 라벨이 다시 바뀔 수 있다는 점에서 유연성이 떨어질 수 있다.

다른 하나는 regression-based router다. 이 계열은 질의와 모델 쌍에 대해 직접 비용과 성능을 예측한 뒤, 사용자가 준 선호 가중치에 따라 효용을 최대화하는 모델을 고른다. OmniRouter, Carrot, MetricRouter가 이 흐름에 가까우며, 이 논문도 기본 철학은 여기에 가깝다. 회귀형의 장점은 사용자 선호가 바뀌어도 라우터 자체를 다시 학습하지 않고, 예측된 비용과 성능을 재조합해 다른 정책을 계산할 수 있다는 데 있다. 특히 배치 단위 모델 할당이나 quota 제약을 넣는 운영형 시스템과도 잘 맞는다.

문제는 두 계열 모두 대개 충분한 인도메인 평가 로그를 전제로 한다는 점이다. 후보 모델이 6개든 20개든, 학습 질의마다 각 모델의 응답을 뽑아 보고 성능과 비용을 기록해야 한다. 이 과정이 가능하면 라우터는 강력해질 수 있지만, 실제로는 가장 비싼 단계이기도 하다. 결국 기존 라우터 연구는 “라우터를 배우는 비용”을 종종 숨겨진 전처리 비용으로 넘겨 왔고, 이 논문은 სწორედ 그 숨은 비용을 정면에서 드러낸다.

또한 기존 방법은 질의 표현을 바로 비용/성능 예측으로 연결하는 경우가 많다. 이 접근은 표면적으로는 단순하고 세련돼 보이지만, 저자들은 그 사이에 태스크 의미론이 빠져 있다고 본다. 질문의 문장 표면이 다르더라도 같은 태스크에 속하면 비슷한 모델 선택 규칙이 적용될 수 있고, 반대로 표현이 비슷해 보여도 실제 요구 능력이 다르면 다른 모델이 유리할 수 있다. 이 논문이 task type이라는 잠재변수를 끼워 넣는 이유가 여기에 있다.

2.2 콜드스타트와 cross-domain generalization 문제

논문이 진짜로 비판하는 것은 단순히 “기존 라우터 성능이 낮다”가 아니다. 더 정확히는 기존 라우터의 일반화 가정이 약하다는 점이다. 서로 다른 데이터셋, 서로 다른 평가 프로토콜, 서로 다른 사용자 질의 스타일로 넘어가는 순간 성능이 쉽게 흔들린다는 것이 저자들의 출발점이다. 실제 메인 결과에서도 cross-domain으로 가져온 RouterDC나 MetricRouter는 cold-start 시나리오에서 안정적이지 못했고, 경우에 따라서는 간단한 휴리스틱인 Adaptive LLM보다도 좋지 않았다.

이 현상은 자연스럽다. 라우터는 본질적으로 질의 분포와 모델 분포의 상호작용을 학습하는데, 훈련 때 봤던 태스크와 테스트 시점의 태스크가 다르면 질의 임베딩이 같은 의미를 갖지 않을 수 있다. 예컨대 일반 QA 위주로 학습한 라우터가 요약, 법률 질의, 장문 추론, 수학 문제로 넘어가면 성능과 비용의 패턴이 완전히 달라질 수 있다. 따라서 단순 cross-domain transfer만으로 cold-start를 해결하려는 시도는 구조적으로 취약할 수밖에 없다.

저자들이 제안한 합성 전략은 이 문제를 “일단 도메인 설명에서 시작해 테스트 시나리오를 닮은 질의 분포를 만들어 보자”로 바꾼다. 즉, 과거 로그를 재사용하기보다는, 현재 목표 서비스가 다루려는 작업군을 hierarchical taxonomy로 풀어내고, 거기서 질의를 생성해 라우터를 학습시키는 방식이다. 이 접근은 완벽한 대체물이 아니라 근사지만, 적어도 질의 분포를 현재 목표 환경에 맞출 수 있다는 점에서 단순 cross-domain transfer보다 훨씬 정직하다.

특히 이 논문은 평가 프로토콜의 불일치도 중요한 문제로 본다. 요약이나 긴 reasoning처럼 전통적 문자열 매칭 지표가 잘못된 선호를 줄 수 있는 태스크에서는, 라우터가 학습해야 할 성능 신호 자체가 왜곡될 수 있다. 그래서 저자들은 traditional metrics와 LLM-as-a-judge 두 프로토콜을 모두 보고, 실제로 프로토콜 차이가 후보 모델 분포와 효용 차이를 얼마나 바꾸는지 별도로 분석한다. 이는 “라우터만 잘 만들면 된다”가 아니라, 무엇을 성능으로 정의하는가도 라우팅 문제의 일부라는 사실을 보여준다.

2.3 샘플 다양성 라우팅과 advisor orchestration과의 차이

최근 나온 [arXiv 2604.02319]은 질의마다 가장 다양한 고품질 답 집합을 낼 모델을 선택하는 라우팅을 제안했다. 그 논문이 묻는 질문은 “어떤 모델이 더 넓은 answer space를 보여 주는가”였다. 반면 본 논문이 묻는 질문은 “어떤 모델이 지금 이 사용자 선호 하에서 비용과 성능의 효용을 가장 잘 만족시키는가”다. 두 논문 모두 query-level routing을 다루지만, 전자가 다양성 목표를 위해 oracle-best model의 가변성을 강조했다면, 후자는 cold-start data acquisition과 task-type regularization을 더 핵심적인 공헌으로 둔다.

advisor-model-orchestration과 비교해도 차이가 분명하다. advisor 구조는 흔히 가장 비싼 모델을 sparse하게 불러 계획 수정이나 오류 교정만 맡기고, 실제 실행은 더 저렴한 모델이 담당하게 한다. 이것은 런타임 orchestration의 문제다. 하지만 이 논문은 질의가 들어오자마자 누구에게 보낼지를 정하는 pre-execution router를 학습한다. 즉, 강한 모델을 조언자로 둘지, 바로 실행자로 둘지, 아주 작은 모델로 충분한지를 미리 결정하는 정책층에 가깝다.

이 차이는 실무적으로 꽤 중요하다. advisor 구조는 대개 한 번의 실패 뒤 escalation이 붙는 형태라서, 첫 번째 선택이 잘못되면 이미 지연시간과 비용을 일부 지불한 뒤다. 반면 query-aware router는 애초에 잘 맞는 후보를 고르려 하기 때문에, 초반 branch 자체를 더 효율적으로 만들 수 있다. 본 논문의 contribution은 바로 이 지점, 즉 첫 번째 선택을 더 잘하기 위한 학습 데이터와 잠재 태스크 구조를 설계했다는 데 있다.

정리하면, 이 논문은 기존 라우팅 연구의 여러 축을 이어 받지만 목표가 선명하다. classification처럼 단일 최적 모델 라벨을 맞히는 것도 아니고, diversity routing처럼 answer set 폭을 최대화하는 것도 아니며, cascade처럼 고정된 순서를 설계하는 것도 아니다. 대신 사용자 선호가 반영된 utility maximization을 유지하면서, 인도메인 데이터가 없다는 현실 제약을 정면으로 해결하는 방향으로 문제를 재설계한다. 이 점이 본 논문의 위치를 가장 잘 설명한다.

3. 방법론: 비용-성능 효용과 태스크 인지형 TRouter의 정식화

3.1 효용 함수와 사용자 선호 시나리오

논문은 라우팅 문제를 아주 명시적으로 utility maximization으로 적는다. 후보 모델 집합을 $\mathcal{M}$이라 할 때, 질의 $q$에 대해 선택해야 할 최적 모델 $m^*$는 예상 성능과 예상 비용을 사용자 선호에 맞춰 결합한 효용을 가장 크게 만드는 모델이다. 여기서 중요한 점은 성능만 높인다고 좋은 것이 아니라, 비용이 함께 들어가며, 그 비중이 사용자별로 달라질 수 있다는 것이다. 따라서 동일한 질의라도 비용 민감 사용자와 성능 민감 사용자는 서로 다른 모델을 고르는 것이 자연스럽다.

$$m^* = \arg\max_{m \in \mathcal{M}} U(m, q) = \mu_r \cdot \mathbf{r}(m,q) - \mu_c \cdot \mathbf{c}(m,q), \quad \mu_r + \mu_c = 1$$

이 식은 단순해 보이지만 실제로는 몇 가지 중요한 함의를 갖는다. 첫째, 라우터가 예측해야 하는 것은 모델 정답 인덱스 하나가 아니라 질의-모델 쌍별 성능 함수와 비용 함수다. 둘째, 효용이 선호 가중치에 따라 연속적으로 바뀌기 때문에, 회귀형 구조가 여러 사용자 정책을 지원하는 데 유리하다. 셋째, 성능 지표와 비용 지표의 스케일이 다르므로 반드시 정규화가 필요하다. 저자들이 결과 표에서 raw accuracy나 raw cost가 아니라 normalized value를 많이 보고하는 이유가 여기에 있다.

논문은 세 가지 대표 사용자 시나리오를 둔다. Cost First에서는 $(\mu_r, \mu_c) = (0.2, 0.8)$, Balanced에서는 $(0.5, 0.5)$, Performance First에서는 $(0.8, 0.2)$를 사용한다. 눈에 띄는 점은 성능 우선이라도 $(1, 0)$을 쓰지 않는다는 것이다. 만약 비용 항이 완전히 사라지면 라우팅은 거의 무조건 가장 큰 모델을 고르는 퇴행적 정책으로 수렴할 수 있기 때문이다. 즉, 저자들은 라우팅을 “큰 모델을 정당화하는 장치”가 아니라 실제 운영에서 쓸 만한 절충 문제로 유지하려 한다.

이 설계는 논문 전체 결과 해석에도 중요하다. 표에서 Utility가 약간 올랐다고 해서 항상 성능이 오른 것은 아니다. 어떤 경우에는 성능을 조금 덜 얻는 대신 비용을 크게 줄여 전체 효용이 좋아졌을 수 있고, 다른 경우에는 비용을 조금 더 쓰더라도 성능을 더 크게 끌어올려 효용이 좋아졌을 수 있다. 즉, 이 논문은 accuracy winner를 뽑는 리더보드가 아니라 비용과 성능을 같은 평면에 놓은 운영 실험으로 읽어야 한다.

3.2 왜 latent task type이 필요한가

기존 MetricRouter류 방법은 사실상 $p(h \mid q, m)$, 즉 “질의와 모델이 주어졌을 때 비용 또는 성능이 어떻게 될까”를 바로 예측한다. 하지만 저자들은 이 표현이 너무 직접적이라고 본다. 질의는 표면적으로는 무수히 다양하고, 실제 모델 반응은 그 안의 태스크 범주와 난이도에 더 강하게 좌우될 수 있기 때문이다. 예를 들어 요약, 분류, 독해, 산술, 코드 생성은 표면 문자열이 달라도 내부적으로는 비슷한 비용-성능 곡선을 보일 수 있고, 반대로 겉으로 비슷한 질문이라도 reasoning depth가 다르면 전혀 다른 라우팅 규칙이 필요할 수 있다.

그래서 논문은 질의와 모델 사이에 잠재 태스크 변수 $t \in \mathcal{T}$를 둔다. 이때 $\mathcal{T}$는 합성 과정에서 만든 difficulty-level task taxonomy의 leaf 집합이다. 즉 라우터는 먼저 질의가 어떤 태스크 유형 분포를 갖는지 추정하고, 그다음 각 태스크 유형이 모델별 비용과 성능을 어떻게 만들지 계산해 최종 효용을 얻는다. 이 구조는 질의 임베딩을 그대로 회귀하는 것보다 더 해석 가능하고, 특히 cold-start에서 합성 데이터가 제공하는 구조적 prior를 쓸 수 있다는 장점이 있다.

논문이 두는 핵심 가정은 두 가지다. 첫째, 태스크 유형과 모델이 주어지면 성능은 질의 자체에 조건부 독립적이라고 본다. 둘째, 질의가 주어졌을 때 태스크 유형은 모델과 독립적이라고 본다. 이 가정 아래에서 비용과 성능의 조건부분포는 태스크 유형을 따라 분해되며, 라우터는 질의에서 태스크 posterior를 추정하고, 모델별 태스크-조건부 metric predictor를 합쳐 답을 낸다. 저자들은 이 가정이 완벽한 진실이라기보다, 과적합을 줄이고 구조적 일반화를 돕는 inductive bias라고 해석하는 편이 맞다.

$$p(h \mid q,m) = \sum_{t \in \mathcal{T}} p(h \mid t,m) p(t \mid q)$$

이 식의 장점은 명확하다. 질의 하나가 여러 태스크 성분을 동시에 가질 수 있어도, 그것을 hard assignment가 아니라 distribution으로 표현할 수 있다. 따라서 하나의 모호한 질의가 “정보 검색”과 “읽기 이해” 사이에 걸쳐 있거나, “설명형 튜터링”과 “상식 추론”을 동시에 요구하더라도, 라우터는 둘 중 하나를 억지로 고르지 않고 가중합 형태로 metric을 예측할 수 있다. Appendix에서 저자들이 failure case를 분석하며 여러 질의가 실제로 다중 태스크 성격을 띤다고 말하는 것도 이 때문이다.

3.3 ELBO 관점에서 본 TRouter의 정규화 효과

논문은 위 분해를 학습 가능하게 만들기 위해 variational posterior $q_\phi(t \mid q)$를 두고, evidence lower bound 형태로 최적화한다. 직관적으로 보면 첫 번째 항은 “이 태스크 분포가 실제 cost/performance를 잘 설명하는가”를 보는 재구성 항이고, 두 번째 항은 “태스크 posterior가 합성 taxonomy로부터 온 prior에서 너무 멀어지지 않는가”를 보는 regularization 항이다. 후자가 없다면 라우터는 다시 query-specific noise를 강하게 외워 버릴 수 있고, 그러면 cold-start 일반화가 어려워진다.

$$\log p_\theta(h \mid q,m) \ge \mathbb{E}_{q_\phi(t \mid q)}\left[\log p_\theta(h \mid t,m)\right] - \mathrm{KL}\left(q_\phi(t \mid q) \| p(t \mid q)\right)$$

이 ELBO 해석이 중요한 이유는, TRouter가 단순히 task label을 하나 더 붙인 회귀기가 아니라는 점을 보여 주기 때문이다. 태스크 인식 모듈은 cross-entropy로 prior와 맞추고, metric predictor는 각 태스크 임베딩을 통해 모델별 값을 예측한다. 다시 말해 질의 의미를 곧바로 metric으로 보내는 것이 아니라, 태스크 의미 공간을 먼저 거치게 함으로써 query-level noise를 누르고자 한다. Appendix의 ablation에서 Assumption (1)을 풀거나, 두 가정을 모두 풀어 MetricRouter에 가까워질수록 cold-start 성능이 흔들리는 것은 이 regularization 효과가 실제로 작동했음을 시사한다.

이 구조는 해석 가능성도 함께 준다. black-box embedding router는 왜 특정 모델을 골랐는지 설명하기 어렵지만, TRouter는 최소한 어떤 task type distribution이 그 결정에 기여했는지를 볼 수 있다. 저자들은 이를 근거로 node offloading, bias correction, incremental update 같은 유지보수 이점까지 논의한다. 다시 말해 태스크 변수를 넣은 것은 성능만을 위한 선택이 아니라, 운영 가능한 라우팅 계층을 만들기 위한 설계라고 해석할 수 있다.

3.4 Task-profile-guided Data Synthesis의 구축 절차

3.4.1 도메인·하위범주·난도로 쪼개는 3단 taxonomy

저자들이 합성 데이터 파이프라인에서 가장 먼저 하는 일은 task taxonomy를 만드는 것이다. 구조는 세 단계다. 가장 위에는 domain, 그 아래에는 subcategory, 마지막에는 difficulty level이 온다. 각 노드는 단순 이름만 갖지 않고 짧은 정의와 예시를 함께 가진다. 이 설계는 중요하다. 라우터가 활용할 수 있는 태스크 prior를 만들려면 단지 카테고리명 목록이 아니라, 언어적으로 설명 가능한 task description이 필요하기 때문이다.

논문은 초기에 여섯 개 seed domain을 둔다. Mathematics, Creative Writing, Commonsense Knowledge, Programming, Long-context Understanding, Reading Comprehension이 그것이다. 그다음 도메인 확장 프롬프트를 통해 총 열 개의 broader domain으로 넓힌다. 도메인 수준에서는 최대 네 개의 신규 노드를 추가하도록 제한하고, 각 domain 아래에서는 최대 열 개 subcategory, 각 subcategory 아래에서는 최대 다섯 개 difficulty level을 만들게 한다. 즉, 논문은 taxonomy를 무한 확장하지 않고 제어 가능한 breadth와 depth를 강하게 유지한다.

이 제한은 실무적으로도 납득할 만하다. taxonomy가 너무 거칠면 서로 다른 질의가 같은 노드에 뭉개져서 라우팅 prior가 약해진다. 반대로 taxonomy가 너무 세밀하면 합성 데이터가 과도하게 분산되고, 태스크 인식 모듈이 안정적으로 학습하기 어려워진다. 따라서 저자들이 prompt rule에 “노드는 서로 겹치지 말 것”, “difficulty level은 순서가 있고 상호배타적이어야 할 것”, “generic length difference만으로 difficulty를 만들지 말 것” 같은 규칙을 넣은 것은 매우 실용적인 선택이다.

이 3단 구조가 특히 설득력 있는 이유는 비용과 성능이 함께 difficulty에 반응한다는 저자들의 관찰 때문이다. 같은 domain과 subcategory라도 난도가 올라가면 reasoning length가 길어지고, 모델 간 성능 차이와 비용 차이가 함께 커질 수 있다. 그래서 domain이나 subcategory만으로는 충분하지 않고, difficulty node까지 내려가야 실제 라우팅에 유효한 태스크 프로파일을 만들 수 있다는 것이 논문의 입장이다. 뒤에서 보겠지만 cold-start에서는 오히려 domain-level regularization이 조금 더 잘 나오는 경우도 있어, 이 구조가 단순히 “깊을수록 무조건 좋다”는 일방향이 아니라는 점도 흥미롭다.

3.4.2 Task Type Generator와 Quality Evaluator의 역할 분담

taxonomy를 만드는 주체는 두 모듈이다. Task Type Generator는 부모 노드 설명을 조건으로 하위 노드 후보를 생성한다. 여기서는 다양성과 관련성이 동시에 중요하다. 서로 너무 비슷한 하위 노드를 만들면 taxonomy의 의미가 약해지고, 너무 동떨어진 노드를 만들면 seed domain과의 연결이 끊긴다. 그래서 저자들은 상위 노드 정의를 프롬프트에 넣어, 생성된 하위 노드가 부모 의미를 유지하면서도 서로 겹치지 않도록 유도한다.

하지만 generator만으로는 taxonomy 품질을 보장하기 어렵다. LLM은 쉽게 중복되는 카테고리, 지나치게 넓은 카테고리, 서로 다른 수준의 추상도를 섞은 카테고리를 함께 낼 수 있다. 그래서 논문은 Task Type Quality Evaluator를 별도로 둔다. evaluator는 redundancy, specificity, completeness 같은 기준으로 현재 후보 집합을 self-critique하고, 필요하면 후보를 수정한다. 이 과정은 no-change 판정이 세 번 연속 나올 때까지 반복되며, 그 시점의 집합이 최종 child set이 된다.

이 구조는 단순한 self-refine 아이디어처럼 보이지만, 이 논문 맥락에서는 상당히 중요하다. 라우터는 최종적으로 이 taxonomy를 prior로 쓰기 때문에, taxonomy 자체가 불안정하면 후단 학습도 불안정해질 수 있다. 저자들이 appendix에서 프롬프트를 길게 공개한 것도 이런 이유로 읽힌다. 즉, 논문의 novelty는 단지 synthetic QA를 만든다는 선언이 아니라, 어떤 task space를 만들고 그 품질을 어떻게 통제할 것인가까지 구체화했다는 데 있다.

실제로 appendix를 보면 node generation rule은 꽤 세세하다. domain은 일반적이되 겹치지 않아야 하고, subcategory는 많은 사용자 질의를 포괄하되 model selection에 도움을 줄 정도로 구체적이어야 하며, difficulty level은 reasoning complexity나 token usage, required capability를 반영해 순서화되어야 한다. 이런 규칙은 단순 prompt engineering이라기보다, 라우팅용 synthetic curriculum을 만드는 일종의 ontology design에 가깝다.

3.4.3 QA Pair Generator와 중복 제거 전략

taxonomy가 완성되면, 각 difficulty-level node를 하나의 task profile로 보고 질문-답변 쌍을 생성한다. 저자들은 difficulty node의 이름과 정의뿐 아니라 부모 domain과 subcategory 설명까지 함께 묶어 프롬프트 조건으로 사용한다. 이 설계의 요지는 간단하다. 같은 difficulty node라도 상위 문맥이 없으면 질문이 부정확하게 퍼질 수 있는데, 부모 노드 정보를 함께 넣으면 더 명확한 분포를 만들 수 있다는 것이다. 즉 task profile은 leaf label 하나가 아니라 경로 전체에서 유도된 문맥적 설명이라고 이해하면 된다.

QA 생성은 한 번에 많이 뽑고 끝내는 방식이 아니다. 논문은 batch size를 8로 두고 반복적으로 생성한 뒤, 새로 나온 QA 쌍이 기존 집합과 얼마나 가까운지 sentence-transformer로 계산한다. 만약 기존 QA와의 최대 semantic similarity가 0.9를 넘으면 near-duplicate로 보고 버린다. 이 단순한 filtering이 중요한 이유는, synthetic data에서 자주 발생하는 문제가 “서로 다른 표면만 가진 사실상 같은 문제”의 대량 복제이기 때문이다. 저자들은 강한 LLM 기반 필터보다 이 정도 semantic filtering만으로도 routing 목적에는 충분하다고 주장한다.

이 지점에서 이 논문은 생성 모델 학습용 데이터 합성과 조금 다른 철학을 보인다. 일반적인 instruction-tuning 데이터 합성에서는 낮은 품질이나 중복이 성능 붕괴를 일으킬 수 있어 매우 강한 필터가 필요하다는 논의가 많다. 하지만 저자들은 라우팅이 개별 답안을 학습하는 문제가 아니라 모델 간 cost-performance trend를 태스크 수준에서 파악하는 문제이기 때문에, 개별 QA pair의 약간의 노이즈에는 더 강하다고 본다. 그래서 중복 제거는 엄격하게 하되, 품질 필터는 상대적으로 가볍게 간다.

실험 세팅에서 이 생성기는 task profile당 40개의 QA pair를 만든다. 결국 GPT-4.1 기반 파이프라인은 10 domains, 103 subcategories, 447 difficulty nodes, 17,880 QA pairs를 만들고, Gemini-2.5-Flash 기반 파이프라인은 10 domains, 98 subcategories, 380 difficulty nodes, 15,200 QA pairs를 만든다. 이 수치는 단순한 양의 과시가 아니라, taxonomy 구조가 실제로 수백 개 leaf node 수준의 세밀함을 갖고 있음을 보여준다. cold-start router를 학습하기 위한 synthetic supervision으로는 꽤 큰 규모다.

Figure 2: domain, subcategory, difficulty 중 어느 수준의 task profile을 쓰느냐에 따라 샘플링 효율이 어떻게 달라지는지 보여주는 ablation

Figure 2는 왜 저자들이 difficulty-level task profile을 강조하는지 보여 준다. 고정된 샘플링 반복 수에서 domain이나 subcategory 조건부 생성은 시간이 지날수록 중복이 누적되어 유효 QA 증가 속도가 둔화되지만, difficulty-conditioned profile은 상대적으로 선형에 가까운 증가를 보인다. 즉 같은 호출 예산이라면 더 세밀한 task profile이 더 많은 비중복 QA를 확보해 준다. 이 그림은 단순히 “더 세밀하면 좋다”는 직관이 아니라, 실제 합성 효율과 다양성 측면에서 leaf-level conditioning이 이득이라는 점을 보여 주는 근거다.

3.4.4 합성 데이터의 비용, 품질, 누수 가능성

합성 데이터 접근의 가장 큰 질문은 대개 두 가지다. “얼마나 정확한가”와 “얼마나 싼가”다. 논문은 appendix에서 세 도메인, 즉 Mathematics, Creative Writing, Commonsense Knowledge를 골라 정량 점검을 수행한다. 난도를 easy, medium, hard로 묶어 샘플링한 결과, 정답 정확도는 easy에서 거의 100%, medium에서 97.16%, hard에서 94.5%를 보였다. hard만 따로 보면 Mathematics는 92.5%, Commonsense Knowledge는 97.5%다. 이는 합성 데이터가 적어도 명백히 잘못된 QA의 대량 집합은 아니라는 뜻이다.

다양성 측면의 분석도 흥미롭다. 저자들은 103개 subcategory, 447개 difficulty node 수준에서 semantic redundancy가 없다고 보고하고, 특히 프로그래밍과 상식 지식 도메인의 30개 difficulty node를 들여다본 결과 근접 중복 질문이 남아 있지 않다고 말한다. 물론 더 넓은 의미에서 semantic equivalence를 엄격하게 보느냐에 따라 redundancy rate는 달라진다. 예컨대 commonsense 도메인에서는 약 10% 정도의 의미 중복이 있을 수 있다고 한다. 하지만 routing 관점에서는 이 정도가 치명적이지 않으며, 오히려 완전 무중복을 강제하는 비용이 과도하다는 것이 저자들의 판단이다.

비용 측면에서는 GPT-4.1 기반 생성이 입력 0.91M 토큰, 출력 1.56M 토큰으로 총 14.34달러, Gemini-2.5-Flash 기반 생성이 입력 0.78M, 출력 3.92M 토큰으로 10.03달러가 들었다. 두 엔진을 모두 합친 총합은 24.37달러 수준이다. cold-start 라우터 학습용 데이터셋을 이 정도 비용으로 얻는다면, 적어도 초기 제품 실험 단계에서는 꽤 매력적이다. 특히 저자들은 수작업으로 같은 수준의 데이터셋을 만들면 6,000달러 이상이 들고, 실제로는 그보다 훨씬 더 비싸질 수 있다고 추정한다.

데이터 누수 가능성에 대한 점검도 빠지지 않는다. GSM8K와 SQuAD 테스트셋을 synthetic training data와 embedding similarity로 비교한 뒤, top-20 유사 샘플을 GPT-4.1로 다시 semantic equivalence 판정한 결과, GSM8K에서는 exact 또는 semantic overlap이 없었고, SQuAD에서는 매우 소수의 고유사례만 발견되었다. 저자들은 이 결과와 함께 “5~10 shots만으로도 거의 최적 성능이 나온다”는 점을 들어, 논문 결과가 test leakage에 기대어 나온 것이 아님을 주장한다. 완전한 증명은 아니지만, 최소한 직접 복사된 synthetic train set 위에 성능이 서 있는 것은 아니라는 점은 설득력 있게 보인다.

Table 1. 논문이 메인 실험에 사용한 벤치마크와 평가 지표

Dataset	Task Type	Metric	Cases
Alpaca	Hybrid QA	F1	2000
GSM8K	Reasoning	Accuracy	2000
SQuAD	Reading Comprehension	F1	2000
Multi-News	Summary	F1	2000

Table 1은 실험 범위가 단일 태스크에 갇혀 있지 않음을 보여 준다. Hybrid QA, 수학 추론, 읽기 이해, 요약이 함께 들어가 있다는 것은 합성 taxonomy가 단순 한 도메인 전용 라우터가 아니라, 서로 다른 비용-성능 곡선을 가진 작업군을 동시에 포괄한다는 뜻이다. 특히 Multi-News처럼 전통적 문자열 기반 평가지표가 다소 거칠게 작동할 수 있는 태스크가 포함되어 있어, 이후 LLM-as-a-judge 결과와의 차이를 읽는 데 중요한 기준점이 된다.

Table 2. 메인 및 보조 실험에 등장하는 후보 LLM 풀과 백만 토큰당 가격

Model	Size	Input (¥/M)	Output (¥/M)
Open-source	-	-	-
Qwen3-235B-A22B	235B	2.00	8.00
Qwen3-32B	32B	2.00	8.00
Qwen3-14B	14B	1.00	4.00
Qwen3-8B	8B	0.50	2.00
Qwen3-1.7B	1.7B	0.30	1.20
Qwen3-0.6B	0.6B	0.30	1.20
Commercial	-	-	-
Gemini-2.5-Flash	-	2.14	17.86
Gemini-2.5-Flash-Lite	-	0.71	2.86
Gemini-2.0-Flash	-	0.71	2.86
Gemini-2.0-Flash-Lite-Preview	-	0.54	2.14
Doubao-Seed-1.6-Flash	-	0.15	1.50

Table 2를 보면 저자들이 일부러 모델 크기와 가격이 계단형으로 다른 풀을 만들었음을 알 수 있다. 이런 풀이어야 라우터가 진짜로 고민할 여지가 생긴다. 모든 모델이 가격과 성능에서 비슷하면 라우팅은 큰 의미가 없다. 반대로 0.6B에서 235B까지, 그리고 다양한 상용 플래시 모델이 섞여 있으면 특정 태스크와 난도에서 어느 지점이 진짜 frontier인지 학습할 가치가 커진다.

Table 3. 합성 taxonomy와 QA 데이터셋의 규모 및 생성 비용 요약

Synthesizer	Domains	Subcategories	Difficulty Nodes	QA Pairs	Input Tokens	Output Tokens	Synthesis Cost
GPT-4.1-2025-04-14	10	103	447	17,880	0.91M	1.56M	14.34달러
Gemini-2.5-Flash	10	98	380	15,200	0.78M	3.92M	10.03달러
Total	-	-	-	33,080	1.69M	5.48M	24.37달러

Table 3은 이 논문의 실용성을 한 줄로 요약한다. 대략 24달러대의 합성 비용으로 수백 개 difficulty node와 3만 개가 넘는 QA supervision을 확보했다는 뜻이기 때문이다. 물론 이것이 모든 도메인에서 동일한 품질을 보장한다는 의미는 아니다. 하지만 라우터가 cold-start에서 아예 학습 불가능한 상태와, 최소한 task-conditioned regression을 시도할 수 있는 상태 사이의 차이는 매우 크다. 저자들이 이 비용 구조를 제시한 것은 “synthetic data가 정말 싸게 먹히는가”라는 가장 현실적인 질문에 대한 정면 답변이라고 볼 수 있다.

3.5 TRouter의 확률적 구조와 학습 메커니즘

3.5.1 Task recognition module이 하는 일

TRouter의 구현은 생각보다 과장되지 않았다. 먼저 질의 $q$와 모든 task type 설명 텍스트를 all-MiniLM-L6-v2로 인코딩하고, 이를 256차원 잠재공간으로 투영한다. 이때 각 task type은 단순 인덱스가 아니라 자연어 정의를 가진 노드이기 때문에, embedding 자체에 어느 정도 의미 정보가 들어간다. 그런 다음 질의 임베딩과 task 임베딩들을 결합해, 질의가 어떤 task type 분포를 가질지 예측하는 task recognition module을 학습한다.

흥미로운 점은 논문이 각 질의가 실제로는 여러 태스크 성격을 가질 수 있음을 인정하면서도, 메인 실험에서는 단일 ground-truth task label을 사용한다는 점이다. difficulty level에 해당하는 라벨 하나를 one-hot prior로 두고 cross-entropy로 학습한다. 얼핏 보면 이것이 과도하게 단순해 보일 수 있지만, 후단 metric prediction이 확률 분포 전체를 활용하기 때문에 inference 단계에서는 어느 정도 task ambiguity를 흡수할 수 있다. Appendix에서 multi-task-type supervision을 넣어도 큰 이득이 없었던 이유를 저자들은 여기에 연결한다.

이 recognition module은 단지 분류기를 하나 더 붙인 정도가 아니다. 논문에서 이것은 ELBO의 KL 항을 실제로 구현하는 장치이며, task prior를 따라가도록 posterior를 규제하는 역할을 한다. 다시 말해 task recognition은 “질의가 무엇인가”를 맞히기 위한 보조 과제가 아니라, metric regression이 query idiosyncrasy를 과도하게 외우지 못하도록 하는 structural regularizer다. TRouter가 MetricRouter보다 더 안정적으로 나온 근본 이유도 결국 여기에 있다.

3.5.2 Metric prediction module과 가중합 추론

task distribution이 나오면, 각 모델과 각 metric에 대해 task-specific predictor를 거쳐 최종 값을 합성한다. 성능과 비용 모두 동일한 방식으로 예측되며, 질의가 특정 task에 속할 확률이 높을수록 그 task-specific metric prediction이 더 크게 반영된다. 이 방식은 hard routing이 아니라 soft aggregation이라는 점에서 중요하다. 질의가 하나의 leaf node로 완전히 결정되지 않아도 되고, 여러 노드의 혼합으로 표현될 수 있기 때문이다.

$$\hat{h}(q,m) = \sum_{i=1}^{K} l_i \cdot \sigma\left(\mathrm{MLP}_{h,m}(e_t^i)\right)$$

이 식에서 $l_i$는 질의가 $i$번째 task type에 속할 가능성이고, 각 $\mathrm{MLP}_{h,m}$는 해당 task와 모델에서의 metric을 예측한다. 시그모이드를 거쳐 normalized output을 만든 뒤, 사용자 선호 식에 넣어 utility를 계산한다. 구현 차원에서 보면 매우 가벼운 구조지만, 해석 차원에서는 “이 모델이 왜 선택되었는지”를 task mixture로 설명할 수 있게 된다. 예를 들어 어떤 질의가 수학-중난도와 독해-중난도의 혼합처럼 보인다면, 그 분포가 비용과 성능 예측에 각각 다르게 기여한다.

저자들이 각 model-metric 쌍마다 별도 MLP를 두는 점도 눈에 띈다. 이는 공유 파라미터를 크게 쓰지 않는 대신, 각 모델이 어떤 task에서 얼마나 유리한지를 더 직접적으로 배우게 하려는 설계다. 후보 모델 수가 아주 많아지면 파라미터 수가 늘 수 있지만, 논문 범위에서는 여전히 lightweight router 수준에 머문다. 중요한 것은 라우터가 거대한 LLM이 아니라도 task-conditioned metric prediction만 잘하면 충분히 효과를 볼 수 있다는 메시지다.

3.5.3 최종 손실함수와 학습 세부사항

TRouter의 최종 학습 목표는 task recognition용 cross-entropy와, 모든 모델-모든 metric에 대한 MSE를 평균한 값을 합친 것이다. recognition loss는 taxonomy prior를 따르도록 만들고, regression loss는 실제 관측된 비용과 성능을 복원하도록 만든다. 이 구조는 매우 단순하지만 목적이 분명하다. task type이라는 중간 표현이 질의 의미를 구조화하도록 하고, 동시에 그 구조가 실제 routing utility에 유효하도록 만드는 것이다.

$$\mathcal{L} = \mathcal{L}_{\text{CE}} + \frac{1}{|\mathcal{M}|\,|\mathcal{H}|} \sum_{m \in \mathcal{M}} \sum_{h \in \mathcal{H}} \mathcal{L}_{\text{MSE}}^{h,m}$$

세부 구현은 비교적 소박하다. text encoder는 all-MiniLM-L6-v2, latent dimension은 256, temperature $\tau$는 0.07, optimizer는 Adam, learning rate는 1e-4다. cold-start에서는 task type당 30개 QA pair를 학습용으로, 10개를 검증용으로 사용한다. 즉, 엄청난 대형 학습이 아니라도 task prior가 유효하다면 충분히 라우팅 개선이 나온다는 것이 논문의 요지다. appendix의 learning-rate ablation도 1e-4 근처가 가장 안정적이라고 보고한다.

이 설정에서 중요한 것은 모델의 복잡도가 아니라 중간 표현의 질이다. 같은 MiniLM 기반 문장 표현을 쓰더라도, MetricRouter는 질의 임베딩에서 바로 metric을 예측하고, TRouter는 task distribution을 한 번 통과시킨다. 저자들은 이 한 단계의 차이가 cold-start robustness를 만든다고 주장한다. 특히 태스크 공간이 447개 leaf node까지 커지는 상황에서도 top-5 task accuracy가 70% 수준까지 나온다는 appendix 분석은, recognition module이 완전히 허공의 분류를 하고 있는 것은 아니라는 점을 보여 준다.

Figure 3: 왼쪽은 task-profile-guided data synthesis, 오른쪽은 latent task type을 넣은 TRouter의 전체 구조

Figure 3은 본 논문의 두 기여를 한 장에 묶어 보여 준다. 왼쪽에서는 task type generator와 quality evaluator가 계층형 taxonomy를 만들고, QA pair generator가 각 difficulty-level profile에 맞는 질의를 생산한다. 오른쪽에서는 질의가 task distribution으로 바뀐 뒤, 그 분포가 모델별 cost/performance prediction을 만들고 최종 utility로 연결된다. 즉 이 논문의 핵심은 합성 데이터와 라우터 구조가 따로 노는 것이 아니라, 같은 task taxonomy를 공유하는 폐루프로 설계되었다는 데 있다.

4. 실험 설정: 벤치마크, 후보 모델, 평가 프로토콜, 구현 디테일

4.1 데이터셋과 split 설계

메인 실험은 Alpaca, GSM8K, SQuAD, Multi-News 네 데이터셋을 함께 모아 수행한다. 이 네 작업은 각각 hybrid QA, 수학 추론, 읽기 이해, 요약이라는 서로 다른 성질을 대표한다. 저자들은 각 질의마다 후보 LLM들의 응답을 생성하고, 그 응답의 performance와 cost를 계산해 multi-task interaction dataset을 만든다. 이후 이를 train:validation:test = 7:1:2로 나눈다. supplementary 실험에서는 WMT, MBPP, LegalBench, MedMcQA 네 가지를 추가로 사용하고, 이쪽은 5:1:4 비율로 나눈다.

이 split 전략이 의미 있는 이유는 라우터가 단지 one-task router가 아니라 heterogeneous task mixture 위에서 학습되기 때문이다. 만약 특정 도메인만 들어갔다면 synthetic taxonomy의 역할을 판단하기 어려웠을 것이다. 하지만 수학과 요약, 법률과 의료까지 퍼진 supplementary 결과를 보면, 적어도 저자들이 만든 taxonomy가 단일 장난감 도메인에 갇히지는 않았다는 점을 확인할 수 있다. 물론 real production traffic와 완전히 같은 것은 아니지만, 학술 실험으로서는 충분히 넓은 범위를 커버한다.

4.2 후보 LLM과 비용 구조

메인 후보 풀은 Qwen 3 시리즈다. 0.6B, 1.7B, 8B, 14B, 32B, 235B-A22B까지 크기와 가격이 크게 다른 모델들을 넣어, 라우터가 실제 절충을 배울 수 있게 했다. supplementary 실험에서는 Gemini 계열과 Doubao, 추가로 gpt-5 계열까지 넣어 모델 다양성에 대한 우려를 줄였다. 이 구성은 꽤 중요하다. 특정 계열 안에서만 성립하는 라우팅이면 실용성이 약한데, 논문은 최소한 여러 commercial family로 확장되는지까지 보였다.

비용은 입력 토큰 수와 출력 토큰 수에 각각 모델별 단가를 곱해 계산한다. 따라서 같은 모델이라도 긴 추론을 하면 cost가 커지고, 같은 질의라도 output length가 길어지면 utility가 달라진다. 이 점은 뒤 appendix에서 제시한 분포 시각화와 연결된다. 저자들은 합성 데이터 위에서도 difficulty가 올라갈수록 긴 reasoning이 요구되며 cost tail이 두꺼워지는 패턴을 확인했고, 이것이 task-aware routing의 정당성을 뒷받침한다고 주장한다.

4.3 전통 지표와 LLM-as-a-judge를 함께 쓰는 이유

논문은 성능 평가를 두 가지 방식으로 수행한다. 하나는 각 데이터셋이 가진 traditional metric이다. GSM8K는 accuracy, 요약과 QA류는 F1, 프로그래밍은 pass@1, 번역은 BLEU를 쓰는 식이다. 다른 하나는 LLM-as-a-judge다. 여기서는 질문, 정답, 후보 응답을 함께 보여 주고, judge model이 0.0에서 1.0 사이 점수 하나만 반환하게 한다. 메인 judge는 비용을 고려해 gpt-4.1-nano-2025-04-14를 사용한다.

이중 평가가 중요한 이유는, 라우터가 결국 무엇을 “좋은 모델”로 정의하느냐에 완전히 의존하기 때문이다. 문자열 겹침 기반 F1은 수학에서 formatting issue 때문에 semantic correctness를 놓칠 수 있고, 요약에서 content selection이나 coherence를 잘 반영하지 못할 수 있다. 따라서 전통 지표로 학습한 라우터와 judge 기반으로 학습한 라우터는 서로 다른 candidate model ranking을 배울 수 있다. 저자들이 두 설정을 분리해 보고, 나아가 appendx figure로 distribution 차이까지 시각화한 것은 상당히 꼼꼼한 설계다.

실무 관점에서도 이 메시지는 중요하다. 만약 서비스 운영자가 production에서 사람 선호와 비슷한 신호를 따르고 싶다면, 라우터 학습 단계에서도 그에 맞는 평가 프로토콜을 써야 한다. 논문이 “evaluation setup과 test scenario의 정렬”을 강조하는 이유가 바로 여기에 있다. 즉, 라우터의 성능은 단지 모델 구조가 아니라 어떤 스코어를 정답으로 삼았는지에 의해 크게 좌우된다.

4.4 비교 베이스라인과 하이퍼파라미터

cold-start 베이스라인은 Smallest LLM, Largest LLM, Adaptive LLM, Prompt LLM 네 종류다. Adaptive LLM은 사용자 선호에 따라 작은, 중간, 큰 모델을 규칙적으로 선택하는 휴리스틱이고, Prompt LLM은 외부 LLM에게 질의와 모델 풀, 목표를 넣어 가장 적절한 후보를 고르게 한다. 이 비교는 중요하다. 왜냐하면 실제 서비스에서는 가장 먼저 이런 규칙 기반 또는 prompt-based selection을 시도하는 경우가 많기 때문이다.

in-domain 베이스라인에는 RouterDC, GraphRouter, FrugalGPT, C2MAB-V, MetricRouter, Oracle이 포함된다. RouterDC와 GraphRouter는 분류형, MetricRouter는 회귀형, C2MAB-V는 contextual bandit, FrugalGPT는 품질 예측 기반 선택기다. Oracle은 모든 query-model 쌍의 진짜 비용과 성능을 알고 효용을 최대화하는 상한선이다. 또한 cold-start 비교를 위해 RouterDC와 MetricRouter는 세 데이터셋에 학습하고 남은 하나에 평가하는 cross-domain 변형도 함께 둔다. 이 때문에 결과표에서 별표가 붙은 baseline들이 등장한다.

구현 측면에서는 합성 taxonomy 생성에 GPT-4.1과 Gemini-2.5-Flash 두 엔진을 번갈아 쓰고, recognition과 regression은 모두 MiniLM 기반 가벼운 MLP들로 구현한다. batch size 8, task profile당 40 QA, task evaluator의 no-change 기준 3회, cold-start에서 task type당 train 30 / val 10, learning rate 1e-4 같은 수치가 명시되어 있다. 이 정도 세부사항은 재현성 차원에서도 의미가 있지만, 더 중요한 것은 방법 자체가 과도한 compute를 요구하지 않는다는 점이다.

• cold-start baseline은 인도메인 데이터 없이도 실행 가능한 규칙 기반 또는 prompt 기반 선택기들이다.
• in-domain baseline은 기존 라우팅 연구의 대표 분류형, 회귀형, bandit형 방법을 고르게 포함한다.
• TRouter는 synthetic data만으로도 cold-start에 투입 가능하고, 인도메인 데이터가 생기면 같은 구조로 더 미세 조정할 수 있다.

이 구성 덕분에 논문은 두 가지 질문에 동시에 답할 수 있다. 첫째, “기존 강한 라우터들과 정면 비교해도 이기나?” 둘째, “정말 cold-start에서 쓸 만한 간단한 대안들보다도 확실히 낫나?” 실제 결과를 보면 이 두 질문 모두에 꽤 일관된 긍정 답을 내놓는다.

5. 주요 실험 결과: cold-start와 in-domain에서 utility가 어떻게 달라지는가

5.1 전통 지표 기준 메인 결과: cold-start에서도 규칙 기반보다 앞선다

가장 먼저 볼 표는 traditional metrics 기준 메인 결과다. cold-start 상황에서 가장 강한 단순 baseline은 Adaptive LLM으로 utility sum 0.4913을 기록한다. cross-domain RouterDC는 0.4676, cross-domain MetricRouter는 0.2319로 크게 흔들린다. 반면 TRouter는 synthetic data를 GPT-4.1로 만들면 0.5274, Gemini-2.5-Flash로 만들면 0.5382까지 올라간다. 중요한 것은 이 수치가 단순히 “baseline보다 조금 좋다”가 아니라, 인도메인 데이터 없이도 cross-domain learned router를 안정적으로 넘는다는 점이다.

세부 preference를 보면 더 흥미롭다. cost-first에서는 GPT 기반 synthetic이 0.0355, Gemini 기반 synthetic이 0.0352로 거의 비슷하게 최고권을 형성한다. balance에서는 0.1811과 0.1809로 역시 비슷하다. performance-first에서는 오히려 Gemini 기반 synthetic TRouter가 0.3221로 가장 좋다. 즉 합성 엔진이 바뀌어도 전반적 메시지는 유지되며, 특정 preference에서 우열이 조금 달라질 뿐이다. 저자들이 “framework의 versatility”를 강조하는 이유가 여기 있다.

in-domain으로 가면 TRouter의 장점은 더 선명해진다. MetricRouter가 utility sum 0.5741, RouterDC가 0.5667인데, GPT 기반 TRouter는 0.5925, Gemini 기반 TRouter는 0.5836을 기록한다. 특히 GPT 기반 TRouter는 cost-first 0.0518, balance 0.1974, performance-first 0.3433으로 세 preference 모두에서 가장 높다. 이는 TRouter가 단지 cold-start rescue model이 아니라, 인도메인 데이터가 있을 때도 기본 회귀형 라우터보다 더 좋은 inductive bias를 제공할 수 있음을 뜻한다.

Oracle 0.7037과의 차이는 여전히 크다. 하지만 이것은 오히려 문제의 난도를 보여 준다. 라우팅 자체가 여전히 상한선과 거리가 있다는 뜻이며, synthetic data만으로 얻은 0.53대 cold-start 결과가 결코 사소하지 않다는 의미이기도 하다. 실무적으로 보면, 아무 로그도 없이 heuristic만 쓰는 상태와, 0.53 수준의 learned task-aware router를 바로 얹는 상태의 차이는 충분히 클 수 있다.

Table 4. traditional metrics 기준 메인 결과 요약

Scenario	Method	Cost-first Utility	Balance Utility	Performance-first Utility	Utility Sum
Cold-start	Adaptive LLM	0.0217	0.1809	0.2887	0.4913
Cold-start	Prompt LLM	0.0085	0.1434	0.2887	0.4406
Cold-start	RouterDC*	0.0197	0.1490	0.2989	0.4676
Cold-start	MetricRouter*	0.0123	0.0703	0.1492	0.2319
Cold-start	Ours (GPT synthesis)	0.0355	0.1811	0.3108	0.5274
Cold-start	Ours (Gemini synthesis)	0.0352	0.1809	0.3221	0.5382
In-domain	RouterDC	0.0411	0.1849	0.3408	0.5667
In-domain	MetricRouter	0.0442	0.1911	0.3388	0.5741
In-domain	Ours (GPT synthesis)	0.0518	0.1974	0.3433	0.5925
In-domain	Ours (Gemini synthesis)	0.0509	0.1936	0.3336	0.5836
Upper bound	Oracle	0.0705	0.2332	0.3999	0.7037

Table 4는 cold-start와 in-domain을 한눈에 비교하기 좋은 요약이다. 가장 눈에 띄는 점은 TRouter가 synthetic data만으로도 cross-domain MetricRouter를 크게 앞선다는 사실이다. 단순히 태스크 prior 하나를 더 넣은 정도가 아니라, 학습 데이터의 출발점과 구조적 regularization이 동시에 바뀌어야 cold-start가 풀린다는 것을 수치로 보여 준다. 또 in-domain에서도 개선이 유지된다는 점은, synthetic stage가 임시변통이 아니라 오히려 라우터 설계 자체를 더 좋게 만들 수 있음을 뜻한다.

5.2 LLM-as-a-judge 결과: 평가 프로토콜이 바뀌어도 TRouter는 강하다

judge 기반 결과는 traditional metric 결과와 비슷하면서도 미묘한 차이를 보인다. cold-start에서 TRouter는 utility sum 0.6551을 기록해 Adaptive LLM 0.6191, Prompt LLM 0.5888보다 높다. 흥미롭게도 cost-first에서는 RouterDC*가 0.0544로 가장 높고, TRouter는 0.0505로 근소하게 뒤진다. 그러나 balance에서는 0.2196으로 최고, performance-first에서는 0.3850으로 크게 앞선다. 결국 utility sum 전체는 TRouter가 가장 높다. 즉 특정 preference 한 지점의 순간 우세보다, 여러 사용자 조건에 걸친 안정성에서 강점을 보인다고 해석하는 편이 맞다.

in-domain에서도 TRouter는 utility sum 0.6733으로 가장 높고, MetricRouter는 0.6512로 그 뒤를 잇는다. cost-first에서는 TRouter와 MetricRouter가 모두 0.0604로 사실상 동률이지만, balance와 performance-first에서는 TRouter가 조금씩 더 높다. 이 패턴은 저자들의 주장과 맞물린다. task-type regularization이 항상 압도적인 개선을 주는 것은 아니더라도, 분포가 흔들리거나 평가 프로토콜이 바뀌는 상황에서 variance를 줄이고 평균 성능을 끌어올리는 방향으로 작동한다는 것이다.

또 하나 중요한 관찰은 cold-start와 in-domain 사이의 gap이 traditional metrics보다 judge 기반 평가에서 다소 줄어든다는 점이다. 논문은 이를 candidate LLM들의 performance distribution이 프로토콜에 따라 달라지기 때문이라고 해석한다. 쉽게 말해, 어떤 지표로 모델 성능을 측정하느냐에 따라 라우터가 배워야 할 landscape가 바뀌는 것이다. 이 때문에 저자들은 production에서 judge-like 선호를 따를 것이라면 학습 때도 같은 방식으로 model performance를 산정하는 편이 낫다고 제안한다.

Table 5. LLM-as-a-judge 기준 메인 결과 요약

Scenario	Method	Cost-first Utility	Balance Utility	Performance-first Utility	Utility Sum
Cold-start	Adaptive LLM	0.0488	0.2194	0.3510	0.6191
Cold-start	Prompt LLM	0.0495	0.1883	0.3510	0.5888
Cold-start	RouterDC*	0.0544	0.2159	0.2074	0.4777
Cold-start	MetricRouter*	0.0498	0.2078	0.1830	0.4406
Cold-start	Ours	0.0505	0.2196	0.3850	0.6551
In-domain	RouterDC	0.0582	0.2002	0.3470	0.6054
In-domain	C2MAB-V	0.0492	0.2194	0.3785	0.6471
In-domain	MetricRouter	0.0604	0.2189	0.3769	0.6512
In-domain	Ours	0.0604	0.2223	0.3906	0.6733
Upper bound	Oracle	0.0968	0.3175	0.5472	0.9615

Table 5를 보면 LLM-as-a-judge 기준에서는 전체 utility scale이 커지고, Oracle과의 격차도 더 넓어진다. 이는 judge가 표면 overlap보다 더 풍부한 품질 차이를 반영해 모델 간 성능 편차를 더 크게 드러냈기 때문으로 읽을 수 있다. 그럼에도 TRouter가 최고 utility sum을 유지한다는 것은, task-aware prior가 특정 metric family에만 맞춘 트릭이 아니라는 뜻이다. 특히 performance-first에서 cold-start utility가 0.3850까지 올라가는 것은, 비용을 너무 많이 쓰지 않으면서도 사람이 보기 좋은 응답을 고르는 능력이 충분히 개선될 수 있음을 시사한다.

Figure 4: Alpaca와 Multi-News에서 전통 지표를 썼을 때 후보 모델들의 정규화된 비용-성능 분포가 어떻게 달라지는지 보여 주는 시각화

Figure 4는 왜 평가 프로토콜 정렬이 중요한지 직관적으로 보여 준다. 같은 Qwen 계열 모델들이라도 데이터셋에 따라 cost와 performance 분포 모양이 달라지고, 따라서 “좋은 모델”의 정의도 달라질 수 있다. 만약 라우터가 한 프로토콜에서 배운 분포를 다른 프로토콜로 그대로 가져가면, 효용 곡면 자체가 어긋날 수 있다. 저자들이 production에서 judge 기반 선호를 쓸 계획이라면 학습에서도 유사한 judge-based signal을 쓰라고 권하는 이유가 바로 이 그림에 담겨 있다.

6. 추가 분석 및 Ablation Study: 샘플 효율과 일반화 범위를 어떻게 읽을 것인가

6.1 샘플 효율, taxonomy 수준, 학습률 ablation

TRouter의 장점이 단지 synthetic data 양으로 밀어붙인 결과인지 확인하기 위해, 논문은 여러 ablation을 수행한다. 먼저 shot 수를 바꾸는 실험에서는 cold-start에서 30 shots를 기본값으로 쓰지만, 5 shots 이하에서도 성능이 거의 최적에 가깝게 나온다. 이는 매우 중요한 결과다. 만약 shot 수가 수십에서 수백으로 커져야만 의미가 있다면, synthetic data의 비용 이점이 줄어든다. 하지만 실제로는 몇 개의 representative QA만으로도 task prior가 상당히 유효하게 작동했다.

taxonomy 수준 ablation도 흥미롭다. cold-start에서는 domain-level regularization이 utility sum 0.5402로 가장 높고, full difficulty-level regularization은 0.5274다. 반면 in-domain에서는 difficulty-level이 0.5925로 가장 높고, domain-level은 0.5641에 그친다. 저자들의 해석은 납득할 만하다. cold-start에서는 너무 세밀한 difficulty prior가 아직 잘 calibrate되지 않아 오히려 간섭을 만들 수 있지만, 인도메인 데이터로 조금이라도 적응이 이루어지면 세밀한 task space가 더 풍부한 정보를 주기 시작한다는 것이다.

또한 appendix에서 AgenticRouter, 즉 test-time에 ground-truth task label을 직접 주는 이상화된 variant는 cold-start utility sum 0.5325를 보인다. TRouter 0.5274보다 약간 높지만 차이가 크지 않다. 이는 recognition module 자체가 병목이 될 정도로 형편없지는 않으며, latent task distribution만으로도 대부분의 이득을 이미 얻고 있음을 뜻한다. 반대로 Assumption (1)을 푼 variant는 cold-start 0.5159로 떨어져, task-conditioned independence 가정이 실제 일반화에 도움이 된다는 점도 보여 준다.

Figure 5: cold-start에서 synthetic shot 수가 늘어날 때 TRouter와 MetricRouter의 효용이 어떻게 달라지는지 비교

Figure 5는 sample efficiency 측면에서 TRouter의 강점을 압축한다. shot 수가 적을 때도 TRouter는 비교적 안정적인 성능을 보이고, 같은 synthetic data를 써도 task regularization이 없는 MetricRouter는 훨씬 불안정하다. 즉 이 그림은 “더 많은 데이터가 있으니 잘 된다”가 아니라, 같은 데이터에서도 task prior가 있느냐 없느냐가 성능 차이를 만든다는 것을 시각적으로 보여 준다. cold-start 실전성을 따질 때 매우 중요한 그림이다.

Table 6. domain, subcategory, difficulty 중 어떤 수준의 태스크 집합 $\mathcal{T}$를 쓰는지가 utility에 미치는 영향

Setting	Method	Cost-first Utility	Balance Utility	Performance-first Utility	Utility Sum
Cold-start	Domain regulation	0.0343	0.1809	0.3250	0.5402
Cold-start	Subcategory regulation	0.0350	0.1740	0.3204	0.5294
Cold-start	Difficulty regulation (Ours)	0.0355	0.1811	0.3108	0.5274
In-domain	Domain regulation	0.0505	0.1887	0.3249	0.5641
In-domain	Subcategory regulation	0.0510	0.1920	0.3379	0.5809
In-domain	Difficulty regulation (Ours)	0.0518	0.1974	0.3433	0.5925

Table 6은 본 논문의 핵심 통찰을 잘 보여 주는 표다. cold-start에서는 coarse한 domain prior가 의외로 가장 강하지만, 인도메인 적응이 가능해지면 difficulty-level prior가 확실히 이긴다. 이것은 태스크 구조를 얼마나 세밀하게 넣을지는 “원칙적으로 깊을수록 좋다”의 문제가 아니라, 현재 보유한 supervision이 그 세밀함을 지탱할 수 있는가의 문제라는 뜻이다. 이 해석은 실제 서비스에서도 유용하다. 초기에는 coarse taxonomy로 시작하고, 로그가 쌓이면 finer taxonomy로 내려가는 incremental deployment 전략을 자연스럽게 떠올릴 수 있기 때문이다.

Figure 6: cold-start에서 learning rate를 바꿨을 때 TRouter utility가 어떻게 달라지는지 보여주는 ablation

Figure 6은 하이퍼파라미터 민감도를 점검한 결과다. 1e-4 부근에서 utility가 가장 높고, 그보다 낮은 learning rate로 가도 성능이 크게 무너지지 않는다. 이는 TRouter가 극도로 예민한 optimization trick에 기대지 않는다는 점을 보여 준다. cold-start 같은 실무적 시나리오에서 중요한 것은 SOTA 숫자 자체보다 조금 거칠게 맞춰도 안정적으로 돌아가느냐인데, 이 그림은 그 질문에 꽤 긍정적인 답을 준다.

6.2 supplementary 데이터셋과 closed-source 모델 풀에서도 유지되는가

메인 실험만 보면 “Qwen 계열 안에서만 통하는 결과 아닌가”라는 의문이 남을 수 있다. 논문은 이를 줄이기 위해 supplementary 실험을 꽤 충실하게 넣는다. Gemini 계열과 Doubao가 섞인 closed-source pool에서는 cold-start utility sum이 0.5875, in-domain이 0.6327로 모두 최고다. 또 gpt-5, gpt-5-mini, gpt-5-nano, Doubao 조합의 추가 pool에서는 cold-start 0.6193, in-domain 0.6474로 역시 utility sum 기준 최상위다. 즉 TRouter는 특정 오픈소스 시리즈의 내부 구조를 암묵적으로 외운 것이라기보다, 서로 다른 가격-성능 ladder를 가진 모델군 전반에 대해 작동할 여지가 있음을 보여 준다.

추가 네 데이터셋 WMT, MBPP, LegalBench, MedMcQA에서도 같은 메시지가 반복된다. cold-start에서는 Adaptive LLM 0.4890보다 TRouter가 0.4926으로 약간 앞서고, in-domain에서는 MetricRouter 0.5014보다 TRouter가 0.5128로 더 높다. 절대폭이 메인 테이블만큼 크지는 않지만, 이는 오히려 신뢰감을 준다. 즉 어떤 환경에서는 개선폭이 작고, 어떤 환경에서는 더 크다는 사실 자체가 실전 분포의 다양성을 반영하기 때문이다. 저자들은 이를 method generalization의 근거로 제시한다.

여기서 한 가지 주목할 점은, supplementary 결과가 “항상 모든 칸에서 크게 앞선다”는 형태가 아니라는 것이다. 예를 들어 GPT pool cold-start cost-first에서는 Smallest LLM과 Adaptive LLM이 0.0756으로 가장 높고, TRouter는 0.0755로 사실상 동률이다. 하지만 balance와 performance-first에서 TRouter가 앞서면서 전체 utility sum은 최고가 된다. 이는 TRouter가 특정 preference에만 강한 편향적 정책이 아니라, 여러 preference를 동시에 잘 감당하는 generalist router임을 시사한다.

Table 7. supplementary 실험에서 드러난 일반화 요약

Evaluation Group	Setting	Best Baseline Utility Sum	TRouter Utility Sum	Oracle Utility Sum	Interpretation
Gemini + Doubao closed-source pool	Cold-start	0.5708	0.5875	0.7247	휴리스틱 대비 synthetic routing의 이득이 유지됨
Gemini + Doubao closed-source pool	In-domain	0.6227	0.6327	0.7247	상용 모델군에서도 task-aware prior가 유효
GPT-5 family + Doubao pool	Cold-start	0.5902	0.6193	0.7274	새로운 상용 family 조합에도 확장 가능
GPT-5 family + Doubao pool	In-domain	0.6344	0.6474	0.7274	baseline보다 높은 평균 utility를 유지
Supplementary 4 datasets	Cold-start	0.4890	0.4926	0.6002	영역이 바뀌어도 utility 우세가 사라지지 않음
Supplementary 4 datasets	In-domain	0.5014	0.5128	0.6002	좁지 않은 범위의 일반화 가능성 확인

Table 7은 본 논문의 메시지가 메인 벤치마크에만 갇혀 있지 않음을 요약한다. 개선폭은 환경마다 다르지만, 여러 closed-source family와 추가 벤치마크에서도 TRouter가 baseline best를 넘는 패턴이 반복된다. 이 일관성은 논문이 단순히 Qwen 가격표 하나에 맞춘 heuristic이 아니라, task-aware routing이라는 더 일반적인 운영 원리를 제안하고 있음을 뒷받침한다.

6.3 해석 가능성, synthetic 품질, manual comparison

appendix에서 개인적으로 가장 흥미로운 부분은 interpretability analysis다. TRouter는 447개 task type 공간에서 top-1 task accuracy 약 30%, top-3 50%, top-5 70%를 기록한다. 절대적으로 높은 분류 정확도로 보기는 어렵지만, leaf node가 447개임을 생각하면 전혀 낮다고만 보기도 어렵다. 무엇보다 이 정확도가 utility 개선으로 이어졌다는 점이 중요하다. 저자들은 특히 Alpaca에서 top-1 accuracy가 0.03 수준으로 낮았다고 보고하는데, 이는 Alpaca 질의가 여러 태스크 성격을 동시에 띠는 hybrid QA이기 때문이라고 해석한다.

이 결과는 TRouter의 soft task mixture 설계가 왜 필요한지 다시 설명해 준다. 만약 질의를 하나의 task label로만 억지 분류했다면, 이런 ambiguity는 바로 오류가 되었을 것이다. 그러나 TRouter는 weighted combination으로 metric을 예측하므로, 정답 label 하나를 틀리더라도 top-k 안에 의미 있는 태스크가 여러 개 들어 있다면 여전히 괜찮은 routing 결정을 내릴 수 있다. 즉 task recognition accuracy와 routing utility가 완전히 일치하지 않는다는 점에서, 이 모델은 분류기를 넘어 task-distribution estimator로 보는 편이 맞다.

synthetic data와 manual labeled data 비교도 흥미롭다. 저자들은 세 명의 PhD 연구자가 손으로 task type을 만들고 QA를 구축하려 했지만 충분히 다양하고 품질 높은 set를 만들기 어려웠다고 말한다. 최종적으로는 difficulty node당 5개씩 골라 총 2,235 QA의 curated dataset을 만들었고, 이를 cold-start 평가에 사용했다. 결과는 utility sum 기준 synthetic 0.5397, manual 0.5425로 거의 비슷하다. 즉 synthetic data가 hand-labeled gold를 압도하지는 않지만, 적어도 훨씬 싼 비용으로 거의 같은 utility를 준다는 점이 중요하다.

single-task-type supervision과 multi-task-type supervision 비교도 마찬가지다. multi-label을 써서 KL divergence로 task recognition을 학습해도 utility sum은 0.5853에 그치고, 원래의 single-task-type 기반 TRouter는 0.5925로 오히려 조금 더 좋다. 저자들은 이를 이미 모델 구조가 marginalization을 통해 task ambiguity를 흡수하고 있기 때문이라고 해석한다. 즉, supervision을 더 정교하게 만드는 것이 항상 이득은 아니고, 기본 구조 자체가 이미 충분한 확률적 표현력을 갖고 있다는 뜻이다.

Table 8. supervision 방식과 데이터 출처를 바꿨을 때의 비교

Comparison	Reference Setting	Utility Sum	TRouter Main Setting	Utility Sum	읽는 포인트
Task recognition supervision	Multi-task-type training	0.5853	Single-task-type (Ours)	0.5925	복잡한 multi-label supervision이 필수는 아님
Data source	Manual labeled dataset	0.5425	LLM-generated synthetic dataset	0.5397	비용 차이를 생각하면 synthetic의 실용성이 큼
Interpretability	Top-1 task accuracy	약 30%	Top-5 task accuracy	약 70%	정답 task 하나보다 meaningful top-k 분포가 더 중요함

Table 8이 주는 메시지는 의외로 보수적이다. 더 복잡한 supervision이 반드시 더 좋지 않고, 더 비싼 수작업 데이터가 synthetic보다 압도적으로 낫지도 않다. 이는 TRouter의 핵심 가치가 엄청난 라벨 정밀도보다는 태스크 구조를 일관되게 형성하고 그것을 비용-성능 예측에 연결하는 방식에 있다는 점을 말해 준다. 결국 이 논문의 실용성은 “perfect data를 만들었다”가 아니라, 충분히 쓸 만한 structured proxy를 매우 싼 비용으로 만들었다는 데 있다.

7. 한계점 및 향후 연구 방향: 실제 배포까지 남아 있는 구조적 과제

7.1 최소 인간 개입은 남아 있다

저자들도 분명히 인정하듯이, 이 방법이 완전히 인간 개입을 제거하는 것은 아니다. 최소한 초기 domain description은 사람이 주어야 하고, 어떤 서비스 맥락인지에 대한 상위 컨텍스트도 필요하다. 물론 기존 라우터가 인도메인 평가 로그 전체를 요구한다는 점을 생각하면 훨씬 가벼운 요구다. 하지만 완전 zero-input cold-start는 아니며, 실제 배포에서는 이 seed domain을 얼마나 잘 잡느냐가 synthetic data의 품질을 크게 좌우할 가능성이 높다.

이 한계는 한편으로 장점이기도 하다. 저자들이 말하듯, 도메인을 사람이 조금 제어할 수 있으면 저품질 노드를 잘라내거나, 특정 산업에 맞는 분기를 직접 추가할 수 있다. 즉 cold-start 자동화와 human controllability 사이에서 절충을 택한 셈이다. 다만 논문 본문에서는 seed domain 선택이 얼마나 민감한지, domain seed가 지나치게 좁거나 넓으면 어떻게 되는지에 대한 실험은 충분히 다루지 않는다. 향후에는 domain seed sensitivity analysis가 꼭 필요해 보인다.

7.2 synthetic QA 품질과 judge bias는 완전히 해결되지 않는다

합성 QA가 개별 질문 단위에서는 다소 noisy해도 routing 목적에는 충분하다는 저자들의 주장은 설득력이 있다. 실제로 utility 개선도 나온다. 그럼에도 이 가정은 어디까지나 이 논문이 다룬 범위에서 검증된 것이다. 예를 들어 매우 전문적인 법률 해석, 의료 추론, 멀티턴 대화형 상담 같은 환경에서는 task-type 수준의 평균 경향만으로는 부족할 수도 있다. 합성 데이터 노이즈가 특정 태스크 노드에 체계적으로 몰려 있다면, 라우터가 잘못된 cost-performance frontier를 배우는 위험도 남아 있다.

LLM-as-a-judge 역시 편향을 완전히 벗어날 수는 없다. 저자들은 candidate model family와 다른 judge 모델을 써 self-preference bias를 줄였다고 하지만, judge가 특정 표현 스타일이나 특정 reasoning format을 선호할 가능성은 여전히 있다. 특히 라우터는 아주 작은 score 차이에도 model choice가 달라질 수 있기 때문에, 평가 편향은 곧 routing policy 편향으로 이어질 수 있다. 따라서 후속 연구에서는 다중 judge ensemble이나 사람 선호 calibration을 통한 policy robustness 점검이 중요할 것이다.

7.3 다중 태스크, 유지보수, 운영 업데이트 문제

appendix의 failure case 분석이 암시하듯, 실제 사용자 질의는 종종 여러 태스크를 동시에 요구한다. 논문은 soft task distribution으로 이 문제를 일정 부분 완화하지만, main supervision이 여전히 single-task label에 의존한다는 사실은 남는다. multi-task supervision 실험에서 큰 이득이 없었다고 해도, 이는 현재 데이터와 task space에서의 결과일 뿐이다. 특히 agentic workflow처럼 planning, retrieval, explanation이 섞인 질의가 많아지면, single leaf prior는 한계에 부딪힐 수 있다.

그럼에도 TRouter의 해석 가능성은 장기 유지보수 측면에서 꽤 매력적이다. 저자들이 말하듯, 사용자는 irrelevant subcategory를 제거하는 node offloading, 특정 노드의 과도한 고비용 편향을 고치는 bias correction, 새로운 도메인을 가지로 붙이는 incremental update를 상대적으로 쉽게 시도할 수 있다. black-box embedding router에 비해 이 점은 분명한 차별점이다. 앞으로는 단지 SOTA 숫자보다, 이런 유지보수 가능성이 실제 운영 비용을 얼마나 줄이는지 측정하는 연구도 중요해질 것이다.

• seed domain 선택이 잘못되면 synthetic taxonomy 전체가 흔들릴 수 있다.
• LLM-as-a-judge는 현실적인 대안이지만, routing policy 편향을 완전히 제거하지는 못한다.
• single-task supervision은 단순하고 강력하지만, 복합 질의가 많은 환경에서는 한계를 드러낼 수 있다.
• 반대로 taxonomy 기반 구조는 node-level 수정과 점진적 확장이라는 운영상의 이점을 준다.

결국 이 논문은 cold-start를 완전히 해결했다기보다, cold-start 라우팅을 학습 가능한 문제로 끌어내린 첫 설계 중 하나라고 보는 편이 정확하다. 그리고 그 설계가 단순 accuracy competition이 아니라 운영 가능한 task structure를 제공한다는 점에서, 후속 연구의 출발점으로서 충분히 가치가 있다.

8. 내 해석: 약점 1과 후속 제안 1로 읽는 이 논문의 실제 가치

내가 이 논문을 높게 보는 이유는 LLM 라우팅의 가장 불편한 전제, 즉 인도메인 학습 데이터가 이미 있다는 가정을 정면으로 치웠기 때문이다. 많은 라우터 논문이 모델 선택 성능만 비교할 때는 화려하지만, 실제 서비스 시작점으로 돌아가 보면 가장 먼저 막히는 것은 라우터 구조가 아니라 학습 로그 수집 비용이다. 이 논문은 그 출발점을 데이터 합성으로 바꾸고, 합성한 task taxonomy를 다시 라우터의 잠재변수로 넣어 구조적 일관성까지 확보했다는 점에서 설계가 상당히 잘 맞물린다. 다만 내가 보는 가장 큰 약점은 task taxonomy가 결국 seed domain과 single-task annotation 방식에 의존한다는 점이다. 실제 사용자 질의는 하나의 difficulty node로 정리되지 않는 혼합형 요청이 많고, 서비스가 커질수록 taxonomy drift도 빨라질 가능성이 높다. 그래서 내가 후속 연구로 가장 보고 싶은 것은, 배포 후 소량의 실제 질의를 받아 taxonomy posterior를 온라인으로 갱신하고, uncertainty가 높은 질의만 stronger advisor model로 넘기는 hybrid active-routing loop다. 그렇게 되면 이 논문의 cold-start 장점과 실제 운영 중 적응성이 더 자연스럽게 연결될 것 같다.

또 하나 흥미로운 연결점은 이미 다뤘던 [arXiv 2604.02319] 샘플 다양성 라우팅과의 대비다. 그 글이 “질의마다 무엇을 최적화할 것인가”를 diversity로 바꿨다면, 이 논문은 “질의마다 누구를 고를지 배우기 위한 데이터를 어디서 얻을 것인가”를 cold-start synthetic supervision으로 바꾼다. 나는 실제 서비스에 붙인다면 strongest model을 항상 전면에 세우는 advisor-model-orchestration보다 먼저, 이런 query-level router를 얇게 깔아 기본 분기부터 안정화할 것 같다. 그래야 비싼 모델을 조언자로 쓸지 실행자로 쓸지에 대한 후속 정책도 더 작은 비용으로 실험할 수 있기 때문이다.

9. 결론: cold-start 라우팅을 학습 가능한 문제로 끌어내린 설계

이 논문이 남기는 가장 큰 성과는 LLM 라우팅을 더 영리하게 만든 것보다, 인도메인 로그가 없는 시작점에서도 라우터를 배울 수 있다는 사실을 설계 수준에서 보여 준 데 있다. domain description에서 출발해 계층형 task taxonomy를 만들고, 그 taxonomy를 합성 QA와 latent task prior의 공통 축으로 다시 쓰는 구조는 생각보다 단단하다. cold-start에서 heuristic을 넘고, in-domain에서도 기존 회귀형 라우터를 계속 앞서는 결과는 이 구조적 선택이 단순한 전처리 꼼수가 아니라는 점을 뒷받침한다.

물론 taxonomy drift, judge bias, 복합 태스크 질의 같은 문제는 아직 남아 있다. 그럼에도 이 논문은 strongest model을 항상 기본값으로 두는 운영에서 한 단계 더 나아가, 질의 분포와 사용자 선호를 함께 고려하는 라우팅 계층을 콜드스타트부터 세울 수 있음을 보여 준다. 그래서 이 연구는 라우팅 리더보드의 한 칸을 채운 논문이라기보다, 멀티모델 서비스가 실제 제품으로 넘어갈 때 필요한 초기 정책층을 어떻게 만들지에 대한 꽤 실용적인 출발점으로 읽을 가치가 있다.

10. 요약 정리: 이 논문에서 기억할 핵심 포인트

• 핵심 문제정의: 이 논문은 “어떤 라우터가 더 정확한가”보다 “인도메인 로그가 없는 콜드스타트에서 라우터를 어떻게 학습할 것인가”를 정면으로 다룬다.
• 주요 아이디어: domain, subcategory, difficulty로 이뤄진 3단 taxonomy를 만든 뒤, 각 leaf task profile에 맞는 QA를 합성해 라우터 학습 데이터를 만든다.
• TRouter의 차별점: 질의에서 바로 비용과 성능을 회귀하는 대신, latent task type 분포를 먼저 추정하고 그 위에서 모델별 metric을 합성한다.
• cold-start 성과: traditional metrics 기준 utility sum이 0.5274~0.5382로, Adaptive LLM 0.4913과 cross-domain RouterDC 0.4676을 넘는다.
• judge 기반 성과: LLM-as-a-judge 기준 cold-start utility sum은 0.6551, in-domain은 0.6733으로 모두 최고를 기록한다.
• 샘플 효율: 30-shot이 기본이지만 5-shot 이하에서도 거의 최적에 가까운 성능을 보여, synthetic routing의 초기 도입 비용이 크지 않다.
• taxonomy 해석: cold-start에서는 coarse한 domain prior가 더 강할 수 있지만, in-domain 적응 후에는 fine-grained difficulty prior가 가장 높은 utility를 준다.
• 실용성: GPT-4.1과 Gemini-2.5-Flash를 합쳐 약 24.37달러로 3만 개가 넘는 synthetic QA supervision을 만들 수 있었고, 수작업 추정 비용은 6,000달러 이상이다.
• 한계와 다음 질문: seed domain 의존성, judge bias, 복합 태스크 질의 처리는 아직 남은 과제이며, 실제 서비스 로그를 이용한 online taxonomy update가 자연스러운 후속 방향으로 보인다.