标签 长上下文 下的文章

导读

阿里云 Tair KVCache 团队联合 SGLang HiCache Team 、蚂蚁 AI Infra-推理服务团队、阿里云服务器震旦异构计算团队，共同推出面向 Sparse Attention 的分层稀疏化框架，本文详细介绍该框架的架构设计与实现细节。

在前文《智能体式推理对 KVCache 的挑战与 SGLang HiCache 技术深度剖析》中，我们详细介绍了 HiCache 如何通过分层存储架构（GPU → CPU → 远端存储）突破 KVCache 的容量瓶颈，将有效缓存容量从 40GB 扩展至 TB 级别，使长上下文、高并发的 LLM 推理服务得以规模化部署。

然而，当上下文长度跨越 128K 甚至迈向百万 Token 时，两个新的瓶颈开始凸显：

  • 计算瓶颈：Attention 计算成本随序列长度线性增长，并受限于 HBM 带宽。动态稀疏注意力（DSA）通过"Select-then-Compute"范式选择 Topk Token 参与 Attention 计算，成功突破了这一瓶颈。
  • 容量瓶颈：引入 DSA 后，主要瓶颈从 HBM 带宽转移到了 HBM 容量——为确保低延迟，全量 KV Cache 仍需驻留 GPU，导致并发推理能力受限。

本文引入了分层稀疏化——将全量 KV Cache 存储在 CPU，GPU 中仅维护 Top-k 的 LRU Buffer——为破解这一双重约束提供了可行路径。本文将系统性介绍 SGLang 的分层稀疏化框架设计，包括：

  • 整体架构：SparseCoordinator、Algorithm、BackendAdaptor、SparseKVCacheManager 的模块化设计；
    *
  • 核心机制：Sparse Diff Kernel 的增量传输、I/O Kernel 的高性能传输优化；
  • 实践案例：DeepSeek DSA 的深度集成，实现单请求显存占用从 8GB 降至 200MB，3倍单机吞吐提升；
    分层稀疏化标志着 KVCache 管理范式的又一次跃迁：从 HiCache 的"分层存储 → 扩展容量"，到本文的"稀疏化 + 分层 → 突破带宽与容量双重约束"，为超长上下文推理开辟了全新的技术路径。(注：此项目目前处于开发阶段，尚未正式发布。)

本系列技术文章将系统性拆解面向智能体推理的KVCache技术演进路径：

1.智能体式推理对 KVCache 的挑战与 SGLang HiCache 技术深度剖析

2.3FS-KVCache 工程化落地：企业级部署、高可用运维与性能调优实践

3.Hybrid Model Support：SGLang 对 Mamba-Transformer 等混合架构模型的支持方案

4.Tair KVCache Manager：企业级全局 KVCache 管理服务的架构设计与实现

5.KVCache 仿真分析：高精度的计算和缓存模拟设计与实现

  1. 本文｜Hierarchical Sparse Attention：分层稀疏注意力框架下的 KV 分层管理与按需加载
  2. 展望：KVCache驱动的软硬结合演进

1.引言：双重瓶颈与协同破解之道

1.1 HiCache：容量扩展的胜利与新的战场

在前文《智能体式推理对 KVCache 的挑战与 SGLang HiCache 技术深度剖析》中，我们详细介绍了 HiCache 如何通过分层存储架构（GPU 显存 → CPU 内存 → 3FS 远端存储）突破 KVCache 的容量瓶颈。通过智能的热度感知调度与异步预取机制，HiCache 将原本仅有 40GB 的 GPU 显存扩展至 TB 级别的有效缓存容量，使得长上下文、高并发的 LLM 推理服务得以实现规模化部署。

在真实生产环境中，HiCache 已展现出显著价值：缓存命中率从 40% 提升至 80%，平均 TTFT 下降 56%，推理 QPS 提升 2 倍。

然而，当我们将目光投向更极致的长上下文场景——例如 128K 甚至百万级别的上下文窗口时，新的瓶颈开始浮现。

1.2 长上下文的 HBM 带宽墙：从线性增长到稀疏化破局

1.2.1 Attention 计算的带宽瓶颈

在长上下文推理中，Attention 计算呈现出独特的性能特征。每个 Decode 步骤需要将完整的 KV Cache 从 HBM 加载到计算单元，执行Attention计算。由于 KV Cache 随序列长度线性扩展，Attention 计算成本也随之线性增长。

关键问题在于 Attention 的计算强度（Arithmetic Intensity） 过低——相对于海量的访存操作，实际的浮点运算量不足以饱和 GPU 的计算单元。这使得 Attention 成为典型的 memory-bound 操作，Attention 计算受限于 HBM 带宽。随着上下文长度从 32K 扩展至 128K 甚至百万级别，这一带宽瓶颈成为长上下文推理的主要性能制约因素。

1.2.2 动态稀疏注意力（DSA）的 Select-then-Compute 范式

为突破带宽瓶颈，动态稀疏注意力算法（Dynamic SparseAttention, 后文简称 DSA）从 Attention 机制的本质特性出发：在自回归生成过程中，并非所有历史 Token 都对当前输出贡献相同的权重。研究发现，Attention 分布往往呈现显著的长尾特征——少数关键 Token 占据了绝大部分的 Attention Score，而大量 Token 的贡献可以忽略不计。更重要的是，这些关键 Token 的集合在不同 Query 间动态变化，无法通过静态规则预先确定。

DSA 将这一观察转化为 "Select-then-Compute" 工作流，通过三个协同阶段实现稀疏化：

  • 分块与元数据抽象：将 KV Cache 划分为固定大小的块（block size 通常为 32 tokens），每个块维护轻量级的元数据结构。这些元数据可以是 Key 向量的统计摘要（均值、方差）、Bounding Box（每维度的最大/最小值）、或经过降维的紧凑表示。元数据的存储开销通常不到完整 KV Cache 的 1%，可以常驻 GPU 内存。
  • 快速重要性评估：对于每个新生成的 Query Token，算法无需访问完整的 Key Cache，而是基于元数据快速计算每个块的 Criticality Score。这一评估过程的计算量远小于完整 Attention（通常为 O(n/32) vs O(n)），且可以高效并行化。随后通过 Top-k 选择算法（如 heap-based selection），筛选出最相关的 k 个块（典型值 k=2048，对应 64 个块）。
  • 按需稀疏计算：仅对选中的 Top-k 块加载其完整的 Key 和 Value Cache，执行标准的 Scaled Dot-Product Attention。未被选中的块则完全跳过，避免了不必要的 HBM 访问。

