山村商店

【Project Maya】Maya v1.1.15 公開：複数 GPU での EXL3 ドラフト高速化、V100 の長いプロンプト処理高速化、AMD GPU での EXL3 実験的対応

ProjectMayaローカルLLMGLMGPULLM

目次
  1. 今回の要点
  2. v1.1.15 リリースと H100/CMP 170HX 等新ハードウェア性能報告
  3. Maya v1.1.14 リリース: Pascal GPU 実験的サポートと Unsloth 量子化対応
  4. GLM エンジン: DFlash によるマルチトークン検証と複数会話スケジューリング
  5. GLM Prefill の VRAM 管理とストリーミング最適化
  6. Maya v1.1.11 リリースと監視機能の更新
  7. Volta 向けグループ WMMA カーネルの追加
  8. Pascal sm_60 (Tesla P100, GP100) のエンジンビルドとデコード最適化
  9. 2026-10-16 のリリース (Project Maya v1.1.13 〜 v1.1.15・2 版)
  10. GLM エンジン: gfx1201 環境での NaN 発生と無効な Expert ID 不具合修正
  11. Radeon AI PRO R9700 (gfx1201) での動作検証
  12. EXL3 量子化: 半整数ビットレート (K 1.5/2.5/3.5) と exllamav3 互換性テスト
  13. Volta 向け GLM プロンプト高速化と AVX-512 CPU 最適化
  14. EXL3 4.10bpw 量子化対応と GPU/CPU エキスパートルーティング
  15. 1Mコンテキスト実測とWindowsビルド不具合報告
  16. HIPバックエンドにgfx908 (MI100) 実験的サポートとベンチマーク
  17. GLMプロンプト処理の高速化: DSAインデクサーと短プロンプトバッチ化
  18. GLMのexpertスキップ機能とCPUレーンでの再現性確保
  19. Tesla P40およびRTX 3060搭載環境でのベンチマーク報告
  20. GLM エンジン: レイヤ分割時の PCIe 経由专家ステージング最適化
  21. HIP 環境: Web UI Monitor での GPU 計測を amdgpu sysfs に変更
  22. HIP 環境: 共有 CPU プールによる RX 7900 XTX 2 枚構成のデコード高速化
  23. DeepSeek-V4.1-Flash: Maya 上での実験的サポートと独自エンジン
  24. GLM Recurrent State Backup の確保不具合修正
  25. RTX 3090/3060/V100 混合 4GPU 構成でのエージェント実装報告
  26. Pascal (sm_6x) GPU 向けビルドと L1 キャッシュ最適化
  27. Responses APIとバックグラウンドジョブの追加
  28. CUDA環境でのGLMプロンプト共有専門家サブバッチ最適化
  29. マルチGPU構成の改善
  30. READMEと主要ドキュメントの簡体中国語翻訳追加
  31. GLMモデルにおける動画入力サポートの機能リクエスト
  32. プリフィルステージの分離
  33. Unsloth UD量子化モデルのQ8_0 Expert対応とロード失敗修正
  34. 出典

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.15 リリース：RTX 3090 + RTX 5060 Ti 8 枚で EXL3 と DFlash2 によるデコードの高速化を確認
  • Pascal GPU (P100/P40) が実験的サポートに昇格、Unsloth UD 量子化モデルのロード失敗を修正
  • GLM エンジンの VRAM 管理を最適化：プロンプト処理中の不要 VRAM を解放し、OOM 対策を強化
  • 動画入力やアイドル時アンロードなど、サーバー運用に便利な新機能を追加
  • Volta アーキテクチャ向けに WMMA カーネルを追加し、プロンプト処理を高速化

v1.1.15 リリースと H100/CMP 170HX 等新ハードウェア性能報告

v1.1.15 がリリースされました。H100 2 枚でのベンチマークでは、Maya-L モデルで 124 tok/s のデコード速度、1M コンテキストで 2099 tok/s のプリフィル速度を記録しています https://github.com/mw00/project-maya/issues/258。H100 1 枚でも 61.4 tok/s を達成 https://github.com/mw00/project-maya/issues/260。また、NVIDIA CMP 170HX 2 枚 (40GB ずつ) では 54.3 tok/s、プリフィル 465/831 tok/s を記録 https://github.com/mw00/project-maya/issues/263。これは PCIe Gen2 x16 環境での結果です。

利用者の報告

@Molyleaf は H100 2 枚 (80GB) で Maya-M-Derisked (IQ2_S) をテストし、1M コンテキストで 123.7 tok/s、プリフィル 1411/1986 tok/s を報告 https://github.com/mw00/project-maya/issues/259。H100 1 枚では 61.4 tok/s https://github.com/mw00/project-maya/issues/260。H100 2 枚の報告は v1.1.11 のインストーラービルド (sm_90)、1 枚の報告は v1.1.15 のインストーラービルドで、両方とも Xeon Platinum 8488C (192 スレッド)、504 GB RAM 環境です。

@nvsofts は NVIDIA CMP 170HX 2 枚 (40GB ずつ、PCIe Gen2 x16) で Maya-S をテストし、128K コンテキストで 54.3 tok/s、プリフィル 465/831 tok/s を報告 https://github.com/mw00/project-maya/issues/263。環境は Xeon w3-2423、128 GB RAM、Ubuntu 26.04 LTS、CUDA 13.4.3 です。

