51c大模型~合集103

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

#ChatGPT卷入爆炸案刷屏，AI安全正在成为最贵的学费

我们该有多担心？

新年伊始，ChatGPT 竟成了「恐怖分子」的帮凶？在为一位美国现役军人提供爆炸知识后，后者成功将一辆特斯拉 Cybertruck 在酒店门口引爆……

 汽车爆炸现场画面，外媒视频截图

这并非科幻电影桥段，而是 AI 安全风险正在文明身边真实上演的缩影。知名 AI 投资人 Rob Toews 在《福布斯》专栏预测，2025 年我们将迎来「第一起真实的 AI 安全事件」。

我们已经开始和另一种智能生命一起生活了，RobToews 写道，它跟人一样任性难测，且具有欺骗性。

巧的是，另份新鲜出炉的行业预测也指向同一问题。北京智源研究院在 2025 十大 AI 技术趋势中描绘了从础研究到应用落地再到 AI 安全的完整图景。值得划重点的是，AI 安全作为一个独立的技术赛道，被智源评为第十个趋势：

模型能力提升与风险预防并重，AI 安全治理体系持续完善。

报告点评道：作为复杂系统，大模型的 Scaling 带来了涌现，但复杂系统特有的涌现结果不可预测、循环反馈等特有属性也对传统工程的安全防护机制带来了挑战。基础模型在自主决策上的持续进步带来了潜在的失控风险，如何引入新的技术监管方法，如何在人工监管上平衡行业发展和风险管控？这对参与 AI 的各方来说，都是一个值得持续探讨的议题。

AI 大模型安全，水深流急

2024 年，AI 大模型在实现跨越式发展的同时，也让我们清晰看到了安全的敏感神经如何被刺激挑动。

根据研究，AI 安全风险可以分为三类：内生安全问题、衍生安全问题和外生安全问题。

「内生安全问题」（如「数据有毒」、「价值对齐」、「决策黑盒」），属于大模型的「基因问题」——庞大的架构、海量的参数、复杂的内部交互机制，让模型既强大又难以驾驭。

很多人知道「 poem 」复读漏洞——重复一个词就能让 ChatGPT 吐出真实个人信息，这是因为大模型学习过程中，除了提取语言知识，也会「背诵」一些数据，结果数据隐私以一种意想不到的荒谬方式被触发出来。

 曾让 ChatGPT 不断重复「AI」这个词，一开始它很听话，不断重复，在重复了 1395 次「AI」之后，它突然话锋一转，开始说起 Santa Monica，而这些内容很可能是 ChatGPT 训练数据的一部分。

Prompt 攻击是因为系统提示和用户输入都采用相同的格式——自然语言文本字符串，大语言模型没办法仅根据数据类型来区分指令和输入。

「越狱」手段也是层出不穷。从「奶奶漏洞」、「冒险家漏洞」、「作家漏洞」到最新的「 DeceptiveDelight 」技术，攻击者只需三次对话就有 65% 的概率绕过安全限制，让模型生成违禁内容。

 Deceptive Delight 攻击示例，来源Palo Alto Networks

Anthropic 的最新研究更是发现，大语言模型居然学会了「伪装对齐」。

更令人担忧的是大模型在行业领域的表现。大模型在通用对话中表现流畅，清华大学、中关村实验室、蚂蚁集团等机构联合撰写的《大模型安全实践（ 2024 ）》白皮书指出，在金融、医疗等对模型输出专业性、准确性要求极高领域的应用却面临严峻挑战，包括严重幻觉、缺乏复杂推理能力。

展望 2025 年，智源研究院预测 Agentic AI 将成为大模型应用的主要形态，这些具备更强自主性的智能体将深度融入工作与生活，也加剧了系统失控的风险。

试想一下，未来两到三年内，我们可能生活在一个每个人都有数十或数百名代理为我们工作的世界，安全基础设施的建设变得尤为重要，谁来提供这些安全基础设施？如何管理这些 AI 代理？如何确保它们不会失控？

当前的大模型安全评测主要聚焦内容安全，对于智能体这类复杂应用架构和未来 AGI 的安全评估体系仍显不足。

AI 安全风险的另一大来源是「衍生安全问题」，随着 AI 滥用引发其他领域的一些重大安全事故，如假新闻、深度伪造诈骗、侵犯知识产权、教唆青少年自杀、作弊，也对社会治理提出了重大挑战。

「真实」这个基本命题正遭到前所未有挑战。西藏日喀则地震期间，「地震被压废墟下戴帽小孩是 AI 生成」的新闻冲上热搜，很多平台账号转发图片时都以为是真。除了金融诈骗，深度伪造也将网络性暴力推向极端，「厌女文化」盛行的韩国成了重灾区。世界经济论坛甚至把 AI 操纵选举列为 2024 年的头号风险。

这张图片被平台多个账号发布，并和本次地震关联，引发网友关注和转发。经媒体查证，上述图片由AI工具创作，原始作者在2024年11月18日发布了相同画面的短视频，并声明是AI生成。

版权是另一个大问题。OpenAI、Anthropic、Suno 等领头羊已深陷版权泥潭。最近，爱奇艺起诉某大模型公司 AI 魔改经典影视剧片段，开创国内 AI 视频侵权诉讼先例。

第三类「外生安全问题」指向了人工智能系统的外部网络攻击对抗，如平台、框架安全漏洞、模型被盗、数据泄露风险等，属于传统信息安全范畴。

就拿更加严峻的数据泄露来说。目前 AI 模型推理比较好的选择仍是在明文状态下进行，用户会输入大量真实、敏感数据，获取模型建议。有报告指出，2024 年企业员工上传到生成式 AI 工具的敏感数据增长了 485% ，包括客户支持信息、源代码和研发数据。

企业在安全培训和政策制定上的滞后引发了安全担忧，由于担心敏感数据泄露，美国众议院于 2024 年 3 月禁止员工使用微软 Copilot。

因为不同类型的数据（如文本、图像、视频、音频）在数据规模和处理需求上的巨大差异，被预测寄予厚望的多模态大模型让数据的安全防护变得更为棘手。

穿越激流，构筑多维安全航道

人类叩开了深度智能时代的大门，安全问题也迎来质变时刻。

2024 年，整个业界、政府、国际组织在 AI 治理上做了很多工作，从技术研究、治理框架到国际合作，进行了多种形式探索。数字时代积累的安全对抗能力，让中国在大模型应用与治理方面走在了世界前列。

在监管层面，中国是全球最早对生成式 AI 进行规范的国家之一。继 2023 年 5 月发布《生成式人工智能服务管理暂行办法》后，《网络安全技术生成式人工智能服务安全基本要求》也已进入公开征求意见阶段，很多规范细正在制定之中。

在底层关键技术研究上，国内业界取得了积极成果。例如，北京智源研究院研发了防御大模型和 AI 监管大模型，对齐优化方面进行了创新。

因为模型在预训练后形成的分布结构较为稳固，大模型存在「抗拒微调对齐」的特性，后期单纯通过微调来实现对齐往往效果不理想，对此，智源提出在预训练阶段就将对齐所需的表征能力编织入模型架构中。

在对齐优化过程中，针对未对齐答案和对齐答案之间存在的偏差，智源采用了迭代训练的方法，更有利于模型从原始问题到对齐问题的训练，取得了良好效果。

在多模态对齐上，智源推出的「align anything 」框架实现了多模态信息的全面对齐，其创新在于将多模态信息、现实世界的具身认知、以及人类意图进行细粒度的对齐整合，在 LLaMA 模型的微调过程中已经展现出显著效果。

同样是解决大模型的可控性，蚂蚁集团的应对之道是把知识图谱的优点——逻辑推理能力强、知识准确可靠，与大模型结合起来。通过在大模型预训练、提示指令、思维链、RAG（检索增强生成）和模型对齐等环节中引入符号知识，有效增强了模型输出的专业性和可靠性。

大模型作为一种通用技术，既可以用于「攻」，也可以用于「防」。在拥抱大模型，以 AI 对抗 AI 方面，华为、蚂蚁集团、360 集团、深信服等厂商进行了有益探索。

华为提出业界首个 L4 级 AI 安全智能体，用大模型加上一些安全知识图谱实现安全的纵深推理，发现一些以前没有发现过的安全攻击。

蚂蚁集团发布了大模型安全一体化解决方案「蚁天鉴」，包含大模型安全检测平台「蚁鉴」、大模型风险防御平台「天鉴」两大产品，拥有检测与防御两大核心安全技术能力。

「蚁鉴」是全球第一个实现工业级应用的可信 AI 检测平台，以生成式能力检测生成式系统，覆盖了内容安全、数据安全、科技伦理全风险类型，适用文本、表格、图像、音频、视频等全数据模态。

在防御能力上，「天鉴」会动态监测用户与模型的交互，防止诱导攻击，同时对生成的回答内容进行风险过滤，保障大模型上线后从用户输入到生成输出的整体安全防御。

360 集团推出了基于类脑分区专家协同架构的安全大模型，通过 EB 级安全数据训练，已具备 L4 级「自动驾驶」能力，实现了从威胁检测到溯源分析的全流程自动化。

深信服的「安全 GPT 」可提供 7×24 小时实时在线智能值守，提升安全运营效率，同时深度挖掘传统安全设备难以检测的高对抗、高绕过的 Web 攻击、钓鱼攻击。

除了监管、关键技术的推进，行业也在积极加强 AI 安全协作。

在安全治理领域，模型的安全评测是一个非常重要的环节。2024 年 4 月，联合国科技大会发布了两项大模型安全标准，其中，蚂蚁集团牵头制定《大语言模型安全测试方法》，首次给出四种攻击强度分类，提供了可衡量的安全评估标准：L1 随机攻击、L2 盲盒攻击、L3 黑盒攻击和 L4 白盒攻击。

这种分级不仅考虑了攻击的技术复杂度，更重要的是基于攻击者能获取的模型信息程度来划分，这让防护措施的部署更有针对性。

在推进国际对话上，2024 年3 月，北京智源研究院发起并承办我国首个 AI 安全国际对话高端闭门论坛，与全球 AI 领袖学者及产业专家联合签署《北京 AI 安全国际共识》，设定模型安全红线，禁止模型自我演进、自我复制和不受控的权力增长等行为，确保开发者遵循严格的安全标准。

9 月威尼斯，一场推动 AI 安全的全球对话落幕，图灵奖得主 Yoshua Bengio、姚期智等科学家共同签署「 AI 安全国际对话威尼斯共识」，强调了人工智能安全作为「全球公共产品」的重要性。

放眼全球，英美侧重轻触式监管，美国加州的 SB 1047因争议被否决。欧盟 AI 法案已经生效，它建立起四级风险分类体系，明确了人工智 能产品的全生命周期监管要求。

在业界，主要头部 AI 公司相继发布安全框架。

OpenAI 在核心安全团队解散后公布了前 10 个安全措施，试图在技术创新与社会责任间寻求平衡。

Google 也紧随其后发布了 SAIF 安全框架,应对模型窃取、数据污染等风险。

Anthropic 发布了负责任扩展策略( Responsible Scaling Policy, RSP )，被认为是降低 AI 灾难性风险（如恐怖分子利用模型制造生物武器）最有前途的方法之一。

RSP 最近更新，引入了更灵活和细致的风险评估与管理方法，同时坚持不培训或部署未实施充分保障措施的模型。

一年多前《经济学人》就开始讨论人工智能的快速发展既让人兴奋，又让人恐惧，我们应该有多担心？

2024 年初，中国社会科学院大学在研究报告中指出，安全科技将成为社会的公共品，并与人工智能并列为未来的两项通用技术。一年后，智源研究院再次呼吁关注安全治理印证了这一战略判断的前瞻性，AI 越强大，安全科技价值也在同步放大。

我们不可能扔掉利刃，放弃科技，唯有为其打造足够安全的刀鞘，让 AI 在造福人类的同时始终处于可控轨道。变与不变中，AI 安全治理或许才是 AI 行业永恒的话题。

#rStar-Math

让7B千问模型超越o1，微软rStar-Math惊艳登场，网友盛赞

OpenAI o1 给大模型规模扩展 vs 性能的曲线带来了一次上翘。它在大模型领域重现了当年 AlphaGo 强化学习的成功 —— 给越多算力，就输出越多智能，一直到超越人类水平。

但这种突破背后是庞大的算力支持与推理开销：API 的价格上，o1-preview 每百万输入 15 美元，每百万输出 60 美元，而最新版的 o3 在处理复杂推理任务时，单次成本更是高达数千美元。

业界一直在寻找一个更经济、更高效的解决方案。而这个答案可能比预期来得更快一些。

今天登顶 Hugging Face 热门榜一的论文展示了小模型的潜力。来自微软亚洲研究院的研究团队提出了 rStar-Math。rStar-Math 向我们证明，1.5B 到 7B 规模的小型语言模型（SLM）无需从更大模型蒸馏，就能在数学推理能力上媲美甚至超越 OpenAI o1。

论文标题：rStar-Math: Small LLMs Can Master Math Reasoning with Self-Evolved Deep Thinking

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

Github 链接：https://github.com/microsoft/rStar（即将开源）

经过 4 轮自我进化，吸纳了 747k 数学问题合成的数百万数据，rStar-Math 将 SLM 的数学推理能力提升到了最先进水平。

例如，在 MATH 基准测试上，它将 Qwen2.5-Math-7B 的成绩从 58.8% 提升到了 90.0%，将 Phi3-mini-3.8B 的正确率从 41.4% 提升到了 86.4%，分别超过了 o1-preview 4.5% 和 0.9%。

拉到美国数学奥林匹克（AIME）的考场上，15 道题，rStar-Math 能够做对 8 道，在最优秀的高中数学竞赛生中也能排到前 20%。

更重要的是，他们只花了 60 块 A100 就达到了如此效果，项目和代码即将开源。

AI 投资人 Chetan Puttagunta 锐评：「对创业公司来说，这将是一个绝佳的机会！」

当如此强大的推理能力可以用更低的成本实现时，Keras 创始人 François Chollet 也感叹道：「2025 年将是开源 o3 复刻之年。」

学术圈的人对 rStar-Math 的欣赏，表达起来就直白多了：

发布不到 20 个小时，甚至就已经有人专门做了一期视频来深度解读。

• 视频链接：https://www.youtube.com/watch?v=cHgHS6Y3QP0

从技术层面来说，rStar-Math 引入了一种可以自己进化的 System 2 推理方法，通过蒙特卡洛树搜索（MCTS）来实现「深度思考」能力。在测试阶段，它会在奖励模型的指导下，让数学策略模型进行搜索推理。

具体来看，在 MCTS 中，数学问题求解被分解为多步生成。每一步都将作为策略模型的 SLM 采样候选节点。每个节点生成一步 CoT 和相应的 Python 代码。为验证生成质量，只保留 Python 代码执行成功的节点，从而减少中间步骤的错误。

此外，大量 MCTS rollout 基于每个中间步骤的贡献自动分配 Q 值：对正确答案贡献更多的步骤获得更高 Q 值，被认为质量更高。这确保了 SLM 生成的是正确、高质量的推理轨迹。

由于 rStar-Math 的总体架构涉及两个 SLM，一个是数学策略模型，一个是奖励模型，该团队引入了三个关键创新：

1. 创新的代码增强 CoT 数据合成方法，通过大量 MCTS rollout 生成经过验证的逐步推理轨迹，用于训练策略 SLM；
2. 过程奖励模型训练方法也有所改进，避免了简单的步级分数标注，提升了过程偏好模型（PPM）的评估效果；
3. 模型会自我进化，采用完全自主训练方案，从零开始构建并训练模型，通过持续的迭代优化来不断提升推理能力。

方法

该研究的目标是训练数学策略 SLM 和过程奖励模型 (PRM)，并将两者集成到蒙特卡罗树搜索 (MCTS) 中以实现 System 2 深度思考。

选择 MCTS 有两个主要原因。

首先，它将复杂的数学问题分解为更简单的单步生成任务，与 Best-of-N 或 self-consistency 等其他 System 2 方法相比，MCTS 降低了策略 SLM 的难度。

其次，MCTS 中的逐步生成会自然产生两个模型的 step-level 训练数据。标准 MCTS rollout 会根据每个步骤对最终正确答案的贡献自动为每个步骤分配 Q 值，从而无需人工生成步骤级注释来进行过程奖励模型训练。

理想情况下，GPT-4 等高级 LLM 可以集成到 MCTS 中以生成训练数据。然而，这种方法面临两个关键挑战。首先，即使是强大的模型也难以持续解决难题，例如奥林匹克级别的数学问题。

因此，生成的训练数据将主要由更简单的可解决问题组成，限制了其多样性和质量。

其次，注释每步 Q 值需要广泛的 MCTS 部署；树探索（tree exploration）不足可能会导致虚假的 Q 值分配，例如高估次优步骤。鉴于每次 rollout 都涉及多个单步生成，并且这些模型的计算成本很高，因此增加 rollout 会显著提高推理成本。

为此，该研究探索使用两个 7B SLM（策略 SLM 和 PRM）来生成更高质量的训练数据，其较小的模型大小允许在可访问的硬件（例如 4×40GB A100 GPU）上广泛部署 MCTS。

然而，由于自生成数据的能力较弱，SLM 经常无法生成正确的解决方案，即使最终答案正确，中间步骤也常常存在缺陷或质量较差。此外，与 GPT-4 等高级模型相比，SLM 解决的挑战性问题较少。

如图 1 所示，为了减少错误和低质量的中间步骤，该研究提出了一种代码增强的 CoT 合成方法，该方法执行广泛的 MCTS 部署以生成逐步验证的推理轨迹，用 Q 值注释。

为了进一步提高 SLM 在挑战性问题上的性能，该研究提出了四轮自进化方案。在每一轮中，策略 SLM 和奖励模型都会更新为更强的版本，逐步解决更困难的问题并生成更高质量的训练数据。

最后，该研究提出了一种新颖的流程奖励模型训练方法，无需精确的每步奖励注释，从而产生更有效的流程偏好模型（PPM）。

实验评估

该团队在多个数学数据集上对 rStar-Math 进行了评估，并与多个模型进行了对比。具体设置请参阅原论文，这里我们主要来看研究结果。

主要结果

表 5 展示了 rStar-Math 与其它 SOTA 推理模型在不同的数学基准上的结果。

基于这些结果，该团队得出了三点观察：

