TurboFieldfare Gemma 4 26B M4 Mac mini 실측: 2GB 메모리로 돌지만 느린 이유

결론 먼저

TurboFieldfare는 상주 메모리 약 2GB로 Gemma 4 26B-A4B를 돌리는 데 성공했지만, M4 Mac mini 16GB에서는 decode 6.26 tok/s, 웜 prefill 24~25 tok/s에 그쳤습니다. 외장 SSD의 콜드 첫 읽기는 웜 대비 3~4배 느려 Hermes 에이전트 첫 턴이 35분 이상 걸렸고, 에이전트용으로는 부적합하다는 결론입니다.

실험 환경: Apple M4 Mac mini 16GB, macOS 26.6, Swift 6.3.3, TurboFieldfare (Swift/Metal, Apache 2.0), Gemma 4 26B-A4B IT 4bit (13.6GB 설치), 외장 NVMe SSD OWC_1M2
누구에게 유용한가: 16GB Apple Silicon Mac에서 26B급 로컬 모델을 직접 돌려보려는 사람, MLX/llama.cpp 래퍼가 아닌 Metal 네이티브 런타임의 실제 성능이 궁금한 사람

확인한 자료와 한계

확인한 자료

drumih/turbo-fieldfare GitHub 저장소
mlx-community/gemma-4-26b-a4b-it-4bit 모델 카드
Daejin Lab M4 Mac mini 16GB 로컬 실행 기록

한계

단일 장비(M4 16GB)와 단일 모델(Gemma 4 26B-A4B 4bit) 기준입니다. M2/M5 Pro 참조값은 저장소와 공개 기록의 값이며 같은 조건에서 다시 측정하지 않았습니다. 콜드·웜 비교도 외장 SSD와 이번 모델 조합에서의 결과입니다.

이 글에서 다루는 핵심 3가지

결론 먼저
TurboFieldfare란
설치와 빌드

모델이 2GB 메모리로 돌아간다는 말을 들으면 “이건 될 것 같다”는 기대가 먼저 듭니다. 26B짜리 모델이 그 정도로 가볍게 돌면 로컬 에이전트로 써도 되겠다는 생각이 들 수 있습니다. 이 글은 그 기대를 직접 실측으로 확인한 기록입니다. 사용한 장비는 M4 Mac mini 16GB, 내장 256GB에 외장 NVMe SSD 2TB를 붙인 구성입니다.

결론부터 쓰면, 메모리는 정말 가벼웠습니다. 상주 약 2GB, 서버 64K 컨텍스트에서도 3.2GB 수준이었습니다. 그런데 속도는 기대와 달랐습니다. decode 6.26 tok/s, 웜 상태 prefill 24~~25 tok/s였고, 외장 SSD의 콜드 첫 읽기는 그보다 3~~4배 느렸습니다. 실제로 에이전트에 붙여보니 첫 턴이 35분 이상 걸렸고, “하이” 한 마디에 prefill이 39분 걸리는 화면을 직접 봤습니다. 결론은 “짧은 단발 프라이빗 채팅용”이었습니다.

결론 먼저

하려는 일	판단	근거
Hermes 에이전트 (다중 턴, 도구 호출)	부적합	첫 턴 12K 토큰 기준 콜드 35분+, 웜 20분+
짧은 단발 프라이빗 채팅 (CLI/curl)	사용 가능	첫 턴 5~10분 각오, 연속 대화는 prompt cache로 이후 턴 빨라짐
내장 SSD로 옮겨서 해결	아님	첫 턴(콜드)만 일부 개선, decode·웜 prefill은 동일
16GB에서 로컬 에이전트 대안	4B급 작은 모델	메모리 여유보다 턴당 지연이 먼저 문제

핵심은 “작은 메모리 = 빠른 응답”이 아니라는 점입니다. 이 모델은 필요한 expert만 SSD에서 스트리밍하는 구조라서, 메모리는 아끼는 대신 디스크 읽기와 GPU 속도가 성능을 결정합니다.

TurboFieldfare란

TurboFieldfare는 Gemma 4 26B-A4B 전용 Swift/Metal 런타임입니다. MLX나 llama.cpp의 래퍼가 아니라 Swift로 직접 만든 엔진입니다. macOS 26 이상, Metal 4, arm64가 필요합니다. 라이선스는 Apache 2.0이고, 저장소는 drumih/turbo-fieldfare입니다.

