TurboFieldfareとは｜26BのGemma 4を約2GBのRAMで動かすSwift製ランタイムの実像

MoE（Mixture of Experts）モデルの重みは、そのほとんどが常には使われない。Gemma 4 26B-A4B は各層に128個のエキスパートを持ち、ルーターが1トークンあたり8個だけを選ぶ。ならば全部をメモリに載せる必要はないはずだ——TurboFieldfare（drumih/turbo-fieldfare・★6,602・Apache-2.0・2026-09-04時点）は、その発想をApple Silicon向けにSwiftとMetalで実装したランタイムである。

公称は「26BのGemma 4を約2GBのRAMで動かす」。14.3GBあるモデルのうち、共有コア1.35GBとFP16のKVキャッシュだけをメモリに置き、各トークンで必要になったエキスパートだけをSSDから読む。

この記事はこの主張を検証しようとして、実行にすら到達できなかった記録である。手元の環境（M2 MacBook Air 16GB / macOS 14.5）では swift build がバージョン不一致で止まった。そこで論点を切り替え、「8GBのMacでも動く」という見出しの手前に実際は何のゲートがあるのかと、公式・コミュニティが公開している実測値から何が読み取れるのかを整理する。

Apple Silicon でのローカル推論全般の位置づけはLLMとは？仕組み・主要モデル比較・ローカル実行・量子化を一気にまとめる2026年版にまとめている。

TurboFieldfareとは：エキスパートをSSDに置いたままMoEを走らせる

設計の核は docs/SYSTEM_DESIGN.md に書かれている。Gemma 4 の構造のうち、実装を規定しているのは次の4点だ。

量子化は MLX の affine 4bit（グループ64・BF16のスケールとバイアス）で、ルーター射影だけ8bit、共有・ルーテッド両方のエキスパートが4bit という配分になっている。ルーターの精度を落とすと選ぶエキスパートを間違えるので、そこだけ精度を残すという判断だ。

スライディングウィンドウの25層は直近1,024トークンだけを見て、K/Vを1,152行のリングに保持する（余分な128行はチャンク化プリフィルの書き込み用）。全注意の5層は追記のみで全文脈を持つ。この非対称なKV設計が「2GB」を成立させている実質的な部分で、単に量子化を強めただけの数字ではない。

.gturbo という独自のモデルディレクトリ形式を持ち、インストーラ（TurboFieldfareRepack）が Hugging Face の固定リビジョンから必要なバイト範囲だけをレンジリクエストで取得して、届いた端から再パックする。チェックポイント全体を一度ディスクに置かないので、14.3GBの設置に対して余分な14.3GBが要らない。8GB機を想定したときにディスクも効いてくる、という前提が設計に効いている。

turbo-fieldfareを動かす前にある3つのゲート（RAMではない）

ここが本記事の主眼だ。READMEの見出しは「Gemma 4 26B-A4B inference in about 2 GB of RAM / A custom Swift + Metal runtime for any Apple Silicon Mac, even the 8 GB ones」で、制約としてRAMだけが前に出ている。実際の Requirements 節と Package.swift を読むと条件はもっと厳しい。

