コミュニティが生み出した推論エンジン「Strata」をGPUSOROBANに組み込んで推論アプライアンス化させてみた件

Posted at 2026-10-28

本記事はZennに掲載した内容を転載したものです。

はじめに

Qwen3.8-Flash-Nextと言うモデルについて、拙作「次世代アーキテクチャを先取り！Qwen3.8-Flash-Nextで覗くQwen4の設計思想」で私は紹介していますが、このモデルはある意味一定の完成を見た次世代モデルだと認識しちゃうほどの高品質な応答を実現します。それ故、このモデルを手元に置きたいという人はかなり存在していて、わざわざ中古の NVIDIA Tesla V100 32GBモデルを複数個買い集める人もでてくるぐらいの人気モデルとして現在君臨している状況です。¹

図 1 Qwen3.8-Flash-Nextのアーキテクチャ構成図

このモデルのパラメータ量は 125B+51B(n-gram)+4B(mtp)-A6Bという構成で、結構大きなモデルになります。（内51B(およそ27GB)はメインメモリに格納して動作する）私もこのモデルを評価する際、とても手元の環境では実行できないためハイレゾさんより「NVIDIA A100」の搭載マシンをお借りして評価していたわけですが、もっと少ないリソースでしかも高速にこのモデルが使用可能になるという話をちょうど10月初旬頃に聞きました。

当初は「そんなものあるわけないでしょー、どうせなんかちょろっとごまかして速度を上げたりするようなものでしょ？」とか思ったりしたわけですが・・・

今回紹介するのは、そんなことを実際に実現していた Strata という推論エンジンのお話になります。

読み方ガイド
この記事は大きく「Strataの仕組み解説＋GPUSOROBANへの導入手順」と「KV・Expertキャッシュの挙動を含めた実測値」の2部構成になっています。順番に読みたい方はこのまま読み進めてください。数値だけ早く見たい方は、「利用してみてその実態は？」まで読み飛ばしても問題ありません。

Strataについて

Strataは、llama.cppをベースにした「Qwen3.8-Flash-Nextの量子化モデル」を少ないリソース環境で実行できるように様々な工夫を盛り込んだ推論エンジンです。基本的にはllama.cppと同様のインタフェースを構成することが可能であり、GGUFファイルを元にモデルを動かします。最小構成としては

48GB 以上の空きメインメモリ容量
12GB以上の空きVRAM容量
100GB以上のSSD領域

があればQwen3.8-Flash-Nextが動かせると言うとんでもない代物です。

作者は Niko Veitさん
（ https://x.com/coldniko ）で、有志と一緒にこのプロダクトを作り上げています。執筆時点での最新バージョンは、v0.2.2となっています。²

盛り込まれている工夫についてそれぞれ説明していきます。

リソースの3Tier構造

Strataでは、全てをGPU上に配置するのではなく、Qwen3.8-Flash-Nextが持つMoEアーキテクチャ、n-gram Embeddingの能力にうまく乗っかる形でリソースを3階層のTier構造で表現しています。

図 2 リソースの階層構造

GPU上には固定的に「どうしても必要なもの」だけを設置し、non Shared Expertsは全てメインメモリに配置する構造をとっています。必要に応じてよく使われるExpertsのみを「Expert Cache」として配置し、アクセス頻度の高いExpertのみを高速領域におくよう配慮が成されています。

KV Cacheについても、2つの階層に分けて構成されています。

このとき、コンテキスト長をより効率よく稼ぎ出せるようにするため、v0.1.40からElastic KV（--kv-grow）方式を採用しています。
従来はKVキャッシュ部分は固定長で構成されており、必要に応じて代替領域であるピン留めホストメモリに逃がす構造をとっていたのですが、Elastic KV方式では必要に応じてコールド状態のExpert CacheよりKVメモリを優先して明け渡せるように仕組みが変わり、より長いコンテキストサイズが要求されても高速に応答できるように構成されています。

本来Qwen3.8-Flash-Nextではメインメモリにおいていた n-gram Retriever はSSD領域にシフトしています。ある意味従来のPLE本来の使い方に近く、そのデータもGGUFファイルから直接読み出すようにすることで、SSD領域のオーバーヘッドが発生しないように配慮されている点はリソースが限られた環境下では非常に助かるポイントとなっています。

llama.cppラッパーではない

strataが動作するエンジンは、ggml-org/llama.cpp を土台としつつも、MoEオフロード・投機的デコード・独自カーネルなどの大部分を独自実装で追加したハイブリッドエンジン（独自拡張込みの派生エンジン）です。

自動チューニング機能

Strataは、インストール処理の最後に自動チューニングを行い、その環境に応じた最適パラメータをある程度設定できるようになっています。導入後に細かいパラメータチューニングをしなくても一定以上のパフォーマンスが発揮できるため、導入してから運用に載せるまでの時間コストを削減することが可能です。

MTP機能はデフォルトON

生成速度を向上するための施策として、MTP（投機的トークン予測）機能はデフォルトONになっています。これにより、特にマルチターン処理が行われる環境下においては、非常に高速にトークン生成が行え、限られた時間の中でより多くの推論処理ができるようになっています。

SSDに対しての負荷は殆ど読み取り負荷

今回SSDも使うことになるため、例えばSSDキャッシュを構成することにより、書き換えの大量発生でNAND劣化が発生しないかを懸念しましたが、Strataではその領域に使ってるものの大半が n-gram Embeddingとなっています。n-gram Embeddingを構成するデータは固定的な知識データとなっており、これに対して書き換えが発生することはありません。単純に必要に応じて読み取りが生じるだけです。

