Mac mini M5 Pro (2026)의 64GB로 로컬 LLM은 무엇을 사용할 수 있을까

메모리 64 GB를 탑재한 Mac에서, 기기 자체만으로 구동하는 AI(로컬 LLM)를 사용한다고 가정해 봅시다. 이때 기다림 없이 사용 가능하면서도 충분히 똑똑한 모델은 어떤 것일까요? 이를 확인하기 위해 실제 측정했습니다.

이 글을 다 읽으면 다음 4가지에 대한 판단 자료를 얻게 됩니다.

• 속도: 어느 정도의 모델이라면 기다릴 필요가 없을지
• 지능: 속도와 답변의 질은 양립할 수 있는지
• 크기의 한계: 64 GB로 얼마나 큰 모델을 사용할 수 있을지
• 클라우드와의 거리: 로컬 모델이 클라우드 모델과 비교했을 때 어느 정도 수준인지

이 글은 누구를 위한 것인가

• 64 GB급 Mac을 가지고 있거나 구매할 예정이며, 기기 자체에서 AI를 구동하고 싶지만 어떤 모델이 실용적인지 판단 자료가 없는 사람
• '모델이 클수록 더 똑똑할 것이다'라고 생각하여 70B나 80B가 쾌적하게 작동하는지 모르는 사람
• 평소 클라우드 AI를 사용하며, 로컬 모델이 그것과 비교했을 때 어느 정도 수준인지 감을 잡지 못하는 사람

용어는 처음 등장할 때 설명합니다. 6가지 테스트 후에 용도별 선택 방법을 표로 정리했습니다. 마지막으로 측정 조건과 주의사항을 언급했습니다.

측정한 장비와 진행 방식

장비는 2026년 모델의 Mac mini (Apple M5 Pro, 메모리 64 GB, macOS 27.0)입니다. 모델을 구동하는 소프트웨어로는 llama.cpp (Homebrew 0.5.0)와 LM Studio 0.4.25(모델을 불러와 API로 응답을 반환하는 앱)를 사용했습니다. GPU가 사용할 수 있는 메모리 상한선은 macOS의 기본값(약 48 GB)으로 변경하지 않았습니다.

용어를 세 가지 설명하겠습니다.

• 양자화 (Quantization): 가중치를 거친 숫자로 반올림하여 작게 만든 버전. 이번에는 4bit 계열입니다.
• GGUF / MLX: 배포 형식 두 종류. MLX는 Apple Silicon 전용입니다. 둘 다 4bit 계열이지만 같은 양자화는 아닙니다(나중에 다룹니다).
• 토큰 (Token): 문장을 나눈 처리 단위. 속도는 1초당 토큰 수(t/s)로 표시합니다.

모델 이름의 '8B', '32B'는 가중치 수(B는 10억)입니다.

처음에는 속도 측정만 할 계획이었고, 이후 테스트는 결과를 보고 추가했습니다.

테스트 1: 8B, 32B, 70B의 3가지 크기로 속도를 측정하기

모델이 클수록 똑똑할 것이라고 생각합니다. 그렇다면 64 GB Mac에서 어느 정도까지 실용적인 속도가 나올까요? 처음 대상은 8B와 32B였고, 한계를 보기 위해 70B를 추가했습니다. 70B는 약 40 GB로 GPU 상한선에 가깝습니다.

• 생성 속도 (Generation Speed): 답변을 출력하는 속도(t/s)
• 최초 응답 (First Response): 입력을 보내고 첫 번째 토큰이 나올 때까지 걸리는 시간(TTFT). 약 8,000 토큰의 장문을 주고 측정했습니다.

같은 입력을 반복해서 보내면 KV 캐시(처리된 입력을 기억해 같은 입력 재전송을 빠르게 하는 메커니즘)가 작동하여 빨라집니다. 그래서 매번 입력의 시작 부분을 바꿔서 전체를 다시 처리한 값을 채택했습니다. 재전송 값은 다른 열에 표시합니다.

생성 속도는 짧은 입력 기준, 최초 응답은 장문 기준입니다. 4번 측정하여 첫 번째 값을 제외한 3회의 평균값입니다(재전송은 1회 값).

70B는 상한선을 바꾸지 않고 올렸습니다. 다만 장문을 주면 첫 토큰까지 약 1분 정도 기다립니다. 32B도 31.6초가 걸립니다. 생성 속도는 8B에서 32B로 약 4분의 1, 70B에서는 그 절반 이하로 줄었습니다. 커질수록 느려집니다.

참고로 Qwen3는 기본적으로 사고 모드(답변 전에 생각을 적어내는 동작)가 활성화되어 있어, 생성의 대부분이 생각 부분에 할애되었습니다. 이 부분은 답변이 아닙니다.

