---
title: "로컬 모델은 ‘돌아감’이 아니라 ‘제품처럼 동작함’까지 가야 한다"
published: 2026-05-08T23:57:17.000Z
canonical: https://jeff.news/article/2443
---
# 로컬 모델은 ‘돌아감’이 아니라 ‘제품처럼 동작함’까지 가야 한다

로컬 대규모 언어 모델(LLM)은 모델, 추론 엔진, 양자화, 템플릿, 컨텍스트 설정이 흩어져 있어 코딩 에이전트에서 제대로 평가하기조차 어렵다는 글이다. 저자는 DeepSeek V4 Flash 전용 추론 엔진 ds4.c와 Pi 확장 pi-ds4를 예로 들며, 범용성보다 한 조합을 끝까지 다듬는 접근이 필요하다고 주장한다.

- 저자는 로컬 모델이 진짜 잘됐으면 좋겠다고 말함. 이유는 단순함. 평균적인 개발자가 실험할 수 있어야 하니까.
  - 지금은 코딩 에이전트에서 로컬 모델을 고르면 5분 안에 호스티드 API로 돌아가고 싶어지는 경우가 많음.
  - 모델 자체가 나빠서라기보다, 그 모델을 실제 제품처럼 쓰게 만드는 주변 경험이 너무 덜 다듬어져 있다는 얘기임.

- 클라우드 모델은 지루할 정도로 쉽지만, 로컬 모델은 선택지가 너무 많음.
  - API 키를 붙여넣으면 끝나는 경험과 달리, 로컬은 추론 엔진, 모델, 양자화, 채팅 템플릿, 컨텍스트 크기, JSON 설정을 줄줄이 맞춰야 함.
  - 그중 하나만 어긋나도 모델이 조용히 멍청해지거나, 아예 동작하지 않음.

- 저자가 콕 집은 예시는 도구 호출 파라미터 스트리밍(tool parameter streaming)임.
  - 텍스트 토큰 스트리밍은 흔한데, 로컬 스택에서는 도구 호출 인자를 생성 중간에 보여주지 않는 경우가 많음.
  - 코딩 에이전트가 어떤 파일을 어떻게 고칠지, 어떤 셸 명령을 만들고 있는지 모델이 다 만든 뒤에야 보이면 이미 늦음.

> [!IMPORTANT]
> 로컬 모델이 5분 동안 아무 토큰도 안 내보내면 연결이 죽은 건지, 긴 도구 호출을 만들고 있는 건지 알 수 없음. 그래서 타임아웃을 늘리게 되고, 결국 타임아웃이 의미 없어지는 이상한 상황이 생김.

- 로컬 추론 생태계는 활발하지만 파편화가 심함.
  - llama.cpp, Ollama, LM Studio, MLX, Transformers, vLLM 등 훌륭한 프로젝트가 많지만, 조합에 따라 실제 동작이 크게 달라짐.
  - 채팅 템플릿, reasoning 토큰 처리, 도구 호출 포맷, 실제 컨텍스트 윈도, KV cache, 하드웨어 매칭, 사용량 스트리밍까지 전부 영향을 줌.

- 문제는 사람들이 로컬 모델을 공정하게 평가하지 못한 채 실망한다는 점임.
  - 설정이 어긋난 상태에서 나온 결과를 보고 ‘로컬 모델은 별로네’라고 판단하게 됨.
  - 에너지도 너무 많은 조합으로 흩어져서, 한 조합을 제품 수준까지 끌어올리는 힘이 쌓이지 않음.

- 저자는 ‘일단 하나를 골라서 끝까지 다듬자’고 제안함.
  - 모든 모델을 다 지원하려 하지 말고, 모델 하나와 서빙 경로 하나와 코딩 에이전트 하나를 묶어 제대로 만든 뒤 다음 조합으로 넓히자는 주장임.
  - 도구 호출이 깨지면 제품 버그, reasoning 스트림이 이상하면 제품 버그, 지연 시간이 말이 안 되면 제품 버그로 보고 끝까지 고쳐야 한다는 태도임.

- 그래서 ds4.c에 기대를 걸고 있음.
  - ds4.c는 살바토레 산필리포가 만든 DeepSeek V4 Flash 전용 추론 엔진임.
  - 맥 128GB 이상만 대상으로 하고, 범용 GGUF 러너나 프레임워크가 아니라 모델별 로딩, 프롬프트 렌더링, KV 처리, Metal 경로, 서버 API 접착, 테스트까지 포함한 좁은 패키지임.

