山村商店

【Project Maya】Project Maya v1.1.19 リリース: DeepSeek-V4.1-Flashの長文プロンプト処理が最大約1.5倍高速化

ProjectMayaローカルLLMGLMGPULLM

目次
  1. 今回の要点
  2. v1.1.19: DeepSeek-V4.1-Flashの高速化とプロンプト形式修正
  3. Windows環境でのTUI起動停止不具合の修正
  4. GLM Prefill最適化PRの再提出とWindows TUI不具合修正
  5. maya-ds4のマルチGPUハングとアイドル状態の修正・要望
  6. v1.1.18 リリースと主な変更点
  7. v1.1.17 リリース: GLM-5.3-Flash 高速化と DeepSeek-V4.1-Flash のチャンク処理改善
  8. APIサーバーのキュー溢れとタイムアウト処理の改善
  9. M aya v1.1.17 リリースとPR #313によるコミュニティ速度レポートの統合
  10. Radeon AI PRO R9700 (gfx1201) での検証と性能向上（続報）
  11. RTX 3090 4枚構成での1Mコンテキスト推論
  12. Fedora 44 での ROCm HIP コンパイラ未検出問題
  13. Windows ビルドでの sys/mman.h 未定義エラー
  14. Windows MSVCビルドでの __cpuidex 未定義エラー
  15. 並列実行(--parallel)時のタイミング情報共有バグ
  16. ROCm環境での混在GPUアーキテクチャによるカーネル実行失敗
  17. GLM-5.3-Flash (Maya-S24) の RX 7900 XTX + Strix Halo 実測ベンチマーク
  18. RX 7900 XT/XTX (gfx1100) 向け融合プロンプトエキスパートカーネルの有効化
  19. Linux HIP環境でのDeepSeekプロンプトデフォルト設定の修正
  20. PR #298: EXL3向けHIPプリフィルカーネル実装とAMD対応
  21. MI100 (gfx908) 環境でのテスト結果と既知の問題
  22. GLM Speculative Decodeのバックアップとウォームアップ修正
  23. 2x RTX 3090環境でのEXL3量子化モデルベンチマーク
  24. 混合GPU構成でのMaya-M実測とエージェント動作報告
  25. DGX Spark (GB10) での推論速度レポート
  26. CMP 170HX 64GBアンロック版でのベンチマーク
  27. Tesla T10 4枚構成でのマルチGPU推論速度
  28. GLMモデルのCPUレーン再タイミング設定の修正
  29. DeepSeek V4.1-flash のプリフィル速度低下報告
  30. DS4モードにおけるテンソル並列崩壊時の警告表示追加
  31. vision-memory.jsonの.gitignore追加
  32. maya-ds4のマルチGPUハングとアイドル状態の修正・要望
  33. Project Maya v1.1.18 リリースと主な変更点
  34. Project Maya v1.1.17 リリース: GLM-5.3-Flash 高速化と DeepSeek-V4.1-Flash 対応
  35. Windows環境でのTUI起動停止不具合の修正
  36. 出典

Project Maya は mw00 が開発する、GLM-5.3-Flash (zai-org・321B MoE・MIT ライセンス) を自分の NVIDIA GPU (1 枚から最大 16 枚) で動かすローカル推論エンジン・サーバー・ダッシュボード・量子化ツール。よく使うエキスパートを GPU、次を RAM、残りを NVMe SSD に置いて動かす。Strata (Niko1221/Strata) のエンジンとサーバーを元に GLM-5.3-Flash 向けに作り直したもの。OpenAI/Anthropic 互換 API、MIT ライセンス。AMD GPU と Windows は実験的な対応。

今回の要点

  • v1.1.19 リリース: DeepSeek-V4.1-Flashの長文プロンプト読み込みが最大約1.5倍高速化（回答品質は維持）。
  • プロンプト形式修正: エージェントやツール呼び出しの履歴が正しく保持されるよう、DeepSeek公式形式に準拠。
  • v1.1.18では、MSVCでのビルドとWindowsのテストビルドに関する不具合が修正された。
  • マルチGPU環境の改善: 2GPU環境でのハングアップ不具合修正と、アイドル状態の改善要望が報告されている。
  • GLM Prefill最適化: 複数GPUでのチャンクサイズ個別指定やメモリ確保に関するPRが再提出されている。

v1.1.19: DeepSeek-V4.1-Flashの高速化とプロンプト形式修正

v1.1.19では、DeepSeek-V4.1-Flashモデルにおける長文プロンプトの処理速度が大幅に向上しました。このモデルでは、レイヤー20〜39において、プロンプトの初期トークンはレイヤー20が保持する圧縮されたKVキャッシュのみを通じて参照される仕組みになっています。この特性を活かし、プロンプトの最後の約2,700トークン以外の部分については計算をスキップする最適化が実装されました。