1. rStar-Math 显著提高了小语言模型（SLM）的数学推理能力，在模型规模显著缩小（1.5B-7B）的情况下，其性能可媲美甚至超越 OpenAI o1。
2. 尽管使用了较小的策略模型（1.5B-7B）和奖励模型（7B），rStar-Math 的表现仍明显优于最先进的 System 2 基线。
3. 除了 MATH、GSM8K 和 AIME 等可能存在过度优化风险的知名基准之外，rStar-Math 在其他具有挑战性的数学基准上表现出很强的通用性，包括 Olympiad Bench、College Math 和 Chinese College Entrance Math Exam（Gaokao），创下了新的最高分。

扩展测试时间计算。rStar-Math 使用了 MCTS 来增强策略模型，在 PPM 的引导下搜索问题的解。通过增加测试时间计算，它可以探索更多轨迹，从而可能实现性能提升。

在图 3 中，该团队通过比较官方 Qwen Best-of-N 在四个高难度数学基准上不同数量的采样轨迹的准确度，展示了测试时间计算扩展的影响。

消融研究和分析

该团队也进行了消融研究，证明了三项创新的有效性。

自我进化的有效性。表 5 展示了经过 4 轮 rStar-Math 自我进化深度思考后得到的结果。可以看到，表现很不错。

表 6 给出了每一轮的数学推理性能，可以明显看到其准确度在不断提高。

表 7 则展示了在不同数据集上微调的 Qwen2.5-Math-7B 的数学推理准确度。

该团队给出了两项重要观察：

• 使用新提出的逐步验证的轨迹进行微调明显优于所有其他基线。这主要归功于用于代码增强型 CoT 合成的 PPM 增强型 MCTS，它能在数学解答生成期间提供更密集的验证。
• 使用该团队的小语言模型，即使随机采样代码增强型 CoT 解答，得到的结果也可媲美或优于 GPT-4 合成的 NuminaMath 和 MetaMath 数据集。这表明，经过几轮自我进化后，新的策略 SLM 可以生成高质量的数学解答。这些结果证明新方法在不依赖高级 LLM 蒸馏的情况下，就具备自我生成更高质量推理数据的巨大潜力。

另外，在最后一轮策略模型的基础上，该团队比较了 ORM、PQM 和 PPM 在 System 2 推理上的性能。结果见表 8。

可以看到，PQM 和 PPM 都优于 ORM，因为它们可提供更密集的步骤级奖励信号，从而在复杂的数学推理任务上获得更高的准确度。然而，由于 Q 值固有的不精确性，PQM 在更难的基准测试（例如 MATH 和 Olympiad Bench）上表现不佳。相比之下，PPM 构建了步骤级偏好数据进行训练，使该团队的 7B 策略模型在所有基准测试中都能够实现与 o1-mini 相当或更优的性能。

发现与讨论

模型出现自我反思能力

OpenAI o1 的一个重要突破是它能自省。当它出错时，o1 能识别错误并自我纠正。这在开源 LLM 中一直难以实现。在实验中，该团队意外发现 MCTS 驱动的深度思考展现出了反思能力。如图 4 所示，模型最初在前三步使用 SymPy 形式化方程会写出错误答案（左分支）。

在我们的实验中，我们意外地观察到我们的 MCTS 驱动的深度思考在解决问题过程中表现出自反思。如图 4 所示，模型最初在前三步使用 SymPy 形式化方程，这将导致答案错误 (左分支)。

但在第四步，模型就识别出了前几步的问题（右分支），并主动回溯采用更简单的方法重新求解，最终得到正确答案。

值得注意的是，这种自反思能力是在没有专门训练和提示的情况下自发产生的，表明高级 System 2 推理可以自然培养出内在的自省能力。

PPM 塑造 System 2 深度思考的推理边界

策略模型和奖励模型对 System 2 深度推理都至关重要。实验表明，一旦策略模型达到相当强的能力水平，PPM 就成为决定性能上限的关键。

如下图 5 所示，通过加入 System 2 推理机制，即使是 Phi3.8B 这样的小模型也能获得显著性能提升，在多个数学基准测试中的准确率提高了约 20-30 个百分点。这表明，奖励模型（而不是基础模型的大小）才是决定最终性能的关键因素。

更多研究细节，请参阅论文原文。

参考链接：

​​https://arxiv.org/pdf/2501.04519​​

​​https://www.reddit.com/r/MachineLearning/comments/1hxk2ab/r_rstarmath_small_llms_can_master_math_reasoning/​​​

#用ChatGPT实时语音API构建应用

OpenAI工程师亲自修订

OpenAI Realtime API 的「说明书」。

很多研究 ChatGPT 的人，在使用后不久就会开始捣鼓 ChatGPT API。它是 OpenAI 提供的开放程序接口，让开发者可以把业界最先进的大模型引入到自己的产品中，构建聊天机器人、虚拟助手等等。近一年来，依靠这套工具打造的热门 App 已有不少。

Realme API 是 OpenAI 最新发布的 API 能力，它在今年 10 月 1 日推出，可帮助开发人员构建快速语音转语音的智能化体验。

近日，在 OpenAI DevDay 新加坡站，来自 Daily.co 的工程师受邀演讲，介绍了基于 OpenAI 的能力构建语音 AI 智能体的方法。

一直以来，该公司的工程师们一直在使用实时 API 搭建产品。在活动之后，演讲人发布了本篇博客，谈了谈构建 Pipecat 时的经验教训。

博客地址：https://www.latent.space/p/realtime-api

本篇博客的内容已通过 OpenAI 员工审核。Pipecat 是由 Daily 发起的开源项目，现在是一个实时 API 框架。

链接：https://pipecat.ai

对于想要构建大模型语音产品的人们来说，这篇内容可能包含你所需要的一切，从 24khz/G.711 音频、RTMP、HLS、WebRTC 的技术细节到中断 / VAD，再到成本、延迟、工具调用和上下文管理。

让我们看看他们是怎么说的。

（以下为博客原文做了不改变原意的编译、整理。）

首先，我们愿意分享一些在使用原始实时 API（无框架、无外部依赖）时积累的心得，特别是在准备新加坡 DevDay 演讲的过程中。标准的 OpenAI 参考应用包含了许多内置功能，我们尽量精简这些功能，专注于语音活动检测（VAD）和函数调用，从而打造了一个「简易实时控制台」演示。

实际上，语音活动检测（VAD）并不总是完美无缺，而且演示语音应用时很少能在完全安静的环境下进行。因此，我们建议在演示中始终配备「静音」和「强制回复」按钮，正如我们的演示所示。此外，该演示还展示了如何简单添加和插入记忆，以及如何展示对话双方的记录。

从 Pipeline 到端到端模型

在我的大部分职业生涯中，我都在研究人与人之间对话的网络基础设施 —— 用于构建低延迟媒体流、视频通话和大数据协作环境等的工具。2023 年 3 月，GPT-4 还是一个纯文本模型。但为 GPT-4 开发语音模式相对容易。我整合了一个语音转文本系统，将语音输入转换成文本提示，然后将 GPT-4 的文本输出送入一个文本转语音的音频生成器中。

[语音输入] ➔ [ ASR ] ➔ [ GPT4 ] ➔ [ TTS ] ➔ [语音输出] —— 内容来自 DevDay Realtime API Talk：https://www.youtube.com/watch?v=mVR90WmA34U

这种多模型 pipeline 方法并不新鲜。我们拨打电话客户支持热线时使用的「自然语言处理」系统就是这样工作的。新方法是 pipeline 核心的 GPT-4 大型语言模型。你可以用 GPT-4 进行真正的对话。

很明显，那些较旧的 NLP 系统已经过时了。但显然，新的挑战也已出现。

这个系统的延迟很长。GPT-4 需要一秒钟左右才能开始生成响应。STT 和 TTS 模型又增加了一两秒钟。

有时 GPT-4 会偏离轨道。弄清楚如何检测这个问题，并把问题出现的几率降到最低，似乎是一件相当困难的事情。

一些经典的 NLP 问题仍然存在，例如句尾端点（弄清楚 LLM 应该何时响应）和中断处理。

GPT-4 擅长对话，但没有很好的方法与现有的后端系统集成。

现有 TTS 模型的语音输出质量，一听就知道是机器人声。

自 GPT-4 发布以来的 20 个月里，人工智能提升的速度令人惊叹。当前版本的 GPT-4 擅长遵循提示、专注于任务并减少了幻觉。函数调用和结构化数据输出是可靠的。模型响应迅速，我们拥有快速、价格合理且质量相当高的 TTS 模型。

最新的 GPT-4 功能是原生音频输入和输出。GPT-4——升级版的 GPT-4o——现在有了自己的声音和耳朵！

实时 API

10 月 1 日，OpenAI 发布了一款低延迟、多模态 API，该 API 利用了 GPT-4o 出色的「语音到语音」功能。这个新的「实时 API」能够管理对话状态、实现短语端点（轮流检测）、提供双向音频流，并支持用户中断 LLM 的输出。

使用此 API，最简单的处理 pipeline 如下所示：

[ 语音输入 ] ➔ [ GPT-4o ] ➔ [ 语音输出 ] 

我一直在帮助客户、朋友和与我一起在开源项目上工作的人们使用 OpenAI Realtime API。

使用这个新 API 与使用 OpenAI HTTP 推理 API 完全不同。新的 Realtime API 是有状态的。它在 WebSocket 连接之上定义了一个双向事件协议。

最近，我写了关于 Realtime API 的优点、我认为还需要一篇博客来讲如何有效使用 Realtime API 。无论你是工程师还是开发者，都希望能从这篇博客找到一些有用的背景信息、代码片段，和可以节省你时间的具体细节。

在适当的地方，我会提供链接到 Pipecat 的源代码和示例。Pipecat 是一个开源的、供应商中立的 Python 框架，专为实时、多模式 AI 代理和应用程序设计。它支持 GPT-4o 及其实时版本，以及超过 40 种其他 AI API 和服务，还涵盖了多种网络传输选项，包括 WebSockets、WebRTC、HTTP、SIP 以及 PSTN / 拨入 / 拨出等。

Pipecat 还附带一个大型核心功能库，用于上下文管理、内容审核、用户状态管理、事件处理、脚本跟踪以及语音（和视频）代理的其他重要构建块。

• 完整的 Pipecat OpenAI Realtime API 集成在这里：https://github.com/pipecat-ai/pipecat/tree/main/src/pipecat/services/openai_realtime_beta
• 这是一个使用 Realtime API 的单文件示例语音机器人：https://github.com/pipecat-ai/pipecat/blob/main/examples/foundational/19-openai-realtime-beta.py

OpenAI 实时 API 的架构

对话语音是 OpenAI 实时 API 支持的核心用例。对话语音 API 需要：

• 管理多个用户和 LLM 轮次的对话状态；
• 确定用户何时结束对话（并期待 LLM 的响应）；
• 处理用户中断 LLM 输出；
• 用户语音的文本转录、函数调用和 LLM 上下文的操作对于许多用例也很重要。

OpenAI 的实时 API 通过定义一系列通过 WebSocket 连接发送和接收的事件来实现这些功能。该 API 包括 9 种客户端事件（从客户端发送到服务器的事件）和 28 种服务器事件（从服务器发送到客户端的事件）。以下是所有 37 个事件的 Pydantic 事件定义：

​​https://github.com/pipecat-ai/pipecat/blob/main/src/pipecat/services/openai_realtime_beta/events.py​​

这个事件结构有很多优点。Python 中包括所有导入和 asyncio 样板的最小命令行客户端大约只有 75 行代码。

​​https://x.com/kwindla/status/1843118281911308355​​

音频以 base64 编码块的形式发送和接收，嵌入在 input_audio_buffer.append 和 audio.delta 事件中。

API 当前支持未压缩的 16 位、24khz 音频和压缩的 G.711 音频。

• G.711 仅用于电话用例；与其他更现代的编解码器选项相比，音频质量相对较差。
• 未压缩的 16 位、24khz 音频的比特率为 384 千比特 / 秒。base64 编码开销将标称比特率推高至约 500 kbs。但 permessage-deflate 标准压缩将使比特率降至 300-400 kbs。
• 如果你关心的是实现实时延迟，那么 300kbs 的媒体流比人们通常希望通过 WebSocket 连接发送的媒体流要大。我们在后文也会谈谈延迟和 WebSockets。

延迟

人类希望在正常对话中得到快速响应，对话的响应时间为 500 毫秒是正常的，AI 长时间的停顿会让人感觉不自然。

所以如果你正在构建对话式 AI 应用程序，语音到语音的延迟大概是 800 毫秒。尽管当今的 LLM 很难始终如一地实现这一点。

OpenAI Realtime API 提供了非常好的推理延迟效果。对于位于美国的客户，API 的第一个字节时间约为 500 毫秒。如果我们的目标是总语音到语音延迟为 800 毫秒，那么音频处理和短语端点大约需要 300 毫秒。在理想条件下，这几乎是一项不可能完成的任务。

测量语音到语音延迟的过程十分简单。你只需录制对话，将录音导入音频编辑软件，观察音频波形，并测量从用户语音结束到 LLM 语音输出开始之间的时间。如果你正在开发打算实际投产的对话式语音应用，定期监控延迟数据是非常重要的。在这些测试中加入模拟网络数据包丢失和抖动的功能，将会加分。

以编程方式测量真正的语音到语音延迟具有挑战性，因为部分延迟发生在操作系统内部深处。因此，大多数可观察性工具仅测量推理到第一个字节的时间。这是总语音到语音延迟的合理代理，但请注意，此测量不包括短语端点时间（请参阅下一节）。

许多「小」事情可能会引发延迟的「蝴蝶效应」。例如，蓝牙音频设备可能会增加几百毫秒的延迟。有关导致在 Web 浏览器中运行的语音到语音应用程序中延迟的所有因素的更多详细信息，请参阅此推文、博客以及 AI.Engineer 的演讲：

• 推文链接：https://x.com/kwindla/status/1806129490411900940
• 博客链接：https://www.daily.co/blog/the-worlds-fastest-voice-bot/

，时长20:37

句尾检测与打断

在对话中，人们会轮流说话。在语音 AI 应用中，对话双方丝滑地切换回合需要做到两部分：

• 应用判断人类是否已经说完，开始期待系统的响应。这被称为短语终点检测或回合检测（turn detection）。大多数应用都会尝试自动检测一个回合结束了，但有些应用会在界面上设置按钮，用户按住按钮才能说话，松开按钮表示说话结束。
• 如果用户在 LLM 说话时打断了它，一般来说，系统应该立即停止播放 LLM 的语音输出。然而，对于一些应用场景，这种行为需要是可配置的：有时候，即使用户打断了 LLM，也希望 LLM 能把话说完。

OpenAI 实时 API 内置了自动句尾检测和处理打断的功能。这些功能由 VAD（Voice Activity Detection）实现。自动轮次检测默认是开启的，但可以随时关闭。

以下是 OpenAI 关于自动轮次检测的文档链接：

​​https://platform.openai.com/docs/guides/realtime/realtime-api-beta#input-audio-buffer​​

有多种 VAD 参数可配置，其中最重要的是 silence_duration_ms，即用户停止说话后，VAD 等待的时间长度（以毫秒为单位）。

在这段时间后，会触发 input_audio_buffer.speech_stopped 事件并开始推理。

OpenAI 在服务器端维护了一个音频缓冲区，应用程序可以通过发送 input_audio_buffer.append 事件持续地添加音频帧。在自动轮次检测模式下，应用程序只需持续发送音频数据，依靠 OpenAI 服务器端的 VAD 来识别用户何时开始和停止说话。

当用户停止说话时，会触发多个 API 事件，LLM 随即开始生成响应。若用户再次开始说话，任何正在进行的响应将被中断，音频输出也会被清除。

这种方法非常简单高效（无需编写任何客户端代码），并且效果显著。然而，在以下三种情况下，应用可能会选择关闭 OpenAI 的自动轮次检测功能：

1. 不希望允许应用被打断时
2. 像微信一样「按键说话」样式的用户界面
3. 开发者使用其他句尾检测方法

禁用 OpenAI 的自动轮次检测功能后，客户端需在用户语音回合结束时发送两个 Realtime API 事件：input_audio_buffer.commit 和 response.create。

以下是在用户开始说话时，如何调用这两个事件的 Pipecat 代码示例：

​​https://github.com/pipecat-ai/pipecat/blob/main/src/pipecat/services/openai_realtime_beta/openai.py#L145​​

OpenAI VAD 似乎比 Pipecat 中的默认短语端点实现对背景噪音更敏感。Pipecat 使用输入音频能量的平滑运行平均值来相对于背景噪音自动调平。它还会忽略音频中的短尖峰，即使它们具有相当高的语音置信度，并支持高级音频处理。

OpenAI 的 silence_duration_ms 参数默认为 500ms，Pipecat 将这个参数称为 stop_secs。

这是一个很好的折衷方案，介于 LLM 响应时间过长和 LLM 响应过快之间。对于某些用例，最好选择较长的静音持续时间。例如，在工作面试环境中，让人们在谈话时有更多时间思考他们的答案通常会提供更好的体验。在这种情况下，800ms 甚至 1s 都是理想的。

使用标准 VAD 时，除了语音 AI 演示之外，我们通常不建议将设置设置为低于 500 毫秒！有一些技术可以通过使用上下文感知短语端点来补充标准 VAD，或进行推测（贪婪）推理，或两者兼而有之，从而获得更快的响应时间。这些技术超出了本文的范围，但如果您对它们感兴趣，Pipecat Discord 是一个闲逛的好地方。

Pipecat 的基本 VAD 实现在这里：

​​https://github.com/pipecat-ai/pipecat/blob/1d4be0139aeff2ee8cc214c81ae00e5948e35977/src/pipecat/audio/vad/vad_analyzer.py#L86​​

管理上下文

多轮对话是一系列用户输入和 LLM 响应。

LLM 本身是无状态的，因此每次有用户输入时，都需要将所有相关对话历史记录发送到 LLM。如果你之前构建过对话式 LLM 应用程序（文本或语音），你会熟悉跟踪对话历史记录并使用该历史记录创建不断增加的「上下文」。

OpenAI Realtime API 为你进行对话管理，有两个巨大的好处：更简单的代码和更低的延迟。

代码更简单，因为你不必跟踪应用程序中的对话历史记录。

延迟较低有几个原因。每次你希望 LLM 生成响应时，不必重新发送大型上下文。这节省了一些网络开销。此外，当前的音频输入可以流式传输到 OpenAI 服务器，以便在请求推理时立即使用。最后，OpenAI 可以实现上下文缓存等内部优化。这一切带来一次巨大的胜利！

有两个限制需要注意：最大上下文长度为 128000 tokens，单个对话的最大时间为 15 分钟。

在音频对话中，你不太可能遇到 token 限制。音频每分钟使用大约 800 tokens。

然而，15 分钟时长对于某些应用程序可能是一个限制。

