Project Maya v1.1.0〜v1.1.6：並列推論、EXL3量子化、KVキャッシュのRAM配置と高速化

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.0)： 最大 8 リクエストを同時に処理可能に。v1.1.0 では、Maya-S の全エキスパートが GPU メモリに収まる Strix Halo 環境で、2 並列時 1.67 倍、4 並列時 2.02 倍の高速化を確認。
• EXL3 量子化の修正と高速化 (v1.1.3, v1.1.4, v1.1.6)： v1.1.3 では調査中のクラッシュ報告を受けて非表示にしていた Windows セットアップの EXL3 選択肢を復活させ、v1.1.4 では DFlash2 併用時のノイズ出力と EXL3 エキスパート用カーネルの不足を修正。DFlash2 ドラフター併用時の推論速度を大幅に改善し、MTP ブロックや単一推論を上回る性能に。
• Vision 機能の修正 (v1.1.2)： Claude Code の Read ツールから返される画像が認識されない問題を修正。
• 長文コンテキストの高速化 (v1.1.6)： 注意機構のキャッシュを RAM にストリーミングし、VRAM をエキスパート用に確保。512K コンテキストでプロンプト処理が 4-9 倍高速化。

並列推論機能の追加

v1.1.0 で、複数のリクエストを同時に処理する並列推論機能が追加されました。コマンドライン引数 --parallel N（最大 8）で有効化できます。単一の GPU では、各リクエストのトークンをモデルに同時に通し、密な重み（注意機構の射影、共有エキスパート、密な層、出力ヘッド）を一度読み出すことで効率化します。注意機構とルーティングされたエキスパートはリクエストごとに実行されます。各リクエストは、単独で処理した場合と同じトークン数を受け取ります。

この変更により、環境に応じた速度向上が期待できます。V100 上で Maya-S のエキスパートの多くを RAM からストリーミングする場合、2 並列で 1.41 倍、4 並列で 1.35 倍の高速化が確認されています。一方、Strix Halo 環境で全てのエキスパートを GPU メモリに保持できる場合、2 並列で 1.67 倍、4 並列で 2.02 倍の高速化が報告されています。2 枚以上の GPU を使用する場合は、各カードが異なるリクエストを順番に処理します。

• リリースノート: Project Maya v1.1.0

EXL3 量子化モデルの修正と高速化

