Niko1221

Strata の新x2 GPUモード（all-cards split）を RTX4060Ti/16GB×2 で動かした件（最新0.2.11 の結果追記） Strata の新x2 GPUモード（all-cards split）は、本家が未検証の民生品GeForce で、DGX Spark の 2.3 倍速でエージェントが回ったという驚く結果に！ 本文の数字は Strata 0.2.10（エンジン 0.1.56）で 2026-11-04〜05 に測ったものです。その直後の 11-05 に 0.2.11 が出たので、同じ PC・同じ手順で測り直しました。その結果を先に書きます。 ★追記：0.2.11 が登場！追加測定！ 0.2.11 が出た直後、SNS で「速度が倍近くになった」という投稿を見かけました。分割エンジンにも速くなる変更が入ったとのことだったので、この PC でも試しました。 結論から書きます。 - 0.2.11 の分割エンジンも、16GB×2 で動いた。 本家のリリースノートでは、16GB×2 で確かめたのはレイヤー分割だけで、分割エンジンは試されていません。 - ただし、速くなったのは 3〜4%。 倍にはなりませんでした。品質は変わりません。 - 本文の結論（生成は最速、出力 約 730 トークンが分かれ目、品質は同じ、256K で使える）は、0.2.11 でもそのまま当てはまる。 !0.2.11 と 0.2.10 の比較 条件は本文と同じです（ShareGPT 200 件を 1 件ずつ送る c=1 は、個人で使うときの条件）。設定は変えず、エンジンのバイナリだけを 0.2.11 にしました。各 1 回の測定なので、3〜4% の差は測り直すたびの揺れの範囲かもしれません。「遅くはなっていない」と読むのが安全です。 | | 0.2.10 | 0.2.11 | 変化 | |---|---|---|---| | 短い出力の速さ（生成トークン ÷ 所要時間） | 35.70 tok/s | 37.25 tok/s | +4.3% | | 長い出力の速さ（max_tokens 1024） | 49.44 tok/s | 51.12 tok/s | +3.4% | | デコード中央値（長い出力） | 58.85 tok/s | 61.0 tok/s | +3.7% | | プロンプトを読む時間（短い出力、中央値） | 2.49 秒 | 2.39 秒 | −4.3% | | JamC-QA（日本語 4 択 2,309 問） | 64.96% | 64.79% | 差なし（p=0.65） | | 200K トークンの新しいプロンプトを読む時間 | 150.3 秒 | 155.5 秒 | +3.5%（遅くなった） | なぜ倍にならなかったのか 倍近い数字は、この PC とは違う構成のものでした。 リリースノートを読むと、大きく伸びたのは主に AMD Radeon を 4 枚挿した分割エンジン（もともとレイヤー分割より遅かった構成が追いついた）と、レイヤー分割や 1 枚の構成です。NVIDIA の分割エンジンについては、デコードの数字が載っていません。載っているのは、48GB のカード（RTX A6000）2 枚でプロンプトを読む時間が 10〜12% 短くなった、という数字だけです。 NVIDIA の分割エンジンで変わったのは、主にプロンプトを読むときの既定値でした。 0.2.11 は、プロンプトを読むときに一度に処理する行数を、空き VRAM に合わせて自動で選びます。48GB のカードなら大きく取れますが、16GB のこの PC では空きが足りず、一番小さい設定が選ばれました。手で大きくしてみると、起動できないか、起動できても GPU に置けるエキスパートが減って、読みもデコードも大きく遅くなりました。0.2.11 の自動の選び方は、この PC ではほぼ最適です。 この PC の遅さの原因には、0.2.11 の変更が届いていませんでした。 この PC ではエキスパートの約 7 割が RAM にあり、プロンプトのたびにそれを PCIe で運ぶ時間が効いています（本文の「リクエストごとのオーバーヘッド」）。ここは 0.2.11 でも変わっていません。本家には issue で報告しています。 デコードの +3% 程度は、共有エキスパートの計算をほかのエキスパートと 1 回にまとめる変更によるものと考えられます。 この変更がこの PC でも有効になっていることは、ソースと起動ログで確かめました（切り分けて測ってはいません）。 リリースノートの数字は、それぞれの構成では正しいのだと思います。ただ、自分の構成でどれだけ速くなるかは、測ってみないと分かりません。当ラボの OpenCode の推論先は、この結果を見て 0.2.11 に切り替えました。 ここからは、0.2.10 で測った本文です。 --- はじめに Strata 0.2.10（2026-11-02）で、GPU を 2 枚使う新しいモード「all-cards split engine」が入りました。従来の「レイヤー分割」は、カード A が前半の層、カード B が後半の層を持ち、交互に働く方式です。新しいモードは、2 枚のカードが全レイヤーを少しずつ分担して、同時に動きます。本家が試したのは RTX A6000 48GB×2 と RTX PRO 6000×2 だけで、ドキュメントには「GeForce の 2 枚組は 1 台も無いので未検証」と書かれていました。 当ラボには、RTX 4060 Ti 16GB を 2 枚挿した GPU サーバ（自作 PC）があります。これで動くのか、動いたとして速いのか、OpenCode のようなハーネスの推論先に使えるのか。結論から書きます。 - 動いた。 ただし配布物のままでは動かず、ビルド・起動チェックの切り替え・memlock の上限・エキスパートの追い出し方、の 4 か所に手を入れた。パッチは本家に PR 済み。 - 生成は最速。 同じ PC のレイヤー分割 2 枚より 1.2 倍、1 枚より 1.6 倍。ただしリクエストごとに約 1.4 秒のオーバーヘッドがあり、出力 約 730 トークンを境に有利不利が入れ替わる。 - 品質は同じ。 JamC-QA（日本語 4 択 2,309 問）で 64.96% 対 65.09%。 - コンテクスト長 256K で起動でき、200K を埋めた直後でも 49 tok/s。 - エージェントの実務（GembaBench）では、レイヤー分割 2 枚より 1.3 倍速く、DGX Spark より 2.3 倍速く、点数は同じ。 !fig1_structure.png all-cards split とは何か Qwen3.8-Flash-Next は 125B の MoE（Mixture of Experts）で、各層に 512 個のエキスパートがあり、トークンごとに 10 個が選ばれます。Strata の売りは「VRAM に載らないエキスパートは RAM に置き、必要になったら持ってくる」仕組みで、これで 16GB のカード 1 枚でも 125B が動きます。 従来の 2 枚対応はレイヤー分割でした。カード A が層 0〜23、カード B が層 24〜47 を持ち、A が働いている間 B は待ちます。2 枚あっても、同時に働くのは 1 枚です。 0.2.10 の all-cards split は、John Fink 氏の sFNX というエンジンを取り込んだもので、全カードが全レイヤーの一部ずつを持ち、同時に重みを読みます。層ごとに各カードの計算結果（部分和）を交換する必要があり、本家の A6000 では PCIe 越しにカード同士が直接やり取りします。GeForce にはその機能（P2P）が無いので、Strata 版はホストメモリ経由で交換するように書き換えてあります。つまり、仕組みの上では GeForce でも動くはずでした。 機材 | 部品 | 製品 | |---|---| | CPU | AMD Ryzen 5 5600（6 コア） | | マザーボード | GIGABYTE X570 AORUS PRO WIFI（PCIe 4.0 x8 ＋ x8、両方 CPU 直結） | | メモリ | DDR4-3200 32GB ×4（128GB） | | GPU | NVIDIA GeForce RTX 4060 Ti 16GB ×2 | | 電源 | 850W | | OS など | Ubuntu 22.04.4、NVIDIA ドライバ 615.71.09、CUDA 13.4 | | モデル | Qwen3.8-Flash-Next GSQ-RCO IQ3_S（本家配布の 3bit 量子化、78GB）＋ MTP の下書き層 | RAM 128GB が要るのは、エキスパートの複製（約 45GiB）と埋め込みテーブル（27.5GB）を pinned メモリに置くためです。64GB では足りません。 余談： RTX 4060 Ti 16GB は、省電力と引き換えに PCIe 4.0 x16 スロットに挿しても x8 でしか動かないのですが、この X570 マザーボードは 2 本の PCIe 4.0 x16 がどちらも CPU 直結で x8 として動かせるので、実はちょうどいいんですよ。 動くまでの 4 つの壁 壁 1: sm_89 向けのバイナリが無い 分割エンジンはカードのアーキテクチャごとに別バイナリで、配布されているのは sm_86（A6000）と sm_120（RTX PRO 6000）だけです。4060 Ti は sm_89 なので、本家のビルドスクリプト（packaging/build_split_cuda.sh）に ARCH=89 を指定して自分でビルドしました。sm_89 ならではのエラーは出ず、約 8 分で通りました。 壁 2: 起動チェックが「全エキスパートが VRAM に載る構成」しか通さない ランチャーには 2 つのチェックがあります。「実績のあるアーキテクチャか」は環境変数 STRATA_SPLIT_ALLOW_UNTESTED=1 で通せますが、もう 1 つの「ルーティングされるエキスパートが全部カードに載るか」（IQ3_S なら 1 枚あたり約 31GB 必要）は、16GB では満たせず、回避する手段もありません。 ところが、エンジン本体のソースを読むと、VRAM に載らない分を RAM に置き、無ければ取りに行く仕組み（Strata の 1 枚モードと同じ考え方）が、分割エンジンにも入っていました。ランチャーが「全部 VRAM」に決め打ちしていただけです。ここを環境変数で切り替えられるようにしました（既定は本家どおり）。 壁 3: memlock の上限 エンジンは約 80GiB を pinned メモリに置きます。ふつうの Linux PC は ulimit -l が 16GiB 程度なので、埋め込みテーブル（27GB）を固定しようとしたところで止まります。起動するプロセスにだけ prlimit --memlock=unlimited をかけて通しました。本家のワークステーションでは無制限なので、表に出ていなかった問題です。 壁 4: 大きいエキスパートから先に追い出され、起動できない いちばん手こずったところです。IQ3_S は層ごとにエキスパートの量子化が違うので、エキスパートの大きさも層によって違います。エンジンはこれを大きさごとに 7 つの「プール」に分けて管理していて、どのプールも、処理に必要な数（320 個）は GPU に残しておく必要があります。 VRAM に入りきらないエキスパートは「使用頻度 ÷ バイト数」の小さい順に RAM へ追い出されます。すると、大きいエキスパートのプール（3 層分、1,536 個）から先に削られ、320 個を割って起動できません。かといって追い出す量を減らすと、今度は VRAM があふれます。両立する設定がありませんでした。 直し方は、「プールに残る数が N を下回ったら、そのプールからは追い出さない」という下限を choose_residency() に入れることです（約 15 行、既定は 0 で本家どおり、FNX_POOL_MIN_RESIDENT=384 で有効）。これで起動し、最初の質問に答えました。 !図 2: プールの模式図 速さ 同じ PC の 4 構成を同じ手順で ShareGPT 200 件、1 件ずつ（c=1、個人利用の条件）、コンテクスト長 8K、MTP あり、思考オフ。サーバーのログから再計算した値です。 !図 3: 4 構成の棒グラフ。総スループット・デコード・プロンプト読みの 3 本 デコードは分割エンジンが最速ですが、プロンプトを読むたびに 2〜5 秒のオーバーヘッドがあり、短いやり取りが多いこの測定では、総合でレイヤー分割に負けました。 | | S（分割、初期設定） | S2（分割、読み方を調整） | L2（レイヤー分割 2 枚） | L1（1 枚） | |---|---|---|---|---| | 総スループット（生成トークン ÷ 所要時間） | 23.3 tok/s | 35.7 | 40.6 | 32.3 | | デコード中央値 | 57.5 | 58.2 | 48.7 | 36.3 | | プロンプト読み中央値 | 4.98 秒 | 2.49 | 1.05 | 1.01 | オーバーヘッドの正体 プロンプトは「先頭の N−6 行」と「末尾の 6 行」の 2 回に分けて読まれます。各回で、RAM にあるエキスパート（この PC では 7 割）を「GPU が PCIe 越しに RAM から直接読む」か「まとめて VRAM に運んでから読む」かが選ばれ、その境目が FNX_PF_STAGE_ROWS（既定 2048 行）です。本家の想定では全エキスパートが VRAM にあるので、直接読むほうが速い。この PC では逆で、短いプロンプトでも直接読むと 2〜6 秒かかっていました。 境目を 8 に下げると、先頭はまとめて運び（1.6 秒）、末尾の 6 行は直接読む（0.3 秒）ようになり、短いプロンプトの読みが 3.0 → 2.0 秒、780 トークンが 6.0 → 2.4 秒になりました（上の表の S2）。残る 1.6 秒は「各カードが 16.7GiB を PCIe 4.0 x8 で運ぶ」時間そのもので、設定では消えません。 出力が長いと逆転する 出力を 1,024 トークンまで伸ばして同じ 200 件を流すと、S2 49.4 tok/s、L2 49.3 tok/s で並びました。デコードが 13% 速い分と、1.4 秒のオーバーヘッドが、ちょうど相殺する形です。分かれ目は出力 約 730 トークン。コード生成や長い文章では分割エンジンが上、短いやり取りのチャットではレイヤー分割が上、ということになります。 品質 JamC-QA（日本語の 4 択、2,309 問、思考オフ）で、分割エンジン 64.96%、レイヤー分割 65.09%。同じ答えが 96.3%、McNemar 検定で p=0.81。演算の順序が違っても、正答率には出ませんでした。 コンテクスト長 OpenCode で使うには 256K が要ります（足りないと、セッションを最初からやり直すことになります）。--max-context を 64K → 128K → 256K と上げても、起動時に GPU に置かれるエキスパートの数は変わりません（K/V はコンテクストが伸びるたびにエキスパートの置き場を借りて広がる作り）。256K で 200K トークンの新しいプロンプトを 150 秒（約 1,330 tok/s）で読み、直後のデコードは 49 tok/s（短いプロンプトのときの 81%）でした。続きのターンは会話キャッシュが効いて 2.4 秒です。 エージェントの実務で測る（GembaBench） 当ラボのエージェントベンチ GembaBench（OpenCode v2 に、使い捨ての VM 2 台のサーバー調査・修正を 6 課題やらせる。各 3 回、思考 medium・思考トークン上限 8192、判定 j14）で、分割エンジンとレイヤー分割 2 枚を、どちらも 256K で測りました。公開済みのほかの構成と並べます。 !図 4: 構成ごとの 18 本の所要時間の合計（横棒）と、生成速度の中央値 EVO-X2 は 2026-10-25 に Strata 0.2.4.1 の既定設定で測った値で、量子化が UD-IQ4_XS（この記事の IQ3_S より 1 段大きい）です。量子化が違うので、点数や速さは参考として見てください。「1 枚（10 月）」は 10 月に Strata の別の版で測った値で、所要時間は短いものの、成果物なしで終わった試行が 1 本あります。版が違うので、ほかの列と同じ条件の比較ではありません。 | | 分割エンジン（この記事） | レイヤー分割 2 枚 | 1 枚（10 月） | EVO-X2（Ryzen AI Max+ 395） | DGX Spark | |---|---|---|---|---|---| | エンジン・量子化 | Strata 0.2.10 分割エンジン・IQ3_S | Strata 0.1.56 通常エンジン・IQ3_S | Strata（10 月の版）・IQ3_S | Strata 0.2.4.1 既定設定・UD-IQ4_XS | SGLang・NVFP4 | | 18 本の所要時間の合計 | 5.7 時間 | 7.3 時間 | 5.4 時間 | 7.4 時間 | 12.9 時間 | | 生成速度の中央値（OpenCode 側） | 43.6 tok/s | 35.8 | 34.1 | 42.8 | 26.4 | | 点数（T1 F1 / T2 / T3 / T4 / T5 / T6） | 42 / 8 / 8 / 31 / 41 / 23 | 43 / 8 / 8 / 31 / 42 / 23 | 40 / 7 / 8 / 31 / 39 / 23 | 45 / 6 / 8 / 31 / 39 / 23 | 43 / 6 / 8 / 31 / 41 / 23 | | 成果物なしで終了（時間切れを含む、本数） | 0 | 0 | 1 | 0 | 3 | 点数はどの構成も同じ水準です（N=3 なので差とは言えません）。所要時間は、分割エンジンがレイヤー分割より 1.6 時間短く、DGX Spark の半分以下です。Spark が遅いのは、NVFP4 を SGLang で動かすデコードが 27 tok/s 止まりなのと、同じ課題でも出力トークンが 1.5〜2 倍に膨らむ傾向があるためです。 課題ごとに見ると、T2 だけはレイヤー分割が速く、T5 ではレイヤー分割のステップ数が倍でした。モデルの手数の振れも混ざっているので、速度差の全部がエンジンの差ではありません。 いくらで組めるか（2026 年 11 月の相場） | | 価格（2026 年 11 月） | 価格（1 年前） | |---|---|---| | DGX Spark 128GB | 98〜120 万円（2026 年 10 月に $6,950 へ値上げ） | 約 60 万円 | | GMKtec EVO-X2 128GB | 約 62 万円 | 約 30 万円（早期予約） | | この記事の PC（中古で組む場合） | 約 32〜36 万円 | 約 18 万円 | PC の内訳（中古相場）: RTX 4060 Ti 16GB が 1 枚 8.5〜9.5 万円（ヤフオクの落札、2026 年 10〜11 月）、DDR4 32GB ×4 が 10〜14 万円（新品の 64GB キットが 1 年で 4.5 倍）、CPU・マザーボード・電源・SSD で 4〜5 万円。値上がりの大半は GPU とメモリで、1 年前なら 18 万円で組めた構成です。それでも DGX Spark の 3 分の 1 の値段で、エージェントの実務が半分の時間で回ります。 !図 5: 価格と所要時間の散布図 まとめ - Strata 0.2.10 の all-cards split engine は、本家未検証の Linux GeForce 16GB×2 で動く。手を入れたのは 4 か所。配布物が「全エキスパートが VRAM に載る」前提で作られていただけで、エンジン本体は VRAM 不足も織り込んで作られていた。 - 生成は最速だが、リクエストごとに 1.4 秒のオーバーヘッドがある。出力 730 トークンが分かれ目。 - 品質は同じ、256K で使える、エージェントの実務ではレイヤー分割 2 枚より速く、DGX Spark の 2.3 倍速い。 - 0.2.11 でも動き、3〜4% 速くなった。当ラボでは OpenCode の推論先をこの構成（0.2.11）に切り替えた。 本家への報告と、パッチ・測定スクリプト: - issue（動作報告）: Strata#5187 - 0.2.11 の結果: Strata#5187 - issue（プロンプトの読み方を切り替える FNX_PF_STAGE_ROWS の既定値）: Strata#5440 - PR（プールの下限）: Strata#5258 - ブランチ（ビルド手順、パッチ 2 本、結果）: github.com/nabe2030/Strata/tree/split-geforce-16gb - GembaBench: nabe2030/gembabench

