요약: Gemini 3.1 Flash-Lite가 GA로 공개되면서 고성능 모델을 무조건 호출하는 방식보다 “작은 모델로 먼저 분류하고 필요한 요청만 큰 모델로 보내는” 라우팅 패턴이 더 현실적인 선택이 됐습니다. Google 문서는 Flash-Lite를 저지연·저비용 멀티모달 모델로 설명하며, Gemini CLI도 task complexity를 분류해 Flash 또는 Pro로 보내는 패턴을 사용한다고 소개합니다.
Gemini 3.1 Flash-Lite 모델 페이지에 따르면 이 모델은 text, image, video, audio, PDF 입력을 지원하고 1,048,576 token input limit과 65,536 output token limit을 가집니다. Batch API, caching, code execution, file search, flex inference, function calling, search grounding, structured outputs, thinking, URL context도 지원합니다. 다만 Computer Use, image generation, Live API는 지원하지 않는다고 명시돼 있습니다.
이 스펙을 보면 역할이 분명합니다. 복잡한 추론을 끝까지 맡기는 모델이라기보다 고빈도·저비용 전처리 모델에 가깝습니다. 번역, 음성·문서 요약, 간단한 데이터 추출, 요청 분류, 라우팅, 정책 체크처럼 많이 호출되는 작업에 적합합니다. 특히 제품 트래픽이 커질수록 “작은 요청까지 비싼 모델로 보내는 낭비”가 커지기 때문에 라우팅 가치가 올라갑니다.
모델 라우팅은 간단합니다. 사용자 요청이 들어오면 먼저 Flash-Lite가 요청 복잡도를 판정합니다. 결과는 simple, standard, complex처럼 enum으로 받습니다. simple은 Flash-Lite 또는 Flash로 처리하고, complex는 Pro 계열로 보냅니다. 애매한 요청은 standard로 두고 비용·품질 데이터를 보며 조정합니다.
분류 기준은 구체적이어야 합니다. 단순 요청은 1~3개 단계로 끝나고, 외부 도구가 없거나 하나만 필요하며, 출력 형식이 명확한 작업입니다. 복잡 요청은 4개 이상 단계, 여러 도구 호출, 큰 코드베이스 분석, 모호한 요구사항, 전략 수립, 원인 분석, 민감한 의사결정이 포함된 작업입니다. 이 기준을 프롬프트에 적고 structured output으로 받으면 운영이 쉬워집니다.
분류기는 답변을 잘하는 모델이 아니라 “판정만 하는 모델”이어야 합니다. 프롬프트에는 역할을 좁게 줍니다. 예를 들어 “너는 task routing classifier다. 사용자의 요청을 읽고 SIMPLE 또는 COMPLEX 중 하나를 고른다. SIMPLE은 1~3단계, 명확한 입력, 낮은 위험이다. COMPLEX는 4단계 이상, 다중 도구, 높은 모호성, 코드 변경, 전략 판단이 필요하다. JSON으로 reasoning과 model_choice만 반환한다.” 정도면 충분합니다.
중요한 점은 reasoning을 길게 받지 않는 것입니다. 운영 분류기는 빠르고 싸야 합니다. reasoning은 한두 문장으로 제한하고, model_choice는 enum으로 검증합니다. 분류 결과가 파싱되지 않으면 안전하게 더 강한 모델로 보내되, 그 비율을 모니터링합니다. 파싱 실패가 많으면 프롬프트나 스키마가 복잡하다는 뜻입니다.
라우팅의 효과는 호출 비율로 계산합니다. 전체 요청 100만 건 중 70%가 simple이고, simple을 Flash-Lite로 처리할 수 있다면 큰 모델 호출은 30만 건으로 줄어듭니다. 여기에 캐싱과 Batch API를 섞으면 반복성 높은 문서 처리 비용도 더 내려갑니다. 다만 라우팅 모델을 한 번 더 호출하기 때문에 아주 짧은 요청에서는 오히려 손해일 수 있습니다.
따라서 첫 적용 대상은 고비용 워크로드입니다. 긴 문서 요약, 상담 티켓 분류 후 답변 생성, 코드 리뷰 우선순위 판정, RAG 질의 난이도 분류처럼 “분류 결과에 따라 뒤 호출 비용이 크게 달라지는 작업”부터 시작합니다. 단순 챗봇 짧은 응답처럼 뒤 호출 비용이 낮은 작업은 나중에 봐도 됩니다.
라우팅의 가장 흔한 실패는 어려운 요청을 쉬운 요청으로 잘못 분류하는 것입니다. 이를 막으려면 conservative routing을 씁니다. 애매하면 큰 모델로 보냅니다. 특히 결제, 법률, 의료, 계정 보안, 데이터 삭제, 배포 작업은 기본값을 complex로 둡니다.
두 번째 장치는 fallback입니다. 작은 모델이 답변을 생성했더라도 confidence가 낮거나 validation에 실패하면 큰 모델로 재시도합니다. 세 번째 장치는 sampling audit입니다. simple로 처리된 요청 중 1~5%를 큰 모델에도 보내 비교합니다. 사람이 전부 볼 필요는 없습니다. 출력 길이, 근거 일치, 사용자 평가, 후속 질문 비율을 비교하면 됩니다.
Flash-Lite는 이미지, 비디오, 오디오, PDF 입력을 지원하지만 모든 멀티모달 작업에 적합한 것은 아닙니다. 작은 텍스트 추출, 음성 메모 전사, PDF 요약은 좋은 후보입니다. 반대로 작은 글씨가 많은 이미지 분석, 복잡한 표 추출, 시각적 추론이 중요한 작업은 더 강한 모델이 필요할 수 있습니다. Gemini 3 문서에는 media_resolution이 token usage와 latency에 영향을 준다고 설명돼 있으므로, 이미지·비디오 처리에서는 해상도 정책도 함께 잡아야 합니다.
라우터가 modality를 고려하도록 만드는 것도 좋습니다. 입력이 text only인지, PDF인지, audio인지, image인지에 따라 기준을 조금 다르게 둡니다. 예를 들어 PDF 1장 요약은 simple일 수 있지만 200쪽 계약서 비교는 complex입니다. 이미지 1장의 alt text 생성은 simple이지만 여러 스크린샷에서 버그 원인을 찾는 작업은 complex입니다.
출처: Gemini API release notes, Gemini 3.1 Flash-Lite model page, Gemini 3 developer guide.
