MiniMax M3#

验证过的模型#

引擎文档： vLLM 支持模型中的 MiniMax-M3（架构 MiniMaxM3SparseForConditionalGeneration）。

状态: 已通过 LMCache 验证。

启动 LMCache MP 服务器：

lmcache server --l1-size-gb 100 --eviction-policy LRU

使用 LMCache MP 连接器（8 个 GPU）启动 vLLM：

vllm serve MiniMaxAI/MiniMax-M3 \
    --tensor-parallel-size 8 \
    --trust-remote-code \
    --block-size 128 \
    --kv-transfer-config \
    '{"kv_connector":"LMCacheMPConnector", "kv_role":"kv_both"}'

对于该模型，--block-size 128 是必需的（参见注意事项）；更小的默认值会导致 vLLM 的 KV Cache 初始化失败。--trust-remote-code 用于加载 M3 的自定义架构。请根据您的硬件调整 --tensor-parallel-size —— M3 的权重需要八块 140 GB 级别的 GPU。有关 LMCache + vLLM 的通用连接配置（端口、远程主机），请参见 快速入门。

如果在 vLLM 设置中遇到任何问题，请参考 vLLM Recipes 以获取更多详细信息。

状态： 未通过 LMCache 验证。

状态： 未通过 LMCache 验证。

CacheBlend 支持#

压缩支持#

方法

状态

备注

CacheGen

未验证

注意事项#

  • 基于 lightning indexer 的稀疏注意力。 M3 运行分组查询（grouped-query）全注意力，外加 DeepSeek 风格的稀疏注意力索引器。每个稀疏层拥有两个分页缓存——主 K/V（rank-5）和仅含 key 的索引器缓存（rank-3）——vLLM 将它们放在单个 UniformTypeKVCacheSpecs 引擎组中。LMCache 会检测这两种布局，并将每一种作为独立的组进行存储/检索；索引器的 key 会随 K/V 一起传输，因为命中时无法从已缓存的 K/V 重新计算出它们。

  • ``--block-size 128`` 是必需的。 M3 的索引器使用 sparse_block_size = 128；vLLM 无法在全注意力内核与稀疏内核之间协调默认块大小（16）或 64，并会以 No common block size 中止 KV Cache 初始化。请使用 128。

  • LMCache 的 chunk 大小必须是 block 大小的整数倍。 默认的 chunk 大小（256）已满足 128，因此无需额外的标志；如果您向服务器传入 --chunk-size，请保持它是 128 的整数倍。