更快的模型，真的更快吗？要看任务做完没有，而不是 token 有多快

Morgan Suo 在 MiniMax 工作了将近三年。公司刚进入美国市场的时候，几乎没人知道它，不过那时它已经有了第一个视频生成模型，她答应在演讲最后给大家看看。不过在那之前，她想先聊聊 MiniMax 下周就要发布的最新语言模型，以及更快的模型背后的隐藏成本。

设想你有一个 AI 应用，已经嵌进了自己的工作流。新模型出来了，有人问你要不要试试。它完成任务更快，于是问题变成：该不该换？你跑了一个研究任务，报告很快就回来了，却漏掉了一个非常重要的来源。现在得有人去把这个来源找回来、把报告改好，这正是每天都在发生的事。那么，这件活真的变快了吗？

这场演讲先看 MiniMax 是怎样减少模型计算量的，再看怎样检验这些改动值不值。为了回答这个问题，Morgan 用了一个具体的任务。

MiniMax 做了好几个多模态模型和产品，而一次快速的聊天回复和一份研究报告，需求完全不同：好的表现是什么，由任务来定义。她这次聚焦在新的大语言模型 M3.1 Flash 和一个研究任务上。分析师的问题是：随着 AI 服务器需求增长，供应印制电路板（也就是 AI 服务器这类设备里连接电子元件的板子）的公司，有没有把这份增长变成现金？

按照 MiniMax 内部评审的描述，这项工作涉及 14 家公司的报告，模型要完成好几件事：找到对的报告，对齐相同的报告期，把不同的业务分开，然后解释这些数字意味着什么。

想想收到这份报告的分析师。他们需要打开某个重要论断背后的来源，核对一笔计算，看到哪些证据可能改变结论。一份有用的报告，会给分析师留下可以核对的东西，这就是 MiniMax 对一个做完的研究任务的标准。

内部评审点出了这些核对为什么重要：利润可能在增长，现金流讲的却是另一个故事。公司卖得更多，报表上的利润涨了，可客户还没付钱，或者买进来的原材料还堆在仓库里。模型应该把分析师引向现金流量表和相关的披露。论断经得起核对，报告才能赢得信任，所以来源和计算仍然要核实，时间和成本也要在同一个任务上衡量。另外一些单独的技术测试，可以帮助理解具体的取舍。

任务讲清楚了，Morgan 转向 M3.1 Flash 内部的改动，并把每项改动都和一个简单的问题联系起来：哪里可以减少注意力计算？数据怎么存储、怎么搬运？服务部署怎样影响用户的等待时间？模型要做多少推理？这些选择影响任务的不同环节，每一项都要对照我们想要的结果去检验：每一项优化都必须对最终完成的任务有帮助。

先说长输入。现在每个模型都在宣传超大的上下文窗口，MiniMax 的是一百万 token，但问题在于它能不能帮你更快地拿到正确的结果。对某个问题来说，报告里有些段落远比其他段落重要。稀疏注意力先运行一个很小的选择步骤，给文本块打分；主注意力再在选中的块上计算，同时附近的文本也保留在视野里。选择会随查询变化，因为不同的问题需要上下文的不同部分。

对这个研究任务来说，目标是减少跨多份文档的注意力计算。可在一份文档里，一条很短的脚注就可能改变整个结论：对于现金流问题，这条脚注可能比好几页行业展望都重要。注意力计算少了，仍然必须找到关键证据。

所以下一个问题是：模型还能不能找到它需要的事实？M3.1 Flash 在前三层使用稀疏注意力，所以检索是一项重要的检查。另一项单独的测试把事实放在长输入的不同位置，模型通过了全部 39 个请求，最长的输入约 83 万 token。这覆盖了测试里的情形，但研究任务需要用真实报告来检验：模型能找到现金流脚注吗？用的是正确的报告期吗？能发现不同文档之间的矛盾吗？把关键段落挪到输入的不同位置，再问一遍同样的问题。长输入只有在模型能找到关键事实时才有用。

接下来是模型内部的数字。模型会把前文的内部信息保存在所谓的 KV 缓存里。M3.1 Flash 把键和值从 8 位改成 4 位存储，查询仍然是 8 位。这减少了要存储和搬运的数据，但也改变了这些内部信息的精度。