모델 구조는 MoE입니다. 총 26B 파라미터 중 토큰당 활성화되는 것은 약 3.88B이고, 레이어는 30개(25개 sliding-window + 5개 full-attention)이며, 레이어당 128개 routed expert 중 top-8을 씁니다. 필요한 expert만 SSD에서 읽는 16-slot LFU expert cache 방식이라, 상주 메모리가 작습니다.

제품군은 네 가지입니다. 하나의 모델 프로세스만 실행해야 하고, 서버·앱·CLI를 동시에 띄우면 안 됩니다.

TurboFieldfareMac       GUI 앱
TurboFieldfareCLI       메시지 파일 기반 채팅
TurboFieldfareServer    OpenAI 호환 서버 (127.0.0.1:8080, tool calls, prompt cache)
TurboFieldfareRepack    모델 설치기

설치와 빌드

빌드는 CommandLineTools만으로 됐습니다. Xcode는 필요 없었고, swift build -c release가 103초 만에 끝났습니다. 저장소를 클론한 뒤 다음 순서로 진행했습니다.

git clone https://github.com/drumih/turbo-fieldfare
cd turbo-fieldfare
swift build -c release

모델은 mlx-community/gemma-4-26b-a4b-it-4bit를 받았습니다. 다운로드 약 15GB, 설치 후 13.6GB였고 설치 경로는 scratch/gemma4.gturbo였습니다. 설치기(TurboFieldfareRepack)가 manifest.json과 verified-install.json을 만들어 검증을 통과한 뒤 사용했습니다.

여기서 하나 짚을 점이 있습니다. Gemma 4는 Hugging Face gated 모델이라 이용약관 동의가 필요합니다. 동의하지 않고 받으려 하면 실패하는데, 그때 HF_TOKEN 설정이 필요합니다.

서버 실행과 사용법

에이전트 연동은 OpenAI 호환 서버를 사용했습니다. 64K 컨텍스트로 띄우는 명령은 아래와 같습니다.

TurboFieldfareServer --model scratch/gemma4.gturbo --port 8080 --max-context 65536

CLI는 채팅 형식의 메시지 파일을 넣는 방식이 권장됩니다. raw prompt를 그대로 넣으면 반복 루프가 생길 수 있어서, --messages-file로 JSON을 넘기는 쪽이 안정적이었습니다.

TurboFieldfareCLI --model scratch/gemma4.gturbo --messages-file <json> --max-new 256 --temperature 0.2

실측 성능

이번 측정은 두 가지 실험으로 나눠서 진행했습니다. 첫 번째는 생성 속도, 두 번째는 prefill에서 콜드 캐시와 웜 캐시를 비교하는 것입니다.

생성 속도 (decode)

항목	값
CLI chat format, 256 토큰	6.26 tok/s (prefill 61 tok, TTFT 약 5.1초)
참조: 8GB M2 MacBook Air	5.1~6.3 tok/s
참조: 24GB M5 Pro	31~35 tok/s

M4 16GB의 생성 속도는 M2급이었습니다. M5 Pro 대비 약 1/5입니다. 이 런타임은 SSD 스트리밍 구조라 M4의 10코어 GPU로는 M2급 성능에 머물렀습니다.

Prefill: 콜드 vs 웜

같은 3,015토큰 프롬프트를 curl로 반복 측정했습니다.

조건	소요	prefill 속도
콜드 캐시 (첫 읽기)	7.5분+ (완료 못 함)	약 6~7 tok/s
웜 캐시, 64K 컨텍스트	125초	약 24 tok/s
웜 캐시, 16K 컨텍스트	122초	약 25 tok/s

이 표에서 두 가지가 분명해졌습니다.

64K와 16K 컨텍스트의 속도 차이가 없습니다. 컨텍스트 크기는 병목이 아닙니다.
콜드 첫 읽기가 웜 대비 3~4배 느립니다. 외장 SSD에서 expert를 처음 스트리밍할 때의 접근 비용이 지배적입니다.

측정 장비는 PCIe NVMe 외장 SSD였습니다. 캐시 히트 시 6.3GB/s지만, 콜드 랜덤 읽기는 실효 10~20MB/s 수준으로 떨어졌습니다. 서버를 재시작하면 캐시가 리셋되므로 첫 요청이 다시 느려집니다. 같은 외장 SSD는 원래 영상 생성 작업의 기본 폴더로 쓰는 장비라, 디스크 자체가 느린 것이 아니라 랜덤 접근에서 이 구조가 취약하다는 뜻입니다.

메모리

설정	값
64K 컨텍스트 서버 물리 풋프린트	약 3.2GB
KV 캐시 16K	약 0.5GiB
KV 캐시 32K	약 0.85GiB
KV 캐시 64K	약 1.5GiB

