DDR3搭載のワークステーションで、RTX 3050 8GBによる256Kコンテキスト
中古のXeonワークステーション（ECC DDR3メモリ64GB搭載（システムには約62GBと見える）とRTX 3050 8GB）を、256Kトークンのコンテキスト窓に設定した。詳細な測定は160Kトークンまでであり、256K全体には達していない。以前の16K構成では、実テキストで59 tok/sが示されていた。
2026年11月11日、ワークステーションP3001からの結果が公開された。構成はIntel Xeon E5-2697 v2（12コア / 24スレッド、AVX1のみ）、1333 MT/sのECC DDR3 RAM 64GB搭載（システムには約62GBと見える）、NVIDIA RTX 3050 8GB、NVMe SSD、Ubuntu 24.04。ソフトウェアはStrata 0.1.55（AVX互換ビルド）と、圧縮モデルQwen3.8-Flash-Next IQ3_S。
以前の16K構成：実テキストで59 tok/s
同日のより早い段階で、同じマシンについて、8ビットKVキャッシュを用いた16Kコンテキスト構成が報告された。KVキャッシュは、すでに処理したトークンのためのモデルの作業メモリである。その投稿で公開された数値：
| コンテキスト | Prefill | Decode | TTFT |
|---|---|---|---|
| 2K | 132 tok/s | 24.3 tok/s | 11.9s |
| 8K | 121 tok/s | 28.0 tok/s | 42.6s |
| 16K | 128.5 tok/s | 30.7 tok/s | 87.5s |
| ウォームな8K（キャッシュから） | キャッシュから | 28.7 tok/s | 0.2–0.33s |
同じ投稿では、実テキストのデコードで59 tok/s、プリフィルで120〜132 tok/sと示されている。後続のスレッドでは、この59 tok/sは投機的デコードによるものと説明されている。Strataは先の複数トークンを予測し、まとめて検証する。実テキストでは予測の採択率が高かったが、人工的なベンチマーク埋め込みではそうではなかった（16Kの投稿によれば、合成埋め込みでの採択率は約70%）。プリフィルはDDR3-1333とAVX1に制約され、その16K構成では8GBのVRAMがコンテキストを16Kに制限していた。
256K構成
掲げられた目標は、256Kトークンのコンテキスト窓、つまり1回の要求でおよそ262,144トークンを扱える容量である。最初の試みは、8ビットKVキャッシュのまま上限を256Kに上げただけだった。投稿によれば、そのときStrataはこの作業メモリの多くをGPUの8GB VRAMに置こうとし、GPU上のエキスパートキャッシュはゼロスロットになり、その後cuBLASエラーが発生した。サーバーは応答していたが、GPU加速は正しく動作していなかった。
公開された解決策は次の通り。KVキャッシュをint8からq4_0（4ビット圧縮）へ切り替え、トークンあたりのメモリを約71KBから29.5KBへ減らす。–kv-resident 20480を設定し、GPUメモリに常駐するのは20,480個のKV位置だけとし、追加のKVデータはシステムRAMから取り出す。46.47GBのモデルエキスパートをページロックしたDDR3 RAMに置く。GPUメモリに498個のエキスパートキャッシュスロットを残す。プロンプトキャッシュを1つの有効なチェックポイントに制限する。示された最終設定は –max-context 262144、–kv q4_0、–kv-resident 20480、–prompt-cache 1、–prompt-cache-every 0。投稿によれば、その後Strataは正しく起動し、max_context: 262144、loaded: true を報告した。
測定された速度
以下の数値は推論エンジン自体の測定で、1行あたり1回の実行である。繰り返しベンチマークの平均ではなく、暫定データである。プリフィルは応答前の入力処理、デコードはトークンごとの生成、TTFTは最初の応答トークンまでの待ち時間である。
| 入力トークン | Prefill | TTFT | Decode |
|---|---|---|---|
| 77 | 35.9 tok/s | 3.7s | 20.1 tok/s |
| 1,561 | 163.5 tok/s | 9.5s | 23.1 tok/s |
| 6,161 | 187.6 tok/s | 32.7s | 24.6 tok/s |
| 24,061 | 187.6 tok/s | 128.3s | 25.7 tok/s |
| 50,061 | 183.4 tok/s | 273s | 23.5 tok/s |
| 100,061 | 177.5 tok/s | 564s | 23.8 tok/s |
| 160,061 | 172.5 tok/s | 928s | 23.8 tok/s |
投稿では、入力を約6Kから160Kトークンへ増やしても、プリフィルは188から173 tok/sへ下がっただけであり、デコードはおよそ23〜26 tok/sのままだったと記されている。キャッシュ済みコンテキストでの24Kトークンの再実行では、TTFTが128.3秒から0.49秒へ下がった。160Kトークンのコールド入力は、最初の応答トークンまで約15.5分かかった。これは古いXeonとDDR3メモリのボトルネックによるものとされている。200Kトークン実行に関するエージェント報告は触れられているが、その実行の完全な数値行は表にない。
スレッドにおける重要な区別：256Kは設定され、宣言されたコンテキスト上限である。詳細な測定は160Kまでであり、256K全体ではない。投稿時点では、262Kの窓全体はまだ測定されていなかった。ある返信では、262K全体のコールドプリフィルを約26分と見積もり、まだ測定が必要だと述べている。59 tok/sは、256Kコンテキスト負荷では確立されていない。新しい構成のプリフィルは以前の16K構成より高かった。スレッドではこれを単一の原因の証拠ではなく、構成間で観察された差として扱っている。KV形式とメモリ配置も変わっているためである。
制約とエネルギー見積もり
スレッドで挙げられた制約：GPUメモリはほぼ満杯で、8GBのうち約7.5〜7.7GBを使用し、一部の実行では空きが193〜331MBしかないと警告された。システムRAMは62GBのうち約53GBで、うち約46.5GBはメモリに固定されたモデルエキスパートが占める。プロンプトキャッシュのウォームなチェックポイントは1つだけなので、非常に大きな会話を切り替えると入力の再処理が必要になる場合がある（200Kトークンのチェックポイントだけでも約4.7GBを占める可能性がある）。また、長いコールドプロンプトは遅い。
160Kプリフィルの粗いエネルギー見積もりは、300W × 15.5分 ≈ 0.078 kWhと示されている。0.25 €/kWhでは、電気代はおよそ0.02 €になる。投稿ではこれを測定ではなく見積もりとしている。
スレッドの実務的な結論は、安価なローカルAIは、長く負荷の高いセッションでクラウドモデルと競うためのものではない、ということである。そうした場面では、クラウドサービスがしばしばより速く、より経済的である。こうした古い安価なコンピュータの主な利点はプライバシーであり、機微な文書をローカルで処理できる点にある。そうした作業の多くでは、小さなコンテキスト窓で十分である。公開された結果は、RTX 3050 8GBが、作業メモリのすべてをVRAMへ移さずに、256Kに設定したローカルモデルを実行できるというものである。コンテキスト範囲全体、再現性、作業上の品質を含む、さらなる測定がなお必要である。
測定結果とログは公開リポジトリに掲載されている。