当前位置：首页 > news >正文

51c大模型~合集32

news 2025/10/27 8:41:06

我自己的原文哦~ https://blog.51cto.com/u_16839134/11742161

#斯坦福系创企「炒作」AgentQ

直爆料OpenAI「草莓」的账号，竟然是个智能体？

当炒作出了「泼天的流量」，已经没人关心产品厉不厉害了。

最近，OpenAI 的秘密项目「Q*」一直受到了圈内人士的广泛关注。上个月，以它为前身、代号为「草莓（Strawberry）」的项目又被曝光了。据推测，该项目能够提供高级推理能力。

最近几天，关于这个项目，网络上又来了几波「鸽死人不偿命」的传播。尤其是一个「草莓哥」的账号，不间断地宣传，给人期望又让人失望。

没想到，这个 Sam Altman 出现在哪里，它就在哪里跟帖的「营销号」，皮下竟然是个智能体？

今天，一家 AI 智能体初创公司「MultiOn」的创始人直接出来认领：虽然没等来 OpenAI 发布「Q*」，但我们发了操控「草莓哥」账号的全新智能体 Agent Q，快来和我们在线玩耍吧！

MultiOn 联合创始人兼 CEO Div Garg，他在斯坦福读计算机科学博士期间休学创业。

这波看起来让 OpenAI 给自己做嫁衣的营销操作给大家都看懵了。毕竟，最近很多人彻夜未眠等待 OpenAI 的「大新闻」。这要追溯到 Sam Altman 和「草莓哥」的互动，在 Sam Altman 晒出的草莓照片下，他回复了「草莓哥」：惊喜马上就来。

不过，「MultiOn」的创始人 Div Garg 已经把认领 Agent Q 就是「草莓哥」的帖子悄悄删了。

此次，「MultiOn」宣称，他们发布的 Agent Q 是一款突破性的 AI 智能体。它的训练方法结合了蒙特卡洛树搜索（MCTS）和自我批评，并且通过一种叫做直接偏好优化（DPO）的算法来学习人类的反馈。

与此同时，作为拥有规划和 AI 自我修复功能的下一代 AI 智能体，Agent Q 的性能是 LLama 3 基线零样本性能的 3.4 倍。同时，在真实场景任务的评估中，Agent Q 的成功率达到了 95.4%。

Agent Q 能做什么呢？我们先来看一下官方 Demo。

它能够为你预定某个时间某家餐厅的座位。

然后为你执行网页操作，比如查询空位情况。最终成功预定。

此外还能预定航班（比如本周六从纽约飞往旧金山，单程、靠窗和经济舱）。

不过，网友似乎对 Agent Q 并不买账。大家关心更多的还是他们是否真的借「草莓哥」账号炒作的事情，甚至有些人称他们为无耻的骗子。

重要组件和方法概览

目前，Agent Q 的相关论文已经放出，由 MultiOn 和斯坦福大学的研究者联合撰写。这项研究的成果将在今年晚些时候向开发人员和使用 MultiOn 的普通用户开放。

论文地址：https://multion-research.s3.us-east-2.amazonaws.com/AgentQ.pdf

总结一波：Agent Q 能够自主地在网页上实施规划并自我纠错，从成功和失败的经验中学习，提高它在复杂任务中的表现。最终，该智能体可以更好地规划如何在互联网上冲浪，以适应现实世界的复杂情况。

在技术细节上， Agent Q 的主要组件包括如下：

使用 MCTS（Monte Carlo Tree Search，蒙特卡洛树搜索）进行引导式搜索：该技术通过探索不同的操作和网页来自主生成数据，以平衡探索和利用。MCTS 使用高采样温度和多样化提示来扩展操作空间，确保多样化和最佳的轨迹集合。

AI 自我批评：在每个步骤中，基于 AI 的自我批评都会提供有价值的反馈，从而完善智能体的决策过程。这一步骤级反馈对于长期任务至关重要，因为稀疏信号通常会导致学习困难。

直接偏好优化（DPO）：该算法通过从 MCTS 生成的数据构建偏好对以微调模型。这种离策略训练方法允许模型从聚合数据集（包括搜索过程中探索的次优分支）中有效地学习，从而提高复杂环境中的成功率。

下面重点讲一下网页（Web-Page）端的 MCTS 算法。研究者探索了如何通过 MCTS 赋予智能体额外的搜索能力。

在以往的工作中，MCTS 算法通常由四个阶段组成：选择、扩展、模拟和反向传播，每个阶段在平衡探索与利用、迭代细化策略方面都发挥着关键作用。

研究者将网页智能体执行公式化为网页树搜索，其中状态由智能体历史和当前网页的 DOM 树组成。与国际象棋或围棋等棋盘游戏不同，研究者使用的复杂网络智能体操作空间是开放格式且可变的。

研究者将基础模型用作操作建议（action-proposal）分布，并在每个节点（网页）上采样固定数量的可能操作。一旦在浏览器中选择并执行一个操作，则会遍历下个网页，并且该网页与更新的历史记录共同成为新节点。

研究者对反馈模型进行多次迭代查询，每次从列表中删除从上一次迭代中选择的最佳操作，直到对所有操作进行完整排序。下图 4 为完整的 AI 反馈过程。

扩展和回溯。研究者在浏览器环境中选择并执行一个操作以到达一个新节点（页面）。从选定的状态节点轨迹开始，他们使用当前策略 𝜋_𝜃 展开轨迹，直到到达终止状态。环境在轨迹结束时返回奖励 𝑅，其中如果智能体成功则 𝑅 = 1，否则 𝑅 = 0。接下来，通过从叶节点到根节点自下而上地更新每个节点的值来反向传播此奖励，如下所示：

下图 3 展示了所有结果和基线。当让智能体在测试时能够搜索信息时，即为基础 xLAM-v0.1-r 模型应用 MCTS 时，成功率从 28.6% 提升到了 48.4%，接近平均人类表现的 50.0%，并且显著超过了仅通过结果监督训练的零样本 DPO 模型的性能。

研究者进一步根据下图中概述的算法对基础模型进行了微调，结果比基础 DPO 模型提高了 0.9%。在精心训练的 Agent Q 模型上再应用 MCTS，智能体的性能提升到了 50.5%，略微超过了人类的平均表现。

他们认为，即使智能体经过了大量的强化学习训练，在测试时具备搜索能力仍然是一个重要的范式转变。与没有经过训练的零样本智能体相比，这是一个显著的进步。

此外，尽管密集级监督比纯粹的基于结果的监督有所改善，但在 WebShop 环境中，这种训练方法的提升效果并不大。这是因为在这个环境里，智能体只需要做很短的决策路径，可以通过结果来学习信用分配。

评估结果

研究者选择了让智能体在 OpenTable 官网上预订餐厅的任务来测试 Agent Q 框架在真实世界的表现如何。要完成这个订餐任务，智能体必须在 OpenTable 网站上找到餐厅的页面，选择特定的日期和时间，并挑选符合用户偏好的座位，最后提交用户的联系方式，才能预定成功。

最初，他们对 xLAM-v0.1-r 模型进行了实验，但该模型表现不佳，初始成功率仅为 0.0%。因此，他们转而使用 LLaMa 70B Instruct 模型，取得了一些初步的成功。

不过由于 OpenTable 是一个实时环境，很难通过编程或自动化的方式进行测量和评估。因此，研究者使用 GPT-4-V 根据以下指标为每个轨迹收集奖励：(1) 日期和时间设置正确，(2) 聚会规模设置正确，(3) 用户信息输入正确，以及 (4) 点击完成预订。如果满足上述所有条件，则视为智能体完成了任务。结果监督设置如下图 5 所示。

而 Agent Q 将 LLaMa-3 模型的零样本成功率从 18.6% 大幅提高到了 81.7%，这个结果仅在单日自主数据收集后便实现了，相当于成功率激增了 340%。在引入在线搜索功能后，成功率更是攀升至 95.4%。

更多技术细节和评估结果请参阅原论文

参考链接：https://www.multion.ai/blog/introducing-agent-q-research-breakthrough-for-the-next-generation-of-ai-agents-with-planning-and-self-healing-capabilities

你的直觉也许会告诉你「不可能吧」，如果是这样，你不是唯一这样认为的。17 世纪末，一位身份不明的人就此与莱茵河的鲁珀特亲王打了个赌。鲁珀特是英王查理一世的侄子，曾在英国内战中担任保皇党军队的指挥官。他在温莎城堡的实验室中度过了晚年，从事冶金和玻璃制造的研究。鲁珀特赢得了这场赌局。

鲁珀特亲王

数学家 John Wallis 在 1693 年记述了这个故事，但并未说明鲁珀特是否写下了证明，或者真的在立方体上钻出了那个通道。不过 Wallis 自己给出了数学证明：如果沿着立方体内部对角线的方向钻一条直通道，这条通道确实可以足够宽，让另一个相同大小的立方体穿过。这是一个极其紧密的契合，如果第二个立方体只比原来大 4%，它就无法通过。

人们自然会好奇，还有哪些形状具备这种性质。谷歌软件工程师 Tom Murphy 表示，他在业余时间深入研究过这个问题，并称，「我认为这个问题非常经典，它一定会被一遍又一遍地重新发现，就算是外星人也会遇到它。」

把一个立方体倾斜到角上，另一个就能穿过它。

形状的种类太多，无法一一穷尽，因此数学家通常专注于凸多面体，即像立方体那样具有平面表面、没有突起或凹陷的形状。当某种形状在某些方向上比其他方向宽得多时，通常很容易找到一条可以让另一个相同形状通过的通道。但许多著名的凸多面体，例如十二面体或截角二十面体（足球的形状）具有高度对称性，难以分析。在这些形状中，「几百年来我们只知道立方体具备这种性质，」Statistics Austria 的数学家 Jakob Steininger 说。

直到 1968 年，数学家 Christoph Scriba 才证明四面体和八面体也具备这种称为「鲁珀特性质」的特征。而在过去十年中，专业数学家与业余爱好者又陆续发现，许多广为研究的凸多面体，包括十二面体、二十面体以及足球形状，都能找到「鲁珀特通道」。

鲁珀特性质似乎普遍存在，以至于数学家提出了一个普遍假设：每一个凸多面体都拥有鲁珀特性质。几乎没人能找到例外，直到现在。

诺珀特多面体（Noperthedron）。迄今为止，它是唯一一个被证明不具备鲁珀特性质的形状。

在八月的一篇论文中，Jakob Steininger 与另一位 A&R Tech 的研究者 Sergey Yurkevich 描述了一种拥有 90 个顶点和 152 个面的形状，他们将其命名为「诺珀特多面体」（Noperthedron，名字源于 Rupert 和 nope 的组合）。

他们证明，无论你怎样在诺珀特多面体中钻一条直通道，第二个相同的诺珀特多面体都无法穿过。

论文标题：A convex polyhedron without Rupert’s property
论文地址：https://arxiv.org/pdf/2508.18475

这一证明需要理论上的突破与大规模计算机运算的结合，并依赖于诺珀特多面体顶点间一种极其微妙的性质。Steininger 表示：「它能成立简直是个奇迹。」

穿过阴影

要理解一个立方体如何能穿过另一个立方体，可以想象你手里拿着一个立方体，放在桌面上方，从上方照射光线，观察它在桌面上的影子。如果你让立方体保持标准姿势，影子是一个正方形。但如果你把其中一个角朝上指向光源，影子就会变成一个正六边形。

1693 年，John Wallis 证明了正方形的影子可以完全嵌入这个六边形之内，只留下极窄的边缘。这意味着，如果让立方体的一个角朝上，你就可以垂直钻出一条通道，这条通道足以让第二个立方体穿过。

大约一个世纪后，数学家 Pieter Nieuwland 发现另一种姿态可以投射出更理想的影子 —— 这种影子可以容纳一个比原通道立方体大 6% 以上的立方体。

对更复杂形状的每一次后续分析，都依赖于这样一个过程：将形状从不同方向旋转，寻找一种投影（阴影）可以嵌入另一种之中。在计算机的辅助下，数学家们已经在各种形状中找到了鲁珀特通道。其中，有些契合得极其紧密，例如在一种名为「三尖四面体」（triakis tetrahedron）的形状中，通道余量仅约为该形状半径长度的 0.000002 倍。史密斯学院名誉教授 Joseph O’Rourke 表示：「计算与离散几何结合的世界已经开花结果，使得这类计算成为可能。」

那些编写算法以寻找鲁珀特通道的研究者注意到一个奇特的二分现象：对于任意给定的凸多面体，算法要么几乎立刻就能找到通道，要么完全找不到。在过去五年中，数学家们积累了一小批尚未找到通道的「顽固」形状。

约翰斯・霍普金斯大学的应用数学家 Benjamin Grimmer 使用台式机连续运算了两周，只为测试菱方截二十十二面体（rhombicosidodecahedron）。这种立方体由 62 个规则三角形、正方形和五边形组成。「它似乎就是对任何尝试都毫不妥协。」

菱方截二十十二面体是目前最有希望的「诺珀特」候选形状。

但是，这种抗拒并不能证明某个形状就是诺珀特。原因在于，形状可以有无穷多种取向方式，而计算机只能检查有限多种。研究者并不确定这些「顽固者」究竟是真正的诺珀特，还是只是那些鲁珀特通道极难找到的形状。

他们所知道的是，诺珀特候选者极为罕见。从去年开始，Murphy 开始构造数亿种不同的形状。这些包括随机生成的多面体、顶点分布在球面上的多面体、具有特殊对称性的多面体，以及他故意移动一个顶点以破坏原有鲁珀特通道的多面体。他的算法几乎能轻松地为每一种找到鲁珀特通道。

这些快速成功的结果与少数顽固「候选者」的强烈对比，让一些数学家怀疑真正的诺珀特确实存在。但直到今年八月，他们拥有的还只是猜测。

无通道

现年 30 岁的 Steininger 和 29 岁的 Yurkevich 从少年时期参加数学奥林匹克竞赛时就是朋友。尽管两人后来都离开了学术界（Steininger 获得硕士学位，Yurkevich 获得博士学位），但他们一直在共同探索尚未解决的数学难题。

Sergey Yurkevich（左）与 Jakob Steininger（右）。

「我们三个小时前刚吃了披萨，几乎整顿饭都在谈数学，」Steininger 在接受《量子杂志》采访时说。「这就是我们平常的样子。」

五年前，他们偶然看到一个展示「一个立方体穿过另一个立方体」的视频，并立刻被吸引。他们开发了一种用于搜索鲁珀特通道的算法，并很快确信有些形状是诺珀特。

在 2021 年的一篇论文中，他们提出菱方截二十十二面体并不具有鲁珀特性质。他们的研究早于 Murphy 和 Grimmer 的最新探索，因此 Steininger 自认为是第一个提出可能存在不具备这种性质的立方体工作。

论文标题：An algorithmic approach to Rupert’s problem
论文地址：https://arxiv.org/pdf/2112.13754

如果你想证明某个形状是诺珀特，就必须排除在两种形状的所有可能取向下存在鲁珀特隧道的可能性。每一种取向都可以用一组旋转角度来表示，而这组角度又可以表示为高维「参数空间」中的一个点。

假设你为这两个形状选择了一种取向，计算机告诉你，第二个形状的阴影超出了第一个阴影的边界。这就排除了参数空间中的一个点。

但你可能不仅能排除一个点。如果第二个阴影超出的部分相当明显，那么要让它重新进入第一个阴影，需要进行较大的调整。换句话说，你可以排除的不只是最初的取向，还包括所有邻近的取向，也就是参数空间中整块的区域。

Steininger 和 Yurkevich 提出了一个他们称为「全局定理」的结果，用于精确量化在这种情况下可以排除的区域块有多大。通过测试许多不同的点，人们可以逐步在参数空间中排除一个又一个区域块。

如果这些区域块覆盖了整个参数空间，那么你就证明了该形状是一个诺珀特。但每个区域块的大小取决于第二个阴影超出第一个阴影的程度，而有时这种超出非常微小。

举例来说，如果你从两个形状完全重合的位置开始，然后仅让第二个形状稍微旋转一点，它的阴影最多只会在第一个阴影之外略微伸出一点，因此全局定理只能排除一个极小的区域块。这些区域太小，无法覆盖整个参数空间，这就留下了一个可能性：也许还有某个未检查到的点对应着一条鲁珀特通道。

为了解决这些小幅度重新取向的问题，两人提出了一个与全局定理互补的结果，他们称之为「局部定理」。这个定理处理的是在原始阴影的边界上能找到三个满足特定条件的顶点（或角点）的情况。例如，如果将这三个顶点连接成一个三角形，它必须包含阴影的中心点。

研究者证明，如果满足这些条件，那么无论怎样对形状进行微小旋转，都会使新的阴影至少让其中一个顶点进一步向外延伸。因此，新的阴影无法完全落在原来的阴影之内，也就意味着不会形成鲁珀特通道。如果某个形状的阴影缺少满足条件的三个顶点，局部定理就无法适用。而此前所有被认为可能是诺珀特的候选形状，都至少有一个阴影存在这种问题。

Steininger 和 Yurkevich 查阅了一个包含数百个最对称、最优美的凸多面体的数据库，但仍找不到一个所有阴影都符合条件的形状。于是，他们决定自己生成一个合适的形状。

他们开发了一种算法，用于构造形状并测试其是否具备「三顶点」性质。最终，该算法生成了「诺珀特多面体」，它由 150 个三角形和两个规则十五边形组成。其外观像一个圆润的水晶花瓶，底部和顶部都很宽。有位网友已经用 3D 打印制作出一个模型，用作铅笔筒。

图源：https://bsky.app/profile/fractalkitty.com/post/3lxkvjiqa2c2p

接着，两人将取向的参数空间划分为大约 1800 万个微小区域块，并测试每个区域中心点对应的取向是否会产生鲁珀特通道。结果一个也没有。随后，他们又证明每个区域块都满足局部定理或全局定理，从而排除整个区域。由于这些区域块填满了整个参数空间，这就意味着诺珀特多面体不存在任何鲁珀特通道。这就意味着，「那个被普遍认为正确的自然假设被推翻了。」

至于数学家们能否利用这种新方法构造出更多诺珀特形状，或找到能够处理如菱方截二十十二面体等候选者的另一种局部定理，还有待观察。但既然数学家如今已经确认诺珀特确实存在，「我们就有了坚实的基础去研究其他形状了」，Murphy 说。

与此同时，Steininger 和 Yurkevich 正寻找新的问题去挑战。「我们只是谦逊的数学爱好者，热爱这类问题，并会一直这样探索下去。」

原文链接：https://www.quantamagazine.org/first-shape-found-that-cant-pass-through-itself-20251024/

....

#Robot Learning

手把手带你入门机器人学习，HuggingFace联合牛津大学新教程开源SOTA资源库

入坑机器人的春天来了。

众所周知，机器人学本质上是一个多学科交叉的领域，自 20 世纪 60 年代诞生以来，已经取得了前所未有的进步。

