山村商店

Project Maya v1.1.9：EXL3デコードのTensor Core対応と4.05bpwサポート

ProjectMayaローカルLLMGLMGPULLM

目次
  1. 今回の要点
  2. v1.1.9：EXL3量子化のTensor Core対応と4.05bpwサポート
  3. v1.1.7：Windows環境の速度改善とRAM最適化
  4. v1.0.34以降の修正とベンチマーク報告
  5. Windows環境でのRAM残留層（Resident Tier）容量上限問題
  6. DFlash2 bf16 DrafterでのIllegal Memory Access不具合
  7. EXL3量子化モデルのCPUラン利用とHIP対応、コミュニティ向け最適化
  8. AMD GPU 初期設定の自動化と Tesla P40/RTX 3090 実測ベンチマーク
  9. HIP 環境でのマルチ GPU 対応拡大：3 GPU 以上とビジョンウォームアップの改善
  10. Blackwell RTX PRO 4000/6000 でのベンチマーク報告
  11. エンジン停止時のサイレントウォッチドッグ機能の改善
  12. CPU レーンキャリブレーションの精度向上：vCPU 環境での測定不備修正
  13. ディスクスロット有効時におけるチェックポイント保存不具合の報告
  14. RTX 3090 Ti + EPYC 環境でのデコード高速化事例
  15. RTX 3090 環境でのディスクボトルネックによるデコード遅延
  16. 続報：RTX 5080 での CUDA Prefill 速度とチューニング余地
  17. 続報：Threadripper PRO + 4x RTX 3090 での EXL3 量子化モデルベンチ
  18. MI100 (CDNA 1) でのテスト失敗とウェーブサイズ問題
  19. 出典

Project Mayaは、mw00が開発するGLM-5.3-Flash（zai-org・321B MoE・MITライセンス）をNVIDIA GPUで動かすためのローカル推論エンジン、サーバー、ダッシュボード、量子化ツールです。Strata（Niko1221/Strata）のエンジンとサーバーを基盤とし、OpenAI/Anthropic互換APIを提供します。今回は、v1.1.7でのWindows環境の速度とRAM階層の改善、モデルファイルの変更に対する保護、INT8キャッシュのプロンプト処理の高速化と、v1.1.9でのEXL3処理の高速化および4.05bpw量子化モデルの追加について紹介します。

今回の要点

  • v1.1.9でEXL3デコードがRTX 30以降のTensor Coreに対応 ：RTX 3090とRTX 5060 Ti 8枚の構成では、MTPブロックおよびDFlash2を使用したEXL3-4.05bpwのデコードが14～30%高速化し、NVIDIA限定の実験的な4.05bpw量子化モデルがセットアップに追加されました。
  • Windows環境でのRAM残留層（Resident Tier）容量制限：64GB PCで約45GBで停止し、約7GBが未使用になる現象が報告されています。
  • DFlash2 bf16 Drafterでのクラッシュ不具合：初回デコード時に「illegal memory access」で強制終了する事象が確認されています。
  • v1.1.7でWindowsの速度改善とRAM最適化：バックグラウンド時の速度低下が修正され、RAM残留層のピン留め制限が改善されました。
  • EXL3 CPU活用とHIP対応の進捗：単GPUでのCPUラン利用、AMD GPU（HIP）対応、Q8_0量子化モデルの高速化がPRとして提出されています。

v1.1.9：EXL3量子化のTensor Core対応と4.05bpwサポート

v1.1.9では、EXL3量子化モデルのデコード処理がRTX 30シリーズ以降のTensor Coreを活用して高速化されました。v1.1.9では、RTX 3090とRTX 5060 TiでEXL3のエキスパートカーネルが約1.8倍高速になり、RTX 3090と8枚のRTX 5060 Tiを用いたEXL3-4.05bpwの構成で、MTPブロック使用時とDFlash2使用時にデコードが14〜30%高速になりました。v1.1.9では、turboderpによる4.05bpw量子化モデルがNVIDIA専用の実験的な選択肢としてセットアップに追加されました。

この変更は、NVIDIA GPU（RTX 30以降）ユーザーにとって、より低ビット数の量子化モデルを高速に動作させることを可能にし、VRAMの節約と推論速度の両立に寄与します。V100、T4、RTX 20シリーズなどの旧世代GPUでは、従来のデコードカーネルが維持され、v1.1.8と同等の速度と出力が保証されています。

