AI 모델 라우팅 설계: 비용·품질·지연시간으로 나누는 기준

AI 기능을 처음 붙일 때는 모델 하나로 시작하는 편이 자연스럽습니다. 연결할 엔드포인트가 하나이고, 프롬프트와 장애 대응도 한 경로만 보면 되기 때문입니다. 그런데 문서 분류처럼 답을 확인하기 쉬운 요청과 여러 자료를 엮어 판단해야 하는 요청을 같은 모델에 보내기 시작하면 비용과 응답 시간이 아깝게 느껴집니다.

여기서 모델 라우팅이 등장합니다. 요청의 성격에 따라 작은 모델과 상위 모델을 나눠 쓰는 방식입니다. 듣기에는 효율적이지만, 라우터가 틀리거나 재시도가 늘면 오히려 느리고 비싼 구조가 될 수 있습니다. 중요한 건 모델을 많이 붙이는 일이 아니라 어떤 요청을 어느 경로로 보냈는지 검증할 수 있게 만드는 일입니다.

먼저 판단할 것

작은 모델을 먼저 써도 되는지는 요청이 쉬워 보이는가보다 실패를 잡아낼 수 있는가로 판단하는 편이 안전합니다. 정답이나 형식을 검사하기 어렵고 실패 비용이 크다면 처음부터 상위 모델이나 사람 검토로 보내는 쪽이 낫습니다.

요청을 난이도와 검증 결과에 따라 서로 다른 크기의 AI 모델로 보내는 라우팅 구조

모델 라우팅은 자동 절약 버튼이 아닙니다

Microsoft Foundry의 Model Router는 프롬프트 특성을 분석해 지원되는 하위 모델 가운데 하나를 요청별로 선택하고, 애플리케이션에는 하나의 엔드포인트를 제공하는 방식을 설명합니다. 목표는 모든 요청에 가장 큰 모델을 쓰는 것이 아니라 품질과 비용 사이에서 적절한 선택을 만드는 것입니다.

다만 관리형 라우터와 애플리케이션이 직접 구현하는 단계적 승격은 구분해야 합니다. 관리형 라우터는 요청을 보고 모델을 선택합니다. 직접 만든 승격 경로는 작은 모델의 결과를 스키마나 업무 규칙으로 검사한 뒤 실패한 요청만 상위 모델에 다시 보낼 수 있습니다. 둘은 비슷해 보이지만 호출 횟수와 지연시간이 다릅니다.

호출량이 적고 작업 종류가 비슷하다면 단일 모델이 더 나을 수도 있습니다. 모델별 프롬프트와 평가 세트, 장애 경로를 따로 관리하는 비용이 절감액보다 커질 수 있어서입니다. 라우팅은 기본값이 아니라 요청량과 작업 편차가 커졌을 때 검토할 운영 선택지에 가깝습니다.

라우팅 기준은 요청 길이보다 실패 위험에 가깝습니다

짧은 질문이 반드시 쉬운 것은 아닙니다. 문장은 짧아도 이전 대화를 모두 이해해야 하거나, 권한과 결제처럼 틀렸을 때 피해가 큰 판단일 수 있습니다. 반대로 긴 문서에서도 정해진 필드만 뽑는 작업은 출력 형식을 기계적으로 검사하기 쉽습니다.

그래서 라우팅 기준은 작업 유형, 실패 비용, 검증 가능성을 함께 보는 편이 낫습니다. 분류·태깅·정형 추출처럼 성공 조건을 코드로 확인할 수 있는 작업은 작은 모델 후보가 됩니다. 외부로 발송되는 답변이나 모호한 분석, 권한 변경과 연결된 판단은 상위 모델 또는 사람 검토가 기본 경로가 되어야 합니다.

모델이 스스로 내놓은 확신 점수만으로 승격 여부를 결정하는 것도 불안합니다. 필수 필드 누락, JSON 스키마 오류, 근거 문서 부재, 금지된 도구 호출처럼 모델 밖에서 확인할 수 있는 신호를 우선하는 편이 좋습니다.

처음에는 규칙 기반 라우터로 충분할 수 있습니다

초기 라우터를 또 다른 AI 모델로 만들 필요는 없습니다. 요청 유형이 분류나 추출이면 작은 모델, 긴 문맥이나 복합 분석이면 상위 모델, 외부 발송이나 민감한 동작이면 사람 검토처럼 설명 가능한 규칙부터 시작할 수 있습니다.

작은 모델의 결과가 형식 검사를 통과하지 못하면 상위 모델로 승격합니다. 같은 유형에서 승격이 반복되면 처음부터 상위 모델로 보내도록 규칙을 고칩니다. 이 방식은 화려하지 않지만 어떤 판단 때문에 비용과 지연이 생겼는지 추적하기 쉽습니다.

요청 유형이 늘고 규칙이 서로 충돌하기 시작하면 분류기나 관리형 라우터를 검토할 수 있습니다. 그때도 기존 규칙과 평가 결과가 있어야 새 라우터가 실제로 나아졌는지 비교할 수 있습니다.

