【Project Maya】Project Maya v1.1.20：停止処理の改善、Strix HaloでのDeepSeek高速化、Windows起動の修正

今回の要点

• Project Maya v1.1.20がリリース：Windowsの起動不具合修正、ダッシュボードでのポート変更機能、Strix Halo / Windows APUでのDeepSeekのGPUメモリ使用量の自動調整
• AMD環境向けにDeepSeek-V4.1の最適化PR：int8 MMQおよびhipBLASLtによる推論速度改善案が提出中。
• 9GPU構成でのDeepSeek-V4.1ベンチマーク：Tensor Parallel（--tp 8）でプロンプト読み込みが約1.9倍、回答生成が約1.55倍高速化。
• v1.1.20におけるサーバーの改善：クライアントが切断したリクエストの即時キュー離脱
• v1.1.18のDeepSeekのPCIeレーン：実測コストに応じたGPUへのエキスパート転送とMAYA_DS4_STREAM=0による無効化

Project Maya v1.1.20 リリースと主要修正

Project Maya v1.1.20がリリースされました。今回のアップデートでは、DeepSeek-V4.1-Flashの高速化やWindows環境での安定性向上などが行われています。

何が変わったか

• ストッピング機能の改善：長いプロンプト読み込み中でも「Stop」を押すと即座に停止し、それまでの会話履歴が保持されるようになりました。
• DeepSeek-V4.1の高速化：Strix Halo環境において、DSpark drafterを有効化することで約6.5%トークン/secが向上。
• Windows APUでのGPUメモリ最適化：WindowsのHIP環境において、APUのGPUメモリとシステム共有メモリを区別し、モデルを専用メモリ内に収めるように変更。
• Windowsセットアップ画面の修正：v1.1.18以降発生していた、セットアップ画面が表示されても処理が進まない不具合が修正。
• ダッシュボードのポート変更：Settings > Portからポート番号を変更可能に。

なぜ重要か

Windowsユーザーにとってセットアップ画面の修正は大きな安心材料です。また、Strix Halo（APU）ユーザーは、これまでVRAM不足を解消するために必要だった--vram-expertsフラグなしで、フルスピードでモデルを実行できるようになります。

根拠のリンク

• Project Maya v1.1.20
• #337 Stop during long prompts, the Halo's GPU memory, Settings > Port, EXL3 on V100 and AMD

AMD環境向けDeepSeek-V4.1のint8 MMQおよびhipBLASLt最適化PR

AMD GPU（HIPビルド）向けに、DeepSeek-V4.1の推論速度を改善する技術的最適化がPull Requestとして提出されています。

何が変わったか

• int8 MMQ（Mixed Matrix Quantization）：MAYA_DS4_EXPERT_MMQ=1を有効にすることで、专家の活性化をq8_1に丸め、int8行列コアで計算を実行。
• hipBLASLtによるGEMM最適化：MAYA_DS4_DENSE_LT=1を有効にすることで、hipBLASLtがヒューリスティックな候補を評価し、最も高速なカーネルを選択。

なぜ重要か

AMD GPUユーザーにとって、DeepSeek-V4.1の推論速度が大幅に向上する可能性があります。ただし、これらの機能はデフォルトで無効になっており、環境変数を明示的に設定する必要があります。

根拠のリンク

• #354 DeepSeek: int8 MMQ for routed prompt experts on AMD (opt-in)
• #353 DeepSeek: hipBLASLt solution table for dense prompt GEMMs (AMD, opt-in)

DeepSeek-V4.1 9GPU Tensor Parallel性能報告：プロンプト1.9倍高速化

9枚のGPUを使用したTensor Parallel構成において、DeepSeek-V4.1の推論速度が大幅に向上するベンチマーク結果が報告されています。

何が変わったか

• プロンプト読み込み（prefill）：--tp 8（3.5ビット量子化）で、メインブランチ比で約1.9倍高速化。
• 回答生成（decode）：約1.55倍高速化。
• パープレキシティ：変更なし（品質維持）。

なぜ重要か

大規模なマルチGPU構成（9枚）でも、DeepSeek-V4.1の推論速度が大幅に向上します。特にプロンプト読み込みの高速化は、長いコンテキストを扱う際に体感速度として大きく寄与します。

根拠のリンク

• #344 DeepSeek-V4.1 tensor parallel on 9 GPUs: prompts ~1.9x and answers ~1.55x faster at --tp 8 than main, the same perplexity (all-reduces off the SMs, the prompt skip on several GPUs, the expert cache's recent slots); ./maya.sh --calibrate tunes --tp

利用者の報告

@needmorevram により、9枚のGPU（PCIe 3.0 x8、2 NUMAノード）を使用した環境で、LibertAIDAIの3.5ビットEXL3量子化モデルを用いてベンチマークが実行されました。その結果、--tp 8 --prefill-chunk 2048の設定で、prefillが約1.9倍、decodeが約1.55倍高速化し、パープレキシティは同等であることが確認されています。