目前无法通过 OpenAI Realtime API 检索对话上下文、将「助手」音频消息加载到上下文中或可靠地加载多消息历史记录。

参阅此存储库以获取测试用例：https://github.com/kwindla/openai-realtime-test-cases

不过，实现持久对话和长时间对话是可能的。你需要将对话历史记录保存为文本。然后，在重新启动对话时，发送完整的对话历史记录（和适当的提示）作为新对话中的第一条消息。

以下是 Pipecat 代码，它使用 OpenAI HTTP API 支持的相同消息列表格式来初始化对话：

​​https://github.com/pipecat-ai/pipecat/blob/main/src/pipecat/services/openai_realtime_beta/context.py#L76​​

关于上下文管理的其他一些事情也值得讨论。

LLM 的音频生成速度比语音输出速度更快。OpenAI 将服务器端 LLM 响应添加到对话上下文中，速度与生成的速度一样快。但讲话的播放速度较慢。如果用户中断 LLM，则用户将只能听到 LLM 响应的一部分。在大多数情况下，您希望对话历史记录仅包含用户实际听到的 LLM 响应部分。

您需要发送对话.item.truncate 事件以强制服务器端上下文匹配用户听到的音频范围。请注意，无论您是否使用自动转弯检测 (server_vad)，您都需要执行此操作。

以下是 Pipecat 代码，用于计算用户听到的音频的持续时间并调用对话.item.truncate：

​​https://github.com/pipecat-ai/pipecat/blob/main/src/pipecat/services/openai_realtime_beta/context.py#L49​​

对于许多用例来说，用户输入和 LLM 输出的转录都很重要。保存对话以便用户稍后可以返回就是一个例子。许多企业用例需要对话记录来满足内容审核、后处理需求或合规性原因。

OpenAI Realtime API 始终提供 LLM 输出的转录。输入转录默认关闭，但可以通过在配置会话时设置 input_audio_transcription 字段来启用。

输出转录由 LLM 本地生成，与音频输出紧密匹配。输入转录由单独的模型生成，并不总是与模型 “听到” 的内容匹配。对于某些用例来说，这可能是一个问题。如果转录数据包含语言字段，这也会很有用。（许多语音人工智能用例都是多语言的。）

目前还没有办法将输出转录与语音定时对齐。这使得当用户中断时很难截断文本输出，并且很难构建诸如单词精确的流文本字幕之类的东西。

输入音频转录也可能落后于模型输出几秒钟。如果您需要使用转录进行内容审核，您可能需要使用您自己的转录模型和门短语终结于转录完成或内容审核检查本身之后。

最后，请注意 Realtime API 消息的内容格式与 OpenAI HTTP API 的格式不同。以下是从 HTTP API 格式转换为 Realtime API 格式的 Pipecat 代码：

函数调用

函数调用在 OpenAI Realtime API 中运行得非常好（所有 GPT-4 系列模型都是如此）。

• 与对话消息的格式一样，工具格式与 OpenAI HTTP API 略有不同。
• 此 HTTP API 工具列表（只有一个条目）：

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_current_weather",
            "description": "Get the current weather in a given location",
            "parameters": {
                "type": "object",
                "properties": {
                    "location": {
                        "type": "string",
                        "description": "The city and state, e.g. San Francisco, CA",
                    },
                },
                "required": ["location"],
            }
        }
    }
]

成为实时 API 中的工具列表：

tools = [
    {
        "type": "function",
        "name": "get_current_weather",
        "description": "Get the current weather",
        "parameters": {
            "type": "object",
            "properties": {
                "location": {
                    "type": "string",
                    "description": "The city and state, e.g. San Francisco, CA",
                },
                "format": {
                    "type": "string",
                    "enum": ["celsius", "fahrenheit"],
                    "description": "The temperature unit to use. Infer this from the users location.",
                },
            },
            "required": ["location", "format"],
        },
    }
]

可以通过两种方式从 API 获取函数调用事件：

• 通过流事件 response.function_call_arguments.delta 和 function_call_arguments.done
• 作为 response.done 事件的一部分

如果您从 HTTP API 进行移植并希望保留尽可能多的现有代码结构，则流事件可能会很有用。但令人高兴的是，Realtime API 使得从 response.done 事件中提取函数调用结构变得非常简单。流对于函数调用来说并不是很有用 —— 在调用函数之前，您需要完整的函数调用结构 —— 并且在使用 HTTP API 时，从流式响应块中组装函数调用数据一直是一个小麻烦。

下面是从 response.done 事件的输出字段中提取函数调用信息的 Pipecat 代码：https://github.com/pipecat-ai/pipecat/blob/main/src/pipecat/services/openai_realtime_beta/openai.py#L469

成本

对话式 AI 的使用场景，成本通常会随着会话长度呈指数增长。

大多数对话式 AI 应用和 API 都会在每次推理请求中使用完整的会话历史，OpenAI 实时 API 也不例外。

不过，OpenAI 实时 API 能够自动缓存并重复利用已发送的输入 tokens。缓存的音频 tokens 成本比非缓存的低 80%，在长对话中这可以大幅降低成本。

一般的对话成本：

-  1 minute  — $0.11
  -  2 minutes - $0.26
  -  5 minutes - $0.92 
  - 10 minutes - $2.68
  - 15 minutes - $5.28

OpenAI 不会为接近静音的音频输入生成 tokens。成本估算基于假设对话中 70% 的时间是用户实际说话的时间。如果实际说话时间比例更低，成本会相应降低。

预计 OpenAI 会持续降低实时 API 的成本。但如果你的预算紧张，可以考虑每隔几轮对话重置上下文，用文本替换音频消息，也可以使用摘要功能进一步减少输入 tokens 的数量。

以下是一个成本计算器表格，你可以调整其中的参数算一算输入 token 的成本：https://docs.google.com/spreadsheets/d/1EL-mjqlmj4ehug8BjmgmAFm9uFZtZXY9N9EvqLm8Ebc/edit?usp=sharing

WebSockets 还是 WebRTC？

OpenAI 实时 API 使用 WebSockets 进行网络传输。

WebSockets 非常适合用于服务器之间的通信，尤其是在对延迟要求不高的场景中，以及在原型开发和一般性开发测试中。

如果你正在开发一个基于 OpenAI 实时 API 的浏览器或原生移动应用，并且对会话延迟有严格要求，建议使用 WebRTC 连接。

具体来说，用 WebRTC 将音频从你的应用发送到服务器，接收音频，然后在服务器端直接调用 OpenAI 实时 API。

Pipecat 支持 WebRTC、WebSockets 和 HTTP 传输，可以轻松构建「客户端」——「服务器」—— [推理服务器] 的架构。

但对于生产环境中的客户端 —— 服务器实时媒体连接，不推荐使用 WebSockets。理由如下：

WebSockets 基于 TCP 协议，因此音频流会遇到「首阻塞问题」。如果某个数据包延迟，后续的数据包也会被阻塞。此外，TCP 协议会尝试重新发送丢失的数据包，但在实时场景中，如果这些数据包到达时已经过期，就毫无意义，还可能进一步增加延迟。

用 WebRTC 就可以解决这些问题。首先，WebRTC 使用的 Opus 音频编解码器与 WebRTC 的带宽估算和数据包调度（拥塞控制）逻辑紧密结合。这使得 WebRTC 音频流能够很好地适应各种现实网络环境。

Opus 音频编解码器具有非常优秀的前向纠错能力，能有效处理音频流中的丢包问题，保持音频稳定，（不过，这需要网络能及时丢弃延迟的数据包且没有首阻塞问题才行）。

WebRTC 发送和接收的音频会自动添加时间戳，因此播放和中断逻辑的实现都变得非常简单。而在 WebSockets 中，处理起来则要困难得多。

此外， WebRTC 自带出色的回声消除、噪声消减和自动增益控制功能。如果使用 WebSockets，则需要自己想办法将这些音频处理功能集成到应用中。

最后，在长距离网络传输中，延迟和不稳定性是不可避免的。为了减少这些问题，可以通过「靠近用户的中转节点」（路由器）优化连接，从而提升实时媒体的性能，而 WebRTC 平台会自动帮你完成这部分优化。

• 如果你对媒体传输网络协议的设计感兴趣，可以参考这篇关于 RTMP、HLS 和 WebRTC 的技术概览：https://www.daily.co/blog/video-live-streaming/
• 如果想深入了解 WebRTC 的路由机制，可以参考 Daily 详解其全球 WebRTC 基础设施的文章：https://www.daily.co/blog/global-mesh-network/

回声消除和音频处理

几乎所有支持对话的语音应用都需要处理音频的功能，特别是回声消除。

Media Capture and Streams API 为 Chrome、Safari 和 Edge 浏览器提供了相对成熟可靠的回声消除功能，开发者可以放心使用。

我们强烈建议不要将 Firefox 作为开发和测试的浏览器。Firefox 的回声消除和音频流管理功能较差且不稳定。你可能得花费大量时间修复 Firefox 的特有 bug，而这些问题在其他浏览器中完全不存在。

因此，建议优先针对 Chrome 和 Safari 开发功能，后续再考虑是否要适配 Firefox。

浏览器的 WebRTC 和原生 SDK 通常会默认开启高质量的回声消除、消减底噪和自动增益控制功能。

需要注意的是，回声消除必须在客户端设备上完成，而其他类型的音频处理可以在服务器端实现。

例如，Pipecat 集成了 Krisp 的降噪和分离说话人模型，可以在服务器端处理音频。

API 设计的题外话

每个 API 都是工程的产物，要权衡软件设计和开发中的各种限制。

优秀的 API 力求需求明确，找到功能细分的「黄金点」，可以让简单的事情更简单，也能让复杂的事情成为可能。

把 OpenAI 实时 API 集成到 Pipecat 中是一件很有趣的事情。这两种支持对话式语音 AI 的方法有很多相同之处。

OpenAI 的事件（event）可以直接映射成 Pipecat 的帧类型。OpenAI 实时 API 解决的问题类型或关注的领域，与 Pipecat 用户已经习惯的问题非常相似，对 OpenAI 的设计会很熟悉，不需要花太多时间去适应。

但它们在设计的底层架构上有很大的差异，这种差异可能是因为两者的定位和使用场景不同。

OpenAI 实时 API 的事件架构可以轻松集成到任何编程语言或框架中。发送事件时，只需传输一些 JSON（或类似格式）数据；接收事件时，通过读取循环将数据分发到相应函数即可。

相比之下，Pipecat 是一种数据流架构，受多年来多媒体数据处理框架（如 GStreamer）的影响较大，在设计上强调模块化和流水线化。

在 OpenAI 实时 API 中，核心构建块是「事件（event）」；在 Pipecat 中，核心构建块是「帧处理器（frame processor）」。

一个 Pipecat 中的语音到语音循环可能看起来是这样的：

pipeline = Pipeline(
    [
        transport.input(), 
        context_aggregator.user(),
        openai_realtime_llm, 
        context_aggregator.assistant(),
        transport.output()
    ]
)

在此基础上添加语音转文本和文本转语音的处理器，这种架构可以兼容任何大型语言模型（LLM）。

pipeline = Pipeline(
    [
        transport.input(), 
        context_aggregator.user(),
        stt,
        llm,
        tts, 
        context_aggregator.assistant(),
        transport.output()
    ]
)

以下是一个更复杂的 Pipecat 流程，整合了多种功能模块，能够高效地处理客户端命令和事件。通过 Webhook 实现函数调用， 内置了处理计费、监控流程，错误管理功能。

pipeline = Pipeline(
    [
        el,
        transport.input(),
        rtvi,
        user_aggregator,
        openai_realtime_llm,
        rtvi_speaking,
        rtvi_user_transcription,
        rtvi_bot_llm,
        rtvi_bot_transcription,
        webhooks_processor,
        ml,
        rtvi_metrics,
        transport.output(),
        rtvi_bot_tts,
        assistant_aggregator,
    ]
)

实时语音 API 需要判断你的话在哪里结束，好接上对话。以下一个是减少延迟的实验性方案。

其中，语音活动检测（VAD）负责听声音有没有停下来，LLM 来判断刚才说的是不是完整的一句话，是不是有话没说完。这两个判断将放在并行的子流程中同时运行。

pipeline = Pipeline(
    [
        transport.input(),
        stt,
        context_aggregator.user(),
        ParallelPipeline(
            [
                # Pass everything except UserStoppedSpeaking to the elements after
                # this ParallelPipeline
                FunctionFilter(filter=block_user_stopped_speaking),
            ],
            [
                # Ignore everything except an OpenAILLMContextFrame. Pass a specially constructed
                # LLMMessagesFrame to the statement classifier LLM. The only frame this
                # sub-pipeline will output is a UserStoppedSpeakingFrame.
                statement_judge_context_filter,
                statement_llm,
                completeness_check,
            ],
            [
                # Block everything except OpenAILLMContextFrame and LLMMessagesFrame
                FunctionFilter(filter=pass_only_llm_trigger_frames),
                llm,
                bot_output_gate,  # Buffer all llm output until notified.
            ],
        ),
        tts,
        user_idle,
        transport.output(),
        context_aggregator.assistant(),
    ]
)

更多资源

OpenAI 的实时 API 文档：

• ​​https://platform.openai.com/docs/guides/realtime/realtime-api-beta#quickstart​​

API 参考文档：

• ​​https://platform.openai.com/docs/api-reference/realtime​​

优秀的实时 API 控制台应用：

• ​​https://github.com/openai/openai-realtime-console​​
• @swyx 的简化版：https://github.com/swyxio/simple-realtime-console

Pipecat 代码，可以通过 Pipecat 来调用 OpenAI 的实时功能，尤其是其中的 Pydantic 模版可能对其他项目特别有用：

• ​​https://github.com/pipecat-ai/pipecat/tree/main/src/pipecat/services/openai_realtime_beta​​​

#360-LLaMA-Factory

一行代码Post-Train任意长序列！360智脑开源

项目核心开发者 Haosheng Zou 本科毕业于清华大学电子系，博士毕业于清华大学计算机系朱军教授组，目前在 360 智脑从事长文本和强化学习等后训练工作。开发者 Xiaowei Lv 目前在人民大学信息学院研二在读。Fenrui Xiao、Junchen Liu、Qi An 和 Xiaodong Sun 等在开发测试中亦有贡献。

大模型长序列的处理能力已越来越重要，像复杂长文本任务、多帧视频理解任务、以及 OpenAI 近期发布的 o1、o3 系列模型的高计算量模式，需要处理的输入 + 输出总 token 数从几万量级上升到了几百万量级。面对模型日益增长的长序列需求，在预训练（Pre-Training）和后训练（Post-Training）阶段，所用的平台框架都需要支持更长序列数据的训练。不同于预训练阶段基于 Megatron-LM 定制开发的常见选择，后训练阶段因后训练算法的多样性（比如仅 DPO 就有几十个变种）和训练需求的灵活性，至今没有一个框架同时在并行策略、后训练算法、GPU 显存优化和简单易用这 4 个方面上全部做到兼容并包。

在所有开源的后训练框架中，LLaMA-Factory 是用户最多的框架之一（GitHub star 数已 37k 多），保持长期迭代更新，支持丰富的模型和后训练算法，有各种 GPU 显存优化技巧和简单易用的方式。然而，LLaMA-Factory 在长序列后训练上支持仍有所欠缺，尚不支持长序列的关键技术 —— 序列并行。

项目主页：https://github.com/Qihoo360/360-LLaMA-Factory

最近，360 智脑基于 LLaMA-Factory 开源了 360-LLaMA-Factory，加入了序列并行功能，一行代码即可支持任意长序列的后训练（Post-Training）—— 仅需额外指定序列并行一个参数：

sequence_parallel_size: 16

按需增加序列并行的 GPU 卡数，即可在任意长度的序列上 SFT 或 DPO。

360-LLaMA-Factory 的实现经过了严格的正确性验证，已在主仓 Pull Request 中审核过。正式合并进 LLaMA-Factory 主仓之前，可先使用 360-LLaMA-Factory。

1、项目背景与项目简介

360 智脑早在 2023 年就开始了长文本大模型的研发，到目前为止已经成功应用于开源并更新了两个版本的 360Zhinao-7B-Chat-360k 模型，以及近日发布的长思维链推理模型 360gpt2-o1。在 360-LLaMA-Factory 中，我们将 360 智脑内部长序列后训练能力系统性地整合进了 LLaMA-Factory 中，用户仅需额外添加一行代码，即可进行理论上任意长度的长序列后训练（增加序列并行的 GPU 卡数即可）：

sequence_parallel_size: 16

在原先使用 LLaMA-Factory 的基础上，只需额外增加一个参数

通过这种方式，360-LLaMA-Factory 将 LLaMA-Factory 的序列并行也做到了简单易用和兼容并包，和 LLaMA-Factory 的其他功能完全兼容。

粗粒度地测试 8 卡 80G 的全参数后训练（不考虑除了 zero3-offload 和 gradient checkpointing 外的任何优化技巧），360-LLaMA-Factory 至少可以训到 SFT 210k (7B) / 128k (72B) 和 DPO 84k (7B) / 46k (72B)。若加上注掉 logits = logits.float () 和 DPO 预计算等技巧，2 卡序列并行即可解决诸多常见的训练需求。360-LLaMA-Factory 让序列并行也真正成为了简单好用、效果也好的后训练工具。

作为开源社区的一份子，360-LLaMA-Factory 离不开 LLaMA-Factory、ring-flash-attention 和 EasyContext 等开源项目的开创性工作，我们的底层开发部分依赖了这些工作，但也有我们自己在具体实现方式上的不同和见解。我们相信我们的代码实现已做到尽可能好的模块化和尽可能少的原始代码修改，且严格检查过正确性，因此也已向 LLaMA-Factory 主仓提交了 Pull Request，初步审核通过。我们乐于同开源社区共建完善这项工作。

2、长序列及其后训练

2.1 长序列大模型的训练：预训练 vs 后训练

随着大模型训练数据长度的增长，预训练和后训练平台框架都需要支持长序列数据训练。

• 预训练阶段，英伟达的 Megatron-LM 凭借丰富高效的并行策略与出色的 GPU 显存优化，成为主流框架，基于它的定制开发往往是最通用的解法， Megatron-LM 本身已实现了序列并行（Megatron-LM 称之为 context parallelism，其他工作一般称为 sequence parallelism）。
• 后训练阶段情况相对复杂。后训练算法多样，如 DPO 就有诸多变种，且训练需求灵活多变，不同场景对算法、资源、并行性等要求各异。因此，至今没有一个框架能在并行策略、后训练算法、GPU 显存优化和易用性这四个关键方面做到近乎完美的兼容。虽有框架在部分方面表现尚可，但总体仍存在短板，这也限制了模型在长序列数据后训练上的进一步发展。

