공개 사항: 저는 벤치마크 대상인 Lynkr의 유지 관리자이므로, 이 점을 염두에 두고 다음 내용을 읽어주시기 바랍니다. 완화 조치: 이 포스트의 모든 수치는 제가 아닌 RouterArena의 인프라에서 그들의 CI(지속적 통합, CI)를 통해 실행된 자동 평가 파이프라인에서 도출되었습니다. 여기에는 저희를 평범해 보이게 만드는 수치들도 포함되어 있습니다.

모든 LLM 라우터(LLM router)의 README — 저희의 것도 포함하여 — 는 동일한 주장을 합니다. 즉, 쉬운 쿼리(query)는 저렴한 모델로 보내고, 어려운 쿼리는 성능이 좋은 모델로 보내 품질을 저하시키지 않으면서 비용을 절감해 준다는 것입니다. 하지만 증거를 첨부하는 경우는 거의 없습니다. 존재하는 수치들도 벤더(vendor)가 직접 선택한 데이터셋과 베이스라인(baseline)을 바탕으로 측정된 자가 보고된 수치들뿐입니다.

따라서 RouteWorks 그룹에서 내놓은 LLM 라우터를 위한 개방형 표준 벤치마크인 RouterArena(논문, 리더보드)가 등장했을 때, 저희는 Lynkr를 제출했습니다. 이 포스트는 저희가 성적이 좋지 않았던 지표를 포함하여 무엇을 배웠는지에 대한 기록입니다. 왜냐하면 선택적으로만 인용하는 벤치마크 결과는 그저 단계가 하나 더 추가된 마케팅에 불과하기 때문입니다.

RouterArena가 실제로 측정하는 것

RouterArena는 9개 도메인과 44개 카테고리에 걸친 8,400개 이상의 쿼리를 세 가지 난이도 수준에서 라우터를 평가하며, 다섯 가지 축을 기준으로 점수를 매깁니다:

• Arena Score — 헤드라인 수치로, 정확도 대비 비용(accuracy-vs-cost)의 트레이드오프(tradeoff)를 결합한 값입니다.
• Accuracy (정확도) — 라우터가 선택한 모델이 정답을 맞혔는가?
• Cost (비용) — 실제 제공업체 가격 기준, 1,000개 쿼리당 평균 달러($) 비용.
• Optimality (최적성) — 오라클(oracle) 대비 세 가지 하위 지표: 얼마나 자주 가장 저렴하면서도 정답을 맞히는 모델을 선택했는가(Opt.Sel), 지출액이 최적에 얼마나 근접했는가(Opt.Cost), 그리고 정확도가 사용 가능한 풀(pool) 내에서 달성 가능한 최상에 얼마나 근접했는가(Opt.Acc).
• Robustness (강건성) — 동일한 쿼리를 사소하게 재표현(rephrasing)했을 때 라우팅 결정이 뒤바뀌는가?

지표보다 더 중요한 규칙이 하나 있습니다: RouterArena는 오직 평가 전용(evaluation-only)입니다. 해당 데이터나 레이블(labels)을 사용하여 훈련(trained), 적합(fitted), 또는 튜닝(tuned)된 모든 라우터 컴포넌트는 거부되며, 나중에 위반 사항이 발견되면 철회됩니다. 이 규칙을 명심하세요. 이 포스트의 마지막 부분에서 다시 언급됩니다.

우리가 제출한 것

우리는 Lynkr의 **튜닝되지 않은 프로덕션 기본값(untuned production default)**을 제출했습니다. 즉, 리포지토리(repo)에 포함되어 배포되는 것과 동일한 복잡도 점수 산출기(complexity scorer)와 계층 경계(tier boundaries)를 사용했습니다. 어댑터(adapter)는 ~70줄의 Python 코드로 구성되어 있으며, 각 쿼리를 라이브 Lynkr 인스턴스의 /routing/analyze 엔드포인트(endpoint)로 보내고 반환된 계층(tier)을 모델에 매핑합니다. 벤치마크 전용 코드 경로(benchmark-special code path)는 없습니다. 해당 엔드포인트는 라이브 프록시(live proxy)가 사용하는 것과 정확히 동일한 의도 점수 산출기(intent scorer)를 실행합니다 (로컬 임베딩(local embeddings) 사용, 라우팅 결정 자체에는 LLM 호출 없음).