v1.1.7：Windows環境の速度改善とRAM最適化

v1.1.7では、Windows環境でバックグラウンド時の速度低下とRAM層のピン留め容量の問題が修正されました。特に、Mayaのウィンドウがバックグラウンドにある際の速度低下が修正され、CPUレーンがハイブリッドCPUの効率コアに割り当てられるのを防ぎました。また、RAM残留層のピン留め制限に対して、Windowsがピン留めを拒否した場合でも、残りの容量を測定して適切なサイズに調整する仕組みが導入されました。

これにより、128GB PCなど大容量メモリ環境でも、RAM残留層が上限近くまで効率的に使用され、SSDからの読み込みが減少しました。さらに、セットアップ後にモデルファイルが変更されるのを防ぐガードも追加され、整合性エラーのリスクが低減されました。

v1.0.34以降の修正とベンチマーク報告

v1.0.34以降、v1.1.0からv1.1.5にかけて、複数の修正と改善が行われました。特に、マルチGPU環境でのパフォーマンス向上と、EXL3量子化モデルのサポートが強化されました。ユーザーからのベンチマーク報告では、4x V100環境で26.7 tok/s、RTX 5090環境で最大25.1 tok/s、2x RTX 5880 Ada環境で54.5 tok/sなどの結果が報告されています。

利用者の報告

4x Tesla V100-PCIE-32GB環境（v1.1.0）
Issue #130 で、4枚のV100（PCIe）を使用したベンチマークが報告されました。GLM-5.3-Flash Maya-L IQ3_Sモデルを使用し、26.7 tok/sのデコード速度が確認されています。NUMAノード構成やPCIeリンクの生成・幅、NVLink接続の有無がパフォーマンスに影響している可能性があります。

RTX 5090 32GB環境（v1.1.3）
Issue #139 で、RTX 5090（PCIe 5.0 x16）とIntel i9 13900k、64GB DDR5 RAMの環境でベンチマークが報告されました。IQ2_XXS量子化モデルを使用し、デコード速度は21.4〜25.1 tok/s、プリフェッチ速度は635〜2173 tok/sが測定されています。

2x RTX 5880 Ada 45GB環境（v1.1.4）
Issue #149 で、2枚のRTX 5880 Ada（45GB）とIntel Xeon Gold 5420+、393GB RAMの環境でベンチマークが報告されました。Maya-Lモデル（156.3GB）を使用し、デコード速度54.5 tok/s、プリフェッチ速度1401 tok/s（8Kコンテキスト）が測定されています。

2x RTX 3090環境（v1.1.5）
Issue #169 で、2枚のRTX 3090（24GB）とAMD Ryzen 7 5800X3D、125.7GB RAMの環境でベンチマークが報告されました。Linux環境で動作し、PCIe 3.0/4.0のリンク構成が確認されています。

Windows環境でのRAM残留層（Resident Tier）容量上限問題

Windows 11 Pro for Workstations（ビルド 26200）環境で、64GB RAMのPCにおいてRAM残留層が約45GBで停止し、約7GBが未使用になる現象が報告されています。この現象は、Windowsのページロック制限（pinning cap）が関与している可能性があります。

報告者によると、STRATA_GLM_RAM_GB を60や61に設定しても、RAM残留層のサイズは45.08GBのまま変化せず、約3分の1のエキスパートがSSDから読み込まれています。デコード速度は約8 tok/s（正確なデコード時）に留まっています。ログでは、CUDA0のピン留めキャップが33.00GB、RAM残留層が45.08GBに設定されていることが確認されています。

利用者の報告

Windows 11 Pro for Workstations + RTX 3090 24GB（v1.1.x）
Issue #185 で、@Hosein20000 により、64GB RAMのPCでRAM残留層が約45GBで停止し、約7GBが未使用になる現象が報告されました。HVCI（仮想化ベースのセキュリティ）が有効な環境で、ページファイル64GB、コミット制限128GBの設定下で確認されています。Maya-S24（IQ2_XXS_S）モデルを使用し、--max-context 32768、--kv-streaming on、--prefill auto の設定で、デコード速度は約8 tok/sでした。

