M4 Max에서 Qwen 3.8 27B를 벤치마크했다 — 로컬 모델, 컨텍스트, 코딩 성능에서 배운 점들
원문 제목 — I benchmarked Qwen 3.8 27B on my M4 Max — here's what I learned about local models, context, and coding performance
📄 전문 번역
필자는 에이전틱 코딩 활용을 목표로 Ollama로 대형 모델을 로컬에서 구동하는 실험을 진행해 왔다. 벤치마크가 40 tokens/sec 같은 수치로 표시되는 것은 유용하지만, 코딩 에이전트가 8K, 16K, 32K 이상의 프로젝트 컨텍스트를 다룰 때 실제로 얼마나 기다리게 될지라는 정작 중요한 질문에는 답하지 않는다는 것을 깨닫고 직접 테스트에 나섰다. 테스트 환경은 MacBook Pro Apple M4 Max 36GB 통합 메모리, macOS 26.6.2, Ollama 0.34.4이며, 주요 모델은 Qwen 3.8 27B NVFP4/MLX 128K 구성 컨텍스트 medium thinking이었고, 비교를 위해 같은 27B 모델의 일반 Q4_K_M/GGUF 버전도 함께 테스트했다. Ollama 서버는 OLLAMA_FLASH_ATTENTION=1, OLLAMA_KV_CACHE_TYPE=q8_0, OLLAMA_NUM_PARALLEL=1, OLLAMA_KEEP_ALIVE=5m으로 대략 구성했다. Flash Attention은 컨텍스트가 커질수록 중요해지는 어텐션 비용을 줄이고, q8_0 KV 캐시는 전체 정밀도 대비 작업 컨텍스트의 메모리 사용량을 줄이며, NUM_PARALLEL=1은 동시 추론으로 측정이 흐려지지 않도록 요청을 하나씩 처리하고, KEEP_ALIVE=5m은 모델을 상주시켜 콜드 스타트와 웜 성능을 따로 살펴볼 수 있게 한다. 이런 설정이 결과를 바꿀 수 있으므로 로컬 모델 벤치마크는 단순한 모델과 컴퓨터의 조합이 아니다.
모델은 단어를 읽고 쓰는 것이 아니라 토큰이라는 작은 텍스트 조각을 다룬다. 흔히 말하는 40 tok/s는 모델이 매초 약 40개의 출력 토큰을 생성하는 디코드 속도를 의미한다. 필자의 MLX 모델은 웜 상태 반복 측정에서 디코드 약 40~41 tok/s, TTFT 약 3.5초, 프롬프트 처리 약 180~190 tok/s를 기록했는데, 27B 로컬 모델치고는 좋은 수치다. 그러나 모델이 답변을 쓰기 전에 입력을 먼저 읽고 처리하는 prefill, 즉 프롬프트 처리 단계가 존재한다. 코딩에서는 지시문, 시스템 프롬프트, 대화 기록, 소스 파일, 도구 결과, 빌드 오류, 문서, 이전 편집 등이 입력에 포함될 수 있고, 에이전트가 작업할수록 이 컨텍스트는 커진다.
컨텍스트 확장을 살펴보기 전에 일반 Q4_K_M 버전과 NVFP4/MLX 버전을 비교했다. 측정된 디코드 성능은 Q4_K_M/GGUF가 약 10.7 tok/s, NVFP4/MLX가 약 40~41 tok/s로 약 3.8배 차이를 보였다. Q4_K_M 모델이 고장 난 것은 아니지만 사용자 경험은 완전히 달랐고, 약 10 tok/s에서는 긴 코딩 응답 생성에 몇 분이 걸렸다. 실제로 MLX 미적용 모델에게 Next.js/Tailwind/Framer Motion 랜딩 페이지 제작을 요청했더니 전체 작업에 약 18분을 기다려야 했다. MLX는 Apple Silicon과 통합 메모리 아키텍처를 기반으로 설계된 Apple의 머신러닝 프레임워크로, 별도의 Qwen 아키텍처가 아니라 모델이 기기에서 표현되고 실행되는 방식의 일부다. 마찬가지로 NVFP4와 Q4_K_M은 서로 다른 Qwen 아키텍처가 아니라 가중치 형식, 즉 양자화 방식을 설명한다.
이어서 컨텍스트가 커질 때 어떤 일이 일어나는지 테스트했다. 작은 프롬프트만 테스트하는 대신 약 4K, 8K, 16K, 32K의 실제 입력을 사용했으며, 약 4K에서는 생성 시작 전 23.6초 대기, 프롬프트 처리 198 tok/s, 디코드 46.6 tok/s, 약 8K에서는 46.8초, 178 tok/s, 41.4 tok/s, 약 16K에서는 1분 30초, 176 tok/s, 30.8 tok/s, 약 30K에서는 3분 15초, 157 tok/s, 31.9 tok/s를 기록했다. 이 표는 처음의 40 tok/s 수치보다 훨씬 많은 것을 알려준다. 약 8K에서는 에이전트가 하는 작업에 따라 생성 시작 전 47초 대기가 충분히 합리적일 수 있지만, 약 16K에서는 이미 1분 반, 약 30K에서는 3분 이상 기다려야 한다. 주목할 점은 30K에서도 모델이 여전히 약 32 tok/s로 생성한다는 것이며, 디코드 속도만 보고하면 나쁘지 않아 보이지만 사용자 입장에서는 생성이 시작되기 전에 이미 3분을 기다린 셈이다. 그래서 필자는 TTFT, 즉 첫 토큰 생성까지의 시간이 로컬 코딩 모델에서 특히 중요하다고 생각한다.
마지막으로 에이전틱 코딩에 무엇이 사용 가능해 보이는지에 대해, 필자는 이 부분이 주관적이라 정해진 답이 있을 수 없다고 전제한다.
💬 주요 댓글 번역 (5)
🔍 루키 분석
M4 Max 36GB 환경에서 Qwen 3.8 27B를 테스트한 결과, NVFP4/MLX 버전이 Q4_K_M/GGUF 대비 디코드 속도가 약 3.8배 빠른 것으로 나타났다. 컨텍스트가 약 30K에 이르면 디코드 속도는 31.9 tok/s를 유지하지만 첫 토큰 생성까지 3분 15초를 기다려야 했다. 이 글은 로컬 코딩 모델 평가에서 토큰 생성 속도만큼 TTFT가 중요한 지표임을 보여준다.
— 루키 · glm-5.3-flash:cloud
이런 게시물들이 점점 링크드인형 저품질 콘텐츠처럼 들린다
사실 그렇다. 둘 다 LLM이 쓴 글이다
128GB M4 Max 소유자다. 놀랍도록 빠르진 않지만 로컬이라는 점이 마음에 든다. 다시 산다면 64GB를 살 것 같다. 대형 모델은 발전이 느려서 크게 밀어붙이지 않는다. 27B나 탄탄한 MoE, 소형 코더 모델 몇 개면 충분하다
오, 스펙 대비 속도가 좋네요. 어떻게 구동되고 있다고 생각하세요? 에이전틱 코딩도 해봤나요? 어떤 컨텍스트 윈도우를 쓰고 있나요?
챗 모델은 128K로 돌리고 코더 모델은 분해된 요청만 받으니 32K만 쓴다. 내가 보기엔 잘 돌아간다. 64GB M6 Studio를 알아보는 중인데, 내 244개의 정신나간 프로젝트 중 하나가 모델의 실시간 응답을 정말 필요로 하지 않는 한 거기서 충분할 것 같다