RTX 3060 12GB 在 Unraid 上跑 Qwen3.8-Flash-Next：换 Swift 后约 30 tok/s，双卡还有优化空间

benson Playben

看了坛里这两篇分享，我也来交一份作业：

我的机器是一台日常使用的 Unraid NAS，显卡主要是 RTX 3060 12GB。这次通过 Strata，把 Qwen3.8-Flash-Next 这个 125B MoE 模型跑了起来，后面又加上闲置的 RTX 3070 8GB，并换成 Swift 1.5 的 IQ2_XS 量化版本。

先说目前的体验：能用，Swift 版在热态、有缓存的短回复里，可以看到约 30～34 token/s。 不过，加入 3070 并没有测出稳定、明显的速度提升，这部分还值得继续研究。

我的配置

项目	配置
系统	Unraid 7.3.2，Docker 部署
CPU	Intel i7-7700K，4 核 8 线程
内存	64GB
主卡	RTX 3060 12GB
辅助卡	RTX 3070 8GB
模型存储	SSD
引擎	Strata v0.1.21
当前模型	Swift-1.5-Qwen3.8-Flash-Next-GSQ-RCO-GGUF，IQ2_XS
上下文	128K，即 131072 tokens

这套硬件比较普通，CPU 也有些年头了。NAS 上还有其他服务，所以内存分配和系统稳定性，也是这次折腾中比较关注的事情。

需要说明，“3060 12GB 跑 125B”不代表整个模型都塞进了显存。 Strata 会把专家权重分配到 GPU、系统内存和 SSD 等层级，GPU 缓存常用专家。我们这套配置的专家内存区域约 33GiB，因此 64GB 系统内存和 SSD 也是能跑起来的重要条件。

从单卡到双卡，再换 Swift

最开始用 3060 12GB，跑的是原模型的 Q2_0 量化版本。确认文字和图像功能能用以后，就把闲置的 3070 加了进去，希望让第二张卡也缓存、计算一部分专家。

后面又试了原模型的 IQ2_XS，最后换到 Swift 1.5 IQ2_XS。目前保留 Swift 和原版 IQ2_XS，方便以后继续对比。

当前主要设置是：

128K 上下文；
INT8 KV cache，驻留窗口为 32768；
开启 MTP，使用 --spec 4；
3070 辅助专家缓存设置为 --expert-cache-device1 3000；
图像支持已启用。

Swift 这套 GGUF 分成两片，权重合计约 68GB，下载和存储前还是需要留够空间。

实际速度怎样？

这里把固定测试和日常日志分开，避免把一个最好看的数字当成所有任务的速度。

场景	测到的生成速度
原版 IQ2_XS，热态中文短回复，约 180 tokens	约 23～26 tok/s
Swift IQ2_XS，同类热态中文短回复，约 180 tokens	约 27 tok/s
Swift 日常已有缓存的短追问	约 30～34 tok/s

所以，说目前体验在 30 token/s 左右，基本符合实际。不过这是热态、部分上下文已经缓存时的表现；首次请求、代码输出、长输入等场景会有变化。

换 Swift 后，另一个比较明显的感受是回答更利落。我们测过的部分推理题，它输出的思考和回答更短，总耗时也下降了。这里既有生成速度的因素，也有输出 token 数减少的因素，不能全部算成引擎提速。

3070 加进去，有没有帮助？

目前在我这台机器上，没有看到稳定、明显的提速。

我们在同一个 Strata v0.1.21、同一个 Q2_0 模型下，调整过辅助卡的专家缓存数量。固定短回复测试大致如下：

3070 辅助专家缓存	热态请求总耗时
关闭辅助专家计算	约 6.3～7.5 秒
1500	约 6.3～7.3 秒
3000	约 6.1～7.1 秒
4000	约 6.6～6.9 秒

结果有波动，但没有呈现出缓存越多、速度就越快的趋势。

日志确认了 3070 确实参与专家计算，并非只是占着显存。目前运行 Swift 时，3060 显存占用约 11.7GiB，3070 约 4.7GiB。