この変更により、1枚のGPU環境では32Kトークンのプロンプトで約30%、Strix Halo搭載環境では8K〜16Kトークンのプロンプトで43〜54%の高速化が確認されています。全体的な読み込み速度は最大約1.5倍になりながら、回答品質は従来通り維持されています。さらに、環境変数 MAYA_DS4_PROMPT_SKIP=2 を設定することで、DeepSeek公式サーバーと同様に最後の128トークンのみを処理する形で、より大きな高速化が期待できます（回答にわずかな変化が生じる可能性があります）。この最適化は 0 に設定することで無効化できます。

また、プロンプトのレンダリング形式がDeepSeekの公式形式に準拠するよう変更されました。これにより、複数のシステムメッセージ、メッセージローカルなツール、並列ツール呼び出しの結果やそのIDが正しく保持されるようになり、エージェントセッションでの挙動が安定します。この変更は PR #300 により @Gazelle221B によって実装されました。

エンジンの終了処理も改善され、モデルの停止や切り替え時に不要な待機が発生しなくなりました。これは PR #306 により @loktar00 によって修正されています。

利用者の報告

v1.1.18におけるDeepSeek-V4.1-Flashの単一GPU環境でのパフォーマンスについて、@pietroMastro92 による報告があります。Windows 11 Pro for Workstations、RTX 4000 Ada Generation (20GB)、CUDA 13.0の環境において、v1.1.18はv1.1.17と比較してデコード速度が11.6トークン/秒から9.3トークン/秒へ、プリフィル速度が221トークン/秒から175トークン/秒へ低下したとの報告があります。この報告では、v1.1.18はv1.1.17より多くのエキスパートをVRAMに保持するものの、同じ条件で速度が低下しています。

この報告を受け、@mw00 による修正PR PR #320 が提出されています。単一GPU環境で --tp 1 と --threads on を設定することで、プリフィル速度が103トークン/秒から205トークン/秒へと約2倍の改善が確認されています。

Project Maya v1.1.19 リリース: DeepSeek-V4.1-Flashの高速化とプロンプト形式修正 の項目一覧

Windows環境でのTUI起動停止不具合の修正

この不具合は、@kelheor によって詳細な報告が行われ、@mw00 によって修正されました。RTX 4090、CUDA 13.1、MSVC 2022の環境で再現し、START-MAYA.bat を使用せずに --plain オプションを指定すると正常に動作することから、エンジン自体の問題ではなく、Windows固有のシグナル処理に起因することが特定されました。

GLM Prefill最適化PRの再提出とWindows TUI不具合修正

GLM-5.3-Flashモデルのプリフィル処理に関する複数の最適化PRが再提出されています。これらは、元々 @gopinath87607 によって作成されましたが、フォークの削除により閉じられていたものを、新しいフォークから再提出したものです。

主な変更点として、各GPUが独自のチャンクサイズを選択できるようになる PR #288、長文プロンプト処理時のメモリ確保に関する PR #283、MMQスクラッチ領域の最適化に関する PR #289、エキスパートスロットの保持数に関する PR #286 などが含まれます。また、プリフィル処理の各段階での時間配分を表示する PR #284 や、プロンプトパスのウォームアップに関する PR #285 も含まれています。

ROCm 10 (hipBLASLt 100401) における gfx1100 (RX 7900 XT) のためのテーブルも PR #292 で追加されました。これにより、プリフィル速度が2048トークンで315トークン/秒から449トークン/秒へ、8192トークンで382トークン/秒から602トークン/秒へと大幅に向上しています。

GLM Prefill最適化PRの再提出とWindows TUI不具合修正 の項目一覧

maya-ds4のマルチGPUハングとアイドル状態の修正・要望

GPU 1が100%の負荷状態になり、GPU 0が0%のまま、プロンプトが処理されないという現象でした。この不具合は @mw00 によって修正され、fix-303 ブランチでテスト可能です。

また、同じ環境において、2枚のGPUが交互に処理を行うため、片方のGPUがアイドル状態になるという報告が @mw00 によって行われています。レイヤースプリット（CUDA0 [0,19)、CUDA1 [20,39]+head）の構成で、GPU 0の平均利用率が57%、GPU 1の平均利用率が47%という結果が得られています。両方のGPUを同時に活用する改善が要望されています。

v1.1.18 リリースと主な変更点

v1.1.18では、DeepSeek-V4.1-Flash-1017の各PCへの適応、Windows + AMD Strix Halo搭載ラップトップでのデコード速度改善、Tesla P100でのGLM-5.3-Flash対応、Responses APIの追加などが行われました。特に、Windows + AMD Strix Halo環境では、ページファイルの管理方法が変更され、より多くのエキスパートがGPUに保持されるようになり、デコード速度が改善されました。

DeepSeek-V4.1-Flash-1017の単一GPU環境では、プロンプト処理時にエキスパートのVRAMを一時的に借用する仕組みが実装され、プロンプトチャンクのサイズが16Kまたは32Kトークンに拡大されました。これにより、デコード時により多くのエキスパートがVRAMに保持され、パフォーマンスが向上しています。

