Qwen3.8-Flash-Next (로컬) vs Claude 비교
Qwen3.8-Flash-Next (local) vs Claude
핵심 요약
로컬 환경에서 Qwen3.8-Flash-Next와 Claude를 코드 리뷰 성능으로 비교한 실험 결과입니다.
- 실험 환경 — 로컬 서버에서 Qwen3.8-Flash-Next와 Claude Code를 활용해 코드 리뷰 진행함
- 리뷰 성능 — Qwen은 모든 발견 사항이 정확했으나 Claude가 놓친 일부 로직 오류를 놓치기도 함
- 운영 팁 — 메모리 최적화와 템플릿 설정 등 로컬 구동 시 필요한 기술적 조치 공유함
- 결론 — 로컬에서 돌리기 좋은 신뢰할 만한 1차 리뷰어이나 최종 검증은 필수임
진심으로 감탄해서 내 경험 좀 공유해 본다.
Qwen3.8-Flash-Next (로컬) vs Claude Code의 Claude: 실제 커밋 하나로 리뷰 비교
내 저장소 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가 직접 헤드리스로 제어 (claude -p로 로컬 서버 지정, 읽기 전용 툴). 비교 대상인 Claude (Opus)는 Claude Code에서 먼저 블라인드 리뷰를 진행한 뒤, Qwen의 리뷰를 평가하게 함. 그래, Claude가 자기 경쟁자를 평가하는 거라 편향될 수 있다는 건 인정함. 근데 아래 결과는 전부 소스 코드랑 대조해 봤고, 중요한 건 Swift 재현 코드로 직접 확인했다.
결과: Qwen이 찾아낸 문제점 8개는 전부 진짜였고, 오탐은 0개였다. Claude가 놓친 거 2개도 잡아냄 (앱의 리콜 경로를 안 따르는 테스트 하네스랑, frontmatter "---"를 설명으로 인식해 버리는 마크다운 ingest). 반면 Claude가 찾은 것 중 5개는 놓쳤는데, 그중엔 제일 중요한 것도 있었음: 어간 추출된 단어랑 안 된 리스트를 비교하는 스톱워드 필터 문제인데, 덕분에 "this"나 "does" 같은 게 검색어로 그대로 새어 나감. 세부적인 거 2개도 틀림 (failable init의 정확한 폴백 동작이랑, 컬럼 카운트 몇 개 틀림). 심각도 조정이나 "확인 완료" 섹션은 괜찮았음. 파일 전체를 꼼꼼하게 읽고 모듈 경계까지 쫓아가는 게 마치 사람처럼 신중하더라.
비용: 53턴, 41분 소요, 컨텍스트는 약 110K 토큰까지 늘어남. 디코딩 속도는 4K 컨텍스트에서 약 21 t/s, 128K에서 약 14 t/s 나옴. 프리필은 520 t/s에서 시작해서 230 t/s까지 떨어짐. MTP는 64K까지는 약 1.5배 성능 향상이 있는데, 100K 넘어가면 오히려 손해임.
주의사항:
-
--lazy-mode를 꼭 켜라. 안 그러면 27 GiB짜리 n-gram 임베딩 테이블이 mmap 상태로 안 있고 램을 다 잡아먹음.
-
unsloth의 MTP 헤드가 llama.cpp에서 뻗어버림 (GGUF에서 MTP 레이어 압축률이 0이라 GGML_ASSERT in set_input_k_idxs 에러 뜸). 수정 브랜치: https://github.com/leok7v/llama.cpp/tree/qwen4exp/mtp-dense-no-indexer
-
Claude Code가 대화 중간에 시스템 메시지를 보내는데, Qwen 챗 템플릿이 이걸 처리 못 하고 에러 뱉음. 템플릿을 수정해서 시스템 턴으로 렌더링 되게 바꿔야 함.
결론: 밤새 로컬에서 돌려놓기 딱 좋은 믿음직한 1차 리뷰어임. 근데 수정하기 전에 메커니즘은 꼭 직접 확인하고, 미묘한 로직까지 완벽할 거라고 기대하진 마라. 커밋 하나 돌려본 거라 벤치마크라기보단 그냥 참고용 후기로 봐라.

