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预测。普通语言模型训练时每一步只预测下一个tokenmulti-token prediction则让模型同时预测后续好几个token。这个思路通俗讲就是给模型多安了几个探针——它必须在每一步训练中同时理解后面几步的语义从而学得更快。MiMo-V3明确引用了这项成果大概率是在训练阶段加入了多token预测的辅助损失。论文里的通常做法是让模型的主干继续预测下一个token然后额外接一个或者两个预测头同时预测第二、第三个token。训练时辅助损失只用来计算梯度更新主干推理阶段会把辅助头去掉所以推理速度不会受影响。这套设计对多模态模型特别有价值。图像理解中一个图像区块往往对应一组语义高度相关的token如果模型只能预测下一个token很容易在早期预测错一个然后一路放大。多token预测在训练时等于提前给了模型全局视角让视觉编码器和语言解码器的对齐更加稳定。对比维度MiMo-V2.6MiMo-V3推测参数结构Dense稠密MoE稀疏激活注意力机制常规MHA/GQAMLA变体低秩KV压缩上下文能力中等长度KV占用高长上下文KV占用降低50%以上多模态处理图片入口受限图像专用路由延迟分离训练目标标准Next Token Prediction多Token预测辅助loss3. 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观察吞吐和内存曲线再决定要不要扩到大规模集群。别看桌上摆着几百张卡就任性架构不稳定时卡越多亏得越凶。等小规模验证完了再考虑全量训练这样心里有底遇到问题时也知道该查哪里。
)