KV 캐시는 full-attention 5개 레이어만 컨텍스트에 선형으로 증가하고, sliding-window 25개 레이어는 1,152-row 링 캐시로 고정됩니다. 16GB 머신에서는 어떤 컨텍스트도 메모리 문제가 없었습니다.

Hermes 에이전트 연동 시도

로컬 에이전트 후보로 실제로 붙여봤습니다. 구성은 OpenAI 호환 서버를 127.0.0.1:8080에 띄우고, 프로필에서 context_length: 65536, max_tokens: 1024로 잡았습니다.

핵심 최적화는 보조 작업의 라우팅이었습니다. 압축, 제목 생성, 승인, 웹 추출 같은 auxiliary 작업을 로컬 모델이 아니라 별도 fallback 모델로 고정했습니다. 로컬 모델이 64K 압축을 맡으면 수십 분이 걸리기 때문입니다. 턴당 컨텍스트가 무한정 커지지 않도록 tool_output.max_bytes: 20000도 걸어뒀습니다.

문제는 첫 턴에서 드러났습니다. Hermes 첫 턴 프롬프트가 약 12K 토큰이었는데, 이 크기에는 시스템 프롬프트 31.5KB와 30개 도구의 스키마가 포함됩니다. 콜드 상태에서 35분 이상, 웜 상태에서도 20분 이상 걸렸습니다. “하이” 한 마디에 prefill 39분이 걸리는 상황에서는 에이전트 대화가 성립하지 않습니다.

추가로 서버가 단일 생성 + 대기열 4 구조라, 클라이언트가 끊겨도 고아 요청이 계속 생성됐습니다. 해소는 프로세스 재시작뿐이었습니다. 서버가 SIGINT·SIGTERM을 무시하고 멈추지 않으면 프로세스를 확인한 뒤 SIGKILL로 정리했습니다.

운영 메모

재현할 사람을 위해 정리한 항목입니다.

- 서버는 Terminal 창에서 직접 실행해야 세션 종료 후에도 유지된다
- 서버 재시작 후에는 큰 프롬프트로 한 번 워밍업하면 이후 턴이 빨라진다
- 하나의 모델 프로세스만 실행한다 (서버/앱/CLI 동시 실행 금지)
- CLI는 messages-file 형식을 쓴다 (raw prompt는 반복 루프 가능)
- 클라이언트가 끊긴 뒤에도 생성이 계속되면 프로세스를 확인하고 정리한다

결론이 바뀐 지점

이 실험에서 알게 된 것은 “26B 모델이 16GB에서 도는가”가 아니라, 도는 방식이 무엇을 결정하는가였습니다.

메모리는 작아도 응답 시간은 별개입니다. expert 스트리밍 구조는 디스크 읽기 지연을 그대로 응답 지연으로 옮깁니다.
내장 SSD로 옮기면 콜드 첫 턴만 일부 개선됩니다. 근본 생성 속도는 M4 GPU 한계라 바뀌지 않습니다.
로컬 에이전트로 쓸 16GB 머신은 4B급 작은 모델이 더 현실적입니다. 메모리 여유보다 턴당 지연이 먼저입니다.

짧은 단발 프라이빗 채팅용으로는 쓸 만한 선택지입니다. 연속 대화는 prompt cache 덕분에 첫 턴 이후 빨라지고, 2GB 메모리라 다른 작업과 병행하기도 부담이 적습니다. 다만 첫 응답까지 5~10분을 기다릴 수 있을 때의 이야기입니다.

실측 성능

생성 속도 (decode)

항목	값
CLI chat format, 256 토큰	6.26 tok/s (prefill 61 tok, TTFT 약 5.1초)
참조: 8GB M2 MacBook Air	5.1~6.3 tok/s
참조: 24GB M5 Pro	31~35 tok/s

M4 16GB의 생성 속도는 M2급이었습니다. M5 Pro 대비 약 1/5입니다.

Prefill: 콜드 vs 웜

같은 3,015토큰 프롬프트를 curl로 반복 측정했습니다.

조건	소요	prefill 속도
콜드 캐시 (첫 읽기)	7.5분+ (완료 못 함)	약 6~7 tok/s
웜 캐시, 64K 컨텍스트	125초	약 24 tok/s
웜 캐시, 16K 컨텍스트	122초	약 25 tok/s

이 표에서 두 가지가 분명해졌습니다.

64K와 16K 컨텍스트의 속도 차이가 없습니다. 컨텍스트 크기는 병목이 아닙니다.
콜드 첫 읽기가 웜 대비 3~4배 느립니다. 외장 SSD에서 expert를 처음 스트리밍할 때의 접근 비용이 지배적입니다.

