TurboFieldfare - 모든 M 시리즈 Mac에서 Gemma 4 26B를 2GB RAM으로 실행하는 오픈소스 엔진

 (github.com/drumih)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 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를 전체 메모리에 적재하지 않음
    • 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의 후원·승인을 받은 프로젝트가 아닌 독립 연구 프로젝트임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 왜 매번 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를 갖춘 시스템이라면 이런 기법으로 초대형 모델도 실행할 수 있기를 기대함

답변달기