StrataはCPUとGPUで計算を分担して大型MoEを動かす

12GBのグラフィックスメモリで、1250億パラメーターのAIモデルを動かす。Strataが掲げるこの使い方は、モデル全体をVRAMに詰め込んで実現するものではない。よく使う「専門家」の重みをVRAMに置いてGPUで計算し、残りは主にRAM上の重みを使ってCPUで計算する。また、このモデルが短いトークン列から計算用の数値を引くPLE表はSSDに保存し、必要な行を取得する。PC全体の容量と処理速度が、使い勝手を決める。

2026年10月4日公開のv0.1.39では、生成処理と長い入力の読み込みを改良し、複数の要求を同時に扱う機能とCodex CLI向けのResponses APIを加えた。手元のモデルでコードを書かせ、ツールの結果を渡して作業を続ける用途が具体的になった。ただし、並列化で速くなるとは限らず、APIにも対応範囲がある。

この記事はv0.1.39のリリース、タグに固定した文書とコードを読んだ解説だ。性能値は開発者や貢献者の報告として扱う。LATENTではモデルのダウンロード、推論、Codexとの接続実験を行っていない。

この記事の要点

1. StrataはQwen3.8-Flash-Next系の推論ソフトだ。頻出の専門家の重みをVRAMに保持してGPUで計算し、VRAMにキャッシュしていない重みは主にRAMからCPUが読んで計算する。12GB GPUで使えても、モデル全体が12GBに収まるわけではない。
2. v0.1.39のRTX 5070による旧版比較では、生成速度が2.5〜6％向上した。4件の並列処理では最後の応答開始が11.2秒から1.8秒へ早まる一方、合計の処理速度は約11％下がった。量子化、文脈長、キャッシュ容量で結果は変わる。
3. Codex CLIはResponses API経由でローカルモデルに接続し、ツール実行の結果を返せる。開発者はCLI 0.160.0で確認したが、保存済み応答IDによる継続やOpenAIのホスト型ツールには対応しない。OpenAIのCodexモデルをローカル化する機能ではない。

1250億パラメーターのモデルをPC全体で動かす

Strata自体は、知識を学習した新しいAIモデルではない。学習済みの重みを読み、入力から出力を計算する推論ランタイムである。v0.1.39の中心はQwen3.8-Flash-Nextと、その量子化版や派生版だ。どのモデルでも読み込める汎用エンジンではない。

MoEはMixture of Expertsの略で、計算の一部を「専門家」と呼ぶ複数のネットワークへ振り分ける構造だ。専門家は人間の役職や知識分野をそのまま表すものではない。入力に応じてルーターが使う専門家を選ぶため、保存する重みの総量に比べて、1回の計算で使う重みを少なくできる。

通常版の構造は48層、各層512専門家で、合計24,576専門家となる。各トークンは各層で10専門家を使う。ここでのトークンは単語の一部や記号などの処理単位で、日本語の1文字とは限らない。「モデル全体から10個だけ選んで終わる」と読むと、層を重ねて処理する部分を見落とす。モデル構造の定義とルーターの実装で確認できる。

生成時と入力処理時で専門家の使い方が変わる

文章を少しずつ生成するdecodeでは、よく選ばれる専門家の重みをVRAMに残す。GPUはその重みを使って専門家の計算を行い、注意機構や出力部分なども計算する。通常モードでは、全専門家の重みをRAMにも保持する。VRAMにキャッシュしていない重みは主にCPUがRAMから読み、その場で計算する。GPUとCPUの仕事を重ねるため、VRAMにない重みを毎回すべてGPUへコピーする必要はない。

ただし、CPUとGPUの分担は固定ではない。会話に応じてVRAMにキャッシュする専門家の重みを入れ替え、キャッシュしていない重みの一部をPCIe経由でGPUへ送って計算させる経路もある。PCIeはCPU側とGPUをつなぐ通信路だ。CPUの速さ、RAMの帯域、PCIe転送、キャッシュに当たる割合が、生成速度に関わる。

生成中はGPUとCPUが専門家の計算を分担する

ルーターが各層で10専門家を選ぶ

GPUとVRAM