そのため、Strataを導入することで急激にSSDが劣化、使用不能になるリスクは極めて少ないものと予想されます。

丁度良いところにGPUSOROBAN

GPUSOROBANは日本国内にあるGPUクラウドとしては、個人でも手が出せる価格帯のGPUリソースを持ち合わせたサービスなのですが、その気軽に利用できるリソースの概要は以下のNVIDIA RTX A4000搭載型リソースとなります。

このリソースはコンテナ型インスタンスとして駆動し、その使用料金は 50 JPY/h となっているため、私はよく独立した環境で評価したい場合や自前でIntel ARC Pro B70を買うまでは RTX 3060では手に負えないモデルなどの評価をこのインスタンスで行ってきました。

項目	スペック情報
使用インスタンス種別	s16-1-a-standard-ubs24-v
GPU	NVIDIA RTX A4000
GPUメモリ	GDDR6 16GiB
GPUメモリ帯域幅	448.0 GB/s
演算性能FP32	19.17 TFLOPS
演算性能BF16	38.34 TFLOPS
演算性能INT8	153.4 TOPS
演算性能INT4	306.7 TOPS
vCPU	11 Core
システムメモリ	62.5 GiB ³
ストレージ	Persistent 100 GiB
CUDAバージョン	13.2
NVIDIA Driver Ver.	580
OS	Ubuntu 24.04 Server

表 1 GPUSOROBAN NVIDIA RTX A4000インスタンスのスペック

丁度このStrataを評価しようと思った矢先にこのマシンのスペックを見てみると、丁度良くぴったりこのスペックに当てはまることに気づきました。そこで、このGPUSOROBANのRTX A4000インスタンスをQwen3.8-Flash-Nextを動かすアプライアンスとして何か仕上げられないかと思い、検証を行ってみることにしました。

GPUSOROBANインスタンスにStrataを導入する

本記事ではLinux環境を前提にして記述を進めていきます。

GPUSOROBANに対する操作

GPUSOROBANへのアカウント登録については、以下を参照してください。

https://soroban.highreso.jp/article/article-001

大まかな流れとしては以下の通りとなっています。それぞれ細かな説明がなされてますので、これを参照しながら登録するとよいでしょう。

会員登録
電話番号認証
クレジットカード登録手順
インスタンス接続までの流れ
インスタンスの作成
秘密鍵の設置
アクセスサーバー用秘密鍵の設置
Webコンソールからインスタンスに接続
ターミナルからインスタンスに接続

なお、ターミナルからインスタンスに接続する際、.sshディレクトリ配下に config ファイルを作成し、以下のような設定を追加しておくと便利です。

Host a4000-instance
Hostname <指定されたIPアドレス>
Port 22
User <ログイン先のユーザ名>
LocalForward <転送させたいポート番号> localhost:8080
IdentityFile ~/.ssh/mykey.key
ProxyCommand /usr/bin/ssh -W %h:%p -p <指定されたポート番号> -i ~/.ssh/ackey.txt \
<指定されたアカウント名>@<指定されたログインサーバ名>
Host *
ServerAliveInterval 60

これにより、設定して以降はログインする際

ssh a4000-instance

とするだけでログインできますし、アイドルタイムアウトをしなくなります。また、StrataサービスのSSHフォワードが出来るように自動設定されますので、後々便利です。

Strataの入手・インストール

Strataのインストールを行います。

以下のようにコマンド入力をし、まずはインストールスクリプトを起動します。

curl -fsSL https://github.com/Niko1221/Strata/releases/latest/download/install.sh | sh

すると、まずは以下のような表示が行われ、セットアップ準備がととのいます。

https://github.com/Niko1221/Strata/releases/latest/download/install.sh | sh
Strata Terminal installer
This computer: Linux x86_64 (linux-x86_64), graphics: NVIDIA NVIDIA RTX A4000
Release folder: https://github.com/Niko1221/Strata/releases/latest/download
Terminal 0.1.47 (94 MB)
Downloading…
Checksum ok.
Checking the release's signature…
Signature ok.
Installed. Run: /home/user/.local/bin/strata launch
(To type just 'strata', add this line to your shell profile: export PATH="/home/user/.local/bin:$PATH")

その指示に従い、以下の通りコマンド入力をし、Stratat TUI画面を起動します。

$ /home/user/.local/bin/strata launch

すると、Strata TUI画面が起動し、セットアップするのか、既存モデルからセットアップを行うのかを求められますので、ここで「Set up from the beginning」を選択します。

（画像1）

次にモデルを選択します。

（画像2）

Download列で示されるのはモデルファイルの容量、Needsで示されるのは、メインメモリとGPU上のVRAMを足した値であり、ここから右の列にある「On this computer」列でモデルがこのマシンにあうかどうかを判断されます。

今回、私は Qwen3.8-Flash-Next IQ3_XXSモデルを選択しました。その他UnslothモデルやGyroモデルなども選択が可能です。

なお、Qwen3.8-Flash-Nextとして配布されているモデルの内、IQ2_XS, IQ3_XXS, IQ3_S各モデルは ISTAが開発した Qwen3.8-Flash-Next-RCO-GSQと呼ばれる、量子化レベルに対して非常に性能維持率の高い量子化フォーマットが採用されています。これらのモデルでも十分使用に耐えうると思われますので、あまりリソースに余裕がない場合はこうしたモデルを選択する方が良いかもしれません。

続いて、モデルデータや一時保存されるExpertsデータの保存領域のパスを指定します。通常はホームディレクトリ直下に Strata-data と言うディレクトリを作成し、これを使用します。

（画像3）

