Project Maya v1.0.20：RTX 20シリーズの高速化、24GB GPU向け量子化、AMD GPU実験的サポート、新ダッシュボード

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

今回の要点

• RTX 20シリーズ (Turing) の高速化とクラッシュ修正： 長いプロンプトでエンジンが落ちる不具合を修正し、Tensor Core を利用可能にした。Titan RTX や Quadro RTX などのユーザーにも恩恵がある。
• 24GB GPU向け量子化モデル「Maya-S24」の追加： 24GB未満のGPUでも、より多くのエキスパートをVRAMに収め、デコード速度を向上させる量子化モデルが提供された。
• AMD GPU (HIP) の実験的サポート開始： Linux環境において、RX 7900 XT/XTX や Radeon AI PRO R9700 などのAMD GPUでの動作が可能になった（コントリビューターによる実装）。
• 新ダッシュボードと「Maya-L」の公開： チャット管理機能が大幅に強化された新UIが導入され、同時に最高精度の量子化モデル「Maya-L」が公開された。
• ツール呼び出し（Tool Calls）の動作： GLM-5.3-Flashの関数呼び出し機能が正常に動作するようになり、コーディングエージェント等との連携が可能になった。

RTX 20シリーズ (Turing) のプロンプト処理改善とクラッシュ修正

Project Maya は、プロンプト（入力テキスト）の処理（Prefill）において、GPUのアーキテクチャに応じた最適化を進めている。2026年10月7日に公開された v1.0.4 では、Turingアーキテクチャ（RTX 20シリーズ等）向けにTensor Coreを利用したプロンプト処理が導入されたが、VRAMの共有メモリ制約により、長いプロンプトを入力するとエンジンがクラッシュする問題が残っていた。

この問題は、v1.0.7 および v1.0.10 で解決された。v1.0.7 では、長いプロンプト（約1000トークン以上）で発生していたクラッシュを修正し、v1.0.10 では、Turing GPU が以前より低速だったFP32カーネルから、Tensor Core を利用する高速カーネルへの切り替えを可能にした。

具体的には、プロンプトの注意機構（Attention）が要求する共有メモリ（67,584バイト）が、Turing GPUの上限（64KB）を超えていたため、最適化が無視され、結果としてエンジンが異常終了していた。修正により、コンテキスト情報をレジスタに保持するよう変更され、共有メモリの使用量を削減した。これにより、Turingアーキテクチャでも高速なプロンプト処理が可能になった。

この修正は、RTX 2060 などのコンシューマー向けGPUだけでなく、Titan RTX や Quadro RTX などのプロフェッショナル向けGPUにも適用される。v1.0.10 のベンチマークによれば、2枚の Titan RTX を使用した場合、18,476トークンのプロンプト処理時間が 62秒 から 58秒 に短縮された。

利用者の報告

このクラッシュ現象と修正については、GitHub Issue #8 で詳細な報告と検証が行われている。

Project Maya v1.0.10: RTX 20シリーズ (Turing) のプロンプト処理改善 の項目一覧

• Project Maya v1.0.10 (リリース・2026-10-08)
• #10 Prompt attention on the tensor cores for Turing: the context in the accumulator registers (58368 bytes) (PR・2026-10-08)

• 環境： 2x Titan RTX (sm_75, 24 GB), 48 GB DDR4, ドライバー 610.57.04, CUDA 12.9/13.0, Ubuntu, Maya-S
• 報告者： @dummerjindabin は、v1.0.4 の段階で、1000トークンを超えるプロンプトを入力するとエンジンが即座に終了し、サーバーが再起動してコンテキストがリセットされる現象を報告した。ログには「shared memory」の不足を示すエラーが含まれていた。
• 開発者の確認： 開発者 @mw00 は、この報告を正確な診断として認め、v1.0.7 および v1.0.10 での修正に反映させた。

AMD GPU (HIP) の実験的サポート開始

Project Maya は、これまで NVIDIA GPU 中心だったが、2026年10月8日に公開された v1.0.11 において、Linux環境での AMD GPU サポートが実験的に開始された。

このサポートは、コントリビューターの @boxwrench による実装で、ROCm 7 を使用してエンジンが構築される。対応しているのは、Linux環境、1枚のGPU、テキスト入力のみである。サポート対象デバイスは、RX 7900 XT / XTX (gfx1100) と、Radeon AI PRO R9700 / RX 9070 (gfx1201) である。

v1.0.14 では、2枚の AMD GPU を使用した設定も実験的にサポートされた。2枚のGPUでレイヤーを分割し、2枚目のGPUでMTP（Speculative Decoding）ブロックを実行することで、速度の向上が図られている。例えば、R9700 と RX 7900 XT の組み合わせでは、単独の RX 7900 XT と比較して、デコード速度が約 15 トークン/秒 から 33 トークン/秒 に向上したという報告がある。

AMD GPU での動作は実験的な段階であり、Windows サポートは含まれていない。また、NVIDIA GPU での動作には影響がない。

利用者の報告

AMD GPU での動作報告は、コントリビューター @boxwrench によるものが中心である。

• 環境： Radeon AI PRO R9700 (gfx1201) および RX 7900 XT (gfx1100)
• 結果： R9700 単体でのデコード速度は約 20 トークン/秒、プレフィル（プロンプト読み込み）は最大 490〜560 トークン/秒。RX 7900 XT 単体でのプレフィルは最大約 410 トークン/秒だった。
• 2枚構成： R9700 + RX 7900 XT の組み合わせで、デコード速度は約 33 トークン/秒、プレフィル（4Kトークン）は約 490 トークン/秒だった。

詳細なセットアップ手順とベンチマーク結果は、docs/AMD_MAYA.md に記載されている。

24GB GPU向け量子化モデル「Maya-S24」の追加

2026年10月8日に公開された v1.0.15 において、VRAMが24GB以下のGPU向けに最適化された量子化モデル「Maya-S24」が追加された。

標準的な「Maya-S」モデルは、注意機構（Attention）と共有エキスパートを6-bit (Q6_K) で量子化しているが、Maya-S24 ではこれを 4-bit (Q4_K) に変更した。これにより、約 1.5 GB 分、より多くのモデルパラメータをVRAMに収めることが可能になり、SSDからの読み込み頻度を減らすことができる。

ベンチマークによれば、VRAM 24GB に制限された Tesla V100 において、デコード速度は 11.8 トークン/秒 から 13.5 トークン/秒 （約 14% 向上）に改善された。32GBのフルVRAMを使用する場合でも、17.2 トークン/秒 から 19.1 トークン/秒 （約 11% 向上）となった。精度については、FP8 原版のゼロショット精度の 97.7% を維持している（標準版 Maya-S は 97.9%）。