尤其是在大模型诞生，多模态大模型等人工智能技术蓬勃发展的当下，机器人领域与过去经典机器人学产生了重大的变化，机器人学习成为了现代机器人学的中流砥柱。

随着机器学习和多模态模型的迅速发展以及大规模机器人数据的拓展，机器人学习逐步转向了基于学习的范式，强化学习、模仿学习，以及研究热门的 VLA 模型，都正在为自主决策的机器人开辟全新的潜力。

值得庆幸的是，HuggingFace 与牛津大学的研究者们为想要进入现代机器人学习领域的新人们提供了了一份极其全面易懂的技术教程。

这份教程将带领读者探索现代机器人学习的全景，从强化学习和模仿学习的基础原理出发，逐步走向能够在多种任务甚至不同机器人形态下运行的通用型、语言条件模型。

论文标题：Robot Learning: A Tutorial
论文链接：https://www.arxiv.org/abs/2510.12403v1
Github 链接：https://github.com/huggingface/lerobot
模型和数据集链接：https://huggingface.co/lerobot

更良心的是，这份教程还额外附带了机器人领域的基于 PyTorch 的开源数据集、模型、工具和代码库 LeRobot，收录了许多当前的 SOTA 方法，这些方法已经在模仿学习和强化学习方向上展示了良好的真实机器人迁移能力。

目前，LeRobot 已经提供了一系列预训练模型、包含人工采集示范的数据集，以及模拟环境，用户无需搭建实体机器人就可以开始上手。

LeRobot 是由 Hugging Face 开发的开源端到端机器人库。该库在整个机器人栈上垂直整合，支持对真实世界机器人设备的低级控制、高级数据和推理优化，以及具有纯 Pytorch 简单实现的 SOTA 机器人学习方法。

这份教程从经典机器人学的概念开始，逐步介绍强化学习和模仿学习，生成模型的理念，以及通用机器人策略。

「技多不压身」，该教程是成为踏入机器人学习领域的一份有价值的起点。

我们将简单介绍一下这份教程涉及的基本内容：

经典机器人学

从显式建模到隐式建模的演化，标志着机器人运动生成方式的一次根本性变革。传统机器人技术依赖显式建模，通过正向运动学、逆向运动学以及基于控制的规划来生成动作；而基于学习的方法则通过深度强化学习和专家示范学习，实现了隐式建模。

经典的机器人系统通常遵循一个模块化流水线：感知模块处理原始传感器数据，状态估计模块确定机器人的当前状态，规划模块生成运动轨迹，控制模块则负责执行这些轨迹。

基于动力学的机器人方法存在多方面的局限：

系统中多个组件需要协同工作，导致集成过程复杂且容易出错；
不同的传感模态和任务往往需要定制化的数据处理流水线，降低了系统的可扩展性；
对物理现象的解析模型通常过于简化，限制了真实环境中的性能表现；
基于动力学的方法往往忽视了机器人数据在规模与可获取性方面的增长趋势。

综合来看，这些限制促使人们探索基于学习的方法，这些方法能够（1）更紧密地整合感知和控制，（2）在任务和本体之间进行适应，同时减少专家建模干预，以及（3）随着更多机器人数据的可用性，在性能上扩展。

机器人（强化）学习

强化学习通过试错法让机器人自主学习最优行为策略，在许多场景下展现了巨大潜力。

基于学习的机器人学通过训练一个（1）统一的高层控制器，能够直接处理（2）高维、非结构化的感知 - 运动信息，从而简化从感知到动作的过程。学习过程（3）无需动力学模型，而是聚焦于交互数据，并且（4）其效果与所用数据的规模呈经验性正相关。

然而，该教程也明确指出了其在现实世界中面临的瓶颈：一是安全与效率问题，尤其是在训练初期，机器人可能因探索性动作造成硬件损伤；二是高昂的试错成本，尤其是在真实物理环境中。

为解决这些问题，教程介绍了一系列前沿技术，例如通过模拟器训练来规避物理风险，并利用「域随机化」技术来缩小模拟与现实之间的差距。

同一运动任务可在训练阶段于不同（仿真）域中执行（以地形差异为例），从而提升对多样化环境动态的鲁棒性。

此外，教程还重点介绍了「离线到在线」（Offline-to-Online）强化学习框架，该框架利用预先收集的专家数据来引导学习过程，显著提升了样本效率和安全性。

其中，HIL-SERL（Human-in-the-Loop, Sample-Efficient Robot Reinforcement Learning）方法作为典型案例被详细阐述，该方法通过在训练中引入人类监督和干预，使得机器人在短短 1-2 小时内就能掌握复杂的真实世界操作任务，成功率接近 100%。

(A) HIL-SERL 通过借鉴 SAC、RLPD 和 SERL 的最新进展，实现了在现实世界中对高性能 RL 智能体的训练。 (B) 在真实 SO-100 上进行 HIL-SERL 训练过程中的人类干预示例。

机器人（模仿）学习

与强化学习不同，模仿学习为机器人提供了一条更为直接的学习路径，即通过「行为克隆」来复现专家操作。教程指出，模仿学习的核心优势在于它完全规避了复杂的奖励函数设计，并通过直接学习专家数据来确保训练过程的安全性。

然而，简单的行为克隆也面临两大挑战：一是「复合误差」，即微小的预测偏差会在序贯决策中被放大；二是难以处理专家演示中的「多模态」行为，例如，同一个任务目标可以通过多种不同的有效动作序列完成。

教程详细介绍了一系列基于生成模型的先进模仿学习方法。

例如，Action Chunking with Transformers (ACT) 和 Diffusion Policy 等技术，通过学习专家行为的潜在分布而非单一的映射函数，来有效建模多模态数据。

ACT 中使用的 CVAE 编码器。输入的动作块首先被嵌入并与位置嵌入聚合，然后与嵌入的本体感知信息以及一个用于聚合输入层信息并预测风格变量 z 的可学习 [CLS] 标记一起处理。该编码器仅用于训练解码器，在推理阶段完全被忽略。

其中，Diffusion Policy 利用扩散模型生成动作序列，在模拟和真实世界的多种任务中表现出色，仅需 50-150 个演示（约 15-60 分钟的遥操作数据）即可完成训练。

Diffusion Policy 架构。将 H_o 个历史观测堆叠作为外部条件，用于对一组 H_a 个动作进行去噪。条件注入在 U-Net 块的每一层都执行。Diffusion Policy 仅需 T = 10 步去噪即可获得完整的动作块。

此外，教程还探讨了如何通过「异步推理」优化模型部署，有效提升机器人在资源受限环境下的响应速度和计算效率。

异步推理。异步推理栈示意图。注意，策略可以在远程服务器上运行，可能配备 GPU。

通用机器人策略

在模仿学习的基础上，教程进一步展望了机器人技术的未来：构建能够跨任务、跨设备的「通用机器人策略」，即机器人领域的「基础模型」。

这一方向的兴起源于大规模开放机器人数据集（如 Open X-Embodiment）的出现，以及强大的视觉 - 语言模型（VLM）的发展。

教程重点介绍了两种前沿的 VLA 模型：π₀ 和 SmolVLA。这两者均采用了混合专家（MoE）架构，将预训练的 VLM 作为强大的「感知主干」，负责理解视觉和语言指令，再结合一个专门的「动作专家」来生成精确的机器人控制指令。

π₀ 模型利用 Flow Matching 技术进行训练，并基于包含超过 1000 万个轨迹的大规模数据集进行预训练，展现了强大的少样本甚至零样本泛化能力。

π0 架构。视觉与语言 token 被送入 VLM 主干，该主干被禁止关注机器人本体感知状态与动作 token；后者转而输入架构内一个更小的权重子集，称为「动作专家」。该架构在 1000 万 + 条轨迹上以 Flow Matching 训练，数据来自封闭与公开数据集的混合。

SmolVLA 则代表了另一个重要趋势：模型的小型化和开源化。作为一个完全开源的项目，SmolVLA 在保证高性能的同时，参数量仅为 π₀的约七分之一，内存消耗降低了 6 倍，极大地降低了前沿机器人模型的应用门槛

SmolVLA 架构如 @shukorSmolVLAVisionLanguageActionModel2025 所示。它是一个紧凑的 MoE 模型，通过流匹配训练对动作块进行去噪。视觉与语言令牌输入 VLM 主干，通过注意力机制与本体感知及动作令牌共享信息。注意力专家在 VLM 主干视觉特征上交替使用 SA 与 CA 层进一步条件化。SmolVLA 跳过部分计算并压缩视觉令牌，内存占用仅为 π₀ 的 1/7（4.5 亿参数 vs. π₀ 的 33 亿）。

更多细节内容，代码示例等请参阅教程原文。

....

#DisCO

以判别式监督学习强化推理LLM，解决难度偏差和熵崩塌难题

作者介绍：德州农工大学博士生李港，专注于设计和应用高效算法到大规模机器学习和人工智能任务，包括增强大型基础模型的后训练算法、对抗性鲁棒学习算法和分布鲁棒性学习算法。曾发表数篇论文在 NeurIPS、ICML、KDD 等顶会，并作为主要贡献者之一发布了针对不平衡分类任务的知名软件包 LibAUC。

DeepSeek-R1 的成功吸引了人们对群体相对策略优化（GRPO）作为大型推理模型（LRM）强化学习方法的广泛关注。

在本文中，作者分析了二元奖励（binary reward）设置下的 GRPO 优化目标，发现了由其群体相对优势函数引起的问题难度偏差的固有局限性，并且揭示了 GRPO 与传统判别式监督学习方法之间的联系。

基于这些分析发现，作者提出了一个新颖的判别式约束优化（DisCO）框架来强化大型推理模型。该框架基于判别式学习的基本原则：增加正确答案的得分，同时减少错误答案的得分。

与 GRPO 及其变体相比，DisCO 具有以下优势：

它通过采用判别式优化目标完全消除了难度偏差；
通过使用非裁剪评分函数和约束优化方法，解决了 GRPO 及其变体的熵不稳定性，得到了长期稳定的训练动态；
它允许结合先进的判别式学习技术来解决数据不平衡问题，例如在训练过程中一些问题的错误答案远远多于正确答案。

在增强大型模型的数学推理能力方面的实验表明，DisCO 大幅优于 GRPO 及其改进版本（如 DAPO），在 1.5B 模型的六个基准任务中，平均增益比 GRPO 高 7%，比 DAPO 高 6%。值得注意的是，最大响应长度（max response length）为 8k 的 DisCO 甚至优于最大响应长度为 32k 的 GRPO。

论文以「5，5，5，5」的高分被 NeurIPS 2025 接收。

论文标题：DisCO: Reinforcing Large Reasoning Models with Discriminative Constrained Optimization
论文地址：https://arxiv.org/abs/2505.12366
开源模型地址：https://huggingface.co/collections/ganglii/disco-681b705decb9979e65614d65
GitHub 地址：https://github.com/Optimization-AI/DisCO

GRPO 的难度偏差问题分析

GRPO 的核心思想在于对输入问题 q 生成多个输出，并定义群体相对优势函数。当采用期望形式而非经验平均时，其优化目标为：

其中，

表示群体相对优势函数，

表示裁剪操作，

是冻结的参考模型。在二元奖励（binary reward）设置下，即奖励函数

时，上述目标可简化为（暂时忽略 KL 项后）：

其中：

是正确答案概率
是奖励为 1 的输出分布（正确答案）
是奖励为 0 的输出分布（错误答案）
和
是裁剪后的评分函数。

从上面的变式分析中，作者有两个重要发现：

1. 与判别式监督学习的联系

在上述优化目标

中，最大化

就是在增加正确答案的得分，同时减少错误答案的得分。这种优化目标与 AUC 最大化的判别式监督学习的思路不谋而合。

2. 难度偏差（Difficulty Bias）

在上述优化目标

中，

在每个问题上起到了加权作用，导致模型只重点学习「中等难度」的问题（如下图 a 所示）。然而实际训练过程有很多正确率相对较高或较低的问题却不被重视，使得学习效率下降。

当作者移除

进行实验发现，没有加权的变体「GRPO_RW」能够在更多的问题上实现 100% 正确率和更少的问题上实现 0% 正确率（如下图 c, d 所示），证实了不适当的加权的有害影响。

提出方法：判别式强化学习

1. 判别式目标函数（类似 AUC 优化）

基于上述与 AUC 最大化联系的分析发现，作者直接从判别式学习的原则重新设计了新的判别式强化学习框架：

为了避免其他研究发现的由裁剪操作引起的熵崩塌现象，作者设计选择非裁剪评分函数，例如：

对数似然 (log-L)：
似然比 (L-ratio)：

2. 基于 DRO 的判别式目标函数（类似局部 AUC 优化）

基于判别式学习原则设计目标函数的一个优点是能够利用文献中先进监督学习技术来改进训练。推理模型的强化学习微调的一个关键挑战就是稀疏奖励，这导致答案生成的不平衡。具体来说，对于一些问题，错误答案的输出的数量可能大大超过正确答案的数量，这反映了一个经典的数据不平衡问题。这个问题在判别式学习领域中得到了广泛的研究。

为了解决这个问题，作者利用局部 AUC 优化设计了分布鲁棒性优化（DRO）目标：

3. 约束优化（稳定训练）

为了稳定训练，作者借鉴 TRPO 中的信任域思想，加入 KL 散度约束，形成以下优化问题：

DisCO-b：
DisCO：

不同于 TRPO 的二阶优化方法，作者采用近期发展的一种非凸不等式约束优化策略，将约束替换为平滑的方形铰链惩罚项 (squred hinge penalty)：

其中

。在适当条件下，求解上述方形铰链惩罚目标可保证满足原始问题的 KKT 条件。

实验结果与分析

测试效果对比

作者采用平均 16 次输出的 Pass@1 作为评价指标，在六个数学基准数据集上评估了 DisCO 和其他基线方法。

从下表观察到，作者提出的 DisCO 方法始终显著优于其他基线方法。值得注意的是，训练和推理长度均为 8k 的 DisCO （log-L）比 GRPO 平均提高了 7％，超过了以最大 24k 长度训练并以 32k 长度评估的 DeepScaleR-1.5B-Preview。在 7B 模型实验中，DisCO 也大幅优于所有基线方法，比 GRPO 平均提高了 3.5％。

在上面这张表格中，作者展示了多种强化学习方法在 1.5B 模型上的效果对比。作者也加入了 OpenAI 的 o1-preview 模型作为参考基线。表中的 MRL（Max Response Length）表示训练或测试时使用的最大响应长度，限制模型能生成多长的推理结果。其中用阴影标注的模型，是其他团队所训练的成果，相应的指标也来自他们的原始论文或 DeepScalaR 项目。除了这些以外，其余结果要么来自现有模型的直接评估，要么是基于不同方法训练后得到的结果。值得注意的是，表格下半部分的所有方法，都是基于相同的数据集（DeepScaleR），对 DeepSeek-R1-Distill-Qwen-1.5B 模型进行微调的结果。其中，DS 是 DeepSeek-R1 的缩写，DSR 是 DeepScalaR 的缩写。

训练动态对比

随着大规模强化学习训练成为改进推理模型的核心技术，学习算法的稳定性至关重要，因为学习稳定性决定了学习算法是否适用于大规模训练。作者从训练奖励和生成熵的角度比较了不同方法的训练动态。

从下图对 1.5B 和 7B 模型进行微调的实验中，我们可以看到，由于 GRPO、GRPO-ER、Dr. GRPO 的熵崩塌和 DAPO 的熵过度增长，它们都只能获得早熟的确定性策略或高度随机的策略，所有基线都出现了过早饱和。使用 KL 散度正则化的 TRPA 在后面的步骤中也观察到不稳定的生成熵。

相比之下，作者提出的 DisCO 使用两种非裁剪评分函数的方法最为稳定，训练奖励不断增加，生成熵保持相对稳定。

上图展示不同方法在训练过程中的动态表现：左边两张图展示的是在训练 1.5B 模型时的训练情况，右边两张图则对应于训练 7B 模型。图 (a) 和 (c) 展示了训练奖励随训练步数的变化情况，奖励是对每一步中用于训练的问题所生成答案的平均得分。图 (b) 和 (d) 展示的是生成结果的熵值（反映输出的多样性）随训练步数的变化趋势。

消融实验

作者通过单独替换 DisCO 中的组件来分析每个组件的单独贡献。他们在 1.5B 模型上进行了实验，与 (1) 去除困难负样本权重的 DisCO-b 进行了比较；(2) 在 DisCO-b 中添加问题级权重偏差

，(3) 在 DisCO-b 中使用 KL-divergence 正则化替换 KL-divergence 约束，以及 (4) 在 DisCO-b 中分别使用

的裁剪评分函数。

从下图中可以看到，作者提出的每个组件在 DisCO 的改进中都很重要，其中使用非裁剪评分函数是至关重要的。

总结

在这项工作中，作者提出了一种新的判别式约束优化框架用于强化大型推理模型，避免了难度偏差和熵崩塌问题。数学推理实验表明，与 GRPO 及其最近的变体相比，本文方法具有显著的优越性。

虽然这项工作主要关注的是二元奖励，但是对于非二元奖励，可以考虑利用监督学习中排序目标函数或者其他新颖的评分函数来进行设计。作者将应用判别式约束优化微调更大的模型或其他推理任务留作后续研究。

....

#连马桶都会看图说话了，巨头敢卖，你敢坐么？

屎屁尿也是宝贵数据，卫浴巨头把AI放进厕所，看好「被动式、零交互」的健康场景。

据说，日本人来香港买楼，有一条隐形标配：TOTO 智能马桶，必不可少。

加热座圈、温柔清洗、播放自然声掩盖尴尬声音，TOTO 早就把如厕体验做成了一门细腻的生活艺术。

如今，这份高级感正被 AI 玩出戏剧感。

想象一个场景：你坐下如厕，马桶里的摄像头悄悄亮起，默默记录你的早间大事。

算法看懂你的尿液与粪便后，结果立刻飞向手机 App。

这一次，出手的是老牌卫浴巨头 Kohler（科勒）。

Kohler发布马桶相机Dekoda：599美元装在马桶里的健康监测器，能看便便、识别用户，当然，还要交订阅费。

他们把影像 AI 塞进了马桶——一台名为 Dekoda 的小相机，售价 599 美元。

核心卖点相当直球：拍照识别屎尿，分析肠道健康与身体含水状态，遇到可疑出血还能发出警报。

比如，根据检测结果生成补水评级，提醒是否该多喝水。

根据粪便的形状与颜色，提示肠道发炎、便秘、腹泻，乃至肠易激综合征（IBS）风险。

血尿，则是更严肃的信号，可能与肾脏疾病相关。

如果一家人共用同一个厕所，也不用担心数据混乱。

Kohler 为 Dekoda 配备了指纹识别功能，可自动区分用户身份。

支持电池与 USB 两种连接方式。

如果大家能接受在马桶边安装摄像头，这或许是把如厕变成持续健康监测的最低摩擦路径：

无需手动输入、数据客观真实、采样频次天然高。

