小米 MiMo API 大幅降价背后:罗福莉用工程账回应“价格战”质疑

144次阅读
没有评论

共计 1176 个字符,预计需要花费 3 分钟才能阅读完成。

「观察视角」
围绕事件本身、节奏变化与潜在影响展开。

小米 MiMo 的一次大幅降价 , 把国产大模型 API 的成本讨论再次推到台前。 围绕“最高降幅 99%”的争议,MiMo 负责人罗福莉近日通过技术说明回应外界质疑: 这并非单纯营销或亏本抢市场, 而是多项推理工程优化共同作用后的结果。

📌 降价焦点并非所有调用, 而是缓存命中的输入

此次 MiMo-V2.5 系列 API 调整中,最受关注的是 Input(Cache Hit) 价格最高下降 99%。需要注意的是, 这并不等于所有模型调用都按同等幅度降价。新输入、模型输出等部分的降幅相对有限, 真正被大幅压低的是长对话、长文档、代码库等场景中反复读取历史上下文的成本。

换句话说,MiMo 希望把“重复算一遍”变成“从缓存里取”。如果缓存命中率足够高, 重复上下文的边际成本就会显著降低, 这也是此次定价调整能成立的关键前提。

🔍 核心工程: 围绕 KVCache 做系统性降本

罗福莉在技术说明中重点解释了 KVCache 的优化。KVCache 可以理解为大模型在对话过程中保存的“短期记忆”, 它会占用显存与存储资源, 也是长上下文推理成本的重要来源。

MiMo-V2.5-Pro 采用 Hybrid SWA 架构: 部分层只关注最近窗口内的 token, 少数层保留全局注意力。按照披露的信息, 这让 KVCache 体积和相关计算量降至传统 Full Attention 的约七分之一。随后, 团队又通过双池管理, 让不同注意力层按真实需求分配缓存空间, 避免显存被“按最大规格”浪费。

  • 架构压缩:减少长上下文下 KVCache 的体积压力。
  • 双池分配:让节省出的空间真正转化为并发能力。
  • 前缀缓存:提升重复上下文的实际命中率。

💡 缓存、调度与生成速度共同支撑成本下降

仅有缓存还不够,缓存放在哪里、请求如何被分配, 也会影响最终成本。MiMo 团队称, 其自研 GCache 分布式缓存部署在 GPU 机器自带 SSD 上, 用于降低额外存储开销; 同时通过 LLM-Router 调度系统, 把相似前缀请求尽量路由到合适机器, 以提高复用效率。

此外,MiMo 还提到 3 层 MTP(Multi-Token Prediction)能力, 用于提升模型生成 token 的速度。由于实际请求同时包含输入和输出, 若只降低缓存输入成本, 整体调用费用仍会受到输出侧制约; 生成效率提升则有助于补齐这一环。

📊 行业观察: 价格战之外, 工程能力正在变成竞争门槛

过去两年,国产大模型 API 降价频繁出现, 外界自然会把 MiMo 的动作归入价格战。但这次争议的特别之处在于, 小米选择用较完整的技术拆解来解释定价逻辑, 而不是只强调“更便宜”。

🚀 值得关注的几个影响

  • 开发者成本可能下降:长对话和长文档应用会更直接受益。
  • 行业定价压力加大:其他模型服务商可能需要解释自身成本结构。
  • 推理基础设施重要性提升:模型能力之外, 缓存、路由、存储将成为关键差异。
本文基于公开信息整理, 如有侵权请联系删除。
正文完
 0