제가 새로운 모델들을 테스트하는 한 가지 방법은, (좋은 프롬프트를 사용하여) 고전 아케이드 게임인 Pacman의 단일 웹페이지 클론을 원샷 (one-shotting) 해보는 것입니다. 저는 보통 3번의 시도를 하고 그중 가장 좋은 결과물을 유지합니다. 지금까지 Anthropic, ChatGPT, Google 모델들을 포함한 모든 모델이 실패했으며, 대부분 처참하게 실패했습니다. 지금까지 가장 좋았던 것은 GLM 5.1이었습니다.

하지만 Qwen 3.6 27b F16으로 시도하기 전까지는 그랬습니다. 3번의 시도 중 2번이 압도적으로 훌륭했으며, 최고 결과물은 아주 미세한 오류만 있었습니다! 하지만 8bit 양자화 (quantisation)로 낮추자마자, 5번 이상 시도했음에도 불구하고 그 좋은 결과들을 재현할 수 없었습니다. 이는 제가 경험을 바탕으로 오랫동안 주장해 온 바를 보여줍니다. 대부분의 사람들이 손실이 없거나 거의 없다고 주장함에도 불구하고, 16bit와 8bit 양자화 사이에는 천지 차이가 존재합니다.

결과가 매우 좋았고, 마침 제가 저만의 양자화 모델로 llama.cpp MTP 추측적 디코딩 (speculative decoding) PR(당시에는 아직 병합되지 않음)을 테스트 중이었고, Qwen 3.5/3.6을 위한 저만의 고정된 Jinja 채팅 템플릿 (fixed jinja chat template)을 개발 중이었기에, Qwen 3.6 27b F16을 제대로 된 에이전트형 코딩 워크플로우 (agentic coding workflow)에 통과시켜 보면 어떨까 생각했습니다. 결과는 매우 훌륭했으며, 결과 자체가 모든 것을 말해준다고 생각합니다. 전체 단일 페이지 게임은 여기서 확인하실 수 있습니다:

https://guigand.com/pacman

배운 교훈 및 관찰 사항:

• 좋은 채팅 템플릿 (Chat Template)은 매우 중요합니다. 공식 채팅 템플릿은 vLLM만을 대상으로 설계되어 있어 다른 도구에서는 오류가 가득했고, 사용할 수 없는 수준이었습니다. 처음에는 커뮤니티 템플릿으로 시작했고 이는 개선된 형태였지만 여전히 많은 기이한 점(quirks)들이 있었습니다. 이것이 제가 공식 템플릿의 버그를 하나씩 수정하며 점진적으로 개선하기 시작한 이유입니다. 에이전트 세션(agentic sessions)의 초기 단계는 수많은 기이한 현상과 오류들 때문에 고통스러웠습니다. 하지만 점차 개선되었고, 템플릿을 잘 튜닝하고 나니 마치 모델의 새로운 지능 수준을 잠금 해제한 것 같은 기분이 들었습니다.

• MTP 투기적 디코딩 (Speculative Decoding)은 모든 작업에서 동일하게 가속화되지 않습니다. 기본적으로 코딩과 같은 결정론적 (deterministic) 작업에서 가장 효율적이며, 브레인스토밍과 같은 창의적인 작업에서는 효율이 가장 낮습니다. 이에 대해 이곳에 글을 작성했습니다: https://www.reddit.com/r/LocalLLaMA/comments/1t9gcar/mtp_benchmark_results_the_nature_of_the/ - 이번 Pacman 개발 과정에서, 저의 생성 토큰/초 (generative tok/s)는 작업에 따라 8 tok/s에서 18 tok/s 사이를 오갔습니다. 참고로, MTP가 없을 경우 동일한 모델과 양자화 (quant) 설정에서 6.6 tok/s를 기록했습니다.

• 모든 하네스 (harness)가 코드 품질뿐만 아니라 속도 측면에서도 동일한 것은 아닙. 대부분의 사용자는 코딩 하네스 (coding harness)가 품질에 엄청난 영향을 미친다는 것을 이미 알고 있으며, Claude Code는 골드 스탠다드 (gold standard)로 간주됩니다. 저 또한 일반적인 일상 코딩에는 이를 사용합니다. 이번 사례에서는 주로 채팅 템플릿 (chat template) 문제 때문에 Qwen CLI로 시작했습니다. Qwen LLM의 특성을 가장 잘 처리할 가능성이 높은 하네스는 그들 자신의 하네스일 것이라는 원칙 때문이었습니다. 실제로 저는 기분 좋은 놀라움을 경험했으며, Qwen CLI는 제 기대치를 훨씬 뛰어넘는 성능을 보여주었습니다! 후반 단계에서는 최종 채팅 템플릿이 그곳에서도 제대로 작동하는지 확인하기 위해 다시 Claude Code로 전환했습니다. 프로세스나 코드 품질의 개선은 감지되지 않았습니다. 하지만 제가 느낀 점은, Claude Code에서의 개발이 Qwen CLI보다 훨씬 느렸다는 것입니다! 이는 Claude Code 내부에 구축된 모든 추가 프롬프트 (prompts) 때문입니다. tok/s (초당 토큰 수)가 이렇게 느린 로컬 모델의 경우, 이는 사용 가능한 수준과 머리카락을 쥐어뜯고 싶을 정도의 경계선 사이의 차이를 만들 수 있습니다...

