TGOcc
V2EX  ›  Local LLM

RTX 3080 Ti 12G 跑 125B MoE Qwen3.8-Flash-Next — Strata 安装跟实测

  •  
  •   TGOcc ·
    PRO
    · 6h 42m ago · 1189 views

    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

    11 replies  •  2026-10-13 16:50:26 +08:00
    iorilu
        1
    iorilu  
       6h 38m ago
    机器上开这个还能干其他活吗
    TGOcc
        2
    TGOcc  
    OP
    PRO
       6h 30m ago
    @iorilu 调用时 cpu 占用 50%左右,gpu 快满载了,你开个网页浏览,写个文档还行,干别的重活就不太行了。
    wwhc
        3
    wwhc  
       6h 18m ago
    大家可以再等等,过几个星期,等补丁全落地(MTP/ GPU LRU 缓存的补丁已经 merged),llama.cpp 的性能就追的差不多了,最重要的 llama.cpp 是全量化支持,输出质量远胜 Strata 。如果显存不是太紧缺(多于 16GB),现在 llama.cpp 的速度已经不比 Strata 差太多,而输出质量更好
    iorilu
        4
    iorilu  
       6h 17m ago
    @TGOcc 嗯, 至少这套方法普通显卡本地也能用合适模型了, 不是完全玩具模型
    hanguofu
        5
    hanguofu  
       5h 59m ago via Android
    谢谢分享!能不能把这个 40G 的模型上传到百度网盘?
    qq316107934
        6
    qq316107934  
       5h 49m ago
    上下文 32K 不是硬上限,可以改到 128/256K ,但是会占用特别多的内存。32K 不具备实用性
    uni
        7
    uni  
       5h 42m ago
    @wwhc llamacpp 的代码我看得头疼,本来运行时是运行时,模型特定结构(比如各种缓存等)应该与运行时分离的现在全搅在一起了,六七层继承让人头皮发麻
    realJamespond
        8
    realJamespond  
       5h 13m ago
    q2 算了,q3s128k 3090*2 100t/s pl400
    langhuishan
        9
    langhuishan  
       4h 38m ago
    这个是限定模型+启动程序啊。有没有相同做法跑其他模型的?内存不够。
    jifengg
        10
    jifengg  
       3h 25m ago
    昨天尝试了部署,我这电脑,之前 llama.cpp qwen 3.8 27b q4 ,只能跑 10token/s ,现在用 strata 推荐的 iq3_xxs ,能跑到 50~60token/s 。不过还没看具体的模型能力如何。有时间继续测试。
    hanguofu
        11
    hanguofu  
       8 mins ago via Android
    @jifengg 请问你用的是什么显卡?
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Privacy   ·   Solana   ·   5680 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 62ms · UTC 08:58 · PVG 16:58 · LAX 01:58 · JFK 04:58
    ♥ Do have faith in what you're doing.