DFlash2 bf16 DrafterでのIllegal Memory Access不具合

DFlash2 Drafterをロードした環境で、bf16形式のDrafter GGUFファイルを使用すると、初回デコードリクエスト時に「illegal memory access」でエンジンが強制終了する不具合が報告されています。この現象は、トークン間のエキスパートテーブル更新（glm_fast_path.cu:4032）で発生し、次のリクエスト時にfast_boundaryのストリーム同期で表面化します。

一方、同じDrafterファミリーのQ4_K_M形式のDrafterファイルでは正常に動作します。この不具合は、Linux環境（ドライバー 610.57.04、CUDA 12.0）で7枚のRTX 3090（24GB）を使用した環境で再現されています。

利用者の報告

7x RTX 3090 24GB環境（Linux）
Issue #173 で、@waxinz により、DFlash2 bf16 Drafterを使用すると初回デコードでクラッシュし、Q4_K_M Drafterでは正常に動作することが報告されました。neko-legendsのGLM-5.3-Flash-Uncensored-EXL3（4bpw）コミュニティ量子化モデルを使用し、--layer-split auto で7枚のGPUに分散しています。エキスパートティアキャッシュは約23.5/24 GB per cardでした。

EXL3量子化モデルのCPUラン利用とHIP対応、コミュニティ向け最適化

複数のPR（#188、#186、#170）で、EXL3量子化モデルのCPUラン利用、AMD GPU（HIP）対応、Q8_0量子化モデルの高速化が提案されています。特に、単一GPU環境でのEXL3モデルにおいて、ルーティングされたエキスパートの大部分をCPUで処理する仕組みが導入され、デコード速度の向上が期待されています。

また、AMD Radeon RX 7900 XTX（25.8GB）でのEXL3テストが成功し、ポータブルEXL3カーネルがAMDカードでも正常に動作することが確認されました。Q8_0量子化モデルでは、BF16 keep16行の高速パスが量子化されたアクティベーションに対して動作するため、ホスト側のQ8_0コピーが追加され、パフォーマンスが向上しています。

AMD GPU 初期設定の自動化と Tesla P40/RTX 3090 実測ベンチマーク

前提: Maya は、初期実行時にバックエンドを自動検出する仕組みを持っています。従来は NVIDIA GPU が存在しない環境でも NVIDIA 環境を前提としたチェックを実行し、エラーで停止する問題がありました。

何が変わったか: 設定ファイルや引数がない状態で初回実行する際、NVIDIA GPU がない場合にサポート対象の AMD GPU（RX 7900, RX 9070/R9700, Strix Halo/Gorgon Halo）を自動検出し、バックエンドを `hip` に選択するようになりました。修正は `maya.py` の 5 行です https://github.com/mw00/project-maya/pull/190。

なぜ重要か: AMD GPU ユーザーが、手動でバックエンドを指定することなく、エラーなく Maya を起動できるようになります。

根拠: https://github.com/mw00/project-maya/pull/190

利用者の報告

AMD GPU 初期設定の検証: @thomas9120 氏は、サポート対象 AMD GPU 環境において、`--backend` 引数なしで初回実行した際、正しく `hip` が選択され、NVIDIA 環境でのエラーが発生しなくなったことを報告しています https://github.com/mw00/project-maya/pull/190。

Tesla P40 (Pascal) 実測データ: @hengwen1 氏は、実験的な Pascal ビルド（sm_61）を用いた 3 枚の Tesla P40 (24 GB) 環境での報告です。Xeon E5-2658 v2 2 台、RAM 110 GB、Debian、CUDA 12.9、Maya v1.1.7 の環境で、レイヤースプリット（`--gpu 0,1,2`）を実行しました。デコード速度は 9.2 tok/s、プレフィルは 204 tok/s (8K) を記録し、各トークンのエキスパートの 91-96% が VRAM に収まり、SSD からの読み出しはゼロでした https://github.com/mw00/project-maya/issues/189。

RTX 3090 (2 枚) 実測データ: @catonooka 氏は、2 枚の RTX 3090 (24 GB) と Threadripper PRO 3955WX、RAM 247 GB の環境で、EXL3-3.05bpw モデルを実行しました。Maya v1.1.9 で、2 GPU スプリットは問題なく動作し、デコード速度は 29.2 tok/s を記録しました https://github.com/mw00/project-maya/issues/187。

