我为 Qwen3.8 的 MTP 起草者增加了 69.2 MiB 的精度。吞吐量从每秒 50.44 个 token 降至 37.02 个 token。这个结果总结了整个实验：最佳的本地推理设置通常不是由各自 "最佳" 的部分构成的。我想要一个密集的 27B 模型，它完整的 262,144-token 上下文、多模态输入、最大有效质量和在 24 GB VRAM 的 NVIDIA RTX PRO 4000 Blackwell SFF 上进行的推测解码。服务器还必须在打印模型加载后继续进行实际代理工作。这个实验遵循了我之前写过的直觉：小心操作可能和迁移到更大模型一样重要。现成的系统在当前的十次运行生产系列中平均每秒 50.44 个 token。在严格的运行时 A/B 测试中，定制的 llama.cpp 构建达到了 55.40 个 token/s，而干净的主版本为 45.42，提升了 21.97%。与目标唯一贪婪解码相比，嵌入式 MTP 的吞吐量从 21.19 提高到 59.46 个 token/s，增幅为 2.81 倍。在真实占用的 256K 缓存的远端，它仍能在没有内存溢出失败的情况下产生 12.61 个 token/s。这些数字来自不同的门，应该保持分开。将它们结合成一个英雄般的加速会使标题更好，但基准更差。获胜的设置来自于量化、起草者、CUDA 内核、内存布局和工作负载之间的适配。没有任何组件能够单独获胜。目标是故意设定的不合理。Qwen3.8 27B 是一个 64 层的密集模型。它的重复模式包含三个门控 DeltaNet 层，后跟一个全注意力层，形成了 48 个递归层和 16 个常规注意力层。它有原生的 262,144-token 上下文、一个层的 MTP 头和一个独立的 27 层视觉编码器。硬件在有用的方面是不平衡的：GPU0: RTX PRO 4000 Blackwell SFF，24 GB GDDR7 带 ECC，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 个 token/s，而在 261.5K-token 缓存的远端则为 12.61 个 token/s。最初的计划很简单：估算容量，选择量化，然后基准测试。机器立即教会我容量估算只是入场券。真正的测试在加载后开始。第一个赢家是 Q4_0，而我是从公用 GGUFs 以 40K 上下文开始的错误赢家。Q4_0 的实力令人惊讶。目标唯一解码达到了 22.40 个 token/s，而 MTP 在 n_max=3 时达到了 44.95。它超越了更小的 Q3_K_M 和名义上更聪明的 Q4_K_M 变体，因为文件大小和量化标签并不能描述实际运行的 CUDA 内核。量化目标仅 MTP n=3 接受度：Q3_K_M 17.00 token/s 31.34 token/s 83.98% IQ4_XS，iMatrix 20.63 token/s 34.40 token/s 64.87% Q4_0 22.40 token/s 44.95 token/s 80.40% Q4_K_M 17.57 token/s 26.15 token/s 66.86% 然后质量测试破坏了简单的答案。在一段短的、相同的 WikiText-2 控制中，IQ4_XS 得分为 6.1175 困惑度，而 Q4_0 得分为 6.3798。Q4_0 在速度表上领先。然而，Hermes 需要一个主要模型，而这个质量的权衡对于几百毫秒来说感觉太昂贵。我本会使用一个 27B 模型作为过大的自动完成功能。相反的极端也失败了。Q4_1 达到了 6.1127 PPL，轻微领先于 IQ4_XS，但它的内存占用使 256K 加上 F16 视觉变得不舒服。有用的点在于某个快速钝化量化和一个留下其他系统没有余地的精确文件之间。加载 256K 几乎没有什么证明。早期容量测试看起来很出色。Q4_0、MTP、Q4 KV、四个递归检查点和 F16 投影器都在 262,144 上下文中分配。这仍然没有回答我关心的问题。我填充了 261,500 个输入 token 的插槽，生成了另外 256 个，然后重用热缓存。没有截断。没有 OOM。第一个 Q4_0 配置在缓存的末尾以 12.06 个 token/s 解码，与 40K 附近的 44.95 相比。GPU 使用率在 99% 至 100% 之间，而服务器大约使用了一个 CPU 核心。瓶颈在于 16 个全注意力层读取一个巨大占用的 KV 缓存，而不是一个秘密 CPU 回退。这改变了每次运行的基准方法。