Thread

MiMo v2.6

1130 points · 483 comments · volf_

stymaar · 1790022964 · focus · HN ↗
Flash[1]: 309B total / 15B activated parameters
Pro [2]:, 1.02T total / 42B activated parameters
[1]: <a href="https://huggingface.co/XiaomiMiMo/MiMo-V2.6-Flash-RL" rel="nofollow">https://huggingface.co/XiaomiMiMo/MiMo-V2.6-Flash-RL
[2]: <a href="https://huggingface.co/XiaomiMiMo/MiMo-V2.6-Pro-RL" rel="nofollow">https://huggingface.co/XiaomiMiMo/MiMo-V2.6-Pro-RL
1. verdverm · 1790023617 · focus · HN ↗
  curious why the HF pill (on the right) always has inaccurate values
  1. stymaar · 1790024101 · focus · HN ↗
    I noticed the same, and I wonder as well.
    verdverm · 1790024599 · focus · HN ↗
    I suspect they are calculating something in the weights or config, I see it pretty consistently with quants
  2. bopbop9876 · 1790031234 · focus · HN ↗
    I believe it's because this model is natively fp8 (for the most part), and that display struggles native quants.
  3. wren6991 · 1790055010 · focus · HN ↗
    Packed 4-bit weights are often identified as u8 byte arrays in the safetensors metadata, so the HF UI counts them as half a weight each.
    verdverm · 1790058463 · focus · HN ↗
    I would think there is sufficient information in the various config files to work this out, based what I've seen in my own quant artifacts.
    wren6991 · 1790062220 · focus · HN ↗
    Yeah, I agree it's probably fixable, but I think a naive interpretation of the metadata is probably the source of this bug (which HF has had for as long as I can remember)
2. verdverm · 1790023950 · focus · HN ↗
  There's also a Qwen 3.5 9B distill
  <a href="https://huggingface.co/XiaomiMiMo/MiMo-V2.6-Distill-Qwen-9B" rel="nofollow">https://huggingface.co/XiaomiMiMo/MiMo-V2.6-Distill-Qwen-9B
  1. gandreani · 1790024133 · focus · HN ↗
    Those this mean they've fine-tuned this Qwen 3.5 9B on output from the V2.6 model?
    mydreamof · 1790024369 · focus · HN ↗
    It is a 9B agentic model developed by Xiaomi MiMo through supervised fine-tuning of Qwen3.5-9B on MiMo-generated data
    simonedepertis · 1790024393 · focus · HN ↗
    [dead]
3. segmondy · 1790025837 · focus · HN ↗
  more like 500B in FP8
4. embedding-shape · 1790078912 · focus · HN ↗
  Been playing around with both of these since last night. So far, when enabling reasoning (which is binary on/off), it seems to me like Flash either is less "token efficient" or just likes to think more, or I'm doing something else wrong, because most prompts I send to both, Flash reasons more and for longer than Pro, which is the opposite of my expectations.
  Are others seeing the same thing?
  1. alfiedotwtf · 1790079878 · focus · HN ↗
    Maybe it’s the quant you’re using?
    embedding-shape · 1790084908 · focus · HN ↗
    Tried both <a href="https://token-plan-ams.xiaomimimo.com/v1" rel="nofollow">https://token-plan-ams.xiaomimimo.com/v1 and <a href="https://api.xiaomimimo.com/v1" rel="nofollow">https://api.xiaomimimo.com/v1, hoping they don't run any quantized variants there, but who knows.
  2. the_duke · 1790082219 · focus · HN ↗
    Most of the Chinese models get into long complicated thinking loops before they accomplish something more complicated.
    This is also true for Deepseek 4(.1) .
    embedding-shape · 1790085338 · focus · HN ↗
    Any lower (or broken) quantization could do that, not what I'm talking about though. They work fine for their size, as far as I can tell. Just surprised the Flash would reason for longer than the Pro.
    FredFS456 · 1790099624 · focus · HN ↗
    I prefer GLM 5.3 (Flash or not) over Deepseek 4.1 Flash because the GLM models are significantly less verbose.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.