MiMo-V2.6-Flash
309B-A15BXiaomi MiMo
小米 MiMo-V2.6 系列中较小的一款：309B 参数，每个 token 约激活 15B，MIT 许可，能读文本、图像、视频和音频。发布的权重在专家层本身就是 4 比特（MXFP4），ggml-org 的 GGUF 原样保留：4K 上下文约需 175 GB，只有 512 GB 的 Mac Studio 才宽裕，256 GB 的偏紧。Q2_K 版本（约 132 GB）在 256 GB 的 Mac 上很宽裕，在 192 GB 的 Mac 上偏紧。48 层中只有 9 层保留会增长的缓存，所以即使用满 100 万 token 窗口也只多约 25 GB。llama.cpp 以 `mimo2` 架构运行它（与 MiMo-V2.6-Pro 相同），视觉通过单独的编码器加载。体积按 ggml-org 的 GGUF 文件计算，各档位的质量损失未公布。
1049K
最大上下文
2
量化变体
GGUF MXFP4
最佳质量
100.0%
精度保留率
量化变体对比
各量化级别的显存、质量损失及 RTX 4090 推理速度
实测 = 本站跑过 · 估算 = 本站未跑过：推算所得，或本站未核实的数字 · 社区 = 公开报告
MiMo-V2.6-Pro
Xiaomi MiMo
小米的开放权重旗舰，今年秋天位列开源模型排行榜前列：约 1.02 万亿参数，每个 token 激活约 42B，MIT 许可。发布的权重本身就是 4 比特（专家层为 MXFP4），GGUF 版本只是重新打包、没有再次量化。在这个档位下 4K 上下文约需 604 GB，超过本索引里任何一台单机：最大的 Mac Studio 给 GPU 的约 384 GB，四张 80 GB 的 H100 合计 320 GB。八张 80 GB 显卡（640 GB）大约是能装下它的最小服务器，按本站规则也只算「勉强」。收录它是为了让计算器能把这一点说清楚。70 层中只有 10 层保留会增长的缓存，所以即使 100 万 token 也只多约 50 GB。llama.cpp 以 `mimo2` 架构运行它，视觉通过单独的编码器加载。体积按已公布的 GGUF 文件计算，各档位的质量损失未公布。
Muse Spark Open 816B-A42B
Meta Muse
Meta 目前最大的开放权重模型，10 月以 Muse Model License 发布：816B 混合专家模型，每个 token 约激活 42B 参数，面向编程和智能体任务，支持图像和音频输入。只有最小的量化版本能在单台机器上运行。Q2_K（ggml-org 发布的 304 GB 文件）在 4K 上下文下约需 319 GB，到 128K 也只要 327 GB，因为 62 层中只有 16 层的缓存会随上下文增长——512 GB 的 Mac Studio 可以从容运行，四张 80 GB 的 H100 则偏紧。用满 100 万上下文约需 389 GB。Q4_K_S（470 GB）和 Q8_0（872 GB）在本站收录的任何单台机器上都装不下。视觉和音频编码器是另外 2–4 GB 的文件，未计入。体积按已发布的 GGUF 文件计算；基准成绩是 Meta 自己报的，各档位的质量损失未公布。它的许可证不是常规开源许可：Meta 的仓库需要申请访问才能下载；基于它的产品须注明"Built with Muse Spark Open"；年收入超过 2000 万美元的公司若要把它作为 API 服务提供，须先与 Meta 另签协议。
Nemotron 3.5 Bolt 74B-A9B
NVIDIA Nemotron
NVIDIA 的 Nemotron 3.5 Bolt 是 74B 混合专家模型，每个 token 约激活 9B 参数，目标是装进 24 GB 显卡。它由 Nemotron 3.5 Super VL 压缩而来，只有一个版本，即 NVIDIA 官方原生 2-bit 文件，22.0 GB。88 层中只有 8 层的缓存随上下文增长，所以上下文很便宜：4K 约 23.1 GB，128K 约 24.1 GB，用满 256K 约 25.2 GB。这正是 NVIDIA 设计的 24 GB，但超过了本站的宽裕线，所以 24 GB 显卡判定为偏紧；32 GB 显卡或 48 GB 的 Mac 可以从容运行。图像编码器是另外 1.7 GB 的文件。基准成绩是 NVIDIA 自己报的，2-bit 版本的质量损失未公布。
Nemotron 3.5 Super VL 120B-A12B
NVIDIA Nemotron
NVIDIA 的 Nemotron 3.5 Super VL 是 120B 混合专家视觉语言模型，每个 token 约激活 12B 参数，面向编程、工具调用和文档处理，上下文最长 100 万 token。88 层中只有 8 层的缓存随上下文增长，所以即使用满窗口也不贵：Q4_0（ggml-org 发布的 71.8 GB 文件）在 4K 下约需 75 GB，100 万上下文约 84 GB。128 GB 的 Mac 或 DGX Spark 128G 可以从容运行，单张 80 GB 显卡偏紧。Q8_0（128 GB）需要 256 GB 的 Mac。视觉编码器是另外 1–1.7 GB 的文件。体积按已发布的 GGUF 文件计算；基准成绩是 NVIDIA 自己报的，各档位的质量损失未公布。
在本地运行 MiMo-V2.6-Flash
在 MXFP4、4K 上下文下，MiMo-V2.6-Flash 约需 175.3 GB —— 权重 159.1 GB、KV 缓存 0.23 GB、激活缓冲 15.9 GB。MXFP4 是 MiMo-V2.6-Flash 官方发布时的格式，所以这里以它为基准，而不是社区的二次量化版本。本索引中能宽裕跑它的最小显卡是 512 GB 的 Mac M5 Ultra 512G，78 张卡中有 1 张可以。这些是计算值而非实测值：估算把「宽裕」的界线画在显存的 88%，大致就是桌面环境需要留出的余量。
上下文变长会多花多少
从 4K 提到 32K 约多占 0.62 GB，总量来到 176.0 GB。这比参数量给人的印象要温和：48 层中只有 9 层的 KV 缓存会随上下文增长，另有 39 层被滑动窗口封顶，因此缓存的增速只有常规架构的一小部分。该模型的原生上下文是 1M；在 MXFP4 下把它全部撑满约需 200 GB。
该下载哪个版本
本索引只收录了 MiMo-V2.6-Flash 的 GGUF 格式，共 2 个档位（Q2_K、MXFP4）。 其中 MXFP4 的公开困惑度损失最低，为 0.0%。本站硬件上没有该模型的吞吐实测数据。GGUF 可在 NVIDIA、AMD 与苹果芯片上通过 llama.cpp 和 Ollama 运行；AWQ 与 GPTQ 面向 CUDA 和 ROCm 上的 vLLM；EXL2 是 ExLlamaV2 —— 仅限 CUDA，而且已经归档，适合本机使用而不适合提供服务。
常见问题
- MiMo-V2.6-Flash 需要多少显存？
- 在 MXFP4、4K 上下文、batch 1 下约 175.3 GB，到 32K 时约 176.0 GB。这个数字是权重加 KV 缓存再加 10% 激活缓冲，由模型架构计算得出，不是在显卡上实测的。
- MiMo-V2.6-Flash 能在 512GB 显卡上跑吗？
- 可以 —— 在 MXFP4、4K 上下文下约需 175.3 GB，在 Mac M5 Ultra 512G 上还剩 208.7 GB。这是本索引中能宽裕跑它的最小显卡；78 张中有 1 张可以。
- MiMo-V2.6-Flash 该用哪个量化档位？
- MXFP4 的公开质量损失最低（0.0%），而 MXFP4 是多数人使用的档位。索引中的 2 个档位是 Q2_K、MXFP4。 注意这是 MoE 模型 —— 尽管每个 token 只激活一部分参数，全部参数仍需驻留显存，因此显存开销按总参数量算，而不是激活参数量。
这个模型能跑在哪
按 MXFP4、4K 上下文估算，显存从小到大排列。「从容」指估算占用不超过显存的 88%。
- 提供格式
- GGUF
怎么把它跑起来
针对本模型及同类硬件的部署指南。
本页数字会随模型数据或运行时版本的变化而更新。最近更新 2026-10-20 RSS → /zh/feed.xml