Strata 0.1.38 → 0.1.43 性能评测：不同上下文长度下的真实表现

设备：单卡 NVIDIA RTX 3060 12GB（compute capability 8.6，即 sm_86）+ 64GB 内存 模型：Qwen3.8-Flash-Next（IQ2_XS 量化，约 39GB 权重，MoE + 专家缓存 + 4 级投机解码） 结论先行：

升级后短上下文 decode 稳定 +37%、长上下文 prefill 最高 +19%、专家缓存命中 +7~+10 个百分点。

进一步拉到 16K–512K 超长上下文：新版 decode 全程领先旧版 +17%~+108%（64K 直接翻倍），同时本次还提供单卡 12GB 上跑通 512K 上下文测试数据。

一、为什么做这次评测

Strata 在 0.1.42 / 0.1.43 的更新日志里明确写了针对 sm_86（正是 RTX 3060 的架构） 的 decode 提速：

• ◆STRATA_ROUTE_TAIL_SKIP=7 在 CUDA 上默认开启，decode +13–16%；
• ◆route-resident swap，decode +1.6–2.4%；
• ◆0.1.43 的 adaptive-tier overlap 进一步优化长序列。

但我们更关心一个常被忽略的问题：速度到底随"上下文长度"怎么变？ 这是实际使用中（长文档、多轮对话、RAG）最影响体感的因素。所以本次评测不只比"快了多少"，还把上下文长度（512 / 1500 / 4000 / 8000 token）单独拆开测。

二、测试方法（可复现）

• ◆接口：OpenAI 兼容 /v1/chat/completions（流式测 decode，非流式 max_tokens=1 测 prefill）。
• ◆Prompt：固定一段英文散文，按字符→token 比例校准到目标 token 数，保证各长度下输入一致、低方差。
• ◆Decode 基准：每档跑 6 轮取平均，丢弃冷启动首轮；固定 max_tokens=256。
• ◆Prefill 基准：每档跑 5 轮，丢弃冷启动首轮（首轮含 kernel/显存预热，会虚高）；非流式 + max_tokens=1，总耗时近似 prefill 时间（生成 1 个 token 的耗时可忽略）。
• ◆专家缓存命中率：从服务端日志 expert cache X% hit 读取。
• ◆关键一致性：两个引擎在完全相同的配置下对比——--expert-cache auto --prefill auto --spec 4 --kv int8 --max-context 131072，且都带 --expert-profile（两个引擎都强制要求该 .bin 存在，否则启动即退出——实测 0.1.43 缺失时直接报 read_expert_profile: cannot open 退出；为公平两者统一带上）。模型权重、硬件、并发（单请求串行）完全一致，差异只来自引擎版本。

数据文件：bench_0138_*.json / bench_0143_*.json（decode）、bench_prefill_0138_*.json / bench_prefill_0143_*.json（prefill），均落在 /home/user/Strata/。

三、Decode 吞吐：短上下文几乎不随上下文变化，整体 +37%

洞察 1：decode 速度几乎与上下文长度无关。 无论是 512 还是 8000 token，老版本都稳定在 ~33–34 tok/s，新版本稳定在 ~45–48 tok/s。原因是 decode 是逐 token、受显存带宽 / 专家计算主导的环节，每生成一个 token 都要过一遍 MoE 专家，注意力对 KV cache 的开销占比很小，因此上下文变长几乎不拖慢单 token 生成。

洞察 2：升级收益在稍长上下文时反而略大。 8000 token 下提升 +41%，高于 1500 的 +33%。说明 0.1.43 针对 sm_86 的优化（tail-skip、resident 专家 GPU 计算、adaptive overlap）在更"重"的序列上收益更明显。

四、Prefill（预填充）吞吐：短输入输出中随上下文暴增 ~20 倍

洞察 3：prefill 吞吐随上下文长度近乎线性暴涨。 从 512 到 8000 token，prefill 速度提升约 20 倍（3.3k → 67.7k tok/s）。这是因为预填充是高度并行的矩阵运算——prompt 越长，GPU 的计算批次越饱满，利用率越高。短 prompt 反而"喂不饱"GPU，吞吐被 kernel 启动与调度开销稀释。

洞察 4：热态 prefill 延迟几乎是平的。 单独看"耗时"：512 与 8000 token 的预热后 prefill 时间都只有 ~0.13–0.2 秒。也就是说，在引擎已热身的前提下，首 token 延迟不随 prompt 变长而明显变大——这是长文档 / RAG 场景的利好：你塞 8000 token 进去，和塞 512 token 进去，用户感知到的"出字前等待"差不多。

洞察 5：0.1.43 的 prefill 优势集中在长上下文。 短上下文基本持平（+0.4%），但 4000 token +8%、8000 token +19%，与 decode 的结论一致：新架构对"重"序列更友好。

五、专家缓存命中率：普遍 +7~10 个百分点

新版本的专家缓存命中率整体更高，意味着更多专家命中显存热区、更少回退到主机/磁盘读取——这是 decode 提速的重要来源之一（resident 专家在 GPU 上直接计算）。

六、长上下文实测：16K → 256K，以及全新的 512K

