花了3天在搭载40GB显存笔记本+TB4外置显卡的独特组合上，对llama.cpp的各类标志参数进行基准测试。最终实现：生成速度提升70%、预填充速度提升40%、上下文容量增加6万token，并向llama项目提交了关于MTP的技术问题报告。以下是实践中的关键发现。

摘要：生成速度从约16~27个token/秒，无需任何牺牲便将可用上下文从220k提升至完整的262k，预填充速度也从376提升到573。附上我最终使用的命令供参考：`llama-server -m Qwen3.8-27B-UD-Q6_K_XL.gguf -c 262144 -ngl 999 -fa on \ -ctk q8_0 -ctv q8_0 --spec-type draft-mtp,ngram-map-k4v --spec-draft-n-max 3 \ --spec-draft-device CUDA0 --split-mode layer -dev CUDA0,Vulkan2 -ts 40,60 \ --jinja -fitt 256` 请注意我的配置有些特殊。P1 Gen 6（一台RTX 4090笔记本，实质是运行在95~W功耗限制下的4080芯片，配备16GB显存，带宽约536GB/s）+ XTX 7900，通过雷电4连接AG02显卡扩展坞。笔记本是我闲置的，因此这是以最低成本获得40GB显存并以Q6_K_XL量化完整上下文运行Qwen的方案。总体而言，我对这套配置非常满意且印象深刻。 一些相关问题： **两张卡之间的性能差距有多大？** 这比你想象的更有趣。我原本以为如果减少上下文比例、让XTX承担更多分割任务会带来巨大收益，结果发现它们实际平衡得非常好。 - 预填充：在22k冷启动提示下，4090快34%。 - 预填充，7B模型@深度0：4090快82%？惊人。 - 无推测解码生成：XTX快27%。 - 生成，7B模型@深度0：XTX快23%。 - 启用MTP（推测解码）生成：XTX快72%。 - 深度生成，7B模型@98k深度：XTX快2.5倍。 所以，XTX是更强大的解码机器，即使在雷电4下也是如此。但差距并没有想象中那么夸张，而4090在预填充上的优势弥补了相当多的差距。 另外，生成时那个巨大的MTP差距？我相当确定是个bug，已经提交了issue。发现尽管如此，MTP仍为我带来了25%的净增益，但启用MTP后我的预填充速度从900多降到500多。这似乎仅发生在多GPU情况下，测试发现单卡（包括4090在Vulkan或NVIDIA驱动下）均无此惩罚。已提交issue，希望没有闹笑话：https://github.com/ggml-org/llama.cpp/issues/27428 总之，如我所说：通过减少上下文并尝试比自然的40/60分割更多地使用XTX，性能提升仅约3%或更少。这点提升不值得牺牲上下文容量。**雷电4的性能损耗有多大？** 并不像乍看那么糟。如果你手头有雷电4设备，那就用它。进行层分割时，理论上我可以在这套配置上达到接近1000个预填充token/秒（因发现的bug暂未使用MTP），运行Qwen 27B Q6_K_XL。雷电4带宽为40Gbps，延迟仅0.025毫秒（四分之一毫秒），这是我测试两台电脑间雷电4连接延迟时的数据（且包含了ping本身的延迟）。我猜想你不会使用张量并行（我还未能测试，需要NVIDIA显卡），但这套方案比我卖掉笔记本买服务器等（虽然我最终可能还是会买）要简单得多。 顺便问下：你试过RPC吗？llama.cpp现在支持这个，很酷。我最初有两台类似配置的笔记本，一台带16GB显存的3080和现在的4090。卖了3080买AG02和XTX。但当我同时拥有它们时，我尝试通过将3080机器设为RPC节点并用雷电4连接两台笔记本（雷电4网络很棒，但很难找到两台主板兼容的机器；不过千兆和万兆以太网也行，即使局域网WiFi我也得到了惊人可用的结果）运行（当时的）3.6版27B Q5模型配合262k上下文。得到的token/秒速度非常可用，令我惊叹。由于没有详细的基准测试设置，我无法提供很多数据，只是想分享一下。 回到我当前的配置。这是AI在经过三天密集基准测试后生成的表格（值得一提的是，我积极参与了测试过程；其中一些结论若非我基于实际理解提出思路，Claude自己无法得出），“调节旋钮”（Claude喜欢这么称呼）带来的增益说明如下： - `--spec-type draft-mtp,ngram-map-k4v`（所有默认值）：生成速度+50–70%（17→26-28；复制密集型请求在100%接受率下飙升至85 t/s）但...在我配置中预填充速度减半，大吃一惊。值得，因我工作负载中77%时间是生成。 - NVIDIA卡使用CUDA后端，AMD使用Vulkan（`-dev CUDA0,Vulkan2`）：预填充无推测时+28%，有推测时+41%（376→532）。最初都用Vulkan运行，感觉接近，深度测试显示4090用NVIDIA驱动有优势。需要AI帮助我跑通，但值得。（附注：CUDA的q8_0-KV解码在密集模型上随深度下降-50%，混合SSM模型则没问题） - `--spec-draft-device CUDA0`：预填充+8%（532→573）。这是我最后一次测试试图寻找MTP预填充惩罚根源时的小发现。不错。 - 将llama.cpp重建为两周后的新版本：生成速度免费+13%（25.0→28.3，配置完全相同）。起初我做了各种小调整...重建后这些调整都变得无用，而增益现在内置为免费提升。呵呵。 - UD-Q6_K_XL 相比 Q8_0：生成+9%，上下文+3GB，预填充相当（仅限CUDA——在Vulkan上，Q8预填充快12%，因K-quant反量化在RADV上昂贵，在CUDA上免费）。嗯。但无论如何，我在Q6上获得了262k上下文，用Q8则会牺牲，但仍值得测试。 - q8_0 KV缓存 262k上下文 vs ~190k：注意这运行更慢。我之前不知道。显然在llama-bench中深度预填充-23%/生成-9%，但在实际服务器中仅预填充-7.5%；取上下文`-ts 40,60`（按显存比例）基线±5点移动约2%；不值得牺牲上下文（如果我调整这些数字就必须牺牲）。262k上下文意味着4090几乎100%满，XTX也接近满载。 **我尝试过但无效的操作：** - 尝试：结果 - `-ub 1024 / 2048`（经典的“提高预填充的批处理大小”）：预填充-13% / -31%。这显然在单卡时有帮助，但我发现在我多GPU层分割中适得其反。较小块在跨卡管道中更佳。于是我尝试调小，但更新至最新版后此优势消失。 - `-b 4096`：在llama-bench中+9%，在实际服务器中正好0%。采用任何优化前请先在生产环境路径上测试...当时以为发现了什么。 - ngram调优（min-hits、draft length M、p-min）：在旧版本上+17%；重建后，所有增量均坍缩为噪声。上游重构吸收了调节旋钮带来的收益。我曾感觉很专业，但当这些功能开箱即用时我们都会受益，所以很好。 - `ngram-mod`（自适应ngram）：生成-17%。 - 为我确切模型训练的DSpark草稿头：1–5%接受率（GGUF标签错为dflash），33%强制为dspark——仍比MTP+ngram慢3倍。看来训练的草稿模型尚未即插即用。唉。 - `-sm row`：在我此配置上不可行。等有3090时会测试看看。 - 混合KV类型（`-ctk q8_0 -ctv f16`或镜像）：预填充崩溃4–13倍——静默内核回退；KV类型必须匹配。彻底失败。试图弥补q8 k/v损失的尝试。 - `-fa 0`：无法启动：量化KV需要Flash Attention。AI曾告诉我这在NVIDIA上唯一，但实际上Vulkan也支持。有趣。 - 在Windows上提高80W功耗限制，顺便提一下，我观察到这张卡在游戏中最高维持135W~。在Linux下似乎限制在95W。但说实话，我看了很久遥测图。这张卡在此配置下不受功耗限制——算力并非瓶颈。 - 全Vulkan配对（在MTP发现后重新测试）：376 vs 532预填充（带推测栈）；生成相当。CUDA在此卡上仍有优势。 - `--fitt 256`：尝试262k上下文时遇到“显存不足”，使用此参数后解决，但仍可见两张卡各有1-2+GB空闲显存。添加后，问题消失。 **如果你尝试基准测试，沿途一些陷阱在此列出，仅供参考...**