山村商店

【Project Maya】Maya v1.1.27: 動画入力対応と、Windowsのフリーズ・TP設定のエラーを修正

ProjectMayaローカルLLMGLMGPULLM

目次
  1. 今回の要点
  2. 動画入力機能のネイティブサポート
  3. Windows環境での画像入力によるフリーズ修正
  4. DeepSeek GGUF不均一TP設定でのCublasエラー修正
  5. RAMにExpertを保持する場合の推論速度改善
  6. v1.1.24 ベンチマーク報告
  7. Issue #443 の実験的機能：V100向けCTC
  8. DeepSeek 環境設定変更時の不具合修正
  9. Project Maya v1.1.27 リリース：DeepSeek 高速化、GLM 動画入力、Windows 不具合修正
  10. DeepSeek-V4.1: 4ソケットNUMA対応とGSQ-RCO GGUF読み込み
  11. GLM-5.3/EXL3: V100 互換 GPU 対応と RDNA4 最適化
  12. ベンチマーク: Radeon 8060S 活用と Windows/V100 環境
  13. DeepSeek DSpark ドラフターの GPU 選択機能の追加
  14. Volta GPUでのGLM MLA注意機構のTensor Core活用による高速化
  15. DeepSeek GGUF向けIQ2_XS量子化サポートの追加
  16. CPUでのIQ1_M量子化Expert行のAVX2デコード高速化
  17. NVIDIA Ada GPUでの大規模プロンプト処理速度低下
  18. コミュニティ要望のデリスク化と分散推論
  19. GLM: RAMインクルーシブモードとルーティング微最適化
  20. 出典

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

今回の要点

  • 動画入力対応: GLM-5.3-Flash 向けに動画全体の分析・要約を行うネイティブサポートが追加されました。
  • Windowsのフリーズ修正: Windows環境で画像入力時にサーバーが固まる不具合が修正されました。
  • TP設定のエラー修正: 複数GPUでDeepSeekを動かす際のメモリアクセスエラーが修正されました。
  • 推論速度の改善: RAMにExpertを保持する場合、デフォルト設定で速度が約22%向上するよう調整されました。

動画入力機能のネイティブサポート

GLM-5.3-Flash は画像だけでなく動画の処理も可能ですが、それまで Maya では動画入力に対応していませんでした。今回の更新で、動画全体の分析や要約、質問への回答を行うためのネイティブな動画入力機能が追加されました。テストでは Minimax H3 によって生成された動画が正常に処理されており、SSDオフロードを有効にした開発機でも数分以内に完了するとの報告があります。

この機能は、GLMのチャットテンプレートに基づいて実装されました。以前から llama.cpp では video_url 経由で動画がサポートされていましたが、Maya 側でも同様に動作するように修正されています。

Windows環境での画像入力によるフリーズ修正

Windows環境で Maya サーバーを動かしているユーザーの間で、画像を含むリクエストを送信するとサーバー全体がフリーズし、すべてのリクエストに応答しなくなるという不具合が報告されていました。この問題は、親プロセスの監視スレッド（stdin でのブロッキング読み取り）と、画像処理時に実行される numpy の遅延インポートが競合することで引き起こされていました。

修正版では、Windows 環境においてブロッキング読み取りの代わりにポーリングを行うよう変更されました。これにより、画像入力時のデッドロックが解消されました。

利用者の報告

DikiyLifter は、Windows 11 環境（RTX PRO 6000 Blackwell 96 GB、i9-14900K、CUDA 13.3）で、画像を含む最初のリクエストを送信するとサーバーが完全にフリーズし、GET /v1/models などの他のリクエストも応答しなくなる現象を報告しました。この問題は v1.1.19 および v1.1.26 で再現し、v1.1.16 および v1.1.17 では発生しませんでした。

開発者の mw00 は、この報告に基づいて修正を行い、v1.1.27 で問題が解消されたことを確認しました。

DeepSeek GGUF不均一TP設定でのCublasエラー修正

複数GPUでTensor Parallel（TP）設定を使用して DeepSeek モデルを動かす際、MAYA_DS4_TP_GGUF_UNEVEN 環境変数を有効にすると、最初の長いプロンプトで cublasGemmEx が失敗し、その後 illegal memory access が発生するというエラーが報告されていました。この問題は、FFN（全結合層）の幅がレイヤー間で変化する場合に、バッファのサイズが不足してオーバーランすることが原因でした。