一方、@mw00 からは、AMD（HIP）環境およびVoltaアーキテクチャにおいて、ビルドエラーや単一GPUでのデコード速度低下（-13%〜-19%）が発生する可能性が指摘されています。これらの問題は開発側で修正中とのことです。

v1.1.20におけるサーバーのコンテキスト超過エラー発生不具合

v1.1.20において、約68リクエストを処理した後に、再起動するまですべてのリクエストにコンテキスト超過エラーを返す不具合が報告されています。

何が変わったか

• エラー内容：約68リクエスト後に、すべてのリクエストに対して「prompt (...) + max tokens (...) exceeds the context (0)」というエラーが返される。
• 環境：4x RTX 3090、GLM-5.3-Flash Maya-S24（IQ2_XXS、3 shards）、--max-context 131072、CUDA 12.8、Linux。

なぜ重要か

サーバーとして長期間運用する場合、この不具合によりサービスが停止する可能性があります。現在、原因の調査と修正が行われています。

根拠のリンク

• #351 After ~68 requests the server answers 'exceeds the context (0)' to every request, until restarted (v1.1.20, 4x3090)

利用者の報告

@jorgermp により、4x RTX 3090環境で164のHumanEval+サンプルを逐次生成するテストが行われました。最初の68リクエストは正常に処理されましたが、69リクエスト目以降はすべて上記のエラーで失敗しました。クライアントの切断や並行リクエストは発生しておらず、一貫して再現しています。

DS4: 2x4090 環境での PCIe ラーン誤認識によるデコード遅延

v1.1.18/19の2x4090環境では、PCIeレーンが起動時にCPUレーンの処理時間を過小評価してデコード速度が低下する問題が報告され、v1.1.20のWindows上のRX 7900 XTX環境でも同様の速度低下が報告されています。

何が変わったか

• 速度低下：2x4090環境で、v1.1.17の約32-38 tok/sから、v1.1.18/19で約27-34 tok/sに低下。
• 原因：起動時のPCIeレーン推定が正しく行われず、デコード時にCPUレーンの速度が過小評価される。
• 回避策：MAYA_DS4_STREAM=0を設定することで、速度低下を回避可能。

なぜ重要か

マルチGPU構成（特に2x4090）やAMD GPUユーザーにとって、デコード速度が大幅に低下する可能性があります。環境変数を設定することで、速度を回復できます。

根拠のリンク

• #329 DS4: v1.1.18 PCIe lane mis-estimates the CPU lane on 2x4090, slowing decode (MAYA_DS4_STREAM=0 fixes it)

利用者の報告

@bluewowo により、2x4090 48G環境で、v1.1.17の約32-38 tok/sからv1.1.18/19で約27-34 tok/sに速度が低下することが報告されました。この問題は、v1.1.18で導入されたPCIeレーンが起動時にCPUレーンの処理時間を過小評価することが原因と報告されています。

また、@jerem91150 により、AMD GPU（RX 7900 XTX 24 GB、HIP、gfx1100）環境でも同様の問題が発生することが報告されました。v1.1.20では、v1.1.17の約4.28-4.36 tok/sに対して、v1.1.20は約3.31-3.34 tok/sに低下しましたが、MAYA_DS4_STREAM=0を有効にすることで、約4.43-4.31 tok/sまで回復しました。

AMD HIP環境でのビジョンエンコーダービルドと有効化対応

AMD GPU（HIP環境）でも、ビジョンモデル（画像認識）を使用可能にするためのビルド対応がPull Requestとして提出されています。

何が変わったか

• HIP対応のビジョンビルド：それまでCUDAのみだったmaya-visionのビルドを、HIP環境でも可能に。
• 設定オプション：STRATA_VISION_HIPオプションにより、HIPバックエンドを有効化。

なぜ重要か

AMD GPUユーザーも、ビジョンモデル（画像認識）を使用できるようになります。これにより、テキストだけでなく画像を含むマルチモーダルな推論が可能になります。

根拠のリンク

• #345 HIP: build and enable the vision encoder on AMD GPUs

RTX 2080 Ti (sm_75) でのプロンプト注意機構のレジスタカーネル不具合

Project Maya は、GLM-5.3-Flash モデルの推論において、プロンプト処理時に共有メモリを活用した tensor-core カーネルを実行します。この際、カーネルのサイズ設定が旧世代 GPU の制限を超えると、レジスタカーネルが常に実行されるようになり、出力の整合性や再現性に影響を及ぼす可能性があります。

v1.1.19 において、RTX 2080 Ti (sm_75) 環境では、共有メモリカーネルのサイズが 91,136 バイトに設定されており、Turing アーキテクチャの制限（64 KB）を超えています。このため、`tcreg` が無効化され、レジスタカーネルが強制実行される状態になります。その結果、f32 精度でのテキスト生成が変化し、AVX-512 を持たない CPU 環境では greedy 推論の再現性が失われる問題が報告されています。

この不具合は、旧世代 GPU を複数枚使用しているユーザーにとって、出力結果の不安定さや再現性欠如という形で影響します。特に、NVLink 接続の 2 枚構成など、特定のハードウェア構成で顕著になる傾向があります。

根拠: GitHub Issue #338

