メインコンテンツまでスキップ

Strata：12 GB のカードで 94 tok/s を出す 125B MoE と、その正確な代償

上級
What you'll learn
  • 125B モデルを 12 GB のカードで対話可能にする 3 つのアーキテクチャ上の事実を理解する。そのどれもが「積極的な量子化」ではない理由も含めて
  • Strata 自身のベンチマーク表を正直に読む。見出しの 94 tok/s は量子化ラダーの*最下段*であり、最上段の量子化ではその 43% を失う
  • 品質の代価を正確に見積もる。SWE-bench Verified の 91.3% と LiveCodeBench の 98.7% を並べ、その差からプルーニングが実際にどこで効くかを読み取る
  • README の見出しには載っていない 4 つの落とし穴を知る。needle-in-haystack には通るのに、長文ドキュメントの精度を静かに落とすデフォルト設定も含む
  • 自分の用途に対して、Strata、素の llama.cpp と --n-cpu-moe、ホスト型 API のどれを選ぶかを決める

2026 年 9 月 24 日、Strata というリポジトリがワンクリックのインストーラーとともに現れ、 誤植のように読める主張を掲げました。1,250 億パラメータのマルチモーダルモデルを ゲーミング PC で、会話できる速度で動かせる、というものです。 10 日後には 10,622 スター、935 フォーク、265 件のオープン issue を集め、 Hacker News のスレッドは 473 ポイント、245 コメントに達しています。あるコメント投稿者は この状況をこうまとめました。「世界中の LLM スレッドが Strata のリンクでスパム状態だ」

この主張は本当です。面白いのはその代償のほうですが、それを書き残している人はほとんどいません。 プロジェクト自身の見出しの数字には、精度の列がまったく含まれていないからです。このページがそれを補います。

一文でまとめると​

Qwen3.8-Flash-Next は 1 トークンあたり 125B のうち約 6B しかアクティブにしません。 そこで Strata はトークンごとの経路（アテンション、ルーター、共有エキスパート、出力ヘッド）を VRAM に置き、 24,576 個すべてのエキスパートをシステム RAM に固定（pin）し、28.8 GB のルックアップテーブルを SSD からストリーミングします。 エキスパートをストリーミングする他のエンジンが妥協するバッチ速度ではなく、対話的な速度を手に入れているわけです。

Colibrì を読んだ方なら、 これは同じ階層構造の反対側の端だとわかります。Colibrì はエキスパートをディスクに置いて、 744B パラメータのモデルを 0.05〜6.8 tok/s で動かします。Strata はエキスパートを RAM に置き、 その 5 分の 1 のサイズのモデルを 44〜94 tok/s で動かします。階層も用途も違います。 一方は夜間バッチ向け、こちらは実際に待ちながら使うコーディングエージェント向けです。

3 つのアーキテクチャ上の事実。どれも「量子化」ではない​

トリックは強引な圧縮だと思われがちです。圧縮も使われてはいますが、仕事の大半をしているのはモデルの 3 つの性質です。 それを知っておけば、自分のマシンでの挙動を予測できます。

1. スパース比はおよそ 20 対 1​

項目値
Transformer の総パラメータ数125B
1 トークンあたりのアクティブ数約 6B
1 層あたりの MoE エキスパート数512（ルーティング 10 + 共有 1 がアクティブ）
層数48
モデル全体のエキスパート数48 × 512 = 24,576
隠れ層サイズ2,560

512 個のうち 10 個のルーティングエキスパートということは、任意のトークンで触れられるエキスパート群は およそ 2% です。つまりエキスパートの重みは大きいけれど「冷たい」。メモリ階層の下へ押し下げるのにまさに向いた性質です。 熱いまま残るトークンごとの経路は十分小さく、12 GB のカードに収まります。

2. モデルは「125B」より大きく、RAM 上ではファイルサイズより小さい​

これが、意外に控えめな 32 GB という RAM の下限を説明する事実ですが、ほぼ必ず間違って報じられています。

Qwen3.8-Flash-Next は全体で 176.9B パラメータです。125B の Transformer、 51B の n-gram 埋め込みテーブル、4B の multi-token-prediction モジュールからなります。 n-gram テーブルはプロンプト検索（prompt lookup）に使う固定のルックアップ構造で、行列積には使われないため、 常駐させる必要がありません。Strata はこれを SSD からバッファなしで読み込みます。

ISTA-DASLab の Coder リリースを実例にしましょう。

