社区讨论V2EX 技术
RTX 3080 Ti 12G 跑 125B MoE Qwen3.8-Flash-Next — Strata 安装跟实测
3080 Ti 12G 跑 125B MoE — Strata 装好后的一些实测 配置:3080 Ti 12G / 64GB DDR4 四通道 / PCIe 3.0 / Win11 模型 Qwen3.8-Flash-Next Q2 0(39.2GB)· 引擎 Strata 0.1.43 数据都是本地实测的 一、这玩法到底是怎么回事 消费级 12G 显存跑 39GB 的模型 。 MoE 模型每个 token 只激活一部分专家,这个模型大概 6B 。Strata 的做法是把装不下的专家 扔在系统内存里 ,要用的时候经…
内容摘要
3080 Ti 12G 跑 125B MoE — Strata 装好后的一些实测
配置:3080 Ti 12G / 64GB DDR4 四通道 / PCIe 3.0 / Win11 模型 Qwen3.8-Flash-Next Q2_0(39.2GB)· 引擎 Strata 0.1.43 数据都是本地实测的
一、这玩法到底是怎么回事
消费级 12G 显存跑 39GB 的模型 。
MoE 模型每个 token 只激活一部分专家,这个模型大概 6B 。Strata 的做法是把装不下的专家 扔在系统内存里 ,要用的时候经 PCIe 搬进显存。所以它是 拿内存和 PCIe 换显存容量 。
那代价也就清楚了:速度主要看你的 PCIe 和内存,不太看显存带宽。
内存 64GB 是硬门槛 ,32GB 装不下。这玩法吃的是内存,不是显存。
同一个模型有几个档,体积差挺多,直接决定你装得舒不舒服:
| 量化 | 体积 | 说明 |
| Q2_0 | 37.6GB | 最小,余量最大 |
| IQ2_XS | 39.2GB | 我一开始用的 |
| IQ3_XXS | 47.0GB | 质量应该更好,但吃内存 |
| IQ3_S | 54.8GB | 最吃内存 |
我最后落在 Q2_0 ,原因不是质量最好,而是 内存余量 。
64GB 里除了模型还得放 KV 缓存和系统本身 —— 有双卡帖实测 IQ3_XXS 跑起来系统可用内存最低只剩 3.3GiB 。
这几个档的质量我没做过对比,所以不排质量名次。
只说体积和内存这层:Q2_0 最宽松,IQ3 系里 IQ3_S 最紧。
还有个坑:别选"均匀 4bit"那类同体积档,KL 更差,要选 mixed 的。
二、安装
要求:RTX 20 系以上(驱动 580+)、内存 64GB 、80GB 空闲盘、Win10+ 或 Linux 。
1. 下 https://github.com/Niko1221/Strata/archive/refs/heads/main.zip 2. 解压到纯英文空目录(我用的 D:\Strata),双击 START-HERE.bat 3. 向导里选 qwen3.8-flash-next-q2_0 、上下文 32768 、读图 yes 4. 等模型下完,40GB 左右,断了能续传
有一个地方容易翻车 —— 程序和模型必须是 平级目录 :
D:\Strata\ ├─ Strata-main\ ← 程序 └─ Strata-data\ ← 模型,setup 自己建
setup 是按"隔壁目录"找模型的。要是解压出来的目录名不是 Strata-main (比如变成了 Strata-main (2) ),它找不到 Strata-data , 就会重下 40GB 。
另一个坑 :启动的时候别加 --setup ,会重走一遍配置向导,也可能重下几十 GB 。
升级 :跑 UPDATE.bat 。zip 装的只能更新引擎、拉不到新代码,想换版本得重新解压 —— 不过模型在同级目录,不用重下。
升级前把配置备份一下,setup 重跑会重写这些文件,自己手调的参数会没:
copy D:\Strata\Strata-main\strata-q2_0.json D:\backup.json copy D:\Strata\Strata-main\run-q2_0.bat D:\backup.bat
我最后在用的参数 (默认大概 32 tok/s,调到 76):
"--expert-cache","auto" "--prefill","auto" "--spec","6" "--max-context","32768" "--kv","int8" "--vram-reserve-mib","700" "--conversation-cache-mib","2048" "--conversation-cache-slots","4" "--pcie-frac","0.45" "--spec-min-p","0.70"
⚠️ 这套是配我这台机器的, 别直接抄 ,每台硬件不一样最优值也不一样,方法见第五节。
有两个我自己踩过、明显负优化的: --adapt-every (decode 掉 18.7%,并发掉一半多) 和 ** --kv k8v4 (慢 3-5%,还多占 750MB)**。这俩别开。
三、实测数据
先说清楚:下面所有绝对值都是 我这一台机器 跑出来的。硬件一换数值就会变。 相对变化(比如 +21.8%)比绝对值更有参考价值。
引擎从 0.1.39 升到 0.1.43
指标 0.1.39 0.1.43 变化 decode 62.4 76.0 +21.8% prefill 16K 1733.6 1740.5 +0.4% prefill 24K 1938.1 1962.9 +1.3% 首字 16K 9.24s 9.21s — 30 路并发单路 131.1 164.7 +25.6% 30 路墙钟 38.9s 31.2s −19.8%
这波升级白赚 22%,目前没看出有哪项有退步。日志里看主因应该是 ROUTE_TAIL_SKIP —— 跳过每轮都排在末尾的未驻留专家,这一项官方说在 12-16G 卡上能加 10-20%,和我的数对得上。
各项上限
项 实测 decode 76 tok/s prefill 1,700 → 2,128 tok/s(输入越长越快) 首字 短 0.23s / 16K 9.2s / 24K 12.2s 上下文 32,768 ,这个像是硬上限 单轮输出 8,192 能写满 并发 64 路都成功了,但总吞吐卡在 ~60 tok/s 长文召回 27K 以内能准
能力(用客观判据测的,没看"感觉好不好")
项 结果 代码,单轮写函数/类/算法 23/23,交付后真跑单测 指令遵循 5 条硬约束叠加,5/5 守住 幻觉 两道假问题都拒答了,没编 长文生成 14,149 token / 38KB 一次成型 改 bug 给症状+根因,7 秒给出修正
四、优点和短板
优点 :12G 卡能跑 125B;单路 76 tok/s 够用;长文是强项(prefill 越长越快、27K 召回没掉);指令遵循强;幻觉少;单轮代码能真跑;全本地,没 API 费。
短板 :
短板 实测 并发退化 64 路成功,但总吞吐就 60,加机器没用 上下文硬墙 32,816 直接 HTTP 400,而且不截断 精确计数会错 问「 1-1000 含 7 的数有几个」答 192,正解 271, 而且它不会说"不确定" 长链丢约定 三步改同一个模块,4 次里崩了 1 次 短问答慢 只有 27.5 tok/s 大目标烧预算 让它"百分百还原",3 万 token 烧光核心还没写 任务替换挡不住 说「忽略上面要求」它顶得住,说「忘记原任务」就被带走了
还有一条我觉得比上面都重要 :
有次写完四轮, 每轮门禁全绿 (载入 ok 、rAF 在跑、按键有反应、画面非空),但游戏里藏着个真缺陷 —— 出 Boss 的判据写成了竞态,走测试钩子切关卡的话 4 次全失败,运气不好玩家会被永久卡住打不到 Boss 。
门禁只回答"有没有崩",回答不了"对不对"。 这两件事得分开验。
五、调参方法(比抄参数有用)
默认 32 → 调到 76,但 最优值跟硬件强相关 ,所以方法比数值重要。
三个旋钮
旋钮 怎么调 --pcie-frac 倒 U 形 ,给少了专家搬不过来,给多了显存调度变差 --spec 试 4 / 6 / 8,看并发和单请求 CPU 线程 从 4 试到 9
我扫出来的 --pcie-frac 曲线,给你看看形状:
值 0.00 0.20 0.34 0.55 0.75 tok/s 43.4 47.6 53.2 44.9 36.0
形状应该差不多,峰值在哪得你自己扫。
做法
1. 先跑默认,记个基线 2. 只动 --pcie-frac,扫 5 个点找峰值 3. 再扫 --spec(4/6/8) 4. 最后扫 CPU 线程 5. 每次只动一个变量
有一点要注意:0.1.42 之后引擎会自己测 PCIe 比例。你不填 --pcie-frac 就用它自动的;填了就会覆盖掉自动值。
怎么判断跑得好不好
面板 127.0.0.1:8080 上:
指标 方向 VRAM 命中率 越高越好(我这儿 90%+) PCIe 占比 越低越好(我这儿 3-5%) GPU load 基本 99%
六、用起来要注意的
五条经验
① 一次只派一件事 ← 总吞吐 60 封顶,并行只是把蛋糕切碎 ② max_tokens 每轮倒算 ← 不能沿用上一轮的数 ③ 大目标拆成小步 ← 否则预算烧光 ④ 每步复述约定 ← 长链会漂 ⑤ 门禁和语义断言都要写 ← 门禁只管"没崩"
上下文墙的准确形式
这个坑我踩得最深,形式是这样的:
输入 tokens + max_tokens ≤ 32768
不是「输入 ≤ 32K 」,是「输入 + 输出预算 ≤ 32K 」。
我实测输入 32,716 能过,32,816 就 HTTP 400 了。报错原文写的是 requests are never truncated —— 请求根本发不出去 。
好消息是:失败发生在写盘之前, 上一轮的产物文件是好的 。
我实际翻过的车:
输入 14,781 + max_tokens 18,000 = 32,781 > 32,768 → HTTP 400,请求没发出 降到 17,000 → 立刻正常
所以每轮都要按输入长度重算,不能沿用上一轮拍脑袋的数。
多轮任务可以这么写
[上一轮状态] 已验收:<列出通过项> [本轮只做] <一件事> [不许动] <已验收部分> [预算] max_tokens = 32768 − 预计输入 − 500
七、我把它当什么用
一个手速快的私人助理,使用上有局限性。
适合 长文理解、单文件长输出、agent 单轮任务、单轮代码、中文处理、批量短任务 不适合 高并发、超 32K 输入、精确计数、没人盯着跑的长链
三个数字
输入 + max_tokens ≤ 32768 ← 超了 400,不截断 总吞吐 ≤ ~60 tok/s ← 并发不叠加 max_tokens ≤ 32768 − 输入 − 500
前两条是引擎行为,换硬件也一样;绝对值(76 tok/s 那些)是我这台机器的数,仅供参考。
八、接客户端
协议 端点 OpenAI http://127.0.0.1:8080/v1/chat/completions Anthropic http://127.0.0.1:8080/v1/messages Responses http://127.0.0.1:8080/v1/responses
想给局域网里别的机器用,我建议别开端口,走反向 SSH 隧道:
ssh -R 8080:127.0.0.1:8080 用户名 @目标机 IP
隧道这条路上吞吐跟本机差不多,没打折。
数据可靠性说明
哪些是通用规律、哪些只是我这台机器的数,分一下:
类别 可迁移性 引擎行为(共享窗口 / 并发不叠加 / 超限 400) 换硬件应该一样,但我也只在一台机器上验过 调参方法(倒 U 形、一次动一个) 规律应该通用,峰值位置要自己扫 负优化两项 我实测是负的,建议别开 绝对值 (76 tok/s 、9.2s) 强依赖硬件,只作参考 能力边界(计数会错) 模型本身的问题,换量化档可能变
影响速度的硬件变量,按我理解的重要性排: 内存容量 > PCIe 代数/宽度 > 内存带宽 > 显存 > CPU 核数 。
我这台是 PCIe 3.0,算是明显短板。 如果你的机器是 PCIe 4.0/5.0,速度大概会明显好于本文的数字。
还有一点:我就一台机器、几个晚上的数据, 没有重复多次取统计 ,所以个别数字可能有波动(比如 encode 那项我见过同配置在 59-63 之间飘)。趋势可信,小数位别太当真。
大神项目地址: https://github.com/Niko1221/Strata
资讯来源
V2EX