【Project Maya】Project Maya v1.1.22〜23: AMDの2 GPU構成のDeepSeekハングアップ修正、Maya-XS追加、長文コンテキストのエラー修正

今回の要点

• 2 GPU構成のハングアップ修正: AMD GPU (HIP) で 2 枚構成かつ hipBLASLt 有効時に発生していたハングアップを修正 (v1.1.22)。
• サブエージェントのキャッシュ: DeepSeek Harness 利用時、サブエージェントのコンテキスト再読み込みを回避し、最大 7 倍の高速化を実現。
• 推論速度の向上: CPU のコア割り当て最適化でデコード速度を 68.5 tok/s に向上。Expert Lending 最適化で 7-9% の高速化。
• VRAM節約と新量子化: 128 GB PC 向け「Maya-XS」や、VRAM節約に有効な IQ1_S/IQ2_XS 量子化をサポート。
• 長文コンテキストの修正: 32,768 トークン超のコンテキストで AMD GPU や RTX 20 シリーズでエラーが発生する問題を修正 (v1.1.23)。

2 GPU構成のハングアップ修正

AMD GPU (HIP) を 2 枚使用して DeepSeek-V4.1-Flash を動かす際、hipBLASLt が有効だと最初の長いプロンプトでエンジンがハングアップする問題が報告されていました。この原因は、GPU 間のデータ転送待ちの間、プロセス全体のロックが保持されていたため、別の GPU の処理がブロックされるデッドロック状態に陥っていたためです。

v1.1.22 では、各 GPU デバイスごとにロックを個別に管理するよう修正されました。これにより、GPU 間のやり取り待ち中でもロックが解放され、正常に処理が完了するようになりました。

この修正は、2 枚の gfx1201 (32 GB) を搭載した環境で確認されています。ロックのローカル化により、GPU0 が GPU1 の完了を待つ間、GPU1 が他の処理を進めることが可能になりました。

詳細: PR #367 / Issue #366

利用者の報告

Gazelle221B 氏は、2 枚の gfx1201 (32 GB) を搭載した環境で、v1.1.21 では hipBLASLt が有効な場合に最初の 8,192 トークンの読み込みが完了せず、DS4_LT=0 を指定すると同じ実行が完了すると報告しています。GPU1 がアイドル状態になり、GPU0 が処理を進める様子が確認されました。(リンク: Gazelle221B)

mw00 氏は、この修正が v1.1.22 に含まれてリリースされたことを確認しています。

サブエージェントのコンテキスト再読み込み回避

DeepSeek Harness を使用して、メインエージェントが複数のサブエージェントにタスクを振り分ける場合、エンジンが各エージェントのコンテキストを毎回再読み込みしていました。これにより、トークン生成の 70% の時間がプロンプトの再読み込みに費やされ、メインエージェントのターンが戻るたびに約 54 秒の遅延が発生していました。

PR #356 では、会話の切り替えや再起動時にプロンプトを再読み込みしないよう、DeepSeek エンジンに会話の状態を保存・再利用する仕組みを導入する変更が提案されています。これにより、最初のトークンの生成速度が最大 7 倍高速化されました。

この機能は、メインエージェントと 4 つのサブエージェントが交互に処理を行う環境で、12 回のリクエスト中 0 回だったキャッシュ再利用が有効になり、再読み込み時間を大幅に削減しました。

詳細: PR #356 / Issue #375

利用者の報告

talisp 氏は、DeepSeek-V4.1-Flash を Maya で DeepSeek Harness 使用時に、メインエージェントと 4 つのサブエージェントが交互に処理を行う環境で、修正前では 12 回のリクエスト中キャッシュが 0 回再利用されていたのが、修正後はキャッシュが有効になり、再読み込み時間が大幅に削減されたことを報告しています。