Maya v1.1.14 リリース: Pascal GPU 実験的サポートと Unsloth 量子化対応

v1.1.14 では、NVIDIA Pascal (compute capability 6.x: Tesla P40/P100、GTX 10 シリーズ) が実験的サポートに昇格しました https://github.com/mw00/project-maya/releases/tag/v1.1.14。Pascal では L1 キャッシング (-Xptxas -dlcm=ca) がデコードに必要で、Tesla P40 2 枚で Maya-S24 を 28 tok/s でデコード可能とのことです。CUDA 12.x が必要です。

また、Unsloth の UD-Q6_K_XL および Q8_0 量子化 GGUF のサポートが追加されました https://github.com/mw00/project-maya/releases/tag/v1.1.14。これらは MoE レイヤーの一部を Q8_0 で保持しており、それまでロードに失敗していました。

利用者の報告

@Xar1c は RTX PRO 5000 72GB + 48GB (AMD EPYC 7532、512 GB RAM) で Unsloth UD-Q4_K_XL、UD-Q6_K_XL、Q8_0 をテストし、1M コンテキストでのベンチマーク結果を報告 https://github.com/mw00/project-maya/issues/218。Q6_K_XL と Q8_0 は、UD-Q4_K_XL を使ってパッチを作成し、PR #216 で対応しました。

GLM エンジン: DFlash によるマルチトークン検証と複数会話スケジューリング

複数の会話スケジューラー (STRATA_GLM_SEQS > 1) が、DFlash を使った本格的な共有マルチトークン推論検証をサポートするようになりました https://github.com/mw00/project-maya/pull/257。これにより、1 枚の GPU 上で複数の会話をバッチ処理し、ドラフトの検証を効率化できます。各会話ごとに DFlash 提案キューを持ち、バッチ処理されたターゲットウィンドウで検証を行います。また、Ragged Windows により、ドラフト準備完了のタイミングが揃わない場合でも、各リクエストの深さに合わせて処理できます。

速度比較のための --spec-follow オプションも追加されました https://github.com/mw00/project-maya/pull/266。これは、特定のテキストをデコードさせて、2 つの設定やビルドの速度を A/B 比較するためのものです。

GLM Prefill の VRAM 管理とストリーミング最適化

PR #223 では、STRATA_GLM_ROOM_MIN を設定すると、プロンプト処理中にデコード専用の VRAM をプリステージリングに貸し出す仕組みが説明されています。プロンプト処理中にデコードが必要ない VRAM を解放し、プリフィルリングリングとして再利用する仕組みが追加されました https://github.com/mw00/project-maya/pull/223。具体的には、DFlash ドラフター (~0.7 GB) と MTP 設定の NextN ブロックの VRAM が、プロンプト処理中に解放されます。

また、プロンプト処理中の OOM (Out of Memory) 問題が修正されました https://github.com/mw00/project-maya/pull/242。16,384 トークンのチャンクで 3.4 MB の空き VRAM しかなく、1.2 MB の修正バッファが収まらないとエンジンが中断される問題が、プールをサイズクラス (128 KB〜2 MB) で管理するよう変更されたことで解消されました。

プロンプトのチャンク管理も柔軟になりました。各パートが独自のチャンクを保持できるようになり、異なる GPU の組み合わせでも最適化できます https://github.com/mw00/project-maya/pull/241。また、プロンプト処理の進捗をリアルタイムで表示するオプションも追加されました https://github.com/mw00/project-maya/pull/237。

利用者の報告

@mw00 は 3 枚の Tesla V100 (32GB) でテストし、レイヤースプリットでは 2 枚から 3 枚に増やしてもデコード速度は +14% 程度、プリフィルはほぼ変化しないことを報告 https://github.com/mw00/project-maya/issues/235。これは、プロンプト処理が PCIe バンド幅に制限されるためです。8K トークンのプロンプトでは、2 枚と 3 枚で 586/587 tok/s とほぼ同じ速度でした。

@gopinath87607 は、VRAM 解放機能により、CUDA2/CUDA3 (8GB ずつ) で 439/303 エキスパートまで処理可能になったことを報告 https://github.com/mw00/project-maya/pull/223。これは、Strata の 160 エキスパートの制限を超えた結果です。