모든 모델 풀(model pool)은 OpenRouter를 통해 구성되었습니다:

8,400개의 모든 쿼리를 실행하는 데 총 $2.46가 소요되었습니다. 이것이 전체 평가 비용이며, 이는 2026년 중반의 추론(inference) 가격이 어느 정도인지 그 자체로 시사하는 바가 있습니다.

결과

우리의 제출 PR에 대한 RouterArena의 자동 평가 결과는 다음과 같습니다:

공식 리더보드(우리의 제출 건 2026-07-23 병합됨)에서, 이는 중간 순위인 27개 라우터 중 15위에 해당합니다.

우리가 인용할 부분들

우리는 라우터로 사용된 GPT-5를 이겼습니다 — 비용은 34배 더 저렴하게. 리더보드에는 라우팅 베이스라인(routing baseline)으로서 GPT-5 자체가 포함되어 있습니다: GPT-5의 Arena Score는 쿼리 1K당 $10.02에서 64.32입니다. Lynkr는 쿼리 1K당 $0.29로 67.65를 기록했습니다. LLM 호출 없이 결정을 내리는 로컬 의도 점수 산출기(local intent scorer)가 프론티어 모델(frontier model)에게 라우팅을 요청하는 것보다 성능이 뛰어납니다. 이것이 바로 Lynkr가 구축된 핵심 논지(thesis)이며, 벤치마크 결과가 이를 뒷받침해주어 다행스럽게 생각합니다. 몇몇 잘 알려진 시스템들(RouterBench 베이스라인인 NotDiamond 57.29, RouteLLM 48.07) 또한 우리보다 낮은 점수를 기록했습니다.

Robustness(강건성) 92.38은 상위 5위권 수준입니다. 대부분의 리더보드 라우터들은 22에서 72 사이의 점수를 기록하는데, 이는 쿼리(query)가 재구성될 때 모델 선택이 빈번하게 바뀐다는 것을 의미합니다. Lynkr의 라우팅 결정은 92%의 확률로 재구성 후에도 유지됩니다. 사용자가 프롬프트(prompt)를 반복적으로 수정하는 인터랙티브 도구의 경우, 결정의 안정성(decision stability)은 정확도 몇 점보다 훨씬 더 가치 있을 수 있습니다. 대화 도중 문구만 바뀐 후속 질문을 다른 모델로 보내버리는 라우터는 결국 사용하지 않게 될 것이기 때문입니다.

우리가 차라리 숨기고 싶었던 부분들 (하지만 공개합니다)

Opt.Sel(최적 선택)은 10.97입니다. 우리 풀(pool) 내의 여러 모델이 쿼리에 올바르게 답변할 수 있는 상황에서, 우리는 약 11%의 확률로 가장 저렴한 정답 모델을 선택했습니다. Lynkr는 보수적으로 라우팅합니다. 즉, 확신이 서지 않을 때는 한 단계 높은 티어(tier)로 격상시킵니다. 이는 의도적인 라이브 서비스 편향(live-serving bias)입니다(잘못된 저렴한 답변은 불필요하게 좋은 답변이 비용을 소모하는 것보다 사용자의 신뢰를 더 많이 잃기 때문입니다). $0.29/1K라는 수치는 절대적인 지출이 낮게 유지됨을 보여줍니다. 하지만 오라클(oracle)과의 비교는 명확합니다. 우리가 챙기지 못한 비용 절감의 기회가 분명히 존재했습니다.