セットアップは、`./setup.sh --setup --model Maya-S24` （Windows: `START-MAYA.bat --setup --model Maya-S24`）で行う。VRAMが24GB以下のGPUを単一、または複数使用しているユーザーには、デフォルトで推奨される設定となっている。

新ダッシュボードと「Maya-L」の公開

2026年10月9日に公開された v1.0.17 および v1.0.18 において、Project Maya のユーザーインターフェースであるダッシュボードが大幅に更新された。同時に、最高精度の量子化モデル「Maya-L」が公開された。

新ダッシュボードの特徴

• チャット管理： 複数のチャットをサイドバーで一覧表示可能になり、検索、名前変更、削除が可能になった。ブラウザ上にチャット履歴（画像や添付ファイル含む）が保持される。
• コンテキストサイズ設定： 設定から 4K から 1M トークンまでコンテキストサイズを調整可能。変更時には、現在のPC環境でのメモリ使用量が推計され、警告が表示される。
• メッセージの編集と再生成： 送信したメッセージの編集や、最後の回答の再生成が可能。
• 自動更新： ダッシュボードの「About > Update」ボタンから、モデルのダウンロードを含む更新が可能になった。

Maya-L の公開

v1.0.18 で公開された「Maya-L」は、Project Maya の量子化モデルの中で最高精度を追求したモデルである。サイズは 156.3 GB。

• 量子化構成： ゲート/アップエキスパートに IQ3_S、ダウン投影に IQ4_XS、最も敏感な MoE レイヤーに Q5_K、注意機構と共有エキスパートに Q6_K を使用。
• 精度： FP8 原版のゼロショット精度の 99.2% を維持。HellaSwag や PIQA では原版と同じスコアを記録。
• KLダイバージェンス： Maya-M と比較して 35% 低く（0.188 vs 0.291）、原版の次のトークンを 90% の確率で再現。
• 要件： 156 GB のモデルサイズのため、VRAM と RAM を合わせて十分なメモリ容量を持つ環境が推奨される。

ツール呼び出し（Tool Calls）の動作

2026年10月8日に公開された v1.0.13 において、GLM-5.3-Flash のツール呼び出し（関数呼び出し）機能が正常に動作するようになった。

それまで、GLM-5.x が独自の形式（`NAME......`）でツール呼び出しを出力していたが、サーバー側が別のモデルファミリーの形式のみを読み取っていたため、すべてのツール呼び出しが「malformed tool call」（不正なツール呼び出し）エラーで終了していた。この修正により、GLM 独自の形式と従来の形式の両方が読み取られるようになり、MCP や OpenAI/Anthropic 互換クライアント（Claude Code など）との連携が可能になった。

また、コードブロック内など、ツール呼び出しが引用として出力される場合は、実際に実行されないよう安全策が講じられている。さらに、エンジンが 90 秒間応答しない場合、自動的に再起動する機能も追加された。

利用者の報告

ツール呼び出しの問題と修正については、GitHub Issue #5 で報告・検証が行われている。

• 報告者： @xldistance は、ツール呼び出しが常にエラーで終了する問題を報告した。
• 検証： 修正後、ツール呼び出し、その結果の次のターン、両方の API でエンドツーエンドのチェックが行われ、正常に動作することが確認された。

その他の主な変更点

会話スロット（Conversation Slots）

v1.0.9 で、会話の切り替え時にプロンプトを再読み込みしない「会話スロット」機能が導入された。会話の状態が SSD 上のファイルに保存され、必要な時に読み込まれる。これにより、3,500トークンの会話に戻った場合、プレフィル時間が 10.2秒 から 2.2秒 に短縮された。各会話あたりのファイルサイズは、トークン数に応じて約 21KB ずつ増加する。

ベンチマーク機能の改善

v1.0.6 で導入された `--bench` コマンドは、v1.0.8 で改善された。プロンプト読み込み（Prefill）の測定前にウォームアップ用のプロンプトが実行されるようになり、より公平な速度比較が可能になった。また、`--report` コマンドにより、システム情報とエンジンログをまとめたレポートファイルが生成可能になり、問題報告や速度比較に活用できる。

長いプロンプトでの数値の正確な処理

v1.0.15 で、長いプロンプトに含まれる数値が正しく処理されるよう修正された。それまで、サーバー側で数値が1桁ごとに分割されてしまう不具合があり、長いプロンプトでは数値が変換されて出力されていた（例：「504」が「5504」になる）。修正により、32K および 128K のプロンプトで数値が正確に保持されることが確認された。

Project Maya v1.0.12: 16 GPU対応とGSQ-RCO量子化モデルの追加

Project Maya v1.0.12では、最大16枚のGPUでの並列推論と、新しい量子化モデルのサポートが導入されました。

最大16枚のGPUに対応し、各GPUの空きVRAMに合わせてレイヤーを分割して実行できます。これにより、大規模なモデルを複数GPUで効率的に処理可能になりました。また、単一GPU環境ではプロンプトのチャンクサイズを最大32,768トークンに拡大し、CPUとGPUの並行処理を最適化することで、プロンプト読み込み（prefill）速度が大幅に向上しました。具体的には、Tesla V100 1枚で8Kトークンプロンプト時の速度が373トークン/秒から578トークン/秒へ、2枚では485トークン/秒から541トークン/秒へ改善しています。さらに、コミュニティ製量子化モデル「GSQ-RCO 3.5-bit」がセットアップ時にダウンロード可能となり、VRAM使用量を削減しながら推論を実行できます。

16 GPU対応により、複数GPUを持つ環境でより大規模なモデルや高速な推論が可能になります。また、単一GPUでのprefill速度向上は、長いプロンプトを扱う際の待ち時間を大幅に短縮します。GSQ-RCO 3.5-bitの追加は、VRAMが限られる環境でもモデルを利用できる選択肢を広げます。

根拠: Project Maya v1.0.12, #12 GLM-5.3-Flash: GSQ-RCO 3.5-bit download, up to 16 GPUs, faster decode/prefill on one RTX 3090

利用者の報告

@needmorevram 氏は、9枚のGPU（8x RTX 5060 Ti 16 GB + 1x RTX 3090）環境で、8Kトークンプロンプト時のprefill速度が1,150〜1,210トークン/秒、decode速度が約28トークン/秒であることを報告しています。

GLMパスの自動レイヤースプリットとCPUピンニング

GLMパスにおいて、レイヤースプリットとプロンプトチャンクのサイズを自動で最適化する機能が追加されました。

--layer-split auto を使用することで、各GPUの空き容量、レイヤーのルートカバー率、メモリ帯域幅、ホストRAMの読み取り速度などを基に、各GPUへのレイヤー配置を推論し、最も高速な配置を自動選択します。また、各GPUのCPUスレッドを対応するCPUコアに固定（ピンニング）することで、スレッド切り替えのオーバーヘッドを削減し、RAMティアでのストールを修正しました。

