【Project Maya】Project Maya v1.1.26でV100のDeepSeekプロンプト処理が最大1.5倍に、WindowsでGLMを2基のGPUで動かす際の起動不具合を修正

Project Mayaは、mw00が開発するGLM-5.3-FlashをNVIDIA GPUで動かすためのローカル推論エンジンです。よく使う計算部分をGPU、次をRAM、残りをSSDに配置して動かす仕組みを持っています。2026年10月23日にリリースされた最新版では、特にDeepSeek関連の高速化とWindows環境での安定性が改善されました。

今回の要点

• DeepSeekの推論速度向上: V100などの旧世代GPUでも推論速度が最大1.5倍に。CPUスレッドの最適化でデコード速度が大幅に向上。
• WindowsのマルチGPU問題修正: 2枚のGPUを使う場合、VRAM不足で起動失敗していた不具合を修正。
• EXL3モデルのメモリ管理改善: SSDから読み込む問題を解決し、RAMに全てロードするオプションが改善。
• IQ量子化のプリフェッチ最適化: Windows環境での読み込み速度が6〜7%向上。
• 複数の会話の同時処理: 複数の会話を同時に処理する機能が強化。

DeepSeekの推論速度向上

DeepSeekの推論速度が大幅に向上しました。特にV100などの旧世代GPUでは、推論速度が最大1.5倍に改善されました。これは、Sparse AttentionをFP16 Tensor Coreで実行するようになったためです。

また、CPUスレッドの最適化により、デコード速度が42.4 tok/sから68.6 tok/sに向上しました。これは、CPUスレッドの数を2つ余分に確保することで、スレッドの競合を減らした結果です。

これらの改善により、V100 3枚構成で2Kトークンのプロンプトが約1.3倍、8Kと32Kでは約1.5倍高速化しました。デコード速度も同じように向上しています。

根拠: https://github.com/mw00/project-maya/releases/tag/v1.1.26

利用者の報告

RTX 3090 24GB + Ryzen 7 9700Xの環境で、Windows 11上でDeepSeek-V4.1-Flash-1017 Maya-Sを使用した場合、デコード速度が6〜7%向上したという報告があります。特に長い回答ではより大きな改善が見られました。

https://github.com/mw00/project-maya/pull/425

WindowsのマルチGPU問題修正

Windows環境で2枚のGPUを使う場合、VRAM不足で起動失敗していた不具合が修正されました。これは、WDDM（Windows Display Driver Model）のピン割り当て制限が原因でした。

具体的には、CUDA0がRAM層をピン留めした際、CUDA1に割り当てられるVRAMが0GBになってしまう問題でした。この問題は、RAM層を1GB以下のブロックに分割してピン留めすることで解決されました。

この修正により、2枚のGPUを正常に使用できるようになりました。また、EXL3モデルのメモリ管理も改善され、SSDから読み込む問題が解決されました。

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

利用者の報告

• v1.1.26ではGLM RAMティアが最大1GBのピースに分割されてピン留めされるため、Windows環境で2番目のGPUもティアの共有が可能になり、MAYA_GLM_RAM_GBワークアラウンドなしで動作する可能性がある。 mw00

利用者の報告

RTX 5060 Ti 16GB x 2 + 128GB DDR4のWindows 10 Pro環境でMaya-S24を使用した際にv1.1.25で起動に失敗した報告に対し、mw00はv1.1.26でMAYA_GLM_RAM_GBワークアラウンドなしで試し、各GPUのRAMティアの容量を知らせるよう依頼しました。

https://github.com/mw00/project-maya/issues/417

EXL3モデルのメモリ管理改善

EXL3モデルのメモリ管理が改善されました。具体的には、SSDから読み込む問題が解決され、RAMに全てロードするオプションが改善されました。

また、--mmap-experts offオプションが正常に認識されるようになり、setupコマンドでも使用できるようになりました。

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

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

• Thanks! In v1.1.26 `--mmap-experts auto|on|off` is a setup option: `./maya.sh --setup --mmap-experts off` writes it into… — mw00

利用者の報告

v1.1.26についてのコメントでは、EXL3は一部の層を引き続きSSDから読み込む場合があり、全てをRAMに載せるオプションは検討中と説明されています。

https://github.com/mw00/project-maya/issues/422

IQ量子化のプリフェッチ最適化

Windows環境でのIQ量子化エクスパート読み込み速度が6〜7%向上しました。これは、プリフェッチを最適化し、RAMに既にロードされているエクスパートをスキップした結果です。

この改善により、特に長い回答でより大きな速度向上が見られました。

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

複数の会話の同時処理

複数の会話を同時に処理する機能が強化されました。具体的には、MTPドラフティング、アテンション、小さなカーネルの同時実行、新しいプロンプトの読み込み中にリクエストをデコードする機能などが追加されました。

これにより、複数の会話を効率的に処理できるようになりました。

根拠: https://github.com/mw00/project-maya/releases/tag/v1.1.25

DeepSeekツール呼び出し：長い文字列のストリーミング問題

DeepSeekモデルがツール呼び出しでファイル内容などの長い文字列を生成する際、閉じタグまでの間、クライアントへのデータ送信が一時停止する現象が報告されています。これにより、ストリーミングアイドルタイムアウト設定のあるクライアントは、モデルが正常に生成を続けているにもかかわらず、通信が停止していると判断してリクエストをキャンセルし、再試行を繰り返すことになります。

この問題により、DeepSeek-V4.1-Flashが約16〜18 tok/sで動作している環境で、約5,000トークンのファイル生成後にタイムアウトが発生し、1回の試行に加えて5回の再試行が約31分間にわたって行われた末に失敗した事例が確認されています。この現象はサーバーやGPUを介さず、Mayaのパーサーのみを用いたオフライン環境でも再現可能です。

この不具合は、クライアント側のタイムアウト設定とモデルの出力形式の相性によるもので、推論エンジン自体のバグではありませんが、エージェントの処理効率に大きな影響を与えます。修正はIssue #403で議論されています。

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

利用者の報告

talisp 氏は、DeepSeek Harness (pi-ai) が `pi-ai stream idle timeout after 300000ms` で失敗し、1回の試行と5回の再試行で約31分を要したと報告しています。この現象はオフラインでも再現可能であり、DeepSeek (DSML) では値が開いている間に0個の引数イベントしか送信されないのに対し、GLMではツールスキーマを正規化することで対応できると比較しています。

DeepSeek CPUスレッド数：減少による速度向上の逆説

DeepSeek-V4.1-FlashをMayaで実行する際、デフォルト設定（vCPU数分のスレッド）ではCPUのリソースが枯渇し、デコード速度が約15 tok/sに留まることがあります。CPUスレッド数を意図的に減らすことで、エンジンが他の処理にリソースを割けるようになり、速度が大幅に向上する可能性があります。

具体的には、32 vCPU環境でデフォルト設定（32スレッド）から28スレッドに減らしたところ、デコード速度が15.0 tok/sから26.5 tok/sに向上しました。さらにDSpark（ドラフター）を併用し、28スレッドに設定することで、41.2〜41.7 tok/sという約3倍の速度向上を実現しています。リアルなエージェントトラフィック（112-127Kトークンコンテキスト）でも、28スレッド＋DSpark環境で通常約42 tok/sを維持できました。

この最適化は、単一のGPU環境でRAMに多くのエキスパートを置いている場合に特に効果的です。v1.1.21からv1.1.25へのバージョンアップ自体は速度に影響を与えていませんが、スレッド数の調整とDSparkの併用が鍵となります。

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

利用者の報告

talisp 氏は、32 vCPU環境でデフォルト設定が15.0 tok/sだったのに対し、28スレッド＋DSparkで41.2-41.7 tok/sを達成したと報告しています。また、v1.1.25の速度キャリブレーション機能は、このスレッド数最適化のテストをスキップする可能性があるため注意が必要だと指摘しています。

v1.1.25: setup.shのDS4.1/EXL3 2.9bit対応不具合

Maya v1.1.25のセットアップスクリプト（setup.sh）において、DeepSeek 4.1 (DS4.1) および EXL3 2.9bit 量子化モデルの処理でエラーが発生する不具合が報告されています。以前のバージョンでは正常に動作していたセットアップが、v1.1.25で失敗するようになりました。

この問題は、PythonコードがEXL3形式を処理する際にMTP（Mixture of Tuned Parameters）ルート済みエキスパートや他のMTPテンソルに対するビット幅チェックが正しく行われないことに起因しています。具体的には、MTPルート済みエキスパートはmtp_bits (4)、他のMTPテンソルはhead_bits (6)、レイヤー0のwq_aおよびwkvは6としてチェックされる必要があります。また、レイヤー29の混合ビット共有エキスパートに対する既存の特殊処理も保持される必要があります。