代表性 DSA 算法包括：

  • Quest：训练无关的启发式算法，利用 Query-Key Bounding Box 的几何关系近似估计 Attention Score 上界。通过维护每个块在各维度上的 Key 最大/最小值，Quest 可以在不访问完整 Key 的情况下，快速排除不重要的块。
  • ClusterKV: 将 Prefill 阶段的所有 Keys 向量进行聚类（如 K-means），生成 C 个聚类中心；每个原始 key 被映射到其最近的 centroid; Decode 阶段 Query 跟聚类中心计算，获取最具相关的 Topk。
  • DeepSeek DSA：作为模型原生的稀疏注意力机制，通过专门训练的 Indexer 模块动态预测 Token 重要性，Indexer 的输出直接指导 Top-k 选择。

1.3 隐形的显存墙：稀疏计算的容量困境

尽管稀疏注意力在计算层面取得突破，但其执行流程存在固有的先后依赖关系：

在 Stage 1 中，算法需要评估每个 Token/Page 的重要性（计算 ）；在 Stage 2 中，基于评分选择 Top-k；只有在 Stage 2 完成后，Stage 3 才知道应该对哪些 KV 进行计算。

这一依赖链导致了一个根本性问题：在确定 Top-k 之前，系统无法预知需要哪些 KV 数据，因此必须将全量 KVCache 保留在 GPU 中。

关键约束：稀疏化实现了计算复杂度的降低（O(n) \rightarrow O(k)），但显存占用复杂度依然保持 O(n)；也即采用 DSA 后，主要性能瓶颈从 HBM 带宽转移到了 HBM 容量；这一容量约束导致：

  1. HBM 容量利用率低下（Poor HBM Capacity Utilization）：98.4% 的 KV Cache 在每步中未被访问，却占据宝贵的 HBM 空间。
  2. 并行能力受限（Limited Parallelism）：小 Batch Size 无法充分发挥 GPU 的并行计算能力，推理吞吐难以提升；例如对于 DeepSeek V32，单个 128K 请求的 Latent Cache 占 8 GB，H200 扣除模型权重后，最多只能支持 Batch=5，这严重限制了 GPU 并行计算能力的发挥。
  3. 分层存储价值受阻（Value Blockage）：传统的 KV Cache Offload 方案要求所有数据在 Decode 前加载到 HBM，无法与 DSA 的动态选择特性协同工作。

1.4 分层稀疏化：存储与计算的协同优化

破解显存墙的关键洞察在于：既然 Attention 计算只需要 Topk 部分，何不只在 GPU 中存储 Topk 部分，并结合 CPU HICache，在计算完 Topk 后动态加载增量的 Topk 部分？

分层稀疏化的关键是改变 KVCache 的存储位置和加载时机（下面以 DeepSeek DSA 为例）：

  • 传统流程：完整 Latent Cache 必须驻留在 GPU 显存中。Decode 阶段执行 Indexer 选择 Top-2k，然后对选中的部分进行 Attention 计算。单个 128K 请求，虽然理论计算量降低了 60+ 倍，但显存占用依然是 O(n)，占用 8 GB，H200 最多支持 Batch=5；

  • 分层稀疏化流程：Prefill 后将完整 Latent Cache（8 GB）Offload 至 Host 内存，GPU 仅保留轻量 Sparse Indexer 元数据。Decode 时基于元数据在 GPU 执行 Indexer 选择 Top-2k，Host 筛选对应的 Latent 子集并增量传输至 GPU，最后执行 Attention 计算；

    • 单请求 GPU 显存占用降至 < 200 MB，单 GPU 可支持$B_{max} = \min \left( \frac{M_{host}}{M_{req}}, B_{SLO} \right)$
    • 其中，$M_{host}$代表单卡可分配的最大 CPU 内存容量；B\_{SLO}代表满足 SLO 延迟要求的最大 Batch Size。

核心优势：

  • 完整 KVCache 存储在 Host，突破 GPU 显存物理空间限制；
  • GPU 侧只需存储轻量 Sparse 元数据和 Topk 部分 KVCache，Req 显存占用从O(n)降至 O(k)；
  • 高性能传输：结合 HICache IO Kernel 实现 Topk Cache 高性能传输，单层 IO 延迟控制在 us 级别；并结合 Overlap 能力将 IO 延迟隐藏在计算中。

分层稀疏化不仅解决了计算问题，更从根本上破解了显存容量的刚性约束，实现了计算效率与存储效率的协同优化，为超长上下文推理开辟了全新的技术路径。

2.SGLang 分层稀疏化框架设计

2.1 整体框架设计

SGLang 的分层稀疏化框架采用模块化、可插拔的三层架构设计，通过标准化接口实现算法解耦、后端兼容与非侵入式集成。框架核心由以下模块构成：

  • SparseCoordinator（协调层）：通过生命周期钩子编排三大功能模块的协同工作

    • Algorithm（算法层）：提供可插拔的 Top-k 选择策略实现；
    • BackendAdaptor（适配层）：完成稀疏索引到物理地址的转换与后端对接；
    • SparseKVCacheManager（传输层）：基于 Diff & IO Kernel 实现 Host-GPU 间的高效、增量数据传输。
  • RequestTrackers（状态管理）：维护每个请求的稀疏化状态管理。

该架构既原生支持模型内置的稀疏化机制（如 DeepSeekV32 DSA），也允许 Training Free 的稀疏化算法（Quest / SnapKV）与通用 Attention 后端（FlashAttention / Triton）灵活组合，为长上下文推理场景提供统一且高度可扩展的分层稀疏化方案。

2.2 SparseCoordinator：稀疏化流程编排器

SparseCoordinator 是分层稀疏化框架的中枢控制器，通过生命周期钩子函数（Lifecycle Hooks）在模型推理的关键节点精确编排 Algorithm、BackendAdaptor 和 SparseKVCacheManager 三大模块的协同工作。其设计遵循事件驱动模式，将 Retrievable Sparse 的完整流程解耦为标准化的钩子接口，实现了算法与模型的零侵入集成。

SparseCoordinator 将稀疏化推理划分为两个核心阶段：

  • Representation Construction Phase（Prefill 结束或 Decode 初期）：通过 attention\_end hook 调用 Algorithm 的 construct\_representations() 和 update\_representations() 方法，将原始 KVCache 压缩为语义表示并存入 Representation Pool，此阶段执行完整 Attention 计算以确保表示质量；
  • Query-Guided Decoding Phase：每个 Decode Step 在 attention\_begin hook 中，Coordinator 驱动 Algorithm 基于当前 Query 从 Representation Pool 中执行 retrieve\_topk() 选择最相关的 Top-k 表示，随后由 BackendAdaptor 完成逻辑索引到物理索引的转换并触发 SparseKVCacheManager 的增量数据传输（通过 Diff Kernel 计算 Topk 集合差异，仅加载变化部分），最终动态重构 Attention Metadata（如 FlashAttention 的 PageTable）供 Attention 后端执行稀疏化计算；
  • 通过这种"捕获-计算-转换-注入"的闭环设计，SparseCoordinator 在保持框架灵活性的同时，实现了高效的 KVCache 分层管理。

