一句话让 AI 造出快 6.3 倍的推理引擎，贾扬清离职英伟达官宣二度创业：AI Infra 正从“管算力”走向“造系统”

作者 | 四月

一个月之前, 我们曾对贾扬清离开英伟达这件事情进行了报道 , （收购仅仅一年便走向“决裂”！创始人贾扬清离开了英伟达: 黄仁勋对运营成效不满意 , 20亿美金的AI Infra突围为何遭遇失败）  注 “AI Infra不换行是因为你表述的要求, 实际使用应换行符合规范”。

当时，外界的猜测是：他大概率还会回到 GPU 云这张牌桌。

毕竟从阿里云开始, 一直到英伟达DGX Cloud那, 贾扬清在过去几年当中, 始终都在和算力调度相关问题打交道, 还得处理多云部署事宜, 以及GPU利用率这种Infra方面的问题。在6月初的时候, GPU云服务商又聘请了他去担任顾问, 其业务方向几乎能够无缝衔接上以往的路线。

但现在，真正的答案浮出水面。

贾扬清联合白、向L.、王等开源领域资深人士, 正式创办新公司 lab（意图实验室）, 此次, 他没有持续开展GPU云平台业务, 也并非单纯重复AI Infra的旧路, 而是尝试解决一个更具层级性的问题:

若是模型已然愈发擅长编写代码, 那么 AI 距离真正独立自主地开发出一套生产级别的软件, 到底尚缺哪一个步骤呢?

伴随官宣一起亮相的，还有  Lab 的首批成果：

1）一个GLM - 5.2推理引擎, 处于两台Grace节点之上, 其输出速度从每秒102提升至每秒647, 提升幅度为6.3倍。

2）话说有一个数据库引擎, 它是从一句模模糊糊的需求开始起步的, 经过了一系列复杂的过程, 最终成功跑通了数量为600万条的兼容性测试。

3）另外存在一个具备形式化验证功能的分布式文件系统, 它能够找出由普通agent所生成代码里面的数据损坏类bug。

不是从推理引擎开始, 不是到数据库为止在其次到代理文件系统, 这些全都是比较偏向底层的工具, 似乎看起来并且貌似并没有直接的联系, 而是实际上你知道吗在这其中贾扬清真真真正正想要展示的, 是这一系列事物背后存在着的同一套系统Fleet的能力。

贾扬清把Fleet定义为, “全球第一个把意图变成生产级软件的自主团队”, 这意味着, 用户不再是下达一个“写段代码”的命令给AI, 而是提出一个更高层的目标, 由一组智能体自己去完成理解, 去完成设计, 去完成编码, 去完成验证, 以及完成后续演进。

这使得贾扬清此次再度开启创业历程, 具备了较“AI领域顶尖人才告别英伟达”更为值得予以关注的行业层面的意味。

AI Infra 的底层命题变了

在过去的十年当中, 贾扬清做过Caffe, 贾扬清做过ONNX, 贾扬清做过1.0 , 贾扬清是上一代AI框架被公认的奠基人；贾扬清在阿里参与过大规模AI基础设施建设, 贾扬清在英伟达参与过大规模AI基础设施建设。到后来, 贾扬清试图降低开发者使用GPU的门槛, 贾扬清试图降低开发者部署模型的门槛。

先是之前的情况, 而后到如今的Lab, 其所为是, 使AI直接去构建, 那种具备交付能力的基础软件。

这背后, 实际上也是, AI Infra正在经历的一回价值重新评估。

于上一篇报道里, 我们曾进行过探讨, 将开发者运用以及管理GPU集群的门槛予以降低, 此一命题, 在2023年来看, 也许是一个值得耗费数亿美元去处理的问题。然而到了当下, 解决办法以及门槛已然出现松动。

是以表示代码之意的字即 Code, 还有法典编纂之意的代码 Codex 为代表, 这样的存在使得软件开发的底层逻辑正在遭受到重塑, 已经有开发者能够运用自然语言去描述自己的需求, 此后就产生着这样一个过程, 即 AI Agent 会自动对于完整的含有基础设施的代码做出生成, 再加以调试并且进行部署。

这同样表明, 传统的AI Infra尝试通过产品化途径去封装的那种复杂性, 正被借助代码生成的办法直接给绕开了。

那些仅仅停留在“让工程更省事”这一范畴的工具层平台, 正遭遇着被开源组件以及 Agent 组合予以替代的系统性挑战, 这也是致使 DGX 未能达到黄仁勋预期、开源承诺未能兑现等等一系列状况的客观背景。

