ローカル言語モデル実行ツールのStrataが、対応モデルに画像入力と最大8件のリクエストの同時処理を追加した。複数のユーザーやエージェントを接続する開発者の選択肢が増え、回答生成も高速化したが、効果はグラフィックスメモリの余裕によって異なる。
1. 画像入力を選ぶインストール手順
2026年10月17日に公開された今回のバージョンは、Qwen3.6-35B-A3Bに画像入力を追加した。インストール時に画像の使用を選ぶと、画像をモデルに接続する0.9 GBのファイルをダウンロードし、設定に反映する。
開発チームは同じ画像と入力トークンを使ってllama.cppと比較した。比較対象の回答を固定して次のトークンを検査したところ、最初のトークンは6件中5件が一致した。画像2枚を入力した残りの1件は候補のスコアがほぼ同じ箇所で分かれたが、テスト画像への回答文は同じだったという。
24 GB未満のNVIDIAカードで画像を有効にすると、CPUエンコーダーが選ばれるようになった。画像をモデル入力に変換するのに1枚当たり4～6秒かかり、最大300トークンとして読み込むが、この処理はグラフィックスメモリを占有しない。既存の設定は変わらない。
2. 最大8件の会話をまとめて処理
インストール時に--parallel Nで同時リクエスト数を指定し、設定ファイルでは"parallel": Nに対応する。スロットは同時に進める会話の枠と考えればよい。インストーラーはメモリと選択したコンテキスト長に合う数を案内し、Enterを押すと1件ずつ処理する状態を維持する。
各会話のトークンを1つずつまとめて処理するため、共通のモデル重みと会話間で共有するエキスパートの重みを1回だけ読み込む。ここでエキスパートとは、モデル内で選択的に使われる計算部分だ。開発チームは2・4・8スロット、スロットの再利用、長い入力の並行処理をテストし、各会話が単独実行時と同じトークンを生成したと報告した。
開発チームの測定値だ。R9700 32 GB にすべてのエキスパートの重みを載せ、リクエストごとに新しいトークンを 128 個生成し、llama.cpp の llama-server -np N -fa on と交互に 5 組ずつ比較した。速度比は 1.14～1.61 倍で、どのリクエスト数でも 5 組すべてで Strata が速かった。
| 同時リクエスト数 | Strata | llama.cpp（llama-server） |
|---|---|---|
| 1 | 83.9 | 73.8 |
| 2 | 173.5 | 107 |
| 4 | 252 | 165 |
| 8 | 325 | 208 |
3. 同時処理の代償はメモリにある
エキスパートの重みがすべてグラフィックスメモリに収まる場合、インストーラーは最大3～4スロットを提案する。そうでなければ、会話用の領域がエキスパートキャッシュ、つまり重みを近くに保持する領域を減らす。複数リクエストを同時に進める利点と、1件のリクエストの速度低下を併せて検討する必要がある。
RTX 3060 12 GBでコンテキスト8K、リクエスト4件でテストした同時処理性能は、ドラフト層でトークンを先に予測しながらリクエストを1件ずつ処理する方式の1.15倍だった。同じスロット設定でリクエストを1件だけ実行すると、速度は4%低下した。したがって、同時リクエスト数を増やすことは、単一の会話を速くする設定とは異なる。
4. 回答生成と入力読み込みの高速化
デコードは回答トークンを順番に生成する処理だ。新しい計算カーネルは、実際の内部値で比較した18,360件で従来のカーネルとのビット単位の不一致がなかった。入力を一度に読み込むバッチも、メモリに合わせてデフォルトで4096・2048・1024トークンに拡大した。
R9700 32 GBとUD-Q4_K_XLモデル形式では、回答生成が毎秒83.2トークンから117.8トークンへと1.42倍になり、交互に測定した5組すべてで改善した。同じ条件での4K入力の読み込みは、毎秒3,453トークンから6,220トークンへと1.80倍になった。
一方、CPUがボトルネックとなるハイブリッド実行モードのRTX 3060 12 GBでは、回答生成は2%、入力読み込みは3%の改善にとどまった。先のカードでの倍率を、ほかの機器での期待値とするのは難しい。
入力バッチより短いプロンプトは変わらないが、長いプロンプトはバッチサイズの変更で出力が少し変わる可能性がある。以下は原文で示された、従来の512トークンのサイズに戻すオプションだ。
--prefill 5125. 適用前に区別すべき範囲
複数のGPUを使うサーバー向けには、8を超えるスロットと、コピー・中間状態の保存の最適化も用意された。これらのサーバー向け機能は明示的に有効にする必要があり、デフォルトは変わらない。通常の最大8件の同時リクエスト対応とは別の選択肢だ。
このモデルの検証は、Windows実機、Intel Arc、RTX 5070では行われていない。Windows AMDでのモデル認識の問題は修正されたが、その環境での検証まで完了したという意味ではない。
更新はWindowsではUPDATE.bat、Linuxでは./update.shで実行し、インストール処理がエンジンを置き換える。
今回のリリースの価値は、最大同時リクエスト数そのものより、機器のメモリと実際の会話数に合わせて画像入力と処理能力の改善を選べる点にある。