コンポーネントファイルサイズRAM に常駐するか格納形式
Transformer の重み（512 中 256 エキスパートを保持）29.6 GBする元の 125B に対して実効 1.89 bpw
N-gram テーブル28.8 GBしない（SSD から読む）固定 4.5 bpw
ディスク上の合計58.4 GB常駐は 29.6 GBBF16 では 354 GB

つまり 58 GB のダウンロードに対して、メモリ予算は 29.6 GB です。これが 32 GB マシンが対応リストに入っている理由のすべてです。 また、このモデルを機械式ドライブに置くのが「遅い選択」ではなく設定ミスである理由でもあります。 テーブルはすべてのプロンプトで熱い経路に載るからです。

3. KV キャッシュが育つのは 48 層中わずか 12 層​

Flash-Next はハイブリッドアテンションのモデルです。4 層のうち 3 層は Gated DeltaNet（GDN）を使います。 これは履歴を固定サイズの再帰状態に圧縮する線形アテンションの仕組みです。残りの 1 層は Qwen Sparse Attention（QSA）を使い、コンテキスト全体にわたる精密な検索を担います。内訳は GDN 層が 36、QSA 層が 12 です。

ローカル推論ガイドが見落とし続けている帰結がここにあります。通常の 48 層 Transformer では、 コンテキストのコストは 48 層すべてに比例して増えます。ここでは 12 層分です。 262,144 トークンのネイティブウィンドウ（1M まで拡張可能）がコンシューマ向けハードウェアで現実的なのは、 量子化のおかげではなくこのためです。Strata が --kv-resident フラグを提供できるのも同じ理由で、 コンテキストキャッシュを RAM に置き、アテンションの作業セットだけを VRAM に置けます。

メモリマップ​

階層そこに置かれるもの
VRAMアテンションと DeltaNet のミキサー、ルーター、共有エキスパート、出力ヘッド、MTP ドラフト層、64K を超える部分の KV キャッシュの一部。さらに、残った VRAM を最も使われるエキスパートで埋めるエキスパートキャッシュ
RAM24,576 個すべてのエキスパート（固定）。キャッシュされていないエキスパートは、CPU が AVX-512/AVX2 カーネルでその場で計算し、GPU の処理と並行して動く
SSD28.8 GB の n-gram テーブル。バッファなしで読み込む（--ple-io direct。回転式ディスクでは --ple-io ram を使う）

エキスパートキャッシュを静的な分割よりうまく機能させる仕組みが 2 つあります。同梱のエキスパートプロファイルが、 学習データ上での発火頻度で 24,576 個のエキスパートすべてを順位付けするため、キャッシュは最初から温まっています。 さらに 0.1.31 からはルーターのルックアヘッドがあります。CPU がある層を処理している間に、 バックグラウンドスレッドが次の層のルーターを走らせ、どのエキスパートが必要になるかを予測して、 その OS ファイルキャッシュのページを先読みします。I/O と計算が重なるわけです。 その上で適応型の階層システム（--adapt-every）が、実際の会話に合わせてキャッシュを再編成します。

ベンチマーク表を正直に読む​

以下はプロジェクト自身の測定値です。量子化の列がそれらに何をもたらすかに注目してください。

RTX 5070（12 GB）、Ryzen 5 7600、64 GB RAM

量子化デコード（tok/s）プリフィル（tok/s）
Q2_0942,650
IQ2_XS792,090
IQ3_XXS621,750
IQ3_S531,620
Coder（プルーニング済み）552,180

RX 9070 XT（16 GB）、Ryzen 9 3900X、47 GB RAM

量子化デコード（tok/s）プリフィル（tok/s）
Q2_0601,160
IQ2_XS521,110
Coder（プルーニング済み）441,420

見出しの「94 tok/s」は Q2_0、つまり最下段です。プロジェクトが最高品質とラベル付けしている IQ3_S は 53 tok/s で動きます。 ラダーを上がるために、宣伝されている速度の 43% を差し出すことになります。コミュニティの報告が残りの分布を埋めますが、 そのばらつきは大きいものです。4090 と 128 GB の DDR5、7950X3D の組み合わせで 124 tok/s。 3600X と 3080（10 GB）で約 30 tok/s。RTX 2060 では Q2_0 で 33 tok/s、IQ3_XXS で 21 tok/s。 M1 Max の 3 ビットで約 25 tok/s。GPU なしの 96 GB 搭載 8845HS ノート PC ではデコード 7 tok/s、プリフィル 60 tok/s です。

このリストはランキングではなく法則として読んでください。デコード速度は GPU のクラスではなく、 RAM 帯域と量子化レベルに追従します。 Q2_0 で 2060 が 3080 を上回るのは測定ミスではありません。 カードは熱い経路を保持し、システムメモリがエキスパートをストリーミングしているのです。