よく使う専門家の重みをVRAMに保持

GPUで専門家や注意機構などを計算

CPUとRAM

通常は全専門家の重みをRAMに保持

キャッシュにない重みを使ってCPUで計算

両方の計算結果を合わせて次の処理へ進む

PLE表をSSDに保存　IQ4_NL形式では約28.8GB

キャッシュにない行をSSDから読み、読み出した行の一部を再利用する

Qwen3.8-Flash-Next系には、短いトークン列からモデルの計算に使う数値の列を取り出す、PLEという仕組みがある。その学習済みの埋め込み表がper_layer_token_embd.weightで、StrataはSSD上のモデルファイルから参照する。文章や回答例を保存した表ではなく、MoE全般に必須の仕組みでもない。

ここでいう約28.8GBは、元モデルのQ2_0、IQ2_XS、IQ3_XXS、IQ3_SとCoderが共用する、IQ4_NL形式のPLE表の容量だ。320,001,536行を1行90バイトで保存するため、合計28,800,138,240バイト、十進単位で約28.8GBになる。専門家の量子化名とPLE表の保存形式は別であり、この容量がすべての形式に当てはまるわけではない。

表を引くときは、現在のトークンと直前の2トークンを使う。現在と直前の2個組が2-gram、さらに1つ前まで含む3個組が3-gramとなる。それぞれ8ヘッドで行番号を計算するので、1トークンにつき参照先は計16行だ。同じ短いトークン列から、複数の数値の列を取り出して使う仕組みである。

Strataは必要な行を専用の行キャッシュで探し、そこにない行をSSDから読む。取得した値は量子化を戻して数値の列にし、GPUへ渡してモデルの計算に使う。読み出した行の一部は容量を制限したキャッシュに残るため、参照のたびに必ずSSDを読むわけではない。

RAM消費を抑えるため、SSD向けの既定設定--ple-io directでは、表全体をRAMに常駐させず、OSのファイルキャッシュも迂回して読む。ただし、専用の行キャッシュや読み出し用バッファにはRAMを使う。これは専門家の重みをすべてRAMへ置く通常モードでも行う、PLE表側の処理だ。短い概要文書にはOSキャッシュ経由という説明も残るため、ここではDETAILSの設定説明と表の定義、行番号を求める実装に従った。

入力をまとめて読むprefillでは、別の使い方になる。通常は最大8,192トークンの単位で、必要な専門家の重みをGPUへ順に送り、まとまった行列計算を行う。次の層で使う重みの転送と、現在の層の処理を重ねる。生成時にCPUが使う重みも、長い入力を読む間はGPUへ送る価値がある。処理するトークン数が多く、転送した重みをまとめて使えるからだ。

重みの配置とは別に、過去の文脈を再利用するKVキャッシュもメモリを使う。64K以上では、条件が合えば主な部分をRAMに置き、注意機構がよく読む32K分をVRAMに残す。これで専門家の重み用のVRAMを確保する。ただしWSLや一部のKV形式では使えない。KVストリーミングの条件、GPUへのコピー、RAM上の重み参照。

12GBのVRAMに加えて数十GBのRAMが要る

12GBはVRAMの容量であり、PC全体の必要メモリではない。通常モードでは、VRAMにキャッシュした分も含め、全専門家の重みをRAMにも保持する。そのため、VRAMを増やすだけで同じ量のRAMが不要になるとは限らない。量子化は重みを少ないビットで表す方法で、容量を減らす代わりに数値の表現が変わる。

モデルと形式	RAMに置く専門家の重み	通常構成のRAM目安
Q2_0	約34GB	48GB以上
IQ2_XS	約35.5GB	48GB以上
IQ3_XXS	約43GB	64GB
IQ3_S	約50GB	64GBで他の使用量を抑える
Coder / IQ1_M	約23GB	32GB

表はv0.1.39の容量説明に基づく目安だ。「RAMに置く専門家の重み」列には、専門家以外の重み、OS、他のアプリ、文脈用の領域は含まない。文書は専門家の重みに加えて約10GBの余裕を見込む。長い文脈を選ぶ際のsetupの見積もりはさらに保守的で、64GB PCのIQ3_XXSとIQ3_Sには通常128Kまでを勧める。