Run Qwen3.8-Flash-Next Locally with Strata: 64 GB Quickstart Qwen3.8-Flash-Next (QFN) has 125B total parameters, 6B active per token, and a native 256K context window. It has thinking enabled by default and records the highest agentic-coding benchmarks in its local-model class. <!--more--> This article describes running a 3-bit quantization of QFN on a 64 GB RAM desktop with an RTX 5090 using Strata, and documents why sub-Q4 quantizations do not produce reliable tool calls for agentic workloads. The install commands, the RAM each quantization pins, and the tool-call failures on a 64 GB desktop are below. Speed and failure figures mix runs on that machine — an RTX 5090, 64 GB of RAM, Ubuntu 26.04 — with reports on the Strata tracker and the 0.2.11 release notes. Commands and engine defaults were checked on 06/11/2026 against Strata 0.2.11, when the repository showed 40,836 stars and the engine packages were 0.1.57. Where this runtime sits next to Ollama, llama.cpp, and vLLM is the job of the [LLM hosting guide](glukhov.org "LLM Hosting in 2026: local, self-hosted, and cloud infrastructure compared."). What Strata Is The engine in this quickstart is Niko1221/Strata, MIT-licensed. A different project, the OSDI 2026 paper on hierarchical KV caching for SGLang, uses the same name. Strata builds on llama.cpp and ggml, and the repository includes a write-up at docs/paper/Strata-Paper.pdf. It runs Qwen3.8-Flash-Next across one consumer GPU, system RAM, and an SSD. The same engine also serves Qwen3.6-35B and DeepSeek V4.1-Flash. Qqwen 3.8 Flash Next has 24,576 routed experts across 48 layers; each token activates 10 experts (6B active params in total). Strata divides the model across three memory tiers instead of requiring it to fit in one. | Tier | Holds | Does | |---|---|---| | GPU (VRAM) | Attention, DeltaNet mixers, gated-residual weights, routers, shared experts, output head, the MTP draft layer, the KV cache (from 64K: the most-read part; the rest streams from RAM), plus an expert cache | Everything that runs per token; the expert cache fills whatever VRAM is left with the most-used experts and adapts to the conversation while it runs | | RAM | All 24,576 experts, pinned | The CPU computes the experts the GPU does not have, in place, at the same time as the GPU works on the cached ones (AVX-512/AVX2 kernels, ggml for the i-quants) | | SSD | The 28.8 GB n-gram embedding table | Read a few rows per token through the OS page cache | The 51B n-gram parameter block serves as a 20M-entry lookup table indexed by bigrams and trigrams. Because this is a lookup rather than a matrix multiplication, it can reside on an SSD with minimal runtime cost. VRAM capacity determines the scaling axis. Every additional gigabyte of VRAM holds approximately 700 experts, and each expert cached on the GPU reduces CPU compute. A slow card with more VRAM outperforms a fast card with less. RAM capacity is a hard constraint because all experts must be pinned for simultaneous CPU and GPU computation. Strata does not support lazy memory mapping to disk. Download size and RAM usage are nearly identical for QFN. How the decode speed is built Three mechanisms supply the decode rate. 1. Multi-token prediction. The checkpoint includes one MTP layer trained for multi-step drafts. Strata drafts up to 3 tokens and verifies them in a single pass over all 48 layers — the draft-verify cycle in the [speculative decoding guide](glukhov.org "Speculative decoding: draft-verify, MTP, n-gram, and engine setup."). The project measures average acceptance at 2.4–3.2 tokens per pass, and reports that as 1.6–1.8× decode speed with the same output. 2. Prompt lookup. The server pulls up to 5 draft tokens from earlier copies of the context when the model is repeating it, as in a code edit or a quotation. The project reports code edits 6–11% faster, and other text unchanged. 3. Chunked prefill. Prompts arrive in blocks of up to 8,192 tokens, and the next layer's experts move over PCIe while the current layer's attention runs. The project puts long-document and codebase ingestion above 1,000 tokens/s, and a follow-up starts within seconds because the conversation state stays resident. The server ships a local chat UI, as a desktop app or in the terminal, plus OpenAI- and Anthropic-compatible endpoints on localhost. Claude Code, Codex CLI, OpenCode, Hermes Agent, and OpenClaw attach through strata connect. Hardware the project lists: NVIDIA RTX 20/30/40/50 series (CUDA 13 engine packages need driver 580 or newer), AMD Radeon on HIP, Intel Arc on Linux, Apple Silicon, and AMD Strix Halo. Release 0.2.11 is Strata-0.2.11-linux-x86_64.AppImage for the desktop app; the terminal path below is the one this quickstart walks through. QFN Benchmarks Against Local Alternatives Alibaba's model card compares Flash-Next with Qwen3.8-27B, DeepSeek-V4-Flash (the 0731 checkpoint), and Claude Opus 4.6 (Max). | | QFN | Qwen3.8-27B | DeepSeek-V4-Flash | Claude Opus 4.6 (Max) | |---|---|---|---|---| | Total / active params | 125B / 6B | 27B / 27B | 284B / 13B | – | | N-gram embedding params | 51B | – | – | – | | DeepSWE 1.1 (agentic coding) | 58.7 | 42.2 | 54.4 | – | | SWE-bench Pro | 62.5 | 61.7 | 56.0 | 53.4 | | SWE-bench Multilingual | 81.0 | 73.8 | – | 77.5 | | Toolathlon Verified (tool use) | 73.5 | 67.1 | 70.3 | – | | JobBench (agentic office) | 55.7 | 33.4 | 41.3 | 36.6 | | CoWorkBench | 73.9 | 70.7 | 45.1 | 68.2 | | GPQA Diamond | 91.7 | 89.2 | 90.8 | 91.3 | | LiveCodeBench v6 | 91.9 | 90.3 | 90.6 | 88.8 | Agentic-coding rows on that card used temperature 1.0, top_p 0.95, and a 256K window. DeepSWE reports the higher of the Claude Code and mini-SWE-agent harnesses, and the card says Flash-Next's higher score is on mini-SWE-agent. SWE-bench Pro re-ran the baselines on a corrected task set; the Claude Opus 4.6 cell is the vendor's published score, and the other cells are Claude Code. Two rows on the same card go the other way. NL2Repo-Bench is 48.1 for Flash-Next and 54.2 for DeepSeek-V4-Flash. HLE, judged by GPT-4o, is 35.9 against Claude Opus 4.6 (Max) at 40.0. For agent work the card's defaults are preserve_thinking on, so the reasoning trace stays across turns, and reasoning_effort at xhigh. The other levels are medium and low. The [Qwen 4 family page](glukhov.org "Qwen 4: what Alibaba has confirmed, the 27B ladder, and what Flash-Next previews.") tracks what Alibaba has confirmed about this line, including the Qwen Community License 1.0 on these weights. The table above is the part that can be measured today. Quantization Builds and Sizes ISTA-DASLab GSQ-RCO The ISTA-DASLab GSQ-RCO GGUFs use non-uniform quantization. GSQ is low-bit scalar quantization per tensor, and RCO assigns a type per tensor inside a size budget. The method spends almost all of the compression on the routed experts, which are 95% of the searchable weights. Each build is two shards. The second is the n-gram table at about 4.5 bits per weight, and it can be mapped from disk. | Build | Avg bpw | Resident shard | N-gram shard | Total | Notes | |---|---|---|---|---|---| | Q2_0 | 2.40 | 37.6 GB | 28.8 GB | 66.4 GB | Speed build: avoids lookup-table formats; 367 prompt t/s, 93.8 decode t/s, 6.7 s avg latency (vs 12.7 s for IQ2_XS at nearly the same size) | | IQ2_XS | 2.50 | 39.2 GB | 28.8 GB | 68.0 GB | Smallest at equal quality | | IQ3_XXS | 3.00 | 47.0 GB | 28.8 GB | 75.8 GB | The tight-memory pick; matches the base model on AIME25, gives up ~1.5 points on GPQA-Diamond | | IQ3_S | 3.50 | 54.8 GB | 28.8 GB | 83.6 GB | ISTA's recommendation: matches or exceeds the base model on every task in their harness (GPQA-Diamond 92.93 vs 91.92) | Those GPQA figures are ISTA's harness, not the 91.7 on Alibaba's card. A Coder variant keeps 256 of the 512 routed experts per layer, at 58.4 GB and 1.89 effective bits per weight. A 0.91 GB BF16 vision projector is the multimodal add-on. The ISTA line stops at IQ3_S; it has no Q4 build. Unsloth packs in Strata 0.2.11 On 04/11/2026 Unsloth re-uploaded its Qwen3.8-Flash-Next GGUFs as Dynamic v3.1. The 0.2.11 release notes say Strata can download, prepare, and run seven of them from the app, from strata launch --family unsloth, or from a folder you already have. Each file is checked by size and SHA-256 against Unsloth revision d9620119. The last file of every set is the 28.8 GB per-token table. Sets that share a table share the file: UD-IQ1_M with UD-IQ2_XS, and UD-IQ3_XXS with UD-IQ4_XS-v31. | Name in Strata | Download | Files | |---|---|---| | UD-IQ1_M | 68.0 GB | 3 | | UD-Q2_0 | 70.6 GB | 3 | | UD-IQ2_XS | 75.8 GB | 3 | | UD-Q2_K_XL | 79.6 GB | 4 | | UD-IQ3_XXS | 83.6 GB | 4 | | UD-Q3_K_XL | 89.5 GB | 4 | | UD-IQ4_XS-v31 | 93.7 GB | 4 | UD-IQ4_XS-v31 is a different file from the UD-IQ4_XS Strata already offered: other tensor types, four files instead of three. UD-Q4_K_XL, UD-Q5_K_XL, UD-Q6_K_XL, and Q8_0 stay on the 30/09/2026 files. The 04/11 UD-Q4_K_XL is the same weights in a four-file split, and Strata accepts that split if you already have it. UD-IQ1_S does not load — one layer mixes two expert formats — so UD-IQ1_M is the 1-bit choice. UD-IQ4_XS-v31 uses the Q5_0 expert format in 33 layers. The same notes say Strata's Q5_0 math lands 1.2–1.3% from the exact result, against 2.6–3.0% for llama.cpp's formula on those tensors. On a Mac, the app rewrites the experts into one GPU file before the first start, so the disk budget is the download plus that file plus a few gigabytes (about 115 GB for UD-IQ1_M). If the 28.8 GB table stays mapped, the rest of UD-IQ4_XS-v31 is about 64.9 GB before KV cache, which is already past a 64 GB machine under Strata's pinning rule. UD-IQ1_M's remainder is about 39.2 GB. That file can fit where IQ3_S cannot, and it is a 1-bit pack, further from the tool-call behaviour measured below at 3 bits. Quickstart: Install, Launch, and First-Run Setup A Linux desktop needs an RTX 20/30/40/50 series card or another GPU the project lists, enough RAM for the chosen pack plus KV-cache headroom, and SSD space for the download. CUDA 13 engine packages need driver 580 or newer. Terminal install: curl -fsSL https://github.com/Niko1221/Strata/releases/latest/download/install.sh -o install.sh && sh install.sh strata launch strata launch asks for the model, the quantization, the context, the storage folder, and the access settings, downloads the engine for the card, starts the server, and shows a monitor with speed, memory, and request data. The default endpoint is http://127.0.0.1:8080. To see what fits before a 76 GB download, or to start without the prompts: strata launch --family qwen --model q2_0 --plan # dry run: what's missing, what fits strata launch --family qwen --model q2_0 --yes --no-tui # start in background strata launch --status strata connect # prints the config for Claude Code / OpenCode / Hermes / OpenClaw / ... strata launch --stop Those --family qwen --model q2_0 flags are the dry run used for the ISTA Q2_0 build on Ubuntu 26.04. Unsloth packs use --family unsloth and the name from the table above. strata connect prints a provider block per tool. Both API shapes use an OpenAI-compatible base URL (http://127.0.0.1:8080/v1) and the model name the launch prints. Any client that accepts a custom OpenAI-compatible endpoint, including Cursor, uses that pair. Two settings to verify on first run 1. Sampling. In 0.2.11 a pack config with no sampling block follows the model card. Thinking requests get temperature 1.0, top_p 0.95, and top_k 20. Non-thinking requests get 0.7, 0.8, and 20, with presence_penalty 1.5. Precedence is the request, then the web UI's Chat settings, then the config block, then the card. Temperature 0 applies only when the request or the block sets it, and those greedy runs are the ones that fell into repetition loops on this checkpoint. If an older pack config still contains "sampling": {"temperature": 0}, replace it with the card's thinking preset. 2. tool_call_recovery. The key lives in the model run config (strata-*.json). It has been on by default since 0.2.8, and off in 0.2.7 and earlier. Strata's engine notes, citing 1,462 agent turns, report 98.3% of calls read as intended with the switch and 92.9% without. It accepts four shapes of a call whose name was in the request: a <parameter=NAME> tag, JSON inside <tool_call>, a <function=NAME> block with no <tool_call> wrapper, and a second call inside one <tool_call>. An undeclared name or broken JSON stays text. On 0.2.7 and earlier, set "tool_call_recovery": true. Leave the 0.2.11 default on for agent work. Keep the server on localhost The server binds to localhost by default, and the access settings are part of strata launch. The endpoints expose the model and the conversation on that machine, and they were not built for an open network. When another machine needs them, put an authenticated reverse proxy in front of the port. ss -ltnp | grep :8080 # confirm the listener is 127.0.0.1, not 0.0.0.0 curl -s http://127.0.0.1:8080/v1/models # the server answers on localhost Cards with 13 GB of VRAM or less STRATA_ROUTE_PRIOR=1.5 tells the router to prefer experts already on the card. Strata's notes for an RTX 3060 12 GB running IQ3_XXS report +15% on story decode and +37% on code decode against the prior left off, and fewer agent tasks passed: 4.5 of 10 on average over 4 runs, against 5.6 over 7 runs with the prior off. Version 0.2.7 turned 1.5 on by itself for discrete NVIDIA cards of 13 GiB or less. Version 0.2.8 turned that back off on 29/10/2026, after repetition and weaker long agent sessions (issue #4402). With the variable unset, 0.2.11 routes as 0.2.6 did. The project points the prior at chat and short answers on a 12 GB card, and away from long agent runs. Testbed: A 64 GB Desktop Running an Agent The measured box: | Component | Spec | |---|---| | CPU | Intel Core Ultra 7 265 (20 cores, DDR5-6400 dual channel ≈ 102 GB/s) | | GPU | RTX 5090, 32 GB | | RAM | 64 GB | | OS | Ubuntu 26.04 | | Also running | KVM host for the Hermes VM, Cursor IDE, browser | With ISTA IQ3_XXS the resident shard is 47 GB. Because the experts are pinned, about 9 GB remains for everything else. The Hermes VM — the agent stack in the [Hermes production setup](glukhov.org "Hermes production setup: profiles, skills, and the local agent stack.") — plus Cursor leaves about 5 GB, which is not enough page cache or KV cache for a long agent session. ISTA IQ3_S does not fit this machine as a daily desktop. The 54.8 GB resident shard plus the 28.8 GB mapped n-gram table use the 64 GB. With Cursor running, 3 GB stay free, and the Hermes VM has nowhere to go. | Config | Resident | Free RAM (model only) | Free RAM (model + VM + Cursor) | Decode (measured) | Agentic verdict | |---|---|---|---|---|---| | IQ3_XXS (3.00 bpw) | 47 GB | ~9 GB | ~5 GB | – | Tool calls fail regularly; not a daily driver | | IQ3_S (3.50 bpw) | 54.8 GB + 28.8 GB mmap | ~3 GB (Cursor only) | – | 100–130 tok/s | No headroom at all; not usable | IQ3_S decoded at 100–130 tokens/s, the same speed class as a 27B build on llama.cpp with MTP 3 in the [Qwen 3.6 MTP comparison](glukhov.org "Qwen 3.6 MTP vs standard decoding on a 16 GB GPU: token speed, VRAM, and draft length."). The pack that fits the RAM budget (IQ3_XXS) is the one that misses the tool-call format. The pack ISTA recommends (IQ3_S) leaves no room for the rest of the desktop. On IQ3_XXS the model emitted malformed tool-call arguments, invented tool names that were not in the schema, and re-issued the same command three to five times after a short thinking block. The harness treats each miss as a retry, so the session fills with the same error. On this hardware IQ3_XXS is not an agent model. What the Community Reports Speed reports for Qwen3.8-Flash-Next on Strata, from issue threads and the 0.2.11 notes: | Setup | Result | |---|---| | 2× RTX 4090 | 6,553 prompt t/s, 271 decode t/s single stream | | RTX 5080 + 4060 Ti, 32 GB RAM | 200+ tok/s decode peaks | | 12 GB VRAM + 32 GB RAM, experts offloaded to CPU | ~65 tok/s; one comment at 199K context with q8 KV: 1,740 prompt t/s, ~21.5 decode t/s | | RTX 5070 12 GB + 64 GB RAM, IQ3_S | 85–100 tok/s decode | | Pro 6000 + 2× 3090, 256 GB RAM, Unsloth 6-bit, 160K context | Decode 70–80 → 150 tok/s after switching from llama-server to Strata | | RTX 2060 laptop, 32 GB RAM + 6 GB VRAM | Q2_0 running at all | | RTX 3060 12 GB, UD-IQ1_M, short prompts (0.2.11 notes) | 31–37 decode tok/s, 18% of experts on the card | Three failure modes are written up for low-bit Qwen3.8-Flash-Next in agent workloads. 1. Mangled tool-call emission that tracks the schema's size. Issue #1431 reports that with 39 function schemas (about 12K tokens) and a 6K system prompt, IQ3_XXS on Strata 0.1.40 produced a usable turn in about 30–50% of 20-plus controlled replays. The model either emitted a tool-call shape the parser could not map — the text landed in content with finish_reason: stop — or closed the thinking block and emitted end-of-sequence with no call and no answer. The same weights on llama.cpp parsed tool calls in all 8-plus consecutive runs. llama.cpp constrains the emission with a PEG grammar and lifts mangled content back into tool_calls. A wrapper that repaired the text afterwards did not push the useful-turn rate above that 30–50% band, because the repair runs after the tokens are already chosen. 2. Config errors and a non-deterministic expert path. Issue #2685 reports an RTX 5070, IQ3_S, and 60 GB of RAM, with tool calls failing through Strata: malformed arguments, hallucinated tools, and retry loops, including after a sampling block and tool_call_recovery were turned on. The same quant through llama serve succeeded on 5 of 5 runs of the same harness. The reporter found that identical seeds diverged in the MMQ expert path during prefill, and that disabling that path made the runs bit-identical. Strata 0.1.44 shipped determinism fixes. Later reports still do not show Strata matching llama.cpp on the same quant. 3. Tool calls left inside the thinking block. Issue #804 reports that a complete tool call inside an unclosed think block comes back as reasoning_content, with empty content and no tool_calls, and the agent loop stops. One user counted about 1 in 100 responses over roughly 1,300 real agent replies, using Hermes with IQ3_XXS, IQ2_XS, and the Coder builds. Why Sub-Q4 Breaks Agentic Tool Calls A tool call has to match a wire format. At 3 bits this 125B model misses that format on some turns, and the misses grow with the tool-schema context. A larger schema asks more of the working memory that formats the call, and quantization noise lands on that formatting. Chat turns hide it. Agent turns, which are mostly tool calls, do not. The same compression hurts more when few parameters are active. The [local-LLM comparison for OpenCode](glukhov.org "Best LLMs for OpenCode: local Ollama and llama.cpp models against a migration-map task.") measured a dense 27B at IQ3_XXS with about a 5% error rate on a structured agent task. Low-active MoE checkpoints at similar bit widths failed harder: the 35B-A3B had 64.2% errors on IQ3_S and 98.8% on IQ4_XS, and the 122B-A10B had 80% errors on IQ3_S and 90% on IQ3_XXS. Qwen3.8-Flash-Next activates 6B parameters per token, so a 3-bit pack behaves like a small model on a heavy quant. Those OpenCode runs show IQ3 and IQ4 missing the structured task for the 35B-A3B and the 122B-A10B; they do not include a Q5 run of Flash-Next. Strata's UD-IQ4_XS-v31 has been downloadable since 0.2.11, has no agent-task comparison in the sources checked here, and does not fit the 64 GB box. The same GSQ-RCO weights fail when they are loaded in llama.cpp and in Ollama. [llama.cpp](glukhov.org "llama.cpp quickstart: llama-cli, llama-server, and the flags that place a GGUF.") still constrains the emission with a grammar and can lift a mangled span back into tool_calls, so the client sees a call instead of a broken string. Strata's JSON mode, in the engine notes, is schema prompting plus a check after generation, not grammar-constrained decoding: a bad object returns HTTP 502 with structured_output_failed. tool_call_recovery and the later releases repair the four shapes listed above. They do not change the distribution the model samples from, which is why issue #1431's wrapper could not climb past the emission rate. Strata spends RAM to keep the CPU and the GPU in step. On 64 GB, the largest ISTA pack that still leaves room for a desktop and an agent VM is IQ3_XXS, and that pack is below the emission threshold measured here. IQ3_S already decodes in the same band as a 27B model with MTP 3, so the limit on that pack is RAM. A llama.cpp run with a lazy map would commit less RAM and give up the decode rate that makes Strata the faster of the two on this model. Verdict Qwen 2.8 Flash Next outperforms Qwen3.8-27B on agentic benchmarks: DeepSWE 58.7 vs 42.2, JobBench 55.7 vs 33.4, and Toolathlon 73.5 vs 67.1. Multi-step work is noticeably more competent. Per-token compute is closer to a small model than a 125B model. Quantizations below Q4 do not provide reliable tool-call emission for agentic work, failing at rates that produce retry loops on both Strata and llama.cpp. Q4 performance is not yet proven through controlled comparison on agent benchmarks. Q5-class quants are the demonstrated floor for reliable agentic work; the Unsloth UD-Q5_K_XL exists but lacks published benchmarks. A Mac Studio with an M5 Max and 128 GB unified memory can hold the 105 GB MLX build or a Q4 pack with sufficient headroom for the agent stack. The QFN architecture was designed for this offloading model. I will continue using in my current setup uses an NVFP4 27B model — 17 GB on the RTX 5090 — with MTP 3, It is achieving 100+ tokens/s with reliable tool calls and no RAM competition. I will return to QFN when a Q4-class quant is benchmarked on agent tasks, when Strata's emission recovery matures, or when hardware is upgraded. References - Niko1221/Strata — the inference engine in this article. The OSDI 2026 hierarchical-KV paper for SGLang is a different project with the same name. - Strata 0.2.11 release notes — Unsloth Dynamic v3.1 packs, Q5_0 math, and the short-prompt speeds cited above. - Engine notes (docs/DETAILS.md) — sampling precedence, tool_call_recovery, and the route-prior measurements. - Qwen/Qwen3.8-Flash-Next — architecture, sampling presets, and the benchmark table. - ISTA-DASLab Qwen3.8-Flash-Next GSQ-RCO GGUFs — the Q2 and IQ3 builds in the testbed. - Issue #1431, issue #2685, issue #804, and issue #4402 — the failure reports in the community and small-card sections. Useful links - [Choosing the Best LLM for Ollama on a 16 GB VRAM GPU](glukhov.org "Dense-model choices when the card has 16 GB and the runtime is Ollama.") — dense-model alternatives when the card is the limit. - [Ollama cheatsheet](glukhov.org "Ollama CLI cheatsheet: serve, run, ps, and model management.") — the other local server the same GGUFs can be imported into.