修正版では、バッファのサイズがデバイスが持つレイヤーの中で最も広い FFN の幅に合わせて確保されるようになりました。これにより、レイヤー間の幅の違いによるバッファオーバーランが解消されました。

利用者の報告

mgabor3141 は、4x RTX 3090（Gen3、P2Pなし、ドライバー 615.78.08、CUDA 13.4）の環境で、MAYA_DS4_TP_GGUF_UNEVEN=1 および --tp 2 設定を使用している際、最初の長いプロンプトで cublasGemmEx が失敗し、その後 illegal memory access が発生する現象を報告しました。この問題は、CUDA0 と CUDA1 がグループを形成し、CUDA1 が 8.5 GB の空きメモリを残している状態で発生しました。

pepuscz は、この問題が #439 と同じオーバーランによるものであり、#446 で修正されると指摘しました。DS4_FAT_ROWS は最初の使用時にバッファをサイズ決定するため、MAYA_DS4_TP_GGUF_UNEVEN 有効時にはレイヤー間で FFN 幅が交互に変化し、後の広いレイヤーがバッファを越えて書き込む原因となっていました。

tran8749 は、2x RTX PRO 5000 Blackwell 48 GB の環境で、MAYA_DS4_TP_GGUF_UNEVEN=1 と --tp 2 設定を使用している際、最初のストリーミングレイヤーでエラーが発生し、すべてのリクエストが失敗する現象を報告しました。この設定なしでは、同じ構成で正常に動作していました。

RAMにExpertを保持する場合の推論速度改善

DeepSeek モデルを動かす際、Expert を RAM に保持する場合、デフォルト設定（--mmap-experts auto）では推論速度が低下するという問題が報告されていました。これは、Expert がファイルから直接読み込まれるため、RAM にコピーするよりも速度が遅くなることが原因でした。

修正版では、Expert がすべて RAM に収まる場合、デフォルトで CPU ラインの Expert が RAM にコピーされるようになりました。これにより、--mmap-experts off を指定した場合と同様の速度が得られるようになりました。

利用者の報告

HansStrupat は、4x Tesla V100 32GB（128 GB VRAM、504 GB RAM）の環境で、--mmap-experts off を指定した場合、デコード速度が 41.4 tok/s と、デフォルトの 33.8 tok/s よりも約 22.5% 高速であることを報告しました。この結果は、Expert が RAM にコピーされることで速度が向上することを示しています。

開発者の mw00 は、この報告に基づいて v1.1.27 でデフォルト設定を変更し、Expert がすべて RAM に収まる場合に自動的にコピーされるようにしたと報告しました。

v1.1.24 ベンチマーク報告

v1.1.24 における DeepSeek モデルのベンチマーク報告が寄せられています。2x NVIDIA A100-SXM4-80GB（RAM 1007.4 GB）の環境で、コンテキスト 262144、平均 83.6 tokens/s の速度が記録されました。

Issue #443 の実験的機能：V100向けCTC

Issue #443 では、JadDid911 が Tesla V100 2基で動かしている `maya-ds4` に compress-then-correct（CTC）デコーディングを実験的な任意機能として追加し、PR を出す前に意見を求めています。これは、lossy expert routing と exact re-decode を組み合わせた手法で、VRAM が限られた環境での推論速度向上を目指しています。

DeepSeek 環境設定変更時の不具合修正

GPU 枚数を変更する際、設定ファイルに残った古い設定が原因で正しく動作しない不具合が修正されました。

2 GPU から 1 GPU に設定を変更した際、設定ファイル (maya-ds4.json) やスクリプト (maya.sh) に古い設定 (GPU 枚数 2、TP 2) が残ったままになり、その後の処理で失敗する事象が報告されていました。この修正により、設定変更時に古い設定が正しく上書きされるようになりました。

GPU 構成を変更するユーザーにとって、設定ファイルの残存によるエラーを防ぐ重要な修正です。

出典: #436 v1.1.26 when changing configuration from two GPUs to one GPU, setup does not change GPU amount

利用者の報告

uris-code1 さんが、v1.1.26 で 2 GPU から 1 GPU に変更した際、maya-ds4.json と maya.sh に古い設定が残ったままになり失敗すると報告しています。

報告: uris-code1 さんの報告

Project Maya v1.1.27 リリース：DeepSeek 高速化、GLM 動画入力、Windows 不具合修正

v1.1.27 がリリースされ、DeepSeek の高速化、GLM での動画入力対応、Windows 環境の修正が含まれています。