- DeepSeek V4 Flash가 이 실험에 맞는 이유도 있음.
  - 로컬에서 흔히 쓰는 작은 dense 모델보다 충분히 크고, sparse 구조라 활성 파라미터 수 관점에서는 실행 가능성이 있음.
  - 큰 컨텍스트 윈도를 갖고 있고, ds4.c는 맥과 Metal만 노리기 때문에 코딩 에이전트 워크로드에 중요한 KV cache를 SSD로 옮기는 전략도 쓸 수 있음.

- 저자는 Pi 안에 pi-ds4 확장을 만들어 ds4.c를 직접 붙였음.
  - `pi install https://github.com/mitsuhiko/pi-ds4`로 설치하는 형태임.
  - 확장은 `ds4/deepseek-v4-flash`를 등록하고, 필요하면 런타임을 다운로드 및 빌드하고, `ds4-server`를 켜고, 장비에 맞춰 양자화를 고르고, 로그를 보여주고, 클라이언트가 없으면 watchdog으로 서버를 내림.
  - 지금은 일부러 노브를 거의 안 줌. 사용자가 튜닝하게 두기보다 자동으로 맞추는 법을 찾고 싶다는 의도임.

- 핵심 질문은 ‘로컬 모델이 돌아가냐’가 아님. 이미 돌아가는 건 다들 앎.
  - 진짜 질문은 고사양 맥에서라도 호스티드 제공자에 가까운 사용성을 만들 수 있느냐임.
  - 캐시, 도구 노출 방식, 코딩 에이전트 하네스, 지연 시간, 서버 수명주기까지 한 덩어리로 다듬어야 답이 나옴.

- 저자는 이게 접근성 문제이기도 하다고 봄.
  - 개발자에게 필요한 도구가 외국 데이터센터의 구독 서비스 안에만 갇혀 있으면 건강한 실험이 어렵다는 얘기임.
  - 물론 128GB 이상 맥이라는 시작점은 비싸고 제한적임. 그래도 공개된 한 조합에 사람들이 집중해 개선을 쌓는 게 중요하다고 봄.

---

## 기술 맥락

- 여기서 중요한 선택은 범용 로컬 추론 스택을 더 넓히는 게 아니라, DeepSeek V4 Flash와 맥 128GB 이상이라는 좁은 조합을 먼저 제품처럼 다듬는 거예요. 조합을 좁히면 채팅 템플릿, KV cache, 도구 호출 포맷 같은 애매한 문제를 ‘사용자 설정 문제’가 아니라 ‘제품 버그’로 다룰 수 있거든요.

- 코딩 에이전트에서는 일반 챗봇보다 스트리밍 품질이 훨씬 중요해요. 텍스트 답변이 늦는 건 참을 수 있어도, 어떤 파일을 고칠지나 어떤 명령을 실행할지 안 보이는 상태로 몇 분을 기다리면 사용자가 중간에 끊거나 잘못된 작업을 놓치기 쉬워요.

- ds4.c가 Metal과 맥만 노리는 것도 같은 이유예요. 하드웨어 범위를 좁히면 양자화 선택, 메모리 배치, SSD 기반 KV cache 같은 최적화를 더 공격적으로 할 수 있어요. 대신 리눅스나 엔비디아 GPU 사용자까지 한 번에 품으려는 범용성은 내려놓는 선택이죠.

- pi-ds4가 서버 빌드와 실행, 양자화 선택, 종료 감시를 자동화하는 건 로컬 모델의 복잡성을 숨기려는 게 아니에요. 복잡성을 한곳에 모아야 실제로 개선할 수 있기 때문이에요. 사용자가 매번 설정 파일을 뒤지는 구조에서는 같은 문제가 반복돼도 생태계 차원의 학습이 잘 안 쌓여요.

## 핵심 포인트

- 로컬 모델의 문제는 성능만이 아니라 설정과 통합 경험이 너무 거칠다는 점
- 도구 호출 파라미터 스트리밍 부재는 코딩 에이전트 사용성을 크게 망침
- ds4.c는 맥 128GB 이상과 DeepSeek V4 Flash에만 집중한 좁고 깊은 실험
- pi-ds4는 설치, 빌드, 서버 실행, 양자화 선택, 로그, 종료까지 자동화함

## 인사이트

로컬 모델 생태계가 계속 ‘새 모델 돌려보기’에 몰리면 실제 사용성은 안 쌓인다. 개발자에게 중요한 건 벤치마크 표보다 코딩 에이전트에서 5분 쓰고도 클라우드 모델로 안 돌아가게 만드는 완성도다.