precisionailabsllc-collab 氏は、Strix Halo (Ryzen AI Max+ 395, gfx1151) 環境でテストを行い、キャッシュ機能が正常に動作することを確認しました。ただし、サーバー経由で使用する場合は、エンコーダーの設定追加が必要な場合があるとしています。

mgabor3141 氏は、本番環境での使用を報告し、リトライ時にスロットの回答が欠落するなどの課題があるものの、小さなパッチでスロットのチェックポイント復帰を修復し、テストで約 99% の再利用率を達成したと報告しています。

推論速度の向上と VRAM節約

今回のアップデートでは、推論速度の向上と VRAM の節約を目的とした複数の最適化が行われました。

まず、CPU のコア割り当てを最適化し、デコード処理のスレッドがコアの待ち時間を削減しました。これにより、デコード速度が 42.4 tok/s から 68.5 tok/s に向上しました。また、Expert Lending 最適化により、28,432 トークンの処理で 7-9% の高速化が実現しました。

VRAM節約のため、128 GB PC 向けに「Maya-XS」が導入されました。これは、DeepSeek-V4.1-Flash の全モデルを 120.6 GB のメモリに収め、各レイヤーのエキスパートを約 1.6 ビット (IQ1_S) で量子化し、エラーフィードバック付きで層ごとに量子化モデルから補正するものです。これにより、128 GB Ryzen AI Max 環境ですべてのエキスパートを GPU メモリに配置することが可能になりました。

また、GGUF 量子化の拡張として、IQ1_S と IQ2_XS がサポートされました。これにより、VRAM の節約が可能になり、特に IQ1_S はゲート/アップ層で、IQ2_XS はダウン層で適用されることで、推論速度と精度のバランスを保ちます。

詳細: PR #360 / PR #357 / v1.1.22 リリース

利用者の報告

PR #360 のコメントでは、OscarSheng 氏は、v1.1.21 に PR 1 などを加えた構成で、28,432 トークンの処理がデフォルト設定で 3,276-3,366 tok/s となり、別途 v1.1.19 では同最適化の無効時と有効時で 28K トークンの処理が 2,234 tok/s から 2,345 tok/s に向上したと報告しています。また、同じプロンプトで同じトークン ID が生成されることを確認しています。(リンク: OscarSheng)

OscarSheng 氏は、CPU のコア割り当て最適化により、デコード速度が 42.4 / 41.6 tok/s から 68.6 / 68.5 tok/s に向上したと報告しています。Windows 環境でのみ測定されており、Linux ではデフォルトが 0 の場合、SMT 有効環境では 16 スレッドの方が 10% 高速になる可能性があるとしています。

mgabor3141 氏は、Linux (SMT 有効、1950X, 16C/32T) 環境で、16 スレッドがデフォルトの 14 より 10% 高速であると報告しています。また、設定の `env` が `STRATA_DS4_LANE_FREE` として渡されるため、`MAYA_DS4_LANE_FREE` が見えない場合があるとしています。

Issue #394 での 4x RTX 3090 環境のクロック固定によるデコード速度改善報告

4 枚の RTX 3090 を使用して DeepSeek-V4.1-Flash を動かす際、アイドル状態での GPU クロック低下により、デコード速度が半減する問題が報告されていました。これは、レイヤースプリット時に各 GPU が短時間だけ処理し、その後待機するため、ドライバーがクロックを低く保つためです。

Issue #394 では、v1.1.20 のサーバー経由で、クロックを固定するとデコード速度が向上したと報告されています。これにより、デコード速度が 23.2 tok/s から 44.2 tok/s に向上しました。

この修正は、4 枚の RTX 3090 (PCIe 3.0 x8/x16/x8/x16, 300 W cap) を搭載した環境で確認されています。クロックを固定することで、GPU の処理速度が安定し、デコード速度が向上しました。

詳細: Issue #394

利用者の報告