RAMが少なくVRAMが大きいPCにはlow-RAMモードがある。モデルファイルをメモリマップし、VRAMに保持していない専門家の重みを主にRAMへ残す方式だ。32GB RAMと24GB GPUならQ2_0やIQ2_XSを扱う例が示される。ただしVRAMが小さいGPUではSSDから読む専門家の重みが増え、遅くなる。「RAMとVRAMの合計が表の数字を超えた」というだけでは動作条件を判断できない。

Coderは、通常版の各層512専門家から256専門家を残した派生版で、単に同じモデルを強く圧縮したものとは違う。コード以外や英語以外、特にCJKの文章では弱くなると文書にある。32GBに収まる利点と、日本語の作業に使う場合のモデル選択は分けて考えたい。

SSDの空き容量にも追加分がある。小さい3形式の本体は約66〜76GB、MTPの先読み用重みは約6GB、画像対応を付けるとさらに約1GB。Q2_0をAVX-512対応CPUで使う場合は、高速なCPU計算用に約40GBの追加パックも作る。READMEの「約80GB」を全構成の上限とは読めない。インストール時の容量条件。

より大きいUnsloth版では、UD-IQ4_XSが94GBのダウンロードと59.5GBの専門家の重み、実験的なUD-Q4_K_XLが111GBのダウンロードと約77GBの専門家の重みを持つ。RAM予算を超える部分は生成中もSSDから読む。後者の64GB RAM・12GB GPUでの開発側の報告は7〜8.5トークン毎秒だ。小さい形式の数十トークン毎秒という値を、この構成へ当てはめることはできない。大きい形式の条件。

新しい版の生成速度は旧版比で数％伸びた

StrataはMTPというモデル内の先読み部分で数トークンを予測し、本体でまとめて検証する。予測が当たれば、重い本体の処理1回で複数トークンを進められる。v0.1.39では検証処理のGPU起動回数やCPUとの往復を減らし、関連処理をまとめた。

形式と出力内容	v0.1.38	v0.1.39	公表した改善率
Q2_0 物語	68.4 tok/s	72.7 tok/s	+6%
Q2_0 コード	75.8 tok/s	80.0 tok/s	+6%
IQ3_XXS 物語	46.1 tok/s	48.8 tok/s	+6%
IQ3_XXS コード	50.7 tok/s	51.9 tok/s	+2.5%

出典はリリースノート。RTX 5070で旧版と新版を交互に10組ずつ測った中央値で、tok/sは1秒あたりに生成するトークン数だ。改善率は公表値の丸めを残した。4Kと32Kの入力後の生成では5〜7％向上したという。入力を読む時間や待ち行列を含む、作業全体の短縮率ではない。

同じリリースでも、最適化のすべてを12GB GPUで測れたわけではない。CPUからの通知をさらに省く検証グラフは、その層の全専門家の重みがVRAMにあるときだけ動く。開発者の12GBカードではその条件に届かず、大きなGPUでの追加効果は未測定とされる。

READMEに載るQ2_0の94トークン毎秒などは、今回の比較表とは別の測定だ。NVIDIA欄のQ2_0はエンジン0.1.36、ほかは主に0.1.26に基づき、v0.1.39ではREADMEの速度表を再測定していない。異なる入力と設定の94を、上表の80と直接比べて新版が遅くなったとは判断できない。

長い入力の高速化は空きVRAMと設定に左右される

長い入力では、GPUへ順に送る専門家の重みの一時領域と、VRAMに残すキャッシュの配分が問題になる。v0.1.39は量子化パックのバイト数に応じて転送用リングの大きさを決め、prefillの処理単位も調整する。リングは、送った重みを次々に入れ替えて使う一時領域だ。

リリースのRTX 5070・32K入力では、IQ3_XXSと1,500スロットの専門家キャッシュで入力処理が18.5％速くなった。一方、setupの既定構成では変わらなかった。Coderは文脈上限32Kで30Kの入力を読むと約8％遅く、文脈上限64Kでは約6％速かった。ここでのスロットは専門家の重みを置く場所であり、次節の会話用スロットとは異なる。