この不具合により、DS4.1/EXL3 2.9bitモデルを使用したいユーザーは、セットアップに失敗する可能性があります。修正パッチがIssue #430で提示されています。

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

RTX 3090: DEFER_CPUとAFFINITYのスタック効果

単一GPU環境（RTX 3090）において、複数の最適化設定（MISS_SKIP、DEFER_CPU、ROUTE_AFFINITY）を組み合わせることで、加算以上の速度向上（スタック効果）が実現することが報告されています。特にDEFER_CPUとROUTE_AFFINITYは、それぞれ個別に最適化された設定ですが、併用することで66%の高速化をもたらしました。

テスト環境は、RTX 3090 24GB、Ryzen 7 7700、DDR5 RAM 144GB、GLM-5.3-Flash UD-IQ4_XS（146GB）です。Maya v1.1.23で、コンテキスト131072、KVストリーミング有効、RAM割り当て116GBの設定下でベンチマークを行いました。結果、MISS_SKIP、DEFER_CPU、ROUTE_AFFINITYをすべて有効にした場合、デコード速度が最大66%向上しました。ただし、品質面での注意点が報告されています。

この設定スタックは、単一GPU環境でRAMにモデルの一部を置いている場合に特に有効です。ROUTE_AFFINITYは以前4枚の3090で測定されていましたが、単一GPUでのスタック効果と品質への影響が新たな知見です。

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

利用者の報告

ConnorJ 氏は、RTX 3090単一GPU環境で、MISS_SKIP、DEFER_CPU、ROUTE_AFFINITYを組み合わせることで66%の速度向上を達成したと報告しています。環境はUbuntu 24.04、CUDA 12.6、GLM-5.3-Flash UD-IQ4_XS（146GB）で、RAM割り当ては116GBに固定されています。品質面では、これらの設定が推論の正確性に影響を与える可能性があるため、注意が必要だと指摘しています。

RTX 6000D: DeepSeek-V4.1-Flashの高速推論実測

大規模なVRAM（85GB）を備えたRTX 6000Dを用いることで、DeepSeek-V4.1-Flashの512Kコンテキスト推論が高速に実行可能であることが実測されています。この環境では、デコード速度が89.3 tok/s、プリフィル速度（33Kトークン時）が2836 tok/sを記録しました。

テスト環境は、RTX 6000D 85.6GB、Threadripper PRO 9965WX（24コア/48スレッド）、RAM 251GB、NVMe SSD 1.8TB、Ubuntu 24.04です。Maya v1.1.25で、DeepSeek-V4.1-Flash-1017-EXL3-2.9bpw（512Kコンテキスト）を使用し、DSpark、スレッド有効、プリフィルチャンク16384などの設定でベンチマークを行いました。デコード速度は質問によって67.5〜103.6 tok/sの範囲で、平均89.3 tok/sを達成しました。

この結果は、大規模なVRAMを備えたGPU環境で、非常に長いコンテキストを扱うエージェントアプリケーションが実用的な速度で動作する可能性を示しています。プリフィル速度も33Kトークンで2836 tok/sと非常に高速です。

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

利用者の報告

Ross-Yang-94 氏は、RTX 6000D 85GB環境でDeepSeek-V4.1-Flash-1017-EXL3-2.9bpw（512Kコンテキスト）をテストし、デコード速度の平均89.3 tok/s、プリフィル速度（33Kトークン）2836 tok/sを達成したと報告しています。環境はThreadripper PRO 9965WX、RAM 251GB、Maya v1.1.25です。DSpark、スレッド有効、プリフィルチャンク16384などの設定が使用されました。

RTX 4090: GLM-5.3-Flash Maya-S24の性能報告

単一のRTX 4090（24GB VRAM）で、GLM-5.3-Flashの極端なハイブリッド量子化モデル（Maya-S24）を実行した結果、デコード速度が24-28 tok/sに達し、ベースライン（EXL3 4.05bpw、約14.0 tok/s）と比較して75%の速度向上が実現しました。

テスト環境は、RTX 4090 24GB、RAM 256GB、Maya v1.1.24です。Maya-S24（24-Block極端ハイブリッド量子化）を使用し、コンテキスト30Kで最大28.64 tok/sを記録しました。プリフィル速度は、コールドで1,200〜2,512 tok/s、プリフィックスキャッシュ有効で13,000〜296,000 tok/sでした。TTFT（初-tokenまでの時間）は、コールドプロンプト（1K-8K）で3.4〜4.2秒、プリフィックスキャッシュ有効で78〜100msでした。4並列の同時実行では、キャッシュプロンプトで合計23.37 tok/sのスループットを維持しました。

また、FinEval（34科目）およびエージェント評価でも、量子化による品質低下は最小限に抑えられ、実用的な精度を維持していました。この結果は、単一のRTX 4090で高品質なGLM-5.3-Flashを高速に実行可能であることを示しています。

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

利用者の報告

oscarlius 氏は、RTX 4090単一GPU環境でGLM-5.3-Flash-Maya-S24をテストし、デコード速度23.4〜25.7 tok/s（最大28.64 tok/s）、4並列同時実行で23.37 tok/sのスループットを達成したと報告しています。FinEval（34科目）およびエージェント評価でも、量子化による品質低下は最小限に抑えられ、実用的な精度を維持していました。環境はMaya v1.1.24、RAM 256GBです。

P2Pドライバーインストール後のPCIE_SHARE警告

Project Mayaでは、GPU間のデータ転送効率を調整する環境変数`MAYA_GLM_PCIE_SHARE`が存在します。P2P（Peer-to-Peer）ドライバーのインストール前後で最適な値が変化するため、設定値が古いまま（stale）になっていると、推論速度が大幅に低下する可能性があります。

Issue #419 では、P2Pドライバー導入後の2枚のRTX 3090を搭載したLinux環境で、古い設定値`MAYA_GLM_PCIE_SHARE=0.25`を維持した場合、ベンチマークの平均速度がv1.1.24で25 t/s、v1.1.25で24〜27 t/sだったと報告されています。この値を`0`に再調整（recalibrate）することで、速度は約40 t/sまで回復しています。AMD GPUユーザーや、ドライバーを更新したユーザーは、設定の見直しが必要です。

この問題は、ドライバー変更後のデコード速度低下と、再キャリブレーションの必要性を示しています。

根拠: Issue #419

利用者の報告

catonookaさんは、2枚のRTX 3090（NVLinkなし、PCIe4 x16）とThreadripper PRO 3955WX、Linux 7.0.0-38、ドライバー615.71.09（aikitoria P2Pビルド）の環境で報告しています。`MAYA_GLM_PCIE_SHARE`を`0.25`（古い設定）のままにしていた場合、デコード速度は25 t/s程度に低下しましたが、`0`に再調整することで39〜41 t/sまで回復したと報告しています。

RX 7900 XTX: DeepSeek-V4.1-Flashの推論性能

Project MayaはAMD GPUについても実験的な対応を行っています。DeepSeek-V4.1-Flashモデルを、2枚のRX 7900 XTXとStrix Halo（統合GPU）を組み合わせて使用する場合、Strix Haloを「専門家の補助（expert helper）」として活用できます。

Issue #410では、v1.1.21に37コミットを加えた環境で、130Kトークンのプロンプト入力後、256Kコンテキストにおいて37.1 / 42.8 tok/sの速度が報告されています。これは、Discrete GPU（XTX）だけでなく、統合GPUの共有メモリも活用したハイブリッド構成による成果です。

AMD GPU環境でのDeepSeek推論性能と、Strix Haloとの連携可能性を示しています。

根拠: Issue #410

利用者の報告

pepusczさんは、2枚のRX 7900 XTX（TP 2）とStrix Haloを組み合わせ、DeepSeek-V4.1-Flash Maya-Sモデル（IQ2_XXS/IQ2_Sエキスパート）でベンチマークを実施しました。130Kトークンのプロンプト入力後、256Kコンテキストにおいて37.1 t/s / 42.8 tok/sの速度を達成しています。また、この環境構築のためのAnsibleレシピを公開し、再現性を確保しています。開発者のmw00さんも、この報告をREADMEの速度表に追加する形で承認しています。

RTX PRO 5000: DeepSeek-V4.1-FlashのマルチGPU評価

次世代BlackwellアーキテクチャであるRTX PRO 5000 72GBを2枚使用した場合のDeepSeek-V4.1-Flash性能が報告されています。512Kという非常に長いコンテキストでも、DSpark（分散Spark）を有効にすることで高速な推論が可能です。

512Kコンテキストでのデコード速度は、DSpark有効時で71.03 tok/s、無効時で46.03 tok/sでした。DSparkの有効により約54%の速度向上が確認されています。また、21,457 / 127,057 / 431,057トークンの長文プロンプトすべてで、情報検索（needle-in-a-haystack）テストに合格しています。

2×RTX PRO 5000環境でのDeepSeek推論性能と、長文コンテキストにおける品質の安定性を示しています。

