MiMo 是小米的开源权重模型家族，目前家族里只有一位成员：MiMo-V2.5，2026 年发布，采用 MIT 许可。它是一个 310B 参数的 MoE 模型，共 256 个专家、每 token 路由 8 个，每次前向只激活 15B 参数。"总参数量数据中心级、激活计算轻量级"正是 MoE 架构的精髓，也让 MiMo-V2.5 成为目前最值得自部署的"大脑袋、小胃口"模型之一。但别高兴太早：那 310B 参数总得找个地方放，而那个地方就是你的 VRAM。
本文用与站内 GPU 指南 相同的公式来拆解 MiMo-V2.5 的硬件需求：Q4 @ 8K 上下文 ≈ Q4 权重体积 + 0.025 × 激活参数（B）× 8 + 1 GB 开销。
尺寸梯度
- MiMo-V2.5（总参数 310B，MoE 激活 15B）—— 仅 Q4 权重就约 171 GB；按 8K 上下文算，整套工作负载约 174 GB → 想要从容运行，需要 192 GB+ 的配置（比如 2×96 GB 或 8×24 GB）。FP16 权重约 620 GB，已经是多机多卡的领域。完整估算见 MiMo-V2.5 模型页。
目前家族没有更小的兄弟型号——如果 192 GB VRAM 超出预算，MiMo 更适合在云端仰望，而不是在家用机上跑。唯一的"逃生舱"是 Q2 量化（权重约 87 GB）：能勉强塞进 96 GB 单卡或双 48 GB 组合，但这个码率下，对这个量级的模型，质量下滑是可预期的。
家族特色
- 极致稀疏。 310B 里每 token 只激活 15B（约 4.8%），单 token 速度更接近 15B 稠密模型，而非 300B 级别的任何模型。瓶颈在显存容量与带宽，不在算力。
- 1M 上下文窗口。 模型支持最长 1024K 上下文。但要注意 KV cache 随上下文长度线性增长：我们公式里的 8K 基线只增加约 3 GB，而逼近完整 1M 窗口时，KV cache 会在权重之外再吃掉数百 GB。长上下文的 MiMo 是服务器级负载。
- MIT 许可。 完全宽松——商用、微调、再分发都可以，在这个参数级别上相当少见。
- 单旗舰策略。 小米只发了一款超大模型，没有铺尺寸梯度，所以不存在"给游戏卡用的 MiMo-7B"。要么围绕旗舰规划硬件，要么看看别的家族。
怎么选
家族只有一款模型，所以真正的问题是：什么显存档才够得着它？
- 12 GB / 16 GB / 24 GB 显卡： 不现实。就算重度 offload，也得从内存甚至 SSD 里倒腾几百 GB，输出速度会按"每 token 多少秒"而不是 tok/s 来计算。想知道什么配置真的可行，看我们的 MiMo 显卡推荐。
- 48 GB / 96 GB： 离 Q4 还差得远。Q2 量化（约 87 GB 权重）技术上能塞进 96 GB 配个小上下文窗口，当作尝鲜可以，但请把它当体验版，别当日常主力。
- 192 GB 及以上： 这是 Q4 @ 8K 可用状态的入场券——双 96 GB 卡、4×48 GB 工作站，或 8×24 GB 机架。由于每 token 只有 15B 参数在干活，吞吐表现会很"MoE 友好"。
- 多节点 / 数据中心： FP16（约 620 GB）或大规模利用 1M 上下文的必需选项。
一句话总结：按"每瓦能力"算，MiMo-V2.5 是笔超值的买卖，但门票是 192 GB VRAM。如果你够得着这张门票，MIT 许可加 MoE 的速度，让它成为 2026 年最值得自部署的旗舰之一。
相关链接
MiMo（小米） 族共 1 个模型，按系列分组。Q4 (GB) 仅为权重体积；总 VRAM 还需加 KV cache 与开销——装机核对链接按代表性零售 GPU、8K 上下文计算。