이 시점에서의 저의 결론은 이랬습니다. 일상 사용은 32B까지. 70B는 기다릴 수 있는 용도에 배치한다.

하지만, 32B의 31.6초는 대화에는 길다. 같은 크기에서 속도를 빠르게 할 방법은 없을까?

테스트 2: MoE 방식의 Qwen3 30B-A3B를 추가하자 결론이 뒤집혔습니다

다음으로 모델 구조에 초점을 맞춰 시험을 진행했다. 시험 1의 세 가지 방식은 토큰당 모든 가중치를 사용한다. 이를 일반형(dense)이라고 부른다. 반면 MoE(Mixture-of-Experts) 형태는 토큰당 일부 전문 레이어만 사용한다. Qwen3 30B-A3B는 총량 30B 중 약 3B만 구동된다. 사용하는 가중치가 적다면, 같은 19GB 전후에서도 빠르지 않을까?

Qwen3 30B-A3B를 시험 1과 동일한 방식으로 측정했다.

생성 속도는 32B의 약 6배가 되었다 (102.3 ÷ 15.7 = 6.5배). 초기 응답은 31.6초에서 5.5초로 단축되었다. 8B보다 빠르다. 시험 1의 '일반 사용은 32B까지'는 일반형에 한정된 이야기였다.

빠른 이유는 토큰당 읽어야 하는 가중치가 약 3GB면 충분하기 때문으로 설명할 수 있다.

빠르다는 것은 알겠다. 하지만 일부만 사용한다면, 지능이 떨어지지 않을까? 이 시점에서는 품질을 측정하지 않았다.

시험 3: MoE 형태는 일반형 Qwen3 32B보다 지능이 떨어지지 않았나?

Qwen3 32B (일반형)와 Qwen3 30B-A3B (MoE 형태)에 표준 문제 세트 3종을 동일한 조건(MLX 4bit)으로 풀게 했다. 일본어 상식(JCommonsenseQA), 지식 및 추론(MMLU-Pro), 코드 생성(HumanEval+)이다. 생각 없이 전 문항, 생각이 있는 경우 각 100문항으로 진행했다.

500문항에서 ±4 포인트, 100164문항에서 ±79 포인트 미만의 차이는 오차 범위로 해석한다.

MoE 형태가 명확히 열세인 항목은 없었다.

일반형은 길게 쓰고, 깊이 생각한다. 지식 및 추론의 생각이 있는 100문항에서는 출력 제한까지 답에 도달하지 못하고 중단된 문제가 일반형 24개, MoE 형태 7개였다. 같은 문제 세트에 MoE 형태는 약 93분, 일반형은 약 7.5시간이 걸렸다 (재로딩 포함 실시간).

이는 4bit 양자화・예제 없음・이 출력 제한에서의 단일 값이며, 공식 점수와 일치하지 않는다. 말할 수 있는 것은 '이 세 가지 종류/이 규모에서는 명확한 차이를 보여주지 못했다'까지만 가능하며, '차이가 없다', '동일 품질'은 아니다. 또한 Qwen3의 두 모델 비교이며, 일반형 전반과 MoE 형태 전반의 우열 관계도 아니다.

그렇다면 더 새로운 MoE 형태, 더 큰 MoE 형태라면 더욱 좋아질까?

시험 4: 신세대 35B는 속도를 유지하며 지능이 높아질까?

다음으로, 신세대의 Qwen3.6 35B-A3B (MoE 형태・20.4 GB)를 측정했다. 기준은 Qwen3 30B-A3B이며, 크기는 그보다 약 1할 정도 크다. 측정 전 예측치는 생성 속도 70~90 t/s였다.

속도는 예측을 상회하여 기준과 동등 이상이었다. 다만 두 가지 습관이 있었다.

• 즉답에서 번호를 착각한다. 일본어 상식 오답 69개 중 50개가 '정답 번호 ±1'이었다. 0부터 시작하는 선택지 번호를 세는 것을 착각했다. 같은 100문항을 생각하기로 하면, 정답은 88개에서 94개로 늘어난다 -
• 너무 깊이 생각한다. 생각이 필요한 코드 생성에서는 100문항 중 58문항이 생각만으로 출력 제한을 모두 소진하여 중단되었다 (정답률 40.0%) . 두 모델 모두 답을 다 풀어낸 38문항에서는 Qwen3.6가 전 문항 정답이었다. 제한을 크게 잡은 경우는 측정하지 않았다.

교체할 가치가 있는지는 용도에 따라 다르므로, 여기서는 단정하지 않는다.