Four DGX sparks for the official model. Two sparks for the quantized (shrunk, less intelligent) model. Or you can try strata if you have some GPUs (like 4 Radeon AI PRO R9700s) and a large system RAM (>=256 GB).

VRAM 12GBのRTX 3060で125B級モデルを動かすStrata：めちゃいい！ はじめに 煽りではないです。 かなり速く、賢いです。 以前、FreeTokenで120B級モデルを動かしてみたときは、WSL2へのメモリ割り当てに64GBが必要で、生成速度は平均 15～16 token/s程度でした。 zenn.dev しかし、Strata では 48GB でいけます。しかも約 38 token/s 程度出ます。 筆者の環境では、デスクトップ版ChatGPTと体感が変わらないくらいの印象です。出力品質も凄く良いのでは？（今後、要検証） 今回使用したモデルは Qwen3.8-Flash-Next の IQ3_XXS版 です。 Strataとは何か？ Strataは、概ね、Qwen系の大型モデルをローカル環境で爆速で動かすことに特化した、軽くて強力なエンジンという認識で良さそうです。 FreeTokenとはどう違う？ 一応、違いも整理しておきます。 項目 Strata FreeToken 対応範囲 Qwen3.8-Flash-Next、Qwen3.6-35B-A3B、DeepSeek V4.1-Flash など Qwen、DeepSeek、GLM、MiniMax、gpt-oss など幅広いモデル Expert（専門家）モデルの配置 利用状況に応じてGPUにキャッシュし、CPU計算も組み合わせる LRUキャッシュと、実行方式の選択が可能 CPUとGPUの分担 キャッシュ外のExpertモデルについて、CPU計算と転送を分担する 転送中心、CPU計算中心、両者の混合を選択できる 特徴的な機能 対応モデル向けの最適化処理、先読み生成（投機生成）、メモリ階層の使い分け 帯域に応じた分担、会話編集後の状態再利用、実行中のVRAM再配分 今回（いつも）の実行環境 項目 今回の想定 GPU GeForce RTX 3060 12GB OS Windows上のWSL2 Linux Ubuntu 26.04 x86-64 RAM 64GB、WSL2に48GBを割り当て モデル Qwen3.8-Flash-Next IQ3_XXS コンテキスト 32K 同時実行数 1 圧縮形式は IQ3_XXS を使います。 モデルファイルサイズは約76GBです。 インストール手順 CLI版をインストールします。 説明に登場するディレクトリは自由にしてください。 sudo apt update sudo apt install -y curl ca-certificates export STRATA_HOME="$HOME/workspace/strata" export STRATA_DATA_DIR="$STRATA_HOME/strata-data" mkdir -p "$STRATA_HOME/strata-setup" "$STRATA_DATA_DIR" cd "$STRATA_HOME/strata-setup" curl -fsSL \ github.com/Niko1221/Strata/releases/latest/downlo… \ -o install.sh sh install.sh PATHに ~/.local/bin がまだ通っていない場合だけ必要です export PATH="$HOME/.local/bin:$PATH" strata --version ダウンロード前に起動計画を確認する まず --plan を使い、表示されるモデル、GPU用エンジン、保存先、必要容量を確認します。 この段階ではダウンロードを開始しません。 --data-dir には絶対パスを指定します。 strata launch \ --family qwen \ --model iq3_xxs \ --context 32k \ --parallel 1 \ --vision off \ --data-dir "$STRATA_DATA_DIR" \ --access local \ --plan 出力例は次のようになります。 Plan for 'IQ3_XXS 32K': model Qwen3.8-Flash-Next IQ3_XXS, 76 GB context 32K pictures off parallel 1 download About 77.0 GB to download: the model (75.8 GB) and the DFlash2 drafter (1.2 GB). To skip the DFlash2 drafter, add --drafting mtp. The engine for your graphics card is downloaded first (from the update source; its size is shown when it starts). drafting DFlash2 (its drafter is downloaded first) tuning skip access This computer only, port 8080 same as strata launch --model iq3_xxs --data-dir "~/workspace/Strata/Strata-data" --context 32k --vision off --parallel 1 --tune skip --access local --port 8080 Nothing was changed. 準備ができたら起動します。 qwen-iq3-32k という名前で起動設定が保存されます。 --no-tui は、対話型TUIを表示せずに起動するためのオプションです。 バックグラウンド運用に向いた起動を目的として使えます。 初回はモデルのダウンロードと準備に時間がかかります。 strata launch \ --family qwen \ --model iq3_xxs \ --context 32k \ --parallel 1 \ --vision off \ --data-dir "$STRATA_DATA_DIR" \ --access local \ --save-preset "qwen-iq3-32k" \ --yes \ --no-tui 状態確認 strata launch --status curl -fsS 127.0.0.1 停止 strata launch --stop 次回以降の起動 先程保存したプリセット名で起動するイメージです。 strata launch --preset "qwen-iq3-32k" --no-tui 起動に失敗した場合 次のコマンドで状況を確認します。 strata --version strata doctor --live strata launch --status 自動チューニング 一度正常に動作したことを確認してから、チューニングを適用してください。 まずStrataを停止し、保存済みのpresetに対してチューニングを実行します。 strata launch --stop strata launch \ --preset "qwen-iq3-32k" \ --tune quick \ --save-preset "qwen-iq3-32k" \ --yes \ --no-tui 公式資料では、quick は約20分、thorough は最大2時間程度が目安とされています。 実際には環境によって変わります。 一度計測された調整条件は再利用されます。 再測定したい場合は --retune を追加します。 ちなみに、筆者の環境では quick の結果、次のように表示され、変更はなかったようです。 Tuning result: already fastest. Your computer already runs at its best with the standard settings. Nothing needed changing. 100% あとがき 正直どれも同じだと思っていましたが、思いがけない収穫となりました。 ローカルLLMに対する印象や世界観がガラリと変わりました。 早速この記事を丸ごと校正してもらいました。

