如何理解MiniMax股价创历史新高？拆解国产大模型技术底座
MiniMax股价创历史新高这件事，我是从一个做企业知识库的朋友那儿听说的——他那天在群里问的不是"能买吗"，而是"它家API这个价格还能撑多久"。这个反应其实挺说明问题的。资本市场看的是叙事，但写代码的人看的是单位token成本，这两个视角如果指向同一家公司，通常意味着技术曲线和商业曲线真的对齐了一次。
我不想在这篇文章里讨论K线。想聊的是更硬的那一层：一家2021年底才成立的公司，凭什么在最烧钱的大模型赛道里把成本结构做出差异，进而让市场愿意给出高预期。 答案藏在三份技术报告和两次模型切换的选择里。
核心结论摘要：MiniMax股价创历史新高的底层支撑不是营销叙事，而是三条可验证的技术曲线——线性注意力把长上下文成本压进可商用区间、MoE稀疏激活把单位推理成本降了一个量级、CISPO让强化学习后训练不再烧钱。三件事同时成立，"低价高能力"的商业模式才跑得通。
先把MiniMax的技术家底摸清楚
很多人对这家公司的印象还停留在"Talkie做AI陪伴"的阶段，那是2023年的认知了。创始人闫俊杰出自商汤，团队从2022年的Glow、2023年的abab系列一路迭代到今天的M系列，模型路线其实换过一次大方向。
真正的转折点在2025年1月。那份MiniMax-01技术报告（arXiv:2501.08313，2025年1月15日）把架构细节公开得很彻底，也是从这版开始，MiniMax正式把"长上下文"当成核心卖点，而不是跟着别人卷榜单分数。
下面这张表是我按官方技术报告和Hugging Face模型卡整理的，具体规格以官方最新公布为准：
| 模型 | 发布时间 | 总参数 | 激活参数 | 上下文窗口 | 主要定位 | |---|---|---|---|---|---| | MiniMax-Text-01 | 2025年1月 | 456B | 45.9B | 推理100万token（训练时达400万） | 通用文本基座 | | MiniMax-M1 | 2025年6月 | 456B | 45.9B | 100万token | 开源推理模型 | | MiniMax-M2 | 2025年10月 | 230B | 10B | 约20万token | Agent与代码场景 |
看这张表有个细节容易被忽略：从M1到M2，总参数砍了一半，激活参数只剩不到四分之一。这不是"缩水"，方向变了。
Lightning Attention：长上下文为什么突然变得便宜了
传统Transformer的注意力机制有个绕不开的账：序列长度翻倍，注意力矩阵的计算量翻四倍。处理一份50页的合同还行，处理一整套IPO招股书（动辄几百页）就开始肉疼了。检索增强（RAG）能缓解一部分，但切片会丢跨段落的逻辑关联，做合同比对、代码库级理解这类任务时，丢失的恰恰是最关键的信息。
MiniMax的解法是混合注意力架构：每8层Transformer里，7层用线性注意力（Lightning Attention），只留1层标准的softmax注意力。
为什么不全换？因为纯线性注意力在近距离依赖上精度会掉。保留那1/8的softmax层，等于在便宜的全局视野上补了一层"精确聚焦"。这个取舍思路，我觉得比单纯堆参数聪明得多。
线性注意力的核心是把注意力从"每对token互相看"改成"维护一个压缩状态"。下面是我写的简化版分块实现，用来理解递推逻辑，省略了归一化和数值稳定化处理，不能直接用于生产：
import torch
def lightning_attention_chunkwise(q, k, v, block_size=128): """ 线性注意力的分块递推实现（教学用简化版） q, k, v 形状: [batch, heads, seq_len, dim] 关键点：维护 KV 累计状态，把 O(n^2) 的注意力矩阵消掉 """ b, h, n, d = q.shape out = torch.zeros_like(v)
全局 KV 状态，形状只和 head_dim、value_dim 有关，与序列长度无关
kv_state = torch.zeros(b, h, d, v.shape[-1], device=q.device)
for start in range(0, n, block_size): end = min(start + block_size, n) q_blk, k_blk, v_blk = q[:, :, start:end], k[:, :, start:end], v[:, :, start:end]
1) 块与历史状态的交互：承担长距离信息，成本与块大小线性相关
intra = q_blk @ kv_state
2) 块内局部精确注意力：保住近距离依赖，用下三角掩码防止看到未来
local = (q_blk @ k_blk.transpose(-1, -2)).tril() @ v_blk
out[:, :, start:end] = intra + local
3) 更新状态：这一步的显存占用是常数级
kv_state = kv_state + k_blk.transpose(-1, -2) @ v_blk
return out
按MiniMax-01技术报告里的数据，在40万token这个量级的输入上，这套架构的注意力计算量比同规模纯softmax方案低了一个数量级——这就是"100万token上下文还能按合理价格卖"的技术前提。根据该报告披露的内容，400万token的训练上下文和100万token的推理上下文是在同一套架构上实现的，没有靠外挂检索模块硬撑。
坦白讲，我第一次读到"100万token"这个数字时是怀疑的，因为2024年喊这个口号的厂商不少，真正能在百万级上下文里保持"大海捞针"准确率的没几个。后来我在一个法律文书比对的小项目里实测，把两份合计约80万token的协议塞进去做条款差异定位，返回结果基本可用，偶尔漏掉几处措辞级差异，但人工复核的成本已经比原来低很多了。这个体验对我来说比任何榜单分数都有说服力。
M1到M2：参数减半、能力反升的工程逻辑
如果说长上下文解决的是"能读多少"，那M1和M2解决的是"读完之后能不能干活"。
M1是MiniMax第一个开源的大规模推理模型，同期的技术报告（arXiv:2506.13585，2025年6月）里有个我印象很深的数据：完整的强化学习阶段只用512张H800训练约三周，按当时的算力租赁价格折算，成本约为53.5万美元。 在动辄千万美元起步的后训练叙事里，这个数字相当克制。
省钱的功夫下在强化学习算法上。M1论文提出了CISPO（Clipped Importance Sampling Policy Optimization），简单说就是只裁剪重要性采样权重，不裁剪整个token的梯度贡献。GRPO、DAPO那类方法在处理超长序列时，少数高权重token会主导整个梯度更新，训练容易震荡；CISPO把这个问题拆开了，长上下文场景下的稳定性明显更好。这也是为什么M1能在100万token上下文下做推理强化。
到了2025年10月开源的M2，思路又往前走了一步。总参数230B、激活10B，官方把它定位成面向Agent和代码执行场景的模型。参数砍掉一半多，是因为M2引入了一种"交错思考"（interleaved thinking）的机制——模型在调用工具、观察结果、再决策的循环中保持推理连续性，而不是每次工具调用都重新起一段思考。这类任务的瓶颈通常在交互轮次和上下文管理，不在骨干网络的绝对容量。
有意思的是市场对M2的反应。当时不少开发者第一反应是"激活10B，能行吗"，结果官方公布的SWE-bench Verified成绩接近闭源头部模型，开源圈讨论的重点才从"参数够不够"转向"每百万token花多少钱"。这个舆论转向本身，恰好解释了为什么MiniMax的估值逻辑和别家不一样。
落到实操：这套技术栈怎么用进你的项目
聊完原理，说点能直接上手的。我把实践建议按场景拆成三块：
场景一：超长文档处理（合同、财报、代码库）
不要再用传统的"切片+向量检索"硬扛了。百万级上下文的正确用法是分层：先用长上下文模型做一次全局扫描，定位关键段落索引，再针对具体段落做细粒度抽取。这样单次调用的token量大，但总调用次数少，