2.3 可插拔的稀疏化策略

在 SparseCoordinator 的编排下，Algorithm 和 BackendAdaptor 作为两个核心功能模块，分别负责"选择什么"和"如何映射"的问题，通过清晰的接口定义实现了高度的可插拔性和扩展性。

2.3.1 Algorithm：抽象的 Top-k 选择策略

Algorithm 层采用抽象基类 BaseSparseAlgorithm 定义统一接口，将稀疏化算法的核心逻辑解耦为三个标准化方法：

  • retrieve\_topk(queries, layer\_id, ...)：

    • 基于当前 Query 从 Representation Pool 中检索 Top-k 重要 Token/Page 的逻辑索引；
    • 算法只需返回"逻辑索引"（Token ID 或 Page ID），无需关心底层 KVCache 的物理存储布局和 Attention 后端的实现细节（FlashAttention / Triton）。
  • construct\_representations(...)：在 Prefill 阶段或 Decode 阶段初期构建用于检索的 Representation Pool 语义表示（如 Key 的压缩表示）。

  • update\_representations(...)：在 Decode 阶段增量更新 Representation Pool。

    以 Quest 算法为例：

  • Quest 是一个 Training Free 的 page-wise 稀疏注意力算法，通过为每个 KV Page 维护 per-dimension 的 Key Bounding Box（min/max 值）来避免完整的 Query-Key 点积计算；
  • 在 construct\_representations 阶段，算法遍历所有 Pages 提取 Keys 并计算 Keys 在每个维度的最小/最大值存入 page\_k\_min/max Representation Pool （内存开销约为完整 Key 存储的 1%）；
  • 在 retrieve\_topk 阶段，通过 criticality 计算 Attention Score 的上界估计，快速筛选 Top-k Pages 后交由 BackendAdaptor 完成物理地址转换。
2.3.2 BackendAdaptor：索引转换与后端对接的桥梁

BackendAdaptor 层解决了"逻辑世界"到"物理世界"的映射问题。不同的 Attention 后端（DSA Backend、FlashAttention、Triton FA3）对输入数据的格式和索引方式有不同要求，Adaptor 负责屏蔽这些差异。

以 FlashAttention Adaptor 为例：FlashAttentionAdaptor 通过 req\_to\_token 映射表将逻辑 Page IDs 转换为物理页号，重构 PageTable 并更新序列长度元数据（cache\_seqlens, cu\_seqlens\_k），使 FlashAttention 能够基于 Top-k 选中的稀疏页执行注意力计算。

2.4 DeepSeek DSA 接入实践

2.4.1 DeepSeek SparseAttention 介绍

和 DeepSeek-V3.1 相比，DeepSeek-V3.2 的架构改动是在继续训练过程中引入了 DeepSeek Sparse Attention（DSA）。

DSA的原型设计由两部分进行构成，Lightning Indexer（闪电索引器）和 Fine-grained Token Selection Mechanism（细粒度 Token 选择机制）。其首先通过一个轻量级的索引器，进行快速筛选出与当前查询 Token 最相关的候选 Tokens，然后仅在这部分稀疏的候选集上执行高精度的注意力计算。

(注：图片出自 DeepSeek 论文)

2.4.2 DeepSeek DSA 整体接入流程


关键设计包括：

  • 双缓存映射：系统维护两套独立的物理地址映射表（DSADecodeReqToTokenPool）：req\_to\_token 中存储每个 Req 对应的  Latent Cache LRU Buffer 页表（LRU Size = 2～4KB），req\_to\_dsa\_index\_k 存储 indexer\_k 页表。Prefill 阶段，Indexer 模块为每个 Token 生成 index\_k，存储至 GPU 端；同时完整的 Latent Cache 被 Offload 至 CPU 内存。Prefill 阶段结束后，每个 Req 占用的显存空间会固定在 LRU Size。
  • 增量传输机制：Decode 阶段，每个 Token 生成时，Indexer 基于当前 Query 和历史缓存的 index\_k 高效计算出 Top-2K Tokens 逻辑索引；随后 Sparse Diff Kernel 通过集合差分算法比较 prev\_topk 和 curr\_topk，精确计算出需要新加载的索引变化量 Δ；SparseKVCacheManager 据此调用 load\_to\_device\_per\_layer 仅传输 Δ 对应的 Latent Cache 块到 GPU 的 LRU Buffer，最小化 PCIe 带宽消耗。
  • 零侵入集成：DeepSeek DSA 通过 SparseCoordinator 的生命周期钩子与模型解耦集成，DeepSeekDSAAlgorithm 作为 Algorithm 层的具体实现直接调用模型原生的 Indexer；DSABackendAdaptor 负责将逻辑 Top-k 索引转换为物理设备地址并触发增量传输；最终由 DSA Backend（支持 flashmla\_sparse/flashmla\_kv/fa3 等多种实现）基于稀疏页表执行 Attention 计算。这一设计使得 128K 长上下文推理的 GPU 显存占用从约 8GB 降至约 200MB。
2.4.3 Sparse Diff Kernel: 增量 Cache 传输基石

动机：时间局部性带来的优化空间

DSA 的 Top-k 选择结果在时间维度上呈现显著的局部性：相邻 Decode Steps 的 Top-k 集合高度重叠。实验表明，相邻 Steps 的 Top-k 重合度通常达到80%～90%，这意味着每个 Decode Step 理论上仅需加载不到 20% 的新 Cache，为增量传输提供了天然的优化空间。

Buffer 容量与命中率的权衡

然而，随着序列长度的增长，Top-k 选择的候选范围线性扩展，相邻步的差异逐渐放大。不同的 LRU Buffer 容量配置会直接影响 Cache 命中率。

可以看到，当 Buffer 容量仅为 Top-k 大小（2K）时，长序列场景下命中率显著下降，I/O 延迟成为瓶颈。而将 Buffer 扩大至 4K～8K，可以用可控的显存开销换取成倍的 I/O 效率提升。

LRU Diff Kernel 设计与实现

为充分利用 DSA 的时间局部性，我们设计了基于 LRU 淘汰策略的 Diff Kernel。其核心思想是：在 GPU 侧维护一个 Top-k 的 2～4 倍容量的 LRU Buffer（典型配置为 4K～8K Token），通过智能淘汰策略容纳 Top-k 的短期波动。