利用者の報告

yusheng227507 氏は、2 枚の RTX 2080 Ti (sm_75) を NVLink 接続で使用する環境（CUDA 12.8, Ubuntu 24.04.5, v1.1.19）で、プロンプト注意機構が常にレジスタカーネルを実行し、`tcreg` が no-op になる現象を確認しています。また、AVX-512 を持たない CPU（Intel Core i7-10700K）環境では greedy 推論の再現性が得られないことを報告しています https://github.com/mw00/project-maya/issues/338。

GGUF モデルの --mmap-experts 設定によるデコード速度への影響

Project Maya は、GLM-5.3-Flash のような MoE モデルを GGUF 形式で扱う際、`--mmap-experts` オプションによりエキスパートパラメータの読み込み方法を制御できます。デフォルトの `auto` はファイルから直接読み込む設定ですが、RAM に余裕がある環境では、これを `off` に変更して RAM にコピーすることで、デコード速度の大幅な向上が期待できます。

v1.1.20 での検証によると、RAM にエキスパートデータを保持できる PC 環境では、`--mmap-experts auto`（デフォルト）時のデコード速度が約 5.75 tok/s に対し、`--mmap-experts off`（RAM 読み込み）では 12.11 tok/s と、約 2 倍の速度差が確認されています。プロンプト処理速度も、2,687 トークンで 175 tok/s から 223 tok/s、63,850 トークンで 569 tok/s から 648 tok/s と向上しています。

大容量 RAM を搭載した PC で GGUF モデルを使用するユーザーにとって、`--mmap-experts off` 設定は推論速度を最大化するための重要な調整ポイントとなります。

根拠: GitHub Issue #339

利用者の報告

pietroMastro92 氏は、255 GB RAM を搭載した PC（RTX 4000 Ada Generation, Windows 11）で、DeepSeek GGUF モデル（178.2 GB）を使用する際、`--mmap-experts auto` ではデコード速度が 5.75 tok/s にとどまるのに対し、`--mmap-experts off` に設定することで 12.11 tok/s への速度向上を確認しています。エンジンログでは、`off` 設定時にエキスパートが RAM にコピーされる様子が確認されています https://github.com/mw00/project-maya/issues/339。

続報：--parallel 実行時の共有状態によるタイミング・キャッシュ情報の混線

前回の修正ではキュー処理の改善が行われましたが、`--parallel N` 実行時の並列処理において、リクエスト間のタイミング情報やキャッシュ情報が混線する問題が報告されています。これは、各リクエストの完了情報を共有変数 `StrataEngine.last` に書き込む仕組みに起因しています。

v1.1.17 において、`Service.run` がストリーミング終了後に `StrataEngine.last` を読み取る際、他のリクエストの `DONE` 行が間に挟まると、そのリクエストのタイミング情報（`prompt_ms`, `predicted_ms`）やキャッシュトークン数（`cached_tokens`）が混入する可能性があります。この問題は、`/metrics` リクエスト履歴や `/v1/status` の `last_timings` にも影響します。

並列推論を使用するユーザーにとって、メトリクス情報の正確性が損なわれる問題となります。

根拠: GitHub Issue #310

GLM: マルチ会話スケジューラのdrain失敗とSTOP修正

Project Maya の GLM マルチ会話スケジューラ（`--parallel` > 1）において、リクエストの受付時に drain 処理が失敗した場合、新しいリクエストに ERR 応答が送られない問題と、無効な ID を持つ STOP/PAUSE 行がすべてのリクエストを停止させる問題が修正されました。

修正前、drain 失敗時に新しいリクエストのクライアントは DONE や ERR を待機する状態が続いていました。修正により、同じ ERR 応答が送られるようになりました。また、無効な ID（-1 など）を持つ STOP/PAUSE 行が、現在受付中のリクエスト ID と比較されず、すべての実行中リクエストを停止させるバグも修正されました。これにより、エンジン stdin プロトコルの堅牢性が向上しています。

マルチ会話環境で並列処理を使用するユーザーにとって、リクエストのタイムアウトや予期せぬ停止が防がれ、処理の信頼性が向上します。

根拠: GitHub PR #323

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

• Thank you @somnergy - merged and released in v1.1.20; we checked that a single conversation's tokens are unchanged.… — mw00

利用者の報告

somnergy 氏は、マルチ会話スケジューラの修正について、drain 失敗時の ERR 応送と無効 ID の STOP 行の無視処理が実装されたことを報告しています。開発者 mw00 氏は、この修正が v1.1.20 にマージされ、単一会話のトークン数が変更されていないことを確認したと返信しています https://github.com/mw00/project-maya/pull/323。

Metal: Apple Silicon での GLM-5.3-Flash 実験的サポート

Project Maya は、macOS（Apple Silicon）での GLM-5.3-Flash 実行を可能にする Metal バックエンドを追加しました。これにより、macOS ユーザーも NVIDIA GPU に限らず、Apple Silicon GPU を活用して推論エンジンを実行できるようになります。