品質の請求書​

ここからが、見出しの数字が語らない部分です。使われている圧縮は 2 種類あり、壊れ方が違います。

GSQ：量子化器​

Gumbel-Softmax Quantization は、グリッドの割り当てとグループスケールを同時に学習する、 学習後のスカラー量子化です。低ビット幅でのベクトル量子化との通常の差を縮めつつ、 ファイルは標準的な GGUF としてロードできます。保持されたエキスパートは 1 重みあたり 3.5 ビットに落ち着きます。

RCO：プルーナー​

Riemannian Constraint Optimization は、どのエキスパートを削除するかを選びます。 実行可能集合を滑らかな多様体として扱うため、層ごとの予算がペナルティ係数の調整なしに厳密に守られ、 層ごとに異なる予算を同時に扱えます。Coder リリースは各層 512 個のうち 256 個のエキスパートを残します。 1 トークンあたりのアクティブ数は 10 のままで、コード、エージェント、ビジョンのデータでキャリブレーションされています。

プルーニングの代償を実測する​

ベンチマークBF16 ベースGSQ-RCO Coder維持率
SWE-bench Verified82.8075.6091.3%
LiveCodeBench v687.4386.2898.7%

これを「だいたい同じ」と読んではいけません。この 2 つの差こそ、このページで最も役に立つ数字です。

LiveCodeBench は短いホライズンのタスクです。問題を読み、解答を出力する。エキスパート群の半分が消えていることにほとんど気づきません。 落ち幅は 1.3% です。SWE-bench Verified は実際のリポジトリを相手にした長いエージェント的軌跡を走らせるため、 同じモデルが 7.2 ポイント落ちます。同じ重み、同じ量子化で、相対的な損失は 6 倍です。

エキスパートのプルーニングが奪うのは知識ではなく、ホライズンです。 モデルは関数の書き方を今も知っています。 劣化するのは、40 回のツール呼び出しにわたって計画を保ち続ける力、つまりエージェント型のコーディングループを構成するまさにその能力です。 あるコメント投稿者はこれを「ロボトミー」と呼びましたが、この 2 つのベンチマークの組がその証拠です。

作者たちも、対応する適用範囲の限界を明言しています。キャリブレーションはコード、エージェント、ビジョンのデータを対象としており、 「この範囲外での劣化は受け入れたコスト」だというのです。Coder 版を散文、翻訳、コード以外の推論に向ければ、 設計上の分布外になり、どこまで悪化するかを示す公表値はありません。

見出しには載っていない 4 つの落とし穴​

Watch out
  • ESP と呼ばれる高速化モードは、プロジェクト自身の文書で拒否方向を取り除くものと記載されています。これは性能機能の中に出荷された安全面の挙動変更です。「より速いモデル」ではなく「別のモデル」として扱ってください。

1. ESP は速度と引き換えに、アライメントと出力分布を犠牲にします。 プロジェクト自身の文書によれば、 この速度射影の経路は拒否方向を取り除くことで安全性を下げ、コードの perplexity を 15% 引き上げ、 素のモデルとの top-1 トークン一致率を約 93% まで下げます。次トークン選択での 7% の不一致は、長い生成の中で大きく積み重なります。 有効にした時点で、あなたはもうベンチマークしたモデルを動かしていません。

2. 4 ビット KV は needle テストに通るのに、長文ドキュメントの精度を失います。 同梱のデフォルトは 8 ビット KV です。 --kv q4_0 は量子化の前に Hadamard 回転を適用し、キャッシュメモリを半分にして、128K で約 4% 高速になりますが、 その代わり長文ドキュメントでの perplexity が 8〜12% 高くなります。文書には needle テストは依然として通ると書かれています。 そこが罠です。needle-in-haystack の検索が生き残ることは、長いコンテキストでの推論が生き残った証拠にはなりません。 インストーラーは 4K を超えるコンテキストで 4 ビットを勧めてきます。つまり、その意味を理解する理由がまだないうちに、 この判断を迫られることになります。--kv k8v4 というハイブリッド（8 ビットのキー、回転済み 4 ビットの値）もあり、 KV メモリを 23% 減らせますが、プロンプトは目に見えて遅くなります。

