★ FEATURED ARTICLE 1. 小米这次把开源模型的牌桌掀了小米 MiMo-V2.6 发布的消息出来那天我正在调一个 MoE 推理服务的负载均衡参数群里直接炸了锅。倒不是因为小米发大模型这件事本身有多意外——毕竟 MiMo 系列之前已经刷过几轮存在感——而是这次的两个数字实在有点扎眼Pro 与 Flash 双版本价格不变同时AA 指数排名直接超过 Kimi K3 和 GLM-5.3成为当前排名最高的开源模型。先把话说在前面AA 指数Artificial Analysis 综合指数不是万能的它更像是一个综合体检报告把推理、知识、代码、指令跟随等一堆维度揉成一个分数。但它的参考价值在于同一套题、同一个评测口径下横向对比比各家自己发的我们超过了 GPT-4要靠谱得多。所以当 MiMo-V2.6 在这个榜单上把几个老牌开源选手压下去的时候值得认真拆一拆它到底做对了什么。这篇不是新闻通稿我想从一个实际要部署、要算成本、要调吞吐的工程视角聊聊 MiMo-V2.6 这次的双版本策略、MoE 架构带来的显存与负载均衡问题、SGLang 部署时的真实坑以及开源模型质变这件事对普通开发者到底意味着什么。如果你正在纠结现在开源小模型有好用的么、或者想知道 MoE 架构到底要不要全部参数进显存这篇应该能给你一些能直接抄的结论。2. Pro 与 Flash 双版本价格不变背后的产品逻辑2.1 为什么是双版本而不是一个大模型打天下很多人第一反应是既然 Pro 更强为什么还要留一个 Flash直接上 Pro 不就完了。这个想法在实验室里成立在工程里不成立。真实场景里请求是分层的。我手上跑过的业务里大概有这么几档高频低难度意图分类、槽位抽取、简单改写、格式转换。这类请求占了总量的 60% 到 80%但对模型能力要求极低。中频中难度多轮对话、带上下文的问答、中等复杂度的代码补全。低频高难度复杂推理、长链路 Agent 规划、跨文件代码重构。如果所有请求都走 Pro成本会以肉眼可见的速度烧起来。Flash 存在的意义就是把前两档接住让 Pro 只处理真正需要它的那部分。这不是阉割版而是分层服务——和 CDN 边缘节点回源到中心节点的逻辑一模一样。小米这次强调价格不变我理解有两层意思一是 Flash 的定价维持在和上一代同级甚至更低的水平二是 Pro 虽然能力涨了但没有借机涨价。对做应用的人来说这意味着单位 token 的性价比是实打实提升的而不是能力涨了但你也得多掏钱。2.2 两个版本的能力边界怎么划从公开的评测分布看Pro 和 Flash 的差距主要集中在长链路推理和复杂代码上而在短文本理解、常规问答、指令跟随这些维度上两者的差距被压得很小。这个分布很关键它直接决定了你的路由策略。我的建议是这样划请求类型推荐版本理由意图识别、分类、抽取Flash能力足够延迟和成本优势明显单轮问答、知识查询Flash差距小没必要上 Pro多轮复杂对话看上下文长度短上下文 Flash长上下文 Pro代码生成与补全ProFlash 在复杂逻辑上会掉链子Agent 规划、工具调用链Pro长链路推理是 Pro 的主场长文档摘要与改写Pro长上下文稳定性更好提示不要凭感觉路由。上线前一定要用你自己的真实请求集跑一遍 A/B把Flash 答不好的那部分单独捞出来看往往和你预想的分布不一样。我见过太多团队拍脑袋觉得这个任务很简单结果 Flash 一上就翻车。2.3 价格不变对成本模型的实际影响算一笔账。假设你每天有 100 万次请求平均每次输入 800 token、输出 300 token。如果全部走 Pro成本是基准值如果按 7:3 分流70% 走 Flash30% 走 Pro而 Flash 单价假设是 Pro 的 1/5那么总成本大约是全 Pro1.0 × 基准 分流后0.7 × 0.2 0.3 × 1.0 0.14 0.30 0.44 × 基准也就是说分流能砍掉一半以上的成本而用户体验的下降几乎感知不到——因为被分流的那 70% 本来就是 Flash 能轻松搞定的。这就是双版本策略真正的价值不是让你二选一而是让你按需付费。3. MoE 架构能力涨了但显存这道坎绕不过去3.1 MoE 到底解决了什么问题MiMo-V2.6 用的是 MoEMixture of Experts混合专家架构这一点从热搜词里也能看出来。MoE 的核心思想其实很朴素不是每个 token 都需要动用全部参数。传统稠密模型Dense里每个 token 都要过一遍所有参数。参数量越大能力越强但推理成本也线性上涨。MoE 把 FFN 层拆成很多个专家每个 token 只激活其中一小部分比如 8 个专家里激活 2 个。这样总参数量可以做得很大但单次推理的实际计算量只和激活的专家数相关。打个比方稠密模型像是一家所有科室都开着的医院你去看个感冒也得让全院医生待命MoE 像是一家分诊制的医院你挂哪个科就只叫哪个科的医生其他科室该干嘛干嘛。总医生数总参数可以很多但你这次看病实际动用的激活参数很少。这就是为什么 MoE 能做到参数规模大、推理成本相对可控。MiMo-V2.6 能在 AA 指数上超过几个对手MoE 架构带来的大容量 可控成本是重要原因。3.2 MoE 架构要全部参数进显存吗——这是最常被问的问题答案要分两层说很多人在这里被绕晕。第一层权重加载。是的所有专家的权重都需要能被访问到。因为不同 token 会路由到不同专家你没法预知下一个 token 会用到哪个专家。所以从权重必须可寻址这个角度说全部参数都得在可访问的存储里。第二层显存占用。这里才是关键。全部参数可访问不等于全部塞进单卡显存。实际部署时有几种做法全量驻显存所有专家权重都放 GPU 显存。延迟最低但显存需求最大。专家卸载offload把部分专家放 CPU 内存或 NVMe用到时再换入。显存需求降下来但延迟会上去。专家并行EP把不同专家分布到不同 GPU 上token 路由时跨卡通信。这是大规模部署的主流做法。所以MoE 要全部参数进显存吗这个问题准确的回答是权重必须全部可访问但不一定全部常驻单卡显存。具体怎么选取决于你的延迟预算和硬件规模。部署方式显存需求延迟适用场景全量驻显存最高最低单机多卡、延迟敏感专家卸载中中高显存受限、可容忍延迟专家并行分散到多卡低有通信开销大规模集群部署注意MoE 的显存账不能只算权重。KV Cache、激活值、通信缓冲区都要算进去。我见过有人按激活参数估显存结果一上线就 OOM因为漏算了非激活专家的权重驻留。3.3 负载均衡MoE 部署里最容易翻车的地方MoE 有个天然的坑专家负载不均。如果路由网络学偏了某些专家被疯狂调用另一些几乎没人用就会出现热点专家——它所在的那张卡成了瓶颈其他卡在摸鱼。这在训练时叫专家坍缩在推理时表现为尾延迟飙升。热搜里出现moe 负载均衡代码不是偶然这是所有做 MoE 部署的人都会撞上的问题。常见的应对手段负载均衡损失auxiliary loss训练阶段就约束路由分布让专家使用更均匀。这是模型侧的事推理时你改不了。容量因子capacity factor给每个专家设一个 token 上限超出的 token 走溢出路径。能防热点但会丢信息。推理侧的动态调度监控各专家实际负载动态调整请求分发。这是部署侧能做的。我自己的经验是上线前一定要压测把各专家的调用频次打出来看分布。如果发现前 20% 的专家承担了 60% 以上的流量那基本可以确定会遇到尾延迟问题得提前做调度优化。4. SGLang 部署实战从环境到跑通的那些坑4.1 为什么是 SGLang而不是 vLLM热搜里sglang 和 vllm被一起搜说明很多人在纠结选哪个。我的看法是两者都能跑 MoE但侧重点不同。vLLM 的强项是 PagedAttention 和成熟的生态通用性好社区大遇到问题好搜。SGLang 的强项是RadixAttention前缀缓存和结构化生成在多轮对话、Agent 这类大量共享前缀的场景下吞吐优势非常明显。MiMo-V2.6 这类模型如果用在 Agent、多轮对话场景SGLang 的前缀缓存能省下大量重复计算。这也是为什么这次发布相关的内容里 SGLang 被反复提到——它不是随便选的是场景驱动的。维度SGLangvLLM前缀缓存RadixAttention强有但相对弱结构化输出原生支持强需额外配置生态成熟度较新更成熟多轮/Agent 场景优势明显可用社区问题检索较少丰富选型建议如果你的场景是多轮对话、Agent、大量共享前缀优先 SGLang如果是通用单轮推理、追求生态稳定vLLM 更稳。4.2 环境准备最容易被忽略的三个细节跑通 SGLang 部署 MoE环境这块有三个坑我踩过不止一次。第一CUDA 和驱动的版本匹配。SGLang 对 CUDA 版本比较敏感尤其是用到特定 kernel 优化时。装之前先确认驱动支持的 CUDA 上限别直接pip install完事。第二PyTorch 版本。SGLang 通常要求较新的 PyTorch但太新又可能和某些算子不兼容。建议按官方推荐的版本组合来别自己乱升。第三显存预估要留余量。MoE 的显存占用比同激活参数的稠密模型高不少因为非激活专家权重也要驻留。我的经验是按总参数而非激活参数估显存再留 20% 余量。# 查看 GPU 和驱动信息 nvidia-smi # 确认 CUDA 版本 nvcc --version # 建议用虚拟环境隔离依赖 python -m venv mimo_env source mimo_env/bin/activate4.3 启动参数怎么配一份可参考的配置SGLang 启动 MoE 模型时几个关键参数决定了吞吐和显存python -m sglang.launch_server \ --model-path /path/to/mimo-v2.6 \ --tp-size 4 \ --mem-fraction-static 0.85 \ --max-running-requests 256 \ --context-length 32768 \ --enable-torch-compile逐个说--tp-size张量并行度等于你用几张卡。MoE 模型建议至少 2 卡起具体看总参数量。--mem-fraction-static静态显存占比。别设太高0.85 已经比较激进留点给 KV Cache 和临时缓冲。设到 0.95 很容易 OOM。--max-running-requests并发请求上限。这个值直接影响吞吐和延迟的平衡需要压测调。--context-length上下文长度。设太大浪费显存设太小长请求会被截断按实际业务定。--enable-torch-compile开启编译优化首次启动慢但后续推理更快。提示mem-fraction-static是最容易设错的一个。很多人为了榨干显存设到 0.95结果一有长请求就崩。宁可保守一点稳定比极限吞吐重要。4.4 跑通之后的第一件事压测而不是庆祝服务起来了能返回结果了这时候千万别急着上线。第一件事是压测而且要压出这几个数首 token 延迟TTFT用户感知最明显的指标。每 token 输出延迟TPOT决定生成速度。吞吐tokens/s决定成本。各专家调用分布决定会不会有热点。压测工具可以用sglang.bench_serving也可以用自己写的脚本打真实请求。关键是用真实分布别用均匀分布的假数据——真实请求的长尾特征才是暴露问题的关键。我一般会跑三档并发低并发看延迟下限中并发看稳态高并发看崩溃点。三档跑完心里就有数了。5. 开源模型质变这件事普通开发者该怎么接5.1 AA 指数排名第一意味着什么又不意味着什么MiMo-V2.6 在 AA 指数上超过 Kimi K3、GLM-5.3成为排名最高的开源模型这个成绩值得肯定。但要清醒地看它意味着在标准化评测下这个模型综合能力确实到了第一梯队开源模型和闭源头部模型的差距在快速缩小。它不意味着它在你的具体任务上一定最好。AA 指数是综合分你的任务可能恰好落在它的弱项上。评测榜单是筛选器不是决策器。我的做法一直是榜单用来缩小候选范围最终决策一定靠自己的评测集。花半天时间搭一套自己的 eval比看十篇评测文章都值。5.2 开源模型质变对应用层的影响开源模型质变这个说法最近很热我认同这个判断但想说得更具体一点。质变体现在三个层面第一能力下限被抬高了。以前开源模型做 Agent 经常在工具调用上翻车现在第一梯队的开源模型已经能稳定跑通多步工具链。这意味着很多以前只能用闭源 API 的场景现在可以自部署了。第二成本结构变了。自部署的边际成本主要是硬件和运维一旦跑起来请求量越大单位成本越低。对于高频场景自部署的经济性越来越明显。第三数据主权回来了。敏感数据不出内网这对很多行业是硬需求。开源模型能力上来之后自部署不再是能力妥协的代名词。5.3 一个务实的落地路径如果你现在想接 MiMo-V2.6我建议按这个顺序走先跑通用 SGLang 把服务起起来确认能正常推理。再评测用你自己的真实任务集对比 MiMo-V2.6 和你现在用的模型。做路由如果 Pro 和 Flash 都可用设计分流策略先小流量灰度。压测调优根据真实流量调并发、显存、批处理参数。监控上线把延迟、吞吐、错误率、专家负载都监控起来再逐步放量。别跳步。我见过太多团队跑通即上线结果在真实流量下各种翻车。跑通只是起点压测和灰度才是关键。6. 几个被高频问到的问题集中回答一下6.1 现在开源小模型有好用的么有而且越来越好用。但要区分小模型和小激活参数的 MoE。MiMo-V2.6 这类 MoE 模型总参数量不小但激活参数相对可控所以推理成本比同能力的稠密模型低。如果你要的是真正的小模型比如 7B 级别那要看你任务的复杂度——简单任务够用复杂推理还是得上一梯队。6.2 MoE 架构要全部参数进显存吗前面详细说过再强调一遍结论权重必须全部可访问但不一定全部常驻单卡显存。可以用专家并行分散到多卡也可以用卸载换显存。具体选哪种看你的延迟预算和硬件。6.3 SGLang 和 vLLM 到底选哪个看场景。多轮对话、Agent、共享前缀多选 SGLang通用单轮、追求生态稳定选 vLLM。两者不是非此即彼有条件的话都跑一遍压测用数据说话。6.4 部署时最容易忽略的是什么KV Cache 的显存占用。很多人算显存只算权重忘了 KV Cache 会随并发和上下文长度线性增长。长上下文 高并发时KV Cache 能吃掉一大半显存。mem-fraction-static设太高就是没给 KV Cache 留够空间。7. 我在实际部署里攒下的几条经验最后分享几条踩坑换来的经验都是文档里不会写的。第一条显存预估永远按总参数算别按激活参数。激活参数只决定计算量不决定显存占用。非激活专家的权重一样要占地方。按激活参数估显存必 OOM。第二条MoE 的尾延迟比平均延迟重要。专家负载不均会导致部分请求特别慢平均值看不出来但用户能感知到。压测时一定要看 P99别只看平均。第三条前缀缓存是吞吐的命门。如果你的场景有大量共享前缀比如固定的 system prompt、多轮对话历史一定要把前缀缓存用起来。SGLang 的 RadixAttention 在这块优势明显能省下的计算量很可观。第四条灰度比压测更重要。压测是模拟灰度是真实。先放 1% 流量观察一周再逐步放量。真实流量的长尾特征压测很难完全复现。第五条别迷信榜单建自己的 eval。AA 指数排名第一是个很好的起点但你的任务只有你自己最清楚。花时间建一套自己的评测集长期看回报最高。MiMo-V2.6 这次的双版本 价格不变 AA 指数登顶对开源生态是件好事。但工具再好也得会用、会调、会评估。把上面这些工程细节吃透你才能真正把排名第一转化成业务上跑得稳、成本上划得来。
阅读完成 · 觉得有帮助？
