ニュース

持続負荷下のRTX 3060 12 GB：最後のトークンまで60–68トークン/秒

平均値ではなく、長い回答のすべてをトークン単位で速度測定しました：16Kコンテキストで8192トークンの回答を推論ありで60–68トークン/秒、推論なしで79–96トークン/秒、プロンプトを1Kから30Kにしても低下は約8%だけです。145個の生ファイルはすべてダウンロードできます。

30.10.2026

2026年10月30日、RTX 3060 12 GBを搭載した実験用コンピューターB2003で長い一連の測定を行いました。結果：推論オン（デフォルト）で、Strata上のQwen3.8-Flash-Next IQ3_Sは16Kプロンプトにおいて最初のトークンから8192番目まで60–68トークン/秒を落ち込みなく維持します。推論オフでは79–96トークン/秒で動作します。コンテキストをほぼ満杯にしてもコストは約8%だけです：プロンプトを1Kから30Kにすると中央値は88から84トークン/秒になります。

以前の記事では、このカードで最大68トークン/秒のデコードを報告しました。Xで最もよく聞かれる質問は2つです：その速度は長い回答の最後まで続くのか、それともウォームアップ時のピークにすぎないのか。そして長いコンテキストの後半でも性能は保たれるのか。これに答えるため、回答全体の平均ではなく、ストリーミングされたすべてのトークンの時刻を計測しました。

同じ回答内の区間ごとの速度、1Kから30Kトークンのコンテキスト、コールドとウォームのプロンプトキャッシュ、高速と精密のエキスパートルーティング、3種類のコンテンツ（JSON、Cコード、ロシア語の技術文書）、GPUの電力・クロック・温度、そして出力自体が正しいままかどうかを確認しました。

構成

マシンB2003：ASUS Pro Q870I-C、Intel Core Ultra 7 265、2×24 GiB DDR5-5600。
GPU：RTX 3060 12 GB（GA106）、ドライバー615.71.10、GPUアンロック有効、電力制限170 W。
ストレージ：Lexar NM1090 PRO 2 TB NVMe（PCIe 5.0 × 4）。
システム：Ubuntu 24.04.5、カーネル7.0.0-38。
エンジン：Strata 0.1.52（build f-027-rel）。
モデル：Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S（78 GiB、2シャード）。

--max-context 32768 --prefill 4096 --pool-workers 12 --spec 4 --spec-min-p 0.5
--kv int8 --kv-resident 32768 --conversation-cache-mib 1536
--resident-experts --resident-budget-gib 24
STRATA_UNBUFFERED_LOAD=1  STRATA_RESIDENT_HEADROOM_GIB=10

方法論

サーバーは/tokenizeを公開していないため、トークンはストリーミングされたSSEチャンクのタイムスタンプから数え（1チャンク≈1トークン。検証：usage.completion_tokensの5479トークンに対して5478チャンク）、正確な最終トークン数に合わせました。単語数や行数は使っていません。
プロンプトはmax_tokens: 1のプローブで較正し（フィラー文1つあたり20.2トークン、固定オーバーヘッド145トークン）、実際のサイズはusage.prompt_tokensで確認しました。
回答の長さは32768からプロンプトとマージンを引いた値で、最大8192トークンです。30Kでは2048トークンになります。
主要なシナリオはそれぞれ少なくとも3回繰り返し、中央値・最小値・最大値を示します。デコードのノイズは±20%、プリフィルのノイズは±5%で、それより小さな差は結果として扱っていません。
ハードウェアテレメトリは3秒ごとに記録されました（クロック、電力、温度、使用率、VRAM、空きRAM、スワップ、NVMe読み取りカウンタ）。プリフィル、MTPドラフト承認、エキスパートキャッシュヒット、およびファイル階層の読み取りは、エンジンログから取得されました。
エキスパートルーティングは2モード：高速（デフォルトのルーティング、prior 1.5）と精密（STRATA_ROUTE_PRIOR=0）。モードはエンジンを再起動して切り替えました。
精密モードのファイルのうち4行は、実行中にブロックスクリプトが書き換えられたため高速エンジンで生成されました。これらは表から除外し、アーカイブにはそのまま残しています。
合計：13個のJSONLファイルで52回の測定実行（高速モード14回、精密モード13回、バリアント25回：推論、ウォームキャッシュ、コード、文章、コンテキスト上限、較正）、さらに除外した4行。

