抡锤者

可以分享一下这个notebook 吗？多谢了。

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

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

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

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

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

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

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

补一份 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 跑酷、任务看板和小型全栈应用，看看能不能一次运行成功、后续修改会不会出问题。欢迎有类似双卡配置的朋友交流参数，继续一起优化！

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

• RTX 3080 20G 单卡跑 Qwen3.8-Flash-Next IQ2_XS：Strata 上机实测
• 不管你信不信，单卡 3090 跑 Qwen3.8 Flash Next 可以到 100tok/s 了！

我的机器是一台日常使用的 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，或者其他不同显存容量的双卡配置，欢迎交流参数。现在模型已经跑起来了，但怎样让第二张卡带来实实在在的收益，我觉得还有很大的优化空间。

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

@David-Chen 说:

8G????!!!!!!!!!!看來我的3060 12G不只能做動畫了，晚點驗證看看

我的3060 12g 已经跑起来了。我靠，用swift1.5 128k 上下文竟然可以32 tok/s。

与你情况一样。之前一直用claude max， gpt 是plus，出了GPT-6 astra 后升 pro了。刚开始用的确惊艳，特别在computer use那一块。但是目前看来 ，如果一直用 gpt-6 astra的话一样不够用。现在claude 出了opus 5.5 和sonnet 5.5后就觉得性价比很高了。目前是准备下个月续费的时候把GPT 降回 plus。 我觉得还是看你的使用场景把。如果你干活是coding，数据分析，炒股啊，claude 的体感还是比很好。但是其它的 GPT就更好了。 (说真的的，GPT的编程能力也不比claude差。所有只能说体感差一点了。 ）。

看了论坛的 7900 XTX 单卡 Full-KV 测试 和 KVMem 512K 测试，我也把家里主要用作 Plex/media server 的空闲显卡利用起来。这台机器是 RTX 3060 12GB＋RTX 3070 8GB、64GB 内存。目标是在不额外买 24GB 卡的情况下，让 27B 模型处理较长的代码库和持续编程任务。

先说结果：DavidAU 的 Qwen3.8-27B LOW-MTP-IQ4_XS 配合 KVMem CUDA 双卡源码构建，已经实际处理并回答 240,056-token 的请求；后来保存的启动配置设为 262,144-token 逻辑上下文。一次接近满窗的 20 点远距离检索，实际输入 241,838 token，答对 15/20。所以“能塞进 256K”和“能精确找回 256K 中每个细节”是两回事。现在 27B 容器暂时停着，腾出 GPU 给另一项 150B 实验；下面都是此前实测，不是当前实时跑分。

大家关心的出字速度：早期纯文本测试中，生成约 31.0–34.0 tok/s；94K 输入时为 31.0 tok/s，240K 输入时为 34.0 tok/s。 相应 prefill 约 452–461 tok/s。这些数字来自 16K KVMem budget、4K 生成预留、关闭思考的配置。后来保存的 32K budget＋开启 low 思考配置没有同条件重测，不能直接沿用这个生成速度。

硬件、模型和部署

项目	配置
系统	Unraid、64GB RAM；原本以 Plex/media server 为主
GPU	RTX 3060 12GB＋RTX 3070 8GB；不是两张同容量卡
模型	DavidAU Qwen3.8-27B TURBO NEO-CODER-MAX MTP GGUF 的 LOW-MTP-IQ4_XS，约 14.26 GiB
引擎	KVMem llama.cpp CUDA 双卡源码构建；单容器、单并发
存储	模型、程序和配置放 SSD appdata，避免机械盘加载

最后保存的配置关键参数如下，供同类硬件参考；显卡型号、驱动和空余显存不同，不能直接照抄：

--device CUDA0,CUDA1 --split-mode layer --tensor-split 1,2 --gpu-layers all
--ctx-size 262144 --parallel 1 --flash-attn on
--cache-type-k q4_0 --cache-type-v q4_0
--batch-size 1024 --ubatch-size 128
--kvmem-budget 32768 --kvmem-gen-reserve 32768
--kvmem-mtp-state replay --spec-type draft-mtp --spec-draft-n-max 2
--enable-thinking --reasoning-effort low

KVMem 进程里 CUDA0 是 3070 8GB、CUDA1 是 3060 12GB；1,2 让更多层落在 3060，给 3070 留出空间。它不是显存精确的 1:2 切分，因为 KV、计算缓冲和 MTP 也占显存。262144 是逻辑窗口；32768 GPU budget 是历史 KV 的工作预算，超出的历史需要主机内存和检索机制。后来的 32768 generation reserve 也限定单次回复最多约 32K token，思考 token 算在里面。

这个模型也是视觉语言模型。我后来加了同仓库的 F16 mmproj 和 image-min-tokens 1024，图片内容识别已验证。以下长上下文基准主要来自更早的纯文本、16K budget、4K 生成预留、思考关闭配置；不要把它们当成上面最终 32K budget＋思考开启配置的跑分。

长上下文与速度：输入确实跑完了

在 1:2 分配、16K budget 的纯文本配置上，我用服务器返回的实际 token 数核对：

任务	实际输入	结果	Prefill	生成	整轮
Requests 源码 10 道事实题	94,309 token	10/10	460.6 tok/s	31.0 tok/s	209.3 秒
合成代码长输入，开头/中间/末尾标记及跨段引用	240,056 token	5/5	452.4 tok/s	34.0 tok/s	533.1 秒

请求完成后显存快照约为 3060 已用 10,407 MiB、3070 已用 4,903 MiB；分别还剩约 1.55 GiB 和 2.99 GiB。这是快照，不是带 Plex 转码时的峰值保证。KVMem 把更长的历史放到主机内存，GPU 显存不随逻辑上下文线性增长。

为了像第二篇帖子那样区分“容量”和“召回”，我又用固定 2:3 分配、同一份输入、20 个只出现一次的随机标记做对照；这个测试刻意让事实缺少语义线索，比较苛刻：

输入长度	LOW-MTP-IQ4_XS	更大的 MTP-Q4_K_S
124,584 token	18/20；471 tok/s prefill	18/20；448 tok/s prefill
241,838 token	15/20；466 tok/s prefill	15/20；444 tok/s prefill

两种量化在每档错的是同几个位置。单次实验不能证明原因，但提醒我不要把更大的量化当成 KVMem 远距检索的万能补丁。Q4_K_S 在偏向 3060 的 1:2 分配下甚至无法为每张卡建起 KV 工作块；改成 2:3 才能加载，近 256K 请求后 3060 只剩约 750 MiB。因此我保留 LOW 量化，获得更大的资源余量。这个 20 点实验只能评估孤立事实召回，不能直接当作编程质量排名。

从两篇帖学到、以及这台机器不同的地方

第一篇的 q8_0 KV 跑分来自 AMD 7900 XTX 24GB、Full-KV、HIP build；作者也补测了同一 build 的 q4/q8，prefill 几乎一样。我们这里是 NVIDIA 12GB＋8GB、KVMem、q4_0 K/V，不能把 607 tok/s 的数字或 q8 配置直接迁过来。我在本机曾只把 K 从 q4_0 改 q8_0、V 仍 q4_0：约 94K 的 10 题都为 10/10，没测到收益，资源还更紧。

第二篇最有价值的提示是：实际填满输入、量显存/主机内存、测远距离召回，并分开看 TTFT、decode 和 E2E。我们的 256K 测试也确实暴露了 5 题没看出的检索漏失。我试过把 KVMem budget 从 16K 提到 32K；早期 240K 单项测得 prefill 从约 467 降到 400 tok/s，5 题仍都是 5/5。后续视觉/编程用途仍采用 32K 工作预算，但这并不等于已经证明它能改善极端 needle 召回。

真实长编程任务还踩了两个客户端坑。约 145K 上下文的冷 prefill 曾接近 500 秒；客户端原来的 300 秒流式空闲超时会取消请求，缓存没暖起来，重试又从头开始。把这个本地模型连接的超时改为 900 秒后才稳定。另一个是生成预留：低于任务所需时会在长代码输出中途截断。提高到 32K 是保险，实际更有效的办法仍是让 agent 分块写文件。后续同一编程任务的重复测试还显示，关闭思考明显比低强度思考差；low 与 medium 的微小分数差异没有稳定复现，所以最后保存的配置默认开启 low。这些设置变化后的速度仍需与上面的基准分开看。

对我而言，这套方案的价值是把 media server 闲置时的 3060＋3070 变成可用的本地长上下文编程服务，同时保留对显存余量、检索错误和客户端超时的清醒认识。欢迎同样用小显存双卡的朋友交流：尤其想看大家在相同输入长度下对 KVMem budget、needle recall、真实跨文件编程任务和 Plex 并发的复测。