可能的原因包括两张卡之间的数据传输、同步开销，以及老 CPU 的限制，但还没有足够证据确定是哪一个瓶颈。另外，在我们测试的 v0.1.21 辅助专家模式中，第二张卡没有参与 prompt prefill，因此长输入的读取速度也没有直接获得双卡加速。

所以目前更准确的结论是：这套 3060＋3070 配置的双卡收益还没有发挥出来。 Swift 切换后的改善，也不能归功于加了 3070，因为我们还没有做 Swift 单卡与双卡的严格对照测试。

128K 和图像也试了

上下文目前设为 128K，做过约 17.5K 和接近 119K tokens 的标记检索测试，Swift 都有通过的记录。

接近 119K 的那次，总耗时约 4 分 49 秒，大部分时间花在读取和处理输入上。这也说明，长上下文能装进去，与交互是否足够快，是两件需要分别观察的事情。

长输入测试中也出现过一次卡住、触发 watchdog 的情况，重启后重新测试通过。因此目前只能说大上下文已经跑通过，长期稳定性还需要继续观察。

图像方面，简单的颜色、形状和图片文字识别测试通过了。语音功能目前没有配置或测试。

接下来继续折腾什么？

对我来说，这次最有意思的是：一张 3060 12GB，加上 64GB 内存和 SSD，确实可以通过 Strata 把这个大 MoE 模型用起来。 换成 Swift 1.5 IQ2_XS 后，短回复的速度和整体使用感受也比较满意。

下一步准备看看新版 Strata 的改进，再继续研究双卡。目前这些数据都是 v0.1.21 的结果，新版是否更快，还要实际测试。

如果有朋友也在用 3060＋3070，或者其他不同显存容量的双卡配置，欢迎交流参数。现在模型已经跑起来了，但怎样让第二张卡带来实实在在的收益，我觉得还有很大的优化空间。

新人交作业，求点赞、求回复，欢迎大家交流指点！

benson Playben

补一份 2026-09-30 的更新：这次升级到 Strata 官方 v0.1.30，并重新调整双卡分配后，速度提升相当明显，终于看到闲置 3070 带来的实际收益了。

本次配置变化

硬件仍是 i7-7700K、64GB 内存、RTX 3060 12GB＋RTX 3070 8GB，模型仍是 Swift 1.5 Qwen3.8-Flash-Next 的 IQ2_XS，没有更换量化版本。保留 128K 上下文、INT8 KV、MTP 和图像支持，Ubuntu 虚拟机也保持运行。

引擎由 v0.1.21 升级到 v0.1.30，双卡由原来的辅助专家缓存方式改为整层拆分：3060 负责前 32 层，3070 负责后 16 层。试过几个拆分点，当前 32／16 的日常生成表现比较好，不能说已经是全局最优。

新旧速度对照

以下为同一个 Swift IQ2_XS、同一短中文提示的热态测试，temperature 0、关闭思考，输出上限 180 tokens：

配置	生成速度
v0.1.21，旧双卡配置	约 25.5 token/s
v0.1.30，保留旧辅助缓存方式	约 36.5 token/s
v0.1.30，仅使用 3060	约 32.8 token/s
v0.1.30，双卡按 32／16 层拆分	约 44–45 token/s

最终配置相对旧配置提升约 74%，相对新版单卡提升约 35%。所以之前说“3070 没有明显提速”，是旧版本、旧辅助专家模式的结果；这次新版配合手动层拆分，短中文生成已经测到了收益。

不过 45 token/s 是热态短中文场景，不能当成所有任务的速度：初次冷请求约 34 token/s，代码生成复测约 25.7 token/s。另外，新版单卡的输入处理比最终双卡更快，双卡收益也不是每个环节都一致。

长上下文也更快了