HIP 環境でのマルチ GPU 対応拡大：3 GPU 以上とビジョンウォームアップの改善

前提: HIP 環境では、エンジン側は 2 GPU 以上の使用をサポートしていましたが、設定ファイルでの手動設定が必要でした。また、ビジョンエンコーダは CPU フォールバックを使用し、GPU メモリを確保しないため、ウォームアップの効果が限定的でした。

何が変わったか: 3 GPU 以上の構成を `maya.py` が正式に受け付けるようになり、設定ファイルでの手動操作なしで利用可能になりました https://github.com/mw00/project-maya/pull/183。また、HIP 環境では CPU フォールバック時のビジョンエンコーダウォームアップがスキップされるようになりました https://github.com/mw00/project-maya/pull/184。

なぜ重要か: 2 GPU 以上の HIP 環境ユーザーが、より簡単にマルチ GPU 構成を構築・利用できるようになります。

根拠: https://github.com/mw00/project-maya/pull/183、https://github.com/mw00/project-maya/pull/184

利用者の報告

HIP マルチ GPU 対応の検証: @izabera 氏は、2 GPU 以上の構成がエンジン側で既にサポートされていたが、設定ファイルでの手動設定が必要だったと述べ、今回の変更により `maya.py` がオプションを正式に受け付けるようになったことを報告しています https://github.com/mw00/project-maya/pull/183。

Blackwell RTX PRO 4000/6000 でのベンチマーク報告

前提: RTX PRO 4000 (24 GB) と RTX PRO 6000 (96 GB) は、Blackwell アーキテクチャを搭載した新しい GPU です。

何が変わったか: 初の実測ベンチマークデータが報告されました。

なぜ重要か: 新規 GPU における Maya の性能目安が得られます。

根拠: https://github.com/mw00/project-maya/issues/174、https://github.com/mw00/project-maya/issues/171

利用者の報告

RTX PRO 4000 Blackwell (24 GB) 実測データ: @morrisfamily 氏は、i9-13900K、RAM 128 GB (3600 MT/s)、RTX PRO 4000 Blackwell (24 GB)、Ubuntu 26.04.1、Maya v1.1.7 の環境で、Maya-S24 モデルを実行しました。デコード速度は 24.7 tok/s、プレフィルは 1146 tok/s (8K) を記録しました。コンテキスト 131072 への拡張も、`--kv-streaming on` により速度低下なしで可能でした https://github.com/mw00/project-maya/issues/174。

Tesla V100 (32 GB) 実測データ: @mw00 氏は、Xeon Gold 6138 2 台、RAM 183 GB、Tesla V100 (32 GB)、Ubuntu 26.04.1、Maya v1.1.7 の環境で、Maya-S24 モデルを実行しました。デコード速度は 26.8 tok/s、プレフィルは 541 tok/s (8K) を記録しました https://github.com/mw00/project-maya/issues/171。

エンジン停止時のサイレントウォッチドッグ機能の改善

前提: エンジンの停止を検知するウォッチドッグ機能は、サービススレッドが回転している場合、GPU がアイドル状態でも健全とみなされていました。

何が変わったか: GPU テレメトリを用いて、GPU がアイドル状態かつ一定時間（`STRATA_ENGINE_STALL_S`）沈黙している場合、エンジンを終了するようになりました https://github.com/mw00/project-maya/pull/181。

なぜ重要か: GPU ハングアップによる、見かけ上は正常だが実際には停止している状態をより正確に検知し、リカバリできるようになります。

根拠: https://github.com/mw00/project-maya/pull/181

利用者の報告

サイレントウォッチドッグ機能の検証: @briepala 氏は、GPU テレメトリを用いた新しい検知ロジックにより、アイドル状態の GPU ハングアップを正しく検知し、エンジンを終了できることを報告しています https://github.com/mw00/project-maya/pull/181。

CPU レーンキャリブレーションの精度向上：vCPU 環境での測定不備修正

前提: キャリブレーションツール（`./maya.sh --calibrate`）は、エンジンが使用する CPU レーン数以下のスレッド数しか測定していませんでした。

