Together AI 是 MiniMax M3 的首选云合作伙伴。Together AI 将在其公开发布后，以开发者端点的形式托管该开放权重模型。
- 我们的推理和内核团队实现了
重大的工程突破，以高效服务 M3，包括关键优化，如 KV-Block-Major 稀疏注意力内核、用于 MSA 的新型分页注意力集成、高度优化的索引评分内核以及基于 Rust 的多模态预处理网关，从而在不同并发级别上实现了 81–125% 的吞吐量提升。 - 大规模生产环境下的
MiniMax M3 服务验证了 Together AI 作为首选推理平台，适用于那些在硬系统问题上推动前沿、使实际部署成为可能的模型。
MiniMax 发布了其最新的最先进模型 M3，Together AI 很高兴成为首选云合作伙伴，使 MiniMax 能够高效地在生产环境中大规模服务 M3。一旦 MiniMax M3 在未来几天内作为开放权重模型发布，Together AI 还将直接为开发者托管该模型作为端点。在这一规模背后，是我们的推理和内核团队的卓越工作，他们推动了深度性能优化，并确保了一个推动前沿的模型的生产级可靠性：100 万 token 上下文窗口、原生多模态，以及需要严肃工程才能高效服务的架构。在这篇文章中，我们将介绍我们是如何实现这一点的。祝贺 MiniMax 团队发布了具有里程碑意义的模型并持续创新。
MiniMax M3 是一款一体化模型，集成了最先进的编码性能、代理工作流支持和原生多模态推理。在这些能力之上，它还设计为支持 100 万上下文，同时服务成本非常经济。这使得它非常适合实际任务，其中长文档、代码库、工具使用、图像和迭代推理经常同时出现且上下文密集。与前一代相比，服务 M3 带来了更多挑战，因为新能力需要在更多维度上进行优化，包括稀疏注意力计算、更大的 KV 缓存管理、多模态处理等。
架构 / 特点
M3 中最新颖的架构变化是 MiniMax 稀疏注意力（MSA），旨在解决 MiniMax M2.7 中看到的注意力计算瓶颈。其块稀疏注意力机制限制了每个查询可以关注的 token 最大数量，降低了长上下文处理的成本，并使更长的上下文窗口变得实用。这在前缀填充阶段带来了超过 9 倍的加速，在解码阶段带来了超过 15 倍的加速。
本质上，MSA 的计算由两部分组成：一个分数计算，用于确定每个 KV 组最相关的 K 个块进行关注，然后是查询 token 与这些块之间的密集注意力。这种设计在 KV 组维度上保持了表达能力，同时仍然限制了查询 token 关注的 KV token 的最大数量。注意力计算本身不再随上下文长度呈 N^2 缩放，因此非常适合长上下文工作负载。
我们在 B200 上以 8 并发测量了代理式流量模式（60k 前缀缓存）下的内核执行时间分解。MSA 显著降低了每次迭代中实际注意力计算的挂钟时间占比。
在 60K 前缀缓存、8 并发和 NVIDIA B200 的代理式流量下，另一项内核执行分解显示，MSA 显著降低了每次迭代中注意力计算所花费的挂钟时间百分比。
除了注意力架构的变化，M3 还配备了多模态支持，包括视觉组件以及新的图像和视频预处理功能。
鉴于这些根本性变化，Together AI 与 MiniMax 的工程团队密切合作，以应对新出现的挑战。一些主要挑战包括：
- 尽管 MiniMax 的稀疏注意力计算本身非常高效，但从工程角度来看，支持 1M 上下文长度仍然具有挑战性。
- 视频和图像处理本质上比文本分词更复杂。
优化
KV-Block-Major 稀疏注意力
在预填充阶段，对于长上下文输入，注意力计算仍然是一个重要因素，因为对于每个 token，我们需要计算 Selected Block * KV Head Group * Tokens。块稀疏注意力的特性允许多个查询关注相同的键值块。因此，如果我们遍历每个查询来计算与键值块的注意力，就会重复将 KV 从 HBM 移动到 GPU 上的 SRAM。在外层循环中遍历键值组，在内层循环中计算查询 token 之间的注意力，可以实现更好的算术强度，因为 KV 缓存只移动一次。
为了实现这一点，我们需要重新组织从 {q, kv block} 到 {kv block, q} 的映射，并重新实现注意力内核。由于我们只计算 kv 块的部分 O 输出，因此需要基于 Log-Sum-Exp 进行最终的“归约”以重新缩放输出 O 并求和。过程如下：
将 MSA 与分页注意力集成
在现代推理引擎中，分页注意力通常用于管理请求的 KV 缓存上下文。大多数高度优化的注意力内核都支持固定的页面大小集。阻止我们使用这些内核的障碍是，所选块在不同 KV 组之间是不同的。
在 Together AI，我们提出了一种将 MiniMax 稀疏注意力集成到引擎中的新方法。在解码过程中，我们首先基于所选块构建页表，将 KV 组维度展平到批次维度，并利用 KV 缓存张量的跨步视图为注意力内核提供检索 KV 页面所需的指针。关键在于步幅：页面地址按 D 前进以选择虚拟页面起始位置，而 token 按 Hkv * D 前进。这将一个物理张量解交织为每个头的页面，因此每个展平的行现在可以使用不同的页表。
这种设计使我们能够使用现有的支持GQA的注意力内核，而无需从头编写一个新的支持稀疏注意力的内核。由于每个查询选择的块数量有限，用于查找块到页面映射的内核开销非常低。这种设计使解码吞吐量提升了5%。
解码索引评分内核优化
对于解码，MSA将大部分成本从密集注意力转移到了评分/前k索引器上。对于每个解码查询，引擎将查询侧索引向量与候选键侧索引向量进行比较，将每个128令牌的KV块缩减为单个分数，并仅保留前k个块用于实际注意力内核。此扫描位于每个生成令牌的关键路径上，并且在长上下文长度下，候选块的数量随上下文长度增长。解码评分具有小查询索引、长键索引的形状。将一批解码查询视为一个更大的GEMM很诱人，但评分/索引步骤不仅仅是密集矩阵乘法：每个请求和K组都有自己的候选块范围、掩码、逐块归约和前k边界。将查询拼接在一起仍然会在GEMM周围留下一个不规则的收集和归约问题，同时强制填充和额外的簿记进入关键路径。因此，我们的优化路径使用了AB交换的HMMA布局：128令牌的键索引块成为MMA的M维度，而查询侧仅填充到较小的N维度。内核使用异步拷贝分阶段加载128令牌的K索引，预取下一页，使用HMMA以bfloat16计算点积，并将每个页面归约为一个块分数。
网关处的多模态预处理
SMG（服务模型网关）是一个基于Rust的模型网关，位于兼容OpenAI的API和推理引擎之间。除了路由和分词外，SMG还承担了对多模态模型特别重要的角色：它在请求到达GPU工作节点之前在CPU上执行所有视觉预处理。
图像和视频输入在用于视觉编码器之前需要大量的CPU工作：下载、解码、帧采样、调整大小和转换为补丁张量。在推理引擎内部执行这些操作会占用本应用于生成的资源。SMG在网关中处理所有这些，因此当请求到达GPU时，张量已经准备就绪。
对于M3，这意味着：获取视频，使用FFmpeg提取帧，基于FPS（每秒帧数）选择子集，调整大小和归一化，然后进行补丁化并嵌入时间维度。输出是一个扁平补丁张量和一个小的网格元数据张量，打包到gRPC消息中。工作节点直接运行视觉编码器——无需在其端进行预处理。
此外，SMG的多模态流水线围绕Rust特性构建，这些特性将特定于模型的预处理逻辑与流水线管道分离。添加M3多模态支持意味着使用M3特定的常量实现这些特性；流水线本身没有改变。相同的架构适用于大多数具有视觉能力的开源模型，并跨推理引擎运行时通用。
性能结果
自收到 MiniMax M3 权重和模型架构以来，我们致力于提升推理性能。在常见的智能体形状流量下，我们实现了不同并发级别上 81% 至 125% 的性能提升。
未来工作
新架构带来了新的基础设施和工程挑战。在 Together AI，我们的目标是提供最佳的推理性能。关于 M3，我们正在积极研究的几个主题包括：
稀疏注意力架构引入了更多小内核，例如，对 kv 块进行 topk 操作、将 q-kv 映射重新映射为 kv-q 等。存在更多内核融合的机会。我们的内核代理研究团队正在积极开发能够编写生产级内核的代理。
k-index 和实际 kv 缓存的 CPU 缓存卸载现在可以分离。我们正在研究加载完整的 k-index，并根据 topk 选择按需加载 kv 缓存。