大家好，欢迎收看本期节目。今天我们将深入探讨 DeepSeek V4 Flash 结合 MTP（多令牌预测）技术的应用。如果你还不了解，MTP 是一种推测性解码策略，它通过在不实际运行主模型的情况下猜测接下来的几个令牌来提升推理性能。简单来说，它就是顶层的一个额外层，专门用于预测额外的令牌。从技术角度来看，结果应保持百分之百的准确性，因为较小的草稿模型会预先选取这些令牌，随后主模型以提示处理模式批量运行它们。

如果你还不清楚，生成速度通常比提示处理速度慢得多，而后者能一次性快速验证这些令牌。如果预测正确就保留并继续；若错误则需回溯时间，在主模型中重新运行（包含 MTP 层）。DeepSeek 早在 V3 版本就引入了 MTP，而在 V4 中我们提取了独立层级以展示性能增益。为了节省时间，左侧是未启用 MTP 的 DeepSeek V4 Flash，正在制作 Flappy Bird HTML，速度为每秒 31.15 个令牌；右侧启用 MTP 后达到每秒 37.3 个。

接下来我们测试故事写作场景。未启用 MTP 时速度为每秒 32.9 个令牌，启用后仅为 33。这表明 MTP 在创意写作中的预测准确率不如编程场景，因为故事创作的令牌范围更广且更具创造性。我们将重新运行测试并逐步展示如何自行操作。目前我们已稳定在每秒 30 个令牌以上，这是针对 DeepSeek V4 Flash 的特殊实现，支持工具调用等功能。基础版本存在较多代码错误，调试颇具挑战。

启用 MTP 后，速度波动较大：有时飙升至每秒 40 个令牌，跌至 25，或稳定在 35。这是因为主模型需不断验证草稿模型的预测并频繁回溯。理论上若完全准确可达每秒 40 个令牌，但 DeepSeek V4 Flash 的 MTP 层占用高达 3.6 GB。内存方面，启用后从 149 GiB 增至 153.5 GiB。在故事测试中仅提升约每秒 1 个令牌，效果不明显；但在 Flappy Bird 编程任务中，未启用时约每秒 30-31 个令牌，启用后常突破每秒 40 个。

编程场景中令牌选择范围较小且语法约束强，因此 MTP 表现更佳。本次测试产生约一千个令牌时，未启用速度为每秒 30.5 个，而启用 MTP 后性能提升约 20%。接下来演示完整的 3D 俄罗斯方块项目，未启用 MTP 时生成近六千个令牌的速度为每秒 30.7 个，内存占用 148.5 GiB。我们对比了不同量化版本：DeepSeek V4 Flash 权重已预压缩，直接提取的 MTP 层为 Q4.3（约 3.6 GB），另测试了进一步压缩的 Q3 版本。

启用 MTP（Q4.3）后，生成近五千个令牌的速度达到每秒 36.2 个，再次体现约 20% 的性能提升。虽然代码逻辑看似相同且模型自报百分之百准确，但实际执行路径略有差异。由于 MTP 层增加了额外运算，浮点数计算产生微小偏差，加上随机数生成器的不同结果，导致决策树分支出现细微变化。尽管主模型验证了所有路径的正确性，最终结果仍存在轻微差异。Q3 版本的 MTP 实测速度为每秒 35.9 个令牌，表现同样出色。

每秒生成的令牌数实际上比基础版本更慢，原因在于这仅仅是一个基础的Q3量化模型。通常来说，Q3的表现并不理想，尤其是在处理代码时容易出错。尽管生成速度可能更快，通常能超过每秒45个令牌，但最终结果会导致更多的缓存回滚。这意味着模型会猜测出略微不同的错误令牌，因此我决定不上传Q3版本，只保留MTP版本。

如果你想跟着一起体验，这里就是具体的操作方法。我已经上传了DeepSeek V4 Flash的MLX 9位量化版本，并在描述中添加了关于改进性能的说明。你需要下载并启用兼容的MTP投机解码器，点击链接即可找到相关代码模型。该版本专为配合DeepSeek V4 Flash MLX使用，我也列出了运行速度数据：首次运行时分别为每秒31和37个令牌。

如果你想在Inferencer中运行它，只需进入模型部分搜索DeepSeek V4。我这里使用的是MLX 9位版本，但列表中也有MTP MLX选项。为了简化操作，你可以直接搜索“MTP”。当你同时下载了主模型和MTP版本后，Inferencer会自动检测并识别出这是投机解码器。在推理控制中选中DeepSeek V4 Flash时，会出现一个“投机解码器”选项区域。