`maya-metal` は、llama.cpp にピン留めされた Metal バックエンド上で ggml グラフとして順伝播を実行し、GGUF ファイルを直接読み込みます。メモリプランは統一メモリに対応し、密集重み、KV キャッシュ、エキスパートパラメータの配置を最適化しています。サーバー、トークナイザー、セットアップは Maya 側で実装され、`--serve` プロトコルを通じて駆動されます。

macOS ユーザーにとって、NVIDIA GPU なしでも GLM-5.3-Flash を実行できる選択肢が広がります。ただし、AMD GPU や Windows 同様に実験的な対応となります。

根拠: GitHub PR #334

DS4: Tesla V100 (Volta) でのコンパイル失敗修正

Project Maya の DeepSeek 用エンジン（maya-ds4）において、Tesla V100 (Volta, Compute Capability 7.0) 環境でビルドが失敗する問題が報告されました。これは、CUDA の組み込み関数 `__bfloat16_as_ushort` が compute capability 7.0 で利用できないことに起因しています。

公式ドキュメントでは Maya-S 量子化形式が Volta (V100) 以降の NVIDIA GPU で実行可能とされていますが、ソースコード内で使用されている一部の関数が旧世代アーキテクチャで未定義でした。この不具合により、V100 環境ではビルドプロセス全体が失敗していました。

Tesla V100 を使用するユーザーにとって、ビルド失敗によりエンジンが使用できない状態となっていました。

根拠: GitHub Issue #336

利用者の報告

judasatan 氏は、2 枚の Tesla V100-SXM2-32GB (Volta) を使用する環境（CUDA 12.0, Ubuntu 24.04, g++ 13.3.0）で、maya-ds4 のビルド時に `__bfloat16_as_ushort` が未定義というエラーによりコンパイルが失敗することを報告しています https://github.com/mw00/project-maya/issues/336。

Server: 詰まったFIFOとリクエストID重複の修正

Project Mayaのサーバーは、複数のリクエストを並行して処理する際、内部の待ち行列（FIFO）とリクエストID（rid）を使用して順序を保っています。この仕組みにおいて、リクエストIDの重複や割り当てミスが発生すると、処理が正しくルーティングされなくなる問題がありました。

この修正により、サーバーが永久にアイドル状態になり、以降のリクエストが一切処理されなくなっていた不具合が解消されました。特に `--parallel` オプションで複数の会話を同時に実行する環境において、サーバーの安定性が向上します。修正はサーバー側の処理のみに関わるもので、推論エンジンやパフォーマンスへの影響はありませんhttps://github.com/mw00/project-maya/pull/330。

利用者の報告

jettoblack は、エンジン再起動時にリクエストIDが重複し、古いリクエストの応答が新しいキューにルーティングされて処理が停止する現象を確認し、この修正がその原因を特定したと報告していますhttps://github.com/mw00/project-maya/pull/330。

Project Maya v1.1.21 リリース：AMD Strix Halo/RDNA3/4向けDeepSeek-V4.1高速化とEXL3改善

v1.1.21 では、AMD GPU（Strix Halo、Radeon RDNA 3/4）における DeepSeek-V4.1 モデルの推論速度が大幅に向上しました。特にプロンプト処理速度は約 2.4 倍高速化され、GPU メモリにエキスパートが収まる層ではデコード速度も向上しています。また、AMD 環境での EXL3 形式モデルの処理速度も約 30% 向上しましたhttps://github.com/mw00/project-maya/releases/tag/v1.1.21。

NVIDIA GPU（V100）でも、より軽量なエキスパートタイルの使用により、プロンプト処理速度が 5〜11% 向上しています。AMD ユーザーは、環境変数 `DS4_LT=0` などで一部機能を無効化することも可能です。

4x Tesla V100-SXM2 32GB: GLM-5.3-Flash (Maya-S) 性能報告

8枚の Tesla V100-SXM2 32GB を搭載した環境でのベンチマーク報告です。GLM-5.3-Flash (Maya-S) を 4枚の GPU で実行した場合、デコード速度は 68.4 tok/s、プリフィル（2K/8K トークン）は 400/549 tok/s を記録しました。3枚以上の GPU を使用すると、すべてのエキスパートが VRAM に収まり（99.6% ヒット）、ディスク読み込みが 0.00 回/tok となり、生成中にディスクにアクセスしなくなりますhttps://github.com/mw00/project-maya/issues/333。

一方で、5枚、6枚、8枚の GPU を使用した場合、4枚の時よりも 12〜18% 低速となりました。これは層の分割が直列処理であり、GPU 数が増えるとトークンあたりの直列境界が増えるためです。また、NVLink の有無が速度に測定可能な影響を与えていないことも確認されています。

利用者の報告

jeremiahlangner は、4x Tesla V100-SXM2 32GB (NVLink 2.0) 環境で Maya 1.1.18 を使用し、4枚の GPU が最適な組み合わせであることを報告していますhttps://github.com/mw00/project-maya/issues/333。