在 MiniMax 的评测里，宏平均几乎没变，SciCode 却掉了 6.6 分，其他分数则有所上升。平均分恰恰可能掩盖用户在意的那种错误。而且比较两套完整配置，并不能告诉你每个分数的变化是哪项改动造成的。对研究任务来说，要再检查一遍输出：来源对不对？计算对不对？解释和证据是否一致？

同样的思路也适用于专家。M3.1 Flash 是混合专家（MoE）模型，每个 token 会选用其中一部分专家，这些路由专家现在使用 4 位权重和激活值，共享专家不在这次改动之内。精度降低能减少数据搬运，让计算更高效，但完整的计算有好几步：先缩放数字，再计算，最后还原缩放，而在哪里还原缩放，决定了答案对不对。计算快了，也必须是对的。所以 MiniMax 衡量的是完整的实现，重新跑同样的研究问题，并检查答案为什么仍然通不过核对。

看完模型内部，Morgan 转向模型怎样生成答案。推测解码分两个阶段：一个更快的草稿过程先提出一小串 token，目标模型进行检查，系统保留目标模型接受的部分，必要时修正，然后继续。有时能保留好几个提出的 token，有时草稿做的工作只能扔掉。机会在于一次目标检查就拿到好几个 token，但起草、检查、拒绝都要花时间，所以检查草稿的时间也要算进去。

这些检查针对的是 token；财务论断和来源需要它们自己的检查。对研究任务来说，要把来源检索、工具调用和重试都算进去。真正要衡量的，是分析师拿到一份真正能用的报告需要多长时间。

就算单个请求跑得很好，用户一多，体验也会变。在一项单独的服务测试里，推理强度设为低，并发请求从 32 增加到 64。每秒总输出增长到大约 1.9 倍，但首 token 的 P95 等待时间从约 1.5 秒涨到 11 秒以上，大约长了八倍，尽管中位数还算可以接受。用户感受到的是等待，所以光有很高的吞吐量数字是不够的。而且第一个 token 可能还是推理内容：重要的是可用的报告什么时候到。给这份报告定一个截止时间，再衡量有多少次没赶上。

还有一个设置会改变我们让模型做的工作量：推理控制，这是第一次在这个模型上使用。思考始终开启，如果强度留空，默认就是 max，所以单是默认值就会改变一个请求要求的工作量。一项编程测试展示了其中的取舍：high 比 max 用的输出 token 更少，但准确率从 80% 掉到了 68%。token 少了，准确率也低了，所以要给每个任务它需要的思考预算。

对研究任务来说，要在同样的报告上比较这些设置，检查每一档能不能找到证据、支撑计算；快速的初稿和准备送审的报告，可能需要不同的预算。记下用的是哪一档推理设置，后续的工作才能依赖它。

要把带着这些改动的研究工作流上线，先固定问题、来源报告和信息截止时间，并在做任何比较之前，就什么样的报告算合格达成一致。然后检查三件事。第一，分析师能信任这份报告吗？打开重要论断背后的来源，核对报告期，重新计算数字，寻找可能改变结论的证据。

第二，完成这件活花了多少钱、多少时间？把检索、工具成本和重试都算上；如果必须有人先改过报告才能用，这部分工作也要算，还有每一次失败的尝试。按预期的用户数量做测试，检查报告是否在承诺的时间内送达，衡量一份真正能用的报告的成本。

第三，结果能复现吗？保存模型和运行时版本、提示词设置和来源，留下失败的样例。先小范围上线，并保留切换回去的办法。

Morgan 最后放了一段用 MiniMax 自家视频模型制作的简短回顾视频，还提到公司正在做的另一个开放权重的文生视频模型。

回到开场的问题：该不该换成更快的模型？看最终完成的任务。对分析师来说，那就是一份来源能打开、数字能核对、在需要时按时送到的报告。M3.1 Flash 改变了计算的花法；完整的任务才能说明这些改动对用户意味着什么。衡量按时把活做完的成本。更快的模型确实重要，但最重要的是我们能用它们做成什么。