ハクソク

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

Apple SiliconとmacOS仮想マシン：Llama.cppによるLLM推論が11～16倍速くなる

2026年8月11日原文(github.com)

概要

Apple Silicon搭載Mac上のmacOS仮想マシン（VM）で、llama.cppによるLLM推論速度を最大16倍向上させる手法を解説。 Metalの仮想GPU機能制限をプロセス単位で緩和する「Metal capability shim」を開発し、ベンチマークで大幅な性能向上を実証。 本手法はLume仮想化基盤上で動作し、ソースコード・ビルドスクリプト・検証ログも公開。 Apple Silicon各世代やmacOSバージョン、Metal APIごとに独立検証が必要。 CuaおよびLumeと同一の寛容ライセンスでリサーチリリース、再現・検証・改善に協力を呼びかけ。

Apple SiliconとmacOS VM：llama.cppによるLLM推論の高速化

  • Apple Silicon搭載Mac のmacOS VMで llama.cpp を用いた大規模言語モデル（LLM）推論の高速化事例
  • Lume仮想化基盤上のmacOSゲストは Virtualization.framework の仮想GPUを利用
  • デフォルトではMetal機能が制限され、 llama.cpp が古いGPUカーネル経路を選択し性能低下
  • プロセス単位でMetalの機能応答を上書きする Metal capability shim を開発
  • shim導入で、 新しいMetalカーネル経路 が選択可能になり、推論速度が大幅向上

ベンチマーク結果（M1 Ultra環境）

  • TinyLlama 1.1Bモデル： プロンプト処理11.08倍、トークン生成16.36倍 高速化
  • Gemma 4 12Bモデル： プロンプト処理7.20倍、トークン生成14.54倍 高速化
  • Muse Glimmer 30Bモデル： プロンプト処理7.55倍、トークン生成8.87倍 高速化
  • 各モデルとも ベアメタル（ホスト直接実行）に近い速度 を実現

技術的背景

  • Appleの仮想GPUは パラバーチャライゼーション方式 で、ゲストはMetal経由で仮想デバイスにアクセス
  • デフォルトでは古いApple GPUファミリー（例: family 5）として認識され、 SIMD-group matrix・bfloat16等が無効
  • shimは supportsFamily:1009（Apple family 9）を有効化 し、 最大threadgroupメモリを32KB→64KB に拡張
  • これにより 最新Metalパス（SIMD-group reduction/matrix, bfloat16） が利用可能に

他の仮想化フロントエンド

  • Tart等の他のmacOS仮想化CLIでも 同様のGPU機能制限問題 が報告
  • 本手法は 物理GPUのパススルーやカーネル改変不要 で、既存の仮想GPU経路を活用

Metal capability shimの仕組みと使い方

  • shimは 1プロセス単位 でMetal APIの応答値を上書き
  • DYLD_INSERT_LIBRARIES で対象プロセスにshimライブラリを注入
  • LUME_METAL_APPLE_FAMILY_MAX 等の環境変数で上書き値を指定
  • Lume VM上での導入手順：
    • ソースコードのビルド・検証（build.sh/verify.sh）
    • VM停止→ForceUnrestrictedDeviceFeatureLevel有効化→VM再起動
    • dylibとワークロードをゲストに転送し、対象プロセスでshimを有効化
  • 長期稼働サーバ等には LaunchAgent でプロセス単位のshim適用

制限事項と注意点

  • 実験的・バージョン依存 ：macOSアップデートでshimが動作しなくなる可能性
  • プロセス単位 ：注入対象とその子プロセスのみ影響、保護実行ファイルには非対応の場合あり
  • 物理GPU機能検出や他API は対象外、各API・モデル・チップごとに 独立検証が必要
  • 既存の仮想GPU経路の制約 （帯域・遅延等）はそのまま

まとめと今後の展望

  • 仮想GPUの保守的な応答 がパフォーマンスのボトルネックであったことを実証
  • プロセス単位のMetal capability shim で、仮想環境下でも ベアメタル並みのLLM推論速度 を実現可能
  • Lume/Cua基盤の発展により、 Apple Silicon各世代・macOSバージョン・多様なMetalワークロード への展開を目指す
  • GitHubでCuaをStarし、shimの検証・改善・新規組み合わせの報告やPRを歓迎