Cass67 は、画像を含む会話スロットの管理改善について報告しています。従来、画像を含むスロットは再利用されず、毎回トークン 0 から読み直されていましたが、画像ハッシュの保存により、同じ画像を含むスロットは再利用されるようになりました。これにより、4x 7900 XT 環境で 225K トークンのセッションにおいて、再読み込み時間が 3分以上かかっていた問題が解消されますhttps://github.com/mw00/project-maya/pull/331。

4×RTX 3090環境でのGLM-5.3-Flash Maya-M/GSQ-RCOベンチマーク比較

4枚の RTX 3090 を搭載した環境での、異なる量子化フォーマットの比較報告です。Maya-S24（デコード 100.8 tok/s）に対し、ネイティブな Maya-M は量子化なしで 43.7 tok/s、MTP 使用で 70.1 tok/s でした。外部の GSQ-RCO 3.0-bit は 41.1 tok/s、3.5-bit は 33.5 tok/s でした。DFlash2 ドラフティングを使用すると、Maya-M で 86.5 tok/s、GSQ-RCO 3.0-bit でも 86.5 tok/s を達成していますhttps://github.com/mw00/project-maya/issues/349。

利用者の報告

Whamp は、4× RTX 3090 環境で Maya v1.1.19 を使用し、Maya-M と GSQ-RCO 量子化の速度を比較報告していますhttps://github.com/mw00/project-maya/issues/349。

GLMモデルのExpert Lending機能：RAM層でのディスク読み込み40%削減

プロンプト処理時に VRAM から RAM へエキスパートが移動する際、最近使用されたエキスパートを RAM 層に残す最適化が導入されました。これにより、新しいプロンプト処理後のディスク読み込み回数が 40% 削減されます。カウントの古さや使用頻度に基づいて、どのエキスパートをディスクに退避させるかが判断されますhttps://github.com/mw00/project-maya/pull/352。

DeepSeek-V4.1ベンチマーク実行時のバイナリ指定不具合修正

HIP 環境（AMD GPU）で DeepSeek-V4.1 設定時に、ベンチマーク実行コマンドが誤って GLM 用バイナリを参照し、`FileNotFoundError` を発生させていた不具合が修正されました。これにより、DeepSeek 設定でも正しく `maya-ds4` バイナリが使用されるようになり、ベンチマークが正常に実行可能になりましたhttps://github.com/mw00/project-maya/pull/350。

利用者の報告

GravLabs は、HIP 環境で DeepSeek-V4.1-Flash-1017 をセットアップし、`./maya.sh --bench` 実行時に `build-hip/maya` が見つからないエラーが発生していたことを報告し、この修正で解決したと確認していますhttps://github.com/mw00/project-maya/pull/350。

AMD HIP環境向けDeepSeek-V4.1 AttentionカーネルのLDSバンク競合低減

AMDのRDNA4世代GPUにおいて、DeepSeek-V4.1のAttentionカーネルがLDS（Local Data Share）にBF16ベクトルを配置する際、行方向のレイアウトが原因でバンク競合が発生し、パフォーマンスが低下するケースがありました。この競合を低減するための最適化が追加されました。

PR #348 では、環境変数 DS4_HIP_ATTN_SWIZZLE=1 を指定することで、ベクトルの配置順序を並べ替える最適化を有効にする変更が提案されています。既存のカーネルはデフォルトのまま変更されず、CUDA側のディスパッチも影響を受けません。これにより、16 KiBのLDS使用量や計算結果、演算順序を変更せずに、Attentionカーネルの性能向上が図られます。

RDNA4環境（例：Radeon AI PRO R9700）において、Attention処理のボトルネックを解消し、推論速度の向上が期待できます。特に、長文プロンプトの処理や、Attention計算が頻繁に発生するワークロードで効果が発揮されます。

詳細は以下のプルリクエストをご参照ください：https://github.com/mw00/project-maya/pull/348

Windows環境でのDeepSeek-V4.1 EXL3形式プロンプト処理速度の低さ

Windows環境において、DeepSeek-V4.1-FlashのEXL3量子化モデルを使用する場合、プロンプト読み込み（prefill）速度がGGUF形式と比べて著しく遅くなる現象が報告されています。これは、EXL3形式のデータ読み込み処理におけるボトルネックが原因と考えられます。

v1.1.20での実測によると、Windows 11環境（RTX 3090 2枚、Threadripper 3990X）において、EXL3形式のプロンプト読み込み速度は約100 t/s（トークン/秒）でした。一方、同じ環境でのMaya-S GGUF形式は約500 t/sを記録しており、EXL3形式はGGUF形式の約4〜5倍の時間がかかっています。これは、プロンプトのチャンキング（8192トークン単位）が機能しているものの、形式自体の読み込み効率に課題があるためです。

WindowsユーザーでEXL3形式を使用している場合、プロンプト処理に非常に時間がかかるため、GGUF形式への切り替えや、環境変数 DS4_FLOW=0 などの調整による改善余地を検討する必要があります。特に、長いプロンプトを扱う場合、この速度差が体感速度に直結します。

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

利用者の報告

