로컬 LLM 아저씨, OpenRouter에 패배하다

안녕하세요, 로컬 LLM 아저씨입니다.

GPU에 모델을 올린다.

Ollama로 구동한다.

vLLM으로 처리량(Throughput)을 낸다.

양자화(Quantization)해서 VRAM에 밀어 넣는다.

전부 내 손안에서 움직인다.

크으~ 이거지.

……라고 생각하던 시기가 있었습니다.

정신을 차려보니, Agent를 만들고 있어야 하는데 모델 뒷바라지를 하고 있었습니다.

우와, 추론(Inference)만 하고 싶은 건데 VRAM과 상담을 시작했다.

예전의 감각으로는, 로컬에서 돌릴 수 있는 것이 강점이었습니다.

API에 의존하지 않는다.

토큰 과금을 신경 쓰지 않는다.

데이터를 외부로 내보내지 않는다.

모델을 직접 선택할 수 있다.

오프라인에서도 작동한다.

그것이 제대로 된 구성이라고 생각했습니다.

물론, 지금도 이것이 틀린 것은 아닙니다.

기밀 데이터를 외부로 내보낼 수 없는 환경.

대량 배치(Batch)로 인해 과금이 부담되는 용도.

오프라인 요구사항이 있는 시스템.

특정 모델로 고정하고 싶은 기반.

그런 곳에서는 지금도 로컬 추론이 강력합니다.

다만, 개인 개발이나 PoC, Agent/RAG의 실험에서 똑같은 무게감을 가져가면 이야기가 조금 달라집니다.

실제로, trend-to-rule에서도 처음에는 로컬 모델을 사용하고 있었습니다.

vertical 판정, 즉 입력이 패션의 어느 영역에 관한 이야기인지를 추론하는 부분에 gemma3를 사용하던 시기가 있습니다.

그 후에 gemma4로 올렸습니다.

커밋 히스토리를 보면 제대로 남아 있습니다.

가벼운 판정이고, 로컬로도 충분할 것이라고 생각했다.

모델을 올리면 판정도 좋아질 것이라고도 생각했다.

하지만 진행하다 보니, 보고 있는 지점이 어긋나 있다는 것을 깨달았습니다.

gemma3에서 gemma4로.

모델을 올린다.

VRAM을 본다.

로드(Load) 시간을 본다.

양자화를 본다.

추론 속도를 본다.

보는 것이 늘어난다.

하지만 정말로 보고 싶었던 것은 vertical 판정의 정확도 그 자체가 아니었습니다.

그 vertical 판정이 후속 단계인 retrieval이나 reasoning의 토대로서 잘 작동하고 있는가였습니다.

우와, 모델을 올리고 있었는데 책임(Responsibility)은 어디로 간 거야.

로컬 모델을 올리면 판정 자체는 좋아집니다.

하지만 체감상 원했던 '개발로 돌아갈 수 있는 가벼움'은 생각만큼 오지 않았습니다.

모델을 바꿀 때마다 다시 로드한다.

VRAM의 여유 공간을 신경 쓴다.

다른 모델도 시험해보고 싶어진다.

양자화 정밀도를 비교한다.

추론 서버의 기동을 기다린다.

그리고 Agent 본체의 코드로 돌아올 때쯤에는, 처음에 무엇을 하고 싶었는지 조금 잊어버린다.

곤란했던 것은 모델의 벤치마크 점수가 아니었습니다.

모델을 교체할 때마다 발생하는 환경별 마찰이었습니다.

필요했던 것은 조금 더 똑똑한 로컬 모델이 아니라, 모델을 가볍게 교체할 수 있는 상태였습니다.

그래서 OpenRouter로 옮겼습니다.

지금은 메인 생성은 google/gemini-3-flash-preview를, 속성 추론 주변은 gemini-2.5-flash-lite를 사용하고 있습니다.

둘 다 API를 통해서입니다.

예전의 저라면 아마 이렇게 생각했을 겁니다.

'아니, 그건 직접 구축해야지.'

'API 과금이 무섭지 않아?'

'데이터를 외부로 내보낸다고?'

'로컬에서 재현할 수 없으면 불안하지 않아?'

하지만 옮겨보고 나서 알게 된 것이 있습니다.