Strata 0.2.11 is now out! 👀 - Supports new Unsloth Qwen3.8-Flash-Next quants - Layer splitting is now allowed for all configurations - Performance increase - App & Terminal improvements More at: github.com/Niko1221/Strata/releases/tag/v0.2.11 t.co

In my private coding benchmark Luna Low effort is beaten by Qwen 3.8 Flash Next Coder IQ_1 served by Strata locally niko1221/strata Luna medium effort is very slightly better than its output and completes tasks in 5-10x less time.

Agree, I run QFN on my AI Pro R9700 (32GB) using Niko1221/Strata It's even faster than on a Strix Halo. Typically I get around 90 tokens/sec with a small context, down to 70 tokens/sec when it's near the maximum context usage.

A 125B model at 50+ tok/s on a 12 GB gaming card: what I changed in Strata I run Qwen3.8-Flash-Next, a 125-billion-parameter mixture-of-experts model, on one RTX 3060 with 12 GB of video memory and 30 GB of RAM. Nothing leaves my PC. This post is about the fork I made to get there, what I measured, and what I have not tested. Starting point: Strata The model is about 78 GB of files at the quantization I use (IQ3_S). It does not fit on a 12 GB card. Strata by Niko1221 and contributors (MIT) solves that by keeping the most-used experts on the graphics card, putting more in RAM, and streaming the rest from the SSD. My fork, Strata-HotRod, makes that path faster and checks that answers stay correct. What I measured All of this is on one machine: RTX 3060 12 GB, Intel i5-12400F, 30 GB RAM, a 500 GB NVMe on a PCIe 3.0 link, Rocky Linux 9.6. | Answer (131K context) | tokens/s | |---|---| | Code, 500-650 tokens | 52-55 | | Reasoning, about 1,000 tokens | 66-71 | | Prose, 100-150 tokens | 50-53 | Long prompts, 262K context: an 8,554-token prompt is read in 16.9 s and answered at 52-54 tokens/s. A 45,398-token prompt takes 67-68 s to read, then the answer comes at 38-41 tokens/s. The next turn of that same conversation starts in 0.4-0.5 s, because the saved state is reused. The first message of a chat is the slow part: it waits on the SSD for the model's experts. What I changed - A learned look-ahead. The engine guesses which experts the next layers will need and loads them early. Against the plain router, the guesses are right 85-88% of the time one layer ahead (router: 77-79%), 76-79% two layers ahead (66-69%), and 66-71% four layers ahead (55-58%). - Three tiers: card, RAM, SSD. The hottest experts sit on the card, the next ones in a RAM tier sized from free memory, the rest on the SSD. Budgets and reserves are measured on your PC and kept across restarts. - Expert placement from routing traces, instead of a fixed guess. - Stand-in experts with a re-check. To stay fast, some of a token's experts are replaced with similar ones already on the card. - Pinned RAM segments (on by default): about 9% faster on this PC. Every change and its measurement is in the repo's docs, including ideas that did not help. For example, a learned read-ahead of lower-ranked guesses made decoding 23% slower on this PC, because the drive was already at its limit, so it stays opt-in. Is the answer quality still good? In a small test (50 maths questions, 30 coding questions, answers read by hand), the stand-ins gave 47/50 and 30/30 correct, against 48/50 and 30/30 with nothing replaced. A test this small cannot show a difference of one or two answers either way. On MMLU-Pro (15 questions from each of its 14 subjects, 210 in all, thinking on, temperature 0) it scored 87.1%, 183 of 210. That is a small sample, so read it as a sanity check, not a leaderboard result. What I have not tested One card, one model, one PC, Linux only. Other GPUs, AMD, Windows, macOS and other model sizes may work in upstream Strata, but I have not run them, so I will not claim them. Try it, and tell me what you get The repo has the install steps and the full change log: sangharshadhyeta/Strata-HotRod. If you run it on different hardware, I would like your numbers, good or bad. The repo has a short guide for how to report them.