DeepSeek において、RAM にエキスパートを全て収められる環境で、ファイルから読み込む代わりに RAM にコピーする処理 (デフォルト動作) が追加されました。これにより、V100 4 枚 (504 GB RAM) で +22%、20 GB カード (255 GB RAM) で約 2 倍、RTX 3090 4 枚 (126 GB RAM) で +23% の高速化が報告されています。GLM については、動画を入力として扱えるようになり、フレームレート 4fps で画像エンコーダーに送られます。Windows では、最初の画像読み込み時にサーバーがフリーズする不具合 (v1.1.18 以降の影響) が修正されました。

RAM 容量が十分な環境での DeepSeek 推論速度が大幅に向上します。また、Windows ユーザーは動画入力や安定性の向上を利用できます。

出典: Project Maya v1.1.27

DeepSeek-V4.1: 4ソケットNUMA対応とGSQ-RCO GGUF読み込み

DeepSeek 環境において、4ソケット CPU への対応、コンテキスト長の拡張、新量子化形式の読み込みが可能になりました。

DeepSeek の CPU ラインによる RAM エキスパートのコピー対象が、最大 2 NUMA パートから 4 NUMA パート (4 ソケット CPU 向け) に拡張されました。これにより、マルチソケット環境でのコアとメモリ帯域の活用が進みます。また、DeepSeek-V4.1-Flash 向けに、セットアップとダッシュボードでのコンテキスト長選択が 512K および 1M に対応しました。さらに、ISTA-DASLab 製の DeepSeek-V4.1-Flash-1017 GSQ-RCO IQ2_XXS チェックポイント (IQ4_NL Engram テーブル含む) の読み込みに対応し、重みの変換なしで利用可能になりました。

4 ソケット CPU を持つ環境では推論性能の向上が期待できます。また、1M コンテキストや新量子化形式の利用により、より長い文脈や新しいモデル形式を試すことができます。

出典: #463 ds4: DS4_COPY_NUMA up to 4 NUMA parts、#442 DeepSeek-V4.1: 512K and 1M contexts、#453 feat(ds4): load GSQ-RCO GGUF and IQ4_NL Engram tables

利用者の報告

noahark さんは、3x Tesla V100 32GB + Windows 環境 (128 GB RAM) で、v1.1.25 から v1.1.26 への変更により、prefill 速度が 314 t/s から 425 t/s (+35%) に向上したと報告しています。また、--mmap-experts auto と off の比較では、RAM 容量が少ない環境では変化がないか、コピーされた部分が測定で遅くなるケースもあったとあります。

報告: noahark さんの報告

geoffreybyers さんは、4x Xeon E7-8880 v4 (88 コア) 環境での DS4_COPY_NUMA 拡張について報告しています。4 パート設定で長いプロンプト処理時にスタックオーバーフロー ("stack smashing detected") が発生する事象が確認されていますが、短いチャットではこのパスに到達しないため影響はありません。

報告: geoffreybyers さんの報告

needmorevram さんは、512K および 1M コンテキストのテストについて報告しています。--tp 8 (9 GPUs) で 1M コンテキストの "Needle in a haystack" テストが成功したとあります。

報告: needmorevram さんの報告

GLM-5.3/EXL3: V100 互換 GPU 対応と RDNA4 最適化

GLM 推論において、旧世代 NVIDIA GPU での EXL3 高速化と、AMD RDNA4 GPU 向けの最適化が進みました。

sm_80 以前の NVIDIA GPU (V100, T4, RTX 20 シリーズ) 向けに、EXL3 デコードの高速化が行われました。trellis ステップのウィンドウ処理を 8 回まとめて行うことで、V100 でデコード速度が 11-17% 向上しました。出力はビット単位で同一です。また、AMD RDNA4 (gfx1100/gfx1151) 向けに、GLM の IQ2_S ゲート/アップ処理を最適化されたカーネルで実行するオプション (MAYA_GLM_GU22_TUNED=1) が追加されました。さらに、インデクサーのスコアリングと MLA の分割アテンションを最適化する 2 つのオプトインカーネルが追加されました。

V100 などの旧 GPU ユーザーは EXL3 モデルの速度向上を利用できます。AMD RDNA4 ユーザーは、IQ2_S モデルやアテンション処理の高速化を試すことができます。

出典: #461 EXL3 decode on V100 / T4 / RTX 20、#457 GLM decode attention: take-two kernels、#455 GLM experts: IQ2_S gate/up on the tuned RDNA kernel

利用者の報告