v1.1.17 リリース: GLM-5.3-Flash 高速化と DeepSeek-V4.1-Flash のチャンク処理改善

v1.1.17では、GLM-5.3-Flashの長文プロンプト処理が高速化され、DeepSeek-V4.1-Flashのチャンク処理が実装されました。DeepSeek-V4.1-Flash-1017のプロンプトがMayaの量子化形式で8192トークンのチャンク処理されるようになり、7枚のRTX 3090を搭載した環境では、32Kトークンのプロンプト処理速度が99トークン/秒から1010トークン/秒へと大幅に向上しました。

また、Maya-SモデルがMayaリポジトリから6ファイルのGGUFスプリットとして提供されるようになり、EngramテーブルがQ6_K形式で量子化されました。これにより、モデルファイルの総サイズが381GBから339.5GBに削減されました。

APIサーバーのキュー溢れとタイムアウト処理の改善

MayaのAPIサーバーは、キャンセルやタイムアウトしたリクエストを適切に処理できず、キューが溢れて新しいリクエストに応答不能になる問題がありました。v1.1.6で、GLM-5.3-Flash、--parallel 4、512kコンテキストを使用した環境において、キュー内のリクエストが長時間滞留する現象が報告されていました。

この改善により、キャンセルやタイムアウト発生時にキューが正常にクリアされ、サーバーが新しいリクエストを処理できるようになります。エージェントワークフローなど、短時間で多数のリクエストを発生させる利用環境において、サーバーの安定性が大幅に向上します。

根拠: Issue #314: Server queue filled with cancelled/timed out chat completion requests & stops responding to new requests

利用者の報告

jettoblack 氏は、v1.1.6、GLM-5.3-Flash、--parallel 4、512kコンテキストの環境で、エージェントワークフロー実行中にキュー溢れが発生し、単純な「hi」といったリクエストでも17件のリクエストがキューに溜まり、2時間以上経ってもタイムアウトしない状態になったと報告しています。この報告は Issue #314 で確認できます。

M aya v1.1.17 リリースとPR #313によるコミュニティ速度レポートの統合

v1.1.17がリリースされました。PR #313では、v1.1.12以降に報告されたコミュニティの速度レポートがREADMEの速度表に追加されています。

これにより、ユーザーは自身の環境に近いハードウェア構成での推論速度を参照しやすくなります。最も速い環境として、2枚のH100で124 tokens/sという数値がヘッドラインに掲載されています。

根拠: PR #313: README: the community's speed reports in the speed table

Radeon AI PRO R9700 (gfx1201) での検証と性能向上（続報）

Radeon AI PRO R9700 (gfx1201) 環境において、v1.1.12の適用によりデコード性能が約15%向上しました。ROCm 7.0 (pip ROCm SDK wheels) 環境での検証です。

v1.1.11では約18 tok/sだったデコード速度が、v1.1.12ではコールドスタートで19.7 tok/s、ウォームスタートで21.4 tok/sに向上しました。384Kコンテキストのテストも実施され、1Mコンテキスト（NoPE native）での針テストも111k、185k、296kトークンでパスしています。296kトークン時のKVメモリ使用量は約3.90 GBで、RAMティアへの干渉なしに完全な回復が確認されました。

根拠: Issue #213: Validation on Radeon AI PRO R9700 (gfx1201, ROCm 7.0): v1.1.12 +15% decode, 384K context tested, thinking control confirmed

RTX 3090 4枚構成での1Mコンテキスト推論

RTX 3090 4枚構成（1枚あたり24 GB）で、1Mコンテキストの推論が実証されました。Broadcom PEX880xx Gen4スイッチ経由で4枚のGPUを接続し、Xeon Platinum 8260M（376 GB RAM）環境でのテストです。

v1.1.17、Maya-Lモデル、--context 1048576、KVストリーミング有効、MTPドラフティング有効、4枚のGPUにモデルを分割（13/11/11/10）する設定で、デコード速度は51.4 tok/s（ルートアフィニティなしで44.2 tok/s）を記録しました。プリフィルは2Kトークンで約437 tok/s、8Kトークンで約700 tok/sでした。モデルはOptane pmem上に配置され、推論中はディスク読み込みが発生しない構成でした。

根拠: Issue #302: Speed report: 4x RTX 3090 (Gen4 x8 behind one PEX880xx switch), Xeon 8260M, 376 GB RAM, Maya-L at 1M context: 51.4 tok/s (44.2 without route affinity)

利用者の報告

foureight84 氏は、上記の環境で--calibrateを実行した結果、デコード速度が約40.2 tok/sに向上したと報告しています。また、--calibrateがエンジン自体のスレッド数よりも少ないCPUスレッドを試す可能性がある点にも言及しています。この報告は Issue #302 で確認できます。