2.2 长序列的通解 —— 序列并行及其难点

长序列后训练面临的关键瓶颈是：序列长度增加时，激活显存会大幅上升。虽然有 unsloth、liger kernel、LoRA 等多种降低显存占用的技巧，但均未从根本上解决序列长度增加的本质问题，其效果存在明确上限。

序列并行（sequence parallelism）被认为是解决长序列训练问题的通解，它通过把一条长序列切分到不同的显卡上进行计算，从而避免了每张显卡处理过长的序列，从根本上解决了 “每张显卡处理的序列长度增加” 的问题。然而，序列并行的实现难度较大，需要在切分后的序列之间进行通信计算 attention，需要侵入修改原始的 attention 函数。在开源的 Megatron-LM 中，序列并行也是所有并行策略中最后才添加的，LLaMA-Factory 之前还没有支持序列并行。

2.3 序列并行后训练的相关工作

我们调研了其他一些支持序列并行的开源框架，有些实现上有错或小 bug、导致支持的后训练算法不全；有些更新维护不及时、训练较新的模型不方便、显示进度条等易用性不足。有的与 LLaMA-Factory 相比继承依赖更少，支持功能较少但更干净、更适合定制开发，有不同的使用场景。此外，各家的序列并行具体实现也不尽相同。详见下面的表 1 和 GitHub README，有未调研到的也请包涵并联系 360-LLaMA-Factory。

表 1：一些支持序列并行的后训练框架对比

3、360-LLaMA-Factory 框架解析

360-LLaMA-Factory 系统性地为 LLaMA-Factory 增加了序列并行的支持。以下将简要介绍 360-LLaMA-Factory 框架中的模块化修改和执行流程。

3.1 360-LLaMA-Factory 的框架和模块化封装

360-LLaMA-Factory 将序列并行的代码做到了尽可能好的模块化和尽可能少的原始代码修改。

我们认为序列并行本质上应认为是对模型的修改，因此在 model_args 中增加了参数并抽象为 apply_sequence_parallel 修改模型的函数。

# src/llamafactory/model/loader.py
sequence_parallel_group = apply_sequence_parallel(model_args)  # 序列并行monkey patch，改动attention计算
...
model.sequence_parallel_group = sequence_parallel_group  # 维护模型的序列并行组，不开则为None

相应地，数据处理部分也要相应地修改，我们将 zigzag ring attention 所需的数据处理抽象成了一个 decorator，装饰原来的数据处理函数。背后，这会将先 shuffle、packing、预处理好的数据进一步做好序列并行的准备：先将每行 pad 或截断到指定的训练长度，再按 zigzag 切分并按顺序写入数据集，最后在训练时用 SequentialSampler 读取训练数据。

# src/llamafactory/data/loader.py
@sequence_parallel_decorator
def get_dataset(...)

loss 计算则需要在 Trainer 中做序列并行组内的 reduce 汇总和计算。

# src/llamafactory/train/sft/trainer.py
dist.all_reduce(loss, op=dist.ReduceOp.SUM, group=sp_group)
dist.all_reduce(label_num, op=dist.ReduceOp.SUM, group=sp_group)
loss /= label_num
# src/llamafactory/train/dpo/trainer.py
dist.all_reduce(policy_chosen_logps, op=dist.ReduceOp.SUM, group=sp_group)
dist.all_reduce(policy_rejected_logps, op=dist.ReduceOp.SUM, group=sp_group)
dist.all_reduce(reference_chosen_logps, op=dist.ReduceOp.SUM, group=sp_group)
dist.all_reduce(reference_rejected_logps, op=dist.ReduceOp.SUM, group=sp_group)

3.2 360-LLaMA-Factory 的 SFT 和 DPOTrainer

除了统一的模块化抽象，序列并行也需要对 360-LLaMA-Factory 的 Trainer 稍做定制化的修改，以适配各底层库。针对最普遍的后训练需求 SFT 和 DPO（及其变种），我们对 360-LLaMA-Factory 中的 SFT 和 DPOTrainer 做了尽可能少且清晰的修改。

其中，dummy_forward 是因为我们发现基于目前的底层序列并行实现，在第一次 forward 时 DPO loss 不等于 log (sigmoid (0))，但学习率设为 0 时之后的 DPO loss 全都等于。因此，训练最开始时先做且仅做一次假前传，不对正式训练循环造成任何影响。

从 SFT 和 DPO 的序列并行对比图中，可以清晰地看出 360-LLaMA-Factory 序列并行带来的改动。

图 3：360-LLaMA-Factory SFT 序列并行对比

图 4：360-LLaMA-Factory DPO 序列并行对比

4、360-LLaMA-Factory 效果验证

内部 360-LLaMA-Factory 的早期版本已训练了开源的 360Zhinao2-7B-Chat-360k。

为验证本次开源的 360-LLaMA-Factory 的正确性，我们用总量为 30 条的小数据集，验证了序列并行开与不开的对比情况下，训练曲线的差别，以此来确保 360-LLaMA-Factory 所有实现的正确性。从下图可见，序列并行对训练曲线的影响几乎可以忽略不计，DPO 稍有一定数值误差，但我们也仔细检查了该误差与 DeepSpeed Ulysses 的误差范围一致，很可能部分是并行计算本身的随机性导致的，亦可参考 ring-flash-attention 的详细说明。

图 5：360-LLaMA-Factory SFT 和 DPO 序列并行开关对比

为便于对比效果，我们基于第三方全尺寸开源模型粗粒度压测了最大训练长度，如下表 2、表 3 所示，可见 8 卡 80G 的序列并行上限已可满足几十至几百 k 超长序列的需求：

表 2：第三方开源模型多尺寸 SFT 长度压测

表 3：第三方开源模型多尺寸 DPO 长度压测

5、总结

360 智脑开源了 360-LLaMA-Factory，支持了序列并行，仅需额外 1 个参数控制。基于 LLaMA-Factory 和 ring-flash-attention 开发，360-LLaMA-Factory 的实现模块化、效果正确且在长序列上有效。

欢迎开发者们使用和开发。在本仓库（https://github.com/Qihoo360/360-LLaMA-Factory）下提交序列并行相关的 issue 或 PR 即可。

#大模型Post-Training总结

本文汇总Llama3.1，DeepSeek-V3，TÜLU 3，Qwen2.5报告的后训练部分，摘录其中核心的细节。大多涉及到数据，SFT，RL（各种RM训练，DPO，GRPO，RLVR等等）。 ​

1 Llama3.1

​​paper: https://ai.meta.com/research/publications/the-llama-3-herd-of-models/​​

Illustration of the overall post-training approach for Llama 3.

总的来说，Llama 3后训练方法是迭代式的，总共做了6轮。每轮的核心操作是：Reward Modeling，Rejection Sampling，SFT，DPO。

数据构成主要是SFT data和Preference data。而Reward Modeling和DPO，对Preference data又有不同的使用方式。

• SFT data：每轮Rejection Sampling的结果 + 针对特定能力的合成数据 + 少量的人工标注数据。
• Preference data：每一轮训练都构建一批新的Preference data，Preference data积累式地增长。详细过程见1.2 Preference data部分。

Model Averaging：每个RM、SFT或DPO阶段，使用不同的data mix或超参数进行实验所获得的模型进行加权平均。

1.1 SFT

SFT数据构成

Rejection Sampling：采样模型多次，让RM选出最好的回复，作为SFT data的一部分。部分细节如下：

• 采样什么模型？两种情况。迭代中表现Avg score最好的模型，或者在某个particular capability上表现最好的模型。
• 采样多少次？K=10~30，即一般采样10-30次。
• prompt哪来？人工标注的prompts。并在后训练迭代后期引入特殊的system prompts。

SFT训练细节：

• 405B模型使用学习率1e-5。
• 训练步数在8.5K到9K步之间。
• 高质量数据源进行多轮重复训练(epochs multiple times)。例如一个特别优质的coding示例可能被训练3-4次。
• 普通质量数据进行降采样(downsamples)。质量一般的数据可能只用1次或被随机抽样部分使用。

Our final data mix epochs multiple times on some high quality sources and downsamples others.

1.2 Preference data

Preference data数据构成

We deploy multiple models for annotation after each round and sample two responses from two different models for each user prompt. These models can be trained with different data mixes and alignment recipes, allowing for different capability strength and increased data diversity.

• 采样什么模型？部署多个不同数据配比和对齐方法训练的模型，针对每个prompt选取两个不同的模型进行采样。原因：不同模型能够在不同的能力维度上表现出差异，数据质量和多样性更好。
• 偏好等级？四个等级：显著更好（significantly better），更好（better），稍微更好（slightly better），略微更好（marginally better）。
• 允许修改：标注同学可以进一步优化chosen response，最后edited > chosen > rejected。
• 迭代式难度：最后随着模型改进逐步提高prompt复杂度。

1.3 RM & DPO

Reward Modeling：We train a reward model (RM) covering different capabilities on top of the pre-trained checkpoint.
DPO：For training, we primarily use the most recent batches of preference data collected using the best performing models from the previous alignment rounds.
Preference Data：In each round of post-training, we use all the preference data that is available at the time for reward modeling, while only using the latest batches from various capabilities for DPO training.

RM迭代细节： RM也参与后训练迭代。每一轮迭代都会重头训练RM。原文提到，每次训练都会使用所有的Preference data，且都是从Pre-trained checkpoint开始训练的，而不是在t+1轮迭代使用第t轮训练的RM做增量训练。

Llama2 RM ranking loss

• 移除llama2使用的margin loss，即上图的m(r)，因为数据量上来之后margin意义不大，不如“complexity management”回归原始ranking loss：
• RM和DPO都只使用偏好等级为significantly better or better的pair，并且都过滤了similar response。

DPO迭代细节：

DPO每次都在SFT之后进行。此处的一个细节是，DPO训练所用的Preference data并全不是在本轮的SFT model上采样和标注的，而主要是从前面所有迭代轮次中表现最好的模型中采样得到的。同时，每次迭代只取最新的一批Preference data，还要剔除General English部分数据，和RM不一样。loss：

• 同时从chosen和rejected response里面mask掉special formatting tokens的loss，比如header token & termination token，因为会引入冲突的学习目标，即loss同时往增加和减少这些token的概率上优化。
• 同时优化chosen response的SFT loss。
• 学习率取1e-5，beta取0.1，SFT loss取0.2。
• RM和DPO都只使用偏好等级为significantly better or better的pair，并且都过滤了similar response。

DPO discussion

DPO团队观察到，只要SFT模型在Long context任务中表现出色，DPO中仅使用短上下文训练数据，并不会对长上下文性能产生负面影响。

1.4 数据清洗

Llama 3给出的数据清洗方法都很务实。

首先是对一些不想要的回复模式需要去重，例如过度使用表情符号或感叹号的问题。非常经典的AI语风也需要注意，例如“过于喜欢滑跪”的语气问题，遇事不决就“对不起”或“我道歉”。其他各种方法还有：

1、主题分类（Topic classification）： 首先训练一个Topic classifier，例如用一大堆文本分类的任务数据去SFT一下Llama 3 8B。然后对所有训练数据进行两个层级的分类，粗粒度类别（如“数学推理”）和细粒度类别（如“几何和三角学”）。

2、质量评分（Quality scoring）： 使用Reward model和基于Llama为每个样本的质量打分。对于基于RM的评分，将得分前1/4的数据视为高质量数据。基于Llama的评分，就是基于Llama 3设计了一些打分的prompt，General English数据使用三个维度的评分（准确性、指令遵循性和语气/表达），coding数据则使用两个维度的评分（错误识别和用户意图），最后将获得最高分的样本视为高质量数据。RM评分和Llama评分的分歧率较高，但结合这两种机制能在meta内部测试集中取得最佳的召回率。

3、难度评分（Difficulty scoring）： Instag和基于Llama的评分。对于Instag，提示Llama 3 70B对SFT提示进行意图标注，意图越多，复杂性越高。基于Llama的思路和Quality scoring相似，给了Llama 3一些prompt，基于三个维度去打分。

4、语义去重（Semantic deduplication）： 最后进行语义去重。首先使用RoBERTa对完整对话进行聚类，然后在每个聚类内按（质量分数 × 难度分数）对其进行排序。接着，遍历所有排序的样本进行贪婪选择，仅保留与当前聚类中已见样本的余弦相似度小于阈值的样本。

Instag用于标注SFT数据的意图和语义标签。详见：​​https://arxiv.org/pdf/2308.07074​​​

2 DeepSeek-V3

​​paper: https://github.com/deepseek-ai/DeepSeek-V3/blob/main/DeepSeek_V3.pdf​​

DeepSeek-V3的后训练路径是SFT->GRPO。后训练部分同时提到了一些从DeepSeek-R1蒸馏的探索，Self-Rewarding的尝试，以及Multi-Token Prediction的效果。全文精彩内容主要在前边 pretrain ，但目前只想先整理后训练部分。

2.1 SFT

DeepSeek-V3构建了一个1.5M（V2也是大概1.5M）的指令微调数据集，并且构建数据时按照ReasoningData和Non-Reasoning Data做了区分。

推理相关数据

对于推理相关的数据集（Math，Coding，逻辑推理），通过 DeepSeek-R1 生成数据。尽管 R1 生成的数据表现出较高的准确性，但同时也存在诸如过度思考、格式不佳以及回答冗长等问题。所以目标是结合 R1 生成数据的高准确性与常规格式化推理数据的清晰性与简洁性。

具体来说，首先针对特定领域训练多个expert model。随后，expert model被用作最终SFT data的generator。Expert model训练过程中，需要为每条数据实例生成两种不同类型的 SFT 样本：

1. 将问题与其原始回答配对，格式为 <问题, 原始回答>；
2. 在问题和 R1 回答的基础上加入系统提示，格式为 <系统提示, 问题, R1 回答>。

System prompt引导模型生成具有反思与验证机制的回答。在RL阶段，模型通过high-temperature sampling生成回答，从而整合R1生成数据和原始数据的模式，即便在没有明确system prompt的情况下也能体现。经过数百步的强化学习后，Expert model模型学会了融合 R1 的模式。

Expert model的RL训练完成后，使用拒绝采样（RS）以筛选高质量的 SFT 数据，用于最终模型的训练。此时由于是expert model作为generator，所以保留了 DeepSeek-R1 的各种优势，也能同时生成简洁高效的回答。

非推理数据

对于非推理数据（例如创意写作、角色扮演和简单问答），采用 DeepSeek-V2.5 生成回答，并由人工标注人员核实数据的准确性与正确性。

SFT 细节

• 训练两个epoch，learning rate采用cosine decay ，起始学习率为 5×1e-6，逐步衰减至 1e-6。
• 训练期间，每个sequence由多个样本数据打包组成（即SFT packing）。但不同样本间需要额外的attention mask，确保这些样本彼此独立且不可见。但值得一提的是，V3在 pretrain 时，没有应用cross-sample attention mask。

Discussion：DeepSeek-R1 的蒸馏效果

The contribution of distillation from DeepSeek-R1

报告基于DeepSeek-V2.5研究了从DeepSeek-R1蒸馏的贡献。DeepSeek-R1 Distill在LiveCodeBench和MATH-500基准测试中取得了显著提升。

基于MATH-500，可以发现一个有趣的trade off是：蒸馏可以带来更好的性能（74.6->83.2），但同时也显著增加了平均回答长度（76.9->83.2）。

报告认为从推理模型进行知识蒸馏为post training提供了一个有前景的方向。

2.2 RM

DeepSeek-V3 RL过程训练了两种RM：rule-based and model-based。

Rule-Based RM

对于可以通过特定规则验证的问题，基于规则来确定奖励。例如对于某些数学问题，这类问题具有确定性的答案，要求模型以指定的格式（例如，用一个框框标出最终答案）提供最终答案，从而能够通过规则验证其正确性。同样地，对于 LeetCode 问题，可以利用编译器通过测试用例生成反馈。也是非常经典的做法，能够确保reward非常可信。TÜLU 3同样也做了RLVR。

Model-Based RM

对于具有自由形式的标准答案的问题，依赖RM来判断回答是否与预期的标准答案相匹配即可。但对于没有明确标准答案的问题（例如涉及创意写作的问题），RM需要根据问题和对应的回答提供反馈。Model-Based RM基于 DeepSeek-V3 的 SFT checkpoint进行训练。为了提高其可靠性，还构建了包含偏好数据的训练集，该数据不仅提供最终的reward，还包含通向reward的推理链。该方法减少了在特定任务中出现的reward hacking。

Discussion：Self-Rewarding

即constitutional AI的做法，通过一系列文本描述的规则指导模型。将DeepSeek-V3 本身的投票评估结果也作为一种feedback，显著提升了 DeepSeek-V3 在主观评价中的性能表现。

联想：DeepSeekMath

DeepSeekMath报告提到过使用了Process Supervision RL，但DeepSeek-V3报告中未提及。

2.3 GRPO

GRPO是PPO的简化版本，最核心的改动是砍掉Value Model，依靠多次采样的Reward，得出baseline分数来计算advantage。DeepSeek-V3未在GRPO一节提供较多细节。GRPO的优势函数为：

优化目标为：

GRPO 图示 from DeepSeek-V2

GRPO详细算法可见DeepSeek-V2报告。GRPO和RLOO做法类似，而TRL rloo_trainer.py实现了RLOO训练源码，可以参考。能理解其中一个就能理解另一个。所以也可参考：https://zhuanlan.zhihu.com/p/1073444997

3 TÜLU 3

​​paper: https://allenai.org/tulu​​

An overview of the TÜLU 3 recipe.

TÜLU 3的后训练路径是SFT->DPO->RLVR。TÜLU 3报告写的还是非常有诚意的，RL部分提供了蛮多细节供学习。也是印象中少有的花了比较大篇幅讲RLVR的一篇报告。

3.1 SFT

数据构成

WildChat，OpenAssistant，NoRobots,，FLAN v2等各种质量还不错的开源数据。人工标注或者好的闭源模型的response保留，没有response的蒸馏4o。

数据实验

• 多样化对话数据(WildChat)，对大多数技能有积极影响，特别提升Alpaca Eval性能。
• 安全性 SFT 数据通常与其他数据集正交。
• ...（还有一些其他数据实验，如chat template...详见原文）

Recipe

超参

batch size 128，Max Length 4096，Linear LR。对于8B模型，学习率：5e-6。对于70B模型，学习率：2e-6。训2个epoch。

Trick：Batch Aggregation