何が変わったか: エンジンが使用するスレッド数以上のキャリブレーションが可能になりました。`STRATA_GLM_CPU_LANE_MAX=N` を設定することで、エンジンが使用するスレッド数以上のスレッド数を測定し、最適な数を見つけることができます https://github.com/mw00/project-maya/pull/178。

なぜ重要か: KVM ゲストなどの vCPU 環境で、より最適な CPU レーン数を見つけ、パフォーマンスを向上させることができます。

根拠: https://github.com/mw00/project-maya/pull/178

利用者の報告

CPU レーンキャリブレーションの検証: @Jw88888 氏は、16 vCPU の KVM ゲスト環境で、エンジンが 10 スレッドを使用している場合、キャリブレーションにより 14 スレッドを使用することで約 18% の高速化を報告しています https://github.com/mw00/project-maya/pull/178。

CPU レーンキャリブレーションの問題点: @needmorevram 氏は、キャリブレーションがエンジンが使用しないスレッド数を記録する可能性がある問題点を指摘しています。特に、3 GPU 以上のスプリットや DFlash2 環境では、共有プールに対してキャリブレーションが正しく機能しない可能性があります https://github.com/mw00/project-maya/pull/178#issuecomment-6169743588。

ディスクスロット有効時におけるチェックポイント保存不具合の報告

前提: ディスクスロット（`STRATA_GLM_DISK_QD`）を有効にすると、チェックポイントの保存が正しく機能しない問題が発生しています。

何が変わったか: ディスクスロット有効時、チェックポイントが保存されず、同じシステムプロンプトの新しいチャットがトークン 0 から読み込まれる現象が報告されました。

なぜ重要か: ディスクスロットを使用しているユーザーは、チェックポイント機能を利用できない状態です。

根拠: https://github.com/mw00/project-maya/issues/179

利用者の報告

ディスクスロット有効時のチェックポイント保存不具合: @jerem91150 氏は、Windows 11、RX 7900 XTX、Maya v1.1.7 の環境で、ディスクスロット有効時にチェックポイントが保存されず、同じシステムプロンプトの新しいチャットがトークン 0 から読み込まれる現象を報告しています https://github.com/mw00/project-maya/issues/179。

RTX 3090 Ti + EPYC 環境でのデコード高速化事例

AMD EPYC CPU と KVM 仮想環境において、CPU スレッド数と VRAM 退避ポリシーを調整することで、デコード速度を向上させる手法。

RTX 3090 Ti 単体環境で、`STRATA_GLM_CPU_LANE=14`（CPU スレッド割り当て）と `STRATA_GLM_VRAM_EVICT=lru`（VRAM 退避アルゴリズム）の設定により、デコード速度が 14.9 t/s から 18.4 t/s（約 23% 向上）に改善した。

仮想環境（KVM）や CPU 構成が異なる環境でも、適切なパラメータ調整により GPU 性能を最大化できる。

根拠: Speed report: RTX 3090 Ti + EPYC 7302P (KVM guest, 16 vCPUs), Maya-L: decode +23% with `STRATA_GLM_CPU_LANE=14` + `STRATA_GLM_VRAM_EVICT=lru`

利用者の報告

Jw88888 氏は、RTX 3090 Ti (24 GB) と AMD EPYC 7302P (KVM ゲスト、16 vCPU) 環境で Maya-L (v1.1.7) を使用し、上記設定によりデコード速度が 14.9 t/s から 18.4 t/s に向上したと報告している。

RTX 3090 環境でのディスクボトルネックによるデコード遅延

VRAM に収まりきらないモデルデータが SSD に配置される場合、デコード処理が SSD の読み込み速度に依存し、速度低下を引き起こす現象。

RTX 3090 (24 GB) + Ryzen 7 5800X 環境で Maya-S24 を実行したところ、デコード速度は 9.0 t/s と、README 記載の 3090 環境の約 3 分の留まった。エンジンの統計では、トークン生成時間の約半分が SSD 待機に費やされており、PCIe 3.0 x4 の DRAM-less NVMe SSD (Team TM8FP6001T) の読み込み速度 (約 1.3 GB/s) がボトルネックとなっている。

VRAM 容量が不足し、RAM や SSD にオフロードされる領域が生じると、GPU の性能を十分に発揮できない可能性がある。

