애플 실리콘 맥에서 젬마 4 26B를 램 2GB로 돌리는 오픈소스 엔진 등장

26B 모델을 2GB 메모리 예산에 욱여넣은 프로젝트

• TurboFieldfare는 Gemma 4 26B-A4B instruction 모델을 애플 실리콘 맥에서 약 2GB RAM으로 돌리는 커스텀 런타임임

  • 전체 모델 설치 크기는 약 14.3GB지만, 이걸 통째로 메모리에 올리지 않음
  • 메모리에는 1.35GB짜리 공유 코어와 FP16 KV cache를 두고, 토큰마다 필요한 전문가 가중치만 SSD에서 읽어옴
  • 타깃은 애플 실리콘 맥이고, 검증 기준은 8GB M2 맥북 에어임

• 이게 가능한 이유는 Gemma 4 26B-A4B가 MoE 구조라서임

  • 총 파라미터는 26B지만 토큰당 활성화되는 파라미터는 약 3.88B 수준임
  • 모든 전문가를 매번 쓰는 게 아니라 router가 고른 top-8 전문가만 필요함
  • TurboFieldfare는 바로 이 “필요한 전문가만 읽는다”는 점을 SSD 스트리밍으로 밀어붙임

• 구현은 Swift와 Metal로 직접 짠 네이티브 런타임임
  • MLX나 llama.cpp를 감싼 래퍼가 아니라 모델 특화 런타임임
  • Swift 라이브러리, 네이티브 맥 앱, CLI, 디코드 서비스, OpenAI 호환 로컬 서버, 스트리밍 repack 설치 도구를 제공함
  • macOS 26, Metal 4, Swift 6.2 이상이 필요하고 arm64 전용임

성능과 제약

• 벤치마크는 꽤 솔직하게 “참고점이지 상한선은 아니다”라고 못박고 있음

  • 8GB M2 맥북 에어에서는 decode 5.1-6.3토큰/초
  • 24GB M5 Pro에서는 decode 31-35토큰/초
  • 프롬프트 길이, 생성 길이, 페이지 캐시 상태, 하드웨어에 따라 처리량이 달라짐

• 모델 가중치는 꽤 공격적으로 압축되어 있음

  • MLX affine 4-bit, group 64 가중치를 사용함
  • router는 8-bit, shared expert와 routed expert는 4-bit임
  • 4K KV cache와 약 2GB 가중치 메모리 사용을 기준으로 설명됨

• 기능 범위는 텍스트 전용임

  • 이미지, 오디오, 비디오는 지원하지 않음
  • 맥 앱과 CLI는 사용자 메시지, 모델 메시지, 선택적 시스템 지시를 지원함
  • 로컬 서버는 함수 도구 선언을 받을 수 있지만, 실제 도구 실행은 클라이언트가 승인하고 실행해야 함

설치 흐름도 꽤 개발자스럽다

• 첫 실행 때는 모델을 다운로드하고 .gturbo 포맷으로 다시 패킹함

  • 앱에서 Download를 누르면 고정된 Hugging Face revision에서 필요한 byte range를 가져옴
  • 전체 원본 체크포인트를 디스크에 한 번 더 만들지 않고, 도착하는 대로 .gturbo 레이아웃에 repack함
  • 다운로드는 약 15GB, 최종 설치는 약 14.3GB이며 manifest와 파일 해시 검증을 통과해야 완료로 인정됨

• CLI와 앱은 같은 .gturbo 모델 디렉터리를 사용함

  • 맥 앱으로 설치했다면 기본 경로는 scratch/gemma4.gturbo임
  • CLI는 --messages-file로 chat message 배열을 받아 앱과 같은 방식으로 포맷팅함
  • --prompt는 raw completion용이고, instruction-response 대화에는 --messages-file을 쓰는 식으로 구분됨

• 로컬 OpenAI 호환 서버도 제공함

  • Chat Completions, 스트리밍, function tool declaration, single-prefix prompt reuse를 지원함
  • 기존 OpenAI API 클라이언트나 로컬 코딩 도구와 붙여보기 좋지만, 지원 API는 부분집합임

내부 구조가 진짜 흥미로운 부분

• 각 transformer layer에서 Metal은 attention과 router를 resident weight로 계산함

  • CPU는 router가 고른 top-8 expert ID를 받아 각 layer의 16-slot LFU cache를 기준으로 miss를 계획함
  • miss가 나면 bounded parallel pread로 SSD에서 Metal-visible buffer로 전문가 가중치를 채움
  • 그동안 Metal은 resident shared-expert branch를 계산하고, 이후 shared output과 routed output을 합침

• prefill과 decode도 SSD 스트리밍에 맞게 설계되어 있음

  • prompt prefill은 최대 128토큰 chunk로 처리해서 한 번 가져온 expert가 여러 row에 쓰이게 함
  • generation은 토큰 하나씩 routed layer loop를 반복함
  • installer도 같은 원칙으로 원격 range를 바로 .gturbo에 repack해서 shard나 tensor 전체를 staging하지 않음

• KV 저장도 모델 구조에 맞춰 나눠둠

  • 25개 sliding-window layer는 bounded circular storage를 사용함
  • 5개 full-attention layer는 linear storage를 사용함
  • decode attention은 normalized K와 V 경로를 분리한 exact split-K/V 방식이라고 설명됨

---

기술 맥락

• 이 프로젝트의 핵심 선택은 “큰 모델을 줄인다”가 아니라 “지금 필요한 가중치만 가져온다”예요. Gemma 4 26B-A4B가 MoE 구조라서 토큰마다 모든 전문가를 쓰지 않는다는 점을 시스템 설계로 끌고 온 거죠.

• 왜 SSD 스트리밍을 택했는지도 명확해요. 8GB 맥에서는 14.3GB 모델을 통째로 메모리에 올리는 순간 게임이 끝나니까, 공유 코어와 KV cache만 메모리에 남기고 routed expert는 필요할 때 읽는 방식으로 메모리 병목을 피한 거예요.

• Metal을 직접 쓴 이유도 단순 취향만은 아니에요. router, attention, quantized GEMV, MoE 계산을 모델 구조에 맞춰 촘촘하게 제어해야 SSD 읽기와 GPU 계산을 겹칠 수 있거든요. 범용 런타임 위에서 이 정도로 특정 모델에 맞춘 스케줄링을 하기는 쉽지 않아요.

• LFU expert cache가 들어간 것도 중요해요. 매 토큰마다 SSD를 무작정 읽으면 지연이 커지니까, layer마다 16-slot cache를 두고 자주 쓰는 expert를 남겨서 읽기 비용을 줄이려는 거예요.

• 실무 제품으로 바로 쓰기보다는 온디바이스 추론 설계 사례로 보는 게 좋아요. 메모리가 작은 클라이언트 기기에서 MoE 모델을 굴릴 때, 양자화만으로 안 되는 구간을 I/O 스케줄링과 캐시 설계로 풀 수 있다는 걸 보여주거든요.