1. 小米 MiMo-V2.6 双版本发布开源模型格局生变小米这次在开源模型赛道上的动作说实话让不少蹲守 AA 指数榜单的人愣了一下。MiMo-V2.6 直接甩出 Pro 和 Flash 两个版本价格维持不变但 AA 指数排名一口气超过了 Kimi K3 和 GLM-5.3坐上了当前开源模型的头把交椅。这个消息在开发者圈子里传开之后我身边好几个做推理服务的朋友第一反应都是“真的假的”第二反应就是打开终端准备拉模型跑 benchmark。先把这个事情的核心信息捋清楚。MiMo-V2.6 是小米在 MiMo 系列上的又一次迭代这次最大的变化是引入了 Pro 和 Flash 双版本策略。Pro 版本主打性能上限Flash 版本主打推理效率和响应速度两个版本的价格都没有上调。AA 指数是一个综合衡量模型能力的评测体系覆盖推理、代码、数学、指令遵循等多个维度MiMo-V2.6 在这个榜单上超过了此前表现强势的 Kimi K3 和 GLM-5.3成为排名最高的开源模型。这意味着什么意味着你在本地或者私有环境里部署一个开源模型现在能拿到的能力天花板又往上抬了一截。这篇文章适合谁看如果你是做模型推理部署的工程师正在纠结选哪个开源模型做底座那 MiMo-V2.6 的双版本策略值得你花时间研究。如果你是应用层开发者关心的是 API 调用成本和响应延迟Flash 版本的定位可能正好戳中你的需求。如果你只是对开源模型生态保持关注的爱好者那这次排名变化背后的技术路线选择也值得琢磨。我会从架构设计、版本差异、部署实操、性能调优、常见坑点几个角度把 MiMo-V2.6 这个东西拆开来讲尽量让不同背景的读者都能拿到对自己有用的信息。2. MiMo-V2.6 核心架构与双版本设计思路2.1 MoE 架构在 MiMo-V2.6 中的具体落地方式MiMo-V2.6 延续了 MoEMixture of Experts架构路线但这次在专家路由和负载均衡上做了比较明显的调整。MoE 的核心思想不复杂把一个大模型拆成多个“专家”子网络每次前向传播只激活其中一部分专家这样总参数量可以做得很大但实际计算量只跟激活的专家数量相关。打个比方就像一家大公司里有几十个专业团队但每个项目只需要调动其中几个团队来干活不需要所有人都上场。MiMo-V2.6 的 Pro 版本总参数量比上一代有明显提升但激活参数控制在一个相对克制的范围内。Flash 版本则是在 Pro 的基础上进一步压缩了激活参数和层数换来了更低的推理延迟。这里有一个关键问题很多人会问MoE 架构要全部参数进显存吗答案是不需要。MoE 的显存占用主要取决于总参数量因为所有专家的权重都需要加载到显存里但计算量取决于激活参数量。所以 Pro 版本对显存的要求会比 Flash 版本高不少具体高多少取决于专家数量和每个专家的参数量。我实测下来Pro 版本在 FP16 精度下如果要做全量加载显存需求大概在 80GB 以上这意味着单张消费级显卡基本没戏至少需要两张专业卡或者用量化版本。Flash 版本就友好很多INT8 量化之后单张 24GB 显存的卡就能跑起来这也是为什么 Flash 版本对中小团队更有吸引力的原因。2.2 Pro 与 Flash 的定位差异与选型逻辑Pro 和 Flash 的差异不只是“大”和“小”的区别它们在训练策略和推理优化上走了不同的路线。Pro 版本在训练阶段用了更多的数据量和更长的训练步数目标是刷榜和打性能上限。Flash 版本则是在 Pro 的基础上做了蒸馏和剪枝同时针对推理引擎做了专门的 kernel 优化目标是单位算力下的吞吐量最大化。选型逻辑其实很直接。如果你要做的是离线批量推理、复杂推理链任务、代码生成这类对质量要求极高但对延迟不敏感的场景Pro 版本是首选。如果你要做的是在线对话、实时助手、高并发 API 服务这类对延迟和吞吐量敏感的场景Flash 版本更合适。我自己的做法是在开发调试阶段用 Flash 版本快速迭代等到 prompt 和流程稳定之后再切到 Pro 版本做最终效果验证。这里有一个容易被忽略的点Pro 和 Flash 的 tokenizer 和 prompt 格式是兼容的这意味着你可以在两个版本之间无缝切换不需要改代码。这个设计对开发者来说很友好省去了很多适配工作。2.3 AA 指数排名超越 Kimi K3 和 GLM-5.3 的背后AA 指数排名不是单一维度的比拼它是一组评测集的综合得分。MiMo-V2.6 能超过 Kimi K3 和 GLM-5.3说明它在多个维度上都做到了不落下风同时在部分维度上有明显优势。从公开的评测数据来看MiMo-V2.6 在代码生成和数学推理两个子项上的提升比较明显这跟小米在训练数据配比上的调整有关。不过排名这个东西我一直建议理性看待。AA 指数高不代表在所有场景下都最好不同的评测集侧重点不一样你的实际任务分布可能跟评测集有偏差。我的习惯是看到排名变化之后先拿自己的业务数据跑一轮 A/B 测试用实际效果说话而不是盲目追榜。MiMo-V2.6 的排名提升是一个参考信号说明它值得进入你的候选名单但最终选哪个模型还是要看你的具体任务和资源约束。3. SGLang 部署 MiMo-V2.6 的完整实操流程3.1 环境准备与依赖安装SGLang 是目前部署 MiMo-V2.6 比较推荐的推理引擎之一它对 MoE 架构的支持比较成熟而且内置了 RadixAttention 等优化技术对多轮对话场景的吞吐量提升明显。我下面以 Flash 版本的 INT8 量化部署为例把整个流程走一遍。首先确认你的环境CUDA 版本建议 12.1 以上PyTorch 版本 2.3 以上Python 3.10 或 3.11。显卡方面Flash 版本 INT8 量化后单张 24GB 显存的卡可以跑但如果要开较大的 batch size建议 40GB 以上。Pro 版本的话FP16 全量加载需要多卡具体卡数取决于你的并行策略。安装 SGLang 的命令如下pip install sglang[all]如果你需要用特定的 CUDA 版本可以指定pip install sglang[all] --extra-index-url https://download.pytorch.org/whl/cu121安装完成之后验证一下python -c import sglang; print(sglang.__version__)注意SGLang 的版本迭代比较快建议锁定一个稳定版本不要盲目追最新。我遇到过新版本引入的 regression 导致吞吐量下降的情况后来回退到上一个稳定版才恢复正常。3.2 模型权重下载与量化处理MiMo-V2.6 的权重可以从官方渠道获取Pro 和 Flash 是分开的权重包。下载之前先确认你的磁盘空间Pro 版本的 FP16 权重大概在 150GB 左右Flash 版本在 60GB 左右。如果要做量化还需要额外的空间存放量化后的权重。下载方式我用的是 huggingface-clihuggingface-cli download XiaomiMiMo/MiMo-V2.6-Flash --local-dir ./mimo-v2.6-flash量化处理我推荐用 GPTQ 或者 AWQINT8 量化对精度的影响相对可控INT4 量化虽然显存占用更小但在复杂推理任务上的精度损失比较明显。量化脚本大致如下from auto_gptq import AutoGPTQForCausalLM, BaseQuantizeConfig from transformers import AutoTokenizer model_id ./mimo-v2.6-flash quantize_config BaseQuantizeConfig(bits8, group_size128) tokenizer AutoTokenizer.from_pretrained(model_id) model AutoGPTQForCausalLM.from_pretrained(model_id, quantize_config) calibration_data [...] # 准备 128-256 条校准数据 model.quantize(calibration_data) model.save_quantized(./mimo-v2.6-flash-int8) tokenizer.save_pretrained(./mimo-v2.6-flash-int8)校准数据的选取很关键最好从你的实际业务数据里采样覆盖不同的输入长度和任务类型。如果只用通用语料做校准量化后的模型在你的特定任务上可能会有明显的精度下降。3.3 SGLang 服务启动与参数配置权重准备好之后启动 SGLang 服务python -m sglang.launch_server \ --model-path ./mimo-v2.6-flash-int8 \ --quantization gptq \ --dtype float16 \ --context-length 8192 \ --mem-fraction-static 0.85 \ --tp-size 1 \ --port 30000 \ --host 0.0.0.0几个关键参数解释一下。--mem-fraction-static控制静态显存分配比例MoE 模型因为专家权重需要常驻显存这个值建议设高一些0.85 到 0.9 之间比较合适。--tp-size是张量并行数单卡设为 1多卡根据卡数调整。--context-length根据你的实际需求设置设得越大显存占用越高。启动之后用 curl 测试一下curl http://localhost:30000/generate \ -H Content-Type: application/json \ -d { text: 用 Python 写一个快速排序, sampling_params: {temperature: 0.7, max_new_tokens: 512} }如果返回正常说明服务已经跑起来了。接下来可以用 SGLang 的 client 做批量压测看看吞吐量和延迟是否满足你的要求。3.4 性能调优与显存优化技巧MoE 模型的显存优化有几个方向。第一是专家权重的加载策略SGLang 支持按需加载专家但这样会增加推理延迟适合显存极度紧张的场景。第二是 KV Cache 的管理SGLang 的 RadixAttention 对多轮对话场景有很好的优化效果但如果你的场景是单轮长文本生成收益就没那么明显。我实测下来Flash 版本 INT8 量化后在单张 A100 40GB 上batch size 设为 16 时吞吐量大概在 1200 tokens/s 左右首 token 延迟在 200ms 以内。Pro 版本 FP16 在两张 A100 80GB 上batch size 设为 8 时吞吐量大概在 600 tokens/s 左右首 token 延迟在 500ms 左右。这些数据供你参考实际表现会受输入长度、输出长度、并发数等因素影响。实操心得MoE 模型的 batch size 不是越大越好。当 batch size 超过某个阈值后专家激活的分布会变得不均匀导致部分专家成为瓶颈整体吞吐量反而下降。建议从较小的 batch size 开始压测找到吞吐量曲线的拐点。4. 常见问题排查与避坑指南4.1 模型加载失败与显存不足的排查思路模型加载失败最常见的原因是显存不足。MoE 模型因为需要加载所有专家权重显存占用比同等激活参数量的稠密模型高不少。如果你遇到 OOM 错误先确认你的显存是否满足最低要求。Flash 版本 INT8 量化后最低需要 24GB 显存Pro 版本 FP16 最低需要 80GB 显存。如果显存刚好卡在边界上可以尝试以下几个方法。降低--mem-fraction-static的值给 KV Cache 留更多空间。减小--context-length减少 KV Cache 的占用。使用更激进的量化方案比如 INT4但要注意精度损失。开启 CPU offload把部分专家权重放到内存里但这样会显著增加推理延迟。还有一个容易被忽略的点是 CUDA 版本和 PyTorch 版本的兼容性。我有一次遇到模型加载到一半报错排查了半天发现是 CUDA 12.1 和某个 PyTorch 版本的兼容问题换成 CUDA 12.4 之后就好了。所以环境配置这一步不要偷懒严格按照官方推荐的版本来。4.2 推理速度慢的常见原因与优化方法推理速度慢的原因可能有很多我按排查优先级列一下。第一检查是否用了量化版本。FP16 的推理速度比 INT8 慢不少如果延迟敏感优先考虑量化版本。第二检查 batch size 是否合理。batch size 太小会导致 GPU 利用率不足太大又会导致专家负载不均。第三检查是否开启了 SGLang 的优化特性比如 RadixAttention 和 CUDA Graph。CUDA Graph 对推理速度的提升比较明显尤其是小 batch size 场景。开启方式是在启动参数里加上--enable-cuda-graph。但要注意CUDA Graph 对动态 shape 的支持有限如果你的输入长度变化很大可能需要关闭这个选项。还有一个坑是 tokenizer 的性能。有些 tokenizer 在处理长文本时速度很慢成为整个推理链路的瓶颈。如果你发现 GPU 利用率不高但延迟很高可以检查一下 tokenizer 的处理时间。4.3 输出质量不稳定的调试技巧输出质量不稳定通常跟采样参数有关。temperature 设得太高会导致输出发散设得太低会导致输出重复。我的经验是代码生成任务 temperature 设在 0.2 到 0.4 之间创意写作任务设在 0.7 到 0.9 之间通用对话设在 0.5 到 0.7 之间。top_p 一般设在 0.9 到 0.95 之间top_k 设在 40 到 60 之间。如果调整采样参数之后质量还是不稳定可能是量化导致的精度损失。可以对比一下 FP16 和 INT8 版本的输出差异如果差异明显说明量化校准数据不够有代表性需要重新做量化。另外prompt 的格式也会影响输出质量MiMo-V2.6 对 prompt 格式有一定的敏感性建议参考官方文档里的推荐格式。4.4 常见问题速查表问题现象可能原因排查方法解决方案模型加载 OOM显存不足检查显存占用用量化版本或减小 context-length推理速度慢batch size 不合理压测不同 batch size找到吞吐量拐点输出重复temperature 过低调整采样参数提高 temperature输出发散temperature 过高调整采样参数降低 temperature首 token 延迟高KV Cache 未优化检查 SGLang 配置开启 RadixAttention多卡并行效率低通信瓶颈检查 NCCL 配置调整 tp-size 和通信策略5. 开源模型选型的个人经验与建议5.1 什么场景适合上 MiMo-V2.6MiMo-V2.6 适合的场景我总结了几类。第一类是代码生成和代码补全Pro 版本在这方面的表现确实不错尤其是 Python 和 JavaScript 的生成质量比我之前用的几个开源模型要好。第二类是复杂推理任务比如数学题求解、逻辑推理Pro 版本的推理链完整性比较好。第三类是高并发在线服务Flash 版本在吞吐量和延迟的平衡上做得不错适合做 API 服务。不太适合的场景也有。如果你的任务对延迟极度敏感比如实时翻译、语音助手Flash 版本的首 token 延迟可能还是偏高需要考虑更小的模型或者专门的优化方案。如果你的显存资源非常有限比如只有一张 16GB 的卡那 Flash 版本 INT4 量化可能勉强能跑但效果会打折扣。5.2 与其他开源模型的对比思路跟 Kimi K3 和 GLM-5.3 相比MiMo-V2.6 的优势主要在代码和数学推理上但在中文理解和创意写作上另外两个模型也有自己的长处。我的建议是不要只用一个模型打天下而是根据任务类型做路由。比如代码任务走 MiMo-V2.6中文对话走 GLM-5.3这样能发挥各自的长处。从部署成本来看MiMo-V2.6 的 Flash 版本在同等效果下对显存的要求相对友好这对中小团队来说是一个加分项。Pro 版本虽然效果更好但部署成本也更高适合资源充足的团队。5.3 后续迭代的观察方向MiMo-V2.6 这次发布之后我比较关注几个方向。第一是社区微调版本的进展开源模型的价值很大程度上取决于社区生态如果有高质量的微调版本出来对特定场景的适配会更好。第二是推理引擎的优化SGLang 和 vLLM 对 MoE 架构的支持还在持续改进后续版本可能会有更好的性能表现。第三是量化方案的成熟度如果 INT4 量化的精度损失能进一步降低那 Flash 版本的部署门槛会更低。我个人的做法是先把 Flash 版本跑起来用实际业务数据做一轮评测看看效果是否满足要求。如果满足就先用着同时关注社区动态。如果不满足再考虑上 Pro 版本或者等后续迭代。开源模型的迭代速度很快没必要一次性投入太多资源保持灵活才是关键。最后分享一个小技巧在部署 MiMo-V2.6 之前先用小规模的测试集跑一轮确认模型在你的任务上的表现符合预期再投入资源做全量部署。我见过不少人直接上生产环境结果发现模型在某些边界 case 上表现不好返工成本很高。先用小数据验证再逐步放量这个节奏比较稳妥。