最近组里在选代码模型MiMo 2.6 和 DeepSeek 是讨论最多的两个名字。一个主打轻量高效、开源可自托管一个是口碑稳定的实力派。光看跑分没意思我把它们拉到实际场景里用两道代码题硬碰硬测了一轮一道算法题一道 C 语言链表题考察的不只是“写不写得出来”还有复杂度控制、边界意识、代码完整度以及追问时的修正能力。这篇文章会把题目设计、测试环境、两边回答的全过程完整记录下来最后给出我留下的选择思路。如果你正在刷题、写竞赛代码、准备 C 语言期末或者要给团队挑编程助手这篇实测记录可以拿来直接当参考。1. 为什么偏要用“两道代码题”来选模型1.1 跑分再高不如现场写一段代码现在市面上的模型榜单HumanEval、MBPP 这类代码测试集已经被刷得很熟很多模型榜单分数接近实际用起来差别却不小。原因很简单榜单题目分布相对固定模型在训练时很可能见过同款或相似题等于开卷考试。真实场景是闭卷的——题目可能是新瓶装旧酒约束条件写得很含糊边界情况得靠模型自己想全。所以我在选型时不迷信榜单只做一件事把真实任务抛给模型看它从零开始怎么写。这次选的两道题不是随手抓的是我平时工作里经常遇到的两类任务一类是带明确复杂度要求的算法题测模型“会不会解”一类是考察语言功底和内存意识的 C 语言题测模型“写出来的代码能不能上生产”。两类题结合起来比单纯跑一个 benchmark 更能反映日常体验。1.2 第一道题滑动窗口最大值题目是 LeetCode 239 的原题给定一个整数数组和一个窗口大小 k输出每个窗口内的最大值要求时间复杂度 O(n)。题目看着普通实际上非常考验基础功知不知道“单调队列”这个数据结构能不能解释清楚为什么队首过期元素要淘汰、队尾遇到更大值时为什么要弹掉会不会主动处理 k1、k 等于数组长度、空数组这些边界给不给带测试用例的可运行代码。很多模型能写出能跑的代码但写不出 O(n) 的版本。这恰好能区分“背过题”和“真懂原理”的模型。1.3 第二道题C 语言单链表反转第二道题我选了单链表原地反转这是大学 C 语言期末和面试里出场率极高的题。题目本身不难但考点密集空链表和单节点链表能不能正确处理反转后头指针是否真的指向了原尾节点用迭代还是递归递归在处理长链表时有没有栈溢出风险有没有补全测试代码还是只甩一个函数就完事。这类题最能暴露模型对内存和运行时的理解。代码能跑只是及格分能解释清楚“为什么这样写更稳”才是加分项。1.4 我说的“选择”到底在选什么固定两道题之后我把最终对比拆成五个维度首答正确率、复杂度与健壮性、代码完整度、解释质量、追问表现。前四个是硬指标最后一个是软指标但恰恰是软指标最影响日常体验——因为真实开发很少一锤子买卖大多是“先给我一版我再让你改几轮”。2. 测试环境与参数设置2.1 两种接入方式官方 API 和本地部署为了公平我把两个模型都接到同一个格式的接口上测试。DeepSeek 走官方 APIMiMo 2.6 我用本地部署因为它的定位之一就是可自托管。两者都兼容 OpenAI 的接口格式所以客户端调用代码可以完全复用。DeepSeek 的调用长这样from openai import OpenAI client OpenAI( api_keysk-你的key, base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: user, content: 题目文本} ], temperature0.0, max_tokens2048 ) print(resp.choices[0].message.content)这里用的是 OpenAI SDK 兼容模式不是 DeepSeek 独有 SDK。这样切模型时只需要改 base_url 和 model 名其余一行不用动。对比测试时这个习惯能省很多事也能排除“因为客户端实现不同导致结果差异”的干扰。MiMo 2.6 本地部署我用的是 vLLM启动命令大概是这样vllm serve /path/to/MiMo-2.6-Instruct \ --served-model-name MiMo-2.6-Instruct \ --port 8000 \ --max-model-len 32768 \ --gpu-memory-utilization 0.85启动后客户端只需要把 base_url 换成 http://localhost:8000/v1model 换成 MiMo-2.6-Instruct。注意 --served-model-name 这个参数如果你改了对外暴露的模型名客户端配置里必须同步修改否则会报 model not found。2.2 参数设置代码题不能乱开“想象力”代码生成和写诗不一样temperature 必须压住。我这两轮把两个模型的 temperature 都设成 0.0让输出尽量确定。max_tokens 给到 2048防止代码太长被截断。提示用推理模型和用对话模型是两套配置。DeepSeek 的 deepseek-reasoner 会在正式回答前输出一大段思考过程如果你还按普通对话模型的 max_tokens 设置很容易被截断。我第一轮就把两边的模型配置搞混了导致 DeepSeek 的回答被截掉一段后来才发现是模型名填错了。对比测试前一定确认你调的是对话模型还是推理模型。评测过程我记录了四个数据首次返回第一个 token 的延迟、整段回答的总耗时、输出 token 数以及从第一问到追问第三轮时模型的表现变化。2.3 我遇到的第一个环境坑本地部署 MiMo 2.6 时我一开始用原生推理加载 FP16 权重24GB 显存勉强能放下但并发一高就明显变卡。换成 vLLM 之后吞吐改善很多但第一次请求的首 token 延迟反而略高因为 vLLM 启动后有 prefill 优化和显存预热的过程。如果你只是单机自己用这点差异无所谓如果是多人共用一个推理服务vLLM 的收益非常明显。3. 第一道题实测滑动窗口最大值3.1 题目与评分标准题目原文我给两个模型都是同一句“给你一个整数数组 nums 和一个整数 k有一个大小为 k 的滑动窗口从数组的最左侧移动到最右侧只可以看到窗口中的 k 个数字窗口每次向右移动一位。返回滑动窗口中的最大值数组。要求设计一个时间复杂度为 O(n) 的算法。”评分标准分四块代码是否运行正确、是否严格满足 O(n)、边界情况是否处理、讲解是否把单调队列原理讲透。测试用例我用的是经典例子nums [1,3,-1,-3,5,3,6,7]k 3期望输出是 [3,3,5,5,6,7]。3.2 DeepSeek 的回答一步到位的最优解DeepSeek 这次用的是 deepseek-chat 对话模型不是推理模型但回答质量很高。它先讲了一段思路维护一个单调递减的双端队列队列里存索引而不是值这样既能快速拿到窗口最大值又能通过索引判断元素是否过期。然后给出代码from collections import deque def max_sliding_window(nums, k): dq deque() res [] for i, v in enumerate(nums): # 过期的索引从队首淘汰 if dq and dq[0] i - k: dq.popleft() # 队尾所有小于等于当前值的索引都没用了 while dq and nums[dq[-1]] v: dq.pop() dq.append(i) # 窗口形成后队首就是当前窗口最大值 if i k - 1: res.append(nums[dq[0]]) return res我直接跑了一遍输出和期望完全一致。更意外的是它对边界处理很完整k1 时每个元素都是独立窗口的最大值k 等于数组长度时只有一个窗口空数组直接返回空列表。它还专门解释了为什么要用索引而不是值因为窗口滑动时要判断哪些元素已经“滑出去了”只看值判断不了。3.3 MiMo 2.6 的回答能跑但第一次没达标MiMo 2.6 第一轮给出的是最大堆方案思路是维护一个大小为 k 的堆窗口右移时把新元素推进去再把堆顶不在窗口内的元素弹出。代码长这样import heapq def max_sliding_window(nums, k): if not nums: return [] heap [(-nums[i], i) for i in range(k)] heapq.heapify(heap) res [-heap[0][0]] for i in range(k, len(nums)): heapq.heappush(heap, (-nums[i], i)) while heap and heap[0][1] i - k: heapq.heappop(heap) res.append(-heap[0][0]) return res这段代码也是对的用最大堆取窗口最大值弹出的都是过期索引输出结果和期望完全一致。但它不满足题目的硬性要求堆操作的单次复杂度是 O(log k)整体是 O(n log k)不是 O(n)。题目里白纸黑字写了“要求设计一个时间复杂度为 O(n) 的算法”MiMo 第一轮没有主动往这个方向靠而是选了它认为最稳妥的常规解法。随后我追加了一句“题目要求 O(n)能不能用双端队列优化到线性复杂度”它立刻给出了和 DeepSeek 几乎一样的单调队列方案并正确解释了头尾维护逻辑。这说明它具备生成最优解的能力但在第一次回答时没有把“题目要求”当作最优先约束去自我检查。3.4 第一轮判分差距不在正确率在“约束意识”第一轮打分如下维度MiMo 2.6DeepSeek首答正确性8/10正确但非最优10/10复杂度控制6/1010/10边界处理8/109/10解释清晰度7/109/10追问后修复9/109/10如果只看“能不能跑出正确答案”两个模型几乎没差别heap 方案在数据量不大的时候甚至更直观。但真实场景里题目要求 O(n) 就是硬约束一个模型如果不主动检查约束你很容易在不知不觉中拿到一版“性能不达标但能跑”的代码。这就是我常说的“约束意识”模型不能只会解题还得懂题目的考点在哪。4. 第二道题实测C 语言单链表反转4.1 题目与隐藏考点第二道题的原文也很简单“用 C 语言实现单链表的原地反转函数返回反转后的新头结点并给出测试代码。链表节点定义为 struct ListNode { int val; struct ListNode *next; }。”这类题在期末和面试里出现频率极高但很多人栽在同一个点上递归解法看起来简洁实际在长链表上会爆栈。C 语言期末考试一般不会用几十万个节点的链表去测所以递归能骗过评测系统但到了真实工程里一个百万节点链表就能让程序直接段错误。4.2 MiMo 2.6 的解法简洁但埋了隐患MiMo 2.6 给的解法是递归代码非常短struct ListNode* reverseList(struct ListNode* head) { if (head NULL || head-next NULL) { return head; } struct ListNode* newHead reverseList(head-next); head-next-next head; head-next NULL; return newHead; }思路没问题先反转后面的链表再把当前节点的下一个节点的 next 指向当前节点最后把当前节点的 next 置空。空链表和单节点链表都在递归出口覆盖了。它还补了一个 main 函数创建 5 个节点的链表反转后逐节点打印 val能编译能运行。我给它的扣分点在最后一句解释里。我问它“如果这个链表有 100 万个节点这段代码会怎样”它承认递归深度会达到 100 万层超过默认栈空间程序会崩溃。也就是说它是知道风险的但写代码时没有主动选择更稳妥的迭代方案而是选了“看起来更优雅”的递归。这恰好是编程里最危险的一种选择数据量小时没事数据量大时才炸。4.3 DeepSeek 的解法直接选了工程上更稳的迭代DeepSeek 第一轮直接给的是迭代解法三个指针 prev、curr、next 轮转struct ListNode* reverseList(struct ListNode* head) { struct ListNode *prev NULL; struct ListNode *curr head; while (curr ! NULL) { struct ListNode *next curr-next; curr-next prev; prev curr; curr next; } return prev; }解释逻辑很清晰每次循环把当前节点的指针反转三个指针整体右移循环结束后 prev 指向原链表的尾节点也就是新链表的头。它还特意说明迭代只用 O(1) 额外空间不存在递归深度问题。我追问“百万节点会怎样”它直接说迭代解法没有栈溢出风险唯一要注意的是链表本身不能有环否则会死循环。这个回答很专业因为链表反转确实要警惕环的存在。4.4 追问三轮后的表现差异第二题我追问了三个问题记录下来的差异很有意思。第一个追问是“怎么验证反转结果是对的”。DeepSeek 建议用断言思路反转前记录原链表尾节点反转后检查它是不是新链表头再遍历一遍确认长度不变、顺序逆序。MiMo 第一反应是“打印出来看看”在我追问“有没有更自动化的验证”之后才补上和 DeepSeek 类似的遍历验证方案。第二个追问是“如果链表是循环链表会怎样”。DeepSeek 立刻指出迭代法会陷入死循环建议测试时限制节点数量或先判环。MiMo 犹豫了一下先说“可以在循环里加计数器超过节点数就退出”后来才补上判环方案。对比下来DeepSeek 应对异常场景时知识组织得更靠前MiMo 需要被提示一下才能调出来。第三个追问是“能不能同时给出递归和迭代两个版本”。两边都很快给出了MiMo 给出的迭代版明显是在递归版基础上改进的说明它确实理解了迭代思路不是背模板。这一点我觉得很加分一个模型在被追问时能不能真正修正自己的初始方案比它第一次给什么更重要。5. 两道题放在一起看五个维度的真实差异5.1 首答质量的差距有但没有想象中悬殊两轮测试跑完我把结果汇总过一遍对比维度MiMo 2.6DeepSeek首答正确率高但追求“能跑”而非“最优”高且主动满足题目约束复杂度与健壮性需要追问才能暴露隐患首答就主动规避代码完整度有测试代码但偏“演示”有测试思路偏“验证”解释质量简洁结论多结构清晰过程完整追问后表现能改但需要引导基本不需要引导结论很直白如果只比第一次回答差距集中在“主动性和工程意识”上不是“会不会写”。MiMo 2.6 能写出对的递归链表反转也能在提示后改成迭代DeepSeek 是一开始就写迭代。同样地MiMo 第一次给的滑动窗口是 O(n log k)提示之后才换成 O(n)DeepSeek 第一次就是 O(n)。5.2 推理风格一个像讲解员一个像快枪手用一句糙话总结DeepSeek 像带徒弟的老师傅先讲思路再写代码最后还要补一句边界注意MiMo 2.6 像手脚麻利的年轻同事活能干完但细节需要有人盯。这个差异直接影响使用体验。让 DeepSeek 写代码它经常连“为什么”一起交代了我能在拿到代码的同时判断它适不适合当前项目MiMo 写得快但我需要自己检查它有没有忽略约束。这不是说哪种风格一定更好。如果你只需要快速拿到一段能用的代码MiMo 这种“少废话”的风格反而顺手如果你需要理解思路、判断取舍、甚至把代码讲给别人听DeepSeek 的完整度更舒服。我个人使用时把 DeepSeek 当“解题搭档”把 MiMo 当“打字机”前者用来讨论方案后者用来出初稿。5.3 速度与成本本地部署和 API 是两条不同的曲线DeepSeek 走官方 API实测首次 token 延迟在 0.5 到 1 秒之间整段回答 10 到 20 秒完成。费用方面两道题加上三轮追问总共二十多次调用API 花费不到一块钱对日常个人使用基本无感。MiMo 2.6 本地部署的体验比较看硬件。我在一张 24GB 显存的显卡上跑了 4bit 量化版显存占用大概 14GB 到 16GB首次 token 延迟在 1.2 到 1.8 秒之间比 DeepSeek 官方 API 稍慢。但如果跑 FP16 原版显存需求会拉到 20GB 以上很多 16GB 显卡就玩不转了。提示本地部署是一次性硬件投入之后不再按量付费。适合高频调用、数据敏感、需要完全离线使用的场景。但如果只是隔三差五写几段代码API 的按量付费反而更划算没必要为了低频使用去背一块显卡的成本。5.4 生态与接入成熟度差了一个身位DeepSeek 的生态明显更成熟官方 API 文档齐全IDE 插件、代理工具、各种工作流几乎都内置了支持很多第三方工具默认就能配好它的 base_url。MiMo 2.6 胜在开源可自托管数据不出本机也能做私有化微调但生态还在爬坡不少工具需要手动配。我的看法是如果你是个人用户想开箱即用DeepSeek 的生态能把接入成本压到最低如果你是企业或实验室对数据合规和模型定制有要求MiMo 2.6 这类可自托管的开源模型的优势就显现出来了。6. 实测中的常见问题和避坑实录6.1 对话达到上限后怎么让新对话“接上”旧对话测试过程中我遇到过 DeepSeek 提示“达到对话长度上限请开启新对话”的情况。这不是错误是上下文窗口满了旧消息被截断。要让新对话承接旧话题最实用的办法是把关键历史整理成一段“摘要”塞到新对话的第一条消息里。比如之前的题目要求、已经确认的方案、目前卡住的问题都压缩成几行附上现有代码模型就能无缝续上。在 API 里也是一样的逻辑不要在 messages 列表里无限追加消息而是定期把前面的内容压缩成一条 system 或 user 摘要再追加新的问答。这样做既能延续上下文又能避免请求过长触发超时。我自己的习惯是一旦当前对话接近上下文窗口的一半就手动整理一次摘要这是最稳的续接姿势。6.2 API 报错速查表对比测试期间我踩了不少 API 的坑整理成一张速查表都是高频问题报错特征大概率原因解决办法401 UnauthorizedAPI Key 填错或无效去控制台重新生成 Key检查是否有多余空格429 Rate Limit请求太频繁或余额不足降低并发检查余额或加退避重试400 context length exceeded输入太长超出模型窗口压缩历史消息或换更长上下文的模型版本响应被截断max_tokens 设置太小调大 max_tokens推理模型要留足思考空间request extension preparation failedIDE 扩展配置异常检查扩展的 base_url、模型名、端口重启扩展最后一个报错是我在测试 IDE 插件时遇到的定位后发现是插件配置里的模型名和本地服务不一致。如果你改过 vLLM 暴露的模型名记得在客户端同步修改。这类问题排查起来最费时间因为报错信息基本不指向真实原因。6.3 本地部署的显存与量化选择本地部署这类模型第一件事就是算显存。经验公式是 FP16 权重下模型权重显存大约是参数量的 2 倍比如一个 13B 左右的模型大概需要 26GB 权重显存再加上 KV cache 和运行开销24GB 显卡会非常紧张。所以我建议先上 4bit 量化比如 AWQ 或 GPTQ显存占用能降到四分之一左右代码生成的质量损失在实测里几乎看不出来。量化版在跑两道代码题时输出和 FP16 版本没有明显差异但因为显存占用低反而能开更大的并发。如果你只有 16GB 显卡量化后也能跑但窗口长度要调小比如 8192否则还是会爆显存。vLLM 配合量化模型是目前最省心的方案gpu-memory-utilization 建议给到 0.85 到 0.9别拉满。6.4 接入 IDE 的几个细节用了几轮之后我把两个模型都接进了常用 IDE。有几个细节必须提醒第一OpenAI 兼容接口的 base_url 末尾不要漏掉 /v1尤其是本地 vLLM 部署写成 http://localhost:8000/v1 才能被大多数插件识别漏了会报“连接失败”。第二用 CC Switch 这类工具在多个模型之间切换时一定要检查切换后 base_url 和 model 名是否还对应旧服务。我踩过一次切回 ChatGPT 后 model 名还留着 DeepSeek 的结果每次都报错排查了半小时才发现是配置残留。第三不要在同一个扩展里同时挂对话模型和推理模型。两种模型的 max_tokens 行为不同推理模型可能先输出几百上千字的思考过程如果插件把这段过程也算进代码上下文很容易把会话搞乱。7. 两道题之后我留下的选择思路两轮测试做完我的结论可能和你想的不太一样这两个模型的代码能力差距远没有跑分榜上看起来那么悬殊。真正的差异集中在“主动约束意识”和“工程稳健性”上。如果你写代码主要靠自己把关只是需要一个快速出活的工具MiMo 2.6 完全够用如果你希望模型像一个老练的同事把约束、边界和隐患都提前帮你想到DeepSeek 的体验会更省心。我个人现在的用法是混着来日常在 IDE 里刷题和写业务代码用 DeepSeek 的 API因为它生态成熟、解释清楚改起来快到了需要完全离线、批量生成代码这类不方便联网的场合就切到本地部署的 MiMo 2.6。这样两头的好处都能吃到。最后分享一个我常用的判断小技巧拿到任何一个新模型别急着看榜单直接拿一道带复杂度约束的算法题和一道带内存陷阱的语言题去问它各追问两轮。如果它能在提示下把 O(n log k) 改成 O(n)、把递归改成迭代这个模型写代码的底子就差不了。本文这两道题你也可以直接拿去测任何模型实测比任何参数表都有说服力。
最近组里在选代码模型MiMo 2.6 和 DeepSeek 是讨论最多的两个名字。一个主打轻量高效、开源可自托管一个是口碑稳定的实力派。光看跑分没意思我把它们拉到实际场景里用两道代码题硬碰硬测了一轮一道算法题一道 C 语言链表题考察的不只是“写不写得出来”还有复杂度控制、边界意识、代码完整度以及追问时的修正能力。这篇文章会把题目设计、测试环境、两边回答的全过程完整记录下来最后给出我留下的选择思路。如果你正在刷题、写竞赛代码、准备 C 语言期末或者要给团队挑编程助手这篇实测记录可以拿来直接当参考。1. 为什么偏要用“两道代码题”来选模型1.1 跑分再高不如现场写一段代码现在市面上的模型榜单HumanEval、MBPP 这类代码测试集已经被刷得很熟很多模型榜单分数接近实际用起来差别却不小。原因很简单榜单题目分布相对固定模型在训练时很可能见过同款或相似题等于开卷考试。真实场景是闭卷的——题目可能是新瓶装旧酒约束条件写得很含糊边界情况得靠模型自己想全。所以我在选型时不迷信榜单只做一件事把真实任务抛给模型看它从零开始怎么写。这次选的两道题不是随手抓的是我平时工作里经常遇到的两类任务一类是带明确复杂度要求的算法题测模型“会不会解”一类是考察语言功底和内存意识的 C 语言题测模型“写出来的代码能不能上生产”。两类题结合起来比单纯跑一个 benchmark 更能反映日常体验。1.2 第一道题滑动窗口最大值题目是 LeetCode 239 的原题给定一个整数数组和一个窗口大小 k输出每个窗口内的最大值要求时间复杂度 O(n)。题目看着普通实际上非常考验基础功知不知道“单调队列”这个数据结构能不能解释清楚为什么队首过期元素要淘汰、队尾遇到更大值时为什么要弹掉会不会主动处理 k1、k 等于数组长度、空数组这些边界给不给带测试用例的可运行代码。很多模型能写出能跑的代码但写不出 O(n) 的版本。这恰好能区分“背过题”和“真懂原理”的模型。1.3 第二道题C 语言单链表反转第二道题我选了单链表原地反转这是大学 C 语言期末和面试里出场率极高的题。题目本身不难但考点密集空链表和单节点链表能不能正确处理反转后头指针是否真的指向了原尾节点用迭代还是递归递归在处理长链表时有没有栈溢出风险有没有补全测试代码还是只甩一个函数就完事。这类题最能暴露模型对内存和运行时的理解。代码能跑只是及格分能解释清楚“为什么这样写更稳”才是加分项。1.4 我说的“选择”到底在选什么固定两道题之后我把最终对比拆成五个维度首答正确率、复杂度与健壮性、代码完整度、解释质量、追问表现。前四个是硬指标最后一个是软指标但恰恰是软指标最影响日常体验——因为真实开发很少一锤子买卖大多是“先给我一版我再让你改几轮”。2. 测试环境与参数设置2.1 两种接入方式官方 API 和本地部署为了公平我把两个模型都接到同一个格式的接口上测试。DeepSeek 走官方 APIMiMo 2.6 我用本地部署因为它的定位之一就是可自托管。两者都兼容 OpenAI 的接口格式所以客户端调用代码可以完全复用。DeepSeek 的调用长这样from openai import OpenAI client OpenAI( api_keysk-你的key, base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: user, content: 题目文本} ], temperature0.0, max_tokens2048 ) print(resp.choices[0].message.content)这里用的是 OpenAI SDK 兼容模式不是 DeepSeek 独有 SDK。这样切模型时只需要改 base_url 和 model 名其余一行不用动。对比测试时这个习惯能省很多事也能排除“因为客户端实现不同导致结果差异”的干扰。MiMo 2.6 本地部署我用的是 vLLM启动命令大概是这样vllm serve /path/to/MiMo-2.6-Instruct \ --served-model-name MiMo-2.6-Instruct \ --port 8000 \ --max-model-len 32768 \ --gpu-memory-utilization 0.85启动后客户端只需要把 base_url 换成 http://localhost:8000/v1model 换成 MiMo-2.6-Instruct。注意 --served-model-name 这个参数如果你改了对外暴露的模型名客户端配置里必须同步修改否则会报 model not found。2.2 参数设置代码题不能乱开“想象力”代码生成和写诗不一样temperature 必须压住。我这两轮把两个模型的 temperature 都设成 0.0让输出尽量确定。max_tokens 给到 2048防止代码太长被截断。提示用推理模型和用对话模型是两套配置。DeepSeek 的 deepseek-reasoner 会在正式回答前输出一大段思考过程如果你还按普通对话模型的 max_tokens 设置很容易被截断。我第一轮就把两边的模型配置搞混了导致 DeepSeek 的回答被截掉一段后来才发现是模型名填错了。对比测试前一定确认你调的是对话模型还是推理模型。评测过程我记录了四个数据首次返回第一个 token 的延迟、整段回答的总耗时、输出 token 数以及从第一问到追问第三轮时模型的表现变化。2.3 我遇到的第一个环境坑本地部署 MiMo 2.6 时我一开始用原生推理加载 FP16 权重24GB 显存勉强能放下但并发一高就明显变卡。换成 vLLM 之后吞吐改善很多但第一次请求的首 token 延迟反而略高因为 vLLM 启动后有 prefill 优化和显存预热的过程。如果你只是单机自己用这点差异无所谓如果是多人共用一个推理服务vLLM 的收益非常明显。3. 第一道题实测滑动窗口最大值3.1 题目与评分标准题目原文我给两个模型都是同一句“给你一个整数数组 nums 和一个整数 k有一个大小为 k 的滑动窗口从数组的最左侧移动到最右侧只可以看到窗口中的 k 个数字窗口每次向右移动一位。返回滑动窗口中的最大值数组。要求设计一个时间复杂度为 O(n) 的算法。”评分标准分四块代码是否运行正确、是否严格满足 O(n)、边界情况是否处理、讲解是否把单调队列原理讲透。测试用例我用的是经典例子nums [1,3,-1,-3,5,3,6,7]k 3期望输出是 [3,3,5,5,6,7]。3.2 DeepSeek 的回答一步到位的最优解DeepSeek 这次用的是 deepseek-chat 对话模型不是推理模型但回答质量很高。它先讲了一段思路维护一个单调递减的双端队列队列里存索引而不是值这样既能快速拿到窗口最大值又能通过索引判断元素是否过期。然后给出代码from collections import deque def max_sliding_window(nums, k): dq deque() res [] for i, v in enumerate(nums): # 过期的索引从队首淘汰 if dq and dq[0] i - k: dq.popleft() # 队尾所有小于等于当前值的索引都没用了 while dq and nums[dq[-1]] v: dq.pop() dq.append(i) # 窗口形成后队首就是当前窗口最大值 if i k - 1: res.append(nums[dq[0]]) return res我直接跑了一遍输出和期望完全一致。更意外的是它对边界处理很完整k1 时每个元素都是独立窗口的最大值k 等于数组长度时只有一个窗口空数组直接返回空列表。它还专门解释了为什么要用索引而不是值因为窗口滑动时要判断哪些元素已经“滑出去了”只看值判断不了。3.3 MiMo 2.6 的回答能跑但第一次没达标MiMo 2.6 第一轮给出的是最大堆方案思路是维护一个大小为 k 的堆窗口右移时把新元素推进去再把堆顶不在窗口内的元素弹出。代码长这样import heapq def max_sliding_window(nums, k): if not nums: return [] heap [(-nums[i], i) for i in range(k)] heapq.heapify(heap) res [-heap[0][0]] for i in range(k, len(nums)): heapq.heappush(heap, (-nums[i], i)) while heap and heap[0][1] i - k: heapq.heappop(heap) res.append(-heap[0][0]) return res这段代码也是对的用最大堆取窗口最大值弹出的都是过期索引输出结果和期望完全一致。但它不满足题目的硬性要求堆操作的单次复杂度是 O(log k)整体是 O(n log k)不是 O(n)。题目里白纸黑字写了“要求设计一个时间复杂度为 O(n) 的算法”MiMo 第一轮没有主动往这个方向靠而是选了它认为最稳妥的常规解法。随后我追加了一句“题目要求 O(n)能不能用双端队列优化到线性复杂度”它立刻给出了和 DeepSeek 几乎一样的单调队列方案并正确解释了头尾维护逻辑。这说明它具备生成最优解的能力但在第一次回答时没有把“题目要求”当作最优先约束去自我检查。3.4 第一轮判分差距不在正确率在“约束意识”第一轮打分如下维度MiMo 2.6DeepSeek首答正确性8/10正确但非最优10/10复杂度控制6/1010/10边界处理8/109/10解释清晰度7/109/10追问后修复9/109/10如果只看“能不能跑出正确答案”两个模型几乎没差别heap 方案在数据量不大的时候甚至更直观。但真实场景里题目要求 O(n) 就是硬约束一个模型如果不主动检查约束你很容易在不知不觉中拿到一版“性能不达标但能跑”的代码。这就是我常说的“约束意识”模型不能只会解题还得懂题目的考点在哪。4. 第二道题实测C 语言单链表反转4.1 题目与隐藏考点第二道题的原文也很简单“用 C 语言实现单链表的原地反转函数返回反转后的新头结点并给出测试代码。链表节点定义为 struct ListNode { int val; struct ListNode *next; }。”这类题在期末和面试里出现频率极高但很多人栽在同一个点上递归解法看起来简洁实际在长链表上会爆栈。C 语言期末考试一般不会用几十万个节点的链表去测所以递归能骗过评测系统但到了真实工程里一个百万节点链表就能让程序直接段错误。4.2 MiMo 2.6 的解法简洁但埋了隐患MiMo 2.6 给的解法是递归代码非常短struct ListNode* reverseList(struct ListNode* head) { if (head NULL || head-next NULL) { return head; } struct ListNode* newHead reverseList(head-next); head-next-next head; head-next NULL; return newHead; }思路没问题先反转后面的链表再把当前节点的下一个节点的 next 指向当前节点最后把当前节点的 next 置空。空链表和单节点链表都在递归出口覆盖了。它还补了一个 main 函数创建 5 个节点的链表反转后逐节点打印 val能编译能运行。我给它的扣分点在最后一句解释里。我问它“如果这个链表有 100 万个节点这段代码会怎样”它承认递归深度会达到 100 万层超过默认栈空间程序会崩溃。也就是说它是知道风险的但写代码时没有主动选择更稳妥的迭代方案而是选了“看起来更优雅”的递归。这恰好是编程里最危险的一种选择数据量小时没事数据量大时才炸。4.3 DeepSeek 的解法直接选了工程上更稳的迭代DeepSeek 第一轮直接给的是迭代解法三个指针 prev、curr、next 轮转struct ListNode* reverseList(struct ListNode* head) { struct ListNode *prev NULL; struct ListNode *curr head; while (curr ! NULL) { struct ListNode *next curr-next; curr-next prev; prev curr; curr next; } return prev; }解释逻辑很清晰每次循环把当前节点的指针反转三个指针整体右移循环结束后 prev 指向原链表的尾节点也就是新链表的头。它还特意说明迭代只用 O(1) 额外空间不存在递归深度问题。我追问“百万节点会怎样”它直接说迭代解法没有栈溢出风险唯一要注意的是链表本身不能有环否则会死循环。这个回答很专业因为链表反转确实要警惕环的存在。4.4 追问三轮后的表现差异第二题我追问了三个问题记录下来的差异很有意思。第一个追问是“怎么验证反转结果是对的”。DeepSeek 建议用断言思路反转前记录原链表尾节点反转后检查它是不是新链表头再遍历一遍确认长度不变、顺序逆序。MiMo 第一反应是“打印出来看看”在我追问“有没有更自动化的验证”之后才补上和 DeepSeek 类似的遍历验证方案。第二个追问是“如果链表是循环链表会怎样”。DeepSeek 立刻指出迭代法会陷入死循环建议测试时限制节点数量或先判环。MiMo 犹豫了一下先说“可以在循环里加计数器超过节点数就退出”后来才补上判环方案。对比下来DeepSeek 应对异常场景时知识组织得更靠前MiMo 需要被提示一下才能调出来。第三个追问是“能不能同时给出递归和迭代两个版本”。两边都很快给出了MiMo 给出的迭代版明显是在递归版基础上改进的说明它确实理解了迭代思路不是背模板。这一点我觉得很加分一个模型在被追问时能不能真正修正自己的初始方案比它第一次给什么更重要。5. 两道题放在一起看五个维度的真实差异5.1 首答质量的差距有但没有想象中悬殊两轮测试跑完我把结果汇总过一遍对比维度MiMo 2.6DeepSeek首答正确率高但追求“能跑”而非“最优”高且主动满足题目约束复杂度与健壮性需要追问才能暴露隐患首答就主动规避代码完整度有测试代码但偏“演示”有测试思路偏“验证”解释质量简洁结论多结构清晰过程完整追问后表现能改但需要引导基本不需要引导结论很直白如果只比第一次回答差距集中在“主动性和工程意识”上不是“会不会写”。MiMo 2.6 能写出对的递归链表反转也能在提示后改成迭代DeepSeek 是一开始就写迭代。同样地MiMo 第一次给的滑动窗口是 O(n log k)提示之后才换成 O(n)DeepSeek 第一次就是 O(n)。5.2 推理风格一个像讲解员一个像快枪手用一句糙话总结DeepSeek 像带徒弟的老师傅先讲思路再写代码最后还要补一句边界注意MiMo 2.6 像手脚麻利的年轻同事活能干完但细节需要有人盯。这个差异直接影响使用体验。让 DeepSeek 写代码它经常连“为什么”一起交代了我能在拿到代码的同时判断它适不适合当前项目MiMo 写得快但我需要自己检查它有没有忽略约束。这不是说哪种风格一定更好。如果你只需要快速拿到一段能用的代码MiMo 这种“少废话”的风格反而顺手如果你需要理解思路、判断取舍、甚至把代码讲给别人听DeepSeek 的完整度更舒服。我个人使用时把 DeepSeek 当“解题搭档”把 MiMo 当“打字机”前者用来讨论方案后者用来出初稿。5.3 速度与成本本地部署和 API 是两条不同的曲线DeepSeek 走官方 API实测首次 token 延迟在 0.5 到 1 秒之间整段回答 10 到 20 秒完成。费用方面两道题加上三轮追问总共二十多次调用API 花费不到一块钱对日常个人使用基本无感。MiMo 2.6 本地部署的体验比较看硬件。我在一张 24GB 显存的显卡上跑了 4bit 量化版显存占用大概 14GB 到 16GB首次 token 延迟在 1.2 到 1.8 秒之间比 DeepSeek 官方 API 稍慢。但如果跑 FP16 原版显存需求会拉到 20GB 以上很多 16GB 显卡就玩不转了。提示本地部署是一次性硬件投入之后不再按量付费。适合高频调用、数据敏感、需要完全离线使用的场景。但如果只是隔三差五写几段代码API 的按量付费反而更划算没必要为了低频使用去背一块显卡的成本。5.4 生态与接入成熟度差了一个身位DeepSeek 的生态明显更成熟官方 API 文档齐全IDE 插件、代理工具、各种工作流几乎都内置了支持很多第三方工具默认就能配好它的 base_url。MiMo 2.6 胜在开源可自托管数据不出本机也能做私有化微调但生态还在爬坡不少工具需要手动配。我的看法是如果你是个人用户想开箱即用DeepSeek 的生态能把接入成本压到最低如果你是企业或实验室对数据合规和模型定制有要求MiMo 2.6 这类可自托管的开源模型的优势就显现出来了。6. 实测中的常见问题和避坑实录6.1 对话达到上限后怎么让新对话“接上”旧对话测试过程中我遇到过 DeepSeek 提示“达到对话长度上限请开启新对话”的情况。这不是错误是上下文窗口满了旧消息被截断。要让新对话承接旧话题最实用的办法是把关键历史整理成一段“摘要”塞到新对话的第一条消息里。比如之前的题目要求、已经确认的方案、目前卡住的问题都压缩成几行附上现有代码模型就能无缝续上。在 API 里也是一样的逻辑不要在 messages 列表里无限追加消息而是定期把前面的内容压缩成一条 system 或 user 摘要再追加新的问答。这样做既能延续上下文又能避免请求过长触发超时。我自己的习惯是一旦当前对话接近上下文窗口的一半就手动整理一次摘要这是最稳的续接姿势。6.2 API 报错速查表对比测试期间我踩了不少 API 的坑整理成一张速查表都是高频问题报错特征大概率原因解决办法401 UnauthorizedAPI Key 填错或无效去控制台重新生成 Key检查是否有多余空格429 Rate Limit请求太频繁或余额不足降低并发检查余额或加退避重试400 context length exceeded输入太长超出模型窗口压缩历史消息或换更长上下文的模型版本响应被截断max_tokens 设置太小调大 max_tokens推理模型要留足思考空间request extension preparation failedIDE 扩展配置异常检查扩展的 base_url、模型名、端口重启扩展最后一个报错是我在测试 IDE 插件时遇到的定位后发现是插件配置里的模型名和本地服务不一致。如果你改过 vLLM 暴露的模型名记得在客户端同步修改。这类问题排查起来最费时间因为报错信息基本不指向真实原因。6.3 本地部署的显存与量化选择本地部署这类模型第一件事就是算显存。经验公式是 FP16 权重下模型权重显存大约是参数量的 2 倍比如一个 13B 左右的模型大概需要 26GB 权重显存再加上 KV cache 和运行开销24GB 显卡会非常紧张。所以我建议先上 4bit 量化比如 AWQ 或 GPTQ显存占用能降到四分之一左右代码生成的质量损失在实测里几乎看不出来。量化版在跑两道代码题时输出和 FP16 版本没有明显差异但因为显存占用低反而能开更大的并发。如果你只有 16GB 显卡量化后也能跑但窗口长度要调小比如 8192否则还是会爆显存。vLLM 配合量化模型是目前最省心的方案gpu-memory-utilization 建议给到 0.85 到 0.9别拉满。6.4 接入 IDE 的几个细节用了几轮之后我把两个模型都接进了常用 IDE。有几个细节必须提醒第一OpenAI 兼容接口的 base_url 末尾不要漏掉 /v1尤其是本地 vLLM 部署写成 http://localhost:8000/v1 才能被大多数插件识别漏了会报“连接失败”。第二用 CC Switch 这类工具在多个模型之间切换时一定要检查切换后 base_url 和 model 名是否还对应旧服务。我踩过一次切回 ChatGPT 后 model 名还留着 DeepSeek 的结果每次都报错排查了半小时才发现是配置残留。第三不要在同一个扩展里同时挂对话模型和推理模型。两种模型的 max_tokens 行为不同推理模型可能先输出几百上千字的思考过程如果插件把这段过程也算进代码上下文很容易把会话搞乱。7. 两道题之后我留下的选择思路两轮测试做完我的结论可能和你想的不太一样这两个模型的代码能力差距远没有跑分榜上看起来那么悬殊。真正的差异集中在“主动约束意识”和“工程稳健性”上。如果你写代码主要靠自己把关只是需要一个快速出活的工具MiMo 2.6 完全够用如果你希望模型像一个老练的同事把约束、边界和隐患都提前帮你想到DeepSeek 的体验会更省心。我个人现在的用法是混着来日常在 IDE 里刷题和写业务代码用 DeepSeek 的 API因为它生态成熟、解释清楚改起来快到了需要完全离线、批量生成代码这类不方便联网的场合就切到本地部署的 MiMo 2.6。这样两头的好处都能吃到。最后分享一个我常用的判断小技巧拿到任何一个新模型别急着看榜单直接拿一道带复杂度约束的算法题和一道带内存陷阱的语言题去问它各追问两轮。如果它能在提示下把 O(n log k) 改成 O(n)、把递归改成迭代这个模型写代码的底子就差不了。本文这两道题你也可以直接拿去测任何模型实测比任何参数表都有说服力。
