「高性能GPU×共有メモリ」でLLMのパフォーマンスは良好

　今回は「LM Studio」のパフォーマンスも検証した。LM Studioはオープンソースの大規模言語モデル（LLM）を動かすためのアプリで、いわゆるチャット型のAIアシスタントをオンデバイスで実行可能だ。 　ここではLLMの性能テストが直接の目的ではないが、比較的規模が大きく、実用性の高そうなモデルとして「Qwen2.5 Coder 32B Instruct」を使うことにした。評判の高い「Llamma 3.2」向けAIモデル「Qwen2.5」を、プログラマー向けにトレーニングしたものだ。ランタイムの実装はAppleのGPUライブラリ「Metal」を用いており、推論演算に特化したNPU「Neural Engine」は利用しない。 　LM Studioをテストに用いた理由は、M4チップファミリーを搭載する新型MacBook Proが発表されたときに、Apple自身が「このアプリの強力な開発プラットフォームになり得る」と訴求していたからだ。実際にテストをしてみると、Appleがそう主張した理由が分かった。Apple Siliconの広帯域共有メモリがLLMを稼働する際に極めて有利に働くからだ。 　テストに用いたAIモデルは、日本語の質問にはあまり良い品質の回答は得られないが、プログラミングの補助に使うのであればそこそこ使える感じだ。このモデルは320億パラメーターで、容量が17GB以上ある。 　このモデルをTUF Gaming A16（FA607PI）で動かすと、全く話にならないほど文字出力が遅い。GPU（GeForce RTX 4070 Laptop）のグラフィックスメモリが8GBしかなく、AIモデルを収納しきれないからだ。結果としてGPUには一部の処理が割り振られるだけで、大部分（今回であれば95％）がCPUに回されてしまう。 　その点、今回試したM4ファミリーのMacでは、M4チップ以外は共有メモリ内にAIモデルを格納できた。よって、GPUの性能をフルに生かすことも可能だった。結果はグラフの通りだが、「これをローカルで動かす必要があるのか」という議論はさておいて、将来的にローカルAIを実用レベルで動かせそうということはよく分かった。 　LLMをローカルで動かす利点として、より長いコンテクストに対応するための文脈を保存するためのメモリをより多く確保しやすいという利点がある。見方を少し変えると、より長いプログラム（コード）を作る際に、過去の指示履歴をより多く覚えておいてくれるということになるので、「プログラミングの補助」としてLLMをローカル稼働させることは一定のメリットがあるかもしれない。ただし、ローカルで動かすLLMがより賢く、本当に使い物になるまでは、もう少し時間がかかるだろう。 　ともあれ、今回のテスト結果を通して外付けGPUで扱いきれないサイズのデータを扱う場合は、Apple Siliconの共有メモリアーキテクチャは有利に働きやすいということがよく分かった。自身が使うアプリごとに状況は異なるが、このことは心に留めておきたい。