当然，心理门槛自然不低。

Kohler 的说法是：摄像头只向下拍、不拍其他画面；所有数据都采用端到端加密，只看马桶里，不窥马桶外。

「看图说话」，还有更绝的

这条最有味道的赛道上，显然不止巨头在跑。

来自奥斯汀的初创公司 Throne（中文直译「王座」，名字相当贴切）也盯上了这门生意。 5 月，他们刚刚完成 400 万美元种子轮融资，投资人名单中甚至出现了传奇自行车手兰斯·阿姆斯特朗（患有睾丸癌）。

「王座」的设备同样安装在马桶边，镜头固定朝下，只拍马桶内的便便与尿液。

通过 AI 算法分析形态、颜色、流速、含水量等多维指标，系统可推断肠道健康、代谢状态，甚至脱水风险。

Throne 把这套底层算法称为「人工肠智能（Artificial Gut Intelligence）」。据说，算法由医生参与训练，能从排泄物中解读健康信号，连尿液中细微的纹理与色度变化，都被纳入身体含水判断参数。

公司目前仍处于预量产原型阶段，预计将在 2026 年 1 月推出首款产品。

其实，早在十几年前，已故的分子影像巨匠、斯坦福大学教授 Sanjiv 「Sam」 Gambhir 就在研发智慧马桶，并在五年前完成并测试了首个原型。

为了将粪便与本人进行匹配，它扫描的不是你的指纹，而是在座圈内部加入了肛门识别摄像头——通过肛纹进行身份验证。

理论依据很简单：每一个肛门，都是独一无二的。

马桶会同时捕捉尿液和粪便的视频数据（自动上传云端），通过算法分析「尿动力学」参数，包括流速、排泄时间与总量以及粪便稠度差异，用以区分健康与异常状态。

对于站立排尿者，双高速摄像头还能测量尿流速度、流量与持续时间。

原型机还内置尿液试纸模块，可检测特定分子特征：从白细胞计数、持续性血液污染，到蛋白质水平，这些指标都可用于提前预警感染、膀胱癌乃至肾功能衰竭。

首先，扫描仪会扫描的臀部来识别主体。然后，压力传感器会测量你坐着的时间以及你排便的时间。另一个传感器会监测你的尿流宽度和力度，颜色检测器则会识别排尿量是否在健康范围。还有一个传感器可以识别任何固体的形状和性质。该图还显示了一个指纹传感器和一个基于云的健康门户。

当然，这样的研究原型造价不菲，商业化依然是最大挑战。

如今，杜克大学的智能马桶实验室已将自家研发的技术授权给初创公司 Coprata，推进市场化落地。

从废物到数据金矿

从排泄物中提取健康信息，这个听起来略带荒诞的想法，其实有着的科学基础。

人体大约有三四十万亿个细胞，而在你的肠道里，却住着超过一百万亿个细菌——比人体细胞还多。

它们不仅负责分解食物、帮助消化，还在悄悄调控免疫系统、代谢，甚至影响情绪与思维。

通过合成或改造上千种代谢物，这些细菌像信使一样，与人体进行着持续而复杂的化学对话。换句话说，排泄物并非废物，而是一份生物化学报告书。

研究显示，肠道微生物与多种疾病密切相关。在结直肠癌的发生与进展中，它们扮演着关键角色。美国癌症协会曾指出，某些癌症甚至能通过排尿习惯的变化在早期被察觉。

如今，医生已经能通过分析排泄物中的特定生物标志物——如钙卫蛋白、乳铁蛋白、短链脂肪酸以及细菌 DNA 谱系——在无需侵入性检查的前提下，判断肠道炎症活跃度、疾病复发风险，甚至监测治疗反应。

在慢性消化系统疾病中，这种能力尤为重要。克罗恩病、溃疡性结肠炎、肠易激综合征（IBS）等疾病，往往伴随着菌群失衡、炎症指标升高与肠黏膜受损。

当然，这些公司也很聪明，智能马桶的定位非常谨慎——

它们强调健康管理，而非医疗诊断，目标是让异常被尽早发现，而不是直接替代临床检测。

这类产品的目标人群也非常明确。一方面是关注健康管理的老龄用户；另一方面，是患有慢性消化道疾病的群体。

对他们而言，即便监测结果尚不足以确诊，持续的数据追踪依然很有意义。

你的马桶，下一个被低估的健康入口

从马桶开始，如厕这件再日常不过的小事，正在被重新定义——

它正变成一个连续、零打扰、几乎无感的健康监测入口。

巨头的加入，意味着这场关于「看图说话」的马桶革命，正加速从概念走向产品化。

在健康科技的版图中，马桶其实属于持续健康监测（Continuous Health Monitoring）的一环，与智能手表、手环同属一个大类。

不同的是，手表可以摘下，而马桶——谁都必须用。正因为「无法不使用」，它在健康监测层面反而拥有了天然优势。

人们希望获得更精准的生理信号，却又不想被设备打扰。而马桶，恰好满足这些要求：你什么都不用做，数据自然生成，健康信息悄然记录。

在可穿戴设备之后，真正稀缺的，是这种被动式健康数据入口。智能马桶正是利用被忽视数据源的完美方式。

与此同时，随着硬件与算法成本的快速下降，这一切也变得可行。

而肠道健康关注度的提升、隐形失血等慢性风险的潜在价值，包括老龄化社会的来临，也让市场看到了新空间。

但在这条最私密的健康赛道上，能否跨过信任这道坎，才是真正的成败分水岭。

针对身份识别、样本分析等关键数据保护，Throne 强调，他们的系统只「看马桶里的事」。所有非相关画面会被算法自动识别并删除，只保留与排泄物相关的数据。

团队「不接触个人层级数据」，只分析经过去标识化处理的整体统计信息。

已故斯坦福教授 Sanjiv 「Sam」 Gambhir 表示，「除了您本人或您的医生，没有人会看到这些扫描结果。」

所有信息在上传云端前都经过匿名化处理，发送给医疗机构时也符合美国 HIPAA 医疗数据保护标准。

相比之下，卫浴巨头 TOTO 干脆放弃摄像头。

他们在喷嘴出口附近内置了一枚「便便扫描仪」：通过 LED 光源照射排泄物落入水中时的反射信号，再由算法推断形态、色阶与排出量。

这种光学传感方案天然规避了「拍到不该拍的」风险，也减少了厕纸等异物干扰。

TOTO 还参考并改良了英国的布里斯托大便分型法：从长度、宽度、轮廓等特征出发，建立七种类型标签——从「颗粒状」到「有裂纹」等都有定义。

排便量通过落下时间反推：少于 100 克为「少」，100 至 300 克为「中」，超过 300 克为「多」；

颜色则按亮度分为黄土色、棕色和深棕色。

当你坐下时，传感器自动启动，LED 灯照亮粪便，测量结果瞬间发送至手机 App。

应用会自动配对用户、生成排便日历，追踪趋势与异常，还能结合饮食与运动数据，给出生活方式优化建议。

隐私之外，算法的准确性和稳定性，是另一道门槛。

杜克大学的智能马桶实验室曾验证了这项技术的可行性：

在长达 10 个月的实验中，6 名志愿者共留下 474 次排便图像。算法结合深度学习分割与数学特征提取，对粪便形态进行量化分析。

结果显示，系统在识别异常便型时的准确率达到 94%，灵敏度 81%，特异性 95%。

但要走出实验室，还面临一系列现实挑战。

家庭环境中的光线复杂、马桶形态多样、镜头易污；算法如何在真实世界保持稳定识别？误报与漏报的比例对医疗决策是否安全？多用户识别、设备维护、数据同步体验是否足够顺滑？

Nice to have? Must have ?

在商业模式上，智能马桶的故事，才刚刚开始。

科勒的 Dekoda 只是入门票，真正的商业逻辑在后续订阅。设备已开启预售，售价599美元；此外，还需额外订阅，每年费用在 70 至 156 美元之间，视套餐而定。

Throne 的方案类似。设备定价 499 美元，早鸟价 299 美元，用户同样需要持续付费以解锁分析与健康追踪功能。

但现实是，目前对大多数人来说，它依然是「Nice to Have（可有可无）」，而非「Must Have（非装不可）」。

价格高、隐私敏感、使用习惯尚未形成，都是阻力。

多数厂商目前只提供数据检测与可视化报告，但差异化的关键仍在于服务体验，如结合在线健康咨询、处方开立、药物配送等服务，让用户真正感受到持续价值，将决定它能否从噱头变成刚需。

更长远的想象空间，是如何让数据流动起来。如果这些排泄数据能与保险产品、医院远程诊疗系统、甚至个性化营养建议平台串联，智能马桶就不只是一个设备，可能会成为健康生态的底层入口。

换句话说，未来的竞争，不在马桶里，而在马桶之外。

....

#Pico-Banana-400K

打造图像编辑领域的ImageNet？苹果用Nano Banana开源了一个超大数据集

苹果在大模型和大模型应用上总是慢人一步。

Apple Intelligence 发布也已经一年多了，除去其仍未能在国行设备上提供服务外，功能上也很难称得上有多好用。

就拿视觉生成类功能举例子，苹果的图像生成大概是这个画风：

但在开放研究领域里，苹果似乎一整个脱胎换骨，在纯粹的研究中经常会有一些出彩的工作。

但这次苹果发布的研究成果的确出人意料：

他们用谷歌的 Nano-banana 模型做个了视觉编辑领域的 ImageNet。

对于苹果用纳米香蕉和 Gemini 的事情，引发了网友遐想：

在文本引导的图像编辑的工作中，GPT4-o 和谷歌 Nano-banana 都能够实现令人惊艳的编辑效果，保留原图像的特征，实现高质量的新图像的生成。尤其是 Nano-banana，真正能被成为图像编辑的里程碑和新标杆。

但目前在研究界仍然缺乏针对图像编辑的，来自真实图像的大规模，高质量的开放数据集。

为此，来自苹果的研究团队提出 Pico-Banana-400K，一个包含 40 万张图像的基于指令的图像编辑综合数据集。

论文标题：Pico-Banana-400K: A Large-Scale Dataset for Text-Guided Image Editing
论文链接：https://arxiv.org/pdf/2510.19808

该数据集通过利用 Nano-Banana 在 OpenImages 实拍照片上生成多样化的编辑对构建而成。

与以往的合成数据集不同，Pico-Banana-400K 的独特之处在于对质量与多样性的系统化设计。苹果的研究团队采用精细的图像编辑分类体系，以确保编辑类型的全面覆盖；并通过基于多模态大模型的质量评分与人工精筛，实现内容一致性与指令忠实性的平衡。

数据集构成

单轮监督微调 (SFT) 子集包含 25.8 万个成功的单轮图像编辑示例，作为遵循指令的图像编辑模型的核心训练数据。此子集涵盖了 35 种编辑分类法的全部范围，并为模型训练提供强大的监督信号。

除了单轮编辑外，Pico-Banana-400K 还支持复杂的多轮编辑研究。数据集包含三个专门子集：

72K 多轮编辑集 —— 用于研究连续修改中的顺序编辑、推理与规划；

多轮 SFT 子集包含 7.2 万个按顺序进行的编辑交互示例，序列长度从 2 到 5 轮不等。对于每张采样的图像，随机选择 1-4 种额外的编辑类型以形成连贯的编辑序列。Gemini-2.5-Pro 为每一轮生成上下文感知指令，鼓励使用指代性语言以保持语篇连续性。该子集支持对迭代细化、上下文相关编辑以及跨多个编辑步骤的复杂推理进行研究。

56K 偏好集 —— 用于对齐研究与奖励模型训练；

偏好子集包含 5.6 万个示例，由原始图像、指令、成功编辑和失败编辑组成的三联体。这种独特的资源专为对齐研究而设计，可用于训练奖励模型和应用直接偏好优化（DPO）等对齐技术。这解决了现有数据集的一个关键空白，因为现有数据集通常只提供成功的编辑，而缺乏对比性的低质量编辑示例。

长短指令配对集 —— 用于发展指令重写与摘要能力。

通过提供这一大规模、高质量且任务丰富的资源，Pico-Banana-400K 为训练和评测新一代文本引导图像编辑模型奠定了坚实基础。

苹果不仅发布了一个数据集，还构建了一个能够自我编辑和评估的完整流程：

纳米香蕉负责进行编辑。Gemini 2.5 Pro 负责评判结果，失败会自动重试，直到通过。该流程真正实现端到端运行，全程无需人工干预。

来自 Pico-Banana-400K 数据集的单轮文本引导图像编辑示例。每一对图像展示了编辑结果（右）及其对应的原始图像（左）。该数据集涵盖多种编辑类型，包括光度调整、物体级操作、风格化变换以及场景或光照修改等。

图像编辑指令内容的分布情况

该数据集系统地映射为 35 种现实世界的编辑类型，涵盖了从全局色调变化到人类风格化和物体重新定位等所有方面。这就像向人工智能传授所有存在的 Photoshop 技能一样。

图像编辑分类。

如上表所示，每种操作都归属于其对应的类别。Count 表示在单轮编辑子集中，经 Gemini-2.5-Pro 评估器判定（符合指令且具备视觉质量）并在最多三次尝试内成功的样本数量。

若某个（图像，指令）对在三次生成尝试中全部失败，则被视为失败案例，并从公开数据集中剔除。若在获得成功结果前经历了一到两次失败尝试，则这些失败的编辑结果也会被保留下来，用于构建偏好数据（preference data）。

这里是一个很巧妙的地方，苹果保留了失败的编辑结果。

每个失败的编辑都与成功的编辑配对。因此，在该数据集上，不再只是训练模型「做得更好」，而是训练它们知道「更好」是什么样的。这是一种在多模态系统中构建判断力的方法。

偏好三元组示例。从左至右依次为：原始图像、中间面板中的自然语言指令（要求将粉白色吸管移动到最左边的玻璃杯中），以及模型生成的两种结果：一种是成功的编辑，准确完成了指令并保持了场景一致性；另一种是失败的编辑，未正确执行指令（位置或几何关系错误）。

偏好子集是该领域中一项极具价值的贡献。通过系统地收集成功与失败的编辑尝试，该数据集为人类对齐与偏好学习研究提供了可能。

失败的编辑通常表现出一些常见的失误类型，例如未能完整遵循指令、出现视觉伪影或与原图内容融合不佳。这些数据可用于训练能够理解人类编辑质量判断的奖励模型，或用于应用 DPO 等技术，从而提升模型与人类偏好的对齐程度。

数据分析

各编辑类型的成功率

研究团队评估了数据集中不同编辑类型的成功率。如图所示，呈现出一致的规律：全局外观和风格编辑较为容易，而需要精细空间控制、布局或符号一致性的编辑仍然具有挑战性。

容易：全局编辑与风格化

全局编辑的可靠性最高。强艺术风格迁移的成功率为 0.9340，胶片颗粒 / 复古效果为 0.9068，现代↔历史风格互转为 0.8875。这些操作主要调整全局纹理、色彩统计和色调，对空间推理或显式目标协调的需求较低。

中等：对象语义与场景上下文

语义上有针对性但较粗粒度的编辑总体表现稳健。移除物体的成功率为 0.8328，替换类别为 0.8348。场景级修改（如季节变换 0.8015、照片→卡通 / 素描 0.8006）表现相似。典型失败案例源于仅文本条件下定位不准确（例如误改相邻区域）或轻微的颜色 / 纹理漂移。

困难：精确几何、布局与文字编辑

需要精细空间控制或符号正确性的编辑可靠性最低。移动物体最为困难，成功率仅 0.5923；改变尺寸 / 形状 / 方向为 0.6627，常出现透视不一致或拓扑断裂。外延绘制（outpainting）的成功率为 0.6634，常在边界连续性上出现问题。

文字编辑尤为脆弱：更改字体 / 样式的成功率最低，仅 0.5759；而翻译、替换或添加文本也不稳定，反映出在真实感图像中保持字形完整性、对齐和对比度的困难。

在人类风格化编辑中，皮克斯 / 迪士尼式 3D 风格（0.6463）和漫画夸张风格（0.5884）往往出现身份漂移或阴影伪影，尤其在形变较大时更明显。

排版仍然是多模态人工智能迄今为止最难的问题。

总结

该论文的主要贡献有：

1. 大规模可共享数据集：发布了 Pico-Banana-400K，包含约 40 万个基于真实图像构建的高质量图像编辑示例。数据集依据 35 类编辑类型分类体系进行系统组织，并通过自动化评分与人工核验实施严格的质量控制。

2. 多目标训练支持：除 25.8 万个单轮监督微调样本外，还提供 5.6 万对偏好样本（成功编辑 vs. 失败编辑），用于 DPO 和奖励建模等对齐方法的研究，从而支持模型在鲁棒性与偏好学习方面的探索。

3. 复杂编辑场景：收录了 7.2 万组多轮编辑序列，每个会话包含 2–5 次连续编辑，便于研究迭代式优化、上下文感知编辑与编辑规划等问题。所有样本均包含详细版与简洁版指令，以支持研究提示粒度对模型表现的影响。

Pico-Banana-400K 不仅仅是一个数据集，它是证明人工智能现在可以大规模生成和验证自己的训练数据，并且精确无误，无需人工监督。

苹果公司悄无声息地奠定了未来十年多模态学习的基础。

....

#Fast-dLLM v2

NVIDIA港大MIT联合推出：端到端吞吐量提升2.5倍

自回归（AR）大语言模型逐 token 顺序解码的范式限制了推理效率；扩散 LLM（dLLM）以并行生成见长，但过去难以稳定跑赢自回归（AR）模型，尤其是在 KV Cache 复用、和可变长度支持上仍存挑战。

Fast-dLLM v2 给出了一条务实路线：将预训练 AR 模型适配为适配为能并行解码的 Block-dLLM—— 且只需～1B tokens 量级的微调即可达到 “无损” 迁移，不必训练数百 B tokens（如 Dream 需～580B tokens）。在 A100/H100 上，它在保持精度的同时，将端到端吞吐显著拉高，最高可达 2.5×。

，时长00:50

作者单位：HKU、NVIDIA、MIT。

论文链接：https://arxiv.org/pdf/2509.26328

项目网站链接：https://nvlabs.github.io/Fast-dLLM/v2/

代码链接：https://github.com/NVlabs/Fast-dLLM

核心看点

少量数据适配（~1B tokens）：已有的 AR 模型（如 Qwen2.5-Instruct 1.5B/7B）用约 1B tokens 的微调就能适配成 Block Diffusion LLM，不必训练数百 B tokens（如 Dream 需～580B tokens）。
架构上 “AR 友好”：设计上块内双向、块间因果；配合互补掩码与 token-shift，让模型既保留 AR 的语义组织与可变长度能力，又获得块内并行带来的效率增益。迁移过程更自然、数据效率高。
层级缓存 + 并行解码：块级 KV Cache + 子块 DualCache，配合置信度阈值的并行解码，端到端最高 2.5× 提速。
大模型验证：在 7B 规模上保持与 AR 相当的生成质量下，吞吐对比 Qwen2.5-7B-Instruct 提升 2.54×。