開発者である mw00 氏は、この詳細なレポートを感謝し、チューニング済み実行結果（44.2 tok/s）がREADMEの速度表に追加されたことを明記しています。v1.1.18では、--calibrate は明確に速いと測定された場合を除き、設定ファイルのCPUレーン設定を維持するよう修正されました。このやり取りは Issue #302 comment で確認できます。(リンク: Issue #302 comment)

Fedora 44 での ROCm HIP コンパイラ未検出問題

Fedora 44環境において、ROCm HIPコンパイラとhipBLASが検出されないエラーが発生しています。Minisforum MS-S1 Max（gfx1151、Strix Halo）でのビルド時に確認されました。

必要なパッケージ（hipblas、hipcc、rocm-clang等）がインストールされているにもかかわらず、ビルドスクリプトがコンパイラを検出できない状態です。ROCm関連のパッケージは正常にインストールされているものの、環境変数やパスの認識に問題がある可能性があります。

根拠: Issue #301: ROCm HIP compiler and hipBLAS not found.

利用者の報告

paxsali 氏は、Maya v1.1.17、Fedora 44、gfx1151環境で、ROCm HIPコンパイラとhipBLASが見つからないというエラーに遭遇しました。インストール済みのパッケージ一覧にはhipblas、hipcc、rocm-clangなどが含まれていることを確認しています。この報告は Issue #301 で確認できます。

Windows ビルドでの sys/mman.h 未定義エラー

Windows 11環境でMayaをビルドする際、tests/ds4_cpu_bench.cppのコンパイルでsys/mman.hが見つからないエラーが発生しています。ROCm SDK wheels 10.2.0a20260930を使用するv1.1.16で確認されました。

他のターゲット（maya.exe、maya-ds4.exe、パリティテストバイナリ）は正常にビルドされていますが、このテストファイルのビルドエラーによりスクリプトが終了コード1を返し、ビルド失敗と判定されます。Windowsではsys/mman.hが利用できないため、Windows環境ではテストビルドをスキップするか、Windows用の代替実装（CreateFileMapping等）が必要です。

根拠: Issue #296: Windows: build_maya_windows.bat tests stops on tests/ds4_cpu_bench.cpp (sys/mman.h not found), v1.1.16

利用者の報告

jerem91150 氏は、Windows 11、ROCm SDK wheels 10.2.0a20260930環境で、tools\hip\build_maya_windows.bat tests実行時にsys/mman.h not foundエラーが発生し、ビルドが停止すると報告しています。CMakeListsでif(NOT WIN32)で囲むか、Windows用のCreateFileMappingブランチを用意することで、Windowsのテストビルドを成功させられると提案しています。この報告は Issue #296 で確認できます。

Windows MSVCビルドでの __cpuidex 未定義エラー

MSVC（Visual Studio 2022）環境において、CPUID命令を使用するソースファイルにヘッダーが含まれていないため、ビルドが失敗する事象が報告されています。

この問題は、`src/kernels/cpu/iq_avx512_one.cpp` のコンパイル時に `__cpuidex` 識別子が見つからないというエラー（C3861）として発生します。`` を追加することで解決可能です。

Windows 11 で Maya をローカルビルドする際、MSVC環境ではこの修正が必要です。

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

利用者の報告

suprekt 氏は、Windows 11 Pro、Intel Core i7-13700K、NVIDIA GeForce RTX 4080 16 GB、RAM 192 GB、CUDA Toolkit 13.0、MSVC 14.44.35207 の環境で報告しています。`iq_avx512_one.cpp` に `#ifdef _MSC_VER` による `` のインクルードを追加したところ、ビルドは成功しました。

「The latest Project Maya engine failed to compile on Windows 11 using Visual Studio 2022 Build Tools. ... I was able to resolve the issue by adding the missing <intrin.h> header. After this change, the engine compiled successfully.」

並列実行(--parallel)時のタイミング情報共有バグ

`--parallel N` で複数のリクエストを同時に処理する際、`StrataEngine.last` という共有フィールドにタイミング情報が書き込まれる仕様により、別のリクエストのタイミング情報が混入する不具合があります。

v1.1.17 において、`Service.run` がストリーミング終了後に `self.engine.last` を読み取る際、他のリクエストの `DONE` 行が間に挟まると、`timings`（処理時間やトークン/秒）や `cached_tokens` が正しく表示されなくなります。

並列処理でレスポンスのメトリクスを確認する際、他のリクエストのデータと混同される可能性があります。

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

利用者の報告

pepuscz 氏は、v1.1.17 において、`--parallel N` 使用時に `timings` や `cached_tokens` が別のリクエストの値と混同されることを報告しています。

「With `--parallel N`, every request's `DONE` line is parsed into one shared field, `StrataEngine.last`. ... If another request's `DONE` arrives in between, the response can carry the other request's figures」

ROCm環境での混在GPUアーキテクチャによるカーネル実行失敗

Linux + ROCm 7.2.x 環境において、異なるGPUアーキテクチャ（例：RX 7900 XTX と Strix Halo iGPU）を同一プロセスで使用すると、rocBLASの制限によりカーネル実行に失敗します。

