架构层面的 KV Cache 压缩
小米 MiMo-V2.5 系列模型在推理成本优化上的核心突破，源于对 KV Cache 存储需求的根本性重构。传统 Transformer 模型在生成每个 token 时，需将全部历史上下文以键值对形式缓存在 GPU 显存中，上下文越长，缓存占用越大，可并发请求越少。MiMo-V2.5-Pro 采用 70 层 Transformer 架构，其中仅 10 层使用 Full Attention（完整注意力），其余 60 层使用 Sliding Window Attention（滑动窗口大小 128 token）。这一设计使整体 KV Cache 存储需求降至全 Full Attention 方案的约 1/7，同时 Prefill 阶段的计算成本也降至约 1/7。
这种 Hybrid SWA 架构的经济性在长序列场景下尤为显著：Decode 阶段的延迟与 KV Cache 读取量正相关，存储压缩几乎直接等价于推理成本的等比例下降。小米官方数据显示，基于这套优化方案，MiMo-V2.5 系列 API 完成永久降价，最高降幅达 99%。
双池分治与三级缓存的工程实现
架构层面的 "应该省" 与线上的 "真的省" 之间，隔着一整套推理系统的适配工程。MiMo 团队将 KV Cache 拆分为 Full KV Pool 与 SWA KV Pool 两个独立池：Full KV Pool 按需增长、长期保存；SWA KV Pool 仅按窗口大小配置容量，采用环形缓冲区设计，支持基于窗口的独立淘汰，存储严格限制在 O (W) 规模。对上层调度器和前缀树仍暴露统一序列视图，由 Full Attention 索引作为权威索引并维护到 SWA 的映射关系。
前缀缓存的重构是另一关键工程。传统前缀缓存的匹配规则建立在 "token 序列相等→KV 也相等" 的假设上，在 SWA 模式下这一假设被打破。MiMo 团队将匹配规则升级为 "窗口安全长度"（尾部至少 W 个 token 仍有有效 slot），线上前缀缓存命中率平均达到 93%，高频用户超过 95%。
针对用户对话的时间间隔问题，小米自研 GCache 三级缓存系统，同时支持 GPU 显存、CPU 内存和 NVMe SSD。KV Cache 按访问热度在三级间自动流转：活跃数据驻留显存，冷数据降级到内存或 SSD，用户返回时快速恢复。通过 RDMA 通信实现单进程 170 GB/s 读吞吐、280μs 延迟。
KV Cache 量化策略的技术选型
在边缘部署场景下，KV Cache 量化是进一步压缩内存占用的必要手段。当前主流方案可分为两类：
KIVI 方案采用 2 比特非对称量化：对 Key 缓存按通道进行分组量化，对 Value 缓存按 Token 维度量化。其技术洞察在于 ——Key 缓存中某些固定通道表现出大幅度异常值，按通道量化可将误差限制在通道内；而 Value 缓存无明显异常值，按 Token 量化可将误差限制在单个 token 上。KIVI 在保持几乎相同模型质量的同时，减少 2.6 倍峰值内存，实际推理吞吐量提升 2.35 至 3.47 倍。
KVQuant 方案则引入更精细的优化：在 RoPE 之前对 Key 进行量化以减轻位置嵌入对量化的影响；采用敏感度加权的非均匀量化数据类型；实施按向量的密集和稀疏量化，隔离异常值以最小化量化范围偏差；同时保留第一个 token 为 FP16 精度以应对 Attention Sink 现象。
对于 MiMo 的 Hybrid SWA 架构，量化策略需额外考虑 SWA 层的特殊性：SWA KV 的物理生命周期与逻辑生命周期不一致，量化分组粒度需与窗口大小对齐，避免跨窗口边界的量化误差累积。
边缘部署的工程权衡与参数清单
将 MiMo-V2.5 部署至边缘设备时，需在以下维度进行权衡：
量化精度选择：边缘设备建议采用 INT8 或 FP8 量化作为基线。INT8 在 LLaMA2-7B 级别模型上可实现几乎无损精度，同时支持 2 倍 KV block 数量提升；FP8（E5M2）保留 2-3 个尾数位，适合需要更高精度的代码生成场景。INT4 虽可进一步压缩至 4 倍 KV block，但精度损失需在具体任务上验证。
缓存层级配置：边缘设备通常显存受限（如 8-16GB），建议配置二级缓存（GPU 显存 + CPU 内存）。设置kv_cache_free_gpu_mem_fraction为 0.85-0.9，保留足够空间给模型权重和激活。余留缓存（residual cache）长度建议设为 128，以原始精度存储最新 token，平衡内存效率与生成质量。
分桶调度策略：采用三级长度分桶（0-4K/4K-16K/16K-64K），将负载特征相近的请求聚合调度，避免短请求被长请求拖慢。边缘场景下可适当缩小分桶边界以适应更有限的资源。
SWA 窗口大小：边缘部署建议保持 128 token 的滑动窗口，这是 MiMo 架构的预设值。如需调整，需同步修改前缀缓存的 "窗口安全长度" 判定逻辑。
生产环境监控要点
部署后需持续监控以下指标：
- 前缀缓存命中率：目标 > 90%，低于 85% 需检查前缀树配置或用户会话模式
- KV Cache 显存占用：监控 Full Pool 与 SWA Pool 的配比，确保 SWA Pool 严格按 O (W) 增长
- 量化误差累积：定期采样验证量化前后的输出一致性，特别是长序列场景
- 三级缓存流转延迟：GCache 或等效系统的跨层级访问延迟应 < 1ms
- TTFT（首 token 时间）：P90 目标 < 500ms，边缘场景可放宽至 1s
资料来源
- 小米 MiMo 推理系统全链路优化技术细节，IT 之家，2026 年 5 月
- 大模型推理优化技术 - KV Cache 量化，稀土掘金技术社区
- KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV Cache, arXiv:2402.02750
- KVQuant: Towards 10 Million Context Length LLM Inference with KV Cache Quantization, arXiv:2401.18079
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。