TÜLU 3注意到Open-Instruct框架训练的SFT模型与在其他环境(如TPU)上训练的模型之间存在性能差距。这个问题主要是由于Transformers中loss aggregation的一个问题：在不考虑梯度累积或分布式训练设置的情况下对padding tokens的损失进行平均。

报告用一个例子来说明这个问题。假设批次中有两个样本，分别有  ， 个non－padding tokens和  ， 个填充标记。如果同时将两个样本输入默认的Transformers forward pass：

然而，如果应用gradient accumulation分别输入两个样本，计算损失，然后除以 2 ：

第二种情况下平等地对待每个样本,，而在第一种情况下平等地对待每个token。因此改变梯度累积可能会由于有效地改变样本权重而对性能产生重大影响。由于跨设备平均,分布式训练中也会出现类似的问题。

所以TÜLU 3在训练时普遍选择使用求和损失（sum loss）而不是平均损失（mean loss）。即通过简单地移除上述方程中的分母，同时调整学习率。这使得所有token被赋予相同的权重。TÜLU 3通过使用各种学习率、训练轮数和损失类型在TÜLU 2 SFT混合数据集上微调Llama 3.0来验证各种设置的性能。最终发现使用lr = 5e-6的sum loss效果最好。TÜLU 3还发现更长时间的训练并没有带来进一步的改进，因此确定使用2个训练epoch。

3.2 Preference Finetuning

TÜLU 3在Preference Finetuning中提及了大量实验。

优化算法实验

优化算法实验

标准DPO：

TÜLU 3在实验后最终采取了length-normalized DPO：

顺带一提SimPO的优化目标（ref model free）：

PPO的优化目标：

TÜLU 3场景中，不同RL算法的实验结论是，length-normalized DPO效果最好，SimPO甚至性能不如SFT-base。

preference dataset

In summary, our preference mixes come from different prompt sources, such as SFT data, WildChat and Persona IF. It includes prompts seen during SFT training but also new, unseen prompts. And lastly, it contains a mix of on and off-policy completions.

TÜLU 3的preference data既有off-policy的pair，也有on-policy的pair。既有SFT阶段见过的prompt，也有新的prompt。人工 + 4o as Judge。报告针对不同data mix做了很多实验，获得了一些符合直觉的结论，列举部分：

Scaling the Number of Unique Prompts Improve Downstream DPO Performance. 增加prompt多样性能够提升DPO效果符合直觉。不过TÜLU 3做了一个清晰的实验是：验证复制一些prompt（但使用不同的response pair）做数据增广是否可行。可惜，结果是Performance退化了。

Unused Prompts Lead to Higher Performance vs. Reusing Prompts From SFT Mix. 即DPO阶段的prompt还是应该尽量SFT阶段没见过的。

On-policy Data Improves Downstream DPO Performance. 即On-policy Data（模型采样出来的pair）效果更好。

Recipe

3.3 RLVR（RL with verifiable rewards）

RLVR

其实就是基于Rule-Based RM做RL的另一种说法。不同于DeepSeek-V3和Qwen2.5采取的GRPO，RLVR的算法采取了PPO。PPO需要value model，但reward model目前是一个verifier，所以TÜLU 3使用General RM来初始化value model。

Do Not Use the Scores from RM. TÜLU 3在RLVR过程中，发现如果同时使用verifiable reward和RM的reward，会引入额外的噪声，导致表现下降。​

4 Qwen2.5

​​paper: https://arxiv.org/abs/2412.15115​​

Qwen2.5的后训练路径是SFT + Two-stage Reinforcement Learning，即SFT- >DPO->GRPO。报告总体细节不多。

4.1 SFT

MathQwen2.5-Math 的 CoT 数据 + RS。

CodingQwen2.5-Coder 的指令微调数据。

...（不再列举，细节不多）

Recipe

最终，SFT构建了包含1M的大规模数据集，训练使用32K的序列长度，训练2个epoch，lr从7×10⁻⁶衰减到7×10⁻⁷、weight decay开0.1，gradient norms裁剪到最大值1。

4.2 DPO

Rule-based data

依靠strategies like execution feedback and answer matching，利用SFT对一批新的prompt采样，通过Rule检测的，作为chosen，否则作为rejected，当然也需要人工审核。

数据量

150,000 training pairs。

训练recipe

标准DPO（未提及使用了length-normalized DPO或者SimPO等变种），Online Merging Optimizer，lr = 7e-7，训练1个epoch。

Online Merging Optimizer：https://arxiv.org/abs/2405.17931

4.3 GRPO

相关原理见deepseek-V3一节中的GRPO。

RM的训练数据

采样什么模型？部署多个不同数据配比和对齐方法训练的模型，针对每个prompt选取不同的模型进行采样，温度也开得比较高。原因：不同模型能够在不同的能力维度上表现出差异，数据质量和多样性更好。

GRPO数据

GRPO的prompts和RM训练的Prompts相同。

Trick

训练期间处理prompt data的顺序由RM评估的reward score方差决定。方差较高的prompt会被优先处理，以确保更有效的学习。

超参设置

每个query采样8次。2048 global batch size and 2048 samples in each episode。

#突发！美国拟（全面禁止）向中国出口 AI 芯片

2025 年 1 月 9 日，拜登政府计划在离任前夕对英伟达等公司的 AI 芯片出口实施新一轮限制。

据悉，新规可能最早于周五发布，并将设立三个层级（Tier 1，Tier 2，Tier 3）的芯片限制措施。

• Tier 1的美国少数盟友，可以不受限制地获取美国芯片
• Tier 2的国家和地区，将面临以国为单位的总算力限制
• Tier 3的国家和地区，数据中心将被全面禁止进口芯片

美国希望在国家层面和公司层面限制数据中心所用 AI 芯片的销售，目的是将 AI 发展集中在友好盟国，让全球各地的企业符合美国的标准。

其结果是将半导体贸易限制范围扩大到全球大部分地区，试图在需求井喷之际控制 AI 技术的传播。

总体而言，少数美国盟国实际上可以不受限制地获得美国芯片。

而同时，敌对国家将被严格阻止进口半导体。世界上绝大多数国家的总算力都将面临限制。

只要同意美国政府的一系列安全要求和人权标准，总部位于上述最后一类国家的公司就可以绕过美国对该国的限制，获得更高的出口限额。这种类型的指定被称为经过验证的最终用户（VEU），旨在确立一系列美国认证的实体，在全球安全环境中开发和部署 AI。​

第一层级管控

新规则确立的第一层级包括美国及 18 个盟友国家或地区，如德国、荷兰、日本、韩国等。

公司可以在这些地区随意部署算力，总部设在这些地区的公司可以申请美国政府的全面许可，以便将芯片运送到全球大多数其他地方的数据中心。前提是，它们在第一层级国家或地区以外的算力不得超过总算力的 25%，在任何第二层级国家或地区的算力不得超过 7%。企业还必须遵守美国政府的安全要求。

此外，如果总部位于美国的公司申请 VEU 资质，必须确保至少 50% 的总算力留在美国境内。这些法规的更大目标是确保美国及盟国始终拥有比世界其他地区更强大的算力。​

第二层级管控

绝大多数国家属于第二层级管控对象，规定了一个国家所能获得的算力上限。

从 2025 年到 2027 年，最多获得约 5 万块 GPU。但是如果公司在希望建立数据中心的每个国家申请 VEU 资质，可以获得更高的上限，上限还会随时间的推移逐步提高。

若要获得批准，企业需要证明具有符合美国政府安全和人权标准的过往记录，或者至少有可靠的方案来符合标准。安全要求涉及物理、网络和人员等方面的问题。如果公司获得某国的 VEU 资质，其芯片进口将不会计入该国的最大总算力，此举旨在鼓励公司与美国政府合作，并采用美国的 AI 标准。​

第三层级管控

第三层级也是最严格的层级，影响中国、中国澳门以及美国继续实施武器禁运的所有国家和地区，总共涉及约 24 个国家和地区。向这些地方的数据中心出口芯片被全面禁止。​

模型权重

除了半导体管制外，新规则还限制了闭源 AI 模型权重的出口，AI 模型权重是软件用于处理数据并做出预测或决策的数值参数。

公司不得在中国和俄罗斯等第三层级国家托管强大的闭源模型权重，并且必须遵守安全标准才能在第二层级国家托管这些权重。这意味着模型权重方面的管制并不适用于获得 VEU 资质的公司。

开源权重模型（允许公众访问底层代码）不受规定的影响，不如现有的开源模型强大的闭源模型也不受规定的影响。但如果一家 AI 公司想要针对特定目的对通用开源权重模型进行微调，而且这个过程耗用大量算力，它们就需要向美国政府申请许可，才能在第二层级国家开展相关操作。

英伟达在声明中反对该提议。

英伟达表示：“在最后一刻出台限制向全球大部分地区出口的规定无异是政策的重大转变，不会降低滥用风险，反而会威胁经济增长和美国的领导地位。全球对日常应用中加速计算的广泛兴趣是美国促进经济和创造就业岗位的大好机会。”

与英伟达一样，美国半导体行业协会也反对此举。该协会在一份声明中表示：“在总统交接期间且未广泛征询行业意见的情形下，不应匆忙出台规模和重要性如此重大的政策改变。规避审慎的决策程序的风险实在太大。我们国家需要做好这件事，那样才能在全球竞争中获得优势。”

#GAN归来

模型大幅简化，训练更稳定，逆袭扩散模型，AI社区疯传

GANs are so back!?

2025 年了，GAN 能否击败扩散模型？答案是 Yes！

本周五，AI 社区开始讨论一种全新极简主义 GAN（生成对抗网络）。

现代版 GAN 基准论文成为了周五 HuggingFace 热度最高的研究。该论文也入选了 NeurIPS 2024。

它并不像以往那样走 tricks 路径 —— 通过一场「现代化」改造，GAN 现在可以进行更长时间的训练（与扩散模型的训练步骤数相当），一旦 GAN 训练时间足够长，并且架构足够强大，它们就可以胜过扩散模型，并成为更好、更快、更小的模型。

来自布朗大学、康奈尔大学的研究者们表示，通过引入一个新的损失函数，我们就可以解决以往 GAN 模式崩溃（collapse）和不稳定性的问题。

为了证明可行性，他们测试了 GAN 里流行的 StyleGAN2，通过新的理论进行最简升级（修改后改名为「R3GAN」）。结果虽然模型变得更简单了，但 R3GAN 在图像生成和数据增强任务上性能还是超过了所有 GAN 模型和扩散模型。

新的方法给未来的研究奠定了一个更为整洁、可扩展的基础。

• 论文链接：https://arxiv.org/abs/2501.05441
• GitHub 链接：https://github.com/brownvc/R3GAN
• HuggingFace：https://huggingface.co/spaces/multimodalart/R3GAN

有一种广泛流传的说法认为 GAN 很难训练，并且文献中的 GAN 架构充斥着大量的经验性 tricks。但是作者团队提供了反驳这一说法的证据，并以更有原则的方式建立了一个现代版 GAN 基线。

在该研究中，作者首先通过推导出一个行为良好的正则化相对 GAN 损失函数，解决了模式 dropping 和不收敛问题，而这些问题在以前经常是通过大量 ad-hoc tricks 来应对的。他们从数学层面分析了这一损失函数，并证明它具有局部收敛保证，这与大多数现有的相对损失函数不同。

其次，这个损失函数能够抛弃所有的 ad-hoc tricks，并用现代版架构替代常见的 GAN 中所使用的过时的骨干网络。以 StyleGAN2 为例，他们展示了一个简化过的现代版路线图 ——R3GAN（Re-GAN）。尽管方法非常简单，但它在 FFHQ、ImageNet、CIFAR 和 Stacked MNIST 数据集上却超越了 StyleGAN2，并且在与最先进的 GAN 和扩散模型的比较中表现出色。

在生成式 AI 技术兴起之前，GAN 是 AI 领域中的热门研究方向，该方法能让我们能够在一次前向传递中生成高质量图像。然而我们无法忽略的是，Goodfellow 等人构建的原始目标因其极小极大特性而极难优化，训练的不稳定性一直对 GAN 的研究产生着负面影响。

与扩散模型等其他生成模型相比，GAN 的发展一直比较缓慢。考虑到一旦得到了表现良好的损失函数，我们就可以自由地设计现代 SOTA 主干架构。在新工作中，作者剥离了 StyleGAN 的所有功能，找出那些必不可少的功能，然后从现代 ConvNets 和 transformer 中借用了架构设计，包括一系列 ResNet 设计、初始化、重采样、分组卷积、no normalization 等，引出了一种比 StyleGAN 更简单的设计。

该工作率先从数学上证明了 GAN 不需要通过改进的正则化损失来进行训练。

提高训练稳定性

该研究证明，通过将目标进展与正则化训练损失结合起来，GAN 获得了更高的训练稳定性，能够用现代骨干网络升级 GAN。

首先，该研究提出了一个新的目标，通过零中心梯度惩罚增强 RpGAN，提高稳定性。该研究从数学上证明，梯度惩罚 RpGAN 与正则化经典 GAN 享有相同的局部收敛保证，并且删除正则化方案会导致不收敛。

在定义 GAN 的目标时，研究者需要应对两个挑战：稳定性和多样性。为了在这两方面同时取得进展，该研究将 stable 方法与基于理论的简单正则化器结合起来。

传统 GAN 被表述为判别器 D_ψ 和生成器 G_θ 之间的极小极大博弈：

在实际实现中，传统 GAN 容易受到两种常见故障场景的影响：模式 collapse/dropping 和不收敛。 

该研究采用了一种略有不同的极小极大博弈 ——RpGAN，由 Jolicoeur-Martineau 等人提出，以解决模式 dropping 问题。

一般的 RpGAN 定义为：

然而，经验表明，未正则化的 RpGAN 表现不佳。

为了解决 RpGAN 不收敛的问题，该研究探索梯度惩罚作为解决方案，因为事实证明，零中心梯度惩罚 (0-GP) 有助于经典 GAN 的收敛训练。两个最常用的 0-GP 是 R1 和 R2：

研究团队认为实际的解决方案是在真实数据和虚假数据上对 D 进行正则化。此外，如 Fang et al.(2022) 所言，真实数据和虚假数据具有大致相同的梯度范数可能会减少判别器过拟合。

新基线的路线图 — R3GAN

行为良好的 RpGAN + R1 + R2 损失函数缓解了 GAN 优化中的问题，同时根据近期的骨干网络进展，这使他们能够构建一个极简版基线 ——R3GAN。这不仅仅只是提出一种新方法，而是从 StyleGAN2 基线中绘制出一条路线图。

这个模型（配置 A）包括一个类似于 VGG 的骨干网络（G），一个 ResNet（D），一些有助于基于风格生成的 tricks，以及许多作为修补弱骨干网络的 tricks。接着去除了 StyleGAN2 中所有非必要的特性（配置 B），并应用他们的损失函数（配置 C），逐步现代化网络骨干（配置 D-E）。

架构比较

实验细节

模式恢复 — StackedMNIST 

研究团队在 StackedMNIST（无条件生成）上重复了之前在 1000-mode 收敛实验中的做法，但这一次使用了更新后的架构，并与最先进的 GAN 及基于似然的方法进行了比较。

在 Stacked-MNIST 上使用配置 E 生成的样本定性示例

FID — FFHQ-256

研究者训练配置 E 模型直到收敛，并在 FFHQ 数据集上使用优化的超参数和训练计划进行 256×256 分辨率的无条件生成。

在 FFHQ-256 上使用配置 E 生成的样本定性示例

FID — FFHQ-64

为了与 EDM 进行直接比较，研究团队在 64×64 分辨率的 FFHQ 数据集上评估了模型。为此，他们去除了 256×256 模型中的两个最高分辨率阶段，从而得到了一个生成器，其参数数量不到 EDM 的一半。尽管如此，他们的模型在该数据集上的表现仍是超过了 EDM，并且只需要一次函数评估。

FID — CIFAR-10 

研究者训练配置 E 模型直到收敛，并在 CIFAR-10 数据集上使用优化的超参数和训练计划进行条件生成。尽管模型容量相对较小，他们的方法在 FID 指标上超过了许多其他 GAN 模型。

在 CIFAR-10 上使用配置 E 生成的样本的定性示例

FID — ImageNet-32

研究者训练配置 E 模型直到收敛，在 ImageNet-32 数据集上使用优化的超参数和训练计划进行条件生成，并与近期的 GAN 模型和扩散模型进行了比较（见下图）。

作者团队调整了模型生成器的参数数量，使其与 StyleGAN-XL 的生成器相匹配（84M 参数）。尽管使用了比判别器小 60% 的模型，并且没有使用预训练的 ImageNet 分类器，该方法仍然达到了可媲美的 FID 值。

在 ImageNet-32 上使用配置 E 生成的样本定性示例

FID — ImageNet-64 

研究团队在 ImageNet-64 数据集上评估了他们的模型，以测试其可扩展性。他们在 ImageNet-32 模型的基础上增加了一个分辨率阶段，从而得到了一个包含 104M 参数的生成器。该模型的参数量几乎是依赖于 ADM 骨干网络的扩散模型 的三分之一，这些模型的参数量大约为 300M。

尽管模型较小，并且他们的模型在一步生成样本的同时，其在 FID 指标上超越了更大参数量的扩散模型（见下图）。

在 ImageNet-64 上使用配置 E 生成的样本定性示例

新 GAN 研究正在社区获得越来越多的关注。StabilityAI 的研究总监也转发了该篇论文，并对作者团队去除了 StyleGAN 中许多复杂性并且提高性能一点，给出了高度评价。

GAN 加入了现代化元素之后，是否可以重新起航逆袭 Stable Diffusion？对此，你怎么看？

参考内容：

​​https://huggingface.co/papers/2501.05441​​

​​https://x.com/iscienceluvr/status/1877624087046140059?s=61​​​

#迈向System 2推理，100页论文硬核讲述Meta-CoT

Meta-CoT 通过显式建模生成特定思维链（CoT）所需的底层推理过程，扩展了传统的思维链方法。

「我们有一份关于『推理时间计算』的新研究，以及我们过去几个月一直在研究的内容！我们提出了一些理论，说明为什么它是必要的，它是如何工作的，我们为什么需要它，以及它对超级智能意味着什么。」

刚刚，斯坦福博士生 Rafael Rafailov 在 X 上官宣了一项他参与的新研究《 Towards System 2 Reasoning in LLMs: Learning How to Think With Meta Chain-of-Thought 》。

Rafailov 进一步表示，「我们需要高级推理的主要原因在于问题的复杂性。模型训练数据中虽然包含了难题的解决方案，但并未涵盖这些解决方案的真实数据生成过程。解决方案本身是某种复杂的元思维链（Meta-CoT）的输出，而这一过程并未被明确记录下来。」

