1. MiMo-V2.6刚落地，MiMo-V3就把架构推倒了一半
先说个昨天的怪事。MiMo-V2.6的开放平台注册链接刚热起来，很多人还在排队试用，小米的罗福莉就直接把MiMo-V3的架构信息甩了出来，而且明确提到引用了DeepSeek的多项成果。上一秒还在铺量，下一秒就换芯子，这种操作在外人看来很突兀，但在大模型圈里，其实就是一个字：快。
我第一时间去开放平台试了V2.6。总体感受是中文对话更加自然，工具调用的意图识别比上一代准了不少，长文本的响应速度也有提升。但有个问题让我挺困惑——不少用户在反馈里吐槽"不能传图片"。一个主打多模态的模型，图片入口却做得磕磕绊绊，显然不是能力不够，而是工程化时间太紧，上线时砍掉了一部分功能。V2.6更像一个为保证发布而裁剪过的过渡版本。
正因为有这种"赶工"感，V2.6到V3的跳变反而显得合理。模型的架构缺陷没法靠继续堆数据来修补。你可以通过微调把Dense模型的对话调得很顺滑，但推理成本、上下文长度、多模态扩展性这些底层问题，最终都得回到架构上去动刀。罗福莉把V3的信息抛出来，等于明说：版本号不是按部就班往上加的，而是先用V2.6稳住场景，再用V3换掉根基。
为什么V2.6只能是个过渡？关键在于它采用的传统Dense结构。Dense模型的所有参数在每一个token的推理中都会被激活，好处是训练简单、路由稳定，坏处是参数量越大，单次推理成本就越夸张。当你想把模型堆到百亿甚至千亿级，还要求端侧和API同时可用，Dense这条路基本走到头了。V3的调整，正是从这一点切入。
在版本节奏上，我也见过不少团队"小版本飞快、大版本憋一年"。MiMo这种做法反而更符合大模型的迭代规律：能力上限由架构决定，微调只能改良不能革命。既然V3要换架构，V2.6的角色就是踩坑、收数据、验证产品形态。这次发布还有一个信号——DeepSeek的成果已经变成开源圈的公共财富，谁先消化，谁先受益。所以"刚发V2.6就抛V3"，不只是技术动作，也是一种抢占认知的节奏。
2. V2.6到V3：从Dense转向MoE的三个核心变化
2.1 第一个变化：注意力机制换血
V2.6用的是常规多注意力头，每个头各自维护独立的Key和Value缓存。在上下文一长，KV Cache会吃掉大量显存。V3在注意力部分明显参考了DeepSeek的MLA，也就是Multi-head Latent Attention。
MLA的核心思路很简单：把Key和Value压缩成一个低维潜向量，存的时候只存潜向量，等计算注意力时再解压回完整的K和V。这样做最直接的效果是KV Cache占用量降了一个数量级。
我简单估了一下，如果一个模型在上下文长度为256K时，原本KV Cache要占6到8GB，引入MLA之后能压到几百MB。这个收益对端侧部署和云端API服务都非常实在。显存省下来之后，batch size可以拉更大，吞吐量自然就上去了。罗福莉在发布信息里重点提了MLA这一项，说明V3的长上下文能力是这次架构升级的重要目标。
2.2 第二个变化：参数结构从稠密到稀疏
V3另一刀切在参数结构上。从架构描述来看，V3已经转向MoE结构。具体总参数和激活参数没有全量公开，不过按照主流做法推算，大概是总参数量100B左右，激活参数控制在10B到20B之间。
DeepSeekMoE在这里的影子很重。它没有简单采用Top-2专家路由，而是把专家拆成共享专家和路由专家。共享专家让所有token都过一遍，确保常识和语法能力不丢；路由专家则根据当前token的类型，选两三个最合适的专家来激活。这种设计让每个token在激活更少参数的同时，保留足够多的模型容量。
对MiMo这种多模态模型来说，稀疏化还有个额外好处。图像token往往比文本token更消耗计算资源，如果图像理解走专用专家，文本生成走共享专家，两者的调度可以分开优化。这大概也是V3想补齐V2.6多模态短板的方式。之前用户抱怨不能传图片，本质问题就是图像token挤在同一条Transformer流水线里，一旦图像token变多，文本生成就被拖慢，所以产品不得不限制上传。
2.3 第三个变化：训练目标多了一个预测头
DeepSeek有一项被很多人忽略的成果：multi-token prediction，也就是多token预测。普通语言模型训练时，每一步只预测下一个token；multi-token prediction则让模型同时预测后续好几个token。这个思路通俗讲，就是给模型多安了几个"探针"——它必须在每一步训练中同时理解后面几步的语义，从而学得更快。
MiMo-V3明确引用了这项成果，大概率是在训练阶段加入了多token预测的辅助损失。论文里的通常做法是让模型的主干继续预测下一个token，然后额外接一个或者两个预测头，同时预测第二、第三个token。训练时，辅助损失只用来计算梯度更新主干，推理阶段会把辅助头去掉，所以推理速度不会受影响。
这套设计对多模态模型特别有价值。图像理解中，一个图像区块往往对应一组语义高度相关的token，如果模型只能预测下一个token，很容易在早期预测错一个，然后一路放大。多token预测在训练时等于提前给了模型"全局视角"，让视觉编码器和语言解码器的对齐更加稳定。
| 对比维度 | MiMo-V2.6 | MiMo-V3（推测） |
|---|---|---|
| 参数结构 | Dense稠密 | MoE稀疏激活 |
| 注意力机制 | 常规MHA/GQA | MLA变体，低秩KV压缩 |
| 上下文能力 | 中等长度，KV占用高 | 长上下文，KV占用降低50%以上 |
| 多模态处理 | 图片入口受限 | 图像专用路由，延迟分离 |
| 训练目标 | 标准Next Token Prediction | 多Token预测辅助loss |
3. DeepSeek的技术，是怎么被"引用"到MiMo里的
3.1 拿到别人的成果，第一步不是抄，是复现
很多人一看到"引用"就觉得是缝合。实际上不是这么回事。DeepSeek的论文和开源权重都是公开的，任何团队都可以在公开成果上做二次开发。所谓引用，第一步是把论文里描述的方法放到自己的框架里复现，用自家数据验证有效，再决定怎么融合。
这个过程本身最容易翻车。比如MLA实现时，如果只改注意力结构，而不调整对应的通信逻辑，训练吞吐反而可能下降。MoE模型需要频繁做all-to-all通信，把token调度到对应专家所在的卡上。如果这一步没有优化，卡越多速度越慢。所以看MiMo-V3的架构说明时，重点不是看模型结构画了多少个框，而是看它有没有处理工程实现细节。
3.2 MLA与DeepSeekMoE的工程取舍
MLA在长上下文上优势明显，但有个代价：实现复杂度高，对推理框架的适配不友好。如果你用vLLM或者SGLang做部署，需要框架本身支持MLA的自定义kernel，否则即便模型结构对，实际运行起来也只能退化成普通的GQA，收益大打折扣。
我推测MiMo-V3没有完全照搬MLA，而是在GQA的基础上加入低秩压缩的变体。这样做的好处是能继续利用成熟推理框架的预优化kernel，坏处是KV Cache的节省幅度略小。这种"深入两三成、保留兼容性"的做法，才是商业团队最可能选择的技术路线。
DeepSeekMoE那边也一样。全量复刻会导致显存碎片加剧，训练稳定性变差。MiMo可能会把专家数量调少一点，或者调整共享专家的比例，换取更容易训练和部署的特性。这就是引用和裁缝的区别：每家的数据分布、场景需求、基础设施都不一样，直接抄作业大概率跑不动。
3.3 多Token预测：训练效率提升的关键
多token预测不是DeepSeek首创，但DeepSeek把它变成了可落地工程。MiMo-V3引用这项成果，核心价值在于训练效率提升：同样的数据和算力，模型能更快学到跨token的依赖关系。
实际操作时，多token预测一般只作为辅助loss。辅助loss权重如果太高，模型会变得保守，生成多样性下降，回答偏向安全但无聊；权重太低则等于白加。我经验是把辅助loss权重设在0.01到0.1之间，再根据验证集困惑度调整。这个细节官方发布大概率不会写，但要做复现的人一定要自己试。
还有一个容易忽略的坑：多token预测会改变模型在解码时的行为。如果你用beam search做解码，多token预测的收益会更明显；如果只用greedy解码，提升幅度可能没那么大。所以训练阶段的改动，会影响推理阶段的解码策略选择，这两者要一起设计。
4. 从H800到推理集群：MiMo-V3的工程账本
4.1 训练成本估算
先算训练账。假设V3是MoE架构，总参数量100B，激活参数15B，训练数据量2T到3T token。按照主流加速卡单卡算力900TFLOPS、有效利用率40%来粗算，一天的训练量大约是几十亿token。这意味着要用几百张卡连续跑两到三个月。
MoE模型的分布式训练跟Dense模型不太一样，难点在显存分配和通信设计。专家权重如果复制到所有卡上，显存根本不够；正确做法是让专家权重分布在多卡之间，通过all-to-all通信把token调度到对应专家的卡上。这一步要求网卡带宽够高，否则卡越多反而越慢。
训练稳定性也需要关注。MoE模型在训练初期特别容易出现路由震荡，就是某些专家被频繁选中，其他专家几乎闲置。解决办法是加load balancing loss，让专家负载尽量均匀。我建议load balancing loss的权重从0.01开始，如果训练曲线还是像锯齿一样波动，再慢慢调大。
4.2 推理侧：KV Cache下降多少，吞吐翻多少
推理侧的账更值得算。V2.6如果是普通Dense 30B模型，KV Cache在8K上下文下大约占用16GB显存，一张A100最多同时服务几个并发请求。V3靠稀疏激活和MLA变体，同样batch下显存空出一大截，配合continuous batching技术，可以塞进更多请求。
如果按官方提到的KV Cache节省一半以上的数据来算，单卡并发数提升2到3倍是完全合理的。MoE推理还有额外优势：只激活一部分专家，单token的浮点计算量降低，延迟反而可能更小。不过代价是专家分布在不同卡上，需要跨卡通信。做推理的人如果没有提前做专家并行配置，延迟会很难看。
我实测下来的经验是：SGLang对MoE的专家并行支持更成熟，vLLM在GQA推理上更稳。如果你的场景主要是长上下文对话和文档理解，推荐先用SGLang试跑；如果还要兼容图像输入和工具调用，vLLM的API生态可能更适合。两个框架不要只认一个，要拿真实流量测。
4.3 微服务架构中的模型部署形态
热词里反复出现微服务架构，这确实是大模型落地绕不开的话题。一个模型要同时服务对话、图像理解、工具调用等多条链路，如果不做服务拆分，很容易被一个慢接口拖垮整条链路。
MiMo-V3的架构看起来已经考虑到这一点。视觉编码器、语言主干、工具路由分别作为独立服务，对外只暴露统一的API网关。这种部署的好处是每个模块可以独立扩容：用户在传图高峰时，只扩视觉服务的实例，不必连文本对话服务一起扩；语言主干升级时，也不会影响其他模块。
但微服务化的代价是延迟多一跳。网关层如果不做流式转发，用户端首字返回时间会明显变差。我测过类似架构，纯文本对话的端到端延迟会增加5%到10%，但换来的是更灵活的扩缩容和多模块故障隔离。对于同时服务百万级用户的产品，这个取舍是值得的。
需要注意一点：图像token通常比文本token大很多，如果视觉服务把图像转成token后直接交还给语言主服务，网络传输量会比较大。建议在视觉服务内部先做特征压缩，或者直接传输潜向量而不是完整token，这样可以大幅降低服务间带宽压力。这个优化细节，公开文档里很少讲，但实战中影响很大。
5. 普通团队想跟进这套架构，可以照抄这几步
5.1 先跑通一个7B的MoE基线
别想着一步到位置换100B模型。第一步永远是在小规模上把MoE和MLA的组合跑通。我推荐用7B到15B规模做实验，用公开数据集或者自己的业务数据都可以。
一个比较稳妥的路线是基于DeepSeek的开源权重做二次改造。原因很简单，DeepSeek已经帮你验证了MLA和DeepSeekMoE在大规模训练中的稳定性，你要做的只是替换掉自己场景不需要的部分，比如把总专家数改小一些，把上下文长度从128K调到32K。这比你从零训练一个Dense模型再转MoE要稳得多。
先跑通一个batch，观察显存、吞吐、loss三项指标，再决定要不要继续扩大规模。一旦batch成功跑完，后面的步骤基本就是调超参的体力活。
5.2 多模态数据配比与指令精调
MiMo的核心场景是多模态，V3的架构为此做了专门设计。想跟进的人，重点要处理图文混合数据的配比。我经验里，纯文本与图文交错数据的比例在3:1到5:1比较合适。图像侧如果有大量OCR类任务，需要单独加权重，否则模型会在自然图像上表现好，一遇到表格截图就崩。
指令精调阶段，不要只用简单问答对。要多加带引用和检索的样本，让模型学会在文档里找答案。V2.6被人吐槽不能传图片，根子就在于视觉入口的SFT样本太少，模型没见过足够多"用户上传图片后应该怎么回应"的对话。V3应该重点补了这块，而你在复现时，也别指望官方数据会自动满足你的业务场景。
5.3 最容易踩的坑
最后说几个我踩过的坑，每一条都是真金白银换来的。
第一，MoE模型的loss曲线非常容易波动。如果你发现训练曲线像锯齿一样来回跳，大概率是路由震荡，要加load balancing loss，权重0.01起步。第二，MLA在低精度训练时数值稳定性差，bf16下偶发NaN。解决办法是在attention输出后加一个额外的LayerNorm兜底，牺牲一点性能换训练稳定。第三，不要迷信"引用"两个字。别人跑得通不代表你能跑通，框架版本、数据清洗方式、学习率调度，任何一个变量都会让结果差很远。
还有一个更隐蔽的坑：多模态数据的batch组成。如果你在同一个batch里混了文本和图像样本，而两种样本的token长度差异过大，显存分配会非常不均匀。我建议图像样本单独建batch，或者用动态padding到相近长度，可以明显提高显存利用率。
我的习惯是：每次改架构先在一台8卡机上跑满一个batch，观察吞吐和内存曲线，再决定要不要扩到大规模集群。别看桌上摆着几百张卡就任性，架构不稳定时，卡越多亏得越凶。等小规模验证完了，再考虑全量训练，这样心里有底，遇到问题时也知道该查哪里。