mgabor3141 氏は、4 枚の RTX 3090 (PCIe 3.0 x8/x16/x8/x16, 300 W cap) を搭載した環境で、アイドル状態でのクロック低下によりデコード速度が 23.2 tok/s だったのが、クロックを固定することで 44.2 tok/s に向上したと報告しています。また、26K プロンプト後のデコードでも 7.8 tok/s から 16.5 tok/s に向上しました。

長文コンテキストの修正

v1.1.22 で導入された機能により、32,768 トークン超のコンテキストで AMD GPU や NVIDIA RTX 20 シリーズでエラーが発生する問題が報告されていました。これは、長文コンテキストの top-k バッファサイズが各 GPU の共有メモリから適切にサイズ設定されていないためです。

v1.1.23 では、この問題を解決するため、長文コンテキストの top-k バッファサイズを各 GPU の共有メモリからサイズ設定するよう修正されました。これにより、32,768 トークン超のコンテキストでも正常に処理が完了するようになりました。

この修正は、AMD GPU (Strix Halo, Radeon) と NVIDIA RTX 20 シリーズで確認されています。NVIDIA V100、RTX 30 以降は影響を受けていませんでした。

詳細: v1.1.23 リリース

GLM: プロンプト読み込み中のデコード並列化（インターリーブ）

通常、複数の会話を並行して処理する際、新しい長いプロンプトを読み込むと、他の会話が生成（デコード）を一時停止して待機する必要があります。この新機能は、プロンプト読み込み中でも他の会話が生成を継続できる仕組みです。

具体的には、プロンプト読み込みを複数のチャンクに分けて行い、その合間に他の会話の生成を挟む「インターリーブ」や、読み込みの待ち時間に生成を許可する「ギャップ」の2つのオプションが追加されました。これにより、長いプロンプトの処理中でもシステム全体の応答性が維持されます。

複数のユーザーと同時に対話する環境や、長いコンテキストを扱う際に、待ち時間を感じにくくなります。

根拠: PR #386: GLM several conversations: decode during a prompt read, opt-in (PREFILL_INTERLEAVE, _GAPS)

Maya-XS: 2GPU環境での初回プロンプトハング（#303関連）

2枚のNVIDIA GPUを使用してモデルを分割して動かす際、Maya-XS量子化モデルで初回のプロンプト入力時にシステムが固まる不具合が発生していました。これは既存の修正が適用されていなかったことが原因です。

開発者により、この不具合は既存の修正（fix-303）がリリース版に反映されていなかったことが判明し、v1.1.23ベースの修正ブランチで対応が進められています。この修正により、GPU間のバッファ処理が適切に行われ、ハングが発生しなくなります。

2枚のGPUを使って高速推論を行いたいユーザーにとって、安定して推論を開始できるようになります。

根拠: Issue #384: Maya-XS hangs on the first prompt on two GPUs

利用者の報告

xiongqiyang 氏は、Windows 10環境（2x RTX 3080, CUDA 13.2）で、Maya-XS (IQ1_S) を2枚のGPUで動かした際、初回プロンプト入力時にGPU 1が100%使用率で応答停止し、GPU 0は0%のまま固まる現象を報告しました。同じ環境でMaya-S (MXFP4) は正常に動作したため、Maya-XS固有、あるいは特定量子化のパスに問題があることが示唆されました。

開発者 mw00 氏は、この報告が既存の修正漏れ（fix-303）を特定するものだと確認し、修正ブランチ（fix-384）へのテストを依頼しています。

AMD GPU: HIPビルドでのLDS超過によるデコード失敗の修正

AMD GPU（HIPビルド）において、長いプロンプト処理後のデコード時に、GPUの共有メモリ（LDS）の容量制限を超え、推論が失敗する不具合がありました。

具体的には、gfx1201アーキテクチャにおいて、top-kマージ処理に必要なメモリが64 KiBの制限を超えていたため、`HSA_STATUS_ERROR_INVALID_ALLOCATION` エラーが発生していました。この修正により、メモリ使用量が制限内に収まり、長いコンテキストでも正常にデコードできるようになります。