ユーザー 21387A は、Windows 11、RTX 3090 2枚、Threadripper 3990X、DDR4-2866、v1.1.20の環境で、--tp 2 --max-context 131072 --dspark none --vision off の設定でベンチマークを行いました。その結果、Maya-S GGUF（--mmap-experts off）は531 t/s、EXL3 2.9は102 t/s、EXL3 3.5は72 t/sとなり、EXL3形式の低速性が確認されました。また、DS4_FLOW=0 を指定するとGGUFでも393 t/sに低下するなど、環境変数の影響も報告されています。

DeepSeek-V4.1の長プロンプトスキップ機能とマルチGPUレイヤースプリットの互換性

v1.1.19で導入された「長プロンプトスキップ」機能は、層20〜39でプロンプトの末尾約2,700トークンにのみ完全な処理を行い、それより前の部分の処理を省くことで、回答を変えずに長いプロンプトの処理を高速化するものですが、トランクが複数のデバイスにまたがる場合は無効でした。マルチGPU構成でレイヤースプリット（層をGPU間で分割）している場合、この機能が自動的に無効化される仕様になっていました。

PR #343 では、2つのGPU間のレイヤー分割がKVソース層以前にあり、そのソース層と後続の全層が同じデバイスにある場合に、長プロンプトスキップを利用できるようにしています。ただし、テンソル並列（Tensor-parallel）や、スキップ対象の領域内部での分割は依然として対象外です。これにより、2枚のGPUで層を分割している環境でも、プロンプト処理の高速化が期待できるようになりました。

2枚以上のGPUでレイヤースプリット構成を組んでいるユーザーにとって、長文プロンプトの処理速度が向上し、推論の待ち時間が短縮されます。ただし、GPU間のデータ転送や、層の分割バランスによっては、効果が変わる可能性があるため、環境に応じた調整が必要です。

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

利用者の報告

PR #343 では、v1.1.19の長プロンプトスキップはトランクが複数のデバイスにまたがる場合に無効になると説明されています。GGUF形式では500 t/s程度出るため、EXL3形式のWindows環境での最適化に課題が残っている可能性があります。

3×V100環境でのGLM-5.3-Flash Maya-S推論性能報告

3枚のV100（32GB）を搭載した環境において、GLM-5.3-FlashのMaya-S量子化モデルを使用した場合の推論性能が報告されています。特に、異なるモデルのV100（Tesla PG500-216とTesla V100-PCIE）を混在させ、レイヤースプリット構成で動作させた場合の性能が注目されます。

v1.1.20でのベンチマーク結果、131072コンテキストでのデコード速度は平均52.9 t/s（52.1 / 51.3 / 55.4）でした。prefill速度は、2048トークンで451 t/s、8192トークンで616 t/sを記録しています。これは、1枚のV100（v1.1.11、RAM経由）での10.8 t/sと比較して、約4.9倍の高速化です。 expertsの約98%をVRAMに保持できていることが、この性能向上の要因となっています。

古いV100を搭載しているユーザーにとって、複数枚のGPUを組み合わせることで、実用的な推論速度が得られることが示されました。特に、RAM経由で動作していた環境からVRAM主体への移行により、大幅な速度改善が期待できます。

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

利用者の報告

ユーザー noahark は、Windows 10、Xeon E5-2696 v3、DDR3L-1600、3枚のV100（2枚のPG500-216と1枚のPCIE）構成で、Maya-S-v2-IQ2_XXSモデルを使用しました。v1.1.20でのベンチマーク結果、デコード速度52.9 t/s、prefill（2048トークン）451 t/s、prefill（8192トークン）616 t/sを報告しています。また、1枚のV100での10.8 t/sと比較して4.9倍の高速化を確認しています。

2GPUレイヤースプリット環境でのDeepSeek-V4.1プロンプトスキップ有効化

v1.1.19までのプロンプトスキップ機能は、すべての層が単一のGPUに存在する場合にのみ有効でした。2枚のGPUでレイヤースプリットしている場合、層が異なるGPUにまたがるため、スキップ機能が無効化されていました。

PR #343 では、KVソース層以前で分割し、ソース層とそれより後ろのすべての層が同一のGPUに存在する場合に、2枚のGPUでのレイヤースプリットでもプロンプトスキップを有効にする変更が示されています。これにより、2枚のGPUで層を分割している環境でも、プロンプトの末尾部分のスキップが可能になり、処理速度の向上が期待できます。ただし、テンソル並列や、スキップ対象の領域内部での分割は依然として対象外です。

2枚以上のGPUでレイヤースプリット構成を組んでいるユーザーにとって、長文プロンプトの処理速度が向上し、推論の待ち時間が短縮されます。特に、層の境界が20層目付近にある場合、スキップ効果が期待できます。

詳細は以下のプルリクエストをご参照ください：https://github.com/mw00/project-maya/pull/343

RX 7900 XTX (gfx1100) でのベンチマーク報告

AMDのRX 7900 XTX（24GB、gfx1100）を搭載したWindows環境において、DeepSeek-V4.1-FlashのMaya-S量子化モデルを使用した場合の性能が報告されています。Issue #342 では、v1.1.20での長プロンプトスキップの効果を確認するベンチマークが報告されています。