長い入力では、キャッシュ済みと転送中の専門家の重みを組み合わせる方法が変わるため、旧版と計算結果のビット列まで一致するとは限らない。リリースにはFP16の入力処理を参照した追加評価がある。IQ3_XXSの32K入力後、続く2,001トークンを正解文脈に沿って評価したtop-1一致率は95.3％で、旧版は95.0％だった。これは次トークンの最有力候補が参照と一致した割合で、質問への正答率ではない。

文書内の版表記にも注意が要る。同じタグのDETAILSには、このリング処理を「0.1.39b」とし、0.1.39を比較元とする説明が残る。一方、公開リリースはv0.1.39と0.1.38の比較として記す。この記事の旧新版比較はリリースノートに統一し、DETAILSの追加条件を同じ試験の結果として混ぜていない。

RAM使用量を予算で制限する構成には、不必要なSSD読み込みを防ぐ修正も入った。0.1.38はファイルの総量を基準に早すぎる段階で読み方を決めていた。96GB RAM、UD-Q4_K_XL、72GiB予算の報告では、その誤判定で入力が0.1.34より15〜40％遅かった。新版はRAMへ置いたコピーの外にある専門家の重みの量を数え、コピー作成後に判定し直す。出力トークンは読み方によらず同じとされる。

並列化は待ち時間と総処理量を分けて評価する

既定では1件ずつ処理するが、モデル設定の"parallel": 4などで複数の会話を同時に進められる。待っている短い入力を、長い入力の処理の区切りで先に通す仕組みもある。利用者が何人もいるとき、前の回答が最後まで終わるのを待たずに済む。

4件を同時に送った場合	1件ずつ処理	4スロット
最後の要求の最初のトークン	11.2 s	1.8 s
全体の処理速度	70.7 tok/s	63.1 tok/s
各要求の生成速度	79.6 tok/s	16.9 tok/s

測定はBATCHINGの表に基づく。RTX 5070 12GB、Ryzen 5 7600、64GB DDR5、Q2_0、32K文脈で、800語のエッセーを求める異なる要求をHTTP経由で同時送信した。各回答は256トークン、greedy、thinking無効、3ラウンドの中央値である。全体の処理速度と各要求の生成速度は測り方が違うため、各要求の数値を単純に4倍して比較しない。

最後の要求が始まるまでの時間は大きく減ったが、全体の処理速度は約11％下がった。会話ごとの状態がVRAMを使い、専門家キャッシュを減らすためだ。32K文脈・8ビットKVでは1スロットが0.56GiBを使う。GiBは2の30乗バイトの単位で、容量表のGB表記と同じ数字として足し算しない。

スロットを確保したまま1件だけ処理しても影響は残る。リリースノートでは2スロットで単独生成が11％、4スロットで22％低下したと報告する。BATCHINGの表では、全体の処理速度の低下率が9％と22％、各要求の生成速度から計算すると約11％と24％になる。本文の説明にも差があるため、指標と出典を分けて読む必要がある。

並列の検証窓では、各会話から1トークンずつをまとめ、MTPの先読みを使わない。共有する重みをまとめて読める利点はあるが、会話ごとに違う専門家を選ぶとCPUの仕事は増える。1件だけになったら通常の先読み経路へ戻るものの、予約した状態領域の分だけキャッシュは小さくなる。12GB GPUの既定が1件ずつなのは、このためだ。

大きい構成では結果が変わる。貢献者による4台の16GB GPU、PCIe Gen3、IQ3_S、8スロットと4パイプライングループの測定では、合計速度が1要求の120から8要求の360トークン毎秒へ増えた。回答は各400トークン、temperatureは0.7。VRAMに専門家の重みを多く置き、層を分けて別の会話を並行処理する構成であり、12GBの単一GPUへは一般化できない。

出力の一致も条件付きだ。厳密比較ではSTRATA_IQ_MT_MIN=1、--pcie-frac 0、固定に近い専門家配置などを指定する。既定設定のQ2_0・4会話では、単独と一致したのは1会話で、ほかは最初または途中のトークンから異なった。並列経路では反復・頻度・存在ペナルティも適用しない。「常に単独と同じ文章」と受け取らず、必要な生成条件を確認したい。