Kernel 工作流程分为三个阶段：

阶段 1：集合交集计算

比较 prev\_topk 和 curr\_topk，识别出两步共同选中的 Token。这部分 Cache 已驻留 GPU，无需重新加载，直接更新 PageTable（curr\_device\_indices）以复用现有数据。

阶段 2：LRU 淘汰决策

这是与严格 Top-k Buffer 的核心差异。Kernel 不会简单驱逐所有 prev\_topk 中未在 curr\_topk 出现的 Token，而是：

  • 仅当 Buffer 空间不足时才触发淘汰；
  • 优先淘汰过去多个 Step 中均未被命中的 Cache 页（基于 LRU 策略）；
  • 计算 evict\_device\_indices，标记最冷的物理页位置可被覆写。

阶段 3：增量加载映射

从 curr\_topk 中提取新增的 Token（未命中部分），生成一对一的加载映射关系：

  • load\_host\_indices：这些 Token 在 Host Memory 中的物理地址；
  • load\_device\_indices：它们在 GPU 中的目标物理页号（复用阶段 2 淘汰的位置）。

这种启发式策略充分利用了 DSA Top-k 选择的时间连续性，为每个 Request 动态维护一个高效的缓存窗口, 使得系统可以用较少的 GPU 缓存空间维持长序列场景下至少 80%+ 的缓存命中率，达到空间和效率的动态平衡。

2.4.4 I/O Transfer Kernel: 高性能传输利器 TODO

为了实现 GPU-CPU 异构内存层次间的高效数据迁移，SGLang HiCache 设计了专门的 IO Kernel 传输引擎。该引擎采用 CUDA 底层优化技术，通过 warp-level 细粒度并行最大化 PCIe 带宽利用率。

IO Kernel 支持多种内存布局模式（layer\_first、page\_first、page\_head），实现了对 MHA和 MLA 架构的统一抽象。在 CPU 侧采用 pinned memory 和 CUDA host register 机制确保零拷贝传输，结合 per-layer 和 all-layer 两种传输粒度的动态调度策略，在 prefill 阶段后进行批量全层 offload，在 decode 阶段进行增量单层传输，有效平衡了传输延迟与带宽开销。

实测表明，通过 NUMA 绑定，该 IO Kernel 在 8×H20 上可达到接近\~40GB/s per GPU，为分层 KV cache 架构提供了低延迟、高吞吐的数据搬运基础设施。

3.性能评估

我们在 SGLang 分层稀疏注意力框架上接入了 DeepSeek V32 DSA，并在长上下文推理场景下进行了系统性能评估。实验采用 DeepSeek-V32 模型，针对 16k、32k 和 64k 三种序列长度配置，在 8×H200 GPU With 1TB 内存上测试了不同 batch size 下的输入吞吐量（input tokens/s）。

实验结果表明，相较于传统的全量 KV cache 方案，分层稀疏注意力方案（Hierarchical Sparse）通过结合KV cache 分层管理、GPU-CPU 异构存储以及动态 TopK 检索机制，在长序列场景下展现出显著的性能优势。具体而言：

  1. 内存效率&吞吐量突破：传统方案受限于 GPU 显存容量，在 64k/32k/16k 序列长度下分别仅能支持最大 batch size 为 32/64/128，而 Hierarchical Sparse 方案通过将 KVCache Offload 至 CPU 内存，可支持的最大 batch size 分别达到 160/304/600，实现了 5 倍的批处理能力提升，2～3 倍的 Through 提升。
  2. 可扩展性验证：随着 batch size 增加，Hierarchical Sparse 方案的吞吐量呈现近线性增长趋势，验证了分层缓存架构和稀疏注意力机制在大规模并发推理场景下的良好扩展性。

该结果证明了分层稀疏注意力架构在突破 GPU 显存墙、支持超长上下文大规模并发推理方面的有效性。

4.展望与Roadmap

技术深化方向：

  • 算法与后端扩展：适配更多 Sparse 算法（如 StreamingLLM、PQCache）与 Attention 后端（如 FlashInfer、Triton），提升框架的生态兼容性。

  • 性能优化：

    • IO 掩藏：通过 TwoBatch Overlap、Kernel Fused 等技术进一步降低 I/O 延迟开销，逼近理论性能上限。
    • 异步检索： 基于相邻 Token 的 Query 具有高度相似性原则，通过前序 Token 的 Query 提前异步检索 当前 Step 的 Topk，减少检索开销。

架构演进方向：随着超节点架构的普及，GPU 通过 Scale-Up 网络访问共享内存池的带宽已显著超越传统 PCIe 带宽。在此硬件趋势下，KVCache 的内存池化管理（Memory Pooling）成为自然选择。我们将协助实现超节点内的 KVCache 统一池化调度，充分发挥 Scale-Up 网络的带宽优势，突破传统 PCIe 瓶颈，为超长上下文推理提供更高效的分层稀疏化基础设施。

了解更多

欢迎搜索钉钉群号：109765011301入群与技术专家交流！

过去几周，我对于 Vibe Engineering 的实践有了更多的体会, 今天再次总结一下。其实也能看出来我避免使用 Vibe Coding 这个词，是因为当下的重点已经不再是代码，而是一些更高维度的东西。另外，本文的 AI 含量我会尽量控制在 5% 内，可以放心阅读😄。

之前我提到的我开始的 TiDB Postgres 重写项目已经不再在是个玩具。在前几天出差的路上, 因为长途飞行没有网络, 我仔细 review 了一下这个项目的代码, 虽然一些地方略有瑕疵, 但是总体质量已经很高, 我认为已经是接近生产水平的 rust 代码，和以前我理解中的早期原型的定义很不一样。

顺便提一句, 我认为这个项目从一开始就选择 rust 是一个无比正确的决定, rust 的严谨性让 AI 能写出更接近 bug free 的 infra code (对比我另一个项目 agfs 的 shell 和它自带的脚本语言 ascript，由于这项目使用 python，项目变大后，可维护性就大大降低，但此时重写已经很困难，只能捏着鼻子慢慢重构)，所以现在已经是 2026 年了， 如果你要再启动一个新的 backend infra 项目, rust 应该是你的第一选择。

验证差不多后，我也邀请了几位我团队内的几个顶尖的 vibe coder 加入项目, 看看 100% 的 AI Native 研发模式能在多快把这个项目推进到何种程度，无论如何都很想看看，应该会很有意思。

下面说说自己最近的一些感受。