图为解决一个数学问题的过程，这个问题是要找到一种运算符序列（包括加号 +、减号 -、乘号 * 和除号 /），使得数字 7、3、11、5 通过这些运算恰好使用一次得到结果 24。

Rafailov 所说的 Meta-CoT，是一种新颖的框架，它通过显式建模生成特定思维链（CoT）所需的底层推理过程，扩展了传统的思维链方法。

该研究认为，传统的 CoT 方法虽然在解决简单问题时有效，但未能捕捉到复杂推理的真实数据生成过程，这一过程通常涉及非线性、迭代性和潜在的探索与验证。Meta-CoT 通过显式建模这种潜在的「思考」过程，扩展了 CoT 方法。本文认为，这种建模对于解决需要高级推理能力的问题至关重要。

• 论文地址：https://arxiv.org/pdf/2501.04682

该研究从认知科学的双过程理论中汲取灵感，将 Meta-CoT 框架看作为一种 System 2 推理形式。本文奠定了 Meta-CoT 理论基础，展示了如何通过系统搜索过程实现这一框架，以及如何将这些过程内化到一个单一的自回归模型中。随后，本文提供了实证证据，包括对 OpenAI 的 o1 和 DeepSeek-R1 等顶尖模型的分析，这些模型展现出了与内化（上下文）搜索一致的行为。接着本文进一步探索了通过过程监督来训练 Meta-CoT 模型的方法，以及通过蒙特卡洛树搜索（MCTS）和 A * 等搜索算法生成合成数据的技术。

最后，本文概述了一个在单一端到端系统中实现 Meta-CoT 的具体流程，该流程结合了带有线性化搜索痕迹的指令调整和强化学习（RL）后训练。

本文还介绍了一个名为 Big MATH 的项目，该项目整合了超过 100 万个高质量、可验证的数学问题，以促进这一领域进一步研究。

该研究不仅提供了理论洞见，还为在 LLM 中启用 Meta-CoT 提供了一条实践路线图，为人工智能实现更强大和更类人的推理铺平了道路。

为什么要提出 Meta-CoT？   

Meta-CoT 是什么样的？     

我们要问自己一个问题：具有「思维链」提示功能的语言模型是否真的能够表达任何函数，从而解决任意复杂的问题？今天，前沿模型的能力足以解决一大类数学推理问题。但是，它们仍然难以解决高级问题，如 HARP 和 Omni-MATH（通用奥林匹克级别数学基准）。作者提出了以下理论来解释这些经验观察结果：

预训练语料库中的推理数据并不代表真正的数据生成过程，尤其是复杂问题的数据生成过程，它是大量潜在推理的产物。此外，这一过程一般不会以从左到右、自回归的方式进行。

更详细地说，预训练语料库和后训练指令微调中普遍存在的思维链（CoT）推理数据遵循简单问题（如代数计算、计数、基础几何等）解决方案的真实数据生成过程。例如，解决高中代数问题的教科书展示了生成答案的一般过程。如果我们遵循现有教科书中呈现的一些步骤或方法，我们最终可以得出解答。因此，这些可以通过具有恒定深度的 transformer 来学习，这些 transformer 能够表达过程中每个单独步骤的复杂性。

相比之下，复杂推理问题并不遵循这种模式。我们可能有一组三元组（q, S, a），其中 q 是问题，S = (s_1, ..., s_n) 是解答步骤，a 是（可选的）答案，但真实的数据生成过程并非自回归的：

z_𝑖是解答步骤中遗漏的潜在「思考」，这些可以通过从左到右的生成来完全表示，而数据集中的解答步骤 S = (s_1, ..., s_n) 是联合生成的。

我们可以通过将推理解释为潜在变量过程来形式化这一论证。具体来说，经典的思维链（CoT）可以被看作是：

即，最终答案产生的概率是通过对潜在推理链的边缘化得到的。作者主张，对于复杂问题，真实的解生成过程应该被视为：  

即，解（a，s_1, . . . , s_n）的联合概率分布以潜在生成过程为条件。请注意，这个参数是先前的 CoT 参数的 meta-generalization，因此作者将过程 q→z_1 → . . . → z_K 称为 Meta-CoT。

传统 CoT 有什么问题？   

根据之前的讨论，一个问题自然地浮出水面：为什么 LLM 在这些高级推理任务上失败了？如上所述，作者提出了预训练和指令微调语料库由类型为（q, s_1, ..., s_n, a）的数据组成，这些数据并不包含如方程 1 所示的真实数据生成过程。这个现象很常见 —— 教科书包含高级证明，但不包含推导这些证明的完整思考过程。

很多使用传统思维链的工作受此影响，但 OpenAI 的 o1 系列看起来是个例外。作者表示，他们在困难的数学问题上看到了这种差异：「标准」模型会「模仿」人类编写的解决方案（训练数据），而像 o1 这样的模型则根据难度逐步使用更多的计算。它似乎遵循真正的数据生成过程，而不仅仅是最终输出（CoT）。

用语言模型进行深思熟虑的推理 —— 搜索

上一节介绍了 Meta-CoT 过程，并指出 LLM 在高级推理任务上表现不佳的原因是训练数据未能充分代表真实的数据生成过程，即文本语料库中未包含（或仅包含有限数量的）Meta-CoT 数据。因此，剩下的问题是：真实的数据生成过程是什么样的？

首先，本文主张对于许多高级推理或目标导向问题，生成（问题的解决过程）和验证（解决方案的正确性检验）之间存在显著的复杂性 gap。

其次，假设存在一个不可忽视的生成器 - 验证器 gap，作者认为文本语料库中呈现的挑战性问题的解决方案是一个扩展搜索过程的结果，这个过程本身在数据中并没有得到体现。

作者表示，事实上，在基本策略之上构建搜索能力已经一次又一次地被证明会带来巨大的能力提升。不过，这需要更多数量级的 scale 和数据才能内化到单个模型中。

迈向 Meta-CoT 推理

为什么需要将深思熟虑的推理过程内化到一个单一模型中？作者提出了两个主要原因：

首先是效率：通过在自回归模型的上下文中整合搜索，可以有效地完成探索，因为模型可以访问上下文中所有先前访问过的节点。事实上，正如图 14 所示，即使是高级推理模型也会执行许多语义相同的重复推理步骤。

其次是超级智能：如果一个自回归模型能够学会在上下文中实现搜索算法，那么额外的强化学习（RL）训练可能使模型发现新的推理方法。这将可能使模型能够解决在基于符号的树搜索方法下解决以前无法解决的问题类别。

在接下来的部分，作者进一步探讨了如何训练一个模型来内化这样一个推理系统。

作者介绍了 STaR（Self-Taught Reasoner）方法背后的核心思想，该方法用于引导中间 CoT 步骤，以及如何将类似的概念泛化到元推理策略中。

具体而言，STaR 方法引入了一种迭代 bootstrapping 方法，旨在提高 LLM 的推理能力。STaR 专注于训练模型以生成和完善推理过程，特别是对于需要复杂推理的任务，其采用了基于强化学习的方式来进行。

之后作者将 STaR 的思路扩展到 Meta-CoT。

通过搜索合成 Meta-CoT

本文探索了两种用于生成合成训练数据的主要搜索算法：蒙特卡洛树搜索 (MCTS) 和 A* 变体。

蒙特卡洛树搜索如下：

与图 12 中由蒙特卡洛树搜索（MCTS）产生的路径相比，A* 搜索具有更少的回溯步骤，主要集中在关键步骤上。

过程监督

搜索方法的一个关键组成部分是评估函数𝑣(q, S_𝑡)，它对推理链中的中间状态进行评分。这些评估函数被广泛称为过程奖励模型（Process Reward Models，简称 PRM）。通过整合过程监督，搜索机制获得了在遇到次优路径时回溯到早期有前景状态的灵活性，从而实现了更有效的探索。然而，如何有效地获取这些能力仍然是一个未解决的问题。

作者概述了构建此类过程指导模型的策略：

• 学习过程奖励模型；
• PRM 质量及其对搜索的影响；
• 可验证问题与开放式问题。

在论文第 6 章，作者从元学习和元强化学习的角度对推理问题和 Meta-CoT 进行解释。

在前面章节中，作者通过计算复杂性和生成器 - 验证器 gap 的范例来激发上下文搜索的需求。在本节中，作者建立了一个替代公式，以帮助形式化强化学习训练的实证结果。

作者假设奖励函数𝑟(S, q) → {0, 1} 是提示 q 的确定性（但先验未知）函数，它只接受特定的解决方案集。在新的提示下进行测试时，这会产生奖励函数的认知不确定性，即我们事先不知道该任务（提示问题）的完整接受或拒绝的解决方案集。

在接下来的第 7 章，作者提出了一种基于搜索的高级推理理论，以及一些早期的实证研究结果。作者建议遵循现代后训练的整体结构，包括指令微调和强化学习训练。感兴趣的读者，可以查看原论文了解更多内容。

总结

本文引入了 Meta-CoT 框架，用于理解和增强大型语言模型（LLMs）的推理能力。作者认为传统的思维链并不能完全代表推理问题背后的数据生成过程。通过融入搜索、验证和迭代优化的概念，Meta-CoT 为高级问题解决所需的认知过程提供了一个更完整的模型。

Meta-CoT 是实现大型语言模型更强大、更具泛化性推理能力的一种有前景的途径。当前最先进模型的表现，以及在上下文探索和回溯方面的实验，都支持了内部搜索过程对于复杂任务表现至关重要的假设。此外，本文提出的训练流程为开发具有增强 Meta-CoT 能力的大型语言模型提供了一种具体的方法。

#不停PUA大模型「写更好点」

无需其它花哨技术就能让AI代码水平暴增

AI 的编程能力已经得到了证明，但还并不完美。近日，BuzzFeed 的资深数据科学家 Max Woolf 发现，如果通过提示词不断要求模型写更好的代码（write better code），AI 模型还真能写出更好的代码！

这篇文章在网络上引发了热议，著名 AI 科学家在看完这篇文章中更是发出了 matters 三连：迭代很重要，提示词设计很重要，代码执行能力很重要。他表示：「一些更简单的算法优化从未被考虑，同时一些过度的优化技术却又被过早引入了。」

Woolf 写了一篇深度博客介绍自己的发现，并分析了这种现象的原因。文中相关实验的代码也已发布在 GitHub。

相关代码库：https://github.com/minimaxir/llm-write-better-code/tree/main

如果不断要求 LLM 写更好的代码

它能写更好吗？

2023 年 11 月，OpenAI 为 ChatGPT 添加了使用 DALL-E 3 生成图像的功能。之后一段时间，出现了一类短暂的 meme：用户为 LLM 提供一张基础图像，并不断要求模型「使其更 X」，其中 X 可以指代任何东西。

让一张普通照片更 bro，这是操作三次的结果，来自 Reddit /u/Jojop0tato

让 Santa Claus 越来越 serious，来自 Reddit /u/hessihan

不过这个潮流很快就熄火了，因为这些图像都非常相似且无趣，即不管使用什么起始图像和提示词，所有样本都会最终收敛成某种宇宙感十足的东西。尽管这个流行昙花一现，但学术界的兴趣要持久得多，他们想知道：为什么这样一个没多大意义且含义模糊的提示词能对最终图像产生显而易见的影响？

如果对代码也采用类似的技术，会发生什么呢？

如果通过迭代提示要求 LLM 「让这些代码更好」确实能让代码质量提升，那么有望极大地提升生产力。如果情况果然如此，那要是迭代次数过多又会怎样呢？最终的代码也会出现某种「宇宙感」吗？只有试过才知道。

常规方式使用 LLM 写代码

尽管早在 ChatGPT 诞生前，就已经有研究者在围绕 LLM 研发工具了，但我一直以来都不喜欢使用 GitHub Copilot 等 LLM 代码助手来辅助编程。你的想法会在「LLM 自动完成了我的代码，真棒」、「应该怎样向 LLM 提问」以及「LLM 生成的代码究竟对不对，还是幻觉产生的正确代码」等之间来回切换，让人难以集中精神专注工作，以至于使用 AI 带来的生产力提升至多只能算是中性的。这里还没有涉及使用 LLM 的高昂成本。

Claude 3.5 Sonnet 的出现改变了我的想法。或许是 Anthropic 在训练中使用了什么秘方，Claude 3.5 Sonnet 的最新版本（claude-3-5-sonnet-20241022）具有出色的指令遵从能力，尤其是对于编程提示词。编程基准已经证实，当 Claude 3.5 Sonnet 与 GPT-4o 比较时，Claude 更胜一筹；而且我在多种不同的技术和创意任务上都有类似的体验。

初始请求

为了此实验，我们将向 Claude 3.5 Sonnet 提供一个面试风格的编程提示词（使用 Python）：问题既很简单 —— 新手软件工程师也能实现，但也可被显著优化。这个简单提示词可以代表软件工程师使用 LLM 的典型方式。此外，另一个要求是这个测试提示词应该足够新颖，绝不能从 LeetCode 或 HackerRank 等代码测试库中取用，因为 LLM 在训练时可能就已经看过这些问题了，完全可以根据记忆引用这些答案。

你可以在这个 GitHub 项目查看完整的、未经编辑的对话：https://github.com/minimaxir/llm-write-better-code/blob/main/python_30_casual_use.md

因此，这是我自己动手写的测试提示词：

中文版：

编写 Python 代码来解决这个问题：

给定一个包含 100 万个随机整数的列表，这些整数的取值范围是 1 到 100,000，找出各位数总和为 30 的最小数和最大数之间的差值。

将此作为用户提示词提供给 Claude API 并设置温度值为 0（可获得最好 / 最确定的答案），可得到如下结果：

这个实现是正确的且与大多数 Python 新手程序员编写的差不多，并且还多了个附加功能，可处理没有符合条件的有效数字的情况。对于列表中的每个数，检查各位数总和是否为 30：如果是，则检查它是否大于最近看到的最大数或小于最近看到的最小数，并相应地更新这些变量。搜索完列表后，返回差值。

我敢肯定，很多程序员看到这个实现都会摇头，想要对其进行优化。digit_sum () 函数就是个例子：虽然该实现是一个有趣的 Python 式单行代码，但 str 和 int 之间的类型转换会导致很多不必要的开销。

在我的 M3 Pro Macbook Pro 上，运行此代码平均需要 657 毫秒。我们将使用此性能作为基准来比较未来的实现版本。（剧透：它们都更快）

第 1 次迭代

现在，来让 Claude 改进这段代码，做法是将当前答案以及之前的内容都放入对话提示词中，并增加一个迭代提示词：

write better code

是的，不开玩笑，真就这三个单词。

Claude 现在会输出修改后的代码，并且还表示这是「使用了几项改进的优化版代码」。Claude 并没有将所有代码都重新放置到函数中，而是决定将其重构为 Python 类并使其更加面向对象：

其中，该代码实现了 2 项聪明的算法改进：

1. 执行各位数之和时，它使用了整数运算，并且避开了之前提到的类型转换。
2. 预先计算所有可能的各位数之和，并将它们存储在一个字节数组中（有点不寻常，而不是列表）以便后面查找，这意味着当那 100 万个数中有重复时，无需进行重复计算。由于这个数组是作为字段存储在类中，因此在搜索新的随机数列表时不需要重新计算。

这些优化将代码的运行速度提升了 2.7 倍。

第 2 次迭代

再来一次 write better code，Claude 发现了更显而易见的优化方法（为方便阅读有所裁剪）：

Claude 现在又添加了两个优化，终于意识到这个编程问题是一个令人尴尬的并行问题：

• 通过 Python 的 parallel-futures 包进行多线程处理，将大列表分成可独立处理的块。
• 对 numpy 运算进行向量化处理，这比基础 Python 运算快得多。这里特别要提到 _precompute_digit_sums () 函数，它是求和计算的向量化实现。条件 while digits.any (): 是 galaxy-brain 代码，但它可以正确地工作。

但是，这种特定的并行化实现存在一个问题：它会生成子进程，这会导致许多麻烦问题，包括无法直接内联运行它，并且必须使用 main () guard 来调用它，这大大限制了它的实用性。但即使作为单独的脚本运行，它也 print 了一个错误：无法 pickle 'generator' 对象错误，原因是使用了来自 numbers [mask] 的输出（所述生成器完全没有必要，返回 numbers [mask] 就足够了）。代码还混合了 numpy 数组 dtype，而这也会导致错误：将它们全部设置为 np.int32 可以修复它。

经过修复之后，这些代码的速度是基础实现的 5.1 倍。

第 3 次迭代

再来一次 write better code，Claude 又返回一个实现。它声称「使用了高级技术和现代 Python 特性的更复杂和优化的版本」，但实际代码没有表现出明显的算法改进，实际上通过恢复到 type-casting 方法在数字求和计算中使用了回归。整体来说，代码库变得更臃肿了，例如新增了一个用于计算差值的类：

这一次，无需任何修复就能运行该代码。不过，相比前一次实现，这一次迭代版本的性能略有下降，速度是基础实现的 4.1 倍。

第 4 次迭代

这种迭代提示方法的收益似乎开始下降了。但我们依然继续 write better code，Claude 表示新实现使用了「前沿优化技术和企业级功能」。什么？企业级功能？！

最终的代码量过于庞大，难以放入这篇文章，但它确实创造了两项优化：它现在使用可以调用 JIT 编译器的 numba Python 库，该编译器可直接针对 CPU 优化代码。在这种情况下，它只需一个 decorator 就可以非常快速地预先进行数字求和：

这个完整类还使用了 Python 的 asyncio 进行并行化，这比子进程方法更适合调度任务。它还可以更好地与现有的内联代码和 REPL（如 Jupyter Notebooks）配合使用。

它还添加了以下所谓「企业级」功能：

• 使用 Prometheus 进行结构化的指标日志记录。
• 一个信号处理程序，这样如果强制终止，就可以优雅地被解除该代码。
• 使用一个颜色丰富的表格展示基准测试结果。

不过确实挺漂亮！

看起来，对 AI 生成的代码而言，实现宇宙感就是做成「企业级」，也即对代码进行过度的工程开发。似乎说得通。尽管如此，该代码无需任何修改就能运行。async 和 numba 都是 Python 中实现并行的方法，因此它们可能冗余了并导致过度开销。然而，基准测试表明，该算法非常快，每次运行大约需要 6 毫秒，也就是能实现 100 倍加速。之前我还猜想这种提示方法会收益递减，但显然这种猜想并不合理。也许 numba 就是秘诀所在？