그렇다면 세대별이 아니라, 총량을 80B까지 늘린다면 어떻게 될까?

시험 5: 80B급은 64GB에서 무너졌다

다음으로 Qwen3-Next 80B-A3B (MoE 타입, 44.9 GB)를 테스트했습니다. 총량은 80B이지만, 구동량은 약 3B로 동일합니다. 측정 전 예측치는 생성 속도 60~80 t/s였습니다.

우선 LM Studio의 안전장치(메모리 부족을 예상하여 로드를 중지시키는 메커니즘)가 로딩을 거부했습니다. 이를 해제하자, GPU 상한은 기본값 그대로 표시되었습니다.

입력 측면은 예측과 같았습니다. 입력 처리는 1,333 t/s (기준 1,459 t/s), 최초 응답은 6.0초입니다. 문제가 생긴 것은 생성 속도였습니다. 10회 요청 동안 50.8 t/s에서 13.6 t/s까지 떨어졌습니다. 예측치의 절반 이하입니다. 측정 중 여유 메모리는 최소 19%였고, GPU 사용량은 최대 51.0 GB로 기본 상한을 초과하는 영역에서 작동했습니다. 스왑(메모리 부족 시 디스크로 데이터를 옮기는 동작)도 발생하여 다른 작업과 공존할 수 없었습니다.

이 속도로는 품질 측정에 10~20시간이 걸릴 것으로 예상되어, 품질 측정 없이 중단했습니다.

• Qwen3-Next 80B-A3B의 품질은 측정하지 않았습니다. '이 Mac에서는 속도가 나오지 않아 실용적이지 않다'는 것이지, '모델이 떨어진다'는 의미가 아닙니다.
• 속도는 10회 요청에 대한 중간 값일 뿐입니다. 메모리 압박이 원인으로 보이지만, 분리 측정은 하지 않았습니다.
• 안전장치를 해제하는 작업은 권장하지 않습니다.

여기까지로 지식과 추론의 정답률이 가장 높았던 것은 35B였습니다. 그렇다면 이는 평소 사용하는 클라우드 모델과 비교했을 때 어느 정도 수준일까요?

시험 6: 클라우드 모델과 동일한 100문제로 비교

공개된 순위표가 아니라, 같은 문제와 같은 채점 기준으로 비교하고 싶었습니다. 그래서 클라우드의 4개 모델에 동일한 문제지 각 100문항을 생각 없이 풀게 했습니다. 경로는 CLI(터미널에서 사용하는 제품. Claude Code와 Codex)입니다. 가지고 있는 3개 모델은 동일한 100문항을 추출했습니다. 이 절의 수치는 100문제 기준이며, 시험 3·4의 수치와는 일치하지 않습니다.

| 모델 | 한국어 상식 (%) | 지식과 추론 (%) | 코드 생성 (%) | :--- |
| Qwen3 30B-A3B | 90 | 69 | 88 | :-
| ... |
위 3행이 가지고 있는 모델입니다. Haiku 4.5와 GPT-6-Luna가 소형, Sonnet 5와 GPT-6-Sol이 주력입니다.

가지고 있는 모델 중 가장 좋았던 Qwen3.6 35B-A3B는 클라우드의 소형 모델보다 약간 아래에 위치합니다. 코드 생성은 비슷한 수준이지만, 지식과 추론은 56 포인트, 한국어 상식은 48 포인트 낮아 주력인 GPT-6-Sol에는 세 가지 모두 명확히 미치지 못합니다.

이 위치를 고려할 때, 클라우드 대신 사용할 수 있는 범위는 제한적입니다. 단답형 질문 답변, 객관식 판단, 함수 1개 정도의 코드 생성처럼 한 번에 답이 나오는 작업이라면, 소형 모델과 비슷한 수준으로 가지고 있는 모델만으로도 충분히 처리할 수 있습니다. 반면, 긴 문맥에서의 다단계 작업, 도구를 사용하는 작업, 큰 코드베이스, 한국어 장문 작성은 측정하지 않았습니다. 실무에서 차이가 벌어지는 것은 이 영역이며, 여기서 클라우드의 대체재라고는 할 수 없습니다.

• 100문제 기준 ±9 포인트 정도의 폭이 있습니다. 소형 모델과의 차이는 범위 내에 있으며, '약간 아래'라는 것은 '차이를 보여주지 못했다'는 의미를 포함합니다. 범위를 초과한 것은 GPT-6-Sol와의 차이뿐입니다.
• 순수 모델이 아닌 CLI 제품을 측정했으며, 자동으로 붙는 지시문(프롬프트)의 영향이 있습니다. Codex는 가벼운 추론이 있으며, Claude와 가지고 있는 모델은 생각 없이 처리했기 때문에 조건이 갖춰지지 않았습니다.
• 최신 주력 GPT-6.1-Sol과 각 사의 최고급 모델은 대상에서 제외되었습니다.

