TL;DR: TinyGPUのテストについて前回投稿したところ、いくつかの関心を集めました。これはそのフォローアップです。Blackwellのカードは検出されドライバも読み込まれますが、NVIDIAのGSPファームウェアがTB5経由で起動に失敗します（既知の問題で、tinygradと一緒に取り組んでいます）。デバッグしているうちに迷路のように調べていくことになり、AppleのRDMAサブシステムがゼロコピーのネットワーク転送のためにMetal GPUバッファを受け入れることを発見しました — しかし誰もドキュメント化していないようです。さらに、Appleのlibibverbs内に隠されたibv_reg_dmabuf_mrシンボルを見つけました。これは、カーネル修正なしでmacOS上でGPUDirect RDMAが可能かもしれないことを示唆しています。ここに、私が見つけたものをすべてまとめ、どこで助けが必要かを書きます。
https://preview.redd.it/d1086k5fcjzg1.png?width=3024&format=png&auto=webp&s=84e4ddd650c2a56637f63c4db0a85ff85d3d5fd0
セットアップ（前回投稿を見逃した人向け）
私は4ノードのMacクラスタを動かしています（3×M3 Ultra + M5 MaxのMacBook Pro、合計で約1.5TBの統一メモリ）。Thunderbolt 5で接続し、分散推論のためにJACCL RDMAを使用しています。Razer Core X V2にRTX PRO 5000 Blackwell 72GBを取り付けてTinyGPUのテストを開始しました。
Blackwellカードで起きたこと
カードは検出されます。macOSからPCIe上で見えています（リンクアップ、x4 @ 16 GT/s、80 Gb/s TB5）。TinyGPUのDriverKit拡張が読み込まれ、マッチします。BAR0 MMIOはマップされており、GPUレジスタを読み書きできます。ですが、NVIDIAのGSPファームウェアは初期化中に失敗します：
RuntimeError: RPC call 4097 failed with result 101
NOCATのエラーレコードをデコードしてFBFLCN UNRECOGNIZED_CLIENTを見つけました — TB5トンネル経由で要求しているPCIeピアが、GPUのメモリファブリックに認識されていないようです。これは、TB5エンクロージャ上のすべてのNVIDIA GPUに影響する既知の問題です（tinygrad#15843）。同じエンクロージャ経由ではAMD GPUは問題なく動きます。私はこのissueにNOCATデコード結果を投稿しました — tinygradチームや、NVIDIA GSPファームウェアの初期化に取り組んだことのある方と協力して修正できると嬉しいです。
しかしデバッグ中に見つけたのはこれ
NVIDIA eGPUのVRAMが将来的にRDMA転送へ参加できるかどうかを調べるために、macOS上でibv_reg_mr()が実際に受け付けるメモリタイプをテストしました。その結果は驚くものでした。
メモリタイプの検証結果
| メモリソース | ibv_reg_mr | 想定？ |
malloc() | FAIL | 想定外 — Linuxでは動く |
posix_memalign() | FAIL | 想定外 — ページアラインされているのにまだ失敗 |
mmap(MAP_ANON) | PASS | 想定通り |
IOSurfaceGetBaseAddress() | PASS | どこにもドキュメントがない |
MTLBuffer.contents（Metal共有） | PASS | どこにもドキュメントがない |
AppleのRDMA実装は、物理的な裏付けではなくVMマッピングのタイプを検証する。 ヒープ割り当て（malloc/posix_memalign）は失敗する。VMマップされたメモリ（mmap、IOSurface、Metalバッファ）は通る。これは、ibv_reg_mrがピン留め可能な任意のメモリを受け付けるLinuxとは異なる。 | | |
トリプル登録バッファ — ゼロコピーを証明
私は単一の64MB mmapバッファを作成し、3通りの方法で同時に登録しました：
void *buf = mmap(NULL, 64*1024*1024, PROT_READ|PROT_WRITE, MAP_ANON|MAP_PRIVATE, -1, 0); // 1. RDMAメモリリージョン構造体 ibv_mr *mr = ibv_reg_mr(pd, buf, size, IBV_ACCESS_LOCAL_WRITE | IBV_ACCESS_REMOTE_WRITE | IBV_ACCESS_REMOTE_READ); // PASS, lkey=0x101 // 2. Metal GPUバッファ（ゼロコピー、同じ物理ページ） id<MTLBuffer> metalBuf = [gpu newBufferWithBytesNoCopy:buf length:size options:MTLResourceStorageModeShared deallocator:nil]; // PASS // 3. 異なるコンシューマによる書き込みテスト metalBuf.contents[0] = 99.99f; // Metal経由で書き込み assert(mr->addr[0] == 99.99f); // RDMA経由で読み取り — PASS、同じメモリ
1つのバッファ、3つのコンシューマ、ゼロコピー。 AppleのGPUの書き込みは、同じ物理ページなのでRDMAサブシステムに即座に可視になります。つまり：
Apple GPU compute → ［共有バッファへ書き込み］ → JACCL RDMAは、この2つの間でゼロコピーでリモートノードへ送信↑
隠されたibv_reg_dmabuf_mr — Appleはビルドしたが隠した
dyld共有キャッシュに対してdyld_info -exportsを使ったところ、Appleがlibibverbs.dylibにコンパイルしたシンボルが見つかりました。ただし、SDKヘッダからは意図的に除外されています：
ibv_reg_dmabuf_mr offset 0x4EC8 EXPORTED but NOT in <infiniband/verbs.h> ibv_cmd_reg_dmabuf_mr offset 0x43E4 EXPORTED but NOT in headers darwin_mmap_region_extended offset 0x75A0 Apple custom — not in upstream rdma-core mlx5_reg_dmabuf_mr offset 0x2CEA0 In libmlx5.dylib — Mellanoxプロバイダも
ibv_reg_dmabuf_mrは、LinuxでGPUDirect RDMA（GPU VRAMをRDMAメモリリージョンとして登録する）に使われる関数です。`ibv_reg_dmabuf_mr`は、LinuxでGPUDirect RDMAに使われる関数です（GPU VRAMをRDMAメモリリージョンとして登録します）。私はそれを逆アセンブルしましたが、**スタブではありません。完全に機能するコードです**：
```
ibv_reg_dmabuf_mr (0x4EC8) → vtable dispatch
→ mlx5_reg_dmabuf_mr (libmlx5) → MR構造体を確保し、6つの引数すべてを転送
→ ibv_cmd_reg_dmabuf_mr → 0x130バイトのioctlコマンド構造体を構築
→ execute_ioctl → カーネルへ直接SEND
```
AppleはDMA-BUFのRDMAメモリ登録パイプライン一式をビルドして出荷しています — ユーザ空間からMellanoxプロバイダ、そしてカーネルのioctlまで。残る唯一の疑問は、`IORDMAFamily.kext`がそのコマンドを受け入れるのか拒否するのかという点です。
なぜこれが重要か
ゼロコピーGPU → RDMAはmacOSで現実のものです。 Metalの計算結果は、中間コピーなしでリモートのクラスタノードへ送信できます。JACCL/MLXは、より高速なテンソルパラレリズムのためにこれを活用できるかもしれません。 ibv_reg_mr の検証パターン（VMマップ＝パス、ヒープ＝フェイル）は、eGPUのRDMAに対して影響があります。 TinyGPUのDriverKitドライバは、IOMemoryDescriptor を介してNVIDIA GPUのBAR1メモリをマップします。これによりVMマッピングが作られる――つまり、ibv_reg_mr がパスするのと同じタイプです。これは、NVIDIA eGPUのVRAMとTB5のRDMAコントローラ間のGPUDirect RDMAが、カーネルの修正なしでmacOS上で動く可能性があることを示唆しています。（現在は、TB5筐体でのTinyGPUの別のGSPファームウェア初期化問題によってブロックされています――tinygrad/tinygrad#15843を参照。） さらに ibv_reg_dmabuf_mr が示すのは、AppleがデバイスメモリRDMAへ向けて構築を進めているということです。 コンパイルはされているが、まだ公開されていないだけです。
ハードウェア
- 3x Mac Studio M3 Ultra（512GB + 512GB + 256GB = 1.28TB の統合メモリ）
- JACCLによるThunderbolt 5 RDMAメッシュ
- 分散推論のベースライン：DeepSeek-V4-Flash 151GBを2ノードで30 tok/s
- Razer Core X V2にRTX PRO 5000 Blackwell 72GB（接続済み、検出済み、TinyGPUドライバロード済み――ただしNVIDIA GSPファームウェアのTB5経由での初期化が失敗。別件として追跡中）
テストコード
すべてのテストプログラムはObjective-Cで、次のようにコンパイルしています：
clang -framework Foundation -framework Metal -framework IOSurface -lrdma -o test test.m
注：macOSのibv_reg_mrは、アクティブなRDMAデバイスが必要です（rdma_en2ではなくrdma_en3/4/5。rdma_en2はPORT_DOWNの可能性があります）。ポート状態を確認するにはibv_devinfoを使用してください。
助けが必要なところ
私は複数の観点からここを追いに行っていますが、ここには一人でカバーできる範囲を超えているものがあります。これらのどれかがあなたの得意分野に当てはまるなら： 1. TB5でのTinyGPU GSPファームウェア初期化（tinygrad#15843) GSP起動中に出るFBFLCN UNRECOGNIZED_CLIENTエラーは、GPUのメモリファブリックがTB5のPCIeトポロジを理解していないことを示唆しています。あなたがNVIDIAのGSPファームウェア、open-gpu-kernel-modules、あるいはPCIeトンネリングで作業したことがあるなら、私が使ったNOCATデコード手法（NVRpcQueue.read_respをパッチしてPOST_NOCAT_RECORDイベントからASCIIを抽出する）で、より深掘りする手がかりになるかもしれません。 2. macOSにおける ibv_reg_dmabuf_mr のGhidra解析 関数はlibibverbs.dylib（dyld shared cache）のオフセット0x4EC8にあります。この関数はexecute_ioctl（本当のカーネル経路）を呼び出しますか、それともENOSYSを返すだけのデッドスタブですか？ GhidraMCPはセットアップ済みで準備できていますが、もし誰かがすでにAppleのRDMAスタックを逆アセンブルしているなら、何日も節約できます。 3. 誰かが ibv_reg_mr をmacOSでデバイスマップメモリと一緒に試したことはありますか？ 見つけた検証パターン（VMマップ＝パス、ヒープ＝フェイル）は、DriverKitによるBARマッピングがVMマップされたIOMemoryDescriptor領域を作るため、PCIeのBARメモリでもパスする可能性を示しています。macOSで動いているeGPUがあるなら（TinyGPU経由でもAMDでも）、BAR1マップされたポインタでibv_reg_mrを呼んでみてください。NULLではない値が返れば、それはmacOSでのGPUDirect RDMAです。 4. darwin_mmap_region_extended ――「extended」とはどういう意味？ これはrdma-coreに対するApple独自の追加で、オフセット0x75A0にあります。アップストリームにはありません。拡張されていないdarwin_mmap_regionも存在します。AppleのRDMAスタックでREをしたことがあるなら、拡張版は追加でどんなパラメータを受け付けますか？
より大きな全体像
Appleは能力を構築し、それを社内で使い、公開APIからは隠しています。問題は、ibv_reg_dmabuf_mrが機能しているのか、死んだコードなのかで、それはGhidraセッションを行えば答えに近づけるはずです。これはクラスタを持つ人だけでなく、全員にとって重要である理由があります：macOSでGPUDirect RDMAが動くなら、Thunderboltを備えたMacは誰でもハイブリッドAIワークステーションになります。$200のeGPUエンクロージャ経由でNVIDIA GPUをMacに接続すると、そのGPUのVRAMがMacのメモリプールの一部になります――Metal、RDMA、推論スタックからアクセスでき、ゼロコピー転送で利用可能です。Macの128GB/256GB/512GBの統合メモリと、GPUの24/48/72GBのGDDR7が、すべて一緒に機能します。Linuxマシンは不要。別のPCも不要。ケーブル1本。現在TinyGPUではMac上でCUDA計算を動かせます。私たちが証明しようとしているのは、GPUのメモリがAppleのRDMAネットワークにも参加できる、という点です――つまり、マルチMacクラスタがノード間でNVIDIA VRAMを共有できるということ。~1.5TBの統合メモリ + 72GBのGDDR7が、すべてRDMA対応で、今日買えるハードウェア上にあります。
これは私のTinyGPUテスト投稿のフォローアップです。すべてのテストプログラム（Objective-C、各約50行）と研究ノートが利用可能です――興味があればリポジトリを共有できます。さらに、TB5のGSP初期化のデバッグを手伝いたいなら、 tinygrad#15843 でNOCATデコードの知見も投稿しています。
