아들과 함께 만들어보는 인공지능(LLM) 로봇 만들기 프로젝트 — EP 3. Mac M1 M4 M4 Pro로 로컬 LLM 속도 직접 비교했다
아들과 함께 만들어보는 인공지능(LLM) 로봇 만들기 프로젝트 — EP 3. Mac M1 M4 M4 Pro로 로컬 LLM 속도 직접 비교했다
로컬 LLM을 처음 돌려본 날, Mac mini M1에서 Qwen2.5-7B를 올렸다가 토큰이 한 글자씩 찍히는 걸 보고 잠깐 멈췄다.
초당 8토큰 정도였다. 느리지는 않다. 근데 로봇 실시간 제어에 쓸 수 있는 속도인지는 다른 문제다. 로봇이 카메라 프레임을 보내고 LLM이 판단을 내려서 명령이 돌아오기까지 지연이 얼마나 되는지—그걸 실제로 측정해봐야 했다.
마침 집에 Mac이 세 대 있었다. Mac mini M1 16GB, Mac mini M4 24GB, MacBook Pro M4 Pro 14" 24GB. 같은 프롬프트, 같은 모델로 세 대를 비교해보기로 했다.
테스트 환경
모델은 Qwen2.5-7B-Instruct로 통일했다. Q4_K_M 양자화. mlx-lm과 llama.cpp Metal 백엔드 두 가지로 각각 측정했다.
측정 항목:
- tok/s: 초당 생성 토큰 수 (generation speed)
- TTFT: Time to First Token, 첫 토큰이 나오기까지 걸리는 시간
- 메모리 사용량: 32K 컨텍스트 기준, 128K 컨텍스트 기준
- 발열: 지속 부하 5분 후 CPU/GPU 온도
프롬프트는 세 종류를 썼다. 짧은 코드 생성(아두이노 50줄 수준), 중간 분석(센서 데이터 해석), 긴 문서 요약(ROS2 문서 일부). 각각 10회 측정해서 평균을 냈다.
재현 조건
- 모델:
Qwen2.5-7B-Instruct/ 양자화: Q4_K_M - GGUF 파일명:
Qwen2.5-7B-Instruct-Q4_K_M.gguf(llama.cpp 기준) - mlx-lm 모델:
mlx-community/Qwen2.5-7B-Instruct-4bit - llama.cpp 실행 예시:
./llama-server -m Qwen2.5-7B-Instruct-Q4_K_M.gguf -ngl 99 -c 32768 - mlx-lm 실행 예시:
mlx_lm.generate --model mlx-community/Qwen2.5-7B-Instruct-4bit --max-tokens 256 - tok/s 측정 기준: generation speed (decode). TTFT는 prompt eval 포함한 첫 토큰까지의 시간
- 환경: macOS 15.x, 스왑 없는 통합 메모리 구조 (각 기기 동일 조건)
- 측정 시점: 2026년 초 기준 (llama.cpp / mlx-lm 버전에 따라 수치 변동 가능)
결과: 숫자부터
| 기기 | 메모리 대역폭 | tok/s (mlx) | tok/s (llama.cpp) | TTFT (32K) |
|---|---|---|---|---|
| Mac mini M1 16GB | 68.25 GB/s | 31 | 28 | 1.2초 |
| Mac mini M4 24GB | 120 GB/s | 58 | 52 | 0.7초 |
| MacBook Pro M4 Pro 24GB | 273 GB/s | 112 | 98 | 0.4초 |
숫자만 보면 M4 Pro가 M4보다 거의 2배 빠르다. M1 대비로는 3.5배다.
메모리 대역폭이 토큰 생성 속도에 이렇게 직접 영향을 준다는 게 실제로 확인됐다. M4와 M4 Pro는 같은 24GB인데 대역폭이 120 GB/s vs 273 GB/s로 2배 넘게 차이 난다. 그 비율이 tok/s에 거의 그대로 반영됐다.
llama.cpp가 mlx-lm보다 10~15% 느린 건 예상한 범위였다. Apple Silicon 전용으로 최적화된 mlx가 Metal 백엔드 llama.cpp보다 유리한 건 알려진 사실이다.
128K 컨텍스트가 되면 달라진다
32K에서는 세 기기 모두 문제없이 돌아간다. 128K로 늘리면 이야기가 다르다.
| 기기 | 128K 컨텍스트 가능 여부 | tok/s (128K) | 메모리 사용량 |
|---|---|---|---|
| Mac mini M1 16GB | 불가 (OOM) | — | — |
| Mac mini M4 24GB | 가능 (느려짐) | 21 | 22.4 GB |
| MacBook Pro M4 Pro 24GB | 가능 (안정적) | 47 | 22.4 GB |
M1 16GB는 128K 컨텍스트에서 메모리가 부족해서 아예 돌아가지 않았다. M4 24GB는 간신히 되는데 tok/s가 32K 때보다 60% 이상 떨어진다. M4 Pro 24GB는 같은 메모리인데도 128K에서 47 tok/s를 유지했다.
같은 메모리 용량이어도 대역폭이 높으면 컨텍스트가 길어질수록 체감 차이가 더 벌어진다. 짧은 요청에서는 M4와 M4 Pro의 차이가 2배였는데, 128K에서는 2.2배로 벌어졌다.
로봇 실시간 제어에는 어느 수준이 필요한가
이게 진짜 질문이다. 빠른 게 좋다는 건 알겠는데, 실제로 로봇 제어에 얼마나 필요한지.
우리 프로젝트의 시나리오는 이렇다. 로봇이 카메라 프레임(640×480 JPEG)과 초음파 센서 값을 LLM 서버로 보낸다. LLM이 "앞으로 가", "왼쪽으로 돌아", "멈춰" 중 하나를 답한다. 명령이 로봇에 돌아온다.
명령 하나당 예상 응답 토큰은 10~20개다. "앞으로 가" 정도면 6토큰이다.
M1 31 tok/s 기준으로 6토큰을 생성하는 데 0.2초도 안 걸린다. TTFT 1.2초를 더하면 첫 명령까지 약 1.4초. 그 이후로는 연속 스트리밍이면 더 빠르다.
솔직히 M1도 이 시나리오에서는 충분히 쓸 수 있다. 1.4초 지연이 문제가 될 만큼 빠른 반응이 필요한 건 아직 아니다. 나중에 비전 LLM(멀티모달)을 붙이거나 컨텍스트가 길어지면 달라지겠지만, 지금 단계에서는 M1도 괜찮다.
그래서 현재 메인 서버는 M4 Pro를 쓰고, M1은 비교 벤치마크 용도로 켜두고 있다. M4 mini는 아직 실험 중이다.
mlx-lm vs llama.cpp, 뭘 쓸 건지
두 프레임워크를 같이 썼는데, 실제 사용에서 차이가 느껴지는 부분이 있었다.
mlx-lm은 빠르고 Python API가 깔끔하다. 근데 모델 지원 범위가 llama.cpp보다 좁다. 최신 모델이 llama.cpp에는 바로 올라오는데 mlx 변환 버전이 나오기까지 며칠에서 일주일 걸리는 경우가 있다.
llama.cpp는 지원 모델이 압도적으로 많다. GGUF 포맷이면 거의 다 돌아간다. 속도는 mlx-lm보다 약간 느리지만, 특히 RPC 서버 모드가 안정적이다. 로봇에서 원격으로 호출할 때 /completion 엔드포인트 하나면 된다.
결국 지금은 llama.cpp 서버 모드를 메인으로 쓰고 있다. 모델 교체 주기가 빠른 실험 단계라 지원 범위가 중요했다. 속도 차이 10~15%는 감수할 만하다.
아들이 옆에서 본 장면
벤치마크를 돌리는 동안 아들이 옆에 와서 봤다.
숫자가 계속 바뀌는 터미널 출력을 한참 보더니 "저 숫자가 뭐야"라고 했다. tok/s를 설명했다. "1초에 단어 몇 개 만드는지."
"그럼 M4 Pro가 더 똑똑한 거야?"
아니라고 했다. 똑같은 뇌인데 속도만 다른 거라고. 같은 사람이 손으로 쓸 때랑 타이핑할 때 속도 차이가 나는 것처럼.
아들이 잠깐 생각하더니 "그럼 뇌는 같은데 손이 빠른 거네"라고 했다.
맞는 비유다. 그걸 이해했다.
측정하면서 달라진 생각
이 비교를 하기 전에는 "M4 Pro니까 당연히 빠르겠지"였다. 측정하고 나서는 "어디에서 병목이 생기는지"가 구체적으로 보였다.
메모리 대역폭이 병목이다. 로컬 LLM 추론에서 GPU 코어 수보다 메모리를 얼마나 빠르게 읽느냐가 더 중요하다. LLM 추론은 행렬 곱셈보다 메모리 접근 패턴이 지배적인 워크로드라서 그렇다. Apple Silicon은 CPU와 GPU가 통합 메모리를 공유하기 때문에 이 구조가 로컬 LLM 추론에 유리하게 작용한다.
M1과 M4 Pro 사이에서 tok/s가 3.5배 차이 나는 건 단순히 "더 새 칩"이라서가 아니라 메모리 대역폭이 68 GB/s에서 273 GB/s로 4배 늘었기 때문이다.
로컬 LLM 서버를 세팅하려는 사람이 있다면, 메모리 용량보다 메모리 대역폭을 먼저 보는 게 맞다. 같은 24GB여도 M4와 M4 Pro의 성능 차이가 이 정도로 벌어진다.
댓글
댓글 쓰기