根拠: Speed report: RTX 3090 24 GB (Ryzen 7 5800X, 62 GB RAM) - Maya-S24, 9.0 tok/s decode / 507 tok/s prefill (8K), Linux + disk-bound decode question

利用者の報告

  • RTX 3090（VRAM 16GB、RAM 49GB）環境で約 9 tok/s の推論速度となり、SSD 上のデータ読み込みがボトルネックになっていると報告。mw00

利用者の報告

itsmetamike 氏は、RTX 3090 (24 GB) + Ryzen 7 5800X (62 GB RAM) 環境で Maya-S24 (v1.1.4) を使用し、デコード速度が 9.0 t/s と低速になったと報告している。

開発者 mw00 氏は、この速度は VRAM 不足によりモデルの一部が SSD に配置され、PCIe 3.0 NVMe の読み込み速度がボトルネックになっているため想定内であると回答している。VRAM 128 GB の環境では 26 t/s、RAM 60 GB + PCIe 4.0 NVMe の環境では 13.3 t/s だったとの比較データも提示された。

続報：RTX 5080 での CUDA Prefill 速度とチューニング余地

前回の報告に続き、RTX 5080 におけるプリフィル（プロンプト処理）速度の実測値と、コンシューマー GPU 向けのチューニング可能性。

RTX 5080 (16 GB) + Ryzen 7 9800X3D 環境で Maya-S24 (v1.1.4) を実行した結果、プリフィル速度は 2K トークンで 106 t/s、8K トークンで 279 t/s だった。

コンシューマー向け GPU でも、CUDA プリフィルパスにチューニングの余地があることが示唆された。

根拠: CUDA prompt speed, single RTX 5080 (Maya-S24): 106/279 tok/s at 2K/8K - prefill tuning headroom on consumer NVIDIA

続報：Threadripper PRO + 4x RTX 3090 での EXL3 量子化モデルベンチ

大規模マルチ GPU 環境における、EXL3 量子化モデルの実測性能。

Threadripper PRO 3975WX (256 GB RAM) + 4x RTX 3090 (PCIe 4.0 x16) 環境で、Maya-L、EXL3-3.05bpw、EXL3-4.05bpw の各モデルをテストした。

Maya-L: pp ~600-700 t/s, decode ~38 t/s
EXL3-3.05bpw: pp ~800 t/s, decode ~42 t/s
EXL3-4.05bpw: pp ~400 t/s, decode ~19-21 t/s

EXL3 量子化モデルは、特に 3.05bpw において高いプリフィル速度を示したが、4.05bpw では速度が低下した。また、DFlash2 + EXL3 の組み合わせはチャット/DSH において正常に動作しなかったと報告されている。

根拠: Speed Report(s): Maya L, EXL3-3.05bpw, EXL3-4.05bpw Threadripper PRO 3975WX 32c, 256GB DDR4 (4x64gb), 4x 3090 PCIE 4.0x16

MI100 (CDNA 1) でのテスト失敗とウェーブサイズ問題

AMD Instinct MI100 (GFX908) 環境でのテスト実行結果。5 つのテストが失敗し、ウェーブサイズ (wave size) の不一致が原因と推測される。

47 テスト中 5 テストが失敗し、そのうち 2 つは「expected wave32, got wave64」というエラーにより失敗している。MI100 はデフォルトで wave size 64 を使用するため、wave size 32 を前提としたコードとの互換性問題が発生している可能性がある。

AMD CDNA 1 アーキテクチャ (MI100) での動作には、ウェーブサイズ設定の調整が必要である可能性が高い。

根拠: MI100 CDNA 1 GFX908 TESTING

利用者の報告

Elefant-Freeciv 氏は、AMD Instinct MI100 (GFX908) でテストを実行し、47 テスト中 5 テストが失敗したと報告している。失敗したテストには `hip_intrinsics`、`hip_glm_handoff`、`hip_glm_prefill_attention` などが含まれ、一部は「expected wave32, got wave64」というエラーにより失敗していた。

出典

【宣伝】SwitchBot 購入はこちらから

SwitchBot公式ページ
クーポン「AF-4903」で5％引き（アフィリエイトクーポンになりますのでご協力お願いします）
割引の詳しい仕組みに関してはこちらのページを参照ください。
製品ごとの特徴・紹介動画は SwitchBot 製品ガイド にまとめています。