勾选该选项后，两个模型就会并行运行，但这会额外消耗约4吉字节的内存。如果你的存储空间紧张，这一点需要特别注意。我尚未测试DeepSeek Q9的2.8位量化版本，但在128吉字节内存的配置下已经相当紧张。这就是在Inferencer中运行的方式：下载两个模型，它们会作为独立的侧层运行。这种分离设计的好处是你可以灵活尝试不同的技术策略。

例如，如果你想查看Eagle Free或DFlash的效果，就不必运行MTP版本，可以改用其他策略。我最近一直在用DFlash和Eagle 3进行实验。剧透一下：目前Eagle 3在Mac上运行得不太理想，我还在排查原因。可能不得不自己训练Eagle 3或DFlash模型，因为仓库中我想要的特定版本是受限访问的。其他现有版本在这台硬件上表现也不佳，这部分内容我们将在另一个视频中详细探讨。

现在让我们进行一些其他测试，看看工具调用是否会产生不同的结果。我点击“工具”并启用它，输入查询内容，同时切换到MTP版本，移除令牌限制以获取完整响应。当禁用MTP时，模型正确识别了目标并正在撰写摘要；而启用MTP后，右侧仅勾选了投机解码器按钮。可以看到它正在执行工具调用并抓取结果，运行速度明显领先。

从速度上看，进行工具调用时分别为每秒37.2和31个令牌，仍有约20%的提升。在文本摘要方面则是每秒28.9对30.3个令牌，虽然投机解码器带来了改善，但幅度不如之前显著。接下来我们测试一个关于洗车的问题：如果去洗车店需要开车还是走路？禁用MTP时，模型给出了幽默且实用的答案。DeepSeek V4 Flash实际上拥有多种思考模式，之前我一直禁用思考功能，现在我要将其切换为最大思考模式。

让我们看看启用MTP后的对比结果：禁用时为每秒31.5个令牌，生成165个令牌；启用后则生成了280个令牌。这是因为模型在额外层的影响下走向了不同的路径，尽管结果由主模型100%验证。这种情况类似于调整温度、种子或在提示词中增加空格时，模型会因微小变量变化而进入不同的结果分支。虽然答案依然准确，但具体表述会有所不同。

有趣的是，启用MTP后模型建议“交钥匙、走路回家”，声称这样更快更健康；而禁用时则建议开车。为了排除偶然性，我在问题中添加了空格并重新运行最大思考模式测试。结果显示速度为每秒32对35.5个令牌，差距不像代码生成那样巨大。在最大思考模式下，启用MTP的模型依然得出了错误的“走路”结论，而禁用时则正确指出必须开车。

尽管理论上答案应被完全验证，但两者结果仍不一致：分别生成了728和990个令牌。为了确认是否只是运气好，我再次在问题中加入空格并重跑测试，以验证禁用思考模式下的稳定性。这种细微的输入变化确实会影响模型的推理路径和最终输出，展示了投机解码机制在复杂逻辑判断中的潜在不确定性。

再跑一次看看效果，我想确认一下。大家想不想看？听起来挺有趣的。你看！[笑声] 看看这个结果，我就知道嘛，我刚才只是运气好罢了。其实我只做了一件事：在提示词里加了一个空格，仅此而已。天哪，这些人很快就要去控制武器系统了，真让人害怕。

没错，我只是在提示词里加了个空格，然后它给出的逻辑答案是你应该走路。这显然是错的，简直太疯狂了。好吧，不管怎样，我们进去直接问问它吧。哦，这个任务我得先做一下，然后再处理答案部分。我要允许模型进行思考，这里有最大深度思考、纳米级思考和普通思考几种选项。我决定让它在这个任务中启用思考模式，题目是：使用 WebGL 生成一张人脸的实时渲染图。

同时，我也将启用 MTP（多令牌预测）功能来生成这个内容，这其实挺有趣的。结果发现，未启用 MTP 的版本陷入了推理循环，应用检测到了这种死循环现象。在推理控制设置中，我将最大循环次数设为 9。这意味着如果检测到代码连续重复输出九次相同内容，程序就会强制退出。默认值通常是 6 左右，如果你遇到类似情况可以自行调整这个参数以优化结果。

最终，该版本在生成约 9800 个令牌后触发了循环检测机制。相比之下，启用 MTP 的版本成功完成了推理过程，并且此刻正在实时输出代码。这绝对是一次胜利，我对此感到有些惊讶。这里有几种策略可以绕过这种死循环困境。实际上，应用内部已经专门处理了这种情况，所以未来你无需再为此担心。但如果你进入令牌检查器界面，可以看到之前模型在思考“现在让我写出代码”时，曾考虑输出的一个令牌是右括号。

