M4 Max 128GB 로컬 LLM 4종 속도 비교 — 실측 기록과 한계
M4 Max 128GB에서 로컬 LLM은 얼마나 빠를까?
이 글의 과거 표에서는 gemma4:latest가 88 tok/s로 가장 높고, gemma4:26b는 85 tok/s다. gpt-oss:120b 47 tok/s, qwen3.6:35b-a3b 25 tok/s가 뒤를 잇는다. 처리량 표이지 정답률이나 코딩 품질 순위가 아니다.
작성자: 닥터조지. 2026년 4월 게시 당시 측정 기록 / 편집 보완: 2026-09-23. 기존 수치는 그대로 보존했고 이번에 모델을 다시 실행하지 않았다. 초판 제목의 llama3.3 표기와 “26B가 가장 빠르다”는 도입은 표와 일치하지 않아 바로잡았다.
원문의 장비·런타임·모델 표기는 당시 기록이다. 표의 qwen3.6:35b-a3b는 원문에서 사용한 축약 표기이며, Q8과 qwen3.6:35b-a3b-q8_0 표기는 당시 본문 기록에서 가져왔다. 모델 파일이나 digest를 이번에 확인한 것은 아니다. 원 프롬프트 전문, 모델 digest, 반복 횟수와 개별 원시 응답이 이 글에 없어 표의 숫자를 그대로 재현했다고 확인할 수는 없다. 특히 latest는 고정 버전 식별자가 아니다.
아래는 M4 Max 128GB 한 대에서 기록한 네 모델의 처리량이다. 모델 구조, 양자화, 크기가 동시에 다르므로 어느 한 요인만의 효과를 분리한 실험으로 읽으면 안 된다.
모델 크기만으로 속도를 예측하기 어려운 이유
원문은 gpt-oss:120b를 총 117B, 활성 약 5.1B의 MoE로 기록했다. 활성 파라미터 수만으로 실제 생성 속도를 계산할 수는 없다.
모델 구조에 따른 메모리 접근 차이는 가능한 설명이지만, 이 표는 메모리 대역폭이나 접근 패턴을 직접 계측한 자료가 아니다. 생성 속도 차이만으로 병목의 원인을 확정하지 않는다.
당시 표의 gemma4:26b는 gpt-oss:120b보다 높은 생성 처리량을 보였다. 다만 이 결과를 모든 Dense 모델과 MoE 모델의 우열로 일반화할 수는 없다. 같은 장비라는 조건 외에 모델과 양자화 조건도 함께 살펴야 한다.
테스트 환경
하드웨어는 Mac Studio M4 Max, 통합 메모리 128GB, 메모리 대역폭 546GB/s.
런타임은 Ollama 0.20.7 (llama.cpp 기반).
동일 프롬프트 3종 — 짧은 한국어, 짧은 수학, 긴 코드 생성. Cold start(첫 로드)와 Warm(모델 올라간 상태)을 분리 측정.
결과
4-way 비교표. 단위 tokens/second(tok/s). Prompt eval은 프롬프트 입력 처리 속도(초당 토큰 몇 개를 읽어들이는가), Generation은 응답 생성 속도(초당 토큰 몇 개를 출력하는가).
| 모델 | 크기(디스크) | 활성 파라미터 | Cold Load | Prompt eval | Generation |
|---|---|---|---|---|---|
| gpt-oss:120b | 65GB | 5.1B (MoE) | 16.8s | 620 tok/s | 47 tok/s |
| gemma4:26b | 17GB | ~26B (Dense) | 5.0s | 460 tok/s | 85 tok/s |
| gemma4:latest | 9.6GB | ~9B (Dense) | 3.2s | 679 tok/s | 88 tok/s |
| qwen3.6:35b-a3b | 38GB | ~3B (MoE) | 19.1s | 140 tok/s | 25 tok/s |
예상 벗어난 지점 세 개.
첫째, gemma4:latest가 표에서 88 tok/s로 가장 높다. 표의 9.6GB는 디스크 크기이며 파라미터 수와 다른 단위다.
둘째, gemma4:26b와 gpt-oss:120b의 생성 처리량은 85 대 47 tok/s다. 약 1.81배 차이지만, 그 차이를 만든 단일 원인은 이 측정만으로 확인하지 못했다.
셋째, 원문에서 Q8로 기록한 qwen3.6:35b-a3b-q8_0는 25 tok/s다. 다른 모델은 Q4 계열 또는 MXFP4로 기록되어 있다. 서로 다른 양자화를 사용했으므로 양자화만 통제한 비교가 아니며, Q8이 느린 원인 전부라고 단정할 수 없다.
이 표로 고를 수 있는 것과 없는 것
다음은 당시 처리량을 기준으로 한 후보 선정이다. 최신 추천이나 품질 벤치마크 결론은 아니다.
생성 속도를 우선한다면 당시 표의 gemma4:latest가 첫 확인 후보였다. 9.6GB, 88 tok/s라는 기록이며, 현재 같은 태그가 같은 모델 파일을 가리키는지는 별도로 확인해야 한다.
gemma4:26b는 17GB, 85 tok/s로 기록됐다. 한국어 답변이나 코딩 품질이 필요한 독자는 자신의 고정된 문제와 정답 기준으로 추가 평가해야 한다.
gpt-oss:120b는 47 tok/s다. 추론 기능의 존재만으로 복잡한 문제의 정답률이 더 높다고 결론 낼 수 없으며, 이 글에는 동일 문제에 대한 품질 채점표가 없다.
qwen3.6:35b-a3b-q8_0는 당시 생성 속도만 보면 후순위였다. 다른 양자화 변형의 속도나 품질은 이 결과로 추정하지 않는다.
메모리 용량을 고를 때는 모델 파일 외에 컨텍스트와 동시에 실행할 앱의 사용량도 기록해야 한다. 이 글의 디스크 크기 표만으로 모든 긴 컨텍스트에서 swap이 없다고 보장하거나 64GB 장비의 결과를 대신 계산할 수는 없다.
이번 편의 결론
모델 크기나 활성 파라미터 수 하나로 속도를 정하지 말자. 모델 식별자·양자화·런타임·컨텍스트·Cold/Warm 조건을 함께 기록하고, 처리량과 품질은 따로 평가하는 것이 이 표에서 가져갈 기준이다.
내 Mac에서 다시 비교할 때의 기록 절차
- 장비·메모리·OS·Ollama 버전, 모델의 전체 태그와 digest, 양자화, 컨텍스트 길이, 생성 옵션을 기록한다. 바뀔 수 있는 latest 태그만 남기지 않는다.
- 동일한 프롬프트 전문과 출력 길이 조건을 파일로 고정한다. 짧은 질문과 긴 코드 생성은 따로 집계하고, 품질 판정 기준도 실행 전에 정한다.
- 모델이 내려간 상태의 첫 요청과 이미 올라간 상태의 요청을 분리한다. 모델별 같은 횟수로 반복하고 각 회차 원시 응답을 보관한다. 첫 로드 시간을 생성 속도에 섞지 않는다.
- Ollama Generate API의
stream:false응답에서load_duration,eval_count,eval_duration을 기록한다. 생성 처리량은eval_count / eval_duration × 1,000,000,000으로 계산한다. duration은 나노초 단위다. - 회차별 처리량과 중앙값, 실패한 요청, 메모리·swap 상태를 함께 남긴다. 속도가 빨라도 정답 기준을 통과하지 못했다면 별도 실패로 기록한다.
응답 필드와 단위의 출처: Ollama 공식 Generate a response 문서(2026-09-23 조회). 이 절차는 재측정 안내이며 위의 과거 수치를 새로 재현한 결과가 아니다.
시리즈 다음 편 — 이 모델을 실전 투입한다
이번 편은 벤치마크만 했다. 원래 목적은 ChatGPT Plus 쿼터가 터졌을 때 맥 스튜디오 로컬 LLM이 받아주게 만드는 것. 다음 편에서는 이 gpt-oss:120b를 실제 에이전트 fallback 체인 끝에 꽂아서, 쿼터가 터지는 순간 로컬로 자동 전환되게 만든 과정을 적는다. 설정 JSON 그대로 공개한다.
댓글
댓글 쓰기