ユーザーは手動でレイヤースプリットを設定する必要がなくなり、異なるGPU構成でも最適なパフォーマンスを引き出しやすくなります。CPUピンニングにより、マルチGPU環境での処理効率が高まります。

根拠: #44 GLM split and prompt chunks: --layer-split auto, --prefill auto | N, per-GPU CPU lane pinning, RAM-tier huge-page fix

利用者の報告

@needmorevram 氏は、この自動レイヤースプリット機能の実装と、CPUピンニングによる改善を確認しています。

Webアプリ画像認識不具合：埋め込み欠落

Webアプリ経由で画像を送信すると、画像認識が失敗する不具合が報告されました。

Webアプリは常に strata_resume を送信しますが、この際、画像の埋め込み情報が設定されるスレッドと、エンジン呼び出しが行われるスレッドが異なるため、埋め込みパスが None になり、エンジンが画像を認識できません。その結果、画像が空白/黒い画像として読み込まれたり、モデルが架空のタスクを生成したりします。API経由で直接リクエストを送った場合は正常に動作します。

Webアプリで画像認識を利用しているユーザーは、この不具合により画像入力が正しく機能しない可能性があります。修正により、Webアプリ経由でも画像認識が正常に動作するようになります。

根拠: #42 Web app pictures reached the engine without their embeddings (strata_resume job thread)

利用者の報告

@tanutanu56 氏は、v1.0.16およびv1.0.17で、512x384の赤背景画像を送信した際に画像認識が失敗することを確認し、原因となるスレッドローカル変数の問題を報告しています。

GLM 128Kコンテキスト対応：KVキャッシュ最適化

GLMの高速パスにおいて、128Kコンテキスト対応のためのKVキャッシュ最適化が導入されました。

インデクサーキー/ゲートループにより、FP32のキャッシュをリングバッファ（8192 + 64位置）に削減し、VRAM使用量を節約します。また、オプションでINT8潜在キャッシュ（STRATA_GLM_KV_INT8=1）を有効にすることで、トークンあたりのVRAM使用量を約544バイトに削減し、より多くのエキスパートをVRAMに配置可能になります。

128KコンテキストをVRAMを節約して利用できるようになり、長い会話履歴や大量のドキュメントを扱う際にも、モデルのパフォーマンスを維持できます。INT8キャッシュの追加は、VRAMが限られる環境で長文コンテキストを利用する際に特に有効です。

根拠: #41 GLM KV cache for 128K context: indexer key/gate ring, INT8 latent cache

利用者の報告

@merbanan 氏は、INT8潜在キャッシュの有効化と、リングバッファによるVRAM節約の効果を確認しています。

RTX 5090でのGLM推論ベンチマーク報告

RTX 5090単体でのGLM推論速度の実測値が報告されました。

RTX 5090、AMD 7950x、96GB RAMの環境で、Maya-Mモデル使用時、prefill速度が2000トークン/秒、decode速度が30トークン/秒超を記録しました。また、3080をセカンダリGPUとして接続し、レイヤースプリット併用時はパフォーマンスが大幅に低下することが報告されています。

RTX 5090単体で非常に高速な推論が可能であり、単一GPUでも大規模モデルを現実的な速度で実行できることが示されました。ただし、複数GPU併用時の最適化には課題が残ります。

根拠: #43 5090 bench report for Maya-M, plus some questions

利用者の報告

@siganos 氏は、RTX 5090単体での高速推論と、3080併用時のパフォーマンス低下を報告しています。

Windows RTX 4000 Adaでのプロンプト読み込みハング

Windows環境（WSL2以外）で、RTX 4000 Ada使用時に初回プロンプト読み込みが無限待機する不具合が報告されました。

エンジン起動後、初回の実プロンプト処理時に、GPU利用率が1-4%に低下し、プロンプト読み込みが20分以上待機する状態になります。最後のログは「glm_batch: CUDA0 prompt attention on the tensor cores (mma.sync, 32 heads a block)」で、プロンプトアテンションカーネルの完了失敗が原因と推測されます。再起動で一時的に解消し、約10回に3回の頻度で再現します。

Windows環境でRTX 4000 Adaを使用しているユーザーは、初回プロンプト処理時にハングする可能性があります。この不具合により、推論の開始が不安定になることがあります。

根拠: #40 Intermittent hang on the first prompt after a start (Windows, RTX 4000 Ada): 'reading the prompt' stalls forever, GPU idle, last line is the mma.sync prompt attention

利用者の報告

@pietroMastro92 氏は、Windows環境でRTX 4000 Ada使用時に、初回プロンプト処理がハングし、GPU利用率が低下することを報告しています。

Windows 11 + RTX 5090でのページファイル設定とGSQ-RCO

Windows環境でのページファイル（仮想メモリ）の容量は、RAM階層に割り当てられるメモリ容量を制限する要因となる。v1.0.15では、ページファイルの不足による制限を回避し、PCIeリンクのキャリブレーションを改善する修正が適用された。

ページファイルの容量が不足すると、物理RAMが空いているにもかかわらずRAM階層のサイズが制限され、SSDへの読み込みが増加して速度低下を招く。修正により、v1.0.15ではVRAM + 8GB以上のページファイルが要求され、不足時には警告が表示される。また、アイドル時のPCIeリンク速度低下による誤ったキャリブレーションを修正し、GSQ-RCO 3.5-bit量子化モデルでのデコード速度が改善された。

RTX 5090を搭載したWindowsユーザーは、ページファイルの適切な設定とv1.0.15以降の使用により、より安定した高速推論が可能になる。

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

利用者の報告

anbow1は、RTX 5090 32GB、Ryzen 7 9800X3D、128GB RAM、Windows 11、CUDA 13.3、Project Maya v1.0.13の環境で報告した。ページファイル（17GB、その後8GB）によりコミット制限が約135GBになり、VRAM 31GBを使用してもRAM階層が約90GBに制限され、物理RAM 27GBが空いたままSSD使用率が76%、転送速度が約770MB/sになったと報告した。https://github.com/mw00/project-maya/issues/20

開発者 mw00 は、この報告をv1.0.15で修正したと回答した。ページファイルの制限問題に加え、アイドル時のPCIeリンク速度低下によるキャリブレーション誤差（GeForceカードでアイドル時にGen1に低下）と、VRAMからRAMへ移動したエキスパートの再読み込み問題が修正され、GSQ-RCO 3.5-bitでの速度が改善された。https://github.com/mw00/project-maya/issues/20#issuecomment-6069348555

違法メモリアクセスによるクラッシュ修正

v1.0.15/16で、長時間のプロンプトやRAM階層を多用する際に発生していた「違法メモリアクセス」によるGPUクラッシュが修正された。これはAMD GPUで特に顕著だったが、CUDA環境でも同様の競合状態が存在した。