原理与做法：从 AR 到 Block Diffusion

1）块式扩散与 AR - 友好注意力

Fast-dLLM v2 按固定块大小把序列切成若干块：块内双向注意力以并行去噪，块间保持左到右的因果关系，从而既能并行、又能沿用 AR 的语义组织、可变长度和 KV Cache；配合互补掩码（complementary masking）与 token-shift，保证每个 token 都在 “可见 / 被遮” 两种视角下学习，稳定恢复 AR 语义表征。

2）层级缓存（Hierarchical Cache）

块级缓存：已解码块的 KV 直接复用，天然支持 KV Cache。
子块缓存（DualCache）：在部分解码的当前块内部，同时缓存前缀与后缀的 KV 激活，减少迭代去噪揭示 / 复原时的重复计算，贴合并行细化流程。

3）置信度感知的并行解码

延续 v1 的思路：当某位置的预测置信度超过阈值（如 0.9），即可并行确定多个 token，其余不确定位置保留待后续细化。在 GSM8K 上，阈值 0.9 时吞吐从 39.1→101.7 tokens/s，提速约 2.6×，精度影响可忽略。

性能结果

端到端加速：综合实验显示，对标准 AR 解码最高 2.5× 提速，同时维持生成质量。
7B 规模吞吐与精度：在 A100 上，Fast-dLLM v2（7B）吞吐为 Qwen2.5-7B-Instruct 的 2.54×；同时对比 Fast-dLLM-LLaDA 还有 +5.2% 的准确率提升（GSM8K）。
Batch / 硬件可扩展性：在 A100/H100 上随 batch 增大，扩散解码的并行优势更明显；A100 上可达～1.5× 吞吐加速，H100 上最高可达～1.8× 加速。

Benchmark 综合得分：
1.5B：平均分 45.0，超过 Qwen2.5-1.5B 与 Qwen2.5-1.5B-Nemo-FT（使用相同的 LLaMA-Nemotron 后训练数据集上对 Qwen 做的标准 NTP 微调 baseline）；在同量级（≈1B 规模）的扩散类与 NTP 训练的 AR 类模型里，属于新的 SOTA。
7B：平均分 60.3，超过 Qwen2.5-7B-Nemo-FT（59.6）和 Dream（57.6）；多数单项基准上持平或更好。评测覆盖 HumanEval/MBPP、GSM8K/MATH、MMLU/GPQA、IFEval 等多项基准。

训练成本

数据 / 算力成本：以～1B tokens 量级微调把 AR 模型适配为 Block Diffusion LLM（对比 Dream 的～500B tokens），门槛显著降低；论文给出了 Qwen2.5-Instruct 1.5B/7B 在 64×A100 上的具体训练步数与配置，只需要几个小时即可完成训练，可复现性强。

总结

Fast-dLLM v2 提供了一条务实路线：用很少的数据（~1B tokens）把 AR 模型适配为 Block Diffusion LLM，相较等规模 AR 的端到端吞吐量约提升 2.5×，精度保持可比，并且关键开关（块大小、阈值、缓存）都能工程化地按目标调优，这是一个成本与收益比较均衡的解法。

....

#Inside vLLM

深度拆解，硬核解构，揭开vLLM推理系统实现高效吞吐的秘籍

在大模型应用快速发展的今天，如何让推理变得更快、更高效，已经成为研究和产业界共同关注的焦点。

vLLM 便是在这样的背景下诞生的一套高性能推理框架。它专门针对大语言模型的推理优化，在保持模型准确性的同时，大幅提升了吞吐量与响应速度。凭借对显存管理、并行调度和 KV 缓存等关键环节的创新，vLLM 已经成为业界广泛采用的开源推理引擎。

一篇超长的硬核博客文章：《Inside vLLM: Anatomy of a High-Throughput LLM Inference System》针对 vLLM 的架构、代码和原理进行了深入的分析，这可能是关于 LLM 推理引擎和 vLLM 工作原理的最深入解读。

本文作者是前 Google DeepMind 和 Microsoft 的研究工程师 Aleksa Gordć。

Aleksa 花了好些时间才达到对代码库的这种理解程度，充分低估了这篇文章的工作量，甚至这些内容很容易就能写成一本书。

博客标题：Inside vLLM: Anatomy of a High-Throughput LLM Inference System
博客链接：https://www.aleksagordic.com/blog/vllm

文中涵盖了：

推理引擎流程基础：包括输入 / 输出请求处理、调度（scheduling）、分页注意力（paged attention）、连续批处理（continuous batching）。
「高级」功能：分块预填充（chunked prefill）、前缀缓存（prefix caching）、引导式解码（guided decoding，基于语法约束的有限状态机 FSM）、推测解码（speculative decoding）、解耦的 P/D（prefill/decoding）。
扩展能力：从可以在单 GPU 上托管的小型模型，到参数量超过万亿的超大模型（通过张量并行 TP、流水线并行 PP、序列并行 SP 实现），最终扩展为多 GPU、多节点的部署方案。
Web 端部署与服务：从离线部署，到多个 API 服务器的在线服务；再到负载均衡（load balancing）、数据并行（DP）协调器，以及多引擎（multiple engines）部署架构。
推理系统性能测量：包括延迟（latency，涵盖首 token 时间 TTFT、迭代延迟 ITL、端到端 e2e、吞吐时间 TPOT）、吞吐量（throughput），以及 GPU 性能屋顶线模型（roofline model）。

这篇博客包含了大量的实例以及作者手绘的架构示意图和可视化图像，希望能够对读者们理解推理引擎提供一些有价值的帮助。

以下是博客的详细内容：

在这篇文章中，我会逐步介绍一个现代高吞吐量大语言模型（LLM, Large Language Model）推理系统的核心组件和高级特性。具体来说，我将详细拆解 vLLM 的工作原理。

这篇文章是系列中的第一篇。写作方式采用「倒金字塔结构」：先从宏观层面入手，再逐步深入细节。这样你可以在不被繁琐技术细节淹没的情况下，先建立起对整个系统的清晰整体认知。

LLM 引擎与引擎核心

LLM 引擎是 vLLM 的核心构建模块。单独使用时，它已经能够实现高吞吐量的推理 —— 但仅限于离线场景。此时，你还无法将其直接通过 Web 提供给用户。

接下来，我们将使用下面的离线推理代码片段（改写自 basic.py）作为示例进行讲解。

from vllm import LLM, SamplingParams
prompts = ["Hello, my name is","The president of the United States is",
]
sampling_params = SamplingParams(temperature=0.8, top_p=0.95)
def main():llm = LLM(model="TinyLlama/TinyLlama-1.1B-Chat-v1.0")outputs = llm.generate(prompts, sampling_params)
if __name__ == "__main__":main()

环境变量:

VLLM_USE_V1="1" # we're using engine V1VLLM_ENABLE_V1_MULTIPROCESSING="0" # we're running in a single process

这个配置的特点是：

离线：没有 Web 或分布式系统的支撑。
同步：所有执行都发生在一个单一的阻塞进程中。
单 GPU：没有数据并行、模型并行、流水线并行或专家并行（DP/TP/PP/EP = 1）。
使用标准 Transformer：如果要支持像 Jamba 这样的混合模型，就需要一个更复杂的混合 KV-Cache 内存分配器。

从这里开始，我们会逐步扩展，构建一个在线、异步、多 GPU、多节点的推理系统 —— 但仍然基于标准 Transformer。

在这个示例中，我们主要做两件事：

1. 实例化一个引擎（instantiate an engine）。

2. 调用它的 generate 方法，从给定的提示词（prompt）中进行采样。

接下来，让我们从构造函数（constructor）的分析开始。

LLM 引擎构造函数

引擎的主要组成部分包括：

vLLM 配置（vLLM config）：包含模型、缓存、并行等所有可调参数。
处理器（processor）：将原始输入转化为 EngineCoreRequests，过程包括校验、分词（tokenization）和预处理。
引擎核心客户端（engine core client）：在我们的示例中使用的是 InprocClient，它基本上等同于 EngineCore；后面我们会逐步扩展到 DPLBAsyncMPClient，它能支持大规模推理服务。
输出处理器（output processor）：将原始 EngineCoreOutputs 转化为用户最终可见的 RequestOutput。

引擎核心（engine core）本身由多个子组件构成：

模型执行器（Model Executor）：负责驱动模型的前向计算。当前我们使用的是 UniProcExecutor，它只在单 GPU 上运行一个工作进程（Worker）。后面我们会逐步扩展到 MultiProcExecutor，以支持多 GPU。
结构化输出管理器（Structured Output Manager）：用于引导式解码（guided decoding），后面章节会详细讲解。
调度器（Scheduler）：决定哪些请求进入下一步的引擎执行。它内部进一步包含：

1. 策略设置（policy setting）：可以是 FCFS（先来先服务），也可以是优先级调度（高优先级请求先执行）。

2. 等待队列与运行队列。

3. KV 缓存管理器（KV cache manager） —— 分页注意力（paged attention [3]）的核心。

其中，KV 缓存管理器会维护一个 free_block_queue —— 一个可用 KV 缓存块的池子（通常数量可达几十万甚至更多，具体取决于显存大小和块大小）。在分页注意力中，这些缓存块作为索引结构，负责将 token 映射到其计算得到的 KV 缓存块。

本节核心组件及其关系

标准 Transformer 层（非 MLA）的块大小（block size）计算公式如下：

2 * block_size (default=16) * num_kv_heads * head_size * dtype_num_bytes (2 for bf16)

在模型执行器（Model Executor）的构造过程中，会创建一个 Worker 对象，并执行三个关键步骤。（后续使用 MultiProcExecutor 时，这些步骤会在不同 GPU 上的每个工作进程中独立执行。）

1. 初始化设备（Init device）

分配一个 CUDA 设备（例如 "cuda:0"）给 Worker，并检查模型的数据类型（dtype）是否受支持（例如 bf16）。
根据设定的 gpu_memory_utilization（例如 0.8 → 使用 80% 的显存），验证是否有足够的显存可用。
设置分布式参数（数据并行 DP、张量并行 TP、流水线并行 PP、专家并行 EP 等）。
实例化一个 model_runner（包含采样器、KV 缓存、以及前向计算所需的 buffer，如 input_ids、positions 等）。
实例化一个 InputBatch 对象（包含 CPU 侧的前向计算 buffer、用于 KV 缓存索引的块表 block tables、采样元数据等）。

2. 加载模型（Load model）

实例化模型结构。
加载模型权重。
调用 model.eval（)（PyTorch 推理模式）。
（可选）对模型调用 torch.compile ()。

3. 初始化 KV 缓存（Initialize KV cache）

获取每一层的 KV 缓存规格。历史上通常是 FullAttentionSpec（同质 Transformer），但在混合模型（如滑动窗口、Transformer/SSM 混合模型 Jamba）中会更复杂（参考 Jenga [5]）。
运行一次虚拟 / 性能分析前向计算，并截取显存快照，用于计算可容纳的 KV 缓存块数量。
分配、重塑并将 KV 缓存张量绑定到注意力层。
准备注意力元数据（例如指定后端为 FlashAttention），在前向计算时由内核调用。
如果没有传入 --enforce-eager，则会对每个预热（warmup）批大小运行一次虚拟推理，并捕获 CUDA 图（CUDA graphs）。CUDA 图会记录整个 GPU 工作流程形成一个有向无环图（DAG）。在后续的前向计算中，系统会直接复用这些「预编译」的图，避免重复的内核启动开销，从而降低延迟。

这里我省略了一些底层细节，但以上就是需要重点掌握的核心部分。后续章节会多次引用这些概念。

既然引擎已经初始化完成，接下来我们就进入 generate 函数的解析。

Generate 函数

第一步：验证并将请求输入引擎

对于每个提示词（prompt），处理步骤如下：

1. 创建一个唯一的请求 ID，并记录其到达时间。

2. 调用输入预处理器（input preprocessor），对提示词进行分词（tokenization），并返回一个字典，内容包括：原始提示词、prompt_token_ids、以及输入类型（text、tokens、embeds 等）。

3. 将这些信息打包成一个 EngineCoreRequest，并添加优先级（priority）、采样参数（sampling params）以及其他元数据。

4. 将该请求传递到引擎核心（engine core），它会把请求封装成一个 Request 对象，并将其状态设为 WAITING。此时请求被加入到调度器的等待队列：

若为 FCFS（先来先服务）策略，则采用追加（append）；
若为优先级调度，则采用堆插入（heap-push）。

到这里，引擎已经接收请求，执行流程可以开始。

在同步引擎示例中，这些初始提示是唯一会被处理的请求 —— 中途无法再注入新的请求。

而异步引擎则支持这种操作（即连续批处理）：每一步之后，都会同时考虑新请求与旧请求。

由于前向传播（forward pass）会将批次展平成一个单一序列，并且自定义内核可以高效处理，所以即便是同步引擎，连续批处理也是在底层得到支持的。

之后，只要仍有请求需要处理，引擎就会反复调用 step () 函数。

每个 step 包含三个阶段：

1. 调度（Schedule）：选择本步骤要执行的请求（可能是解码 decode，或 / 和分块预填充 chunked prefill）。

2. 前向传播（Forward pass）：运行模型并采样新 token。

3. 后处理（Postprocess）：

将采样得到的 token IDs 附加到对应的请求上；
进行去分词（detokenize）；
检查停止条件（stop conditions）。
如果请求完成，执行清理操作（例如将其 KV 缓存块归还到 free_block_queue），并提前返回输出。

停止条件（Stop conditions）

- 请求超出了长度限制（max_model_length 或该请求的 max_tokens）。

- 采样到的 token 是 EOS ID（除非启用了 ignore_eos —— 在基准测试时强制生成指定数量的输出 token 时很有用）。

- 采样到的 token 匹配了采样参数中指定的 stop_token_ids。

- 输出文本中出现了 stop string：此时我们会将输出截断到首次出现 stop string 的位置，并在引擎中终止该请求。注意：stop_token_ids 会出现在最终输出中，而 stop string 不会。

接下来，我们将更深入地分析调度（scheduling）机制。

调度机制

推理引擎主要需要处理两类工作负载：

1. Prefill 请求 —— 对所有提示（prompt）token 执行一次前向传播。这类请求通常是计算受限（compute-bound）的（具体阈值取决于硬件和提示长度）。在完成 prefill 之后，会从最后一个 token 的概率分布中采样一个 token。

2. Decode 请求 —— 仅对最新生成的一个 token 执行前向传播。之前的 KV 向量已经被缓存好。这类请求则是内存带宽受限（memory-bandwidth-bound）的，因为即使只计算一个 token，也仍然需要加载全部 LLM 权重（以及 KV 缓存）。

在 V1 调度器中，由于更智能的设计，可以在同一个 step 中混合处理 prefill 与 decode 请求。而 V0 引擎在同一时刻只能处理 prefill 或 decode 二者之一。

调度器会优先处理 decode 请求（即那些已经在运行队列中的请求）。对于每个 decode 请求，它会：

1. 计算需要生成的新 token 数。

2. 调用 KV-cache 管理器的 allocate_slots 函数（下面详述）。

3. 更新 token 配额（token budget），减去第 1 步计算得到的 token 数量。

随后，调度器才会处理 prefill 请求（来自等待队列）：

1. 获取计算的块数（如果前缀缓存 prefix caching 被禁用，则返回 0 —— 细节后续介绍）。

2. 调用 KV-cache 管理器的 allocate_slots 函数。

3. 将请求从 waiting 队列弹出，移入 running 队列，并将其状态设置为 RUNNING。

4. 更新 token 配额。

接下来，我们看看 allocate_slots 函数的作用：

1. 计算需要的块数 —— 确定需要分配多少新的 KV-cache 块 (n)。默认每个块可以存储 16 个 token。例如，一个 prefill 请求包含 17 个新 token，则需要分配 ceil (17/16) = 2 个块。

2. 检查可用性 —— 如果管理器的池中没有足够的空闲块，则提前退出。根据请求类型（decode 或 prefill），引擎可能尝试重计算抢占（recompute preemption）（在 V0 中支持 swap preemption，即通过调用 kv_cache_manager.free 回收低优先级请求的 KV 块），或者跳过调度继续执行。

3. 分配块 —— 通过 KV-cache 管理器的协调器，从块池（即前面提到的 free_block_queue 双向链表）中取出前 n 个块。然后存储到 req_to_blocks 字典中，该字典映射 request_id → KV-cache 块列表。

KV cache 块的列表

前向传播流程

调用 model executor 的 execute_model，它会委托给 Worker，而 Worker 又会调用 model runner。主要步骤如下：

1. 更新状态

从 input_batch 中剪枝已完成的请求。
更新与前向传播相关的元数据（例如：每个请求对应的 KV-cache 块数量，用于索引到分块的 KV-cache 内存）。

2. 准备输入

将输入缓冲区从 CPU 拷贝到 GPU。
计算位置索引。
构建 slot_mapping（后续示例会讲）。
构造注意力元数据（attention metadata）。

3. 执行前向传播

使用自定义 paged attention 内核运行模型。
所有序列会被展平并拼接成一个长的「超级序列」 (super sequence)。
通过位置索引和注意力 mask 确保每个序列只关注自己的 token，这样就能在不使用右填充 (right-padding) 的情况下实现连续批处理 (continuous batching)。

4. 收集最后一个 token 的状态

提取每个序列在其最后位置的隐藏状态 (hidden states)。
计算 logits。

5. 采样 (sampling)

根据采样配置（greedy、temperature、top-p、top-k 等）从 logits 中采样出下一个 token。

前向传播的两种执行模式

1. Eager 模式：当启用 eager execution 时，直接运行标准的 PyTorch 前向传播。

2. Captured 模式：当不强制 eager 时，执行/重放预先捕获的 CUDA Graph。这些图在引擎构造过程中（初始化 KV-cache 的时候）已经捕获好。

接下来会给一个具体的例子，用于解释连续批处理 (continuous batching) 与 paged attention 的结合方式。

前向传播：连续批处理与分页注意力

高级功能 —— 扩展核心引擎逻辑

在已经掌握基本的引擎流程之后，我们可以进一步看看一些高级功能。

我们之前已经讨论过抢占（preemption）、分页注意力（paged attention）和连续批处理（continuous batching）。

接下来要深入介绍的功能包括：

1. 分块预填充（Chunked prefill）

2. 前缀缓存（Prefix caching）

3. 引导式解码（Guided decoding，基于语法约束的有限状态机 FSM）

4. 推测解码（Speculative decoding）

5. 解耦的预填充 / 解码（Disaggregated P/D，即 prefill/decoding 分离）

分块预填充

分块预填充是一种处理长提示词（prompt）的技术。它的核心思想是：把预填充步骤拆分为更小的块来执行。

如果没有这一步，我们可能会遇到一个非常长的请求，它会在一次引擎步骤中独占计算资源，导致其他预填充请求无法执行。这会推迟所有其他请求的执行，从而增加它们的延迟。

