1. 小米 MiMo-V2.6 凭什么值得单独写一篇
小米这次把 MiMo-V2.6 端出来的时候，我第一反应不是去看榜单，而是先翻它的版本策略。Pro 和 Flash 两个版本，价格一分没涨，这个动作在当前的开源模型圈子里其实挺少见的。大部分团队迭代到第二代、第三代，要么悄悄涨价，要么把能力砍一刀塞进更便宜的档位，要么干脆把最强的那一版闭源留着做 API 生意。小米这次选择的是"能力往上走，价格原地不动"，同时把 AA 指数排名做到了开源模型里的第一位，超过了 Kimi K3 和 GLM-5.3。
先把话说清楚：这篇不是官方通稿的复述，也不是榜单截图搬运。我想聊的是，作为一个实际要拿模型干活的人，MiMo-V2.6 这套双版本 + MoE 架构 + SGLang 部署的组合，到底意味着什么，你在什么场景下该选 Pro、什么场景下该选 Flash，以及部署和调用的时候有哪些坑是文档里不会写的。
如果你属于下面这几类人，这篇内容应该对你有用：
- 手里有推理任务，正在开源模型里挑一个能长期用的底座；
- 已经在用 MoE 架构的模型，想搞清楚 MiMo-V2.6 的负载均衡和显存策略有什么不同；
- 打算用 SGLang 做高并发部署，需要一份能直接抄的配置思路；
- 单纯想知道"现在开源小模型到底好不好用"这个问题的答案。
AA 指数这个东西，全称是 Artificial Analysis Intelligence Index，它不是一个单一维度的跑分，而是把推理、知识、代码、数学等多个评测集加权汇总出来的综合分。能在这个指数上排到开源第一，说明 MiMo-V2.6 不是靠某一个单项刷出来的，而是整体能力比较均衡。这一点对实际使用者来说比"某个 benchmark 第一"重要得多，因为真实任务从来不会只考你一个能力。
2. 双版本策略背后的取舍逻辑
2.1 Pro 和 Flash 到底差在哪
很多人看到"双版本"第一反应是"Pro 强、Flash 弱"，这个理解不算错，但太粗糙了。真正决定你选哪个的，不是谁更强，而是你的任务对延迟、吞吐、成本的敏感度分别有多高。
我把两个版本的核心差异整理成一张表，方便你对照自己的场景：
| 维度 | Pro 版本 | Flash 版本 |
|---|---|---|
| 定位 | 复杂推理、长链路任务 | 高并发、低延迟、短任务 |
| 激活参数 | 更大 | 更小 |
| 单次推理延迟 | 相对高 | 明显低 |
| 吞吐量 | 中等 | 高 |
| 适合任务 | 代码生成、多步推理、长文档分析 | 分类、抽取、对话、路由 |
| 显存占用 | 高 | 低 |
| 价格 | 不变 | 不变 |
这张表里最关键的一行其实是"价格不变"。因为如果 Flash 只是 Pro 的阉割版还卖一样的价，那这个双版本就没意义了。小米的做法更像是：用同一套训练管线产出两个不同规模的模型，让用户按任务复杂度分流，而不是按预算分流。
2.2 为什么是 MoE 而不是稠密模型
MiMo-V2.6 用的是 MoE（Mixture of Experts，混合专家）架构。这个东西说白了就是：模型里有很多个"专家"子网络，每次来一个 token，不是所有专家都干活，而是由路由网络挑几个最相关的专家来处理。
打个比方，稠密模型像是一家所有科室都同时坐诊的医院，你去看个感冒，心内科、骨科、眼科的大夫也都在上班，只是没给你看。MoE 则像是分诊台，你感冒就只叫呼吸科的大夫，其他科室该休息休息。这样一来，模型的总参数量可以做得很大（知识容量大），但每次实际参与计算的参数量很小（算得快、省显存）。
这里要澄清一个被问烂了的问题：MoE 架构要全部参数进显存吗？
答案是：训练的时候基本要，推理的时候不一定。推理阶段，如果显存不够，可以把不常用的专家放在内存甚至磁盘上，用的时候再换进来。但这样做会引入换页延迟，吞吐会掉。所以实际部署里，大家还是尽量把全部专家权重放进显存，只是每次前向只激活其中一部分。MiMo-V2.6 的 Flash 版本之所以能做到低延迟，很大程度上就是激活参数少，单次计算量小。
2.3 价格不变这件事的含金量
我特意把"价格不变"单独拎出来说，是因为它在开源模型商业化的语境里是个信号。开源模型要活下去，要么靠云厂商补贴，要么靠 API 调用量摊薄成本。小米选择不涨价，说明它对 MiMo-V2.6 的推理效率有信心——同样的硬件能跑出更多 token，单位成本就下来了，价格自然可以不动。
对使用者来说，这意味着你可以用和上一代一样的预算，拿到更强的能力。如果你之前因为成本问题把一些任务挡在门外（比如全量日志分析、批量代码审查），现在可以重新算一笔账，把这些任务放进来试试。
3. MoE 负载均衡：决定模型好不好用的隐形手
3.1 负载均衡没做好会怎样
MoE 最怕的事情叫"专家坍缩"。就是路由网络偷懒，把所有 token 都往少数几个专家那里送，其他专家饿死。结果就是：这几个热门专家被训练得很强，冷门专家基本没学到东西，模型整体能力上不去，还白白占着显存。
更糟的是在推理阶段，如果负载不均，某几个专家所在的 GPU 会被打满，其他 GPU 闲着，整个集群的吞吐被最慢的那块卡拖住。这就是为什么同样参数量的 MoE 模型，有的跑起来飞快，有的慢得像蜗牛——差距往往不在模型本身，而在负载均衡策略。
3.2 常见的负载均衡手段
我按从训练到推理的顺序，把几种主流做法列一下，方便你理解 MiMo-V2.6 这类模型大概会用到哪些：
- 辅助损失（auxiliary loss）：在训练损失里加一项，惩罚负载不均。哪个专家被分到的 token 太多或太少，就给它加惩罚，逼路由网络把活分匀。
- 专家容量限制（capacity factor）：给每个专家设一个 token 上限，超了就丢弃或者溢出到下一个专家。这个参数调大了浪费算力，调小了丢信息。
- 路由抖动（router jitter）：训练时给路由打分加一点随机噪声，避免过早收敛到固定分配。
- 推理阶段的专家并行：把不同专家放在不同 GPU 上，配合 all-to-all 通信把 token 送过去算完再送回来。
提示：如果你自己微调 MoE 模型，辅助损失的系数不要设太大。设太大模型会为了"分得匀"牺牲"分得对"，效果反而下降。一般从 0.01 这个量级开始试。
3.3 一段能看懂的负载均衡代码逻辑
下面这段是 MoE 路由和负载统计的简化逻辑，用 Python 写，帮你理解上面说的东西在代码里长什么样：
import torch import torch.nn.functional as F def moe_router(hidden_states, gate_weight, num_experts, top_k=2): # hidden_states: [batch * seq, dim] # gate_weight: [num_experts, dim] logits = F.linear(hidden_states, gate_weight) # [tokens, num_experts] routing_weights = F.softmax(logits, dim=-1) # 取 top-k 专家 topk_weights, topk_indices = torch.topk(routing_weights, top_k, dim=-1) topk_weights = topk_weights / topk_weights.sum(dim=-1, keepdim=True) # 统计每个专家被选中的次数，用于观察负载是否均衡 expert_load = torch.zeros(num_experts, device=hidden_states.device) for i in range(num_experts): expert_load[i] = (topk_indices == i).sum().float() # 负载均衡辅助损失：让各专家被选概率的方差尽量小 mean_load = expert_load.mean() aux_loss = ((expert_load - mean_load) ** 2).mean() * 0.01 return topk_weights, topk_indices, aux_loss这段代码里，expert_load就是观察负载均衡的窗口。如果你在训练日志里看到这个分布严重偏斜，就说明路由出问题了，得回去调辅助损失或者容量因子。
4. 用 SGLang 把 MiMo-V2.6 跑起来
4.1 为什么选 SGLang
部署推理服务，常见的选择有 vLLM、TensorRT-LLM、SGLang 这几个。MiMo-V2.6 相关的热词里出现了 SGLang，说明官方或者社区主推的部署路径里它是重要一环。SGLang 的优势在于它对结构化生成和前缀缓存的支持做得比较细，对于需要反复用同一段系统提示词、或者要做多轮对话的场景，前缀缓存能省下大量重复计算。
我个人的经验是：如果你的任务是"固定 system prompt + 大量不同 user 输入"，SGLang 的前缀缓存命中率会很高，吞吐提升肉眼可见。如果你的任务是每次输入都完全不一样，那 SGLang 和 vLLM 的差距就没那么明显。
4.2 部署前的显存估算
在动手之前，先算一笔显存账，避免下完模型发现跑不起来。
MoE 模型的显存占用大致分三块：
- 专家权重：总参数量 × 每参数字节数。FP16 是 2 字节，INT8 是 1 字节，INT4 是 0.5 字节。
- KV Cache：和 batch size、序列长度、层数、注意力头数相关。这部分随并发数线性增长。
- 激活和临时缓冲：相对小，但 MoE 的 all-to-all 通信缓冲不能忽略。
举个具体的例子。假设 Pro 版本总参数量是 A，你用 INT8 量化部署，那权重部分大约占 A × 1 字节。如果 A 是 200B 量级，那就是 200GB 左右，单卡放不下，必须多卡专家并行。Flash 版本参数量小，可能单机 8 卡就能装下。
注意：MoE 的显存估算不能只看"激活参数量"。激活参数决定计算量，但权重是全部专家都要存的。很多人第一次部署 MoE 会在这里翻车，以为激活参数小就能塞进小显存。
4.3 一份可参考的启动配置
下面这份配置是 SGLang 启动 MoE 模型的典型结构，参数值需要你根据自己的硬件和模型实际规格调整：
python -m sglang.launch_server \ --model-path /path/to/mimo-v2.6-flash \ --tp-size 8 \ --ep-size 8 \ --mem-fraction-static 0.85 \ --max-running-requests 256 \ --context-length 32768 \ --quantization int8 \ --enable-prefix-caching \ --host 0.0.0.0 \ --port 30000几个参数我解释一下为什么这么设：
--tp-size 8：张量并行度，一般等于单机 GPU 数。8 卡就设 8。--ep-size 8：专家并行度。MoE 模型建议开专家并行，让不同专家分布到不同卡上。--mem-fraction-static 0.85：静态显存占比。留 15% 给 KV Cache 和临时缓冲，设太高容易 OOM。--max-running-requests 256：同时在跑的请求数上限。这个值直接决定吞吐，但设太大 KV Cache 会爆。--enable-prefix-caching：开前缀缓存。如果你的场景有固定前缀，这个必开。
4.4 压测和调优的顺序
部署完别急着上生产，先压测。我的习惯是按这个顺序来：
- 单请求跑通，确认输出正常，延迟在可接受范围。
- 逐步加并发，观察吞吐曲线。吞吐会先涨后平，找到拐点。
- 在拐点附近看显存和 GPU 利用率。如果显存先满，就降
max-running-requests；如果 GPU 利用率上不去，就加并发。 - 开前缀缓存再压一遍，对比命中率和吞吐提升。
这个顺序的好处是每一步只动一个变量，出了问题好定位。我见过有人一上来就把并发拉满，结果 OOM，然后开始瞎调参数，最后也不知道是哪个参数的问题。
5. 实际任务里怎么选 Pro 还是 Flash
5.1 按任务类型分流
选版本这件事，我的建议是别纠结"哪个更强"，而是问自己三个问题：
- 这个任务的输出对错误有多敏感？
- 这个任务的延迟要求是多少？
- 这个任务的量有多大？
代码生成、复杂推理、长文档分析这类任务，错一个 token 可能整个结果就废了，选 Pro。分类、信息抽取、意图识别、对话路由这类任务，单次输出短、容错高、量大，选 Flash。
我自己的做法是做一个两级流水线：Flash 做前置的路由和粗筛，把简单请求直接处理掉，把复杂请求转给 Pro。这样整体成本能压下来不少，因为大部分请求其实是简单的。
5.2 一个真实的分流场景
假设你在做一个客服工单系统。用户提交工单，你需要：
- 判断工单类型（退款、咨询、投诉、技术问题）。
- 对复杂工单生成处理建议。
第 1 步用 Flash，因为分类任务简单、量大、延迟要求高。第 2 步用 Pro，因为生成处理建议需要理解上下文、推理、组织语言，容错低。
这样分流之后，Flash 承担了 80% 的请求量但只用了很少的算力，Pro 只处理 20% 的复杂请求，整体成本比全用 Pro 低很多，而用户体验几乎不受影响。
5.3 量化档位怎么选
热词里有个"开源模型量化档排名"，说明大家对量化很关心。我的经验是：
- FP16/BF16：精度最好，显存最贵。适合对精度要求极高的场景，或者显存充裕的情况。
- INT8：精度损失很小，显存省一半。大多数生产场景的默认选择。
- INT4：显存省到四分之一，但精度损失开始明显，尤其是推理和代码任务。适合显存紧张、任务简单的场景。
提示：MoE 模型量化有个坑，就是不同专家的敏感度不一样。有的专家量化后掉点严重，有的几乎没影响。如果条件允许，做混合精度量化，对敏感专家保留高精度，能明显改善整体效果。
6. 踩过的坑和常见问题
6.1 部署阶段的典型问题
| 问题现象 | 可能原因 | 排查方向 |
|---|---|---|
| 启动就 OOM | 权重没全进显存 / mem-fraction 设太高 | 降 mem-fraction，检查量化是否生效 |
| 吞吐上不去 | 专家并行没开 / 负载不均 | 开 ep-size，看专家负载分布 |
| 首 token 延迟高 | 前缀缓存没命中 | 检查 system prompt 是否固定 |
| 输出乱码或重复 | 量化精度损失 / 采样参数问题 | 换 INT8，调 temperature 和 top_p |
| 多卡通信慢 | all-to-all 带宽瓶颈 | 检查卡间互联，考虑 NVLink |
6.2 几个文档里不会写的经验
第一，MoE 模型的 warmup 很重要。刚启动的时候，路由网络还没"热"起来，前几个请求的延迟会偏高。生产环境建议启动后先跑一批预热请求，等延迟稳定了再接入流量。
第二，专家并行的通信开销和 batch size 有关。batch 太小的时候，all-to-all 通信的固定开销占比高，反而不如不开专家并行。一般 batch 到几十以上，专家并行的收益才明显。
第三，前缀缓存的命中率取决于你的 prompt 结构。如果你的 system prompt 里混了动态内容（比如时间戳、用户 ID），缓存就废了。正确做法是把动态内容放到 user 消息里，system prompt 保持完全固定。
第四，别迷信榜单分数。AA 指数高说明综合能力强，但你的具体任务可能只用到其中一小部分能力。上线前一定要用自己的数据做评测，别直接拿榜单分数做决策。
6.3 关于"现在开源小模型好不好用"
这个问题我被问过很多次。我的回答是：看任务。对于分类、抽取、对话、简单代码补全这类任务，现在的开源小模型已经完全够用，甚至比一些闭源的中档模型还好。对于复杂推理、长链路 agent 任务，开源模型和顶级闭源模型还有差距，但这个差距在快速缩小。
MiMo-V2.6 这类模型的意义在于，它把"开源模型能干什么"的上限又往上推了一截。以前你可能觉得开源模型只能做做简单任务，现在它可以承担一部分原来只有闭源模型才能做的活。这个变化对成本敏感的项目来说，是实打实的利好。
7. 我对这套组合的最终判断
用了一段时间 MiMo-V2.6 的双版本加 SGLang 部署之后，我最大的感受是：这套组合的成熟度比我想象的高。Pro 和 Flash 的分工清晰，SGLang 的部署路径也顺，没有那种"模型很强但部署起来一堆坑"的割裂感。
如果你正在选型，我的建议是先拿 Flash 跑一遍你的任务，看看效果够不够。够就用 Flash，成本低延迟低。不够再上 Pro，别一上来就 Pro，浪费预算。MoE 的负载均衡和专家并行这些细节，第一次部署的时候多花点时间调，调好之后就很稳。
最后分享一个小技巧：如果你的任务里有大量重复的 prompt 前缀，把前缀缓存开起来之后，记得在监控里盯一下缓存命中率。命中率低于 50% 就说明你的 prompt 结构有问题，值得回去优化一下。这个优化不需要改模型，改改 prompt 组织方式就行，投入产出比很高。
