호스팅 모델을 쓸 때는 API 키 하나 붙여넣으면 끝입니다. 로컬 모델은 다릅니다. 추론 엔진을 고르고, 모델을 고르고, 양자화 방식을 고르고, 채팅 템플릿을 설정하고, 컨텍스트 크기를 잡고, 여러 곳에 JSON 설정을 흩뿌리다 보면 어느 순간 결과가 이상해지거나 아예 작동을 안 합니다.
Flask 창시자이자 개발자인 Armin Ronacher가 자신의 블로그에 로컬 모델 생태계의 구조적 문제를 짚은 글을 올렸습니다. 모델 품질 때문이 아니라 스택 전체의 파편화와 완성도 부재 때문에 로컬 모델 경험이 나쁘다는 진단입니다.
출처: Pushing Local Models With Focus And Polish – lucumr.pocoo.org
“돌아간다”와 “잘 작동한다”는 다릅니다
로컬 모델 생태계의 대부분의 노력은 모델을 “실행 가능하게” 만드는 데 집중돼 있습니다. 필요한 일이지만, 완성된 경험과는 다릅니다.
Ronacher가 드는 대표적인 예가 툴 파라미터 스트리밍입니다. 호스팅 API는 텍스트뿐 아니라 툴 호출 파라미터도 생성되는 즉시 토큰 단위로 흘려보냅니다. 로컬 모델 대부분은 이걸 지원하지 않아서, 모델이 툴 호출을 완전히 끝내기 전까지 아무 응답도 오지 않습니다. 코딩 에이전트 환경에서 이 차이는 생각보다 큽니다.
- 아무 토큰도 오지 않으면 연결이 끊긴 건지, 모델이 처리 중인 건지 알 수 없습니다
- 에이전트가 백그라운드에서 어떤 명령을 만들고 있는지 보이지 않으니 중단할 타이밍을 잡을 수 없습니다
- 이미 스트리밍을 지원하는 API 스펙이 있는데 구현이 안 돼 있다는 점에서, 완성도의 문제입니다
토큰을 뱉어내는 것 자체는 빠르게 할 수 있지만, 끝에서 끝까지 경험을 괜찮게 만드는 건 훨씬 더 많은 공을 들여야 합니다.
파편화가 만드는 불투명한 실패
로컬 스택은 llama.cpp, Ollama, LM Studio, MLX, vLLM 등 수많은 엔진과 레이어에 걸쳐 있습니다. 각각이 훌륭한 프로젝트라는 건 사실이지만, 문제는 같은 모델을 써도 어떤 엔진, 어떤 설정 조합을 선택했느냐에 따라 실제 동작이 완전히 달라진다는 점입니다.
채팅 템플릿이 제대로 렌더링됐는지, reasoning 토큰이 의도대로 처리되는지, KV 캐시가 코딩 에이전트 워크로드에서 실제로 작동하는지, Hugging Face에서 올바른 양자화 모델을 골랐는지. 이 중 하나라도 어긋나면 결과가 나빠지지만, 어디서 문제가 생긴 건지 알기 어렵습니다.
결과적으로 사람들은 로컬 모델을 써보고 실망합니다. 모델이 나쁜 건지, 설정이 잘못된 건지, 엔진 버그인지 알 수 없으니 “로컬 모델은 별로”라는 결론으로 이어집니다. 모델에 대한 공정한 평가도, 완성된 제품 경험도 아닌 상태에서 말이죠.
임계 질량이 쌓이지 않는 이유
매주 새 모델이 나오고, 관심은 곧바로 다음 모델을 돌려보는 쪽으로 옮겨갑니다. 하나의 모델-엔진-에이전트 조합에 충분한 집중이 쌓이기 전에 다음 것으로 이동하는 사이클이 반복됩니다. 그러면 어떤 조합도 실제로 얼마나 좋아질 수 있는지 알아낼 기회를 얻지 못합니다.
Ronacher의 요점은 간단합니다. 호스팅 모델 제공자는 가중치 파일만 던져주고 나머지를 알아서 하라고 하지 않습니다. 로컬 모델도 같은 사고방식이 필요합니다. 하나의 모델, 하나의 서빙 경로, 하나의 에이전트. 툴 호출이 깨지면 제품 버그입니다. reasoning 스트림이 이상하면 제품 버그입니다. 어디서 실패했든 고쳐야 하는 버그입니다. 이 멘탈리티를 로컬 모델에도 적용해야 한다는 겁니다.
ds4.c와 pi-ds4가 시도하는 것
이 생각을 실제로 구현한 프로젝트가 Redis 창시자 Salvatore Sanfilippo가 만든 ds4.c입니다. 128GB 이상 RAM을 갖춘 Mac 전용, DeepSeek V4 Flash 전용 추론 엔진입니다. 범용 프레임워크가 아니라 이 모델과 이 하드웨어에 최적화된 단일 패키지입니다. Metal 경로, KV 캐시의 SSD 오프로드, 프롬프트 렌더링까지 하나의 엔진 안에 들어 있어서 MLX나 Ollama 없이도 작동합니다.
Ronacher는 여기서 한 발 더 나아가 코딩 에이전트 Pi에 ds4.c를 직접 내장한 pi-ds4 확장을 만들었습니다. 확장을 설치하면 양자화 선택부터 서버 시작, 사용 종료 후 종료까지 Pi가 알아서 처리합니다. 설정 노브를 일부러 제공하지 않은 이유도 여기 있습니다. 어떤 값이 최적인지를 자동으로 결정하는 방법을 먼저 알아내야 하기 때문입니다.
목표는 복잡성을 숨기는 게 아니라, 복잡성을 한 곳에 모아서 개선할 수 있게 만드는 것입니다.
왜 이 방향이 의미 있는가
로컬 모델이 호스팅 경험에 근접할 수 있는지를 알아내려면, 모든 하드웨어와 모든 모델을 동시에 지원하려는 시도보다 하나의 조합을 제대로 완성시키는 경험에서 배우는 게 먼저입니다. ds4.c와 pi-ds4 실험이 흥미로운 이유는 바로 그 ‘하나를 제대로’를 실제로 시도한다는 점입니다.
128GB Mac이라는 초기 제약은 분명 크지만, Ronacher의 관심은 그 장비를 가진 사람에게만 있는 게 아닙니다. 하나의 조합이 완성도 높게 작동하는 방법을 배우면, 그 학습이 다음 하드웨어 구성으로, 다음 모델로 이어질 수 있습니다.
참고자료:
답글 남기기