没苦硬吃!!3090带着小弟跑Qwen3.8-Flash-Next IQ4双卡实测
-
测试日期:2026-08-29
llama.cpp 版本:b10676 / commit ba29f94da(master HEAD)结论先放
把 Qwen3.8-Flash-Next(
Uncensored-IQ4_XS,97 GB,176B 参数)放在RTX 3090 24G带 RTX 3070 8G 这种非对称双卡上,用 llama.cpp 最新 master build(含 qwen4exp 架构支持),实测四档 context 下来:- Prefill:4K 301 t/s → 16K 266 t/s → 32K 244 t/s → 64K 280 t/s
- Decode:4K 26.1 t/s → 16K 23.2 t/s → 32K 19.6 t/s → 64K 15.2 t/s
- Wall time:4K 灌入+生成 16 秒,64K 灌入+生成 238 秒
- KV Cache 精度:4K / 16K 用 q8_0;32K / 64K 用 q4_0(显存装不下 q8_0)
- 整体判断:在没有 R9700 / 5090 / 4090 的前提下,这台机器能把 176B 量级 MoE + sparse-attn 模型扛住到 64K context;本地日常使用(写代码、聊问答、做长摘要)完全 OK。
1. 测试环境
1.1 硬件一览

项目 型号 / 规格 CPU AMD Ryzen 9 3950X(16C / 32T) 内存 64 GB (实际可用约 60 GB) GPU 0 NVIDIA GeForce RTX 3070(8 GB,sm_86,PCIe 4.0 x16 @ x16) GPU 1 NVIDIA GeForce RTX 3090(24 GB,sm_86,PCIe 4.0 x16 @ x16) 总显存 32 GB(3070 + 3090) 存储 系统 NVMe 4TB 系统 Ubuntu 22.04.5 LTS(kernel 6.8.0-138-generic) NVIDIA 驱动 580.178.04(CUDA 13.0) CUDA toolkit nvcc 12.8.93(驱动兼容构建) 这里要诚实说一句:这是非常不均衡的双卡 —— 一张 8G、一张 24G;而且不是 NVLink。MoE 大模型在两张卡之间按层切的时候,跨卡通信会变成主要瓶颈。但至少比纯 CPU 跑 176B 模型要快很多倍。也试过单张3090加内存跑,真的跑不动,我说的是可以跑起来, 但是跑时间长了就OOM死掉了。
1.2 软件
项目 版本 llama.cpp b10676 / commit ba29f94da(master HEAD,2026-08-28 后) CUDA backend sm_86(RTX 3070 / 3090) cuDNN 驱动自带 Backend ggml-cuda.so 0.22.0 模型
qwen4exp架构在 c1d0e7a00 之前的 llama.cpp 上会直接报unknown model architecture: 'qwen4exp',必须升级到 b10660 之后、最好用 master latest。本次实测就是在自己本地源码重建 ba29f94da 之后做的,libllama.so 含 37 个qwen4exp相关符号。
1.3 模型
项目 规格 模型 Qwen3.8-Flash-Next 量化 IQ4_XS(4.25 bpw) 文件大小 97 GB(3 个 GGUF 分片:44.7 GB + 44.7 GB + 7.9 GB) 参数量 176.94 B(n_params=176943899520) 架构 qwen4exp(sparse attention + MoE + MTP) 词表 n_vocab=248320 嵌入维度 n_embd=2560 2. 实测结果
2.1 主表:4K / 16K / 32K / 64K KV Cache 下的 Prefill 与 Decode
每个数据点跑 3 次(去除冷启动),取 median。
Context (target) Prompt tokens (actual) Prefill t/s (median) Prefill t/s (max / min) Prefill ms/t (median) Decode t/s (median) Decode ms/t (median) 4 096 4 057 301.10 308.07 / 292.41 3.32 26.13 38.28 16 384 16 195 265.95 275.78 / 259.38 3.76 23.15 43.20 32 768 32 617 244.26 274.77 / 217.99 4.09 19.56 51.11 65 536 65 461 280.16 280.20 / 279.82 3.57 15.24 65.60 一个值得注意的事实:Prefill 完全主导长 prompt 的总延迟。即便 64K 下 Decode 慢到 15.2 t/s,单条请求的 64 token 生成只要 4.1 秒;但 Prefill 那 234 秒是真等的。
如果你的工作流是「长文档一次性灌入 + 短追问」,那你应该把眼睛盯在 Prefill 速度上;如果你做的是「多轮对话、每轮都要新生成 200+ token」,那么 Decode 速度才是体验瓶颈。