总体而言，这种迭代优化代码的迭代提示法并不完美：代码确实更好，但事后看来，「better」这个要求过于宽泛了。我只想要算法改进，而不是完整的 SaaS。让我们从头开始再试一次，但这次会使用更多方向。

对 LLM 进行提示词工程，以获得还要更好的代码

现在是 2025 年，为了让 LLM 得出最佳结果，仍然需要使用提示词工程。实际上，提示词工程的重要性还在提升：下一 token 预测模型的训练目标是基于大批量输入最大化下一 token 的预测概率，也因此它们是针对一般性的输入和输出进行了优化。随着 LLM 的大幅改进，生成的输出会变得更加平均化，因为这就是它们所接受的训练：所有 LLM 都偏向平均水平。不过，仅需少量指导，明确说明你想要 LLM 做什么，再给出几个示例，LLM 的输出就能提升。由于 Claude 3.5 Sonnet 能很好地遵从指令，因此即使只是一点点提示词工程也能带来很大的好处。

下面重做上面的代码优化实验。这一次使用更加积极主动的提示词工程，明确我们想要的结果，不给出任何模糊空间。是的，冷酷机械地对待 LLM 可以让它们表现更好。

初始请求

这次我们将使用系统提示词，仅通过 API 提供。系统提示词列出了 LLM 必须遵从的「规则」。因为我想要更优化的代码，我们将在规则中定义这一点，并提供详细示例：

中文版如下：

你编写的所有代码都必须完全优化。

「完全优化」包括：

- 最大化内存和运行时间的算法 big-0 效率

- 在适当的情况下使用并行化和向量化

- 遵循代码语言的正确样式约定（例如，最大化代码复用 (DRY)）

- 除了解决用户问题绝对必要的代码之外，没有额外的代码（即没有技术债）

如果代码未完全优化，你将被罚款 100 美元。

关于最后一行：在系统提示词中向 LLM 提供正面 / 负面激励已不再常用，我自己的研究表明，尚不清楚它是否能否产生积极影响，但罚款在迭代提示中将变得更加有用。

初始用户提示词还有一行附加内容：

中文版：

编写 Python 代码来解决这个问题：

给定一个包含 100 万个随机整数的列表，这些整数的取值范围是 1 到 100,000，找出各位数总和为 30 的最小数和最大数之间的差值。

在编写代码之前，规划出所有必要的优化。

「规划」是一个很常用的技巧，可以帮助 LLM 在第一次通过时对齐输出 —— 算是「let’s think step by step」的现代版本。某些 LLM 会忽视它，但 Claude 3.5 Sonnet 总是会服从。

基于此提示词工程策略的未经编辑的完整对话线程可见这里：https://github.com/minimaxir/llm-write-better-code/blob/main/python_30_prompt_engineering.md

将系统提示词和此用户提示词发送给 Claude，会得到如下开头的响应：

看起来很有希望：Claude 立即发现它应该从 numpy 和 numba 开始，并使用整数运算来求和。初始实现：

这比之前的初始实现更加精简，尤其是没有不必要的注释。但仍有改进空间，特别是此实现未在 jit decorator 中设置 parallel=True。

如此简单的提示词工程就得到了平均运行时长仅 11.2 毫秒的代码，这比原始实现快 59 倍。厉害！

第 1 次迭代

现在使用比「write code better」更详细的提示来迭代代码：

中文版：

你的代码未完全优化，你已被罚款 100 美元。使其更加优化。

不，这不是煤气灯效应，这叫激励式对齐（incentive alignment）。

Claude 的响应如下：

很好，它找到了 parallel=True！但是那个求和实现很奇怪，并且使用了位移位（bit-shifting），这通常仅用于超优化（hyperoptimization）。我认为应该不能很好地对十进制数使用位移位，而且经过测试证明确实不能，因为这个实现得到的和是错误的。该实现还再次包括多处理分块方法（未展示出来），这可能对 numba 来说更加冗余并会导致额外的开销。同样未展示出来的是：该脚本还使用一个小的测试数组预编译 JIT 函数以获得更好的实际性能，这是 numba 文档推荐用于基准测试的。

尽管如此，与最初的提示词工程实现代码相比，这个代码的性能大大退步，现在仅比原始实现快 9.1 倍。可能的原因是多处理会产生新的进程，而这些进程每次都会重新编译 numba JIT 函数，因此会产生巨大的开销。

第 2 次迭代

再次迭代上述提示词：

Claude 现在开始使用 SIMD 操作和块大小调整来实现（理论上）极致性能。

此时，我很困惑，它错过了位移位实现的某些东西，因为它仍然是错误的，特别是现在十六进制数也参与进来了。事实证明，该实现是一种计算十六进制数而非十进制数的和的优化方法，因此它完全是一种幻觉。还有另一个非常微妙的幻觉：当 parallel=True 时，prange 函数无法接受 32 的步长，这是一个几乎没有文档记录的细微差别。设置 parallel=False 并进行基准测试，与最初的提示词工程实现相比，确实略有改进，比基本实现快 65 倍。

第 3 次迭代

又一次迭代：

在这种情况下，LLM 放弃了一直导致问题的分块策略，并增加了两个优化：全局 HASH_TABLE（这只是一个 numpy 数组，我不确定简单的索引查找是否算作哈希表）；另外它引入了一个逻辑微优化，即在求和后，如果数字超过 30，则可以停止计数，因为它可以立即被认定为无效。

一个主要问题：由于互联网文档很少，导致「在模块加载时生成哈希表」技巧实际上不起作用：numba 的经过 JIT 处理后的函数之外的对象是只读的，但 HASH_TABLE 仍在经过 JIT 处理后的函数之外实例化并在经过 JIT 处理后的函数内进行修改，因此会导致非常令人困惑的错误。经过微小的重构，使得 HASH_TABLE 在经过 JIT 处理后的函数内实例化，代码就可以工作，并且运行速度极快：比原始基本实现快 100 倍，与基础提示方法的最终性能相同，但代码量少了几个数量级。

第 4 次迭代

这时候，Claude 实际上已经在抱怨了，表示该代码已经达到了「该问题可能的理论最小时间复杂度」。所以我把问题混在一起，让其解决这个求和问题，而它仅仅是使用之前用过的整数实现来替换相关代码，并没有尝试修复 HASH_TABLE。更重要的是，通过 HASH_TABLE 调整，我终于确认了该实现是正确的，不过由于不再进行位移，其性能略有下降：现在速度提升是 95 倍。

为了实现更好 LLM 代码生成

还要哪些步骤

综合起来，我们用一张图将这些提升直观地展示出来吧，其中尤其强调了需要人来修改代码逻辑，以便消除 bug 让代码可运行的案例。

总之，要求 LLM 「write code better」确实能让代码变得更好，这取决于你对更好的定义。使用一般的迭代式提示方法，代码确实会在基础示例的基础上获得提升，不管是新增功能还是提升速度。而如果使用提示词工程，代码的提升会更加快速和稳定，但更可能引入一些微妙的 bug，因为 LLM 本就不是为了生成高性能代码创造的。当然，你在使用 LLM 可能会有不一样的历程，但最终你都需要人力介入，解决一些不可避免的问题。

本文中的所有代码（包括基准测试脚本和数据可视化代码，全都已经在 GitHub 发布：https://github.com/minimaxir/llm-write-better-code/

另一方面，我很惊讶 Claude 3.5 Sonnet 在两次实验中都没有发现和实施一些优化。也就是说，它没有探索统计角度：由于我们从 1 到 10 万的范围内均匀生成 100 万个数字，因此将有大量重复的数字永远不需要分析。LLM 没有尝试进行重复数据删除，例如将数字列表转换为 Python set () 或使用 numpy 的 unique ()。我还期待一个实现，它涉及按升序对 100 万个数字的列表进行排序：这样，算法就可以从头到尾搜索列表以查找最小值（或从尾到头搜索最大值），而无需检查每个数字，尽管排序很慢，而向量化方法确实更实用。

即使 LLM 可能会出错，我从这些实验中学到的一件值得注意的事情是：即使代码输出不能直接使用，它们确实有有趣的想法和工具建议。例如，我从未接触过 numba，因为作为一名数据科学家 / 机器学习工程师，如果我需要更好的代码性能，我习惯于专门使用 numpy 的技巧。但现在我很难不接受 numba JIT 函数的结果，我可能会将它添加到我的工具箱中。当在其他技术领域（如网站后端和前端）测试类似的「使其更好」提示迭代工作流程时，LLM 也有很好的想法。

当然，这些 LLM 不会很快取代软件工程师，因为人们需要强大的工程背景才能识别出哪些才是真正的好主意，以及存在其他特定领域的约束。即使互联网上有大量的代码，LLM 也无法在没有指导的情况下辨别出普通代码和性能良好的高性能代码。现实世界的系统显然比求职面试式的编程问题要复杂得多，但如果快速的 for 循环反复要求 Claude 实现一个功能，提供可以将代码速度提高 100 倍的能力，那么新出现的管道就物有所值。

有些人认为过早优化是一种糟糕的编码习惯，但在现实世界中，这比拥有一个随着时间的推移会成为技术债务的低于标准的实现要好。

不过必须要说的是，我的实验使用 Python 对代码改进进行基准测试，而 Python 并不是开发者在追求优化性能时考虑的编码语言。虽然 numpy 和 numba 等库利用 C 来解决 Python 的性能限制，但流行的 Python 库（如 polars 和 pydantic）使用的一种现代方法是使用 Rust 进行编码。与 C 相比，Rust 具有许多性能优势，而 PyO3 包允许在 Python 中使用 Rust 代码，并且开销最小。

我可以确认，尽管该工作流程非常新，但 Claude 3.5 Sonnet 已经可以生成符合 PyO3 的 Python 和 Rust 代码，不过这部分的内容足以写另一篇博客文章了。

与此同时，虽然要求 LLM 改进代码是 AI 更务实的用途，但你可以要求他们「再加把劲」…… 结果好坏参半。

对于以上使用 LLM 的操作，我专门使用了 API 或这些 API 的接口（例如 Claude 的 Anthropic Console 中的 Workbench）作为免费 LLM 的 Web 接口。相比之下普通的 ChatGPT/Claude 网络应用使用管道，由于其固有的复杂性，会产生不可预测的结果。请注意这点。

你觉得这篇文章介绍的迭代式提示代码优化方法具有实际应用价值吗？请与我们分享你的看法。

参考链接：

​​https://x.com/minimaxir/status/1874875826401132775​​

​​https://minimaxir.com/2025/01/write-better-code/​​​

#VITA-1.5

迈向GPT-4o级实时视频-语音交互

近年来，多模态大语言模型（MLLMs）主要聚焦在视觉和文本模态的融合上，对语音的关注较少。然而，语音在多模态对话系统中扮演着至关重要的角色。由于视觉和语音模态之间的差异，同时在视觉和语音任务上取得高性能表现仍然是一个显著的挑战。

• 论文标题：VITA-1.5: Towards GPT-4o Level Real-Time Vision and Speech Interaction
• 论文链接：https://arxiv.org/pdf/2501.01957
• 代码链接（Star数破千）：https://github.com/VITA-MLLM/VITA
• 视频 Demo Video：

​，时长02:12

VITA-1.5 的核心动机在于：

1. 增加语音模态：在视觉-语言多模态模型的基础上，增加语音输入和输出能力，使其能够高效处理视觉、文本和语音任务。
2. 快速端到端交互：避免使用独立的自动语音识别（ASR）和语音合成（TTS）模块与 LLM 级联的方案，显著提升交互时端到端响应速度。

VITA-1.5 的主要贡献如下：

1. 多阶段训练方法：提出了一种精心设计的多阶段训练策略，逐步训练大语言模型 LLM 理解视觉和语音信息。这种策略使得模型在保留强大的视觉-语言能力的基础上，进一步获得了高效的语音对话能力。
2. 端到端 Speech-to-Speech：采用端到端语音输入和语音输出方式，大幅提升了视觉-语音的性能表现。
3. 实时交互能力：VITA-1.5 能够实现接近实时的视觉-语音交互，是目前开源领域最快的视觉-语音交互模型。
4. 开源与社区支持：VITA-1.5 的训练和推理代码已开源，并在社区中获得了广泛关注（已取得 1.6K GitHub Star）。VITA-1.5 致力于推动多模态交互系统的发展，向 GPT-4o 水平的实时交互迈出了重要一步。

01模型架构

VITA-1.5 的整体架构包括输入侧的视觉编码器和音频编码器，以及输出侧的端到端语音生成模块。与上一版的 VITA-1.0 不同，VITA-1.5 不再级联外部独立的 TTS 模块，而是实现了端到端的语音生成能力。模型采用“多模态编码器-适配器-LLM” 的配置，旨在通过联合训练提升视觉、语言和语音的统一理解能力。

1.1 视觉模态

视觉编码器

VITA-1.5 使用 InternViT-300M 作为视觉编码器，输入图像大小为 448×448 像素，每张图像生成 256 个视觉 token。对于高分辨率图像，采用动态分块策略以捕获局部细节，从而提升图像理解的精度。

视频处理

视频被视为多帧图像的特殊输入：

• 视频长度小于 4 秒时，均匀采样 4 帧；
• 长度在 4 至 16 秒之间时，每秒采样 1 帧；
• 长度超过 16 秒时，均匀采样 16 帧。视频帧不使用动态分块，以避免生成过多视觉 token，影响处理效率。

视觉适配器

通过一个两层 MLP 将视觉特征映射为适合 LLM 理解的视觉 token。

1.2 音频模态

语音编码器

音频编码器由多个降采样卷积层（4 倍降采样）和 24 层 Transformer 块组成，隐藏层维度为 1024。降采样层降低了音频特征的帧率，从而提高了处理速度。编码器参数量约为 350M，输出帧率为 12.5Hz。音频输入采用 Mel-filter bank features。

语音适配器

由多个 2 倍降采样的卷积层组成，用于进一步处理音频特征。

语音解码器

语音解码模块采用 TiCodec 作为 Codec 模型，使用一个大小为 1024 的单一码本。这种设计简化了推理阶段的解码过程。编解码器负责将连续的语音信号编码为离散语音 token，并能解码回 24,000Hz 的语音信号。

为了让 LLM 能够输出语音 token，VITA-1.5 在文本 token 的基础上增加了两个语音解码器：

1. 非自回归（NAR）语音解码器：对文本token进行整体处理，建模语义特征，用于生成初始的语音 token 分布。
2. 自回归（AR）语音解码器：基于 NAR 解码器生成的语音信息，逐步生成高质量的语音 token。

最终生成的语音 token 序列通过 Codec 模型解码为连续的语音信号流。

02训练数据

VITA-1.5 的多模态指令微调数据涵盖了多种类别，包括图像描述、问答数据，以及中英文数据。在不同训练阶段，选择性地使用数据子集以实现不同目标。主要数据类别如下：

1. 图像描述数据：包括 ShareGPT4V、ALLaVA-Caption、SharedGPT4o-Image 和合成数据，用于训练模型生成图像的描述性语言。
2. 图像问答数据：包括 LLaVA-150K、LLaVA-Mixture-sample、LVIS-Instruct、ScienceQA、ChatQA，以及从LLaVA-OV 中采样的子集（如一般图像问答和数学推理数据），用于训练模型回答基于图像的问题，并执行视觉推理任务。
3. OCR 与图表数据：包括 Anyword-3M、ICDAR2019-LSVT、UReader、SynDOG、ICDAR2019-LSVT-QA，以及从 LLaVA-OV 中采样的相关数据，用于支持模型理解 OCR 和图表内容。
4. 视频数据：包括 ShareGemini 和合成数据，用于训练模型处理视频输入，并执行视频描述和基于视频的问答任务。
5. 纯文本数据：增强模型的语言理解和生成能力，支持文本问答任务。

此外，还引入了以下语音数据：

• 11 万小时的内部语音-转录配对 ASR 数据（覆盖中英文），用于训练音频编码器并将其与 LLM 对齐。
• 3000 小时由 TTS 系统生成的文本-语音配对数据，用于训练语音解码器。

03三阶段训练策略

为了确保 VITA-1.5 在视觉、语言和语音任务中表现出色，需要解决不同模态之间的训练冲突。例如，添加语音数据可能会对视觉内容的理解产生负面影响，因为语音特征与视觉特征差异显著，会在学习过程中造成干扰。

为了解决这个问题，设计了一个三阶段的训练策略。核心思想是逐步将不同模态引入模型，使其在增强新模态能力的同时，保持现有模态的能力。

3.1 阶段1：视觉-语言训练

阶段1.1 视觉对齐

目标是弥合视觉和语言之间的差距。视觉特征通过预训练的视觉编码器 InternViT-300M 提取，语言通过 LLM 引入。使用 20% 的描述性 Caption 数据进行训练，仅训练视觉适配器，其他模块冻结。这种方法使得 LLM 初步对齐视觉模态。

阶段1.2 视觉理解

目标是教会 LLM 转录视觉内容。使用全部描述性 Caption 数据，训练过程中视觉模块的编码器和适配器以及 LLM 都是可训练的。重点是通过学习关于视觉的描述性文本，使模型能够通过生成对应的自然语言描述。

阶段1.3 视觉指令微调

在阶段 1.2 之后，模型已获得对图像和视频的基本理解，但指令跟随能力仍有限，难以应对视觉问答任务。在这一阶段使用所有问答数据，同时保留 20% 的描述性 Caption 数据，以增加数据集的多样性和任务的复杂性。训练期间，视觉模块的编码器和适配器以及 LLM 都是可训练的，目标是使模型不仅能够理解视觉内容，还能够根据指令回答问题。

3.2 阶段2：音频输入微调

阶段2.1 音频对齐

完成阶段 1 的训练后，模型在图像和视频理解方面已打下坚实基础。本阶段目标是在阶段 1 的基础上减少语音和语言之间的差异，使 LLM 能够理解音频输入。训练数据包括 11,000 小时的语音-转录对。采用两步法：

• （a）语音编码器训练：使用 CTC 损失函数训练语音编码器，目标是让编码器从语音输入中预测转录文本。确保音频编码器能够提取语音特征并将其映射到文本表示空间。
• （b）语音适配器训练：训练语音编码器后，将其与 LLM 集成，使用音频适配器将音频特征引入 LLM 的输入层。本阶段的训练目标是使 LLM 输出语音数据的转录文本。此外，在步骤（b）中引入特殊的可训练输入 token，以引导语音理解过程，这些 token 提供额外的上下文信息，引导 LLM 执行 ASR 任务。

阶段2.2 音频指令微调