举个例子：假设我们让每个分块包含 n = 8 个 token，并用小写字母加 - 来表示分块。一个长提示词 P 可能表现为：x-y-z ，其中 z 是一个不完整的分块（例如只有 2 个 token）。

如果直接执行 P 的完整预填充，那么至少需要 3 个引擎步骤（甚至可能更多，如果它在某一步没有被调度执行）。而且，只有在最后一个分块的预填充步骤结束时，系统才会采样一个新的 token。

下面是这个例子的可视化示意：

实现方式其实很直接：限制每一步中新 token 的数量上限。

如果某个请求的新 token 数量超过了 long_prefill_token_threshold，系统就会把它重置为这个阈值。剩下的处理由之前介绍过的底层索引逻辑（indexing logic）自动完成。

在 vLLM V1 中，可以通过把 long_prefill_token_threshold 设置为一个正整数来启用分块预填充（chunked prefill）。（严格来说，即使没有主动设置，当提示词长度超过 token 配额时，系统也会自动截断，并以分块预填充的方式执行。）

（二级）前缀缓存

为了说明前缀缓存是如何工作的，我们先拿之前的代码示例，稍微改动一下：

from vllm import LLM, SamplingParams
long_prefix = "<a piece of text that is encoded into more than block_size tokens>"
prompts = ["Hello, my name is","The president of the United States is",
]
sampling_params = SamplingParams(temperature=0.8, top_p=0.95)
def main():llm = LLM(model="TinyLlama/TinyLlama-1.1B-Chat-v1.0")outputs = llm.generate(long_prefix + prompts[0], sampling_params)outputs = llm.generate(long_prefix + prompts[1], sampling_params)
if __name__ == "__main__":main()

前缀缓存的核心思想是：避免重复计算多个提示词（prompt）在开头部分共享的 token —— 这就是「前缀」的由来。

关键点在于 long_prefix：它被定义为长度超过一个 KV-cache 块的前缀（默认一个块是 16 个 token）。

为了简化例子，我们假设 long_prefix 的长度刚好等于 n × block_size（其中 n ≥ 1）。

也就是说，前缀和块的边界完全对齐。否则，系统就需要重新计算 long_prefix_len % block_size 这些 token，因为我们无法缓存不完整的块。

如果没有前缀缓存，每次处理一个拥有相同 long_prefix 的新请求时，系统都会重复计算全部 n × block_size 个 token。

而启用前缀缓存后，这些 token 只需计算一次（它们的 KV 会被存储在 KV 缓存的分页内存里），之后就能直接复用。这样，系统只需要处理新的提示词 token，从而显著加快预填充请求（prefill request）的速度（不过对解码请求没有帮助）。

在 vLLM 中，它是如何工作的？

在第一次调用 generate 时，在调度阶段（scheduling stage），kv_cache_manager.get_computed_blocks 会调用 hash_request_tokens：

1. 分块：该函数会把 long_prefix + prompts [0] 拆分为若干个 16-token 的块。

2. 计算哈希：

对每个完整的块计算一个哈希值（可使用内置哈希，或者更慢但碰撞率更低的 SHA-256）。
这个哈希由以下部分组合而成：前一个块的哈希值、当前块的 token 以及可选元数据。可选元数据包括：多模态哈希（MM hash）、LoRA ID、缓存盐值（cache salt，注入到第一个块的哈希中，用来确保只有带相同 cache salt 的请求才能复用该块）。

3. 存储结果：每个结果会被封装成一个 BlockHash 对象，包含哈希值和对应的 token IDs。函数最终返回一个 BlockHash 列表。这个列表会被存储在 self.req_to_block_hashes [request_id] 中。

接着，引擎会调用 find_longest_cache_hit 来检查这些哈希是否已存在于 cached_block_hash_to_block 中。

在第一个请求中，通常不会命中任何缓存。

然后，我们调用 allocate_slots，它会进一步调用 coordinator.cache_blocks：

这个函数会把新的 BlockHash 条目与分配到的 KV 块（KV blocks）关联起来。
同时，它会将这些映射记录在 cached_block_hash_to_block 中。

随后，在前向传播（forward pass）阶段，系统会在分页 KV 缓存（paged KV cache）中填充对应于刚分配的 KV 块的 K/V 值。

经过多次引擎步骤之后，系统可能会分配更多的 KV 缓存块，但这对我们当前的例子没有影响，因为在 long_prefix 之后，提示词立即发生了分支（diverge），不再复用之前的前缀块。

在第二次调用 generate 时，如果使用相同的前缀（prefix）：

步骤 1 到 3 会重复执行。
但是此时，find_longest_cache_hit 会在 n 个块中找到全部匹配（通过线性搜索）。
引擎可以直接复用这些 KV 块，无需重新计算前缀部分的 token。

如果原始请求仍然存在，这些 KV 块的引用计数（reference count）会增加（例如增加到 2）。

在这个例子中，第一个请求已经完成，因此这些块被释放回块池（pool），它们的引用计数也被重置为 0。

由于我们能够从 cached_block_hash_to_block 中检索到它们，这说明这些 KV 块仍然有效（KV-cache 管理器的逻辑就是这样设计的）。

因此，我们只需要再次将它们从 free_block_queue 中移除即可。

高级说明：

KV-cache 块只有在即将从 free_block_queue 重新分配时才会被标记为无效（free_block_queue 是从左侧 pop 块）。如果此时发现块仍然有相关的哈希值，并存在于 cached_block_hash_to_block 中，那么我们会：

清除该块的哈希值；从 cached_block_hash_to_block 中移除对应条目。

这样可以确保该块无法通过前缀缓存再次复用（至少不能用于旧前缀）。

总结一下前缀缓存（Prefix Caching）的核心思想：

不要重复计算已经出现过的前缀 token —— 直接复用它们在 KV 缓存中的值即可！

如果你理解了这个例子，也就理解了分页注意力（paged attention）的工作原理。

引导式解码（ FSM）

引导式解码是一种技术：在每一步解码（decoding step）时，logits 会受到基于语法的有限状态机（finite state machine, FSM）约束。

这确保了只有符合语法规则的 token 才能被采样。

这个机制非常强大：

可以强制遵循正规文法（Chomsky Type-3，例如任意正则表达式模式）。
也可以支持上下文无关文法（Context-Free Grammar, Type-2，覆盖大多数编程语言）。

为了让概念更直观，我们从最简单的例子开始，基于之前的代码示例进行说明：

from vllm import LLM, SamplingParams
from vllm.sampling_params import GuidedDecodingParams
prompts = ["This sucks","The weather is beautiful",
]
guided_decoding_params = GuidedDecodingParams(choice=["Positive", "Negative"])
sampling_params = SamplingParams(guided_decoding=guided_decoding_params)
def main():llm = LLM(model="TinyLlama/TinyLlama-1.1B-Chat-v1.0")outputs = llm.generate(prompts, sampling_params)
if __name__ == "__main__":main()

在我给出的示例（假设使用字符级 tokenization）中：在 prefill 阶段，FSM 会对 logits 进行掩码（mask），确保只有 "P" 或 "N" 是可选的。如果采样到了 "P"，FSM 就会切换到「Positive」分支；在下一步，FSM 只允许 "o" 被采样，以此类推。

FSM 示例

在 vLLM 中的实现方式：

1. 在 LLM 引擎构建阶段，会创建一个 StructuredOutputManager：它可以访问 tokenizer，并维护一个 _grammar_bitmask 张量（tensor）。

2. 当添加一个请求时：请求状态会被设置为 WAITING_FOR_FSM。grammar_init 会选择后端编译器（例如 xgrammar；注意，这些后端是第三方代码）。

3. 该请求的语法会异步编译。

4. 在调度阶段（scheduling）：

如果异步编译完成，状态切换为 WAITING，并将 request_id 添加到 structured_output_request_ids；
如果尚未完成，则将请求放入 skipped_waiting_requests，在下一次引擎步骤重试。

5. 调度循环结束后（仍在调度阶段）：如果存在 FSM 请求，StructuredOutputManager 会调用后端准备或更新 _grammar_bitmask。

6. 前向传播（forward pass）生成 logits 后：

xgr_torch_compile 的函数会将 _grammar_bitmask 扩展到词表大小（使用 32 位整数时，扩展比例为 32 倍）。
不允许的 token 的 logits 会被设置为 –∞。

7. 采样下一个 token 后：请求的 FSM 会通过 accept_tokens 前进一步。在 FSM 图上，状态会相应向下移动到下一节点。

步骤 6 的进一步说明：

如果 vocab_size = 32，则 _grammar_bitmask 是一个整数。其二进制表示用来编码哪些 token 允许（1），哪些禁止（0）。例如 "101…001" 会扩展成长度为 32 的数组 [1, 0, 1, …, 0, 0, 1]，位置为 0 的 token logits 被设置为 –∞。对于更大的词表，会使用多个 32 位整数，并进行扩展和拼接。后端（例如 xgrammar）负责根据当前 FSM 状态生成这些位模式。

为了直观展示，这里给出一个更简单的示例：vocab_size = 8；使用 8 位整数，适合喜欢可视化表示的读者。

在 vLLM 中，可以通过传入所需的 guided_decoding 配置来启用引导式解码（Guided Decoding）。

推测解码

在自回归生成（autoregressive generation）中，每生成一个新 token 都需要对大型语言模型（LLM）进行一次前向传播（forward pass）。

这非常耗时 —— 每一步都要重新加载并应用所有模型权重，仅仅为了生成一个 token！（假设 batch size = 1，一般情况是 B）

推测解码通过引入一个较小的草稿模型（draft LM）来加速这一过程：

草稿模型负责快速生成 k 个候选 token。
但我们并不最终从小模型中采样 token —— 它只是用来猜测可能的续写。
大模型仍然决定哪些 token 是有效的。

具体步骤：

1. Draft（草稿）：在当前上下文下运行小模型，提出 k 个 token 候选。

2. Verify（验证）：使用大模型在上下文 + k 个草稿 token 上运行一次。这会生成这 k 个位置的概率分布，再加一个额外位置（总共 k+1 个候选）。

3. Accept/Reject（接受 / 拒绝）：从左到右检查 k 个草稿 token：

如果大模型给该 token 的概率 ≥ 草稿模型概率，则接受；
否则以概率 p_large (token) /p_draft (token) 接受；
遇到第一个拒绝就停止，或者接受全部 k 个草稿 token。如果全部 k 个 token 都被接受，还可以「免费」采样第 k+1 个 token（因为我们已经计算过大模型分布）。如果有拒绝，则在该位置重新生成一个再平衡的概率分布（p_large - p_draft，最小值限制为 0，归一化到和为 1），并从中采样最后一个 token。

为什么可行？

虽然我们使用小模型来提出候选 token，但接受/拒绝规则保证了序列的期望分布与逐 token 从大模型采样完全一致。

也就是说，推测解码在统计上等价于标准的自回归解码。但它潜在更快，因为一次大模型前向传播可以生成最多 k+1 个 token。

注意，可以参考 gpt-fast 获取简单实现，原始论文提供了数学细节和等价性证明。vLLM V1 不支持 LLM 草稿模型方法，而是实现了更快但精度略低的候选方案：n-gram、EAGLE、Medusa。

各方法简述：

1. n-gram：

取最后 prompt_lookup_max 个 token，在序列中寻找先前匹配；
若找到，则提出该匹配后面的 k 个 token；
否则缩小窗口并重复，直到 prompt_lookup_min。
当前实现返回第一个匹配后的 k 个 token，可以考虑引入近期偏置（recency bias），反向搜索更自然（即寻找最后一次匹配）。

2. Eagle：

对大模型进行「模型手术」 —— 保留 embeddings 和 LM head，将 transformer 堆栈替换为轻量 MLP；
微调该 MLP 作为廉价草稿模型。

3. Medusa：

在大模型的 embeddings（LM head 前）上训练辅助线性头（linear heads），并行预测接下来的 k 个 token；
使用这些线性头比单独运行小模型更高效地提出 token。

下面是如何在 vLLM 中使用 n-gram 方法启用推测解码的示例：

from vllm import LLM, SamplingParams
prompts = ["Hello, my name is","The president of the United States is",
]
sampling_params = SamplingParams(temperature=0.8, top_p=0.95)
speculative_cnotallow={"method": "ngram","prompt_lookup_max": 5,"prompt_lookup_min": 3,"num_speculative_tokens": 3,
}
def main():llm = LLM(model="TinyLlama/TinyLlama-1.1B-Chat-v1.0", speculative_cnotallow=speculative_config)outputs = llm.generate(prompts, sampling_params)
if __name__ == "__main__":main()

在 vLLM 中是怎么实现的呢？

引擎构建阶段（Setup）

1. 初始化设备（Init device）：创建 drafter（草稿模型，例如 NgramProposer）和 rejection_sampler（拒绝采样器）。其中部分组件是用 Triton 实现的。

2. 加载模型（Load model）：加载草稿模型的权重（对于 n-gram 方法，这一步是无操作）。

在 generate 函数中处理新请求（假设是全新请求）

1. 使用大模型执行常规的 prefill 步骤。

2. 前向传播（forward pass）和标准采样完成后，调用 propose_draft_token_ids (k) 从草稿模型采样 k 个 draft token。

3. 将这些 token 存入 request.spec_token_ids（更新请求元数据）。

4. 在下一次引擎步骤，当请求进入运行队列（running queue）时，将 len (request.spec_token_ids) 加入「新 token」计数，以便 allocate_slots 为前向传播保留足够的 KV 缓存块（KV blocks）。

5. 将 spec_token_ids 复制到 input_batch.token_ids_cpu，形成上下文 + 草稿 token。

6. 通过 _calc_spec_decode_metadata 计算元数据，将 token 从 input_batch.token_ids_cpu 拷贝过来，准备 logits 等信息，然后对草稿 token 执行大模型前向传播。

7. 不是直接从 logits 采样，而是使用 rejection_sampler 从左到右进行接受 / 拒绝操作，生成最终的 output_token_ids。

8. 重复步骤 2–7，直到满足停止条件（stop condition）。

理解这一流程的最佳方式是启动调试器，逐步跟踪代码执行。不过这一节已经让你对推测解码在 vLLM 中的执行流程有了基本了解。

分离式 Prefill/Decode

我之前已经提到过分离式 Prefill/Decode 的设计动机。

Prefill 和 Decode 的性能特性非常不同：Prefill 主要受计算能力（compute-bound）限制；Decode 主要受内存带宽（memory-bandwidth-bound）限制。因此，将两者分离执行是一种合理的设计。这种设计可以更精细地控制延迟：TFTT（Time-To-First-Token，首个 token 时间）；ITL（Inter-Token Latency，token 间延迟）。

实际上，我们会启动 N 个 vLLM prefill 实例和 M 个 vLLM decode 实例，并根据实时请求负载自动伸缩。Prefill Worker 会将 KV 写入专用 KV-cache 服务；Decode Worker 从该服务读取 KV。这样可以将长且突发的 prefill 请求与延迟敏感的 decode 请求隔离开来，保证系统稳定性和低延迟。

在 vLLM 中的实现方式是怎么样的？

为了说明原理，下列示例使用 SharedStorageConnector，这是一个用于调试的 Connector 实现，用来演示内部机制。

Connector 是 vLLM 用于处理实例间 KV 交换的抽象接口。目前该接口尚未稳定，短期内会有一些改进，其中一些可能会引入破坏性变更。

我们启动 2 个 vLLM 实例（GPU 0：用于 prefill，GPU 1：用于 decode），然后在这两个实例之间传输 KV 缓存。

import os
import time
from multiprocessing import Event, Process
import multiprocessing as mp
from vllm import LLM, SamplingParams
from vllm.config import KVTransferConfig
prompts = ["Hello, my name is","The president of the United States is",
]
def run_prefill(prefill_done):os.environ["CUDA_VISIBLE_DEVICES"] = "0"sampling_params = SamplingParams(temperature=0, top_p=0.95, max_tokens=1)ktc=KVTransferConfig(kv_cnotallow="SharedStorageConnector",kv_role="kv_both",kv_connector_extra_cnotallow={"shared_storage_path": "local_storage"},)llm = LLM(model="TinyLlama/TinyLlama-1.1B-Chat-v1.0", kv_transfer_cnotallow=ktc)llm.generate(prompts, sampling_params)prefill_done.set()  # notify decode instance that KV cache is ready# To keep the prefill node running in case the decode node is not done;# otherwise, the script might exit prematurely, causing incomplete decoding.try:while True:time.sleep(1)except KeyboardInterrupt:print("Script stopped by user.")
def run_decode(prefill_done):os.environ["CUDA_VISIBLE_DEVICES"] = "1"sampling_params = SamplingParams(temperature=0, top_p=0.95)ktc=KVTransferConfig(kv_cnotallow="SharedStorageConnector",kv_role="kv_both",kv_connector_extra_cnotallow={"shared_storage_path": "local_storage"},)llm = LLM(model="TinyLlama/TinyLlama-1.1B-Chat-v1.0", kv_transfer_cnotallow=ktc)prefill_done.wait()  # block waiting for KV cache from prefill instance# Internally it'll first fetch KV cache before starting the decoding loopoutputs = llm.generate(prompts, sampling_params)
if __name__ == "__main__":prefill_done = Event()prefill_process = Process(target=run_prefill, args=(prefill_done,))decode_process = Process(target=run_decode, args=(prefill_done,))prefill_process.start()decode_process.start()decode_process.join()prefill_process.terminate()

注意：我也尝试过 LMCache，这是最快、可用于生产环境的 Connector（以 NVIDIA 的 NIXL 作为后端），但它仍处于前沿技术阶段，我在使用中遇到了一些 bug。由于其大部分复杂逻辑存在于外部仓库，SharedStorageConnector 更适合作为讲解示例。

在 vLLM 中的步骤如下：

1. 实例化（Instantiation） — 在引擎构建期间，Connector 会在两个地方创建：在 Worker 的 init device 过程中（位于 init worker distributed environment 函数下），角色为「worker」。在 Scheduler 构造函数中，角色为「scheduler」。

2. 缓存查询（Cache lookup） — 当 Scheduler 处理来自等待队列的 prefill 请求（经过本地 prefix-cache 检查后），会调用 Connector 的 get_num_new_matched_tokens：该函数检查 KV-cache 服务器中是否有外部缓存的 token。Prefill 在这里始终返回 0；decode 可能会命中缓存。结果会在调用 allocate_slots 之前加入本地计数。

3. 状态更新（State update） — Scheduler 然后调用 connector.update_state_after_alloc，记录已经命中缓存的请求（prefill 为无操作）。

4. 元信息构建（Meta build） — 在调度结束时，Scheduler 调用 meta = connector.build_connector_meta：Prefill 会将 is_store=True 的请求加入，用于上传 KV。Decode 会将 is_store=False 的请求加入，用于获取 KV。