AMD GPUユーザーが、長いプロンプトを含む会話でも安定して推論を行えるようになります。

根拠: PR #374: ds4: keep the HIP top-k merge within 64 KiB LDS (fixes long-context decode on AMD)

利用者の報告

Gazelle221B 氏は、2x 32 GB AMD GPU (HIP, gfx1201) 環境で、長いプロンプト（32K, 64K, 120Kトークン）後のデコードが失敗する現象を報告し、修正パッチにより400トークンの継続生成が成功したことを確認しています。

開発者 mw00 氏は、PR #374 が扱うクラッシュはv1.1.23で修正済みのものと同じだと確認し、対応済みとしてPRをクローズしています。(リンク: mw00)

Tensor Parallel: 複数GPU構成でのゲート値共有不具合の修正

テンソル並列処理（TP）構成で、複数のGPUを使用してモデルを動かす際、2枚目以降のGPUが正しくないゲート値を使用して計算を行っていた不具合がありました。

この不具合により、出力は一見正常に見えても、論理値（logits）に誤差が生じていました。修正により、各GPUが自身のゲート値をRAMコピーから適切に読み込むようになり、推論の正確性が保証されます。

複数GPU構成で高精度な推論を行いたいユーザーにとって、出力の信頼性が向上します。

根拠: PR #377: ds4: flow - a TP member stages its own gate/up rows from a RAM copy

利用者の報告

NenadSteric 氏は、TP構成で発生するこの不具合の詳細な原因分析と、修正パッチによる解決を確認する報告を行っています。

Windows環境: Engramの非バッファリング読み込みと高精度タイマー最適化

Windows環境において、Engramデータの読み込み速度向上と、タイマー分解能の向上により、推論速度が改善されました。

Engramデータの読み込みにおいて、バッファリングを無効化することで、複数スレッドからの読み込み競合を減らし、プロンプト処理速度を約2〜5%向上させました。また、Windowsのタイマー分解能を1msに高めることで、アイドル時間中の待機処理を最適化し、デコード速度を最大約68.5 tok/sまで改善しました。

Windowsユーザーが、より高速なプロンプト処理とデコード速度を実現できるようになります。

根拠: PR #362: DeepSeek on Windows: Engram rows read unbuffered from their unmapped file, PR #358: DeepSeek on Windows: 1 ms timer resolution

利用者の報告

OscarSheng 氏は、Windows環境でEngramの非バッファリング読み込みを有効化した際、プロンプト処理速度が約2〜5%向上したことを報告しています。

2x RTX 4090 + 188GB RAM: DeepSeek-V4.1-Flash Maya-XSの速度レポート

大規模なRAM（188GB）と2枚のRTX 4090を搭載した環境での、DeepSeek-V4.1-Flash（Maya-XS量子化）の推論速度レポートです。

この環境では、デコード速度が約21.5 tok/s、プリフィル（プロンプト処理）速度が8Kトークンで約573 tok/sという結果でした。また、GLM DFlash2とMTP（Multi-Token Prediction）の比較も行われています。

大規模なリソースを活用して高速推論を行いたいユーザーの参考になります。

根拠: Issue #393: Speed report: DeepSeek-V4.1-Flash Maya-XS on 2x RTX 4090 + 188 GB RAM

利用者の報告

fuad00 氏は、2x RTX 4090, 188GB RAM, Ubuntu 24.04環境で、DeepSeek-V4.1-Flash (Maya-XS) を動かしたベンチマーク結果を報告しています。デコード速度は21.5 tok/s、プリフィル速度は8Kトークンで573 tok/sでした。

GLM: プロンプト読み込みのチャンク分割によるパイプライン最適化