최상위권과의 정확도 격차는 실재합니다. Cross-Router가 78.14%의 정확도로 앞서고 있으며, 우리는 68.41%를 기록했습니다. 이 차이의 일부는 모델 풀(pool) 때문입니다(격상시킬 수 있는 프런티어 폐쇄형 모델 없이, 직접 호스팅 가능한 세 개의 오픈 웨이트(open-weight) 모델만 사용함). 하지만 일부는 진정으로 라우터 자체의 성능 차이입니다. 우리는 과장하지 않고 중간 순위에 위치하고 있습니다.

벤치마크를 통해 배운 점 — 그리고 왜 모든 것을 즉각 반영하지는 않을 것인가

실패 사례(failure cases)를 분석하는 것이 이번 과정에서 가장 가치 있는 부분이었습니다. 가장 명확한 패턴은 다음과 같습니다. 우리의 SIMPLE→MEDIUM 경계선이 보수적이라는 점입니다. 상당수의 쿼리가 경계선을 살짝 넘겨 점수를 받았고, 저렴한 티어 모델이 정답을 맞힐 수 있었음에도 중간 티어 모델을 할당받았습니다.

이에 따라 경계선을 조정한 프로토타입을 제작하여 로컬에서 약 10%의 하위 샘플(subsample)로 테스트를 진행했습니다. 결과는 Arena 점수 69.93, 정확도 71.07%, Opt.Sel이 약 11에서 약 66으로 급증했습니다. 임계값(threshold) 하나를 옮긴 것만으로 Arena 점수에서 2점의 이득을 얻었습니다.

해당 설정은 리더보드(leaderboard)에 절대 공개되지 않을 것입니다. 이는 RouterArena 자체의 실패 사례(failure cases)를 통해 진단된 것이며, 이는 바로 그들의 '평가 전용 규칙(evaluation-only rule)'이 방지하고자 하는 것, 즉 평가 데이터에 맞춰진 라우터(router fitted to the eval)의 전형적인 사례입니다. 리더보드에 등록된 항목은 튜닝되지 않은 기본값(default)이며, 그 상태를 유지합니다. 정직한 일반화(generalization) 주장은 훨씬 더 좁습니다. 벤치마크는 우리에게 _어떤 노브(knob, 조절 장치)_가 중요한지를 보여주었으며, 우리는 새로운 기본값을 그들의 데이터가 아닌 우리의 자체 트래픽(traffic)을 통해 검증할 것입니다.

만약 당신이 라우터를 관리한다면, 이것이 바로 함정입니다. 공개적인 벤치마크가 존재하는 순간, 그것에 맞춰 튜닝하고 싶은 유혹이 생기며, 그 방식으로 얻은 모든 점수는 실제 사용자들에게 전달되는 과적합(overfitting)의 점수가 됩니다.

적절한 판단을 돕기 위한 주의 사항 (Caveats)

• RouterArena는 단일 턴(single-turn) Q&A 방식의 평가입니다. Lynkr의 주요 워크로드(workload)는 멀티 턴(multi-turn) 코딩 에이전트(coding agents)이며, RouterArena는 이를 측정하지 않습니다. 에이전트 라우팅(agentic routing, 도구 호출 밀도 및 컨텍스트 축적)은 단일 프롬프트(prompt)를 분류하는 것과는 다른 문제입니다.
• 우리의 점수는 우리가 선택한 풀(pool)에 따라 달라집니다. 최상위 프런티어 모델(frontier model)이 포함된 풀을 사용한다면 양방향 모두에서 점수가 다르게 나타날 것입니다 (더 높은 천장, 더 높은 비용).
• 리더보드 순위는 변동됩니다. 이 스냅샷을 신뢰하기보다 라이브 리더보드를 확인하십시오.

만약 당신이 우리를 포함한 라우터들을 평가하고 있다면, 모든 벤더(vendor)에게 그들의 RouterArena 수치를 요구하십시오. 이를 얻는 데는 불과 몇 달러와 하나의 PR(pull request)이면 충분합니다. "제출하지 않았다"라는 답변 또한 하나의 답변이 될 것입니다.

링크: RouterArena 논문 (arXiv:2510.00202) · 리더보드 · 우리의 제출 PR · Lynkr