修正前は、プロンプト->最初のトークン手渡しの直後や、会話の一時停止後などにクラッシュし、エンジンが再起動するまで応答しなくなる現象が発生していた。修正により、メモリテーブルの更新競合と無効なルーティングインデックスの問題が解消された。

RAMを多く使用する環境や長時間のプロンプトを扱うユーザーは、この修正により安定性が大幅に向上する。

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

利用者の報告

開発者 boxwrench は、この修正PRを提出し、RX 7900 XTとR9700でのクラッシュ症状を詳細に報告した。RX 7900 XTでは2回目のリクエストでクラッシュし、R9700では7Kトークン以上のプロンプトで7/13がクラッシュし、28Kトークンでは0/3しか完了しなかったと報告した。https://github.com/mw00/project-maya/pull/39

会話スロットの永続化とSIGTERMハンドラの追加

エンジン停止時に会話スロット（会話履歴）が保存されず、再起動時にすべての会話が読み直される問題と、SIGTERM（Ctrl+C）ハンドラがなかったため、停止時にGPUリソースが解放されず保存も行われない問題が修正された。

v1.0.15では、`STRATA_GLM_SLOT_KEEP=1`を設定することでスロットフォルダが保持され、エンジン終了時に会話が保存される。また、SIGTERM受信時にキュー内のリクエストを拒否し、実行中のリクエストを完了（WRAP）させてから停止する仕組みが追加された。

サーバーとして使用し、会話履歴を保持したいユーザーは、この機能により再起動後の手間が省ける。

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

AVX2非対応CPU（Sandy/Ivy Bridge）でのSIGILL対策

AVX2命令セットをサポートしていない古いCPU（Sandy/Ivy Bridge）で、インストール時に拒否されたり、起動時にSIGILL（不正な命令）クラッシュが発生する問題が修正された。

修正により、AVX2非対応CPUでもインストールが可能になり、起動時にSIGILLが発生しなくなった。AVX2非対応の場合、ggmlのベクトル演算カーネルが使用され、AVX2対応CPUと比較してデコード速度が約15%低下するが、動作可能になった。

古いCPUを搭載しているユーザーは、Mayaを動作させることができるようになる。

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

利用者の報告

開発者 ksanislo は、2x Xeon E5-2660 v2 + 4x T4の環境で、修正前は起動時にSIGILLが発生していたが、修正後は動作し、CPUレーン（ggmlカーネル）を使用することで`STRATA_GLM_CPU_LANE=0`と比較してデコード速度が+15%向上したと報告した。https://github.com/mw00/project-maya/pull/32

4090D 48GB + 3600X環境での高速化実測（+120%）

特定の構成（RTX 4090D 48GB + Ryzen 9 3600X 128GB DDR4）において、PRの適用によりデコード速度が約10-11t/sから25t/sに向上した。

この高速化は、RAMが十分にあり、オフカードのデータをRAMに保持できる環境で効果的である。逆に、RAMが限られる環境（例：2x Tesla V100、30GB RAM）では、速度が低下する可能性があるため、注意が必要。

大規模なRAMを搭載し、GPUを複数使用するユーザーは、速度向上の可能性がある。

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

利用者の報告

handmade0octopus は、4090D 48GB + 3600X 128GB DDR4の環境で、2つのPRを提出し、デコード速度が約10-11t/sから安定して25t/sに向上したと報告した。https://github.com/mw00/project-maya/issues/28

開発者 mw00 は、これらのPRがv1.0.15にマージされ、4090 Dの環境では256Kコンテキストでデコード速度が11.8から22.1 tok/sに向上したと確認した。また、RAMが限られる環境（2x Tesla V100、30GB RAM）では速度が低下する可能性があるため、READMEで大きなRAM環境向けのチューニングとして説明されていると回答した。https://github.com/mw00/project-maya/issues/28#issuecomment-6069348086

Windows環境でのPCIeキャリブレーションとディスク再読み込み問題の修正

Windows環境のコンシューマーGPU（RTX 4070 Ti SUPERなど）で、アイドル時のPCIeリンク速度低下（Gen1）によるキャリブレーション誤差と、進行中のデモション時のディスク再読み込みにより、デコード速度が半分（7.1 -> 14.6 tok/s）になる問題が修正された。

修正により、アイドル時のPCIeリンク速度低下を考慮したキャリブレーションと、デモション中のスロット再利用が実装され、デコード速度が約2倍に向上した。

Windows環境でコンシューマーGPUを使用しているユーザーは、速度が大幅に向上する。

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

利用者の報告

tanutanu56 は、RTX 4070 Ti SUPER 16GB + RTX 5070 Ti 16GB、Ryzen 7 3700X、128GB DDR4、Windows 11、CUDA 12.9、Maya-S-v2-IQ2_XXS、32Kコンテキスト、v1.0.11の環境で報告した。修正前（v1.0.11）のデコード速度は7.1 tok/sだったが、修正後（デフォルト分割）で9.8、`STRATA_GLM_SPLIT=17`、CPUレーン6/スレッド2で14.6 tok/sに向上した。https://github.com/mw00/project-maya/issues/13

開発者 mw00 は、この報告が正しいと確認し、両方の問題（デモション中のディスク再読み込みとアイドルリンクキャリブレーション）が修正されたと回答した。テストマシン（Tesla V100）ではアイドル時にリンクが低下しないため、この問題は発見されなかったと説明した。https://github.com/mw00/project-maya/issues/13#issuecomment-6064354679

Qwenプリトークナイザーによる数字分割エラーの修正

GLM-5.3-Flash向けに設計されたプリトークナイザーが、Qwen用の設定をデフォルトで参照していたため、長文プロンプトにおいて数字が 1 桁ごとに分割される不具合が発生していました。これにより、トークン数が過剰に増加し、数値が文字化けしていました。

修正により、パッケージ内の `tokenizer.json` に定義された `pre`（`glm4`）と特殊 ID を正しく読み込むようになりました。これにより、数字の分割が公式トークナイザーと同様の単位（例: `504` → `50|4`）になり、32k および 128k の長文コンテキストでも正確な数値抽出が可能になりました。

この修正は、GLM パックのディレクトリ構成を自動認識するため、ユーザーが手動で設定を再適用する必要はありません。

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

利用者の報告

• v1.0.15で修正され、Maya-S packにおいて数字の分割が正しく処理されるようになった。 mw00

利用者の報告

mab776 氏は、修正版 (v1.0.12) でのテスト結果を報告しています。Maya-S 環境において、32k および 128k のコンテキストで 6/6 の正確な needle-in-a-haystack テストを達成し、公式トークナイザーとのエンコーディング一致を確認しました。

Strix Halo (gfx1151) 公式サポートとUnified Memory対応

AMD Ryzen AI Max+ 395 等の Strix Halo (gfx1151) 搭載機では、GPU メモリとシステム RAM が共用 (Unified Memory) であるため、従来の VRAM 基準のメモリ管理では正しく動作しませんでした。特に、セットアップ時のメモリプールや RAM サイズの手動設定が必要でした。

