로컬 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

시행착오 / 주의사항

  1. 끌 수 없는 기능의 위험성: thinking 모드는 모델의 강점이지만, 비활성화 불가하면 에이전트 시스템에서 독이 됩니다.
  2. tok/s ≠ 응답 시간: 빠른 생성 속도가 빠른 엔드투엔드 응답 시간을 보장하지 않습니다.
  3. 다운로드 크기 ≠ VRAM: MoE 모델은 실제 환경 로드 후 ollama ps로 실측이 필수입니다.

마무리

벤치마크에서 가장 빠른 모델이 실전에서 가장 느린 모델이 될 수 있습니다. 최고 성능 측정보다 실제 에이전트 태스크(도구 호출, heartbeat 응답)를 기반으로 벤치마크해야 합니다.

시리즈 전체 안내: 시리즈 목차

댓글

이 블로그의 인기 게시물

"LLM 핵심 학습 (1/6) — 기본: 토큰화·임베딩·어텐션·위치 인코딩"

"LLM 핵심 학습 (2/6) — 파인튜닝: LoRA·QLoRA·증류·Adapter"

"ML 기초 학습 (1/9) — 머신러닝과 sklearn: 학습의 좌표계"