単一チャンクで読み込まれるプロンプトを複数の小さなチャンクに分割し、GPU間でパイプライン処理を行う仕組みです。これにより、従来は各GPUがプロンプト処理の完了まで待機していたアイドル時間を削減し、並列処理効率を向上させます。

環境変数 MAYA_GLM_PREFILL_MIN_CHUNKS を使用して、プロンプトを分割する最小チャンク数（1〜8）と最小トークン数（デフォルト512）を指定できます。これにより、複数のGPUがプロンプト処理を分担し、デコード処理と並行して実行できるようになります。ただし、GPUが1枚の場合や読み込みデータが極端に短い場合はこの最適化は適用されません。

複数のGPUでGLMを動かしている場合、プロンプト処理時間の短縮により全体のスループットが改善されます。

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

GLM: バッチデコードにおけるDSAアテンションの統合ランチャー

バッチデコード処理において、複数の行（リクエスト）にまたがるDSA（Dense Sparse Attention）アテンション計算を、1つのGPUカーネル呼び出し（ランチャー）に統合する最適化です。

環境変数 MAYA_GLM_ROWS_ATTN=1 を有効にすると、バッチ内の全行のアテンション計算、クエリ/出力射影、インデクサー選択を1つのランチャーで実行します。これにより、従来は行ごとにカーネルを呼び出していた際のGPUリソースの未使用状態を減らし、大規模GPUカードの処理効率を向上させます。出力はビットレベルで同一性が保証されています。

バッチデコード処理を行う環境において、GPUの計算リソースをより効率的に使用できるようになり、処理速度の改善が期待できます。

根拠: GLM batched decode: the rows' DSA attention, selections, scores and KV resolves in one launch, opt-in (MAYA_GLM_ROWS_ATTN, MAYA_GLM_ROWS_SMALL)

GLM: CPUレーンとデコード/ティアスレッドの共有状態に関するドキュメント更新

GLMのCPUレーン（スレッド）が、エンジン全体のCPUリソースをデコード処理やティア（階層）処理のスレッドと共有している状態について、その影響とチューニング指針を文書化したものです。

デフォルトの設定では、SMT（スレッドデュプレックス）を無効化したホストで全てのCPUコアを使用する場合のみ、コアの約3分の1が空き状態となります。一方、taskset やコンテナのcpusetでCPUリソースを制限している場合、CPUレーンは利用可能なコアをすべて占有しようとし、デコード処理がタイムスライスの割り当てを待つ事態を引き起こす可能性があります。このドキュメントは、リソース競合を避けるための設定指針を提供します。

CPUリソースを制限してGLMを実行しているユーザーは、デコード処理の待機時間を減らすために、CPUレーンへのリソース割り当てを適切に調整する必要があります。

根拠: docs: GLM's CPU lane shares the engine's CPUs with the decode and tier threads - give it enough of them

GLM: エキスパートのメモリ使用量とプール尾部の分散制御

RAM上に保持されるエキスパート（MoE層の重み）の管理において、使用頻度のカウントメモリと、プール尾部（unused領域）の割り当て方法を最適化する仕組みです。

以下の環境変数により制御できます：
- MAYA_GLM_COUNT_HALF: 使用頻度カウントの減衰期間を指定（デフォルトは約30秒）
- MAYA_GLM_PROMPT_COUNTS: プロンプト読み込み時のカウント加重を指定（0-1）
- MAYA_GLM_LEND_SPREAD: 1に設定すると、プール尾部の領域を層全体に分散して割り当て

これにより、RAM上のエキスパート管理におけるメモリ使用の効率化と、頻繁な読み書きの削減が図れます。

根拠: GLM expert tiers: the count memory, a prompt's weight in it, and the pool's tail spread across the layers, opt-in (MAYA_GLM_COUNT_HALF, MAYA_GLM_PROMPT_COUNTS, MAYA_GLM_LEND_SPREAD)

GLM: EXL3エキスパートのテンソルコアパスによるプロンプト処理