rocBLAS 7.2.x はプロセスごとに1つのTensileソリューションライブラリしか読み込まないため、互換性のないアーキテクチャのGPUで実行しようとするとエラーになります。この問題はROCm側で修正されていますが、`rocm-7.2.4` には含まれていません。

Discrete GPUとAPUを組み合わせる場合、ROCmのバージョンやタグに注意が必要です。

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

利用者の報告

pepuscz 氏は、Linux 7.0.0-38-generic、ROCm 7.2.4、Ryzen AI Max+ 395、Radeon 8060S、RX 7900 XTX の環境で報告しています。`maya-ds4` を両GPUで実行し、GLM層を分割した際、`no kernel image is available for execution on the device` エラーが発生しました。

「On Linux with ROCm 7.2.x, a Maya process that calls rocBLAS on two GPUs of different architectures fails with `no kernel image is available for execution on the device`. We hit it with an RX 7900 XTX (gfx1100) next to the Strix Halo iGPU (Radeon 8060S, gfx1151)」

GLM-5.3-Flash (Maya-S24) の RX 7900 XTX + Strix Halo 実測ベンチマーク

AMD GPU（RX 7900 XTX）とAPU（Strix Halo）を組み合わせるHelperモードでの、GLM-5.3-Flash (Maya-S24) の推論速度が報告されています。

v1.1.17 において、131,072トークンのコンテキスト、`--parallel 4`、約114Kトークンのプロンプトで測定されました。ROCm 7.2.4、HIP config（`--expert-cache auto --prefill auto --kv-streaming on`）が使用されました。

長文コンテキストでの推論性能が実測されています。

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

利用者の報告

pepuscz 氏は、Bosgame M5（Ryzen AI Max+ 395、Radeon 8060S、128 GB RAM、120 W APU）、RX 7900 XTX 24 GB（M.2 to OCuLink、PCIe 4.0 x4）、Linux 7.0.0-38-generic、ROCm 7.2.4 の環境で報告しています。

「Maya v1.1.17 on an RX 7900 XTX + Strix Halo in helper mode, with 131,072 tokens per slot, one request and `--parallel 4`. Two questions at the end.」

RX 7900 XT/XTX (gfx1100) 向け融合プロンプトエキスパートカーネルの有効化

RX 7900 XT/XTX (gfx1100) において、MMQではなく融合WMMAカーネルを使用可能になり、プロンプト処理が高速化されました。

従来はgfx1151のみが使用可能でしたが、gfx1100もランタイムゲートに追加されました。これにより、`MAYA_GLM_PREFILL_FUSED=1` でプロンプト処理速度が向上します。

gfx1100ユーザーは、プロンプト処理の高速化が期待できます。

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

利用者の報告

Cass67 氏は、4x RX 7900 XT、i9-9900K、60 GB RAM、ROCm 10、v1.1.17、262Kコンテキストの環境で報告しています。

「For speed I used one binary and toggled MAYA_GLM_PREFILL_FUSED=0 vs on. ... Engine prompt speed in tok/s, off vs on: 1.3K at 35K depth: 306 vs 347, 2.8K: 447 vs 505, 3.7K: 549 vs 603, 7.9K: 866 vs 919, 16K: 1093 vs 1149. So that's +5-13%」

Linux HIP環境でのDeepSeekプロンプトデフォルト設定の修正

Linux HIP環境において、TP（Tensor Parallelism）が機能しない場合でも、適切なスレッド設定とプロンプトウィンドウ幅が適用されるようデフォルト設定が修正されました。

従来、TPが機能しない場合、プロンプト処理が16トークンウィンドウで実行され、速度が低下していました。修正により、`--threads on --prefill-chunk 8192` がデフォルトで適用されます。

Linux HIPユーザーは、プロンプト処理速度の改善が期待できます。

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

利用者の報告

boxwrench 氏は、Ryzen AI Max+ 395、Radeon 8060S、128 GB RAM、Linux、ROCm 7.2.2、v1.1.16、Maya-S、8192プロンプトトークン、128生成トークンの環境で報告しています。

「Measured on Ryzen AI Max+ 395 / Radeon 8060S (gfx1151), 128 GB unified RAM, Linux, ROCm 7.2.2, v1.1.16, Maya-S, 8192 prompt tokens, 128 generated tokens, greedy, DSpark none: ... TP2 requested → TP1, threads off: 8K TTFT seconds 742.75, Prompt tok/s 11.0, Decode tok/s 12.9」

PR #298: EXL3向けHIPプリフィルカーネル実装とAMD対応

Project Mayaは、AMD GPU（HIP）でもEXL3量子化モデルのプリフィル処理を可能にするカーネルを実装しました。これにより、手動で構成されたDeepSeek EXL3モデルが、AMD環境でもグループ化されたエキスパートパスを実行できるようになります。