結果：回答内の速度

値の単位はトークン/秒、中央値（最小–最大）。コンテキストはプロンプトのトークン数、回答は最大8192トークン（30Kでは2048）。

高速モード、推論オフ

コンテキスト	実行回数	0–0.5K	0.5K–1K	1K–2K	2K–4K	4K–6K	6K–8K	末尾	回答全体
983–1516	3	86 (56–86)	87 (87–88)	86 (85–88)	88 (88–90)	—	—	92	88 (55–89)
7865	2	84 (81–87)	96 (93–99)	94	95 (94–96)	—	—	94	93 (93–94)
15816	3	79 (77–88)	86 (86–96)	90 (90–96)	92 (90–98)	93 (93–96)	93 (92–96)	95	91 (90–96)
23917	3	81 (77–85)	86 (83–91)	83 (81–92)	90 (80–90)	96	—	83	86 (80–92)
30153	3	78 (77–78)	86 (86–87)	86 (85–88)	—	—	—	86	84 (84–85)

高速モード、推論オン（デフォルト動作）

コンテキスト	実行回数	0–0.5K	0.5K–1K	1K–2K	2K–4K	4K–6K	6K–8K	末尾	回答全体
15854	1	61	68	61	59	58	60	85	60
30191	1	66	56	65	—	—	—	96	63

精密モード、推論オフ

コンテキスト	実行回数	0–0.5K	0.5K–1K	1K–2K	2K–4K	4K–6K	6K–8K	末尾	回答全体
1011	2	27 (26–29)	28 (26–29)	27 (26–28)	25 (24–26)	25 (24–25)	23	26	25 (25–26)
7893	2	29 (29–30)	30 (29–31)	28 (24–31)	27 (22–31)	26 (21–31)	27	24	26 (23–30)
15814	3	29 (26–32)	27 (25–32)	26 (22–28)	23 (20–24)	23 (20–23)	22	21	24 (21–24)
23915	3	31 (30–32)	32 (31–34)	29 (26–31)	25 (25–28)	24	—	24	26 (26–29)
30151	3	32 (28–32)	32 (30–33)	29 (29–30)	—	—	—	29	30

高速モードでは速度は一定か、回答の終わりに向けてむしろ上がります（16K：79 → 93、末尾95）。終盤での減速は精密モードでのみ見られます：8000トークンで29 → 22（−24%）。16Kで推論オンの精密モードは回答全体で25トークン/秒です。高速ルーティングは精密ルーティングより3.8倍速くなります。

コンテンツタイプ（高速モード、16Kコンテキスト）

タスク	回答、トークン	回答全体、トークン/秒	MTPドラフト受理率
レコードのJSON配列	8192	91 (90–96)	92% (90–98%)
Cコード	7332	59	74%
ロシア語の技術文書	4730	40 (40–43)	38% (1327/3485)

差はデコードのノイズより数倍大きく、予測しやすい構造は生成を2–2.3倍速くし、自由な文章は遅くします。これはコンテンツの性質によるもので、時間経過による減速ではありません。

プリフィル、最初のトークンまでの時間、プロンプトキャッシュ

ケース	プロンプト、トークン	コールドプリフィル、トークン/秒	コールドTTFT	ウォームTTFT	再利用トークン
1K	983–1516	293	3.4–3.8 s	—	0
8K	7865	865	9.1–9.2 s	—	0
16K	15816	908	17.3–17.6 s	0.2 s	15 803
24K	23917	914	25.4–26.3 s	—	0
30K	30153	892	33.6–34.5 s	0.4 s	30 141