GLM PrefillのVRAM管理とストリーミング最適化 (PR #242, #241, #239, #237, #238) の項目一覧

Maya v1.1.11 リリースと監視機能の更新

PR #250 では、実行中または待機中のリクエストがない状態が指定した秒数続くとモデルをアンロードする機能を追加しています。リクエストが実行されていない状態が N 秒続くと、エンジンが終了し GPU メモリと RAM ティアを解放します。これは、GPU を他のプログラムと共有する PC に便利です。(リンク: https://github.com/mw00/project-maya/pull/250)

動画入力もネイティブにサポートされました https://github.com/mw00/project-maya/pull/248。GLM-5.3-Flash は動画入力に対応しており、動画の分析、質問への回答、要約が可能になりました。SSD オフロード環境でも数分で完了します。

3 枚の V100 向けに、AVX2 ベクトル化や NUMA ワーカーの最適化、多 GPU パイプラインの調整が行われ、12K 持続デコードで 34.93 tok/s、ピークで 37.85 tok/s を達成しました https://github.com/mw00/project-maya/pull/234。

Volta 向けグループ WMMA カーネルの追加

Volta (sm_70) 以降のアーキテクチャ向けに、グループ WMMA カーネルが追加されました https://github.com/mw00/project-maya/pull/262。これにより、プロンプト処理時の MoE レイヤーの GEMM 演算が高速化されます。IQ3_XXS/IQ3_S/IQ2_S のゲートアップと IQ4_NL/Q2_0 のダウンプロダクトに対応しています。デコードは変更されていません。

Pascal sm_60 (Tesla P100, GP100) のエンジンビルドとデコード最適化

Pascal (sm_60) 向けにエンジンがビルド可能になり、GP100 向けのデコードカーネルが追加されました https://github.com/mw00/project-maya/pull/261。__dp4a は sm_61 以降の命令ですが、sm_60 では 4 つの vmad に変換されています。4 枚の GP100 で Maya-M をデコードすると、21.0 tok/s から 28.2 tok/s に高速化し、同じ回答を生成します。

2026-10-16 のリリース (Project Maya v1.1.13 〜 v1.1.15・2 版)

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 は実験的な対応。

2026 年 10 月 16 日に v1.1.13 と v1.1.15 の 2 版がリリースされた。v1.1.13 では、1 回の会話で最後に使われたエキスパートを保持する「最近性」ベースの VRAM 管理や、Windows 環境での GPU メモリ割り当て不具合の修正が行われた。v1.1.15 では、複数 GPU 環境での EXL3 量子化モデルの推論高速化、Tesla V100 での長文プロンプト処理の最適化、Zen 5 などの AVX-512 VBMI 対応 CPU における推論速度向上、そして AMD GPU での EXL3 量子化モデルのサポート（実験的）が含まれている。

これらの変更により、複数 GPU を持つ環境や、特定の CPU アーキテクチャを持つユーザーの推論速度が向上する。また、Windows 環境での VRAM 管理が安定し、AMD GPU ユーザーもより多くの量子化フォーマットを利用可能になる。

Project Maya v1.1.13

Project Maya v1.1.15

GLM エンジン: gfx1201 環境での NaN 発生と無効な Expert ID 不具合修正

GLM エンジンは、MoE モデルの推論において、特定のコンテキスト長や環境条件下で数値計算エラー（NaN）や無効なエキスパート ID の発生を引き起こす場合があった。

この不具合は、約 409K トークンのコンテキスト長で再現し、NaN ガードがトークン 0 から永遠に再試行する状態に陥っていた。修正により、この環境での安定した推論が可能になった。

この修正は、gfx1201 アーキテクチャ（AMD AI PRO R9700 など）を使用し、長文コンテキスト（最大 1M トークン）を扱うユーザーにとって重要である。VRAM 不足時に RAM や NVMe からエキスパートをストリーミングする環境でも、数値エラーによる推論停止が解消される。

#267 GLM router layer 43: deterministic non-finite scores / invalid expert IDs at ~409K context (IQ3_S, 2x gfx1201, 1M ctx, RAM tier + NVMe streaming) - NaN guard retries from token 0 forever

利用者の報告

eugenrepp は、2x AMD AI PRO R9700 (gfx1201)、1M コンテキスト、RAM 80GB + NVMe ストリーミング環境で、v1.1.15 (commit a4e1ff0) において約 409K トークン地点で NaN 発生と無効なエキスパート ID が検出されたことを報告している。環境は Linux (kernel 7.0.0-38-generic)、ROCm 7.2.4、Maya-L IQ3_S モデルを使用。

Radeon AI PRO R9700 (gfx1201) での動作検証

Project Maya は AMD GPU に対して実験的な対応を行っている。Radeon AI PRO R9700 (gfx1201) 環境での動作検証により、推論速度の向上と長文コンテキストでの安定性が確認された。

v1.1.12 では、v1.1.11 比でデコード速度が約 15% 向上した（コールド起動 19.7 tok/s、ウォームアップ 21.4 tok/s）。また、NoPE 対応の 1M コンテキスト環境において、296k トークンまでのナイルテスト（正確な文字列の位置 0 での recall）に合格し、長文コンテキスト後の推論速度も完全に回復することが確認された。

この検証結果は、gfx1201 アーキテクチャを持つ AMD GPU ユーザーが、長文コンテキストを扱っても安定して高速な推論を行えることを示している。

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

利用者の報告

potatopote-debug は、Radeon AI PRO R9700 (gfx1201) / i5-14400F / 128 GB RAM / Ubuntu, ROCm 7.0 環境で、Maya-S-v2-IQ2_XXS モデルを使用して v1.1.12 の検証を行った。デコード速度は v1.1.11 の約 18 tok/s から、v1.1.12 でコールド 19.7 tok/s、ウォーム 21.4 tok/s (+15%) に向上した。また、296k トークンでのナイルテストに合格し、長文コンテキスト後の推論速度も 25-28 tok/s に完全に回復した。`reasoning_effort: "none"` や `chat_template_kwargs: {"enable_thinking": false}` による思考制御も確認された。

EXL3 量子化: 半整数ビットレート (K 1.5/2.5/3.5) と exllamav3 互換性テスト

EXL3 量子化フォーマットは、exllamav3 1.6 で導入された半整数ビットレート（K 1.5 / 2.5 / 3.5）に対応した。これにより、層の量子化予算が整数幅の間に収まる場合でも、より精密な量子化が可能になる。

また、EXL3 デコーダー（CPU リファレンス、デバイスカーネル、CPU ラインの演算、packer）が、exllamav3 の出力とビット単位で一致するようにテストされた。これにより、Maya 内の EXL3 実装が exllamav3 と完全に互換性を持つことが保証された。

この対応により、コミュニティで公開されている半整数ビットレートの EXL3 モデル（例：Qwen3.8-Flash-Next の一部層など）を Maya で正確に読み込み、推論できるようになる。

#265 EXL3: exllamav3 1.6's half-integer bitrates (K 1.5 / 2.5 / 3.5) - every decoder bit for bit exllamav3's

#264 EXL3 tests against exllamav3 itself: its packer's tiles and a model's matrices - every decoder the same bits

Volta 向け GLM プロンプト高速化と AVX-512 CPU 最適化

Volta アーキテクチャ（Tesla V100 など）では、MMQ カーネルが int8 テンソルコアを利用できないため、プロンプト処理時のエキスパート演算がボトルネックになっていた。この問題に対し、プロンプト内のエキスパートを FP16 にデキューブし、cuBLAS の FP16 テンソルコアを使用して演算する最適化が導入された。

また、CPU ラインでの IQ2_XXS 量子化エキスパートの処理において、AVX-512 VBMI 対応 CPU（Zen 4, Zen 5, Ice Lake 以降の Xeons）向けに、コードブック参照を回避した高速な行演算が実装された。これにより、結果は ggml とビット単位で同一でありながら、デコード速度が 6-8% 向上する。

Volta ユーザーは 27K トークンのプロンプト処理時間が 41.3 秒から 33.4 秒に短縮され、8K トークンでは 20% の速度向上が確認された。AVX-512 VBMI 対応 CPU ユーザーは、RAM tier のエキスパート処理が高速化され、全体として 6-8% のデコード速度向上が期待できる。

#254 GLM prompt on Volta: heavily routed experts as FP16 cuBLAS GEMMs - 27K prompt 41.3 -> 33.4 s, 8K +20 %

#227 CPU lane: AVX-512 one-token IQ2_XXS rows (bit-identical to ggml), +6-8% decode on Maya-S / S24

利用者の報告

merbanan は、Tesla V100 32 GB 環境で、GLM-5.3-Flash Maya-S24 モデルを使用して Volta 向け最適化を検証した。27K トークンのプロンプト処理時間が、MMQ みの場合 41.1-41.4 秒から、デフォルト（128 行以上で cuBLAS 使用）で 33.3-33.4 秒に短縮された。8K トークンでは 616-607 tok/s から 737-736 tok/s に向上した。

cryptedy は、AVX-512 VBMI 対応 CPU 向けに IQ2_XXS の高速行演算を実装し、Zen 5 環境でデコード速度が 6-8% 向上したことを報告している。また、mw00 は、Ryzen AI Max+ PRO 495 (Zen 5) で検証し、トークンが ggml と同一であり、CPU ラインのエキスパート処理時間が 0.168 ms から 0.136 ms に短縮されたことを確認した。

jerem91150 は、Ryzen 9 7900X3D (Zen 4, AVX-512 with VBMI) 環境で、v1.1.15 の CPU ライン最適化を検証した。エキスパートあたりの処理時間が 0.140-0.180 ms から 0.123-0.130 ms に短縮され、デコード時のエキスパート処理時間が約 14% 減少した。ただし、エンドツーエンドの推論速度（9.46-9.48 tok/s vs 9.64 tok/s）への影響はノイズ範囲内だった。

EXL3 4.10bpw 量子化対応と GPU/CPU エキスパートルーティング

Project Maya のセットアップに、turboderp による GLM-5.3-Flash の EXL3 自己較正量子化（4.10bpw）が追加された。この量子化は、4.05bpw と同じフォーマット（trellis, suh, svh, mul1 codebook）を使用し、エンジンと packer でそのまま読み込み可能である。4-bit ルートドエキスパート、8-bit アテンション、6-bit 密層などを採用し、VRAM 効率と精度のバランスを改善している。

また、1 枚の GPU で RAM tier にエキスパートを持つ場合、CPU ラインのエキスパート処理を非同期化し、GPU の待機時間を削減するオプション（`STRATA_GLM_DEFER_CPU=1`）と、VRAM 常駐エキスパートの選択スコアを調整するオプション（`STRATA_GLM_ROUTE_AFFINITY`）が導入された。これにより、Tesla V100 環境でデコード速度が 21-26% 向上する可能性がある。

これらの変更により、4.10bpw 量子化モデルの利用が可能になり、RAM 不足時の CPU 活用効率が向上する。ただし、`STRATA_GLM_DEFER_CPU` と `STRATA_GLM_ROUTE_AFFINITY` はデフォルトで無効であり、有効化すると出力がわずかに異なる場合がある。

#256 EXL3-sc_4.10bpw in the setup: turboderp's self-calibrated quant at 4.10 bits (8-bit attention and shared experts, the MTP block in its shards)

#252 GLM decode: CPU-expert deferral and routing affinity opt-ins (+21-26 % decode on one V100), KL dump for testing them

利用者の報告

needmorevram は、EXL3-sc_4.10bpw モデルのセットアップとテスト手順を報告している。turboderp の GLM-5.3-Flash-exl3/sc_4.10bpw (167.8 GB) を使用し、packer とエンジンが正常に読み込むことを確認した。

merbanan は、Tesla V100 32 GB 環境で、CPU ライン非同期化（`STRATA_GLM_DEFER_CPU=1`）とルーティングアフィニティ（`STRATA_GLM_ROUTE_AFFINITY=0.02`）を検証した。2K トークンのプロンプト処理後、デコード速度が 22.2-22.3 tok/s から 26.8-27.0 tok/s に向上し、8K トークンでも 29.0-29.7 tok/s から 35.0-35.5 tok/s に向上した。ただし、出力の KL 散逸が確認されており、回答がわずかに異なる可能性がある。

1Mコンテキスト実測とWindowsビルド不具合報告

Project Maya はコマンドライン引数で最大 1,048,576 トークンのコンテキスト長を指定可能だが、RTX 5090D 環境では長文コンテキスト時のデコード速度にボトルネックが生じる。また、Windows 10 環境ではビルドプロセスがクラッシュする報告がある。

RTX 5090D (24 GB) 単体環境で 1M コンテキストを測定した結果、1,039,819 トークンの取り込みはオーバーフローやクラッシュなしで完了した。ただし、コンテキスト長が 76K トークンを過ぎるとデコード速度が 6.3〜7.7 tok/s に低下し、短文会話時の速度と比較して顕著な遅延が確認された。この現象は MTP ドラフターを無効化した単一 GPU 環境でも再現した。一方で、Windows 10 環境においてビルドスクリプト実行時にエラーが発生し、ビルドが失敗する事例が報告されている。

RTX 5090D などの高スペック GPU を持つユーザーは、1M コンテキストの利用時にデコード速度の低下を前提とする必要がある。また、Windows 10 ユーザーはビルド失敗の可能性に注意し、ログ確認が求められる。

根拠: #246 # Issue draft — Project Maya (Maya-S-v2 IQ2_XXS, single RTX 5090D 24 GB): full 1M-context measurements, the long-context decode bottleneck, and a v1.1.11 → v1.1.15 retest

利用者の報告

RTX 5090D v2 (24 GB) + i7-14700KF + 128 GB DDR5 + Windows 10 環境で、GLM-5.3-Flash Maya-S-v2 IQ2_XXS (96.5 GB) を 1M コンテキストで動作させた biurquezjoselina-design 氏は、76K トークス以降でデコード速度が 6.3〜7.7 tok/s に低下したと報告している。

Windows 10 環境でビルドを試みた rizh42 氏は、CUDA v12.8 を指定してもビルドプロセスがクラッシュし、エラーログを添えて助けを求めている。

報告詳細: Issue #246、Issue #251

HIPバックエンドにgfx908 (MI100) 実験的サポートとベンチマーク

Project Maya の HIP バックエンドにおいて、AMD Instinct MI100 (gfx908, wave64) 向けの実験的サポートが追加された。これにより、AMD GPU を使用したローカル推論の選択肢が広がる。

既存の 32-lane warp 向けカーネルを維持しつつ、gfx908 の 64-lane wavefront に対応する互換レイヤーが導入された。これにより、AMD Instinct MI100 4 枚構成 (計 128 GB VRAM) の環境で、GLM-5.3-Flash Maya-S24 モデルが動作可能となった。ベンチマークでは、262,144 トークンのコンテキスト設定で 58.5 tok/s のデコード速度が記録された。

AMD GPU 環境（特に MI100 などのデータセンター向けカード）を持つユーザーは、実験的なサポート対象として Maya を利用できるようになった。ただし、正式サポートではなく、互換性レイヤーの動作確認が必要。

根拠: #245 HIP: experimental gfx908 (Instinct MI100, wave64) support

利用者の報告

AMD Instinct MI100 4 枚 (32 GB x 4) + AMD EPYC 7402 + Debian 13 + ROCm 7.2.4 環境で、GLM-5.3-Flash Maya-S24 を動作させた nsaxploit 氏は、262,144 トークンコンテキストで 58.5 tok/s のデコード速度を達成したと報告している。

開発者 mw00 氏はこの報告を評価し、gfx908 向けの実験的サポート PR の提出を促している。また、MI100 所有者による検証結果（ctest リストや `hip_expert_kernel_bench` の結果）がマージの条件となることを示唆している。

報告詳細: Issue #229

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

  • Thanks a lot for this, @nsaxploit - 58.5 tok/s on four MI100s, and the build notes are exactly what we needed. Yes, plea… — mw00

GLMプロンプト処理の高速化: DSAインデクサーと短プロンプトバッチ化

GLM モデルのプロンプト処理（プリフィル）において、DSA インデクサーの計算を FP16 テンサーコアで実行するよう最適化された。また、短プロンプトのバッチ化閾値が引き下げられ、エージェントセッションでの応答速度が向上した。

DSA インデクサーのスコア計算を FP16 テンサーコアに移行した結果、27K トークンのプロンプト処理時間が 824 ms から 494 ms に短縮された。また、単一 GPU 環境において、32 トークン以上だった短プロンプトのバッチ化閾値が 8 トークンに引き下げられた。これにより、エージェントセッションでの短い応答ターン（8〜32 トークン）の処理時間が最大 34% 短縮され、1 ターンあたりのプロンプト処理時間が 1,108 ms から 529 ms に改善された。

長文プロンプトやエージェント利用時の応答速度を改善したいユーザーにとって、特に恩恵のある変更。V100 などの環境で短プロンプトの処理が高速化される。

根拠: #233 GLM prompt: the DSA indexer's scores on FP16 tensor cores - dsa_index 824 -> 494 ms on a 27K prompt、#232 GLM prompt: short prompts from 8 tokens take the batched path on one GPU (was 32) - agent turns -34% prompt time

利用者の報告

V100 32 GB 単体環境で、GLM-5.3-Flash Maya-S24 を使用し、13.5K トークンの履歴を持つセッションで短いユーザーターンを追加するテストを行った merbanan 氏は、短プロンプトのバッチ化閾値を 32 から 8 に変更した結果、3 ターンのプロンプト処理時間が 1,108 ms / 658 ms / 536 ms から 529 ms / 406 ms / 578 ms に短縮され、最大 34% の改善を確認したと報告している。

報告詳細: PR #232

GLMのexpertスキップ機能とCPUレーンでの再現性確保

VRAM 不足時に、軽量の expert をスキップして処理する機能が追加された。また、CPU レーン使用時の再起動後の出力再現性に関するドキュメントが更新された。

VRAM に収まらない expert のうち、ルートの重みが一定値未満のものをスキップする `STRATA_GLM_MISS_SKIP_W` 設定が追加された。これにより、PCIe 転送や CPU レーンの処理を省略し、速度と VRAM 使用量を削減できる。ただし、出力内容が変更される可能性がある。また、CPU レーン使用時、GPU と CPU で計算経路の丸め誤差が異なるため、再起動後に出力が異なる場合がある。この現象を回避するには、特定の設定で出力を固定する必要がある。

VRAM が不足気味の環境や、CPU レーン併用時の出力再現性を重視するユーザー向け。出力の安定性よりも速度を優先するか、再現性を優先するかを選択可能。

根拠: #228 GLM decode: leave out light misses by weight (STRATA_GLM_MISS_SKIP_W / _FROM, off by default, changes the answers)、#224 docs: how to get the same tokens after a restart with the CPU lane on

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

  • Merged - thank you, @cryptedy! It conflicted with #225 (merged earlier today, which moved the route kernel's tables into… — mw00

利用者の報告

RTX 3090 + Ryzen 7 9700X 環境で、expert スキップ機能を実験的にテストした cryptedy 氏は、機能有効化により処理が変更されることを確認している。また、RTX 5090 64 GB 環境で CPU レーン使用時の再現性を測定した hiroki-abe-58 氏は、GPU と CPU で計算経路が異なるため、再起動後に出力が異なる場合があることを報告し、再現性を確保するための設定必要性を示している。

報告詳細: PR #228、PR #224

Tesla P40およびRTX 3060搭載環境でのベンチマーク報告

公式サポート外の旧世代 GPU (Tesla P40) や低 VRAM GPU (RTX 3060) での動作報告と、P40 向けのパフォーマンス最適化情報が報告された。

Tesla P40 (Compute Capability 6.1) は公式サポート外だが、コンパイルガードにより動作可能。初期状態ではデコード速度が 5.8 tok/s と遅かったが、`-Xptxas -dlcm=ca` フラグを指定して L1 キャッシュを有効化することで、1.7〜3 倍高速化し、2 枚構成で 28 tok/s (Maya-S24) および 17 tok/s (Maya-L) を達成した。また、RTX 3060 12 GB 環境では、GLM-5.3-Flash Maya-S24 が 4.3 tok/s で動作し、実用的な推論が可能であることが確認された。

旧世代 GPU や低 VRAM GPU を再利用したいユーザーにとって、動作確認と最適化方法の参考になる。特に P40 ユーザーはコンパイルオプションの変更で大幅な速度向上が期待できる。

根拠: #212 Speed report: 1 / 2 / 3x Tesla P40 (Pascal, sm_61) - Maya-S24 28 tok/s and Maya-L 17 tok/s on two P40s, once global loads are cached in L1 (`-Xptxas -dlcm=ca`, 1.7-3x decode)、#230 Benchmark: Dell T620 / Dual E5-2696 v2 / RTX 3060 12GB / Maya-S24 — 4.3 tok/s

利用者の報告

Tesla P40 複数枚構成で、`-Xptxas -dlcm=ca` フラグを使用して L1 キャッシュを有効化した結果、デコード速度が 1.7〜3 倍向上し、2 枚構成で 28 tok/s (Maya-S24) を達成したと報告したのは Jw88888 氏。また、RTX 3060 12 GB 環境で GLM-5.3-Flash Maya-S24 を動作させた Zapece 氏は、平均 4.3 tok/s のデコード速度を記録し、Creative writing や production planning などの実務タスクも完了したと報告している。

報告詳細: Issue #212、Issue #230

GLM エンジン: レイヤ分割時の PCIe 経由专家ステージング最適化

2 枚の GPU でレイヤを分割して使用する場合、NVLink 非接続環境でも PCIe を経由して专家データをステージングする最適化が追加された。

2 GPU 構成でレイヤを分割すると、片方の GPU が処理している間、もう片方の GPU と PCIe リンクが待機状態になる。この最適化では、待機側の GPU が自身の PCIe リンクを使用して、処理側 GPU が必要な专家データをステージングする。これにより、RAM tier の expert が大部分を占める環境でのアイドル時間を削減し、パフォーマンスを向上させる。この機能は `STRATA_GLM_PREFILL_CALC` 設定でオプトイン可能。

NVLink 非接続の 2 GPU 構成（GeForce カードなど）で、レイヤ分割を使用して推論を行うユーザーは、この最適化により PCIe リンクの効率化が期待できる。

根拠: #270 GLM prompt on a split without NVLink: the waiting GPU computes a share of the working half's staged experts over its own PCIe link (STRATA_GLM_PREFILL_CALC, opt-in)

HIP 環境: Web UI Monitor での GPU 計測を amdgpu sysfs に変更

AMD GPU (HIP/ROCm) 環境では、NVIDIA 用の NVML ライブラリが利用できないため、Web UI の Monitor タイルに GPU の負荷や温度が表示されませんでした。この変更により、ROCm ライブラリや pip パッケージの追加なしに、Linux 上の amdgpu ドライバが提供する sysfs ファイルから直接データを取得する仕組みが導入されました。

これにより、AMD GPU を搭載した環境でも、VRAM 使用量、温度、消費電力、負荷率を Web UI 上でリアルタイムに確認できるようになります。Windows 環境では従来どおりの動作となります。

出典: PR #269: serve: GPU telemetry from amdgpu sysfs on the HIP backend (AMD, Linux)

HIP 環境: 共有 CPU プールによる RX 7900 XTX 2 枚構成のデコード高速化

AMD GPU (HIP) 環境において、CPU のスレッドプール構成を 2 枚の GPU ごとに独立させるのではなく、1 つの共有プールに変更するオプションが導入されました。これにより、GPU 間の CPU メモリ転送やスケジューリングのオーバーヘッドが削減され、推論速度の向上が期待できます。

具体的には、環境変数 STRATA_GLM_CPU_SHARED=1 と STRATA_GLM_CPU_LANE=48 を設定することで、48 スレッドの共有プールを使用するようになります。これにより、デコード速度が最大 34% 向上したとの報告があります。

出典: Issue #268: [HIP/gfx1100] Shared CPU pool improves dual-XTX Maya-L decode by 16–34%

利用者の報告

@Jlauti 氏は、Threadripper PRO 5975WX (256GB RAM) と RX 7900 XTX 2 枚 (ROCm 10.2, Maya v1.1.15) の構成で、共有 CPU プール (48 スレッド) に変更した結果、デコード速度が 16〜34% 向上したと報告しています。

  • プロンプトトークン 8,149: 23.09 → 30.84 トークン/秒 (+33.5%)
  • プロンプトトークン 50,057: 27.56 → 31.88 トークン/秒 (+15.7%)

報告: Issue #268

DeepSeek-V4.1-Flash: Maya 上での実験的サポートと独自エンジン

GLM-5.3-Flash に加え、DeepSeek-V4.1-Flash-1017 モデルの実験的サポートが追加されました。このモデルは、GLM とは異なる独自エンジン (build/strata-ds4) によって実行され、テンソル並列処理、チャンク化されたプロンプト、ビジョン機能に対応しています。

セットアップ時に GLM-5.3-Flash と DeepSeek-V4.1-Flash-1017 のどちらを優先するかを選択できるようになります。モデルデータは LibertAIDAI による EXL3 量子化 (2.9 bpw) と DeepSeek 公式の Engram テーブルを使用します。

出典: PR #271: DeepSeek-V4.1-Flash-1017 on Maya: its own engine (strata-ds4) with tensor parallel, chunked prompts and vision

GLM Recurrent State Backup の確保不具合修正

Speculative Decode (MTP) 設定において、Recurrent State (KDA) のバックアップバッファが適切なタイミングで確保されないバグが修正されました。従来、200MB の reserve 設定などで glm spec: the recurrent-state backup did not allocate エラーが発生し、HTTP 400 が返されていましたが、セットアップ時にバックアップを事前に確保するよう変更されました。

これにより、少ないメモリ reserve 設定でも Speculative Decode が正常に動作するようになります。

出典: PR #243: glm spec: take the NextN head's recurrent-state backup at setup, before the expert pool

利用者の報告

@gopinath87607 氏は、この修正により、200MB の reserve 設定で発生していた the recurrent-state backup did not allocate エラーが解消され、正常に推論が実行できるようになったと報告しています。

報告: PR #243

RTX 3090/3060/V100 混合 4GPU 構成でのエージェント実装報告

異なる NVIDIA GPU (RTX 3090, RTX 3060, V100 x2) を組み合わせた 4 枚構成の PC で、Maya-M を使用したエージェントワークロードの実装例が報告されました。256K コンテキストでの運用実績が共有されています。

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

利用者の報告

@techrian 氏は、Ryzen 7 9700X、64GB クラスの RAM、Ubuntu 24.04.5 LTS の環境で、V100（32GiB）2枚、RTX 3090（24GiB）、RTX 3060（12GiB）の混合4GPU構成による Project Maya v1.1.11 / Maya-M の導入と、256K コンテキストでのハードウェア・エージェントワークロードの報告を共有しています。(リンク: @techrian)

報告: Issue #220

Pascal (sm_6x) GPU 向けビルドと L1 キャッシュ最適化

Tesla P40 などの Pascal 世代 GPU (sm_6x) 向けに、ビルドガードを追加し、グローバルロードを L1 キャッシュにキャッシュするオプション (-dlcm=ca) を有効化しました。これにより、Pascal GPU でのデコード速度が 1.7〜3 倍向上し、出力精度は従来通り維持されています。

デフォルトの MIN_CC 設定は変更されていないため、手動で CMAKE_CUDA_ARCHITECTURES=native 等を指定してビルドする必要があります。

出典: PR #214: Pascal (sm_6x): build with three guards, cache global loads in L1 (-dlcm=ca)

Responses APIとバックグラウンドジョブの追加

既存の生成サービス上に POST /v1/responses エンドポイントを実装し、同期・ストリーミング両方のレスポンス、関数ツール、スキーマ検証付き出力、保存済み会話、バックグラウンド実行に対応しました。

リクエストでは文字列入力、メッセージ履歴、システム/開発者指示、テキスト/画像パート、推論アイテム、関数呼び出し結果を正規化し、関数結果は call_id でマッチして順序を保持します。レスポンスでは、安定した識別子と増加するシーケンス番号を持つ、レスポンス、出力アイテム、コンテンツパート、テキスト、関数引数のライフサイクルイベントを出力します。

認証付きレスポンスリソース、構成可能な容量制限、ライフサイクルメトリクス、ドキュメント、回帰テストカバレッジが含まれています。

出典: PR #217 feat(serve): add Responses API with stored conversations and background jobs

CUDA環境でのGLMプロンプト共有専門家サブバッチ最適化

環境変数 STRATA_GLM_PREFILL_SUB が未設定の場合、プロンプトパスの共有専門家がサブバッチサイズ 256 (kSub) で実行され、各サブバッチで 3 つの行列を FP16 にデ量子化していました (27K プロンプトで層あたり 105 回)。

CUDA ではサブバッチサイズが 2048 (kShSub) に拡大されました。環境変数 STRATA_GLM_PREFILL_SH_SUB で上書き可能、STRATA_GLM_PREFILL_SUB はすべてのサブバッチを設定し、HIP は kSub を維持します。

V100-PCIe-32GB での測定では、27K プロンプトで 2 ラウンド実行した結果、共有専門家の実行時間が 2.96/2.98 秒 (メイン) から 1.55/1.55 秒 (この PR) に短縮されました。GPU 時間は 79.4/80.1 秒 (メイン) から 78.6/78.9 秒 (この PR) になりました。

出典: PR #215 GLM prompt: the shared expert in sub-batches of 2048 on CUDA - a 27K prompt -1.2%

マルチGPU構成の改善

マルチGPU構成に関する改善が行われました。

出典: PR #221 Multigpu

READMEと主要ドキュメントの簡体中国語翻訳追加

README と docs/ 内の 5 つのドキュメントファイル (GLM5-FLASH, QUANT-PLAN, SETTINGS, SETUP, WINDOWS) に簡体中国語翻訳が追加されました。各ファイルは .zh-cn.md 拡張子の兄弟ファイルとして追加されます。

英語版の原本にはタイトル下に言語切替行 (English | 简体中文) が追加され、中国語版ドキュメントは英語版へのリンクを含みます。中国語版ドキュメント内のクロスドキュメントリンクは、存在する場合は中国語版を指します。モデル名、量子化フォーマット、ハードウェア、バージョン、環境変数、コード、リンクはそのまま保持されます。

出典: PR #244 Add Simplified Chinese translations for README and five docs

GLMモデルにおける動画入力サポートの機能リクエスト

GLM はマルチモーダルモデルであり、画像だけでなく動画も処理するように設計されています。現在、llama.cpp は video_url を介して動画をサポートしていますが、このリポジトリでは機能しません。GLM チャットテンプレートから判断すると、原則としてサポートされるはずですが、動画からマルチモーダルトークンとして何も認識しません。Minimax 動画の処理に役立ちます。

出典: Issue #231 Feature: whole video input support

プリフィルステージの分離

プリフィル処理のステージ分離に関する改善が行われました。

出典: PR #222 Pr/prefill stages

Unsloth UD量子化モデルのQ8_0 Expert対応とロード失敗修正

出典

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

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