3. 同一の重みでもエンジンが違えば答えが違います。 ある HN のコメント投稿者は、50 枚の画像による座標位置特定のベンチマークを、 同じ GGUF と同じビジョンアダプタを使って両方のエンジンで走らせました。Strata の誤差は中央値 154.8 ピクセル（平均 168.8）、 llama.cpp は 46.5（平均 81.4）でした。投稿者の評価では、この差は「9B モデルから 35B モデルへの飛躍と同じくらい大きい」とのことです。 プロジェクトの文書は、同じ系統の問題としてもっともらしい仕組みを示しています。IQ-pack のマルチトークンカーネルは、 シングルトークンの CPU 経路とは丸め方が異なり、0.1.30 で再現性のためのオプトインフラグ（STRATA_IQ_MT_MIN=1）が追加されました。 この教訓はこのプロジェクトを超えて一般化できます。すでに持っている重みで新しいエンジンが大幅な高速化を謳うなら、 出力を信用する前に、自分のタスクで自分の評価を走らせてください。「同じファイル」は「同じ答え」を意味しないからです。

4. 262K を超えると未検証の領域です。 ネイティブウィンドウを超えると yarn RoPE スケーリングが適用されますが、 文書はこれを実験的と述べており、品質は 1 台のマシンでしか測定されていません。150K 以上でのツール呼び出しの失敗やスペルミスの コミュニティ報告は、この注意書きと整合しています。

最初のトークンを出すまで​

Guided walkthrough1 of 5
  1. 最低要件は、NVIDIA RTX 20/30/40/50 シリーズ、または対応する AMD Radeon（RX 7700 XT 以上、RX 9060 XT、RX 9070/9070 XT、Radeon AI PRO R9700、RX 6800/6900）の 12 GB VRAM、32 GB のシステム RAM、約 80 GB の空き容量です。ストレージは SSD にしてください。28.8 GB の n-gram テーブルはプロンプトごとに読み込まれるため、回転式ディスクは遅い構成ではなく、壊れた構成です。

API キーを付けてサーバーを LAN に公開する

START-HERE.bat --setup --host 0.0.0.0 --api-key <your-secret>

知っておくべきフラグと、それぞれが何と引き換えか

--ple-io direct      # unbuffered n-gram table reads (use 'ram' on a rotational disk)
--kv-resident 32768  # keep the context cache in RAM, only attention's working set in VRAM
--prefill auto       # chunk prompts up to 8,192 tokens for GPU streaming
--pcie-frac N        # share of missing experts fetched over PCIe vs computed on CPU
--pool-workers N     # CPU threads computing non-cached experts
--adapt-every N      # how often the expert cache re-ranks around your conversation
--kv q4_0            # halve KV memory: ~4% faster at 128K, 8-12% worse perplexity on long docs
--kv k8v4            # 8-bit keys, rotated 4-bit values: 23% less KV memory, slower prompts
--spec-min-p         # draft-acceptance confidence threshold for speculative decoding
What you'll learn
  • 設定は CLI 引数、モデルごとの strata-<model>.json の args ブロック、STRATA_* 環境変数に分かれており、どれがどこに属するかは文書で一貫して説明されていません。便利な環境変数には、STRATA_PF_FUSED（融合プロンプトカーネル）、STRATA_DECODE_TIMING=1（デコードウィンドウのプロファイル）、STRATA_RESIDENT_PIN=0（RAM が少ない常駐モードでのページロック無効化）、STRATA_IQ_MT_MIN=1（再現性のためのシングルトークン経路の丸め）があります。

実際にどの段を選ぶべきか​

用途選ぶもの理由
エージェント型コーディング、長いツール呼び出しの軌跡IQ3_S のフルモデル、または Unsloth UD-IQ4_XS（RAM 約 80 GB）SWE-bench ではプルーニングが 7.2 ポイントの代償になります。主力の作業でそれを払ってはいけません
単発のコード生成、スニペット、レビューCoder（プルーニング済み、RAM 32 GB）エキスパート群が半分で LiveCodeBench の 98.7%。プルーニングが想定している段はここです
ビジョンと座標の作業ggml-org/Qwen3.8-Flash-Next-GGUF を使った素の llama.cpp同一の重みでの唯一の直接比較は、位置特定の誤差で llama.cpp が 3 倍優れていました
使い捨てのドラフト用に最大の tok/sQ2_094 tok/s。あるコメント投稿者の情報理論的な見積もりでは、2 ビットでモデルの「記憶」の約 80% が残ります。ドラフトには十分ですが、事実には不十分です
長文ドキュメント、128K 以上のコンテキストフルモデル、8 ビット KV、262K 以内に収める4 ビット KV も yarn スケーリングも、文書上は損失あり、または実験的です
速度より信頼性--n-cpu-moe を使った素の llama.cpp同じハードウェアでは遅いものの、あなたの評価の比較対象にすべきリファレンス実装です
間違いの代償が大きいもの全般ホスト型 APIこのハードウェアを持っている人たちの HN での総意は、負荷の高い仕事では今もクラウドが既定だというものです