PR #298 では、既存の8-activation `block_gemv`デコーダを再利用し、デバイス上でのルーティングされた行の境界処理、ゲート/アップスケールとClamped SwiGLUの適用、別のアダプターを介したFP16ダウン/GEMM入力の処理を行うポータブルなプリフィルカーネルが実装されています。これは最適化されたWMMAポートではなく、FP32 FMAによる初期実装です。CUDA側のテンサーコアパスは従来通り保持されます。

この変更により、AMD GPUユーザーはEXL3量子化モデルのプリフィル処理を実質的に利用可能になります。ROCm 7.14.1 / gfx1201環境での検証では、`maya-ds4`および`exl3_test`のビルドが成功し、`exl3_test`の完全なパス（0失敗、0起動エラー）が確認されました。

根拠: PR #298: hip(exl3): implement portable grouped-expert prefill kernels

MI100 (gfx908) 環境でのテスト結果と既知の問題

AMD Instinct MI100 (gfx908) 環境におけるMayaの動作状況と、4枚構成でのベンチマーク報告です。この話題は前回の続きとして、新しいテスト結果が追加されています。

テスト環境では、47テスト中42テストが成功しましたが、5テストで失敗またはタイムアウトが発生しました。主な原因は、wave sizeが32ではなく64であることによるものです。具体的には、`hip_intrinsics`、`hip_glm_handoff`、`hip_glm_prefill_attention`、`hip_device_selftest`が失敗し、`glm_model_big_test`がタイムアウトしました。

一方で、4枚のMI100 (32GB) をPCIe 4.0 x16で接続した環境でのベンチマーク報告も寄せられています。AMD EPYC 7402、251.6 GB RAM、Debian 13、ROCm 7.2.4の環境で、Maya-S24モデル（コンテキスト262144）が動作し、推論速度が測定されました。

根拠: Issue #176: MI100 CDNA 1 GFX908 TESTING、Issue #229: Speed report: 4x MI100 (gfx908), Maya-S24, 262144 context — v1.1.12

GLM Speculative Decodeのバックアップとウォームアップ修正

GLM Speculative Decode（予測デコード）において、再帰状態（KDA）のバックアップとリストア、およびプロンプトパスのウォームアップ処理が修正されました。

この修正では、デコードステップの前に予測パスのヘッドが再帰状態をバックアップバッファに保存し、拒否されたドラフト後にそれを復元する処理が実装されました。これにより、予測デコードの安定性が向上します。また、設定名のエイリアス処理（`STRATA_*` から `MAYA_*` への変更対応）も含まれています。

この変更により、予測デコード使用時の状態管理が改善され、より安定した推論が可能になります。

根拠: PR #290: glm spec: take the recurrent-state backup at setup

2x RTX 3090環境でのEXL3量子化モデルベンチマーク

2枚のRTX 3090 (24GB) をNVLinkで接続した環境での、EXL3量子化モデル（3.05bpw）の実測性能報告です。この話題は前回の続きとして、2-GPU構成での新しいデータポイントが追加されています。

環境はRyzen Threadripper PRO 3955WX、247 GB DDR4-2400、Linux、Maya v1.1.9、コンテキスト131072です。2枚のGPUにモデルを分割（レイヤー[0, 24)をCUDA0、[24, 45)をCUDA1）して実行した結果、デコード速度は平均29.2 tok/s（文章25.4、事実33.1、コード29.2）でした。RAM_RESIDENTとKV_INT8を有効にしても29.0-29.2 tok/sとほぼ同等の性能を維持しています。

この報告は、2-GPU構成でのEXL3量子化モデルの動作が「問題なく動作する」ことを示す最初のデータポイントとなります。

根拠: Issue #187: Speed report: EXL3-3.05bpw on 2x RTX 3090

混合GPU構成でのMaya-M実測とエージェント動作報告

異なるGPU（V100、RTX 3090、RTX 3060）を混合構成で接続したPCでの、Maya-Mの実測性能とエージェントタスク実行結果の報告です。この話題は前回の続きとして、新しいハードウェア構成の報告が追加されています。

構成は、V100 (32GB, PCIe Gen3 x4)、RTX 3090 (24GB, PCIe Gen4 x16)、RTX 3060 (12GB)、およびもう1枚のGPU（詳細は省略）の4枚構成です。Maya 1.1.11 / Maya-Mがデプロイされ、256Kコンテキストでの動作が確認されました。エージェントタスクの結果も再現可能であることが報告されています。

この報告は、多様なGPUを混合して使用する場合の構成例と、その実動作を示すものです。

根拠: Issue #220: Hardware/agent report: Maya-M on RTX 3090 + RTX 3060 + dual V100, 256K context (v1.1.11)

DGX Spark (GB10) での推論速度レポート

NVIDIA DGX Spark (GB10) のような、CPU/GPUメモリを統一した環境での推論速度実測報告です。

環境は、GB10 Grace Blackwell（1 GPU、121 GB 統一メモリ、LPDDR5X）、20コアArm CPU、4 TB NVMe、DGX OS 7.5 (Ubuntu 24.04)、CUDA 13.0です。モデルはMaya-S v2 IQ2_XXS、コンテキスト128K、MTPドラフトを使用しています。

