M4 Max 로컬 LLM 5종 4시간 라우팅 — supergemma4를 1순위에서 뺀 이유
supergemma4를 strict JSON 1순위에서 뺐다. M4 Max 128GB에 ollama로 5종을 4시간 돌린 결정이다.
빠르다는 평판은 형식 오염 앞에서 무력했다. 응답 앞에 JSON: 프리픽스가 붙고 중간에 <channel|> 태그가 들어가니 파서가 깨진다. 같은 워크로드에서 gemma4:26b는 10.7초로 형식을 지켰다.
각 측정은 1회씩이다. 다시 돌리면 결과가 달라질 수 있다. 그래서 1순위/2순위 대체 구조를 뒀다.
TL;DR
- supergemma4를 strict JSON·한국어 1순위에서 뺐다 (형식 오염)
- gemma4:26b가 한국어·정형 출력 1순위로 승격
- gpt-oss:120b가 추론 24.1초로 qwen3.6:35b(33.9초)보다 빨랐다
시작점
M4 Max에 ollama 모델을 8개 올려놨는데 어떤 작업에 어떤 모델을 써야 할지 매번 헤맨다. “빠른 모델”이라는 평판만 듣고 supergemma4를 골랐다가 출력이 깨진다. 35B 모델보다 120B 모델이 더 빠르다는 결과를 본다.
세 번 다 내 케이스다. 4 워크로드를 정해서 5종을 돌렸다.
| 모델 | 크기 |
|---|---|
| qwen3.6:27b | 27B Dense |
| qwen3.6:35b-a3b-q8_0 | 35B MoE A3B |
| gemma4:26b | 26B Dense |
| supergemma4:26b | 26B 파인튜닝 |
| gpt-oss:120b | 120B Sparse MoE |
검색용 임베딩 3종(nomic-embed-text, qwen3-embedding:4b, openai/text-embedding-3-small)은 별도 분리.
워크로드 4개:
- Strict JSON 분류 (포맷 준수)
- 한국어 재작성 3문단 (언어 품질)
- 디버깅 off-by-one 버그 (코드 추론)
- 다리 건너기 단계 계획 (논리 추론)
같은 프롬프트, 같은 시스템 프롬프트, ollama 콜드 로드 후 두 번째 호출 기준.
supergemma4를 1순위에서 뺀 이유
strict JSON 분류를 시켰다. 마크다운 금지, 다른 말 금지, JSON만 출력하라고.
gemma4:26b는 10.7초로 {"task_type": ...} 그대로 출력. 형식 준수.
supergemma4:26b는 응답 앞에 JSON: 프리픽스를 붙였고 중간에 <channel|> 태그가 들어갔다. JSON 파서로 받으면 깨진다.
한국어 작업도 같은 패턴. “on_message 이벤트 핸들러를 한국어로 설명해줘”라고 시켰을 때:
- gemma4:26b: 12.0초, 자연스러운 한국어 3문단
- supergemma4:26b: 2.3초로 빠르지만 첫 줄이 “First, use on_message to trigger actions…”로 시작
속도 5배 차이는 대단하지만 한국어에 영어로 시작하면 다시 시킨다. 빠른 것의 의미가 사라진다.
확률적 모델이라 다시 돌리면 다른 결과 가능. 그래도 엄격한 스키마와 한국어가 필요하면 supergemma4를 1순위에서 뺀다. 다음 측정에서 결과가 달라지면 결정도 바꾼다.
전부 빼는 건 아니다. 빠른 거친 초안, 임시 메모 분류, 가벼운 키워드 추출 같은 후처리 가능 워크로드에서는 속도가 자산이다. 역할만 줄였다.
운영 프리셋
위 측정과 디버깅·추론 결과를 종합한 라우팅 표다. 1순위가 실패하면 2순위로 대체한다.
| 역할 | 1순위 | 2순위 | 근거 |
|---|---|---|---|
| 기본 / 일반 대화 | qwen3.6:27b | gemma4:26b | 균형 |
| 한국어 글 / 문장 정리 | gemma4:26b | qwen3.6:27b | 한국어 자연스러움 |
| Strict JSON / 정형 출력 | gemma4:26b | qwen3.6:27b | 형식 준수 |
| 빠른 거친 초안 | supergemma4:26b | gemma4:26b | 속도 |
| 코드 디버깅 / 설명 | qwen3.6:27b | qwen3.6:35b-a3b-q8_0 | 정확도 (off-by-one 77초로 정확히 잡음) |
| 복합 추론 / 긴 분석 | qwen3.6:35b-a3b-q8_0 | gpt-oss:120b | 추론 |
| 최고 난도 추론 | gpt-oss:120b | qwen3.6:35b-a3b-q8_0 | 의외로 빠름 (아래 참고) |
| RAG / 임베딩 | nomic-embed-text | qwen3-embedding:4b | 검색 전용 |
이 프리셋을 ~/.claude/CLAUDE.md나 OpenClaw 설정에 박아놓으면 라우팅이 자동화된다. 매번 “어떤 모델 쓸지” 결정 비용이 없어진다.
참고: 120B가 35B보다 빨랐다. 같은 추론 문제(다리 건너기 단계 계획)에서 qwen3.6:35b-a3b-q8_0가 33.9초, gpt-oss:120b가 24.1초였다. 둘 다 정답인데 파라미터 4배 차이에서 속도가 역전됐다. 가설은 sparse MoE 활성 파라미터가 120B 전체가 아니라는 것. 다음 측정에서 토큰 처리량으로 검증한다. 어려운 추론에 gpt-oss:120b를 일단 시도해볼 만하다는 운영 take-away는 챙긴다.
정리와 FAQ
가장 중요한 결론은 “내 환경에서 측정한다”는 것이다. 모델 평판이나 이름값보다 워크로드 결과가 우선이다. 측정이 1회면 1회로 명시하고, 더 강한 결정엔 더 많은 측정이 필요하다.
다음에 검증할 것:
- 토큰 처리량 직접 측정 (왜 120B가 35B보다 빨랐는지)
- 1주일 운영 후 라우팅 적중률 (별도 글 예정)
- 클라우드 모델과 작업별 매칭 (Claude Code 모델 선택법과 비교)
라우팅 결정은 한 번 내리면 끝이 아니다. 다음 측정으로 흔들리면 그게 진짜 측정 기반이다.
Q. supergemma4를 완전히 안 쓰는 게 맞나?
아니다. 빠른 초안·메모 분류 같은 후처리 가능 워크로드에는 유용하다. 1순위에서만 뺐다.
Q. M4 Max 128GB가 아니면 gpt-oss:120b 못 돌리나?
못 돌린다. 120B는 메모리 80GB+ 필요. M3 Max 64GB나 M4 Pro 36GB는 35B까지가 한계다.
Q. n=1 측정으로 결정한 게 신뢰할 만한가?
부분적으로만. 대체 구조를 둔 이유다. 추가 측정으로 1순위/2순위가 흔들릴 수 있다.
관련 글
- 맥 스튜디오 M4 Max 128GB 로컬 LLM 4개 속도 비교 — gemma4·llama3.3·qwen3 실측 (시리즈 #1)
- ChatGPT Plus 쿼터 터져도 작업 안 끊기는 법 — 3층 LLM 대체 체인 (시리즈 #2)
- Claude Code 모델 선택법 — 작업 유형별 정답 (Opus 4.7 업데이트) (Cloud 짝 글)
측정 환경: Mac Studio M4 Max 128GB · ollama 0.5.x · 각 1회 wall-clock · 콜드 로드 후 두 번째 호출 · 동일 시스템 프롬프트 · temperature 기본값.
태그: #로컬LLM #M4Max #ollama #qwen3 #gemma4 #gptoss #모델라우팅
댓글
댓글 쓰기