1. 小米 MiMo-V2.6 到底更新了什么小米这次把 MiMo-V2.6 端出来最抓眼球的信息其实就两条一是 Pro 和 Flash 两个版本价格没动二是它在 AA 指数上把 Kimi K3、GLM-5.3 都压了下去成了当前排名最高的开源模型。我第一时间去翻了技术报告和社区里的实测帖发现这次升级不是简单堆参数而是把 MoE 架构的负载均衡策略和推理框架 SGLang 的适配做了深度打磨。先说清楚 MiMo-V2.6 是什么。它是小米开源的多模态大模型系列最新版延续了 MoE混合专家架构总参数量比上一代有提升但激活参数控制得很克制。Pro 版本面向复杂推理、长上下文和代码生成场景Flash 版本主打低延迟、高并发适合线上服务。两个版本价格不变意味着每百万 token 的推理成本跟 V2.5 持平但能力上去了这对做应用落地的团队来说是很实在的利好。AA 指数Artificial Analysis Intelligence Index是第三方评测机构 Artificial Analysis 维护的综合能力榜单覆盖推理、数学、代码、指令遵循等多个维度。MiMo-V2.6 在这个榜单上超过 Kimi K3 和 GLM-5.3说明它在通用任务上的均衡性做得不错。不过要注意AA 指数是综合分不代表每个单项都领先具体场景还得看细分评测。适合谁来关注这个模型如果你是做 AI 应用开发的尤其是需要控制推理成本、又要保证输出质量的团队MiMo-V2.6 值得放进候选池。如果你是在研究 MoE 架构和推理优化的工程师它的负载均衡实现和 SGLang 集成细节也有不少可借鉴的地方。哪怕你只是普通用户想了解当前开源模型的第一梯队是什么水平这篇也能帮你建立基本认知。2. MoE 架构与 SGLang 推理框架的核心细节2.1 MoE 架构为什么成了大模型的主流选择MoE 的核心思路是把一个大模型拆成多个“专家”子网络每次推理只激活其中一部分。这样做的好处很直接总参数量可以做得很大但实际计算量只跟激活参数相关。举个例子一个总参数 100B 的 MoE 模型如果每次只激活 10B 参数那推理成本就接近一个 10B 的稠密模型但知识容量却接近 100B 模型。MiMo-V2.6 的 MoE 设计里有几个关键点值得注意。第一是专家粒度的划分它没有把专家切得太细因为专家太多会导致路由网络难以训练负载均衡也更容易出问题。第二是路由策略它用了可学习的门控网络配合负载均衡损失来防止某些专家被过度激活。第三是共享专家机制一部分专家对所有 token 都激活负责通用知识另一部分专家按需激活负责特定领域。这里要回答一个热词里经常被问到的问题MoE 架构要全部参数进显存吗答案是训练时通常需要因为反向传播要更新所有专家但推理时不一定取决于推理框架的实现。如果框架支持专家并行和动态加载可以把不常用的专家放在 CPU 内存或磁盘上需要时再换入显存。不过这样做会增加延迟所以实际部署中常见做法还是把常用专家常驻显存冷门专家按需调度。2.2 SGLang 在 MiMo-V2.6 里扮演了什么角色SGLang 是一个面向大模型推理的高性能框架核心优势在于 RadixAttention 和前缀缓存。RadixAttention 用基数树管理 KV 缓存多个请求如果共享相同的前缀就能复用缓存不用重复计算。这对多轮对话、few-shot 提示这类场景提升非常明显。MiMo-V2.6 对 SGLang 做了深度适配主要体现在几个方面。一是 MoE 层的专家并行策略跟 SGLang 的调度器打通了可以根据请求的 token 分布动态调整专家分配。二是 Flash 版本针对 SGLang 的连续批处理做了优化在高并发下吞吐量比 V2.5 有提升。三是 Pro 版本的长上下文场景下SGLang 的前缀缓存能有效降低首 token 延迟。如果你打算自己部署 MiMo-V2.6SGLang 是目前比较推荐的选择。它的安装和启动流程不算复杂但有几个参数需要根据你的硬件调整。比如--tp-size控制张量并行度--ep-size控制专家并行度这两个参数设不好要么显存不够要么通信开销过大。2.3 双版本策略背后的产品逻辑Pro 和 Flash 双版本不是小米首创但 MiMo-V2.6 把两者的定位分得很清楚。Pro 版本激活参数更多推理层数更深适合需要多步推理、代码生成、复杂指令遵循的任务。Flash 版本激活参数少层数浅但推理速度快适合分类、抽取、简单问答这类任务。价格不变这个点很关键。很多模型升级后会涨价因为训练成本高了。小米这次保持价格说明它在训练效率和推理优化上做了功课把成本控制住了。对开发者来说这意味着你可以用同样的预算跑更多的请求或者把省下来的钱用在其他环节。从选型角度看如果你的应用场景对延迟敏感比如实时客服、在线翻译Flash 版本更合适。如果是对质量要求高、可以接受稍高延迟的场景比如法律文书分析、复杂代码生成Pro 版本更值得选。两个版本可以混用比如用 Flash 做意图识别用 Pro 做最终回答生成这样兼顾速度和质量的思路在实际项目里很常见。3. 实操部署与核心环节实现3.1 环境准备与依赖安装部署 MiMo-V2.6 之前先确认硬件条件。Pro 版本建议至少 4 张 80G 显存的卡Flash 版本 2 张 80G 卡可以跑起来。如果显存不够可以考虑量化版本但量化会带来一定的精度损失需要根据业务容忍度权衡。软件环境方面Python 版本建议 3.10 以上CUDA 版本跟你的显卡驱动匹配。SGLang 的安装可以用 pippip install sglang[all]如果要用最新特性建议从源码安装git clone https://github.com/sgl-project/sglang.git cd sglang pip install -e .[all]安装完成后验证一下 SGLang 是否能正常导入import sglang as sgl print(sgl.__version__)这一步如果报错多半是 CUDA 版本不匹配或者缺少某些系统依赖。常见的是缺少libnuma和libibverbs在 Ubuntu 上可以用apt install libnuma-dev libibverbs-dev解决。3.2 模型下载与权重转换MiMo-V2.6 的权重在官方仓库和 Hugging Face 上都有发布。下载之前先确认你要的是 Pro 还是 Flash两者的权重文件不通用。下载方式可以用huggingface-clihuggingface-cli download xiaomi/mimo-v2.6-pro --local-dir ./mimo-v2.6-pro如果网络条件不好可以用镜像站或者提前把权重下载到本地再传上去。权重文件比较大Pro 版本大概几百 GB下载前确保磁盘空间充足。下载完成后如果 SGLang 不直接支持原始权重格式可能需要做一次转换。转换脚本通常在官方仓库的scripts目录下运行前先看 README 里的说明确认转换参数。转换过程中会消耗较多内存建议在内存充足的机器上做。3.3 启动推理服务与参数调优启动 SGLang 服务的基本命令如下python -m sglang.launch_server \ --model-path ./mimo-v2.6-pro \ --tp-size 4 \ --ep-size 2 \ --host 0.0.0.0 \ --port 30000 \ --context-length 32768这里解释几个关键参数。--tp-size是张量并行度一般设成显卡数量。--ep-size是专家并行度MoE 模型里这个参数影响专家怎么分布到不同卡上。--context-length是最大上下文长度设得越大占显存越多根据实际需求调整。启动后可以用 curl 测试一下服务是否正常curl http://localhost:30000/generate \ -H Content-Type: application/json \ -d { text: 用一句话解释 MoE 架构, sampling_params: {temperature: 0.7, max_new_tokens: 128} }如果返回正常说明服务跑起来了。接下来可以压测一下吞吐量和延迟用 SGLang 自带的 benchmark 脚本python -m sglang.bench_serving \ --backend sglang \ --host localhost \ --port 30000 \ --num-prompts 100 \ --request-rate 10根据压测结果调整--max-running-requests和--schedule-policy找到吞吐和延迟的平衡点。3.4 负载均衡配置的实际操作MoE 模型的负载均衡是个绕不开的话题。如果路由网络把大部分 token 都分配给少数几个专家这些专家就会成为瓶颈其他专家闲着整体效率下降。MiMo-V2.6 在训练时用了负载均衡损失来缓解这个问题但推理时还需要框架层面的配合。SGLang 里跟负载均衡相关的参数主要是--ep-size和--moe-dense-tp-size。--ep-size设大一点专家分布更分散单卡压力小但通信开销增加。--moe-dense-tp-size控制稠密部分的张量并行度跟专家并行度配合使用。实际调优时可以先跑一个基准测试看各个专家的激活频率是否均匀。如果发现某些专家明显过载可以调整路由温度参数让路由分布更平滑。不过这个参数通常训练时就固定了推理时能调的空间有限。更实际的做法是调整专家并行度让过载的专家分散到更多卡上。注意负载均衡调优没有一劳永逸的参数不同请求分布下最优配置可能不同。建议根据你的实际流量特征做针对性测试不要直接抄别人的配置。4. 常见问题与排查技巧实录4.1 启动时报显存不足怎么排查显存不足是部署 MoE 模型最常见的问题。排查思路按顺序来先看模型权重占了多少显存再看 KV 缓存占了多少最后看中间激活值占了多少。权重占显存是固定的Pro 版本如果 4 张卡不够要么加卡要么用量化版本。KV 缓存跟上下文长度和并发数相关如果--context-length设得太大或者并发请求太多KV 缓存会爆。可以先把--context-length调小比如从 32768 降到 8192看是否能启动。中间激活值跟 batch size 相关--max-running-requests设小一点能缓解。如果以上都调了还是不够考虑用--mem-fraction-static参数控制静态显存分配比例默认是 0.9可以降到 0.8 试试。但降太多会影响性能因为留给 KV 缓存的空间少了。4.2 推理速度慢的几种可能原因速度慢的原因很多按可能性排序第一是专家并行度设置不合理导致通信开销过大第二是前缀缓存没命中每个请求都在重复计算第三是批处理策略不适合你的请求模式。先看专家并行度。如果--ep-size设得太大跨卡通信频繁延迟会上去。可以试着调小--ep-size看速度是否改善。再看前缀缓存如果你的请求之间共享前缀少RadixAttention 的收益就有限。这种情况下可以关掉前缀缓存减少维护基数树的开销。批处理策略方面SGLang 默认用连续批处理适合请求长度差异大的场景。如果你的请求长度都比较短且均匀可以试试静态批处理减少调度开销。具体用哪个压测一下就知道。4.3 输出质量不稳定的应对方法输出质量不稳定通常跟采样参数有关。温度设太高输出随机性大设太低输出重复。MiMo-V2.6 的推荐温度范围是 0.6 到 0.8具体看任务。代码生成建议 0.2 到 0.4创意写作可以到 0.9。另一个原因是量化。如果你用了量化版本精度损失可能导致输出质量下降。可以对比一下原始版本和量化版本在同一批测试用例上的表现如果差距明显考虑换回原始版本或者换一种量化方法。还有可能是提示词的问题。MoE 模型对提示词的格式比较敏感尤其是涉及多步推理的任务。建议在提示词里明确步骤比如“先分析问题再给出答案”这样模型更容易激活正确的专家。4.4 常见问题速查表问题现象可能原因排查方法解决方向启动时 OOM权重KV缓存激活值超显存逐步调小 context-length 和 max-running-requests加卡、量化、调小 mem-fraction-static推理速度慢专家并行通信开销大对比不同 ep-size 下的延迟调小 ep-size 或换用 Flash 版本首 token 延迟高前缀缓存未命中检查请求间前缀共享情况优化提示词结构增加共享前缀输出重复温度太低或重复惩罚不够调高温度加 repetition-penalty温度 0.7 起步惩罚 1.1 左右输出质量下降量化损失或提示词不当对比原始版本检查提示词格式换回原始权重优化提示词服务崩溃显存碎片或并发过高看日志里的 CUDA OOM 信息限制并发定期重启服务提示MoE 模型的显存碎片问题比稠密模型更严重因为专家加载和卸载会导致显存分配不连续。建议在服务启动时预留足够的显存余量不要卡着上限跑。4.5 几个容易踩的坑第一个坑是直接拿稠密模型的部署经验套 MoE。稠密模型调--tp-size就够了MoE 还要考虑--ep-size两个参数配合不好性能可能比单卡还差。我试过把--ep-size设成跟--tp-size一样大结果通信开销把收益全吃掉了后来降到一半才正常。第二个坑是忽略请求长度分布。如果你的请求大部分很短偶尔来一个超长请求连续批处理会把短请求跟长请求混在一起短请求被长请求拖慢。这种情况可以用请求分级短请求走 Flash 版本长请求走 Pro 版本。第三个坑是不做压测就上线。实验室环境跟生产环境的流量特征差别很大实验室跑得通不代表线上稳。上线前至少做一轮全链路压测观察 P99 延迟和错误率确认在可接受范围内再放量。5. 选型对比与场景适配建议5.1 MiMo-V2.6 与同梯队模型的横向对比把 MiMo-V2.6 跟 Kimi K3、GLM-5.3 放在一起看三者的定位有差异。Kimi K3 在长上下文处理上有优势适合文档分析、长对话场景。GLM-5.3 在中文理解和生成上表现稳定适合中文内容创作。MiMo-V2.6 的强项在于综合均衡和推理成本控制AA 指数领先说明它在多个维度上没有明显短板。从开源程度看三者都开放了权重但许可证条款有差异。MiMo-V2.6 的许可证对商业使用比较友好具体条款建议去官方仓库确认。如果你要做商业产品许可证是必须仔细看的一环别等到产品上线了才发现合规问题。从生态支持看MiMo-V2.6 对 SGLang 的适配做得比较深如果你已经在用 SGLang迁移成本低。如果用的是 vLLM 或其他框架可能需要等社区适配或者自己写适配层。5.2 什么场景选 Pro什么场景选 FlashPro 和 Flash 的选择核心看两个维度任务复杂度和延迟要求。任务复杂度高、延迟要求宽松选 Pro。任务简单、延迟要求严格选 Flash。具体来说代码生成、数学推理、多步逻辑分析这些任务Pro 版本的优势明显因为激活参数多推理深度够。分类、抽取、意图识别、简单问答这些任务Flash 版本足够而且速度快、成本低。实际项目里混用是常见做法。比如一个客服系统用 Flash 做意图识别和槽位抽取用 Pro 做最终回答生成。这样既保证了响应速度又保证了回答质量。路由层可以根据意图识别的结果决定走哪个版本实现起来不复杂。5.3 成本估算与资源规划成本估算要算三块显存成本、计算成本、运维成本。显存成本是固定的取决于你选 Pro 还是 Flash以及用多少张卡。计算成本跟请求量相关按 token 计费的话Pro 版本单价高但质量好Flash 版本单价低但能力有限。资源规划时先估算峰值 QPS 和平均请求长度再根据压测结果推算需要多少张卡。留 30% 的余量应对突发流量不要卡着上限规划。运维成本包括监控、告警、故障处理MoE 模型的运维比稠密模型复杂建议预留更多人力。注意MoE 模型的显存占用不是线性的并发数增加到一定程度后显存增长会加速。规划资源时要做压力测试找到显存增长的拐点在拐点之前留足余量。6. 我个人在实际操作中的体会部署 MiMo-V2.6 这段时间最大的感受是 MoE 模型的调优空间比稠密模型大得多但坑也更多。稠密模型调来调去就是那几个参数MoE 多了专家并行度、路由策略、负载均衡这些维度每个维度都能影响最终性能。另一个体会是不要迷信榜单。AA 指数高不代表你的场景就合适一定要用自己的数据做评测。我见过 AA 指数很高的模型在特定领域表现不如小模型的情况因为评测集跟实际业务分布不一致。选型时榜单只做参考最终决策要靠自己的评测结果。最后分享一个小技巧如果你显存紧张可以试试把 Flash 版本和 Pro 版本部署在同一批卡上用请求路由做分流。Flash 版本占显存少Pro 版本占显存多两者错峰使用能提高资源利用率。具体怎么分配看你的流量特征多试几组配置就能找到合适的比例。