5. 上下文管理器（Context manager） — 在前向传播之前，引擎会进入 KV-Connector 上下文管理器：进入（enter）：调用 kv_connector.start_load_kv。对于 decode，这会从外部服务器加载 KV 并注入到分页内存；对于 prefill，则无操作。退出（exit）：调用 kv_connector.wait_for_save。对于 prefill，这会阻塞直到 KV 上传至外部服务器；对于 decode，则无操作。

下面是一个可视化示例：

附加说明：对于 SharedStorageConnector 来说，「外部服务器」只是本地文件系统。根据配置，KV 传输也可以按层进行（在每个注意力层前或后）。Decode 仅在请求的第一步加载外部 KV；之后的步骤在本地计算和存储。

拓展系统：从UniProcExecutor到MultiProcExecutor

在掌握核心技术后，我们可以讨论如何扩展系统。

假设你的模型权重已经无法完全放入单个 GPU 的显存中：

第一个选项是使用张量并行（Tensor Parallelism, TP），将模型分片到同一节点的多张 GPU 上（例如 TP=8）。
如果模型仍然无法容纳，则下一步是在跨节点使用流水线并行（Pipeline Parallelism, PP）。

说明：

节点内带宽（intranode bandwidth）显著高于节点间带宽（internode bandwidth），这也是为什么通常更偏好张量并行（TP）而非流水线并行（PP）。（同时，PP 通信的数据量通常比 TP 少。）
我们不讨论 Expert Parallelism（EP），因为这里关注的是标准 Transformer 而非 MoE 模型，也不讨论序列并行（Sequence Parallelism），TP 和 PP 在实际中是最常用的。

在这个阶段，我们需要多个 GPU 进程（Workers）以及一个协调层来管理它们，而这正是 MultiProcExecutor 提供的功能。

MultiProcExecutor 在 TP=8 配置下（其中 driver worker 的 rank 为 0）

在 vLLM 中的工作原理：

1. 初始化消息队列 — MultiProcExecutor 会初始化一个 rpc_broadcast_mq 消息队列（底层通过共享内存实现）。

2. 生成子进程 — 构造函数循环遍历 world_size（例如 TP=8 ⇒ world_size=8），通过 WorkerProc.make_worker_process 为每个 rank 启动一个守护进程。

3. 创建通信管道 — 对每个 worker，父进程首先创建 reader 和 writer 管道。

4. 运行子进程 — 新进程执行 WorkerProc.worker_main，在其中实例化 worker（经历与 UniprocExecutor 相同的「init device」、「load model」等步骤）。

5. 确定角色并设置队列 — 每个 worker 判断自己是 driver（TP 组中的 rank 0）还是普通 worker。每个 worker 设置两条队列：

- rpc_broadcast_mq（与父进程共享）用于接收任务。

- worker_response_mq 用于发送结果回父进程。

6. 协调完成 — 初始化期间，每个子进程通过管道将 worker_response_mq 句柄发送给父进程。父进程收到所有句柄后解除阻塞，完成协调。

7. 执行任务循环 — Worker 进入忙等待循环，阻塞在 rpc_broadcast_mq.dequeue。当有任务到来时，执行任务（与 UniprocExecutor 类似，但现在是 TP/PP 特定的分区任务），结果通过 worker_response_mq.enqueue 发送回父进程。

8. 请求处理 — 运行时，当有请求到来，MultiProcExecutor 将其非阻塞地放入 rpc_broadcast_mq 给所有子 worker，然后等待指定输出 rank 的 worker_response_mq.dequeue 收集最终结果。

从引擎视角来看，接口没有变化 —— 所有的多进程复杂性都通过调用 model executor 的 execute_model 被抽象掉：

UniProcExecutor 情况：execute_model 直接调用 worker 的 execute_model。
MultiProcExecutor 情况：execute_model 间接通过 rpc_broadcast_mq 调用每个 worker 的 execute_model。

至此，我们可以使用相同的引擎接口运行尽可能大的模型，只受硬件资源限制。

下一步是横向扩展：启用数据并行（DP>1）在多个节点上复制模型，添加轻量级 DP 协调层，引入副本间的负载均衡，并在前端放置一个或多个 API 服务器来处理即将到来的流量。

分布式系统部署 vLLM

部署服务有很多方式，为了具体说明，这里给出一个示例：假设我们有两台 H100 芯片节点，并希望在它们上面运行四个 vLLM 引擎。如果模型需要 TP=4，我们可以将节点配置如下。

两台 8×H100 节点配置：节点 1：Headless（无前端 API），节点 2：API 服务器（负责接收外部请求）

在第一台节点上，以 headless 模式（无 API 服务器）运行引擎，使用以下参数：

vllm serve <model-name>--tensor-parallel-size 4--data-parallel-size 4--data-parallel-size-local 2--data-parallel-start-rank 0--data-parallel-address <master-ip>--data-parallel-rpc-port 13345--headless

在另一台节点上运行同样的命令，做如下调整：

去掉 --headless
修改 DP start rank

vllm serve <model-name>--tensor-parallel-size 4--data-parallel-size 4--data-parallel-size-local 2--data-parallel-start-rank 2--data-parallel-address <master-ip>--data-parallel-rpc-port 13345

注意：这假设网络已经配置好，所有节点都能访问指定的 IP 和端口。

vLLM 中的工作原理：

在 headless 服务器节点上，CoreEngineProcManager 会启动 2 个进程（根据 --data-parallel-size-local），每个进程运行 EngineCoreProc.run_engine_core。每个函数会创建一个 DPEngineCoreProc（引擎核心），然后进入其忙循环。

DPEngineCoreProc 会初始化其父类 EngineCoreProc（EngineCore 的子类），其主要步骤如下：

1. 创建 input_queue 和 output_queue（queue.Queue）。

2. 使用 DEALER ZMQ 套接字（异步消息库）与另一节点的前端进行初始握手，并接收协调地址信息。

3. 初始化 DP（数据并行）组（例如使用 NCCL 后端）。

4. 使用 MultiProcExecutor 初始化 EngineCore（如前所述，TP=4、4 个 GPU）。

5. 创建一个 ready_event（threading.Event）。

6. 启动一个输入守护线程（threading.Thread）运行 process_input_sockets (..., ready_event)。同样启动输出线程。

7. 主线程仍在等待 ready_event，直到跨 4 个进程（覆盖 2 个节点）的所有输入线程完成协调握手，然后执行 ready_event.set ()。

8. 一旦解除阻塞，向前端发送 "ready" 消息，并附带元数据（例如分页 KV 缓存中可用的 GPU 块数量）。

9. 主线程、输入线程和输出线程进入各自的忙循环。

总结：最终我们得到 4 个子进程（每个 DP 副本一个），每个进程运行主线程、输入线程和输出线程。它们完成与 DP 协调器和前端的协调握手，然后每个进程的三个线程进入稳定的忙循环状态。

分布式系统示例：4 个 DP 副本运行 4 个 DPEngineCoreProc

当前稳态（Steady State）:

输入线程（Input thread） — 阻塞在输入套接字上，直到 API 服务器路由一个请求过来；收到请求后，它会解码负载，通过 input_queue.put_nowait (...) 将工作项入队，然后回到套接字阻塞状态。
主线程（Main thread） — 当 input_queue.get (...) 被唤醒时，将请求传入引擎；MultiProcExecutor 执行前向推理，并将结果入队到 output_queue。
输出线程（Output thread） — 当 output_queue.get (...) 被唤醒时，将结果返回给 API 服务器，然后恢复阻塞。

附加机制：

DP 波计数器（DP wave counter） — 系统跟踪「波次」；当所有引擎空闲时，它们进入静止状态，当新工作到达时计数器递增（有助于协调与指标统计）。
控制消息（Control messages） — API 服务器不仅可以发送推理请求，还可发送中止请求或其他控制 RPC。
锁步虚拟步骤（Dummy steps for lockstep） — 如果某个 DP 副本有工作，所有副本都会执行前向步骤；没有请求的副本执行虚拟步骤以参与必要的同步点（避免阻塞活跃副本）。

锁步说明（Lockstep clarification）：事实上，锁步主要用于 MoE 模型，其中专家层（Expert layers）形成 EP 或 TP 组，而注意力层（Attention layers）仍为 DP。当前即使在标准 DP 下也总是执行锁步，这只是因为「内置」非 MoE 的 DP 使用场景有限；在普通场景下，你完全可以运行多个独立的 vLLM，并进行负载均衡。

接下来，我们来看 API 服务器节点会发生什么。

API 服务节点

我们实例化一个 AsyncLLM 对象（一个基于 asyncio 的大语言模型（LLM）引擎封装）。内部会创建一个 DPLBAsyncMPClient（数据并行、负载均衡、异步、多进程客户端）。

在 MPClient 的父类内部，launch_core_engines 函数执行以下操作：

1. 创建启动握手所需的 ZMQ 地址（类似于无头节点中的设置）。

2. 启动一个 DPCoordinator 进程。

3. 创建一个 CoreEngineProcManager（与无头节点相同）。

在 AsyncMPClient（MPClient 的子类）内部：

1. 创建一个 outputs_queue（asyncio.Queue）。

2. 创建一个 asyncio 任务 process_outputs_socket，通过输出套接字与 4 个 DPEngineCoreProc 的输出线程通信，并将结果写入 outputs_queue。

3. 之后，再创建一个 asyncio 任务 output_handler（在 AsyncLLM 中），从 outputs_queue 读取信息，并最终将其发送到 create_completion 函数。

在 DPAsyncMPClient 中，我们创建一个 asyncio 任务 run_engine_stats_update_task，用于与 DP 协调器通信。

DP 协调器在前端（API 服务器）与后端（引擎核心）之间进行中介：

定期向前端的 run_engine_stats_update_task 发送负载均衡信息（队列大小、等待 / 运行的请求数）。
处理前端发送的 SCALE_ELASTIC_EP 命令，通过动态改变引擎数量进行扩缩（仅适用于 Ray 后端）。
发送 START_DP_WAVE 事件给后端（由前端触发），并回报波状态更新。

总结前端（AsyncLLM）运行的 asyncio 任务：

一类任务通过 generate 路径处理输入请求（每个新客户端请求会生成一个新的 asyncio 任务）。
两个任务 (process_outputs_socket, output_handler) 处理底层引擎的输出消息。
一个任务 (run_engine_stats_update_task) 与 DP 协调器保持通信：发送波触发、轮询负载均衡状态、处理动态扩缩请求。

最后，主服务器进程创建一个 FastAPI 应用，并挂载诸如 OpenAIServingCompletion 和 OpenAIServingChat 的端点，暴露 /completion、/chat/completion 等接口。整个堆栈通过 Uvicorn 对外提供服务。

把这些环节串起来，就是完整的请求生命周期：

你从终端发送请求：

curl -X POST http://localhost:8000/v1/completions -H "Content-Type: application/json" -d '{"model": "TinyLlama/TinyLlama-1.1B-Chat-v1.0","prompt": "The capital of France is","max_tokens": 50,"temperature": 0.7
}'

接下来会发生什么：

1. 请求到达 API 服务器上的 OpenAIServingCompletion 的 create_completion 路由。

2. 该函数异步对提示词进行分词（tokenize），并准备元数据（请求 ID、采样参数、时间戳等）。

3. 然后调用 AsyncLLM.generate，其流程与同步引擎相同，最终会触发 DPAsyncMPClient.add_request_async。

4. 接着调用 get_core_engine_for_request，根据 DP 协调器的状态在各个引擎间做负载均衡（选择分数最低 / 负载最小的引擎：score = len (waiting) * 4 + len (running)）。

5. 将 ADD 请求发送到选定引擎的 input_socket。

6. 在该引擎中：

Input 线程 — 解除阻塞，从输入套接字解码数据，并将工作项放入主线程的 input_queue。
Main 线程 — 在 input_queue 上解除阻塞，将请求添加到引擎中，并反复调用 engine_core.step ()，将中间结果加入 output_queue，直到满足停止条件。

提醒：step () 会调用调度器（scheduler）、模型执行器（model executor，可为 MultiProcExecutor）等，我们之前已经讲过了。

Output 线程 — 在 output_queue 上解除阻塞，将结果通过输出套接字发送回去。

7. 这些结果触发 AsyncLLM 的输出 asyncio 任务（process_outputs_socket 和 output_handler），将生成的 token 传回 FastAPI 的 create_completion 路由。

8. FastAPI 附加元数据（完成原因、logprobs、使用信息等），通过 Uvicorn 返回 JSONResponse 到你的终端。

就这样，你的文本生成结果返回了 —— 整个复杂的分布式系统都被一个简单的 curl 命令隐藏了起来！😄

附加说明：

添加更多 API 服务器时，负载均衡在 OS / 套接字层处理。应用层感知不到复杂性，仍然是一条请求 - 响应流程。
使用 Ray 作为 DP 后端时，可以暴露 /scale_elastic_ep URL 接口，实现引擎副本数量的自动上下扩缩。

基准测试与自动调优 — 延迟 vs 吞吐量

到目前为止，我们一直在分析「气体粒子」—— 请求在引擎 / 系统内部的流动方式。现在，我们将视角拉远，看看整个系统，并思考：如何衡量推理系统的性能？

在最高层面上，有两个互相制约的指标：

1. 延迟（Latency） — 从请求提交到返回 token 的时间。

2. 吞吐量（Throughput） — 系统每秒能够生成或处理的 token/请求数量。

延迟对交互式应用最为重要，因为用户在等待响应。
吞吐量对离线工作负载更为关键，例如用于训练前 / 训练后的合成数据生成、数据清洗 / 处理，以及任何离线批量推理任务。

在解释为什么延迟和吞吐量存在竞争关系之前，我们先定义一些常见的推理性能指标：

下面是一个简化模型，用来解释延迟（Latency）和吞吐量（Throughput）之间的竞争关系。

假设：主导因素是权重（weight）I/O，而非 KV 缓存 I/O，也就是说我们处理的是短序列。

当观察批大小 B 对单次 decode 步骤的影响时，这种权衡就很明显了：

当 B↓趋近 1 时，每个 token 的间隔延迟（ITL, inter-token latency）下降：每步处理的工作量更少，token 之间不会互相「竞争」。
当 B ↑趋近无穷时，ITL 上升，因为每步要做更多 FLOPs，但吞吐量提高（直到达到峰值性能），原因是权重 I/O 被更多 token 分摊。

这里可以用 roofline 模型来帮助理解：

在饱和批大小 B_sat 以下，步骤时间主要受 HBM 带宽限制（权重逐层流入片上内存），因此步骤延迟几乎保持不变 —— 计算 1 个 token 和 10 个 token 所需时间相近。
超过 B_sat 后，kernel 开始受计算能力限制，步骤时间大约随 B 增长，每增加一个 token 都会增加 ITL。

Roofline 性能模型

注意：为了更严谨的分析，我们必须考虑 kernel 自动调优（kernel auto-tuning）：随着批量大小 B 增大，运行时可能针对当前形状切换到更高效的 kernel，从而改变实际达到的性能 P_kernel。每步延迟为 t = FLOPs_step / P_kernel，其中 FLOPs_step 是该步的计算量。你可以看到，当 P_kernel 达到峰值 P_peak 时，每步增加的计算量会直接导致延迟上升。

如何在 vLLM 中做基准测试

vLLM 提供了一个 CLI： vllm bench {serve,latency,throughput} ，它封装了 vllm/benchmarks/{server,latency,throughput}.py 脚本。

这些脚本的作用如下：

latency — 使用短输入（默认 32 tokens）并生成 128 个输出 token，使用小批量（默认 8）。运行多次迭代，并报告整个 batch 的端到端延迟。
throughput — 一次性提交固定的 prompt 集（默认 1000 个 ShareGPT 样本，等价于 QPS=∞ 模式），并报告输入 / 输出 / 总 token 数以及每秒请求数。
serve — 启动 vLLM 服务器，模拟真实工作负载：请求间隔时间从 Poisson 或 Gamma 分布采样。它会在时间窗口内发送请求，测量前面讨论的所有指标，并可选择在服务器端设置最大并发量（例如通过 semaphore 限制为 64 个并发请求）。

下面是如何运行 latency 脚本的示例：

vllm bench latency--model <model-name>--input-tokens 32--output-tokens 128--batch-size 8
}'

CI 中使用的基准测试配置存放在 .buildkite/nightly-benchmarks/tests 目录下。

还有一个自动调优脚本，它会驱动 serve 基准测试以寻找满足目标 SLO 的参数设置（例如，「在保持 p99 端到端延迟 < 500 ms 的前提下最大化吞吐量」），并返回推荐配置。

尾声

我们从基础的引擎核心（UniprocExecutor）开始，添加了诸如投机解码（speculative decoding）和前缀缓存（prefix caching）等高级功能，随后扩展到 MultiProcExecutor（TP/PP > 1），最终实现分布式扩展，将所有内容封装在异步引擎和分布式服务栈中 —— 最后介绍了如何衡量系统性能。

vLLM 还包含一些本文未详述的专门处理，例如：

自定义硬件后端：TPU、AWS Neuron（Trainium/Inferentia）等
架构 / 技术：MLA、MoE、编码器 - 解码器（例如 Whisper）、池化 / 嵌入模型、EPLB、m-RoPE、LoRA、ALiBi、无注意力变体、滑动窗口注意力、多模态大语言模型，以及状态空间模型（例如 Mamba/Mamba-2、Jamba）
TP/PP/SP
混合 KV-cache 逻辑（Jenga）、更复杂的采样方法如 beam sampling 等
实验性功能：异步调度

好处是，这些大部分与上文描述的主流程是正交的 —— 你几乎可以把它们当作「插件」来使用（当然实际上仍有一些耦合）。

我非常喜欢理解系统。话虽如此，在这个高度上讲解的细节肯定有所损失。接下来的文章里，我会聚焦具体子系统，深入探讨细节。

参考文献：

1. vLLM https://github.com/vllm-project/vllm

2. "Attention Is All You Need", https://arxiv.org/abs/1706.03762

3. "Efficient Memory Management for Large Language Model Serving with PagedAttention", https://arxiv.org/abs/2309.06180

4. "DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model", https://arxiv.org/abs/2405.04434

5. "Jenga: Effective Memory Management for Serving LLM with Heterogeneity", https://arxiv.org/abs/2503.18292

6. "Orca: A Distributed Serving System for Transformer-Based Generative Models", https://www.usenix.org/conference/osdi22/presentation/yu

7. "XGrammar: Flexible and Efficient Structured Generation Engine for Large Language Models", https://arxiv.org/abs/2411.15100

8. "Accelerating Large Language Model Decoding with Speculative Sampling", https://arxiv.org/abs/2302.01318

9. "EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty", https://arxiv.org/abs/2401.15077

10. "Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads", https://arxiv.org/abs/2401.10774

11. LMCache, https://github.com/LMCache/LMCache

....

#谷歌版GPT-4o和AI手机全上市了

Gemini Live 对标 GPT-4o，谷歌 AI 手机全家桶上线。

在 GPT-4o 进 iPhone 之前，谷歌 Gemini 抢先了一步完成了手机版的落地。

