에이전트가 하는 LLM 호출 중 정말로 최고 성능 모델이 필요한 건 몇 개나 될까요. LangChain이 측정해 보니 7%였고, 그 7%가 전체 청구액의 68%를 차지했습니다.
LangChain이 NVIDIA의 오픈소스 모델 라우팅 라이브러리 NeMo Switchyard를 자사 에이전트 평가 스위트에 물려 실측한 결과를 공개했습니다. 에이전트는 수많은 LLM 호출을 하는데, 대부분의 팀은 그걸 전부 같은 모델로 보내죠. 그런데 “이 파일 읽어줘” 같은 사소한 호출과 “이 테스트가 왜 실패하는지 알아내라” 같은 무거운 호출이 같은 값을 치르고 있다는 게 문제의 출발점입니다.
출처: How many of your agent’s calls actually need a frontier model? – LangChain
한 모델에 다 보내는 게 왜 문제인가
모델이 지금보다 싸고 성능 차이도 작던 시절엔, 모든 호출을 한 모델에 보내는 게 합리적인 기본값이었습니다. 지금은 상황이 달라졌죠.
프론티어 모델은 더 비싸고 강해졌고, 오픈웨이트 모델은 에이전트가 하는 일의 상당 부분을 감당할 만큼 빠르고 저렴해졌습니다. 그런데도 두 종류의 호출이 여전히 같은 모델, 같은 토큰 단가로 처리되죠. 얼마나 많은 호출이 진짜 비싼 모델을 필요로 하는지가, 라우팅이 이득인지 아닌지를 가르는 열쇠입니다.
라우팅이 하는 일, 그리고 그 대가
Switchyard는 각 호출을 살펴 미리 정해 둔 모델 풀 중 가장 적합한 곳으로 보냅니다. 프록시로 앞단에 두거나, 에이전트 안에 미들웨어로 넣어 쓸 수 있죠.
LangChain은 여러 방식 중 ‘LLM 분류기’를 에스컬레이션 모드로 측정했습니다. 흐름은 이렇습니다.
- 모든 작업을 저렴한 모델에서 시작합니다.
- 작은 판정용(judge) 모델이 완료된 턴마다 “제대로 가고 있는가”를 평가합니다.
- 연속으로 두 번 부정 판정이 나오면, 그 작업은 이후로 비싼 모델에 고정됩니다.
이렇게 한 번 올라가면 되돌아오지 않는 ‘일방향 문’ 구조라서, 판정 모델을 매 턴 돌리지 않아 라우팅 자체의 비용도 줄어듭니다. 측정에서 라우터가 프론티어 모델로 보낸 턴은 7%뿐이었고, 30B 규모 모델이 나머지 93%를 처리했죠. Nemotron 3.5 Lightning과 Claude Opus 4.8을 오가게 하니, Opus만 쓸 때보다 총비용이 74% 줄면서 정확도는 약 6점만 내주는 데 그쳤습니다.
언제 이득이고 언제 손해인가
LangChain이 강조하는 건 뛰어들기 전에 계산부터 해 보라는 것입니다. 공식은 단순하죠. 판정 비용을 두 모델의 가격 차로 나누면, 이득을 보기 위해 저렴한 모델로 넘겨야 하는 비율이 나옵니다.
두 모델의 가격이 비슷하면 이 값이 100%를 넘어갑니다. 그러면 저렴한 모델을 직접 호스팅하지 않는 한 라우팅으로는 본전을 뽑기 어렵습니다. 결국 라우팅은 ‘무조건 아끼는 마법’이 아니라, 내 워크로드의 호출 분포에 따라 이득이 갈리는 트레이드오프인 셈이죠.
해보려면
환경: NeMo Switchyard(NVIDIA 오픈소스 라이브러리). 프록시 또는 에이전트 내 미들웨어로 실행. LangChain 측정 조건은 자사 Deep Agents 스위트 145개 태스크(평균 6.3회 호출), Nemotron 3.5 Lightning ↔ Claude Opus 4.8 조합.
출발점: LLM 분류기를 에스컬레이션 모드로 설정(type = "llm_classifier"). 모든 작업을 저렴한 모델에서 시작하게 두는 게 핵심. 전체 설정은 원문 참고.
확인: 라우터가 프론티어 모델로 올려보낸 턴의 비율. LangChain 측정에선 7%였다. 이 비율과 비용 절감폭이 실제로 나오는지로 판단.
걸리는 지점: 두 모델의 가격 차가 작으면 판정 비용이 절감액을 잡아먹어 이득이 사라진다. 정확도 하락(측정에선 약 6점)을 감수할 수 있는 작업인지도 먼저 따질 것.
참고자료: Route AI Agents Across Models with NVIDIA NeMo Switchyard – NVIDIA Technical Blog
답글 남기기