Project Maya on 山村商店

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

Tue, 20 Oct 2026 20:45:01 +0000

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の高速化とプロンプト形式修正の項目一覧

#297 perf(ds4): opt-in HIP prefill transfer pruning (PR・2026-10-20)
#318 DeepSeek long prompts skip layers 20-39 where the answer does not need them, exact (PR・2026-10-20)
Project Maya v1.1.19 (リリース・2026-10-20)
#307 maya-ds4: keep profiling events on their CUDA device (PR・2026-10-20)
#319 CHANGELOG: v1.1.19の長文プロンプト高速化を冒頭に記載（PR）(リンク: #319 CHANGELOG: v1.1.19's headline speed-up)
#316 v1.1.18のDeepSeek：Windowsの単一20 GB Adaで、VRAM内のエキスパート増加とデコード11.6→9.3トークン/秒・プリフィル221→175トークン/秒への低下（Issue）(リンク: #316 v1.1.18 DeepSeek on a single 20 GB Ada (Windows): decode 11.6 -> 9.3 tok/s and prefill 221 -> 175 tok/s, with more experts in VRAM)

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不具合修正の項目一覧

#287 glm checkpoints: CKPT_EVERY also sets the prompt piece size (PR・2026-10-20)

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ハングとアイドル状態の修正・要望

v1.1.17：WindowsのRTX 3080 2基構成で初回プロンプトが停止し、GPU1の使用率が100%になる問題（Issue #303）(リンク: #303 v1.1.17 maya-ds4 hangs on the first prompt on Windows with two RTX 3080s: GPU1 spins at 100%, nothing is ever read)
#317 Feature request: fill the layer-split's idle gaps on the second GPU (DS4 decode uses ~half of each card) (Issue・2026-10-20)

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

#312 DeepSeek tuned to each PC, the Windows + Strix Halo decode fix, and fixes for v1.1.18 (PR)(リンク: #312 DeepSeek tuned to each PC, the Windows + Strix Halo decode fix, and fixes for v1.1.18)
Project Maya v1.1.18 (リリース・2026-10-20)

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

#295 DeepSeek prompts in chunks, Maya-S from Maya's repo, GLM penalties and fixes (PR・2026-10-20)
Project Maya v1.1.17 (リリース・2026-10-20)

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

#315 Windows: the TUI starts but does nothing — `stop_on_signals()` returns before the setup thread is started (Issue・2026-10-20)

出典

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

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

【Project Maya】Project Maya v1.1.16でDeepSeek-V4.1-Flash-1017対応

Mon, 19 Oct 2026 20:45:02 +0000

今回の要点

Project Maya v1.1.16がリリースされ、独自量子化モデル「Maya-S」を含むDeepSeek-V4.1-Flash-1017のサポートが始まった。
独自エンジン「maya-ds4」により、3.5bit量子化や4/8GPUでのTP（Tensor Parallelism）が利用可能。
EXL3量子化モデル使用時、推論が最大トークン数まで停止しないままループする報告と、その回避策が共有された。
L40S vGPU環境では、Unsloth UD-Q5_K_XLモデル使用時に約21〜25 tok/sの推論速度が実測された。

DeepSeek-V4.1-Flash-1017のサポートと独自量子化

Project Maya v1.1.16では、GLM-5.3-Flashに加え、DeepSeekの748Bパラメータモデル「DeepSeek-V4.1-Flash-1017」がサポートされた。このモデルは、Project Maya独自のエンジン「maya-ds4」上で動作し、スライディングウィンドウや圧縮スパースアテンション、2段階インデクサー、ハイパーコネクション、Engram n-gramテーブル、DSpark drafter、ビジョンタワーなどの機能に対応している。設定は「./maya.sh --setup」または「--model DeepSeek-V4.1-Flash-1017」で行える[1]。

量子化形式としては、デフォルトの独自量子化「Maya-S（--ds4-quant maya-s）」が採用されている。これはルータードエキスパートを2〜3bit、アテンションや共有エキスパート、密な重みを8bitに量子化し、178 GBのメモリで動作する。元のモデルと同じ次のトークンを92.6%の確率で選択できる。また、UnslothのGGUF形式（q8/q4）やLibertAIDAIのEXL3量子化（2.9bit、RTX 30/A100以降対応）も選択可能だ[1]。

利用者の報告

EXL3量子化モデルを使用する環境において、推論が最大トークン数まで停止しないままループする現象が報告されている。eliaskg氏は、Project Maya v1.1.15、GLM-5.3-Flash（turboderp製EXL3 3.05bpw量子化）、コンテキスト262144、温度0の環境で、マルチターンコーディングエージェントセッション実行時にこの事象を確認した。多くのプロンプトで最初のターンが終了せず、約35分間（40 tok/s）推論が続いた後、「finish_reason: length」で終了した[2]。

開発者のmw00氏は、この現象について以下の原因と回避策を提示した。まず、GLMエンジンではrepeat_penaltyやpresence_penalty、frequency_penaltyがドロップされており、効果がないというバグがある。また、温度0でのグリディデコーディングは推論モデルでループを引き起こしやすい。推奨されるサンプリング（ダッシュボードChatのデフォルト）を使用するか、thinking_budget（デフォルト32768）を低く設定（例：16384）することで、ループするターンにかかる時間を制限できる[3]。

L40S vGPU環境での推論速度実測

L40S vGPU（48 GB）とXeon 8580 CPUを搭載する環境において、Unsloth UD-Q5_K_XL（225 GBのエキスパート）モデルを使用した推論速度の実測値が報告された。Project Maya v1.1.15、CUDA 12.9、Ubuntu 22.04.5の環境で、sampledかつthinking有効の実際の使用時（glm stat:）に、デコード速度は安定して20〜25 tok/sであった。当初50+ tok/sを期待していたが、このマシンと量子化では約21 tok/sが上限に近いと推測されている[4]。

出典

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

Sun, 18 Oct 2026 20:45:02 +0000

今回の要点

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 版)

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対応とロード失敗修正

#216 Add support for running Unsloth models containing Q8_0 routed experts via --gguf-dir (PR・2026-10-16)
#219 glm fast: serve Q8_0 expert tensors on the routed path (unsloth's UD quants) (PR・2026-10-16)

Project Maya on 山村商店

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

今回の要点

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

利用者の報告

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

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

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

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

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

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

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

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

利用者の報告

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

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

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

利用者の報告

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

利用者の報告

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

利用者の報告

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

利用者の報告

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

利用者の報告

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

利用者の報告

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

利用者の報告

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

利用者の報告

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

利用者の報告

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

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

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

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

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

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

利用者の報告

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

利用者の報告

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

利用者の報告

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

利用者の報告

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

利用者の報告

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

利用者の報告

vision-memory.jsonの.gitignore追加

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

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

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

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

出典

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

【Project Maya】Project Maya v1.1.16でDeepSeek-V4.1-Flash-1017対応

今回の要点

DeepSeek-V4.1-Flash-1017のサポートと独自量子化

利用者の報告

L40S vGPU環境での推論速度実測

出典

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

今回の要点

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

利用者の報告

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

利用者の報告

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

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

利用者の報告

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

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

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

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

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

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

利用者の報告

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

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