EXL3形式のエキスパートパックにおけるプロンプト処理時、チャンクの長さとトークン数に応じて、最適な演算パス（テンソルコアカーネルまたはcuBLAS）を切り替える仕組みです。

環境変数 MAYA_GLM_EXL3_MMA_ROWS_SHORT を使用して、テンソルコアカーネルを使用する行の上限とチャンク長の上限（最大4096トークン）を指定できます。短いチャンクではテンソルコアカーネルが効率的であり、長いチャンクではFP16演算が効率的になるため、この切り替えにより処理時間を最適化します。

EXL3形式のモデルを使用し、プロンプト処理がボトルネックになっている環境において、チャンク長に応じた最適化により処理速度が改善されます。

根拠: GLM prompt: EXL3 experts' tensor-core path by chunk length, opt-in (MAYA_GLM_EXL3_MMA_ROWS_SHORT)

GLM: システムプロンプト状態の保持による新規会話の高速復元

並列処理（--parallel > 1）時に、システムプロンプトの状態をスロットに保持し、新規会話の開始時にその状態を高速に復元する仕組みです。

従来は、システムプロンプトとツール設定が同じ新規会話でも、トークン0から読み込み直す必要がありましたが、この変更により状態が保持されます。復元時間は約0.1秒と非常に高速です。この機能はスロットが有効な場合にデフォルトで有効になり、MAYA_GLM_PREFIX_CUT=0 で無効化できます。

複数の会話を並列処理するユーザーは、新規会話の開始時間を大幅に短縮できます。

根拠: GLM several conversations: keep the system prompt's state in a slot, so new conversations restore it

GLM: バッチデコードステップでのMTPドラフティング有効化

GLMモデルの推論では、複数のリクエストを並行して実行する際、 speculative decode（MTPドラフティング）の効率を最適化する仕組みがあります。

従来、並列実行時にリクエストが増えるとドラフティングが停止していましたが、新オプションによりバッチ処理でもドラフティングを維持できるようになりました。これにより、複数リクエスト実行時の推論効率が改善します。

詳細は公式PRをご参照ください：PR #385

DeepSeek: 固定Engramと厳格なCPUエキスパートRAM常駐オプション

DeepSeekモデルのメモリ配置を固定し、CPUエキスパートのRAM常駐を厳格に制御するオプションが追加されました。

これにより、メモリ配置の安定性が向上します。

詳細は公式PRをご参照ください：PR #368

NVIDIA GPU: DS4プロンプトスパースアテンションのTensor Core対応

NVIDIA GPU（sm_80以降）において、DeepSeekのスパースアテンション処理がTensor Core（BF16）に対応しました。これにより、長文プロンプトの処理速度が向上します。

従来、NVIDIA環境ではスパースアテンションがスカラー演算で実行されていましたが、行列積ユニットを活用した高速化が図られました。

詳細は公式PRをご参照ください：PR #369

利用者の報告

jinsoojinsoo さんは、RTX 3090 2枚構成の環境で検証を行い、スパースアテンション処理の高速化を確認しています。同氏は、PR #369 のコメントで、RTX 3090 2枚構成で`DS4_PROF=1`を設定した場合、スパースアテンション処理が長文プロンプトのGPU処理時間の40〜45%を占めていたと報告しています。PR #369

RDNA4 (gfx12) GPU: スパースアテンションのWMMAカーネル対応

AMD RDNA4（gfx12）GPUにおいて、スパースアテンション処理がWMMAカーネルに対応しました。これにより、RDNA4環境でのプロンプト処理速度が向上します。

従来、RDNA4環境ではスパースアテンションがスカラー演算で実行されていましたが、行列積ユニットを活用した高速化が図られました。

詳細は公式PRをご参照ください：PR #370

利用者の報告