根拠: Issue #424

利用者の報告

realsquall1980-artさんは、2枚のNVIDIA RTX PRO 5000 72GB（Blackwell）、Ryzen 9 9950X3D、Ubuntu 24.04、CUDA 13.0の環境で評価を行いました。Project Maya v1.1.20（sm_120向けビルド）を使用し、Maya-S 339.5GB混合IQ2パックで512Kコンテキスト、DSpark有効の条件下でテストしています。デコード速度は71.03 tok/sを記録し、長文プロンプトでも retrieval needle に合格。また、ローカル推論と公式APIでの回答品質（24タスクスイート）がほぼ同等（24.000/24 vs 23.975/24）であることを確認しています。

GLM: 画像付き会話切り替え時のフルプレフィル問題と修正

GLM-5.3-Flashモデルを使用する場合、画像を含む会話はRAM上のキャッシュスロット（parked conversation slots）から除外される仕様になっていました。これにより、画像を含む会話とテキストのみの会話を切り替える際、RAMに十分なキャッシュ容量があっても、画像を含む会話側で毎回フルプレフィル（最初から処理し直し）が発生し、速度が低下していました。

v1.1.25でこの問題が再確認されており、PR #331で修正パッチが提出されています。画像を含む会話でも、適切なプレフィックス復元によりキャッシュを活用できるようになる予定です。

画像付き会話切り替えでRAMキャッシュを無視しフルプレフィルする不具合の修正を示しています。

根拠: Issue #418

利用者の報告

CoolJohn-labさんは、4枚のRTX 3080、Linux/CUDA、GLM-5.3-Flash Maya-M、1,048,576トークンコンテキスト、`MAYA_GLM_SLOT_RAM_GB=32`、`MAYA_GLM_SLOTS=16`、`MAYA_GLM_RAM_HEADROOM_GB=44`の環境で問題を再現しました。画像を含む会話Aとテキストのみの会話Bを切り替えると、A側で毎回フルプレフィルが発生することを報告しています。これはPR #331の修正対象となる問題の独立した検証として位置づけられています。

DS4: 専門家VRAM不足時のCPU補助モード (MAYA_DS4_HELPER)

DeepSeek-V4.1-Flashなどのモデルでは、VRAMに収まりきらない「専門家層（experts）」をCPUメモリにオフロードする機能が追加されました。`MAYA_DS4_HELPER`環境変数を使用することで、メインのGPUとは別のGPU（またはStrix Haloのような統合GPU）を「補助GPU」として割り当て、VRAMに収まらない専門家層をそこに配置できます。

補助GPUは独自のストリームで処理を行い、CPU側のサービススレッドはCUDA呼び出しを行わず、結果の合算のみを行います。失敗時や10秒応答なしの場合は、処理がCPU側に戻されます。これにより、VRAM不足でも推論を継続可能になります。

VRAM不足時に専門家層をCPUにオフロードするオプションの追加を示しています。

根拠: PR #415

続報：DS4: 会話状態のキャッシュでサブエージェントの再読み込みを高速化

前回の報告に続き、DeepSeek（DS4）における会話状態のキャッシュ機能が強化されました。これにより、会話の切り替えや再起動時に、サブエージェントがプロンプトを最初から読み直す必要がなくなります。

従来、会話切り替えや再起動時にはサブエージェントがプロンプトを0トーク目から再読み込みしていましたが、キャッシュにより状態を保持することで、初回トークンの生成速度が最大7倍高速化されました。特に、70kトークンや185kトークンといった長いプロンプトを持つエージェントランタイムにおいて、切り替え時の待機時間が大幅に短縮されます。

会話切り替え・再起動時の状態保持で初回トークンを最大7倍高速化しています。

根拠: PR #356

2x RTX 3090 (NVLink): Maya-L/M 1Mコンテキスト性能とNVLink Xid 74対策

NVLink接続の2枚構成では、VRAM容量が不足する大規模モデルでも、RAMやSSDを活用して推論を可能にする仕組みが採用されています。

Maya v1.1.23において、2x RTX 3090 (NVLink) 構成でのベンチマーク結果が報告されました。Maya-Lは128Kコンテキストで40.3 tok/s、Maya-Mは54.1 tok/sを記録しています。また、Maya-Lの1Mコンテキスト処理でも、プロンプト長が921Kトークンに達しても正常に処理が完了しています。ただし、推論停止時にNVLinkのXid 74エラーが発生する報告もあります。

この結果は、NVLink接続による高速なGPU間通信が、大規模モデルのローカル推論において有効であることを示しています。ただし、Xid 74エラーの発生には注意が必要です。

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

利用者の報告

ksim63-gifユーザーは、2x RTX 3090 (NVLink) + Threadripper PRO 3975WX + 512 GB DDR4-3200 + Ubuntu 24.04 + driver 595.99.02 + CUDA 12.9 + Maya v1.1.23 (8ceadd7) の環境で、`--gpus 0,1`、MTP drafting、`MAYA_GLM_RAM_GB=200`、`MAYA_GLM_RAM_RESIDENT=1`、`--calibrate` (16 CPU threads) の設定でベンチマークを行いました。その結果、Maya-Lは128Kコンテキストで40.3 tok/s、Maya-Mは54.1 tok/sを記録しました。また、Maya-Lの1Mコンテキスト処理では、プロンプト長が921Kトークンに達しても正常に処理が完了しました。ただし、推論停止時にNVLinkのXid 74エラーが発生しました。

ksim63-gifの報告

DS4: システムプロンプトの思考予算 (think_budget) 強制機能

DeepSeekエンジンでは、システムプロンプトで指定された思考予算 (think_budget) を無視して、出力制限のすべてを推論に費やす問題がありました。

PR #407 では、DeepSeekエンジンでサーバーの `think_budget`／`think_end` GENキーに基づくリクエストごとの思考予算を強制する変更が示されています。これにより、推論の出力制限を超過する問題が修正されました。また、推論終了時に閉じ区切り文字を次のトークンとして出力し、その後に回答を続けるようになりました。

この機能により、DeepSeekエンジンを使用するユーザーは、システムプロンプトで指定された思考予算を正確に守ることができるようになります。

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

サーバー: 68リクエスト後にコンテキストエラーが発生する不具合

Issue #351 では、Maya v1.1.20でGLM-5.3-Flash Maya-S24を4枚のRTX 3090で実行するLinux環境において、最初の68リクエストは成功し、69件目以降は再起動するまでコンテキスト長が0と判定されてすべて失敗する不具合が報告されています。

Issue #351 では、v1.1.20で最初の68リクエストは成功し、69件目以降はすべて失敗すると報告されています。

Issue #351 では、v1.1.20で68リクエストが成功した後、69件目以降のすべてのリクエストが失敗する問題が報告されています。

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

続報: GLM: 複数会話時のプレフィル中にデコードを並行実行する最適化

前回の報告では、長いプロンプトの読み込み中に他の会話がデコードされない問題が報告されていました。

PR #386 では、`--parallel` 使用時に長いプロンプトの読み込み中も他の会話のデコードを進めるための、任意で有効にする2つの方法として `MAYA_GLM_PREFILL_GAPS` と `MAYA_GLM_PREFILL_INTERLEAVE` が示されています。これらのオプションを使用することで、長いプロンプトの読み込み中でも、他の会話がデコードされ続けるようになりました。

この機能により、複数の会話を同時に処理するユーザーは、長いプロンプトの読み込み中でも他の会話が中断されなくなります。

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