接近 119K（118876 tokens）的首次输入，旧配置 prefill 约 286 秒，新配置约 181 秒，吞吐约 657 token/s；整个请求从约 4 分 49 秒缩短到约 3 分 03 秒。读取输入的耗时减少约 37%，开头、中间、末尾的标记检索也通过了。

如果按这次速度估算，接近完整 128K 的首次输入处理约需 3 分 20 秒，这是估算，没有实际塞满 131072 tokens；128K 还要给输出和消息模板留位置。已有对话缓存的后续请求，也不必每次重新处理全部历史。

文字、基础图片识别以及工具调用格式都重新检查过，Open WebUI 也已接入，日常使用更方便了。

一点使用感受

个人体感上，目前这个 Qwen3.8-Flash-Next 大 MoE 的 Swift 1.5 版本，整体回答体验比我之前用的 Qwen3.8-27B 更好。现在速度也上来了，更愿意把它作为日常主力使用。不过这是我的实际使用感受，还没有做严格的同题质量盲测，不能直接当成模型能力排名。

接下来准备拿几个完整项目来测试：飞行模拟器、3D 跑酷、任务看板和小型全栈应用，看看能不能一次运行成功、后续修改会不会出问题。欢迎有类似双卡配置的朋友交流参数，继续一起优化！

Xiaote

作业不错。这次提速建议拆成两个变量记：① Strata v0.1.30 的调度/算子改进；② 3070 真正参与计算（不再闲置）。以后升版本要能分开算，不然不知道收益从哪来。

几点提醒：

3060 12G + 3070 8G 是容量与带宽都不对等的异构对，layer split 比 tensor parallel 合适；确认 3070 分到的层放得下，别出现显存换页反而拖慢。
IQ2_XS 是「容量优先」的取舍，128K 能开起来值得，但关键任务建议和 Q4 档对比一次质量，别默认无损。
INT8 KV + 128K 下 KV 随上下文线性涨，双卡吃紧时优先降 ctx 或 KV 精度，别硬扛。
Unraid 上把模型和缓存盘放 SSD，避开 parity 写入拖慢加载。

方便的话贴一下单卡与双卡的 pp/tg 对比，就能判断瓶颈在带宽、容量还是调度。

benson Playben

接着上条说的测试计划汇报一下。跑酷和 FPS 各跑了一遍，最大感受是：这模型没法自己一次把整个项目做完，但短任务干得挺好。

长任务它不是崩，是空转。跑酷那轮一个回合跑了 5 个小时、258 步，其中 200 多次都在读它自己写的代码，同一个文件读了 11 遍，最后一小时一个文件都没动，连入口页都没写出来。速度正常、不报错，就是在那儿一直"看代码"。

交付的东西还经常"看着挺完整，跑不起来"。那个 FPS 单文件 108KB、2400 多行，需求基本都覆盖了，但里头一处重复声明，整页 JS 直接不执行——它自己没浏览器也没解析器，压根不知道跑不起来。

但只要把确切的失败甩给它，修得飞快：报错原文加行号 7 分钟，浏览器异常栈 4 分钟，给它一条能复现的命令 3.8 分钟。反过来，一条消息里塞四个缺陷，它一个都不改，空转 19 分钟后开始重复调用。

所以我现在固定这么用：在线模型拆任务、定验收、盯进度、最后审代码；本地模型当 sub agent，一轮只干一件事，而且每件事都得有一个它自己在命令行能跑出来的判据。这样跑下来，补完一个项目 25 分钟、修两个缺陷 6 分钟，最后验收 15/15 全过、能玩。跟前面那个 5 小时的长回合比，同一个模型同一台机器，啥也没交出来。差别真不在模型，在怎么用它。

短任务的质量我觉得够用，模块分得干净、命名注释也像样。加上不花钱、代码不外传、还能离线，当个干短活的 sub agent 挺合适。但别指望它无人值守跑完整项目，那块得让在线模型或者人来管。

下一步继续试飞行模拟器和任务看板，主要看能不能一次跑起来、后面改起来会不会失控。

dardeaw feng

3060有這速度也算能用了~

抡锤者