当前关于 Vibe Engineering 的所有的认知都会在 1 个月内严重过时

并非危言耸听，哪怕我正在写的这篇文章，如果你是 2026 年 2 月看到，那么很遗憾，本文聊到的东西很可能已经过时，这个领域发展的太快，很多今天的 SOTA 也许下个月就过时了。而且很有意思，过去很多对 Vibe Coding 嗤之以鼻的大佬，例如 DHH，Linus，Antirez 等，在 2025.12 月开始纷纷改口，我觉得这是相当正常的，去年 12 月开始，AI 编程工具和头部的模型突然有一个跳跃式的进步，突然对于复杂任务和大型项目的理解，以及写出代码的正确率有了极大的提升。这进步大概来自于两个方面：

一方面头部模型在长上下文（>256K) 的支持，尤其是关键信息的召回率提升惊人

例如上面是 GPT-5.2 在长上下文的召回表现和 GPT-5.1 对比很明显，要知道对于 Agent Coding 的场景来说，通常是多轮次推理 + 长上下文（因为要放更多的代码和中间推理结果）才能更好的有大局观，大局观的正确是对于复杂项目起到决定性因素。在这种场景下，你可以做一个简单的计算，一个模型（类似 GPT-5.1) 每轮的召回率 50%，大概 3 轮后，正确的召回率就会降低到 12.5%, 而 GPT-5.2 仍然能保持 70% 以上。

另外一个进步是主流的 Vibe Coding 工具的 Context Engineer 实践日益成熟，例如 Claude Code / Codex / OpenCode。从用户体验到最佳实践，肉眼可见的越来越好，例如对于 Bash 的使用，Subagent 等，这方面越来越多的资深 Engineer 的重度使用和经验分享会对这些工具的进化提供数据飞轮，尤其是 AI 也在深度的开发这些工具，迭代速度只会更快。

其实这个进步也并不是去年 12 月那个时间点的突然什么黑科技爆发，其实前几个月一直在进步，不过还不能长时间离开人工干预，更像是那个时间点，主流 Coding Agent 的质量超过了一个临界点：100% 的无人工干预下完成长时间的 Agentic Loop 成为可能。

Hire the best (model)，否则就是在浪费生命

上面所有提到的进步，我个人感觉只反映在了最顶尖的闭源头部模型中。我听到很多朋友和我反馈到：“我感觉 AI 编程还是很傻啊？并没有你提到那么聪明”，我首先会反问，你是不是只是用着 $20 一个月那种入门模型？如果是的话，那先去用一阵 $200 以上的 Pro Max 档次的，也许有惊喜。

我个人认为，目前主流的模型，即使并非头部那档，作为 chatbot 处理大多数普通人的短上下文的日常工作是完全足够的，哪怕是 GPT-4 在和你讲人生道理的时候也已经足够把你说得一愣一愣了。

作为人来说，我们的直觉或者是一些简单的 CRUD Demo 已经无法评估这些模型之间的智商差距了。但是在复杂的项目的开发中，这个差距是极端明显的。

根据我个人的实践来说，当下能用来进行大型 Infra 项目（数据库，操作系统，编译器等）开发的模型大概就两个：GPT-5.2 (xhigh) + Opus 4.5，还有半个算是 Gemini 3 Pro。

大概上个月我主要用着 opencode + oh-my-opencode + Opus 4.5 但是最近两周转向到了 codex + gpt-5.2 的组合，下面分析一下这几个模型的一些脾气和调性，仅仅是个人感受，而且是在后端 Infra 软件开发这个领域，仅供参考。

Opus 4.5 的风格是速度很快，是个话唠，由于 Sonnet 4 有严重 reward hacking 问题，例如是在解决不了 bug 的时候会偷偷的构造作弊的测试然后糊弄过去，所以导致很长一段时间我都不太敢用 Sonnet 系列模型干复杂的事情，但是这点在 Opus 4.5 中解决得很好，即使在模型冥思苦各种尝试想都搞不定的情况下也没有选择作弊，让我放心不少，但是 Opus 的问题是 reasoning 和做 investigation 的时间太少，动手太快，以至于发现不对的时候，又返回头确认假设和研究，这样的特性催生了像 ralph-loop 这样的奇技淫巧。比方说，同样的一个 prompt 在 Claude Code 结束后又通过 stop hook 重新调用，再完整走一遍流程，不断地逼近最终的结果。

相比之下，GPT-5.2 更像是一个更加小心谨慎、话不多的角色。我最开始用 Codex 的体验其实不算太好，因为我一直觉得它有点太慢了。主要是因为我习惯用它的 xhigh 深度思考模式，在真正开始写代码之前，它会花很长时间去浏览项目里的各种文件和文档，做很多准备工作。可能也是因为 Codex 的客户端不会告诉你它的计划和大概需要多久，所以就显得过程特别长。

有时候一些复杂的任务，它前期的调查可能就要花上一到两个小时。但是经过长时间思考后它完成的效果通常是更好的，尤其是在一个项目的大体框架已经稳定，Codex 考虑得更周全，最终也体现出更少的 bug 和更好的稳定性。

对于第三个顶级模型，也就是 Gemini 3 Pro。虽然我也知道它的多模态能力非常吸引人，但就复杂任务的 Coding 场景而言，至少从我个人的体验来看，它的表现并没有 Opus 4.5 和 GPT-5.2 那么强。不过它确实针对一些快速的前端项目 Demo 和原型制作做了一些优化，再加上它的 Playground 模式，让你在需要一些炫酷的小 Demo 或前端项目时能更快实现。

其实一个比较反直觉的事情是，过去我们经常说 Vibe Coding 只能搞一些比较简单的事情，比如上面那些小 Demo 或 CRUD 项目，你会看到网上各种各样的 KOL 其实都在做这种小原型，反而大家觉得对于一些像后端这种核心的基础设施代码，当前 AI 还是搞不定的。我以前也这么想，但从去年 12 月份开始，这个结论可能需要修正了。

这里面的原因是，其实这类基础设施的代码通常是由顶级工程师长期精雕细琢而成，它们有清晰的抽象、良好的测试，甚至代码本身经过多轮重构后也相当精炼。所以当 AI 具备足够的上下文空间 + 更好的推理能力 + 更成熟的 Agentic Loop + 高效的工具调用时，这类 Infra 代码的开发和维护反而是能最有效地利用这些顶尖大模型的智商的场景。

在实际的工作中，我经常会让多个 Agent 互相协作，或者使用一些复杂的工作流来把它们编排在一起，并不会让一个模型来完成所有的事情。后面我会再分享一些我自己实践中的具体例子。

人在什么时候进入？扮演什么角色？

