小米MiMo-V2.6开源模型：MoE架构与SGLang推理部署实战

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.6，SGLang 是目前比较推荐的选择。它的安装和启动流程不算复杂，但有几个参数需要根据你的硬件调整。比如--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 的安装可以用 pip：

pip 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-cli：

huggingface-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 常见问题速查表

提示：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，什么场景选 Flash

Pro 和 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 版本占显存多，两者错峰使用，能提高资源利用率。具体怎么分配，看你的流量特征，多试几组配置就能找到合适的比例。