周三凌晨，在人们期待 OpenAI 「草莓大模型」的时候，谷歌在 Made by Google 活动上正式发布了 Gemini Live，以及一系列 Pixel 硬件产品。

今天的活动，谷歌充满信心地进行了 100% 现场演示，虽然出现了一些小问题。

两次让手机识图（不过用的是三星），都失败了。

不过正如谷歌所说的，我们已经进入了「Gemini 的时代」。

在 Pixel 9 系列之后，今天发布的一系列 Gemini AI 功能也将随安卓 15 出现在各种 Android 手机上。

Gemini Live：对标 GPT-4o，即刻上线

Gemini Live 是谷歌针对 OpenAI 高级语音模式推出的一款产品，该功能与 ChatGPT 几乎完全相同，之前一直处于 alpha 测试阶段。

Gemini Live 提供了一种移动对话体验，可以让用户和 Gemini 展开自由流畅的对话，甚至可以像在普通电话中一样打断或改变话题，而无需打字。

谷歌在博客中这样描述：你可以与 Gemini Live （通过 Gemini app）交谈，并从 10 种新的自然声音中选择一种来回应，（而 OpenAI 仅提供 3 种声音）。你甚至可以按照自己的节奏说话，或者在回答过程中打断它并提出其他问题，就像在平时对话中一样。

Gemini Live 是可以直接唤醒的，你可以在应用程序在后台运行或手机锁屏时继续与 Gemini 对话，且对话可以随时暂停和恢复。

Gemini Live 还将与多种安卓应用的功能（如 Keep）集成，从而提高 Gemini 的可用性。

今日起，谷歌开始在 Android 手机的 Gemini Advanced 用户推出该功能，仅限英语，并将在未来几周内扩展到 iOS 和更多语言版本。

不过，在现场演示中，当现场人员问到演唱会海报的相关信息时，Gemini Live 失败了两次，需要演示者更换手机才能正常工作。虽然演示过程中遇到了一些问题，但最终成功了，Gemini Live 最终从图片中提取相关信息并连接日历，为用户提供了准确结果。3

值得注意的是，据产品经理 Leland Rechis 介绍，谷歌不允许 Gemini Live 模仿这 10 种声音以外的任何声音。谷歌这样做可能是为了避免与版权法发生冲突。此前，OpenAI 就因为使用了寡姐的声音而被后者告到法庭。

总体而言，该功能似乎是一种比使用简单的 Google 搜索更自然地深入研究主题的好方法。谷歌指出，Gemini Live 是 Project Astra 迈出的一步，Project Astra 是该公司在 Google I/O 期间首次亮相的多模态 AI 模型。目前，Gemini Live 仅支持语音对话，谷歌希望在未来增加实时视频理解功能。

𝗧𝗲𝗻𝘀𝗼𝗿 𝗚𝟰芯片加持，谷歌硬件全家桶来了

在 Gemini Live 推出的同时，谷歌也推出了新一代智能硬件设备，比苹果和华为更早。

今天凌晨新发布的硬件包括 Pixel 9、Pixel 9 Pro 和 Pixel 9 Pro XL，还有一款折叠屏手机 Pixel 9 Pro Fold，它们均由全新的 Google Tensor G4 芯片提供支持，可以带来各种生成式 AI 能力。

Pixel 9 手机采用全新外观，将摄像头置于正面和中心位置，改进了标志性的摄像头模组，提升了手感。谷歌宣称，这些手机的耐用性是 Pixel 8 的两倍。

这一次，Pixel Pro 机型首次提供两种不同尺寸：Pixel 9 Pro（6.3 英寸）和 Pixel 9 Pro XL（6.8 英寸），均配备了 Super Actua 显示屏、42 MP 前置摄像头。除了显示屏尺寸、充电速度和电池外，Pixel 9 Pro 和 Pixel 9 Pro XL 拥有相同的规格和功能。

值得注意的是，Pixel 9 手机采用谷歌全新的定制芯片 Tensor G4。这是全新一代高性能手机芯片，旨在改善日常用例，例如更快地打开应用程序、浏览网页等等。

Tensor G4 由 Google DeepMind 设计，三星代工生产，使用 Arm 架构。经过优化，G4 可运行最先进的人工智能模型。它将是第一款运行多模态 Gemini Nano 模型的处理器 —— 仅在手机端侧，就可以实现大模型理解文本、图像和音频等任务。

从目前的消息可知，Tensor G4 与前代产品相同，使用的核心是当前一代的技术 —— 这意味着它很快会在 9 月份成为落后的芯片组，名为 Mali 的静态 GPU 核心也意味着不支持光线追踪（支持的版本名为 Immortalis）。尽管如此，自己和自己比，相对前一代产品的性能提升还是很可观的。

当然，作为 DeepMind 参与研发的芯片，Tensor G4 拥有不错的 AI 算力，谷歌透露它拥有「业界领先」的每秒 45 token 输出速度。

为了确保设备上的 AI 体验运行顺畅，谷歌也升级了 Pixel 9 系列的内存，它们配备 12GB RAM，Pixel 9 Pro 和 Pixel 9 Pro XL 配备 16GB RAM。

Pixel 系列一直是谷歌技术应用的标杆，新的手机接入了 Gemini Live，且将在 8 月开卖。谷歌表示，Pixel 9 Pro、Pixel 9 Pro XL 和 Pixel 9 Pro Fold 用户在购买手机后均可享受一年的 Gemini Advanced 订阅。看来相比搭载 OpenAI 大模型的 iPhone 16 系列，谷歌这次做到了快人一步。

谷歌介绍了 Pixel 的一系列生成式 AI 能力。

其中，Pixel Studio 可以帮助你在手机上就能将想法转化为图像。它由运行在 Tensor G4 上的设备端扩散模型和云端的 Imagen 3 文本到图像模型相结合而成。

谷歌的文生图新模型 Imagen 3 最早是在 5 月份的 I/O 大会上发布的。该模型在生成细节、光照、干扰等方面进行了优化升级，并且理解 Prompt 的能力显著增强。随着今天的发布会，Google DeepMind 在 arXiv 上提交了 Imagen 3 的论文：

论文链接：https://arxiv.org/abs/2408.07009

Pixel Screenshots 可帮助你保存、整理和回忆想要记住的重要信息，以供日后使用。

假设你有朋友喜欢松鼠，她即将过生日。你可以在 Google Chrome 上寻找礼物，截取松鼠衬衫、松鼠杯垫等所有松鼠相关的东西的屏幕截图。Pixel Screenshots 将分析所有这些图像的内容，并帮你在应用中搜索这些信息。随后，你只需打开应用并搜索「松鼠」，这些结果就会弹出。它还会包含你找到的所有内容的链接，以及正在查看的内容的摘要和相关信息。

人们在手机上最常做的事情之一就是查看天气。Pixel Weather 可以提供更加精确的天气信息，Gemini Nano 还会生成自定义人工智能天气报告，让人们了解当天的天气情况。

在所有手机都卷的拍照上，Pixel 9 增加了 AI 拍摄功能来提升出片效率。

通常，集体照中会遗漏一位指定摄影师。使用 Add Me，你就可以与在场的每个人合影，而无需携带三脚架或向陌生人寻求帮助。

利用重新设计的 Panorama，现在即使在弱光下也能拍摄出细节丰富的照片。这是所有智能手机上质量最高的弱光全景图。

此外，Google Photos 中的 Magic Editor 具有新的编辑功能，你可以拍摄出想要的照片，自动取景功能可以重新构图，你只需输入想要看到的内容（例如：在空旷的田野中添加野花）即可以给照片重新构图，把想法变为现实。

大模型的智能通话记录现在也被集成在了安卓系统重。Clear Calling 功能进一步提高了音频质量，新的通话记录（Call Notes）功能会在用户挂断电话后立即发送私人摘要和完整的通话记录。因此，当你接到回电时，无需手忙脚乱地寻找纸笔进行记录。为了保护隐私，通话记录完全在设备上运行。

最新的 Pixel 9 设备是首批配备全新卫星 SOS 功能的 Android 手机，因此，即使没有移动网络，用户也可以通过卫星联系紧急救援人员并分享位置。卫星 SOS 将首先在美国的 Pixel 9 设备上推出，无论你使用的运营商套餐是什么。在 Pixel 上的前两年，此功能将免费提供。

最后是定价，Pixel 9、Pixel 9 Pro 和 Pixel 9 Pro XL 均已开放预订，起价分别为 799 美元、999 美元和 1099 美元。Pixel 9 和 Pixel 9 Pro XL 将于 8 月 22 日在 Google 商店和谷歌零售合作伙伴上市。Pixel 9 Pro 将于 9 月 4 日在美国上市，同时 Pixel 9 Pro Fold 也将在接下来的几周内在其他市场上市。

参考内容：

https://blog.google/products/pixel/google-pixel-9-pro-xl/

https://www.androidauthority.com/google-tensor-g4-explained-3466184/

....

#SWE-bench Verified

OpenAI「草莓」模型再次跳票，凌晨发布的SWE-bench Verified是个啥？

有人说，「我们期待的是草莓，但他们发布的是羽衣甘蓝。」我们来看看这个「羽衣甘蓝」是做什么用的。

一直以来，大模型的编程能力都备受关注，超强 AI 程序员 Devin 的问世更是将「AI 能否替代程序员」这一话题推上了风口浪尖。最近，Devin 也迎来了新对手 —— 初创公司 Cosine 推出的自主 AI 程序员 Genie。该公司表示，Genie 的表现轻松超越了 Devin，在第三方基准测试 SWE-bench 上的得分为 30%，而 Devin 的得分仅为 13.8%。

这个 SWE-Bench 是一个用于评估 LLM 解决 GitHub 上真实软件问题能力的基准测试数据集。它收集了来自 12 个流行的 Python 仓库的 2,294 个 Issue-Pull Request 对。在测试时，LLM 会拿到一个代码库和 issue 描述，然后生成一个补丁来解决 issue 描述的问题。这个数据集在 AI 编程能力的评估中已被广泛使用。

在 AI 编程能力进化的同时，这个基准也在进化。今天凌晨，网传的 OpenAI「草莓」模型再次跳票，但 OpenAI 确实发布了新东西，就是 SWE-Bench 的改进版本 ——SWE-bench Verified。

OpenAI 指出，原始的 SWE-bench 存在一些问题，可能导致模型的自主软件工程能力被低估。因此，在改进过程中，他们与 SWE-Bench 原作者合作，进行了人工筛选和改进，确保单元测试的范围适当且问题描述明确。

在 SWE-bench Verified 上进行的新测试中，很多 AI 编程智能体的得分都比原来要高。其中，UIUC 的无 Agent 方案 Agentless 甚至实现了得分翻倍，OpenAI 认为，这证明之前的基准确实存在低估 AI 编程能力的缺陷。

但对于蹲守「草莓」的全世界网友来说，这个发布还是过于敷衍了。有人说，「我们期待的是草莓，但他们发布的是羽衣甘蓝。」

关于 SWE-bench 的背景知识

SWE-bench 测试集中的每个示例都是根据 GitHub 上 12 个开源 Python 代码库中一个已解决的 GitHub issue 创建的。每个样本都有一个相关的拉取请求（PR），其中包括解决方案代码和用于验证代码正确性的单元测试。这些单元测试被称为 FAIL_TO_PASS 测试，因为在 PR 中的解决方案代码添加之前它们会失败，添加之后则会通过。每个样本还包括 PASS_TO_PASS 测试，这些测试在 PR 合并前后都会通过，用于检查 PR 是否破坏了代码库中与问题无关的其他功能。

在 SWE-bench 中，AI 智能体会获得来自 GitHub issue 的原始文本，即问题陈述，并可以访问代码库。给定这些信息，智能体必须编辑代码库中的文件以解决问题。

AI 智能体给出的编辑将通过运行 FAIL_TO_PASS 和 PASS_TO_PASS 测试来评估。如果 FAIL_TO_PASS 测试通过，这意味着编辑解决了问题。如果 PASS_TO_PASS 测试通过，则意味着编辑没有破坏代码库中无关的部分。要完全解决原始的 GitHub 问题，两组测试都必须通过。

提高 SWE-bench 稳健性、可靠性的三个改进方向

为了提高 SWE-bench 的稳健性和可靠性。开发团队确定了三个主要的改进方向：

用于评估解决方案正确性的单元测试通常过于具体，有时甚至与问题无关。这可能导致正确的解决方案被拒绝。
许多样本的问题描述不够明确，导致对问题是什么以及应该如何解决存在歧义。
有时很难为智能体可靠地设置 SWE-bench 开发环境，这会无意中导致单元测试失败，而不管解决方案如何。在这种情况下，完全有效的解决方案可能被评为不正确。

SWE-bench Verified

为了解决这些问题，OpenAI 启动了一项由专业软件开发人员进行的人工注释活动，对 SWE-bench 测试集中的每个样本进行了筛查，以确保单元测试的范围适当，问题描述清晰明确。

他们与 SWE-bench 的作者们一起发布了 SWE-bench Verified：这是 SWE-bench 原始测试集的一个子集，包含 500 个样本，这些样本已经通过了人工注释者的验证。这个版本取代了原来的 SWE-bench 和 SWE-bench Lite 测试集。此外，他们还在发布所有 SWE-bench 测试样本的人工注释。

他们还与 SWE-bench 的作者合作，为 SWE-bench 开发了一个新的评估工具，该工具使用容器化的 Docker 环境，使在 SWE-bench 上进行的评估变得更容易、更可靠。

工具地址：https://github.com/princeton-nlp/SWE-bench/tree/main/docs/20240627_docker

改进方法

OpenAI 与 93 位具有 Python 经验的软件开发人员合作，手动筛选 SWE-bench 样本，并对 SWE-bench 测试集中的 1699 个随机样本进行了注释，最终得到 SWE-bench Verified。

他们的方法是对 SWE-bench 测试集中的样本进行注释，以确保测试的公平性和准确性。具体来说，他们关注两个关键点：首先，评估问题描述是否足够详细，以防过于模糊的描述导致测试不公平；其次，检查 FAIL_TO_PASS 单元测试是否会错误地筛选掉有效的解决方案。

每个注释标准都有一个标签，范围为 [0, 1, 2, 3]，严重程度逐渐增加。标签 0 和 1 是次要的；标签 2 和 3 是严重的，表明样本在某些方面不充分，应该被丢弃。

此外，假设样本没有问题，OpenAI 会通过让注释者估计开发人员决定和实施解决方案需要多长时间来评估每个样本的难度。最后，OpenAI 提供了一个自由格式输入选项来标记样本的任何其他主要问题。

为了构建 SWE-bench Verified，OpenAI 从原始测试集中过滤掉问题陈述或 FAIL_TO_PASS 单元测试严重性为 2 或以上的任何样本，并且还过滤掉所有标记有其他严重问题的样本。

注释结果

按照新的标准，原始 SWE-bench 中的样本有很大一部分是不合格的。如图所示，38.3% 的样本因为问题陈述不够明确而被标记，61.1% 的样本因为单元测试可能会不公平地将有效的解决方案错误地标记为不正确而被标记（严重程度 2、3 两级加起来）。总体而言，他们的注释过程导致 68.3% 的 SWE-bench 样本因问题陈述不明确、单元测试不公平或其他问题而被过滤掉。

下图比较了原始 SWE-bench 数据集和新 SWE-bench Verified 数据集的难度分布。他们根据 1699 个样本的随机子集估算 SWE-bench 的难度分布。

从图上可以看出，在原始的 SWE-bench 数据集中，大多数（77.8%）样本的预计完成时间少于一个经验丰富的软件工程师一个小时的工作量。SWE-bench Lite 和新 SWE-bench Verified 数据集进一步增加了这一比例，预计超过一个小时才能解决的问题少于 10%。然而，这种变化背后的机制有着很大的不同：SWE-bench Lite 是对原始数据集的子采样，使基准测试变得更容易，而 SWE-bench Verified 则试图从数据集中移除不可行的样本。

各个智能体在 SWE-bench Verified 上的性能

在新的 SWE-bench Verified 数据集上，开发团队使用多个在原始 SWE-bench 排行榜上表现良好的开源支架测试了 GPT-4o 的性能。

结果发现 GPT-4o 在性能最佳的支架上的性能在 SWE-bench Verified 上达到 33.2%，是原始 SWE-bench 上 16% 分数的两倍多。总的来说，这证实了 OpenAI 最初的怀疑，即原始 SWE-bench 低估了智能体的能力。

值得注意的是，从 SWE-bench Lite 到 SWE-bench Verified 的跳跃并不那么明显，因为经过筛选，SWE-bench Lite 已经比完整数据集变得更容易。

按难度分层的性能分析

在 SWE-bench Verified 上进行评估时，性能的提高可能部分是由于测试样本的分布向更简单的样本倾斜。

OpenAI 通过绘制按难度分层的性能来调查这一点。如果新数据集只是改变难度分布以包含更简单的样本，则每个类别内的分层性能不会改变，就像从原始 SWE-bench 到 SWE-bench Lite 的情况一样。

相反，OpenAI 观察到，当转向 SWE-bench Verified 时，智能体在各个难度类别的性能均有所提高，这与预期效果一致，即从所有类别中移除不可能的样本，而不是简单地移除困难样本。

参考链接：https://openai.com/index/introducing-swe-bench-verified/

....

#开源版VITA

没有等来OpenAI开源GPT-4o

开源领域又传来好消息。

大语言模型 (LLM) 经历了重大的演变，最近，我们也目睹了多模态大语言模型 (MLLM) 的蓬勃发展，它们表现出令人惊讶的多模态能力。

特别是，GPT-4o 的出现显著推动了 MLLM 领域的发展。然而，与这些模型相对应的开源模型却明显不足。开源社区迫切需要进一步促进该领域的发展，这一点怎么强调也不为过。

本文，来自腾讯优图实验室等机构的研究者提出了 VITA，这是第一个开源的多模态大语言模型 (MLLM)，它能够同时处理和分析视频、图像、文本和音频模态，同时具有先进的多模态交互体验。

研究者以 Mixtral 8×7B 为语言基础，然后扩大其汉语词汇量，并进行双语指令微调。除此以外，研究者进一步通过多模态对齐和指令微调的两阶段多任务学习赋予语言模型视觉和音频能力。

VITA 展示了强大的多语言、视觉和音频理解能力，其在单模态和多模态基准测试中的出色表现证明了这一点。

除了基础能力，该研究在提升自然多模态人机交互体验方面也取得了长足进步。据了解，这是第一个在 MLLM 中利用非唤醒交互和音频中断的研究。研究者还设计了额外的状态 token 以及相应的训练数据和策略来感知各种交互场景。

VITA 的部署采用复式方案，其中一个模型负责生成对用户查询的响应，另一个模型持续跟踪环境输入。这使得 VITA 具有令人印象深刻的人机交互功能。

VITA 是开源社区探索多模态理解和交互无缝集成的第一步。虽然在 VITA 上还有很多工作要做才能接近闭源同行，但该研究希望 VITA 作为先驱者的角色可以成为后续研究的基石。