続いて、モデルの最大コンテキストサイズを指定します。私は128kを指定しました。256kには少しメモリ消費が厳しくなりそうでしたので、見送っていますが、選択は可能です。

それ以上のコンテキストサイズを実現するには、別途RoPEに対するチューニングが必要で、実験的要素と現在ではされています。

（画像4）

画像エンコーダーを有効化するかどうかを選択します。今回私はYesを選択し、画像エンコーダーを動かす設定にしました。

（画像5）

同時接続数はいくつに設定するかを選択します。なお、2以上にした場合、1つのGPU計算能力を最悪1/n (n:同時接続数)で割り当てることになる可能性があり、その分処理速度が遅くなるため、慎重な選択が必要です。

（画像6）

セットアップ後に行うチューニング作業のモードを指定します。今回はバージョン0.1 の頃と同じようなチューニングを行うQuickを設定します。

（画像7）

Strataが必要とした場合に、PINメモリの選別方法に関して設定を行います。下図の行でEnterキーを押下し、フォーム内に on を入力することで有効化できますが、これはあくまでWindows向け設定とのことで、Linuxではあまり意味がないようです。

本記事ではそのままOnで進めてしまいました。

（画像8）

このとき、従来通りEnterキーを押すと設定画面に入ってしまうため、今回は n を押下して次の画面へ遷移させます。

（画像9）

何経由でアクセスするのかを設定します。今回SSHトンネルで接続することを想定したため、2行目の My local network を指定しました。

（画像10）

ポート番号やAPIキーを変更したい場合、それぞれ p あるいは t を押下することで設定が出来ます。ただ、特にAPIキーに関してはこれをOFFにしてしまうことで逆にアクセス可能にするための手間がもの凄く増えてしまうため、素直にOnのまま自動設定されたパスワードを使ったほうが良さそうです。

（画像11）

設定を保存して後続処理に進むかどうかを選択します。今回 Save as a preset and launch を指定して先に進めます。

（画像12）

まず、モデルファイルのダウンロードを今から行うかどうかの確認が求められます。今回はダウンロードする方を選択してモデルファイルのダウンロードを即時開始します。

（画像13）

ここからインストール処理が開始され、Engineの構築やモデルのダウンロードが行われます。

（画像14）

（画像15）

起動が完了すると以下のようになります。

（画像16）

キャラクターベースのダッシュボードのような画面が表示されます⁴。ここで、CUIを使った監視が可能となっています。

このダッシュボード、1行あたりの表示文字数が少ないと以下のように簡易型に変更されます。こうしたところはある意味便利と言えるかもしれません。

（画像17）

インストール後、PATH環境変数に /home/user/.local/bin を含めておくと、後々コマンド実行が楽になるので、設定しておくことをお勧めします。

インストール処理にかかった時間(v0.1.x系の場合)

v0.2.x系に移行してから、インストールの時間計測が難しくなり、あまり正確性を帰すことが出来ないため、この前に実施していたv0.1.x時点のインストール処理時間の計測をもって回答にしたいと思います。

インストール処理にかかった時間ですが、ちょうど以下の時間が記録されていましたので、これを参考に処理の時間目安がでました。

2026/10/6 20:37 にGithubよりcloneされたファイルが配置された
2026/10/6 21:13 に起動スクリプトである run-swift-iq2_xs.sh が作成された⁵

正味のインストール処理時間として、ダウンロード環境に寄って左右される可能性はあるため、一概には言い切れませんがおよそ 36分ほど時間がかかったようです。

ここからさらに7回ほど起動・停止を繰り返して自動チューニング処理を行っていますので、それをログから追いかけてみると以下の通りとなっていました。

起動・停止ターン数	Expertロード時間
1(自律チューニング)	359 sec
2(自律チューニング)	363 sec
3(自律チューニング)	362 sec
4(自律チューニング)	362 sec
5(自律チューニング)	362 sec
6(自律チューニング)	362 sec
7(本起動)	362 sec
合計	2,532 sec

表 2 自律チューニングにかかる時間（ログから分かる部分のみ）

これと計測処理はあまり正確には測れませんでしたが、10分程度正味の計測処理に時間がかかったと仮定して 3,132 sec ≒ 52.2分 < 1時間以内には処理が完了すると予想されることから、総合すると1台分推論マシンを作成するのにおよそ1.5時間～2時間程度見ておけば余裕を持ってインストール作業は完了できるのではないかと考えられます。

なにより、自動処理でインストール作業どころか必須コンポーネントのインストールまで完結できるように構成されているのは非常にありがたいところです。ある程度プラットフォームを縛ることにはなるのでしょうが、少なくともそれがGPUSOROBANのインスタンス上で大きな問題になることは結局ありませんでした。

かかったコストについて(v0.1.x系の場合)

こちらも、チューニング時間の計測が非常に難しかったため、v0.1.x系で試したときの結果の転載となります。スミマセンがご容赦ください。ただし、v0.2.x系の方が時間がかかったかというとそれほどでもありませんでした。

逆に、v0.1.xの方が内容を理解するまでに時間がかかってしまい、そちらの方がより時間がかかったんじゃないかという印象です。

インストールして何度か実行した時の請求額なのですが、以下の通りとなりました。

図 3 セットアップおよび1時間程度利用した際の利用料・利用額

1時間あたり50円のレートとなっているため、それ相応の内容となっています。オーバーインストール時のオーバーヘッドとして、このような感じですね。適宜必要な時にON/OFF操作をすることにより、かなりの金額を節約することが可能かなと思います。

もし、常時電源を入れっぱなしにしておこうかなと言う場合には月額プランというのもあるようですので、そちらをご利用頂くことをお勧めします。

Strataを動かす

Strataの起動

