山村商店

【Strata】Strata v0.2.0ベータ版：RDNA4最適化、VRAM管理の不具合、ベンチツール修正の最新状況

StrataローカルLLMQwenGPULLM

目次
  1. 今回の要点
  2. RDNA4 (gfx12) 向けHIPカーネルの大幅最適化
  3. VRAM確保、レイヤ分割、メモリ管理の不具合と最適化
  4. Strata v0.2.0ベータリリースとQwen3.8対応
  5. ベンチマークツールの改善とモニタリング機能の強化
  6. Intel Arc Pro B70 (SYCL) のサポートとベンチマーク
  7. 出典

Strataは、Niko1221 (@coldniko) によって開発されたQwen3.8-Flash-Next (125B MoE) を8GB以上のNVIDIA GPUとシステムRAMで動作させるローカル推論エンジンです。OpenAI/Anthropic互換APIを提供し、MITライセンスで公開されています。今回のv0.2.0ベータ版では、RDNA4 (gfx12) 向けカーネルの大幅な最適化やVRAM管理の仕組み変更が入る一方で、既存ユーザーの環境では予期せぬ不具合や速度低下も報告されています。

今回の要点

  • RDNA4 (gfx12) 向け最適化: QSA、WMMA、GDNカーネルが最適化され、デコード速度が向上しました。
  • VRAM管理の不具合: v0.2.0-betaではVRAM reserveが強制上書きされ、専用GPU環境で速度が低下する報告があります。
  • Linux環境でのクラッシュ: PipeWire環境下でRTTIME制限が原因の「exit code -9」が発生しています。
  • ベンチマークツールの修正: サーバー起動時のNameErrorや、環境情報の正確な取得が改善されました。
  • Intel Arc Pro B70 (SYCL) サポート: 速度向上とコピーエンジンハングの修正が行われています。

RDNA4 (gfx12) 向けHIPカーネルの大幅最適化

前提

RDNA4 (gfx12) はNVIDIAの最新アーキテクチャであり、StrataではHIP (CUDA互換) 経由で動作します。今回の変更は、このアーキテクチャ特有の命令セット (WMMA, QSA) を活用し、カーネルの効率を高めるものです。

何が変わったか

