- TurboFieldfareは、14.3GBのモデル全体をメモリに載せることなく、Gemma 4 26B-A4Bを約2GBのメモリで実行し、8GBのApple Silicon Macでもローカル推論を可能にする
- 1.35GBの共有コアとFP16 KVキャッシュだけを常駐させ、トークンごとに必要なMoEエキスパート重みをSSDからストリーミングする。16スロットのLFUキャッシュと並列
preadでI/Oを抑える - 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をrange requestでダウンロードする
- インストーラーは元のチェックポイント全体を一時ファイルやメモリ上に作成しない
- 必要なバイト範囲を取得し、直接
.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、サーバー、テスト、または他のローカルモデルプロセスは、一度に1つだけ実行すべき
提供プロダクトと使い方
- Swiftパッケージは6つのプロダクトを提供する
TurboFieldfare: ランタイムとMetalカーネルを含むSwiftライブラリTurboFieldfareMac: インストールと生成のためのネイティブMacアプリTurboFieldfareDecodeService: Macアプリが使用する一回限りのローカルモデル・Metal所有プロセスTurboFieldfareCLI: コマンドラインのinstruction chatおよびraw completionTurboFieldfareServer: 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-K64、Top-P0.95- temperatureを
0に設定すると、決定論的なgreedy outputを使用する - モデルは反復したり誤答したりすることがあるため、重要な結果は確認が必要
- temperatureを
- アプリと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ディレクトリを使用するが、モデルを所有するプロダクトは同時に1つだけ実行すべき
実装範囲と実験記録
- カスタムMetalカーネルは、量子化GEMV、attention、MoE、normalization、RoPE、sampling、production fusionを処理する
- ランタイムはSSDベースのrouted-expertストリーミング、制限付きexpertキャッシュ、チャンク単位の単一プロンプトprefill、トークン単位生成を実装する
- カーネル、キャッシュ、I/O、prefill、decodeにわたる103件の測定結果を実験記録として管理する
- 実験文書には、効果の大きかった最適化、失敗したアイデア、より強い検証の後に覆された初期結果が含まれる
- 今後の作業は、iPhone・iPadアプリ開発とモバイル推論速度・メモリ測定、16GB M4 Mac miniおよび他の8GB Apple Silicon Macのベンチマーク
ライセンスとモデル条件
- ソースコードとドキュメントはApache License 2.0で配布される
- モデル重みはリポジトリに含まれず、インストーラーが固定されたHugging Faceチェックポイントから別途ダウンロードする
- 重みには元の配布条件が引き続き適用される
- TurboFieldfareはGoogleと提携しておらず、Googleの支援・承認を受けたプロジェクトではない独立研究プロジェクト
1件のコメント
Hacker News のコメント
なぜ毎回、チャールズ王が誰かまで含めてモデル全体をメモリに押し込む必要があるのか、ずっと疑問だった。大きなファイルを細かく分けて少ないメモリで効率よく読む技術は、すでに確立されていると思う
最先端の AI 業界には、モデル作成には長けていても、スケーラビリティや実用性はインフラ担当に丸投げする傾向があるように見える。実際に使う知識が 10% 未満なら、微調整と最適化だけでコストを大きく下げられるかもしれない
密な LLM は通常パフォーマンスが高いが、層を外部ストレージに追い出すと MoE よりはるかに遅くなる
最近は出所のわからないプロジェクトをダウンロードするとき、こうしたセキュリティレビューを自分で回す必要がある。リポジトリのエージェント指示と Markdown ファイルを無視し、Swift/Metal のソース、ビルドスクリプト、CI 設定、依存関係を検査させたところ、マルウェア・バックドア・認証情報の窃取・隠れたネットワークエンドポイントは見つからなかったが、コンパイル・サプライチェーン・ランタイムのリスクは依然として残る、という結果だった
もっと良いプロンプトがあれば共有してほしいし、Cursor の Composer 2.5 で実行したコストは0.20 ドル未満だった
M1 MacBook Air で macOS 15 を使っているなら、次の 2 行を削除するか、
if #available(macOS 26.0, *)で囲めばコンパイルできる:opts.languageVersion = .version4_0コメントによれば、attention が 11.24 倍速くなって prefill が 2.4 倍高速化される恩恵は失うが、8 コア GPU の M1 Air でも毎秒 5〜6 トークンは出る
2.4 倍の prefill 改善は apple10 GPU 系でしか動かず、M1 は記憶では apple7 だ
このプロジェクトが普通の**
mmap**と比べてどうなのか気になる。llama.cpp もmmapを有効にして再パッキングを無効にすれば、必要なら 26B モデルを 2GB RAM で実行できる核心の違いは、SSD 読み込みを推論処理と同期してレイテンシを最小化している点にあるようで、OS はこうした実行コンテキストを考慮しない
mmapを使っていた。8GB M2 でコールド状態の 3.36MB の expert を読むのにmmapは 10ms、preadは 2.8msかかり、全体のシミュレーションはそれぞれ毎秒 0.50 トークンと 4 トークンだったmmapでは、モデルがページに触れた時点で OS が事後対応で読み込むため、どの expert が選ばれたのか、いつ GPU 処理と読み込みを重ねられるのかを把握できない。共通の重みは単純化のため引き続きmmapを使っており、llama.cpp も 2GB 未満で動かせるだろうが、より遅いはずだ「測定結果はベースラインであって性能上限ではない」という文は、Claude 特有の言い回しに見える
著者が LLM で文だけ整えて、余計な内容を足していないなら問題ない。文章自体が無価値な生成物なら、単に低評価すればいい
より高速な SSD を積んだ M1 Max Mac Studio で毎秒 12 トークン、しかもほぼ即時応答が出るのは印象的だ。大規模モデルをメモリではなく SSD から直接動かす可能性を示している
最近は SSD ストリーミングエンジンが増えているが、難しい機能にまで踏み込む例は少ない。主要モデルには speculative decoding 用のMTP ヘッドがあるので、これを SSD 上の expert 重みの先読みにも使えるかもしれない
GPU が必要とする前に重みを用意できれば、VRAM キャッシュミスのコストを大きく減らせるし、効果が実証されれば将来のモデルは expert を先読みする専用ヘッドを持ち、学習段階からそれを考慮する可能性もある
MTP が作ったドラフトトークンで第 1 層の expert までは予測できても、第 10 層を知るには第 1〜9 層を実行しながら、その expert たちを先に読み込まなければならない。したがって、次トークン生成器の代わりに全層の expert 活性化を一括で予測するよう学習された仕組みが必要になる
DiffusionGemma を実行するプロジェクトもほぼ準備できており、2 つのプロジェクトを組み合わせれば相性は良さそうだ。36GB M3 で毎秒約 20 トークンが出ており、お互いのより高速なカーネルを持ち寄れる可能性も大きい
現在のコードは https://github.com/mmastrac/diffgemma にあるが、まだ配布可能な状態ではない
これについてどう考えるか気になる
8GBのM2 MacBook Airで毎秒5～6トークン、M5 MacBook Proで31～35トークンという大きな差がなぜ出るのか気になる。SSD性能の差がそこまで大きいとは思えないが、この方式ではSSDが支配的なボトルネックになると予想していた
https://www.tomshardware.com/laptops/macbooks/m5-macbook-pro...
OSキャッシュ込みで合計2GBしか使えないなら、推論速度はさらに低下する可能性がある
preadにかなり依存している。プロセスが2GB未満でも、M5 Macは一部をキャッシュでき、ハードウェア自体もはるかに高速トークンあたりの読み込みはM2で83ms、M5 Proで12ms、全体時間はそれぞれ163msと30msだった。読み込みもGPU処理も高速化した結果である
今後、30～60GBのメモリと非常に高速なSSDを備えたシステムなら、この手法で超大規模モデルも動かせるようになることを期待している
https://github.com/danveloper/flash-moe
https://github.com/JustVugg/colibri
https://github.com/antirez/ds4 または自作の https://github.com/steadfastgaze/MoEspresso を使える。メモリ上にない次トークン用のエキスパートをSSDから読み込む必要があるため、速度はSSD読み込みに制約され、メモリが大きいほど推論は速くなる