모델 라우터가 교체 경로를 만들어주지는 않는다

결론부터. NVIDIA NeMo가 LLM 라우터를 Apache-2.0으로 공개했다. 쓸 만해 보이는데, 라우터를 넣는다고 교체 경로가 생기지는 않는다. 순서가 반대다.

무엇이 나왔나

Switchyard는 모든 요청을 비싼 모델에 맡기는 대신 그 작업을 처리할 수 있는 더 저렴한 모델을 고르는 라우터다. OpenAI Chat Completions/Responses와 Anthropic Messages 형식을 지원해서, 기존 클라이언트의 연결 주소를 프록시로 바꾸면 요청별로 다른 모델을 쓸 수 있다.

설계에서 눈에 띄는 게 두 개 있다.

Stage Router는 도구 실행 이력에서 오류, 반복되는 시도와 실제 수정 진행을 살펴 탐색·오류 복구에는 강력한 모델을, 정형적인 작업에는 저렴한 모델을 배정한다. 기본적으로 추가 LLM 호출 없이 판단하며, 판단이 모호할 때만 LLM 분류기를 사용하도록 설정할 수 있다.

(원문)

추가 LLM 호출 없이 판단한다는 부분이 중요하다. 라우팅 판단을 또 LLM에게 물으면 아낀 돈이 거기로 나간다. 그리고 Prometheus 지표에 라우팅 부가 비용이 따로 있다. 만든 쪽도 이 함정을 알고 있다는 신호다.

성숙도는 낮다. 1.0 이전이고, 핵심 라이브러리가 Beta, 모델 호출·변환과 실행 구성요소는 Alpha다. 독립 서버 switchyard-server는 프로덕션용이 아니라 데모·평가용이라고 명시돼 있다. 오늘 프로덕션에 넣을 물건이 아니다.

라우터는 층을 하나 더 만든다

이번 주에 교체 경로 얘기를 여러 번 썼다. 그래서 이런 도구가 반가운데, 반대편도 봐야 한다.

벤더 종속을 피하려고 넣은 층이 그 자체로 층이다. 라우터가 죽으면 전부 죽는다. 라우팅 규칙이 곧 운영 지식이 되고, 그건 다시 다른 데로 옮기기 어려운 자산이다. 3년 뒤에 누가 패치하나 하는 질문을 여기에도 똑같이 해야 한다.

Apache-2.0에 NVIDIA가 뒤에 있다는 건 나쁘지 않은 조건이다. 하지만 아직 1.0이 아니다.

먼저 할 것은 도입이 아니다

Switchyard를 쓰든 안 쓰든, 오늘 무료로 할 수 있는 게 따로 있다.

이 도구의 전제는 내 애플리케이션이 OpenAI나 Anthropic 호환 형식으로 호출하고 있고, 그 연결 주소를 한 곳에서 바꿀 수 있다는 것이다. 반대로 말하면 — 벤더 SDK를 코드 곳곳에서 직접 부르고 있으면 나중에 어떤 라우터를 가져와도 못 붙인다.

그러니 순서는 이렇다.

1. 호출부를 한 곳으로 모은다. 얇은 함수 하나면 된다. 모델명과 base URL이 설정에서 오게 만든다.
2. 모델명을 코드에서 뺀다. claude-...이나 gpt-...가 소스에 하드코딩돼 있으면 그게 종속의 실체다.
3. 그다음에 라우터를 검토한다. 1·2번이 돼 있으면 라우터는 나중에 언제든 끼울 수 있고, 안 돼 있으면 라우터를 사와도 못 쓴다.

1번과 2번은 반나절이면 되고 라이브러리 의존성도 안 늘어난다. 교체 가능성은 도구가 주는 게 아니라 내 코드 구조가 주는 것이다. 도구는 그 구조가 있을 때만 꽂힌다.

모르는 것

라우팅이 실제로 얼마나 아껴주는지 나는 모른다. 원문에 절감률 수치가 없고, 어차피 그건 워크로드에 달렸다. 정형 작업이 많으면 크게 아낄 테고 전부 탐색적이면 거의 못 아낀다.

그리고 저렴한 모델로 내려보낸 요청의 품질 저하를 무엇으로 측정할지가 이 종류 도구의 진짜 난제인데, 원문 요약만으로는 판단할 수 없었다. 도입을 검토한다면 절감액보다 이걸 먼저 봐야 한다.