山村商店

Strata v0.1.40.3：Intel Arc 公式対応、GPU メモリ管理の高度化、prefill 最適化

StrataローカルLLMQwenGPULLM

目次
  1. 今回の要点
  2. Strata v0.1.40.3 リリース：Intel Arc 対応と Windows AMD 高速化
  3. GPU メモリ管理の高度化：LRU 淘汰と Windows 大型ページ対応
  4. Prefill 処理の CPU 共有とストリーミング読み込み最適化
  5. マルチ GPU 構成と Docker 環境の改善
  6. CUDA 量子化カーネルの改善：MMVQ 再利用と INT8 精度向上
  7. 出典

Strata は Niko1221 (@coldniko) が開発する、Qwen3.8-Flash-Next (125B MoE) を 8GB 以上の NVIDIA GPU とシステム RAM で動かすローカル推論エンジン。OpenAI/Anthropic 互換 API、MIT ライセンス。

今回の要点

  • v0.1.40.3 リリース： Intel Arc (A/B シリーズ) の公式対応、Windows 環境での AMD GPU 高速化、Docker 環境の改善。
  • GPU メモリ管理の高度化： Windows 環境での LRU 淘汰アルゴリズムと、大型ページ (Large Pages) による VRAM 確保の最適化。
  • Prefill 処理の最適化： CPU 共有機能の改善と、ストリーミング読み込みの高速化により、長いプロンプト処理が高速化。
  • CUDA カーネルの改善： 量子化精度の向上と、MMVQ 演算の再利用による推論速度の向上。

Strata v0.1.40.3 リリース：Intel Arc 対応と Windows AMD 高速化

前提

Strata は MoE モデルの重みを GPU VRAM とシステム RAM に分散配置し、PCIe 経由で読み出すことで、高スペックな GPU 一つでは収まらない大規模モデルを、比較的安価なハードウェアで動作させることを可能にしています。

何が変わったか

v0.1.40.3 では、Intel Arc シリーズの公式サポートが追加されました。特に Arc A750 などの 8GB クラスカード向けに、設定ファイルの自動生成ロジックが改善され、よりスムーズな起動が可能になっています。また、Windows 環境における AMD GPU の処理速度が改善され、16GB 以上のカードでの回答生成が高速化しています。

なぜ重要か

Intel Arc ユーザーや、Windows 環境で AMD GPU を使用しているユーザーにとって、Strata の利用環境が大幅に広がります。特に Arc A750 などはコストパフォーマンスが高く、ローカル LLM 運用の選択肢の一つとして注目されています。

根拠のリンク

Strata v0.1.40.3

利用者の報告

Intel Arc Pro B50 (16GB) を使用しているユーザーから、このカードが MoE モデルを VRAM 内に完全に収められる有望な選択肢であるという報告があります。70W の低消費電力で、3年の保証付きで販売されており、SYCL バックエンドでサポートされています [1]。

また、Arc A750 でのベンチマークでは、IQ3_XXS モデルで約 19 tok/s の推論速度が確認されています [2]。

GPU メモリ管理の高度化：LRU 淘汰と Windows 大型ページ対応

前提

Strata は、MoE モデルの「エキスパート」重みを、GPU VRAM に収まりきらない分をシステム RAM に保持します。このとき、RAM に保持する重みの管理に LRU (Least Recently Used) アルゴリズムが採用されています。

何が変わったか

Windows 環境において、以下の二つの改善が行われました。

  • LRU 淘汰の高度化： RAM バudget の一部を LRU として扱い、メモリ圧迫時に柔軟に重みを解放する機能が追加されました。これにより、異なるトピックの会話中でも、必要な重みを効率的に保持できます。
  • 大型ページ (Large Pages) の対応： Windows で「メモリをロックする」権限を持つアカウントで Strata を実行する場合、エキスパート領域を 4KB ページではなく 2MB の大型ページで確保するようになりました。

なぜ重要か

大型ページの使用により、OS のページング処理が軽減され、メモリ確保のオーバーヘッドが削減されます。特に、システム RAM に大量の重みを保持する環境では、起動時の警告が消え、より安定した動作が期待できます。

根拠のリンク

PR #1324: file tier: an LRU part of the RAM budget

Issue #1412: Windows: SeLockMemoryPrivilege moves the expert arena to 2 MiB large pages

利用者の報告

RTX 4080 SUPER 16GB + RTX 3090 24GB の環境で、大型ページの使用を確認した報告があります。起動ログにおいて、「large pages refused」の警告が消え、代わりに大型ページでの確保が成功した旨のメッセージが表示されるようになりました [3]。

一方で、Resident Budget 経路では、`cudaHostAlloc` が使用されるため、大型ページが必ずしも適用されない場合があるという指摘もあります。一部の環境では、大型ページ確保に失敗し、通常のピン付き RAM にフォールバックするケースも報告されています [4]。

Prefill 処理の CPU 共有とストリーミング読み込み最適化

前提

Prefill とは、プロンプト（入力テキスト）をモデルが処理する最初の段階です。MoE モデルでは、プロンプトの各トークンに対して、どのエキスパート重みを読み出すか決定するルーティング処理が行われます。この際、CPU と GPU の連携が性能に大きく影響します。

何が変わったか

  • CPU 共有の拡大： `STRATA_PREFILL_CPU_SHARE` 環境変数により、プロンプト処理の一部を CPU に共有させる範囲が拡大しました。最大 3,072 トークンのチャンクまで対応し、レイヤ分割構成でも有効に働きます。
  • ストリーミング読み込みの最適化： 非バッファード読み込みのバッチ処理により、`experts.bin` からの重み読み込み効率が向上しました。