Strataを起動する際は、インストール時に指定されたパスを指定し、launchコマンドを実行します。初回実行時はインストール処理が行われたのですが、既に設定が組み上がった場合は、その設定に従って起動処理が開始されます。

$ /home/user/.local/bin/strata launch

以下の画面が表示されますので、一番上に表示されてるモデル名を選択してEnterを押すことにより、エンジンが始動します。

（画像1）

なお、このときエンジンはおよそ480秒程度かかって起動します。この間はディスクからメモリに様々なものをロードしたり配置したりしますので、かなりDisk I/Oに負担がかかることを認識しておいた方が良いでしょう。

Strataの停止

Strataを停止する際はCtrl + C を押してプロセスを終了させることになります。押すと以下のような画面が表示されます。

（画像1）

Stop serving in the background を選択することで停止します。

そのままフォアグラウンドの部分のみアクセスを解除して継続してエンジンを動かすことは可能です。その場合は A Keep serving in the background を選択してください。

Strataのアップデート

strataは、アップデートコマンドがあり、これを使用することで最新バージョンへのアップデートが可能です。以下は実行例です。エンジンとコントロールプレーンがそれぞれ更新されていることが分かります。

$ strata update
Strata update (https://github.com/Niko1221/Strata/releases/latest/download)
Reading the signed update feed
downloading engine 0.1.48 linux-x86_64-cuda-cuda13: 100% (578 of 578 MiB)
Unpacking 0.1.48 linux-x86_64-cuda-cuda13
Checking the package signature and every file
Test-starting engine 0.1.48 linux-x86_64-cuda-cuda13 before switching to it
Switching to engine 0.1.48 linux-x86_64-cuda-cuda13
Engine 0.1.48 is installed and will be used on the next start
downloading Control 0.1.49.1: 100% (94 of 94 MiB)
Unpacking Control 0.1.49.1
Test-starting Control 0.1.49.1
Feed sequence 111, signed by 5d1bc23abbeffd0d
Engine 0.1.47 -> 0.1.48 updated (tested: started, answered one token, stopped)
Control 0.1.47 -> 0.1.49.1 updated. The next `strata` command already runs it; the app switches on its next start
Saved tuning presets: marked for the short re-check (nothing was deleted).
The previous engine version is kept; `strata components rollback` returns to it.

エンジン差し替え時にどうやら動作テストを行う仕様のようで、アップデートには時間がかかりそうです。

Strataの設定

ここはStrataの泣き所の1つなのですが、実はちゃんとしたConfigに関するリファレンスがありません。また、v0.1.x系とv0.2.x系とでは少し仕様が異なるようです。

設定ファイルは以下の場所にあります。

/home/user/.config/strata/launch-presets/iq3_xxs-128k.json

設定ファイルは今回の場合は以下のようになっていました。

{
"access": "lan",
"api_key": "XXXXXXXXXXXXXXXXXXXXXXX",
"context": 131072,
"created": "2026-10-23 13:54:09.666900",
"data_dir": null,
"extra": {
"STRATA_PIN_BY_NEED": "on"
},
"family": "qwen",
"gpu_roles": null,
"gpus": null,
"kv": null,
"last_used": "2026-10-23 15:28:25.785562",
"model": "IQ3_XXS",
"model_path": null,
"mtp": null,
"name": "IQ3_XXS 128K",
"no_key": true,
"parallel": null,
"port": 8080,
"schema": "strata.launch/1",
"tune": "quick",
"tune_allow_small": false,
"tuned_at": "2026-10-23",
"tuned_preset": "4082656e867d420899b7348cd4987f74",
"vision": "cpu"
}

この設定の変更項目についてですが、記載されているものに限って言えば次の表の通りとなります。

キー	あなたの値	意味
schema	strata.launch/1	プリセット形式のバージョン識別子。SCHEMA 定数そのもの
name	IQ3_XXS 128K	プリセット名。ファイル名 iq3_xxs-128k.json はこの名前の slug 化（小文字化・記号を - に）結果
family	qwen	カタログの「家系」（qwen / swift / coder / unsloth / gyro / nvfp4 …）。qwen は元の Qwen3.8-Flash-Next 量子化
model	IQ3_XXS	カタログ上のサイズ（量子化強度）。48 GB 世代の推奨枠
model_path	null	「自分で用意した .gguf / フォルダを使う」経路は未使用
data_dir	null	モデル保存先は Strata の既定フォルダ
gpus	null	GPU 選択はエンジン任せ（使用可能な全カード）
gpu_roles	null	カード別ロール（main / helper / off）は推奨どおり。複数カード時のみ意味を持つ
context	131072	128K トークン。parse_context は 128k / 131072 alike を同じ値に正規化する。既定の選択肢は 8K〜512K
kv	null	K/V キャッシュの量子化。「8K を超えるなら int8」という setup と同じ既定に従う（int8 / q4_0 / k8v4 / fp16 が選択肢）
vision	cpu	画像リーダーを CPU で実行。選択肢は off / on / gpu / cpu
parallel	null	同時リクエスト数。「カードに合わせる」既定（VRAM 12GB→1、20→2、24→3、32GB以上→4）。1〜8 が有効値
mtp	null	下書き層（draft layer）は「インストールされた状態どおり（on）」
tune	quick	自動チューニングの方式。quick（約20分）/ thorough（最大2時間）/ skip
tune_allow_small	false	「回答がわずかに変わる可能性を受け入れる」チェック。既定 off。true のときのみ起動コマンドに --allow-small-differences が追加される
access	lan	公開範囲。local / lan / cloudflare / tailscale の4種。lan は「自分のローカルネットワーク」
port	8080	サーバのポート（既定値）。OpenAI 互換は http://<IP>:8080/v1
api_key	設定あり	秘密キー。「全体を表示することはなく、プライベートなプリセットファイルにのみ保存される」
no_key	true	--no-api-key で「意図的にキー無しで他マシンに公開する」フラグ。拒否ではなく警告になる
extra	{"STRATA_PIN_BY_NEED": "on"}	高度設定。--set key=value で入るエンジン側のフラグ／STRATA_* 環境変数の袋
tuned_preset	<記載省略>	チューナーが保存したチューニングプリセットの ID（strata presets 経由でアプリからも見える）
tuned_at	2026-10-23	チューニング実施日。tuned_preset または tuned_at のどちらかがあれば「チューニング済み」とみなされ、次回以降再計測しない
created / last_used	2026-10-23	作成時刻・最終使用時刻（起動のたびに更新される実行時情報）

表 3 設定内容・設定値とその詳細

その他、起動時に指定する引数などは本記事の末尾にある付録にて掲載しています。

Strataの動作原理

strataコマンドを実行すると、どうやら以下のような流れで周辺プロセスが動き出すようです。

図 4 strataコマンドによって連動するいくつかのコンポーネント

strataコマンドは、 ~/.local/share/strata/terminal/0.1.47/strata.py に対するラッパーとして動作し、それはstrata用に準備されたPython3.12を経由して実行されます。これを受け、strata.py はサブコンポーネントである strata-terminal の起動コマンドである ~/.local/share/strata/terminal/0.1.47/setup.py 実行します。

実はこの setup.py それ自体は、元々 v0.1.x系だったときのstrata-engine 起動コマンドでもありました。v0.2.x系より実装された strata コマンドは、主に管理コマンドが拡張されたバージョンであることを示しています。

そして、setup.py コマンドはさらにその環境に合わせた strata-engine と言うサブコンポーネントを起動させ、これがエンジン本体となって稼働します。そのコマンドの変遷を見るとどのような設定で起動されていくのかが把握しやすいです。

■例：入力コマンド

strata launch
--preset IQ3_XXS 128K
--no-tui

■最初に起動されるもの

/home/user/.local/share/strata/terminal/0.1.47/python/bin/python3.12 /home/user/.local/share/strata/terminal/0.1.47/strata.py launch
--preset IQ3_XXS 128K
--no-tui

■次に起動されるもの

/home/user/.local/share/strata/terminal/0.1.47/python/bin/python3.12 /home/user/.local/share/strata/terminal/0.1.47/setup.py
--yes
--no-start
--family qwen
--model IQ3_XXS
--context 262144
--vision cpu
--experimental-speed-projection off
--data-dir /home/user/Strata-data

■最後に起動されるもの

/home/user/.local/share/strata/components/engine/0.1.47-linux-x86_64-cuda-cuda13/strata
--serve
--pack /home/user/Strata-data/packs/iq3_xxs
--native /home/user/Strata-data/models/IQ3_XXS/Qwen3.8-Flash-Next-GSQ-RCO-IQ3_XXS-00001-of-00002.gguf
--ple-gguf /home/user/Strata-data/models/IQ3_XXS/Qwen3.8-Flash-Next-GSQ-RCO-IQ3_XXS-00002-of-00002.gguf
--expert-profile /home/user/.local/share/strata/terminal/0.1.47/data/expert-profile.bin
--expert-cache auto --prefill auto
--spec 4
--spec-min-p 0.5
--mtp /home/user/Strata-data/mtp/rt
--max-context 262144
--kv int8
--vision

Strata-dataディレクトリの構造

Strata-dataディレクトリがインストール時に作られていることは画面を通して確認したかと思います。そこには何が格納されてるのでしょうか。実体は以下の通りです。

モデルやトークナイザといった、モデルに関連するものが格納されています。これらはインストール時に決めたモデルネームによってプロファイルが作成されており、そのプロファイルに基づいて格納されています。

図 5 Strata-data ディレクトリの配置構造

単純にStrataはGGUFファイルからモデルを再生しているわけではなく、実は以下のような過程を経てデータが格納されています。

データ区分	重みデータ等の読み出し方法	備考
Dense層データ	独自形式に変換・配置してからエンジンが読み出し	dense.bin等のデータとして格納
Expert層データ	GGUFから直接読み出し、基本全Expertをメインメモリ上にロード、別途定めるExpert配置計画に基づきVRAMへ移行	GGUFからの読み出しとなるため、ファイルの配置は無し
n-gram Embeddingデータ	GGUFから必要に応じて都度読み出し	GGUFからの読み出しとなるため、ファイルの配置は無し

表 4 エンジンからデータを取り込む際の動きの違い

StrataのWebフロントエンド

llama.cpp ですと、Webフロントエンド機能が備わっており、直接URLにアクセスするとチャット画面が表示されていますが、Strataにもそうしたものが用意されています。

図 6 StrataのWebフロントエンド画面

優秀なのはモニタリング画面です。モニタリング画面は、画面左上の「Monitor」をクリックすることによって遷移します。

図 7 メニュー切り替え部分

この画面はリアルタイム状態が表示されており、特に「Model State」画面では、現在Strata上に搭載されたモデルが現在どういう処理をしているかがわかるようになっています。

その際、GPUが処理しているのか、CPUが処理しているのか、そのハイブリッド状態まで追跡できるようになっています。

図 8 モニタリング画面の上半分には、様々なステータスがリアルタイム表示される

モニター画面下部は構成を取っており、コンテキストがどの程度使用されたか、どの程度のExpertがVRAMに常駐してるかが分かるようになっています。画面右側では、それまでに実行した推論処理に関する記載があります。

図 9 モニター画面下部

なお、これらの機能はAPIを有効にしてる場合、ちゃんとAPIキーをセットしなければなりません。

（画像1）

画面右上を見ると「API key needed」と書かれています。

この場合、About画面から少し下にスクロールするとAPIキーを入力する欄がありますので、そこにAPIキーをセットします。

（画像2）

画面右上の表示が idle になれば、正常に認証されたことになります。

利用してみてその実態は？

消費リソースはどれほどか

消費リソースは各Tierで比較した結果、以下の通りとなりました。

Tier	使用容量	所感
GPU上のVRAM	15,639 MiB	ほぼ満杯
メインメモリ（Shard 1）	41.0 GiB	想定通りか
SSD(Shard 2)	81.0 GiB	想定通りか

表 5 リソース消費量の概要。3bit量子化を使用したため、比較的少なめに済んでいる。

メモリ残量としては、およそ23,000 MiB程度、ストレージ残量としてはおよそ 17GiB となりましたので、これ以上にさらに何らかのツールを動かすのはちょっと難しいかもしれません。しかし、これをアプライアンスとして動かすのであれば、その分にはあまり大きな影響にはならないかなと感じています。

例えば以下のように構成して推論環境をワークグループや組織内用途で利用すると良いのではないかと考えています。

図 10 Enterprise用途を想定した場合の構成イメージ

性能はいかほどか？

実際にDify Agent越しにモデルとやり取りした結果は以下の通りです。

Time	Prompt	Reused	Output	Prefill t/s	Decode t/s	VRAM hit rate	Duration
16:18:22	50,582	46,650	6,760	719	68.3	84.10%	104.4
16:17:41	46,655	38,349	1,290	665	65.6	84.40%	32.2
16:17:04	38,354	14,694	966	1,548	69.7	83.30%	29.1
16:16:48	14,699	13,661	343	485	77.5	80.40%	6.6
16:16:40	13,666	13,024	240	443	75.1	79.20%	4.7
16:16:30	13,029	12,858	483	225	69.5	84.30%	7.7
15:55:15	27,256	12,858	6,028	1,529	78	81.50%	86.7
15:51:38	84,787	76,691	7,070	421	73	82.30%	116.1
15:50:39	76,696	58,114	2,137	752	67	82.00%	56.6
15:50:15	58,119	50,647	637	621	69.5	79.90%	21.2
15:49:54	50,652	44,921	744	896	70.9	80.60%	16.9
15:49:20	44,926	18,646	507	1,409	69.8	80.20%	25.9
15:49:03	18,651	12,939	301	1,268	76.9	75.30%	8.4
15:48:32	12,944	12,858	1,803	178	69.3	87.50%	26.5
15:47:49	17,789	12,939	210	908	86.7	76.50%	7.8
15:47:31	12,944	12,858	692	145	66.1	83.40%	11.1
15:38:25	38,661	38,477	4,375	241	74.3	81.80%	59.7
15:38:11	38,482	37,595	671	342	63	79.90%	13.3
15:38:01	37,600	35,633	203	391	68.1	81.10%	8
15:37:36	35,638	25,120	256	540	71.2	78.30%	23.1
15:36:29	25,125	0	994	556	65.5	79.40%	60.4
平均値	36,060	28,073	1,748	680	71.19	81.21%	34.59

表 6 Strata上でQwen3.8-Flash-Nextを動かした時のパフォーマンス計測結果

実は読み出し速度はそれほど早くはありません。読み出し処理ではGPUプロセッサの速度そのものが大きく反映されます。NVIDIA RTX A4000の能力的な弱さが表に出てしまった結果となっています。また、KVキャッシュ量は（モデルの最大である256kはもちろん、）今回設定した128kであっても丸々VRAM上で抱えているわけではなく、一定量のみVRAMに確保、そして入りきれない残り分のデータはピン留めメインメモリ上に確保される仕様である為、そこのオーバーヘッドが出た可能性はあります。ただ、Strataではプロンプトキャッシュがそれを吸収しており、体感速度にはそれほど遅くは出ていません。

何より驚くのはVRAMのExpertキャッシュへのヒット率が非常に高いことです。これはExpertやKVキャッシュが関係しますが、そうしたものへのヒット率が高いからこそ、実際のスループットが高めに出ているのだろうと考えられます。

その出力速度足るや、過日A100インスタンスを用いてQwen3.8-Flash-Nextを評価した時のllama.cppによる出力速度はおよそ50～60tok/sぐらいでしたので、それ以上の値が出ていたことには驚きです。

まとめ：特化型推論エンジンであることは忘れないように。

しかし、このQwen3.8-Flash-Nextは特化型の推論エンジンであるため、他のモデルの推論に使うには少々無理が出てきます。

MoEとn-gram Embeddingが揃って初めて効果をもたらす
このエンジンは非常に細かく構成された大量のExperts構成と本来メインメモリに置くべきn-gram EmbeddingをPLE技術でSSDへシフトさせることで高性能を実現しているため、例えばDenseモデルを動かすにはかなりの無理が出てきます。
メインメモリにDense層を移してしまうとそのスループットに引きずられて出力速度は一桁Tok/s台に低下しますし、じゃぁVRAMに移すかとなると本末転倒になってしまいます。

また、Qwen3.8-Flash-Nextは、本来MoEだけで構成した時にどうしても足りなくなる知識量をN-gram Embeddingで穴埋めをしたモデルです。それをPLE方式でSSDにシフトさせているからこそ成り立つ仕組みと言っても過言ではありません。
通常のMoEアーキテクチャでも実装は可能かもしれないのですが、そもそもMoE自体回答品質面でDenseモデルに劣ってしまうことから、あまり積極的に採用されていない状況であり、他のMoEモデルを適用するにはStrataは少々仕組みが複雑すぎるようにも思えます。
対個人向けの色が濃いプロダクト
プロンプトキャッシュを前提にした構成であるため、これを外してしまうと、読み出し処理（Prefill処理）の面で不利になる可能性が高いです。また、開発期間が浅く、どちらかというと昔のllama.cppに似た印象を受けるプロダクトです。
そのため、エンタープライズで集約的に行うにはまだ少し弱い部分が多いかなというのが率直な印象です。

しかし、その後Prompt Cacheをオフにする設定が追加実装されていたり、Parallel設定が可能になっていたりと、一部llama.cppの機能と連携させつつうまくEnterpriseでも使用に耐えられるような仕組みが追加されており、処理の無駄も順次取り払われて非常に高速に動作するようになってきています。

これに限らず、出てくるモデルの詳細次第でありますが、もし、Qwen3.8-Flash-Next以外のモデルもメインメモリ等でうまく吸収できるようになると、それまでの常識が覆されるのでそういう意味では今後の展開が期待されます。

私個人としては、このプロダクトはそうした先見の明を持って作ったプロダクトなのだろうと感じていて、今後が楽しみです。

参考文献

Deepwiki, Niko1221/Strata https://deepwiki.com/Niko1221/Strata
Niko1221. “Strata README.md（Version 0.2.2 / engine 0.1.47）.” GitHub main branch. https://github.com/Niko1221/Strata/blob/main/README.md
Niko1221/Strata. “strata_cli/launch/settings.py（LaunchSettings, SCHEMA, ACCESS_KINDS, split_setting, as_argv_changes, flags_text, slug）.” GitHub main branch. https://github.com/Niko1221/Strata/blob/main/strata\_cli/launch/settings.py

付録：strata launch ヘルプ（日本語版）

使い方の表記（原文のまま）

usage: strata launch [-h] [--preset NAME] [--model NAME] [--family NAME]
[--model-path PATH] [--data-dir DIR] [--move-data]
[--context SIZE] [--kv FORMAT] [--vision off|on|gpu|cpu]
[--parallel N] [--mtp on|off] [--gpu LIST]
[--gpu-roles LIST] [--tune quick|thorough|skip] [--tune-allow-small]
[--set KEY=VALUE] [--pool-cores LIST]
[--access local|lan|cloudflare|tailscale] [--port N] [--api-key KEY]
[--api-key-env NAME] [--new-key] [--no-api-key]
[--save-preset NAME] [--retune] [--no-tui] [--open] [--yes] [--plan]
[--feed URL|DIR] [--output {human,json}][--list-presets]
[--delete-preset NAME] [--status] [--stop]
[--show-key]

概要

モデルのセットアップ、チューニング、サービング（提供）開始、監視を、一か所に集約します。

フラグを付けずに実行すると、ガイド付き画面が開きます。保存済みプリセットから始めるか、最初からセットアップするかを選べます。画面ごとに決めることは 1 つだけです。

フラグを付けると、同じ内容を質問なしで行い、モニターを開きます。--no-tui を付けると、アドレスを表示して終了します。

プリセットは Strata アプリのプロファイルおよびチューニングプリセットと共有されます。

共通

オプション	引数	日本語の意味	出典表記
-h, --help	なし	この使い方を表示して終了する	options

表 7 共通オプション

実行内容の指定（what to run）

オプション	引数	日本語の意味	既定値・補足
--preset NAME	名前	保存済みプリセットを開始する。他のフラグを併用すると、その回の起動に対してだけ内容が変わる	既定なし
--model NAME	名前	モデルのサイズ。例 iq3_xxs、q2_0、ud-q4_k_xl。大文字・小文字は問わない	—
--family NAME	名前	同じサイズが複数のモデルファミリーで提供されている場合に、ファミリーを指定する（qwen、swift、coder など）	—
--model-path PATH	パス	すでに手元にあるモデルファイルを使う。shard が並ぶフォルダ、または単一の .gguf ファイル	—
--data-dir DIR	ディレクトリ	ダウンロードしたモデルファイルの保存先	Strata のデータフォルダ
--move-data	なし	--data-dir と併用し、すでに持っているモデルを新しいフォルダへ移動する。付けなければ何も移動しない。既存モデルは元の場所に残り、そのまま使え、新しいフォルダは今後のダウンロード先になる	移動しない
--context SIZE	大きさ	一度に記憶できるテキストの量。32k、64k、128k、256k、またはトークン数	—
--kv FORMAT	形式	会話メモリ（KV キャッシュ）の形式。int8、q4_0（メモリは半分量）、k8v4、fp16	既定 int8
--vision off\|on\|gpu\|cpu	4 択	モデルに画像を読ませる。on はビデオメモリでリーダーを選ぶ（24 GB 未満なら CPU リーダー、24 GB 以上なら GPU リーダー。メーカーは問わない）。gpu / cpu は明示的に選択、off は画像機能無効	既定: モデルが画像を読めて、かつエンジンに画像リーダーがある場合は on
--parallel N	1〜8	同時に応答するリクエスト数	既定: グラフィックカードに合わせた値
--mtp on\|off	on / off	応答を速くするドラフトレイヤー。off は無しで開始し、ビデオメモリが約 1 GB 減り、RAM も減るが、応答は遅くなる。小さいカードや RAM の少ない PC で起動時にエンジンが停止する場合に使う	既定 on
--gpu LIST	番号	使うグラフィックカードの番号。例 0、0,1	既定: エンジンの選択
--gpu-roles LIST	役割一覧	カードごとに役割を割り当てる。main、helper、off。例 1=main,0=helper。指定しなかったカードは off。main は各応答の最終ステップを実行し、helper はモデルの一部を保持する	—
--tune quick\|thorough\|skip	3 択	先に最速の設定を探す	既定: ここでは skip。ガイド付き画面では初回に quick を提案
--tune-allow-small	なし	テューナーに、答えを非常にわずかに変えうる設定も試させる	既定: 試さない
--set KEY=VALUE	KEY=VALUE	高度なエンジン設定、または STRATA_* 変数を 1 つ設定する。例 prefill=65536。繰り返し指定できる。未知の名前は拒否ではなく警告だけ出る	—
--pool-cores LIST	一覧（実験的）	CPU ワーカーを、指定した論理プロセッサに固定する。例 2,4,6,8 や 2-14:2（Task Manager や lscpu が表示する番号）	既定: 物理コアあたり 1 ワーカー（エンジンの起動行が表示する）。同一コア上の 2 エントリは警告付きで保持

表 8 基本設定として必要となる引数

誰が使えるか（who can use it）

オプション	引数	日本語の意味	既定値・補足
--access local\|lan\|cloudflare\|tailscale	4 択	local: このコンピューターのみ。lan: 自分のネットワーク。cloudflare: 簡易トンネル。tailscale: 自分の tailnet	—
--port N	番号	ポート番号	既定 8080
--api-key KEY	キー	クライアントが送信すべきキー。このコンピューター外に共有する場合は自動で作られる	—
--api-key-env NAME	環境変数名	この環境変数からキーを読む	—
--new-key	なし	新しい API キーを作成する	—
--no-api-key	なし	API キーなしでこのコンピューター外に共有する。警告は表示されるが、拒否はされない	—

表 9 権限に関連する設定

実行・保存（running）

オプション	引数	日本語の意味	既定値・補足
--save-preset NAME	名前	この選択内容をこの名前で保存する	—
--retune	なし	--tune と併用し（--tune が無い場合は quick を使用）、このコンピューターで既にチューニング済みでも再計測する	既定: 保存済みのチューニング結果を再利用し、計測しない
--no-tui	なし	画面を開かない。サーブし、アドレスを表示して終了する	—
--open	なし	サービング開始時に、サーバーのウェブページをブラウザで開く。このフラグが無ければ何もブラウザを開かない	既定: 開かない
--yes	なし	質問しない。例として、エンジン未導入のコンピューターでモデルをダウンロードするかどうかの質問	既定: 質問する
--plan	なし	何が起こるかを表示して終了する。何も変更しない	—
--feed URL\|DIR	URL またはディレクトリ	署名付きアップデートフィード（エンジンのダウンロード元）の場所	既定: STRATA_UPDATE_FEED、またはプロジェクトの（原文で説明がここで途切れている）
--output {human,json}	human / json	出力形式。原文に説明は無い	原文に記載なし

表 10 実行・設定保存に関係するオプション

管理（manage）

オプション	引数	日本語の意味
--list-presets	なし	保存済みプリセットを一覧表示する
--delete-preset NAME	名前	保存済みプリセットを削除する
--status	なし	このコマンドが現在サーブしている内容を表示する
--stop	なし	このコマンドが開始したものを停止する。--preset NAME を併用すると、その 1 件を停止する
--show-key	なし	--preset NAME（または起動中の launch）の API キーを表示する

表 11 管理系オプション

例（コマンドは原文のまま）

ガイド付き画面を開く

（保存済みプリセットの一覧から、その後、最初からのセットアップ）。

strata launch

保存済みプリセットを開始し、モニターを開く。

strata launch --preset "IQ3_XXS 128K"

すべてをコマンドラインで指定し、サーブして、アドレスを表示する。

strata launch --model iq3_xxs --context 128k --parallel 4 --vision off --tune quick \
--access lan --port 8080 --save-preset "Office" --no-tui

すでに持っているモデルファイルを使う（フォルダ、または単一の .gguf）。

strata launch --model-path /data/models/IQ3_XXS --no-tui

この回の起動に対して、高度な設定を 1 つだけ変更する。

strata launch --preset Office --set prefill=65536 --set STRATA_PIN_BY_NEED=1 --no-tui

何も変更せず、何が起こるかだけ表示する。

strata launch --plan --model q2_0

プリセットと稼働状態の管理。

strata launch --list-presets | --delete-preset NAME | --status | --stop [--preset NAME]

Strata を接続できるアプリを一覧する（launch ではなく connect サブコマンド）。

strata connect

稼働中サーバー向けに OpenCode の設定を書き込む（バックアップは保持される）。

strata connect opencode --write

付録：選択可能なモデル一覧

表 12 インストーラで選択可能なモデルと必要なリソース量

この記事がリリースされる頃には、もう既にQwen4.0がリリースされているかもしれませんが、それを考慮してもなお、Qwen3.8-Flash-Nextは非常に高性能なモデルと言えます。 ↩
開発スピードはもの凄く速く、そのため実際にはかなりバージョンが進んでいる可能性があります。予めご了承ください。 ↩
公称値は50GBとなっていたのですが、topコマンドで見て見ると64044.5 MiBでした。恐らく公称値はメモリ残量を示していたのだろうと推察されます。 ↩
フォントが悪かったのが、Teratermの問題かは分かりませんが、画面が崩れてます・・ ↩
このときのバージョンでは、リポジトリからクローンしたディレクトリ上で直接実行ファイルなどを作成して動かすような仕様となっていました。 ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up