結果として、デコード速度は16-17 tok/s、プリフィル速度は約730 tok/s（6Kトークン）が測定されました。統一メモリ環境では、エキスパートプールとRAMティアが同じメモリを共有するため、`STRATA_GLM_UMA_LEND_GB`や`STRATA_GLM_RAM_HEADROOM_GB`などの設定が重要になります。

利用者の報告

ericoh88 さんは、DGX Spark (GB10) 環境でMaya-S v2 IQ2_XXS（128Kコンテキスト、v1.1.15）を実行し、デコード速度16-17 tok/s、プリフィル速度約730 tok/s（6Kトークン）を報告しました。サーバーはエージェント作業で忙しい状態での測定のため、プリフィルは通常の8Kではなく6Kトークンでの実行でした。

根拠: Issue #282: Speed report: NVIDIA DGX Spark (GB10, 121 GB unified memory)

CMP 170HX 64GBアンロック版でのベンチマーク

プロジェクトMayaは、GLM-5.3-FlashモデルのエキスパートをGPU、RAM、NVMe SSDに分散配置して推論を行う。CMP 170HXは本来推論専用カードだが、ドライバーパッチによりVRAM容量を拡張して使用できる。

v1.1.8において、PCIe Gen2 x16接続のCMP 170HX 64GB（アンロック済み）1枚構成、32Kコンテキストの設定で、Maya-S24モデルのデコード速度が20.6 tok/s、8192トークンのプロンプトでのプリフィル速度が797 tok/sとなった。同じGPUに4.4GBのTTSモデルを共存させると、デコード速度は13.4 tok/sに低下する。この環境ではRAM容量がボトルネックとなっており、VRAMに56GB、RAMに19.8GBのエキスパートが配置されている。

この結果は、PCIe Gen2という帯域の狭い環境でも、アンロックされたCMP 170HXの大容量VRAMを活用してローカル推論が可能であることを示している。

根拠: Maya-S24, 20.6 tok/s decode / 797 tok/s prefill (8K), Linux (v1.1.8)

利用者の報告

ユーザーKanorin-chanは、i7-9700K、RAM 32GB、Ubuntu 26.04の環境でv1.1.8を測定し、Maya-S24で20.6 tok/sを達成したと報告している。同ユーザーは「ボトルネックはRAM。94.7GBのうち約15GBがNVMe SSDから読み込まれている」と分析している。この報告は作者mw00によってREADMEの速度表に採用された（確認コメント）。

Tesla T10 4枚構成でのマルチGPU推論速度

Mayaは複数のGPUにモデルを分割して推論を行うマルチGPU構成をサポートしている。Tesla T10は15GBのVRAMを持つデータセンター向けGPUである。

v1.1.16において、Tesla T10 15GBを4枚使用し、62.7GBのRAMを備えた環境でMaya-S24（94.7GB、コンテキスト102400）を動作させた結果、デコード速度は平均38.4 tok/s、プリフィル速度は316〜393 tok/sとなった。VRAM使用率は85〜94%で、ホット状態ではディスク読み込みは発生しなかった。

この結果は、低容量のGPUを多数組み合わせることで、大規模モデルのローカル推論が実用的な速度で可能であることを示している。

根拠: Speed report: Maya-S24 on 4×Tesla T10 (15GB) + 63GB RAM — 38.4 tok/s decode (v1.1.16)

利用者の報告

ユーザーzeallagは、Xeon E5-2680 v4、RAM 62.7GB、Linux 7.0.0-38の環境でv1.1.16を測定した。4枚のT10に層を分割し、自動分割でルーティングされたエキスパートの約91%がVRAMに収まっていることを確認している。ライブ推論では25〜43 tok/sの範囲で変動したと報告している（詳細レポート）。

GLMモデルのCPUレーン再タイミング設定の修正

MayaはGPUとCPUの間のデータ転送効率を最適化するため、CPUレーンのタイミングを動的に調整する機能を持つ。従来、CPUレーンがPCIeより遅いと判断された場合、システムは初期のCPU割り当てを維持する傾向があった。

PR #305では、GLMのデコードでCPUレーンがPCIeより遅いと繰り返し計測された場合に、CPU割り当てをゼロとする全PCIe構成を選択できるようにする変更が示されている。これにより、不要なCPU割り当てを解除し、GPU間のルーティングを最適化できる。

この修正により、CPUとGPU間のデータ転送ボトルネックが解消され、特に大規模RAMと複数GPUを備えた環境での推論速度向上が期待できる。

根拠: GLM: allow CPU lane retiming to select an all-PCIe plan

利用者の報告

ユーザーJumpEggKillerは、EPYC 7R13、RAM 256GB、RTX 3090 4枚、Windows環境でv1.1.16をテストした。自動CPUレーン設定では8.3 tok/sだった長文デコードが、`MAYA_GLM_CPU_LANE=0`（CPUレーン無効）により37.4 tok/sに向上したと報告している（テスト結果）。

