로컬 AI 인프라 노트 (11/15) — qwen3의 thinking 모드를 끌 수 없다: MoE의 함정
벤치마크 최고 속도 모델이 실전에서 102초 걸린 이유와 모델 선택 교훈
핵심 요약
- qwen3:30b-a3b는 tok/s 최고 속도(37.7)였지만, thinking 모드를 끌 수 없어 "Say OK"에 102초 소요
- Modelfile 수정, 시스템 프롬프트, API 파라미터 모두 실패 — 모델 가중치 자체의 한계
- 최종 선택은 qwen3.5:9b — thinking 제어 가능하고 VRAM 9.2GB로 운영 안정적
배경
로컬 LLM 추론 속도 개선을 위해 벤치마크하던 중 qwen3:30b-a3b 모델을 발견했습니다. MoE(Mixture-of-Experts) 아키텍처로 총 30B 파라미터 중 3B만 활성화되며, tok/s가 37.7로 가장 빨랐습니다.
그러나 "Say OK"라는 단순한 요청에 102초가 소요되었습니다. 약 3,500개의 토큰이 모두 추론(reasoning) 용도로 소모된 것입니다.
본문
thinking 제어 3번의 시도, 3번의 실패
시도 1: Ollama Modelfile 수정 — <think> 태그 주입을 제거하려 했으나, 모델 가중치 자체가 추론하도록 학습되어 있어 무효.
시도 2: 시스템 프롬프트 억제 — "절대 thinking을 사용하지 마시오"라는 지시는 무시됨. 모델은 thinking 블록 내에서 추론 필요성을 다시 설명.
시도 3: API think:false 파라미터 — thinking 필드는 비워졌지만, 추론 텍스트가 content 필드로 이동했을 뿐 시간과 토큰 소모 동일.
qwen3 vs qwen3.5 비교
| 모델 | think:false 결과 |
|---|---|
| qwen3:30b-a3b | 제어 불가 |
| qwen3.5:9b | 정상 작동 |
| qwen3.5:35b-a3b | 정상 작동 |
Ollama 기본 템플릿의 이중 함정
Ollama의 기본 템플릿이 응답 생성 시 <think> 태그를 하드코딩으로 강제 주입하고 있었습니다. 모델 가중치의 추론 강제와 겹쳐 이중 함정을 형성합니다.
VRAM 불일치 함정
deepseek-v2:16b는 다운로드 크기 8.9GB이지만 실제 VRAM 점유 19.0GB. MoE 아키텍처는 라우터와 KV 캐시 오버헤드로 다운로드 크기보다 60% 이상 큰 메모리를 필요로 합니다.
최종 선택
| 모델 | tok/s | 응답 시간 | thinking 제어 | VRAM |
|---|---|---|---|---|
| qwen3:30b-a3b | 37.7 | 102초 | ❌ | 20.4GB |
| qwen3.5:35b-a3b | 18.3 | 6.2초 | ✓ | 26.3GB |
| qwen3.5:9b | 13.5 | 8.1초 | ✓ | 9.2GB |
시행착오 / 주의사항
- 끌 수 없는 기능의 위험성: thinking 모드는 모델의 강점이지만, 비활성화 불가하면 에이전트 시스템에서 독이 됩니다.
- tok/s ≠ 응답 시간: 빠른 생성 속도가 빠른 엔드투엔드 응답 시간을 보장하지 않습니다.
- 다운로드 크기 ≠ VRAM: MoE 모델은 실제 환경 로드 후
ollama ps로 실측이 필수입니다.
마무리
벤치마크에서 가장 빠른 모델이 실전에서 가장 느린 모델이 될 수 있습니다. 최고 성능 측정보다 실제 에이전트 태스크(도구 호출, heartbeat 응답)를 기반으로 벤치마크해야 합니다.
시리즈 전체 안내: 시리즈 목차
댓글
댓글 쓰기