Codex CLIがローカルモデルとツールの往復を担う

Codex CLIは、モデルとの会話を進めながらファイル操作やコマンド実行などを呼ぶクライアントである。StrataのResponses API対応により、その推論先を手元のQwen系モデルへ向けられる。モデルがツール呼び出しを返し、CLI側が設定された権限の範囲で実行し、結果をモデルへ送り返す。この往復が、単発のコード生成と作業を続けるエージェントの違いになる。

モデルの判断とツールの実行を往復する

Codex CLI

指示と履歴とツール定義を送る

→

Strataとローカルモデル

文章またはツール呼び出しを返す

↓ ツール呼び出しをCLIへ返す

CLIがツールを実行し結果を次のinputへ入れる

履歴も再送し一致する部分の計算はStrataが再利用する

Strataの文書が示す接続設定の中心は次のとおりだ。ユーザー側の~/.codex/config.tomlでプロバイダーを指定し、文脈上限をStrataのsetupで選んだ値に合わせる。32,768は文書の例で、全PCの推奨値ではない。Strataの設定例とOpenAIの設定リファレンスを参照した。

model = "strata"
model_provider = "strata"
model_context_window = 32768
show_raw_agent_reasoning = true

[model_providers.strata]
name = "Strata (local)"
base_url = "http://127.0.0.1:8080/v1"
wire_api = "responses"
stream_idle_timeout_ms = 600000

モデル名のstrataは接続用の名前で、OpenAIのモデルを取得する指定ではない。Strataが現在読み込んでいるモデルが応答する。サーバーにAPIキーを設定した場合は、文書にあるenv_key = "STRATA_API_KEY"も設定する。

開発者はCodex CLI 0.160.0、Q2_0、RTX 5070でツール実行を含む往復を確認した。最初の指示とツール説明は9,443トークンで、読み込みは10秒。後続ターンは入力の約96％をキャッシュから再利用し、新しい部分の読み込みは1〜2秒だった。回答全体が1〜2秒で終わる意味でも、あらゆる作業で96％再利用できる保証でもない。

Responses APIはstatelessとして動く。クライアントは毎回、会話全体をinputで送り、Strataは保存済み応答IDで会話を引き継がない。一方、計算済みの入力キャッシュは再利用する。「APIに応答を保存しない」と「毎回すべて再計算する」は別の話だ。

機能	v0.1.39の対応
関数とツール結果	functionとcustomの呼び出しと結果を扱う
思考の強さとストリーミング	effortを変換しResponses形式のイベントを返す
JSON形式	json_schemaとjson_objectは生成後に検査する
previous_response_id	非対応でエラーになる
ホスト型ツール	web_searchやfile_searchなどを除外する
思考の要約	要約は生成せずsummaryは空

JSON検査は、生成中に文法を強制する仕組みとは違う。tool_choiceもnone以外ではモデルの選択に任せ、特定ツールの実行を強制しない。conversation、バックグラウンド実行、保存した応答の取得・削除・キャンセルも対象外だ。対応する入出力と拒否条件は変換コードで確認できる。

思考を次のターンに返す際には、Strata固有のencrypted_contentにも注意したい。名前にencryptedと付くが、実装はBase64で包んだ再送用の文字列であり、暗号化ではない。推論先がローカルでも、CLIが使うWebやMCPなどの外部ツールまで自動的にオフラインになるわけではない。

通常の対応環境と実験的な対応を区別する

通常の導入対象はWindows 10/11またはLinuxと、12GB以上の対応NVIDIA・AMD GPUだ。NVIDIAの通常配布エンジンはCUDA 13で、ドライバー580以降を要求する。CPUはx86-64のAVX2対応が基本となる。AMDは対応GPUを選ぶ必要があり、画像入力はWindows版では未対応、LinuxではCPU経由とされる。

v0.1.39はPascalやVolta向けのCUDA 12.9エンジンも用意したが、実験的な選択肢だ。Windowsはドライバー528以降、Linuxは525以降が条件となる。開発者自身は対象の古いGPUを持たず、ビルドや別GPUでの出力確認と、貢献者の実機報告を区別している。

