罗福莉一场“伏击”,让雷军腰杆硬起来了

蓝鲸财经
Yesterday

文|硅基星芒

3月19日,小米新一代SU7发布会如期举行。雷军站在聚光灯下,神态笃定,言辞从容。这份底气,并非只来自新SU7。真正的惊喜,还来自另一条战线。前DeepSeek工程师、现小米大模型团队负责人罗福莉,带领团队在大模型领域完成了一场“悄无声息的伏击”。

当日晨间,雷军通过个人社交媒体对外发布了Mimo-v2-Pro模型降临的消息。此前在OpenRouter悄然出现的两款匿名模型亮明身份,其中代号“Hunter Alpha”的模型调用量一度登顶日榜,累计突破万亿次。OpenClaw创始人Peter Steinberger曾在X平台上公开溯源询问,如今得到了雷军的正式回应。

两款模型迅速登上Artificial Analysis排行榜,在智能水平与代理能力两个维度上均进入国产模型前列。在AI开发者社区,小米以一种出人意料的方式完成了“后来者居上”的亮相。

然而,也有开发者实测指出,MiMo-V2-Flash存在“输出无限循环”的偶发问题。更关键的质疑来自基准测试本身:OpenAI Frontier Evals团队曾明确指出,小米引以为傲的SWE-bench Verified“实际上已经饱和且高度被污染”,建议行业转向更难的SWE-bench Pro。这意味着,部分亮眼数据需要在更严格的测试框架下重新验证。

罗福莉也在发布声明中直言,“会开源——当模型足够稳定值得开源的时候”。言下之意,眼前的MiMo-V2-Pro尚未达到她心中“值得开源”的标准。雷军的表态同样坦诚:“我们模型刚刚完成,未来一段时间,还会快速迭代增强。”这既是对外界的承诺,也是对现状的坦率承认——MiMo-V2-Pro确实还有不少短板需要弥补。

但瑕不掩瑜的是,MiMo-V2-Pro真正经得起审视的,是ARL-Tangram这项系统级创新。它才是罗福莉这场伏击的真正杀招,也是雷军腰杆挺直的底气所在。

01MiMo-V2-Pro的最大亮点

为了让大语言模型具备在真实世界中执行任务的能力,罗福莉带领的研究团队做出了一个极其准确的判断:

针对智能体的强化学习是不可或缺的核心技术。

与大语言模型不同,要想训练这些更聪明的智能体,就必须让它疯狂调用外部资源,比如用CPU跑代码、用GPU跑奖励模型打分,甚至是消耗海量的外部搜索引擎API配合。

毫无疑问,结果必然伴随指数级增长的成本。

但研究团队却在这个过程中发现了一个问题:

现有的AI系统面对这些复杂的需求时,往往采用简单粗暴的“过度资源配置”,算力浪费甚至高达70%以上。

为了打破这个瓶颈,研究团队提出了一项系统级创新,名为ARL-Tangram。

在这个系统中,“动作级编排”这个概念令人眼前一亮,它能将外部资源分配的粒度细化到极致,不仅能让动作完成时间(ACT)提速4.3倍,还能节省71.2%的外部算力资源。

更重要的是,它不是只停留于实验室的想法,而是已经在小米MiMo两款新模型的训练中实际落地的策略,商业化价值初步显现。

02走上牌桌的“智能体强化学习”

在细聊ARL-Tangram这项技术之前,首先得了解“智能体强化学习”这个概念。

一般来说,强化学习此前针对的都是大语言模型(LLM)的训练过程,传统LLM训练主要在GPU集群内闭环完成。

但是,现在人们已经不需要一个网页中的聊天助手,而是需要一个能操控设备的“数字牛马”。

智能体应运而生,它的底层是大语言模型,自然也需要类似的训练过程。

在采样展开(Rollout)阶段,模型需要不断地与Shell命令、Python解释器、搜索引擎API等外部工具和真实环境交互。

为了完成一项复杂的任务,与外部环境进行的“多轮交互、反复试错”这一系列环节被定义为轨迹。整条轨迹结束后,还需要调用奖励模型来进行打分。

因此,智能体强化学习的训练过程,高度依赖于大语言模型训练集群之外的异构外部资源。

而现有的开源强化学习框架在处理这些外部资源的分配问题时,往往采用的是“宁滥勿缺”的过度配置策略,这在两个层面上同时造成了算力的“黑洞”:

一是轨迹内的过度配置。

为了保证智能体在“反复试错”的过程中能够保证环境隔离,现有的系统大多会在一条执行轨迹的整个生命周期内,为它锁定一块专属的硬件资源。

论文中的实测数据更是超乎所有人的设想:在AI编程任务中,智能体真正在运行代码的时间平均只有47%。

而剩下53%的时间,底层的大模型正在思考或生成下一步的代码,但此时被强制占用的CPU资源完全处于闲置状态。