参考：導入・検証コマンド例

  • ビルド・検証
    • cd libs/lume/metal-capability-shim
    • ./Scripts/build.sh
    • ./Scripts/verify.sh
  • VM設定変更
    • lume stop my-vm
    • defaults write com.apple.gpusw.ParavirtualizedGraphics ForceUnrestrictedDeviceFeatureLevel -bool true
    • lume run my-vm
  • shim適用実行
    • lume ssh my-vm "DYLD_INSERT_LIBRARIES=/path/to/LumeMetalCapabilities-arm64.dylib LUME_METAL_APPLE_FAMILY_MAX=1009 /path/to/metal-capabilities 1009"

お問い合わせ・貢献方法

  • Apple MetalやVirtualization.framework開発者からの 仕様・サポート範囲の明確化要望
  • GitHubでのIssue・Pull Request投稿 による検証・改善協力
  • 連絡先： vz@trycua.com

Hackerたちの意見

同じワークロードを同じストックVMで実行した場合、11.08倍速く、トークン生成は16.36倍速かった。だから、比較としてはちょっと混乱したかな。

└

うん、確かにその通り。HNのタイトル制限内で全体のアイデアを伝えるのはいつも難しいよね。要するに、同じApple Siliconホストの同じLume macOS VMで同じワークロードを実行したんだ。最初はストックのMetal機能報告で、その後にプロセススコープのダイナミックライブラリを使った。11.08倍はプロンプト処理の数値で、16.36倍はトークン生成の数値。技術的にはグラフィックスワークロードにも拡張できるけど、これらの数値はllama.cppからのものだよ。

Apple 1-9って何なのかよくわからない。最初はMシリーズのチップかと思ったけど、M9はまだないしね。

└

https://developer.apple.com/documentation/metal/mtlgpufamily

これ、全員のllama.cppの速度を上げるわけじゃない気がする。特定のVirtualization.frameworkのVMで実行しているユーザーだけだと思う。ここでの修正は、VMがllama.cppに間違ったカーネルを選ばせていた問題を回避するものだね。

└

これ、全員のllama.cppの速度を上げるわけじゃない、特定のVirtualization.frameworkのVMで実行しているユーザーだけだ。正解。これらの数値は、私たちがテストしたmacOSゲスト構成内のllama.cppに適用される。Lumeは私たちが使ったVMのフロントエンドで、AppleのVirtualization.frameworkが仮想GPUを提供している。ベアメタルのllama.cppには影響がない。 > ここでの修正は、VMがllama.cppに間違ったカーネルを選ばせていた問題を回避するものだ。ほとんどはその通りだけど、少しニュアンスがある。llama.cppは受け取った機能の回答に対して正しいカーネルを選んでいる。ストックのゲストは古いApple GPUファミリーと32 KBのスレッドグループメモリ制限を報告するから、llama.cppは遅いカーネルを選んじゃうんだ。私たちのプロセススコープのレイヤーは、テストされたApple 9と64 KBの値を報告し、llama.cppが新しいパスを選べるようにしている。パラ仮想GPUはそのレイヤーをうまく実行できるけど、llama.cppとは独立してMetal APIの境界で動作する。他のMetalコンピュートやグラフィックスアプリも、同じ機能の回答から新しいパスを選ぶかもしれないけど、これはまだ初期段階で、各アプリは別々にテストが必要だよ。例えば、MLX-LMは私たちのテストでは変わらなかった。歴史的な制限がApple Silicon VMのフロントエンド全体で出てきているんだ。例えば、Tartは2023年にMPS/GPUサポートを追跡していた: - https://github.com/openai/tart/issues/501 - https://github.com/openai/tart/issues/1032 UTMにも、アプリがAppleのパラ仮想Metalデバイスを検出するけど、ソフトウェアレンダリングにフォールバックする関連ケースがある: https://github.com/utmapp/UTM/issues/7671

└

勝ちは勝ちだよね。

なるほどね。最初はApple Siliconでの一般的なllama.cppの速度向上のように聞こえたけど、改善がVirtualization.frameworkのVM内でのカーネル選択の修正から来ているなら、その違いはかなり重要だね。

確か、Mac特有のML最適化をローカル推論（おそらくファインチューニングも）に取り組んでいた別のYCスタートアップがあったよね。彼らの仕事と関係があるのかな？

└

RunAnywhereかConiferか？

俺のセットアップは、もっとRAMを買って、CPUで動かして、GPUは自分の性格の一部だと思い込んでる感じ。

└

RAMバブルが弾けたときにAMDが勝つことを期待してる。そしたら、統合されたAMD 395+プラットフォームがもっと速くて帯域幅も広がるはず。

Hacker Newsで議論の続きを見る