• 이 모델은 컨텍스트 관리 (context management)와 캐싱 (caching)이 매우 효율적입니다. 이를 방해하지 마세요. 매우 잘 작동하므로 그대로 두십시오. 캐시나 컨텍스트를 조작하는 스킬, 플러그인 등을 사용하지 마세요. 이는 모델을 혼란스럽게 만들고 훨씬 더 멍청하게 만들며 오류를 발생시키기 쉽게 만듭니다.

• 도구 호출 (tool calls), 컨텍스트 압축 (context compaction), 쉘 사용 (shell usage), 서브 에이전트 (subagents), 병렬 서브 에이전트 (parallel subagents)가 완벽하게 작동합니다. 처음에는 그렇지 않았으며, 채팅 템플릿 수정 및 개선을 통해 제대로 작동하게 만드는 데 오랜 시간과 많은 노력이 필요했습니다. 저는 실제로 테스트 목적으로만 컨텍스트 압축을 사용했으며, Claude Code에서 평소와 마찬가지로 문제없이 작동했습니다.

• 과도한 성능 저하 없이 높은 컨텍스트 (High context)를 사용할 수 있습니다. 최대 컨텍스트 크기는 256k 토큰인 것으로 알고 있습니다. 대부분의 경우 작업을 100k 미만으로 유지하도록 계획했지만, 150k를 약간 초과한 적도 몇 번 있었습니다. 성능이 약간 감소하는 것을 감지했지만, 그리 심각한 수준은 아니었습니다. 컨텍스트를 낮게 유지하려고 노력한 주요 이유는 다른 모든 모델과 마찬가지로 최상의 추론 (Reasoning) 능력을 얻기 위함이었으며, 컨텍스트 사용량이 늘어남에 따라 속도 또한 감소하기 시작했기 때문입니다.

• Gemini를 제외하고, 오디오 지식으로 저를 놀라게 한 첫 번째 모델입니다. 작곡가이자 음악가, 심리음향학자 (Psychoacoustic scientist), 그리고 오디오 엔지니어로서 저는 좋은 오디오에 많은 주의를 기울입니다. 이 경우, 저는 모델에게 고급 오디오 조작 및 생성 작업을 수행하도록 과제를 부여했습니다. 게임의 모든 오디오는 Qwen이 웹 오디오 신디사이저 (Web audio synthesizer)를 매우 고급스럽고 복잡한 방식으로 프로그래밍하여 만들어진 것입니다. 이것은 MIDI도 아니고, 단순한 웨이브테이블 (Wavetables)이나 샘플도 아닙니다. 배음 (Harmonics), 왜곡 (Distorsion), 레이어 (Layers), 다양한 효과 (Effects)를 사용하여 인간의 청각에 맞춰 조정된 심리음향적 특성을 고려합니다. 정말 인상적인 작업입니다. 유일한 예외는 'waka-waka' 소리로, 이를 위해 샘플을 사용하도록 해야 했습니다 (원작 아케이드 게임에서 사용된 것과 동일한 방식입니다).

• 느린 토큰 생성 속도도 감수할 수 있습니다. 이전에는 실용적인 개발을 위해 최소 70~80 tok/s가 필요하다고 생각했습니다. 하지만 이 모델은 사용 가능했으며, 병렬로 다른 일을 할 수 있는 시간을 주었을 뿐만 아니라 에이전트적 작업 (Agentic tasks)에 대해 더 잘 숙고할 수 있는 시간을 제공했습니다. 현재 저의 하드웨어로는 대규모 프로젝트에는 사용하지 않겠지만, 소규모에서 중규모 프로젝트에는 확실히 수용 가능한 수준입니다.

여기까지 읽으셨다면 여러분의 생각을 알려주세요. 게임을 즐겁게 즐기시길 바랍니다.

개발 환경: macOS, Apple Silicon M2 Max, 96GB RAM, OpenAI 및 Anthropic API 엔드포인트를 지원하는 llama.cpp 서버.