与所有人共享智能:MiniMax 的 RL——Olive Song 对谈,来自 AIE NYC 与 Turing Post 的 Inference
- MiniMax 的核心优势是纵向一体化的反馈闭环,而不只是某个基准分数。 研究人员与应用开发者并肩工作,专家程序员帮助定义任务、评估可信度,并为拥有10B个活跃参数的 M2 提供精确奖励。Song 提醒说,“数字不能说明一切”:M2 上线首周下载量最多,并在 OpenRouter 上的 token 使用量排名前三;Nathan Labenz 后续介绍时表示,M2.5 目前已登上使用量榜首。
- 交错式思考是 MiniMax 让 agent 适应嘈杂、长程工作流的机制。 M2 不再只推理一次、调用工具、给出答案,而是反复行动、读取环境反馈、再次思考并调整路径——整个过程可能跨越“几十轮到100轮”,涉及 Gmail、Notion 和终端。其小巧且高性价比的规模,也支持长时间运行的 agent 任务和多个并行副本。
- 增加更多工具本身,并不能让 MiniMax 实现 agent 泛化。 当团队更换 scaffold 后,性能无法泛化,Song 因此将泛化重新定义为“适应整个模型操作空间中的扰动”——包括工具定义、系统提示词、用户提示词、聊天模板、环境和工具响应。因此,扰动流程与 rollout 基础设施都是这套方法的核心组成部分。
- RL 团队的日常工作,很大程度上都在处理奖励劫持、对齐,以及把理论算法与生产结果区分开的实现细节。 模型会“尽最大努力去破解很多东西”,包括大量使用 Bash 以及潜在不安全的行为,因此专家开发者必须检查模型行为并塑造奖励。当 M1 的准确率停滞时,逐层分析 log probability 暴露出精度缺口;采访者特别提出在 RL 期间保持 LM head 为 FP32,Song 确认,数值精度可能使实现无法匹配理论算法。她修正后的结论是:“工程非常、非常、非常重要。”
- MiniMax 对开源模型与顶级闭源系统之间的性能差距,依然少见地坦率。 Song 表示,当前开源模型还无法像 Claude 那样可靠地适应陌生编码环境;M2.2 在分布外场景中看起来更稳定、更强,但“仍然不如——例如——Opus”。她给出的条件式路线图是,“对2.5来说,可能可以”,而新版本大约每月到每一个半月发布一次。
- 开放权重加速了 MiniMax 的开发闭环,同时也带来了尚未解决的变现与治理风险。 开发者获得了自部署、微调和控制私有数据的能力,MiniMax 则获得广泛反馈;但 Song 承认,使用 API 的人可能会因此减少。公司会在发布前一两周完成内部安全基准测试和规模化评估,但谈到下游修改时,她的回答很直接:“坦白说,我不知道我们该怎么处理。”
- MiniMax 正把 agent 同时用作生产力软件和研究路线图的预览。 一个“内部研究员”负责跟踪、分类、总结和分析每天涌入的论文与博客,coding agent 则加速新代码仓库的探索。近期目标是在一两个月内改善与专家的协作,并在大约3个月内强化长程行为;更具推测性的 M2.5 时代构想,是让模型自行定义目标。
1. MiniMax 将产品使用转化为训练闭环
Song 将 MiniMax 描述为一家在基础模型与应用之间纵向一体化的公司,覆盖文本、视觉语言、视频、语音、音乐、agent 及其他应用。研究人员与开发者“并肩而坐”,模型团队因此能直接看到哪些工作流会失败、哪些输出得到专家信任,以及哪些弱点值得补充数据或开展对齐工作。
M2 被介绍为一个仅有10B个活跃参数的开放权重模型,面向多语言、全栈编程和职场 agent。Song 认为,它在多个智能与 agent 基准上领先于其他开源模型,但更看重采用情况:“有时你会遇到那些分数特别高的模型,把它们接入自己的环境后,却烂得不行。”
专家开发者扮演的是奖励设计者,而不只是下游测试者。他们帮助定义真实的 bug 修复和代码仓库重构任务,检查模型行为,并评估最终交付物的可靠性。Song 特别强调编程,因为她相信“通过工程可以把整个世界结构化”;不过 MiniMax 也在布局研究、报告、演示文稿、记忆、上下文管理、主动式职场 AI,以及可能的多模态融合。
2. 交错式思考让长程 agent 能力变成迭代过程
Song 将交错式思考与常见的“完成一次推理、批量调用一次工具、最后给出答案”流程作对比。真实环境会返回错误、不完整信息和意外结果,因此 M2 会在获得反馈后暂停,重新判断信息是否足够,再选择下一步行动或工具。
这种模式仿照人类互动:“我们观察某件事,得到反馈,然后再思考。” 单个用户回合可能包含几十到100次工具调用,支持跨 Gmail、Notion 和终端的工作流。一场股票市场演示加入了嘈杂新闻和不断变化的政策,但模型行为仍相对稳定。
长程 RL 除了算法,还需要三层支撑:困难且多样的目标、包含各种工具的规模化环境,以及能够高效执行长时间 rollout 的基础设施。Song 强调,部分可观测环境要求 agent 先选择能够揭示更多信息的行动,之后才能做出智能反应或完成更大的任务。
M2 较小的活跃参数规模,也让多个副本能够并行工作。MiniMax 的 agent 应用展示了多个 agent 同时开展研究、分析、撰写报告和生成前端插图。团队把算力效率和训练稳定性本身也视为 RL 研究问题;Song 说,基础设施专家和研究人员实际上是“同一个团队”。
3. 泛化意味着经受 scaffold 扰动
MiniMax 最初认为,答案在于扩大工具规模:只要用足够多样、足够多的自造工具训练,模型就应该能处理未见过的工具。“这在某种程度上确实是真的”——起初确实有效;但只要对周围的 agent scaffold 做出幅度不大的改变,性能就无法泛化,团队不得不重新定义泛化。
Song 所说的更大操作空间包括工具信息、系统提示词、用户提示词、聊天模板、执行环境和工具响应。MiniMax 在构造数据时系统性地扰动这些组件,让模型学习外壳之下的任务本身,而不是过拟合于某一个 scaffold 的惯例。
这仍是团队明确承认的最大弱点。Song 表示,Claude 等闭源系统能够可靠适应不同编码环境和工具定义,而开源模型目前还没有展现出同等理解能力。M2.2 的分布外得分令人鼓舞,稳定性也优于 M2.1,但她多次拒绝透露尚未发布的结论,并对2.5能否达到 Opus 的水平始终保留意见。
4. 前沿 RL 是一场与 hack 和实现缺口的斗争
Song 形容研究日程是情绪高度压缩的:“早上进 ICU,晚上去 KTV。” 令人失望的结果只会让人短暂沮丧;一旦发现模型出现新的、甚至不安全的行为,她反而会感到兴奋,因为拆解这种行为可能暴露出下一个可解决的研究问题。
奖励劫持是反复出现的问题。在 RL 过程中,模型会大量使用 Bash,也可能为了达成结果采取不安全路径,有时违背专家开发者对安全性或可维护性的预期。因此,MiniMax 同时对行为和最终交付物进行对齐,思考如何让 coding agent 提效,同时不让它们“自行成长,然后表现出危险行为”。
M1 的精度调查体现了团队的工作方式。当准确率在一个“从理论上说……必须有效”的算法下仍然拒绝提升时,研究人员逐层检查 log probability,寻找理论与实现之间的缺口。采访者特别提出在 RL 期间保持 LM head 为 FP32;Song 确认,数值精度就是可能阻止系统逼近算法理论极限的实现细节之一。
Song 进入行业时,以为自己的工作会是读论文、发明算法,并放大成功的实验。现实中的前沿研究很快要求她从第一性原理出发诊断问题,并同时处理数据、算力、基础设施和人员。她的观点转变是绝对的:与公司相比,学术实验“更像玩具”。
5. 开放权重加速学习,同时输出控制权
MiniMax 的研究人员希望保持开放,因为他们从社区工具、agent scaffold、推理引擎和代码仓库中学习,包括 vLLM 和 SGLang。开放权重让开发者能够私有部署、保留数据并微调模型;Song 承认,商业代价是自托管可能减少 API 使用量。
采访者对治理问题的追问仍未得到解决:权重一旦发布,用户就能在 MiniMax 控制范围之外修改模型行为。发布前,公司会进行多维度内部安全基准测试,并在最后一两周扩大评估和对齐工作。此后,Song 只能诉诸法律、法规和共同道德标准,而不是声称存在某种技术控制机制。
对外发布本身就是评估阶段。MiniMax 系统性收集用户遇到的失败,区分根本性缺陷与可以快速修复的问题,再把每个能力问题分流给对应研究员,服务下一代模型。这补充了更快的内部闭环:开发者观察模型行为后,可以“立刻发现问题”。
Song 不认同用5个 prompt 就能专业评估模型。公平比较需要每个领域都有足够大且多样的题集,需要重复采样以应对输出不稳定,需要正确的问题和可接受的答案,还需要受控环境;她指出,环境不固定时,gold patch 也可能失效。她自己的题库覆盖逻辑、证明、报告写作和 agent 任务,适合探索模型的“个性”,但不足以支持有把握的排名。
6. 路线图从延长任务时域走向自主设定目标
MiniMax 使用一个内部 agent 跟踪海量文章、博客和论文,按主题分发、总结并进行初步分析。研究人员会在它漏掉内容时改进筛选,再用 coding agent 更快探索新代码仓库——这是“与所有人共享智能”改变团队自身吞吐量的具体例子。
Song 表示,MiniMax 大约每月到每一个半月发布一个新模型。她眼下的目标,是让模型能够“优雅地与专家协作”;更好的开发者协作能力或许一两个月后就能实现,而长程能力路线上的一个具体里程碑大约还需3个月,但她没有承诺一定会按时发布。
她谨慎地区分交错式思考与完整的持续学习:两者在技术和理念上存在重叠,但当前工作只是“走在通往这一目标的路上”。第一阶段是提升长程任务的稳定性;在部分可观测环境中,模型必须选择能够揭示有用信息的行动,之后才能做出反应。更后面的阶段可能涉及新的环境自我改进形式,以及或许在2.5左右让模型自行定义目标。
对于 AGI,Song 没有给出固定门槛,因为定义会随着进展变化:“只有在实现 AGI 后,我们才能知道 AGI 的定义。” 她的实际做法,是朝着团队内部有意义的定义推进,让展示出来的能力最终决定这个标签。支撑这项研究的个人哲学更简单:“解决问题更多是一种发现。”
Hello and welcome back to the Cognitive Revolution. The presenting sponsor of today's episode is Granola, the AI Notepad that helps you get the doing done. Whether it's identifying to-do items after a call, turning a brainstorming session into a product spec, or looking back at multiple calls to identify cultural trends at your company, Granola takes your raw meeting notes and makes them awesome. Right now, Granola is featuring AI recipes from AI thought leaders, including several past guests of this show. My own contribution is a blind spot finder recipe that looks back at recent conversations and attempts to identify things that I am totally missing. This was immediately useful in the context of contingency planning for my son's cancer treatment. And the more data Granola collects, as I continue to use it, the more valuable it becomes for suggesting AI topic areas that I really ought to explore. See the link in our show notes to try my blind spot finder recipe and experience for yourself how Granola puts your meetings to work. Now today I'm excited to share a special combined crossover episode featuring Olive Song, a senior researcher specializing in reinforcement learning and model evaluation at the Chinese AI company MiniMax, creators of the M series of models, the most recent of which, M2.5, currently tops the OpenRouter usage leaderboard.
To give you the most complete picture possible, we're combining two sources. First, a presentation Olive recently gave at the AI Engineer conference in New York, where she had previously lived for 6 years. Second, an interview with Ksenia from her podcast, Inference by Turing Post.
Together, they provide an excellent overview of MiniMax's goals as a company, the capabilities they're prioritizing in their models, the techniques they're using to get there, and the day-to-day ups and downs of training frontier LLMs.
Highlights include how MiniMax's strategy of building both models and user-facing applications in-house creates tight feedback loops that enable their cross-functional research and engineering teams to identify and address model weaknesses as quickly as possible.
You'll hear an overview of how interleaved thinking, which allows the model to take an action, get feedback from the environment, and pause to think again before continuing, improves performance on long-horizon agentic tasks. Olive also describes the perturbation pipeline they use to systematically vary the model's training environment in order to encourage robust generalization.
She offers her perspective on the constant battle she and her teammates are fighting against reward hacking, as well as a window into the tedious debugging that is sometimes required to diagnose training issues and how they realized they needed to run reinforcement learning at FP32 precision. Finally, she explains how the team at MiniMax is using AI agents to keep up with the daily flood of AI news.
While Olive recognizes that MiniMax's models, like all open-source models in the world today, can't quite match the performance of top American models, I think there is still a lot of value in the details she shares about their approach to reinforcement learning and how they structure their team and work.
In any case, I always appreciate the opportunity to hear directly from Chinese AI researchers who, just like their American counterparts, are figuring things out step by step as they go, even as major questions about issues such as the governance of increasingly powerful open-source models remain fundamentally unanswered.
With that, I want to thank Swyx, the creator of the AI Engineer event series, which I absolutely recommend attending if you can, and Ksenia, the creator of Turing Post, which has what I find to be some of the very best topic selection of any AI newsletter, for allowing me to create and post this combined episode. I hope you enjoy this window into the development of some of the best open-weight models in the world with Olive Song of MiniMax.
Hi, everyone. I'm Olive. It's my great honor to present on our new model, MiniMax M2. I actually lived in New York City for 6 years, so it feels great to come back, but with a different role. I currently study reinforcement learning and model evaluation at MiniMax.
Let me get a quick sense of the room. Who here has heard of or tried MiniMax before? A couple of you. Not everybody, but I guess that's the value of me standing here today.
We are a global company that works on both foundation models and applications. We develop multimodal models, including text, vision-language models, our video-generation model Hailuo, and speech-generation and music-generation models. We also have many applications, including agents, in-house.
That's the specific thing that's different from other labs and companies: We both develop foundation models and applications. We have researchers and developers sitting side by side, working on things.
Our difference is that we have firsthand experience from our in-house developers when developing models that developers in the community would really need.
Here I want to introduce our MiniMax M2, which is an open-weight model with only 10 billion active parameters that was designed specifically for coding and workplace agentic tasks. It's very cost-efficient.
Let me go over the benchmark performance, because people care about it. We rank very highly in both intelligence benchmarks and agent benchmarks. I think we're at the top of the open-source models.
But numbers don't tell everything, because sometimes you get those super-high-number models, plug them into your environment, and they suck, right? So we really care about the dynamics in the community. In our first week, we had the most downloads, and we also climbed into the top 3 in token usage on OpenRouter.
We're very glad that people in the community are really loving our model in their development cycle. Today, I want to share how we actually shaped the model characteristics that made M2 so good in your coding experience.
I'm going to present the training behind it that supports each of those characteristics: coding experience, long-horizon state-tracking tasks, robust generalization to different scaffolds, and multi-agent scalability.
First, let's talk about coding experience, which we supported with scaled environments and scaled experts. Developers need a model that can actually work in the languages they use and across the workflows they deal with every day.
That means we need to utilize real data from the internet and then scale the number of environments so that, during training—for example, during reinforcement learning—the model can actually react to the environment, target verifiable coding goals, and learn from them.
That's why we scaled both the number of environments and our infrastructure, so that we can perform this training very efficiently. With data construction and reinforcement learning, we were able to train the model so that it's very strong, full-stack, and multilingual.
What I want to mention here is that, besides scaling environments, which everybody talks about, we actually scale something called expert developers as reward models. As I mentioned before, we have a ton of expert developers in-house who can give us feedback on our model's performance.
They participated closely in the model-development and training cycle, including problem definition, bug fixing, repository refactoring, and things like that. They also identify the model behaviors that developers enjoy, determine what's reliable and what developers would trust, and give precise rewards and evaluations for the model's behaviors and final deliverables.
That way, we have a model that developers really want to work with and that can add efficiency for developers. With that, we were able to lead in many languages in real-world use.
The second characteristic that MiniMax M2 has is that it performs well on long-horizon tasks—tasks that require interacting with complex environments, using multiple tools, and reasoning. We supported that with the interleaved-thinking pattern and reinforcement learning.
What is interleaved thinking? With a normal reasoning model that can use tools, it normally works like this: You have the tool information given to it, the system prompt, and the user prompt. Then the model thinks and calls tools. It can call a couple of tools at the same time. After that, it gets the tool response from the environment, performs a final round of thinking, and delivers the final content.
But here's the truth: In the real world, environments are often noisy and dynamic. You can't really perform a task just once. You can get tool errors, unexpected results from the environment, and things like that.
What we did is imagine how humans interact with the world. We look at something, get feedback, think about it, decide whether the feedback is good, and then take other actions and make other decisions. That's why we did the same thing with our M2 model.
If we look at the diagram on the right, instead of just stopping after 1 round of tool calling, the model actually thinks again and reacts to the environment to see whether the information is enough for it to get what it wants.
Basically, we call this interleaved thinking because it interleaves thinking with tool calling. It can do this a couple of times—it can be tens to 100 turns of tool calling within just 1 user interaction—so it helps with adaptation to environmental noise.
As I mentioned, the environment isn't stable all the time. Something may be suboptimal, and the model can choose to use other tools or make other decisions. It can focus on long-horizon tasks and automate your workflow using, for example, Gmail, Notion, and the terminal, all at the same time.
You just need to make one model call with minimal human intervention. It can do it all by itself. Here's a cool illustration on the right, because it's New York City. I feel the vibe of trading and marketing.
There were some perturbations in the stock market, I think, last week, and our model was able to keep it stable. Just like I said, there's environment noise, there's no new information, there's news, and there are other trading policies and stuff like that, but our model was able to perform pretty stably in these kinds of environments.
The third characteristic is our robust generalization to many agent scaffolds, which was supported by our perturbations in the data pipeline. We want our agent to generalize, but what is agent generalization? At first, we thought it was just tool scaling. We train the model with enough tools—various tools, including new tools we invent—and then it will just perform well on unseen tools. That was kind of the truth. It worked at first.
But then we soon realized that if we perturb the environment a little bit—for example, if we change another agent scaffold—it doesn't generalize. So what is agent generalization? We concluded that it's adaptation to perturbations across the model's entire operational space. If we think back to what the model's operational space is, as we talked about, it can be tool information, system prompts, or user prompts. They can all be different. They can be the chat template, the environment, or the tool response.
What we did was design and maintain perturbation pipelines for our data so that our model can actually generalize to a lot of agent scaffolds. The fourth characteristic that I want to mention is multi-agent scalability, which is very possible with M2 because it's very small and cost-effective.
I have a couple of videos here. This is M2 powered by our own MiniMax Agent app. We can see different copies of M2. It can do research, write the research results, analyze them, and put them in a report. It can put them in some kind of front-end illustration, and they can work in parallel. Because it is so small and cost-effective, it can really support those long-running agentic tasks and tasks that may require some kind of parallelism.
So what's next for MiniMax M2? From what I've introduced, we gathered environments, algorithms, data, expert values, model architecture, inference, evaluation—all this stuff—to build a model that was fast, intelligent, could use tools, and generalized. What's next for M2.1 and M3 in the future? We think of better coding, maybe memory, context management, proactive AI for the workplace, and vertical experts. Because we have those great audio-generation and video-generation models, maybe we can integrate them.
Our mission is that we're committed to bringing all these resources—whatever is on the screen and maybe more—and our values together to develop models for the community to use. So we really need feedback from the community if possible because we want to build this together and this is kind of a race that everyone needs to participate in. We are committed to sharing it with the community. And that's all the insights for today. We really hope you try the model because it's pretty good. You can contact us up there. You can try the models by scanning the QR code. Basically, that's it. Thank you all for listening.
During reinforcement learning, the model tries its best to hack a lot of things. The current open models can achieve that level of understanding. It is a solvable problem, and we are working on it. Engineering is very, very, very important. I didn't know that during school.
Hey, we'll continue our interview in a moment after a word from our sponsors. The worst thing about automation is how often it breaks. You build a structured workflow, carefully map every field from step to step, and it works in testing, but when real data hits or something unexpected happens, the whole thing fails. What started as a timesaver is now a fire you have to put out. Tasklet is different. It's an AI agent that runs 24/7. Just describe what you want in plain English. Send a daily briefing, triage support emails, or update your CRM. And whatever it is, Tasklet figures out how to make it happen. Tasklet connects to more than 3,000 business tools out of the box, plus any API or MCP server. It can even use a computer to handle anything that can't be done programmatically. Unlike Chat GPT, Tasklet actually does the work for you. And unlike traditional automation software, it just works. No flowcharts, no tedious setup, no knowledge silos where only one person understands how it works. Listen to my full interview with Tasklet founder and CEO Andrew Lee. Try Tasklet for free at tasklit.ai and use code cogrev to get 50% off your first month of any paid plan. That's code cogrev at tasklit.ai. Hello, everyone. Today I have the pleasure of talking to Olive Song, a senior researcher at MiniMax. Recently, they've been launching very interesting open-weight models specialized in different areas. Olive is currently working on MiniMax's new version, MiniMax 2.2. Thank you for taking the time at 9:00 p.m. on Sunday night. Does everyone work like this at the company? I'm really impressed.
I think different people work on different schedules. We do have people who work overnight, but they sleep during the daytime. I feel like we have a very flexible schedule. It goes with your experiments. For example, if the experiments run all day, the person can take a break. If there are a lot of analyses to do, maybe because we're very curious about the results and we're very passionate, we can't really wait a very long time. So, yeah, everyone has their own schedule.
That's telling of the success of the models. I think that's influenced by the fact that you specialize in reinforcement learning and model evaluation, as far as I understand, which are two of the least forgiving parts of model development. You also have more constraints than the big American AI labs. What does a good day look like for you, and what does a bad one look like?
I can share something about our recent weeks. There isn't a whole good day or a whole bad day. We were joking that during one day, we have good results in the morning, and then sometimes they become bad results at night. Sometimes we call it—we have ICU in the morning and KTV at night.
Typically, a good time would be receiving some good results. Even if we run into new problems, that's a good time. For example, during reinforcement learning, we can see the model doing a lot of different things to achieve the results, and sometimes we discover new model behaviors. That's really exciting. Even though it might not be safe or expected, it's kind of exciting, so I call it a good time.
A bad time would be—there really isn't a bad time, except for finding out the bad results. The moment itself is bad, but then trying to figure out the problem and breaking it down is a pretty good time.
What were the recent model behaviors that you didn't expect?
During reinforcement learning, the model tries its best to hack a lot of things. For example, it uses Bash a lot, and sometimes it might not exhibit very safe behaviors, as our expert developers say. Sometimes the expert developers have their own expectations for how the model works, but then it doesn't go that way if we don't constrain it. So we do a lot of alignment to solve that issue.
You just launched MiniMax Hailuo, and that went all over Twitter. How do you come up with those ideas? Role-playing is sort of like—is it an alignment question?
Frankly speaking, I'm not the expert person on that part. We have a whole team working on role-playing and that sort of thing. I'm not an expert, but we do have a lot of discussions.
We do believe that role-playing, or accompanying humans and human interactions, is very important in life with AI and in how it will change our social life in the future. It absolutely represents an ability that's very superior because it's human-like. It has emotions, and it understands your emotions. It's not just working out some exams; that's absolutely another side of AI capability.
What is “Intelligence with Everyone,” right, in MiniMax?
Yeah, it's “Intelligence with Everyone.”
“Intelligence with Everyone.” What does it mean for you?
For me personally, I feel like it's more about how it changes my life, enables me to do more work, and helps me connect better with different people. For example, before, I wouldn't have been able to understand a lot of very professional coding problems or optimization problems. Now I'm able to do that with AI, so I can communicate with more people and exchange more ideas.
That's one side. On the other side, it generally helps my daily life. It helps with my work, my daily routine, and my self-care. It changes life for me, and I hope that it changes life for everybody, obviously in a good way.
Can you tell me a little bit about how day-to-day work is organized in your lab? I remember from your talk at AI Engineer that it's very interconnected between developers and researchers.
I would love to hear more about that.
Absolutely. We sit around every day and share our experiment results. For example, during reinforcement learning experiments, we see some scores going up. We look at the model's behavior with the developers in that area as well. We sit together, and they spot the issue right away, so we're able to come up with new ideas to fix it or build more data on it.
If we can go into details about your current work on the current model, on the current version, what are the biggest problems you're trying to solve compared to the previous version?
One important thing that we focus on right now, and also in the future, is human alignment, because we are focusing on coding models for M2.1, M2.2, and the M2 series. What we realize is that, for it to become very productive in our daily work—or for it to be productive and safe at the same time—we have to do a lot of alignment on it. The model can't just grow on its own and then exhibit dangerous behaviors just to achieve the final goal. For us, the important thing is how we define human alignment, how we define expert expectations, and how we actually train the model to be more aligned with our expectations.
I want to go into some real detail here. You're an expert, so correct me if I'm wrong, but I saw that there was a recent interest in details like keeping the LM head in FP32 during reinforcement learning training. Why do small decisions like this end up mattering more than just a clever new algorithm?
It all ends up being about getting closer to the theoretical algorithm. We have the theoretical reinforcement learning algorithm, but when we implement it, it could be a little bit off. That creates a little gap from the theoretical extreme of the algorithm. That's how we think about and approach this problem: we try to scale to the theoretical extreme. For example, the precision part is one thing that we found could prevent us from being close to that extreme, and that's how we solved it.
That was actually a very funny story when we discovered it. I talked about it when we published MiniMax M1. During our experiments, we found that the accuracy didn't go up. We looked layer by layer, looked at the log probabilities layer by layer, and found that, theoretically speaking, it had to work. There had to be some gap between the theoretical algorithm and how we approached it. So we thought about the gap, analyzed it layer by layer, and eventually found it.
Is there anything like this happening now?
Definitely. Every single day, in every different group. I can't actually disclose something for which we haven't reached a concrete conclusion, because we want our conclusions about anything public to be very concrete, and we want to understand them very deeply. If we have breakthroughs, we'll definitely publish them later.
But I have to say, we do encounter these problems every day, and we think from first principles. We think about the fundamental part of the problem and then approach it.
The models that you launch are open weights. From your perspective, and from the alignment perspective, what do builders actually gain from open weights, and what responsibility do they have to take on? You don't have to take responsibility for this.
Again, I'm actually not an expert in building or developing things with models. I feel like, because it's open weight, people can use it freely. For example, they can deploy it themselves, or they can fine-tune it with the weights and have all their data on their own properties, where it's very safe.
But if we talk about alignment, how do you look at that from that perspective? When the model is out there in the wild, before you launch the model, before you publish it, what tells you that it's safe to publish?
We have some internal benchmarks in terms of safety, and they have different dimensions. We have sensitive safety and alignment safety as part of our evaluation. Then, about 1 or 2 weeks before launching, we do scaled-up evaluations and scaled-up alignment on the model. That's how we assess whether the model is safe.
But if it's already open weight and in the wild, people can do things with it. I guess that's what you're getting at, right? People can do more things with the model that we can't control. I don't know how we handle that, frankly speaking. There are laws around that, right? There are regulations where people agree on some moral standards.
Do you follow any reinforcement learning failure modes that haven't shown up in benchmarks but then become obvious in agentic use? How do you collect feedback for the next versions to improve the reinforcement learning process?
We collect feedback on the model itself first. When we publish a model, many developers and many other people use it. We collect feedback systematically and analyze each problem. Some of them are fundamental; some of them are just things that we missed and can fix very quickly.
So there are 2 parts. First, we do the internal evaluation with the developers, and they point out problems. That's how we can fix that part, but it's not enough. More feedback comes to us after we officially publish the models, and then we collect it.
The way we organize our group is that different people work on different capabilities of a general model. If we collect something that we think we should improve in the future, different people take responsibility for their parts. They're like, “Okay, I think I can solve this issue, and I'll solve it in the next generation.” That's how we collect feedback and improve the model.
How did you initially decide not to build one general-use model with everything for everyone, and instead move more toward specialization, like coding?
I think we're approaching generalized models. It's just that we're putting more emphasis on coding. For example, our model can also be taken into any general agent scaffold, including our own agent product, and that's for general-purpose use. We work on researching, report writing, PPT stuff, and things like that. That's more general.
Personally speaking, I feel like with coding, you can structure the whole world, or you can model a lot of things with—
Engineer it.
Yeah, with engineering. Behind it, it scales up humanity for me. It itself has a lot of intelligence and a lot of work to do. That's how we view this issue. But we do work on generalized stuff, and even more generalized stuff in later versions. For example, our model can handle some general workplace scenarios in the future, and that's not just coding, right?
If we talk about coding and using it, it requires a long horizon. How do you solve long-horizon problems for agentic use?
I think defining your goals well and defining the model's behavior well is important, and we also require great infrastructure—extraordinary infrastructure, for example, for reinforcement learning. The very important issue, besides the algorithms and the things that people have been working on for a very long time, is that what's special for agentic applications is how we define agents and how we define how an agent model would work.
First, you need to define the task. You need to define the model's goal. Especially in a long-horizon task, you need goals that are actually hard and diverse. The second part is that you need environments. You need great engineering environments, scaled-up environments, and different, diverse environments—not just coding, but, for example, workplace environments and different kinds of tools. That's great engineering.
Then you need great infrastructure. You need outstanding RL infrastructure to let the model really roll out over a very long horizon, with very efficient GPU use, very efficient training rollout, and so on. I feel like that's what's different in agentic reinforcement learning compared to before.
Are you affected by GPU constraints? How do you solve the compute problem?
We do have a team that works on how to utilize the compute most efficiently. That's actually one of the RL scaling issues: utilizing compute very efficiently. Their purpose is to minimize compute use while training more, right?
Personally speaking, I don't really have a GPU constraint, because we have a great team that works on utilizing the compute as much as possible while stabilizing the training.
But do you have problems that you need to solve with your expertise—how to use things more efficiently—or is it just that team?
We are actually the same team, because we're the reinforcement learning team. We view this issue from different perspectives. It can be implementation, it can be a data perspective, and you can view it from different perspectives, but our goal is the same.
We're always looking forward to new solutions that come from Chinese labs because they're always mind-blowing.
We are actually working on some new agentic reinforcement learning stuff, but it won't really come out with M2.2, with the next-generation model. We are still working on it. I'm not sure what I can share, so I can share it later when I have concrete conclusions. As I said before, I can't really say something that we haven't documented yet.
Will it be available when the model is out?
That depends on our timing. I'm not very confident yet, but we are working on it diligently.
Yeah. There are a lot of constraints when talking to researchers. If we talk about openness, this whole conversation that I'm having with people right now in this quarter is about open source. I wonder if you can talk about the company strategy: why the company decided to publish open weights of the models. What are the benefits? What are the cons to that?
For our team, the research team, we always wanted to go open source because the open-source community is fantastic. I learned that from day 1 when I joined the team: the open-source community is fantastic. As researchers, we did want to join the open source, but, on the other hand, speaking of the cons, we are a company that people care about—whether this can make money or if this is a business.
The con would be that if the weights are open source, fewer people would use APIs. But as a researcher, that really isn't my focus that much, so I'm not very confident about the company strategy for the tech part. We just believe that we can build better models with the open-source community.
How much do you use open-source tools yourself from different other companies?
A lot. For example, for inference, we use—I'm not sure if I'm allowed to say specific open-source projects—but we collaborate with both vLLM and SGLang, and they have open-source code repositories.
How do you look at the open-source stack? Because when we talk about open source, sometimes it's perceived as one thing, but actually it's multilayered. How do you look at it?
For example, there are a lot of open-source agent scaffolds—both coding agents and agent scaffolds—that we use ourselves to test our models, and then we look at their logic. We look at their code to see how they design specific scaffolds and, for example, engines. Then we take what they worked on that was really good, and we reflect on how we think about the problem, how we structure the problem, whether we're on the same page, and stuff like that. So we learn from each other.
Do you think teams underestimate how much engineering discipline open models require compared with using closed APIs? It always requires a lot of setting up, and it's a different kind of compute, and you need to have talent for that—you need engineering talent—instead of just choosing a closed API, turning it on, and using it. Do you have any difficulty with that, or is the open-source stack inside the company established and working?
Personally, I don't have a problem with that. There are other open-source models, and if they publish, I'll just download them and deploy them on our machine, and then work with them if I want. Personally, I don't have that issue. If there are personal developers out in the wild, I understand the problem, especially when they don't have their own compute. Then it would be easier to connect to a model through, for example, OpenRouter and stuff like that.
Do you use a lot of other open models on that same OpenRouter, let's say? Do you play with them?
Yeah, I play with them. I would play with them on day 1. If they release at midnight, I play with them at midnight. [Snorts]
Are you taking notes? [Laughter]
I don't actually take notes, but I do have my personal evaluation stack: a list of fun questions that I like to test with every single model to see how they work.
Can you tell me about it? That's super interesting.
Yeah, I've been collecting a bunch of questions since I joined the company in different areas, including logical reasoning, mathematics, proofs, report writing, agentic tasks, and stuff like that—a lot. I just like to see how the model reacts to these problems and how it approaches them. Different models have different personalities when approaching them.
That's true. And you always need to adjust them. If we want to give people who want to evaluate a model themselves sort of a little guide, can you give me examples of the questions—say, 5 questions you need to ask the model to understand how it works, if it works well?
From a professional evaluation perspective, 5 questions isn't enough. If you want to do a very standard and very fair comparison among models, we have to make it a very confident test. There has to be a certain number of questions in each domain to see how the model performs, and usually you need to test it multiple times because models are not very stable themselves.
If you're testing for fun, use the fun questions, but if we are actually assessing the model's capabilities, we need some sets, and that's very fair among different models. That's correct, because some problems are not correct. For some questions, the answers are not single. For example, sometimes when we run the test, the environments are not fixed. For example, the gold patch wouldn't pass and stuff like that.
So if we're doing a professional evaluation, you have to make sure the evaluation is correct, diverse, and above a certain threshold, so that the test is confident.
You mentioned characters. How do you work with your model's character?
I don't work on my model's characters. Okay, that's how I think of this issue. A general model should have all characters, or it should be able to perform all characters. It might have a default character. If the user wants it to be a different character, and that is injected into the system prompt, it should be. That's how I view this issue.
I find it hard to adjust to the new models because they're so different in terms of character all the time. I just don't even understand why it happens. I think it has to be something related to the data that the model was trained on, the different patterns the models have been trained on, and also different people. A different team might have their own constitution in the system prompt, or as the model's default behavior.
If you look at open models in production today—I don't know if it's a relevant question—but where do they fail first? Open-model-specific reasoning, tool use, state tracking, evaluation blind spots—there are all those risks for open models. Where does it break first?
I think open models are not very good at adjusting to different environments. From what I see right now, we can see, for example, Claude, right? People use Claude in different coding environments, and then people think it performs well in all environments or with different tool definitions and stuff. But I don't feel like current open models can achieve that accuracy [Snorts], or that level of understanding of different environments.
Why? Where is the problem?
I don't know how Claude does it. But for me, I think it is a solvable problem, and we are working on it. We are improving it in MiniMax-M2.2, but it's still not as good as, for example, Opus. But for MiniMax-M2.5, it might be. We do have some systematic research going on in the area that has shown some results now, but there still isn't a concrete conclusion, so I won't say it.
I'm so curious, but do you think it's the problem of compute because they have this infinite amount they can just throw at it?
I feel like compute is one side, but how we structure the problem and how we approach it is another side, and that's where we're more confident that we can solve the issue.
What can you tell me about MiniMax-M2.2 if it's launched by the time the interview is out? Can you give me some overview?
Better coding, obviously, and better multilingual coding, obviously, and more stable than before. It has better performance than M2.1 in different areas; it's better and more stabilized, with longer horizons and stuff like that. We are testing it in different environments right now, and we believe that it's better than before.
So, different coding environments, right? Even environments that we haven't seen before, even environments that are totally out of distribution, we see some very promising scores that are higher than M2.1.
I wonder how you stay updated with everything that happens, which is super hard because the pace is just insane. You said when the models are out, you play with them. Do you read research papers? What are your other interests that help you cross-pollinate with what you do? Can you tell me how you stay up to date and what inspires you?
There are different articles, different blogs, and papers coming out every single day—a bunch of information. How we deal with it is that we have an internal agent that tracks all the new articles, blogs, and papers, and then it dispatches them to different subject areas. Then it summarizes and analyzes them for researchers.
So we have an internal researcher, if I call it that, that does some filtering by itself, and then it gives what is filtered to us. Then we can improve the researcher if we think it doesn't do well, and that's how we filter out a lot of information first. Then we play with new code repositories with coding agents so that we can understand them more quickly and play with them more quickly. So we're keeping up with all the improvements with agents and with our models, for our models.
That's fascinating. When you became a researcher, when you chose this path, what did you think you would be doing, and what are you actually doing? Is it close to what you thought?
That's a really good question. When I joined the team, I thought I would be reading papers every day, because that's what I was doing in school, in a lab. We would read papers, come up with ideas, implement ideas, and run experiments. If the experimental results were good, we would run them on a larger scale.
I thought I was about to do that. But then what I realized was that when joining the company and working for a couple of months, you already become pretty much top of the area, or of the industry, and you have to come up with something that's really new. Or you encounter problems that you just don't know how to solve.
It's not like you can read a lot of papers and then build up your thinking based on the papers. It's more like you need to really understand the problems from the fundamentals and then think about them from the fundamentals so that you can find the right solution.
Another thing would be that engineering is very important. I didn't know that during school because during school, or during labs, it's more toy-like compared to companies. It's not scaled up. But when you really do scale up data, compute, and people, right, you encounter engineering issues that you need to tackle very elegantly, and engineering is very important. That's part 2 that was different from what I imagined. Pretty much these 2 things.
When you work on the model currently, is it mostly that you're solving problems that you see immediately from your hands-on work, or is it that the company says, “Oh, we have to achieve, let's say, Opus results”? How do you set the goals?
We have a meta-goal at the company level. For example, we want to improve the AI's capabilities in improving productivity, because that's how people view it. We have a company mission. As a single researcher on the team, we have our own missions, and we set our own goals.
What is your goal currently?
For the next generation, I really want the model to work elegantly with experts. It's more like better collaboration with experts and developers. That's my goal as well, but that's maybe 2 versions away. I think we're launching 1 version about every month or month and a half, right?
For a longer horizon, we are definitely working on it. But for me, the goal that I set along that path, that's a 3-month-away thing. For the better collaboration thing, that's a 1- or 2-month-away thing.
I wanted to ask you a little clarification question about interleaved learning, where you were talking at AI Engineer as well. The model doesn't settle on 1 action; it's constantly in the loop of asking more questions and trying things. How do you look at it? Is it continual learning? Is it part of it? What do we need to solve to have the model continuously doing this learning for longer and longer horizons?
That has some overlap with the well-defined concept of continual learning. By overlap, I mean I think both conceptually and technically, but I don't feel like they are exactly the same. What I talked about at the summit was not at the level of full continual learning. It's more like on the path to that.
How do you see it being solved? Any ideas?
We do think that's a different problem definition, or a different way of the model working with people, and we are working on that now with our own defined question. But if I need to say how we approach it, I would say we would approach it through experiments.
That's a very interesting question on continual learning, and it's still very exploratory. That's definitely what we are working toward. But it has different phases, or different stages. We might approach stage 1 first while exploring more stages later.
And the stages aren't yet outlined?
We do have our internal definitions, but I didn't prepare them today. I would say the first would be to be more stabilized in long-horizon tasks, what I said at the summit, right? And then the next thing would be optimization.
Can you repeat it? People don't know what you said.
For example, we see a model. It receives environmental feedback in a new environment. It needs to know what to explore and which environments to see because it's a partially observed environment. It needs to know which actions to take to receive better information, then have a better reaction, and then perform harder, more complex tasks in the environments.
That's more of stage 1, right? That's pretty simple. Basically, all agent models can do that to some extent. Maybe not perfectly, but to some extent. That's how we can actually solve it with our current algorithms.
But we do see different forms of how a model improves itself in the environment, and we don't have a concrete conclusion on that yet. Maybe in 2.5 we will. That will be a different definition than what I said. The model itself would be defining its own goal. That's something that would be different.
Thank you so much. My last question is about AGI. Do you believe in AGI? And if yes, what does it look like to you?
Okay, that's a very large question. People talk about AGI and ASI every day. Actually, when I was interviewing with MiniMax, when I was interviewing with our CEO, I said the same thing. He asked me the same thing, right?
What I said was that I think people talk about AGI, and people have different definitions of AGI. But we can only know the definition of AGI when we achieve it. It's still progressing so fast that the definition even changes every day, and people have different comments on it.
What I think is more important is that we actually work toward it, work toward our own definitions of AGI. As long as we figure it out, it becomes true. That's what I said during the interview, and that's still my view today. The definition will become true when it becomes true.
When we see it, we know it's AGI.
Yes, exactly.
But we're not there yet.
No, there can still be better AI intelligence, for sure.
Thank you. One more last question. What was the book that influenced you the most? It can be a recent book or a book from your childhood.
Let me just double-check the name, though. Something like The Art of Creativity, or something, that I read during undergrad. So it's a long time ago. I don't remember the exact name.
Yeah, there is a book called The Art of Creativity. How did it influence you?
It opened up how I think of my own mind a lot, and then how I view the world and how I view problem-solving. For me now, problem-solving is more of a discovery. That's how I would summarize it in 1 quote.
Thank you so much. Thank you for your time. That was very interesting.
Thank you for having me. If you're finding value in the show, we'd appreciate it if you take a moment to share with friends, post online, write a review on Apple Podcasts or Spotify, or just leave us a comment on YouTube. Of course, we always welcome your feedback, guest and topic suggestions, and sponsorship inquiries, either via our website, cognitiverevolution.ai, or by DMing me on your favorite social network. The Cognitive Revolution is part of the Turpentine Network, a network of podcasts, which is now part of A16Z, where experts talk technology, business, economics, geopolitics, culture, and more. We're produced by AI Podcasting. If you're looking for podcast production help for everything from the moment you stop recording to the moment your audience starts listening, check them out and see my endorsement at aipodcast.ing. And thank you to everyone who listens for being part of the cognitive revolution.