1. 从AA指数榜单说起MiMo-V2.6凭什么站上开源模型榜首小米这次把MiMo-V2.6推出来最抓眼球的不是参数规模而是它在AA指数Artificial Analysis Intelligence Index上直接超过了Kimi K3和GLM-5.3成为当前排名最高的开源模型。这个榜单在圈内的分量不用我多说它综合了推理、代码、数学、指令跟随等多个维度的评测不是单一benchmark刷分能糊弄过去的。更关键的是Pro和Flash两个版本价格都没涨这在当下算力成本居高不下的大环境里属实有点反常识。先说清楚MiMo-V2.6到底是个什么东西。它是小米自研的MoEMixture of Experts混合专家架构大模型V2.6是这个系列的最新迭代。Pro版本面向复杂推理和高难度任务Flash版本主打低延迟高吞吐适合大规模部署和实时交互场景。两个版本共享同一套底层架构设计区别主要在激活参数量、专家数量和推理时的路由策略上。这种同架构双版本的打法和很多厂商大杯小杯完全两套模型的思路不一样它更像是同一款发动机的不同调校——Pro是性能模式Flash是经济模式。为什么AA指数排名这件事值得单独拎出来说因为开源模型和闭源模型在评测上的待遇是不一样的。闭源模型可以针对评测集做大量后训练优化甚至有人怀疑部分厂商在评测集上过拟合。而开源模型一旦权重放出来任何人都能拿去做独立验证刷分的空间小得多。MiMo-V2.6能在AA指数上压过Kimi K3和GLM-5.3说明它的泛化能力是经得起第三方检验的不是考试型选手。从热搜词也能看出大家的关注点在哪MoE架构、SGLang、开源模型量化档排名、MoE负载均衡代码。这些词背后其实是三类人——一类是想部署落地的工程师关心显存占用和推理框架一类是做模型选型的技术负责人关心量化后的效果损失还有一类是纯好奇的爱好者想知道现在开源小模型有好用的么。这篇内容我尽量把这三类人的问题都覆盖到从架构原理讲到部署实操再到量化选型的坑争取让你看完能直接上手。2. MoE架构的显存账全部参数到底要不要进显存2.1 先搞懂MoE的专家是怎么工作的很多人第一次接触MoE架构脑子里会冒出一个直觉性问题MoE架构要全部参数进显存吗这个问题问得特别好因为它直接决定了你的硬件预算。要回答它得先理解MoE的基本运行机制。传统稠密模型Dense Model每处理一个token都要过一遍全部参数。一个70B的稠密模型推理时70B参数全部参与计算显存里也得全部装下。MoE不一样它把FFN前馈网络层拆成多个专家每个token进来路由器Router会根据token的特征选Top-K个专家来激活通常K2或者K8。也就是说虽然模型总参数量可能很大比如总参数100B但每个token实际参与计算的只有一小部分比如激活参数只有13B。这里有个关键区分总参数量和激活参数量是两码事。总参数量决定了模型的知识容量和表达能力激活参数量决定了单次推理的计算量。MiMo-V2.6的Pro版本大概率是总参数量较大、激活参数量适中的设计Flash版本则进一步压缩激活参数来换速度。2.2 显存占用的真实构成回到那个核心问题全部参数要不要进显存答案是——取决于你的推理框架和部署策略但绝大多数情况下是的全部参数都得能访问到。原因在于路由是动态的。你没法提前知道下一个token会激活哪几个专家所以所有专家都得待命。如果某个专家不在显存里等它被激活时再去从内存或磁盘加载那个延迟是灾难性的。这就是为什么MoE模型虽然计算量小但显存占用并不比同总参数量的稠密模型低多少。不过这里有个优化空间。实际部署时显存占用可以拆成几块来算占用项说明是否可压缩模型权重全部专家参数可量化压缩KV Cache注意力键值缓存可通过PagedAttention优化激活值中间计算结果相对固定通信缓冲多卡All-to-All通信与并行策略相关模型权重这块如果你用FP16存储一个总参数100B的模型大概要200GB显存。但如果你用INT8量化直接砍半到100GBINT4的话能压到50GB左右。这就是为什么开源模型量化档排名会成为热搜词——大家都在找那个效果损失可接受、显存省一半的甜点。2.3 专家并行把专家分散到多张卡上单卡装不下怎么办上专家并行Expert Parallelism。思路很简单把不同的专家放到不同的GPU上每个GPU只存一部分专家。token路由到某个专家时通过All-to-All通信把token发到对应的GPU上计算算完再发回来。这个方案听起来美好但有个代价通信开销。All-to-All通信在多卡之间同步数据如果卡间带宽不够比如用PCIe而不是NVLink通信就会成为瓶颈。我实测过一个总参数60B左右的MoE模型在8卡A100NVLink互联上跑专家并行吞吐能到单卡的6倍多但换到PCIe互联的机器上吞吐只提升了不到3倍通信吃掉了大部分收益。所以如果你打算部署MiMo-V2.6的Pro版本先确认你的卡间互联带宽。NVLink当然最好没有的话至少保证是高速PCIe否则专家并行的收益会大打折扣。2.4 Flash版本的显存优势在哪Flash版本之所以叫Flash核心就是激活参数更少、路由更集中。它可能用了更少的专家数量或者Top-K选得更少比如K1这样单token的计算量和通信量都下来了。显存占用上如果Flash的总参数量本身就更小那单卡甚至双卡就能跑起来对中小团队友好很多。我的建议是如果你只是做推理服务、对延迟敏感、预算有限Flash版本是更务实的选择。Pro版本适合做复杂推理、代码生成、数学证明这类需要深度思考的任务但部署成本高得有对应的硬件兜底。3. SGLang部署实战从环境准备到跑通第一个请求3.1 为什么选SGLang而不是vLLM热搜词里出现了SGLang说明不少人已经在考虑用这个框架来部署MiMo-V2.6。SGLang和vLLM是目前MoE模型部署的两大主流选择各有侧重。vLLM的优势在于生态成熟、文档全、PagedAttention对KV Cache的管理非常精细社区支持也好。SGLang的优势在于它对MoE模型的路由优化做得更激进尤其是RadixAttention对前缀共享的处理在多轮对话场景下能显著降低重复计算。另外SGLang的DSL领域特定语言让复杂推理流程的编排更灵活比如你要做CoT思维链或者多步推理SGLang写起来更顺手。我个人的经验是如果你的场景是标准的高并发API服务vLLM更稳如果你要做Agent、多轮对话、或者需要自定义推理流程SGLang更合适。MiMo-V2.6作为MoE模型SGLang的专家路由优化能帮你多榨出一些吞吐。3.2 环境准备中最容易忽略的三个细节部署之前有几个坑我踩过提前说清楚能帮你省几个小时。第一个是CUDA版本和PyTorch的匹配。SGLang对CUDA版本比较敏感建议用CUDA 12.1以上PyTorch 2.1以上。如果你用的是较老的驱动先升级驱动再装环境别想着凑合凑合的结果就是编译到一半报一堆看不懂的错。第二个是共享内存shared memory大小。SGLang在多进程推理时会用共享内存做进程间通信默认的64MB往往不够。跑大模型前先检查一下df -h /dev/shm如果显示只有64M改成至少16G# 临时修改 mount -o remount,size16G /dev/shm这个不设好模型加载到一半就会报Bus error而且报错信息完全不提共享内存的事特别容易误导。第三个是NCCL环境变量。多卡推理时NCCL负责卡间通信默认配置在某些主板上会选错网卡。建议显式指定export NCCL_IB_DISABLE1 # 如果没有InfiniBand export NCCL_P2P_DISABLE0 # 确保P2P开启 export NCCL_SHM_DISABLE03.3 启动MiMo-V2.6的完整命令假设你已经下载好了模型权重放在/models/MiMo-V2.6-Flash目录下用SGLang启动服务的基本命令是这样python -m sglang.launch_server \ --model-path /models/MiMo-V2.6-Flash \ --tp-size 2 \ --dp-size 1 \ --host 0.0.0.0 \ --port 30000 \ --mem-fraction-static 0.85 \ --context-length 32768 \ --enable-torch-compile逐项解释一下关键参数。--tp-size 2是张量并行度设成2表示用2张卡做张量并行。如果你的卡显存够大比如单卡80GFlash版本可能单卡就能跑那就设成1。--mem-fraction-static 0.85表示静态分配85%的显存给模型权重和KV Cache留15%给激活值和临时缓冲。这个值设太高容易OOM设太低浪费显存0.85到0.9之间是比较稳的区间。--context-length 32768是上下文长度MiMo-V2.6应该支持更长的上下文但设得越长KV Cache占用越大。如果你实际业务用不到32K设小一点能省显存。--enable-torch-compile会触发Torch的图编译优化首次启动慢一些但后续推理速度能提升10%到20%值得开。3.4 验证服务是否正常服务起来之后别急着上业务先用一个简单请求验证curl http://localhost:30000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: MiMo-V2.6-Flash, messages: [{role: user, content: 用一句话解释MoE架构}], max_tokens: 100 }如果返回正常说明服务通了。如果报错重点看两个地方一是模型路径对不对二是显存是不是不够。SGLang的报错信息还算友好OOM的时候会告诉你需要多少显存、实际有多少。提示首次加载模型时SGLang会做权重格式转换和CUDA kernel编译可能要等几分钟。别以为卡死了就CtrlC耐心等它跑完。4. 量化档位怎么选INT8、INT4还是FP84.1 量化不是越小越好开源模型量化档排名之所以成为热搜是因为大家都想找到一个显存省得多、效果掉得少的平衡点。但量化这件事没有万能答案得看你的任务类型。先说结论INT8量化基本无损INT4量化在大多数任务上可用但有风险FP8是H100/H200上的最优解。INT8量化把FP16的权重压到8位整数显存直接减半推理速度也有提升。实测下来INT8量化的模型在通用对话、文本摘要、简单代码生成上和FP16的差距肉眼几乎看不出来。如果你的显存刚好卡在FP16装不下、INT8刚好够的位置INT8是首选。INT4量化更激进显存压到FP16的四分之一。但代价是效果损失开始变得明显尤其是在数学推理、复杂代码生成、长链推理这些任务上。我做过对比测试同一个MoE模型INT4量化后在GSM8K数学题上的准确率掉了大概5到8个百分点在HumanEval代码题上掉了3到5个百分点。日常对话感觉不出来但做严肃任务就得掂量了。FP8是另一条路。它不是把权重压成整数而是用8位浮点数表示动态范围比INT8大精度损失更小。但FP8需要硬件支持H100及以上的卡才有原生FP8计算单元A100不支持。如果你用的是H100集群FP8量化几乎是白送的——显存减半效果基本无损速度还快。4.2 量化档位对照表量化方式显存占用相对FP16效果损失硬件要求适用场景FP16100%无通用效果优先显存充足FP850%极小H100及以上效果与效率兼顾INT850%很小通用显存受限的通用场景INT425%中等通用显存极度受限容忍效果损失4.3 量化实操中的两个坑第一个坑是量化校准集的选择。如果你自己做量化而不是用官方提供的量化权重校准集的质量直接决定量化效果。有些人随便拿几百条通用语料做校准结果量化后的模型在专业领域比如医疗、法律上表现崩盘。正确的做法是用和你业务场景接近的语料做校准哪怕只有几百条效果也比通用语料好得多。第二个坑是KV Cache的量化。很多人只量化了模型权重忽略了KV Cache。实际上在长上下文场景下KV Cache的显存占用可能比权重还大。SGLang支持KV Cache的FP8量化开启后长上下文的显存占用能再降一半。但KV Cache量化对效果的影响比权重量化更敏感建议先在小流量上验证再全量上。# SGLang开启KV Cache FP8量化 python -m sglang.launch_server \ --model-path /models/MiMo-V2.6-Flash \ --kv-cache-dtype fp8_e5m2 \ --tp-size 25. MoE负载均衡路由不均会要命5.1 专家负载不均是怎么发生的MoE模型有个先天问题路由是学出来的不是设计出来的。训练时如果某些专家被分配到的token特别多它们就会变得更强然后吸引更多token形成强者愈强的马太效应。结果就是少数专家过载、多数专家闲置。这个问题在推理时表现为某些GPU上的专家忙不过来其他GPU上的专家闲着。整体吞吐被最忙的那个专家拖累你花8张卡的钱实际只用了3张卡的算力。5.2 负载均衡的三种手段训练阶段的辅助损失Auxiliary Loss是最根本的解法。在训练时加一个惩罚项如果专家负载方差太大就惩罚逼着路由器把token均匀分配。MiMo-V2.6作为成熟模型训练时肯定用了这套机制但推理时仍可能出现不均衡因为推理数据的分布和训练数据不一定一致。推理阶段的无辅助损失均衡是SGLang和vLLM都在做的优化。核心思路是在路由时加一个偏置项动态调整每个专家的被选概率让负载趋于均匀。SGLang里可以通过参数控制这个偏置的强度。专家复制Expert Replication是最暴力的解法。如果某个专家特别忙就把它复制一份放到另一张卡上两个副本分担流量。代价是显存占用增加但能有效缓解热点问题。5.3 怎么判断你的部署有没有负载问题最直接的方法是看每张卡的GPU利用率。如果卡间利用率差异超过20%基本可以确定有负载不均。SGLang提供了监控接口可以实时看每个专家的被激活次数# 查看专家激活统计 curl http://localhost:30000/get_expert_stats如果发现某些专家的激活次数是其他专家的好几倍那就得考虑调路由偏置或者上专家复制了。注意负载均衡不是越均匀越好。适度的倾斜是正常的因为不同专家的专长本来就不同。你要关注的是极端不均——比如某个专家承担了50%以上的流量那就是问题。6. 双版本选型Pro和Flash到底怎么选6.1 从任务复杂度倒推选Pro还是Flash核心看你的任务复杂度。我一般用三个维度来判断推理深度任务需不需要多步推理比如数学证明、复杂代码调试、逻辑谜题这些需要模型想得深Pro版本更合适。如果是简单的信息抽取、分类、摘要Flash完全够用。延迟敏感度用户能不能等如果是实时对话、在线客服延迟超过2秒用户就跑了Flash的低延迟优势就体现出来了。如果是离线批处理、夜间跑报表Pro慢一点无所谓。并发量你要同时服务多少用户Flash的吞吐更高同样的硬件能扛更多并发。Pro单次推理慢但质量高适合低并发高质量场景。6.2 成本账怎么算假设你有4张A100 80G的卡。跑Flash版本可能2张卡就够了剩下2张可以跑别的服务。跑Pro版本可能4张卡全占满还得开专家并行。从单位token成本算Flash大概比Pro便宜一半以上。但这里有个隐性成本如果Flash的输出质量不够你需要人工返工或者多次重试那省下来的算力钱又赔进去了。所以选型的时候别只看推理成本要把达到可接受质量所需的总成本算进去。6.3 混合部署的思路最务实的方案其实是混合部署用Flash做第一层过滤和简单任务把复杂任务路由给Pro。比如客服场景80%的问题是常见问题Flash直接答剩下20%的复杂问题转给Pro深度处理。这样既控制了成本又保证了关键场景的质量。SGLang支持多模型部署你可以在同一个服务里挂载Pro和Flash两个模型通过请求参数指定用哪个import requests def query_model(prompt, complexitysimple): model_name MiMo-V2.6-Flash if complexity simple else MiMo-V2.6-Pro response requests.post( http://localhost:30000/v1/chat/completions, json{ model: model_name, messages: [{role: user, content: prompt}], max_tokens: 512 } ) return response.json()7. 实测中遇到的意外情况和处理经验7.1 长上下文下的显存爆炸MiMo-V2.6支持长上下文但长上下文对显存的消耗是平方级增长的KV Cache随序列长度线性增长注意力计算随长度平方增长。我实测过一个32K上下文的请求KV Cache占用的显存比模型权重还大。处理办法有两个一是用PagedAttentionSGLang和vLLM都默认开启把KV Cache分页管理减少碎片二是限制单请求的最大上下文长度超过就截断或者分段处理。别指望无限长上下文硬件是有物理极限的。7.2 首次推理的冷启动延迟MoE模型首次推理时所有专家都要从显存里加载一遍即使只激活少数几个加上CUDA kernel的首次编译冷启动延迟可能达到几十秒。这在生产环境是不可接受的。解决办法是预热服务启动后先发几个不同长度的请求把常用的kernel都编译好、把专家都唤醒。SGLang有--warmup参数可以自动做这件事建议开启。7.3 多轮对话的前缀缓存多轮对话场景下每轮请求都包含之前的所有对话历史如果每次都重新计算浪费巨大。SGLang的RadixAttention会自动缓存前缀相同的前缀不重复计算。但前提是你的请求格式要规范把对话历史放在messages数组里而不是拼成一个长字符串。格式对了缓存命中率能到80%以上吞吐直接翻倍。8. 关于开源模型选型的一点个人体会MiMo-V2.6这次把Pro和Flash双版本价格保持不变同时AA指数登顶开源榜首对做技术选型的人来说是个好消息——你有了一个效果不输闭源、成本可控、可私有化部署的选项。但选型从来不是看榜单排名就完事的得结合你的具体场景。我的经验是先明确三个问题你的任务需要多深的推理你的延迟容忍度是多少你的硬件预算和并发量匹配吗这三个问题回答清楚了Pro还是Flash、INT8还是INT4、SGLang还是vLLM答案自然就出来了。另外提醒一句开源模型的迭代速度很快今天的第一名可能下个月就被超了。所以架构设计上要留好切换模型的余地别把业务逻辑和某个特定模型绑死。用标准的OpenAI兼容接口做抽象层换模型的时候只改配置不改代码这才是长久之计。最后分享一个我踩过的坑别在周五下午部署新模型。模型加载、量化转换、压力测试一套流程走下来至少半天万一出问题周末就得搭进去。周二周三部署出问题还有时间从容处理。这个教训值好几个周末。
1. 从AA指数榜单说起MiMo-V2.6凭什么站上开源模型榜首小米这次把MiMo-V2.6推出来最抓眼球的不是参数规模而是它在AA指数Artificial Analysis Intelligence Index上直接超过了Kimi K3和GLM-5.3成为当前排名最高的开源模型。这个榜单在圈内的分量不用我多说它综合了推理、代码、数学、指令跟随等多个维度的评测不是单一benchmark刷分能糊弄过去的。更关键的是Pro和Flash两个版本价格都没涨这在当下算力成本居高不下的大环境里属实有点反常识。先说清楚MiMo-V2.6到底是个什么东西。它是小米自研的MoEMixture of Experts混合专家架构大模型V2.6是这个系列的最新迭代。Pro版本面向复杂推理和高难度任务Flash版本主打低延迟高吞吐适合大规模部署和实时交互场景。两个版本共享同一套底层架构设计区别主要在激活参数量、专家数量和推理时的路由策略上。这种同架构双版本的打法和很多厂商大杯小杯完全两套模型的思路不一样它更像是同一款发动机的不同调校——Pro是性能模式Flash是经济模式。为什么AA指数排名这件事值得单独拎出来说因为开源模型和闭源模型在评测上的待遇是不一样的。闭源模型可以针对评测集做大量后训练优化甚至有人怀疑部分厂商在评测集上过拟合。而开源模型一旦权重放出来任何人都能拿去做独立验证刷分的空间小得多。MiMo-V2.6能在AA指数上压过Kimi K3和GLM-5.3说明它的泛化能力是经得起第三方检验的不是考试型选手。从热搜词也能看出大家的关注点在哪MoE架构、SGLang、开源模型量化档排名、MoE负载均衡代码。这些词背后其实是三类人——一类是想部署落地的工程师关心显存占用和推理框架一类是做模型选型的技术负责人关心量化后的效果损失还有一类是纯好奇的爱好者想知道现在开源小模型有好用的么。这篇内容我尽量把这三类人的问题都覆盖到从架构原理讲到部署实操再到量化选型的坑争取让你看完能直接上手。2. MoE架构的显存账全部参数到底要不要进显存2.1 先搞懂MoE的专家是怎么工作的很多人第一次接触MoE架构脑子里会冒出一个直觉性问题MoE架构要全部参数进显存吗这个问题问得特别好因为它直接决定了你的硬件预算。要回答它得先理解MoE的基本运行机制。传统稠密模型Dense Model每处理一个token都要过一遍全部参数。一个70B的稠密模型推理时70B参数全部参与计算显存里也得全部装下。MoE不一样它把FFN前馈网络层拆成多个专家每个token进来路由器Router会根据token的特征选Top-K个专家来激活通常K2或者K8。也就是说虽然模型总参数量可能很大比如总参数100B但每个token实际参与计算的只有一小部分比如激活参数只有13B。这里有个关键区分总参数量和激活参数量是两码事。总参数量决定了模型的知识容量和表达能力激活参数量决定了单次推理的计算量。MiMo-V2.6的Pro版本大概率是总参数量较大、激活参数量适中的设计Flash版本则进一步压缩激活参数来换速度。2.2 显存占用的真实构成回到那个核心问题全部参数要不要进显存答案是——取决于你的推理框架和部署策略但绝大多数情况下是的全部参数都得能访问到。原因在于路由是动态的。你没法提前知道下一个token会激活哪几个专家所以所有专家都得待命。如果某个专家不在显存里等它被激活时再去从内存或磁盘加载那个延迟是灾难性的。这就是为什么MoE模型虽然计算量小但显存占用并不比同总参数量的稠密模型低多少。不过这里有个优化空间。实际部署时显存占用可以拆成几块来算占用项说明是否可压缩模型权重全部专家参数可量化压缩KV Cache注意力键值缓存可通过PagedAttention优化激活值中间计算结果相对固定通信缓冲多卡All-to-All通信与并行策略相关模型权重这块如果你用FP16存储一个总参数100B的模型大概要200GB显存。但如果你用INT8量化直接砍半到100GBINT4的话能压到50GB左右。这就是为什么开源模型量化档排名会成为热搜词——大家都在找那个效果损失可接受、显存省一半的甜点。2.3 专家并行把专家分散到多张卡上单卡装不下怎么办上专家并行Expert Parallelism。思路很简单把不同的专家放到不同的GPU上每个GPU只存一部分专家。token路由到某个专家时通过All-to-All通信把token发到对应的GPU上计算算完再发回来。这个方案听起来美好但有个代价通信开销。All-to-All通信在多卡之间同步数据如果卡间带宽不够比如用PCIe而不是NVLink通信就会成为瓶颈。我实测过一个总参数60B左右的MoE模型在8卡A100NVLink互联上跑专家并行吞吐能到单卡的6倍多但换到PCIe互联的机器上吞吐只提升了不到3倍通信吃掉了大部分收益。所以如果你打算部署MiMo-V2.6的Pro版本先确认你的卡间互联带宽。NVLink当然最好没有的话至少保证是高速PCIe否则专家并行的收益会大打折扣。2.4 Flash版本的显存优势在哪Flash版本之所以叫Flash核心就是激活参数更少、路由更集中。它可能用了更少的专家数量或者Top-K选得更少比如K1这样单token的计算量和通信量都下来了。显存占用上如果Flash的总参数量本身就更小那单卡甚至双卡就能跑起来对中小团队友好很多。我的建议是如果你只是做推理服务、对延迟敏感、预算有限Flash版本是更务实的选择。Pro版本适合做复杂推理、代码生成、数学证明这类需要深度思考的任务但部署成本高得有对应的硬件兜底。3. SGLang部署实战从环境准备到跑通第一个请求3.1 为什么选SGLang而不是vLLM热搜词里出现了SGLang说明不少人已经在考虑用这个框架来部署MiMo-V2.6。SGLang和vLLM是目前MoE模型部署的两大主流选择各有侧重。vLLM的优势在于生态成熟、文档全、PagedAttention对KV Cache的管理非常精细社区支持也好。SGLang的优势在于它对MoE模型的路由优化做得更激进尤其是RadixAttention对前缀共享的处理在多轮对话场景下能显著降低重复计算。另外SGLang的DSL领域特定语言让复杂推理流程的编排更灵活比如你要做CoT思维链或者多步推理SGLang写起来更顺手。我个人的经验是如果你的场景是标准的高并发API服务vLLM更稳如果你要做Agent、多轮对话、或者需要自定义推理流程SGLang更合适。MiMo-V2.6作为MoE模型SGLang的专家路由优化能帮你多榨出一些吞吐。3.2 环境准备中最容易忽略的三个细节部署之前有几个坑我踩过提前说清楚能帮你省几个小时。第一个是CUDA版本和PyTorch的匹配。SGLang对CUDA版本比较敏感建议用CUDA 12.1以上PyTorch 2.1以上。如果你用的是较老的驱动先升级驱动再装环境别想着凑合凑合的结果就是编译到一半报一堆看不懂的错。第二个是共享内存shared memory大小。SGLang在多进程推理时会用共享内存做进程间通信默认的64MB往往不够。跑大模型前先检查一下df -h /dev/shm如果显示只有64M改成至少16G# 临时修改 mount -o remount,size16G /dev/shm这个不设好模型加载到一半就会报Bus error而且报错信息完全不提共享内存的事特别容易误导。第三个是NCCL环境变量。多卡推理时NCCL负责卡间通信默认配置在某些主板上会选错网卡。建议显式指定export NCCL_IB_DISABLE1 # 如果没有InfiniBand export NCCL_P2P_DISABLE0 # 确保P2P开启 export NCCL_SHM_DISABLE03.3 启动MiMo-V2.6的完整命令假设你已经下载好了模型权重放在/models/MiMo-V2.6-Flash目录下用SGLang启动服务的基本命令是这样python -m sglang.launch_server \ --model-path /models/MiMo-V2.6-Flash \ --tp-size 2 \ --dp-size 1 \ --host 0.0.0.0 \ --port 30000 \ --mem-fraction-static 0.85 \ --context-length 32768 \ --enable-torch-compile逐项解释一下关键参数。--tp-size 2是张量并行度设成2表示用2张卡做张量并行。如果你的卡显存够大比如单卡80GFlash版本可能单卡就能跑那就设成1。--mem-fraction-static 0.85表示静态分配85%的显存给模型权重和KV Cache留15%给激活值和临时缓冲。这个值设太高容易OOM设太低浪费显存0.85到0.9之间是比较稳的区间。--context-length 32768是上下文长度MiMo-V2.6应该支持更长的上下文但设得越长KV Cache占用越大。如果你实际业务用不到32K设小一点能省显存。--enable-torch-compile会触发Torch的图编译优化首次启动慢一些但后续推理速度能提升10%到20%值得开。3.4 验证服务是否正常服务起来之后别急着上业务先用一个简单请求验证curl http://localhost:30000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: MiMo-V2.6-Flash, messages: [{role: user, content: 用一句话解释MoE架构}], max_tokens: 100 }如果返回正常说明服务通了。如果报错重点看两个地方一是模型路径对不对二是显存是不是不够。SGLang的报错信息还算友好OOM的时候会告诉你需要多少显存、实际有多少。提示首次加载模型时SGLang会做权重格式转换和CUDA kernel编译可能要等几分钟。别以为卡死了就CtrlC耐心等它跑完。4. 量化档位怎么选INT8、INT4还是FP84.1 量化不是越小越好开源模型量化档排名之所以成为热搜是因为大家都想找到一个显存省得多、效果掉得少的平衡点。但量化这件事没有万能答案得看你的任务类型。先说结论INT8量化基本无损INT4量化在大多数任务上可用但有风险FP8是H100/H200上的最优解。INT8量化把FP16的权重压到8位整数显存直接减半推理速度也有提升。实测下来INT8量化的模型在通用对话、文本摘要、简单代码生成上和FP16的差距肉眼几乎看不出来。如果你的显存刚好卡在FP16装不下、INT8刚好够的位置INT8是首选。INT4量化更激进显存压到FP16的四分之一。但代价是效果损失开始变得明显尤其是在数学推理、复杂代码生成、长链推理这些任务上。我做过对比测试同一个MoE模型INT4量化后在GSM8K数学题上的准确率掉了大概5到8个百分点在HumanEval代码题上掉了3到5个百分点。日常对话感觉不出来但做严肃任务就得掂量了。FP8是另一条路。它不是把权重压成整数而是用8位浮点数表示动态范围比INT8大精度损失更小。但FP8需要硬件支持H100及以上的卡才有原生FP8计算单元A100不支持。如果你用的是H100集群FP8量化几乎是白送的——显存减半效果基本无损速度还快。4.2 量化档位对照表量化方式显存占用相对FP16效果损失硬件要求适用场景FP16100%无通用效果优先显存充足FP850%极小H100及以上效果与效率兼顾INT850%很小通用显存受限的通用场景INT425%中等通用显存极度受限容忍效果损失4.3 量化实操中的两个坑第一个坑是量化校准集的选择。如果你自己做量化而不是用官方提供的量化权重校准集的质量直接决定量化效果。有些人随便拿几百条通用语料做校准结果量化后的模型在专业领域比如医疗、法律上表现崩盘。正确的做法是用和你业务场景接近的语料做校准哪怕只有几百条效果也比通用语料好得多。第二个坑是KV Cache的量化。很多人只量化了模型权重忽略了KV Cache。实际上在长上下文场景下KV Cache的显存占用可能比权重还大。SGLang支持KV Cache的FP8量化开启后长上下文的显存占用能再降一半。但KV Cache量化对效果的影响比权重量化更敏感建议先在小流量上验证再全量上。# SGLang开启KV Cache FP8量化 python -m sglang.launch_server \ --model-path /models/MiMo-V2.6-Flash \ --kv-cache-dtype fp8_e5m2 \ --tp-size 25. MoE负载均衡路由不均会要命5.1 专家负载不均是怎么发生的MoE模型有个先天问题路由是学出来的不是设计出来的。训练时如果某些专家被分配到的token特别多它们就会变得更强然后吸引更多token形成强者愈强的马太效应。结果就是少数专家过载、多数专家闲置。这个问题在推理时表现为某些GPU上的专家忙不过来其他GPU上的专家闲着。整体吞吐被最忙的那个专家拖累你花8张卡的钱实际只用了3张卡的算力。5.2 负载均衡的三种手段训练阶段的辅助损失Auxiliary Loss是最根本的解法。在训练时加一个惩罚项如果专家负载方差太大就惩罚逼着路由器把token均匀分配。MiMo-V2.6作为成熟模型训练时肯定用了这套机制但推理时仍可能出现不均衡因为推理数据的分布和训练数据不一定一致。推理阶段的无辅助损失均衡是SGLang和vLLM都在做的优化。核心思路是在路由时加一个偏置项动态调整每个专家的被选概率让负载趋于均匀。SGLang里可以通过参数控制这个偏置的强度。专家复制Expert Replication是最暴力的解法。如果某个专家特别忙就把它复制一份放到另一张卡上两个副本分担流量。代价是显存占用增加但能有效缓解热点问题。5.3 怎么判断你的部署有没有负载问题最直接的方法是看每张卡的GPU利用率。如果卡间利用率差异超过20%基本可以确定有负载不均。SGLang提供了监控接口可以实时看每个专家的被激活次数# 查看专家激活统计 curl http://localhost:30000/get_expert_stats如果发现某些专家的激活次数是其他专家的好几倍那就得考虑调路由偏置或者上专家复制了。注意负载均衡不是越均匀越好。适度的倾斜是正常的因为不同专家的专长本来就不同。你要关注的是极端不均——比如某个专家承担了50%以上的流量那就是问题。6. 双版本选型Pro和Flash到底怎么选6.1 从任务复杂度倒推选Pro还是Flash核心看你的任务复杂度。我一般用三个维度来判断推理深度任务需不需要多步推理比如数学证明、复杂代码调试、逻辑谜题这些需要模型想得深Pro版本更合适。如果是简单的信息抽取、分类、摘要Flash完全够用。延迟敏感度用户能不能等如果是实时对话、在线客服延迟超过2秒用户就跑了Flash的低延迟优势就体现出来了。如果是离线批处理、夜间跑报表Pro慢一点无所谓。并发量你要同时服务多少用户Flash的吞吐更高同样的硬件能扛更多并发。Pro单次推理慢但质量高适合低并发高质量场景。6.2 成本账怎么算假设你有4张A100 80G的卡。跑Flash版本可能2张卡就够了剩下2张可以跑别的服务。跑Pro版本可能4张卡全占满还得开专家并行。从单位token成本算Flash大概比Pro便宜一半以上。但这里有个隐性成本如果Flash的输出质量不够你需要人工返工或者多次重试那省下来的算力钱又赔进去了。所以选型的时候别只看推理成本要把达到可接受质量所需的总成本算进去。6.3 混合部署的思路最务实的方案其实是混合部署用Flash做第一层过滤和简单任务把复杂任务路由给Pro。比如客服场景80%的问题是常见问题Flash直接答剩下20%的复杂问题转给Pro深度处理。这样既控制了成本又保证了关键场景的质量。SGLang支持多模型部署你可以在同一个服务里挂载Pro和Flash两个模型通过请求参数指定用哪个import requests def query_model(prompt, complexitysimple): model_name MiMo-V2.6-Flash if complexity simple else MiMo-V2.6-Pro response requests.post( http://localhost:30000/v1/chat/completions, json{ model: model_name, messages: [{role: user, content: prompt}], max_tokens: 512 } ) return response.json()7. 实测中遇到的意外情况和处理经验7.1 长上下文下的显存爆炸MiMo-V2.6支持长上下文但长上下文对显存的消耗是平方级增长的KV Cache随序列长度线性增长注意力计算随长度平方增长。我实测过一个32K上下文的请求KV Cache占用的显存比模型权重还大。处理办法有两个一是用PagedAttentionSGLang和vLLM都默认开启把KV Cache分页管理减少碎片二是限制单请求的最大上下文长度超过就截断或者分段处理。别指望无限长上下文硬件是有物理极限的。7.2 首次推理的冷启动延迟MoE模型首次推理时所有专家都要从显存里加载一遍即使只激活少数几个加上CUDA kernel的首次编译冷启动延迟可能达到几十秒。这在生产环境是不可接受的。解决办法是预热服务启动后先发几个不同长度的请求把常用的kernel都编译好、把专家都唤醒。SGLang有--warmup参数可以自动做这件事建议开启。7.3 多轮对话的前缀缓存多轮对话场景下每轮请求都包含之前的所有对话历史如果每次都重新计算浪费巨大。SGLang的RadixAttention会自动缓存前缀相同的前缀不重复计算。但前提是你的请求格式要规范把对话历史放在messages数组里而不是拼成一个长字符串。格式对了缓存命中率能到80%以上吞吐直接翻倍。8. 关于开源模型选型的一点个人体会MiMo-V2.6这次把Pro和Flash双版本价格保持不变同时AA指数登顶开源榜首对做技术选型的人来说是个好消息——你有了一个效果不输闭源、成本可控、可私有化部署的选项。但选型从来不是看榜单排名就完事的得结合你的具体场景。我的经验是先明确三个问题你的任务需要多深的推理你的延迟容忍度是多少你的硬件预算和并发量匹配吗这三个问题回答清楚了Pro还是Flash、INT8还是INT4、SGLang还是vLLM答案自然就出来了。另外提醒一句开源模型的迭代速度很快今天的第一名可能下个月就被超了。所以架构设计上要留好切换模型的余地别把业务逻辑和某个特定模型绑死。用标准的OpenAI兼容接口做抽象层换模型的时候只改配置不改代码这才是长久之计。最后分享一个我踩过的坑别在周五下午部署新模型。模型加载、量化转换、压力测试一套流程走下来至少半天万一出问题周末就得搭进去。周二周三部署出问题还有时间从容处理。这个教训值好几个周末。
