Apple SiliconとmacOS VMにおけるLlama.cppでのLLM推論が11～16倍高速化

Apple SiliconとmacOS VMにおけるLlama.cppでのLLM推論が11～16倍高速化 2026年8月11日公開 Francesco Bonacci および Johnny Franks Cuaを最初からフォローしている方は、CuaがLume、つまりmacOS仮想化スタックのShow HNローンチから始まったことを覚えているかもしれません。本日、私たちはそのVirtualization.framework基盤を、Cua Driverの背後にあるローカルコンピュータ使用環境およびCua CloudとFleetsの背後にあるインフラストラクチャに接続するための、より広範な取り組みからの最初の成果を共有します。それは、macOSゲスト内で新しいMetal高速パスをアンロックする、小さくプロセススコープの互換性レイヤーです。私たちはこの成果を本日、LumeとCuaと同じ寛容なライセンスの下で研究リリースとして公開します。これにより、他の人々も結果を再現し、どのApple Siliconチップ、macOSリリース、およびMetalワークロードが恩恵を受けるかをマッピングするのに役立ちます。 Apple Vzユーザーも他の場所でこれらの制限に遭遇しています。AppleのVirtualization.framework上に構築されたもう一つの著名なCLIであるTartには、「macOSゲストでのGPUパススルーは可能か？」というオープンな問題があり、フレームワークがmacOS VMゲストで利用可能なグラフィックスとまともなLLMパフォーマンスを提供できるかどうかが問われています。VMは引き続きAppleが提供する仮想GPUを使用します。私たちの作業は、そのデバイス上で新しいMetalパスを公開し、実用的なギャップの一部を埋めます。 M1 Ultraでは、llama.cppを介して実行されたTinyLlama 1.1Bは、同じストックVMでの同じワークロードと比較して、プロンプト処理が11.08倍、トークン生成が16.36倍高速でした。プロンプト処理は、ベアメタル結果の98%に達しました。ソースコード、ビルドスクリプト、機能プローブ、および生のベンチマークログが含まれているため、結果を検査して再現することができます。 私たちは今年リリースされた、GoogleのGemma 4 12B QAT Q4_0、6.98 GBのモデルで実験を繰り返しました。同じレイヤーにより、プロンプト処理が7.20倍、トークン生成が14.54倍向上しました。アンロックされたVMは、ベアメタルプロンプト速度の99.59%、ベアメタル生成速度の94.82%に達しました。 macOS VM内のキャップ AppleのVirtualization.frameworkは、macOSゲストに仮想グラフィックスデバイスを提示します。ゲストは、専用のGPUドライバーを介してMetalワークを送信し、Appleのホストスタックがそれを物理GPUで実行します。この構成はパラ仮想化であり、ホストがハードウェアの制御を維持し、ゲストは仮想化を認識したデバイスを使用します。これは、QEMUとKVM上に構築された他の仮想化スタックとは異なり、異なるアーキテクチャを使用できます。 x86 Linuxホストでは、VFIOは互換性のある物理PCIデバイスまたはハードウェア機能をIOMMUを介してVMに割り当てることができ、ゲストにそのデバイスへの直接アクセスを許可します。これは通常、GPUパススルーと呼ばれるモデルです。 私たちのストックTahoe VMでは、パラ仮想化されたデバイスは、おおよそApple 5世代ファミリー、最大スレッドグループメモリ32 KB、およびSIMDグループ行列サポートが無効であると報告しました。最新のMetalソフトウェアはこれらの回答を使用してカーネルを選択するため、デバイスは新しいカーネルを実行できたにもかかわらず、llama.cppは遅いパスを選択しました。AppleはGPUファミリーと機能テーブルを通じてGPU機能を文書化しており、実行時にデバイスをクエリすることを推奨しています。これにより、報告される機能境界が重要になります。アプリケーションは、プラットフォームが指示したとおりに正確に動作します。 解決策：プロセススコープのMetal機能シム 私たちは、ゲストプロセス内で実行される小さなMetal機能シム（アプリケーションとAPIの間に挿入される互換性レイヤー）を構築しました。これは、選択されたMetal機能クエリをインターセプトし、そのプロセスに返される回答を変更します。Metalアプリケーションはこれらの回答を使用してカーネルを選択するため、テストされたAppleファミリーとスレッドグループメモリの値を返すことで、llama.cppが新しいGPUパスを選択できるようになります。 テストされたプロファイルでは、シムは以下を行います。 - supportsFamily: Appleファミリー9（1009）として応答します。 - 報告される最大スレッドグループメモリを32 KBから64 KBに引き上げます。 これにより、テストされたllama.cppビルドは、新しいSIMDグループ削減、SIMDグループ行列、およびbfloat16パスを選択するのに十分でした。 Capability | Stock guest | Tested profile ---|---|--- supportsFamily:1009 | false | true SIMD-group matrix | off | on SIMD-group reduction | off | on bfloat16 | off | on Maximum threadgroup memory | 32 KB | 64 KB テストされたプロファイルは、Appleファミリーの回答とスレッドグループメモリの制限という2つの報告値を変更します。一般的な、Mac、Metal、およびワーキングセットサイズの値は、ベンチマーク中にストック設定を維持します。元の研究フックのプライベート機能プロファイルフック、クロックおよびタイミングインターポレーション、メッシュ置換、レイトレーシングオーバーライド、引数レイアウトガード、およびパイプラインコンパイルフォールバックを削除しました。ソースコードは監査できるほど小さく、フォーマットが不正または欠落している構成は、プロセスをストック機能パスに留めます。 ワークロードはAppleのVirtualization.frameworkグラフィックスパスに留まり、ホストのApple GPUで実行されます。機能の変更は、注入されたゲストプロセスにスコープされます。物理GPU割り当て、生のPCIまたはVFIOパススルー、およびカーネルの変更は、このメカニズムの外にあります。報告されるファミリーは、テストでカバーされるパスを表します。各追加のMetal APIは個別の検証が必要です。シムは、Appleの既存の仮想GPUパスでMetal機能をアンロックします。VMユーザーは、しばしば「GPUパススルー」という名前でより広範な制限に遭遇します。 新鮮な結果と最小限のアーティファクト 私たちは、48コアGPUとmacOS 26.6.1を搭載したApple M1 Ultraでテストしました。ゲストは、Lume 0.5.1で実行されている現在のパブリックTahoe Cuaイメージ（macOS 26.5.2、8 vCPU、16 GiB）でした。3つのすべての実行で、公式のllama.cpp b10167リリースと、同じTinyLlama 1.1B Chat Q4_K_Mモデルを使用しました。コマンドは次のとおりです。 llama-bench -m tinyllama-1.1b-chat-v1.0.Q4_K_M.gguf \ -p 512 -n 128 -r 10 -t 8 -ngl -1 -o json 以下の値は、各ベンチマーク行で発行された10個のサンプルのメディアンです。 Workload | Bare-metal host | Stock guest | Unlocked guest | Guest speedup | Unlocked / host ---|---|---|---|---|--- Prompt processing, 512 tokens | 4,871.99 tok/s | 431.86 tok/s | 4,786.70 tok/s | 11.08× | 98.25% Token generation, 128 tokens | 286.71 tok/s | 12.63 tok/s | 206.60 tok/s | 16.36× | 72.06% プロンプト処理はホストの結果にほぼ達しました。生成はホスト速度の72.06%に達し、測定可能なVMギャップを残しました。この向上は、ホストGPU、ゲストバージョン、アプリケーション、およびワークロードの形状に依存します。TinyLlamaの生の結果と環境記録には、正確なイメージダイジェスト、モデルとバイナリのハッシュ、コマンド、JSON出力、stderr、およびチェックサムが含まれています。これらのリリース候補の結果は、この投稿で使用されている削減されたシムを証明します。 現在の12Bモデル TinyLlamaは、迅速に実行され、Metalパスを明確に公開するため、有用な制御されたベンチマークとなります。また、開発者が今日選択する可能性のある、より大きなモデルも欲しかったため、Googleの公式Gemma 4 12B命令チューニング済みQAT Q4_0 GGUFを同じllama.cppバイナリで実行しました。ホスト、VM、シム、ベンチマーク形状、および10サンプルの方法は同じままでした。スペキュレーティブデコーディングを無効にし、マルチモーダルプロジェクターをロードしないままにして、比較を同じMetal推論パスに保ちました。 Workload | Bare-metal host | Stock guest | Unlocked guest | Guest speedup | Unlocked / host ---|---|---|---|---|--- Prompt processing, 512 tokens | 517.88 tok/s | 71.66 tok/s | 515.76 tok/s | 7.20× | 99.59% Token generation, 128 tokens | 52.38 tok/s | 3.41 tok/s | 49.67 tok/s | 14.54× | 94.82% Gemma 4の証拠は、GoogleのモデルリビジョンとSHA-256を最終的な生サンプルとともにピン留めします。別のホストコンピューティングワークロードを検出した後、予備的なストックシリーズを破棄して再実行しました。保持されたストック、アンロック、およびベアメタルファイルは、同じ競合のないウィンドウから取得され、タイトなサンプル範囲を示しています。 MLX-LM 0.31.3でMLX 0.32.0上のmlx-community/Llama-3.2-3B-Instruct-4bitもテストしました。MLX-LMはストックVMですでに高速だったため、パフォーマンスは横ばいでした。 Workload | Stock guest | Unlocked guest | Ratio ---|---|---|--- Prompt processing, 512 tokens | 1,656.55 tok/s | 1,665.47 tok/s | 1.005× Token generation, 128 tokens | 172.09 tok/s | 170.86 tok/s | 0.993× その横ばいの結果は、リリースプロファイルを定義するのに役立ちました。アブレーション中に、MTLGPUFamilyMetal3を広告すると、MLXはパラ仮想化デバイスでは利用できないレジデンシーセットを要求しました。リリースシムの変更は、Appleファミリーの列挙値への回答を制限し、Metal 3を維持します。