How much FASTER is GLM 5.2 with MTP 💪 | Local AI TEST

MTP机制原理与量化版本选择

本视频旨在测试 GLM 5.2 模型在启用 多令牌预测（Multi-Token Prediction, MTP） 解码后的性能提升幅度。MTP 机制通过一个极小的独立层来预测主模型即将生成的令牌，从而加速推理过程。在 Hugging Face 上已有用户上传了 GLM 的 MTP 层，该功能默认指定生成三个令牌：一个来自主模型，另外两个来自草稿预测。为了平衡内存占用与性能，作者制作了不同量化版本的 MTP 模块：未量化版本需 20GB 内存，而作者最终选用的是压缩至 5.6GB 的 Q4 版本。尽管该小型层需要预测与主模型（约500GB规模）相同的令牌，但 Q4 量化版本在保持可接受内存占用的同时，为后续测试提供了基础。

"I've made one that's unquantized, and that is 20 gigabytes... I quantized it down to a Q8 and a Q4. And now the Q4 is a 5.6 gigabyte model."

C++代码生成场景下的性能对比

在 C++ 冒泡排序的代码生成测试中，作者将输出限制为500个令牌以控制变量。未启用 MTP 的基线测试显示，使用 Q4 INF 版主模型时，平均速度为 15.4 tokens/s。启用 MTP（使用 Q4 草稿模型）后，实时速度波动较大，最低降至12-14 tokens/s，但最终平均速度达到 18 tokens/s。这一结果带来了约 20% 的性能提升，虽然不及其他模型（如 Qwen 或 Gemini）在 MTP 下实现的200%提速，但考虑到 GLM 5.2 庞大的模型体量与小型预测层之间的巨大差异，该提升幅度仍被视为有效结果。

"We ended up with 18 tokens a second. So, that is a 20% boost on performance... I think that is a good result."

百科知识与HTML游戏生成的实测差异

在 埃菲尔铁塔的百科知识问答测试中，基线速度为15.2 tokens/s，启用 MTP 后最终平均仅为 15.8 tokens/s，提升微乎其微。随后进行的 “Flappy Bird 3D HTML5” 测试中，基线为15.2 tokens/s，启用 MTP 后最终平均降至 14.3 tokens/s，甚至出现性能倒退。作者推测这是因为 3D 版本较为复杂且模型不熟悉该特定结构，导致预测失败。相比之下，标准的 Flappy Bird 2D 版本在启用 MTP 后能稳定超过20 tokens/s，表明 结构化且常见的代码模式更易被 MTP 准确预测。

"We ended up with an and oh, fool, we lost that one. 14.3 tokens a second. That was disappointing."

C++代码生成测试与MTP性能波动

在针对C++语言特性的专项测试中，主持人试图验证模型是否对特定编程语言有特殊的MTP（多Token预测）优化。测试指令为“用C++编写一个获取时间的函数”，基准性能（MTP关闭）稳定在15.2 tokens/s。启用MTP后，生成速度出现剧烈波动，实时读数在18至23 tokens/s之间跳跃。尽管过程充满不确定性且伴随“Token City”式的混乱输出，最终平均速度定格在17 tokens/s。这一结果相比基准提升了约13%，主持人将其视为一次“胜利”，并强调这是基于500 token生成的初步结论。

"So, we ended up with a 14.9... I'm going to say something like write me a function in C++ that tells the time."

"Boom shaka laka, we are back. We finally got a win of 17. That is 13% performance boost."

创意写作测试与长文本生成挑战

随后进行的“关于GLM的诗歌”创作测试揭示了MTP在自然语言处理上的短板。基准速度为15.3 tokens/s，但启用MTP后性能显著下降至8-14 tokens/s区间，最终平均仅为13.4 tokens/s。主持人指出MTP在创意写作中表现“糟糕透顶”，主要错误在于选词而非语法。接着，他选取了之前表现较好的“冒泡排序”代码进行2,500 token的长文本压力测试。尽管实际只生成了600个token，但MTP启用后的速度维持在20-22 tokens/s的健康水平。主持人还尝试将预测步数从默认的3调整为5，发现速度在12-17 tokens/s间波动，最终平均16.5 tokens/s，略高于基准但优势微弱。

