# TurboFieldfare - 모든 M 시리즈 Mac에서 Gemma 4 26B를 2GB RAM으로 실행하는 오픈소스 엔진 > Clean Markdown view of GeekNews topic #31958. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31958](https://news.hada.io/topic?id=31958) - GeekNews Markdown: [https://news.hada.io/topic/31958.md](https://news.hada.io/topic/31958.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-30T03:32:03+09:00 - Updated: 2026-07-30T03:32:03+09:00 - Original source: [github.com/drumih](https://github.com/drumih/turbo-fieldfare) - Points: 1 - Comments: 1 ## Topic Body - **TurboFieldfare**는 전체 14.3GB 모델을 메모리에 올리지 않고 Gemma 4 26B-A4B를 약 2GB의 메모리로 실행해, 8GB Apple Silicon Mac에서도 로컬 추론이 가능함 - 1.35GB 공유 코어와 FP16 KV 캐시만 상주시킨 뒤 토큰마다 필요한 **MoE 전문가 가중치**를 SSD에서 스트리밍하며, 16슬롯 LFU 캐시와 병렬 `pread`로 입출력을 제한함 - Gemma 4 26B-A4B는 토큰당 약 3.88B 파라미터를 활성화하며, 측정된 디코딩 속도는 8GB M2 MacBook Air에서 **5.1~6.3 tok/s**, 24GB M5 Pro에서 31~35 tok/s임 - Swift 6.2와 Metal 4로 구현된 전용 런타임이며, 네이티브 Mac 앱·CLI·설치 도구·실험적 **OpenAI 호환 서버**를 동일한 `.gturbo` 모델 디렉터리 위에서 제공함 - 현재 범위는 macOS 26 이상과 최소 8GB RAM을 갖춘 Apple Silicon Mac의 **텍스트 전용 추론**으로 한정되며, 이미지·음성·영상과 원격 서버 인증·TLS는 지원하지 않음 --- ### 메모리를 줄이는 실행 구조 - TurboFieldfare는 instruction-tuned [Gemma 4 26B-A4B](https://ai.google.dev/gemma/docs/core/model_card_4)를 전체 메모리에 적재하지 않음 - **1.35GB 공유 코어**와 FP16 KV 캐시는 메모리에 유지함 - 각 토큰에 필요한 routed expert만 SSD에서 Metal이 볼 수 있는 버퍼로 읽음 - 설치된 텍스트 전용 모델은 약 14.3GB지만, 가중치와 4K KV 캐시가 사용하는 메모리는 약 2GB임 - 모델은 총 26B 파라미터 가운데 토큰당 약 **3.88B 파라미터**를 활성화함 - 가중치는 group 64 기반 MLX affine 4비트를 사용하며, router는 8비트, 공유 및 routed expert는 4비트임 - MLX나 llama.cpp를 감싼 구성이 아니라 Gemma 4 26B-A4B에 맞춰 만든 **Swift·Metal 전용 런타임**임 ### 토큰 생성 과정 - 각 Transformer 레이어에서 Metal이 상주 가중치로 attention과 router를 계산함 - CPU는 router가 선택한 **상위 8개 expert ID**를 레이어별 16슬롯 LFU 캐시와 대조함 - 캐시 미스는 제한된 수의 병렬 `pread` 호출로 채움 - SSD 읽기가 진행되는 동안 Metal은 상주하는 shared-expert 분기를 계산함 - 읽기가 끝나면 shared output과 routed output을 결합함 - 프롬프트 prefill은 최대 **128토큰 청크**를 사용해 한 번 가져온 expert가 여러 행을 처리할 수 있게 함 - 생성 단계에서는 routed layer 루프를 토큰 단위로 반복함 - KV 캐시는 25개 sliding-window layer에 제한된 순환 저장소를, 5개 full-attention layer에 선형 저장소를 사용함 - 디코딩 attention은 정규화된 K와 V 경로를 분리한 exact split-K/V 방식임 ### 설치와 모델 형식 - 첫 실행에서 **Download**를 선택하면 고정된 Hugging Face revision에서 약 15GB를 범위 요청으로 내려받음 - 설치기는 원본 체크포인트 전체를 임시 파일이나 메모리에 만들지 않음 - 필요한 바이트 범위를 받아 곧바로 `.gturbo` 레이아웃으로 재패킹함 - 전체 shard나 tensor를 별도로 준비하지 않아 임시 메모리 사용량이 제한됨 - 완성된 설치본은 manifest와 파일 해시 검증을 통과해야 사용할 수 있음 - 설치 완료 후 모델은 약 **14.3GB 저장 공간**을 차지하며, 설치 과정 자체는 모델을 메모리에 로드하지 않음 - 런타임은 최종 `manifest.json`이 있는 완성된 `.gturbo` 디렉터리만 허용함 - 중단된 다운로드 재개, 부분 다운로드 상태 삭제, 모델을 로드하지 않는 설치 검증을 지원함 ### 실행 환경과 성능 - 요구 환경은 Apple Silicon Mac, macOS 26, Metal 4, Xcode 26, Swift 6.2 이상임 - 패키지는 **arm64 전용**이며 이전 macOS와 Metal 버전은 지원하지 않음 - 검증 대상은 8GB M2 MacBook Air이며 모델 설치를 위한 여유 저장 공간과 최초 다운로드용 인터넷 연결이 필요함 - 측정된 디코딩 성능은 다음과 같음 - 8GB M2 MacBook Air: **5.1~6.3 tok/s** - 24GB M5 Pro: 31~35 tok/s - 처리량은 프롬프트 길이, 생성 길이, 페이지 캐시 상태, 하드웨어에 따라 달라지므로 측정치는 성능 상한이 아닌 기준점임 - 모델 실행 전 메모리를 많이 쓰는 앱을 닫고 `memory_pressure -Q`로 여유 메모리를 확인해야 함 - 앱, decode service, CLI, 서버, 테스트 또는 다른 로컬 모델 프로세스는 한 번에 하나만 실행해야 함 ### 제공 제품과 사용 방식 - Swift 패키지는 여섯 제품을 제공함 - `TurboFieldfare`: 런타임과 Metal 커널을 포함한 Swift 라이브러리 - `TurboFieldfareMac`: 설치와 생성을 위한 네이티브 Mac 앱 - `TurboFieldfareDecodeService`: Mac 앱이 사용하는 일회성 로컬 모델·Metal 소유 프로세스 - `TurboFieldfareCLI`: 명령행 instruction chat 및 raw completion - `TurboFieldfareServer`: loopback OpenAI 호환 Chat Completions 서버 - `TurboFieldfareRepack`: 스트리밍 설치 및 설치 검증 도구 - Mac 앱에서는 모델을 내려받은 뒤 **Load Model**을 선택하고 프롬프트를 입력해 생성함 - 상태 표시줄에서 진행 상황, 디코딩 속도, 메모리 사용량을 확인할 수 있음 - sampling, context length, expert-cache slot과 런타임 옵션을 조정할 수 있음 - CLI의 instruction chat은 JSON 메시지 배열을 받아 Mac 앱과 같은 형식으로 변환함 - 응답 한도인 `--max-new`의 기본값은 1,024토큰임 - Mac 앱은 선택한 context window가 가득 찰 때까지 생성할 수 있음 - `--prompt`는 채팅 형식을 적용하지 않는 **raw completion**과 재현 가능한 비교에 사용함 - 생성 텍스트는 표준 출력, 시간 통계는 표준 오류로 보내며 `--quiet`로 통계 출력을 끌 수 있음 ### 프롬프트와 지원 범위 - Mac 앱은 입력을 instruction으로 처리하고 Gemma의 채팅 형식을 자동 적용함 - 기본 sampling 설정은 temperature `0.2`, Top-K `64`, Top-P `0.95`임 - temperature를 `0`으로 설정하면 결정론적 greedy output을 사용함 - 모델은 반복하거나 잘못 답할 수 있으므로 중요한 결과는 확인해야 함 - 앱과 CLI는 사용자·모델 메시지와 선택적 system guidance를 지원하지만 **도구를 노출하거나 실행하지 않음** - 현재 모델 입출력은 텍스트 전용이며 이미지, 오디오, 비디오는 지원하지 않음 - CLI는 `--max-context`, `--temperature`, `--top-k`, `--top-p`, `--repetition-penalty`, `--seed`, 반복 가능한 `--stop` 문자열을 제공함 ### OpenAI 호환 로컬 서버 - 실험적 서버는 `127.0.0.1:8080/v1`에서 실행되며 **Chat Completions**, 스트리밍, 함수 도구 선언, 단일 prefix 프롬프트 재사용을 지원함 - 서버는 모델이 만든 tool call을 반환하지만, 모든 도구 호출의 승인과 실행은 클라이언트가 담당함 - 원격 인증과 TLS가 없으므로 서버를 **loopback에만 유지**해야 함 - Mac 앱, CLI, 서버는 같은 `.gturbo` 디렉터리를 사용하지만 모델을 소유하는 제품은 동시에 하나만 실행해야 함 ### 구현 범위와 실험 기록 - 커스텀 Metal 커널은 양자화 GEMV, attention, MoE, normalization, RoPE, sampling과 프로덕션 fusion을 처리함 - 런타임은 SSD 기반 routed-expert 스트리밍, 제한된 expert 캐시, 청크 단위 단일 프롬프트 prefill, 토큰 단위 생성을 구현함 - 커널, 캐싱, 입출력, prefill, decode에 걸친 **103개 측정 결과**를 실험 기록으로 관리함 - 실험 문서는 효과가 컸던 최적화, 실패한 아이디어, 더 강한 검증 후 뒤집힌 초기 결과를 포함함 - 향후 작업은 iPhone·iPad 앱 개발과 모바일 추론 속도·메모리 측정, 16GB M4 Mac mini 및 다른 8GB Apple Silicon Mac의 벤치마크임 ### 라이선스와 모델 조건 - 소스 코드와 문서는 **Apache License 2.0**으로 배포됨 - 모델 가중치는 저장소에 포함되지 않으며 설치기가 고정된 Hugging Face 체크포인트에서 별도로 내려받음 - 가중치에는 원본 배포 조건이 계속 적용됨 - TurboFieldfare는 Google과 제휴하거나 Google의 후원·승인을 받은 프로젝트가 아닌 **독립 연구 프로젝트**임 ## Comments ### Comment 62595 - Author: neo - Created: 2026-07-30T03:32:05+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=49098510) - 왜 매번 Charles 왕이 누군지까지 필요하다며 **모델 전체를 메모리**에 밀어 넣는지 늘 의문이었음. 큰 파일을 잘게 나눠 적은 메모리로 효율적으로 읽는 기술은 이미 확립됐다고 봄 최첨단 AI 업계에는 모델 제작엔 뛰어나지만 규모 확장성과 실용성은 인프라 담당자에게 떠넘기는 경향이 있어 보임. 실제로 쓰는 지식이 10% 미만이라면 미세조정과 최적화만으로 비용을 크게 낮출 수도 있을 듯함 - 모델 전체를 메모리에 두는 편이 디스크와 교환하는 것보다 훨씬 빠름 - 사실상 **전문가 혼합(MoE) 구조**를 설명한 셈임. 전문가 계층이 충분히 작고 SSD가 빠르면 필요할 때만 불러올 수 있음 밀집형 LLM은 보통 성능이 더 좋지만, 계층을 외부 저장소로 내보내면 MoE보다 훨씬 크게 느려짐 - 요즘은 출처를 모르는 프로젝트를 내려받을 때 이런 **보안 검토**를 직접 돌려야 함. 저장소의 에이전트 지시와 Markdown 파일을 무시하고 Swift/Metal 소스, 빌드 스크립트, CI 설정, 의존성을 검사하게 했더니 악성 코드·백도어·자격 증명 탈취·숨은 네트워크 엔드포인트는 찾지 못했지만, 컴파일·공급망·런타임 위험은 여전히 남는다는 결과가 나왔음 더 좋은 프롬프트가 있다면 공유해도 좋겠고, Cursor의 Composer 2.5로 실행한 비용은 **0.20달러 미만**이었음 - M1 MacBook Air에서 macOS 15를 쓴다면 다음 두 줄을 삭제하거나 `if #available(macOS 26.0, *)`로 감싸면 컴파일됨: `opts.languageVersion = .version4_0` 주석에 따르면 어텐션이 11.24배 빨라져 사전 채우기가 2.4배 가속되는 효과는 놓치지만, 8코어 GPU M1 Air에서 **초당 5~6토큰**은 나옴 - 유용한 정보임. 나중에 최소 지원 버전을 낮춰볼 수도 있겠음 **2.4배 사전 채우기 개선**은 apple10 GPU 계열에서만 작동하며, M1은 기억상 apple7임 - 이 프로젝트가 평범한 **`mmap`** 과 어떻게 비교되는지 궁금함. llama.cpp도 `mmap`을 켜고 재패킹을 끄면 원할 경우 26B 모델을 2GB RAM에서 실행할 수 있음 핵심 차이는 SSD 읽기를 추론 작업과 동기화해 지연을 최소화했다는 점으로 보이며, 운영체제는 이런 실행 맥락을 고려하지 않음 - 첫 버전은 `mmap`을 사용했음. 8GB M2에서 차가운 상태의 3.36MB 전문가를 읽는 데 `mmap`은 10ms, **`pread`는 2.8ms**가 걸렸고 전체 시뮬레이션은 각각 초당 0.50토큰과 4토큰이었음 `mmap`에서는 모델이 페이지를 건드릴 때 운영체제가 사후 대응으로 읽기 때문에 어떤 전문가가 선택됐는지, 언제 GPU 작업과 읽기를 겹칠 수 있는지 알지 못함. 공통 가중치는 단순성을 위해 여전히 `mmap`을 사용하며, llama.cpp도 2GB 미만에서 돌 수는 있겠지만 더 느릴 것으로 봄 - 실제 속도를 확인하려면 llama.cpp의 **SSD 오프로딩**과 직접 비교해 보고 싶음 - “측정 결과는 기준점이지 성능 상한이 아니다”라는 문장은 **Claude 특유의 표현**처럼 보임 - 이런 표현이 너무 널리 퍼져 Claude식 문체를 계속 읽다가 나도 같은 버릇을 익힐까 걱정될 정도임 - “100번 넘게 실험했고 대부분 실패했지만 일부가 여기까지 이끌었다”도 같은 흔적처럼 보임 - 원래는 ChatGPT식 표현이었을 가능성이 크지만, 그렇다고 서구 기업을 증류했다고 몰아가지는 않겠음. 2022년 이후의 레시피 블로그가 4.6~4.8 무렵 학습 데이터에 들어갔을 수도 있음 - 이제 이런 판별은 그만할 때가 됐다고 봄. 새 형태의 **문법 경찰**과 다를 바 없고 별 가치도 더하지 못함 저자가 LLM으로 문장만 다듬었고 쓸데없는 내용이 추가되지 않았다면 상관없음. 글 자체가 쓸모없는 생성물이라면 그냥 낮은 점수를 주면 됨 - 더 빠른 SSD를 장착한 M1 Max Mac Studio에서 **초당 12토큰**과 거의 즉각적인 응답이 나오는 건 인상적임. 대형 모델을 메모리가 아니라 SSD에서 직접 구동할 가능성을 보여줌 - 아쉽게도 여기서는 **SSD 읽기 속도**가 가장 큰 병목임 - 요즘 SSD 스트리밍 엔진은 많지만 어려운 기능까지 시도하는 경우는 드묾. 주요 모델에 추측 디코딩용 **MTP 헤드**가 있으므로 이를 SSD의 전문가 가중치를 미리 읽는 데 활용할 수 있음 GPU가 필요로 하기 전에 가중치를 준비하면 VRAM 캐시 미스 비용을 크게 줄일 수 있으며, 효과가 입증되면 향후 모델은 전문가를 미리 불러오는 전용 헤드를 갖추고 학습 단계부터 이를 고려할 수도 있음 - SSD 스트리밍에서는 GPU가 올바른 전문가를 가져올 때까지 거의 항상 SSD를 기다리므로, SSD 쪽에는 미리 읽을 여유가 사실상 없음. 잘못 예측한 전문가를 읽으면 오히려 손해이며, 이 때문에 일반적인 비대규모 배치 환경에서는 기존 **MTP도 별 도움이 안 됨** - 실제로는 생각보다 어려움. 계층마다 전문가 집합이 다르고, 작은 라우터가 아래 계층 전문가의 출력 상태를 보고 사용할 전문가를 정함 MTP가 만든 초안 토큰으로 첫 계층의 전문가까지는 예측할 수 있지만, 10번째 계층을 알려면 1~9번째 계층을 실행하며 해당 전문가들을 먼저 읽어야 함. 따라서 다음 토큰 생성기 대신 **모든 계층의 전문가 활성화**를 한꺼번에 예측하도록 학습된 장치가 필요함 - DiffusionGemma를 실행하는 프로젝트도 거의 준비됐으며 두 프로젝트를 결합하면 잘 맞을 수 있음. 36GB M3에서 **초당 약 20토큰**이 나오고 서로 더 빠른 커널을 가져다 쓸 가능성도 큼 현재 코드는 [https://github.com/mmastrac/diffgemma]()에 있지만 아직 배포 가능한 상태는 아님 - 최근 살펴봤지만 확산 모델을 로컬에서 실행하는 건 실익이 적다고 판단했음: [https://eamag.me/2026/why-parallel-diffusion-llms-are-slow-o...]() 이에 대한 생각이 궁금함 - Diffusion Gemma가 프로젝트 중간에 나와 전환을 진지하게 고려했지만 기존 방향으로 마무리하기로 했음. 두 프로젝트는 **아주 잘 맞을 것**으로 보이며, 필요한 코드는 자유롭게 사용하거나 README 끝의 LinkedIn으로 연락해도 됨 - 8GB M2 MacBook Air의 초당 5~6토큰과 M5 MacBook Pro의 31~35토큰 사이에 왜 이렇게 큰 차이가 나는지 궁금함. SSD 성능 차이가 그 정도로 클 것 같지는 않지만, 이 방식에서는 SSD가 지배적인 병목일 것으로 예상했음 - M5 SSD의 성능 향상은 이전 세대와 비교해도 상당함. Blackmagic Disk Speed Test에서 M5 MacBook Pro는 최대 **6,323MB/s**, M4 MacBook Pro는 2,031MB/s를 기록해 3배 이상 차이 났음 [https://www.tomshardware.com/laptops/macbooks/m5-macbook-pro...]() - M5의 메모리가 더 많아 운영체제가 파일 대부분을 이미 캐시했기 때문일 가능성이 큼. M2는 메모리 압박이 커서 SSD 읽기 결과를 덜 캐시할 것임 운영체제 캐시까지 포함해 총 2GB만 쓸 수 있다면 추론 속도는 더 낮아질 수 있음 - 시스템 캐시와 `pread`에 상당히 의존함. 프로세스가 2GB 아래여도 M5 Mac이 일부를 캐시할 수 있고 하드웨어 자체도 훨씬 빠름 토큰당 읽기는 M2에서 83ms, M5 Pro에서 12ms였으며 전체 시간은 각각 **163ms와 30ms**였음. 읽기와 GPU 처리 모두 빨라진 결과임 - 세대가 오래돼 Pro끼리 비교해도 SSD가 훨씬 느리고, 같은 세대에서도 Air의 SSD와 메모리 대역폭이 Pro보다 낮을 가능성이 있음 - M5 MacBook Pro는 RAM이 24GB라서 더 많은 문맥을 메모리에 보관할 수도 있음 - 앞으로 **30~60GB 메모리와 매우 빠른 SSD**를 갖춘 시스템이라면 이런 기법으로 초대형 모델도 실행할 수 있기를 기대함 - Colibri와 Flash-MoE는 이미 이를 시도하고 있음 [https://github.com/danveloper/flash-moe]() [https://github.com/JustVugg/colibri]() - 64GB 통합 메모리라면 DeepSeek V4 Flash 양자화 모델을 초당 7~10토큰으로 실행할 수 있음 [https://github.com/antirez/ds4]() 또는 직접 만든 [https://github.com/steadfastgaze/MoEspresso]()를 사용할 수 있음. 메모리에 없는 다음 토큰용 전문가를 SSD에서 읽어야 하므로 속도는 **SSD 읽기에 제한**되고, 메모리가 클수록 추론이 빨라짐