二是任务内的过度配置。

到了奖励模型打分的阶段,情况变得更加严重。

不同的强化学习任务一般需要调用不同架构的参数的专属奖励模型,为了保证打分的低延迟,开发者往往会为每一个奖励模型挂载多张昂贵的GPU。

但在强化学习训练的全过程中,这些奖励模型大多时间都处于“零请求”状态。

实测数据显示,在某个业务线并行的12个奖励模型所在的GPU集群,流式多处理器的平均活跃度连3%都不到。

英伟达的“卡脖子”越来越紧,宝贵的算力被霸占却空无产出,烧钱的同时,延迟和并发吞吐量也被限制,从商业角度看,这完全是不可接受的事实。

03 ARL-Tangram与动作级调度

为了解决这种无意义的资源浪费问题,小米的研究团队试图通过将任务流程进一步细分来优化资源分配,也就是所谓的“动作级调度”。

类似于化学中分子和原子的概念,一个“动作”指的就是底层大模型与外部资源进行的一次不可分割的交互。

它可以是执行一行Python代码,也可以是向Google发起一次网页查询API。

在这些动作的发生期间,大模型本身无需生成任何文本,只是纯粹在等待外部环境给出执行结果。

ARL-Tangram的核心逻辑很简单:既然大模型只有在这个瞬间才需要外部资源,那就只在这个瞬间给大模型分配资源。

不得不说,小米的研究团队很会给技术起名,Tangram就是七巧板的意思,而这套系统恰好能像七巧板一样灵活地拼装和调度资源。

按照这个理念,ARL-Tangram的核心操作一共有两项:

一是拆解(Breakdown):打破长生命周期环境对物理资源的持续占用。

只要一个动作执行完毕,系统马上把CPU和GPU资源抽走并释放,同时保留环境的上下文状态,等下一次动作来临时再恢复。

二是池化(Pool):将所有释放出来的闲置资源放进一个全局统一的资源池中。

智能体的实际应用过程中往往有海量的动作并发到来,系统会根据排队情况,弹性地按需分配资源给最需要的动作。

04 ARL-Tangram的核心架构

理念简单而美好。但要在复杂的GPU集群中跑通这套逻辑,就会有很多工程挑战摆在眼前:

智能体要求动作执行时间极短、资源类型复杂多样、环境状态需要瞬间保存和恢复。

为此,研究团队为ARL-Tangram设计了三个核心组件:

①统一的动作建模(Unified Action Formulation)

面对CPU的内核、GPU的显存、搜索引擎网站的API调用次数这些截然不同的物理资源,要想在同一个队列内进行统筹调度,就必须有一个统一的度量方法。

ARL-Tangram的方法是将每一个动作的资源成本都抽象为一个多维向量。

更重要的是,它还引入了弹性建模技术。

系统会自动识别哪些动作具备弹性:例如,4个CPU核心运行测试用例需要10秒,而16个CPU核心只需要3秒,这就为后续的动态智能调度提供了明确的数学依据。

②弹性资源调度算法(Elastic Resource Scheduling)

智能体运行的过程中,调度时间只有几毫秒,面对海量并行而来的动作,算法必须在此期间最小化所有排队动作的总体完成时间(ACT)。

系统采用的是一种基于“贪心驱逐(Greedy Eviction)”的轻量级启发式算法。

简单来说,面对一大堆正在排队的动作,调度器首先实现“保底”,给每个候选动作分配仅能满足其运行的最小资源。

然后,算法会贪婪地尝试从队列末尾的动作手中“抢走资源”,并把这些资源加码分配给排在队列前面的具备弹性的动作。

如果经过计算,这种“集中力量办大事”的方法能够让总体等待和执行时间变得更短,那就毫不犹豫地立刻执行。

③异构资源管理器

调度机制已经清晰,接下来就该处理底层硬件资源的落地问题了。

ARL-Tangram针对CPU和GPU集群,研发了一套专用的底层管理机制:

对于CPU管理器,采用“执行时分配(Allocate-on-Execution, AOE)”:

动作执行完毕后,立刻回收CPU核心,但保留内存以维持环境状态,CPU复用率直接拉满。

对于GPU管理器,采用“执行时驱逐(Evict-on-Execution, EOE)”:

由于奖励模型启动极慢,而GPU显存寸土寸金,不可能把所有奖励模型都常驻在GPU中。

因此,将所有奖励模型的服务状态都备份在廉价的CPU内存中。

当一个动作需要特定的奖励模型时,如果GPU显存中有,那就直接运行;如果没有,系统将瞬间把不活跃的奖励模型从GPU显存中“驱逐”出去,并把需要的模型从CPU内存中加载出来。

配合上自主研发的显存分块策略和LRU驱逐算法,GPU碎片化和服务抖动问题也得以解决。

05 实战测试:降本增效能力一目了然

理论已经完备,接下来就该实际应用看看效果了。

