测试方法：DeepSeek驱动hermes执行本地测试
测试日期：2026.05.26
备注：以下结果是AI生成，最终测试结果3080双卡的上限也就是53t/s了，供大家参考
1. 硬件环境
| 组件 | 型号 |
|---|---|
| CPU | Intel Ultra 7 265K（20核，5.4GHz） |
| 主板 | ASUS PRIME Z890-P WIFI |
| 内存 | 96GB DDR5 5600MHz（Corsair 2×48GB） |
| GPU | 2× NVIDIA RTX 3080 20GB（独立，非 SLI，共 40GB VRAM） |
| 系统 | WSL2 Ubuntu 24.04（Windows 11 宿主） |
2. 软件环境
| 项目 | 版本/配置 |
|---|---|
| llama.cpp | commit 95405ac（CUDA 后端，MTP 支持） |
| 编译参数 | GGML_CUDA=ON GGML_CUDA_FA=ON |
| 模型 | Qwen3.6-27B-Q4_K_M.gguf（16GB，Q4_K_M 量化） |
| CUDA | 默认 (WSL2 驱动直通) |
3. 测试方法
- 固定 prompt：64 token 中文问题（Transformer 架构介绍）
- 生成：200 token 输出
- 每次测速前冷加载模型（重启服务器），避免 KV cache 热缓存影响结果
- 温度
--temp 0，保证确定性输出 - 通过 llama-server 返回的
timings.predicted_per_second和timings.prompt_per_second记录速度
4. 测试结果
4.1 基线配置
CUDA_SCALE_LAUNCH_QUEUES=4 ./llama-server \
-m Qwen3.6-27B-Q4_K_M.gguf -ngl 99 \
--host 127.0.0.1 --port 8082 -c 131072 --temp 0 \
--spec-type draft-mtp --spec-draft-n-max 3 \
--ubatch-size 1024 --batch-size 2048 \
-fa on -ctk q4_0 -ctv q4_0
| 指标 | 数值 |
|---|---|
| Prompt 处理速度 | 34.66 tok/s |
| 生成速度 | 52.79 tok/s |
| VRAM（GPU0 / GPU1） | 13.6 GB / 17.6 GB |
4.2 测试 A：调整 tensor-split
... --tensor-split 4,5
| 指标 | 数值 | 变化 |
|---|---|---|
| Prompt 处理速度 | 33.89 tok/s | -2.2% |
| 生成速度 | 52.27 tok/s | -1.0% |
| VRAM（GPU0 / GPU1） | 12.5 GB / 17.2 GB | 更均衡 |
结论：
--tensor-split平衡了显存，但对速度无明显帮助。llama.cpp 的默认 layer 分载已经较优。
4.3 测试 B：增大 MPT 推测数量
... --spec-draft-n-max 5
| 指标 | 数值 | 变化 |
|---|---|---|
| Prompt 处理速度 | 34.47 tok/s | -0.5% |
| 生成速度 | 50.96 tok/s | -3.5% |
| VRAM（GPU0 / GPU1） | 14.1 GB / 16.9 GB |
结论：
--spec-draft-n-max从 3 提高到 5 反而变慢。原因推测：Qwen3.6-27B 的 MTP 接受率在第 3 个 token 后饱和，多余草稿 token 浪费了计算量。
4.4 测试 C：MTP + ngram 组合推测
... --spec-type draft-mtp,ngram-mod \
--spec-ngram-mod-n-max 5 --spec-ngram-mod-n-min 3
| 指标 | 数值 | 变化 |
|---|---|---|
| Prompt 处理速度 | 36.42 tok/s | +5.1% |
| 生成速度 | 53.02 tok/s | +0.4% |
| VRAM（GPU0 / GPU1） | 13.4 GB / 16.3 GB |
结论：MTP + ngram 组合对生成速度有小幅提升，ngram 在重复性高的文本（代码、列表）中效果更好，普通文本中与 MTP 独立效果接近。
4.5 测试 D：增大 ubatch-size
... --ubatch-size 2048
| 指标 | 数值 | 变化 |
|---|---|---|
| Prompt 处理速度 | 45.51 tok/s | +31.3%  |
| 生成速度 | 52.49 tok/s | -0.6% |
| VRAM（GPU0 / GPU1） | 16.1 GB / 17.2 GB |
结论：<u>这是本次测试最重要的发现</u>。
--ubatch-size 2048让 prompt 处理速度暴涨 31%，但生成速度几乎不变。原因分析：ubatch 增大后，GPU 在 prefill 阶段一次处理更多 token，kernel 启动开销摊分到更多 token 上，计算吞吐大幅提升。而自回归生成阶段 batch 天然为 1，不受 ubatch 影响。显存从 13.6G 升至 16.1G（GPU0），仍在 20GB 安全范围内，未 OOM。
4.6 测试 E：增大 CUDA 队列
CUDA_SCALE_LAUNCH_QUEUES=8 ...
| 指标 | 数值 | 变化 |
|---|---|---|
| Prompt 处理速度 | 34.09 tok/s | -1.6% |
| 生成速度 | 52.56 tok/s | ≈持平 |
| VRAM（GPU0 / GPU1） | 13.6 GB / 17.6 GB |
结论：单用户场景下 CUDA 队列翻倍无显著收益。
CUDA_SCALE_LAUNCH_QUEUES=4已足够。
4.7 测试 F（最优组合）：ubatch-2048 + MTP+ngram
CUDA_SCALE_LAUNCH_QUEUES=4 ./llama-server \
-m Qwen3.6-27B-Q4_K_M.gguf -ngl 99 \
--host 127.0.0.1 --port 8082 -c 131072 --temp 0 \
--spec-type draft-mtp,ngram-mod \
--spec-draft-n-max 3 \
--spec-ngram-mod-n-max 5 --spec-ngram-mod-n-min 3 \
--ubatch-size 2048 --batch-size 2048 \
-fa on -ctk q4_0 -ctv q4_0
| 指标 | 数值 | 变化 |
|---|---|---|
| Prompt 处理速度 | 50.17 tok/s | +44.7%  |
| 生成速度 | 53.18 tok/s | +0.7% |
| VRAM（GPU0 / GPU1） | 16.1 GB / 17.2 GB |
5. 结果汇总
| # | 测试项 | Prompt (tok/s) | 生成 (tok/s) | Prompt 提升 |
|---|---|---|---|---|
| 基线 | 当前配置（MTP3 + ubatch1024） | 34.66 | 52.79 | — |
| A | --tensor-split 4,5 |
33.89 | 52.27 | -2.2% |
| B | --spec-draft-n-max 5 |
34.47 | 50.96 | -0.5% |
| C | --spec-type draft-mtp,ngram-mod |
36.42 | 53.02 | +5.1% |
| D | --ubatch-size 2048 |
45.51 | 52.49 | +31.3% |
| E | CUDA_SCALE_LAUNCH_QUEUES=8 |
34.09 | 52.56 | -1.6% |
| F | ubatch2048 + MTP+ngram（最优） | 50.17 | 53.18 | +44.7% |
6. 结论与建议
最优启动命令
CUDA_SCALE_LAUNCH_QUEUES=4 /home/simon/llama.cpp/build/bin/llama-server \
-m /path/to/Qwen3.6-27B-Q4_K_M.gguf \
-ngl 99 --host 127.0.0.1 --port 8082 -c 131072 --temp 0 \
--spec-type draft-mtp,ngram-mod \
--spec-draft-n-max 3 \
--spec-ngram-mod-n-max 5 --spec-ngram-mod-n-min 3 \
--ubatch-size 2048 --batch-size 2048 \
-fa on -ctk q4_0 -ctv q4_0
关键发现
-
--ubatch-size 2048是最大的单一优化点，prompt 处理速度提升 31-45%。这个参数在大多数 llama.cpp 教程中维持默认值 512 或保守的 1024，但在 40GB VRAM 的双卡配置上可以安全升到 2048，无需担心 OOM。 -
MTP 推测解码的 draft-n-max 不宜过大，3 个草稿 token 是 Qwen3.6-27B 的最佳值。更大的值（5）会降低速度，因为草稿接受率在第 3 个 token 后已经饱和。
-
双卡显存天然不均衡。默认 layer 分载下，GPU 0 占 13.6GB，GPU 1 占 17.6GB（相差 4GB）。
--tensor-split可以平衡显存，但对速度无明显影响。 -
生成速度存在上限。双 RTX 3080 对 Qwen3.6-27B（Q4）的生成速度天花板约 53 tok/s，受限于 Ampere 架构的 FP16 计算能力和 PCIe 带宽。纯粹的自回归生成阶段，GPU 利用率天然不高。
-
prompt 处理（prefill）才是双卡配置的主要优化发力点——因为 prefill 阶段可以利用 batch 并行度和两卡的全部算力，而自回归生成只能串行。
适用建议
长上下文 / 长 prompt 场景：优先采用方案 F，prefill 速度提升极大改善首 token 延迟- 短对话 / 流式场景：方案 F 仍是最优，但提升主要体现在首 token 延迟上
- 低于 20GB VRAM 的单卡：不建议直接套用 ubatch-size 2048，需要根据显存余量逐步尝试（1024 → 2048，我自己设置的是1280，没有任何OOM报错）