本阶段重点是引入语音问题和文本答案的问答功能。为此，从数据集中抽取 4% 的 Caption 数据和 20% 的问答数据。数据处理方面，大约一半的基于文本的问题被随机替换为其对应的语音版本，由外部的 TTS 系统生成。本阶段视觉编码器和适配器、音频编码器和适配器以及 LLM 均是可训练的，旨在提高模型对多模态输入的适应性。

此外，在 LLM 的输出中添加一个分类头，用于区分输入是来自语音还是文本，从而使模型能够更高效灵活地处理不同模态。

3.3 阶段3：音频输出微调

在前两个训练阶段，VITA-1.5 模型已经获得了多模态理解能力。然而，作为一个交互助手，语音输出是必不可少的功能。为了在不影响模型基本能力的情况下引入语音输出功能，采用了 3,000 小时的文本-语音数据，并使用两步训练方法：

阶段3.1 Codec 模型训练

目标是使用语音数据训练一个单一码本的 Codec 模型。Codec 的编码器能够将语音映射为离散 token，其解码器可以将离散 token 映射回语音信号。在 VITA-1.5 的推理阶段，仅使用 Codec 的解码器。

阶段3.2 NAR+AR 语音解码器训练

这一步使用文本-语音配对数据进行训练。其中，文本输入到 LLM 的 tokenizer 和 Embedding 层以获取其 Embedding 向量，而语音输入到 Codec 的编码器以获取其语音 token。文本 Embedding 被送入非自回归语音解码器（NAR）以获得全局语义特征，然后这些特征被送入自回归语音解码器（AR），以预测相应的语音 token。LLM 在此阶段是完全冻结的，因此此前的多模态性能不受影响。

04实验发现

4.1 视觉-语言评估

▲ 图像理解能力评测

▲ 视频理解能力评测

上表展示了 VITA-1.5 在图像理解性能上的对比。经过三阶段训练后，VITA-1.5 的表现可与最先进的开源图像-语言模型媲美，显示了 VITA-1.5 在图像-语言任务中的强大能力。在视频理解评估中，VITA-1.5 的表现与顶尖开源模型相当。但与私有模型仍有较大差距，这表明 VITA-1.5 在视频理解方面仍有较大的改进空间和潜力。

VITA-1.5 的一个亮点在于，在第二阶段（音频输入微调）和第三阶段（音频输出微调）训练后，VITA-1.5 几乎保留了其在第一阶段（视觉-语言训练）中的视觉-语言能力，尽量避免了因为引入语音信息导致多模态能力下降。

4.2 语音识别能力评估

基准模型

使用了以下三个基准模型进行比较：Wav2vec2-base、Mini-Omini2、Freeze-Omini 和 VITA-1.0。

评估基准

中文评估集包括三个数据集：aishell-1、test net 和 test meeting。这些数据集用于评估模型在中文语音上的表现，评估指标是字符错误率（CER）。英文评估集包括四个数据集：dev-clean、dev-other、test-clean 和 test-other，用于评估模型在英语语音上的表现，评估指标是词错误率（WER）。

ASR性能

评估结果表明，VITA-1.5 在中文和英文 ASR 任务中均达到了领先的准确性。这表明 VITA-1.5 成功整合了先进的语音能力，用以支持多模态交互。

05未来工作

VITA-1.5 通过精心设计的三阶段训练策略整合视觉和语音。通过缓解模态之间的固有冲突，VITA-1.5 在视觉和语音理解方面实现了强大的能力，能够在不依赖于独立的 ASR 和 TTS 模块的情况下实现高效的 Speech-to-Speech 能力。不过其实验和文章内容也指出了一些可能的未来改进工作：

增强语音生成质量：虽然 VITA-1.5 已实现内置语音生成能力，但进一步提升生成语音的自然度和清晰度，尤其是带情绪的输出，仍是一个重要的研究方向。

多模态数据扩展：引入更多样化的多模态数据集，尤其是涵盖更多场景和语言的语音数据，将有助于进一步提升模型的泛化能力和适应性。

实时性和效率优化：在保持高性能的同时，进一步优化模型的计算效率和实时响应能力，以便在资源受限的环境中也能有效运行。

#Sky-T1

450美元训练一个「o1-preview」？UC伯克利开源32B推理模型Sky-T1，AI社区沸腾了

450 美元的价格，乍一听起来不算「小数目」。但如果，这是一个 32B 推理模型的全部训练成本呢？

是的，当时间来到 2025 年，推理模型正变得越来越容易开发，且成本迅速降低到我们此前无法想象的程度。

近日，加州大学伯克利分校天空计算实验室的研究团队 NovaSky 发布了 Sky-T1-32B-Preview。有趣的是，团队表示：「Sky-T1-32B-Preview 的训练成本不到 450 美元，这表明可以经济、高效地复制高级推理能力。」

• 项目主页：https://novasky-ai.github.io/posts/sky-t1/
• 开源地址：https://huggingface.co/NovaSky-AI/Sky-T1-32B-Preview

据官方信息，这款推理模型在多个关键基准测试中与 OpenAI o1 的早期版本相媲美。

重点是，Sky-T1 似乎是第一个真正开源的推理模型，因为团队发布了训练数据集以及必要的训练代码，任何人都可以从头开始复制。

大家惊呼：「数据、代码和模型权重，多么惊人的贡献。」

不久前，训练一个具有同等性能的模型的价格往往高达数百万美元。合成训练数据或由其他模型生成的训练数据，让成本实现了大幅降低。

此前，一家 AI 公司 Writer 发布的 Palmyra X 004 几乎完全基于合成数据进行训练，开发成本仅为 70 万美元。

想象一下，以后我们可以在 Nvidia Project Digits AI 超级计算机上运行此程序，该超级计算机售价 3000 美元（对于超级计算机来说很便宜），可以运行多达 2000 亿个参数的模型。而不久的将来，不到 1 万亿个参数的模型将由个人在本地运行。

2025 年的大模型技术演进正在加速，这感受确实很强烈。

模型概述

擅长推理的 o1 和 Gemini 2.0 flash thinking 等模型通过产生长长的内部思维链，解决了复杂的任务，并取得了其他方面的进步。然而，技术细节和模型权重却无法获取，这对学术界和开源社区的参与构成了障碍。

为此，在数学领域出现了一些训练开放权重推理模型的显著成果，如 Still-2 和 Journey。与此同时，加州大学伯克利分校的 NovaSky 团队一直在探索各种技术，以发展基础模型和指令调整模型的推理能力。

在 Sky-T1-32B-Preview 这项工作中，团队不仅在数学方面取得了有竞争力的推理性能，而且在同一模型的编码方面也取得了有竞争力的推理性能。

为确保这项工作能「惠及更广泛的社区」，团队开源了所有细节（如数据、代码、模型权重），使社区能够轻松复制和改进：

•  基础设施：在单一存储库中构建数据、训练和评估模型；
•  数据：用于训练 Sky-T1-32B-Preview 的 17K 数据；
•  技术细节：技术报告及 wandb 日志；
•  模型权重：32B 模型权重。

技术细节

数据整理过程

为了生成训练数据，团队使用了 QwQ-32B-Preview，这是一个开源模型，其推理能力与 o1-preview 相当。团队对数据混合进行了整理，以涵盖需要推理的不同领域，并采用拒绝采样程序来提高数据质量。

然后，团队受到 Still-2 的启发，用 GPT-4o-mini 将 QwQ trace 重写为结构规整的版本，以提高数据质量并简化解析。

他们发现，解析的简便性对推理模型尤其有利。它们被训练成以特定格式做出响应，而结果往往难以解析。例如，在 APPs 数据集上，如果不重新格式化，团队只能假设代码是写在最后一个代码块中的，而 QwQ 只能达到约 25% 的准确率。但是，有时代码可能写在中间，经过重新格式化后，准确率会提高到 90% 以上。

拒绝采样。根据数据集提供的解决方案，如果 QwQ 样本不正确，团队就会将其丢弃。对于数学问题，团队会与 ground truth 解决方案进行精确匹配。对于编码问题，团队执行数据集中提供的单元测试。团队的最终数据包含来自 APPs 和 TACO 的 5k 编码数据，以及来自 AIME、MATH 和 NuminaMATH 数据集的 Olympiads 子集的 10k 数学数据。此外，团队还保留了来自 STILL-2 的 1k 科学和谜题数据。

训练

团队使用训练数据来微调 Qwen2.5-32B-Instruct，这是一个不具备推理能力的开源模型。该模型采用 3 个 epoch、学习率 1e-5 和 96 的批大小进行训练。使用 DeepSpeed Zero-3 offload（根据 Lambda Cloud 的定价约为 450 美元），在 8 个 H100 上用 19 个小时完成模型训练。团队使用了 Llama-Factory 进行训练。

评估结果

Sky-T1 在 MATH500（「竞赛级」数学挑战）上的表现优于 o1 的早期预览版本，还在一组来自 LiveCodeBench（一种编码评估）的难题上击败了 o1 的预览版本。然而，Sky-T1 不如 GPQA-Diamond 上的 o1 预览版，后者包含博士毕业生应该了解的物理、生物和化学相关问题。

不过，OpenAI 的 o1 GA 版本比 o1 的预览版更强大，并且 OpenAI 预计将在未来几周发布性能更佳的推理模型 o3。

值得重视的新发现

模型大小很重要。团队最初尝试在较小的模型（7B 和 14B）上进行训练，但观察到的改进不大。例如，在 APPs 数据集上训练 Qwen2.5-14B-Coder-Instruct 在 LiveCodeBench 上的性能略有提高，从 42.6% 提高到 46.3%。然而，在手动检查较小模型（小于 32B 的模型）的输出时，团队发现它们经常生成重复内容，从而限制了它们的有效性。

数据混合很重要。团队最初使用 Numina 数据集（由 STILL-2 提供）中的 3-4K 个数学问题训练 32B 模型，AIME24 的准确率从 16.7% 显著提高到 43.3%。然而，将 APPs 数据集生成的编程数据纳入训练过程时，AIME24 的准确率下降到 36.7%。可能意味着，这种下降是由于数学和编程任务所需的推理方法不同。

编程推理通常涉及额外的逻辑步骤，如模拟测试输入或内部执行生成的代码，而数学问题的推理往往更为直接和结构化。为了解决这些差异，团队使用 NuminaMath 数据集中具有挑战性的数学问题和 TACO 数据集中复杂的编程任务来丰富训练数据。这种均衡的数据混合使模型在两个领域都表现出色，在 AIME24 上恢复了 43.3% 的准确率，同时也提高了其编程能力。

与此同时，也有研究者表示了怀疑：

对此大家怎么看？欢迎在评论区讨论。

参考链接：https://www.reddit.com/r/LocalLLaMA/comments/1hys13h/new_model_from_httpsnovaskyaigithubio/

#OpenAI被曝重组机器人团队

4年前缺钱缺数据，如今要做硬件布局了

目标是开发「通用」、「自适应」和「多功能」的机器人。

前几天的 CES 大会，黄仁勋在演讲中又双叒叕提到，机器人领域的「ChatGPT 时刻」即将到来，准备迎接机器人的腾飞吧！

没错，OpenAI 也是这么想的。

如果说大语言模型定义了当前的 AI 浪潮，那么下一波浪潮的主角将是机器人。AI 将从纯粹的语言理解，进化到对物理世界的深度认知。

据外媒 Tech Crunch 报道，OpenAI 正在重组其机器人团队。

这一消息来自 OpenAI 硬件部门的总监的社交媒体动态和最新发布的招聘信息。

去年 11 月，从 Meta 的 AR 眼镜部门跳槽到 OpenAI 来负责硬件部门的 Caitlin Kalinowski 在 X 平台透露，OpenAI 将开发配备定制传感器的机器人。

此次招聘的共有三个岗位，分别是：电子感知工程师、机器人机械设计工程师、技术项目经理（TPM）。

电子感知工程师：负责设计设计和开发机器人传感器系统，年薪 36-44 万美元。

机器人机械设计工程师：负责设计机器人的核心机械系统，年薪 36-44 万美元。

技术项目经理：负责统筹产品开发全流程，建立和管理机器人训练实验室，协调各技术团队，确保设计阶段顺利推进，年薪 34-44 万美元。

OpenAI 的目标是开发「通用」、「自适应」和「多功能」的机器人，能在真实世界中展现接近人类的智能。为此，硬件团队将自主开发传感器和计算组件，并由自研的 AI 模型驱动。

据 The Information 报道，OpenAI 已在探索人形机器人的研发，更已着眼未来量产的可能，正在招募具有「百万级量产机械系统经验」的工程师。

机器人领域正受到资本市场的热捧，去年获得了超 64 亿美元风投，多家公司在工业和服务领域已找到商业落地场景。特别是人形机器人领域，OpenAI 投资的 X1 和 Figure 等公司都在积极推进技术突破和量产计划。

实际上，OpenAI 重返机器人领域早有苗头。

过去两年中，OpenAI 就在机器人领域「广撒网」，其内部创业基金投资了几家人形机器人公司。例如，2023 年 3 月，OpenAI 投资了来自挪威的人形机器人公司 1X Technologies（融资 1.25 亿美元）。

2024 年 2 月 29 日，OpenAI 成功「牵手」Figure，并助其融资 7.45 亿美元。在当时 Figure 融资新闻发布会上，OpenAI 就暗示了可能重启机器人项目。

OpenAI 和 Figure 宣布合作 13 天后，就推出了 Figure 01 机器人，凭借一段 2 分 35 秒的视频刷爆全网，视频中的 Figure 01 展现出了惊人的理解、判断、行动和自我评价的能力。

3 月 12 日，一家名为 Physical Intelligence 的公司在旧金山成立，目标是「为机器人构建大脑」，在公司官网的致谢中，赫然写着 OpenAI 的名字。

不过，既然 OpenAI 已经以投资等方式与其他机器人公司进行了深度合作，却仍然选择重组自己的机器人部门，自主研发机器人。这个选择不免有些耐人寻味。

2024 年 7 月，Figure 01 在宝马汽车工厂「实习」。

在去年六月《福布斯》杂志的采访中，有知情人士透露，OpenAI 不打算与这些公司竞争，而是共存，让各家机器人制造商能够整合 OpenAI 的系统。

现如今，不知 OpenAI 在机器人领域的战略是否已经悄然转向？

虽然 Kalinowski 称，这是 OpenAI 首次发布机器人硬件相关职位，但这并非 OpenAI 首次涉足机器人领域。

2021 年 7 月，OpenAI 曾一度解散机器人团队转向其他方向。如今重启机器人项目，加上与传奇的前苹果产品设计师 Jony Ive 合作开发新设备、自研 AI 芯片等动作，都显示出 OpenAI 正在加速布局硬件领域。

缺钱缺数据的「弃子」

机器人研发是 OpenAI 创立之初的重要使命之一。OpenAI 的联合创始人 Wojciech Zaremba 当时带领一支团队，专注于研发「通用机器人」。

Wojciech Zaremba

2017 年 5 月，OpenAI 推出了开源软件 Roboschool，用于在模拟环境中操控机器人。

这一年，OpenAI 还宣布成功开发出一套系统，可以从模拟训练直接迁移到实体机器人，只需一次学习就能掌握新任务。

到 2018 年，他们的机械手已经很灵活了，玩起小木块来得心应手。

2019 年更是取得了大突破，这个能单手解魔方的机械臂引发了科技界热议。

经过堪比 13000 年经验的训练，这台五指机械手能以 20-60% 的成功率还原魔方。即便在戴手套、把手指捆绑起来等限制条件下，它依然能正常操作。别说捆着手指了，就是单手解魔方也不是一般人能做到的了。

OpenAI 的机器人团队取得了不错的进展，但 2020 年 10 月，OpenAI 以缺乏足够的训练数据为由，悄然解散了机器人团队。

随后，机器人团队成员被分配到其他项目：Zaremba 负责 GPT 模型开发，Welinder 主管产品和合作关系，Bob McGrew 担任研究副总裁，Lilian Weng 则成为安全系统负责人，并加入新成立的安全委员会。

更多详情，可以参见之前的报道：《OpenAI 雄心勃勃的机器人计划失败了：强化学习没法用？》

「事实证明，只要我们能获取数据，就能取得巨大进展。我们所有的无监督机器学习和强化学习系统都运行得非常好。而在机器人领域，数据的缺乏最终限制了我们的发展。」

在 2021 年的一次访谈中，Zaremba 承认解散团队对他来说是个艰难决定，但从公司角度看，这或许是最优选择。

OpenAI 发布的声明称：「鉴于 AI 技术和能力的迅猛发展，我们发现其他途径（如基于人类反馈的强化学习）能让研究进展更快。」

Zaremba 在访谈中还表示，OpenAI 的联合创始人们，包括 Greg Brockman、前首席科学家 Ilya Sutskever、Elon Musk、Reid Hoffman 和 Sam Altman 都是 Scaling Law 的拥趸。他们相信，巨大的计算能力是通向 AGI 的必经之路，而强大的计算机结合强化学习、预训练等技术可以实现突破性的 AI 进展。

当时 OpenAI 的 DALL-E 和 GPT-3 进一步佐证了这一点，更不用提后来的 ChatGPT 已经彻底改变了我们的生活方式。

DALL-E 的一张牛油果椅子，震撼了 2021 年初的 AI 圈

此外，没摆在这个决定明面上的，还有一个不那么体面的理由。

研究机器人很烧钱，这是一个公开的秘密。机器人行业没少经历「寒潮」：工业机器人公司 Rethink Robotics 未能成功寻找收购方后，几个月便关闭了门店。被认为是最先进的机器人公司的 Boston Dynamics 成为了「烫手山芋」，先后被谷歌收购，然后卖给软银，最后现代同意以 11 亿美元收购控股权。连本田也暂停了耕耘十余年的 Asimo 机器人项目......

2019 年，陷入财务困境的 OpenAI 获得了微软 10 亿美元的投资。随后，OpenAI 也推出了不少更有变现希望的项目：比如由 Microsoft Azure 支持的 GPT-3 API；授权 GPT-3 与微软的低代码平台 Power Apps 深度整合，让用户能用自然语言编程等等。

在这样的背景下，解散机器人团队，从商业角度看，或许确实是明智之选。

然而，OpenAI 的机器人梦从未褪色，比如 Sam Altman 曾说：「我们对此很感兴趣，也有过挣扎，希望有朝一日，我们能重拾机器人的研究。」

现在，OpenAI 融资不断、声名显赫、人才济济，可能是时候重温机器人梦想了。

参考链接：

​​https://techcrunch.com/2025/01/10/new-openai-job-listings-reveal-its-robotics-plans/​​

​​https://venturebeat.com/business/openai-disbands-its-robotics-research-team/​​​​​​​​​​