DeepSeek V4模型性能优势解析与实测对比

最近，小米推出的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批量测试过程与资源消耗

根据测试方案，本次评测过程禁止使用任何第三方智能体工具（如Claude Code、OpenCode等），完全考验大模型自身的推理、规划与代码生成能力。思考过程（Chain-of-Thought）被强制开启，且采用“一轮定胜负”的规则，以模拟真实开发场景下的单次需求交付效果。

为此，我启用了手动搭建的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文件后，页面除了背景图外，几乎空无一物。也就是说，即便耗费了数倍于他人的计算资源，最终产出的也是一个无法运行的程序。检查浏览器开发者工具或任何代码编辑器，都能发现明显的代码结构错误——文本被意外拼接，导致核心数据结构损坏。用GPT-4o的诊断总结就是：这不是“小瑕疵”，而是需要先修复为合法独立对象才能运行的结构性损坏。

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

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

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

MiniMax此次也带来了惊喜，成功生成了可直接在浏览器中打开的页面，UI上没有发现明显问题。

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

网页版补充测试验证

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

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

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

至此，结论已经相当清晰。无论是在资源消耗效率（tokens用量与成本），还是在最终成果的可用性与完成度上，DeepSeek都取得了完胜，而MiMo则在此次特定的“代码生成与网页应用构建”任务中表现不佳。

最后需要郑重声明的是，本次测试仅针对“从零生成一个完整可交互的网页应用”这一特定技术场景，远不能代表大模型的全部能力。从我们过往的其他多项测试来看，MiMo模型在文本理解、对话生成、知识问答等方面仍有其独特优势。接下来，我将继续从不同角度、使用不同难度的题目对国内这些主流大模型进行系列评测，以期为大家提供一个更立体、更直观的大模型能力图谱与选型参考。