모델이 설정 한 줄이 되었습니다.

OPENROUTER_MODEL=google/gemini-3-flash-preview

gemma3에서 gemma4로 올릴 때, 로컬에서는 VRAM과 로드 사이의 상담이었습니다.

OpenRouter에서는 문자열을 바꾸는 것뿐이 되었습니다.

시험해보고 싶은 모델이 있으면 인자(Argument)를 바꾼다.

맞지 않으면 되돌린다.

VRAM을 보지 않아도 된다.

로드를 기다리지 않아도 된다.

양자화를 선택하지 않아도 된다.

추론 서버의 기동을 기도하지 않아도 된다.

그만큼 Agent Runtime의 설계로 돌아갈 수 있었습니다.

OpenRouter로 옮겨서 또 하나 좋았던 점이 있습니다.

모델을 교체하는 것이 가벼워졌기 때문에, 모델을 바꿨을 때 무엇이 무너지는지를 관측할 수 있게 되었습니다.

로컬에서는 교체 자체가 무겁습니다.

그래서 그렇게 자주 시도할 수 없습니다.

하지만 인자를 바꾸는 것뿐이라면 몇 번이고 시도할 수 있습니다.

그리고 시도해보고 알게 된 것은, 모델을 바꿔도 책임의 분리(Separation of Concerns)는 유지된다는 것이었습니다.

vertical 판정을 gemma에서 gemini로 바꿔도, 판정 결과를 후속 단계에서 어떻게 사용할지에 대한 구조는 변하지 않습니다.

메인 생성 모델을 바꾸더라도, retrieval (검색) 을 evidence (근거) 로 취급하는 흐름은 변하지 않습니다.

무너지는 것은, 특정 모델의 습성에 맞춰 작성했던 부분뿐이었습니다.

모델을 전환하는 순간 모든 것이 무너진다면, 그것은 모델에 설계를 너무 많이 맡겼다는 뜻입니다.

전환해도 남는 것이 바로 설계였습니다.

우와, 또 똑같은 이야기로 돌아왔네요.

OpenRouter로 기울어진 것은, 로컬 추론을 부정하고 싶어서가 아니었습니다.

로컬에서 모델을 구동하는 지식은 지금도 필요합니다.

오히려 무엇을 외부로 넘기고 있는지 파악하지 못한다면, API 의존은 그저 블랙박스가 될 뿐입니다.

그래서 이해는 필요합니다.

하지만 이해하고 있는 것과, 매번 VRAM과 상담하는 것은 별개의 문제였습니다.

필요했던 것은 최강의 로컬 추론 환경이 아니었습니다.

모델을 가볍게 교체하면서, 설계 쪽에 집중할 수 있는 상태였습니다.

로컬 추론을 버린 것이 아니라, 모델을 돌보는 시간을 버린 것입니다.

정확히는 모델을 돌보는 시간을, 책임을 바라보는 시간으로 옮긴 것입니다.

gemma3.

gemma4.

Ollama.

vLLM.

양자화 (Quantization).

VRAM과의 상담.

대결해 주셔서 감사합니다.

로컬 LLM 아저씨, OpenRouter에 패배했습니다.

하지만 아마 이것은 나쁜 패배는 아닐 것입니다.

Agent를 만들고 있었을 텐데, 모델을 돌보고 있었습니다.

그로부터 드디어 모델을 인자 (Argument) 로 다룰 수 있는 환경으로 옮겨왔을 뿐입니다.

그리고 모델을 인자로 다룰 수 있게 되면, 재미있는 사실을 깨닫게 됩니다.

경량 모델이라도 생각보다 무너지지 않는 경우가 있습니다.

그것은 모델이 똑똑해서가 아니라, retrieval (검색) 이나 책임의 분리가 모델의 외부에서 발판이 되어주었기 때문일지도 모릅니다.

RAG 설계에 관한 이야기로서 제대로 쓴 것이 이 책입니다.

경량 LLM에서도 무너지지 않았던 이유를, retrieval (검색) 이 reasoning (추론) 의 발판이 되어주었다는 관점에서 쓰고 있습니다.

『검색 결과를 늘리기 전에 봐야 할 RAG 설계』

모델을 올리기 전에, 살펴봐야 할 곳이 있었다는 이야기입니다.