Qwen3.8-27B，256K，24GB RTX PRO 4000 SFF (432 GB/s)：50 tok/s，使用 MTP

我给了 Qwen3.8 的 MTP 绘图器另外 69.2 MiB 的精度。吞吐量从每秒 50.44 个令牌下降到 37.02 个令牌。该结果总结了整个实验：最好的局部推理设置很少是由单独的“最佳”部分组成的。我想要一个密集的 27B 模型、其完整的 262,144 个令牌上下文、多模式输入、最大的有用质量以及在具有 24 GB VRAM 的 NVIDIA RTX PRO 4000 Blackwell SFF 上的推测解码。在加载打印模型后，服务器还必须能够承受真正的代理工作。这个实验遵循了我之前写过的预感：仔细的操作可能与迁移到更大的模型一样重要。在当前十轮生产系列中，成品系统的平均速度为 50.44 tok/s。在严格的运行时 A/B 上，自定义 llama.cpp 构建达到 55.40 tok/s，而 clean master 为 45.42，提高了 21.97%。与仅目标贪婪解码相比，嵌入式 MTP 的速度从 21.19 tok/s 提高到 59.46 tok/s，即吞吐量的 2.81 倍。在真正占用的 256K 缓存的远端，它仍然产生 12.61 tok/s，而不会出现内存不足故障。这些数字来自不同的大门，应该分开。将它们组合成一个巨大的加速将成为一个更好的标题和一个更糟糕的基准。获胜的设置来自于量化、起草者、CUDA 内核、内存布局和工作负载之间的配合。没有一个组件能够单独获胜。目标是故意不合理的 Qwen3.8 27B 是 64 层密集模型。其重复模式包含三个门控 DeltaNet 层，后跟一个全注意力层，从而提供 48 个循环层和 16 个传统注意力层。它有一个原生的 262,144 个令牌上下文、一个单层 MTP 头和一个单独的 27 层视觉编码器。硬件以一种有用的方式不平衡：GPU0：RTX PRO 4000 Blackwell SFF、带 ECC 的 24 GB GDDR7、192 位内存接口、432 GB/s 峰值内存带宽、24,467 MiB 报告容量和 sm120a。它保存目标、嵌入式 MTP、循环状态、图形和 256K KV 缓存。 GPU1：RTX 2000 Ada、15,996 MiB、sm89。它拥有F16多模态投影仪和其他辅助服务。运行时：Debian 13、CUDA 12.9.86、GCC 14.2、双架构 CUDA 构建。只有 16 个全注意力层会生成具有序列长度的传统 KV 缓存，这使得 256K 不像最初看起来那么荒谬。对于 Q4 K 和 V，在分配器开销之前，该缓存的成本约为 4.25 GiB。 DeltaNet 添加了循环状态和检查点。四个检查点是最少有用的；默认 32 占用了我在其他地方需要的内存。 NVIDIA 给出的峰值带宽为 432 GB/s。这是硬件上限，而不是 llama.cpp 中的应用程序指标，但它在这里很重要。自回归解码重复传输量化权重，并且随着上下文填充，16 个注意力层会添加越来越昂贵的 KV 读取。这就是为什么相同的配置文件在生产任务上平均约为 50 tok/s，在 261.5K 令牌缓存的远端平均约为 12.61 tok/s。最初的计划很简单：估计容量，选择量化，然后对其进行基准测试。机器立即告诉我，容量估算只是入场券。真正的测试在加载后开始。第一个获胜者是 Q4_0，这是我在 40K 上下文中以公共 GGUF 开始的错误获胜者。 Q4_0 出人意料地强劲。 Target-only解码达到22.40 tok/s，n_max=3的MTP达到44.95。它击败了更小的 Q3_K_M 和名义上更智能的 Q4_K_M 变体，因为文件大小和定量标签没有描述实际运行的 CUDA 内核。仅定量目标 MTP n=3 接受 Q3_K_M 17.00 tok/s 31.34 tok/s 83.98% IQ4_XS、iMatrix 20.63 tok/s 34.40 tok/s 64.87% Q4_0 22.40 tok/s 44.95 tok/s 80.40% Q4_K_M 17.57 tok/s 26.15 tok/s 66.86% 然后质量测试破坏了简单的答案。在简短、相同的 WikiText-2 控件上，IQ4_XS 的困惑度得分为 6.1175，而 Q4_0 的困惑度得分为 6.3798。 Q4_0 领先速度表。不过，赫尔墨斯需要一个主要模型，而对于几百毫秒来说，这种高质量的交易感觉太昂贵了。我会使用 27B 模型作为超大自动完成功能。相反的极端也失败了。 Q4_1 达到了 6.1127 PPL，稍微领先于 IQ4_XS，但其内存占用让 256K 加 F16 视觉感到不舒服。有用的一点是介于快速生硬的定量和精确的文件之间，没有为系统的其余部分留下空间。加载 256K 几乎证明不了什么早期的容量测试看起来非常好。 Q4_0、MTP、Q4 KV、四个循环检查点和 F16 投影仪均分配在 262,144 个上下文中。这仍然没有回答我关心的问题。我用 261,500 个输入令牌填充该槽，生成另外 256 个，然后重用热缓存。没有截断。没有OOM。第一个 Q4_0 配置文件在接近缓存末尾时以 12.06 tok/s 的速度解码，而在 40K 左右则为 44.95 tok/s。 GPU 使用率为 99% 到 100%，而服务器大约使用一个 CPU 核心。瓶颈是 16 个全注意力层读取巨大的占用 KV 缓存，而不是秘密的 CPU 回退。这改变了每次运行的基准方法