TurboFieldfare: 26Bモデルを約2GBのRAMで動かすSSDストリーミング推論ランタイム
Gemma 4 26B-A4B inference in ~2 GB of RAM on any M-series MacBook
ひと目でわかる
- これは何？
- Gemma 4 26B-A4Bの重みをSSDから都度読み込み、8GBのMシリーズMacで動かすSwift製ランタイム。モデル固有実装という割り切りが、汎用ラッパーとの間にある実際の差になっている。
- 誰に向いている？
- 8GBのApple Silicon Macしか持たず、Gemma 4 26B-A4Bという特定モデルをローカルで動かしたい人には現実的な選択肢になる。逆に複数モデルを切り替えたい、量子化形式を自分で選びたい、LinuxやNVIDIA環境も視野に入れたい場合は、モデル固有実装という前提がそのまま制約になるのでMLXやllama.cppを検討すべきだ。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 8 日前です。
- 何の言語で書かれている？
- 主に Swift です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
26Bモデルと8GBマシンの間にある14.3GBという壁
Gemma 4 26B-A4Bは合計260億パラメータ、1トークンあたりの実効パラメータは約38.8億という構成のモデルだ。READMEによれば、テキストモデルの重みはMLX affine 4-bit（group 64）、ルーターが8-bit、共有エキスパートとルーティング先エキスパートが4-bitで、ストレージ上の占有は約14.3GBになる。8GBのMacBook Airにこの数字をそのまま載せることはできない。
TurboFieldfareが解こうとしているのはこの一点に絞られている。全重みをメモリに展開するのではなく、共有される約1.35GBのコアとFP16のKVキャッシュだけを常駐させ、各トークンで必要になるエキスパートだけをSSDからストリーミングする。READMEの表現を借りれば「a ~2 GB budget」で26Bモデルを動かす、という設計だ。
対象読者は明確で、Apple Silicon Macの中でもメモリが8GBしかない層、あるいはM2の8GB MacBook Airのように検証済みの構成を持っている人だ。汎用の推論エンジンを探している人ではなく、この特定モデルをこの特定の制約下で動かしたい人に向いている。
エキスパートをSSDから引くという発想と、その代償
Mixture-of-Experts系のモデルは、1トークンを生成するたびに全パラメータを使うわけではない。TurboFieldfareはこの性質をメモリ削減に直結させている。常駐させるのは共有コアとKVキャッシュ、そしてルーターの判断に応じて必要なエキスパートの重みをディスクから読み出す。
この方式の代償はI/Oにある。READMEのベンチマーク表では、8GBのM2 MacBook Airで5.1から6.3 tok/s、24GBのM5 Proで31から35 tok/sという計測値が示されている。同じソフトウェアでここまで差が出るのは、SSDの帯域とレイテンシ、そしてページキャッシュの状態がスループットを直接左右するからだ。README自身も「Prompt length, generated length, page-cache state, and hardware all affect throughput」と注記しており、この数値を性能の上限として扱うなと明言している。
つまりこのランタイムは、メモリを節約する代わりにストレージI/Oを推論のクリティカルパスに持ち込む設計だ。NVMe SSDが速いMシリーズMacだから成立している面が大きく、外部ストレージや遅いドライブでは同じ数字は出ないと考えたほうがいい。
Swift Packageが公開する6つのプロダクトと役割分担
リポジトリは単一のバイナリではなく、役割の異なる6つのプロダクトをSwift Packageとして公開している。TurboFieldfareはランタイムとMetalカーネルを含むライブラリ、TurboFieldfareMacはインストールと生成を行うネイティブMacアプリ、TurboFieldfareDecodeServiceはアプリが使うモデルとMetalの所有者となるワンショット実行ファイル、TurboFieldfareCLIはコマンドラインのチャットと生の補完、TurboFieldfareServerはループバック限定のOpenAI互換Chat Completionsサーバー、TurboFieldfareRepackはストリーミング形式のモデルインストーラと検証ツールである。
これらは同じ.gturboモデルディレクトリを共有するが、READMEは「only one model-owning product should run at a time」と明記している。モデルを所有するプロセスを同時に複数立ち上げる設計ではない。アプリとCLIとサーバーを並行して使い分けたい人にとっては、ここが運用上の制約になる。
サーバーはOpenAI互換とはいえループバック限定で、ツール宣言を受け取ってモデルが生成したツール呼び出しを返すところまでが責務だ。実行の認可と実行はクライアント側にある。アプリとCLIはツールを公開も実行もしない。
ビルドと初回セットアップで実際に打つコマンド
導入はリポジトリを取得してリリースビルドを通すところから始まる。READMEのクイックスタートは次の4行だ。
git clone https://github.com/drumih/turbo-fieldfare.git cd turbo-fieldfare swift build -c release .build/release/TurboFieldfareMac
初回ビルドではSwift Package Managerがトークナイザ関連のパッケージを取得してビルドする。リリースビルドにはフォアグラウンドのMacアプリと、その兄弟であるデコードサービス実行ファイルの両方が含まれる。READMEは「Build the complete package so the app and its sibling decode service are both available」と注意しており、アプリだけを個別にビルドするとデコードサービスが欠ける。
アプリを起動したらDownloadを選び、固定されたモデル（約15GB）を取得して再パッケージングする。完了後にLoad Modelを選び、プロンプトを入力してGenerateを押すという流れになる。
要件はApple Silicon Mac（検証済みのターゲットは8GBのM2 MacBook Air）、macOS 26とMetal 4、Xcode 26とSwift 6.2以降、モデル設置用に約14.3GBの空き容量、初回インストール時のネットワーク接続だ。パッケージはarm64専用で、古いmacOSとMetalでは動作しない。
生成パラメータの既定値と、テキスト以外の扱い
生成の既定値はtemperature 0.2、Top-K 64、Top-P 0.95である。決定論的な貪欲出力が欲しい場合はtemperatureを0に設定する。READMEはこの設定を提示したうえで、モデルが同じ内容を繰り返したり誤った答えを返す可能性があるとして、重要な結果は確認するよう求めている。
Macアプリは入力されたテキストを指示として扱い、Gemmaのチャットフォーマットを内部で処理する。ユーザーメッセージとモデルメッセージ、任意のシステム指示に対応する。
画像はビジョンタワー経由で扱い、テキストモデルの隣にコンパニオンパックとしてインストールする。一度入れてしまえばアプリ、CLI、サーバーのすべてが画像を受け付ける。未インストールの場合、画像サポートが利用できない旨を返し、テキストランタイム側には影響しない。このタワーはM2以降のApple Silicon Macを必要とし、テキストのみの推論はM1でも動く。音声と動画には対応していない。
MLXやllama.cppのラッパーではないという意味
READMEはTurboFieldfareを「model-specific rather than a wrapper around MLX or llama.cpp」と位置づけている。これは単なる宣伝文句ではなく、設計上の分岐点を示している。MLXやllama.cppは複数のモデルアーキテクチャを扱う汎用ランタイムで、量子化形式やバックエンドの選択肢も広い。その代わり、特定モデルのメモリ配置をここまで攻めた形で最適化することは難しい。
TurboFieldfareは逆方向に振り切っている。Gemma 4 26B-A4Bのエキスパート構造を前提に、常駐させる部分とストリーミングする部分を固定した。だから約2GBという数字が出る。同時に、対応モデルを差し替える余地はほぼない。MLX affine 4-bit group 64という量子化も、ルーター8-bit、エキスパート4-bitという構成も、このモデル向けに決め打ちされたものだ。
別のモデルを試したい、量子化を自分で選びたい、あるいはLinuxやNVIDIA環境も同じコードで扱いたいという要求があるなら、汎用ランタイムのほうが適している。TurboFieldfareの利点は汎用性の対価として得られている。
103件の実験記録が示すものと、示さないもの
リポジトリにはdocs/experiments/EXPERIMENT_INVENTORY.mdがあり、カーネル、キャッシュ、I/O、prefill、decodeにわたる103件の計測結果をまとめているとREADMEは説明している。ベンチマーク文書、コミュニティ計測のページ、実験の記録、システム設計、実装の参考文献といったドキュメントも揃っている。
ただし、この記事の執筆時点で筆者はこれらのファイルを実際に開いて検証していない。READMEに記載された範囲の情報しか確認できていない。103件という実験数が何を意味するかは、各実験の条件と再現手順を読まない限り判断できない。
コミュニティ計測のページも用意されており、他のMacでの結果を追加する手順が案内されている。M2の8GBという単一の検証済み構成だけでなく、より広いハードウェアでの数字が集まる余地はある。ただし、集まった数字がそのままTurboFieldfareの品質指標になるわけではない点は注意しておきたい。
Apache-2.0で配布されるランタイムと、モデル側の条件
リポジトリのライセンスはApache-2.0で、LICENSEファイルが置かれている。ランタイム、CLI、サーバー、アプリといったコード部分の利用条件はこのライセンスに従う。
ここで切り分けておくべきなのは、コードのライセンスとモデルのライセンスは別物だという点である。TurboFieldfareが扱うのはGoogleのGemma 4 26B-A4Bで、READMEはモデルカードへのリンクを張っている。モデルの重みをどう使えるかはそのモデルカード側の条件で決まる。アプリ内のDownload機能はモデルを取得して再パッケージングするが、これはモデル側の条件を回避するものではない。
具体的な条件の解釈についてはここでは扱わない。商用利用や再配布を検討する場合は、Apache-2.0の条文とGemmaのモデルカードをそれぞれ確認する必要がある。
メンテナンス面では、リリースが0.8.0（2026年9月8日）、0.7.2（9月4日）、0.7.1（8月28日）と短い間隔で続いている。活発に動いている代わりに、追従する側は更新のたびにビルドし直す前提を持ったほうがいい。macOS 26とMetal 4、Swift 6.2という要件も、OS側の更新に連動して動く性質のものだ。
編集部の結論
8GBのApple Silicon Macしか持たず、Gemma 4 26B-A4Bという特定モデルをローカルで動かしたい人には現実的な選択肢になる。逆に複数モデルを切り替えたい、量子化形式を自分で選びたい、LinuxやNVIDIA環境も視野に入れたい場合は、モデル固有実装という前提がそのまま制約になるのでMLXやllama.cppを検討すべきだ。導入前に確認すべきは、macOS 26とMetal 4、Xcode 26とSwift 6.2という要件を満たすか、約14.3GBの空き容量があるか、そして自分の用途がテキストのみかどうかである。画像を使うならM2以降と約1.1GBの追加パックが要る。
コミュニティノート