今回の変更により、HIP 環境において統合 GPU を公式サポートしました。システムの利用可能メモリ (`MemAvailable`) から、重み、KVキャッシュ、スクラッチ領域を差し引いた残量を基に、エキスパートプールのサイズを自動計算するようになりました。また、インストーラーも gfx1151 に対応し、APU 用に 1GB の予約メモリを設定します。

これにより、Strix Halo 搭載機でも手動設定なしで Maya を実行可能になります。

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

利用者の報告

boxwrench 氏は、この変更が AMD 環境でのビルドと動作に寄与していることを確認しています。ROCm 7.2.1 環境 (gfx1100/gfx1201/gfx1151) でのビルド成功と、R9700 でのベンチマーク準備を報告しています。

CPU Lane: PCIeリンク計測とRAMからのExpert提供

GPU がアイドル状態になると PCIe リンクが低速化 (Gen1 等) し、CPU からのデータ転送が遅延する問題がありました。また、VRAM から追い出されたエキスパート (デモート) が、ディスクから再読み込みされるまで待機する必要がありました。

GPU 起動状態で PCIe リンクの速度を計測し、実際の転送速度に基づいて転送先を最適化しました。さらに、VRAM から追い出された直後のエキスパートがまだ RAM に残っている場合、ディスク読み込みではなく RAM から提供するように変更されました。

これにより、PCIe リンクの速度低下による遅延が解消され、SSD への読み込み頻度が削減されました。

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

利用者の報告

boxwrench 氏は、AMD 環境 (HIP/ROCm) でのビルドエラーを報告し、`wall_clock64()` を使用した代替実装を提案しました。この提案は採用され、AMD GPU でも正常に動作するようになりました。

mw00 氏は、2x Tesla V100 環境でのテスト結果を報告しています。デコード速度は 28.4/28.9 → 29.8/29.7 tok/s に向上し、トークンあたりの SSD 読み込み回数は 3.0 → 2.2 に削減されました。また、RAM から提供されたデモート処理が数百回発生していることが確認されています。

ツール呼び出しエラー: malformed tool call

Windows 環境で GLM-5.3-Flash-iq2_xxs を実行時、ツール呼び出し（例: tavily-search）において「malformed tool call」エラーが発生していました。これは、フロントエンドがツール呼び出しの XML 形式を正しく解析・レンダリングできていなかったことが原因です。

フロントエンド (`frontend.py`) の修正により、GLM 固有のツール呼び出し形式（`tool-name/arg_key/arg_value`）が正しく処理されるようになりました。

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

利用者の報告

xldistance 氏は、エラーの原因となるコードと修正が必要なファイル (`serve/frontend.py`) を特定し、報告しています。

2 GPU構成でのGLMパック推論性能

2x 64GB GPU 構成 (GA100) において、GLM-5.3-Flash-Maya-M を完全に VRAM に配置した状態で推論を行った場合、トークン生成速度は 77.0 tok/s となりました。しかし、トークンあたりの処理時間 (13.6 ms) のうち、約 68% を占める「待機時間 (wait tail: 9.20 ms)」がボトルネックとなっていました。

この待機時間は、GPU 間の処理負荷の偏り（テール側の GPU への負荷が高いこと）に起因します。デフォルトでは層の分割数が中間値に設定されているため、テール側の GPU が処理を完了するまでホストが待機していました。

この問題を解決するには、`STRATA_GLM_SPLIT` 環境変数で層の分割バランスを調整するか、`STRATA_GLM_NO_MTP=1` で MTP を無効化することで、ホスト待機時間を削減できます。

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

利用者の報告

mw00 氏は、この待機時間が設計上の制約であることを説明し、層の分割バランス調整による改善の可能性を提示しています。

3 GPU以上での speculative decode 動作

3 GPU 以上の環境では、従来の speculative decode（MTP）が正しく動作していませんでした。これは、NextN ブロックの読み込みと `spec_ready()` の要件が 2 GPU 構成向けに設計されていたためです。

今回の変更により、3 GPU 以上でも speculative decode が動作するようになりました。GPU を「ヘッドグループ（ドラフト生成）」と「テールグループ（トークン確定）」に分け、ヘッドグループがドラフトを生成している間にテールグループが処理を進めるパイプライン処理が実装されました。

4x Tesla T4 環境でのテストでは、decode 速度が 15.0 → 22.6 tok/s (+49%) に向上しました。

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

利用者の報告

jaredschnelle 氏は、4x RTX 3090 環境での独自実装によるベンチマークを報告しています。Direct engine 環境では 54.83 → 85.91 tok/s (+56.7%)、Chat API 環境では 44.2 → 74.0 tok/s (+67.4%) の向上を確認しました。

RDNA4向けHIPプロンプト注意力カーネル最適化

AMD RDNA4アーキテクチャ（gfx12）において、HIPバックエンド用の新しいプロンプト処理カーネルが追加されました。これにより、AMD GPUユーザーがプロンプト読み込みを高速化できるようになります。

新しいカーネル（`wmma2`）は、FP16の高精度/残差積とFP32の蓄積、ソフトマックスを使用するwave32 WMMAカーネルです。これは既存のrocWMMAカーネル（`f16q`）と共に実装され、アーキテクチャごとにデフォルトが切り替わります。具体的には、Radeon AI PRO R9700やRX 9070（gfx12）では新しい`wmma2`カーネルが、RX 7900 XTやStrix Halo（gfx11）では既存の`f16q`カーネルがデフォルトとして使用されます。CUDA環境には影響がありません。

R9700においてプロンプト処理速度が約8〜10%向上します。ユーザーは環境変数`STRATA_GLM_PREFILL_ATTN`（値: `wmma2`、`f16q`、`f32`）を指定することで、カーネルを手動で強制することも可能です。

出典: PR #38: HIP: wave32 WMMA prompt attention on RDNA4

利用者の報告

ユーザー boxwrench は、RX 7900 XTとR9700の両環境でテストを実施し、新しい`wmma2`カーネルがF32カーネルと比較して誤差範囲内で正常に動作し、`glm_layer_parity --selftest`も全カーネルでパスしたと報告しています PR #38。

GLMエンジンにおけるバッチスロット数の拡張要望

GLMエンジンに対して、Strataエンジンで実装されているバッチ処理機能（`--batch N`）の移植と、バッチスロット数の拡張（8スロット以上、理想は16スロット）が要望されています。また、分割された構成でも動作するRAM内での会話保持機能や、Codex互換クライアント向けの`/v1/responses`エンドポイントの実装も提案されています。

この機能により、複数のリクエストを効率的にパイプライン処理できるようになり、特に高負荷環境でのスループット向上が期待されます。