这个符号看起来像是思考标签的闭合标记。如果我选中该特定令牌，就可以仅基于这一选择重新播放生成过程，从而强制结束思考阶段并继续执行响应输出。这是第一种解决方案。另一种方法是直接点击这里的编辑按钮，手动输入闭合思考标签的内容，让模型从该点继续正常工作。不过我认为我会采取另一种做法：由于我在此处频繁使用思考功能，我将克隆那个由 MTP 生成的对话记录，这可能是一个有趣的实验。

接着我会点击编辑按钮，将答案部分中多余的思考标签内容删除并重新运行任务。正如你所见，系统正在处理提示词，并利用 MTP 高级场景生成的思考内容来回答这个问题。让我们看看它在数学问题上的表现如何。左侧显示两者获得了完全相同的响应，即“alpha 是偶数”，这是正确答案。因此两个版本都答对了题。

左侧版本的消耗为 1700 个令牌，耗时 39 秒；右侧版本仅消耗 177 个令牌。在速度方面，前者为每秒 31.8 个令牌，后者达到每秒 36.8 个令牌。这表明我们依然能从 MTP 中获得显著的速度提升。接下来我将进行最终测试，使用照片级真实感的人脸版本来验证效果。让我们看看启用 MTP 后的具体表现，它真的能正常运行吗？

正在加载人脸模型……哦，我们得到了一张脸！你好。这是一张非常漂亮的脸，它有眼睛但没有嘴巴，不过拥有眼睛已经很不错了。渲染效果极其精美。我觉得我可能在拖慢非 MTP 版本的速度，目前速率约为每秒 27 个令牌。尽管如此，它依然生成了带有工作室背景云朵和精美室内灯光的效果，这确实令人印象深刻。

如果你看过 Qwen 生成的版本，那看起来就像一个倒扣的棕色杯子，可能只是头发粘在了上面。但 DeepSeek V4 Flash 生成的这张脸非常美丽，虽然缺少鼻子和嘴巴，但其光影效果看起来棒极了。再次禁用 MTP 后，速度回到每秒约 30 个令牌水平。我们点击播放看看这次生成了什么……正在加载……哇！你好，这是一个鸡蛋。[笑声]

这潜在地可能是一张脸，也许鼻子正在显现出来。灯光效果确实很美，但你必须承认这种偏差非常疯狂：仅仅添加一个额外空格就会导致得出不同答案。启用推测解码器就能生成人脸，而禁用它则只得到一个土豆状物体。[笑声] 这很酷。当然，如果你愿意，也可以使用你喜欢的框架来运行此模型。

如果你想在这里使用推理服务，有一个服务器功能可用。进入“Serve”选项启用该服务器后，你可以选择你的模型或 OpenAI 兼容 API。如果系统支持多节点最大配置，你甚至可以运行分布式计算。你可以创建一个集群将多个实例链接在一起并分摊负载。我将在这里启用服务器，仅为了向你展示它在 OpenCode 中运行的样子，让你快速了解其工作原理。

这是我的模型列表界面，我们可以看到 DeepSeek 提供了我拥有的所有不同 MTP 版本选项。如果我使用此作为模型，你可以直接运行 DeepSeek Flash；或者如果选择带有 MTP 的版本，它会加载特殊的解码器标签并让引擎知道需同时运行两者。例如在 OpenCode 中，如果你编辑 JSON 配置文件并粘贴这里的模型 ID，给它命名为“deepseek”，然后运行 OpenCode P 命令切换模型并选择 DeepSeek……

输入“你好”后，系统回应了问候。[笑声] 首次运行时速度会稍慢一些，因为它需要缓存 OpenCode 提供的庞大系统提示词。但如果你启用了“持久化提示词缓存”功能，进入设置并确保勾选了“缓存提示词”，系统就会保存该响应。这样下次使用 OpenCode 时速度会快得多。再次输入“你好”，系统快速响应并询问今天是否可以开始工作，随后要求编写一个愤怒的小鸟克隆版游戏。

你可以看到它正在这里进行服务器端生成，速度达到每秒 36 个令牌。MTP 显然正在发挥作用，因为速率超过了 30 且 OpenCode 成功处理了所有任务。如果你像我一样经常切换模型，可以进入服务器设置并勾选“覆盖 API 模型选择”选项。这样系统就会自动跟随下拉菜单中选择的当前模型，而不必每次都手动输入模型 ID。

如你所见，所有功能在框架内都正常工作。你认为 DeepSeek 配合 MTP 的性能如何？之前我们看到 Qwen 的表现是两倍速……

速度更快，而且与 Gemma 相比也快了两倍，但这些模型的尺寸要小得多。它们的参数量大约在270亿到300亿的范围内。而 DeepSeek 的参数量超过1000亿，不过在游戏性能上提升20%对我来说也是不错的。希望各位觉得这个视频有用，并享受了这期节目。