A 763B MoE on a 12 GB GPU: Our Speed Ceiling Versus What Strata Reports, and What Closes the Gap TL;DR Two days ago we wrote that a 763B mixture-of-experts model squeezed to 2 bits per weight could, on paper, run on a 12 GB GPU, and we put illustrative speed ceilings of 3.4 to 12 tokens per second on it by assuming every expert had to be fetched cold over PCIe or from an SSD. That post had one weak spot: the card did not say how the Strata engine places tensors, so we guessed. The Strata documentation does say, and it is different from our guess. The experts that do not fit in GPU memory are not shipped to the GPU. The CPU computes them where they sit in system RAM, while the GPU works on a cache of the most popular experts. We did not run Strata or these files. What we did is take the speeds its README and DeepSeek page report, recompute how many expert bytes one token touches for each build, and ask what the reported numbers imply. Three findings. A token touches 1.7 to 2.1 GB of routed experts on the 2.00-bit build, depending on whether the engine uses 5 or 6 experts per layer. The 4.7 tokens per second reported on a 12 GB GPU with 64 GB of RAM is above what a 3.6 GB/s SSD could deliver if experts were hit uniformly, so the routing must be skewed enough for a hot set to carry most of the traffic. And the published speed table is not a clean hardware ranking, because the rows differ in RAM, drive, engine version and settings. !Grouped bars of routed-expert bytes read per generated token for four builds at 6 and 5 experts per layer What does Strata report for this 763B model? Strata is an MIT-licensed local inference engine. When we checked on November 4, its repository had about 39,000 stars, had been created on September 24, and the latest release was v0.2.10, published at 23:52 UTC on November 2. Its README now lists DeepSeek-V4.1-Flash-1017 next to the Qwen models, using the three ISTA-DASLab GGUF sets we looked at on November 2. For the 2.00 bits-per-weight set it gives this table, measured on Strata 0.2.5 (the Strix Halo row on 0.2.7): | Hardware | Output speed | Prompt speed | |---|---:|---:| | RTX 5070 12 GB, 64 GB RAM | 4 to 6 tokens/s | about 110 tokens/s (4K) | | RTX 3060 12 GB, 46 GB RAM | 9 to 11 tokens/s | about 155 tokens/s (4K) | | 1x Radeon AI PRO R9700, 251 GB RAM | 21 to 25 tokens/s | 320 to 360 tokens/s (8K) | | 4x Radeon AI PRO R9700 | 74 to 77 tokens/s | 400 to 450 tokens/s (8K) | | Ryzen AI Max+ 395, 128 GB unified | 19 to 21 (code), 11 (chat) | 87 tokens/s (4K), 125 (8K) | !Grouped bars of the low and high end of the speeds reported in the Strata README for five machines These are the project's own numbers, one report per row, and they are not independent measurements. The DeepSeek page of the same repository adds details that do not line up exactly with the README. It gives 4.7 tokens per second for the RTX 5070 box with a 3.6 GB/s NVMe drive, 8 to 10 for the RTX 3060 (9.9 on code, 7.8 on agent work, drafter off), and about 48 tokens per second for four R9700 cards on the 2.00 set where the README says 74 to 77. A user-built sm_89 binary is reported at 40.2 tokens per second on an RTX 4090 48 GB with 128 GB of RAM. The honest reading is a range, not a point. Where does the engine actually put the experts? This is the part we had wrong. The DeepSeek page describes three tiers. The dense weights (attention and the other tensors every token needs) go to graphics memory. The routed experts go to graphics memory "as many as fit", and the rest are computed on the CPU, read in place from the model files. The n-gram lookup table, called Engram, stays on the SSD, and only a few rows are read per generated token. The HOW_IT_WORKS page for the Qwen models states the same principle: the card keeps the most-asked experts and learns which ones those are while you chat, the CPU works on the others at the same time as the GPU, and more VRAM matters more than a faster GPU. For us the consequence is simple. Our November 2 table priced every token as 2.06 GB crossing a link. In this design only the experts that miss the GPU cache cost anything, and the cost is CPU memory traffic rather than PCIe transfer. The SSD enters the picture only when the experts do not fit in RAM either, which is the 64 GB case, because the 2.00 set has about 132 GB of routed experts. How many bytes does one token touch? The model has 40 layers with 384 routed experts each, so 15,360 experts, and the router picks 6 per layer per token. Strata also offers a "Faster" mode that uses 5, and it is the default on PCs whose graphics cards total 16 GiB or less and on integrated GPUs. Dividing the routed-expert bytes of each build by 15,360 gives the average expert size, and multiplying by 40 layers and by k gives the traffic per token. The expert totals for the three ISTA-DASLab builds come from the GGUF headers we parsed on November 2, and the Q8 figure is the 288.8 GB that Strata's page lists for Unsloth's UD-Q8_K_XL file. LAYERS, EXPERTS = 40, 384 N = LAYERS * EXPERTS # 15,360 routed experts EXP_GB = {"IQ1_M": 114.56, "IQ2_XXS": 132.07, "IQ2_XS": 149.06, "UD-Q8_K_XL": 288.8} def per_token_gb(set_gb, k): # routed-expert bytes touched per token return LAYERS * k * set_gb / N for name, gb in EXP_GB.items(): print(name, round(gb * 1000 / N, 2), "MB/expert", round(per_token_gb(gb, 6), 2), "GB/token (k=6)", round(per_token_gb(gb, 5), 2), "GB/token (k=5)") | Build | Average expert | GB per token, 6 experts | GB per token, 5 experts | |---|---:|---:|---:| | IQ1_M, 1.75 bpw | 7.46 MB | 1.79 | 1.49 | | IQ2_XXS, 2.00 bpw | 8.60 MB | 2.06 | 1.72 | | IQ2_XS, 2.25 bpw | 9.70 MB | 2.33 | 1.94 | | UD-Q8_K_XL | 18.80 MB | 4.51 | 3.76 | Two caveats. The searched allocation gives tensors different types, so the real size of an expert varies by layer and these are averages. And the number is bytes the router asks for, not bytes the machine must move: every expert already in the GPU cache costs nothing on the memory side of the problem. Is the SSD the limit on a 64 GB machine? Take the RTX 5070 row. The experts of the 2.00 build are about 132 GB. Assume, and this is our assumption, that after the 6.16 GB dense path and a cache reserve the GPU holds 3 to 5 GB of experts and that 48 to 56 GB of RAM is left for the experts. That is 51 to 61 GB, or 39 to 46% of the expert bytes in fast memory. If routing were uniform, every token would then read the remaining 54 to 61% from the SSD. With a 3.6 GB/s drive and the Faster mode (5 experts, 1.72 GB per token), that caps decoding at about 3.4 to 3.9 tokens per second. With 6 experts it is 2.9 to 3.2. The reported 4.7 sits above both. The chart shows the SSD-bound ceiling against the share of expert bytes held in fast memory, and where the 4.7 line crosses it. !Line chart of the SSD-bound speed ceiling versus the share of expert bytes held in fast memory, with the reported 4.7 tokens per second as a dashed line Turn it around. To sustain 4.7 tokens per second on a 3.6 GB/s drive, the machine can afford at most 0.77 GB of SSD reads per token. That is 44.5% of the expert bytes at 5 experts, or 37.1% at 6. So the cache must serve at least 55.5% (or 62.9%) of the expert lookups while holding only about 42% of the bytes. This is a mild skew, and it is exactly what a hot-expert cache is for. The DeepSeek page says the project ships a "hot-expert profile" built from routing statistics (a separate one for the Coder variant came from 519,422 calibration tokens) and copies it into the pack. A small speculative-decoding drafter, which the page measures at plus 2 to 13% on the RTX 3060 box, can also lower the cost per token, because several drafted tokens share one verification pass. What this does not prove is the cache hit rate itself. We have a lower bound on skew implied by one reported number and our guess at memory capacity. Running strata launch --plan, which the page says works out expert placement for your cards and RAM, would replace our guess with the engine's own count. Why is the 128 GB Ryzen box about four times faster than the RTX 5070 box? On the Ryzen AI Max+ 395 the GPU and CPU share one memory pool. The page says a 128 GB machine keeps about 109 GB of the 2.00 set's experts in that pool and reads the other 23 GB from the SSD, which agrees with the 132 GB total we computed. That puts 82.5% of the expert bytes in fast memory against about 42% on the 64 GB box. The pool is also fast. The chip's 256-bit LPDDR5X-8000 interface is rated at about 256 GB/s, and community llama.cpp benchmarks report roughly 215 GB/s sustained. Even if every byte of a token's experts came from the pool, 1.72 GB per token at 215 GB/s would allow about 125 tokens per second, so the reported 19 to 21 on code is only 15 to 17% of that bandwidth ceiling. Memory bandwidth is not what limits it. The SSD may be: with uniform routing, 17.5% of 1.72 GB is 0.30 GB per token, which at 19 to 21 tokens per second is 5.7 to 6.3 GB/s of reads, near the limit of a fast PCIe 4.0 drive, and the page does not say which drive was used. Chat at 11 tokens per second would need 3.3 GB/s. Code being faster than chat fits the idea that code routes into the profiled hot experts more often, but that is our hypothesis, and the drafter's acceptance rate on repetitive code would explain it just as well. Why does a 12 GB RTX 3060 beat the newer RTX 5070 in the table? Read as a ranking of GPUs, the table says an RTX 3060 is about twice as fast as an RTX 5070. We do not believe that, and the rows give reasons not to. The 3060 row has 46 GB of RAM and the 5070 row 64 GB, the 3060's drafter was off, the 5070 row names its 3.6 GB/s drive and the 3060 row does not. The README also says the Strix Halo row was measured on a newer engine version than the others. A cleaner experiment holds everything fixed except the card, with cold-cache and warm-cache runs reported separately. Until someone publishes that, treat each row as "this machine, this day". What does the quantization cost in quality? Strata reports its own comparison against the original model on 4,995 positions. For the 2.00 set it gives KL divergence 0.170 and perplexity up 15.5% (code up 8.6%, agent work up 5.3%). For 2.25 it gives KL 0.107 and perplexity up 7.3%. For IQ1_M perplexity is up 21%, with plain English prose the weakest area at plus 53%. The ISTA-DASLab card, as we noted on November 2, reports 98.7% of the base model's task average for the smallest build on three benchmarks. These measure different things, and neither tells you how the Faster mode with 5 experts changes your own task, which Strata describes only as a small change that is usually not noticeable. The same page also quotes a perplexity of 3.405 against a reference of 3.140 for the 2.25 set, which is plus 8.4% where the text says plus 7.3%. Likely different runs, but treat single-run figures here as good to about a point. How should you check this on your own machine? Start with the plan, then measure, and keep the cold and warm cases apart. strata launch --family deepseek41 --model ist-das-2.00bpw --plan Write down the engine's experts-in-VRAM and experts-in-RAM counts from the plan. Divide by 15,360 to get your fast-memory share, then compare your decode speed with the SSD-bound line for that share. If you are above it, your routing is skewed in your favour. If you are well below it, something other than the SSD is the limit, usually the CPU lane or a drafter that is switched off. Log drive throughput while generating, measure with your own prompts and not a fixed one, and compare 5-expert and 6-expert runs at the same settings. Remember the first answer after loading is slower because the cache is cold. FAQ Can a 763B-parameter model really run on a 12 GB GPU? It runs, according to the Strata README, but only because the GPU holds the dense path plus a cache of popular experts while system RAM and the SSD hold the rest. Speeds reported for 12 GB cards are 4 to 11 tokens per second on the 2.00 set, with the exact figure depending heavily on RAM and drive. How much system RAM do you need? The experts of the 2.00 build are about 132 GB. The Strata page says that under about 40 GB of RAM the setup is untested and slow, and that the Engram table, 111 GB shared by all three builds, belongs on a fast NVMe drive. The reported 12 GB GPU rows have 46 and 64 GB. What does the Faster mode change? It uses 5 experts per layer instead of 6, which cuts the bytes touched per token by 17%. It is the default on PCs with 16 GiB of graphics memory or less and on integrated GPUs such as Strix Halo. Are these speeds independent measurements? No. They are the project's reported numbers, and we did not run the engine. Our contribution is the byte arithmetic and the bounds it implies, and the cache-capacity figures for the 64 GB box are our assumptions. Further reading - A 763B MoE at "2 Bits": Where the Bytes Really Go in the GSQ-RCO GGUFs, and Why 100% Recovery Sits Inside the Noise - Why a Sparse 35B MoE Runs Faster on a CPU Than a Dense 27B Model Sources: Strata repository and README, Strata DeepSeek-V4.1-Flash page, Strata HOW_IT_WORKS, ISTA-DASLab/DeepSeek-V4.1-Flash-1017-GSQ-RCO-GGUF, Strix Halo memory bandwidth, 256 GB/s rated versus about 215 GB/s measured. Speeds, quality figures and memory placement are as reported by the Strata project on its pages as of November 4, 2026. Bytes per token, SSD ceilings and implied hit rates are our own illustrative arithmetic, not measurements.