ウォームなプロンプトキャッシュはプリフィルをほぼすべて省き（16Kで17.4秒→0.2秒、30Kで33.6秒→0.4秒）、デコード速度は変わりません。高速モードのエキスパートキャッシュのヒット率は98.7–98.8%、NVMeの読み取りはエキスパート読み込み中に1.1–3.3 GB/秒、安定したJSONデコード中はほぼゼロでした。

上限32,768で30,151トークンのプロンプトの場合、エンジンは回答の予算を自ら削り、エラーなしでstopまたはlengthで終了します。エラー400を返すのは、プロンプト単体で収まらない場合だけです。

実行中のハードウェア

ブロック	電力	温度	SMクロック	VRAM	スワップ	NVMe読み取り
高速モード	162–169 W (max 170.2)	74–76 °C	1815–1875 MHz	11 409–11 423 MiB	0	0.2–4.7 GB/s (6.6)
精密モード	88–105 W (max 167)	62–71 °C	1965–1972 MHz	11 425 MiB	0	1.6–2.3 GB/s (6.1)

測定したブロック全体での範囲、括弧内はピーク値。高速モードはGPUの電力で頭打ちになります：170 Wの上限でクロックは2160 MHzから1815–1875 MHzに下がり、温度は75 °C、サーマルスロットリングはなく、VRAMは12.3 GiB中11.4 GiB使用、スワップなし。精密モードでは、GPUは最大クロックのまま電力を約半分しか使いません：計算ではなくエキスパートを待っているためで、これが速度低下の理由です。

出力品質

JSON形式は崩れません：上限で打ち切られた12回の実行すべてで各レコードは有効なままで、閉じられなかったのは配列自体だけでした。
プロンプトの冒頭にある指示は30Kでも守られます（末尾でのタグのルールは50/50と22/22で維持）。
文書の中ほどにあるマーカーは16Kと24Kでは思い出せますが、30Kでは両モードとも失われます。
高速モードの主な弱点は、長いリストでの項目の繰り返し（約190個中ユニークなコードは26–28個）と、30Kでの122行の重複ループ1回です。16Kの精密モードは168/168と193/193をユニークに保ちましたが、24Kと30Kでは1回の実行で26–33個のユニークなコードまで崩れることもあります。
高速モードのCコードは、681行のうち255行を繰り返し生成したため、高速モードのコードタスクは信頼できません。

この実験の限界

マシン1台、ビルド1つ：GPUの電力制限とエキスパート供給に関する結論は、170 W制限・VRAM 12 GiBのこのカードに当てはまります。モードはエンジン再起動で切り替えたため、1つのモード内の実行は連続しており、順序は完全にはランダム化されていません。ウォームキャッシュでの精密モードは1回、1Kと8Kの精密モードは3回ではなく2回の実行です。

Boxのお客様にとっての意味

手頃な価格の12 GBカードは、最初だけでなく、長い回答を通して60〜68トークン/秒を維持します。
コンテキスト内の長い文書による速度低下はわずかで、同じコンテキストの繰り返しにはプロンプトキャッシュのおかげでほぼ即座に回答します。
モードはタスクごとに選びます：構造化データには高速、長いリストをユニークに保つ必要があるときは精密。生成されたコードはレビューが必要です。

生データ

この実験の全145ファイルをダウンロードできます：13のJSONL結果ファイル、102の回答と推論テキスト、ハードウェアテレメトリ、エンジンログ、スクリプト、システム状態、ロシア語の元のレポート、英語のポストドラフト。アクセスキー、内部アドレス、ユーザー名、内部パスは、公開前に削除されました。

tar.gzをダウンロード（264 KB） · zipをダウンロード（298 KB）

RTX 3060の記事 · すべてのニュース