"So, write a poem about GLM. So, by default MTP disabled you get a nice stable 15.3 tokens per second... and we ended up with an abysmal 13.4."

"So, unfortunately it only made 600 tokens but with MTP enabled... that is nice and healthy at 22 tokens per second."

Q8量化版本对比与非量化层内存代价

为了探究精度对MTP性能的影响，主持人切换至Q8版本模型。在相同的后续提示（优化代码速度）下，MTP关闭时的基准为14.9 tokens/s。然而启用MTP后性能断崖式下跌，速度在7-12 tokens/s间挣扎，主持人形容这“正在打破我的心”。尽管Q8版本在纯代码生成时曾表现更快，但在涉及大量文本解释的场景中失效。最后测试了非量化MTP层（额外占用20GB内存），速度在8.5-14 tokens/s间波动。主持人回顾实现历程，预测准确率从最初的10%提升至50%再到70%，但当前实现仍未达到理想加速效果，暗示可能需要进一步优化代码或接受其内存代价。

"I'm going to switch it over to the Q8 edition... Oh, seven tokens per second. That is breaking my heart."

"When I started the implementation, it was getting a prediction accuracy of 10% and then I got it to 50%... And now we got up to 70."

MTP在量化模型上的性能局限与硬件需求

测试显示，MTP层在量化版本上表现不佳，无法带来预期的性能提升。作者推测这可能是因为我们在尝试预测一个量化模型试图选择的token时出现了偏差。真正的性能飞跃可能来自于运行完全未量化的主模型和MTP层。作者建议拥有多系统（如双RTX显卡或Mac Studio）的用户尝试这种配置，以验证未量化版本在MTP加持下的实际表现。

"So, maybe if you had the ability to run the completely unquantized version of the model... that's where you'd get the performance boost."

未量化MTP层与Q4模型的混合测试对比

作者尝试了一个“奖励”实验：使用全新未量化的MTP层搭配量化主模型。在Bubble Sort任务中，纯Q4版本速度约为15-21 tokens/s（受后台任务影响波动），而混合配置稳定在19 tokens/s。这表明即使MTP未量化，其速度也超过了无MTP的纯Q4版本。在文本摘要任务中，混合配置达到16.4 tokens/s，略高于纯Q4的初始速度。作者指出Q4版本虽然节省了15GB内存，但仅比混合配置慢约1 token/s。

MTP预测步数对生成速度的非线性影响

作者深入测试了MTP的推测解码步数（Steps）对速度的影响，发现默认3步并非最优解。在500 token限制下： * 2步：平均16.6 tokens/s，略快于无MTP基线（~15.5），但慢于3步。 * 3步：平均约19 tokens/s，是测试中的最快配置。 * 4步：平均18.15 tokens/s，速度下降。 * 5步：出现剧烈波动，瞬时峰值达到29 tokens/s，但平均仅18 tokens/s。 * 10步：性能显著下降，最终平均仅12 tokens/s。

"I actually 29 tokens a second I flashed at 29 tokens a second... It's still like chunking away."

结论显示，增加预测步数并不总是提升速度。由于主模型需要验证token且无法批量处理，过多的错误预测会导致时间浪费。作者建议将MTP设为可切换选项：生成少于1000 token时开启MTP可能有益，超过该阈值则建议关闭。

结论

GLM 5.2在启用Q4量化MTP后，仅对结构化代码生成（如C++）带来约13%-20%的有限提速，而在创意写作、复杂HTML及百科问答中性能持平甚至倒退。测试证实MTP存在显著的场景依赖性，且预测步数增加并非线性提升速度，3-5步为当前最优区间。真正的性能飞跃尚未在量化模型上验证，作者推测需运行未量化的主模型与MTP层组合才能发挥其全部潜力。因此，当前配置仅适用于短文本代码生成场景，长文本或非结构化内容建议关闭MTP以避免性能损耗。