小米的MiMo-V2-Flash，谷歌味挺浓

前不久，小米特意挑选在创始人雷军生日当天发布了 MiMo-V2-Flash 这个最新模型。

MiMo是小米基础大模型的产品线，初代只做了7B的参数量，基本上是在复刻DeepSeek模型的训练过程(毕竟是从DeepSeek挖的人)，之前我也写过文章详细解读过。

试水成功后，下一代就是做Scaling，MiMo-V2-Flash采用 MoE 架构进行设计，总参数量一下子拓展到309B，其中，激活参数量为15B。

从官方[1]给出的数据评测数值看，MiMo-V2-Flash已经站上了开源语言大模型的第一梯队。

除了性能外，速度是这款模型的更大亮点，从罗福莉的首秀PPT[2]看，它的速度比相近参数量的模型都要快很多。

Flash有多快？

Flash这个命名方式一看就是"致敬"谷歌的Gemini-Flash。

那么，MiMo-V2-Flash 和 Gemini-3-Flash 谁的速度更快？

下面来进行一个实验。

MiMo-V2-Flash 调用方式

目前在公测期，MiMo-V2-Flash 可以免费调用。

用uv初始化一个Python环境，并安装相关依赖。

复制代码

uv init
uv venv 
source .venv/bin/activate 
uv add openai
uv add python-dotenv

新建.env文件，配置环境变量，秘钥从mimo开放平台[3]获取。

复制代码

MIMO_API_KEY=sk-xxx

运行下面的代码进行调用，我在官方代码的基础上，进一步提供了流式和非流式的两种输出方式。

python 复制代码

import os
from dotenv import load_dotenv
from openai import OpenAI

# 加载 .env 文件中的环境变量
load_dotenv()

api_key = os.getenv("MIMO_API_KEY")
if not api_key:
    raise RuntimeError("MIMO_API_KEY not found in .env file")

client = OpenAI(
    api_key=api_key,
    base_url="https://api.xiaomimimo.com/v1"
)

completion = client.chat.completions.create(
    model="mimo-v2-flash",
    messages=[
        {
            "role": "system",
            "content": (
                "You are MiMo, an AI assistant developed by Xiaomi. "
                "Today is date: Tuesday, December 16, 2025. "
                "Your knowledge cutoff date is December 2024."
            )
        },
        {
            "role": "user",
            "content": "你是谁？"
        }
    ],
    max_completion_tokens=1024,
    temperature=0.3,
    top_p=0.95,
    stream=False,
    stop=None,
    frequency_penalty=0,
    presence_penalty=0,
    extra_body={
        "thinking": {"type": "disabled"}
    }
)

# stream=False
print(completion.choices[0].message.content)

# stream=True
# for chunk in completion:
#     if not chunk.choices:
#         continue

#     delta = chunk.choices[0].delta

#     if hasattr(delta, "content") and delta.content:
#         print(delta.content, end="", flush=True)

一个有意思的发现：在示例代码中，默认配置了system指令，而把system的指令注释掉之后，问它"你是谁？"

它会做出以下内容回答：

又运行了一次，还是"忘本"了：

extra_body有个thinking的参数，用来控制模型是否思考，默认是关闭的，而将它打开，会发现它想起自己是谁了。

从这个现象看，小米的API服务经验不是很足，在不开thinking模式的时候，后台是没有额外的系统提示词的。

而开thinking模式后，在调用时估计会有额外的提示词增加。

MiMo-V2-Flash 速度测试

书回正题，下面来具体测试一下，MiMo-V2-Flash 和 Gemini-3-Flash 的速度。

用一个比较费时的提示词进行测试：

prompt：原封不动地输出圆周率的前1000位数字

对于 MiMo-V2-Flash，程序总运行时间：12.492 秒

对于 Gemini-3-Flash，用一个类似的程序去计算用时：

python 复制代码

import os
import time
from dotenv import load_dotenv
from google import genai

# 1. 加载 .env 文件
load_dotenv()

# 2. 读取 API Key
api_key = os.getenv("GOOGLE_API_KEY")
if not api_key:
    raise RuntimeError("GOOGLE_API_KEY not found in environment variables")

# 3. 创建 Gemini Client
client = genai.Client(api_key=api_key)

# 4. 指定模型
model_name = "gemini-3-flash-preview"

# 5. 开始计时
start_time = time.perf_counter()

# 6. 发起请求
response = client.models.generate_content(
    model=model_name,
    contents="原封不动地输出圆周率的前1000位数字"
)