v1.1.20でのベンチマーク結果、26Kトークンのプロンプト処理時間は、v1.1.17の約224秒から、デフォルト設定（スキップ有効）で約94秒に短縮されました。これは約2.4倍の高速化です。さらに、環境変数 MAYA_DS4_PROMPT_SKIP=2 を指定すると、約80秒まで短縮されました。4,157トークンのプロンプトでも、v1.1.17の約52秒から、v1.1.20のデフォルト設定（MAYA_DS4_PROMPT_SKIP=1）で約50秒、MAYA_DS4_PROMPT_SKIP=2で約38秒へと短縮されています。

Issue #342 では、Windows 11のRX 7900 XTX環境で、v1.1.20の26Kプロンプト処理がデフォルト設定でv1.1.17の約2.4倍となり、スキップによる速度向上は無効時に対してさらに45%と報告されています。特に、長いプロンプトを扱う場合、スキップ機能の有効化により、推論の待ち時間が大幅に短縮されます。

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

利用者の報告

ユーザー jerem91150 は、Windows 11、RX 7900 XTX 24GB、Ryzen 9 7900X3D、DDR5、NVMe構成で、DeepSeek-V4.1-Flash Maya-Sモデルを使用しました。v1.1.20でのベンチマーク結果、26Kトークンのプロンプト処理時間がv1.1.17の224秒から、デフォルトで94秒、MAYA_DS4_PROMPT_SKIP=2 で80秒に短縮されたことを報告しています。また、4Kトークンでもスキップ有効時に38秒と、v1.1.17の52秒から改善しています。

RTX 5070 Ti + RTX 3060 構成での Maya-S 速度報告

コンシューマー向け PC 環境における、異なる世代の GPU を組み合わせた構成での実測値です。Maya は複数の GPU を使用して推論を実行し、VRAM が不足すると RAM や SSD へ階層化して処理します。

RTX 5070 Ti (16 GB) と RTX 3060 (12 GB) を組み合わせた構成で、Maya-S の速度が報告されました。環境は Windows 11、AMD Ryzen 7 9700X、RAM 32 GB です。両 GPU ともアンダーボルト・オーバークロックが適用され、安定動作を確認しています。

ミックス GPU 構成でも、Maya が GPU 間のリソースを適切に管理できることを示す実例です。特に、消費電力制限 (300 W / 170 W) 下での安定動作が確認されています。

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

利用者の報告

ユーザー nikich340 は、RTX 5070 Ti 16 GB と RTX 3060 12 GB、RAM 32 GB の構成で Maya 1.1.15 を実行し、ベンチマーク結果を報告しています。両 GPU ともアンダーボルトおよびオーバークロックが適用され、安定して動作したと述べています。

報告 URL: https://github.com/mw00/project-maya/issues/341

4x Tesla V100 環境での Maya-S/M/L 比較ベンチマーク

同一マシン上で異なる量子化モデル (Maya-S, Maya-M, Maya-L) の性能を比較するベンチマークです。VRAM の使用率やロード時間、トークン生成速度 (Decode) を比較することで、モデルサイズと性能のトレードオフを把握できます。

4x Tesla V100 (32 GB) 構成 (合計 128 GB VRAM) において、Maya-S (IQ2_XXS 量子化)、Maya-M、Maya-L の速度比較が行われました。Maya-S は 96.5 GB、Maya-M は 116 GB、Maya-L は 156.3 GB のモデルサイズです。Maya-S と Maya-M は VRAM 使用率が 100% でしたが、Maya-L は約 93% で、RAM 層を活用していました。

データセンター環境での大規模モデル実行における、量子化レベルによる速度差と VRAM 効率の実測値です。Maya-S が最も高速 (69.3 tok/s) で、Maya-L は 42.1 tok/s でした。

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

利用者の報告

ユーザー HansStrupat は、4x Tesla V100 32 GB、Ubuntu 22.04 環境で Maya 1.1.19 を実行し、3 つのモデルを比較ベンチマークしました。Maya-S が 69.3 tok/s、Maya-M が 65.1 tok/s、Maya-L が 42.1 tok/s のデコード速度を記録しました。Maya-L は RAM 層を活用して VRAM 不足を補い、約 93% の VRAM 使用率で動作しました。

報告 URL: https://github.com/mw00/project-maya/issues/340

2x A100 PCIe 環境での Maya-M 速度報告

データセンター向け GPU (A100) を 2 枚使用した構成での、中規模モデル (Maya-M) の実測性能です。OpenStack 上の仮想マシン環境での実行例です。

2x A100 80GB PCIe、AMD EPYC 7742、RAM 164 GB の環境で、Maya-M (116 GB) が 91.9 tok/s の速度で実行されました。モデルファイルは回転ディスク (HDD) に保存されており、NVMe ではない環境でも安定して動作しています。

クラウド環境での大規模 GPU 構成における、Maya の実用性を示すデータです。HDD からのモデル読み込みでも、推論速度への影響が限定的であることが示唆されます。

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

利用者の報告