Radeon VIIとUbuntu 26.04でROCmを動かし、Flash-NextをOpenCodeにつないだ 5年ほど前に組んだデスクトップがある。当時、GPUにはすでに型落ちだったRadeon VIIを5万円くらいで入手して載せた。Stable Diffusionで遊んでいた時期もあったが、飽きてからはすっかり出番がなくなっていた。 最近はローカルLLMが盛り上がっている。とはいえ、パソコンもGPUもクソ高い。新しいGPUを買う前に、あまり期待せず、久しぶりにこのデスクトップに火を入れて環境を組み直してみることにした。 気になったのは、Radeon VIIのROCm公式サポートが切れていることだ。かなり苦戦する覚悟だったが、実際にはChatGPTのGPT-6.1 Terra（medium）に相談しながら、環境の調査から構築、動作確認まで進められた。多少の修正はあったものの、さくさく進む。最終的に、Qwen3.8-Flash-Nextが動き、OpenCodeからローカルモデルへツール付きでアクセスできるようになった。古いデスクトップでvibe codingを試せる環境ができてしまい、だいぶびっくりしている。 この記事は、そのRadeon VIIでROCmを動かし、ローカルLLMをOpenCodeにつなぐまでの記録だ。 結果は、Q2_0量子化版のFlash-Nextで短めの会話の生成が約35 tokens/s。別途、Qwen3.8-27BのQ3量子化版もllama.cppで約21〜22 tokens/s出ている。両者は量子化も実行エンジンも違うため、モデル同士の純粋な比較ではない。 この記事は2026年11月3日時点の実機メモだ。gfx906のROCmはAMDの通常の動作保証対象とは別扱いで、以下は一つの環境で動いた記録だ。アップデート後も同じように動くとは限らない。 環境と構成 項目 今回の環境 GPU Radeon VII、VRAM 16GB、gfx906 CPU Ryzen 5 3600、6コア12スレッド、AVX2 RAM 公称64GB、OSから約60.7GiB OS Ubuntu 26.04.1 LTS カーネル 7.0.0-42-generic、標準のamdgpu/KFD ROCm TheRock nightly 10.3.0a20261102、gfx906向け HIPのバージョン表示 7.18.26434 推論 Strata v0.2.10、gfx906用ソースビルド モデル ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF、Q2_0 コーディングUI OpenCode v1.19.5 Flash-Nextは本体125B、1トークンで有効になるのは約6BのMoEモデルで、別に51BのN-gram参照テーブルがある。Q2_0はパラメーターを削った小型モデルではなく、重みを量子化したものだ。Qwenの説明と量子化版の配布元を参照してほしい。 構成は大きく3層だ。 Ubuntu標準のamdgpu/KFDがGPUを扱う。 gfx906向けROCmのユーザー空間ライブラリとHIPが計算を担当する。 StrataがモデルをGPU・RAM・ストレージに配置し、ローカルAPIを公開する。 コンテナは使わず、ROCmやビルド成果物はホームディレクトリ下に分離した。システムのドライバやAPTリポジトリは変更していない。 まずamdgpuとKFDを確認する 画面が映っているだけではGPU計算が動くとは限らない。まずカーネルドライバとデバイスノードを確認した。 uname -a lspci -nnk | grep -A 4 -i 'vga|display|3d' ls -l /dev/kfd /dev/dri getfacl /dev/kfd /dev/dri/renderD128 このPCでは1002:66afのRadeon VIIをamdgpuが使用し、/dev/kfdとrenderD128にはログインユーザー向けのACLが付いていた。アクセス権の設定方法は環境によって異なる。/dev/dri/renderD128も固定とは限らないので、自分の環境で確認しよう。 gfx906向けROCmをユーザー領域へ TheRockの対応表ではgfx906はビルド対象だが、Sanity Tested・Release Readyにはチェックがない。配布されていることと、実機で動作検証されていることは別だ。 今回はAMDのnightlyから、同じ日付のSDK・ライブラリ・開発ツール・gfx906向けデバイスコードを仮想環境に揃えた。uvは別途用意した。以下の版は実験時点の固定値で、nightlyの保持期間や配布状態によっては取得できなくなる可能性がある。 uv venv ~/rocm-gfx906/venv uv pip install --python ~/rocm-gfx906/venv/bin/python \ --index-url nightly.repo.amd.com \ 'rocm[libraries,devel,device-gfx906]==10.3.0a20261102' source ~/rocm-gfx906/venv/bin/activate rocm-sdk init export ROCM_PATH="$(rocm-sdk path --root)" export HIP_PATH="$ROCM_PATH" export PATH="$ROCM_PATH/bin:$PATH" export LD_LIBRARY_PATH="$ROCM_PATH/lib:$ROCM_PATH/lib64${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}" rocminfo これは配置先を分かりやすく書き直した再現例だ。実機では~/.local/share/rocm-gfx906/venvを使った。Ubuntu標準のPythonではvenvのensurepipがなかったため、uvで作成した。 rocminfoではRadeon VIIがgfx906:sramecc+:xnack-として見えた。さらにHIPで4,096要素のベクトル加算、rocBLASで2×2と512×512の行列積を検証した。SDK付属テストも27項目が通過した。 HIP compiled vector addition: PASS (4096 elements) rocBLAS SGEMM 512x512 identity product: PASS Ran 27 tests ... OK amdflangは最初、libquadmath.so.0不足で起動しなかった。今回はlibquadmath0をapt downloadしてユーザー領域に展開し、ライブラリパスを通して解決した。同様にC++開発ヘッダーとGCCの開発ライブラリもユーザー領域へ展開した。一般的な環境では、必要な開発パッケージをディストリビューションの方法で揃える方が簡単だ。無関係なUbuntu版のROCmパッケージを混ぜないようにした。 最初にllama.cppでGPU推論を確認 Strataに進む前に、llama.cppをHIP有効・gfx906指定でビルドした。使用したllama.cppのコミットはf9448cddc48c129a4abc7ff9c2a84c2b4c101c61だ。ビルド方法の基本はllama.cppの公式ドキュメントにある。 llama-cli --list-devicesにROCm0: AMD Radeon VIIが表示され、Qwen2.5-0.5BのGGUFで短い生成に成功。次にQwen3.8-27BのUD-Q3_K_XLも試した。モデルファイルは約13.2GBだ。 llama-server -m /path/to/Qwen3.8-27B-UD-Q3_K_XL.gguf \ -ngl 99 -c 4096 -np 1 --host 127.0.0.1 --port 8082 日本語の短い質問に正常回答し、会話では約21〜22 tokens/s。後にログを詳細化して、66/66層がGPUに配置されていることも確認した。別の8K設定では、約7,390トークンの合成入力を約240 tokens/sで処理した。いずれも今回のハードウェアと設定での観測だ。 Strataをgfx906向けにビルドする StrataのAMD向けドキュメントには、gfx906をwave64互換レイヤーでビルドする手順がある。配布済みのRX 6000/7000/9000向けバイナリをRadeon VIIに流用するのではなく、専用のSTRATA_HIP_GFX906経路を使う。 Strata v0.2.10のソースと、プロジェクトが指定するllama.cppコミット3cf03257f219afbe7334045ff7c6a06ac68c627dを用意した。システムにC/C++開発環境、CMake、Ninja、ROCmの開発ツールが必要だ。 STRATA_SRCとLLAMA_SRCは、それぞれ取得・展開したソースディレクトリ cmake -S "$STRATA_SRC" -B "$STRATA_SRC/build-906" -G Ninja \ -DSTRATA_HIP_GFX906=ON \ -DCMAKE_HIP_ARCHITECTURES=gfx906 \ -DSTRATA_GGML_DIR="$LLAMA_SRC" \ -DCMAKE_C_COMPILER="$ROCM_PATH/bin/amdclang" \ -DCMAKE_CXX_COMPILER="$ROCM_PATH/bin/amdclang++" \ -DCMAKE_PREFIX_PATH="$ROCM_PATH" \ -DCMAKE_BUILD_TYPE=Release cmake --build "$STRATA_SRC/build-906" --target strata strata-device -j 6 実機ではシステムにGCC開発環境がなかったため、APTからダウンロードして展開したlibstdc++-15-devとlibgcc-15-devを指す--gcc-toolchainをC/C++/HIPの各フラグに追加した。上は開発環境が通常の場所にある場合の基本形だ。 ビルド時に互換レイヤーの定義を追加した v0.2.10をそのままビルドすると、cudaDeviceGetStreamPriorityRangeとcudaStreamCreateWithPriorityが未定義になった。gfx906互換ヘッダーinclude/strata/platform/hip_compat/strata_hip.hに、対応するHIP APIへのマッピングを追加して再ビルドした。 #define cudaStreamCreateWithFlags hipStreamCreateWithFlags +#define cudaStreamCreateWithPriority hipStreamCreateWithPriority +#define cudaDeviceGetStreamPriorityRange hipDeviceGetStreamPriorityRange これは今回の版とビルドで必要だったローカル修正だ。将来の版では修正済みかもしれない。ビルド後、strata-device --selftest、gfx906向けGDN演算テスト、専門家演算の比較テストで失敗がないことを確認した。これらは全機能や長時間の安定性を保証するものではない。 Flash-Nextを準備して起動 モデルはISTA-DASLabのGGUFのQ2_0を選んだ。37.6GBの本体と28.8GBの参照テーブル、合わせて約66.4GBだ。今回使用したリビジョンはed59f92082b1e93c0e96d60a8b11aab089b52f09。両ファイルを配布元のSHA-256と照合した。 Qwen3.8-Flash-Next-GSQ-RCO-Q2_0-00001-of-00002.gguf SHA256 69820c02ec7d0b45ef2ebb19d6620299db749fe2aded7f39f93c6b88b199b720 Qwen3.8-Flash-Next-GSQ-RCO-Q2_0-00002-of-00002.gguf SHA256 316b46f3a2dbd68c900f43136ab9449f9dcc3725dfd8c794847c204bc161e113 転送が途中で停滞して再始動した際、最初の不完全ファイルを引き継がず、新しいファイルとして再取得した。完成後に古い不完全ファイル約17.6GBを削除した。大きなモデルでは、途中再開の動作と空き容量を確認したいところだ。 取得後、Strataに付属するtools/iq_pack.pyでインデックス、dense重み、トークナイザーを準備する。STRATA_GGUF_PYは上で用意した固定コミットのllama.cppにあるgguf-pyを指す。 export STRATA_GGUF_PY="$LLAMA_SRC/gguf-py" python "$STRATA_SRC/tools/iq_pack.py" \ --gguf /path/to/Q2_0/Qwen3.8-Flash-Next-GSQ-RCO-Q2_0-00001-of-00002.gguf \ --out /path/to/pack-q2_0 サーバー設定には、ビルドしたstrata、pack、2つのGGUF、付属のdata/expert-profile.binを指定する。主要なエンジン引数は次のとおりだ。 { "exe": "/path/to/build-906/strata", "cwd": "/path/to/Strata", "tokenizer": "/path/to/pack-q2_0/tokenizer", "model_name": "Qwen3.8-Flash-Next-Q2_0-gfx906", "backend": "hip", "gpu": 0, "parallel": 1, "drafting": "off", "args": [ "--pack", "/path/to/pack-q2_0", "--native", "/path/to/Q2_0/Qwen3.8-Flash-Next-GSQ-RCO-Q2_0-00001-of-00002.gguf", "--ple-gguf", "/path/to/Q2_0/Qwen3.8-Flash-Next-GSQ-RCO-Q2_0-00002-of-00002.gguf", "--expert-profile", "/path/to/Strata/data/expert-profile.bin", "--expert-cache", "auto", "--prefill", "auto", "--max-context", "262144", "--kv", "int8", "--kv-resident", "32768", "--ple-io", "direct", "--spec", "2" ] } パスは自分の環境に置き換える。Pythonの依存パッケージは別の仮想環境にrequirements.txtから導入し、ROCmのライブラリパスも通した状態で、ソースルートからサーバーを起動した。 cd "$STRATA_SRC" python -m serve.server --engine strata --config /path/to/config.json \ --host 127.0.0.1 --port 8081 最初は--specを付け忘れ、ネイティブpackには--spec T (T >= 2)が必要だとエラーになった。--spec 2を追加すると読み込みが進み、日本語での応答に成功した。ここでの--spec 2はエンジンの指定で、MTP補助モデルを導入したという意味ではない。今回draftingはoffだ。 サーバーはローカルのみにbindしている。稼働確認は以下で行える。 curl -s 127.0.0.1 curl -s 127.0.0.1 8Kから32K、256Kへ まず8,192トークンで動作確認し、その後32,768へ増やした。約30,417トークンの合成入力の中央に置いた合言葉を正しく回収できた。入力処理は約71.8秒、約424 tokens/sだった。 次に--max-context 262144 --kv int8 --kv-resident 32768で起動。約248,458トークンの入力でも、中央の合言葉を正しく回収できた。入力処理は約640秒、約388 tokens/sだった。 試行 結果 8K設定、短い会話 約35 tokens/sの生成を観測 32K設定、約30K入力 合言葉を正しく回収、入力約424 tokens/s 256K設定、約248K入力 合言葉を正しく回収、入力約388 tokens/s 長文は同じ日本語の文章を繰り返した合成データで、検索課題も一つだ。複雑な複数文書の理解、長時間稼働、異なるコンテンツで同じ精度・速度が出ることまでは確認していない。短い出力6トークンの生成速度を、長文回答の安定速度として扱うこともしない。 256K起動時は専門家キャッシュが8,235個、空きVRAMは約790MiBだった。GPUがデスクトップ表示も担当しているので余裕は小さめだ。--expert-cache autoやVRAM予約量の調整が必要になる場合がある。Strataのメモリ設定を確認してほしい。 また、今回のStrataの既定設定ではSTRATA_ROUTE_TAIL_SKIP=7が有効で、キャッシュにない専門家の一部を省略する。ログにも回答が少し変わり得ると表示される。7,390トークンの合成入力で1回ずつ試したところ、生成は有効時36.7 tokens/s、無効時33.7 tokens/sで、回答文も少し変わった。各1回の短い応答なので、この差を一般化したり品質差を判断したりはできない。 OpenCodeにつなぐ StrataのOpenAI互換APIを使う。OpenCode v1.19.5をユーザー領域に導入し、~/.config/opencode/opencode.jsonにローカルプロバイダーを追加した。設定形式はOpenCodeのプロバイダー設定を参照した。 { "$schema": "opencode.ai", "model": "strata/Qwen3.8-Flash-Next-Q2_0-gfx906", "provider": { "strata": { "npm": "@ai-sdk/openai-compatible", "name": "Strata (local Radeon VII)", "options": { "baseURL": "127.0.0.1", "apiKey": "local", "timeout": 1200000 }, "models": { "Qwen3.8-Flash-Next-Q2_0-gfx906": { "name": "Qwen3.8 Flash Next Q2_0 (local)", "tool_call": true, "limit": { "context": 262144, "output": 8192 } } } } } } モデルIDは/v1/modelsが返すIDと一致させる。既存設定がある場合は丸ごと置き換えず、必要なプロバイダーを統合してほしい。apiKeyはこのローカルの無認証サーバーに渡すダミー値だ。 opencode models strata opencode 簡単な接続確認として、OpenCodeにテストファイルを読むよう依頼したところ、readツールを呼び出し、ファイル内の合言葉を正しく返した。コードの変更や複雑なエージェント作業の品質までは、この時点では検証していない。 振り返り Radeon VIIの16GB VRAMだけにモデル全体を載せるのではなく、GPUの専門家キャッシュ、RAM、SSDを組み合わせることで、Flash-Nextの推論までたどり着けた。gfx906は標準的な導入経路から外れているため、GPU認識だけで成功とせず、HIP、行列演算、エンジン、実モデル、ツール呼び出しの順に確かめるのが役立った。 一方、今回はnightly ROCm、ソースビルド、互換ヘッダーへの小さな修正を使っている。Qwen3.8-27BはStrataではなくllama.cppで動かしており、Strataで同じ27Bが動くという話ではない。まずは手元で動いた版と設定を記録し、更新するときは一つずつ比較していこうと思う。 この記事について 実はこの記事も、実際に環境を構築したChatGPTのセッションで書いた。会話の中で調べたこと、実行したコマンド、ログに残った測定結果をもとにChatGPTが下書きした。OpenCodeではファイル読み取りツールの呼び出しまで確認したが、複雑なコード修正の成功率はまだ測っていない。これから、この環境でどこまでできるか試していきたい。