WindowsでもローカルLLMが快適に？ 開発中ビルドで見つかった「AI向けメモリ割り当て機能」の正体：Windowsフロントライン（1/2 ページ）

Appleの新モデル「Mac mini」「Mac Studio」がローカルAI実行環境として優位性をアピールする中、Windows環境でもローカルLLMを快適に動作させるための準備が水面下で進んでいることが明らかになった。それが今後の市場にもたらす影響について解説する。

[鈴木淳也（Junya Suzuki），ITmedia]

　Appleが「Mac mini」「Mac Studio」の新モデルを発表したが、特徴はGPUへのNeural Acceleratorの追加や、M6でのデュアルNeural Engine搭載などを経てAI処理性能が強化されるなどして、ローカルLLM処理での優位性を強くアピールしている点にある。

• →新型「Mac mini」「Mac Studio」の“数字”を読み解く――驚異のAI性能と、日米価格設定のからくり

新たに発表されたMac mini（左）とMac Studio（右）

　もともと、初代Mac Studioはその潤沢なUnified Memoryを搭載可能という特徴を生かして、70Bなどの非常に高いパラメーターを持つLLMをローカル環境で実行可能な点が注目されていた。

　今回は比較的エントリークラスのMac miniでもローカルAI処理でのメリットをうたうなど、最先端AIモデルの技術革新と合わせて、デスクトップ型Macが一種の“ローカルAI実行マシン”としての地位を確立しつつあるといえる。

　そして、今回話題になっているのはWindowsの方だ。Windows Centralのショーン・エンディコット（Sean Endicott）氏などが報じているが、X（旧Twitter）ユーザーのXeno氏がWindows Insider ProgramのExperimental Channel（Future Platforms）で配信されている「Build 29648.1000」において、「Unified Memory」に関する設定が存在することを報告している。

　Experimental ChannelのFuture Platformsは、開発途上ビルドの中でも最も先行して開発が進められている“ブランチ”であり、一部では「Windows vNext」などとも呼ばれる。BetaWikiよれば、同ビルドは「Rubidium」（ルビジウム）の開発サイクルに属しており、「28xxx」番台だったBromine（臭素）に次いで開発が進められていた「29xxx」番台のKrypton（クリプトン）を引き継ぐものになる。

　なお、ルビジウム（Rb）は元素周期表で原子番号37番でアルカリ金属元素に属する。原子番号36番で希ガス（貴ガス）のクリプトンに次ぐ番号で、ここまで周期表通りに開発コード名が割り当てられていることが分かる。

開発コード名に使われる元素周期表（写真はイメージ）

GPU／NPUの利用可能メモリをカスタマイズする機能

　この機能は「Memory for graphics and AI acceleration」の名称が付いており、システム設定の詳細にある「Unified memory」の項目において、同メモリを画像処理やAIのアクセラレーションに割り当てる設定が可能だ。

　Xeno氏のスクリーンショットでは「Don't allow」「Recommended」「High」「Maximum」「Custom」の5つの選択肢があり、通常は「Recommended」がデフォルトになっているようだ。

　Windowsでタスクマネージャーを起動してGPUの項目を確認してみると分かるが、一般にGPUへのメモリ割り当ては「搭載メモリの約50％を上限」としている。外付けGPUかCPU内蔵GPUによっても異なるかと思うが、GPU向けのメモリは最低限度を確保しつつ、必要に応じてメインのヒープ領域との間でダイナミックに割り当てが行われる。

　Windowsにおける伝統的な仕様と言われるが、ここで50％を上限としているのはGPUにメモリを割り当てすぎて本体の動作が不安定にならないための工夫だとされる。

　今回の新機能は、このGPU（ならびにNPU）に割り当てられるメモリを事前に予約し、50％の壁を破りつつ、ダイナミックなページングが行われない形で安定動作可能なメモリ領域を確保するものとなる。

　ローカルAIのためにLLMをオンメモリで動作させる場合、まずメモリ帯域が重要となる。次いで、高いパラメーターを持つLLMの場合はオンメモリ動作のための大容量メモリが必要だ。特にコーディング支援や自律型AIエージェントを動作させる場合など、過去の対話履歴や巨大なソースコードをプロンプトに取り込むため、コンテキストウィンドウが肥大化する。

　この高速処理のためにKVキャッシュと呼ばれる領域が必要となるが、その際に大容量のメモリが使われるので、高速かつ大容量のUnified Memoryが求められるというわけだ。

　注意点としては、先ほどのWindows Centralの記事でも触れられていたように、現状でUnified Memoryを搭載したPC、具体的にはNVIDIA RTX SparkやAMD Ryzen AI MaxなどのSoCやAPUのみがその対象となる。

　AI処理には高速GPUや大きな処理能力を備えたNPUが必要だが、特にグラフィックスカードでは備え付けの高速メモリ容量が少なく、ある程度の性能を持ったローカルAIを実行するのに最低限の水準と考えられる16GBを確保するのも簡単ではない。

　その意味で、現状ではまだ“選ばれた”Windows PCのみが利用できる特権オプションだといえるかもしれない。

　もう1つの注意点として、今回の「Memory for graphics and AI acceleration」はMicrosoft側で公式には説明していない実験段階の実装であり、当該の「Build 29648」をUnified Memoryに対応したPCに導入したとしても、必ずしも項目が出現するとは限らない。

　記事中でも言及されているように、ViVeToolなどでDLL内のAPIを直接呼び出すような仕組みを利用しない限り、機能自体が利用できない可能性がある。