上面的 512–8000 属于"短上下文"。可真实使用里——塞进一份长文档、整个代码库、几十轮对话——动辄几万到几十万 token。所以我们直接把上下文拉到 16K / 32K / 64K / 128K / 256K，并挑战 512K。

口径说明（很重要）：本节的 prefill 速度 = 实际 prompt tokens ÷ 首字时间（TTFT），取冷启动首轮（每个长度用全新 prompt、不命中缓存）。它和第四节"预热轮 prefill"不是一回事——预热轮若重复同一个 prompt 会命中 KV 前缀缓存，跑出来的是虚高吞吐（所以那节 8000 token 能到 5.7 万 tok/s）；本节统一用"用户真实感知的出字前等待"，更代表长文档场景的体感。两节数字不可直接横向比较。

6.1 新引擎 0.1.43 长上下文成绩单

6.2 新旧对比：decode 是长上下文真正的分水岭

洞察 A：旧版 decode 一到长上下文就垮，新版扛得住。 旧版从 32K 的 32.5 tok/s 一路掉到 64K 的 21.6、128K 的 25.4；新版一直到 128K 都稳在 41–51 tok/s，64K 直接翻倍（44.9 对 21.6，+108%）。对体感来说，"长上下文下出字顺不顺"比峰值速度更关键——这正是本次升级最值钱的地方。

洞察 B：新版把"高 decode 区间"从旧版的 ~32K 一路拉长到 ~128K。 到 256K / 512K 才回落到 27–30（这两档受 q4_0 KV 与超长注意力影响），但即便回落，也仍高于旧版在 64K–256K 的表现（仅 21–25）。

洞察 C：真实 prefill（冷启动）新版全程更快，越长优势越大。 64K 起持续领先（785 / 690 / 610 / 489 对 673 / 590 / 508），TTFT 也更短（128K：189s 对 216s；256K：428s 对 502s）。

6.3 512K：从"跑不动"到"跑得动"

512K 是一个增强的能力：模型训练上下文是 256K，512K 靠 --rope-scaling yarn 外扩 + --kv q4_0，在这张 12GB 消费卡上真实跑通——522,101 token 的 prompt，489 tok/s 预填充、29.6 tok/s 解码，稳定产出首字。旧版在这一档直接缺席。

边界说明：受单卡 12GB 显存限制，16K–128K 用 int8 KV，256K / 512K 降到 q4_0 KV（把 KV 显存砍半、给专家缓存腾地方）；512K 还启用了 yarn 外扩——它超出模型 256K 的训练上下文，速度可测，但超长文本的理解质量可能退化，本文只测速、不测准确率。512K 时显存吃到约 11.7 / 12.3 GB，属贴着上限运行。旧版数据取自升级前同型号卡的实测存档。

6.4 配置权衡：把引擎开到 256K，短上下文会变慢

一个容易被忽略的点：--max-context 开多大，会直接影响短上下文的实测速度。 我们让同一套新引擎分别以 --max-context 131072（128K 封顶，int8 KV）和 --max-context 262144（256K 封顶，q4_0 KV）启动，各测 16 / 32 / 64 / 128：

开到 256K 会让 16–64K 变慢（prefill −7%~−17%，decode 最多 −16%），到 128K 才基本打平。根因是显存挤占：--max-context 越大，预留的 KV 容量越多，留给专家缓存的显存越少 → 常驻专家变少、命中率下降（16K 从 74.1% 掉到 68.8%）→ 更多回退到 CPU / 磁盘读专家 → 变慢；q4_0 省下的 KV 带宽补不回来。

实用结论：只用 ≤128K，就配 --max-context 131072 --kv int8（更快）；确实要 256K / 512K 再开到 262144 / 524288，并接受短上下文约 10–16% 的代价。

口径提醒：本小节同时变了 max-context（262144 vs 131072）与 KV（q4_0 vs int8）两个变量，但命中率同步下降表明主导因素是 max-context 预留显存、挤占了专家缓存。

七、升级收益一句话总结

对 RTX 3060 这类"decode 受限"的消费卡，这次升级是实打实的免费午餐：无需换硬件、不增加显存占用，单卡本地推理的体感速度直接上一个台阶，长上下文场景收益更大。

八、附录：本次是如何升级的（供复现参考）

这台机器到 github.com 的出站被封，但 raw.githubusercontent.com / 镜像 ghproxy.net 可达，且 Linux 没有预编译引擎包（需本地编译），所以走的是：

1. 1git remote set-url origin https://ghproxy.net/https://github.com/Niko1221/Strata.git 后 git fetch（只读拉取上游，确认 0.1.43 为目标）。
2. 2./setup.sh --update 触发本地 CUDA 编译（机器已有 nvcc CUDA 12.x + libcublas + cmake，编译约十几分钟），Python 依赖走 pypi（可达）。
3. 3升级前已 cp -a engine engine.bak-0.1.38 备份旧引擎；升级后 cp -a engine engine.bak-0.1.43，可随时回滚。
4. 4重启服务加载新引擎（systemctl --user restart strata），短暂中断后恢复正常。

评测日期：2026-10-12~2026-10-15（16K–512K 长上下文部分为 10-14 补充实测）；所有数字均为单卡单请求串行实测，未开启并发；不同硬件 / 量化 / 并发下绝对值会有差异，但"相对提升趋势"具有参考价值。