Maya v1.1.11：GPUメモリ内訳表示、設定ファイルでのエキスパートプールサイズ指定

Project Mayaは、mw00 が開発する GLM-5.3-Flash (321B MoE) を NVIDIA GPU で動かすローカル推論エンジン・サーバー・ダッシュボード・量子化ツールです。今回の更新（v1.1.11）では、Monitorで各GPUのメモリ内訳を表示する機能と、設定ファイルでエキスパートプールのサイズを指定する機能が追加されました。

今回の要点

• MonitorのUI刷新：GPUごとのVRAM使用内訳（重み、KVキャッシュ、アクティベーション等）を棒グラフで表示し、リソース不足の原因を特定しやすくしました。
• 32GB環境での262kコンテキスト：RTX 4080 SUPER（32GB改造版）で262,144トークンのコンテキストウィンドウを実測。FP16 KVストリーミングにより、専門家の読み出しはロード後にディスクアクセスゼロを達成しました。
• AMD GPU対応の拡大：ROCm 10 (hipBLASLt 100500) 向けに gfx1151 (Strix Halo) のチューニングテーブルを追加。また、APUと離散GPUを組み合わせた混合構成の利用を許可しました。
• V100/Volta向け最適化：推論速度のボトルネックとなっていた再帰処理や注意機構を高速化し、V100でのプロンプト処理時間を大幅に短縮しました。

MonitorのGPU表示を「何で埋まっているか」表示へ変更

ダッシュボードの「Monitor」タブにおいて、GPU使用状況の表示方法が一新されました。従来の表形式から、GPUごとのメモリ使用内訳を棒グラフで視覚化するカード形式に変更されています。

この新しい表示では、モデルの重み、KVキャッシュ、アクティベーション、ドラフター、専門家プール（Expert Pool）、CUDAコンテキスト、他のプログラム、空きメモリなどが区別されて表示されます。各バーのセクションにカーソルを合わせると、すべてのGPUのバーで該当部分が強調表示され、クリックすると詳細な説明と推奨事項が表示されます。また、GPUの負荷、電力、温度、PCIeリンク情報もカード内に統合されました。

この変更により、例えば「他のプログラムがメモリを占有しているため、再起動して専門家プールにメモリを割り当てるべき」といった具体的なアドバイスが得られるようになります。AMD GPUの場合、ドライバーがプロセスごとのメモリ使用量を正確に報告しないため、エンジン起動時の計測値に基づいて表示されます https://github.com/mw00/project-maya/pull/191。

32GB 4080 SUPERでの262kコンテキスト実測とチューニング

大容量VRAM環境における長文コンテキストの実測報告が、ユーザー Micro-ATP 氏から報告されています。この環境では、RTX 4080 SUPER（32GB VRAMに改造済み）と Threadripper 3970X、そして SATA SSD が使用されています。

設定は以下の通りです。専門家のプールは約 23.15 GiB が VRAM に、69.72 GiB が RAM に配置され、一度ロードされると専門家のディスク読み取りはゼロになります。

利用者の報告

Micro-ATP 氏は、この構成で 262,144 トークンのコンテキストウィンドウ（FP16 KVストリーミング、GPUウィンドウ 32,768）をテストしました。結果、以下の推論速度が記録されています。

MTP（Multi-Token Prediction）は 75%、DFlash2 は 91% のドラフトを受け入れました。この報告は、32GB VRAMでも適切なチューニングにより超大容量コンテキストが実用的な速度で動作することを示しています https://github.com/mw00/project-maya/issues/200。

HIP: gfx1151チューニングと混合GPU（APU+離散）サポート

AMD GPUユーザー向けに、Strix Halo (gfx1151) 向けのチューニングと、APUと離散GPUを組み合わせた混合構成のサポートが追加されました。

ROCm 10 (hipBLASLt 100500) では、従来のチューニングテーブル（100202/100401用）が使用できないため、すべてのプロンプト GEMM が未チューニング状態になっていました。今回追加された gfx1151-glm-hipblaslt-100500.txt は、Radeon 8060S で T=8192 の条件下で生成された 84行のテーブルです。これにより、ROCm 10 環境でのパフォーマンスが 67-72% 向上する可能性があります https://github.com/mw00/project-maya/pull/203。

