Together AI上服务MiniMax-M3：稀疏注意力、分页解码与多模态推理的优化实践
MiniMax-M3在一个模型中整合三项服务挑战：100万token上下文窗口、原生多模态能力，以及MiniMax稀疏注意力（MSA）。Together AI是MiniMax-M3的首选云合作伙伴，负责该模型的生产部署，并在其平台上托管开源权重版本作为开发者端点。
该模型面向开发者日益关注的工作负载：长文档、代码库、工具调用、图像、视频及迭代式智能体推理。这些负载上下文量大且形状不规则，同时对注意力计算核、KV缓存管理、解码索引和预处理流水线构成压力。
高效服务M3需全栈协同优化。Together AI的推理与内核团队实现了KV块主序稀疏注意力内核，将MiniMax稀疏注意力与分页注意力集成，优化了解码索引评分路径，并将多模态预处理迁移至基于Rust的网关，在请求抵达GPU工作节点前完成。在常见智能体形态流量下，这些优化使吞吐量提升81–125%。
MiniMax稀疏注意力改变了服务问题
M3最核心的架构创新是MiniMax稀疏注意力（MSA）。MSA通过限制每个查询（query）所关注的token数量，缓解了MiniMax-M2.7中存在的注意力计算瓶颈。
高层面看，MSA包含两个阶段。
第一阶段，模型对KV块打分，并为每个KV组选出最相关的K个块。第二阶段，在查询token与所选块之间执行稠密注意力。该设计在保留KV组维度表达力的同时，约束了每个查询读取的上下文量。
这改变了长上下文的扩展行为：稠密注意力计算量随上下文长度呈平方增长，而MSA将注意力路径限定于所选块数，使100万token上下文更易部署。MiniMax报告称，该稀疏注意力设计带来预填充（prefill）阶段超9倍、解码（decode）阶段超15倍的速度提升。
然而，服务挑战并未消失，而是发生了转移。MSA减少了稠密注意力计算，但引入了新的系统问题： - 如何避免预填充阶段重复移动KV数据 - 如何将稀疏块选择适配进分页KV缓存架构 - 如何让解码索引评分足够快以满足关键路径要求 - 如何将多模态预处理完全移出GPU生成工作流
Together的M3服务工作聚焦于这些问题。
优化
KV块主序稀疏注意力减少冗余KV移动
预填充阶段，长上下文注意力仍可能主导端到端耗时。对于每个token，稀疏注意力的操作量为：所选块数 × KV头组数 × token数
块稀疏结构提供了一个机会：多个查询token常常关注相同的KV块。查询主序实现会为每个查询迭代并获取其选择的KV块，这在不同查询复用相同块时导致KV从HBM到SRAM的重复搬运。
Together将内核重构为以KV块为中心。
不再是如下工作映射： {q, kv block}
而是重新映射为： {kv block, q}
这使得KV块成为外层循环。内核将KV块搬运一次，然后为需要它的查询token计算注意力。这提升了计算强度，因为昂贵的HBM到SRAM搬运被多个查询分摊。
这种重新映射需要不同的注意力内核。每个KV块只产生部分输出O，因此最终输出需要归约步骤。Together使用基于Log-Sum-Exp的归约来正确缩放和求和跨所选块的部分输出。
结果是预填充路径匹配了MSA的稀疏结构，而不是强迫MSA通过查询主序的稠密注意力布局。
MSA需要新的分页注意力集成
现代推理引擎使用分页注意力管理跨请求的KV缓存。高度优化的注意力内核通常假设一组固定的支持页大小和相对规整的页表。
MSA打破了这一假设，因为不同KV组选择的块不同。
Together通过解码时基于所选块构建页表，将MSA与分页注意力集成。关键操作是将KV组维度展平到批次维度，并使用KV缓存张量的步幅视图为注意力内核提供正确的页指针。
步幅是关键技巧： - 页地址按D步进以选取虚拟页起始位置 - token按Hkv × D步进
这将一个物理KV张量解交织为每头独立页。每个展平行因此可以使用不同的页表，即使底层张量仍然是共享的。
这种设计让Together能够复用现有优化的GQA注意力内核，而无需从零为解码编写新的稀疏注意力内核。由于所选块数量有界，将所选块映射到页的内核开销非常低。
该集成实现了5%的解码吞吐提升。
索引评分器成为解码关键路径
MSA将解码的大部分成本从稠密注意力转移到了评分/top-k索引器。
对于每个解码查询，引擎将查询侧索引向量与候选键侧索引向量进行比较。每个128-token KV块被压缩为一个分数。引擎只保留top块，然后将这些块传递给真正的注意力内核。
该扫描在每个生成token的关键路径上运行。在长上下文下，候选块数量随上下文长度增长，因此评分内核成为解码吞吐的核心。
其形状不规整：小查询索引、长键索引。
容易想到将解码查询批量化为一个更大的GEMM。但这并不能解决全部问题。评分/索引步骤包括每个请求和每个KV组的候选范围、掩码、每个块归约和top-k边界。拼接查询仍然在GEMM周围留下一个不规则收集和归约问题，同时向关键路径添加填充和簿记开销。
Together使用AB交换的HMMA布局优化了该路径： - 128-token键索引块成为HMMA的M维 - 查询侧仅填充到较小的N维 - 内核分阶段处理128-token K索引并使用异步拷贝 - 内核预取下一页 - 点积以BF16精度使用HMMA计算 - 每页归约为一个块分数
这使得评分路径贴合真实解码形状，而不是强制将其纳入稠密GEMM抽象，从而将不规则工作留在矩阵乘法之外。
多模态预处理应置于网关层
M3还增加了原生多模态支持。图像和视频输入带来的服务问题与纯文本不同。在模型可以使用它们之前，输入需要CPU密集型预处理：下载、解码、帧采样、缩放、归一化以及转换为块张量。
在推理引擎内部执行这些操作会占用本应用于生成的资源。
Together在SMG（基于Rust的Serving Model Gateway）中处理M3多模态预处理，该网关位于OpenAI兼容API与推理引擎之间。SMG原本已处理路由和分词。对于M3，它还在请求到达GPU工作节点之前执行视觉预处理。
M3视频路径如下： - 获取视频 - 使用FFmpeg提取帧 - 基于FPS选择子集 - 缩放和归一化帧 - 嵌入时间维度后分块 - 生成扁平块张量和小型网格元数据张量 - 将两者打包成gRPC消息 - 向工作节点发送就绪张量
然后GPU工作节点直接运行视觉编码器。它不会将推理引擎资源用于解码或预处理媒体。
SMG的多模态流水线基于Rust trait构建，将模型特定预处理与流水线骨架分离。添加M3支持只需用M3特定常量实现这些trait。网关流水线本身无需改动。
该设计的意义超出M3：相同的模式可泛化到大多数开源视觉模型以及各类推理引擎运行时。
性能结果
Together从MiniMax-M3权重和模型架构出发，优化了稀疏注意力、解码页映射、索引评分和多模态预处理等整个服务路径。
在常见智能体形态流量下，Together测得各并发级别吞吐量提升81–125%。
另一组内核执行分解（agentic风格流量，60K前缀缓存，并发度8，NVIDIA B200）显示，MSA显著降低了每次迭代中注意力计算所占的端到端时间比例。
各个优化在栈的不同层面贡献： - KV块主序稀疏注意力减少了预填充阶段的冗余KV移动。 - 分页MSA解码集成实现了现有GQA注意力内核的复用，并带来5%的解码吞吐提升。 - 优化的解码索引评分器降低了top-k块选择的关键路径开销。 - SMG将图像/视频预处理移出了GPU工作节点路径。
更广泛的结果是，M3在架构层面的效率通过引擎和内核工作落地到生产服务，而不仅仅依靠模型本身的改动。
遗留问题
M3的稀疏注意力设计引入了比稠密注意力路径更多的小型内核。例如： - KV块上的top-k - 将{q, kv block}重新映射为{kv block, q} - 每块评分和归约 - 稀疏页表构建
这带来了内核融合的机会。Together的内核代理研究团队正在积极开发能够编写生产级内核的代理，而M3正是那种小型内核融合可以显著改善端到端服务的模型。
在缓存卸载方面也还有更多空间。稀疏注意力架构允许K索引和实际KV缓存以不同方式处理。未来的服务路径可以保持完整K索引可用，同时基于top-k选择按需加载KV缓存。这将解耦索引状态和值状态的CPU缓存卸载，在不需要完全KV驻留时改善长上下文的经济性。
结论
MiniMax-M3通过MiniMax稀疏注意力使100万token多模态推理更实用，但高效服务它需要贯穿全链路的系统工程工作。
Together的服务栈需要在四个层面进行适配： - 预填充阶段的稀疏注意力布局 - 解码阶段的分页注意力集成 - 关键路径上的优化索引评分 - GPU工作节点前的多模态预处理
这就是M3在Together AI背后的真实服务工作。模型降低了长上下文推理的理论成本；Together的推理和内核工作则将其转化为更高吞吐、更低服务开销、以及开发者可以使用的生产端点。