Macで外付けGPUが使える「TinyGPU」をRTX 5060 Tiで検証 実用性と浮き彫りになった課題（4/4 ページ）

[Yukito KATO，ITmedia]

※本記事はアフィリエイトプログラムによる収益を得ています

動作検証と所感

　導入が完了したので、実際の動作検証に移ろう。利用にあたっては、TinyGPU.appを起動した状態で、tinygradディレクトリに移動し、NVIDIAバックエンドを指定する環境変数DEV=NVを付与してコマンドを実行する。

```shell

cd ~/tinygrad

DEV=NV python3 -m tinygrad.llm

```

　実行するとDockerコンテナの作成とデフォルトモデル（Llama 3.2 1B Instruct）のロードが始まり、完了すると「>>>」プロンプトが返ってくる。

Docker Desktopを確認すると、「cuda-nvcc-persistent」コンテナが実行されていることが分かる

　今回は導入に続いて、下記コマンドを実行してベンチマークを計測してみた。結果は以下の通りだ。

```shell

cd ~/tinygrad

DEV=NV python3 -m tinygrad.llm --benchmark 32

```

フェーズ	該当トークン	生成時間	スループット
ウォームアップ	1トークン目	約5,011ms	毎秒0.20 tok
ウォームアップ	2トークン目	約2,009ms	毎秒0.50 tok
ウォームアップ	3トークン目	約480ms	毎秒2.09 tok
定常	4トークン目以降	約70ms	毎秒14.3 tok

　まず確認できたのは、DEV=NVの指定により、外部GPUが実際に計算処理を担っているという事実だ。「動く」ことは確認できたが、そのパフォーマンスの中身を分析すると、現時点での課題が浮き彫りになる。

　特筆すべきは、生成時のメモリスループットだ。実測では毎秒約15GBと表示されているが、RTX 5060 Tiの理論帯域は毎秒448GBに達する。

　つまり、現時点ではGPUが持つポテンシャルのわずか3%程度しか引き出せていないことになる。

　なぜ、これほどの乖離（かいり）が生まれるのか。その原因を考察すると、大きく2つのボトルネックが浮かび上がる。

　1つは、インタフェースのレイテンシだ。自己回帰的なトークン生成では、1トークンごとに多数の小さなカーネルを起動する必要がある。

　今回のThunderbolt 5接続（PCIe 4.0 x4制限）では、カーネルの起動と同期のたびに外部接続を往復することになり、その通信レイテンシが演算性能を完全に食いつぶしている可能性がある。

　もう1つは、ソフトウェア側の最適化不足だ。tinygradのNVIDIAバックエンドが生成するカーネル自体の効率が出ていない可能性が高い。

　これを確認するため、以下のコマンドでカーネルの自動探索（JITBEAM=2）を有効にした検証も試みた。

```shell

DEV=NV JITBEAM=2 python3 benchmarks/benchmark_llama.py

```

　しかし、この探索プロセス自体が24時間かかっても終了せず、さらにはOSごとフリーズするといった不安定な挙動に見舞われたため、最適化後の真の数値を計測するには至らなかった。

　また、初動の3トークンで発生する「ウォームアップ」の重さも無視できない。

　1トークン目に約5秒かかるのは、JITコンパイルに伴う初回のみのコストだが、短いプロンプトを繰り返す対話用途では大きなストレスとなるだろう。

1トークンあたりの生成時間（ms）結果

まとめ

　正直に言えば、TinyGPUはまだ「常用できる」段階にはない。動作は非常に不安定で、1Bクラスの軽量モデルですら毎秒14トークン程度にとどまっており、実用的な推論性能が出ているとは言い難いのが現状だ。

　しかし、Appleから正式に認証を受け、SIPを有効にしたまま外部GPUを計算資源として扱えるようになったという「枠組み」の達成は、MacにおけるAI開発の歴史において極めて大きな前進だ。

　かつてIntel MacでeGPUがたどった道のように、このTinyGPUもまた、ソフトウェアのアップデートを通じて実用的なツールへと育っていくことを期待せずにはいられない。

　Apple Silicon MacでローカルAIの限界を追求し、CUDAエコシステムとの橋渡しを求めるユーザーにとって、この動向は引き続き追いかける価値があるといえよう。