6가지 시험을 통해: 용도별 선택 방법

| 모델 | 크기 (GB) | 생성 속도 (t/s) | 최초 응답 (초) | 지능 | 적합한 용도 | :--- |
| Qwen3 30B-A3B (MoE 타입) | 17~19 | 102 | 5.5 | 기준. 일반형 32B와 명확한 차이를 보이지 못함 | 대화/코딩 보조 | :-
| ... |
쾌적함의 기준으로 '생성 30 t/s 이상 · 장문 최초 응답 15초 이내'로 설정했습니다. 이번 실측을 통해 제시된 참고값입니다.

대화 및 코딩 보조에는 30~35B급 MoE(Mixture-of-Experts) 모델을 선택한다. 추론 능력이 필요하다면 Qwen3.6 35B-A3B (사고 과정 없음), 출력 형식의 자연스러움을 원한다면 Qwen3 30B-A3B이다. 클라우드와 비교했을 때, Qwen3.6 35B-A3B는 소형 모델보다 약간 낮았다. 하지만 이는 짧은 문제에 국한된 이야기이며, 소형 모델을 대체할 수는 없다고 말할 수 있다.

클라우드 대비 성능이 떨어질 때, 어떻게 활용할 것인가

클라우드에 미치지 못한다는 전제하에, 로컬에서 사용할 만한 활용 방안을 구상했다. 아래 내용은 측정 결과에서 제가 도출한 아이디어이며, 실제 업무 환경에서 검증된 것은 아니다.

• 단번에 답이 나오는 짧은 작업을 여러 개 처리한다. 분류, 태그 지정, 객관식 판별, 짧은 요약 초안 작성, 함수 1개 정도의 코드. 시험 6에서는 소형 모델과 비슷한 수준이었으며, MoE 모델이라면 긴 문장을 넣어도 약 5초 내외로 반환된다. 클라우드 사용량이나 비용을 신경 쓰지 않고 반복할 수 있으므로, 건수가 많은 작업에 적합하다.
• 클라우드 전 데이터 전처리. 대량의 문서에서 후보를 추려내거나, 질문을 정리하거나, 초안을 만드는 용도. 최종 판단이나 긴 작업은 클라우드에 맡기고, 로컬 모델은 전 단계(前段)로 활용한다.
• 외부 유출이 불가능한 문서를 다룰 때. 로컬에서만 구동되는 것이 성능 차이보다 우선시되는 상황이 있다. 이 경우에도 업무는 짧은 질문으로 나누어 전달하는 것이 좋다.
• 기다릴 수 있는 일괄 처리에는 일반형 32B 모델을 사용한다. 속도는 1/6 수준이지만, 답만 나오면 품질은 MoE 모델과 견줄 만하다. 밤에 돌리는 작업이라면 선택지에 포함될 수 있다.

적합하지 않은 것은 긴 문맥에서의 다단계 작업, 도구를 사용하는 업무, 대규모 코드베이스, 한국어 장문 작성이다. 이 영역들은 측정되지 않았으며, 클라우드와의 격차가 벌어지는 부분이기도 하다. 지식이 필요한 질문의 최종 답변 역시 소형 모델에 몇 포인트 미치지 못하기 때문에, 로컬에서 완료해야 할 이유는 적다.

측정 조건 및 주의사항

속도는 1대/1조건(4bit 계열・컨텍스트 길이 10240・온도 0)의 값이며, 날을 두고 측정했다 (버전은 동일). 품질 비교 조건은 별개이다.

• 생성 속도는 80B 추이를 제외하고, 첫 번째 결과를 버린 3회 평균값이다. 128 토큰에 도달하기 전에 끝난 경우는 짧은 구간에서의 값이다.
• GGUF Q4_K_M과 MLX 4bit는 같은 양자화가 아니다 (MLX 측이 약 8% 작다). MLX는 입력 처리 속도가 1.41.5배, 생성 속도는 1218% 빠르지만, 일부는 이 차이에 의한 것이다.
  형식 간의 품질 차이는 미평가되었다. - '오차 범위' 판정에는 p-값(차이가 우연히 나타날 확률의 기준)을 사용했으며, 0.05 미만을 '초과'로 간주했다.

측정은 AI 에이전트 (Claude Code)가 지침에 따라 실행했고, 저는 지시 및 승인을 담당했다.

논의(Discussion)