AI 라우팅 #1 — 큰 모델 하나면 되는데 작은 모델 넷으로 나눴다

오픈소스 LLM 을 여러 개 두고, 프롬프트 내용에 따라 분류해서 추론 모델 쪽에서 처리하게 하거나 코딩 모델 쪽에서 처리하게 하거나 디자인 특화 모델 쪽에서 처리하게 하는 기술을 봤다. AI 코드 어시스턴트를 직접 경험해보자는 생각이 들었다.

Open Table of contents

집 컴퓨터로는 안 됐다

집 컴퓨터는 GTX 1660 Super 를 쓰고 있어서 VRAM 이 너무 적었다. 맥북은 RAM 이 16GB 다.

RunPod 로 RTX 5090 을 대여하는 방법이 있는데, 그 전에 맥북에서 미니미한 모델을 여러 개 깔아서 라우팅하는 튜토리얼을 먼저 해보기로 했다.

AI 모델은 Athena Code 에서 쓰는 모델을 따라 고르려고 했다. 그런데 Devstral2 같은 모델은 가장 작은 것도 VRAM 공간이 많이 필요해서 작은 모델들로 다시 골라야 했다.

AI 에게 맥북 사양을 브리핑하고, 모델을 여러 개 올려야 하니까 한 모델당 5GB 내외로 잡았다.

사실 gemma4:12b 를 쓰면 모든 부분에서 월등하다. 그런데 AI 모델을 라우팅하는 것이 이번 프로젝트의 목표라서 위처럼 골랐다.

OLLAMA_MAX_LOADED_MODELS=1 ollama serve 를 하면 모델이 한 번에 하나씩만 올라간다.

AI 관련 프로젝트를 진행할 때 백엔드로 Python 의 FastAPI 나 TypeScript 를 많이 쓴다는 것을 알게 됐다.

로컬 장비에 대한 욕심이 생길 뻔했는데, 쓸만한 걸 사려면 최소 800만 원은 투자해야 할 것으로 예상된다. RunPod 가 많이 쓰이는 것 같다. 맥북에서 라우팅을 구현해보고 RunPod 에서 여러 모델을 돌려보고 싶다.

허깅페이스와 친해져야겠다는 생각을 했다.

분류기가 어떤 기준으로 나누는가 — 프롬프트를 보고 추론 · 코딩 · 비전 중 무엇으로 보낼지 정해야 하는데, 그 판단을 어떻게 시킬지가 이 프로젝트의 핵심이다. 분류기에게 프롬프트로 시키는 건지, 별도로 학습시키는 건지부터 봐야겠다
OLLAMA_MAX_LOADED_MODELS=1 의 대가 — 한 번에 하나만 올리면 메모리는 아끼는데, 모델이 바뀔 때마다 다시 로딩하는 시간이 들 것 같다. 라우팅은 모델을 자주 갈아타는 구조라 이게 얼마나 느려지는지 재봐야 한다 → Ollama FAQ
왜 FastAPI 나 TypeScript 인가 — 많이 쓴다는 것만 알았지 이유는 모른다. 스트리밍 응답이나 비동기 처리와 관련이 있는지 확인해보고 싶다
RunPod 비용 구조 — 800만 원짜리 장비를 사는 것과 빌려 쓰는 것의 손익분기가 어디쯤인지 계산해보면 판단이 선다
허깅페이스에서 모델 고르는 법 — 같은 모델도 양자화 수준에 따라 크기가 다른 것 같은데, 5GB 라는 제약에 맞춰 고르는 기준을 모르겠다 → Hugging Face: Models