抡锤者

@applejuice 说:

@Moor-Wu 便宜的还得是拼多多吗？
在观望 希望有机会入手3200

我没特别仔细的比价

ddr4 2400 ecc reg 拼多多买的，我就随便挑了一家，900多 32g, 不算便宜

补充：这轮测试实际使用的启动参数

把参数也贴出来，方便大家对照。下面按当前运行进程核对过，用户名、机器地址和本地目录都换成了占位路径。这是本文的 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，本次只补充文字，没有改服务或提高功耗。

strata不是有个参数来执行期协助去审查了么？

最近在双 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 更高。