M3 Pro에서 27B Q4 모델을 18 tok/s로 구동

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

작성자는 36GB unified memory를 탑재한 M3 Pro에서 Qwen3.8-27B의 Q4 가중치를 약 15GB로 mmap하고, 특정 기기에 맞춘 C + Metal runtime과 OpenAI 호환 API로 로컬 실행 환경을 구성했습니다. speculative decoding을 적용한 결과 코드 생성 작업에서 평균 11.95 tok/s를 기록해 비활성화 상태의 7.96 tok/s보다 약 1.5배 빨라졌고, 1,155토큰 LRUCache 구현은 평균 17.7 tok/s와 약 55ms의 inter-token latency를 보였습니다. 산문은 후보 승인율이 낮아 약 10~11 tok/s로 느렸으며, 짧은 프롬프트의 TTFT는 약 1.4초였습니다. 약 120GB/s인 M3 Pro의 메모리 대역폭이 27B Q4 모델에서 약 18 tok/s에 가까운 한계로 작용해 추가 최적화 여지는 제한적입니다.

주요 논점

01찬성소수

작성자의 자체 C + Metal runtime과 speculative decoding 조합이 M3 Pro에서 27B Q4 모델을 실용적인 속도로 실행하게 했다는 평가입니다. 특히 코드 생성에서 약 1.5배 속도 향상과 반복 실행 간 동일한 출력이 측정돼 최적화의 효과와 안정성을 함께 뒷받침합니다.

실용적 조언

동일한 모델과 동일한 M3 Pro에서 llama.cpp와 자체 runtime을 비교하고, 코드 생성과 산문을 분리해 speculative decoding의 효과를 측정할 수 있습니다. 코드 작업에서는 후보 토큰 승인율이 높아질 수 있지만 산문에서는 속도 향상이 작을 수 있으므로 작업별 평균을 따로 기록해야 합니다. TTFT, inter-token latency, end-to-end tok/s를 함께 측정하면 초기 지연과 지속 생성 속도를 구분할 수 있습니다.

섹션별 상세

작성자는 M3 Pro와 36GB RAM 환경에서 Qwen3.8-27B를 로컬 실행하고, Q4 가중치 약 15GB를 unified memory에 mmap하는 구조를 구축했습니다. llama.cpp, mlx-lm, oMLX를 시험한 뒤 특정 기기에 맞춰 모델을 이미지로 컴파일하는 자체 C + Metal runtime으로 전환했으며, WorkBuddy가 연결할 수 있도록 OpenAI 호환 API를 얹었습니다. 코드 작성, 해시 테이블 설명, LRUCache 구현, 가상 메모리 글쓰기와 기술 노트 요약처럼 실제 사용 작업을 기준으로 성능을 측정했다는 점에서 단순 실행 성공 사례보다 재현 가능한 비교에 가깝습니다.

코드 생성에서는 speculative decoding의 효과가 특히 크게 나타났습니다. 1,155토큰의 전체 LRUCache 구현이 여섯 번 연속 실행에서 모두 동일한 결과를 내면서 end-to-end 평균 17.7 tok/s, inter-token latency 약 55ms를 기록했으며, 다섯 개 작업의 평균 속도는 비활성화 시 7.96 tok/s에서 활성화 시 11.95 tok/s로 올라 약 1.5배 개선됐습니다. 반면 산문 작업은 후보 토큰 승인율이 낮아 약 10~11 tok/s에 머물렀고, 이는 최적화 효과가 출력 유형에 따라 달라진다는 점을 보여줍니다.

작성자의 runtime은 같은 M3 Pro와 같은 모델을 사용한 llama.cpp보다 현재 더 빠른 결과를 냈습니다. 다만 M3 Pro의 메모리 대역폭은 약 120GB/s이고 27B Q4 모델에서 약 18 tok/s를 내고 있어, 추가 성능은 메모리 대역폭 한계에 가까워질수록 제한될 가능성이 큽니다. 아직 layer-fusion kernel 하나가 남아 있지만 작성자는 Qwen3.8-27B를 일상용 로컬 모델로 유지하고 MoE 버전을 기다리겠다고 밝혔습니다.

용어 해설

추측 디코딩(Speculative Decoding): — 작은 draft 모델이나 별도 draft vocabulary로 후보 토큰을 먼저 생성한 뒤 검증 커널이 여러 토큰을 한꺼번에 확인하는 추론 최적화 기법입니다. 후보가 승인되면 순차 생성을 줄여 토큰 생성 속도를 높이지만, 코드와 산문처럼 작업 유형에 따라 승인율과 효과가 달라집니다.
메모리 매핑(mmap): — 모델 가중치 파일을 프로세스의 가상 메모리 공간에 직접 매핑해 필요할 때 운영체제가 데이터를 읽도록 하는 방식입니다. 이 글에서는 약 15GB인 Q4 가중치를 M3 Pro의 36GB unified memory에 매핑해 모델 실행에 활용했습니다.
Q4 양자화 가중치(Q4 weights): — 모델의 가중치를 4비트 수준으로 압축한 형식으로, 원본보다 메모리 사용량을 줄여 로컬 하드웨어에서 더 큰 모델을 실행하게 합니다. 글의 27B 모델에서는 Q4 가중치 용량이 약 15GB였고, 메모리 대역폭이 추론 속도의 주요 제약으로 작용했습니다.
첫 토큰 생성 시간(TTFT): — Time To First Token의 약자로, 프롬프트 입력을 시작한 뒤 첫 번째 출력 토큰이 나올 때까지 걸리는 시간입니다. 이 구현은 짧은 프롬프트에서 약 1.4초, 128토큰 프롬프트에서 약 2.7초를 기록해 생성 속도와 별도로 초기 응답 지연을 측정했습니다.
토큰 간 지연 시간(inter-token latency): — 연속된 출력 토큰 사이에 걸리는 평균 시간으로, 스트리밍 응답이 얼마나 빠르게 이어지는지 나타내는 지표입니다. LRUCache 코드 생성에서는 약 55ms였으며, 1,155개 출력 토큰의 end-to-end 속도는 평균 17.7 tok/s였습니다.

언급된 도구

llama.cpp중립

같은 모델과 M3 Pro 환경에서 자체 C + Metal runtime과 생성 속도를 비교하는 추론 runtime

mlx-lm중립

M3 Pro에서 Qwen 모델을 실행하기 위해 시험한 로컬 추론 도구

oMLX중립

M3 Pro에서 Qwen 모델 실행 가능성을 확인하기 위해 시험한 로컬 추론 도구

NVIDIA AIPerf중립

LRUCache 생성 작업을 여섯 번 연속 실행해 end-to-end 속도와 inter-token latency를 측정한 벤치마크 도구

WorkBuddy중립

OpenAI 호환 API를 통해 자체 runtime의 로컬 모델과 연결한 코드 작업 도구

언급된 리소스

GitHubcpu-llms-in-c

M3 Pro에서 27B Q4 모델을 18 tok/s로 구동

TL;DR

주요 논점

실용적 조언

섹션별 상세

용어 해설

언급된 도구

언급된 리소스

관련 토론

댓글

관련 기사

12GB VRAM에서 Qwen 3.8 27B 실행하기

RTX 3090에서 Qwen3.8-27B 추론 가속

5070Ti에서 MTP를 뺀 85k 컨텍스트

Dense 모델 FFN CPU 오프로딩 옵션 제안

로컬에서 실행할 수 있는 LLM은 무엇인가