[实测] 双 RTX 3080 20G + Strata + Qwen3.8 Flash Next IQ3_S：128K 上下文，Pi Agent 持续任务与多会话实测
-
最近在双 3080 20G 上折腾了一轮 Strata，用它给 Pi Agent 提供本地模型服务。平时我通过 Discord 和 Pi Agent 聊天、让它调用工具执行任务，也会在几个不同的会话之间来回切换。
这次主要想看：Pi Agent 读入长对话要等多久，接着做任务能不能复用历史，以及切到别的会话再回来，会不会又从头读一遍。 除了模型生成文字的速度，也检查了完整输出和工具调用。
先说一个比较直观的结果：在模拟这类会话的测试里，复用约 32K 的历史后，输出 100 条结构化记录约需 10 秒；切到另一个会话再回来，原会话缓存能恢复，完成同类输出只多了约半秒。这些是模型一次响应的耗时，不是 Pi Agent 跑完整个任务的时间；工具执行、生图和 Discord 发送还要另外算。
下面记录的是 2026 年 10 月 3–4 日这轮测试，具体的生成速度和耗时放在表格里。
1. 测试环境
项目 配置 GPU RTX 3080 20G × 2，魔改卡 平台 华南 X99 F8，E5-2686 v4，18 核 36 线程 内存 系统可用约 94 GiB 连接 PCIe 3.0，没有 GPU P2P 功耗限制 两张卡分别 250W、280W，测试期间没有提高 引擎、模型 Strata v0.1.38 基础上的修改版；Qwen3.8-Flash-Next GSQ-RCO，IQ3_S 上下文、KV 131,072 tokens；INT8 KV，显存驻留 32,768 cells 推测解码、思考 MTP 6，最低置信度 0.9；medium，思考上限 2048、输出上限 8192 双卡用的是主卡计算 + 副卡专家缓存，不是两个独立模型实例，也不是普通的张量并行。下面全部是单请求成绩，不是并发总吞吐。
2. 现在到底有多快
表里的 t/s 表示每秒处理或生成的 token 数，不等于每秒汉字数；Prefill 是模型读入对话历史的阶段。
下面取最近一轮对照测试中当前配置的结果，每项两次测量取中位数。耗时从客户端发请求算到完整响应结束，不包含 Discord 发送、外部工具执行或生图时间。
任务 Prefill 生成速度 完整响应耗时 32K 档冷输入，约 123 tokens 输出 2109.6 t/s 76.4 t/s 17.28 秒 32K 历史命中，完整输出 100 条记录，约 1012 tokens 复用历史 112.85 t/s 9.76 秒 重复上述结构化任务 复用历史 112.50 t/s 9.55 秒 保留历史，只修改最后一条消息 复用历史 108.15 t/s 10.90 秒 自然语言列表，约 1202 tokens 复用历史 70.55 t/s 18.22 秒 重复自然语言任务，约 1203 tokens 复用历史 84.80 t/s 15.09 秒 切到另一会话，再返回原会话 恢复缓存 103.70 t/s 10.28 秒 128K 是服务允许的上下文长度，不代表 Pi Agent 的长对话填满后，仍能保持表里这组测试的响应速度。 长输入检索、追加消息和取消恢复测过约 123K；表里的主要速度成绩来自 32K 档任务。自然语言两次输出不完全相同，不能只按耗时判断加速幅度。
这轮当前配置与候选配置合计通过 44 项完整任务及缓存检查。它们检查的是测试里的事实、输出格式和工具交互，不代表模型在所有任务上的准确率。每个配置每项只有两次测量，也没有据此计算置信区间。
3. 多个会话轮流请求，实际表现怎么样？
我的用途是多个 Pi Agent／Discord 会话共用一个模型，所以还测了 A → B → A：先处理一个长会话，切到另一个会话，再回到原会话继续请求。
场景 生成速度 完整响应耗时 原会话缓存命中，输出约 1012 tokens 112.85 t/s 9.76 秒 切到另一条约 8K 的新会话 70.60 t/s 7.19 秒 返回原会话，恢复缓存并输出约 1012 tokens 103.70 t/s 10.28 秒 返回原会话后，缓存能够恢复，不需要重新填充整段历史。完整响应只比一直留在原会话时多约半秒，这组测试里，多会话切换并没有让速度明显掉下去。中间那条新会话的输出更短，不能拿它的总耗时与另外两条直接比快慢。
如果需求是几个会话轮流聊天、执行任务，目前这套配置已经挺好用。 但这里测的是交替请求，不是多个请求同时生成；真正同时到达时，仍会排队。
在我这种多个会话交替使用的场景里，目前的响应速度并没有比之前用 vLLM 时差。不过前后的模型和配置不同，这属于使用体验，不能当成同条件下的引擎胜负结论。
4. 相比最开始，改善了多少
项目 早期状态 后续状态 变化 32K 冷输入 prefill 时间 21.83 秒 15.58 秒 减少约 28.6% 64K 冷输入 prefill 时间 42.26 秒 阶段验证值 30.91 秒 减少约 26.9% 已调参的结构化热请求 82.95 t/s 112.85 t/s 提高约 36% 这是不同优化阶段的变化，不是最后重跑的一组原版/修改版严格 A/B。各项收益不能直接相加，更不能把结构化任务的提升当成所有 Agent 任务的提升。
5. 这些速度是怎么提上来的
最开始分析耗时的时候，发现问题不只是显卡算得慢。一次约 1K 输入的冷请求里，预填充 GPU 时间约 3.88 秒，其中等待专家权重搬运就占了约 2.53 秒。显卡有不少时间是在等数据，而不是计算。
所以这一轮先处理的是：能不能少搬一点，或者边搬边算。
沿着这个方向，我们参考了 architectds 的 Strata fork。它在官方 v0.1.38 上增加了 CPU 协助预填充、按输入长度安排分块等改动，正好对应我们这台 PCIe 3.0 双卡机器遇到的问题。本次参考版本是 05c0f36。
我们没有直接把整个 fork 换上去，而是在官方 v0.1.38 的基础上，采用其中相关的实现，再做本机对照测试。第一轮组合测试里，32K 冷输入的预填充从 21.83 秒降到 17.09 秒，64K 从 42.26 秒降到 33.19 秒。这一阶段主要改善的是读入速度，生成速度没有明显提升。
其中两项比较重要：
- CPU 协助计算专家： 小块预填充时，一部分专家直接由 CPU 从内存计算，GPU 同时处理其余部分，减少 PCIe 搬运等待。
- 调整预填充分块： 尽量减少块数，避免最后留下一个很小的块，却仍要支付一轮专家搬运成本。
该 fork 还有按需加载图像编码器、临时借还专家缓存显存的实现，主要解决识图时的显存安排，这里没有给它单独算加速收益。具体来源见其 README。
这部分是参考 fork 的贡献，不是我们的原创。另外，它较早的 Q4 KV attention、MTP KV ring、批量专家 gather 改动已经进入官方 v0.1.38，不能重复计算收益。
在这个基础上，我们继续检查双卡缓存、KV 上传和 CPU 调度，才有了下面四项自己的改动。
6. 我们自己改了什么
自己的 fork 是 moorwu/Strata。原创改动拆成了四个 PR，提交给官方 Strata。
双卡专家缓存去重：PR #731
副卡已有的专家，不再被主卡自适应缓存重复收进去。曾观察到约 1900–2000 个重复槽位；相同副卡容量下，32K 结构化热请求从 81.5 提高到 94.1 t/s，完整耗时从 13.00 降到 11.42 秒。
KV 上传与计算重叠：PR #732
提前上传下一层需要的 KV，让搬运和当前计算重叠。阶段 A/B 中，32K、64K prefill 时间分别减少约 5.3%、4.1%；8K 没有明显收益，也没有测出 decode 加速。
CPU 专家流水线：PR #733
一个专家完成前半段计算，就开始它的后半段，不等整批专家一起完成。单项收益约 1%，没有把它包装成大提升；独立移植版通过了 810/810 项真实权重数值一致性检查。这是局部计算检查，不是模型能力评分。
在消息边界保存 checkpoint：PR #734
长历史不变、只改最后一条消息时，尽量从最后一条消息之前恢复。配合分块调整，首次修改任务从 17.24 降到 11.53 秒；这是组合收益，不是 checkpoint 单项收益。
四个 PR 目前都是 draft，尚未合并。 上面的性能收益来自本机组合版；移植到纯官方代码后的版本已完成编译和部分测试，完整 GPU 性能及回归验证还没全部完成。fork 的 main 仍跟随官方，四项改动在各自分支里，直接克隆 main 不会得到本文测速用的组合版。
7. 配置也有用，但不是越大越好
MTP 从 4 调到 6 的受控对照中，热请求生成速度提高约 15.5%，八类任务耗时的中位数之和减少约 5.7%。冷 prefill 没有改善，短工具任务也没有稳定收益；继续加到 8 没有采用。
会话缓存目前是 8 GiB、4 个槽位，保留 2560 MiB 空闲内存门槛。A/B/A 会话切换测过可以恢复，但缓存不能保证无限保留或跨服务重启恢复。
最后还试过一些局部能提高 token 速度的方案，但混合任务总耗时只改善约 0.9%，工具续接反而更慢，最终没有上线。我现在更看重一件事：同样的任务，能不能更早完整做完，而不只是仪表盘上的 t/s 更高。
-
补充：这轮测试实际使用的启动参数
把参数也贴出来，方便大家对照。下面按当前运行进程核对过，用户名、机器地址和本地目录都换成了占位路径。这是本文的 v0.1.38 组合修改版参数，不是克隆官方或我们的 main 后就能直接复现的通用配置。 模型的 native pack 和配套 MTP 文件需要提前准备好。
1. GPU 顺序和修改版开关
# 按散热情况选择主卡；这里物理 GPU 1 是计算卡，GPU 0 是辅助缓存卡。 export CUDA_VISIBLE_DEVICES=1,0 # 以下开关由本文使用的组合修改版读取，不保证官方版本支持。 export STRATA_PREFILL_CPU=auto export STRATA_DISJOINT_ADAPT=1 export STRATA_KV_PREFETCH=1 export STRATA_POOL_PIPELINE=1 export STRATA_CACHE_MESSAGE_BOUNDARY=1对应关系：CPU 协助预填充来自参考 fork；后四项分别控制双卡缓存去重、KV 预取、CPU 专家流水线、消息边界 checkpoint，详见主帖的四个 PR。仅设置环境变量不会给未包含这些代码的版本增加功能。
2. 引擎启动命令
下面的路径都是占位符，替换成自己的文件位置。参数值则保留本机实际设置。
STRATA_BIN="/path/to/modified-strata" PACK_DIR="/path/to/native-pack/iq3_s" MODEL_DIR="/path/to/gguf" MTP_DIR="/path/to/mtp/rt" EXPERT_PROFILE="/path/to/expert-profile.bin" CONTROL_VECTOR="/path/to/Qwen3.8-Flash-Next-experimental-speed-projection.gguf" "$STRATA_BIN" --serve \ --pack "$PACK_DIR" \ --native "$MODEL_DIR/Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S-00001-of-00002.gguf" \ --ple-gguf "$MODEL_DIR/Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S-00002-of-00002.gguf" \ --expert-profile "$EXPERT_PROFILE" \ --expert-cache auto \ --expert-cache-device1 9500 \ --prefill auto:32768 \ --spec 6 \ --spec-min-p 0.9 \ --mtp "$MTP_DIR" \ --mtp-max-t 6 \ --max-context 131072 \ --kv int8 \ --kv-resident 32768 \ --vram-reserve-mib 700 \ --conversation-cache-mib 8192 \ --conversation-cache-slots 4 \ --conversation-cache-min-free-mib 2560 \ --pcie-frac 0.0 \ --vision \ --control-vector-scaled "$CONTROL_VECTOR:1.0" \ --control-vector-layer-range 4 44 \ --cvec-mode project \ --cvec-dir per-layer几个容易混淆的地方：
- 双卡：
device1是 CUDA 重排后的第二张卡，在上述顺序里对应物理 GPU 0。9500 是副卡专家缓存槽位数，不是 MiB，也不是两卡各跑一份模型。主卡缓存由 auto 按剩余显存安排。 - 128K / INT8 KV：服务上下文是 131072；32768 是显存驻留窗口，不是把总上下文限制在 32K。
- 会话缓存：8192 MiB 总预算、4 个槽位，空闲内存门槛 2560 MiB。用于多个会话交替时恢复历史，不等于四路同时生成，也不保证跨重启保留。
- MTP：本轮采用 spec=6、mtp-max-t=6、最低置信度 0.9，需要配套权重。不是只加一个数字就能启用。
- 识图：本机启用了 vision，依赖配套资源和修改版的按需加载逻辑；本文速度表不代表识图速度。
3. 思考和 HTTP 服务是另外一层
实际对外还套了一层服务封装，处理 OpenAI 兼容接口和思考预算。上面的原生引擎命令不是完整的 HTTP 服务启动脚本。
服务层设置 本轮值 请求思考级别 medium 思考 token 预算 2048 输出 token 上限 8192 封装层通过
STRATA_THINKING_BUDGET=2048和STRATA_OUTPUT_CAP=8192读取预算；它们不是承诺官方原生引擎直接支持的 CLI 参数。客户端的采样设置、提示词和任务内容也会影响实际耗时。4. 控制向量参数
末尾四项是当前启用的运行时控制向量实验：强度 1.0，作用层 4–44，project 模式，per-layer 方向。它与直接修改权重的 abliterated 模型不是一回事，也不是一个保证所有请求都不拒答的通用开关。 文件必须与模型配套；没有该文件时不要照抄这四项。本文没有单独给它计算加速收益。
以上是便于对照的脱敏参数记录，没有公开服务地址、认证信息或本机目录。两卡功耗限制仍是主帖里的 250W / 280W，本次只补充文字，没有改服务或提高功耗。
- 双卡：
-
-
-
-
-
@Moor-Wu 便宜的还得是拼多多吗？
在观望 希望有机会入手3200 -
-