続報: RTX 2080 Ti (sm_75) のプロンプト注意レジスタカーネル不具合 (#338)

前回の報告では、RTX 2080 Ti (sm_75) でプロンプト注意が常にレジスタカーネルを実行し、f32変更でテキストが変化し、greedyが再現不能になる問題が報告されていました。

Maya v1.1.23では、AMD GPUおよびNVIDIA RTX 20シリーズでDeepSeekの会話が32,768トークンを超えるとエンジンが停止する問題が修正されました。レジスタカーネルの代わりに、通常のカーネルが使用されるようになりました。これにより、f32変更でテキストが変化する問題や、greedyが再現不能になる問題が解消されました。

この修正により、RTX 2080 Ti (sm_75) を使用するユーザーは、プロンプト注意のレジスタカーネル不具合に遭遇しなくなります。

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

2x Radeon AI PRO R9700 (gfx1201) 構成でのGLM-5.3-Flashベンチマーク

Radeon AI PRO R9700 (gfx1201) は、AMDのGPUで、Mayaが実験的にサポートしているデバイスの一つです。

2x Radeon AI PRO R9700 (gfx1201) 構成でのベンチマーク結果が報告されました。Maya-S24は44.1 tok/s、Maya-M-Deriskedは24.9 tok/sを記録しています。また、MTP drafts acceptedは82-97%、Routed experts in VRAMは92%、Disk reads per tokenは0でした。

この結果は、Radeon AI PRO R9700 (gfx1201) が、Mayaのローカル推論において有効であることを示しています。

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

利用者の報告

gegnepユーザーは、2x Radeon AI PRO R9700 (gfx1201) + Ryzen 5 3600 + 64 GB DDR4 + Linux + ROCm 7.2.1 + Maya v1.1.20 (35bb2b2) の環境で、`./maya.sh --bench`、`./maya.sh --report`、`--context 262144`、`--env MAYA_GLM_KV_INT8=1`、`--env MAYA_GLM_SLOT_KEEP=1` の設定でベンチマークを行いました。その結果、Maya-S24は44.1 tok/s、Maya-M-Deriskedは24.9 tok/sを記録しました。また、MTP drafts acceptedは82-97%、Routed experts in VRAMは92%、Disk reads per tokenは0でした。

gegnepの報告

Instinct MI100 4枚構成でのDeepSeek-V4.1-Flash DS4エンジン性能

AMD Instinct MI100は、ROCm環境下でGLM-5.3-FlashやDeepSeek-V4.1-Flashなどの大規模モデルを、GPUメモリに収まりきらない重みをNVMe SSDやRAMに配置して推論する「Strata」アーキテクチャに対応しています。特にDeepSeek-V4.1-FlashのDS4エンジンでは、エキスパート層を極限まで量子化し、複数枚のGPU間で分散処理することで、消費電力やコストを抑えた高速推論が可能になります。

この構成でDeepSeek-V4.1-FlashのDS4エンジンを実行した初の実測ベンチマーク結果が報告されました。4枚のMI100（各32GB、PCIe 4.0 x16）とAMD EPYC 7402、ROCm 7.2.4、Debian 13という環境で、v1.1.22のMaya-XS量子化モデル（重みの約120.6GBをGPUに配置、残りをSSDから読み出し）を用いた場合、`./maya.sh --bench`によるベンチマークが実行されています。

MI100のような旧世代・またはデータセンター向けGPUにおいて、最新の量子化エンジンがどのように動作するかという実測値は、既存のハードウェアを流用してローカルLLMを運用したいユーザーにとって、性能の下限や構成の妥当性を判断する重要な指標となります。

根拠: Speed report: 4x Instinct MI100 (gfx908 wave64) - DeepSeek-V4.1-Flash-1017 Maya-XS - v1.1.22

利用者の報告

nsaxploit 氏は、自身の環境（4x Instinct MI100 32GB、AMD EPYC 7402、ROCm 7.2.4、Debian 13）で、DeepSeek-V4.1-Flash-1017のMaya-XS量子化モデル（IQ1_S/Q6_K、2-bit DSpark drafter使用）をv1.1.22で動作させ、ベンチマークを実行した結果を報告しています。

RTX 4090 2枚構成でのDeepSeek-V4.1-Flash Maya-XS性能報告 (v1.1.22)

2026年10月22日の更新（続報）。

前提

Maya-XSはDeepSeek-V4.1-Flashモデルを量子化（IQ1_S）し、GPU、RAM、SSDに分散配置して推論する設定。2枚のGPUで層を分割（Tensor Parallel）して動作させる。

何が変わったか

v1.1.22において、RTX 4090 2枚（PCIe 3.0/4.0スロット、P2Pなし）と188GB RAMの環境で、コンテキスト65536、思考モード無効時の実測値が報告された。デコード速度は21.5 tok/s、プリフィル速度は573 tok/s（2048トークン）。

なぜ重要か

RTX 4090 2枚というハイエンド構成で、DeepSeek-V4.1-Flashの推論速度が実測値として記録された。既存のベンチマーク表に含まれていない構成での数値。

根拠のリンク

Speed report: DeepSeek-V4.1-Flash Maya-XS on 2x RTX 4090 + 188 GB RAM (Linux, v1.1.22)

利用者の報告

報告者 mw00 は、Linux (Ubuntu 24.04, kernel 6.8, driver 595.84, CUDA 13.0.2) 環境で `./maya.sh --bench` を実行。2枚のRTX 4090（sm_89）をPCIe 3.0と4.0のスロットに挿し、P2Pを無効化した構成でテストした。CPUはXeon Silver 4309Y 2個、RAM 188GB、NVMe SSD (1TB) を使用。結果として、デコード処理で平均21.5 tok/s、プリフィル処理で573 tok/sを記録した。

Windows環境でRTX 3080 2枚構成時にDS4エンジンがハングする不具合

2026年10月22日の更新（続報）。

前提

DeepSeek 4th Generation (DS4) エンジンは、Windows環境で2枚のNVIDIA GPUを使用する際、プロンプト読み込み時にハングする現象が発生していた。

何が変わったか

v1.1.17において、Windows 10 (driver 591.74, CUDA 13.2) 環境でRTX 3080 2枚 (sm_86) を使用する場合、DS4エンジンが「プロンプト読み込み」状態で永久にハングすることが報告された。GPU 1は100%使用率で回転し続けるが、GPU 0は0%のままデータが読み込まれない。GLMエンジンでは同環境で正常に動作するため、DS4エンジン固有の問題。

なぜ重要か

Windowsユーザーが2枚のRTX 3080を使用する場合、DS4エンジンでの推論が不可能になる重大な不具合。再現率100%。

根拠のリンク

v1.1.17 maya-ds4 hangs on the first prompt on Windows with two RTX 3080s

利用者の報告

報告者 mw00 は、Windows 10 19045、RTX 3080 2枚、CUDA 13.2の環境でテスト。DS4エンジン起動後、サーバーは準備完了を報告するが、リクエストを送信すると「reading the prompt: 2 tokens, Ns so far」のメッセージが600秒以上表示され、処理が進まない。GPU 1は常に100%使用率、GPU 0は0%で、ディスク読み込みも発生しない。GLMエンジンでは同ハードウェアで正常動作したため、DS4エンジン固有の問題と特定。

Maya-XSの2GPU環境での初回プロンプトハング修正 (#384)

2026年10月22日の更新（続報）。

前提

前述のWindows 2GPUハング不具合（#303）は、Maya-S（6-shardセット）では修正されていたが、Maya-XS（5-shardセット）では依然として発生していた。

何が変わったか

v1.1.23において、Maya-XS（IQ1_S）が2枚のGPUで層を分割する際、初回リクエストでハングすることが報告された。GPU 1は100%使用率で回転し、GPU 0は0%のまま、プロンプト読み込みが永久に停止する。同一ビルドのMaya-Sは正常に動作するため、修正パッチがMaya-XSのパスをカバーしていないことが判明。

なぜ重要か

Windows環境でMaya-XSを使用するユーザーは、2枚のGPUを使用する場合、初回推論でハングし、モデルが使用不可能になる。

根拠のリンク

Maya-XS hangs on the first prompt on two GPUs (Maya-S works on the same build; the #303 fingerprints)

利用者の報告

報告者 mw00 は、Windows 10 19045、RTX 3080 2枚、CUDA 13.2の環境でテスト。Maya-XS（5-shardセット、v1.1.23セットアップでビルド）を使用。`--tp 2` を指定すると、初回リクエストでハング。GPU 1は100%使用率、GPU 0は0%、ディスク読み込み0、プロンプト読み込みが900秒以上表示される。同一ビルドのMaya-Sは正常に動作し、修正パッチがMaya-XSのパスをカバーしていないことが確認された。

Project Maya v1.1.24 リリース: Windows 2GPU 不具合修正と DeepSeek 高速化

前提

Project Maya v1.1.24がリリースされた。Windows環境での2GPU使用不具合の修正と、DeepSeek推論の高速化、大規模RAMサーバー向けの新オプションが含まれる。

何が変わったか

• Windowsでの2GPUハング修正: DeepSeekがWindowsの2枚以上のNVIDIA GPUで初回プロンプト時にハングする問題（#384, #303）を修正。1枚のGPUが他GPUのキュー済みワークの送信を待機していた問題を解消。比較用に `DS4_WIN_SUBMIT=0` で旧動作に戻せる。Linuxと1GPU構成は変更なし。
• DeepSeekの高速化: NVIDIA RTX 30以降およびRDNA 4搭載GPUで、プロンプト処理が高速化。
• モニター表示の改善: DeepSeekの「Where the experts live」カードで、VRAM、RAM、SSDごとのエキスパート数と容量を個別に表示。n-gramメモリもSSDからの測定値を表示。
• Attentionの最適化: NVIDIA tensor cores (RTX 30以降, sm_80+) および RDNA 4のmatrix coresで、プロンプトアテンションが最適化。無効化には `DS4_ATTN_MMA=0` / `DS4_ATTN_WMMA=0`。
• テンソル並列の改善: GPUグループメンバーがRAMコピーから自身のエキスパート行のみを読み込むように変更（#377）。
• 大規模RAMサーバー向けオプション: LinuxでロックされたEngramテーブル（`DS4_ENGRAM_RAM=1`）や、SSDへのフォールバックなしでCPUレーンごとにエキスパートをRAMに保持（`DS4_REQUIRE_ALL_RAM=1`）。
• その他のオプション: `MAYA_DS4_Q8_BATCH=1`（GEMV呼び出しの入力を1回の起動で量子化）、`MAYA_DS4_LT_STORE`（AMDのhipBLASLtの選択をパック外に保持）。

なぜ重要か

Windowsユーザーが2枚のGPUを使用する場合、DS4エンジンでの推論が可能になる。また、RTX 30以降やRDNA 4搭載GPUでの推論速度が向上。大規模RAMサーバーのユーザーは、メモリ使用量を最適化できる。

根拠のリンク

Project Maya v1.1.24

DS4: キャッシュ解放と专家ロードの高速化

前提

DeepSeek 4th Generation (DS4) エンジンは、Linux環境でGGUF形式のエキスパートをRAMにコピーする際、ファイルキャッシュの重複によりメモリ使用量が増加する傾向があった。

何が変わったか

• キャッシュ解放: `DS4_COPY_DROP_CACHE=1` を有効にすると、エキスパートの行列とNUMAパートのコピー完了後、ソースページのPOSIX_FADV_DONTNEEDを発行。境界ページは保持され、退去は助言的に行われる。
• 直接I/O: `DS4_COPY_DIRECT=1` を有効にすると、再利用可能なアライメント済みステージングバッファを使用して直接I/Oを行い、正確なバイト数をNUMA宛先にコピー。直接読み込みがサポートされていないか失敗した場合は、バッファ付き読み込みにフォールバックし、バイト数が起動ログに報告される。

両オプションはデフォルトで無効。ルーティング、テンソル演算、Engram読み込み、インストーラーのデフォルトは変更されない。

なぜ重要か

Linux環境でDS4エンジンを使用するユーザーは、RAM使用量を削減し、エキスパートのロード時間を短縮できる。

根拠のリンク

DeepSeek: add opt-in cache release and direct I/O for RAM expert copies

ds4: Maya_DS4_LOAD_THREADS and Maya_DS4_LOAD_INTERLEAVE for the expert load (cold load 81.3 -> 60.9 s here)

DS4 GGUFテンソル並列：ブロック単位でのGPU分割

前提

GGUF形式のモデルをテンソル並列（TP）で複数のGPUに分割する際、Mayaの量子化（256値ブロック、n_ff 2304 = 9ブロック）では、`--tp 2` などの設定が「テンソル並列 2 -> 1」にフォールバックし、各GPUが独自の層を持つ状態になっていた。

何が変わったか

`MAYA_DS4_TP_GGUF_UNEVEN=1` を有効にすると、GGUFのエキスパートがテンソル並列グループのGPU間で、同種の全体のブロック単位で分割される。2枚のGPUの場合、5 + 4 ブロックに分割され、残りの1ブロックは層ごとにメンバー間で循環する。これはEXL3のsplit128と同様の動作。

• 各メンバーは、自身の範囲とレイアウトをロード、ストリーミング、スワップ、チェックする。
• 共有エキスパートは、メンバーの自身の範囲で分割される。
• 配置は、#344のメンバーごとの空き容量提案に基づき、同じスナップショットから各メンバーの正確なエキスパートバイトがフィットされる。

なぜ重要か

GGUFモデルをテンソル並列で使用する際、GPU間の負荷分散が改善され、より効率的な推論が可能になる。

根拠のリンク

ds4: MAYA_DS4_TP_GGUF_UNEVEN - tensor parallel 2 on Maya's quants (whole blocks, as even as they go), with DS4_FLOW_TP on its groups

利用者の報告

報告者 pepuscz は、Mayaの量子化（256値ブロック）において、`MAYA_DS4_TP_GGUF_UNEVEN=1` を有効化することで、2枚のGPU間で5 + 4 ブロックに分割し、残りの1ブロックを層ごとに循環させる動作を確認。各メンバーが自身の範囲とレイアウトをロード、ストリーミング、スワップ、チェックする動作も確認。共有エキスパートはメンバーの自身の範囲で分割され、配置は#344の提案に基づき、同じスナップショットから各メンバーの正確なエキスパートバイトがフィットされることを確認。

DS4プロンプトスキップ：2-GPUレイヤースプリット対応

2枚のGPUでモデルの層を分割する構成において、プロンプトスキップ機能が正しく動作するように修正されました。それまでは、層が異なるGPUに跨がる場合、スキップ機能が無効化されていました。

この変更により、層の境界が20層目以前にある2-GPU構成でも、スキップ処理が有効になります。これにより、プロンプトの処理効率が改善されます。

2枚のGPUでローカルLLMを運用しているユーザーにとって、プロンプト処理のオーバーヘッドが削減され、レスポンス速度の向上が期待できます。

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

DS4単一GPU構成でのチャンク化パス有効化

単一のGPUで動作させる際、プロンプト処理が「チャンク化パス」を利用するように設定が最適化されました。以前は単一GPUでも強制的に `--tp 2` が設定され、16トークンごとのウィンドウで処理されるため低速でした。

RTX 4000 Ada Generation (20GB) でのベンチマーク結果、プロンプト2,687トークンの場合、処理速度は103 tok/sから205 tok/sに向上しました。63,850トークンの長いプロンプトでも同様の最適化が適用されます。

単一GPUで長文のプロンプトを扱うユーザーにとって、生成速度が約2倍になる重要な改善です。

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

DS4キャリブレーション：TP幅とCPUスレッドの尊重

DS4のキャリブレーションプロセスが、実際のTensor Parallel (TP) 幅とCPUスレッド数を正確に認識するように修正されました。以前は、ロード時のばらつきにより同じ構成が異なる設定として認識される問題がありました。

起動時のINFOログに実際のCPUスレッド数が表示され、キャリブレーションは設定されたスレッド上限ではなく実際の値を優先します。これにより、VRAMに収まらないと誤認するのではなく、正確な配置が行われます。

GPUとCPUのリソースを最大限に活用し、キャリブレーションの精度を向上させることで、推論の安定性が向上します。

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

利用者の報告

Whamp 氏は、RTX 3090 4枚の環境でテストを行いました。その結果、TP4とTP2は両方とも `1/1/1/1` にフォールバックし、重複するTP2の開始では生成が行われなかったことを確認しています。また、CPUスレッドキャリブレーションは報告された12スレッドのベースラインから正常に実行されました。この報告は https://github.com/mw00/project-maya/pull/435 で行われています。

DS4エクスパート読み込み後のページドロップ最適化

エキスパートデータの読み込み完了後、ファイルキャッシュからページを削除する最適化が行われました。これにより、メモリキャッシュの効率が向上し、読み込みの高速化が図られます。

読み込みには `MAYA_DS4_LOAD_THREADS` (デフォルト12) が使用され、ファイルはラウンドロビン方式で読み込まれます。また、キャッシュドロップはデフォルトで有効になっています。

モデルの読み込み時間を短縮し、特に大規模なモデルを頻繁に読み替えるユーザーにとって、待機時間の削減に寄与します。

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

利用者の報告

Ross-Yang-94 氏は、この変更によるパフォーマンスの計測結果を報告しています。キャッシュドロップ機能により、読み込み時間の短縮が確認されています。この報告は https://github.com/mw00/project-maya/pull/434 で行われています。

DeepSeek V4.1 on RTX 4080 SUPER 32GB：性能とDS4報告

RTX 4080 SUPER 32GB での DeepSeek V4.1 Maya-XS のベンチマーク結果が報告されました。65,536トークンのコンテキストでビジョン有効時の平均速度は9.6 tok/sでした。

DSparkを有効にすると速度が5.76 tok/sまで低下し、約58.7%の性能低下が見られました。また、ベンチマークツールやレポート生成ツールにおけるDS4関連の表示不具合も報告されました。

この構成での実用的な速度限界と、ツール側の不具合を把握することで、ユーザーは適切な設定を選択できます。

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

利用者の報告

Micro-ATP 氏は、RTX 4080 SUPER 32GB 環境で DeepSeek V4.1 Maya-XS をテストし、DSpark有効時の大幅な速度低下とツール側の表示不具合を報告しました。この報告は https://github.com/mw00/project-maya/issues/416 で行われています。

開発者の mw00 は、v1.1.26 でこれらの不具合を修正したと回答しています。具体的には、`--bench` が DeepSeek 形式を送信するようになり、`--report` が DS4 の配置情報を表示するようになりました。DSparkの速度低下については、`--speed-calibration` で最適な設定を選択するよう提案しています。このやり取りは https://github.com/mw00/project-maya/issues/416#issuecomment-6373121712 で確認できます。

DS4: エージェント間での会話状態保持

サブエージェントを複数実行する際、プロンプトの再読み込みを防ぐために会話状態を保持する機能が追加されました。以前は、エージェントが切り替わるたびに全てのプロンプトが再読み込みされていました。

12のリクエスト連続実行時、70%の時間がプロンプトの再読み込みに費やされていました。この変更により、状態保持により再読み込みが削減されます。

エージェントを複数使用する高度なワークフローにおいて、プロンプト読み込みのオーバーヘッドを大幅に削減し、処理効率を向上させます。

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

コンテキスト超過エラーのOpenAI互換クライアント対応

OpenAI互換クライアントは、コンテキスト長超過時に標準のエラーコードやメッセージパターンで検知して処理を行う仕組みがある。しかし、それまでMayaが返していたHTTP 400エラーのレスポンスボディには、クライアント側の検知ロジックが認識できるコードやキーワードが含まれていなかった。

この対応により、コンテキスト超過時のエラーレスポンスに、クライアントが認識可能な形式が追加された。これにより、クライアント側での正常なコンパクションやリトライ処理が阻害されることがなくなる。

OpenAI互換クライアントを使用しているユーザーにとって、コンテキスト超過時のエラーハンドリングが安定し、システム全体の信頼性が向上する。

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

利用者の報告

ユーザー ilonalumina は、opencode 1.19.0 において、エラーレスポンスボディに `code` フィールドがなく、メッセージにもオーバーフロー検知パターンが含まれていないことを報告している。

DS4: 画像付き会話のスロット管理改善

MayaのDS4スロット機能は、別の会話がモデルを使用している間に現在の会話を一時退避させ、プロンプトで再開する仕組みである。従来、画像を含む会話はスロットへの退避や復帰が拒否されており、一度画像を含むチャットを行うと、切り替えのたびにトークン0から読み直す必要があった。

この改善により、各スロットが画像の開始位置、ハッシュ、範囲を保持するようになり、同じ位置に同じピクセルの画像がある場合のみ、その会話を復帰できるようになった。メタデータ形式は DS4META3 へ移行し、従来のテキスト専用スロット（DS4META2）も引き続き読み込み可能。

画像を含む会話を行うユーザーにとって、会話の切り替えが高速化され、画像付きチャットの利便性が大幅に向上する。

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

利用者の報告

ユーザー Ross-Yang-94 は、RTX 6000D 85 GB 環境で、画像を含む26Kトークンの会話とテキスト会話を交互に切り替えるテストを行い、画像付き会話のスロット管理が正常に動作することを報告している。

8x RTX 3090 + EPYC: GLM-5.3-Flash EXL3 1Mコンテキスト性能報告

8枚のRTX 3090（計192GB VRAM）とAMD EPYCプロセッサ、126GB RAMという構成で、GLM-5.3-FlashのEXL3量子化モデル（4.05 bpw）を1Mコンテキストで動作させるテストが行われた。重みデータは165GBに達し、VRAMに収まらないエキスパートプールはRAMに配置されるハイブリッド構成となった。

この構成でのデコード速度は117.4 tok/s、8Kプレフィル速度は1470 tok/sという実測値が得られた。PCIe 4.0環境で6枚がx16、2枚がx8の帯域幅で動作しており、VRAM不足分はRAMで補完する設定が有効に機能している。

大規模GPU構成で巨大コンテキストを扱うユーザーにとって、この構成が実用的なパフォーマンスを提供する基準となる。

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

利用者の報告

ユーザー MarkMakers は、8x RTX 3090 + EPYC 7402P、126 GB RAM、Ubuntu環境で、GLM-5.3-Flash EXL3 4.05 bpwモデルを1Mコンテキストで動作させ、デコード117.4 tok/s、プレフィル1470 tok/sを達成したと報告している。

DS4: テンソル並列グループにおけるドラフターのVRAM配置最適化

テンソル並列（TP）グループでDSparkドラフターを使用する場合、従来はドラフターの3つのブロックがすべてリードGPUに配置され、そのVRAMを消費していた。メンバーGPUは同じトランクスロットを持つため、リードGPUにドラフターバイトが配置されるたび、他のメンバーGPUにはアイドル状態のVRAMが生じていた。

この改善により、`MAYA_DS4_DRAFT_DEV` オプションを使用することで、各ブロックをドラフターグループのメンバーGPUに分散配置できるようになった。各ブロックの重み、リング、VRAMエキスパートがそれぞれのGPUに配置され、VRAM効率が向上する。

テンソル並列構成でドラフターを使用するユーザーにとって、VRAMの効率的な利用が可能になり、より大きなモデルやコンテキストを扱えるようになる。

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

DS4: 不均等なアテンションヘッド数に対応したテンソル並列

GGUFパックでは、テンソル並列グループの幅がアテンションヘッド数（64）と出力グループ数（8）で割り切れる必要がある。Maya-SやMaya-XSのようなモデルでは、この制約によりテンソル並列グループを形成できず、レイヤースプリットとして動作していた。

この改善により、`DS4_TP_UNEVEN_HEADS=1`（実験的、デフォルトオフ）を設定することで、ヘッド数が割り切れない幅でもテンソル並列を有効にできるようになった。グループはヘッド数を分割し、残りを処理する仕組みとなっている。

GGUFパックを使用するユーザーにとって、より柔軟なテンソル並列構成が可能になり、ハードウェアリソースの活用範囲が広がる。

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

続報：L40S vGPU: 512Kコンテキストでのデコード性能限界とチューニング

前回の報告から、L40S vGPU（48 GB）とXeon 8580、251 GiB RAMの構成で、unslothのUD-Q5_K_XL量子化モデル（225 GBのエキスパート）を512Kコンテキストで動作させた場合の性能限界について調査が進められた。

デコード速度は安定して20-25 tok/sで、当初期待されていた50+ tok/sには届かなかった。この速度が現在のマシン構成と量子化精度での限界に近いと判断され、さらにチューニング可能な要素があるか確認が進められている。

vGPU環境でGLMを運用するユーザーにとって、この構成での実用的なパフォーマンス基準が明確になり、期待値の調整や追加チューニングの方向性が示された。

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

RX 7900 XTX: Windows環境でのGLM量子化モデル動作検証とキャリブレーション

前回のベンチマークに続き、Windows環境でのAMD GPU（RX 7900 XTX）におけるGLM量子化モデルの実測値と、パフォーマンス向上に寄与する設定が報告されています。

この環境では、SSDからの読み込み速度を向上させるための環境変数 `STRATA_GLM_DISK_QD` と `STRATA_GLM_READ_CHUNKS` の調整が有効でした。具体的には、`STRATA_GLM_DISK_QD=16` と `STRATA_GLM_READ_CHUNKS=1` に設定することで、SSDからの読み込み速度が 1.66 GB/s から 4.27 GB/s に向上しました。また、デコード時の `READ_CHUNKS` についても、値を小さくする（1チャンク）ほどトークン生成速度（7.21 tok/s）が向上する傾向が確認されています。

この情報は、Windows環境でAMD GPUを使用しているユーザーにとって、ローカル推論エンジンのチューニング指針となります。

出典: Speed report: RX 7900 XTX (gfx1100), Windows 11, 64 GB RAM, model on NVMe - what helped and what didn't

GLM: 複数会話時のバッチ処理におけるMTPドラフティング

GLMエンジンにおいて、複数のリクエストを並列実行する際に、スペキュラティブデコード（MTPドラフティング）の効率を高めるオプションが追加されました。

従来、`--parallel` オプションで複数のリクエストを実行すると、2つ目のリクエストが走った時点でスペキュラティブデコードの恩恵が薄れる問題がありましたが、新しいオプション `MAYA_GLM_MULTI_MTP` を有効にすることで、バッチ処理内の各ステップでドラフティングを適用できるようになりました。このオプションはデフォルトで無効になっており、最大7つのドラフト数を指定可能です。また、`MAYA_GLM_MULTI_MTP_MAX`（デフォルト4）を併用することで、実行中のリクエスト数が指定数以下の時のみこの機能を使用することもできます。

これにより、複数ユーザーや複数スレッドから同時にリクエストが来た場合でも、推論速度の低下を抑制できます。

出典: #385 GLM several conversations: MTP drafting in the batched steps, opt-in (MAYA_GLM_MULTI_MTP)

GLM: 分割GPU構成でのプロンプトチャンク分割読み込み

複数のGPUにモデルを分割して使用する環境（Split GPU）において、プロンプト処理の効率化が図られました。

従来、1つのチャンクで収まるプロンプト処理では、分割されたGPU間で順番に処理が行われ、片方のGPUがアイドル状態になる時間が長くなる傾向がありました。新しいオプション `MAYA_GLM_PREFILL_MIN_CHUNKS` を使用することで、プロンプト読み込みを複数のチャンクに分割し、並列処理を可能にします。これにより、各GPUが処理する負荷を分散でき、全体の処理時間を短縮できます。この機能はデフォルトで無効になっており、分割数を1〜8で指定可能です。

分割GPU構成で推論速度を改善したいユーザーにとって有益な変更です。

出典: #392 GLM prompt on a split: cut a one-chunk read into chunks so the parts pipeline it, opt-in (MAYA_GLM_PREFILL_MIN_CHUNKS)

DeepSeek-V4.1 のコンテキスト長と並列処理に関する質問

DeepSeekエンジン（maya-ds4）における、コンテキスト長の上限と並列処理（`--parallel`）の有効性について、ユーザーから質問と議論が行われています。

GGUFメタデータ上は最大104万トークンに対応しているように見えますが、コード上の制限により26万トークンまでしかサポートされていない可能性があることが指摘されました。また、`--parallel` オプションがGLMエンジンに限定されており、DeepSeekエンジンでは並列処理（マルチシーケンスデコード）が現状では利用できないことも確認されています。

この情報は、DeepSeekエンジンを使用する際に、コンテキスト長や並列処理の制限を理解する上で重要です。

出典: #409 DeepSeek-V4.1 Context and Maya Concurrency

利用者の報告

SunYong0821 氏は、2枚のA100-SXM4 80GB（`--tp 2`）とMaya 1.1.24を使用する環境で、上記のコンテキスト長と並列処理に関する問題を確認し報告しています。

Intel Arc での Maya-XS DeepSeek-V4.1 GGUF 実行

Maya本体にはIntel用バックエンドが含まれていませんが、llama.cppのSYCLバックエンドと小さなローダーパッチを適用することで、Intel Arc GPUでも動作させることが可能です。

この方法により、Intel Arc Pro B70 32GB + B65 32GB + B60 24GB（合計88GB VRAM）という構成で、Maya-XS IQ1_Sモデル（64Kコンテキスト）を実行するテストが行われました。その結果、プロンプト処理（prefill）で45.6 tok/s、デコード（decode）で10.9 tok/sという速度が記録されています。また、OpenAI互換ゲートウェイ経由での処理でも同様の速度（41.0 / 10.8 tok/s）が確認できました。

Intel GPUユーザーにとって、VRAMの大きな利点を活かして大規模モデルを動かす一つの実現策となります。

出典: #401 Intel Arc: Maya-XS DeepSeek-V4.1 GGUFs run on llama.cpp SYCL with a small loader patch - interested in a docs page?

利用者の報告

Jumbomuffin777 氏は、上記のIntel Arc構成（Ryzen 9 9950X, 64GB DDR5, Linux）で、1,934トークンのプロンプト処理と2,470トークンの処理において、それぞれ指定の速度が達成されたことを報告しています。

SleepinDevil 氏は、自身のIntel B70と64GB RAMの環境ではGLMモデルを動かすには不十分だが、XeStrataプロジェクトを用いて約100GBのモデルを動かしていることを共有し、MayaプロジェクトがIntel GPU対応のドキュメントやPRを歓迎するか意見を寄せています。

会話スロット復元後のターンチェックポイント保持

GLMエンジンにおいて、会話の切り替え後にユーザー入力を編集した際に、会話全体を再読み込みしてしまう問題を修正するパッチが提出されています。

従来、会話AからB、そしてAに戻った際に、Aの会話スロットは正しく復元されるものの、直近の短いユーザー入力を編集しようとすると、会話全体（最大248Kトークン）を再読み込みする必要があり、最初の出力まで約4分かかる場合がありました。この修正により、ターン開始時のチェックポイントが会話スロットの復元後に保持されるようになり、再読み込みの必要がなくなりました。

長い会話履歴を扱うユーザーにとって、操作のレスポンス性が大幅に向上します。

出典: #400 fix(glm): preserve turn checkpoints after restoring conversation slots

利用者の報告

Zcg2021 氏は、この問題の再現テストを行い、248Kトークンの会話において修正前には約4分かかっていた処理時間が改善されたことを報告しています。

DS4 起動時専門家のプロファイル更新 (#399)

Project Maya は、モデルの「専門家」(MoE の各層の処理担当) を VRAM に配置する順序を、過去の選択履歴に基づいて最適化しています。このプロファイルは起動時に読み込まれ、どの専門家から VRAM にロードするかを決定します。今回、このプロファイルを更新する仕組みが追加されました。

これにより、AMD GPU 3 枚構成の環境において、最初の応答生成速度が 11.3 t/s から 18.0 t/s に、繰り返し応答では 14.6 t/s から 23.9 t/s にそれぞれ改善されました。また、最初の応答における専門家 VRAM 命中率的にも 42.3% から 75.5% への向上が確認されています。これは、過去の膨大な選択履歴 (約 9.2 億回分) に加え、直近のキャリブレーション結果 (約 97.5 万回分) の重みを高めることで、より現在のワークロードに合った配置を実現するためです。

AMD GPU を複数使用してローカル推論を行う場合、起動直後の応答速度や VRAM の有効活用において顕著なメリットがあります。

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

利用者の報告

LostVector 氏は、AMD 環境 (3GPU) での検証結果を報告しています。同氏は「起動時の専門家配置の更新により、保持されたコード生成の速度が最初の応答で 11.3 から 18.0 t/s、繰り返し応答で 14.6 から 23.9 t/s に改善された」と報告し、最初の応答における専門家 VRAM 命中率が 42.3% から 75.5% に上昇したと述べています。この改善は、直近の選択を 80%、正規化された履歴を 20% の比率でブレンドしたプロファイルによるものであり、推論中の適応的キャッシングは従来通り継続されると説明しています。

HIPビルドにおけるMI50 (gfx906) の実験的サポート追加

Project Maya は、AMD GPU 向けに HIP (Heterogeneous-compute Interface for Portability) を使用してビルドされています。通常、アップストリームの HIP アーキテクチャ制限により、古い GPU である MI50 (gfx906) はビルド対象から除外されていました。今回、この制限を回避し、MI50 向けにソースビルドを行う実験的なサポートが追加されました。

この変更により、MI50 向けの実行ファイルを作成し、テストケースを実行することが可能になります。ただし、これはソースビルドのみをサポートするものであり、インストーラーの提供やランタイム設定の追加、ドライバーの修正などは含まれません。ユーザー側で、互換性のある gfx906 対応の rocBLAS/Tensile ライブラリを ROCm 環境から用意する必要があります。

MI50 を所有し、ソースビルド環境を整備できる上級ユーザーにとって、ローカル LLM の推論にこの GPU を活用できる道が開かれます。

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

NUMA: 4/8ソケットサーバーでの专家配置要望

NUMA (Non-Uniform Memory Access) 構成のサーバーでは、CPU とメモリが複数のノードに分散しており、ノードをまたぐアクセスには遅延が生じます。Project Maya は現在、RAM にロードされた専門家 (エキスパート) の配置において、2 ノードまでの環境を前提とした実装となっています。

4つまたは8つのソケットを持つ大規模サーバー (例: Xeon E7 v3/v4 搭載機) で、DeepSeek-V4.1-Flash や GLM-5.3-Flash といった大規模モデルを RAM 全体にロードして実行したいという要望が寄せられています。現状の実装では、RAM tier が 1 つのインターリーブされたプールとして扱われており、CPU スレッドが GPU ごとに分割されているものの、NUMA ノードごとに最適化されていません。ユーザーからは、llama.cpp の --numa distribute や ktransformers のような、ノードごとの専門家配置と、ノードローカルの CPU スレッド割り当てを、GLM および DS4 両方のパスで実装してほしいとのリクエストがあります。

大規模な中古サーバーをローカル推論環境として活用しようとする場合、この NUMA 最適化はパフォーマンス向上の鍵となります。

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

Apple Silicon (M5 Ultra) サポート要望

Project Maya は現在、NVIDIA GPU を主軸とした推論エンジンですが、Apple Silicon (M シリーズチップ) 搭載 Mac での実行を希望する声が上がっています。

特に、メモリ容量 256GB を持つ M5 Ultra 搭載 Mac で、大規模モデルをローカル実行したいという要望が Issue として投稿されています。現時点では、Apple Silicon への対応計画に関する公式な回答や実装は報告されていません。

Apple Mac を所有し、大規模 LLM のローカル推論を試みたいユーザーにとって、今後の対応動向が注目されます。

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

Dockerイメージ公開の要望

Project Maya のビルド・デプロイメントを簡素化するため、公式の Docker イメージを公開してほしいという要望が寄せられています。

現時点では公式イメージは提供されていませんが、noonghunna 氏は、非公式ながら各リリース版から Linux 用 Docker イメージをビルドし公開していることを報告しています。同氏が公開しているイメージ (例: ghcr.io/noonghunna/strata-maya-club3090:v1.1.25) は約 5GB で、NVIDIA の CUDA 13.0 イメージをベースに、Maya のエンジンフラグや llama.cpp のコミット、必要な Python パッケージを含めてビルドされています。また、ビルド時に -DSTRATA_PORTABLE=ON オプションを指定することで、AVX-512 非対応の CPU でも実行可能になるよう、ポータブルなビルドを行っています。レシピは Apache-2.0 ライセンスで公開されており、公式イメージ作成の参考になるとしています。

環境構築に手間取るユーザーにとって、Docker イメージの利用はデプロイメントを大幅に簡素化します。

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

利用者の報告

noonghunna 氏は、非公式の Docker イメージとビルドレシピを公開しています。同氏は、イメージは非公式であり問題が発生した場合は自身の責任で対応するとした上で、ビルドには -DSTRATA_PORTABLE=ON を指定し、AVX-512 非対応 CPU でも実行可能になるよう配慮していると説明しています。レシピは で公開されています。

モニター：ランチャー経由の実行プロセスの GPU 表示修正 (#398)

Project Maya のモニター機能は、GPU のメモリ使用状況を可視化します。しかし、nsys launch のようなラッパー経由でエンジンを実行した場合、モニターが GPU メモリの使用状況を正しく表示しない問題がありました。

この問題は、モニターがサーバーが起動したプロセスの PID を NVML から検索する際に、ラッパー経由で実行された場合、実際のエンジンプロセスの PID が NVML に登録されていないため、エンジンが確保したメモリを「他のプログラム」のメモリとして誤認していたことが原因でした。修正により、ラッパー経由で実行された場合でも、ネストされたプロセスを再帰的に検索し、エンジンとビジョンエンコーダーの PID を正しく特定してメモリ使用量を表示するようになりました。

プロファイリングツールなどを用いてデバッグを行う場合、モニターによる GPU メモリの正確な把握が重要になります。

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

利用者の報告

somnergy 氏は、ラッパー経由で実行される場合、モニターが GPU メモリを誤って表示する問題を報告し、修正内容を確認しています。同氏は、修正により server.nvml_pids がネストされたプロセスも検索し、gpu_map.view がエンジンとビジョンエンコーダーの PID を正しく加算して表示するようになったと説明しています。

MiniMax-M3.1-Flash (428B MoE) サポートリクエスト (#405)

MiniMaxAI が 2026 年 10 月 17 日にリリースした MiniMax-M3.1-Flash モデルの Maya 対応リクエストです。このモデルは 4280 億パラメータの MoE 構造を持ち、トークン生成ごとに 230 億パラメータが活性化します。また、100 万トークンという長いコンテキスト長と、コーディングやエージェント作業に適した設計が特徴です。

このモデルは Maya の得意とする領域と一致しています。まず、MoE 構造は VRAM、RAM、SSD へのエキスパート分割（オフロード）を必要とし、Maya が既に実装している階層化メモリ管理の恩恵を受けられます。次に、MiniMax Sparse Attention (MSA) と 64 本のクエリヘッド、4 本の KV ヘッドを持つ GQA 構造により、100 万トークンという超長文コンテキストを効率的に処理できます。さらに、リリース時に DSpark ドラフティング機構が含まれているため、Maya の既存のドラフティング機能を活用できる可能性があります。

このリクエストが重要なのは、Maya がターゲットとするコーディングエージェントや Computer Use などのワークロードにおいて、このモデルが適している可能性があるためです。ユーザーは Claude Code や opencode などで実行するような負荷を、このモデルで試すことができるようになります。

根拠: MiniMax-M3.1-Flash (428B MoE, sparse attention, 1M context, DSpark drafter) - Issue #405

利用者の報告

Gazelle221B 氏は、このモデルが Maya に適している理由として、MoE 構造によるオフロード適合性、スパースアテンションによる長文コンテキスト処理能力、DSpark ドラフティング機構の利用可能性、そしてコーディングやエージェント作業への適性を挙げています。また、重みは MXFP8 (block size 32, QAT) で約 220GB のサイズであることも報告しています。

Gazelle221B 氏の報告 (Issue #405)

コーディングエージェント向けベンチマークツール (#406)

Maya には既存のベンチマークツール `./maya.sh --bench` がありますが、これは一度に一つの短いリクエストを処理する速度を測定するものでした。一方、コーディングエージェントは複数の長い会話を同時に処理し、各ターンでツール結果やメッセージを履歴に追加していくため、`--bench` では捉えられない設定（`--parallel`、エキスパート階層、バッチデコード、デコードステップ間のプロンプト読み込み、システムプロンプトの保持など）の影響が顕著になります。

このため、`tools/agent_bench.py` という新しいスクリプトが追加されました。このツールは、実行中のサーバーに対してスクリプト化されたエージェントワークロードを実行し、`--seed` によって再現性を確保しています。デフォルトで 4 本のクライアント（会話）が同時に動作し、30K、8K、4K トークンのシステムプロンプトを共有します。これにより、実際のエージェント運用に近い環境でのベンチマークが可能になります。

このツールが重要なのは、コーディングエージェントのような複雑なワークロードにおいて、Maya の設定がどのようにパフォーマンスに影響するかを正確に評価できるためです。`--bench` では検出できなかったパラレル処理やバッチデコードの効果、あるいはプロンプト管理のオーバーヘッドなどを測定できます。

根拠: tools/agent_bench.py: a benchmark shaped like coding agents - Pull Request #406

Tesla V100 3枚・4枚構成でのGLM-5.3-Flash Maya-S性能比較

• #341 Maya-S speed report on consumer PC (RTX 5070 Ti 16 GB + RTX 3060 12 GB) + 32 GB DDR5 (Issue・2026-10-22)
• #340 Speed report: 4x Tesla V100 32GB — Maya-S / Maya-M / Maya-L compared on one machine (Issue・2026-10-22)
• #333 4x Tesla V100-SXM2 32GB (NVLink 2.0) - GLM-5.3-Flash Maya-S: 68.4 tok/s decode, 400/549 tok/s prefill (Issue・2026-10-22)
• #327 Speed report: 4x Tesla V100-PCIE-32GB, Maya-S, 69.3 tok/s decode (Issue・2026-10-22)

DeepSeek CPUスレッド最適化：コア空き設定で速度向上

• #359 DeepSeek: leave two cores free beside the CPU lane (decode 42 -> 68.5 tok/s here) (PR・2026-10-23)

RX 7900 XTX + Strix Halo構成でのGLM-5.3-Flash Maya-S24性能報告

• Issue #311：v1.1.17のRX 7900 XTX + Strix HaloヘルパーモードでのGLM-5.3-Flash Maya-S24性能報告（スロット当たり131,072トークン、--parallel 4、約114Kトークンのプロンプト）(リンク: #311 Speed report: GLM-5.3-Flash Maya-S24 on RX 7900 XTX + Strix Halo helper mode, v1.1.17, 131,072 tokens per slot, --parallel 4 with ~114K prompts)

A100 PCIe 80GB 2枚構成でのMaya-M性能報告 (v1.1.19)

• Issue #326：A100 PCIe 80GB 2枚構成でMaya-Mが91.9 tokens/secを記録した性能報告（v1.1.19）(リンク: #326 Speed report: Maya-M @ 91.9 tokens/sec on 2x A100 PCIe 80GB / AMD EPYC 7742 OpenStack instance 25T / 164GB - Maya 1.1.19)

RTX 3090 + RTX 5060 Ti 8枚構成でのEXL3・DFlash2性能報告 (v1.1.15)

• RX 7900 XTX 24 GB・Windows HIPでのDeepSeek Maya-S性能報告：v1.1.20の長いプロンプトのスキップで26Kプロンプトが224秒から94秒へ (Issue #342)(リンク: #342 Speed report: RX 7900 XTX 24 GB (Windows, HIP), DeepSeek Maya-S, v1.1.20 long-prompt skip: 26K prompt 224 s -> 94 s)

3基のV100 32 GB上でのMaya-S性能報告 (v1.1.20)

• #346 Speed report: 3x V100 32GB (2x PG500-216 + V100, DDR3L), Maya-S, 52.9 tok/s decode - same box, single to triple paired (Issue・2026-10-22)

RTX 3090 4枚構成でのGLM-5.3-Flash Maya-S24/M-MおよびGSQ-RCO比較

• #349 Speed report: 4× RTX 3090, GLM-5.3-Flash Maya-S24/Maya-M and GSQ-RCO, 256K context, drafting comparison (Issue・2026-10-22)

出典

• https://github.com/mw00/project-maya/releases/tag/v1.1.25
• https://github.com/mw00/project-maya/releases/tag/v1.1.26
• https://github.com/mw00/project-maya/issues/417
• https://github.com/mw00/project-maya/issues/422
• https://github.com/mw00/project-maya/pull/425