また、APUと離散GPUを混合で使用する場合の制限が解除されました。離散GPUが優先され、APUは残りのメモリを割り当てます。環境変数 STRATA_GLM_EXPERT_HELPER=1 を設定することで、GPU 1（APUなど）を専門家ヘルパーとして使用し、GPU 0 に trunk layers と MTP を集中させる構成が可能になります。これにより、UMAヘルパーは既存のピン留めRAMティアをエイリアスするため、重みの追加コピーは不要です https://github.com/mw00/project-maya/pull/201。

GLM KDA再帰処理の最適化 (Volta/V100向け)

Voltaアーキテクチャ（V100など）におけるプロンプト処理のボトルネックとなっていた、KDA再帰処理と注意機構（Attention）の最適化が行われました。

KDA再帰処理（kda_rec）は、以前はヘッドごとに1ブロックずつ処理していましたが、これを並列化することで高速化されました。V100-PCIe-32GB 環境でのテストでは、27Kトークンのプロンプト処理時間が 4.71秒 から 3.31秒 へ短縮されました（約30%向上） https://github.com/mw00/project-maya/pull/199。

また、Volta向けの注意機構（mla_attn）も、16ヘッドずつ処理していたものを32ヘッドずつ処理する2パス形式に変更されました。これにより、27KプロンプトのDSA注意処理時間が 22.5秒 から 11.8秒 へとほぼ半減しました https://github.com/mw00/project-maya/pull/196。

DFlash検証ウィンドウのNUMA対応とV100スタック問題修正

DFlashドラフターの検証ウィンドウに関する、NUMAノード対応とV100でのスタックオーバーフロー修正が行われました。

Ryzen 9 7950X のような、1つのNUMAノードに複数のL3キャッシュドメイン（CCD）を持つCPU環境において、ウィンドウのCPUプールをL3ドメインごとに分離する機能が追加されました。これにより、RAMティアの専門家がPCIe経由ではなく、ローカルCPUに直接アクセスできるようになり、パフォーマンスが向上します。

利用者の報告

merbanan 氏は、V100-PCIe-32GB + Ryzen 9 7950X 環境で、このNUMA対応とスタック修正（moe_win_group_kernelのテーブルを共有メモリへ移動）を組み合わせたテストを行いました。その結果、2つのCPUレーン（L3ドメイン別）を使用した場合、DFlashの推論速度は 25.6 / 27.6 / 32.2 tok/s に向上し、Plain（通常）の 24.5 / 26.4 / 28.0 tok/s に近づきました。ドラフトの受け入れ率は 92% でした。また、以前のスタック問題（「out of memory」）が修正されたことで、400 MiB のVRAM予約下でもウィンドウが正常に動作するようになったと報告されています https://github.com/mw00/project-maya/pull/197。

DFlash検証ウィンドウのNUMA対応とV100スタック問題修正 の項目一覧

• #195 Verify window: moe_win_group_kernel's tables in shared memory - as a thread's locals they made every DFlash window launch fail "out of memory" on a V100 at a 400 MiB reserve (PR・2026-10-15)

v1.1.11 リリースとモニター機能の追加

上記の変更を含む v1.1.11 がリリースされました。ダッシュボードの「About > Update」または git pull 後に ./setup.sh（Windows: START-MAYA.bat）を実行することで、エンジンが再コンパイルされ、新しい機能が有効になります。

また、専門家プール（Expert Pool）のサイズを構成ファイルで明示的に設定できるようになりました。デフォルトの --expert-cache auto は、空きVRAMから予約メモリを引いたサイズを計算しますが、Windowsでは割り当て前に読み取られる空き容量が約1GB過大評価されることがあり、VRAMオーバーフロー時にシステムRAMへのページング（推論速度の大幅低下）を引き起こす可能性があります。この設定により、そのようなリスクを回避しながらプールサイズを最適化できます https://github.com/mw00/project-maya/releases/tag/v1.1.11。

GLM Expert PoolのEvictionポリシーをLRUへ変更

