Qwen3.8-Flash-Next在llama.cpp vs SGLang vs FreeToken中的比较：完整上下文下首token时间从35秒到258秒。我对即将引入引擎的新PR的研究发现。

大家好，在我将CPU-only测试扩展到96GB显存后，我在同一工作站上测试了Qwen3.8-Flash-Next在llama.cpp、SGLang和FreeToken上的表现。这次我想看看当硬件和模型家族固定但引擎、权重格式和内存放置改变时会发生什么变化。我还测试了较新的构建、PR补丁和推测解码：llama.cpp的MTP分支、SGLang的Blackwell支持补丁、n-gram推测和一个实验性PLE读取路径构建。简而言之：在完整的262K窗口中，首token时间在SGLang中为35.4秒，FreeToken中为80.4秒，llama.cpp + MTP中为210.2秒，llama.cpp基线中为258.4秒。最快和最慢配置之间的等待时间相差7.3倍。在单独的上下文扫描中，llama.cpp解码速度从101.9降至20.2 token/秒。FreeToken保持更平稳，从100.1到94.8 token/秒。在匹配的编码测试中，llama.cpp MTP在8K时将解码提高了1.63倍，在32K时提高了1.69倍。GSM8K分数为95.22–95.75%；MATH-500为92.20–93.00%。配对测试未检测到显著差异。启动时间则相反：llama.cpp在16秒内得到答案，SGLang在108秒，FreeToken在126秒。https://preview.redd.it/ztjuce0wfcoh1.png?width=1725&format=png&auto=webp&s=fe8f9db72829e04d9f338e0cfab373129c049740 设置 GPU：NVIDIA RTX PRO 6000 Blackwell，96GB显存 CPU：AMD Ryzen 9 9950X 系统内存：96GB DDR5 操作系统：Ubuntu，CUDA 13，Docker 模型：Qwen3.8-Flash-Next llama.cpp：UD-IQ4_XS GGUF；MTP在qwen4exp/mtp分支上测试 SGLang和FreeToken：相同的NVFP4检查点版本 客户端：AIPerf，思考关闭，使用相同的非思考采样器 我一次运行一个引擎，每次都是全新启动并冷却GPU。运行保存了已解析配置、输出、内存使用和GPU遥测数据。 关于比较的重要说明 这些是该工作站上测试堆栈的结果。量化、KV缓存格式、内存放置和推测解码各不相同。SGLang使用其NEXTN草稿头。FreeToken在测试设置中没有推测解码，我无法使其工作。llama.cpp有单独的基线和MTP结果。因此，标题并非仅隔离引擎软件。存储库包含配置，因此您可以看到每个数字的产生方式。 测试的新构建、PR和推测解码 llama.cpp MTP：danielhanchen/llama.cpp qwen4exp/mtp分支，固定在d1a92352，带有大约2.6GB的草稿头。在匹配的编码测试中，解码在8K时提高了1.63倍，在32K时提高了1.69倍。这些增益比较了同一构建在头部关闭和开启时的情况。 SGLang on Blackwell：测试的镜像包含PRs #36567、#36556、#36749和#36750，以及本地FP8 KV缓存补丁。这些是工作配置的一部分，而非单独基准测试的加速。 N-gram推测：ngram-mod在测试代码工作负载中将解码提高了+6.8%，但在24 token匹配设置下，对测试散文生成了零草稿。 实验性PLE读取：我构建了llama.cpp PR #28136，但在发现一个重命名的标志被忽略后，撤回了读取模式比较。预期的直接读取模式从未被使用，因此我不声称从该PR获得加速。报告记录了固定构建和撤回的发现以及成功测试。 1. 所有四种配置都适合完整窗口。等待时间大不相同。此测试使用大约261,500个输入token和在262,144 token窗口内的128个token答案。各配置的接受输入计数相差两个token。 配置 首token时间 解码速度 SGLang 35.4秒 126.9 token/秒 FreeToken 80.4秒 87.5 token/秒 llama.cpp + MTP 210.2秒 52.6 token/秒 llama.cpp基线 258.4秒 20.3 token/秒 从四分钟以上到大约35秒改变了大型提示的可用感。两列测量不同的内容：首token时间是初始等待；解码是之后答案到达的速度。 2. 短提示测试错过了长上下文行为。单独的散文扫描使用2,048 token答案和每个输入长度三个测量请求。 https://preview.redd.it/x7dnlip1gcoh1.png?width=1575&format=png&auto=webp&s=80ead02fdc3287683f58526906fd259bfa58c4b6 配置 在2K输入下的解码速度 在259,584输入下的解码速度 SGLang 182.7 token/秒 191.5 token/秒 FreeToken 100.1 token/秒 94.8 token/秒 llama.cpp + MTP 126.8 token/秒 61.4 token/秒 llama.cpp基线 101.9 token/秒 20.2 token/秒 预填充也改变了排名。FreeToken在2K输入时落后于llama.cpp：1,525 vs 1,869 token/秒。在128K时，它达到3,231 vs 1,362 token/秒，大约快2.4倍。 3. MTP帮助了llama.cpp，但它没有消除长提示等待。在真实的编码提示上，比较同一分支构建在草稿头关闭和开启时的情况： https://preview.redd.it/cbj78fx5gcoh1.png?width=1425&format=png&auto=webp&s=f66cb331d46ba455774bd6e1e2aa282bb01c3419 输入 MTP关闭 MTP开启 解码增益 8,192 tokens 94.9 token/秒 155.1 token/秒 1.63x 32,000 tokens 83.1 token/秒 140.4 token/秒 1.69x 草稿头大约2.6GB。在完整窗口中，测试的MTP配置达到52.6 token/秒，而基线配置为20.3 token/秒。这是2.59倍的差距，但完整窗口比较还涉及不同的构建。上述匹配构建的编码测试更清晰地隔离了草稿头的变化。我不会将258秒到210秒的首token改进仅归因于MTP。 4. 我还检查了准确性以及速度。 https://preview.redd.it/8bb55qjegcoh1.png?width=1725&format=png&auto=webp&s=5b7bda289434d3cfaf371045d8a3e0995ace674f 堆栈 GSM8K MATH-500 llama.cpp基线 95.60% 92.60% SGLang 95.22% 93.00% FreeToken 95.75% 92.20% llama.cpp MTP分支在GSM8K上得分95.75%。测试使用了1,319个GSM8K问题和500个MATH-500问题。配对比较未检测到统计显著差异。这并不证明堆栈具有相同质量。这是两个简短的数学基准测试，此机器上没有全精度参考。 5. 启动模型是单独的基准测试。 https://preview.redd.it/hw5nqk4dgcoh1.png?width=1425&format=png&auto=webp&s=d73d2024745f02654962aa775219883f72983b15 从启动容器到接收第一个答案的中位时间：llama.cpp：16秒 SGLang：108秒 FreeToken：126秒 FreeToken在约3.3秒后从/health返回HTTP 200，但大约需要82秒达到服务就绪，然后大约44秒进行第一次生成。该第一次请求包括编译工作。仅测量健康端点会给出非常误导的启动结果。 6. 当专家在GPU上时，加载模式几乎不改变速度。我在相同的llama.cpp镜像上比较了无、mmap、mlock、mmap+mlock和dio，使用相同的张量放置和真实的编码提示。在8K输入时，预填充范围从2,036到2,124 token/秒——4.3%的差异。在32K时，范围从1,946到1,956 token/秒——约0.5%。没有分支内存不足或重启。我之前使用不同放置的1.87x内存驻留加载增益，其中23个专家层在CPU上计算。在此测试中，所有专家都在GPU上。当CPU计算专家时，加载模式可能重要。在此配置中，它几乎没有影响。 https://preview.redd.it/sas55spwhcoh1.png?width=1575&format=png&auto=webp&s=7250c484d8afd0e4bfcd0f5d7b9ec57a2df0457d 7. 当专家卸载到CPU时，MTP变得更慢。 https://preview.redd.it/ib6wnkk7icoh1.png?width=1650&format=png&auto=webp&s=06493891346e74e888a7d1edaa179db81bd992cc 上述MTP增益并不适用于每个内存预算。我使用较小的可用显存池在同一RTX PRO 6000上重复了测试，使用2,048 token编码提示和256 token答案。两个分支都使用相同的分支构建。 可用显存 专家层在CPU MTP关闭 MTP开启，头在GPU 16 GiB 45 33.0 token/秒 9.5 token/秒 24 GiB 42 34.7 token/秒 10.2 token/秒 32 GiB 36 38.1 token/秒 11.9 token/秒 48 GiB 23 48.3 token/秒 18.2 token/秒 96 GiB 0 99.8 token/秒 160.2 token/秒 在完整的96 GiB预算下，MTP使解码快1.61倍。在24 GiB下，它使解码慢约3.4倍。将草稿头移到CPU上并未修复24 GiB结果：9.6 token/秒