DeepSeek V4性能超越MiMo2.5pro

近期，小米MiMo模型提供了16亿tokens的测试额度，这为深度体验创造了良好条件。我一直认为，严谨的压力测试是检验模型真实能力的关键，而在此次最新一轮的对比评测中，MiMo的表现确实有些出乎意料。

为了更准确地评估新发布的MiMo 2.5 Pro，我特意请Claude Opus 4.7设计了一道全新的测试题目。同时，为了建立更全面的参照体系，我也邀请了国内其他几款主流模型共同参与，包括DeepSeek V4 Pro、GLM5.1、Kimi K2.6以及MiniMax M2.7。本次评测将重点关注DeepSeek V4与MiMo 2.5 Pro的直接对比。

为确保测试的严谨性，我还专门升级了原有的测试系统。接下来，让我们看看具体的测试情况。

测试题目设计：掌门日记

设计全新题目的原因，是我怀疑以往的测试题库可能已被各大模型针对性地优化过，从而失去了区分度。新题目需要满足几个条件：不能来源于任何常规基准测试，不能是过于常见的应用场景，也不能太过抽象。更重要的是，它需要具备一定的难度和趣味性，同时让普通读者也能理解和评判结果。

基于这些要求，我向Claude Opus 4.7提出了命题需求。它最初提供了六个相当专业的方案，例如竞赛级算法题、形式化证明、千次工具调用级长程任务等。这些题目虽然硬核，但显然超出了大众评判的范围，因此均未被采用。

随后，我要求它生成一些更贴近实际、更具创意且能体现综合能力的题目。于是，一批有趣的构想产生了，例如“赛博中医：AI把脉模拟器”、“方言保卫战：濒危方言学习平台”、“复古BBS模拟器”等。

最终，“武侠门派经营模拟”（或称“掌门日记”）这个题目被选中。它要求模型扮演一位新晋掌门，处理招收弟子、安排修炼、参与论剑、应对江湖恩怨等一系列事务，融合了角色扮演、系统设计和代码实现的多重挑战。Opus 4.7为此制定了非常详细的测试方案，包括测试背景、选择理由、完整的提示词、考察维度、评分卡和测试流程，为后续评测奠定了坚实基础。

批量测试过程与资源消耗

根据测试方案的建议，本次评测不使用任何第三方智能体工具，完全考察模型自身的推理、规划和代码生成能力。思考过程被开启，并采用“一轮定胜负”的规则，以模拟真实开发场景下的单次需求交付。

为此，我启用了手动搭建的API批量测试平台进行统一评测。

从宏观的速度与资源消耗对比来看，各模型已显现出差异。在响应速度方面，DeepSeek最快；在完成任务的总耗时方面，Kimi最快；而小米MiMo在端到端延迟和解码速度上表现最佳，但其总耗时和tokens消耗量也最高。

这里暴露了一个关键问题：MiMo在第一次测试中并未完成题目。首次测试采用了平台默认的32000 tokens上限，结果额度用尽时，它的回答才刚刚开始。于是，在第二次测试中，我专门开发了自定义tokens上限功能，为MiMo设置了64000的额度。

令人意外的是，它依然没有完成。相比之下，其他模型的消耗则克制得多：GLM消耗了29652 tokens，DeepSeek消耗了22368 tokens，而Kimi仅用了9796 tokens。这意味着，MiMo消耗了其他模型最高6倍的资源，却未能提供完整的输出。

为了看到MiMo的“完整作品”，我不得不将最大tokens参数大幅提升至128000，为其进行了单独测试。这一次，它终于完成了输出，实际消耗了6万多tokens，未触及上限。这个测试过程也让我意识到，最初测试时忘记切换至赠送的tokenPlan，仅这一个问题的测试就花费了数元。

模型输出结果验收

当所有模型的输出结果准备就绪后，开始了正式的验收。我们逐一审视它们的“作品”。

首先看今天的主角MiMo。打开其生成的HTML文件后，页面除了背景图外，几乎空无一物。也就是说，即便耗费了数倍于他人的资源，最终产出的也是一个无法运行的程序。检查浏览器调试工具或任何IDE，都能发现明显的代码结构错误——文本被意外拼接，导致数据结构损坏。用GPT-4o的话总结就是：这不是“小瑕疵”，而是需要先修复为合法独立对象才能运行的结构性损坏。

接着看对比重点DeepSeek的表现。它生成的界面是完整可用的，具备所有要求的功能模块。UI设计采用了类似案台上摊开纸张的视觉效果，配色、字体和命名基本符合题目要求。设计虽不惊艳，但胜在扎实无误。实际试玩了一下，趣味性还不错，例如第二个月就有新弟子“走火入魔”，消耗了15点银两。

GLM的表现也可圈可点。它先设计了一个“开山立派”的创建界面，体验良好。创建一个名为“青云”的门派后，基础功能运行正常。

Kimi的UI设计则显得更为出众，采用了淡雅的底色而非泛黄复古风，整体感觉清新舒适，字体配色和意境到位，且功能可正常交互。

MiniMax此次也带来了惊喜，成功生成了可打开的页面，UI上没有明显问题。

由于MiMo在本次测试中过早“退赛”，而核心对比在于MiMo V2.5 Pro与DeepSeek V4，因此其他模型的细节在此暂不展开。若大家对详细的评分卡感兴趣，后续可以专门分享。可以肯定的是，深入分析代码结构、逻辑完备性和游戏平衡性等维度，各模型间还存在许多细微差异。

网页版补充测试

通过API调用，MiMo未能完成一次有效的交付。按照“一轮定胜负”的规则，测试本应到此结束。但考虑到对方慷慨赠送了巨额tokens，我认为有必要进行补充测试，并将平台切换至其官方网页版进行验证。

在官方网页版上，我进行了三轮测试。遗憾的是，没有一次能够正常完成，每次都是进行到一半便中断了。推测可能是达到了网页端设置的tokens上限。从之前的测试也能看出，它的思考过程异常消耗资源。经过多轮交互引导，它终于生成了一个网页，但运行时依然存在问题。

作为对照，我同样在DeepSeek的官方网页版上测试了三次，每次都能成功生成功能正常的应用。此外，在Kimi和GLM的官网进行测试，结果也都是可打开、可使用的。

至此，结论已经相当清晰。无论是在资源消耗效率，还是在最终成果的可用性上，DeepSeek都取得了完胜，而MiMo则在此次特定任务中表现不佳。

最后需要说明的是，本次测试仅针对“从零生成一个完整可交互网页应用”这一特定场景，远不能代表模型的全部能力。从我们过往的其他测试来看，MiMo模型在某些方面仍有其优势。接下来，我将继续从不同角度、用不同题目对国内这些主流模型进行评测，以期为大家提供一个更立体、更直观的模型能力图谱。