// Package.swift（tag 0.7.1）冒頭
// swift-tools-version: 6.2
let package = Package(
    name: "TurboFieldfare",
    platforms: [
        .macOS(.v26),
        .iOS(.v26),
    ],

手元の M2 MacBook Air（macOS 14.5 / Swift 5.10 / Xcode 未導入・Command Line Tools のみ）で実行した結果はこうなった。

git clone --depth 1 --branch 0.7.1 https://github.com/drumih/turbo-fieldfare.git
cd turbo-fieldfare
swift build -c release
# → error: 'tf': package 'tf' is using Swift tools version 6.2.0
#          but the installed version is 5.10.0

つまりRAM 8GBのMacを持っていることは条件の一部でしかなく、そのMacが macOS 26 に上がっていて、かつ Xcode 26 が入っていることが実質的な前提になる。8GBのMacBook Airを使い続けている層と、最新のmacOSに上げてXcodeを入れている層は、必ずしも重ならない。

配布バイナリが1つも無い

これを避けようがない事実にしているのが、リリース資産の状況だ。

gh api repos/drumih/turbo-fieldfare/releases --paginate \
  --jq '[.[]|{tag:.tag_name, n:(.assets|length)}]'
# → releases: 16 | total assets: 0

v0.1（2026-07-20）から 0.7.1（2026-08-28）まで16本のリリースがあり、添付アセットは合計0件だった。DMGもpkgもなく、Homebrewのformulaも見当たらない。README の Quick start が git clone → swift build -c release から始まっているのは省略ではなく、それが唯一の入手経路だからである。

公式ベンチマークの読み方：tok/s より TTFT を見る

docs/BENCHMARKS.md にある8GB M2 MacBook Air（Mac14,15）の実測は次のとおり。

メモリの主張は数字で裏付けられている。ピークRSSは1,304〜1,535 MiB、フットプリントでも1,776〜1,971 MiBで、「約2GB」は誇張ではない。26Bのモデルをこの常駐量で回している事実は素直に評価してよい。

一方で同じ表に、見出しに出てこない数字が並んでいる。TTFT（最初のトークンが出るまで）が 8.0秒〜37.7秒である。1,017トークンのプロンプト——コードを数十行貼る程度の長さ——で、最初の1文字が出るまで36.7秒のプリフィルが走る。

デコードが5〜6 tok/s なら「遅いが読める速度」に聞こえる。だが実際の体感はプリフィル待ちが支配的で、8GB機では長いプロンプトを投げるほど不利になる。READMEも「The measured result is a reference point, not a performance ceiling」と断ってはいるが、TTFTの桁はもう少し前に出てよい情報だと思う。

なお公式の注記は誠実で、「4点は信頼区間を構成しないし、長時間生成の持続性能を示すものでもない」「各ワークロードは新規プロセスで1回ずつ実行し、ファイルキャッシュは温かいが統制していない」と明記されている。1回計測であることを隠していない点は、この種のベンチマークとしては信頼できる書き方だ。

コミュニティ実測から見える「同じチップでも8GBと16GBで2.3倍」

docs/COMMUNITY_BENCHMARKS.md には、固定プロンプト・固定シード（temperature 0.2 / Top-K 64 / Top-P 0.95 / 文脈4,096）でGitHubユーザーが提出した結果が集まっている。ここに同じチップでRAMだけが違う組み合わせがあった。

同一チップ・同一プロンプト・同一設定で、RAMが8GBか16GBかだけで2.3倍の差が出ている。しかも3つのプロンプト長すべてで2.31〜2.35倍と揃っており、たまたまの1点ではない。

理由は設計から素直に説明できる。エキスパートはSSDに置いてページキャッシュ越しに読むので、空きメモリが大きいほど直前に読んだエキスパートがキャッシュに残る。8GBではモデル以外のプロセスと奪い合って追い出され、そのぶん実SSDリードが増える。この構造は他のSSDストリーミング型推論と共通で、WASTE解説｜Kimi K3 2.78TをNVMeで動かすC製推論エンジンと「RAM増設が効かない」実測が観測した「キャッシュを増やすと遅くなるページングの崖」とは逆向きだが、ページキャッシュの効き方が支配的という点では同じ土俵にある。

ストレージ側の結果も示唆的だった。

外付けNVMeが最速の列にいる。SSDストリーミング型というと外付けは不利に見えるが、少なくともこの提出値ではそうなっていない。ただし提出はいずれも1回実行（一部は5回の中央値）で、統制されたハードウェア比較ではないと公式も明記している。傾向として読む以上のことはできない。

同じ「巨大MoEを小さいメモリで」という問題設定は、純Cで744BのGLM-5.2を25GBに載せるcolibri解説｜GLM-5.2（744B MoE）を25GB RAMで動かす純Cランタイムの実測速度にも見られる。TurboFieldfareが違うのは、モデルを1つに絞って専用実装にした点だ。汎用性を捨てた代わりに、Gemma 4 のRoPE・正規化・KVレイアウトに合わせ込める。README自身が「model-specific rather than a wrapper around MLX or llama.cpp」と書いているとおりで、これは強みであると同時にGemma 4 以外には使えないという制約でもある。

OpenAI互換サーバーと、速度に効くつまみ

TurboFieldfareServer を使うと、ローカルにChat Completions互換のエンドポイントが立つ。既存のOpenAI SDKやエージェントクライアントをそのまま向けられる形だ。

swift build -c release --product TurboFieldfareServer
.build/release/TurboFieldfareServer   --model scratch/gemma4.gturbo --port 8080 --max-context 16384

# 別ターミナルから
curl -s http://127.0.0.1:8080/v1/chat/completions   -H 'Content-Type: application/json'   -d '{"model":"gemma-4-26b-a4b-it","messages":[{"role":"user","content":"Reply with exactly READY."}],"temperature":0,"max_completion_tokens":16}'

docs/RUNTIME_CONTROLS.md には、速度とメモリのトレードオフを直接触れるつまみが並んでいる。8GB機で効きそうなものを抜き出すと次のとおり。

--prefill-chunk-tokens を 256 にすると16%速くなる、という具体的な数字が公式ドキュメントに書かれているのに既定が128なのは、チャンクを大きくするとピークメモリが上がるためだろう。8GBという設計上の下限を守る側に既定を寄せた結果で、16GB以上の機体では既定を触る余地があることを示唆している。

103件の実験記録が教える「効いたのに採用しなかった最適化」

このリポジトリで技術的にいちばん読む価値があるのは、README でも SYSTEM_DESIGN でもなく docs/experiments/EXPERIMENT_INVENTORY.md かもしれない。103件の計測済み実験が、採否の理由つきで分類されている。

103件の内訳は、プリフィル17件・デコードMoE/INT4/ルーター18件・注意とKVキャッシュ14件・フュージョンとオーケストレーション15件など、領域ごとに9本の要約へ整理されている。

いちばん教訓的なのが F_RDADVISE（macOSのfcntlでファイル読み出しのヒントを与える）の顛末だ。測ると確かに効いていた。

同じ最適化が、ある条件では5%速くし、別の条件では29%遅くした。しかも後の反復ではその崩壊が再現せず、勝つバリアントもあった。結論として「どのときにヒントが効くかを確実に判定できる方針が見つからなかった」ため、本番ではオフのままにしている。

読み側の他の候補も同じ形をたどっている。キャッシュとread-aheadのフラグは中立、投機的読み出しは単体では速く見えたのにデコードを遅くしプリフィルを82.50秒から123.64秒へ伸ばした、ファイルオフセット順の読み出し整列は1回勝って反復で負けた、MTLIOは既に温まったデータには速いが実際のミスの多くはその条件を満たさなかった——。

A/Bで一度勝った数字を採用根拠にしない、という判断が一貫している。当サイトでも同種の落とし穴（測定順序やページキャッシュの状態が結果を1桁動かす）を何度か踏んでいるので、この記録は他人事ではない。TurboFieldfareを使うかどうかとは別に、SSDストリーミング型の推論を自作しようとしている人には、この103件が最大の資産だと思う。

誰が今すぐ試せて、誰が待つべきか

まとめ：主張は正しく、条件の説明が足りない

TurboFieldfareの技術的な主張——26Bのモデルを約2GBの常駐で動かす——は、公式ベンチマークのピークRSS 1,304〜1,535 MiB という数字で裏付けられている。103件の実験記録を docs/experiments/ に残し、ベンチマークの但し書きも誠実で、数字を盛る種類のプロジェクトではない。

問題は数字ではなく、条件の見せ方にある。「even the 8 GB ones」という一文が前面に出る一方で、macOS 26・Xcode 26・Swift 6.2・配布バイナリ0件という、RAMより厳しいゲートが Requirements 節の中に収まっている。8GBのMacを使い続けている人ほど最新OSに上がっていない可能性が高いことを考えると、この順序は実態と逆だと思う。

さらにコミュニティ実測は、同一チップでも8GBと16GBで2.3倍の差があることを示している。「8GBでも動く」は事実だが、それは「8GBが快適」という意味ではない。このプロジェクトが本当に届けたい相手（古い8GB機のユーザー）が、いちばん条件を満たしにくく、いちばん遅いという構図が、現時点の実像である。

なお本記事は手元でビルドできなかったため、性能値はすべて一次資料からの引用であり、独自の実測ではない。実測したのは、ビルドが止まる位置と、リリース資産が0件であることだけである。

参照ソース

• drumih/turbo-fieldfare — GitHub
• TurboFieldfare System design
• TurboFieldfare Benchmarks
• TurboFieldfare Community benchmarks
• Gemma 4 モデルカード — Google AI for Developers