上面提到了，这些顶级模型再配合主流的 Vibe Coding 工具，基本上已经能超越大多数资深工程师的水平了。这不仅体现在能写出更少 bug 的代码，也体现在在 review 中能发现更多人类工程师可能看不到的问题，毕竟 AI 真的会一行一行仔细看。

所以人在这个过程中扮演什么样的角色，哪些阶段只有人才能做？根据我自己的实践来说，第一当然是提出需求，毕竟只有你才知道你想要啥，这很显然，但是有时确实也挺难的，毕竟人很难从一开始就准确描述自己想要什么，这时候我会用一个偷懒的办法：让 AI 来角色扮演，比方说，我在开发 PostgreSQL 版本的 TiDB 时，我就让 AI 假设自己是一个资深的 Postgres 用户，从开发者的视角告诉我有哪些特性是非常重要、一定要实现而且 ROI 比较高的，让它列出 N 个这样的功能点，然后 AI 就会根据它的理解生成一个需求列表，接下来你再和 AI 对这些需求逐个打磨，这其实是一个高效冷启动的方法。

第二是在需求提出后，现在的 Coding Agent 大多都会和你有一个规划阶段（Planning），会反复确认你的需求。在这个过程中其实有一些技巧，比如不要给 AI 太具体的方案，而是让 AI 来生成方案，你只需要关注最终你想要的结果；提前告诉 AI 有哪些基础设施和环境的问题，让它少走弯路。

另外，我通常会在提出需求的第一阶段就要求 Agent 做的一些关键动作。比如无论接下来做什么，都要把计划和 todo 列表放在一个 work.md 或 todo.md 这类文件里。还有，每完成一个阶段的工作，就把上一阶段的经验教训更新到 agents.md 里。第三点是当一个计划完成并且代码合并后，把这个工作的设计文档添加到项目的知识库中（.codex/knowledge）。这些都是我会在一开始提需求时就放进去的内容。

第二个阶段就是漫长的调查、研究和分析的阶段。这个阶段其实基本上不需要人做什么事情，而且 Agent 的效率比人高得多，你只需要等着就好。唯一需要注意的就是在 Research 的过程中，我通常会告诉模型它拥有无限的预算和时间，尽可能充分地进行调研。另外，如果你的模型有推理深度的参数的话，我建议在这个阶段把它们全部调到 xhigh 的级别。虽然这会让过程变慢，但在这个阶段多烧一些 token、做好更好的规划、了解更多上下文，对后续的实现阶段会更有帮助。

实现阶段没什么特别好说的，反正我现在基本不会一行行去看 AI 的代码。我觉得在实现阶段唯一要注意的就是，要么你就让 AI 完全去做，要么你就完全自己做，千万别混着来，我目前是倾向于完全零人工干预的模式效果更好。

第四个阶段人就变得非常重要了，那就是测试和验收结果的阶段。其实在我个人和 AI 开发项目的过程中，我 90% 的时间和精力都花在了这个阶段：也就是如何评估 AI 的工作成果，我觉得在 Vibe Coding 时：There's a test, there's a feature，你只要知道如何评估和测试你要的东西，AI 就一定能把东西给你做出来。另外值得注意的是，AI 在实现过程中会自动帮你添加很多单元测试，但说实话，这些单元测试在微观层面基本都能通过，毕竟 AI 写这种局部代码时已经很难出 bug。

但 AI 不擅长的是集成测试、端到端测试。比如在开发一个 SQL 数据库时，哪怕每个细节的单元测试都没问题，但整合到一起时集成测试可能会出错。所以我在完成大目标前，我一定会先和 AI 一起做一个方便的集成测试框架，并提前准备好测试的基础设施，收集和生成一些现成集成测试的用例，尽量一键能运行那种，这样在开发阶段就能事半功倍，而且关于如何使用这些测试的基础设施的信息，我都会在正式开始前就固化在 agents.md 里，这样就不用每次沟通的时候都再告诉它该怎么测试了。

关于测试从哪来的问题，我自己的经验是你可以让 AI 帮你生成，但一定要告诉它一些生成的逻辑，标准和目的，另外就是千万不要把生成测试的 Context 和实际进行开发工作的 Agent 的 Context 混在一起。

第五个阶段是重构和拆分。我发现当前的 Coding Agent 在面对单一模块复杂度超过大约 5 万行代码之后，就开始很难在 1-shot 里把问题一次性解决掉（但反过来这也意味着，只要任务复杂度控制在这个阈值之下，在一个足够好的 first prompt 驱动下，很多事情确实可以做到 1-shot AC），Agent 通常不会主动去做项目结构和模块边界的治理，你要它把功能做出来，它恨不得把所有东西都写进几个几万行的大文件里，短期看似很快，长期就是债务爆炸。我自己在这个阶段的做法通常是先停下来，用自己的经验进行模块拆分，然后在新的架构下进行 1～2 轮的重构，之后又可以高并发度的进行开发了。

多 Agent 协同编程的一些实践

前面提到我现在使用 Coding Agent 的时候，通常不会只用一个，我自己的工作流会尽量让多个 Coding Agent 同时工作。这也是为什么有时候在一些项目上会花掉好几千美金，因为你必须把并发跑起来。当然，并发和吞吐是一方面，但另一方面我觉得让不同的 Agent 在不共享上下文的前提下互相 Review 工作，其实能显著提高质量。

这就像在管理研发团队时，你不会让同一个人既当运动员又当裁判。相当于 Agent A 写的代码交给 Agent B 来 Review，往往能发现一些 A 看不到的问题。通过这样的循环往复，你就会更有信心。

例如，我在实际工作中现在用得比较好的一个工作流是这样的：首先让 GPT-5.2 在 Codex 下生成多个功能的设计文档，做出详细的设计和规划，第一阶段把这些规划文档都保存下来。然后在第二阶段，依然用 Codex 根据这些需求文档一个一个去实现功能。在实现的过程中，就像我前面提到的那样，记录 To-Do、经验教训，并在接近完成的时候，在代码通过测试并准备提交之前停下，把当前的工作区交给另一个 ClaudeCode 或 OpenCode，在不提供上下文的情况下，让 ClaudeCode 来 Review 当前还未提交的代码，根据设计提出修改建议。然后再把这些建议发回给 Codex，让 Codex 来评论这些建议，如果有道理就修改代码。改完之后，再让 ClaudeCode (Opus 4.5) 那边再次 Review，直到双方都觉得代码已经写得很不错了，再提交到 Git 上，标记这个任务完成，更新知识库，然后进入下一个功能的开发。