merbanan さんは、V100 環境で EXL3 2.05bpw 量子化モデルを用いたテストを行い、デコード速度が 11-17% 向上し、出力は v1.1.26 とビット単位で同一であることを確認しています。

報告: merbanan さんの報告

pepuscz さんは、GLM の最適化カーネルについて報告しています。テスト環境では、各ラベルが元のカーネルとビット単位で同一であることを確認し、Infinity Cache を超えるワークセットでベンチマークを実施しています。

報告: pepuscz さんの報告

GLM-5.3/EXL3: V100互換GPU対応とRDNA4最適化 の項目一覧

ベンチマーク: Radeon 8060S 活用と Windows/V100 環境

Ryzen AI Max+ 環境での Radeon 8060S の活用や、Windows/V100 環境での実測データが報告されています。

Ryzen AI Max+ 395 (Radeon 8060S iGPU 搭載) に 2x RX 7900 XTX を追加した環境で、GLM-5.3-Flash (Maya-M IQ2_S) を実行した報告があります。Radeon 8060S をエキスパートヘルパーとして活用し、層分割と併用することで、単純な層分割の約 2 倍のデコード速度 (2K〜240K トークンで 53-58 tok/s、456K で 50 tok/s) を達成しました。また、3x Tesla V100 32GB + Windows 環境 (128 GB RAM) では、v1.1.25 から v1.1.26 への変更により、prefill 速度が 314 t/s から 425 t/s (+35%) に向上しました。4x RTX 3090 環境では、v1.1.24 から v1.1.26 への変更により、プロンプト処理速度が 14-16% 向上し、デコード速度は概ね同等でした。

統合 GPU を持つ環境や、Windows/V100 環境のユーザーは、設定変更による速度向上を確認できます。

出典: #458 GLM-5.3-Flash Maya-M on 2x RX 7900 XTX + Radeon 8060S、#448 Speed report: 4x RTX 3090、#450 Speed report: 3x Tesla V100 32GB

DeepSeek-V4.1: 4ソケットNUMA対応とGSQ-RCO GGUF読み込み の項目一覧

利用者の報告

pepuscz さんは、Ryzen AI Max+ 395 + 2x RX 7900 XTX + Radeon 8060S 環境で、GLM-5.3-Flash (Maya-M IQ2_S) を実行し、2K〜240K トークンで 53-58 tok/s、456K で 50 tok/s のデコード速度を達成したと報告しています。Ansible レシピも提供されています。

報告: pepuscz さんの報告

mgabor3141 さんは、4x RTX 3090 + Threadripper 1950X 環境で、v1.1.24 から v1.1.26 への変更により、10K トークンプロンプトで 827-839 tok/s から 869-947 tok/s、90K トークンプロンプトで 1,664-1,690 tok/s から 1,918-1,954 tok/s に向上したと報告しています。デコード速度は概ね同等でした。

報告: mgabor3141 さんの報告

DeepSeek DSpark ドラフターの GPU 選択機能の追加

DeepSeek の DSpark ドラフターが実行される GPU グループを選択できるようになりました。

3 枚の GPU を持つ環境などで、ドラフターを第 3 の GPU に割り当てることで、メインモデルのエキスパート用の VRAM を確保する配置オプションが追加されました。3x R9700 の研究ビルドでは、固定キャッシュコーディングケースで、ドラフター有効時 (第 3 カード使用) に 21.21 tokens/s、無効時に 16.83/17.03 tokens/s (+24.5–26.0%) の結果が得られました。ただし、これは MTP を有効にした配置の比較であり、既に有効なドラフターを GPU 間で移動させた場合の速度向上を示すものではありません。タイミングドリフトゲートに失敗したケースもあったため、一般的な速度向上を確立するものではありません。

マルチ GPU 環境で、VRAM の割り当てを柔軟に調整したいユーザー向けの変更です。

出典: #464 ds4: allow choosing the DSpark drafter GPU group

Volta GPUでのGLM MLA注意機構のTensor Core活用による高速化

Voltaアーキテクチャ（V100等）では、GLMモデルのデコード処理でSparse MLA（Multi-Head Latent Attention）注意機構がCUDAコアで実行されていましたが、この処理をTensor Coreで実行する最適化が行われました。

これにより、注意機構の処理速度が4.3倍に改善し、V100環境でのデコード速度は3〜6%向上しました。VRAMの追加消費はありません。

Volta GPU（sm_70/sm_72）でGLMモデルを高速に推論できる環境が整いました。

根拠: PR #459

利用者の報告