Gazelle221B さんは、AMD Ryzen AI Developer Platform 1（gfx1201）の環境で検証を行い、WMMAカーネル対応によるプロンプト処理速度の向上を確認しています。同氏は、WMMAカーネル启用により、スカラー演算と比較して処理速度が改善したことを報告しています。PR #370

Strix Halo環境: Strataエンジン依存によるninjaビルド失敗の修正

AMD Strix Halo（Ryzen AI Max+ 395）環境において、Strataエンジンの依存関係修正により、ninjaビルドが正常に完了するようになりました。

従来、Strix Halo環境では、Strataエンジンのビルド時に依存関係の問題によりビルドが失敗していましたが、修正により正常にビルドできるようになりました。

詳細は公式Issueをご参照ください：Issue #355

利用者の報告

precisionailabsllc-collab さんは、Strix Halo環境でのビルド失敗を報告し、mw00 による修正が適用されたことを確認しています。同氏は、修正により正常にビルドが完了し、Maya-Sパックが動作することを確認しています。Issue #355

Windows環境: DeepSeek用Enグラムリーダーの並列数最適化

Windows環境において、DeepSeek用Enグラムリーダーのデフォルトスレッド数が64に引き上げられました。これにより、プロンプト読み込み速度が21〜27%向上します。

従来、Windows環境ではEnグラムリーダーのスレッド数が10に設定されていましたが、64に引き上げることで、プロンプト読み込みの並列処理が最適化されました。

詳細は公式PRをご参照ください：PR #361

利用者の報告

OscarSheng さんは、Windows環境での検証を行い、Enグラムリーダーのスレッド数を64に引き上げることで、プロンプト読み込み速度が21〜27%向上したことを報告しています。同氏は、28Kトークンのプロンプトにおいて、スレッド数10の場合と比較して、スレッド数64で処理速度が向上したことを確認しています。PR #361

DS4: 量子化精度の統一とサーバー用プロファイリング機能の追加

プロジェクト Maya の推論エンジン DS4 では、AMD GPU 環境における hipBLASLt の設定管理や GEMV 演算の量子化処理、およびサーバーモードでのプロファイリング出力に関する改善が行われました。

まず、環境変数 MAYA_DS4_LT_STORE が導入されました。これにより、hipBLASLt が計測した最適設定（picks）の保存場所を、パッケージ内のファイル、任意のファイル、または保存しない（起動ごとに再計測）のいずれかに指定できます。デフォルトは従来通りパッケージ内のファイルへの保存ですが、この設定を空のファイルパスにすることで、各起動ごとに独立した計測が行えるようになります。また、v1.1.22 で導入されたデバイスごとのロック機構により、保存先を空にした場合でも、2 枚の GPU を使用した際のハングアップリスクは解消されています https://github.com/mw00/project-maya/pull/381。

次に、量子化精度の安定化のため、MAYA_DS4_Q8_BATCH=1 が追加されました。通常、デコード処理では各 GEMV 呼び出しごとに個別に量子化が行われますが、このオプションを有効にすると、呼び出し内のすべてのジョブを一度のカーネル実行で量子化します。これにより、同じジョブの行が同じアルゴリズムで処理され、int8 の値、スケール、および演算結果がビット単位で完全に一致するようになります。これにより、再現性が向上します https://github.com/mw00/project-maya/pull/382。

さらに、サーバーモード（serve ループ）でもプロファイリング情報が出力されるようになりました。従来は CLI 実行時のみ出力されていた DS4_PROF の詳細なステージ別時間（レイヤー間、アテンション、ルーティング、CPU 待機時間など）が、サーバー経由でリクエストが処理される際にも、各リクエストごとに 1 行ずつ出力されるようになりました。これにより、サーバー環境下でのボトルネック特定が可能になります https://github.com/mw00/project-maya/pull/380。

利用者の報告

