저는 정말 깊은 인상을 받았고 제 경험을 공유하고 싶습니다. Qwen3.8-Flash-Next (로컬)와 Claude를 비교하며, Claude Code에서 실제 커밋 하나에 대한 코드 리뷰를 진행했습니다. 저는 리포지토리 https://github.com/leok7v/ChatOKF(Swift 기반 온디바이스 LLM 채팅 앱이며 약 48개 파일이 변경되었고, +1048/-102: 모듈 이동과 새로운 783줄 검색 하네스 포함)에 대해 동일한 코드 리뷰를 두 번 실행했습니다.
설정: llama-server에서 Qwen3.8-Flash-Next UD-Q4_K_XL (unsloth 사용), ROCm, AMD Strix Halo 128 GB, 262K 컨텍스트, MTP 드래프트 헤드를 사용했으며, Claude Code 자체에 의해 비헤드리스(headless)로 구동되었습니다 (Claude가 로컬 서버를 가리키는 -p 옵션과 읽기 전용 도구를 사용). 비교 리뷰어는 Claude Code의 Claude (Opus)였으며, 이 모델은 먼저 블라인드로 리뷰한 후 Qwen의 리뷰 결과를 코드를 기반으로 판단했습니다. 물론 Claude가 자신의 경쟁자를 심사하는 것은 편향성이 있을 수 있습니다. 아래 제시된 모든 발견 사항은 소스 코드와 대조하여 확인되었으며, 주요 내용은 작은 Swift 재현(repro)을 통해 검증되었습니다.
결과: Qwen은 8가지의 발견 사항을 제시했으며, 모두 실제 문제였고 거짓 양성(false positives)은 없었습니다. Qwen이 놓친 것 중 Claude가 찾아낸 두 가지 항목(앱의 리콜 경로를 따르지 않는 테스트 하네스, 프런트매터 "---"를 설명으로 가져가는 마크다운 인제스트)을 잡아냈습니다. 반면, Qwen은 Claude가 발견한 5가지 항목을 놓쳤는데, 그중 가장 중요한 것은 어간(stemmed words)과 비어간(unstemmed list)을 비교하는 스톱워드 필터로, 이 때문에 "this"와 "does" 같은 단어가 검색 용어로 누출되는 문제였습니다. 또한 두 가지 세부 사항도 잘못 파악했습니다 (실패 가능한 init의 정확한 폴백 동작 방식, 그리고 몇 개씩 차이 나는 컬럼 카운트). 심각도 보정(Severity calibration)과 "확인 및 정상" 섹션은 좋았습니다. 전체 파일을 읽고 신중한 인간처럼 모듈 경계를 추적했습니다.
비용: 53턴, 41분 소요되었으며 컨텍스트는 약 110K 토큰까지 증가했습니다. 디코딩(Decode) 속도는 4K 컨텍스트에서 약 21 t/s, 128K 컨텍스트에서 약 14 t/s였습니다. 프리필(Prefill)은 520 t/s로 시작하여 230 t/s까지 떨어졌습니다. MTP는 최대 64K까지 약 1.5배의 성능 향상을 제공하지만, 100K를 넘어서면 손실이 발생합니다.
주의 사항(Gotchas): --lazy-mode 옵션을 사용하세요. 그렇지 않으면 27 GiB n-gram 임베딩 테이블이 mmapped 상태로 유지되는 대신 RAM에 로드됩니다. unsloth의 MTP 헤드는 GGUF에서 MTP 레이어의 압축 비율이 0이기 때문에 llama.cpp를 충돌시킵니다 (GGML_ASSERT in set_input_k_idxs).
수정 브랜치(Fix branch): https://github.com/leok7v/llama.cpp/tree/qwen4exp/mtp-dense-no-indexer Claude 코드는 대화 중간에 시스템 메시지(system message)를 보내고, 이로 인해 Qwen 채팅 템플릿(chat template)에서 오류가 발생합니다. 템플릿을 오버라이드(override)하여 시스템 턴(system turn)으로 렌더링되도록 합니다. 평가: 밤새 사적으로 실행할 수 있는 신뢰할 만한 1차 검토자이지만, 행동에 옮기기 전에 그 메커니즘을 반드시 확인해야 하며, 미묘한 논리(subtle logic)에 대한 최종적인 결정으로 간주해서는 안 됩니다. 커밋 하나, 실행 한 번이므로 이를 벤치마크(benchmark)가 아닌 일화(anecdote)로 취급하십시오. 제출자: /u/leo-k7v [링크] [댓글]