所以, 对于AI Infra层创业而言, 核心的拷问已然转变为, 你所解决的究竟是表层的那种复杂性, 还是底层的那种稀缺性?

给出他答案的是贾扬清, 借助Lab做到, 在官宣帖子当中, 他表述得极为直白:

花整个职业生涯于世界最大分布式系统及AI基础设施, 始终是精心架构设计, 逐个做系统。然而现更感兴趣的, 是一次产出一千个系统的那种系统。

不去做那种将包装弄得复杂的中间件, 而是要去做那个号称能产出一千个系统的系统, 这便是他此次再度创业所蕴含的底层逻辑。

不是AI写代码，而是造工程团队

Lab有一款核心产品, 它的名字叫做Fleet, 从定位这个角度来讲, 它并非是那种能实现更快代码补全的工具, 它也不是新型的IDE插件, 它是一套针对生产系统的自主智能体团队。

这其中的差别在哪里呢？

如今的多数agent，所处理的是“代码生成”方面的问题, 用户讲出一句话后, AI去撰写一段函数, 修正一个bug, 补充一组测试, 甚至于完成一项小功能, 这已然具备颇高的价值, 然而它与实际的软件工程依旧有着极大的差距。

真正的工程并非写完代码便告终, 它需先领悟需求, 剖析目标, 构思架构, 明确接口, 考量性能与成本, 接着才步入编码、测试、评审、验证以及上线环节, 上线之后还得留意运行状况, 依据实际负载持续修正与演进。

Lab 想把这整条链路交给 AI。

Fleet所要达成的, 是源于一个粗陋的人类意向, 自始至终完成设计、予以实现以及开展验证, 且于生产环境之中持续演进。它并非是将人类工程师的某一行为予以自动化, 而是企图去重现一支可靠工程团队的完整协作进程。

这同样是为何, Lab首批所展示的并非是一个聊天应用, 并非是一个网站演示, 不过是推理引擎、数据库以及文件系统。

这几个东西, 都存在着共同之处, 啥共同之处, 就是它们并非那种  “只要能跑就行”的应用层软件哦而是属于对性能有着极高要求、对可靠性有着极高要求、对兼容性有着极高要求以及对正确性有着极高要求的系统软件。

特别是 GLM 负五点二推理引擎这个实例, 极为适宜用以展现 Fleet 的能力界限。

刚开始定下的给Fleet的目标, 只是来自高层的一种意图, 那就是进行改造, 针对-LLM, 要使得GLM-5.2在Grace节点上能够跑得更为快速, 并且要依靠自身去识别优化的空间, 依靠自身去实现, 依靠自身去验证。

要留心, 这并非是从无开始去编写一个玩具推理服务, 而是于英伟达早已经过高度优化的 -LLM 体系之上持续去压榨性能。也就是说, Fleet 所要面对的并非是“低水平代码生成”, 而是苛刻的系统优化。

最后它交付了四类优化。

优化内核层, 借由某方式 , 并直接生成PTX与SASS , 使Agent避开普通编译器路径 , 获取更精细粒度的指令级控制。

利用H2D进行运行时优化, 在稳定阶段大幅减少CPU到GPU的元数据拷贝, 以此降低不必要的调度开销。

通信进行优化, 将add予以操作, 把它折进融合之后的all-里面, 进而减少每层与内存往返通信这一系列行为。

优化投机解码, 配合更佳的, 使模型一次提出多个token, 接着由大模型批量验证, 进而显著提升输出吞吐。

最终呈现的结果是, GLM - 5.2 的输出速度, 由原本的每秒 102 提升至每秒 647, 其性能提升幅度达到了 6.3 倍。

然而, 更值得予以关注的是, Fleet 的工作方式。它并非依靠人类预先撰写好全部优化规则, 而是如同一个系统工程团队那般, 先去进行瓶颈分析, 随后提出方案, 接着实现方案, 再对结果加以验证, 若失败便回退, 成功之后再持续寻觅下一个瓶颈。

这已经不太像普通  agent，更像自动化的系统工程循环。

为什么是数据库和文件系统？

要是讲 GLM - 5.2 推理引擎所呈现出来的是性能方面的优化能力, 那数据库以及文件系统所展现的便是另外一类能力: 复杂系统的正确性。