ユーザー driona-will-fluff は、2x A100 80GB PCIe、AMD EPYC 7742、RAM 164 GB の OpenStack インスタンスで Maya 1.1.19 を実行し、Maya-M が 91.9 tok/s の速度を達成したと報告しています。モデルは HDD に保存されていました。

報告 URL: https://github.com/mw00/project-maya/issues/326

GLM split rows: 実行リクエストの均等グループ化オプション

複数 GPU での推論時、実行中のリクエストを GPU 間でどのように分割して処理するかを制御するオプションです。`MAYA_GLM_SPLIT_ROWS` が有効な場合、リクエストをグループ化して処理します。

`MAYA_GLM_EVEN_GROUPS=1` (デフォルトはオフ) を有効にすると、実行中のリクエストが均等なサイズに分割されます。これにより、GPU 間のアイドル時間を減らし、パイプライン効率を向上させます。例えば、リクエスト数が 5 で k=4 の場合、従来の 4+1 ではなく 3+2 に分割されます。

マルチ GPU 環境でのスループット向上に寄与します。特に、リクエスト数が GPU 数や分割数と一致しない場合に、GPU 資源の効率的な利用が可能になります。

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

利用者の報告

ユーザー somnergy は、この機能の実装と動作について報告しています。均等グループ化により、パイプラインの各部分に常にグループが割り当てられ、GPU のアイドル時間が削減されると説明しています。

報告 URL: https://github.com/mw00/project-maya/pull/324

DS4: 同時リクエスト処理とマルチスロットサービングの計画

DeepSeek-V4.1-Flash (Maya-S) 向けエンジン `maya-ds4` における、同時リクエスト処理 (`--parallel`) の制限と、マルチスロットサービングの実装計画に関する議論です。

現在、`maya-ds4` は `--parallel` オプションをサポートしておらず、一度に 1 つの会話しか処理できません。ユーザーは 8x RTX 5090 構成で 130 tok/s の速度を達成していますが、同時実行機能の欠如が制限要因となっています。開発側は、マルチスロットサービングの実装を検討中であると示唆しています。

大規模 GPU 構成での並列処理能力の向上は、実用的なローカル LLM サーバーとしての価値を高めます。同時実行機能の実装により、複数ユーザーや複数セッションからのアクセスが可能になります。

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

利用者の報告

ユーザー etevrfed34-commits は、8x RTX 5090 32 GB、1 TB RAM 構成で Maya-S を実行し、100K トークンのコンテキストでも 130 tok/s の速度を達成したと報告しています。しかし、`--parallel` オプションが認識されないため、同時実行ができないと指摘しています。

報告 URL: https://github.com/mw00/project-maya/issues/332

続報: ビジョンメモリキャッシュファイルの.gitignore追加

前回の話題で指摘されていた、ビジョンエンコーダーの VRAM 測定キャッシュファイル (`vision-memory.json`) が `.gitignore` で管理されていなかった問題の修正です。

プロジェクトルートに作成される `vision-memory.json` が、既存の `.gitignore` パターンでカバーされておらず、未追跡ファイルとして表示される問題がありました。PR #308 により、このファイルが `.gitignore` に追加され、管理対象となりました。

開発環境のクリーンな状態維持に寄与します。不要な未追跡ファイルの表示が解消され、Git 管理が簡素化されます。

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

利用者の報告: DeepSeek-V4.1の長プロンプトスキップ機能とマルチGPUレイヤースプリットの互換性

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

• Just wanna say that 1.1.17 didn't fix the prefill for EXL3 DeepSeek on Windows at least. Running it on AVX2 CPU (zen2 th… — AutisticPancake

Server: 詰まったFIFOとリクエストID重複の修正

• #327 Speed report: 4x Tesla V100-PCIE-32GB, Maya-S, 69.3 tok/s decode (Issue・2026-10-21)

DeepSeek-V4.1の長プロンプトスキップ機能とマルチGPUレイヤースプリットの互換性

• #328 DS4: long-prompt skip (v1.1.19 yoco) is single-GPU only — multi-GPU layer-split support planned? (Issue・2026-10-21)

出典

• Project Maya v1.1.20
• #337 Stop during long prompts, the Halo's GPU memory, Settings > Port, EXL3 on V100 and AMD
• #354 DeepSeek: int8 MMQ for routed prompt experts on AMD (opt-in)
• #353 DeepSeek: hipBLASLt solution table for dense prompt GEMMs (AMD, opt-in)
• #344 DeepSeek-V4.1 tensor parallel on 9 GPUs: prompts ~1.9x and answers ~1.55x faster at --tp 8 than main, the same perplexity (all-reduces off the SMs, the prompt skip on several GPUs, the expert cache's recent slots); ./maya.sh --calibrate tunes --tp
• #351 After ~68 requests the server answers 'exceeds the context (0)' to every request, until restarted (v1.1.20, 4x3090)
• #329 DS4: v1.1.18 PCIe lane mis-estimates the CPU lane on 2x4090, slowing decode (MAYA_DS4_STREAM=0 fixes it)
• #345 HIP: build and enable the vision encoder on AMD GPUs