共计 1325 个字符，预计需要花费 4 分钟才能阅读完成。
小米 MiMo-V2.5 系列 API 永久降价后 , 其背后的工程优化方案也首次被系统披露。 根据小米公布的信息, 本次最高 99% 的降价并非来自模型能力削减, 而是来自推理系统在缓存、调度、Prefill/Decode 以及多模态链路上的整体重构。
📌 降价背后: 核心矛盾是 KVCache 成本
大模型在线推理的主要成本之一来自 KVCache。模型在生成 token 时, 需要把历史上下文以键值形式保存在显存中; 上下文越长, 占用越高, 并发能力越受限制。对于长文本、Agent、多轮对话等场景, 这会直接推高服务成本。
MiMo-V2.5-Pro 采用 Hybrid SWA 架构: 在 70 层 Transformer 中, 仅 10 层使用完整注意力, 其余 60 层使用滑动窗口注意力, 窗口大小为 128 token。小米称, 这使 KVCache 存储需求降至全 Full Attention 方案的约 1/7, 长序列场景下优势更明显。
简单来说, 模型不是“少算了能力”, 而是让系统更清楚哪些历史信息必须长期保存, 哪些只需保留最近窗口。
🔍 从理论节省到线上可用: 推理栈被重新改造
小米提到,Hybrid SWA 的理论收益并不会自动转化为线上收益。早期部分推理框架虽然支持 SWA, 但仍可能以接近 Full KVCache 的方式存储, 导致架构优势被抵消。因此,MiMo 团队重构了多项底层组件。
- 双 KV 池:将 Full Attention 与 SWA 的缓存拆分管理,SWA 部分采用窗口级容量与环形缓冲设计。
- 前缀缓存树重构:避免 SWA 场景下出现“逻辑命中但物理缓存已失效”的伪命中。
- 三级缓存 GCache:让 KVCache 在 GPU 显存、CPU 内存和 NVMe SSD 之间按热度流转, 提升缓存留存能力。
💡 调度、Prefill 与 Decode 同步提速
缓存节省只是第一步,如何把节省出的显存和算力真正转化为吞吐, 也需要调度系统配合。小米在 Router 侧引入 KVCache 亲和调度, 让请求尽量进入已有相关缓存的节点, 同时加入计算量感知优先级, 避免短请求被长请求长时间阻塞。
📊 多模态链路也被纳入优化范围
除文本推理外,MiMo-V2.5 系列还覆盖视觉、音频、视频理解。小米表示,Encoder 支持跨请求组 Batch, 图片预处理迁移至 GPU, 视频解码则拆分为多 chunk 并行处理。其披露的案例中,1 小时视频端到端延时由 156 秒降至 23 秒, 整体 Encoder 吞吐提升至 2 倍。
🚀 行业观察:API 价格战进入工程效率阶段
值得关注的是,这次降价释放的信号并不只是“更便宜”。当主流模型能力差距逐渐收窄, 推理系统工程能力会成为 API 定价、服务稳定性和长上下文体验的关键变量。
对开发者而言,降价可能降低长文本处理、多模态理解和 Agent 应用的试错成本; 对行业而言, 模型服务竞争正在从参数规模和榜单成绩, 进一步延伸到缓存系统、调度策略、硬件利用率等更底层的基础设施能力。
总体来看,小米此次公开 MiMo-V2.5 的全链路优化, 重点在于说明: 同一模型、相同硬件下, 仍然可以通过系统工程获得更高吞吐与更低延迟。若后续更多优化回流开源社区,Hybrid SWA、MoE 与多模态组合架构的落地门槛也有望进一步降低。