なぜ重要か

長いプロンプトを入力した際の、最初の応答までの時間 (TTFT) が短縮されます。特に、PCIe バンド幅が限られている環境や、レイヤ分割を使用している環境で効果的です。

根拠のリンク

PR #1414: prefill: the CPU share up to 3,072-token chunks

PR #1323: prefill: batched unbuffered stager reads

利用者の報告

Ryzen 9 7940HS + RTX 4070 Laptop 8GB の環境で、`STRATA_PREFILL_CPU_SHARE=auto` を有効にした場合、22,305 トークンの長いプロンプト処理時間が、約 29% 改善したという報告があります (72.7秒 → 51.4秒) [5]。

一方で、Windows 環境で `--ple-io direct` (デフォルト) を使用すると、n-gram テーブルの読み込み速度が SSD の最大速度 (1.4 GB/s) に比べて極端に遅く (約 34 MB/s)、prefill 速度が約 5 倍低下するケースが報告されています。この場合、`--ple-io mmap` に変更することで、ウォーム状態では高速化しますが、コールド状態では依然として遅延が発生し、ウォッチドッグによるエラーを引き起こす可能性があります [6]。

マルチ GPU 構成と Docker 環境の改善

前提

Strata は、複数の GPU を使用してモデルのレイヤを分割する「レイヤ分割」や、Docker での実行をサポートしています。これにより、高メモリな GPU が一つしかない場合でも、複数の GPU を組み合わせたり、コンテナ環境でデプロイしたりすることが可能です。

何が変わったか

  • Dockerfile の追加： ROCm 版の Docker イメージをビルドするための Dockerfile が追加されました。
  • Open WebUI 連携ドキュメント： Open WebUI の背後で Strata を実行するためのガイドラインが提供されました。

なぜ重要か

Docker 環境での構築が簡易化され、K8s などのコンテナオーケストレーション環境でのデプロイが容易になります。また、Open WebUI との連携により、複数ユーザーでの共有運用がより現実的になります。

根拠のリンク

PR #1307: Add Dockerfile for building ROCm-based Strata Docker images

PR #1400: docs: running Strata behind Open WebUI

利用者の報告

2x RTX 3090 (Linux, Docker) 環境でのベンチマーク報告があります。`--pipeline-windows 2` オプションを有効にすることで、すべてのエキスパートモードでデコード速度が 7% から 20% 向上しました [7]。

一方で、P40 (24GB) + RTX 3070 (8GB) の組み合わせで、`--layer-split auto` を使用した場合、フラグの追加により K 値が変化し、prefill 速度が 458 tok/s から 111-113 tok/s に急落するケースが報告されています。これは、コストモデルの予測と実際の処理速度に乖離があることを示唆しています [8]。

利用者の報告

  • Proxmox VE上のAMD Ryzen 9 9950X3DとPCIe 4.0 x8接続のRTX 3090 2枚構成で、Qwen3.8-Flash-Next IQ3_XXSを用いたパイプライン実行はシリアル実行に対し短プロンプトで約1%の速度低下を示した。 GonzMartinez
  • Ubuntu上のRTX 4090 (24GB) で Qwen3.8-Flash-Next IQ2_XS を実行した際、ブラウザゲーム生成の試作では車両物理やゲーム性が不十分と判断された。 darkerow
  • Strix Halo (gfx1151) ホスト上で Strata の高速設定が参照実装の貪欲出力と一致するプロンプトが20件中8件にとどまり、速度向上が出力品質の低下を伴う可能性があることが確認された。 noamsto

CUDA 量子化カーネルの改善：MMVQ 再利用と INT8 精度向上

前提

量子化とは、モデルの重みを低ビット数 (例: INT8, Q4_K) で表現することで、メモリ使用量と計算量を削減する技術です。Strata は様々な量子化形式をサポートしており、カーネルの最適化により速度と精度の両立を図っています。

何が変わったか

  • INT8 精度の向上： `STRATA_PROMPT_ATTN_IMMA=1` を有効にすることで、短プロンプトでの精度劣化を抑制し、FP32 に近い精度を実現するカーネルが追加されました。
  • MMVQ 演算の再利用： Q4_K, Q5_K, Q6_K, IQ4_XS 形式において、出力行間で Q8_1 活性化断片を再利用するカーネルが追加されました。

なぜ重要か

短プロンプトでの精度劣化を防ぎ、より正確な応答が得られるようになります。また、MMVQ 演算の再利用により、特定の量子化形式での推論速度が向上する可能性があります。

根拠のリンク

PR #1367: prompt attention: STRATA_PROMPT_ATTN_IMMA=1

PR #1418: cuda: opt-in MMVQ activation reuse across output rows

利用者の報告

RTX 4070 Laptop (sm_89) 環境で、IMMA カーネルを使用した場合、v2 カーネルと比較して精度が向上し、速度も若干改善したという報告があります [9]。

しかし、4x RTX 5080 (sm_120) の環境では、IMMA カーネルを使用しても速度向上は見られず、むしろ greedy な回答の一部が異なる結果になるケースが報告されています [10]。

Pascal GP100 (compute capability 6.x) 環境では、`STRATA_Q8_SM60=1` を有効にすることで、デコード速度が 28.3 tok/s から 38.9 tok/s (+37%) に向上したという報告があります [11]。

出典

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

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