목차
모든 요청을 최고 성능 모델 하나로 처리하는 것이 정말 최선일까요?
LLM을 서비스에 적용하는 것 자체는 이제 어렵지 않습니다. 하지만 운영 단계에 들어서면 대부분 비슷한 고민을 마주하게 됩니다.
최근 고객 미팅에서 가장 자주 들었던 질문도 여기에 있었습니다.
"LLM을 도입했는데 AI 사용 비용이 예상보다 빠르게 늘어난다."
"단순 번역이나 요약 같은 요청까지 항상 최고 성능 모델로 처리하고 있다."
"품질은 유지하면서 비용을 줄일 방법은 없을까?"
Technical Account Manager로써 다양한 생성형 AI 프로젝트를 지원하면서 반복적으로 들었던 질문도 결국 같은 곳으로 모였습니다. PoC에서는 큰 문제가 없었던 구조가 실제 운영 환경에서는 비용과 성능, 안정성까지 함께 고려해야 하는 과제로 바뀌는 것입니다.
중요한 것은 가장 좋은 모델 하나를 선택하는 일이 아닙니다. 요청 특성에 맞는 모델을 자동으로 선택하고, 이를 안정적으로 운영할 수 있는 구조를 만드는 것입니다.
이 글에서는 그 방법 중 하나로 Alibaba Cloud AI Gateway와 Model Studio를 활용하여 요청 난이도에 따라 모델을 자동 선택하는 Self-Routing Multi-LLM 구조를 구현합니다. 또한 인증(Authentication), AI Fallback, 운영 모니터링까지 포함한 실제 운영 구성을 콘솔 중심의 5단계로 살펴봅니다.
이 글에서 소개하는 Self-Routing은 하나의 정답을 제시하기 위한 것이 아닙니다. AI Gateway를 활용하면 이러한 운영 패턴을 어떻게 구현할 수 있는지를 보여주는 하나의 예시로 봐주시면 됩니다.
실제 서비스의 요청은 단순 FAQ부터 코드 생성, 복잡한 추론까지 난이도가 제각각입니다. 모든 요청에 최고 성능 모델을 쓰면 품질 차이는 미미한데 비용만 늘고, 경량 모델만 쓰면 어려운 질문에서 품질이 무너집니다. 여기에 같은 제품군 안에서도 경량 모델과 최상위 모델의 토큰 단가는 자릿수가 다릅니다. 난이도 분포를 반영하지 못하는 구조 자체가 비용을 만들어내는 셈입니다.
중요한 건 가장 좋은 모델 하나가 아니라, 적절한 모델을 적절한 요청에 쓰는 것입니다.
생성형 AI 서비스가 PoC를 넘어 운영 단계로 이동하면서, 하나의 LLM에 모든 요청을 보내기보다 여러 모델을 조합해 품질과 비용을 함께 관리하는 접근이 늘고 있습니다. 다음 네 가지가 널리 활용되는 운영 패턴입니다.
Model Routing도 판단 시점과 방식에 따라 여러 형태로 구현할 수 있습니다.
저비용 모델부터 호출하고 필요할 때 상위 모델로 승격하는 계단식 라우팅(Cascade Routing), 추론 전에 별도의 분류기가 요청 난이도를 판정하는 분류기 기반 라우팅(Classifier-based Routing), 질문의 의미나 의도를 분석해 태스크별 모델로 전달하는 의미 기반 라우팅(Semantic Routing) 등이 대표적입니다. 연구 사례로는 계단식 접근을 다룬 FrugalGPT와, 학습된 라우터로 모델을 선택하는 RouteLLM 등이 있습니다.
이 글의 Self-Routing은 계단식 접근에 가깝습니다. 별도의 분류 모델을 학습시키는 대신 Qwen-Flash가 답변과 함께 요청 난이도를 스스로 평가하도록 구성해, AI Gateway 설정과 간단한 애플리케이션 로직만으로 시작할 수 있도록 했습니다.
이러한 운영 방식은 특정 클라우드에 국한되지 않습니다. Alibaba Cloud AI Gateway 역시 라우팅, AI Fallback, 인증, 모니터링을 통해 이 패턴을 구현할 수 있도록 지원합니다.
지금까지 살펴본 방식들은 라우팅 판단을 어떻게 내리는가에 대한 것입니다. 이와 별개로 고려해야 할 아키텍처 관점이 하나 더 있습니다. 그 판단을 어디서 수행하는가입니다. 매니지드 서비스 내부일 수도, 게이트웨이 계층일 수도, 애플리케이션 안일 수도 있습니다. 7장에서 이 세 가지 방식과 각각의 운영상 트레이드오프를 비교합니다.
AI Gateway는 LLM 트래픽을 위한 관리형 게이트웨이입니다. 모델을 직접 실행하지 않고, 모델 운영을 담당합니다 — 추론은 Model Studio가, 인증·모니터링·장애 전환은 AI Gateway가 맡습니다.
Self-Routing 자체는 비교적 단순한 로직입니다. 하지만 실제 운영에서는 그 주변을 함께 고려해야 합니다. API Key 관리, 인증(Authentication), 로깅, Rate Limiting, 장애 대응까지 모두 애플리케이션에서 직접 구현하면, 오히려 라우팅 로직보다 운영 계층의 복잡성이 더 커질 수 있습니다.
이번 예제에서는 이러한 운영 기능을 AI Gateway가 담당하고, 애플리케이션은 Self-Routing 판단에만 집중하도록 역할을 분리했습니다.
필요한 기능은 다양하지만, 실제 구성은 대부분 콘솔에서 몇 단계만으로 완료됩니다. 4 장에서는 이를 직접 구성해 보겠습니다.
적용 서비스
(1) 사용자 → ECS: 사용자가 Streamlit 앱에 접속합니다. API Key는 전달되지 않습니다.
(2) Cascade Controller: Flash에게 난이도를 묻고 Plus/Max 승격 여부를 판단합니다. 애플리케이션의 유일한 핵심 로직입니다.
(3) AI Gateway: 모든 호출이 여길 통과하며, 인증·Pass-through·로깅·Rate Limiting 전담합니다.
(4) Model Studio: 실제 추론을 담당하며, Primary 오류 시 GLM으로 자동 전환합니다.
(5) SLS: model, token, 지연, fallback_from을 자동 기록합니다.
결국, 애플리케이션은 모델 선택이라는 비즈니스 로직에만 집중하고, 인증(Authentication), API 관리, 관측성, 장애 대응은 AI Gateway가 담당하도록 역할을 분리했습니다.
모든 요청은 먼저 Qwen3.7-Flash로 갑니다. Flash는 답변과 함께 난이도 점수·신뢰도를 함께 반환하도록 설계했습니다.
{
"answer": "...",
"difficulty_score": 0.72,
"difficulty_band": "medium",
"confidence_score": 0.91,
"reason_code": "..."
}difficulty_score가 0.4 미만이면 Flash 채택, 0.8 미만이면 Plus로, 그 이상이면 Max로 승격합니다. 별도 분류 모델 없이 Flash 스스로 난이도를 매깁니다.
def select_stage_for_score(score: float, config: CascadeConfig) -> str:
if score < config.plus_scoring.score_min or score > config.plus_scoring.score_max:
raise PlusParseError(f"difficulty_score out of range: {score}")
if score < config.thresholds.flash_upper_exclusive:
return "flash"
if score < config.thresholds.plus_upper_exclusive:
return "plus"
return "max"점수 하나만 믿으면 오판할 수 있어 안전장치 세 개를 더했습니다.
confidence_score가 min_confidence(0.70) 미만이면 점수가 낮아도 믿지 않고 상위 모델로 승격.sql, debug, legal, medical 같은 키워드가 있으면 채점 없이 바로 Max.def _hard_task_heuristic_triggered(self, question: str) -> bool:
if not self.cascade.self_route.hard_task_heuristics.enabled:
return False
normalized = question.lower()
return any(term in normalized for term in HARD_TASK_HEURISTIC_TERMS)모든 리소스는 Singapore(ap-southeast-1) 리전, 대부분 콘솔에서 구성했습니다.
인증, 로깅, 장애 전환까지 갖춘 게이트웨이인데, 필요한 건 아래 5단계, 구축까지 걸리는 시간은 단 20분이 전부였습니다.
Model Studio 콘솔에서 Workspace를 확인하고 API Key를 발급합니다. Workspace의 API Host와 사용할 Qwen 모델 ID, 단가를 함께 확인합니다.
https://{WorkspaceId}.ap-southeast-1.maas.aliyuncs.com/compatible-mode/v1 형식의 Workspace 전용 주소를 사용합니다.AI Gateway 콘솔에서 Create Instance를 클릭하여 인스턴스를 생성합니다.
Gateway가 요청을 전달할 Backend를 등록합니다. Service 메뉴에서 Create Service를 클릭합니다.
중요한 점은 Model Studio API Key가 Gateway에만 등록되고, 애플리케이션에서는 사용되지 않는다는 점입니다.
Model API 메뉴에서 Create Model API를 클릭하여 OpenAI-compatible API를 게시합니다.
여기서 가장 중요한 옵션은 Pass-through입니다. 활성화하면 애플리케이션이 요청 본문에 지정한 model=qwen3.7-flash / qwen3.7-plus / qwen3.7-max 값이 그대로 Model Studio에 전달됩니다. 덕분에 하나의 API Endpoint로 여러 모델을 사용할 수 있으며, Self-Routing이 성립하는 지점입니다.
마지막으로 애플리케이션이 사용할 Consumer를 생성합니다. Model API의 Consumer Authentication을 활성화(API Key 방식)하고, Consumer를 생성하여 해당 API에 Authorize합니다.
애플리케이션에서는 발급된 Consumer Key 하나만 사용합니다. Model Studio Key를 노출할 필요가 없으며, 키 폐기·교체도 콘솔에서 즉시 처리할 수 있습니다.
애플리케이션에서는 OpenAI SDK를 그대로 사용할 수 있습니다. 차이점은 Base URL을 AI Gateway로 변경하는 것뿐입니다.
client = OpenAI(
api_key="<CONSUMER_KEY>",
base_url="https://<AI_GATEWAY_DOMAIN>/v1"
)이후에는 일반 OpenAI API와 동일한 방식으로 호출하면서, model 값만 라우팅 결과에 따라 변경하여 전송합니다.
운영 환경에서는 모델 장애나 일시적인 오류도 고려해야 합니다. AI Gateway의 AI Fallback 기능을 사용하면 Primary 모델이 오류를 반환할 경우 Backup 모델로 자동 전환하도록 구성할 수 있습니다.
이번 예제에서는 Primary 모델로 Qwen을, Backup 모델로 GLM 5.2를 구성했습니다. 애플리케이션은 별도의 예외 처리 코드를 추가하지 않아도 되며, Gateway가 자동으로 Backup 모델을 호출합니다.
결과는 두 가지로 남습니다: 검수 결과 JSON, 그리고 SLS 로그의 fallback_from 필드입니다. 두개의 결과는 모두 GLM으로의 전환을 확인해줍니다.
장애 상황에서만 동작하는 보험이라, 평시 비용에는 영향이 없습니다.
AI Gateway는 호출 정보를 자동으로 SLS에 기록합니다. 로깅 코드 없이 아래를 바로 확인할 수 있습니다.
model)input_token, output_token)llm_first_token_duration)llm_service_duration)fallback_from)
이 글에서는 애플리케이션이 직접 난이도를 판단하는 방식을 택했지만, 라우팅 판단 자체를 서비스에 맡기는 접근도 있습니다.
AWS는 Amazon Bedrock Intelligent Prompt Routing을 2025년 4월 정식 출시했습니다. 하나의 서버리스 엔드포인트로 요청을 받아 같은 모델 패밀리 안에서 각 모델의 예상 응답 품질과 비용을 함께 고려해 라우팅합니다.
라우터를 만들 때 사용할 모델과 기준이 되는 fallback 모델을 지정하고, responseQualityDifference를 라우팅 기준으로 설정합니다. 애플리케이션이 개별 모델 대신 Prompt Router를 호출하도록 구성하면, 요청별 모델 선택을 관리형 서비스에 위임할 수 있다는 점이 장점입니다.
다만 공식 문서의 Considerations에 따르면 라우팅은 영어 프롬프트에 최적화되어 있고, 애플리케이션별 성능 데이터를 반영해 판단을 조정하지는 못하며, 라우팅 품질이 초기 학습 데이터에 좌우됩니다. 지원되는 모델 조합과 리전, 언어·유스케이스별 품질은 실제 워크로드로 사전에 검증하는 것이 좋습니다. 또한 도메인 특화 기준이나 세부적인 판단 근거가 필요한 환경이라면 관리형 라우터만으로 충분한지 함께 평가할 필요가 있습니다.
Alibaba Cloud AI Gateway는 게이트웨이 정책이나 애플리케이션 로직으로 라우팅 기준을 직접 설계하는 방식에 가깝습니다. 4장에서 사용한 Pass-through 외에 요청 비율이나 헤더 같은 요청 특성을 기준으로 정책을 구성할 수 있고, 2.1.15 버전 이상에서는 의미 분석으로 요청 의도를 분류해 적합한 모델로 전달하는 Intelligent Routing 기능도 제공합니다.
실무에서 이 셋은 배타적이지 않습니다. 게이트웨이로 관문을 잡고 그 위에서 애플리케이션이 Self-Routing을 하는 조합이 이 글에서 다룬 구성입니다.
각 제품의 기능과 지원 범위는 업데이트가 잦습니다. 반드시 도입 시점의 공식 문서를 최종 기준으로 확인하시기 바랍니다.
AI Gateway는 단순히 여러 LLM을 연결하는 프록시가 아니라, 인증(Authentication), 모델 라우팅(Routing), AI Fallback, 운영 모니터링을 통합 관리하는 운영 플랫폼입니다. Self-Routing 아키텍처와 함께 활용하면 비용 최적화와 운영 효율을 동시에 달성하면서도, 다양한 LLM을 안정적으로 서비스할 수 있는 기반을 마련할 수 있습니다.
이번 글에서는 Alibaba Cloud AI Gateway와 Model Studio를 활용해 질문 난이도에 따라 Qwen 모델을 자동 선택하는 Self-Routing Multi-LLM 아키텍처를 구현하고, AI Fallback과 운영 모니터링까지 포함한 실무 구성을 살펴보았습니다.
그리고 이 구조를 직접 확인해볼 수 있는 화면도 함께 만들었습니다. Max-only와 Cascade의 가격을 바로 비교하고, SLS 기반으로 모니터링·리포트까지 뽑아볼 수 있습니다. 또한 Qwen을 활용하여 모니터링·리포트를 분석하고 한눈에 쉽게 파악하실 수 있습니다.
아래 두 결과는 측정 조건이 다릅니다. 첫 번째는 개별 데모 요청에 대한 Cascade와 Max-only의 예상 비용 비교이고, 두 번째는 난이도별로 구성한 벤치마크 데이터셋을 사용한 누적 측정 결과입니다.
개별 데모 요청 비교
선택한 데모 요청에서는 Max-only 대비 약 70%의 비용 절감이 확인되었습니다. 요청 난이도와 최종 선택 모델에 따라 절감률은 달라질 수 있습니다.
벤치마크 누적 결과
벤치마크 데이터셋은 쉬움 20문항, 보통 50문항, 어려움 30문항의 총 100문항으로 구성했습니다. 전체 100문항을 Max-only와 Cascade 방식으로 각각 실행했을 때, 본 테스트 환경에서는 Cascade가 약 45% 낮은 비용을 기록했습니다. 이 수치는 사용한 프롬프트, 모델 가격, 응답 길이, 라우팅 임계값에 따른 실험 결과이며, 모든 워크로드에서 동일한 절감률을 보장하지는 않습니다.
SLS Logs Operation Anlysis Images: (24hours)
실제 환경에 맞게 라우팅 정책과 모델 구성을 조정해 보시고, AI Gateway의 다양한 기능을 활용하여 안정적이고 효율적인 LLM 서비스를 구축해 보시기 바랍니다.
지금까지 Alibaba Cloud AI Gateway와 Model Studio를 활용한 Self-Routing LLM 아키텍처 구현에 대해 알아보았습니다. 더 많은 내용이나 특정 사용 사례에 대한 상세 정보가 필요하시다면 추가로 문의해 주시면 감사하겠습니다.
Alibaba Cloud
Hosung Kim | Sr.Technical Account Manager
4 posts | 1 followers
FollowJJ Lim - December 31, 2021
Regional Content Hub - December 10, 2025
JJ Lim - December 3, 2021
Junho Lee - June 15, 2023
Regional Content Hub - April 15, 2024
Regional Content Hub - March 20, 2024
4 posts | 1 followers
Follow
Token Plan
Build more, spend less. One plan, every modality.
Learn More
Qwen
Full-range, open-source, multimodal, and multi-functional
Learn More
Alibaba Cloud Model Studio
A one-stop generative AI platform to build intelligent applications that understand your business, based on Qwen model series such as Qwen-Max and other popular models
Learn More
AgentBay
Multimodal cloud-based operating environment and expert agent platform, supporting automation and remote control across browsers, desktops, mobile devices, and code.
Learn More