複数のプルリクエスト (#3233, #3230, #3225, #3223) により、RDNA4 (gfx12) 向けの最適化が実施されました。具体的には、QSA (Quantized Softmax Attention) ブロックスコアリングとtop-k選択の最適化、wave32 QSAデコードアテンションの有効化、MMVQ行再利用、そしてFP16/BF16 WMMAカーネルとGDNプリフィル再帰のポートが行われています。これにより、グローバルKV VMEMロード時のストール回避や、LDS (Local Data Share) バリアーの最適化が図られています。

なぜ重要か

RDNA4 (例: RTX 50シリーズ) を搭載しているユーザーにとって、これらの最適化はデコード速度とプロンプト読み込み速度の向上に直結します。特に、wave32モードの有効化は、新しいアーキテクチャの特性を最大限に引き出すために重要です。

根拠のリンク

利用者の報告

  • NVIDIA RTX A6000 (48GB), CUDA 13.0, Strata 0.1.44.1 環境でベンチマークを実施。Mohongzhi
  • NVIDIA RTX PRO 4000 Blackwell (24GB), CUDA 13.0, Strata 0.1.43.1 環境でベンチマークを実施。DrLove73
  • 2x RTX 3090 環境で連続動作テストを実施し、エラーなしで正常に動作したと報告。alexanderjacuna
  • NVIDIA GeForce RTX 5060 Ti (16GB), Windows 11 環境でベンチマークを実施。williamckl

利用者の報告

RTX 5060 Ti (16GB) を使用するユーザー (@wycoconut) は、モデルダウンロード段階で「command failed (exit 1): python.exe」エラーが発生し、mtpファイルのダウンロードタイムアウトが原因でインストールが止まる報告をしています。再試行を繰り返すことで回避可能ですが、長期的な解決策が必要です (Issue #3214)。

また、開発者 (@bsorensen110) 自身による実装報告では、gfx12における共有メモリバリアーの改善により、グローバルKV VMEMロード時のストールが回避され、デコード性能が向上したとされています (PR #3230)。

VRAM確保、レイヤ分割、メモリ管理の不具合と最適化

前提

Strataは、モデルの重み (エキスパート) をGPU VRAMとCPU RAMに分割して配置します。NUMA (Non-Uniform Memory Access) 環境では、CPUソケットごとのメモリアクセス効率を最適化するために「NUMA分割」が有効になることがあります。

何が変わったか

v0.2.0ベータ版では、VRAM reserve (確保) の挙動が変更されました。特に、ユーザーが `--vram-reserve-mib 0` を指定しても、エンジンが強制的に 1536 MiB を reserve するよう上書きされる現象が報告されています。また、Linux環境ではファイルティア (ファイルキャッシュ) の選択ルールに問題があり、アンバッファードリードと比較してデコード速度が 3〜4 倍遅くなるケースが見つかっています (Issue #3237)。

なぜ重要か

VRAM reserveが強制的に確保されることで、エキスパートキャッシュの領域が削られ、デコード速度が大幅に低下する可能性があります。特に、ディスプレイ出力をCPU内蔵GPUに任せてVRAMを全て推論に使う「専用計算GPU」環境では、この影響が顕著です。また、Linuxユーザーはファイルキャッシュの選択ミスにより、意図せず低速な読み込み経路が使われるリスクがあります。

根拠のリンク

利用者の報告

RTX 5070 (12GB) + Ryzen 7 7700 (iGPU使用) の環境で、@mesosomeso は `--vram-reserve-mib 0` を指定しても 1536 MiB が確保され、デコード速度が 80 tok/s から 50 tok/s へ約 37% 低下したと報告しています (Issue #3215)。同様に、@elusuario73 も 12GB VRAM環境で reserve 値の変更がエラーになることを報告しています。

Linux環境では、@vthomasino が PipeWireデスクトップ環境で `RLIMIT_RTTIME` 制限が原因の「exit code -9」クラッシュを報告しています。OOM (Out of Memory) ではなく、リアルタイム制限による強制終了でした (Issue #3238)。

NUMA分割の効果については、環境によって結果が分かれています。HP Z6 G4 (Dual Xeon Gold 6226 + RTX 3090) の @baptisterajaut は、NUMA分割有効化でデコード速度が 52.6 tok/s から 60.0 tok/s へ向上したと報告しています (Issue #3201)。一方、Dual Xeon E5-2670 v2 + 2x CMP 50HX の @xrip は、分割なしの方が 12.6% 高速だったと報告しており、CPU世代やGPU構成によって最適解が異なることが示唆されています (Issue #3201 Comment)。

Strata v0.2.0ベータリリースとQwen3.8対応

前提

StrataはQwen3.8-Flash-Next (125B MoE) に対応しており、VRAM効率を高めるためにK/Vキャッシュの精度 (FP16/INT8等) や、エキスパートのオフロード設定が重要です。

何が変わったか

v0.2.0ベータ版では、Qwen3.6/3.5系エンジンでFP32だったK/Vキャッシュが、デフォルトでFP16 (6.0 GiB at 262144) に変更されました。また、`--kv-q8` オプションでINT8 (3.1 GiB) での保存が可能になり、16GBカードでも262Kコンテキストが収まるようになりました (PR #3084)。さらに、DFlash2 (7トークンドラフター) のサポート要望や、HyperQwen (lookup augmented block drafter) による速度向上の可能性が議論されています。

なぜ重要か

K/Vキャッシュの精度変更により、VRAMの節約とコンテキスト長の拡大が実現します。また、DFlash2等のドラフター技術のサポートは、推論速度を大幅に向上させる可能性があります。

根拠のリンク

利用者の報告

@apdogod123321-ops は、RTX 2080 Ti (11GB) 環境でDFlash2のサポートを要望しています (Issue #3183)。@Meetsch は、DFlash2とHyperQwenを組み合わせることで、RTX 3090上で最大 380 tok/s の速度向上が期待できると報告しています (Issue #3183 Comment)。

ベンチマークツールの改善とモニタリング機能の強化

前提

Strataには `tools/strata_bench.py` および `BENCH.bat` といったベンチマークツールが含まれており、ユーザーが自分の環境での性能を測定・報告するために使われます。

何が変わったか

v0.2.0ベータ版では、ベンチマークツールにいくつかのバグが見つかりました。特に、サーバーを起動する際に `NameError: name 'port' is not defined` が発生し、ベンチマークが実行できない状態でした (Issue #3188)。また、環境情報の取得について、CUDA UMDバージョンやストレージ情報、GPUの詳細 (電力、PCIeリンク等) が正しく取得されない問題があり、これらが修正されました (PR #3250)。

なぜ重要か

ベンチマークツールは、ユーザーが自分の環境での性能を評価し、開発者にフィードバックを与えるための重要な手段です。ツールのバグ修正により、正確なベンチマーク結果の取得が可能になります。

根拠のリンク

利用者の報告

RTX 5090 (Windows 11) の @ZrDaniel07 と、RTX 4060 Ti (Windows 11) の @JoShMiQueL は、ベンチマークツールがサーバー起動時にクラッシュすることを報告し、修正パッチや回避策を提示しています (Issue #3188 Comment, Issue #3188 Comment)。

Intel Arc Pro B70 (SYCL) のサポートとベンチマーク

前提

StrataはNVIDIA GPUだけでなく、Intel Arc GPU (SYCL経由) のサポートも進めています。Arc Pro B70/B65 (Battlemage) は、32GB VRAMを搭載し、大規模モデルの推論に適しています。

何が変わったか

Intel Arc Pro B70/B65向けに、SYCLエンジンが最適化されました。プロンプト速度が 10-35% 向上し、コピーエンジンのハング (カードのフリーズ) が修正されました。また、INT8クロスオーバーキャッシュの実装や、テストの失敗修正が行われています (PR #3248)。単一B70環境で、IQ2_XS量子化モデルを用いたデコード速度は、最適化前 (67.10 tok/s) から最適化後 (94.85 tok/s) へ向上しています (PR #3153)。

なぜ重要か

Intel Arcユーザーにとって、これらの最適化は推論速度の向上と安定性の確保に直結します。特に、コピーエンジンのハング修正は、長時間の推論やKVキャッシュの保存/復元において重要です。

根拠のリンク

利用者の報告

Intel Arc Pro B70 (32GB VRAM) + Xeon w5-3435X の環境で、@xiangyuT は最適化後のSYCLエンジンで、32Kワークロードにおいて 94.85 tok/s のデコード速度を達成したと報告しています (Issue #3150)。開発者 (@maxfridbe) は、コピーエンジンのハング修正により、テストが正常に通過し、カードのフリーズが解消されたことを報告しています (PR #3248)。

出典

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

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