正直なベースライン：--n-cpu-moe を使った llama.cpp​

Strata はゼロから作られたエンジンではありません。llama.cpp / ggml（MIT）の上に作られ、 上流から i-quant の GPU カーネルを書き写し、llama.cpp の量子化 MMQ ドット積カーネルを使い、 ビジョンエンコーダは llama.cpp の mtmd ライブラリから取り入れています。パッケージングと Flash-Next 固有のスケジューリングが貢献部分です。 これは実用上重要で、ベースラインはフラグ 1 つ先にあります。

--n-cpu-moe N は、最初の N 層の MoE フィードフォワード重みを CPU に移します。 理屈は、このページの冒頭と同じスパース性の議論です。エキスパートの束は大きくてめったに触れられないため、 速度の犠牲が最小で、最も多くの VRAM を節約できます。一方、アテンション、埋め込み、KV キャッシュは小さく、 毎トークン触れられるので GPU に置くべきです。VRAM が多いほど N を小さくでき、CPU 側がボトルネックになるまでの上限も高くなります。 モデルがすでに VRAM に収まっているなら、N を上げるとスループットは着実に落ちます。このフラグは収めるための手段であって、速くするための手段ではありません。

報告されているコミュニティの数字では、llama.cpp は約 21 tok/s、同等のハードウェアで Strata は 100+ tok/s に達します。 これは現実の、大きな差です。同時に、公開 10 日のコードベース、265 件のオープン issue、文書化されたカーネル丸めの乖離、 精度の列がないことと引き換えに買っている差でもあります。見出しではなく、意図して決めてください。

What you'll learn
  • このモデルの GGUF エコシステムは異例なほど混み合っています。ISTA-DASLab の GSQ-RCO リリース（ダウンロード数 1.89M と 351k）、unsloth（1.4M）、公式の ggml-org ビルド、bartowski、そして abliterated や「uncensored」といったコミュニティ製バリアントが複数あります。ダウンロード数は人気であって品質ではありません。ベンチマーク表を公開しているのは ISTA-DASLab の 2 つのリリースで、比較の基準にするリファレンスビルドは ggml-org のものです。

このハイプサイクルが実際に教えていること​

特定のプロジェクトを取り除いても、持続する 3 つの教訓が残ります。次に流行するエンジンにも当てはまるはずです。

  1. 大きなモデルをローカルで動かせるようにするのは圧縮ではなく、スパース性です。 アクティブ 6B の 125B MoE は、 32B の密モデルよりコンシューマ向けハードウェアで快適に動くことがあります。課される制約が VRAM 容量ではなく、 RAM の容量と帯域だからです。総数より先にアクティブパラメータ数を確認しましょう。
  2. 圧縮に決まるのは大きさではなく、形です。「91% 維持」と「99% 維持」は、同じ日に同じ成果物から出てきました。 どちらの数字になるかは、タスクが短いホライズンか長いホライズンかで完全に決まります。維持率の数字がどのベンチマークで測られたのかを尋ねましょう。
  3. エンジンはモデルの一部です。 同一の重みが、2 つのエンジン間で位置特定誤差に 3 倍の差を生みました。 カーネルは丸め、キャッシュは量子化し、速度モードは射影します。評価はチェックポイントだけでなく、エンジンまで含めて行う必要があります。

Check yourself

0/6
  1. 32B の密モデルでは苦しいのに、ここで 125B パラメータのモデルが 12 GB の GPU で動くのはなぜですか。
  2. Coder バリアントは LiveCodeBench v6 の 98.7% を維持しますが、SWE-bench Verified では 91.3% しか維持しません。この差は何を示していますか。
  3. 4 ビット KV キャッシュを有効にしても、128K での needle-in-haystack テストは通りました。これで何が確かめられましたか。
  4. 58.4 GB のダウンロードが、システム RAM は 32 GB で足りるとされています。これが矛盾でないのはなぜですか。
  5. 同じ GGUF と同じビジョンアダプタで、位置特定誤差の中央値が一方のエンジンでは 154.8 px、もう一方では 46.5 px でした。正しい結論はどれですか。
  6. llama.cpp の --n-cpu-moe フラグは何をするもので、上げるとどんな場合に悪影響が出ますか。
Enter キーまたはスペースキーでカードを裏返します。左右の矢印キーでカードを移動できます。用語を表示しました。
1 / 11

出典と参考文献​

次へ​