ハクソク

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

RTX 5090とM4 MacBook Air：ゲームはできるか？

4時間前原文(scottjg.com)

概要

  • MacBook Air にデスクトップ向け GPU を外付けで接続する試みの解説
  • Thunderbolt eGPU の仕組みと現状のmacOS/Linux対応状況
  • PCIパススルー やDMAの技術的課題と解決策
  • AIやゲーム用途 での制限やパフォーマンスの現実
  • Apple Siliconでの IOMMU（DART）制約 や独自ハックの紹介

MacBook AirにデスクトップGPUを接続する挑戦

  • Thunderbolt eGPU を使い、NVIDIA RTX 5090を M4 MacBook Air に接続する試み
    • Thunderboltドックで PCIe→Thunderbolt 変換、USB-Cポート接続
    • Thunderboltは PCIe信号をトンネル して伝送、理論上はPC同様にGPU認識
  • Thunderbolt 4 で4レーン、最大 40Gbps 帯域
    • USB4でも一部で同様のPCIeトンネル対応
  • Thunderbolt経由で GPU→モニター（DisplayPort） 接続
  • 一般的にLinuxやWindowsでは eGPUドライバが標準対応
    • Raspberry PiでもOculink経由で利用例あり

macOSとeGPUの現状

  • Apple Silicon（Mシリーズ） ではmacOSが NVIDIA/AMD GPUドライバ未搭載
  • tinygrad が独自のmacOS用eGPUドライバをリリース
    • AI推論やゲームには パフォーマンス・対応モデルの制限 が大きい
    • tinygradスタック専用、他ソフトでは利用不可
    • Metal推論の方が 10倍高速 な場合も

Linux VMでの挑戦

  • Apple Silicon Macで Linux VM を動作
    • macOSがThunderboltデバイスを認識→Linux VMに GPUパススルー
    • arm64アーキテクチャ なのでパフォーマンスも近い
    • Windows ARM64には NVIDIAドライバ未提供、Linuxのみ対応

PCIパススルー技術の課題

  • PCIデバイス はBAR（Base Address Registers）経由で通信
    • QEMUでVM起動時に BARメモリ領域 をゲストにマッピング
    • 実際にBARにアクセスすると ホストカーネルクラッシュ 発生
  • QEMUのメモリマッピングフラグ （HV_MEMORY_EXEC有無）が原因
    • ARMデバイスメモリの取り扱いに起因する制限
    • 直接マッピング不可のため、 QEMU経由でアクセスをトラップ する方式に変更（パフォーマンス低下）

DMAとIOMMU（DART）の課題

  • DMA（Direct Memory Access）で デバイスが直接ホストメモリ操作
    • VM環境では IOMMU でゲスト→ホストアドレス変換
  • Apple Siliconの DART はIOMMU相当の役割
    • ThunderboltデバイスへのPCIDriverKit経由では 1.5GBマッピング制限 や アドレス指定不可 等の制約
  • apple-dma-pci というQEMU用の仮想PCIデバイスを自作
    • ゲスト側のカーネルドライバでNVIDIAドライバのDMA呼び出しをフック
    • DMAバッファをオンデマンドでマッピング し、1.5GB制限内でやりくり

まとめ

  • MacBook AirでデスクトップGPUを外付け利用 は技術的に可能だが、現状は 制約やハックが多い
  • macOSでは公式サポートや高性能利用は困難
  • Linux VM＋QEMU＋独自ドライバ でパススルーは可能だが、パフォーマンスや安定性に課題
  • Apple Siliconの DART/IOMMU制約 やThunderboltの制限克服には 追加開発や工夫が必須
  • AIやゲーム用途での実用性は 現時点では限定的

Hackerたちの意見

x86エミュが必要なのは、WindowsゲームがARM向けに作られることがほとんどないからだよね？ARMのVMがどうなるのかちょっと興味あったけど。とにかく、素晴らしい記事だね。

└

そうだね。Valveはここでめっちゃ頑張ってるよ。ARM CPUを搭載したSteam Frameでx86ゲームを動かすためには、これが必要なんだ。

これは本当にマッドサイエンスだね、最高！

これ、Appleの承認が取れればAI推論にかなり役立ちそうだね。Mac MiniでNvidiaのGPUを使いたかったから、これでCUDAを直接動かせるようになるんだ。めっちゃクール！

よくできてる！AIの時代でも本物のハッキングがまだ生きてるのを見ると嬉しいな。

嫌だとは思うけど、今のプロジェクトのほとんどはAIに聞くのが最初のステップになってる。もしかしたら知らないことを教えてくれるかも。いや、もっと可能性が高いのは、AIが知らないことを教えてくれるってことかな。昨日、5070TIが実際のビデオカードだってChatGPTと議論してたのを思い出す。5070TIなんて存在しないから、4070tiのことを言ってるんだろうってずっと訂正しようとしてたよ。

└

だから僕はgrokのエキスパートモードを使ってるんだ。情報を探しにウェブを積極的に検索してくれるから、数年前のデータに頼るよりずっといいよ。

└

トレーニングデータは2024年の late までか2025年の初めまでしかないから、そこが理由かもね。でも、インターネットにはアクセスできるみたい。

└