展示于Lab的第二个案例, 讲的是一句话促成一个数据库引擎的生成, 且最终历经有着600万条的兼容性测试。

要清楚, 数据库并非平常的业务代码, 它不但得够去执行 SQL, 而且还得处理查询语义, 以及存储结构, 还有事务行为, 包括边界条件和兼容性问题, 好多 bug 不会在简单测试当中暴露, 而是在复杂语句, 以及异常输入, 还有并发状态和历史兼容里逐个冒出来。

但若有一个 Agent 只给出了那种写出“看上去能够跑起来”的数据库, 这其实没什么值得稀奇的。而真正困难之处在于, 它可不可以将自身置于一整套严苛的测试体系当中, 一次次地进行修正, 一直到其行为近乎符合真实生产系统的要求为止。

有一个专门供AI Agent所使用的分布式文件系统, 此为第三个案例, 其难点在于对状态进行直接管理。

为何要再度制作文件系统呢? 原因是, 当 Agent 在云端开展运行时, 它会持续启动沙箱, 会进行扫描目录的操作, 会读写数量众多的小文件, 并且这些文件常常被放置于共享云存储之上。像 EFS、S3FS 这样的传统方案是能够使用的, 然而却并不契合这种具备高频、小文件、强并发特性的 Agent 工作负载。其中的挑战在于, 它们必须在各种各样的边界情形下, 尽可能地维持一致性以及可恢复性。

于是, Fleet 进行了从零开始的构建。其结果呈现出这样的情况, 在诸如目录创建、文件创建、文件读取等这些基础操作方面 , 相较于 EFS 有着数十倍到数百倍的提升 , 部分指标超出了 600 倍 ；在 Git 仓库操作当中 , clone、删除同步等任务同样加快了 2.5 到 14 倍。

更为关键的是, Fleet并非单纯地将代码编写出来了事, 而是还要去检查其是否可靠。它针对核心协议进行了大约190万个状态的形式化验证, 并且还有300个集成测试、故障注入以及模糊测试与之配合, 这些测试覆盖了崩溃、并发、竞态等极端情况。在这个过程当中, 它还发现并且修复了一个agent在分布式创建和删除文件时会致使数据损坏的bug。

这个案例表明, Fleet 的价值并非仅仅局限于“会写代码”这一方面, 而是在于能够环绕着真实负载对系统进行重新设计, 并且与此同时将性能以及正确性做到可以被验证。

这也是当下   最大的分界线。

在历经的往昔一年之中, AI 于编写代码方面所具备的能力已然进步得极其迅速。然而, 很多团体于实际运用的进程里会发觉, agent 的“演示成效”与“生产价值”之间依旧存在显著的差距。它能够极为迅速地撰写出一个版本, 也能够极为迅速地修复一个故障, 可是一旦系统转趋复杂, 状态数量增多, 依赖关系拉长, 错误所带来的代价变高, 它便易于从“效率工具”转变为“风险源头”。

Lab尝试去补的, 恰恰是这中间的一层, 并且要做到把“用基础设施的主体由人转变为agent”。

AI Infra 的新分水岭

将贾扬清这些年的路径连接一块儿去看, 能够发觉一条极为清晰的主线: 对于运用算力以及系统这件事, 他始终持续不断地在降低门槛, 以使他人能够更顺利地用上。

Caffe促使深度学习脱离实验室范畴, 使得模型转变为生产基础设施, AI让GPU集群具备更好的使用体验。抵达Lab后, 他尝试致使“构建一个生产级系统”此事自身, 由手艺活转化为自动化的事物。

这实际上表明, AI Infra 的价值正处于重新评估的状态, 以往, Infra 具有最高价值的部分是“资源以及封装”, 然而待到它们崛起之后, 一部分具备封装方面复杂性特征的价值, 正被AI自身所吞噬；实际上变得稀缺起来的, 是能够促使 AI 领会模糊意图、剖析架构设计、持续进行验证并找出隐藏 bug 的深层系统能力。

简要来讲, AI Infra 的竞争态势, 正从那种“帮助人去管理基础设施”的方式，转变为“促使 AI 成为基础设施的建造者”这种情况。

此次贾扬清所押注的恰恰是后者, 倘若这个方向能够跑通, 那么未来的软件形态极有可能会变得愈发碎片化、愈发专用, 由于软件的本质便是将意图转化为机器可执行的规则, 以往需要进行层层翻译, 而Infra层正力图解构这层翻译。