Qwen3.8-Flash-Next (UD-IQ4_XS) 在 2x RTX 3060 + 7800X3D 上的基准测试：从初始 36 tps 预填充到 400 tps 及其他基准测试（-sm tensor 陷阱）+ VRAM/RAM 使用情况

TL;DR: llama.cpp 使用 --load-mode mmap 占用了 21-32 GB 的 RAM，而 ik_llama.cpp 使用了 106-108 GB。-sm tensor 严重降低了预填充速度，改为 -sm layer 后从 36 tps 提升到 135 tps。之后，-ubatch 2048 在 -c 131072 时将其提升到 400 tps。在 -c 262144 时，-ubatch 2048 无法适应，因此预填充速度上限约为 180-200 tps，解码速度为 12 tps。本地测试初始解码速度为 14-15 tps 后，我遇到了 36 tps 预填充的瓶颈，这对我来说不可用。尝试调整多项设置后仍无法改善，我决定本地运行一系列基准测试，结果令人惊讶，因此决定发布这些结果以供他人参考。所有测试均使用我在 CachyOS 系统上本地编译的 llama.cpp 和 ik_llama.cpp 二进制文件。CUDA 0 使用 16x PCI 通道并拥有全部 12 GB 可用，而 CUDA 1 运行桌面 UI 并通常在 4x PCI 通道上空闲使用 1.5/12 GB。以下内容为 AI 生成的基准测试报告，随后是原始数据。之所以是 AI 生成，因为我不想全部写出来；祝你有美好的一天。 报告：Qwen3.8-Flash-Next UD-IQ4_XS (93.7 GB, 125B MoE / 6B active) 在消费级双 GPU 系统上的基准测试数据，比较 llama.cpp 和 ik_llama.cpp。以下所有内容均在一台机器上单次会话中测量。所有预填充数据来自一个 8k token 的合成提示，cache_prompt: false。 发现 1. -sm tensor 在 llama.cpp 上使预填充速度降低 7 倍。使用 -sm tensor 时为 41.7 t/s，使用 -sm layer 时为 303 t/s，其他条件相同。llama.cpp 将 CPU 上的 MoE 权重在批次大小为 32 或更大时卸载到 GPU，仅复制批次实际使用的专家 (ggml-backend.cpp:1643)。该代码路径针对单设备，因此当 tensor-parallel splitting 分片权重时，它停止应用，每个专家矩阵乘法都回退到 CPU。测量证明：-sm tensor (35 t/s) 和 GGML_OP_OFFLOAD_MIN_BATCH=999999（完全禁用 op-offload）(38 t/s) 给出相同数字。预填充期间的监控： Split mode llama-server CPU GPU0 利用率 GPU1 利用率 预填充 -sm tensor 1191% ~0% ~0% 41.7 t/s -sm layer 139% 49% 38% 135 t/s 2. -ub 是第二个关键参数，但在修复第一个发现之前无效。在 -sm tensor 下，每个测试的 ubatch 值返回相同速度。在 -sm layer 下，相同扫描给出 512 / 1024 / 2048 时为 135 / 191 / 303 t/s。两个修复相乘。单独使用都不够接近。 3. ik_llama.cpp 没有 split-mode 悬崖。在 ik 上 -sm layer 和 -sm graph 测量相同（407 vs 401 t/s）。陷阱是 llama.cpp 特有的。 4. 哪个引擎获胜完全取决于 -ub 2048 是否适配。引擎在 -ub 512 和 -ub 1024 时打平。ik 在 -ub 2048 时有快速路径。 5. ik_llama.cpp 比 llama.cpp 多需要约 75 GB 系统 RAM。相同模型、相同机器、相同标志。llama.cpp 在 --load-mode mmap 下报告使用 21 到 32 GB，可用 93 GB，因为模型页面位于页面缓存中可回收。ik 报告使用 106 到 108 GB，仅 16 到 18 GB 可用。两者都适合 128 GB，但在 96 GB 系统上，这是 ik 能否运行的区别，并且为机器上其他内容留下的余地很小。 引擎 RAM 使用 RAM 可用 测量于 llama.cpp --load-mode mmap 21 到 32 GB 93 GB 行 L, O, V3, LL ik_llama.cpp (默认 mmap) 106 到 108 GB 16 到 18 GB 行 IKM1, IKM2, IKM3 6. 将专家层保留在 VRAM 中不如 ubatch 缓冲区值。-ncmoe 48 / 46 / 44 在 -ub 512 时给出 135 / 139 / 141 t/s。将专家拉入 VRAM 几乎没有收益，并且消耗足够的 VRAM 导致 -ub 2048 内存不足。设置 -ncmoe 48（所有专家在 CPU 上）并将 VRAM 用于 ubatch 计算缓冲区是更好的权衡。 7. 解码受内存带宽限制，没有标志可以修复它。在 128 GB DDR5 以 3200 MT/s 运行（约 40 GB/s 可用）的浅层上下文下为 12 t/s。作为参考，PR 线程报告相同模型在 12 通道 DDR5 EPYC 9555 上为 28 t/s。 8. 额外的并行槽位降低单流速度并增加少量聚合。聚合吞吐量从 1 到 4 个并发槽位大致持平，并且使用 --parallel 8 运行服务器将单流解码从约 12 t/s 降至约 5 t/s。 建议 上下文 引擎 关键标志 预填充 解码 VRAM (GPU0/GPU1) 系统 RAM 最多 131K ik_llama.cpp -sm layer -ncmoe 48 -ub 2048 -b 4096 -fa on 407 t/s 13 t/s 9.2 / 9.1 GB ~108 GB 196K 到 262K llama.cpp -sm layer --n-cpu-moe 48 -ub 1024 -b 4096 --flash-attn on 215 t/s 12 t/s 9.5 / 8.9 GB ~32 GB 如果您的 RAM 少于约 128 GB，请使用 llama.cpp，无论上下文大小。参见发现 5。 两者使用的附加设置：-t 8 -tb 16, -ctk q8_0 -ctv q8_0, -ts 60,40, --parallel 1。 未帮助的设置，均已测量： 设置 结果 -rtr (ik 运行时重新打包) 159 t/s vs 407 t/s。优化 CPU 内核并失去 GPU op-offload -ictk q8_0 (ik 索引器缓存) 速度或 VRAM 无变化。在 262K + -ub 2048 时仍内存不足 -no-fmoe (ik) 399 vs 407 t/s，因此 -fmoe 价值约 2% -ub 4096 在每个测试上下文时内存不足 --threads-batch 8 vs 16 300 vs 303 t/s，一旦 GPU 工作没有显著差异 KV cache q5_1 代替 q8_0 没有释放足够 VRAM 来改变任何结果 降低 -ncmoe 到 46 或 44 在 -ub 512 时 +4 到 +6 t/s，在 -ub 2048 时内存不足 避免在 8 核/16 线程 CPU 上使用 --threads-batch 12。ggml 在每个操作后设置屏障，因此 4 个核心最终运行 2 个线程而 4 个运行 1 个，并且每个操作等待加倍的核心。 测试系统 设备 设备信息 CPU AMD Ryzen 7 7800X3D, 8C/16T, AVX-512 RAM 128 GB DDR5 at 3200 MT/s (4x32 GB; 主板在额定速度下 4 DIMM 无法 POST) GPU0 RTX 3060 12 GB, PCIe 4.0 x16, 直连 CPU GPU1 RTX 3060 12 GB, PCIe 4.0 x4, 在芯片组后，也驱动桌面 (~1.3 GB) OS CachyOS, Linux 7.2.0 模型 unsloth Qwen3.8-Flash-Next-GGUF UD-IQ4_XS, 93.7 GB, 3 分片 架构 48 层: 36 Gated DeltaNet + 12 Qwen Sparse Attention, 512 专家, 262144 原生上下文 llama.cpp 构建 4e97ac86e, CUDA on, GGML_NATIVE=ON, arch 86 ik_llama.cpp 构建 7cff686d (包括 PR #2365 和 #2367 grid-overflow 修复) GPU1 上的 x4 链接已被调查并排除为瓶颈。在慢预填充期间，两个 GPU 利用率接近 0%，因此链接从未饱和。 llama.cpp 结果 上下文 131072, 8k 提示, -b 4096 -t 8 -tb 16 -ctk q8_0 -ctv q8_0, --load-mode mmap。VRAM 是 nvidia-smi 使用量，在服务器加载和基准测试刚完成时采样。RAM 是总系统使用量，包括约 6 GB 桌面。 # -sm -ncmoe -ub -tb 预填充 t/s 解码 t/s GPU0 MiB GPU1 MiB RAM A tensor 40 512 16 41.7 n/a 11541 11267 32G G tensor 48 512 16 35 n/a 6458 6260 31G P layer 48 512 16 38 9 4620 5958 31G C layer 48 512 16 133 n/a 5654 5983 31G L layer 48 512 16 135 10 5656 5974 31G M layer 46 512 16 139 12 5656 9052 31G N layer 44 512 16 141 12 5654 11328 31G LL layer 48 1024 16 191 8 6587 6464 21G U layer 48 2048 8 300 12 7778 8900 31G O layer 48 2048 16 303 12 7778 8902 31G 行 P 是行 L 设置 GGML_OP_OFFLOAD_MIN_BATCH=999999，完全禁用 op-offload。行 A 和 G VRAM 是在运行中实时采样，而非测试结束时。 上下文 262144 # -sm -ncmoe -ub -ts 预填充 t/s 解码 t/s GPU0 MiB GPU1 MiB RAM V3 layer 48 1024 60,40 215 12 9478 8925 32G llama.cpp 未能加载的配置 # ctx -sm -ncmoe -ub -ts 失败 B/D/E 131072 layer 40 512 51,49 OOM, 设备 1 上 12281 MiB S 131072 layer 46 2048 51,49 OOM, 设备 1 上 3888 MiB T 131072 layer 44 2048 51,49 OOM, 设备 1 上 3888 MiB R 131072 layer 48 4096 51,49 OOM, 设备 1 上 7776 MiB V 262144 layer 48 2048 51,49 OOM, 设备 1 上 7216 MiB V1 262144 layer 48 2048 70,30 OOM, 设备 0 上 6920 MiB V2 262144 layer 48 2048 60,40 OOM, 设备 1 上 7200 MiB (KV at q5_1) ik_llama.cpp 结果 上下文如所述, 8k 提示, -ncmoe 48 -b 4096 -t 8 -tb 16 -ctk q8_0 -ctv q8_0 -fa on -ts 60,40。 # ctx -sm -ub 额外 预填充 t/s 解码 t/s GPU0 MiB GPU1 MiB RAM IK8 131072 layer 512 136 8 IKM3 131072 layer 512 重跑