DeepSeek V4.1-flash のプリフィル速度低下報告

DeepSeek V4.1-flashモデルは、プリフィル（プロンプト読み込み）処理において、複数のユーザーからデコード速度の2〜2.5倍程度しか高速化しないという報告が寄せられている。理想的にはプリフィルはデコードよりも大幅に高速であるべきだが、特定の環境で遅延が発生している。

報告された環境では、2x RTX 4090、4x RTX 3090 + 1x RTX 5060 Ti、2x RTX 3090 + Threadripper 3990X、1x RX 7900 XTXなど、多様な構成で同様の現象が確認されている。一部の原因として、テンソル並列（TP）の崩壊やスレッド設定、CPUのAVX512非対応、GPUのFP4非対応などが指摘されている。

この問題は、DeepSeek V4.1-flashモデルをローカルで使用する際、プリフィル処理に長時間を要するため、プロンプトが長いと体感速度が大幅に低下する可能性がある。

根拠: Very slow Deepseek V4.1-flash prefill = 2x of decode

利用者の報告

ユーザーbyphilippは、EPYC 7713Pと2x RTX 4090（改造）の環境で、プリフィルがデコードの2〜2.5倍しか高速化しないと報告している（報告）。
ユーザーjettoblackは、EPYC 7663（Zen3）と4x RTX 3090 + 1x RTX 5060 Tiの環境で、プリフィルが約100 tok/s、デコードが約40 tok/sであり、Zen3のAVX512不足やGPUのFP4非対応が原因の可能性があると推測している（追加報告）。
ユーザー21387Aは、Threadripper 3990Xと2x RTX 3090の環境で、マルチGPUモード（TP 2）ではプロンプト読み込みが62 tok/s、シングルGPUモード（TP 1）では47.6 tok/sであり、GLM-5.3-Flash（500〜700 tok/s）と比較して著しく遅いと報告している。また、マルチGPU起動時に「out of memory」エラーが発生したと述べている（詳細分析）。
ユーザーjerem91150は、Ryzen 9 7900X3Dと単独のRX 7900 XTX（HIPビルド）の環境で、`--threads`オプションを有効にしない場合、プロンプト読み込みが4 tok/sと極端に遅くなったが、`--threads on`を付与することで116.7 tok/sに改善したと報告している。これは、単一GPU環境でTPが1に降格した際、チャンク読み込みが無効化されるためだと分析している（解決策報告）。

DS4モードにおけるテンソル並列崩壊時の警告表示追加

DS4モードでは、テンソル並列（TP）設定がモデルの構造により単一GPUへの降格（崩壊）を起こすことがある。この場合、プロンプトが16トークンごとの小さなウィンドウで処理され、長文プロンプトで約10倍の低速化を引き起こす。

PR #279 では、テンソル並列が崩壊し、スレッドが無効でプロンプトが16トークンのウィンドウで処理される場合に、起動時に警告する変更が扱われている。これにより、ユーザーは予期せぬ低速化の原因を早期に特定し、設定を調整できるようになる。

この警告は、特にMaya-S GGUFモデルで頻発する問題（n_ff 2304が256値ブロックで分割できないため）に対応したものである。

根拠: ds4: warn at start when prompts run in 16-token windows (tensor parallel collapsed, threads off)

利用者の報告

ユーザーwaxinzは、7x RTX 3090の環境で、テンソル並列が崩壊し16トークンウィンドウで処理された場合、8Kプロンプトで115 tok/s、32Kプロンプトで99 tok/sのプリフィル速度となったと報告している。一方、チャンク処理が有効な場合は大幅に高速化すると比較している（テストデータ）。

vision-memory.jsonの.gitignore追加

Mayaサーバー起動時に生成される`vision-memory.json`（ビジョンエンコーダーのVRAM測定キャッシュ）が、gitの追跡対象外となっていなかったため、毎回未追跡ファイルとして表示される問題があった。

PR #308では、`vision-memory.json`を`.gitignore`に追加することで、サーバー起動時に生成されるこのファイルが未追跡ファイルとして表示される問題を修正している。このファイルは過去にコミットされたことがないため、履歴のクリーンアップは不要である。

この修正により、リポジトリのクリーンな状態が維持され、開発者やユーザーが実際に変更したファイルに集中しやすくなる。

根拠: Ignore vision-memory.json

maya-ds4のマルチGPUハングとアイドル状態の修正・要望

Project Maya v1.1.18 リリースと主な変更点

Project Maya v1.1.17 リリース: GLM-5.3-Flash 高速化と DeepSeek-V4.1-Flash 対応

Windows環境でのTUI起動停止不具合の修正

出典

利用者の報告 (原文抜粋)

  • Thank you for the instrumented build - your analysis was right on. Windows (WDDM) holds GPU work back until the host wai… — mw00

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

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