世界を動かす技術を、日本語で。

Show HN: 2GB RAMで任意のMシリーズMac上で「Gemma 4 26B」を動かすオープンソースエンジン

2026年7月30日原文(github.com)

概要

TurboFieldfareは、Apple Silicon Mac(8GB RAM含む)上でGemma 4 26B-A4Bモデルを約2GBのRAMで動作可能にするSwift+Metal製ランタイム モデル全体(14.3GB)をRAMに読み込まず、必要なエキスパートのみSSDからストリーミング Macアプリ・CLI・OpenAI互換サーバを提供 独自のキャッシュ・ストリーミング・Metal最適化による高速化 実験・ベンチマーク・導入方法・仕組みも丁寧にドキュメント化

TurboFieldfare:Apple Silicon Mac向けGemma 4 26B-A4B推論エンジン

  • TurboFieldfare は、 Gemma 4 26B-A4B モデルを 約2GBのRAM で動作させるために開発された Swift+Metal製のカスタム推論エンジン
  • Apple Silicon Mac (M1/M2/M3/M4シリーズ、8GB RAMモデルも含む)で動作
  • モデル全体(約 14.3GB)をRAMに展開せず、 1.35GBのコア部分+FP16 KVキャッシュ のみ常駐
  • 各トークンごとに必要な エキスパートのみSSDからストリーミング し、RAM消費を抑制
  • CLI、ネイティブMacアプリ、OpenAI互換ローカルサーバ を提供

主な特徴

  • モデル固有設計 (MLXやllama.cppのラッパーではない独自実装)
  • 4-bit量子化済みGemma 4 26B-A4B (Instruction-tuned)をサポート
  • Metal最適化カーネル による高速推論
  • SSDバックエンドのエキスパートキャッシュ でRAM負荷を最小化
  • Swiftパッケージ として、アプリ・CLI・サーバなど6製品を同梱

動作要件

  • Apple Silicon Mac (8GB RAM以上、推奨M2以降)
  • macOS 26+Metal 4+Swift 6.2 以上
  • 14.3GB以上の空きストレージ
  • インターネット接続 (初回モデルダウンロード時のみ)
  • arm64専用 (Intel Macや古いmacOS/Metalは非対応)

インストールと実行手順

  • リポジトリをクローン し、Swiftでビルド
    git clone https://github.com/drumih/turbo-fieldfare.git
    cd turbo-fieldfare
    swift build -c release
    .build/release/TurboFieldfareMac
    
  • 初回起動でモデル(約15GB)をHugging FaceからストリーミングDL&再パック
  • .gturbo形式 で約14.3GBに圧縮保存、検証済みでのみ利用可能
  • アプリ起動後 :「Download」でモデル取得、「Load Model」で読み込み、プロンプト入力後「Generate」で生成開始

推論速度・性能

  • 8GB M2 MacBook Air :5.1〜6.3 tok/s
  • 24GB M5 Pro :31〜35 tok/s
  • 実測値は参考値 (プロンプト長、生成長、キャッシュ状態、ハードウェアで変動)

CLI・サーバ・その他機能

  • CLI :.gturboモデルを直接利用し、命令チャットや生テキスト生成が可能
    • JSON形式のメッセージ で命令チャット
    • 生プロンプト渡し にも対応
    • 生成オプション (max-context, temperature, top-k, top-p, seed等)を細かく指定可能
  • OpenAI互換ローカルサーバ
    • http://127.0.0.1:8080/v1 でChat Completions API提供
    • ストリーミング・ツールコール・プロンプト再利用 等に対応
    • 認証・TLSなし (ローカル利用前提)
  • テストスイート・ベンチマークガイド も同梱

技術的仕組み

  • 各トランスフォーマ層 でMetalがアテンション・ルーター計算を担当
  • CPU はルーター出力からエキスパートIDを選択し、LFUキャッシュを管理
  • SSDからエキスパート部分を並列preadで読み込み、GPUが共有部分を並列実行
  • プロンプトプリフィル は128トークン単位で分割し、エキスパートの重複利用を最適化
  • 推論時は1トークンずつストリーミング生成
  • インストーラも分割ダウンロード&即時再パック で一時ストレージ消費を最小化
  • .gturbo形式 でモデル格納、マニフェストとハッシュ検証で整合性担保

現状の範囲・今後の展望

  • テキスト生成専用 (画像・音声・動画非対応、ツール呼び出しはOpenAIサーバ経由のみ)
  • iPhone/iPad対応・さらなるMacでのベンチマーク も計画中
  • 実験記録・技術解説・ベンチマーク を詳細に公開