それとも、自分が間違えたことを認めて、同じ間違いを繰り返すかも。ClaudeにPowerShell 7についてのHTMLページを生成してもらったんだけど、7.4が最新のLTSリリースだって言ってきたんだ。7.6が3月にリリースされたってリンクを添えて訂正したら、同じ内容のページを生成して、また7.4が最新だって主張してきた。

└

少なくとも、ChatGPTはCodexの存在を認識してるみたい。数ヶ月前にnpmを使って@openai/codexを動かす手助けを求めたチャットがまだ履歴に残ってるんだけど、ChatGPTはこう言ったんだ：> 重要：Codex CLIはもう存在しません > OpenAIはCodexモデルとCLIをしばらく前に廃止しました。現在のOpenAIのnpmパッケージにはcodexという公式バイナリはありません。OpenAIの現在のCLIツールは：npm install -g openai > これでopenaiコマンドがインストールされるけど、codexではないんだ。このモデルたちの世界知識は必ずしも最新ではないよね :) 編集：同じプロンプトを現在のChatGPTに再入力したら、今は少し無知じゃなくなってる。もしかしたらOpenAIは、GPT-5.whateverがCodexの存在を信じてなかったのが完全にバカだったことに気づいて、調整したのかも。

└

LLMは（広い意味で）最前線のトピックの妥当性について強い判断を下すにはあまり適してないと思う。でも、ChatGPTはOPへの返答で正確だったよ！「非常に深い」、「実用的ではない境界線上」、「研究的な意味で」はこの記事自体の完璧な要約だね！ :)

└

超大国の経済全体とほぼすべてのオンライン文化がFurbyに夢中になってるのを見てるのは、今まで見た中で一番変なことの一つだよ。

何年もVMチームにVMのGPUパススルーをお願いしてるんだけど、Apple SiliconのMac Proで作業してた時、LinuxのVMを動かしてケース内のGPUをパススルーできたらもっと意味があったのに！残念ながら、見ての通り、彼らは僕のリクエストを受け入れてくれなかったみたい。でも他の人がそれを実現できたのは素晴らしいね！

└

このブログ記事の半分の問題は、QEMUやVMの境界によって引き起こされるメモリアクセスの問題に対処することみたいだね…多分俺が見逃してるバカなことなんだろうけど、DockerでUbuntuを起動したら、NVIDIAのドライバーはまだ読み込まれないの？それなら、メモリ管理でAppleと戦う必要はないはずだよね。だって、OSXがメモリを管理してるんだから。

└

Mac ProのNVIDIA GPUサポートがないことは、テクノロジーの中で最大の機会損失の一つになると思ってる。まあ、今はMac Proは死んじゃったけどね。音声や映像のプロフェッショナルが提供できる販売音声には限界があるから。

└

ここでのパススルー部分は、標準のDriverKitインターフェースを使って実装されてるみたいだね。つまり、PCIe BARはユーザースペースからマッピングできるから、macOSに特別な変更を加える必要はないんだ。QEMUみたいなVMMが、このインターフェースをLinuxのVFIOなどと一緒に採用するだけの話だよ（Virtualization.frameworkのことを言ってるなら、それは独自のVMMみたいなもんだけど）。macOSに何が足りないと感じてるの？

└

将来的にまたMac Proが出る可能性はどれくらいあるのかな？AppleはSiracusaを喜ばせるようなコンピュータを作ることがあるのかな？（それと、「Believe」のTシャツ持ってる？）

これ、結構すごいね。俺の印象では、eGPUはApple Siliconでは全然動かないと思ってたんだけど。（編集：Appleも俺の印象に同意してる。「eGPUを使うには、Intelプロセッサを搭載したMacが必要です。」それに加えて、公式にサポートされているeGPUは全部AMDで、NVIDIAじゃないんだ。https://support.apple.com/en-us/102363）

いい記事だね。ゲームのベンチマークは楽しいけど、LLMの改善が実用的に面白くなるところだと思う。Appleのプラットフォームは、たくさんのRAMでローカルモデルを動かすのに手軽な方法だから好きなんだけど、プロンプト処理速度が比較的遅いのは見落とされがちだよね。

「ここでのMacの大きな問題は、プロンプト処理（いわゆる“プリフィル”）の速度だよ。プロンプトが長くなるほど、どんどん悪化する。」 4Kトークンのプロンプトでも、そんなに長くないのに、M4 MacBook Airが解析するのに17秒もかかるんだ。レスポンスを生成する前にね。一方で、eGPUをつけると150msで済む。120倍速いよ。小さなチャットでLLMをいじってると、プリフィルの問題には気づかないけど、大きな作業に使おうとすると、計算の限界がボトルネックになっちゃう。最初のトークンまでの時間（TTFT）のグラフは悪く見えないけど、MacプラットフォームがフルGPU計算よりもずっと遅いから、対数スケールで表示しなきゃいけなかったって気づくと、ああってなるよね。

└

興味があるけど専門家じゃないんだけど、TTFTがMacでこんなに悪い理由知ってる？記事ではこのステップが計算に依存してるってだけ言ってるけど、単純な理由なのか、MLXであまり最適化されてないのか気になるんだよね。

Apple SiliconでeGPUが使えるようになったら、PCを持つ理由がほとんどなくなるね。

└

MacのGPUはほとんどのゲームにとってボトルネックじゃないよ。互換性が問題なんだ。