3. 关键参数
① 不要写
-ngl 99也不要写--split-mode layer --tensor-split 1,3我最初是强制
-ngl 99,直接 cudaMalloc failed out of memory。原因很直白:- 模型 97 GB,两张卡总显存 32 GB,根本不可能全 offload。
- 强制 -ngl 99 让
common_fit_params跳过自动适配,结果某些 expert 层被推到 GPU 0(3070,8 GB)上,单 expert 47 GB 装不下,cudaMalloc 失败。 - 手动
--tensor-split 1,3也不行,因为 expert 层本身太大,不能被拆分。
正确做法:不传-ngl,让 llama.cpp 自动 fit 能上 GPU 的层,剩下的走 CPU + RAM。本地实测是 3070 占 6.5 GB、3090 占 23 GB、CPU 部分约 53 GB 落到系统内存。
② 双卡 + 不对称显存:要打开
--no-mmap默认 mmap 会让 CPU 部分按需从外置硬盘页入。我们的模型在外置
/media/johnnyz/PROG_980/上,mmap + 频繁换页会让速度大幅波动。加--no-mmap(已 deprecated,新写法--load-mode none)一次性预读到 RAM,Prefill 速度更稳定。③ 32K+ 必须把 KV cache 降到 q4_0
Context KV 精度 KV 占用 可行性 4 K q8_0 ~0.2 GB
完全无压力16 K q8_0 ~0.8 GB
OK32 K q8_0 ~1.6 GB
️ 3090 23 GB 还能装下,但多轮后碎片占用会顶到 OOM32 K / 64 K q4_0 ~0.8 GB / ~1.6 GB
跑稳4. 主题深入
4.1 为什么 Decode 比 Prefill 掉得慢?
按理说 Decode 阶段每生成一个 token 都要过整个模型,应该比 Prefill 对 ctx 大小更敏感才对。但实测:
- Prefill:4K → 64K 掉 7%(如果剔除 32K 热降频的噪声)
- Decode:4K → 64K 掉 42%
Decode 才是真的对 ctx 敏感。Decode ms/t 从 38 涨到 66(+73%),符合 KV cache scan 成本线性增长的预期。
这台机器 Decode 慢的真正原因是 MoE 路由的 expert 集中在 GPU 上、但仍需要从 CPU 内存抓其它专家——Flash-Next 是 Q3.8 大改版,专家路由在长 ctx 下触发更频繁,CPU
GPU 数据搬运更多。4.2 64K 反而比 32K Prefill 快的现象分析
32K run 1 32K run 3 64K run 1 64K run 3 GPU temp (估计) 73°C 90°C 70°C 85°C Prefill t/s 274.77 217.99 280.20 280.16 表面看是 64K 比 32K 快。真相:
- 64K 那 3 次 prefills 跑得比较快(每次 ~3.9 分钟),中间 GPU 没空冷
- 32K 那 3 次拖了更久(每次 ~2.2 分钟预填 + 短生成 + 等待间隔),GPU 进入 thermal steady state
- 32K 测量的 noise floor 包含了 thermal throttle
4.3 跨 PCIe 通信开销(推测)
两张 RTX 3070/3090 之间是 PCIe 4.0 x16,跨卡带宽 ~25 GB/s(实际单工 16-20 GB/s)。MoE expert layer 在 3090(装得下大头)+ 3070(小头)之间切换时,每次专家切换都要搬运 hidden state(2560 dim × FP16 = 5 KB),总量随 layer 数线性增长。
5. 还没测的东西
这篇主要是 4K / 16K / 32K / 64K 四档 Prefill + Decode 的单实例单请求测试。还没认真做:
- --parallel 2/4 多并发压力测试(32GB 总显存不够同时两份全 ctx 跑)
- 128K / 262K(原生上下文)下的 Prefill 速度——按 issue #27871 描述,262K 在某些驱动上会 cudaMalloc invalid argument;本机也想验证
- 多轮对话"//////" 退化复现(issue #27797)—— 设
LLAMA_ATTN_ROT_DISABLE=1是否有效 - 不同量化(Q4_K_M / Q5_K_M / Q6_K / Q8_0)的速度与质量取舍
- dflash draft MTP(需要单独下载 ~5 GB 模型)
- Hermes CLI / MCP 接入测试
- GPU 温度严格控制下的 32K vs 64K Prefill 对比
所以这篇更适合当成一份 3950X + RTX 3070/3090 双卡 + Qwen3.8-Flash-Next 的实机配置记录,不是完整 benchmark。当初要买卡的时候,电脑里本来就有3070了,当时的目标卡是4080 32G, 只要9000多块(跟现在的3090一个价钱!),但是想了想24+8 也是32G,于是只买了3090,之前一直跑27B小模型, 只用得到单卡,但是这次是我在本地跑过最大的模型了,勉勉强强能跑下来已经不错,也证明了当初我预测后面会用到24+8的想法,如果只是3090单卡,真的是跑不起来了。
最后的最后, 用 Flash-Next 生成了一个八卦图网站,请老特 @terry 品鉴。

-
@Tony-Wang 我也是同样的感觉, 我生成八卦图的时候, 平均速度达到了 24t/s , 真实可用了。 唯一慢的确实就是prefill, 基本第一次需要3分钟左右, 但是对话起来就快很多了。
-
,
T terry 固定了此主题
-
,系统 取消固定了此主题
-
,J johnnybegood 引用了 此主题
-
测试日期:2026-08-29
llama.cpp 版本:b10676 / commit ba29f94da(master HEAD)结论先放
把 Qwen3.8-Flash-Next(
Uncensored-IQ4_XS,97 GB,176B 参数)放在RTX 3090 24G带 RTX 3070 8G 这种非对称双卡上,用 llama.cpp 最新 master build(含 qwen4exp 架构支持),实测四档 context 下来:- Prefill:4K 301 t/s → 16K 266 t/s → 32K 244 t/s → 64K 280 t/s
- Decode:4K 26.1 t/s → 16K 23.2 t/s → 32K 19.6 t/s → 64K 15.2 t/s
- Wall time:4K 灌入+生成 16 秒,64K 灌入+生成 238 秒
- KV Cache 精度:4K / 16K 用 q8_0;32K / 64K 用 q4_0(显存装不下 q8_0)
- 整体判断:在没有 R9700 / 5090 / 4090 的前提下,这台机器能把 176B 量级 MoE + sparse-attn 模型扛住到 64K context;本地日常使用(写代码、聊问答、做长摘要)完全 OK。
1. 测试环境
1.1 硬件一览

项目 型号 / 规格 CPU AMD Ryzen 9 3950X(16C / 32T) 内存 64 GB (实际可用约 60 GB) GPU 0 NVIDIA GeForce RTX 3070(8 GB,sm_86,PCIe 4.0 x16 @ x16) GPU 1 NVIDIA GeForce RTX 3090(24 GB,sm_86,PCIe 4.0 x16 @ x16) 总显存 32 GB(3070 + 3090) 存储 系统 NVMe 4TB 系统 Ubuntu 22.04.5 LTS(kernel 6.8.0-138-generic) NVIDIA 驱动 580.178.04(CUDA 13.0) CUDA toolkit nvcc 12.8.93(驱动兼容构建) 这里要诚实说一句:这是非常不均衡的双卡 —— 一张 8G、一张 24G;而且不是 NVLink。MoE 大模型在两张卡之间按层切的时候,跨卡通信会变成主要瓶颈。但至少比纯 CPU 跑 176B 模型要快很多倍。也试过单张3090加内存跑,真的跑不动,我说的是可以跑起来, 但是跑时间长了就OOM死掉了。
1.2 软件
项目 版本 llama.cpp b10676 / commit ba29f94da(master HEAD,2026-08-28 后) CUDA backend sm_86(RTX 3070 / 3090) cuDNN 驱动自带 Backend ggml-cuda.so 0.22.0 模型
qwen4exp架构在 c1d0e7a00 之前的 llama.cpp 上会直接报unknown model architecture: 'qwen4exp',必须升级到 b10660 之后、最好用 master latest。本次实测就是在自己本地源码重建 ba29f94da 之后做的,libllama.so 含 37 个qwen4exp相关符号。
1.3 模型
项目 规格 模型 Qwen3.8-Flash-Next 量化 IQ4_XS(4.25 bpw) 文件大小 97 GB(3 个 GGUF 分片:44.7 GB + 44.7 GB + 7.9 GB) 参数量 176.94 B(n_params=176943899520) 架构 qwen4exp(sparse attention + MoE + MTP) 词表 n_vocab=248320 嵌入维度 n_embd=2560 2. 实测结果
2.1 主表:4K / 16K / 32K / 64K KV Cache 下的 Prefill 与 Decode
每个数据点跑 3 次(去除冷启动),取 median。
Context (target) Prompt tokens (actual) Prefill t/s (median) Prefill t/s (max / min) Prefill ms/t (median) Decode t/s (median) Decode ms/t (median) 4 096 4 057 301.10 308.07 / 292.41 3.32 26.13 38.28 16 384 16 195 265.95 275.78 / 259.38 3.76 23.15 43.20 32 768 32 617 244.26 274.77 / 217.99 4.09 19.56 51.11 65 536 65 461 280.16 280.20 / 279.82 3.57 15.24 65.60 一个值得注意的事实:Prefill 完全主导长 prompt 的总延迟。即便 64K 下 Decode 慢到 15.2 t/s,单条请求的 64 token 生成只要 4.1 秒;但 Prefill 那 234 秒是真等的。
如果你的工作流是「长文档一次性灌入 + 短追问」,那你应该把眼睛盯在 Prefill 速度上;如果你做的是「多轮对话、每轮都要新生成 200+ token」,那么 Decode 速度才是体验瓶颈。

3. 关键参数
① 不要写
-ngl 99也不要写--split-mode layer --tensor-split 1,3我最初是强制
-ngl 99,直接 cudaMalloc failed out of memory。原因很直白:- 模型 97 GB,两张卡总显存 32 GB,根本不可能全 offload。
- 强制 -ngl 99 让
common_fit_params跳过自动适配,结果某些 expert 层被推到 GPU 0(3070,8 GB)上,单 expert 47 GB 装不下,cudaMalloc 失败。 - 手动
--tensor-split 1,3也不行,因为 expert 层本身太大,不能被拆分。
正确做法:不传-ngl,让 llama.cpp 自动 fit 能上 GPU 的层,剩下的走 CPU + RAM。本地实测是 3070 占 6.5 GB、3090 占 23 GB、CPU 部分约 53 GB 落到系统内存。
② 双卡 + 不对称显存:要打开
--no-mmap默认 mmap 会让 CPU 部分按需从外置硬盘页入。我们的模型在外置
/media/johnnyz/PROG_980/上,mmap + 频繁换页会让速度大幅波动。加--no-mmap(已 deprecated,新写法--load-mode none)一次性预读到 RAM,Prefill 速度更稳定。③ 32K+ 必须把 KV cache 降到 q4_0
Context KV 精度 KV 占用 可行性 4 K q8_0 ~0.2 GB
完全无压力16 K q8_0 ~0.8 GB
OK32 K q8_0 ~1.6 GB
️ 3090 23 GB 还能装下,但多轮后碎片占用会顶到 OOM32 K / 64 K q4_0 ~0.8 GB / ~1.6 GB
跑稳4. 主题深入
4.1 为什么 Decode 比 Prefill 掉得慢?
按理说 Decode 阶段每生成一个 token 都要过整个模型,应该比 Prefill 对 ctx 大小更敏感才对。但实测:
- Prefill:4K → 64K 掉 7%(如果剔除 32K 热降频的噪声)
- Decode:4K → 64K 掉 42%
Decode 才是真的对 ctx 敏感。Decode ms/t 从 38 涨到 66(+73%),符合 KV cache scan 成本线性增长的预期。
这台机器 Decode 慢的真正原因是 MoE 路由的 expert 集中在 GPU 上、但仍需要从 CPU 内存抓其它专家——Flash-Next 是 Q3.8 大改版,专家路由在长 ctx 下触发更频繁,CPU
GPU 数据搬运更多。4.2 64K 反而比 32K Prefill 快的现象分析
32K run 1 32K run 3 64K run 1 64K run 3 GPU temp (估计) 73°C 90°C 70°C 85°C Prefill t/s 274.77 217.99 280.20 280.16 表面看是 64K 比 32K 快。真相:
- 64K 那 3 次 prefills 跑得比较快(每次 ~3.9 分钟),中间 GPU 没空冷
- 32K 那 3 次拖了更久(每次 ~2.2 分钟预填 + 短生成 + 等待间隔),GPU 进入 thermal steady state
- 32K 测量的 noise floor 包含了 thermal throttle
4.3 跨 PCIe 通信开销(推测)
两张 RTX 3070/3090 之间是 PCIe 4.0 x16,跨卡带宽 ~25 GB/s(实际单工 16-20 GB/s)。MoE expert layer 在 3090(装得下大头)+ 3070(小头)之间切换时,每次专家切换都要搬运 hidden state(2560 dim × FP16 = 5 KB),总量随 layer 数线性增长。
5. 还没测的东西
这篇主要是 4K / 16K / 32K / 64K 四档 Prefill + Decode 的单实例单请求测试。还没认真做:
- --parallel 2/4 多并发压力测试(32GB 总显存不够同时两份全 ctx 跑)
- 128K / 262K(原生上下文)下的 Prefill 速度——按 issue #27871 描述,262K 在某些驱动上会 cudaMalloc invalid argument;本机也想验证
- 多轮对话"//////" 退化复现(issue #27797)—— 设
LLAMA_ATTN_ROT_DISABLE=1是否有效 - 不同量化(Q4_K_M / Q5_K_M / Q6_K / Q8_0)的速度与质量取舍
- dflash draft MTP(需要单独下载 ~5 GB 模型)
- Hermes CLI / MCP 接入测试
- GPU 温度严格控制下的 32K vs 64K Prefill 对比
所以这篇更适合当成一份 3950X + RTX 3070/3090 双卡 + Qwen3.8-Flash-Next 的实机配置记录,不是完整 benchmark。当初要买卡的时候,电脑里本来就有3070了,当时的目标卡是4080 32G, 只要9000多块(跟现在的3090一个价钱!),但是想了想24+8 也是32G,于是只买了3090,之前一直跑27B小模型, 只用得到单卡,但是这次是我在本地跑过最大的模型了,勉勉强强能跑下来已经不错,也证明了当初我预测后面会用到24+8的想法,如果只是3090单卡,真的是跑不起来了。
最后的最后, 用 Flash-Next 生成了一个八卦图网站,请老特 @terry 品鉴。

這兩天把3070 8G 換成了 3080 20G, 果然有比較實質性的提升,結果如下:
Qwen3.8 Flash Next 跑完!完整结果:
场景 r comp TTFT (s) total (s) decode t/s tok/chunk code 1 512 2.481 19.98 29.2 1.00 code 2 512 0.274 14.37 36.3 1.00 en_tech 1 512 1.994 18.72 30.6 1.00 en_tech 2 512 0.277 14.36 36.3 1.00 cn_chat 1 512 1.793 18.64 30.3 1.00 cn_chat 2 512 0.303 14.41 36.2 1.00 cn_essay 1 474 0.702 16.45 30.0 1.01 cn_essay 2 474 0.268 13.24 36.5 1.01 tok/chunk = 1.00:纯 autoregressive(未启用 DFlash2 spec-decode,因为你没传 --spec-type draft-dflash + DFlash2 draft model 路径)。
-
Qwen3.5 122B IQ4_XS (65GB)
场景 r comp TTFT (s) total (s) decode t/s tok/chunk code 1 512 2.035 18.15 31.7 1.00 code 2 512 0.338 15.67 33.3 1.00 en_tech 1 512 1.788 17.68 32.2 1.00 en_tech 2 512 0.335 15.76 33.1 1.00 cn_chat 1 512 1.697 17.06 33.3 1.00 cn_chat 2 512 0.334 15.34 34.0 1.00 cn_essay 1 460 0.478 14.57 32.6 1.01 cn_essay 2 460 0.339 13.91 33.8 1.00 GPU 占用:3090 = 22.7 GB, 3080 = 18.6 GB(41.3 GB 共)— 63% 模型放 GPU
-
换3080是对的。3070这个小弟属实有拖后腿的意思了。
-
Qwen3.5 122B IQ4_XS (65GB)
场景 r comp TTFT (s) total (s) decode t/s tok/chunk code 1 512 2.035 18.15 31.7 1.00 code 2 512 0.338 15.67 33.3 1.00 en_tech 1 512 1.788 17.68 32.2 1.00 en_tech 2 512 0.335 15.76 33.1 1.00 cn_chat 1 512 1.697 17.06 33.3 1.00 cn_chat 2 512 0.334 15.34 34.0 1.00 cn_essay 1 460 0.478 14.57 32.6 1.01 cn_essay 2 460 0.339 13.91 33.8 1.00 GPU 占用:3090 = 22.7 GB, 3080 = 18.6 GB(41.3 GB 共)— 63% 模型放 GPU
@johnnybegood 可以分享你的啟動參數嗎?我想自己借你的啟動參數,用自己的設備實做一次...謝謝
-
@johnnybegood 可以分享你的啟動參數嗎?我想自己借你的啟動參數,用自己的設備實做一次...謝謝
@David-Chen 我让AI帮忙配置的, 忘了看参数了, 不过你可以看我文章 3.关键参数 , 那里面的注意就行了, 其他都是默认。