出典: Issue #30: Batch Slots on GLM Engine

AMD（HIP）サポートの現状と計画の追跡

AMD GPU（HIPバックエンド）での動作状況、測定結果、および計画中のPR（プルリクエスト）が追跡されています。現在、Linux環境での実験的なセットアップや、複数のGPUアーキテクチャ（gfx1100, gfx1201, gfx1151）に対応した単一HIPバイナリの開発が進められています。また、APU（Strix Halo）向けの統一メモリ対応も計画されています。

これにより、AMD GPUユーザーはより安定した環境でMayaを利用できるようになります。

出典: Issue #6: AMD (HIP) support: status, measurements and planned PRs

利用者の報告

ユーザー boxwrench は、gfx1151（gfx1151）において14/14のGPUチェックとフルモデル実行がパスしたと報告しています Issue #6。

ユーザー jerem91150 は、Windows 11環境（RX 7900 XTX）での報告を行っています。ビルドと実行は成功しましたが、一部のテスト（`hip_handoff`等）でタイムアウトやハングが発生しました。また、温度設定が0より大きい場合、約15回に1回の割合でプロンプトの最初のトークンの直後にプロンプトが消失するサンプリングバグを特定し、報告しています Issue #6 comment。

開発者 mw00 は、jerem91150 氏の報告に基づき、サンプリングバグを修正したv1.0.15をリリースしました。これにより、NVIDIA環境（V100）で温度1.0時の処理速度が約26.7 tok/sから26.8〜27.6 tok/sに向上しています Issue #6 comment。

ユーザー Talos77 は、Radeon RX 6750 XT（gfx1031）を搭載したWindows 10環境でのサポートを要望しています Issue #6 comment。

2x CMP 170HX（64GB）環境でのMaya-Mベンチマーク

2枚のNVIDIA CMP 170HX（各64GB、合計128GB）をPCIe Gen2 x4で接続した環境でのベンチマークデータが報告されました。この環境では、Maya-Mモデルを完全にVRAM内に配置することで、61.3 tok/sのデコード速度を達成しています。

PCIe Gen2 x4という帯域が限られた環境でも、モデルがVRAM内に収まることで高いパフォーマンスが発揮される実証データとなります。

出典: Issue #22: Speed data: 2x CMP 170HX (64 GB each, PCIe Gen2 x4) - Maya-M fully in VRAM, 61.3 tok/s decode

利用者の報告

ユーザー ZackO2o は、Intel Xeon E5-2690 v4、RAM 91GB、Ubuntu環境（CUDA 13.0）で、`maya.py bench()`の契約を正確に再現する形でベンチマークを実施しました。その結果、デコード速度61.3 tok/s、8Kコンテキストでのプリフィル速度514 tok/sを記録しました Issue #22。

開発者 mw00 は、このデータをREADMEの速度表に追加し、v1.0.15時点での記録として採用したと報告しています Issue #22 comment。

GLMエクスパートのVRAM保持ルール：STRATA_GLM_PROMOTE_MIN

環境変数`STRATA_GLM_PROMOTE_MIN=N`を追加しました。これにより、取得したエクスパートをVRAMに保持する条件を、そのエクスパートが使用された回数（ aged route count ）がN回以上の場合に限定できます。これにより、一度きりの使用でエクスパートがVRAMを占有し、他のエクスパートを追い出す（evict）のを防ぎます。

デフォルト（0または未設定）は従来のルール（空きスロットがあれば常に保持）です。RTX 4090 Dでの測定では、`STRATA_GLM_PROMOTE_MIN=6`を設定することで、コールド起動時の処理時間が53.7 ms/tokから45.8 ms/tokに、ウォーム起動時でも49.8 ms/tokから40.9 ms/tokに改善されました。

出典: PR #26: GLM: opt-in STRATA_GLM_PROMOTE_MIN, stop one-off promotions

GLMエクスパートのRAM居住ティアとディスク退避防止

フラグ`--glm-ram-resident`（環境変数`STRATA_GLM_RAM_RESIDENT=1`）を追加しました。これにより、VRAMに収まらないすべてのエクスパートを固定RAM（pinned RAM）に保持し、エクスパートがディスクに退避（demotion）するのを防ぎます。RAMティアのサイズは、VRAM外のすべてのエクスパートを保持できる大きさに自動調整されます。また、`--glm-ram-slack`（デフォルト16）で、退避処理中の一時的なスロットを追加できます。

これにより、ディスクI/Oを伴う退避処理が不要になり、特にRAMに十分な余裕がある環境で安定したパフォーマンスが期待できます。

出典: PR #25: GLM: opt-in RAM-resident tier, nothing evicted to disk

HIP: RDNA3/3.5向けデコード高速化

AMD GPU（RDNA3/3.5）で、Expertゲートやダウンカーネルの重み読み込みを最適化するデコード高速化が行われました。

この変更により、RX 7900 XT（gfx1100）では回答速度が最大 8.6% 向上し、出力はビットレベルで同一性が維持されました。gfx1151（Strix Halo）では一部カーネルで速度低下が測定されたため、既存カーネルが維持されています。CUDA（NVIDIA）環境への影響はありません。

AMD GPUユーザー、特にRX 7900 XT等を使用している場合、回答生成速度の向上が期待できます。

根拠: PR #19: HIP: faster decode expert kernels on RDNA3/3.5

利用者の報告

boxwrench さんは、RX 7900 XT（gfx1100）環境でベンチマークを実施し、新旧カーネルの比較を行いました。その結果、最大絶対誤差 0、相対 L2 誤差 0 でビット同一性が確認され、回答速度が +8.6% 向上したと報告しています。

また、開発者 mw00 さんは、この変更を含む修正が v1.0.15 に含まれることを確認し、2x Tesla V100 環境でも NVIDIA 側のビルドやパリティテスト、F32 との一致性等に問題がないことを報告しています。

HIP: Linux環境でのベンチマーク・レポート機能追加

Linux 環境の HIP バックエンドにおいて、`--bench` および `--report` コマンドが利用可能になりました。

`--bench` は指定された GPU 選択と環境変数（`HIP_VISIBLE_DEVICES`）に基づいてベンチマークを実行します。`--report` は `amd-smi` / `rocm-smi` から AMD GPU の名称、gfx アーキテクチャ、VRAM、ドライバー情報を取得し、ROCm のパスやバージョン、エンジンの速度ラインを出力します。`nvidia-smi` の呼び出しは行われず、ツールが欠落していてもレポート処理は失敗しません。

AMD GPU を Linux で使用し、環境情報やベンチマーク結果を詳細に確認したいユーザーにとって、トラブルシューティングや環境把握が容易になります。

根拠: PR #18: HIP: --bench and --report on Linux AMD

HIP: MLA製品をFP16化とrocWMMA Attentionカーネル追加

