Qwen 3.6 27B F16, 팩맨 코딩 테스트 통과했지만 8비트 양자화는 실패 — 템플릿과 MTP 추측 디코딩에 관한 핵심 교훈

r/LocalLLaMA의 한 개발자가 실용적인 코딩 벤치마크를 공유했습니다: 좋은 프롬프트로 단일 페이지 팩맨 클론을 한 번에 생성, 세 번 시도 중 최고를 선택. Qwen 3.6 27B F16은 두 번의 거의 완벽한 게임을 생성 — 성공한 최초의 로컬 모델. 그러나 8비트 양자화로 내리면 다섯 번 시도 후에도 좋은 결과를 재현할 수 없었으며, 이는 복잡한 생성 작업에서 8비트 양자화가 무손실이 아님을 주장을 강화합니다.

게시물의 주요 기술적 발견:

• 채팅 템플릿이 중요: 공식 Qwen 채팅 템플릿은 vLLM에 맞춰져 있으며 llama.cpp 및 기타 러너에서 오류가 있습니다. 작성자가 반복적으로 버그를 수정했고, 미세 조정 후 모델이 "새로운 수준의 지능"처럼 느껴졌습니다.
• MTP 추측 디코딩 속도는 작업에 따라 다름: 코딩과 같은 결정론적 작업의 경우 생성 tok/s는 8~18 tok/s (MTP 없는 기준: 6.6 tok/s)였습니다. 창의적 작업은 가속도가 덜합니다.
• 하네스 선택이 코드 품질보다 속도에 더 영향: Qwen CLI는 놀라울 정도로 잘 수행 — 출력 품질에서 Claude Code와 비슷했지만, Claude Code의 추가 프롬프트가 로컬 모델을 느리게 하므로 훨씬 빠릅니다. Qwen 3.6 27B와 같은 느린 모델(~6 tok/s)에서는 추가 프롬프트마다 고통스러운 지연이 추가됩니다.
• 컨텍스트 관리에 간섭하지 마세요: 모델의 네이티브 컨텍스트 캐싱 및 압축이 잘 작동합니다. 캐시나 컨텍스트를 조작하는 플러그인이나 도구는 모델을 혼란스럽게 하고 성능을 저하시킵니다.
• 도구 호출과 하위 에이전트는 적절한 채팅 템플릿 수정 후 완벽하게 작동합니다. 컨텍스트 압축, 셸 사용, 병렬 하위 에이전트 모두 예상대로 기능합니다.

작성자는 결과가 러너 구성에 크게 의존한다고 경고합니다: F16 가중치, 수정된 채팅 템플릿을 사용하고, 추론이 빠르지 않다면 무거운 하네스를 피하세요. 전체 플레이 가능한 팩맨 결과는 guigand.com/pacman에서 확인할 수 있습니다.