v1.1.0 で導入された EXL3 量子化モデルについて、初期バージョンでは Windows 環境でのクラッシュや、DFlash2 ドラフター併用時の出力ノイズ（「Let Letj{{_{ #{ ... !!!!!!!!」といった文字化け）が報告されていました。これは、検証窓（verify window）が BF16 形式の EXL3 埋め込みベクトルの行サイズを正しく認識できなかったことに起因します。

v1.1.4 でこの不具合が修正され、EXL3 モデルが DFlash2 ドラフターと正常に連携するようになりました。さらに v1.1.6 では、EXL3 パックにおける DFlash2 検証窓のコストが削減されました。これにより、各 EXL3 重みが窓内の全トークンに対して一度だけ復号されるようになり、推論効率が大幅に向上しました。

RTX 3090 + 5060 Ti 環境では、DFlash2 併用時の EXL3 復号速度が約 2 倍になり、MTP ブロックを 15-29% 上回る性能となりました。単一の RTX 3090 環境でも、チャットでの復号速度が 13-30% 高速化しています。

• リリースノート (v1.1.4): Project Maya v1.1.4
• リリースノート (v1.1.6): Project Maya v1.1.6
• 修正 PR: #141 EXL3 with the DFlash2 drafter
• 最適化 PR: #164 EXL3 verify windows

利用者の報告

EXL3 モデル使用時の不具合について、複数のユーザーから報告と検証が行われています。

mw00 によると、v1.1.0 の Windows 環境では EXL3 量子化モデルが最初のプロンプトで illegal memory access エラーを起こすことが確認されました。v1.1.1 ではクラッシュ報告を受けて Windows のセットアップで EXL3 量子化モデルの提供が一時停止され、v1.1.3 で提供が再開されましたが、そのクラッシュは報告者と引き続き調査中でした。

anbow1 は RTX 5090 環境で v1.1.3 をテストし、DFlash2 ドラフターと EXL3 を併用するとクラッシュすることが報告しています。特に、ビジョンエンコーダーがプール尾部を借用している場合、DFlash2 併用時のみクラッシュが再現しました。anbow1 は、同じ PC の GSQ-RCO 3.5-bit モデルについて、古いビルドと比較して v1.1.3 ではディスク読み込みが約 10 倍になり、デコード速度が 18-23.6 tok/s から 11-17.6 tok/s に低下したと報告しています。

needmorevram は、EXL3 モデルで DFlash2 ドラフターを使用すると出力がノイズになる問題を報告し、検証窓の行サイズ計算に起因することを特定しました。修正後、同じモデルで MTP ブロックを使用した場合と同様の出力が得られることを確認しています。

EXL3量子化モデルとDFlash2併用時の出力ノイズ不具合修正 の項目一覧

• #129 EXL3 on Windows, less aggressive experts allocation slower decode (Issue・2026-10-13)

Windows 環境での RAM 常駐不具合の修正

Windows/WDDM 環境において、--glm-ram-resident オプション有効時にシステム RAM を完全に常駐させられない問題が報告されていました。RTX 5090 + 256GB RAM 環境で bmgjet が報告したところ、タスクマネージャーで RAM 使用量が 67GB で頭打ちになり、メモリ不足エラーが発生していました。

mw00 によると、この問題は Windows ドライバーと OS による 1 プロセスあたりのページロック（ピン留め）制限（約 67GB）が原因でした。RAM 常駐オプションは、VRAM に収まらないエキスパートを SSD ではなく RAM に保持するものですが、Windows ではドライバーの制限により全ての RAM をピン留めできないため、エラーとなっていました。

v1.1.3 では、SSD から読み込まれる低重みエキスパートをスキップするオプション（STRATA_GLM_DISK_SKIP_W=0.12）が追加されました。PR #153 では、Windows/WDDM 環境での完全な RAM 常駐に向け、エキスパートクラス間のピン留め RAM 配分を調整する、オプトインの割り当て処理の修正が示されています。これにより、利用可能なピン留めメモリ予算が全てのルーティング済みエキスパートと貸与に必要な容量をカバーする場合、正常に RAM 常駐が有効化されるようになりました。

• 報告 Issue: #128 STRATA_GLM_RAM_RESIDENT doesn't seem to work
• 修正 PR: #153 GLM: balance pinned RAM across expert classes

利用者の報告

bmgjet は、RTX 5090 + 256GB RAM 環境で Maya-M と Maya-S をテストし、RAM 常駐有効時に 67GB でエラーが発生することを報告しています。常駐無効時は 7.5-10 tok/s の速度でしたが、常駐有効時は SSD 読み込みが激増し、Qwen3.8 Flash Next が Strata で 280-300 tok/s を記録するのに対し、GLM では 40-80 tok/s を期待していたとのことです。

PhysicistLeon は、Maya-L 構成でテストし、小ストライドクラスの割り当てが不要な予備容量を保持し、他のクラスが要件を下回っていたことを特定しました。修正により、必要なクラス数（2168 / 9214）が確保され、正常に RAM 常駐が動作することが確認されています。

Vision 機能の修正

v1.1.2 で、Anthropic の tool_result 内に含まれる画像が認識されない問題が修正されました。通常、ユーザーコンテンツブロックとして送信された画像はビジョンエンコーダーに到達しますが、tool_result 内にネストされた画像はドロップされていました。これにより、Claude Code の Read ツールが画像を返す場合でも、モデルがそれを見ることができませんでした。

CoolJohn-lab による修正で、_parts_of 関数を通じて画像部分を保持するようになり、テキストのみの結果は文字列として維持されました。これにより、Claude Code セッションで Read ツールが返した画像を正常に認識できるようになりました。

• 報告 Issue: #119 Anthropic tool_result images are dropped
• 修正 PR: #120 Preserve Anthropic tool-result images for vision

利用者の報告

CoolJohn-lab は、Maya v1.0.34 でテストし、64×64 の青い四角形をトップレベルのユーザー画像として送信すると 18 入力トークンが追加され、名前が「blue」と認識されたのに対し、tool_result 内にネストすると 0 入力トークンで「red」と誤認識されたことを報告しています。また、Claude Code セッションで 3 回の Read 呼び出しを行い、PNG バイトがトランスクリプトに含まれていても、モデルが空のツール結果を報告したことを確認しています。

mw00 は、修正後、Read 形状の tool_result に画像が含まれる場合、🖼️ マーカーが 🔚 内にレンダリングされ、テキストのみの結果は文字列として維持されることを確認しています。

長文コンテキストの高速化

v1.1.6 で、注意機構のキャッシュを RAM にストリーミングする機能が追加されました。これにより、キャッシュの窓を VRAM に保持し、残りをピン留め RAM に配置することで、VRAM をエキスパート用に確保できます。

RTX 3090 環境で 512K コンテキストを使用する場合、エキスパートスロットが 714 から 1,176 に増加し、プロンプト処理が 4-9 倍高速化、デコードが 5% 高速化しました。1M コンテキストが単一の 3090 で起動可能になり、2 枚の GPU で 128K コンテキストの 4 会話（--parallel 4）を同時にデコードする場合、37% の高速化が確認されています。

• リリースノート: Project Maya v1.1.6
• 修正 PR: #86 KV streaming for long contexts

その他の主な変更点

会話チェックポイント (v1.1.5)

v1.1.5 で、会話の開始を共有するプロンプト（同じシステムプロンプトとツールを持つ別のチャット、または最後のメッセージが編集されたチャット）が、新しい部分のみを読み込むようになりました。会話の状態は RAM に保持され（各 150 MB 程度、デフォルトで 4 個）、システムプロンプトの末尾、最後のターン開始、および 16K トークンごとに保存されます。

• リリースノート: Project Maya v1.1.5

DFlash2 の速度キャリブレーション (v1.1.3)

v1.1.3 で、DFlash2 ドラフターが各 PC で高速かどうかを自動測定する速度キャリブレーション機能が追加されました。モデルを 2 回読み込み、ウォームアップ後に約 1,500 トークンの回答を書き出し、持続速度を比較します。DFlash2 が 5% 以上高速な場合のみ有効化されます。測定には 5-20 分かかり、各ステップが表示されます。

• リリースノート: Project Maya v1.1.3

サンプルドデコードの高速化 (v1.1.2)

v1.1.2 で、サンプルドデコードの速度が向上しました。サンプラーが語彙の k 回スキャンではなく、top_k トークンを 1 回のパスで選択するようになり、RTX 4090 で top_k 20 の場合、サンプル時間が 1.5 ms から 0.07 ms に短縮されました。4 枚の RTX 4090 環境でサンプルドデコードが 13% 高速化し、選択結果は v1.1.1 とトークン単位で同一であることが確認されています。

• リリースノート: Project Maya v1.1.2

2026-10-12 のリリース (Project Maya v1.1.0 〜 v1.1.4・5 版) の項目一覧

• Project Maya v1.1.1 (リリース・2026-10-12)

Windows環境でのCUDAページロック上限によるRAMティア起動失敗

Windows環境では、CUDAのページロック機能（cudaHostAllocなど）がプロセスごとに約90 GBの上限を設けており、これによりRAMティアの確保が制限される現象が発生しています。

この上限により、VRAMに収まらないモデルの重み（RAMティア）を確保できず、RAM常駐モードの起動に失敗します。例えば、VRAM 32 GB、RAM 192 GBの環境で、128Kコンテキストのモデルを起動しようとすると、RAMティアは最大でも84〜91 GBしかピン留めされず、必要な約125 GBを確保できません。残りのエキスパートはSSDから読み込まれるため、トークン生成速度が大幅に低下し（12.93 reads/tok）、実用的な推論が困難になります。

この制限はドライバーレベルのものらしく、環境変数（STRATA_GLM_RAM_GB）やNUMA設定では回避できません。開発者によると、上限を超えたメモリはGPUが直接読み込めないためCPU経由で処理する必要があり、これはティア構成の根本的な変更が必要なため、即座のパッチではなく今後のロードマップに含まれるとのことです。

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

利用者の報告

gmanzienko さんは、RTX 5090 32 GB、RAM 192 GB、Windows 11、Maya v1.1.3の環境で再現を確認しました。RAMティアは84.23 GBしか確保できず、RAM常駐モードは起動に失敗しています。また、SSDからの読み込みにより、デコード速度は3.06 tok/s、ディスク読み込みは12.93 reads/tokという結果になっています。

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

uvtzxpm さんも、RTX 3090 24 GB、RAM 64 GBの環境で同様の事象に遭遇しています。実行中に約25 GBのRAMが未使用状態になる一方で、エキスパート用に約21.4 GBしかピン留めできないと報告しています。

https://github.com/mw00/project-maya/issues/147#issuecomment-6137461375

サービング機能の修正: 特殊タグ、チェックポイント、NaNガード

エージェント対応や長時間のチャットにおける安定性向上のため、いくつかのサービング機能が修正されました。まず、メッセージ内の特殊トークン（<|user|>など）がモデルに誤って解釈されないよう、プライベートなマークに置換する処理が追加されました。これにより、エージェントがファイルを読み込んだ際や、ツール結果に特殊文字が含まれていても、正しくテキストとしてエンコードされるようになりました。

また、推論中に稀に発生するNaN（Not a Number）のログイットによる出力崩れ（トークン0の繰り返し）を防ぐガード機能が実装されました。NaNが発生したウィンドウのトークンは出力されず、会話は安全な状態にリセットされます。さらに、ストリーミングAPIで"return_progress": trueを指定すると、プロンプト処理の進捗状況（prompt_progress）がストリームに追加され、クライアント側でプログレスバーを表示可能になりました。

根拠: https://github.com/mw00/project-maya/pull/146, https://github.com/mw00/project-maya/pull/143, https://github.com/mw00/project-maya/pull/163

速度報告: 2x RTX 3090 + Threadripper 3990X / EPYC 7452

複数のユーザーから、2枚のRTX 3090を使用したハイエンド構成での速度報告が上がっています。AMD EPYC 7452（32コア）と256 GB RAMの環境では、Maya-Mで44.0 tok/s、Maya-Lで30.2 tok/sのデコード速度が記録されました。また、AMD Ryzen 7 5800X3Dと125.7 GB RAMの環境でも、安定した動作が確認されています。

一方で、AMD Threadripper 3990X（64コア/128スレッド）環境では、デコード処理中にCPUの半分（64スレッド）がアイドル状態になるという報告があります。これは、Mayaが物理コア64個のうち32個の物理コアと32個のSMTスレッドのみを使用しているためであり、残りの32物理コアが活用されていない可能性があります。

根拠: https://github.com/mw00/project-maya/issues/165, https://github.com/mw00/project-maya/issues/168, https://github.com/mw00/project-maya/issues/169

利用者の報告

orochifj さんは、EPYC 7452、256 GB RAM、2x RTX 3090（PCIe 4.0 x16、電力制限250 W）の環境で、Maya-Mで44.0 tok/s、Maya-Lで30.2 tok/sのデコード速度を記録しました。また、プロンプト長17K〜105Kでのプリフィル速度も報告しています。

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

21387A さんは、Threadripper 3990X、256 GB RAM、2x RTX 3090の環境で、プリフィル速度が約700〜720 tok/s、デコード速度が約16 tok/sであると報告しています。また、デコード中にCPUの半分（スレッド64〜127）がほとんど負荷をかけない状態になっていることを指摘しています。

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

drrck82 さんは、Ryzen 7 5800X3D、125.7 GB RAM、2x RTX 3090の環境での速度報告を行っています。

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

HIP環境(gfx1151)およびTuringアーキテクチャの修正

Linux環境でのAMD GPU（HIP）利用において、インストールされているhipBLASLtのバージョンと、Mayaが選択するチューニングテーブルのバージョンが一致しない問題が修正されました。これにより、gfx1151環境で正しくhipBLASLtが使用されるようになりました。

また、Turingアーキテクチャ（RTX 20xxシリーズなど）での推論崩れを防ぐ修正が行われました。従来、Turingでは推論カーネルの実行に必要なレジスタ数が上限を超え、起動に失敗していましたが、修正によりレジスタ使用量が抑えられ、正常に動作するようになりました。

根拠: https://github.com/mw00/project-maya/issues/158, https://github.com/mw00/project-maya/pull/162, https://github.com/mw00/project-maya/pull/161

利用者の報告

Tsury さんは、Linux gfx1151環境で、インストールされているhipBLASLt 100401に対し、Maya v1.1.5が古いテーブル（100202）を選択し、エラーが発生する事象を報告しました。

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

sociolog さんは、Turingアーキテクチャ（sm_75）で、 speculative samplingを使用した場合、レジスタ不足によりカーネル起動に失敗する事象を報告し、修正後のレジスタ使用量の変化を示しています。

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

CPUエキスパートの共有デコードとMTPブロックの画像行対応

CPU上で動作するエキスパートのデコード速度が向上しました。特に、IQ3_SおよびIQ3_XXS量子化形式において、AVX2命令を活用した最適化により、処理が高速化されました。

また、複数のトークンで共有されるCPUエキスパートの重みは、各トークンごとに再デコードされるのではなく、一度デコードされた結果が共有されるようになりました。これにより、特に長いプロンプトや複数トークンの処理において、デコード効率が向上します。さらに、MTP（Multi-Token Prediction）ブロックのキャッシュにおいて、画像行の読み込みが最適化されました。

根拠: https://github.com/mw00/project-maya/pull/166, https://github.com/mw00/project-maya/pull/154

プロンプト読み込みの公平性調整とレイヤ分割パイプライン最適化

長いプロンプトの読み込み中に、短いリクエストが到着した場合、そのリクエストが読み込み完了まで待機するのではなく、読み込みを一時停止して処理できるようになりました。これにより、長時間のプロンプト処理中でも、短いリクエストへの応答待ち時間が短縮されます。

また、複数のGPUにモデルを分割して使用する場合（レイヤ分割）、短いプロンプトでもGPU間で処理を並列化できるようになりました。従来は、プロンプトが1つのチャンクに収まる場合、GPUが順番に処理していましたが、修正によりプロンプトが分割され、GPU間で並列処理が行われるようになりました。これにより、マルチGPU環境でのプロンプト処理効率が向上します。

根拠: https://github.com/mw00/project-maya/pull/144, https://github.com/mw00/project-maya/pull/138

テレメトリサンプラーのクラッシュ不具合とV100環境での性能報告

Project Mayaのサーバープロセスは、推論中にテレメトリ情報を収集するサンプラー内でエラーが発生すると、サーバー全体が停止する仕組みになっています。また、複数のGPUを搭載した環境では、GPUごとの性能が推論速度に直結します。

Issue #136 では、回答のストリーミング中にテレメトリサンプラーのNVML呼び出しでSIGSEGVが発生してサーバーが終了し、使用していた2枚のGPUが、新しいCUDAコンテキストが作成されるまで100%使用率・P0状態・約190Wのままだったと報告されています。また、4枚のTesla V100（PCIe接続、計128GB VRAM）環境では、GLM-5.3-Flash Maya-Lモデル（IQ3_S量子化）で26.7 tok/sの推論速度が実測されています。

このクラッシュはサーバーの安定性を損なうため重要です。開発者mw00氏は、サンプラーがバッファオーバーランを引き起こしていたことを認め、修正パッチを求めています。V100環境での数値は、レガシーGPUでも実用的な推論が可能であることを示す基準となります。

根拠: Issue #136, Issue #130

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

• Thanks for the excellent report, and sorry it took a while to answer. You're right on both points in `serve/telemetry.py… — mw00

利用者の報告

cosmicnag氏は、ストリーミング中にサーバーがSIGSEGVで落ち、GPUがP0状態（100%使用率、約190W）でロックされる現象を報告しています。エンジンプロセスは生き残っていましたが、手動で停止するまでVRAMを保持し続けたとのことです。

areslp氏は、4枚のTesla V100（PCIe接続、計128GB VRAM）環境でGLM-5.3-Flash Maya-Lモデル（IQ3_S量子化）を実行し、26.7 tok/sのデコード速度を確認しました。環境はUbuntu 22.04、CUDA 12.1.105、NVIDIAドライバー535.154.05です。

レイヤ分割環境でのマルチ会話状態管理と共有キャッシュ

レイヤ分割（layer split）設定では、複数のGPUでモデルの層を分担して推論を行います。この際、複数の会話を並列で処理する場合、プロンプトの読み込み（prefill）が他の会話の生成を一時停止させる問題がありました。

PR #125および#126により、プロンプト読み込みがデコード処理と並行して実行されるようになり、会話状態のキャッシュと共有が改善されました。これにより、並列推論時のプロンプト読み込み遅延が解消され、会話の再開や共有状態の保持が効率的に行えるようになりました。

この改善は、複数のユーザーやエージェントが同時に同じサーバーを利用する場合の応答速度と安定性に直結します。

根拠: PR #125, PR #126

利用者の報告

ksanislo氏は、レイヤ分割環境での並列推論において、プロンプト読み込みがデコードと並行して実行されるようになり、会話状態の管理が改善されたことを報告しています。これにより、複数の会話間でプロンプト読み込みが干渉し合う問題が解決されました。

LoRA: llama.cpp互換GGUFアダプターの全エンジンパス対応

Project Mayaは、llama.cpp互換のGGUF形式LoRAアダプターをサポートしています。これにより、既存のLoRAモデルをMayaのすべての推論エンジンパスで利用可能になりました。

PR #137により、GGUF形式のLoRAアダプターがすべてのエンジンパスで利用可能になりました。これにより、ユーザーは既存のLoRAモデルをMayaで簡単に適用できるようになります。

この対応により、ユーザーは既存のLoRAモデルをMayaで簡単に適用できるようになり、モデルのカスタマイズ性が向上します。

根拠: PR #137

速度報告: RTX 5090 + i9-13900KでのGLM-5.3-Flash推論

最新のNVIDIA RTX 5090 GPUとIntel i9-13900K CPUを搭載した環境での推論速度が報告されました。IQ2_XXS量子化モデルを使用することで、高い推論速度が実現できます。

v1.1.3において、RTX 5090（32GB、PCIe Gen5 x16）とi9-13900K（24コア/32スレッド）、64GB RAM、Windows 11、CUDA 13.3の環境で、GLM-5.3-Flash Maya-S-v2-IQ2_XXSモデル（128kコンテキスト）を実行した結果、デコード速度は平均23.0 tok/s、prefill速度は2048トークンで635 tok/s、8192トークンで2173 tok/sでした。モデル読み込み時間は41秒でした。

この数値は、最新GPU環境での実用的な推論速度を示しており、ユーザーが自身の環境で期待できる性能の基準となります。

根拠: Issue #139

利用者の報告

gianbing氏は、RTX 5090（32GB、PCIe Gen5 x16）とi9-13900K（24コア/32スレッド）、64GB RAM、Windows 11、CUDA 13.3の環境で、GLM-5.3-Flash Maya-S-v2-IQ2_XXSモデル（128kコンテキスト）を実行し、デコード速度は平均23.0 tok/s、prefill速度は2048トークンで635 tok/s、8192トークンで2173 tok/sであることを報告しています。

mw00 氏は、v1.1.3以降の`START-MAYA.bat --calibrate`コマンドがCPU側の処理に使うスレッド数とPCIeの共有割合を測定して最速の設定を保持し、一部の環境ではデコード速度が大きく向上すると述べ、Issue #130の環境で34%向上した例を挙げています。(リンク: mw00)

Windowsビルド失敗: CUDA 12とVisual Studioバージョン不整合

Windows環境でProject Mayaをビルドする際、CUDAツールキットとVisual Studioのバージョン間に互換性の問題が発生することがあります。CUDA 12はVisual Studio 2019以降を必要としますが、一部の環境ではエラーが発生します。

Issue #167において、Windows 10、RTX 3090、64GB DDR4、i7-6700K、Visual Studio 2022、CUDA 12.4、CMake 4.4、Python 3.13の環境でビルドが失敗しました。エラーメッセージは「unsupported Microsoft Visual Studio version - CUDA 12 needs Visual Studio 2019 - 2022」と「unsupported gpu architecture compute_70 - CUDA 13 cannot build for Volta, install CUDA 12.x」でした。

この問題は、Windows環境でのビルド環境構築の障壁となります。CUDA 12とVisual Studio 2022の組み合わせが正式にサポートされているか確認が必要です。

根拠: Issue #167

利用者の報告

technerd-official氏は、Windows 10、RTX 3090、64GB DDR4、i7-6700K、Visual Studio 2022、CUDA 12.4、CMake 4.4、Python 3.13の環境でビルドが失敗し、「unsupported Microsoft Visual Studio version」と「unsupported gpu architecture compute_70」のエラーが発生したと報告しています。

@mch_tamaya氏は、RTX 5090、RAM 64GB、VS 2022、CUDA 12.8の環境でGLM-5.3-Flash + Maya-S（Project Maya v1.0.34、コンテキスト32K）を実行した結果を共有しています。

Unsloth分割モデル: メタデータのみシャードでのアーキテクチャチェック失敗

Unslothで分割されたモデルファイルを使用する際、メタデータのみを含むシャード（shard）が正しく認識されない問題が発生します。これは、`--native`オプションでメタデータシャードを指定した場合、必要なテンソルが存在しないために発生します。

Issue #150において、Unsloth分割モデル（Qwen3.8-Flash-Next-UD-IQ3_XXS）のshard 1がメタデータのみ（70 KVs、0テンソル）で、shard 2/3がテンソルを含む（各3つの`split.*` KVs）場合、`--native`オプションでshard 1を指定すると`token_embd.weight`が存在しないエラーが発生し、shard 2を指定すると`general.architecture`が存在しないエラーが発生しました。

この問題は、Unsloth分割モデルをMayaで使用する際の障壁となります。開発者mw00氏は、このパスがメンテナンスされていないことを認め、ドキュメントのクリーンアップを行うと回答しています。

根拠: Issue #150

利用者の報告

Angular-Angel氏は、Unsloth分割モデル（Qwen3.8-Flash-Next-UD-IQ3_XXS）のshard 1がメタデータのみ（70 KVs、0テンソル）で、shard 2/3がテンソルを含む（各3つの`split.*` KVs）場合、`--native`オプションでshard 1を指定すると`token_embd.weight`が存在しないエラーが発生し、shard 2を指定すると`general.architecture`が存在しないエラーが発生したと報告しています。

mw00氏は、このパスがメンテナンスされていないことを認め、ドキュメントのクリーンアップを行うと回答しています。また、7900シリーズカードでは`docs/AMD_MAYA.md`のセットアップを推奨しています。

テンプレート思考モードとパーサー状態の整合性修正

GLM-5.3-Flash 向けに設計された Maya のテンプレートでは、`enable_thinking` が明示的に true の場合にのみ `` タグを出力するようになっています。しかし、`reasoning_effort: "max"` などの設定では、レスポンスパーサーの初期化時にこのフラグが省略されるバグがありました。この不具合により、ストリーミング・非ストリーミング両方のリクエストで、ツール呼び出しのマークアップが正しく解析されず、`reasoning_content` 内に混在して出力されるケースがありました。

今回の修正では、既存の GLM-effort パス以外のテンプレートにおいて、生成されたプロンプトのデフォルトを `enable_thinking: true` に変更し、パーサーのルールと整合させました。これにより、自動ツール呼び出し時のマークアップ出力が正常化されます。

この修正により、思考モード（reasoning mode）でのツール呼び出しが正しく機能し、レスポンスの信頼性が向上します。特に、思考を必要としない強制ツール呼び出しは従来通り動作し、思考をオフにする必要があるツール呼び出しも正しく処理されます。

根拠: PR #148: Align template thinking with parser state

利用者の報告

beverm2391 氏は、RED-SNOW UD-Q4_K_XL モデルを 2 枚の NVIDIA L40 GPU で使用し、RAM/ディスクへのエキスパートオフロードと 106 GiB のサービスメモリ制限を適用した環境で検証を行いました。その結果、修正前のコミットでは自動ツール呼び出しで問題が発生していましたが、修正後のコミット（`37282d821cf1075f116bbbd90f985ef1ccad99df`）では正常に動作し、サーバースイートの 158 テストとインストーラー/ツールスイートの 249 テストがすべてパスしました。

RTX 5080 環境における CUDA Prefill 速度とチューニング余地

RTX 5080 (16 GB) 単体での CUDA 環境におけるプロンプト処理（prefill）速度の実測値が報告されました。2,048 トークンのプロンプトで 106 tok/s、8,192 トークンのプロンプトで 279 tok/s という結果でした。これは、同じマシンでの llama.cpp ベースの 27B モデル（約 1,200 tok/s）や Strata の 125B モデル（1,100〜1,500 tok/s）と比べて遅い値です。

この遅延の主な原因は、GPU ではなく SSD への依存にあります。RAM が 47 GB しかない環境では、エキスパートバイトの約 40% が RAM に保持され、残りは NVMe SSD から読み込まれます。プロンプト処理ではほぼ全てのレイヤーのエキスパートが必要となるため、SSD からの読み込みがボトルネックとなり、プロンプト長に関わらず約 28 秒の処理時間がかかっていました。

開発者（mw00）によると、この環境ではカーネルのチューニングでは速度向上が見込めず、RAM を増設（96 GB 程度）してエキスパートを VRAM と RAM に収めることが、prefill 速度とデコード速度の両方を改善する唯一の方法です。

根拠: Issue #155: CUDA prompt speed, single RTX 5080

利用者の報告

zhanghuqqqq 氏は、Ryzen 7 9800X3D、RAM 47 GB、RTX 5080 単体の環境でベンチマークを行いました。その結果、2K/8K のプロンプトでそれぞれ 106/279 tok/s を記録し、有効な演算能力がカードのピーク性能（約 110 TFLOPS）の約 10 TFLOPS にとどまっていることを示しました。また、開発者の mw00 からの回答により、RAM 容量の不足が SSD 読み込みを強制していることが確認されました。

RDNA4 (RX 9070 XT) 環境での HIP バックエンド速度報告

Windows 11 上で AMD Radeon RX 9070 XT (16 GB, RDNA4) を使用し、HIP バックエンドで Maya を動作させた最初の報告です。Ryzen 9 5900XT、RAM 128 GB、NVMe RAID0 の環境で、Maya v1.1.4 を使用してベンチマークが行われました。

報告では、セットアップ、ビルド、モデルのダウンロード・パック化が正常に完了し、約 2.5 時間のテスト中にドライバーのリセットやエラーは発生しませんでした。ただし、2 つの小さな不具合が確認されました。1 つは、`maya-bench.txt` に古い GPU 名（6700 XT）が表示される問題（レジストリの参照元）。もう 1 つは、プロンプトバッファがエキスパートプールに収まらない場合に、トークン生成速度が急激に低下する「クリフ」現象です。

開発者（mw00）は、GPU 名表示の問題は `hipInfo` を使用することで修正予定であること、速度低下の問題はチャンクサイズを縮小することで対応することを説明しました。また、32K コンテキストでの 2K プロンプト処理が 8K よりも遅いという異常な現象については、プロファイル情報を取得して調査するよう依頼されています。

根拠: Issue #156: RX 9070 XT (gfx1201, 16 GB) on Windows 11, HIP

利用者の報告

pros02 氏は、RX 9070 XT 16 GB を搭載した Windows 11 マシンで Maya-S および Maya-S24 の速度報告を行いました。セットアップからテストまでスムーズに完了し、ドライバーエラーは発生しませんでした。開発者の mw00 からの回答により、報告された 2 つの不具合（GPU 名表示と速度クリフ）が確認され、今後の修正予定が示されました。

EPYC + RTX 3090 環境での DFlash2 と MTP 分割推論ベンチマーク

AMD EPYC 7702P（8 チャンネル DDR4）と RTX 3090 単体、および RTX 3090 + RTX 3060 の構成で、Maya-M モデルの速度が比較されました。RTX 3090 単体ではデコード 27.0 tok/s、prefill（2K/8K）で 592/1069 tok/s を記録しました。

RTX 3060 を追加して MTP（Multi-Token Prediction）ドラフティングを有効にすると、デコード速度は 33.7 tok/s（持続 30.9 tok/s）に向上し、単体構成（22.7 tok/s）と比較して約 36% の改善が見られました。ただし、prefill 速度は 8K で 36% 低下しました。また、DFlash2（高速化のためのドラフティング手法）は、すべての環境で速度較正が失敗し、逆効果となりました。

開発者（mw00）によると、DFlash2 が遅くなるのは、ドラフトウィンドウに必要なエキスパートの多くが VRAM 外（RAM や PCIe 経由）にあるため、ドラフティングのコストが節約分を上回っているためです。また、単一 GPU での `STRATA_GLM_MTP=1` は開発者向けスイッチであり、通常の使用では設定しないよう注意喚起が行われました。

根拠: Issue #157: Speed report: Maya-M on EPYC 7702P + RTX 3090

利用者の報告

erikash 氏は、EPYC 7702P と RTX 3090、および RTX 3060 を追加した構成でベンチマークを行いました。MTP 分割によりデコード速度が向上した一方で、DFlash2 はすべての環境で速度較正に失敗し、逆効果だったことを報告しました。開発者の mw00 からの回答により、DFlash2 が遅くなる理由（RAM からのエキスパート読み込みコスト）と、CPU スレッド数の調整方法（`STRATA_GLM_CPU_LANE`）が説明されました。

Threadripper PRO + 4x RTX 3090 環境での EXL3 ベンチマーク

AMD Threadripper PRO 3975WX（32 コア）、RAM 256 GB、RTX 3090 4 枚の構成で、GLM-5.3-Flash の EXL3 量子化モデル（3.05bpw および 4.05bpw）の速度が測定されました。Maya-L 構成ではデコード約 38 tok/s、EXL3-3.05bpw では約 42 tok/s を記録しました。一方、EXL3-4.05bpw では約 19-21 tok/s と速度が低下し、また DFlash2 との組み合わせではチャットやコーディングテストで品質が著しく低下しました。

この環境では、高解像度の量子化（4.05bpw）や DFlash2 の使用が、速度や品質の面で逆効果となる可能性があることが示されました。

根拠: Issue #142: Speed Report(s): Maya L, EXL3-3.05bpw, EXL3-4.05bpw Threadripper PRO 3975WX

利用者の報告

bandito1 氏は、Threadripper PRO 3975WX と 4 枚の RTX 3090 を使用し、Maya-L、EXL3-3.05bpw、EXL3-4.05bpw の各構成でベンチマークを行いました。EXL3-3.05bpw が最も高い速度（42 tok/s）を示しましたが、EXL3-4.05bpw は速度が半分以下に低下し、DFlash2 との組み合わせでは出力品質が著しく低下したと報告しました。また、@PeasantSmith は、4 枚の RTX 4090 を使用した環境でデコード速度が 13% 向上し、EXL3 が DFlash2 とともに動作するようになったと報告しています。さらに、@loudchirper は、単一の RTX 5090 で 30+ tok/s、4 枚の RTX 4090 で最大 118 tok/s を達成し、大規模モデルのローカル推論が実用的になっていると評価しています。

2x RTX 4090 + Dual Xeon 構成での GLM-5.3-Flash 性能

2 枚の RTX 4090（24 GB）、2 個の Intel Xeon Silver 4309Y、RAM 188 GB の構成で、Maya-S24 モデルの速度が測定されました。デコード速度は 40.5 tok/s、prefill（8K）は 1271 tok/s を記録しました。これは、単一 GPU 構成と比較して非常に高いパフォーマンスです。

`--calibrate` コマンドによる最適化後、デコード速度は 38.1 tok/s に若干低下しましたが、prefill 速度は 1285 tok/s に向上しました。開発者の設定（PCIe シェア 0.36、CPU スレッド 8）が最も高速であることを示しています。

この構成は、大規模な RAM と CPU を活用し、複数の GPU でモデルを分散処理することで、高い推論速度を実現しています。

根拠: Issue #122: Speed report: 2x RTX 4090 24 GB, 2x Xeon Silver 4309Y, 188 GB RAM

利用者の報告

fuad00 氏は、2 枚の RTX 4090 と 2 個の Xeon Silver 4309Y、RAM 188 GB の構成でベンチマークを行いました。デコード速度 40.5 tok/s、prefill（8K）1271 tok/s を記録し、`--calibrate` による最適化で PCIe シェア 0.36、CPU スレッド 8 が最速であることを確認しました。

RTX 3090 2枚構成の電力制限設定と性能

RTX 3090 2枚構成において、電力制限（パワーリミット）をデフォルトの 350W から 225W に設定した場合の実測値です。電力制限は nvidia-smi コマンドで設定します。

電力制限 225W 設定時、RTX 3090 1枚構成では 26.0 tok/s、2枚構成では 53.0 tok/s のデコード速度が記録されました。2枚構成では、VRAM にルーティングされるエキスパートの比率が 65% から約 80% に向上し、MTP ドラフトの恩恵もあって性能がほぼ 2 倍になっています https://github.com/mw00/project-maya/issues/135。

利用者の報告

• RTX 3090 2枚構成で電力制限 225W 設定時、1 枚構成（26.0 tokens/s）の約 2 倍となる 53.0 tokens/s を達成し、VRAM 内のルーティング効率向上と MTP ドラフトが寄与したと報告している。mw00

利用者の報告

@briepala により、AMD Ryzen Threadripper 3970X、RAM 128GB、NVMe SSD 構成での報告があります。両 GPU を 225W に制限し、Maya v1.1.2 で Linux 環境（CachyOS、kernel 7.0.10、CUDA 13.2）を動作させた結果、1枚構成で 26.0 tok/s、2枚構成で 53.0 tok/s を達成しました https://github.com/mw00/project-maya/issues/135。

AMD RX 7900 XTX (Windows)でのGLM-5.3-Flash性能

Windows 11 環境における AMD Radeon RX 7900 XTX (gfx1100) 単体での性能実測です。NVMe SSD にモデルを配置し、32K コンテキストで動作させます。

ディスク読み込みの最適化（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 と最速となり、デフォルトの 2 チャンク（6.48 tok/s）を上回りました。また、バージョン 1.0.29 から 1.0.33 への更新で 8.2 tok/s から 9.6 tok/s (+17%) へと性能が向上し、クラッシュは発生していません https://github.com/mw00/project-maya/issues/134。

利用者の報告

• AMD RX 7900 XTX (Windows) 環境において、`MV_RDNA=1` に効果がないこと、prefetch が約10%のオーバーヘッドを生むこと、`--prefill 8192` が低速であること、`DISK_READERS=8` で変化がないこと、V-cache CCD へのピン留めが数%程度の効果しかないことが確認された。 mw00

利用者の報告

@jerem91150 により、Ryzen 9 7900X3D、RAM 64GB、Windows 11 環境での報告があります。同一時間内での交互テストにより、ディスク読み込みの最適化とバージョンアップによる性能向上を確認しました https://github.com/mw00/project-maya/issues/134。

2x RTX A4000 16GB構成でのUnsloth量子化モデル性能

RTX 3090 24GB と RTX 3060 12GB の 2枚構成において、Unsloth 量子化モデル（UD-IQ4_XS）を使用した場合の性能比較です。MTP ドラフティングと DFlash2 ドラフティングの比較が行われています。

2枚構成では、MTP ドラフティングが 23.97 tok/s を記録し、DFlash2（11.95-14.27 tok/s）を大きく上回りました。1枚構成でも、MTP ドラフティング（23.97 tok/s）が DFlash2（14.57-14.74 tok/s）を上回っています。DFlash2 はドラフトの受け入れ率が 64-93% と正確ですが、検証ウィンドウのコストが利益を上回っているため、この環境では MTP ドラフティングが最適と判断されました https://github.com/mw00/project-maya/issues/127。

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

• Following up on this in [v1.1.3](https://github.com/mw00/project-maya/releases/tag/v1.1.3): DFlash2 is now checked on ea… — mw00

利用者の報告

@sociolog により、Ryzen 9 5900X、RAM 128GB、Linux Mint 環境での報告があります。10種類のセットアップをテストし、MTP ドラフティングが DFlash2 よりも高速であることを確認しました https://github.com/mw00/project-maya/issues/127。

GPU分割推論: Dual-link stagingによるプロンプト高速化

2GPU 分割環境において、PCIe と NVLink を活用してプロンプト処理時間を短縮する最適化です。通常、プロンプト処理時は片方の GPU が待機状態になりますが、この機能により待機中の GPU にもエキスパートをステージングできます。

STRATA_GLM_DUAL_PREFILL=1 を有効にすることで、待機中の GPU の VRAM にエキスパートを配置し、処理中の GPU と NVLink 経由で通信させます。これにより、短中規模プロンプトにおいてプロンプト処理時間の約 3 分の 2 を占めていた待機時間を削減できます https://github.com/mw00/project-maya/pull/121。

利用者の報告

@q8atnight により、この機能の実装と効果についての報告があります。2GPU 分割環境でのプロンプト処理時間の短縮が確認されています https://github.com/mw00/project-maya/pull/121。

推論最適化: 常駐エクスパート計算とPCIeフェッチの並列化

VRAM に常駐しているエキスパートの計算中に、PCIe 経由で転送中のエキスパートを並列処理する最適化です。これにより、GPU の待機時間を削減し、推論速度を向上させます。

STRATA_GLM_FETCH_OVERLAP=1 を有効にすることで、メインストリームで常駐エキスパートの計算を行いながら、サイドストリームで PCIe 経由のフェッチを実行します。この機能はビット単位の正確性を保ちつつ、性能向上をもたらします https://github.com/mw00/project-maya/pull/118。

利用者の報告

@q8atnight により、この機能の実装と効果についての報告があります。並列処理による性能向上が確認されています https://github.com/mw00/project-maya/pull/118。

ビルド環境: 複数CUDA Toolkit存在時のリンク不具合修正

システムに複数の CUDA Toolkit が存在する場合、正しい nvcc とライブラリをリンクするよう修正されました。これにより、ビルド時のリンクエラーや実行時エラーを回避できます。

修正前、CMake は指定した nvcc（例：CUDA 13.0）を使用しながらも、システムデフォルトのライブラリ（例：CUDA 12.0）をリンクする問題がありました。修正後、指定した nvcc に基づいて正しい Toolkit のルートパスを CMake に渡すようになり、リンクが正常に行われるようになりました https://github.com/mw00/project-maya/pull/124。

利用者の報告

• Windowsではツールキットルート（パスに空白を含む場合は引用符で囲む）でエンジンと画像エンコーダーがビルドされ、Ubuntuでは従来通り/usr/bin/nvcc（スクリプト）でビルドされた。 mw00

利用者の報告

@fuad00 により、Ubuntu 24.04 環境での報告があります。複数の CUDA Toolkit が存在する環境でも、正しくビルドできることが確認されました https://github.com/mw00/project-maya/pull/124。

ベンチマーク: 2x RTX 4090環境での速度報告

Mayaは、GPU、RAM、NVMe SSDにモデルを分散配置して推論を行います。この仕組みにより、単一のGPUメモリでは収まらない大規模モデルでも、複数のGPUやシステムリソースを活用して動作させることが可能です。

v1.1.0において、2枚のRTX 4090（各24GB VRAM）と188GB RAMの環境で、Maya-S24モデルの推論速度が報告されました。デコード速度は40.5トークン/秒、プリフィル速度は1271トークン/秒を記録しています。これは、2枚のTesla V100（計32GB VRAM）を使用した場合よりも高速な結果です。

この報告は、高スペックなNVIDIA GPUを複数台所有するユーザーにとって、大規模モデルをローカルで実用的な速度で動かすための有効な構成例を示しています。

根拠: PR #123

利用者の報告

fuad00 は、自身の環境（2x RTX 4090 24GB、PCIe 3.0/4.0 x16、2x Xeon Silver 4309Y、188GB RAM）で ./maya.sh --bench を実行し、v1.1.0のデフォルト設定（ --calibrate でも設定は変わらず）で 40.5 tokens/s のデコード速度と 1271 tokens/s のプリフィル速度を報告しました。(リンク: fuad00)

CUDAプロファイラ環境とLinux HIPでのCPUビジョン機能のドキュメント化

Mayaは、ビルド環境やOS、GPUアーキテクチャ（NVIDIA CUDA / AMD HIP）に応じて、開発者向けツールや機能の有効化手順が異なります。特にLinux環境では、CUDAツールキットの構成や、ROCmを用いたAMD GPU利用時の設定が複雑化しやすい傾向にあります。

Linux環境でのビルドトラブルシューティングとして、CUDA 13.3の分割インストール時に cuda_profiler_api.h や nvtx3/nvToolsExt.h が見つからない場合の対処法が文書化されました。また、AMD GPU（HIP）を使用するLinux環境において、画像認識機能（CPUビジョン）を有効化する手順が追加されました。これにより、ROCm環境でもテキスト推論に加えて画像処理が可能になります。

開発者や上級ユーザーにとって、ビルドエラーの解消や、AMD GPUでのマルチモーダル利用のハードルが下がります。

根拠: PR #160, PR #159

利用者の報告

vjsyongは、Linux（Debian 13, CUDA 13.4）環境で、2枚のRTX 5880 Ada Generation（計90GB VRAM）とXeon Gold 5420+、393GB RAMの構成で Maya-L（156.3GB）を動作させました。262Kコンテキストにおいて、デコード速度は 54.5 tok/s、プリフィル速度は 1401 tok/s を記録し、コンテキストの大部分でVRAM内にエクスパートが収まり、ディスクIOが発生しない状態を報告しました。

開発者の mw00 は、この報告に対し、CPUレーン（約13ms）がトークン生成時間の約18.5ms中最大のボトルネックになっていると指摘し、./maya.sh --calibrate を実行することでPCIe共有やスレッド設定を最適化し、速度向上が期待できると応答しています。

Tsury は、CUDAツールキットのヘッダー不足によるビルド失敗と、その解決策（開発者コンポーネントのインストールまたはNVIDIA wheelsの利用）を確認する形で報告しています。

CPU推論: IQ2_XXS向けAVX-2ゲート/アップカーネルの正確な実装

Mayaは、GPUメモリに収まらないエクスパートをRAM上のCPUで処理します。この際、量子化形式（例: IQ2_XXS）によっては、GPUパスとCPUパスで計算精度や順序が異なる場合があり、推論結果や速度に影響を与える可能性があります。

PR #132では、CPUレーンのIQ2_XXS形式の1行×1トークンの呼び出しに対し、デバイスパスと同じ計算（脱量子化、クリッピング、シグモイド乗算）を行うAVX-2カーネルを追加しています。これにより、計算精度がGPUパスと一致し、AVX-2対応CPU（AVX-512非対応）ではデフォルトで有効になります。

量子化エクスパートの計算精度が向上し、特にCPU処理がボトルネックになりやすい環境での推論速度が改善します。

根拠: PR #132

利用者の報告

handmade0octopusは、1枚のRTX 4090 DとRAMにエクスパートを配置した環境で、Maya-S-v2-IQ2_XXSモデルを用いたベンチマークを報告しました。新しいAVX-2カーネル（exact1）を有効化することで、CPUレーンの処理時間が改善し、全体としてのデコード速度が向上したことを確認しています。

GLM推論: MLA重みの読み込み最適化

GLMモデルの推論では、検証ウィンドウ（verify window）内で複数のトークンに対してAttention計算を行います。従来の実装では、このウィンドウ内でも行ごとに重みを読み込んでいたため、重複したメモリアクセスが発生していました。

PR #117 では、検証ウィンドウ内の全行に対して attn_k_b と attn_v_b の重みを1回だけ読み込む変更が示されています。これにより、行ごとの選択とAttention計算は維持しつつ、重み読み込みのオーバーヘッドを削減しています。

AMD GPU（ROCm）環境において、推論の検証ステップが高速化し、全体としての推論効率が向上します。

根拠: PR #117

利用者の報告

boxwrenchは、AMD Strix Halo（gfx1151）環境において、この最適化によりT=2の検証ラウンドが 78.13ms から 75.61ms（約2.52msの削減）に高速化したと報告しています。また、ROCm 7.2.1環境（R9700, 7900 XT）でもビルドとテストが正常に通過し、出力がバイトレベルで同一であることを確認しています。

出典

• Project Maya v1.1.0
• Project Maya v1.1.1
• Project Maya v1.1.2
• Project Maya v1.1.3
• Project Maya v1.1.4
• Project Maya v1.1.5
• Project Maya v1.1.6
• #128 STRATA_GLM_RAM_RESIDENT doesn't seem to work
• #129 EXL3 on Windows, less aggressive experts allocation slower decode
• #119 Anthropic tool_result images are dropped
• #153 GLM: balance pinned RAM across expert classes
• #141 EXL3 with the DFlash2 drafter
• #120 Preserve Anthropic tool-result images for vision
• #164 EXL3 verify windows
• #86 KV streaming for long contexts