pepuscz により、MAYA_DS4_LT_STORE に新しい空のファイルパスを設定して検証が行われました。その結果、各起動で 2K プロンプトの GEMM 形状が計測され、それぞれ 25 行の整形式なデータが個別のファイルに書き出されました。また、2 回の起動で生成されたファイルの内容はバイト単位で同一であり、パッケージ内の lt-picks.txt は作成されないことが確認されました https://github.com/mw00/project-maya/pull/381。

DS4: 量子化精度の統一とサーバー用プロファイリング機能の追加 の項目一覧

• #382 ds4: MAYA_DS4_Q8_BATCH - batch GEMV input quantization bit-exactly (PR・2026-10-22)

コミュニティ要望: Maya-Sの低リスク量子化モデルとPrefill/Decode分離機能

プロジェクトの GitHub Issues では、より低コストな環境での利用を想定した量子化モデルの要望や、推論アーキテクチャの高度化に関する問い合わせが寄せられています。

まず、sk-surya により、Maya-S / S24 サイズ（96.5 GB / 94.7 GB）の「derisked quant（低リスク量子化）」モデルの追加が要望されました。これは、特定のハードウェア制約下でも安定して動作するための量子化形式を求めるものです https://github.com/mw00/project-maya/issues/383。

また、別のユーザー により、DeepInfer などのプロジェクトで採用されている Prefill/Decode 分離（disaggregation）機能のサポートについて問い合わせがなされました。これは、生成の初期処理（Prefill）と逐次生成処理（Decode）を分離することで、スループットやレイテンシを最適化するアーキテクチャに関するものです https://github.com/mw00/project-maya/issues/378。

利用者の報告

@llm_frontier_jp により、V100 32GB 1枚および2枚構成での実測報告がなされました。大容量 MoE モデルである deepseek v4.1 flash が、メモリ 35 万円の PC（V100 1枚）で実行可能であることが確認されました。これは、従来の 256GB メモリ搭載 Mac や DGX Spark 2台構成といった高額な環境ではなく、個人でも手が届く範囲で動作した点で注目されています。また、V100 2枚構成では glm 5.3 flash と同等の速度が出れば、実用性がさらに高まるとの見解が示されています 。

テストスイート: NaN/Infによる期待値比較の誤判定修正

テストスイート ds4_gguf_test において、数値の異常値（NaN や Inf）がテスト結果の誤判定を引き起こしていた問題が修正されました。

従来、expect() 関数は、期待値（want）や実際の値（got）に NaN や Inf が含まれている場合、スケールの最大値が崩れたり、無限大になったりする可能性があり、結果として誤って「ok」と判定されるケースがありました。今回の修正では、スケール計算やエラー削減の前に、値が有限数（finite）であることを確認するチェックが追加されました。非有限な値が含まれている場合は、そのインデックスと両方の値を出力してテストを失敗させます。これにより、テストの信頼性が向上しました https://github.com/mw00/project-maya/pull/379。

出典

• Project Maya v1.1.22
• Project Maya v1.1.23
• PR #367: hip: keep Lt tuning locks local to each device (fixes a 2-GPU hang)
• Issue #366: HIP: DeepSeek hangs on the first long prompt on a 2-GPU split with hipBLASLt on (v1.1.21)
• PR #356: DeepSeek: cache conversations across switches and restarts, so sub-agents don't re-read prompts (first token up to 7x faster)
• Issue #375: DS4: keep a few conversation states, so agents with sub-agents stop re-reading their prompts
• PR #360: DeepSeek prompts: keep the expert copies going while the host waits for the routing (+7-9% on 28K tokens here)
• PR #357: DeepSeek GGUF: IQ1_S and IQ2_XS experts (unsloth's UD-IQ2_XXS packs and runs)
• PR #359: DeepSeek: leave two cores free beside the CPU lane (decode 42 -> 68.5 tok/s here)
• Issue #394: DeepSeek Maya-S on 4x RTX 3090: idle GPU clocks halve decode, and slots that survive retries and re-rendered turns