Intel ArcのSYCL版はLinuxでソースからビルドする実験的な経路で、配布済みエンジンはない。このリリース時点のArc実機、Windows、WSL2、Aシリーズや内蔵Arc、画像入力は開発者未検証と明記される。AVX2のない古いCPUにも経路を広げたが、対応形式はi-quantに限られ、CPU側の計算は遅い。対応表に名前があることと、手元の構成で検証済みであることは分けたい。

導入時はINSTALLでGPU、RAM、空きディスクとドライバーを照合し、WindowsではSTART-HERE.bat、Linuxでは./setup.shを使う。初回はモデルや依存ソフトを取得し、RAMへ数十GBを読み込む。起動後は短い入力1件から確認し、次に実際の文脈長や同時要求へ広げると、容量不足と処理方式の違いを切り分けやすい。

サーバーの既定の待受先は127.0.0.1である。別の端末へ開く設定ではAPIキーなどの条件も変わる。公開する機能の説明を確認する必要がある。本体はMITライセンスだが、モデルと一部の同梱物にはそれぞれの条件がある。ローカルで動くことだけで、すべて同じ利用条件になるわけではない。

TensorFoldとの違いは対象モデルとメモリの使い方にある

先に紹介したTensorFold v0.6.1も、先読みを検証してローカル生成を速める。ただし、読者が選ぶ際の着眼点は違う。TensorFoldは複数の対応モデルをMacのMLXや対応NVIDIA GPUのCUDAで動かす。StrataはQwen3.8-Flash-Next系に絞り、VRAMに収まりきらない専門家の重みを主にRAMへ置いて、CPUでも専門家の計算を行う。

比較する点	Strata v0.1.39	TensorFold v0.6.1
モデルの範囲	Qwen3.8-Flash-Nextと対応派生版	複数の対応モデル系列
主な実行基盤	NVIDIA CUDAとAMD HIP	Apple MLXとNVIDIA CUDA
この記事で見る工夫	VRAMへの重みのキャッシュとCPU計算	先読みと検証を含むモデル別の実行最適化
比較できないこと	同条件の速度優劣は未検証	同条件の速度優劣は未検証

これはStrataの対応範囲とTensorFoldのREADMEに基づく設計上の比較だ。別モデル、別GPU、別の量子化による速度値を並べて勝敗は付けられない。どちらも、先読みの一致が量子化前のモデルや他のランタイムとの一致まで保証するわけではない。

Strataを検討するなら、まず使いたい派生版と量子化を決め、その専門家の重みをRAMへ置けるかを確認する。次に文脈長で変わるキャッシュ容量を見て、1人の応答速度を重視するのか、複数人の待ち時間を減らしたいのかを選ぶ。Codex CLI接続はその先の使い方であり、モデルの日本語能力、コードの正しさ、ツール選択の確かさは別途確かめる必要がある。

出典と確認範囲

GitHub APIで確認したv0.1.39の公開日時は2026年10月4日12:32:47 UTC、日本時間では同日21:32:47。コードと文書はコミット6f32ec070f23ced9f50e704d854d775da52591abに固定した。2026年10月5日に確認した内容であり、Strataというプロジェクト自体が10月4日に初公開されたという意味ではない。

1. v0.1.39リリースとGitHub API。公開日時、旧版比較、開発者自身の検証範囲。
2. README、MODELS、INSTALL。対象モデル、メモリとディスクの目安、通常と実験的な環境。
3. DETAILSとBATCHING。メモリ階層、Codex検証、並列処理の測定条件と制限。
4. Responses変換コード、APIテストコード、専門家の読み込み、専門家キャッシュ、prefill実装。コードは読んで照合し、Strataのテストや推論自体は実行していない。
5. LICENSEとモデルと同梱物の告知。本体とモデルの利用条件を区別した。

残る未確認点は、読者のPCでの速度と安定性、日本語や実作業での品質、未検証ハードウェアでの動作である。資料内で異なる版名や指標を確認できた箇所は本文で区別した。掲載した数値を、すべての環境で再現する保証としては扱っていない。