merbanan により、V100でのベンチマーク結果が報告されました。注意機構の処理が4.3倍高速化し、デコード速度は3〜6%向上したと報告されています。PR #459

開発者 mw00 により、V100での実環境テストで約2%のデコード速度向上が確認され、品質への影響はなかったと報告されています。PR #459 コメント

DeepSeek GGUF向けIQ2_XS量子化サポートの追加

DeepSeekモデルのGGUF形式において、UnslothのUD-IQ2_XXS量子化形式で使用されるIQ2_XS（ggml 17）のサポートが追加されました。

これにより、IQ1_S量子化モデルのロード時に停止していた問題が解消され、VRAM節約に寄与します。

Unsloth形式の量子化モデルをMayaで正常にロード・推論できるようになりました。

根拠: PR #357

CPUでのIQ1_M量子化Expert行のAVX2デコード高速化

CPU推論時のIQ1_M量子化Expert行のデコード処理が、AVX2命令セットを活用して高速化されました。

Threadripper PRO 3945WX環境でのベンチマークでは、IQ1_Mのゲート/アップ/ダウン処理が14.34倍高速化しました（8.044ms → 0.561ms）。

CPU推論時のIQ1_M量子化モデルの処理速度が大幅に向上しました。

根拠: PR #452

利用者の報告

Whamp により、Threadripper PRO 3945WX（12スレッド）でのベンチマーク結果が報告されました。IQ1_Mの処理が14.34倍高速化し、他の量子化形式（IQ2_XXS、IQ3_XXS）の速度には変化なかったと報告されています。PR #452

NVIDIA Ada GPUでの大規模プロンプト処理速度低下

v1.1.26において、NVIDIA Ada GPU（RTX 4000 Ada等、sm_89）環境で、大規模プロンプト（prefill）の処理速度がv1.1.25比で3.7〜5.4倍低下する問題が報告されました。デコード速度への影響はありません。

この問題はWindows環境に限定されており、Linux環境では再現していません。VRAMの過剰使用による「共有GPUメモリ」への移行が原因と推測されています。

Windows環境でAda GPUを使用するユーザーは、プロンプト処理速度の低下に注意が必要です。環境変数（DS4_FAT_ROWS=0等）で回避できる可能性があります。

根拠: Issue #438

利用者の報告

pietroMastro92 により、RTX 4000 Ada 20GB（Windows 11）での報告がありました。v1.1.26で、2.7kトークン処理で3.7倍、63.8kトークン処理で5.4倍prefill速度が低下したと報告されています。Issue #438

開発者 mw00 により、Linux環境では再現せず、Windows固有の問題であるとの報告がありました。VRAMの過剰使用による共有メモリへの移行が原因と推測され、環境変数で回避できる可能性があるとのことです。Issue #438 コメント

コミュニティ要望のデリスク化と分散推論

ブラジルの大学が、Mayaを複数ユーザー（管理者、プログラマー、研究者等）が共有するラボ環境での実運用テストを報告しています。

Issue #437では、#356、#403およびv1.1.26により、単一L40Sで1ユーザーが約40〜45 tok/sの速度を得られ、サブエージェントを持つエージェントがプロンプトを再読しなくなったと報告されています。

複数ユーザーが同一サーバーでMayaを利用する環境での実用性が確認されつつあります。

根拠: Issue #437

利用者の報告

talisp により、ブラジルの大学での実運用報告がありました。Issue #437のtalispのコメントでは、#356、#403およびv1.1.26により、単一L40Sで1ユーザーが約40〜45 tok/sの速度を得られ、サブエージェントを持つエージェントがプロンプトを再読しなくなったと報告されています。Issue #437

GLM: RAMインクルーシブモードとルーティング微最適化

VRAMからRAMにExpertが退避する際、PCIe経由での書き戻しを不要にする「RAMインクルーシブモード」（MAYA_GLM_RAM_INCLUSIVE）が追加されました。

これにより、デコード速度が6%（±4%）向上しました。プロンプト処理速度への影響はありません。

また、ルーティング処理の微最適化により、V100環境でデコード速度が0.15-0.33%向上しました。

VRAMが限られる環境での推論効率が向上しました。

根拠: PR #460, PR #451

出典

【宣伝】SwitchBot 購入はこちらから

SwitchBot公式ページ
クーポン「AF-4903」で5％引き（アフィリエイトクーポンになりますのでご協力お願いします）
割引の詳しい仕組みに関してはこちらのページを参照ください。
製品ごとの特徴・紹介動画は SwitchBot 製品ガイド にまとめています。