接受长度越高，文本越慢：Ling在单台Spark上的n=1/2/3 MTP测试

Reddit r/LocalLLaMA 工具
multi-token-prediction vllm benchmark cuda-graphs speculative-decoding throughput acceptance-length

摘要

对Ling-3.0-flash的基准测试显示，在多令牌预测中，更高的接受长度会降低文本吞吐量，其中n=1是所评估工作负载中最高效的设置。

缺失的控制在sudoingX的Ling-3.0-flash基准测试图形中可见。之前的表格将Ling的无推测基线标记为“未测量”。后续的代码/文本图形补充了它：在短提示下，没有草稿器时约为23 tok/s，而使用MTP n=1时，代码为40.9 tok/s，文本为38.7 tok/s。这使得调优声明更容易检查。后续图形比较了有无草稿的短代码和文本工作负载。仓库中的一个单独更正隔离了CUDA图：早期的“两个标志”结果同时更改了图和多令牌预测（MTP），因此无法确定哪种更改产生了增益。更正后的8月22日测量在一台128GB DGX Spark上进行，使用官方INT4检查点和供应商的vLLM分支，结果为： | 配置 | 报告的tok/s，短编码任务 | |------|-------------------------| | 急切执行，MTP关闭 | 20.8 | | CUDA图，MTP关闭 | 22.9 | | CUDA图，MTP n=1 | 40.9 | 这大约是图相对于急切基线增加了10%的吞吐量，然后MTP相对于图基线增加了大约79%。这些百分比的分母不同。然后是那个诱人的设置。这里n是num_speculative_tokens：每一步提出多少草稿令牌。vLLM文档中的接受长度指标包括每个验证步骤的一个奖励令牌，因此n=1时平均值可能高于1。创建者从供应商分支报告该指标；其确切的历史计数实现未提供。 | MTP设置 | n=1 | n=2 | n=3 | |---------|-----|-----|-----| | 平均接受长度 | 1.87 | 2.39 | 2.77 | | 文本，512令牌输出，tok/s | 38.7 | 34.8 | 33.6 | | 文本，2,048令牌输出，tok/s | 37.3 | 33.6 | 31.6 | 代码吞吐量在报告的运行间变化中大致保持平稳。文本随着平均接受草稿长度的增加而变慢。接受长度不是接受百分比，也不是优化目标。sudoingX在部署线程中描述了配置；固定的基准测试笔记包含两个表格。这些是作者的测量，此处没有独立重做。该扫描描述了流式和服务器端令牌计数，但没有完全指定其时间分母，因此数字应标记为报告的吞吐量。对于此检查点和这些工作负载，n=1是有用的设置。可转移的实验是隔离无MTP基线，然后比较草稿设置在您实际生成的输出类型上。
查看原文

相似文章

MTP 关键在于接受率

Reddit r/LocalLLaMA

一位用户在 M4 Max Studio 上使用 mlx-vlm 对 Gemma 4 进行了 MTP（多令牌预测）基准测试，发现它在代码生成方面表现出色（速度快 1.53 倍，接受率 66%），但对 JSON 输出不利（速度慢 50%，接受率仅 8%），对长篇散文则影响中性，表明当令牌接受率低于 50% 时，MTP 的优势便荡然无存。