测试日期：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 硬件一览

这里要诚实说一句：这是非常不均衡的双卡 —— 一张 8G、一张 24G；而且不是 NVLink。MoE 大模型在两张卡之间按层切的时候，跨卡通信会变成主要瓶颈。但至少比纯 CPU 跑 176B 模型要快很多倍。也试过单张3090加内存跑，真的跑不动，我说的是可以跑起来， 但是跑时间长了就OOM死掉了。

1.2 软件

模型 qwen4exp 架构在 c1d0e7a00 之前的 llama.cpp 上会直接报 unknown model architecture: 'qwen4exp'，必须升级到 b10660 之后、最好用 master latest。本次实测就是在自己本地源码重建 ba29f94da 之后做的，libllama.so 含 37 个 qwen4exp 相关符号。

1.3 模型

2. 实测结果

2.1 主表：4K / 16K / 32K / 64K KV Cache 下的 Prefill 与 Decode

每个数据点跑 3 次（去除冷启动），取 median。

一个值得注意的事实：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	OK
32 K	q8_0	~1.6 GB	️ 3090 23 GB 还能装下，但多轮后碎片占用会顶到 OOM
32 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 下触发更频繁，CPUGPU 数据搬运更多。

4.2 64K 反而比 32K Prefill 快的现象分析

表面看是 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 品鉴。