另外在一个大型项目中我会同时开多个 Agent (in different Tmux) 并行开发多个功能，但我尽量让它们负责完全不同的模块。比如一个 Agent 修改内核代码，另一个 Agent 做前端界面，这样就能分开进行，如果你需要在一份代码上做一些彼此不太相关的工作时，可以利用 git 的 worktree 让多个 Agent 在不同的 git 分支上各自工作，这样也能快速提升吞吐量。

未来的软件公司和组织形态

未来的软件公司会是什么形态呢？反正从我自己的实践和与一些朋友的交流来看，至少在当下，团队中用 Coding Agent 的 token 的消耗呈现出一个非常符合二八定律的分布，也就是说，最头部的用 AI 用得最好的工程师，他们消耗的 token 可能比剩下 80% 的工程师加起来还要多，而且 Coding Agent 对于不同工程师产出（质量，吞吐）的增益是不一样的，这个方差非常大，也就是对于用的最好的一群人，他们的增幅可能是 10x，但是普通人可能也就是 10%，而且唯一的瓶颈是人工的 code review 和一些无法被自动化的线上运维工作（我觉得也很快了）而且这样的特点能够让这些头部的工程师在 AI 的协助下可以无边界的工作，也就是会有越来越多的 one-man army 出现，只是目前我认为和 token 消耗是正相关的，你能花掉多少 token，大致代表你能做得多好。

另外我发现一个很有趣的现象，同样是 10x 的工程师，他们各自的 Vibe Coding 工作流和最佳实践其实并不相同。也就意味着，两个顶尖的 Vibe Coder 是很难在一个项目中（的同一个模块）协作。这种工作方式更像是头狼带着一群狼群（Agents），在一片自己的领地里面耕耘，但是同一片领地里很难容纳两匹头狼，会造成 1+1 < 2。

在这样的组织形态下，我觉得传统意义上的“团队协作方式”会被重新定义。过去我们强调的是多人在同一个代码库、同一个模块里高频协作，通过评审、讨论、同步来达成共识；但在 Vibe Engineering 这种模式下，更有效的方式反而可能是强解耦的并行。管理者要做的是把问题切分成足够清晰、边界明确的“领地”，让每一个头部工程师带着自己的 Agent 群，在各自的领域里做到极致。

从管理的角度看，这其实是一个挺大的挑战。因为你不能再用统一流程、统一节奏去约束所有人。对顶尖的 Vibe Coder 来说，过多的流程和同步反而会显著拉低效率，甚至抵消 AI 带来的增益。管理者更像是在做“资源调度”和“冲突隔离”：确保不同头狼之间尽量少互相干扰，同时在必要的时候，能够通过清晰的接口、契约和测试来完成协作。

因为上面的种种，AI-Native 的研发组织其实很难自底向上从一个非 AI-Native 的组织中生长出来，因为大多数开发者面对变革的时候的第一反应其实并不是拥抱，而是回避和抵触，但是时代的进步不会因为个人的意志转移，只有主动拥抱和被动拥抱的区别。

大概就写到这里吧，总的来说，在这样一个大环境下，对个人而言意味着一场深刻的转变，就像我之前在朋友圈里提到的，我身边最好的工程师们有一些已经陷入了或多或少的存在主义危机。

但是作为具体的 Builder 的我来说是兴奋的，因为造物，在当下，门槛变低了许多，如果你能从造物中能获得成就感和找到人生的意义，那恭喜你，你活在一个最好的时代。但反过来，作为一个抽象的 “人” 来说，我又是悲观的，人类是否准备好面对这样的工具？以及这样工具带来的对于社会和整个人类文明的冲击？

我不知道。

闫俊杰在商汤敲钟前夕离开，创立了 MiniMax（上海希宇科技），也造就了全球从创立到 IPO 用时最短的 AI 企业——4 年，进程明显快于行业常态。

就在刚刚，1 月 9 日，MiniMax紧随其后挂牌上市，股票代码 00100。招股书显示，MiniMax 的 ToC 收入已经反超 ToB，这在中国大模型公司中极为罕见。

其招股书还透露了一堆硬核数据，截至 2025 年 9 月 30 日：

  • 累计个人用户：超过 2 亿

  • 覆盖 200+国家和地区

  • AI 原生产品 MAU：约 2760 万

  • 企业与开发者客户：超过 10 万家

在这次 IPO 中，Mini Max 计划发行约 2540 万股 H 股，开盘价 235.4 港元，截至上午 10:30，股价已飙升超 60%，市值超 820 亿港元（约合人民币 738 亿元）。

据富途证券数据，MiniMax 此次 IPO 超级火爆，公开发售部分的超额认购倍数高达 1209 倍，投资者通过保证金方式认购的金额累计超过 2533 亿港元。

资本市场为 MiniMax 的技术野心“买单”

在国内近年来涌现的一批 AI 独角兽中，唯二高频更新技术论文、投资开发者生态的，是 MiniMax 和 DeepSeek 背后的深度求索。

闫俊杰曾在各种场合明确表达： MiniMax 是一家技术驱动的公司。据招股书显示，MiniMax 最大的成本就是研发成本，为了在基础模型技术上集中注意力，海外版 App 甚至没有第一时间做英文化。投资人的评价大体也能回归到技术要素，即闫俊杰是一个真正对 AGI 有信仰的人，“他很真”。

这是除市场数据外，MiniMax 市值最明确的支点。

仅在 2025 年，MiniMax 已通过至少两篇公开科研论文系统阐述其大模型架构与推理优化方案，其核心成果包括 MiniMax-01，即基于 Lightning Attention 与 MoE 的超长上下文大模型；以及 MiniMax-M1，即针对推理计算效率进一步优化的模型版本。

相关论文不仅披露了核心机制，还在处理百万级 token 上下文和推理效率上提出可复现技术路径，而非简单参数展示。

回到 2024 年初，在稠密模型仍占主流的背景下，MiniMax 率先推出了中国首个混合专家系统（MoE）大模型 abab6——比 DeepSeek 火出圈 R1 早了约一整年。

在行业仍普遍依赖 Softmax Attention、并为其二次计算复杂度付出高昂算力成本时，MiniMax 开始在模型中大量引入自研的 Lightning Attention（线性注意力）。

具体做法，简单来说就是在每 8 层模型结构中，只保留 1 层传统注意力，其余 7 层改用线性注意力，从而把长上下文推理的计算压力“削薄”。

改动后的直接效果是：模型在面对超长文本、长代码或多轮复杂推理时，不再随着上下文变长而指数级变慢。

这套注意力设计与 MoE 架构叠加后，进一步放大了效率优势，使模型在保持推理能力的前提下，大幅提升了长文本、长代码和复杂任务场景下的计算效率。