ライセンス・注意事項

  • Apache License 2.0 (ソース・ドキュメント)
  • モデル重みは付属せず、Hugging Faceから個別DL
  • Google非公式・独立研究プロジェクト
  • ライセンス・サードパーティ通知はTHIRD_PARTY_NOTICES.md参照

補足・作者について

  • 作者:Andrey Mikhaylov (iOS/Metalエンジニア、画像・動画・オンデバイスAI専門)
  • プロジェクト名の由来や実験記録 はGitHubに詳細掲載
  • フィードバック歓迎

参考リンク


導入・実行の要点まとめ

  • Mac 1台で大規模LLMを実用的に動かしたい場合の最適解
  • ストレージ負荷を最小限に、RAM 2GBでも26Bモデルが動作
  • Swift/Metalによる高効率設計と豊富な実験・検証記録
  • CLI/GUI/サーバまでワンストップで利用可能

Hackerたちの意見

現在、8GBのM2 MacBook Airでは5〜6 tok/s、M5 MacBook Proでは31〜35 tok/sを生成しています。この大きなパフォーマンスの差はどこから来るんだろう?SSDの性能差がそんなに大きいとは思えないし、SSDの性能が優位になると思ってたんだけど…。

M5 MBPは24GBのRAMを搭載してるから、RAMのコンテキストが関係してるのかな?

僕の推測では、M5がもっとメモリを持ってるからだと思う。OSがほとんどのファイルをキャッシュしてるんじゃないかな。M2はメモリの圧迫が大きくて、SSDの読み込みをあまりキャッシュできないかもしれない。もしそうなら、OSキャッシュを含めて合計2GBしかないと、推論速度はさらに遅くなるね。

M5のSSDの性能向上はかなり大きかったよ、前の世代と比べても。 > Blackmagic Disk Speed Testでは、M5 MacBook ProのSSDが最大6,323 MB/sの読み取り速度を達成したのに対し、M4 MacBook Proは2,031 MB/sだった。M4が「遅い」わけじゃないけど、M5のSSDは3倍以上速いから、素晴らしい世代の向上だね。 https://www.tomshardware.com/laptops/macbooks/m5-macbook-pro...

確かに、古いからProよりSSDが遅いし、Airも同じ世代のProよりSSD遅いんじゃなかったっけ?それにメモリ帯域幅も狭いかもね。

あなたのプロジェクトが普通のmmapとどう比較されるのか気になる! llama.cppは、実際にやれば2GBのRAMで26Bを動かせるからね(mmap有効、再パッキング無効)。主な違いは、あなたのプロジェクトがSSDの読み込みを推論アクティビティと同期させてることだと思うけど、それを最小限のレイテンシーで調整してるのかな?OSはそんなこと気にしないだろうし。

うん、SSDオフロードを使ったllamacppの比較を見てみたいな。実際の速度を比較するのに。

僕の最初のバージョンは普通のmmapを使ってた。8GBのM2では、コールドな3.36MBのエキスパートがmmapで10ms、preadで2.8msかかった。フルシミュレーションは、mmapが0.50tok/s、preadが4 tok/sだった。mmapでは、OSがモデルが触れたページを反応的に読み込むから、どのエキスパートが選ばれたかや、GPUの作業と読み込みが重なるタイミングはわからないんだ。共通の重みはシンプルさのためにまだmmapを使ってるから、llama.cppは2GB未満で動くかもしれないけど、遅くなると思うな。

僕もDiffusionGemmaを動かす準備がほぼ整ったプロジェクトがあるよ。この2つのプロジェクトはうまく連携できるかもしれない。36GBのM3で約20tok/s出てるし、お互いに速いカーネルを借りられる可能性が高いよ。気軽に連絡してね。(現在は https://github.com/mmastrac/diffgemma にあるけど、まだリリース可能な状態じゃないよ)

いいプロジェクトだね!最近ちょっと調べてみたけど、ローカルで拡散モデルを動かすのってあんまり意味がない気がするんだよね。どう思う?

めっちゃクールだね!Diffusion Gemmaがプロジェクトの真ん中あたりでリリースされたから、切り替えようか真剣に考えたよ。でも、そのままプロジェクトを終わらせることにしたんだ。完璧なマッチになると思う!プロジェクトのパーツを使ってもいいし、メッセージくれてもいいよ。リードミーの最後にLinkedInのリンクがあるから。後でメッセージするね!

実は、これに似たアイデアをずっと考えてたんだ。もっと小さいエントリーモデルが「専門家」モデルについて十分に知ってて、そっちに作業を渡す方が、今使ってる巨大なモデルよりも問題解決には良いかもって思ってる。高度に精製された専門家と、大きなモデルに戻るための調整機能があればいいな。

Hacker Newsで議論の続きを見る