基准测试新b9200更新：在单张RTX 3090上为Hermes Agent优化Qwen 3.6 27B mtp

**更新（b9200之后）** 好的，现在使用来自unsloth的qwen 3.6 27B mtp gguf作为Hermes Agent的后端。在调试过程中，我发现当前推荐的unsloth mtp标志实际上会形成瓶颈，并在严格的多轮代理工作流中降低草稿接受率。将自定义配置与今天全新的llama.cpp b9200版本（专门修复了mtp内存流量开销）搭配使用，完全扭转了这一局面。 硬件/软件 * RTX 3090（24GB显存）——当前已降压以保持低温 * Ryzen 7 5700G / 64GB * Qwen3.6-27B-IQ4_NL.gguf * llama-server（b9200+从源代码编译，提交#23234） * hermes agent（64K上下文）限制最大值以减少溢出 运行标准的推荐mtp标志（--spec-draft-n-max 6 和 --spec-draft-p-min 0.75）在代理循环中效果不佳。生成速度约为7–8 t/s，mtp草稿接受率徘徊在22–26%左右。代理工作流是刚性的。6个令牌的预判经常猜错标点符号，主模型拒绝草稿，GPU抛弃数学计算并重新计算——完全抵消了mtp的速度提升。如果不显式声明并行槽位，llama-server默认使用4个，这会消耗内存带宽来管理未使用的上下文槽位。 修复与b9200的加速 对于24GB显卡上的代理工作流，限制为单个槽位，将预判降至3，并移除p-min阈值，使其在刚性语法上不再犹豫。结合b9200版本（该版本在提示处理期间停止为批次中的每个令牌复制完整的logits），优化后的启动命令如下： `.\build\bin\Release\llama-server.exe ^ -m D:\models\Qwen3.6-27B-IQ4_NL.gguf ^ --spec-type draft-mtp ^ --spec-draft-n-max 3 ^ --ctx-size 65536 ^ --parallel 1 ^ --flash-attn on ^ --cache-type-k q8_0 ^ --cache-type-v q8_0 ^ --port 8081` 结果（更新前 vs b9200后） 更新前（但使用了优化标志）： * 提示处理速度约为~560 t/s。 * 令牌生成为：短任务上达到**17.06 t/s**，繁重上下文推理循环中为~9.5 t/s。 * 草稿接受率攀升至**77%**（证明较短的预判在严格格式下效果更好）。 b9200更新后： * 提示处理速度跃升至**991+ t/s**。内存流量修复加上--parallel 1让3090能够快速处理Hermes的大量系统提示。 * 令牌生成为：短任务峰值**27.44 t/s**，在繁重上下文循环（代理在工具调用和主内存之间切换）中稳定在高度可用的13.69 t/s。 * 草稿接受率在标准轮次中保持在**~70%**。当你的显存总线没有被幽灵并行槽位或6令牌预判拒绝堵塞时，一块***降压***的3090仍然可以在密集的27B模型上推动近30 t/s。