相比智谱以 GLM 系列基座模型为核心，在 ToB 与 ToG 侧已跑出较为稳健盈利能力的路径；MiniMax 展现出的是另一种取向：模型更强调产业化落地，已在 ToC 端取得了不错的成果。

围绕自研大模型，MiniMax 已形成包括 MiniMax Agent、海螺 AI、MiniMax 语音、星野以及开放平台在内的产品矩阵。

同时在海外市场亦已有实质进展：其产品和服务已覆盖 200 多个国家和地区，累计触达超过 2.12 亿名个人用户，并服务超过 13 万家海外企业与开发者（包括订阅、API 调用等渠道）。

按 2024 年基于模型的收入计算，MiniMax 是全球第四大 pure-play 大模型技术公司，还是全球第十大大模型公司，覆盖文本、视觉、音频、视频的全模态模型体系。

在上市前的近一年内，MiniMax 完成了从 MoE 架构探索（abab 6 / 6.5）到基础大模型开源（MiniMax-01），再到高级推理模型（MiniMax-M1）的连续迭代。

以 MiniMax-01 系列为例，模型总参数规模已达数千亿量级，但单个 token 实际参与计算的参数仅为几十亿，使得模型可以在控制成本的前提下，原生支持百万级乃至更长的上下文窗口。

在 2025 年 12 月 23 日，MiniMax 还对外发布了最新旗舰级 Coding & Agent 模型 M2.1。

在衡量多语言软件工程能力的 Multi-SWE-bench 测试中，该模型在仅约 10B 激活参数的前提下取得 49.4%的成绩，超越了 Claude Sonnet 4.5 等国际顶尖竞品，拿下全球 SOTA。

M2.1 要补上的，是此前不少模型在工程能力上的短板——过去的模型在编写简单脚本或前端代码时尚可应付，但一旦进入后端工程、系统架构或底层逻辑层面，表现往往迅速失稳。

这个模型的关键变化在于，其能力边界首次延伸至更完整的后端开发规范。

这些技术实现背后，是一支极其年轻的团队。据每日经济新闻消息，截至 2025 年 9 月底，MiniMax 员工 385 人，平均年龄 29 岁，研发人员占比近 74%，董事会平均年龄 32 岁。

其核心团队由一批来自商汤科技、全球一流高校和顶级科研机构的技术骨干组成，以创始人闫俊杰为首，包括杨斌、周彧聪等联合创始人。

闫俊杰拥有东南大学、本科到中科院自动化所博士及清华博士后背景，曾担任商汤副总裁与研究院副院长。

杨斌具备加拿大博士及 Uber ATG 与国际初创工程经验；周彧聪则是商汤早期算法团队核心成员。

团队多数来自 AI 与深度学习前沿领域，在 NLP、语音、视觉、生成模型等方向拥有丰富经验和多项全球发明专利。

站在年轻团队另一面的，是 AI 投资界的“老炮”们。

早期有阿里、腾讯、红杉中国、高瓴、IDG、云启、米哈游等产业与风投参与；IPO 前夕，阿布扎比投资局、Mirae Asset、Aspex、易方达等长线机构接力。

尤其是阿里，持有的 MiniMax 股权占比还要大于在智谱的比重。连续两场 IPO 后，一场投资界和 AI 创业团队之间的化学反应和默契已经诞生。

上市之后，还需直面 Claude Code 等问题

需要指出的是，由商汤的 ToB/ToG 模式，转到如今的 ToC/ToB 模式，闫俊杰麾下的 MiniMax 还未实现整理盈利；至少想赢得全球 AICoding 市场，绕不开和 Claude Code 的直接竞争。

Claude Code 是一个面向真实软件工程的 Coding / Agent 模型，由 Anthropic 公司推出。该模型的重点是在 AI 生成代码以外，确保模型在工程约束下不失控，堪称 AICoding 神器。近日， Anthropic 宣布，Claude Code 上线仅 6 个月，已经创造了近 10 亿美元年化营收。

从公开信息看，MiniMax 并没有试图直接复刻 Claude Code 的路径，而是选择了另一种更偏效率驱动的技术路线。

MiniMax 在 Lightning Attention + MoE上的投入，本质上是在解决一个问题：如何在成本可控的前提下，把上下文和工程复杂度拉到“真实软件世界”的尺度。

对于 Coding 模型来说，长上下文不是加分项，而是入场券。 没有足够高效的注意力结构，就无法在真实代码库上长期运行 Agent。

M2.1 针对 Multi-SWE-bench 的表现，某种程度上正是在回应 Claude Code 的“主战场”——不是写某一段代码，而是完成跨语言、跨模块、带验证的软件工程任务。

这意味着 MiniMax 正在补的，并不是单点能力，而是：后端规范、工程一致性，和多语言协作能力，这正是 Claude Code 最难被替代的部分。

MiniMax 若想在全球市场正面竞争，最终比拼的也不会只是 Benchmark，而是 Agent 是否可控、错误是否可解释，以及是否敢被放进 CI / CD 流程。

从招股书来看，MiniMax 的研发投入在过去三年中持续攀升：

2022 年为 1060 万美元，2023 年增至 7000 万美元，2024 年进一步扩大至 1.89 亿美元；截至 2024 年及 2025 年 9 月 30 日止的九个月，研发开支分别达到 1.387 亿美元和 1.803 亿美元。相关投入主要用于模型训练过程中产生的云服务费用。

另外，在头部云厂商和海外独角兽的夹击之下，MiniMax 同时承受着 ToB 与 ToC 两个市场的竞争压力。

模型技术仍在快速演进，这场拼性能、拼效率、拼工程化的技术马拉松还在继续；上市，只是把比赛带入了下一个赛段。

在一次采访中，闫俊杰提到，MiniMax 确实放弃过一些 ToB 订单，是基于对自身交付能力的判断，避免分散注意力。那么，如果 ToB 领域的工程化交付，当下还不是 MiniMax 的“长板”，短期来看，就只剩“技术登顶”一条路能帮 MiniMax 走到终局。

闫俊杰说他在 Dota2 游戏里爱玩小精灵，因为这个英雄实现过从五号位（辅助）转型成为一号位（核心），最终主宰比赛。

目前看来，对于 MiniMax 而言情况类似，能否在 Benchmark 上五转一，保持模型能力长期领先，是上市后走向 AGI 的关键。

参考链接：

https://www1.hkexnews.hk/listedco/listconews/sehk/2025/1231/2025123100026_c.pdf

https://huggingface.co/MiniMaxAI/MiniMax-M2.1?utm_source