新闻
腾讯通3060 12 GB持续负载： 60–68 tok/s到最后一个令牌
我们通过令牌测量每个长答案的速度，而不是平均值： 60–68令牌/秒，在16K上下文中对8192令牌答案进行推理， 79–96令牌/秒，没有推理，从1K到30K的提示仅损失了约8 ％。 所有145个RAW文件均可供下载。
2026年10月30日，我们在B2003上进行了一系列长时间的测量，我们的实验计算机配备了腾讯通3060 12 GB。 结果：在推理开启（默认）的情况下， Strata上的Qwen3.8-Flash-Next IQ3_S在16K提示下从第一个令牌到第8192个令牌保持60–68令牌/秒，没有掉落。 推理结束后，它的运行速度为79–96 tok/s。 几乎完整的上下文成本仅为8%左右：从1K到30K提示，中位数从88 tok/s到84 tok/s。
我们之前的文章报告了此卡上高达68令牌/秒的解码。 我们在X上被问得最多的两个问题是，这种速度是通过长时间的回答还是仅仅是一个热身高峰，以及性能是否在长时间的后半段保持不变。 为了回答这些问题，我们对每个流式令牌进行了计时，而不是对整个答案进行平均。
我们检查了相同答案的间隔速度、从1K到30K令牌的上下文、冷暖提示缓存、快速精确的专家路由、三种内容类型（ JSON、C代码、俄罗斯技术散文）、GPU功率、时钟和温度，以及输出本身是否保持正确。
设置
- 机器B2003 ：华硕Pro Q870I-C ，英特尔酷睿Ultra 7 265 ， 2 × 24 GiB DDR5-5600。
- GPU ：腾讯通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。
- 发动机：地层0.1.52 （制造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方法
- 服务器不公开/令牌化，因此令牌从流式SSE块的时间戳中计算（ 1个块≈ 1个令牌；检查： 5478个块与usage.completion_tokens中的5479个令牌）并锚定到确切的最终令牌计数。 未使用单词和线条。
- 使用max_tokens ： 1 （每个填充句20.2个令牌， 145个固定开销令牌）使用探针校准提示；对照usage.prompt_tokens检查实际大小。
- 答案长度为32768减去提示减去保证金，最多8192个代币；在30K时，这是2048个代币。
- 每个关键场景至少重复3次；我们报告了中位数、最小值和最大值。 解码噪声为± 20% ，预填充噪声为± 5% ；较小的差异不计入结果。
- 硬件遥测每3秒记录一次（时钟、功率、温度、利用率、VRAM、空闲RAM、交换、NVMe读取计数器）。 预填充、MTP草稿验收、专家缓存命中和文件层读取来自引擎日志。
- 两种专家路由模式：快速（默认路由， 1.5之前）和精确（ STRATA_ROUTE_PRIOR = 0 ）。 通过重新启动发动机来切换模式。
- 精确模式文件中的4行是由FAST引擎生成的，因为在运行过程中重写了块脚本。 它们被排除在表格之外，并按原样保存在存档中。
- 总共：在13个JSONL文件（ 14个快速模式， 13个精确模式和25个变体：推理，预热缓存，代码，散文，上下文限制，校准）中进行了52次测量，加上4个排除的行。
结果：答案内的速度
以tok/s为单位的值，中位数（最小值-最大值）。 上下文是令牌的提示大小；答案是最多8192个令牌（ 2048个， 30K ）。
快速模式，推理关闭
| 背景 | 运行 | 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 ）。 接近尾声的减速仅在精确模式下出现： 29 → 22超过8000个代币（ -24 ％ ）。 以16K开启推理的精确模式为整个答案提供25 tok/s。 快速路由比精确路由快3.8倍。
内容类型（快速模式， 16K上下文）
| 任务 | 答案，令牌 | 整个答案， tok/s | 接受中期计划草案 |
|---|---|---|---|
| JSON记录数组 | 8192 | 91 (90–96) | 92% (90–98%) |
| C代码 | 7332 | 59 | 74% |
| 俄罗斯技术散文 | 4730 | 40 (40–43) | 38% (1327/3485) |
差异比解码噪声大几倍：可预测的结构加速生成2–2.3×，自由散文减慢生成速度。 这是内容的属性，而不是随着时间的推移而放缓。
预填充、第一个令牌的时间和提示缓存
| 案例 | 提示，令牌 | 冷预充， tok/s | 冷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/s ，在稳定的JSON解码过程中几乎为零。
在具有32,768个限制的30,151个令牌提示下，发动机会自行调整答案预算，并以停止或长度结束，没有错误。 只有不适合自己的提示才会返回错误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上限时，时钟在75°C时从2160 MHz降至1815-1875 MHz ，无热节流，使用12.3 GiB VRAM中的11.4个，无交换。 在精确模式下， GPU在最大时钟上消耗大约一半的功率：它正在等待专家而不是工作，这就是速度下降的原因。
输出质量
- JSON格式不会中断：在所有12次运行中，每个记录都保持有效；只有数组本身未关闭。
- 从提示的开头开始的指令仍然以30K （尾部保持的标签规则， 50/50和22/22 ）。
- 文档中间的标记以16K和24K被召回，但在两种模式下都以30K丢失。
- 快速模式的主要弱点是在长列表（约190个中的26–28个唯一代码）中重复实体，并在30K处循环122个重复行。 16K的精确模式保持了168/168和193/193的独特性，但在24K和30K时，它也可以在运行中折叠为26–33个唯一代码。
- 快速模式下的C代码在681行中产生了255个重复行，因此快速模式下的代码任务不可靠。
此实验的局限性
一台机器和一台构建：关于GPU功率限制和专家电源的结论适用于此卡，具有170 W限制和12 GiB的VRAM。 通过重新启动引擎来切换模式，因此在一个模式下的运行是连续的，并且顺序没有完全随机化。 具有暖缓存的精确模式运行一次， 1K和8K的精确模式具有2次重复而不是3次重复。
这对 Box 客户意味着什么
- 经济实惠的12 GB卡通过长答案保持60–68令牌/秒，而不仅仅是在开始时。
- 上下文中的长文档花费很少的速度，并且由于提示缓存，几乎可以立即回答重复的上下文。
- 根据任务选择模式：结构化数据快速，长列表必须保持唯一的精确时间；生成的代码需要审查。
原始数据
本实验的所有145个文件均可供下载： 13个JSONL结果文件、102个答案和推理文本、硬件遥测、引擎日志、脚本、系统状态、俄文原始报告和英文帖子草稿。 在发布之前删除了访问密钥、内部地址、用户名和内部路径。