재시도까지 포함해도 더 싼지 계산해야 합니다

모델 단가만 비교하면 작은 모델이 늘 유리해 보입니다. 실제 요청 완료 비용에는 첫 호출뿐 아니라 형식 검증, 재시도, 상위 모델 승격, 라우터 호출, 사람 수정 시간이 들어갑니다. 작은 모델을 거친 요청 대부분이 상위 모델로 넘어간다면 두 번 호출한 만큼 지연도 늘어납니다.

완료 비용으로 비교하세요

첫 호출 비용에 재시도와 승격, 검증, 운영 비용을 더합니다. 같은 요청 세트에서 단일 모델 경로와 라우팅 경로를 나란히 실행해야 절감 여부를 판단할 수 있습니다.

OpenAI의 모델 선택 가이드는 먼저 평가 기준과 정확도 목표를 세우고 충분히 강한 모델로 기준선을 만든 다음, 더 작은 모델이나 프롬프트 개선으로 비용과 지연을 낮추는 순서를 제안합니다. 싼 모델부터 고른 뒤 품질 문제를 예외 규칙으로 메우는 접근과는 순서가 반대입니다.

평균 품질보다 잘못 낮춰 보낸 요청을 보세요

단순 요청이 대부분인 서비스에서는 평균 점수가 멀쩡해 보일 수 있습니다. 하지만 드물고 중요한 요청이 작은 모델로 잘못 들어가면 실제 위험은 평균에 가려집니다. 라우터 평가는 작은 모델에서 끝난 비율보다 어떤 요청을 잘못 낮춰 보냈는지를 중심으로 봐야 합니다.

작업 유형별 성공률, 상위 모델 승격률, 승격 후 복구율, 사람에게 넘어간 비율을 따로 기록하면 병목이 보입니다. 응답 시간도 평균만 보면 안 됩니다. 승격이 일어난 요청의 느린 구간을 따로 확인해야 사용자가 체감하는 지연을 알 수 있습니다.

OpenAI의 평가 가이드는 실제 사용 분포와 경계 사례를 반영한 작업별 평가를 권합니다. 공개 벤치마크가 높더라도 내 서비스의 출력 형식과 실패 비용을 대신 평가해주지는 않습니다. 모델이나 라우팅 규칙을 바꿀 때마다 같은 평가 세트를 다시 실행해야 합니다.

품질 승격과 장애 폴백은 다른 문제입니다

답변이 부족해서 상위 모델로 보내는 것과 공급자 오류 때문에 다른 백엔드로 보내는 것은 원인이 다릅니다. Azure API Management의 백엔드 풀과 회로 차단기 기능은 우선순위와 가중치, 백엔드 상태를 이용해 장애 경로를 제어합니다. 이는 답변의 의미를 평가해 더 강한 모델을 고르는 기능이 아닙니다.

작은 모델 검증 실패 시 상위 모델로 승격하고 인프라 장애는 별도 백엔드로 전환하는 흐름

로그에서도 품질 검증 실패, 타임아웃, 호출 제한, 서버 오류를 분리해야 합니다. 품질 문제와 인프라 문제를 한 종류의 폴백으로 묶으면 어떤 모델을 개선해야 하는지, 어느 공급자의 가용성을 보완해야 하는지 찾기 어렵습니다.

처음에는 검증 가능한 요청 하나만 분리해보세요

• 실제 요청을 유형별로 나누고 성공과 실패를 판정할 평가 세트를 만듭니다.
• 기존 단일 모델 경로를 품질과 완료 비용의 기준선으로 남깁니다.
• 형식 검사가 가능한 반복 작업 하나를 작은 모델로 옮깁니다.
• 애매하거나 위험한 요청은 상위 모델 또는 사람 검토를 기본값으로 둡니다.
• 라우팅 이유와 모델 버전, 재시도, 승격 결과를 함께 기록합니다.
• 승격률과 중요 요청 실패율이 높으면 분기를 넓히지 말고 되돌립니다.

모델 라우팅은 여러 모델을 쓰는 기술보다 경계를 관리하는 기술에 가깝습니다. 완료 비용과 품질이 실제로 개선되는 요청만 분리하고, 차이가 없다면 한 모델로 돌아가도 됩니다. 구조를 복잡하게 유지하는 것보다 측정 결과에 따라 분기를 지우는 판단이 더 실용적입니다.

참고 자료와 공식 안내 원문

• Microsoft Foundry Model Router 개념 문서
• OpenAI 모델 선택 가이드
• OpenAI 평가 모범 사례
• Azure API Management 백엔드 및 회로 차단기 문서

같이 읽으면 좋은 글

• vLLM이란? AI 서비스의 속도와 비용을 좌우하는 추론 서버
• AI 에이전트가 운영에서 망가지는 순간을 잡는 법
• RAG와 Fine-tuning의 차이: 최신 지식과 모델 행동을 나눠 보세요