VRAM、RAM、NVMe SSDにまたがる環境において、モデルのエキスパート（専門部分）をメモリ上に保持する際、どのデータを削除するかを決定する「Eviction（入れ替え）ポリシー」が変更されました。これにより、以前は「古い順」を優先していた入れ替えが、「最近使われた順（LRU）」をデフォルトとするようになりました。

この変更により、VRAMのヒット率が向上し、推論速度が改善されます。具体的には、既存のベンチマーク（Maya-M、3090 + 3060環境）において、デコード速度が2.6%向上し、VRAMヒット率が54.5%から55.9%に上昇しました。また、3台のTesla V100-16GB（計48GB）環境でのテストでは、96.5GBのモデルにおいて約76GBのエキスパートプールを保持しており、トークン1つあたり約1つのエキスパートがNVMe SSDから読み込まれる状況で、この改善が確認されています。

この変更は、VRAM、RAM、SSDを跨いでモデルを配置するユーザーにとって、特にSSDからの読み込み頻度を減らし、レスポンス速度を安定させるために重要です。なお、従来の「古い順」を優先する挙動を維持したい場合は、環境変数 `STRATA_GLM_VRAM_EVICT=least`（または `0`）を設定することで対応可能です。

根拠: PR #210: glm: the expert spares evict by recency by default (VRAM_EVICT=lru)

Calibrationでホストの追加CPUスレッド候補を試すように改善

エンジン内部のCPUスレッド数だけでなく、ホストマシン全体のCPUスレッド数も候補としてスキャン対象に追加されました。これにより、マルチGPU環境やハイブリッドCPU環境において、より最適なスレッド数を見つけやすくなります。

従来は、エンジンが使用するスレッド数「以下」の候補しか試されませんでした。今回の改善により、エンジンが使用するスレッド数「以上」の候補（ただし、デフォルト数と同じ数や2未満の数は除く）も試されるようになりました。特に、3つ以上のGPUを持つ環境では、エンジンが1つのNUMAノードの物理コアからプールサイズを決定するため、ホスト全体のCPUスレッド数がより最適な場合があり、そのようなケースに対応できます。

この変更により、スレッド数の候補範囲が広がりますが、エンジン自身のスレッド数より3%以上性能が向上しない場合は採用されないため、ノイズによる誤った選択は防がれます。これにより、より複雑なハードウェア環境でも最適なスレッド数を見つけやすくなります。

根拠: PR #209: calibrate: try the host's extra CPU-thread candidates above the engine's own too

GLM Expert Cache設定のバグ修正とVRAM Reserve機能

設定ファイル（config）で指定していた `--expert-cache` と `--vram-reserve-mib` のパラメータが、それまで無視されていたバグが修正されました。これにより、ユーザーは設定ファイルを通じてエキスパートプールのサイズとVRAMの予約量を明示的に制御できるようになります。

従来、設定ファイルでこれらのパラメータを指定しても無視され、環境変数 `STRATA_GLM_RESERVE_MB` でのみ制御可能でした。今回の修正により、設定ファイルの `args` セクションで以下のように指定できるようになりました：

• `--expert-cache auto`（デフォルト）：空きVRAMから予約量を差し引いたサイズをプールとして確保。確保後、実際に空きVRAMを再確認し、不足分があればプールを縮小する処理を最大6回繰り返す。
• `--vram-reserve-mib`：VRAMに予約する容量（MB単位）を指定。

この変更により、特にWindows環境や、VRAMが限られている環境において、プールのサイズを適切に制御し、メモリ不足によるエラーを防ぐことが可能になります。

根拠: PR #192: GLM expert pool sizing: --expert-cache auto|N and --vram-reserve-mib in the config, checked once the pool is written

出典

• Project Maya v1.1.11
• #203 HIP: gfx1151 hipBLASLt tuning table
• #201 HIP: enable mixed APU/discrete GPUs
• #200 Maya-S24 on a 32 GB 4080 SUPER + 3970X: 262k context and tuning results
• #199 GLM prompt: the KDA recurrence over 4 blocks a head
• #196 GLM prompt attention on Volta
• #197 DFlash verify window on one NUMA node
• #195 Verify window: moe_win_group_kernel's tables in shared memory
• #191 Monitor: what fills each GPU