研究团队在拥有数百张英伟达Hopper架构GPU和数千个CPU核心的集群中,针对AI编程、深度搜索和多任务奖励对齐等典型的真实业务场景,对ARL-Tangram进行了严格评估。

最直观的效果就是速度的飙升,解决了“排队拥堵”的情况。

在同样的硬件资源下,ARL-Tangram处理突发流量得心应手。AI编程和深度搜索任务中,单步训练时间分别缩短1.4倍和1.5倍。

由于彻底消除了轨迹内的过度配置,环境交互和奖励计算的耗时分别下降了9.0倍和2.8倍,总体的动作完成速度最高能达到4.3倍。

速度提升的背后,则是极致的性价比和算力利用率。

在固定并发量(Batch Size 1024)的极限测试中,对比业界流行的基线方案,ARL-Tangram展现出了强大的资源压缩能力。

例如,为了服务10个不同的奖励模型,基线方案必须长期占用大量GPU,而ARL-Tangram只需使用基线方案29%的GPU资源就可以达到相同的处理延迟。

对于企业来说,这就意味着节约了71.2%的昂贵外部算力。

若是进一步测试极限,将Batch Size提升至1526,传统的K8s调度器由于资源耗尽直接崩溃,而ARL-Tangram仍然稳如泰山。

在CPU可扩展性测试中,平均任务完成时间相比基线降低了27.7倍;在GPU集群上,面对高并发场景,ARL-Tangram也能流畅地提供服务。

06 小米大模型的“伏击”之路

回顾两年前国内大模型的蓬勃发展,小米在AI领域的起步似乎并不算顺利。

腾讯阿里百度等互联网大厂和智谱、Minimax、月之暗面等AI初创企业接连推出世界知名的大模型时,小米显得尤为沉默。

哪怕是现在,提起小米,人们最先想起来的也是手机和汽车,以及雷军的那场“Are you OK?”发布会。

然而,ARL-Tangram和两款最新模型的发布,却让小米一跃成为国产AI的第一梯队,并在部分维度上超越了起步更早的竞品。

对于如何实现这种“后发先至”的跨越,ARL-Tangram的论文其实已经给出了答案。

在AI竞争的下半场,企业竞争的核心已经不再是谁能堆砌更多的参数,或是谁能购买到更多的显卡。

在所有人都已经意识到智能体会成为现阶段最可能通往AGI的必经之路时,小米率先注意到了针对智能体的强化学习才是大厂之间的决胜局。

训练一个聪明的智能体,必将消耗极其庞大且碎片化的异构计算资源。

如果不解决底层的调度效率问题,算法工程师脑中天才般的想法只会被缓慢的实验迭代周期和燃烧着的账单拖垮。

ARL-Tangram的意义就在于提供了一套高度工程化、可无缝落地且具有巨大商业价值的解决方案。

全面部署到小米MiMo系列大模型训练的流水线后,智能体代理能力的提升有目共睹。

技术突破的背后,永远有人的故事和企业战略的交锋。

在这篇重磅论文的作者列表中,可以看到一个熟悉的名字:罗福莉。

这位曾经在DeepSeek任职的核心技术人员,拒绝被外界称为天才少女,始终把自己定位为一个用代码和工程解决实际问题的技术人。

ARL-Tangram一样,弹性按需分配的思路在计算机领域并不罕见,但小米却第一个脚踏实地将技术落实到了产品之中。

如今看来,雷军将罗福莉从DeepSeek挖至麾下,无疑是一次极具战略眼光的人才投资。

若是放在过去的两年之中,外界的怀疑声音早已接踵而来,但ARL-Tangram技术的诞生,以及小米两款新模型的惊艳表现已经给出的确切的回答:

雷军的这笔AI投资,不仅投对了,而且把好钢用在了刀刃上。

160亿的资金不一定能在算力堆砌上产生结果,但却能砸开底层基础设施的坚固壁垒。

系统基建决定了算法的天花板,在拥有了运行速度快4倍的底层训练框架时,竞争壁垒就已经在无形之中建立起来。

大模型商业竞争的下半场,小米正努力挤上牌桌。

Disclaimer: Investing carries risk. This is not financial advice. The above content should not be regarded as an offer, recommendation, or solicitation on acquiring or disposing of any financial products, any associated discussions, comments, or posts by author or other users should not be considered as such either. It is solely for general information purpose only, which does not consider your own investment objectives, financial situations or needs. TTM assumes no responsibility or warranty for the accuracy and completeness of the information, investors should do their own research and may seek professional advice before investing.

Most Discussed

  1. 1
     
     
     
     
  2. 2
     
     
     
     
  3. 3
     
     
     
     
  4. 4
     
     
     
     
  5. 5
     
     
     
     
  6. 6
     
     
     
     
  7. 7
     
     
     
     
  8. 8
     
     
     
     
  9. 9
     
     
     
     
  10. 10