5月27日小米宣布 MiMo-V2.5 系列 API 永久降价、最高降幅 99% 的时候，外界普遍的反应是"又一个赔本赚吆喝的"。这一波国产大模型价格战从去年年中打到今年，每一次降价后都有人算过账：按主流推理成本算，0.025 元/百万 Token 的缓存命中价根本撑不住。
但小米这次不打算让事情停留在"猜测"层面。5月30日，MiMo 团队在官方技术博客发了一篇长文，把降价背后的推理系统改造完整摊开来讲，并直接给出结论——降价之后仍能维持收支平衡。这是过去一年价格战里，少有的厂商主动把成本结构和优化路径同时公开的案例。
先看价格：到底降到了什么程度
降价后的具体定价，MiMo-V2.5 Pro 的输入缓存命中价格降至 0.025 元/百万 Token，配合 Token Plan 计费体系的调整，套餐内的可用量提升到原来的 5–8 倍。叠加 4 月 28 日启动的"百万亿 Token 创造者激励计划"——总申请人数超过 54 万，累计发放 100 万亿免费 Token，折合人民币 6500 万元——MiMo 的开发者获客成本基本已经压到地板上。
问题是，把价格打这么狠，模型还是那个万亿参数 MoE 架构、采用 Hybrid SWA 设计的 MiMo-V2.5 Pro，参数没缩、能力没砍。靠什么撑住？答案就在小米这次披露的五项核心优化里。
五项核心突破，一项一项拆
1. KVCache 双池 + SWA-aware 前缀树
这是这次披露里技术含量最高的一项，也是 Hybrid SWA 架构的产物。
MiMo-V2.5 Pro 共 70 层，其中 60 层只算局部窗口注意力（Sliding Window Attention，SWA），10 层保留全局注意力。理论上 SWA 能把 KVCache 的存储和计算量压得很低，但在工程上有个绕不开的麻烦：SWA 层和全局层的 KVCache 生命周期、命中规则完全不一样。SWA 的窗口随 token 滑动，老数据会被自然淘汰；全局层则要求完整保留。如果用一套缓存机制管两类数据，要么浪费显存、要么命中率暴跌。
小米的做法是直接做"双池"：SWA 层和全局层的 KVCache 物理上分开管理，分别有各自的淘汰策略和命中查询路径。在此基础上，前缀树（prefix tree）的实现也要 SWA-aware——传统前缀树假设缓存数据是连续的，但 SWA 窗口意味着同一个 prompt 的不同层缓存的有效范围不同，前缀匹配时必须把窗口信息纳入考虑。这一项落地之后，长 prompt 场景下的缓存命中率明显上一个台阶，这也是 0.025 元/百万 Token 的输入缓存命中价能站住的核心原因。
2. GCache 分布式缓存
单机的 KVCache 优化做到极致，下一个瓶颈是跨机调度。同一个用户的多轮对话、或者批量请求里类似前缀的 prompt，如果落到不同推理节点上，前缀缓存就白做了。
GCache 是 MiMo 团队搭的一层分布式缓存系统，把 KVCache 从单机的"局部资源"提升到集群级别的"全局资源"。具体的存储介质应该是分层的——热数据在 GPU 显存，温数据在主机内存，冷数据下沉到 RDMA 可达的远端存储。这种架构国内外都有人在做（比如 Mooncake 的 KVCache 池化思路），MiMo 这次没披露太多实现细节，但提到了"分布式"三个字，说明已经过了 PoC 阶段、在生产环境跑。
3. KVCache 亲和调度
光有分布式缓存还不够，调度策略得跟上。如果调度器随机分配请求，分布式缓存的命中率会被白白稀释。
MiMo 的亲和调度逻辑可以理解成：每个推理请求带着"前缀指纹"进来，调度器优先把它路由到缓存了相同前缀的节点上。这听起来简单，但实际工程里要平衡几件事——节点负载、缓存命中率、用户公平性、长尾延迟。亲和度太强会造成热点节点过载，太弱又回到原点。MiMo 没具体讲算法，但从结果看，他们应该是引入了某种动态权重的调度策略，能在命中率和负载之间做实时博弈。
4. Decode 阶段 MTP 加速
MTP（Multi-Token Prediction）这条路径，DeepSeek-V3 的报告里讲过，本质是让模型在一次前向里预测多个 token，从而在 decode 阶段把 GPU 利用率推高。MiMo 在 V2.5 上把 MTP 落到了推理侧。
Decode 阶段是大模型推理最烧钱的部分：和 prefill 不同，decode 是一个 token 一个 token 蹦出来的，GPU 大部分时间在等显存而不是在算，算术强度（arithmetic intensity）低得可怜。MTP 通过让一次 forward 多吐几个候选 token，然后用类似投机解码的方式验证，等于把原本要做 N 次 forward 的工作压到 1 次里。对万亿 MoE 这种参数量巨大的模型尤其受益——每次 forward 要激活的专家参数固定，多吐 token 几乎是"白送"的收益。
5. 多模态推理优化
MiMo-V2.5 系列里有支持视觉输入的版本。多模态推理的开销大头不在文本，而在图像编码和视觉 token 与文本 token 的拼接处理上。一张高分辨率图片切下来的 visual token 可能上千个，直接喂给主干会让 prefill 阶段炸开。
这一项官方披露得比较简略，但能推测出几个方向：视觉编码器的 batch 化和 KVCache 复用、visual token 的动态压缩（高分辨率区域保留细粒度、低信息区域降采样）、以及多模态前缀树的统一管理。这些优化叠加起来，让 MiMo 的多模态能力没有成为价格战里的"成本短板"。
这套打法的含金量在哪
把五项放一起看，能看出 MiMo 团队的优化思路是全栈式的——从单机的 cache 管理（KVCache 双池），到集群的缓存共享（GCache），到调度层（亲和调度），到模型层（MTP），再到模态层（多模态优化）。每一层都在挤水分，没有依赖某一个"杀手锏"。
这也是为什么"降价 99% 还能不亏"听起来夸张但说得通的原因。真正贵的从来不是模型推理本身，而是缓存没命中、调度没对齐、GPU 在干等的那部分浪费。把这些浪费收回来，单 token 的实际成本能下降一个数量级以上。这也是过去一年 vLLM、SGLang、TensorRT-LLM 这些推理框架社区一直在做的事情，只是 MiMo 把它做到了产品化、规模化部署的程度。
价格战的下半场逻辑变了
回过头看国产大模型这一轮价格战，去年的逻辑是"用钱换市场"，今年的逻辑明显变了——真有能力把成本压下去的厂商，价格战不是赔钱，而是合理利润下的常规竞争。DeepSeek 的 R1 是这样，MiMo 这次披露的也是同一个故事。
对开发者来说，这是好事。"低价 + 能力不缩水 + 不画饼"的供给越来越多，多模型组合调用、按场景选型变成可行的工程实践。OpenAI Hub 这边能明显感觉到，最近一两个月开发者切换模型、做 A/B 测试的频次明显高了，平台侧也已经接入了 MiMo-V2.5 系列，和 GPT、Claude、Gemini、DeepSeek 这些放在一个 Key 下调用，对想测试 MiMo 这套低价能力的开发者来说，省去了再开一套账号体系的麻烦。
还有几个没说清楚的地方
技术博客信息量已经不小，但有几个问题 MiMo 没正面回答：
- "收支平衡"的口径是按平均请求算，还是只算缓存命中的高 P 路径？ 如果是后者，那对长尾、首次请求的成本结构其实并没有完全披露。
- GCache 的具体一致性模型和故障恢复机制？ 分布式缓存最难的是边角 case，这部分留给后续。
- MTP 的接受率（acceptance rate）数据？ MTP 收益完全取决于投机 token 被接受的比例，没数据就不好横向对比 DeepSeek、Qwen 等。
这些坑大概率会在之后的技术 deep dive 里继续填。但就目前这次披露而言，含金量已经超过过去一年大多数国产大模型厂商的"降价公告"——至少 MiMo 把账本摊开来给行业看了。这件事本身比降价数字更值得记下来。
参考来源
- 知乎讨论：如何评价小米MiMo-V2.5系列模型5月27日大降价 — 社区视角对降价幅度和 Token Plan 调整的讨论