目前保留两个量化版本：IQ2_XS 日常使用，IQ3_XXS 作为备选。两者都配置了 128K 上下文、INT8 KV 流式缓存和 MTP。已有测试中，IQ2_XS 的综合生成速度约为 36–40 tok/s，IQ3_XXS 约为 28 tok/s。

先交代测试条件：测试期间有游戏在后台运行，负载没有完全控制。以下数字是这台机器上的观测结果，不能直接当成严格的性能提升比例。

一、硬件与软件

这份记录对应 2026 年 10 月 1 日的配置与测试，不代表后续版本的表现。

两张卡的连接带宽差别较大：

• RTX 4070：PCIe 4.0 ×16，实测传输带宽约 18–19.6GB/s。
• RTX 3060：PCIe 4.0 ×4，实测约 6.4GB/s。

因此，不能简单把两张卡视为一张 24GB 显卡，层分配和缓存布局仍需要单独测。

二、当前保留的两个配置

这里有两个容易混淆的地方：

layer_split=40 是层边界，不是 40% 的显存比例。 当前对应：

• 4070：第 0–39 层。
• 3060：第 40–47 层，以及输出头和 MTP。

Strata 的 --spec 4 是包含已接受 token 的验证窗口，最多提议 3 个草稿 token。 所以这里称为 MTP-3，不是直接把参数值叫作 MTP-4。

IQ2_XS 的关键引擎参数如下，仅列调优部分；模型、pack、MTP 路径及服务端 GPU 配置需要另外生成：

--max-context 131072
--kv int8
--kv-resident 32768
--expert-cache auto
--prefill auto
--spec 4
--spec-min-p 0.70
--pcie-frac 0.35
--vram-reserve-mib 1536

IQ3_XXS 使用相同的上下文、KV 和层分配，但恢复产品默认的 PCIe 分担和草稿置信度设置。

两个配置轮流使用，不会同时加载两个大模型占用这两张卡。

三、128K 是怎么放下的？

这套配置同时使用系统内存和 GPU 显存：

• 系统内存保存专家权重，CPU 参与未缓存专家的计算。
• GPU 缓存一部分常用专家。
• 完整 INT8 KV 后备缓存位于系统内存。
• 每个 QSA 层在显存中保留 32768 个驻留缓存单元。
• GDN 循环状态保留在负责对应层的 GPU 上。

因此，128K 上下文并不意味着把完整 128K KV 全部塞进显存。

也要区分两种“用内存”：专家和 KV 使用系统内存，不等于运行时持续从 SSD 读取全部专家。 本次测试用的是完整专家内存模式，没有启用 SSD 支持的专家 mmap 模式。

四、调优结果：手动层分配值得测试

五项吞吐测试均请求生成 512 tokens，温度 0、seed 42、关闭思考。其中四项是短提示，一项输入约 4437 tokens。

表中的综合速度使用“总生成 token 数 ÷ 总引擎解码时间”，不是五个速度数字的简单平均。

同一个 IQ2_XS 配置，前后就出现了 36.23 与 39.86 tok/s 的差异，所以不宜把某一次最高值当作稳定保证。

手动改为 40/8 层分配后，启动记录中的专家缓存槽位大致变化为：

• IQ2_XS：约 4400 → 7600。
• IQ3_XXS：约 3500 → 5600。

这使我保留了手动分配。不过，这里只比较了自动分配与 40/8，没有穷举所有层边界，不能称为全局最优。

CPU 工作线程也做过比较。IQ2_XS 在校准负载中，13、9、6 个工作线程分别约为 37.47、30.75、29.18 tok/s，最终保留默认 13 个。减少线程并没有在这轮测试里带来收益，但这也不能代替后续对 P/E 核亲和性的单独测试。

五、长提示和工具调用是否可用？

两个量化版本都通过了：

• 普通生成。
• 工具调用及工具结果回传。
• 客户端流式输出。
• 约 4419 tokens 的检索测试。
• 36919 输入 tokens 的双标记检索测试，能够取回靠近两端的验证码。

较长提示测试的结果：

这项测试超过了 32768 的驻留窗口，日志也记录了从系统内存读取 KV。

但目前最大的实测输入是 36919 tokens。128K 是分配容量，尚未验证满 128K 的检索质量、长时间稳定性或多用户并发。

首次调优吞吐测试中，MTP 草稿接受率分别约为：

• IQ2_XS：78.54%。
• IQ3_XXS：60.90%。

接受率会随任务与采样变化，不能只凭这个数字判断哪个配置更快。

六、模型放 SATA SSD 会不会拖慢生成？

比较过 SATA SSD 和 NVMe SSD：

NVMe 的加载优势明显，但在这些测试中，没有观察到持续生成速度的一致优势。

这些结果受缓存和后台负载影响，也只适用于本次专家驻留内存的运行方式，不能推导为“SSD 速度永远不影响推理”。如果换成依赖磁盘读取专家的模式，需要重新测试。

目前因此保留 SATA SSD 存储模型。

七、同机 llama.cpp 的参考结果

这台机器也保留了 Qwen3.8 27B 的 llama.cpp 配置：

这里主模型权重、嵌入和活动 KV 都放在 GPU 上，显存余量较紧。

这部分只作为同机使用参考：27B 与 Flash-Next 是不同模型，测试负载也不同，不能据此判定哪个引擎普遍更快或哪个模型质量更好。

八、后续准备验证的方向

当前日常默认仍是 IQ2_XS。IQ3_XXS 能运行，但测试中系统可用内存最低只有约 3.3GiB，对其他应用的余量较小。尚未做完整质量评测，因此不在这里给两个量化版本下质量排名。

后续想继续验证：

1. 更新引擎后重新测 Prefill、首字延迟和解码速度。
2. 对 i5-13600KF 单独比较默认线程布局与 P/E 核亲和性。
3. 比较更长的 MTP 窗口，在代码、中文聊天和工具调用中分别记录收益。
4. 关闭游戏等后台负载，重复自动分配与手动层分配的对照。
5. 在原生 Linux 上复测同一硬件

如果有同样使用 4070 + 3060、Intel P/E 核 CPU、64GB 内存 的朋友，欢迎分享层分配、线程亲和性和 MTP 实测。最好同时注明引擎版本、量化、实际输入长度与后台负载，这样更容易比较。

项目地址：Niko1221/Strata