# 7. 结束计时
end_time = time.perf_counter()
elapsed_s = end_time - start_time

# 8. 输出
print(response.text)
print(f"\n程序总运行时间：{elapsed_s:.3f} s")

结果：程序总运行时间：16.220 秒

MiMo-V2-Flash 会比 Gemini-3-Flash 更快一些。

MiMo-V2-Flash 的核心技术

看 MiMo-V2-Flash 的技术报告，发现这个模型主要有以下亮点。

模型结构

模型采用了很标准Transformer的Encoder-Decoder的结构。

在Decoder-only的结构的当下，仍然采用这种结构，算是一股清流。

也许这也是"致敬"谷歌的一种方式，毕竟Google的T5模型(如下图所示)采用的是相同结构。

混合注意力

通常来说，模型的注意力机制都采用"全局注意力"（full attention），即模型会全局查看输入的文本，哪些Token应该分配更高的注意力比重。

但是，当上下文长度很长时。它的计算成本非常高。

于是，有人提出了"滑动窗口注意力"（SWA），即让AI的视野限制在一个局部"窗口"内，只关注附近的上下文。

但是，这样做很明显是用效率换性能(提升效率，降低性能)。

有没有什么办法，把两者结合呢？

谷歌的 Gemma 3 就采用了局部-全局注意力层交替的架构。具体来说，模型在每 5 个局部层之间插入一个全局层。

局部层负责处理局部依赖关系（仅关注固定跨度（例如1024个token）范围内的上下文），而全局层负责处理长距离依赖关系（跨越整个128K上下文进行注意力计算）[4]。

小米同样采用了这种混合注意力结构（hybrid attention architecture），并且比例和 Gemma 3 保持相同的 5:1，好像又是一处"致敬"。

它在这里还发现，使用这种注意力结构比全部采用全局注意力（all-GA）更好，这个结论有点反常识。

各家的数据集都不太一样，也没法验证这条经验，只能算是一个奇妙的发现。

此外，它还增加了gpt-oss里面的Attention Sink，给 softmax 分母加了一项sink，允许模型在必要时可以"什么都不关注"。

3层MTP

MTP最初是DeepSeek-V3在模型上开始使用，即让模型不仅预测下一个token，还同时预测未来2-3个token。

MiMo-V2-Flash采用的3层MTP，每层都是用的一个轻量级(0.33B)的FFN，同时预测t+1、t+2、t+3位置的token，实现让推理速度提升到3倍。

3其实是一个比较折中的选择，如果让模型连续预测更多Token，速度是会更快，但精度会掉的更明显。

多教师蒸馏

在后训练过程中，MiMo-V2-Flash提出了一个比较新的方法：多教师蒸馏(MOPD)。

在大模型领域，一般说蒸馏其实就是数据蒸馏：让参数量更大更聪明的模型去做数据集，给小模型去训练。

传统的知识蒸馏往往是指搞一组师生模型，让老师模型的输出和学生模型尽可能相近，从而实现"老师教学生"的效果。

MOPD可以用一句话概括：学生模型从自己的分布采样（on-policy rollout），再由多个领域教师对"每一个 token"提供 KL 约束型奖励。

从上面的结构图看，每个领域的教师是第二阶段训练得到，即给一个SFT的基础模型分别喂单独某个领域的知识，使其在某个领域的能力大幅提升。

要说多教师蒸馏，那类似的研究多了去了。

但把这东西用到大模型的后训练上，MiMo可能确实是第一家。

总结

小米的风格是这样：当别人做得火热时，它先开始观望，等大家把路线探得差不多之后，它开始下场超车了。

手机是如此，汽车是如此，MiMo亦是如此。

总体来看，它不像是DeepSeek，能整新鲜的想法，它更多是把人家已经比较成熟的想法拼装起来。

拼装的技术也是技术，就像是开源方案那么多，能整合用好，解决问题的仍然不多。

MiMo-V2-Flash 一下子成绩追上来，速度还极快，确实有点超乎预期。

这个模型当前仅支持文本输入，按照它的风格，下一步估计是扩展规模或者加入多模态，可以起名为 MiMo-V2-Pro了。

参考

1

https://github.com/XiaomiMiMo/MiMo-V2-Flash

2\] https://www.bilibili.com/video/BV1fUqGBZEYv \[3\] https://platform.xiaomimimo.com#/docs/quick-start/first-api-call \[4\] https://www.zhihu.com/question/14793133619/answer/122901399767