这次主要想看：Pi Agent 读入长对话要等多久，接着做任务能不能复用历史，以及切到别的会话再回来，会不会又从头读一遍。 除了模型生成文字的速度，也检查了完整输出和工具调用。

先说一个比较直观的结果：在模拟这类会话的测试里，复用约 32K 的历史后，输出 100 条结构化记录约需 10 秒；切到另一个会话再回来，原会话缓存能恢复，完成同类输出只多了约半秒。这些是模型一次响应的耗时，不是 Pi Agent 跑完整个任务的时间；工具执行、生图和 Discord 发送还要另外算。

下面记录的是 2026 年 10 月 3–4 日这轮测试，具体的生成速度和耗时放在表格里。

1. 测试环境

双卡用的是主卡计算 + 副卡专家缓存，不是两个独立模型实例，也不是普通的张量并行。下面全部是单请求成绩，不是并发总吞吐。

2. 现在到底有多快

表里的 t/s 表示每秒处理或生成的 token 数，不等于每秒汉字数；Prefill 是模型读入对话历史的阶段。

下面取最近一轮对照测试中当前配置的结果，每项两次测量取中位数。耗时从客户端发请求算到完整响应结束，不包含 Discord 发送、外部工具执行或生图时间。

128K 是服务允许的上下文长度，不代表 Pi Agent 的长对话填满后，仍能保持表里这组测试的响应速度。 长输入检索、追加消息和取消恢复测过约 123K；表里的主要速度成绩来自 32K 档任务。自然语言两次输出不完全相同，不能只按耗时判断加速幅度。

这轮当前配置与候选配置合计通过 44 项完整任务及缓存检查。它们检查的是测试里的事实、输出格式和工具交互，不代表模型在所有任务上的准确率。每个配置每项只有两次测量，也没有据此计算置信区间。

3. 多个会话轮流请求，实际表现怎么样？

我的用途是多个 Pi Agent／Discord 会话共用一个模型，所以还测了 A → B → A：先处理一个长会话，切到另一个会话，再回到原会话继续请求。

返回原会话后，缓存能够恢复，不需要重新填充整段历史。完整响应只比一直留在原会话时多约半秒，这组测试里，多会话切换并没有让速度明显掉下去。中间那条新会话的输出更短，不能拿它的总耗时与另外两条直接比快慢。

如果需求是几个会话轮流聊天、执行任务，目前这套配置已经挺好用。 但这里测的是交替请求，不是多个请求同时生成；真正同时到达时，仍会排队。

在我这种多个会话交替使用的场景里，目前的响应速度并没有比之前用 vLLM 时差。不过前后的模型和配置不同，这属于使用体验，不能当成同条件下的引擎胜负结论。

4. 相比最开始，改善了多少

这是不同优化阶段的变化，不是最后重跑的一组原版/修改版严格 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 更高。