측정 장비는 PCIe NVMe 외장 SSD(OWC_1M2)였습니다. 캐시 히트 시 6.3GB/s지만, 콜드 랜덤 읽기는 실효 10~20MB/s 수준으로 떨어졌습니다. 서버를 재시작하면 캐시가 리셋되므로 첫 요청이 다시 느려집니다.

메모리

설정	값
64K 컨텍스트 서버 물리 풋프린트	약 3.2GB
KV 캐시 16K	약 0.5GiB
KV 캐시 32K	약 0.85GiB
KV 캐시 64K	약 1.5GiB

Hermes 에이전트 연동 시도

로컬 에이전트 후보로 실제로 붙여봤습니다. 구성은 OpenAI 호환 서버를 127.0.0.1:8080에 띄우고, context_length: 65536, max_tokens: 1024로 잡았습니다. 압축·제목 생성·승인·웹 추출 같은 보조 작업은 로컬 모델이 아니라 별도 fallback 모델로 고정했습니다. 로컬 모델이 64K 압축을 맡으면 수십 분이 걸리기 때문입니다.

문제는 첫 턴에서 드러났습니다. Hermes 첫 턴 프롬프트가 약 12K 토큰이었는데, 콜드 상태에서 35분 이상, 웜 상태에서도 20분 이상 걸렸습니다. “하이” 한 마디에 prefill 39분이 걸리는 상황에서는 에이전트 대화가 성립하지 않습니다.

추가로 서버가 단일 생성 + 대기열 4 구조라, 클라이언트가 끊겨도 고아 요청이 계속 생성됐습니다. 해소는 프로세스 재시작뿐이었습니다.

결론이 바뀐 지점

이 실험에서 알게 된 것은 “26B 모델이 16GB에서 도는가”가 아니라, 도는 방식이 무엇을 결정하는가였습니다.

메모리는 작아도 응답 시간은 별개입니다. expert 스트리밍 구조는 디스크 읽기 지연을 그대로 응답 지연으로 옮깁니다.
내장 SSD로 옮기면 콜드 첫 턴만 일부 개선됩니다. 근본 생성 속도는 M4 GPU 한계라 바뀌지 않습니다.
로컬 에이전트로 쓸 16GB 머신은 4B급 작은 모델이 더 현실적입니다. 메모리 여유보다 턴당 지연이 먼저입니다.

확인하지 못한 것

M2/M5 Pro 참조값은 저장소와 공개 기록 기준입니다. 같은 조건에서 다시 측정하지 않았습니다.
내장 SSD로 옮긴 뒤의 전체 측정은 하지 않았습니다. 첫 턴 개선만 부분 확인했습니다.
장문 한국어 출력 품질과 다중 사용자 동시 요청은 별도 검증이 필요합니다.

자주 받는 질문

이 모델을 에이전트로 쓸 수 있나요?

제 환경에서는 아니었습니다. 첫 턴 12K 토큰 기준 콜드 35분+, 웜 20분+이었습니다. 도구 호출 지원은 있지만 대화 속도가 문제입니다.

메모리가 2GB면 가볍다고 봐야 하나요?

상주 메모리는 그렇습니다. 하지만 응답 속도는 별개입니다. 외장 SSD 콜드 읽기에서 3~4배 느려지는 구조라, “가볍다”와 “빠르다”를 분리해서 봐야 합니다.

내장 SSD로 옮기면 해결되나요?

첫 턴(콜드)만 일부 개선됩니다. decode 6~7 tok/s와 웜 prefill은 M4 GPU 한계라 그대로입니다.

함께 읽을 글

M4 Mac mini 16GB에서 Bonsai 27B 실험 — 세 엔진을 같은 조건으로 비교한 기록
Gemma 4 12B를 M4 Mac mini 16GB에서 먼저 돌려본 기록 — 로드 가능 여부와 실사용 가능 여부를 분리한 기록
로컬 LLM 실험을 시작하기 전에 정한 기준 — 이 실험의 전제가 된 체크리스트

참고한 문서

drumih/turbo-fieldfare — Apache 2.0, Swift/Metal 런타임
mlx-community/gemma-4-26b-a4b-it-4bit — gated 모델, 이용약관 동의 필요

기준일은 2026년 7월 31일입니다. 런타임 버전과 모델 포맷은 빠르게 바뀌므로, 실제로 돌리기 전에는 저장소의 최신 문서를 다시 확인해야 합니다.