论文地址：https://arxiv.org/pdf/2408.05211
论文主页：https://vita-home.github.io/
论文标题：VITA: Towards Open-Source Interactive Omni Multimodal LLM

在上述视频中，用户可以和 VITA 进行无障碍的沟通，看到用户穿的白色 T 恤后，会给出搭配什么颜色的裤子；在被问到数学题时，能够实时查看题目类型，进行推理，然后给出准确的答案；当你和别人讲话时，VITA 也不会插嘴，因为知道用户不是和它交流；出去旅游，VITA 也会给出一些建议；在 VITA 输出的过程中，你也可以实时打断对话，并展开另一个话题。

在这个视频中，用户拿着一个饼干，询问 VITA 自己在吃什么，VITA 给出在吃饼干，并给出饼干搭配牛奶或者茶口感会更好的建议。

健身时，充当你的聊天搭子：

注：上述视频都是实时 1 倍速播放，没有经过加速处理。

根据用户提供的流程图，VITA 就能编写代码：

提供一张图片，VITA 也能根据图片内容回答问题：

还能观看视频回答问题，当用户抛出问题「详细描述狗的动作」，VITA 也能准确给出答案：

方法介绍

如图 3 所示，VITA 的整体训练流程包括三个阶段：LLM 指令微调、多模态对齐和多模态指令微调。

LLM 指令微调

Mixtral 8x7B 的性能属于顶级开源 LLM 中一员，因此该研究将其作为基础。然而研究者观察到官方的 Mixtral 模型在理解中文方面的能力有限。为了注入双语（中文和英文）理解能力，该研究将中文词汇量扩展到基础模型，将词汇量从 32,000 个增加到 51,747 个。在扩展词汇量后，研究者使用 500 万个合成的双语语料库进行纯文本指令微调。

多模态对齐

为了弥合文本和其他模态之间的表征差距，从而为多模态理解奠定基础。仅在视觉对齐阶段训练视觉连接器。表 1 总结了所使用的训练数据，除了纯文本部分。

视觉模态

首先是视觉编码器。研究者使用 InternViT-300M-448px 作为视觉编码器，它以分辨率 448×448 的图像作为输入，并在使用一个作为简单两层 MLP 的视觉连接器后生成了 256 个 token。对于高分辨率图像输入，研究者利用动态 patching 策略来捕捉局部细节。

视频被视作图像的特殊用例。如果视频长度短于 4 秒，则统一每秒采样 4 帧。如果视频长度在 4 秒到 16 秒之间，则每秒采样一帧。对于时长超过 16 秒的视频，统一采样 16 帧。

其次是视觉对齐。研究者仅在视觉对齐阶段训练视觉连接器，并且在该阶段没有使用音频问题。

最后是数据级联。对于纯文本数据和图像数据，该研究旨在将上下文长度级联到 6K token，如图 4 所示。值得注意的是，视频数据不进行级联。

级联不同的数据有两个好处：

它支持更长的上下文长度，允许从单个图像问题交互扩展到多个图像问题交互，从而产生更灵活的输入形式，并扩展上下文长度。
它提高了计算效率，因为视频帧通常包含大量视觉 token。通过级联图像 - 问题对，该研究可以在训练批中保持平衡的 token 数量，从而提高计算效率。

此外，该研究发现使用级联数据训练的模型与使用原始数据训练的模型性能相当。

音频模态

一方面是音频编码器。输入音频在最开始通过一个 Mel 滤波器组块进行处理，该块将音频信号分解为 mel 频率范围内的各个频带，模仿人类对声音的非线性感知。随后，研究者先后利用了一个 4×CNN 的下采样层和一个 24 层的 transformer，总共 3.41 亿参数，用来处理输入特征。同时他们使用一个简单的两层 MLP 作为音频 - 文本模态连接器。最后，每 2 秒的音频输入被编码为 25 个 tokens。

另一方面是音频对齐。对于对齐任务，研究者利用了自动语言识别（ASR）。数据集包括 Wenetspeech（拥有超过 1 万小时的多领域语音识别数据，主要侧重于中文任务）和 Gigaspeech（拥有 1 万小时的高质量音频数据，大部分数据面向英文语音识别任务）。对于音频字幕任务，研究者使用了 Wavcaps 的 AudioSet SL 子集，包含了 400k 个具有相应音频字幕的音频片段。在对齐过程中，音频编码器和连接器都经过了训练。

多模态指令微调

该研究对模型进行了指令调整，以增强其指令遵循能力，无论是文本还是音频。

数据构建。指令调优阶段的数据源与表 1 中对齐阶段的数据源相同，但该研究做了以下改进：

问题被随机（大约一半）替换为其音频版本（使用 TTS 技术，例如 GPT-SoVITS6），旨在增强模型对音频查询的理解及其指令遵循能力。

设置不同的系统 prompt，避免不同类型数据之间的冲突，如表 2 所示。例如，有些问题可以根据视觉信息来回答或者基于模型自己的知识，导致冲突。此外，图像数据已被 patch，类似于多帧视频数据，这可能会混淆模型。系统 prompt 显式区分不同数据类型，有助于更直观地理解。

为了实现两种交互功能，即非唤醒交互和音频中断交互，该研究提出了复式部署框架，即同时部署了两个 VITA 模型，如图 1 所示。

在典型情况下，生成模型（Generation model）会回答用户查询。同时，监控模型（Monitoring model）在生成过程中检测环境声音。它忽略非查询用户声音，但在识别到查询音频时停止生成模型的进度。监控模型随后会整合历史上下文并响应最新的用户查询，生成模型和监控模型的身份发生了转换。

实验评估

语言性能。为了验证语言模型训练过程的有效性，研究者使用了四个数据集，分别是 C-EVAL、AGIEVAL、MMLU 和 GSM8K。这些数据集涵盖了各种场景，包括一般选择题、多学科问答题以及数学和逻辑推理任务，同时覆盖了中英文上下文。

下表 3 的结果表明，本文的训练显著增强了语言模型在中文评估集（C-EVAL 和 AGIEVAL）上的能力，同时保持了在英文相关基准（MMLU）上的原始性能水平，并在数学推理任务（GSM8K）上实现显著提升。

音频性能。为了验证模型学得的语音表示的稳健性，研究者在 Wenetspeech 和 Librispeech 两个数据集上进行了测试。

其中 Wenetspeech 有两个评估指标，分别是 test_net 和 test_meeting，前者数据源与训练数据更加一致，因而更容易；后者提出了更大的挑战。作为模型的 held-out 数据集，Librispeech 评估了模型在未见过数据集上的泛化能力，它有四个评估集，以「dev」开头的是验证集，以「test」开头的是测试集，「Clean」代表挑战性较低的集，「other」代表挑战性更高的集。

从下表 4 的结果可以看到，VITA 在 ASR 基准测试上取得了非常不错的结果。

多模态性能。为了评估多模态能力，该研究在四个基准上评估了 VITA，包括 MME 、OCRBench、HallusionBench 和 Video-MME。结果如图 5 所示。

在图像理解方面，VITA 优于图像专用开源模型 LLaVA-Next，并且接近闭源模型 Gemini 1.5 Pro。

在视频理解方面，VITA 超过了视频开源模型 Video-CCAM。尽管 VITA 和视频专用的 LLaVA-Next-Video 之间存在差距，但考虑到 VITA 支持更广泛的模态并优先考虑可交互性，因而这是可以接受的。

最后，值得注意的是，目前开源模型与专有模型在视频理解能力方面仍存在较大差距。

....

#CRAB

同时操控手机和电脑，100项任务，跨系统智能体评测基准有了

跨平台的多模态智能体基准测试 CRAB 由 CAMEL AI 社区主导，由来自牛津、斯坦福、哈佛、KAUST、Eigent AI 等机构的研究人员合作开发。CAMEL AI 社区开发的 CAMEL 框架是最早基于大语言模型的多智能体开源项目，因此社区成员多为在智能体领域有丰富科研和实践经验的研究者和工程师。

AI 智能体（Agent）是当下大型语言模型社区中最为吸引人的研究方向之一，用户只需要提出自己的需求，智能体框架便可以调度多个 LLMs 并支持多智能体（Multi-agents）以协作或竞争的方式来完成用户给定的任务。

目前智能体已越来越多地与大型多模态模型 (MLM) 相结合，支持在各种操作系统（包括网页、桌面电脑和智能手机）的图形用户界面（ GUI）环境中执行任务。但是目前针对这种智能体性能评估的基准（benchmarks）仍然存在很多局限性，例如构建任务和测试环境的复杂性，评价指标的单一性等。

针对这些问题，本文提出了一个全新的跨环境智能体基准测试框架 CRAB。CRAB 采用了一种基于图的细粒度评估方法，并提供了高效的任务和评估器构建工具。本文的研究团队还基于 CRAB 框架开发了一个跨平台的测试数据集 CRAB Benchmark-v0，其中涵盖了可以在 PC 和智能手机环境中执行的 100 个任务，其中既包含传统的单平台任务，还包含了必须同时操作多个设备才能完成的复杂跨平台任务。

论文题目：CRAB: Cross-environment Agent Benchmark for Multimodal Language Model Agents
论文地址：https://arxiv.org/abs/2407.01511
代码仓库：https://github.com/camel-ai/crab

作者选取了当前较为流行的四个多模态模型进行了初步实验，实验结果表明，使用 GPT-4o 作为推理引擎的单智能体结构拥有最高的测试点完成率 35.26%。

引言

作为全新的智能体评估基准框架，CRAB（Cross-environment Agent Benchmark）主要用于评估基于多模态语言模型（MLMs）的智能体在跨环境任务中的表现。CRAB 可以模拟真实世界中人类用户同时使用多个设备完成复杂任务的场景，如 Demo 所示，CRAB 可以用来评估智能体同时操纵一个 Ubuntu 桌面系统和一个 Android 手机系统完成发送信息的过程。

想象一下，如果智能体具备根据人类指令同时精确操作电脑和手机的能力，很多繁杂的软件操作就可以由智能体来完成，从而提高整体的工作效率。为了达成这个目标，我们需要为智能体构建更加全面和真实的跨平台测试环境，特别是需要支持同时操作多个设备并且能提供足够的评估反馈机制。本文的 CRAB 框架尝试解决以下几个实际问题：

跨环境任务评估：现有的基准测试通常只关注单一环境（如网页、Android 或桌面操作系统）[1][2][3][4]，而忽视了真实世界中跨设备协作场景的复杂性。CRAB 框架支持将一个设备或应用的交互封装为一个环境，通过对多环境任务的支持，提供给智能体更丰富的操作空间，也更贴近实际应用场景。
细粒度评估方法：传统的评估方法要么只关注最终目标的完成情况（目标导向），要么严格比对操作轨迹（轨迹导向）[1][2][3]。这两种方法都存在局限性，无法全面反映智能体的表现。CRAB 提出了基于图的评估方法，既能提供细粒度的评估指标，又能适应多种有效的任务完成路径。
任务构建复杂性：随着任务复杂度的增加，手动构建任务和评估器变得越来越困难。CRAB 提出了一种基于子任务组合的方法，简化了跨环境任务的构建过程。
智能体系统结构评估：本文还探讨了不同智能体系统结构（单智能体、基于功能分工的多智能体、基于环境分工的多智能体）对任务完成效果的影响，为设计更高效的智能体系统提供了实证依据。

上表展示了本文提出的 CRAB 框架与现有其他智能体基准框架的对比，相比其他基准，CRAB 可以同时支持电脑和手机等跨平台的操作环境，可以模拟更加真实的使用场景。

对于 CRAB，一众网友给出了很高的评价。

有人表示，AGI 已经达成，因为有大语言模型（指 CRAB）已经学会了如何退出 Vim。

"Can you exit Vim?" 这个问题常常是一个编程或技术社区的玩笑，因为 Vim 对新手来说可能很难退出，尤其是当他们不熟悉 Vim 的操作模式时。（在此贡献一张表情包）

有人说很难相信一个智能体可以完成 “查看日历，打开 Vim，进入插入模式，输入事件列表，退出插入模式，并使用 :wq 保存” 这一系列任务。

也有网友总结说下个下一代机器人流程自动化（RPA）将更像是 “请帮我完成下列任务”，而不需要记录每一个步骤，然后在几天内运行时崩溃。

也有人提到了 CRAB 中的图评估器（Graph Evaluator）用于处理智能体在环境中的状态是一种非常智能的方式。

甚至有人夸赞道 CRAB 是 AI PC 的未来，认为这是 LLM 与 PC 和移动设备的完美结合，“它是一种类似 RabbitOS 的 AI，使现有的 PC 和移动设备具备 AI 功能。CRAB 的基准测试允许在现实世界中测试多模态语言模型代理的有效性和实用性。”

定义

任务定义

CRAB 框架将数字设备（如桌面电脑或智能手机）表示为一个具体的环境。每个环境被定义为一个无奖励的部分可观察马尔可夫决策过程（POMDP），可以使用元组

表示，其中

为状态空间，

为动作空间，

是转移函数，

是观察空间。

而对于跨环境任务，可以定义一个环境集合

其中 n 是环境数量，每个环境又可以表示为

。

基于以上，作者将一个具体的跨环境任务表示为元组

，其中 M 是环境集合，I 是以自然语言指令形式给出的任务目标，R 是任务的奖励函数。参与任务的智能体系统可以被建模为一个策略

。

这表示智能体在接收到来自环境

的观察

和动作历史 H 时，在环境 m 中采取动作 a 的概率。

图任务分解（Graph of Decomposed Tasks, GDT）

将复杂任务分解为几个更简单的子任务是 LLMs 解决实际问题时非常有效的技巧 [5][6]，本文将这一概念引入到了智能体基准测试中，具体来说，本文引入了一种分解任务图（Graph of Decomposed Tasks，GDT），如下图所示，它可以将一个复杂任务表示为一个有向无环图（DAG）的结构。

GDT 中的每个节点可以代表一个子任务 (m,i,r)，其中 m 为子任务执行的环境，i 为自然语言指令，r 是奖励函数，用于评估环境 m 的状态并输出布尔值，判断子任务是否完成。GDT 中的边表示子任务之间的顺序关系。

CRAB 框架

跨环境智能体交互

CRAB 首次引入了跨环境任务的概念，将多个环境（如智能手机和桌面电脑）组合成一个环境集合，使智能体能够在多个设备之间协调操作完成复杂任务。

在 CRAB 框架中使用基于环境分工的多智能体系统的运行流程如上图所示。工作流程通过一个循环进行，首先通过主智能体观察环境，并对子智能体指定计划，然后所有的子智能体在各自的环境中执行操作。随后由一个图评估器（Graph Evaluator）来监视环境中各个子任务的状态，并在整个工作流程中不断更新任务的完成情况。这种评估方式可以贴近真实场景，以考验智能体的推理能力，这要求智能体能够处理复杂的消息传递，并且需要深入理解现实世界的情况。

图评估器（Graph Evaluator）

CRAB 内置的图评估器同时兼顾了目标导向和轨迹导向评估的优点，其首先将复杂任务分解为多个子任务，形成一个有向无环图结构。随后定义了一种节点激活机制，即图中的节点（子任务）需要根据前置任务的完成情况逐步激活，确保任务的顺序执行。其中每个节点都关联了一个验证函数，用来检查环境中的关键中间状态。相比之前的评估基准，CRAB 图评估器创新性地引入了一系列新的评价指标：

完成率（Completion Ratio, CR）：完成的子任务节点数量与总节点数量的比率，CR = C / N。
执行效率（Execution Efficiency, EE）：完成率与执行的动作数量的比值，EE = CR / A，A 为指定的动作数。
成本效率（Cost Efficiency, CE）：完成率与使用的模型 token 数量的比值，CE = CR / T，T 为使用的模型 token 数量。

这些指标为智能体基准提供了更细粒度和更多维度的评估侧重点。

CRAB Benchmark-v0

基准构建细节

基于提出的 CRAB 框架，本文构建了一个具体的基准测试集 CRAB Benchmark-v0 用于社区进一步开展研究。CRAB Benchmark-v0 同时支持 Android 手机和 Ubuntu Linux 桌面电脑两个环境。并且为 Ubuntu 和 Android 定义了不同的动作集，用来模拟真实生活中的常见交互。其观察空间由两种环境的系统界面构成，并且使用屏幕截图形式获取环境状态。为了方便智能体在 GUI 中操作，作者使用 GroundingDINO [7] 来定位可交互图标，使用 EasyOCR 检测和标注可交互文本，为每个检测项分配一个 ID，方便后续在操作空间内引用。

我们以一个具体任务举例，例如在 Ubuntu 系统上完成如下任务：创建一个新目录 “/home/crab/assets_copy”，并将所有具有指定 “txt” 扩展名的文件从 “/home/crab/assets” 复制到目录 “/home/crab/assets_copy”。

该任务需要执行多步操作才能完成，下图展示了当使用 GPT-4 Turbo 作为推理模型并采用单智能体结构时的实验细节。智能体首先使用 search_application 命令查找终端并打开。

然后使用 Linux 命令 “mkdir -p /home/crab/assets_copy” 创建新的目标目录。

在创建好目标目录后，智能体直接在终端中执行了拷贝命令：

“cp /home/crab/assets/*.txt/home/crab/assets_copy” 来完成任务，整个流程行云流水，没有任何失误。

实验效果

作者随后在 CRAB Benchmark-v0 进行了 baseline 实验，智能体的核心是后端的多模态语言模型，其用来提供自然语言和图像理解、基本设备知识、任务规划和逻辑推理能力，需要支持多模态混合输入，可以同时处理多轮对话，因而作者选取了 GPT-4o (gpt-4o-2024-05-13)、GPT-4 Turbo (gpt-4-turbo-2024-04-09)、Gemini 1.5 Pro (2024 年 5 月版本) 和 Claude 3 Opus (claude-3-opus-20240229) 作为 baseline 模型。

实验结果如上表所示，其中 GPT-4o 和 GPT-4 Turbo 模型在测试模型中实现了最高的平均测试点完成率（CR）。在执行效率（EE）和成本效率（CE）方面， GPT-4 系列也相比 Gemini 和 Claude 系列模型更加优秀。

总结

本文介绍了一种全新的跨环境多智能体评估基准 CRAB，CRAB 框架通过引入跨环境任务、图评估器和基于子任务组合的任务构建方法，为自主智能体的评估提供了一个更加全面、灵活和贴近实际的基准测试平台。相比先前的智能体基准，CRAB 减少了任务步骤中的手动工作量，大大提高了基准构建效率。基于 CRAB，本文提出了 Crab Benchmark-v0，同时支持智能体在 Ubuntu 和 Android 系统上执行多种复杂的跨环境任务，这一基准的提出，不仅可以推动自主智能体评价体系的发展，也为未来设计更加高效的智能体系统提供全新灵感。开发板商城天皓智联 TB上有视觉设备哦支持AI相关~ 大模型相关也可用

....

查看全文

http://www.dtcms.com/a/532530.html