HIP 環境において、プロンプト処理（prefill）の MLA 製品計算を FP16 に変更し、rocWMMA テンソルコアを用いた新しい Attention カーネルが追加されました。

これにより、Strix Halo（gfx1151）ではプロンプト処理速度が 16% 向上しました。rocWMMA カーネルは 57 KB の LDS を使用し、RDNA の 64 KiB 制限内に収まっています。FP16 化や rocWMMA 使用はデフォルトで有効ですが、環境変数で F32 カーネル等へのフォールバックが可能です。CUDA 環境への影響はありません。

AMD GPU（特に Strix Halo 等）でプロンプト処理の高速化を図れるようになります。

根拠: PR #16: HIP prompt path: MLA products in FP16 and rocWMMA attention

利用者の報告

boxwrench さんは、この変更によるプロンプト速度の向上を測定し、Strix Halo 環境で +16% の改善を確認したと報告しています。また、F32 カーネルとの比較テストも実施し、正常に動作していることを確認しています。

開発者 mw00 さんも、2x Tesla V100 環境で NVIDIA 側のビルドやテスト、F32 との一致性等を確認し、問題なく v1.0.15 に含まれることを報告しています。

RAM Shadow Tier: SSD再読み込み削減のためのRAM共有モード

RAM ティアにモデルの大部分を保持するマシン向けに、`STRATA_GLM_RAM_SHADOW=1` で有効になる Opt-in モードが追加されました。

従来の排他的なティア構成では、Expert が VRAM に昇格すると RAM 側のコピーが解放され、降格時に SSD からの再読み込みやデバイスからホストへのコピーが発生していました。この新モードでは、昇格した Expert の RAM コピー（シャドウ）を保持し、降格時に SSD からの再読み込みを削減します。シャドウは RAM に空きができる際に最も古いものから回収されます。デフォルトでは無効です。

大規模な RAM を持ち、Expert の昇格・降格が頻繁に発生する環境において、SSD への負荷軽減と読み込み速度の改善が期待できます。

根拠: PR #15: Opt-in RAM shadows for the expert tiers

利用者の報告

boxwrench さんは、この機能の概要と、シャドウ保持による SSD 再読み込みの削減効果を報告しています。また、開発者 mw00 さんは、シャドウの回収順序や、V100 環境でのビルド確認を報告しています。mw00 さんは、背景昇格（`STRATA_GLM_PROMOTE`）との相互作用によりシャドウ数が変化する可能性があるため、現在の main での再測定を推奨しています。

HIP: 2枚GPU構成とMTPドラフティング

HIP 環境において、`--gpus 0,1` により 2 枚の AMD GPU（異なるアーキテクチャも可）を使用可能になりました。

より大きな VRAM を持つ GPU が優先され、モデルレイヤーの分割と MTP（Multi-Token Prediction）ドラフティングが実行されます。各 GPU には対応する hipBLASLt のチューニングテーブルが個別に適用されます。CUDA 環境への影響はありません。

複数の AMD GPU を所有するユーザーが、VRAM を拡張してより大きなモデルや高速な推論を利用できるようになります。

根拠: PR #14: HIP: two GPUs (--gpus 0,1) with MTP drafting

利用者の報告

boxwrench さんは、2 GPU 構成のテストと、異なるアーキテクチャ間の動作確認を報告しています。開発者 mw00 さんは、R9700 + RX 7900 XT 環境での実測値（デコード: 約 33 vs 15 tok/s、プレフィル: 490 vs 414 tok/s）を引用し、v1.0.14 に含まれることを報告しています。

RTX 3090 + 3060構成でのベンチマークとディスク読み込み修正

NVIDIA GPU（RTX 3090 + RTX 3060、Quadro RTX 4000 追加）および 125GB RAM を搭載した環境での実測ベンチマークと、ディスク読み込みに関する修正・セットアップ発見事項が報告されました。

この構成における Maya-M の動作確認と、ディスク読み込みの最適化に関する知見が共有されています。

複数カード構成や大規模 RAM を使用する NVIDIA GPU ユーザーにとって、実環境でのパフォーマンス参考やセットアップ時の注意点として役立ちます。

根拠: Issue #29: Maya-M on RTX 3090 + RTX 3060 (+ Quadro RTX 4000), 125 GB RAM: benchmarks, a disk-read fix, setup findings

利用者の報告

sociolog さんは、自身のマシン構成（RTX 3090、RTX 3060、Quadro RTX 4000、125GB RAM）でのベンチマーク結果と、ディスク読み込みに関する修正、セットアップ時の発見事項を詳細に報告しています。

Intel Arc Pro B70 対応の要望

Project Maya は Strata のエンジンとサーバーを基盤としており、Strata は v0.1.40.2 から Intel Arc 向けに SYCL ポートを提供している。この既存のポートを流用し、Maya でも Intel Arc GPU での推論が可能になるかという技術的な検討がなされている。

現在、Maya は NVIDIA GPU への対応が中心だが、Strata が提供している dpct 移行ツールと fixups.py を活用したアプローチにより、Intel Arc Pro B70 での動作が検討されている。これは NVIDIA 環境とは異なるアーキテクチャでの動作検証を意味し、ユーザーの選択肢を広げる可能性がある。

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

利用者の報告

jeberly は、2 枚の Intel Arc Pro B70 (各 32 GB、xe ドライバー) を搭載した環境 (Ryzen 9600X、64 GB RAM、Gen5 x8) で、Strata の SYCL ポート上で Qwen3.8-Flash-Next を動作させている。Maya でも同様のハードウェアで GLM-5.3-Flash を試したいとしており、ベンチマーク結果 (--bench) の報告を約束している https://github.com/mw00/project-maya/issues/37

ハードウェアレポートとエンジンパッチの貢献ガイドライン

Maya への貢献において、ハードウェアレポートやエンジンパッチを提出する際の推奨プロセスが明確化された。特にソースコードからのビルド環境では `maya.sh` が存在しないため、レポートの提出方法に迷うユーザーへの対応が行われた。

ハードウェアレポートは、`--bench` と `--report` オプションを付けた Issue への添付が推奨される。エンジンパッチは `main` ブランチへの Pull Request として提出する。パッチは NVIDIA 環境での動作変更が目的でない限り、Tesla V100 でのビルドとテストを経てマージされる。

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

利用者の報告

ZackO2o は、2 枚の 64 GB Ampere 世代 GPU (合計 128 GB、PCIe Gen2 x4) を搭載した環境で、61.3 tokens/s のデコード速度と 99.8% の VRAM 使用率を記録している。ソースビルド環境でのレポート提出方法について質問し、最終的にガイドラインが策定された https://github.com/mw00/project-maya/issues/21

開発者 mw00 は、CONTRIBUTING.md (v1.0.15 で新規作成) に回答し、ハードウェアレポートは Issue への添付、エンジンパッチは Pull Request への提出を指示した https://github.com/mw00/project-maya/issues/21#issuecomment-6069346997

GLM-5.3-Flash-CYBERSECURITY-W4A16 モデルサポート

Maya は GLM-5.3-Flash の GGUF ファイルからモデルを読み込む。W4A16 量子化形式の safetensors リリースは、そのままでは読み込めないため、変換が必要となる。

W4A16 のチェックポイントを読み込むには、llama.cpp の `convert_hf_to_gguf.py` で BF16 にデ量子化後、`llama-quantize` で GGUF に変換するか、既存の GGUF ファイルを使用する必要がある。Maya の量子化ツールは Z.ai の FP8 リリースを対象としており、W4A16 チェックポイントは直接読み込めない。

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

利用者の報告

開発者 mw00 は、W4A16 safetensors リリースを Maya で直接使用できない理由を説明し、GGUF への変換手順を提示した。MTP (draft) ブロックがない GGUF でも動作し、2 枚の GPU であれば別の GLM-5.3-Flash GGUF からドラフトブロックを借用できることを報告している https://github.com/mw00/project-maya/issues/1#issuecomment-6065480642

4 GPU 構成での単一 GLM-5.3-Flash インスタンス要望

現在、Maya の 1 インスタンスは最大 2 枚の GPU までしか対応しておらず、レイヤーを 2 分割して MTP 推論を行う。4 枚の GPU を使用して 1 つのインスタンスでより高精度な量子化モデルを動かしたいという要望が出されている。

4 枚の V100 32GB (合計 128GB VRAM/RAM) を持つ環境では、現在 2 枚の GPU で Maya-M (116 GB、平均 2.9 bits/weight) を動作させ、残り 50 GB を RAM tier に配置することで SSD 読み込みをほぼ回避できる。4 分割が実装されれば、各 GPU がレイヤーの 4 分の 1 を担当し、約 112 GB の expert 領域を確保できるため、VRAM からの読み込みがほぼ完結する可能性がある。

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

利用者の報告

areslp は、4 枚の V100 32GB を持つ環境で、単一の GLM-5.3-Flash インスタンスによる高精度量子化モデルの動作を求めている。現在の GPU セレクタの制限 (2 枚まで) を指摘し、4 分割の実装計画と MTP の維持可能性について質問している https://github.com/mw00/project-maya/issues/9

開発者 mw00 は、現在の 1 インスタンスは最大 2 枚の GPU までであることを確認し、4 分割は未実装と回答した。4 枚の V100 32GB を持つ環境での現在の動作 (Maya-M の 2 GPU 使用、RAM へのオフロード) と、4 分割が実装された場合のメモリ配置の変化を説明している https://github.com/mw00/project-maya/issues/9#issuecomment-6057839917

プロジェクト共有の呼びかけ

プロジェクト-maya の開発者に対して、GithubStarMate への参加を促す呼びかけが行われた。これは、より多くの開発者にプロジェクトの存在を知ってもらうためのコミュニティ活動の一環である。

GithubStarMate は、GitHub 開発者向けのプロジェクト発見と相互支援プラットフォームであり、Stars、Watches、Forks などの機能を通じてプロジェクトの露出を高めることができる。この呼びかけは、プロジェクトの宣伝プログラムの一環として行われている。

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

利用者の報告

boothjill182 は、プロジェクト-maya の開発者に GithubStarMate への参加を呼びかけた。この呼びかけは、プロジェクトの宣伝プログラムの一環として行われている https://github.com/mw00/project-maya/issues/11

2026-10-08 のリリース (Project Maya v1.0.5 〜 v1.0.16・9 版)

• Project Maya v1.0.5 (リリース・2026-10-08)
• Project Maya v1.0.6 (リリース・2026-10-08)
• Project Maya v1.0.7 (リリース・2026-10-08)
• Project Maya v1.0.8 (リリース・2026-10-08)
• Project Maya v1.0.9 (リリース・2026-10-08)
• Project Maya v1.0.13 (リリース・2026-10-08)
• Project Maya v1.0.14 (リリース・2026-10-08)
• Project Maya v1.0.15 (リリース・2026-10-08)
• Project Maya v1.0.16 (リリース・2026-10-08)

Project Maya v1.0.11: AMD GPU (HIP) 実験的サポート開始

• #2 Fix HIP doorbell publication and KDA parity initialization (PR・2026-10-08)
• #3 Add experimental Linux gfx1100 setup for Maya GLM (PR・2026-10-08)
• #4 Extend Linux HIP setup to R9700 with multi-architecture builds (PR・2026-10-08)
• #7 HIP prompt speed: tuned hipBLASLt GLM projections, runtime sub-batch (7900 XT, R9700, Strix Halo) (PR・2026-10-08)
• Project Maya v1.0.11 (リリース・2026-10-08)

2026-10-07 のリリース (Project Maya v1.0.0 〜 v1.0.4・5 版)

• Project Maya v1.0.0 (リリース・2026-10-07)
• Project Maya v1.0.1 (リリース・2026-10-07)
• Project Maya v1.0.2 (リリース・2026-10-07)
• Project Maya v1.0.3 (リリース・2026-10-07)
• Project Maya v1.0.4 (リリース・2026-10-07)

2026-10-09 のリリース (Project Maya v1.0.17 〜 v1.0.20・4 版)

• Project Maya v1.0.17 (リリース・2026-10-09)
• Project Maya v1.0.18 (リリース・2026-10-09)
• Project Maya v1.0.19 (リリース・2026-10-09)
• Project Maya v1.0.20 (リリース・2026-10-09)

思考予算の制御とループガード（パターン反復防止）

• #33 Loop guard (PR・2026-10-09)
• #34 Thinking budget leaves room for the answer (PR・2026-10-09)

出典

• Project Maya v1.0.0
• Project Maya v1.0.1
• Project Maya v1.0.2
• Project Maya v1.0.3
• Project Maya v1.0.4
• Project Maya v1.0.5
• Project Maya v1.0.6
• Project Maya v1.0.7
• Project Maya v1.0.8
• Project Maya v1.0.9
• Project Maya v1.0.10
• Project Maya v1.0.11
• Project Maya v1.0.13
• Project Maya v1.0.14
• Project Maya v1.0.15
• Project Maya v1.0.17
• Project Maya v1.0.18
• Project Maya v1.0.19
• Project Maya v1.0.20
• Issue #8: Turing (sm_75): the prompt attention asks for 67584 bytes of shared memory
• Issue #5: Tool calls support
• PR #7: HIP prompt speed: tuned hipBLASLt GLM projections
• PR #34: Thinking budget leaves room for the answer
• PR #33: Loop guard

利用者の報告

• RTX 20シリーズ (Turing) で v1.0.10 のプロンプト処理が共有メモリ不足によりクラッシュする問題について、mw00 が原因と対策を報告。mw00