51c大模型~合集109

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

#线性扩散模型LiT来了

用极简线性注意力助力扩散模型AIPC时代端侧部署

王家豪，香港大学计算机系二年级博士，导师为罗平教授，研究方向为神经网络轻量化。硕士毕业于清华大学自动化系，已在 NeurIPS、CVPR 等顶级会议上发表了数篇论文。 

太长不看版：香港大学联合上海人工智能实验室，华为诺亚方舟实验室提出高效扩散模型 LiT：探索了扩散模型中极简线性注意力的架构设计和训练策略。LiT-0.6B 可以在断网状态，离线部署在 Windows 笔记本电脑上，遵循用户指令快速生成 1K 分辨率逼真图片。

图 1：LiT 在 Windows 笔记本电脑的离线端侧部署：LiT 可以在端侧，断网状态，以完全离线的方式遵循用户指令，快速生成 1K 分辨率图片

• 论文名称：LiT: Delving into a Simplified Linear Diffusion Transformer for Image Generation
• 论文地址：https://arxiv.org/pdf/2501.12976v1
• 项目主页：https://techmonsterwang.github.io/LiT/

为了提高扩散模型的计算效率，一些工作使用 Sub-quadratic 计算复杂度的模块来替代二次计算复杂度的自注意力（Self-attention）机制。这其中，线性注意力的主要特点是：1) 简洁；2) 并行化程度高。这对于大型语言模型、扩散模型这样的大尺寸、大计算的模型而言很重要。

就在几天前，MiniMax 团队著名的《MiniMax-01: Scaling Foundation Models with Lightning Attention》已经在大型语言模型中验证了线性模型的有效性。而在扩散模型中，关于「线性注意力要怎么样设计，如何训练好基于纯线性注意力的扩散模型」的讨论仍然不多。

本文针对这个问题，该团队提出了几条「拿来即用」的解决方案，向社区读者报告了可以如何设计和训练你的线性扩散 Transformer（linear diffusion Transformers）。列举如下：

1. 使用极简线性注意力机制足够扩散模型完成图像生成。除此之外，线性注意力还有一个「免费午餐」，即：使用更少的头（head），可以在增加理论 GMACs 的同时 (给模型更多计算)，不增加实际的 GPU 延迟。
2. 线性扩散 Transformer 强烈建议从一个预训练好的 Diffusion Transformer 里做权重继承。但是，继承权重的时候，不要继承自注意力中的任何权重 (Query, Key, Value, Output 的投影权重)。
3. 可以使用知识蒸馏（Knowledge Distillation）加速训练。但是，在设计 KD 策略时，我们强烈建议不但蒸馏噪声预测结果，同样也蒸馏方差预测结果 (这一项权重更小)。

LiT 将上述方案汇总成了 5 条指导原则，方便社区读者拿来即用。

在标准 ImageNet 基准上，LiT 只使用 DiT 20% 和 23% 的训练迭代数，即可实现相当 FID 结果。LiT 同样比肩基于 Mamba 和门控线性注意力的扩散模型。

在文生图任务中，LiT-0.6B 可以在断网状态，离线部署在 Windows 笔记本电脑上，遵循用户指令快速生成 1K 分辨率逼真图片，助力 AIPC 时代降临。 

目录

1 LiT 研究背景

2 线性注意力计算范式

3 线性扩散 Transformer 的架构设计

4 线性扩散 Transformer 的训练方法

5 图像生成实验验证

6 文生图实验验证

7 离线端侧部署

1 LiT 研究背景

Diffusion Transformer 正在助力文生图应用的商业化，展示出了极强的商业价值和潜力。但是，自注意力的二次计算复杂度也成为了 Diffusion Transformer 的一个老大难问题。因为这对于高分辨率的场景，或者端侧设备的部署都不算友好。

常见的 Sub-quadratic 计算复杂度的模块有 Mamba 的状态空间模型（SSM）、门控线性注意力（GLA）、线性注意力等等。目前也有相关的工作将其用在基于类别的（class-conditional）图像生成领域 (非文生图)，比如使用了 Mamba 的 DiM、使用了 GLA 的 DiG 。但是，虽然这些工作确实实现了 Sub-quadratic 的计算复杂度，但是，这些做法也存在明显的不足：

• 其一，SSM 和 GLA 模块都依赖递归的状态 (State) 变量，需要序列化迭代计算，对于并行化并不友好。
• 其二，SSM 和 GLA 模块的计算图相对于 线性注意力 而言更加复杂，而且会引入一些算数强度 (arithmetic-intensity) 比较低的操作，比如逐元素乘法。

而线性注意力相比前两者，如下图 2 所示，不但设计简单，而且很容易实现并行化。这样的特点使得线性注意力对于高分辨率极其友好。比如对于 2048px 分辨率图片，线性注意力比自注意力快约 9 倍，对于 DiT-S/2 生成所需要的 GPU 内存也可以从约 14GB 降低到 4GB。因此，训练出一个性能优异的基于线性注意力的扩散模型很有价值。

图 2：与 SSM 和 GLA 相比，线性注意力同样实现 sub-quadratic 的计算复杂度，同时设计极其简洁，且不依赖递归的状态变量

但是，对于有挑战性的图像生成任务，怎么快速，有效地训练好基于线性注意力的扩散模型呢？

这个问题很重要，因为一方面，尽管线性注意力在视觉识别领域已经被探索很多，可以取代自注意力，但是在图像生成中仍然是一个探索不足的问题。另一方面，从头开始训练扩散模型成本高昂。比如训练 RAPHAEL 需要 60K A100 GPU days ( 中报告)。因此，针对线性扩散 Transformer 的高性价比训练策略仍然值得探索。

LiT 从架构设计和训练策略中系统地研究了纯线性注意力的扩散 Transformer 实现。LiT 是一种使用纯线性注意力的 Diffusion Transformer。LiT 训练时的成本效率很高，同时在推理过程中保持高分辨率友好属性，并且可以在 Windows 11 笔记本电脑上离线部署。在基于类别的 ImageNet 256×256 基准上面，100K 训练步数的 LiT-S/B/L 在 FID 方面优于 400K 训练步数的 DiT-S/B/L。对于 ImageNet 256×256 和 512×512，LiT-XL/2 在训练步骤只有 20% 和 23% 的条件下，实现了与 DiT-XL/2 相当的 FID。在文生图任务中，LiT-0.6B 可以在断网状态，离线部署在 Windows 笔记本电脑上，遵循用户指令快速生成 1K 分辨率逼真图片。

2 线性注意力计算范式

3 线性扩散 Transformer 的架构设计

鉴于对生成任务上的线性扩散 Transformer 的探索不多，LiT 先以 DiT 为基础，构建了一个使用线性注意力的基线模型。基线模型与 DiT 共享相同的宏观架构，唯一的区别是将自注意力替换为 线性注意力。所有实验均在基于类别的 ImageNet 256×256 基准上进行，使用 256 的 Batch Size 训练了 400K 迭代次数。

Guideline 1：Simplified 线性注意力对于基于 DiT 的图像生成扩散模型完全足够。

我们首先尝试了在通用视觉基础模型中成功验证的常见线性注意力的架构设计，比如 ReLU 线性注意力 (使用 ReLU 激活函数作为线性注意力的 Kernel Function)。

对于性能参考，将其与 DiT 进行比较，其中任何性能差异都可以归因于线性注意力对生成质量的影响。如图 4 中所示。与 DiT 相比，使用 ReLU 线性注意力的 LiT-S/2 和 B/2 性能下降很大。结果表明，视觉识别中常用的线性注意力在噪声预测任务中有改进的空间。

然后我们探索以下方法：

• 简化型线性注意力 (图 3，相当于在 ReLU 线性注意力的基础上加上 Depth-wise 卷积)。
• Focused 线性注意力。
• Focused 线性注意力 (使用 GELU 替换 ReLU)。

这些选择中的每一个都保持了线性复杂度，保持了 LiT 在计算效率方面的优势。我们使用相对较大的卷积核 (Kernel Size 5) 来确保在预测噪声时足够大的感受野。

图 3：在 Simplified 线性注意力中使用更少的 heads

图 4：不同架构的线性注意力消融研究

实验结果如图 4 所示。加了 DWC 的模块都可以取得大幅的性能提升，我们认为这是因为模型在预测给定像素的噪声时关注相邻像素信息。同时，我们发现 Focused Function 的有效性有限，我们将其归因于其设计动机，以帮助线性注意聚焦于特定区域。此功能可能适合分类模型，但可能不是噪声预测所必需的。为了简单起见，最后使用简化 线性注意力。

Guideline 2：在线性注意力中建议使用很少的头，可以在增加计算的同时不增加时延。

多头自注意力和线性注意力的计算量分别为：

直觉上似乎使用更多头可以减少计算压力。但相反，我们建议使用更少的头，因为我们观察到线性注意力存在 Free Lunch 效应，如图 5 所示。图 5 展示了使用线性注意力的 Small，Base，Large，XLarge 模型使用不同头数量的延迟和 GMACs 变化。

图 5：线性注意力中的 Free Lunch 效应：不同头数量线性注意的延迟与理论 GMACs 比较

我们使用 NVIDIA A100 GPU 生成 256×256 分辨率的图像，批量大小为 8 (NVIDIA V100 GPU 出现类似现象)。结果表明，减小头数量会导致理论 GMACs 稳定增加，实际延迟却并没有呈现出增加的趋势，甚至出现下降。我们将这种现象总结为线性注意力的「免费午餐（Free Lunch）」效应。

我们认为在线性注意力中使用更少的头之后，允许模型有较高的理论计算，根据 scaling law，允许模型在生成性能上达到更高的上限。

实验结果如图 6 所示，对于不同的模型尺度，线性注意力中使用更少的头数 (比如，2，3，4) 优于 DiT 中的默认设置。相反，使用过多的头（例如，S/2 的 96 或 B/2 的 192），则会严重阻碍生成质量。

4 线性扩散 Transformer 的训练方法

LiT 与 DiT 共享一些相同的结构，允许权重继承自预训练的 DiT 架构。这些权重包含丰富的与噪声预测相关的知识，有望以成本高效的方式转移到 LiT。因此，在这个部分我们探索把预训练的 DiT 权重 (FFN 模块、adaLN、位置编码和 Conditional Embedding 相关的参数) 继承给线性 DiT，除了线性注意力部分。

图 6：线性扩散 Transformer 的权重继承策略

Guideline 3：线性扩散 Transformer 的参数应该从一个预训练到收敛的 DiT 初始化。

我们首先预训练 DiT-S/2 不同的训练迭代次数：200K、300K、400K、600K 和 800K，并且在每个实验中，分别将这些预训练的权重加载到 LiT-S/2 中，同时线性注意力部分的参数保持随机。然后将初始化的 LiT-S/2 在 ImageNet 上训练 400K 迭代次数，结果如图 6 所示。

我们观察到一些有趣的发现：

1. DiT 的预训练权重，即使只训练了 200K 步，也起着重要作用，将 FID 从 63.24 提高到 57.84。
2. 使用预训练权重的指数移动平均 (EMA) 影响很小。
3. DiT 训练更收敛时 (800K 步)，更适合作为 LiT 的初始化，即使架构没有完全对齐。

我们认为这种现象的一种可能解释是 Diffusion Transformer 中不同模块的功能是解耦的。尽管 DiT 和 LiT 具有不同的架构，但它们的共享组件 (例如 FFN 和 adaLN) 的行为非常相似。因此，可以迁移这些组件预训练参数中的知识。同时，即使把 DiT 训练到收敛并迁移共享组件的权重，也不会阻碍线性注意力部分的优化。

图 7：ImageNet 256×256 上的权重继承消融实验结果

Guideline 4：线性注意力中的 Query、Key、Value 和 Output 投影矩阵参数应该随机初始化，不要继承自自注意力。

在 LiT 中，线性注意力中的一些权重与 DiT 的自注意力中的权重重叠，包括 Query、Key、Value 和 Output 投影矩阵。尽管计算范式存在差异，但这些权重可以直接从 DiT 加载到 LiT 中，而不需要从头训练。但是，这是否可以加速其收敛性仍然是一个悬而未决的问题。

我们使用经过 600K 次迭代预训练的 DiT-S/2 进行消融实验。探索了 5 种不同类型的加载策略，包括：

• 加载 Query，Key 和 Value 投影矩阵。
• 加载 Key 和 Value 投影矩阵。
• 加载 Value 投影矩阵。
• 加载 Query 投影矩阵。
• 加载 Output 投影矩阵。

结果如图 7 所示。与没有加载自注意力权重的基线相比，没有一个探索的策略显示出更好的生成性能。这种现象可归因于计算范式的差异。具体来说，线性注意力直接计算键和值矩阵的乘积，但是自注意力就不是这样的。因此，自注意力中的 Key 和 Value 相关的权重对线性注意力的好处有限。

我们建议继承除线性注意力之外的所有预训练参数从预训练好的 DiT 中，因为它易于实现并且非常适合基于 Transformer 架构的扩散模型。

图 8：混合知识蒸馏训练线性扩散 Transformer

Guideline 5：使用混合知识蒸馏训练线性扩散 Transformer 很关键，不仅蒸馏噪声预测结果，还蒸馏方差的预测结果。

知识蒸馏通常采用教师网络来帮助训练轻量级学生网络。对于扩散模型，蒸馏通常侧重于减少目标模型的采样步骤。相比之下，我们专注于在保持采样步骤的前提下，从复杂的模型蒸馏出更简单的模型。

图 9：ImageNet 256×256 上的知识蒸馏实验结果，带有下划线的结果表示不使用知识蒸馏

到目前为止，LiT 遵循 DiT 的宏观 / 微观设计，但采用了高效的线性注意力。使用我们的训练策略，LiT-S/2 显著地提高了 FID。接下来，我们在更大的变体 (例如 B/L/XL) 和具有挑战性的任务 (比如 T2I) 上验证它。

5 图像生成实验验证

ImageNet 256×256 基准

我们首先在 ImageNet 256×256 基准上验证 LiT。LiT-S/2、B/2、L/2、XL/2 配置与 DiT 一致，只是线性注意力的头分别设置为 2/3/4/4。对于所有模型变体，DWC Kernel Size 都设置为 5。我们以 256 的 Batch Size 训练 400K 步。对于 LiT-XL/2，将训练步数扩展到 1.4M 步 (只有 DiT-XL/2 7M 的 20%)。我们使用预训练的 DiT 初始化 LiT 的参数。Lambda_1 和 lambda_2 在混合知识蒸馏中设置为 0.5 和 0.05。

图 10 和 11 比较了 LiT 和 DiT 的不同尺寸模型的结果。值得注意的是，仅 100K 训练迭代次数训练的 LiT 已经在各种评估指标和不同尺寸的模型中优于 400K 训练迭代次数训练的 DiT。使用 400K 训练迭代次数的额外训练，模型的性能继续提高。尽管训练步骤只有 DiT-XL/2 的 20%，但 LiT-XL/2 仍然取得与 DiT 相当的 FID 结果 (2.32 对 2.27)。此外，LiT 与基于 U-Net 的基线性能相当。这些结果表明，当线性注意力结合合适的优化策略时，可以可靠地用于图像生成应用。

图 10：ImageNet 256×256 基准实验结果，与基于自注意力的 DiT 和基于门控线性注意力的 DiG 的比较

图 11：ImageNet 256×256 基准实验结果

ImageNet 512×512 基准

我们继续在 ImageNet 512×512 基准上进一步验证了 LiT-XL/2。使用预训练的 DiT-XL/2 作为教师模型，使用其权重初始化 LiT-XL/2。对于知识蒸馏，分别设置 Lambda_1 和 lambda_2 为 1.0 和 0.05，并且只训练 LiT-XL/2 700K 训练迭代次数 (是 DiT 3M 训练迭代次数的 23%)。

值得注意的是，与使用 256 的 Batch Size 的 DiT 不同，我们采用 128 的较小 Batch Size。这其实不占便宜，因为 128 的 Batch Size 相比 256 的情况，完成 1 Epoch 需要 2 倍的训练迭代次数。也就是说，我们 700K 的训练迭代次数其实只等效为 256 Batch Size 下的 350K。尽管如此，使用纯线性注意力的 LiT 实现了 3.69 的 FID，与 3M 步训练的 DiT 相当，将训练步骤减少了约 77%。此外，LiT 优于几个强大的 Baseline。这些结果证明了我们提出的成本高效的训练策略在高分辨率数据集上的有效性。实验结果如图 12 所示。

图 12：ImageNet 512×512 基准实验结果

6 文生图实验验证

文生图对于扩散模型的商业应用极为重要。LiT 遵循 PixArt-α 的做法，将交叉注意力添加到 LiT-XL/2 中使其支持文本嵌入。LiT 将线性注意力的头数设置为 2，DWC Kernel Size 设置为 5。遵循 PixArt-Σ 的做法，使用预训练的 SDXL VAE Encoder 和 T5 编码器 (即 Flan-T5-XXL) 分别提取图像和文本特征。

LiT 使用 PixArt-Σ 作为教师来监督其训练，分别设置 Lambda_1 和 lambda_2 为 1.0 和 0.05。LiT 从 PixArt-Σ 继承权重，除了自注意力的参数。随后在内部数据集上训练，学习率为 2e-5，仅训练 45400 步，明显低于 PixArt-α 的多阶段训练。图 13 为 LiT 生成的 512px 图像采样结果。尽管在每个 Block 中都使用了线性注意力，以及我们的成本高效的训练策略，LiT 仍然可以产生异常逼真的图像。

图 13：LiT 根据用户指令生成的 512px 图片

我们还将分辨率进一步增加到 1K。更多的实验细节请参阅原论文。图 14 是生成的结果采样。尽管用廉价的线性注意力替换所有自注意力，但 LiT 仍然能够以高分辨率生成逼真的图像。

图 14：LiT 根据用户指令生成的 1K 分辨率图片

7 离线端侧部署

我们还将 1K 分辨率的 LiT-XL/2 模型部署到一台 Windows 11 操作系统驱动的笔记本电脑上，以验证其 On-device 的能力。考虑到笔记本电脑的 GPU 内存的限制，我们将文本编码器量化为 8-bit，同时在线性注意力计算期间保持 fp16 精度。图 1 显示了我们的部署结果。预训练的 LiT 可以在离线设置 (没有网络连接) 的情况下快速生成照片逼真的 1K 分辨率图像。这些结果说明 LiT 作为一种 On-device 的扩散模型的成功实现，推进边缘设备上的高分辨率文生图任务。

下面提供了一个视频 Demo：

，时长02:05

展示了在断网状态下离线使用 LiT 完成 1K 分辨率文生图任务的过程。

#D-FINE

超越YOLOv10/11、RT-DETRv2/3！中科大D-FINE重新定义边界框回归任务

D-FINE 在 COCO 数据集上以 78 FPS 的速度取得了 59.3% 的平均精度 (AP)，远超 YOLOv10、YOLO11、RT-DETR v1/v2/v3 及 LW-DETR 等竞争对手，成为实时目标检测领域新的领跑者。目前，D-FINE 的所有代码、权重以及工具已开源，包含了详细的预训练教程和自定义数据集处理指南。

D-FINE 的作者均来自中国科学技术大学。第一作者为中科大在读博士生彭岩松 (https://scholar.google.com/citations?user=CTidez8AAAAJ&hl=zh-CN)，其研究方向为实时目标检测以及神经形态视觉，已在 AAAI、ICCV、CVPR 等国际顶级会议上以第一作者身份发表多篇论文。本文由吴枫教授、孙晓艳教授和张越一副研究员共同指导，其他作者包括中科大博士生李和倍及硕士生吴沛熹。

引言

在当前内卷严重的实时目标检测 (Real-time Object Detection) 领域，性能与效率始终是难以平衡的核心问题。绝大多数现有的 SOTA 方法仅依赖于更先进的模块替换或训练策略，导致性能逐渐趋于饱和。

为了打破这一瓶颈，来自中科大的研究团队提出了 D-FINE，重新定义了边界框回归任务。不同于传统的固定坐标预测，D-FINE 创新了两种方法：细粒度分布优化 (FDR) 和全局最优定位自蒸馏 (GO-LSD)。通过将回归任务转化为细粒度的分布优化任务，D-FINE 不仅显著简化了优化难度，还能够更精确地建模每条边界的不确定性。此外，D-FINE 将定位知识 (Localization Knowledge) 融入到模型输出，通过高效的自蒸馏策略在各层共享这些知识，因而在不增加额外训练成本的前提下，实现了性能的进一步显著提升。

论文标题: D-FINE: Redefine Regression Task of DETRs as Fine-grained Distribution Refinement

论文地址: https://arxiv.org/abs/2410.13842

项目地址: https://github.com/Peterande/D-FINE

凭借这些创新，D-FINE 在 COCO 数据集上以 78 FPS 的速度取得了 59.3% 的平均精度 (AP)，远超 YOLOv10、YOLO11、RT-DETR v1/v2/v3 及 LW-DETR 等竞争对手，成为实时目标检测领域新的领跑者。目前，D-FINE 的所有代码、权重以及工具已开源，包含了详细的预训练教程和自定义数据集处理指南。

研究团队分别使用 D-FINE 和 YOLO11 对 YouTube 上的一段复杂街景视频进行了目标检测。尽管存在逆光、虚化模糊和密集遮挡等不利因素，D-FINE-X 依然成功检测出几乎所有目标，包括背包、自行车和信号灯等难以察觉的小目标，其置信度、以及模糊边缘的定位准确度明显高于 YOLO11x。

细粒度分布优化 (FDR)

FDR (Fine-grained Distribution Refinement) 将检测框的生成过程分解为：

1. 初始框预测：与传统 DETR 方法类似，D-FINE 的解码器会在第一层将 Object Queries 转换为若干个初始边界框。这些边界框只用于初始化，不需要特别精确。

2. 细粒度的分布优化：与传统方法不同，D-FINE 的解码层不会直接预测新的边界框，而是基于初始边界框生成四组概率分布，并通过逐层优化对其进行调整。这些概率分布本质上是检测框的一种「细粒度中间表征」。D-FINE 可以通过微调这些表征，不同幅度地独立调整各边缘。

具体流程如图所示：

将边界框回归任务重新定义为 FDR 有以下优点：

1. 过程简化：在传统 L1 损失和 IoU 损失进行优化的基础上，模型还通过标签和预测结果之间的「残差」进一步约束这些中间态的概率分布。这使得每个解码层能够更有效地关注当前的定位误差。随着层数增加，优化的目标变得更加简单，从而简化了整体的优化过程。

2. 对复杂场景的鲁棒性更强：FDR 中概率的高低本质上反应了模型对边界微调的自信程度。这使得 D-FINE 能够在不同网络深度下对每条边的不确定性独立建模，从而使模型真正地理解定位的好坏。在遮挡、运动模糊和低光照等复杂的实际场景下，D-FINE 表现出了更强的鲁棒性，相比直接回归四个固定值的方法要更为稳健。

3. 灵活的优化机制：D-FINE 通过加权求和将概率分布转化为最终的边界框偏移值。指数型加权函数 W (n) 保证了能够在初始框准确时进行细微调整，在必要时提供大幅度修正。

4. 可扩展性：FDR 通过将回归任务定义为同分类任务一致的概率分布预测问题，这使得目标检测模型可以更好地受益于知识蒸馏、多任务学习和分布优化等更多领域的创新，从而更有效地适应和整合新的技术，突破传统方法的局限。

全局最优定位自蒸馏机制 GO-LSD

GO-LSD (Global Optimal Localization Self-Distillation) 可以将知识蒸馏无痛应用到 FDR 框架检测器。

基于 FDR 框架的目标检测器既可以实现知识传递，又可以保持一致的优化目标。

新任诺贝尔物理学奖得主 Geoffrey Hinton 在《Distilling the Knowledge in a Neural Network》一文中提到：概率即 「知识」。FDR 将概率分布变成了网络输出，并搭载了定位知识 (Localization Knowledge)。因此，仅计算 KL 散度损失就能将这些「知识」从深层传递到浅层。由于 FDR 架构中每一个解码层都共享一个共同目标，即减少初始边界框与真实边界框之间的残差。因此最后一层生成的精确概率分布可以作为前面每一层的最终目标，并通过蒸馏引导前几层。

由于 FDR 架构中每一个解码层都共享一个共同目标：减少初始边界框与真实边界框之间的残差；因此最后一层生成的精确概率分布可以作为前面每一层的最终目标，并通过蒸馏引导前几层。

研究团队在 FDR 的框架上进一步提出了全局最优定位自蒸馏 GO-LSD，在网络层间实现了定位知识蒸馏，进一步扩展了 D-FINE 的能力，具体流程如图：

FDR 与 GO-LSD 产生了一种双赢的「合力」：随着训练的进行，最后一层的预测将变得越来越准确，其生成的软标签也能够更好地帮助前几层提高预测准确性。反过来，前几层将更快地定位到准确位置。这相当于深层的优化任务得到了简化，从而进一步提高了整体准确性。

实验结果

在 COCO 数据集上，D-FINE-L 和 D-FINE-X 分别以 8.07 ms (124 FPS) 和 12.89 ms (78 FPS) 的时延取得了 54.0% 和 55.8% 的 AP，远超其余所有实时目标检测器，打败了 YOLOv10 (53.2%，54.4%)、YOLO11 (53.4%，54.7%) 及 RT-DETRv2 (53.4%，54.6%)。

在 Objects365 上进行了简单的有监督预训练后，D-FINE 的准确率达到了 59.3% AP。在 paperwithcode 网站的 Real-Time Object Detection on MS COCO benchmark 上，D-FINE 的速度和性能都远超其他方法，取得了 Top1 的成绩。

相比 baseline RT-DETR，D-FINE-L 和 D-FINE-X 大幅降低了参数量和计算复杂度。在推理速度显著提升的同时，分别取得了 1.8% 和 3.2% 的显著性能提升。

更轻量化的 D-FINE-S 和 D-FINE-M 在 T4 GPU 上分别以 3.49 ms (287 FPS) 和 5.62 ms (178 FPS) 的时延下取得了 48.5% 和 52.3% 的 AP，超过 YOLOv10 (46.3%，51.1%)、YOLO11 (46.6%，51.2%) 及 RT-DETRv2 (48.1%，49.9%)。预训练后，D-FINE-S 和 D-FINE-M 分别取得了 50.7% 和 55.1% 的 AP。

虽然 FDR 和 GO-LSD 能够显著提高性能，但不会直接让网络更快或更轻。为了解决这个问题，研究团队对 DETR 架构进行了轻量化处理。这些调整不可避免地让性能有所下降，但 D-FINE 方法最终实现了速度、参数、计算量与性能的平衡。下表展示了从 baseline 到 D-FINE 的逐步修改过程。每一步都含展示了模型在 AP 、参数量、时延以及 FLOPs 上的变化。

研究团队对一系列非实时的 DETR 检测模型应用了 FDR 和 GO-LSD。实验证明，在几乎没有额外参数量和算力的情况下，最高提升了 5.3% 的 AP，证明了方法的鲁棒性和泛化性。

根据消融实验，含有 FDR 的检测器和原始检测器在速度、参数量和计算复杂度上几乎没有区别，可以实现无缝替换。

研究团队分析了训练成本，发现额外的时间和显存消耗主要来自生成用于监督分布的 FGL Loss 标签。通过对 D-FINE 进行的进一步优化，这些额外的训练时间和显存占用被控制在 6% 和 2% 以内，对整体影响很小。

D-FINE 预测的可视化

以下是 D-FINE 在各种复杂检测场景中的预测结果。这些场景包括遮挡、低光照、运动模糊、景深效果和密集场景。可以看出，面对这些具有挑战性的场景，D-FINE 能够产生准确的定位结果。

下图展示了第一层和最后一层的预测结果、对应四条边的分布、以及加权后的分布。可以看出，预测框的定位会随着分布的优化而变得更加精准。

总结和局限

D-FINE 将边界框回归转化为逐层优化的概率分布预测，显著提升了模型在多任务场景中的兼容性。D-FINE 为目标检测模型的设计提供了一条新思路，后续可以考虑进一步挖掘 D-FINE 在跨任务学习和模型轻量化方面的潜力。

D-FINE 也有一些局限：相比于大模型， D-FINE 的轻量化版本对于性能提升不太明显。这可能是因为浅层解码器的预测精度不高，无法有效将定位信息传递给前几层。

未来的研究可以考虑在提高轻量化模型定位能力的同时，避免增加推理延迟。一种思路是继续改进架构设计，尝试在训练时引入额外的异构解码层，在推理时丢弃这些层，保持模型的轻量化。如果训练资源足够，还可以直接用大模型对小模型进行蒸馏，而不是依赖自蒸馏。

思考和展望

2024 年，实时目标检测领域经历了多次版本迭代，YOLO 系列先后推出了 YOLOv9、YOLOv10，以及 YOLO11。而 DETR 系列则在 RT-DETR 之后，陆续推出了 LW-DETR、RT-DETRv2 和 RT-DETRv3。

这两类模型的重要突破，实质上得益于相互借鉴和融合。RT-DETR 引入了 YOLO 的 RepNCSP 模块，以替代冗余的多尺度自注意力层，通过重新设计轻量化的混合编码器，实现了实时 DETR；而 YOLOv10 借鉴了 DETR 的匹配策略，通过训练额外的一对一检测头，对密集 anchor 预测进行自动筛选，避免了 NMS 后处理，显著提升了速度。此外，YOLOv10 和 YOLO11 也引入了自注意力机制，进一步增强了大尺度目标的检测性能。

尽管这些改进取得了显著的效果，但社区对未来的发展方向产生了疑问：在两类模型趋于一致的背景下，实时目标检测的下一步将如何发展？可以预见，在目标检测这一竞争激烈的领域，继续进行模块替换的收益将逐渐减少，可能很快遇到瓶颈。

而基于传统框架的训练策略改进，或许对一些旧的网络（如常用的 Deformable DETR）有效，但应用于最新的 SOTA 网络时，往往难以取得明显的提升，甚至可能产生负面影响。特别是对于计算资源有限的小型团队，即使是精妙的训练策略，若缺乏大规模的超参数搜索，也难以取得预期的效果。

D-FINE 的出现，为目标检测带来了全新的思路。通过引入 FDR 和 GO-LSD，D-FINE 重新定义了目标检测中的边界框回归任务。这种创新有望突破当前的瓶颈，为实时目标检测领域提供新的发展方向。

#视觉生成模型理解物理世界规律的通关密码

当下，视频生成备受关注，有望成为处理物理知识的 “世界模型” （World Model），助力自动驾驶、机器人等下游任务。然而，当前模型在从 “生成” 迈向世界建模的过程中，存在关键短板 —— 对真实世界物理规律的刻画能力不足。

为此，来自悉尼大学、西澳大学等研究机构的研究者，带来了一篇聚焦于生成式“物理 AI”的综述文章，深度剖析如何将物理规律融入视觉生成模型。

• 论文标题：Generative Physical AI in Vision: A Survey
• 论文链接：https://arxiv.org/abs/2501.10928

生成式“物理 AI”的核心概念

综述围绕生成式“物理 AI”，先明确了相关定义。物理模拟（Physical Simulation）是依据物理模型让输入数据随时间演变；物理理解（Physical Understanding）是从观测数据推断物理模型或参数；而生成（Generation）则是用生成模型创造新内容，其中不涉及对物理规律深入理解的为无物理感知的生成（Physics-Unaware Generation），反之则是物理感知生成（Physics-Aware Generation）。

物理感知生成可细分为两类。一类是基于显式物理模拟的（PAG-E），这类方法显式利用物理模拟模型提升生成模型的物理刻画能力；另一类是无显式物理模拟的（PAG-I）。在 PAG-E 中，根据 “物理模拟” 与 “生成模型” 的融合方式，可归纳为六大范式。

 有显式模拟的生成（PAG-E）：六大范式

范式一：生成后模拟（Gen-to-Sim）

这类方法通常在生成内容后，为其添加物理属性，使其可模拟和交互。比如 PIE-NeRF 在 神经辐射场中分布可模拟的 “粒子”，实现用户与场景的交互；PhysGaussian 利用材料点法（MPM）将 3D 高斯核视为可模拟的 “粒子”，模拟形变等物理现象；VR-GS、LIVE-GS 和 DreMa 等也基于此范式，实现 VR 3D 内容的交互或机器人对物体摆放场景的预测。

范式二：生成中模拟（Sim-in-Gen）

此范式将物理模拟直接集成到生成模型中，作为核心子模块。比如 PhysGen 基于牛顿定律下的刚体动力学，结合大模型推断的物理参数，实现用户外力控制下的视频生成；PhyCAGE 把 MPM 物理模拟器当作优化器，将损失函数的梯度视为物理模拟中的速度；PhysDiff 将物理约束加入扩散模型的采样过程中，生成合理的人体运动等。

范式三：生成与模拟并行（Gen-and-Sim）

该范式中，生成和模拟同时进行或具有紧密关联。比如 PAC-NeRF 利用混合 Eulerian-Lagrangian 表示，同时推断物体的几何和物理参数；iPAC-NeRF 在此基础上直接在 Lagrangian 空间中优化粒子位置和特征；PhysMotion 在图像到视频生成过程中，将生成过程与模拟过程交替进行等。

范式四：模拟约束生成（Sim-Constrained Gen）

这种范式下，物理模拟为生成模型提供训练约束或指导。比如 PhysComp 使用基于物理的损失函数，确保生成的 3D 模型在力作用下表现真实；Atlas3D 通过保证在物理模拟中的稳定性，生成可自支撑的 3D 模型；DiffuseBot 则将物理模拟作为数据过滤方式，筛选物理性能好的生成结果等；

范式五：生成约束模拟（Gen-Constrained Sim）

此范式中，生成模型为模拟过程提供指导或先验知识。比如 Physics3D 结合视频扩散模型和 MPM，利用分数蒸馏采样（Score Distillation Sampling）优化物理参数；DreamPhysics 进一步提出运动蒸馏采样（Motion Distillation Sampling）；PhysDreamer 从生成的视频数据中学习优化物理模拟的参数等。

范式六：模拟评估生成（Sim-Evaluated Gen）

这种范式下，生成的内容旨在用于基于模拟的部署，注重在模拟环境中的实用性。比如 PhysPart 生成可用与 3D 打印和机器人场景的 3D 替换部件；PhyScene 生成适合 Embodied AI 的高质量 3D 交互场景等。

无显式模拟的生成（PAG-I）

综述还介绍了无显式模拟的物理感知生成（PAG-I）的相关工作。一些视频生成大模型展现出一定的物理推理能力，能捕捉和复现部分物理动态和因果关系。

此外，PhyT2V 使用大语言模型为视觉生成提供物理知识，通过迭代优化文本提示词提升文生视频模型的物理真实性；Generative Interactive Dynamics 的相关研究聚焦于模拟图像或视频中物体受外力影响下的变化规律；Motion Prompting 等方法利用运动轨迹等控制视频生成和编辑；CoCoGen 等则通过在采样过程中注入物理信息，生成符合物理规律的特定领域数据等。

物理评估：衡量模型的物理 “实力”

综述同时分析了现有方法如何评估图像或视频生成模型的物理刻画能力。传统评估指标在检测物理规律的符合程度方面存在不足。

为此，研究者们提出了专门的数据集和指标。比如 PhyBench、PhyGenBench 和 VideoPhy 等 Benchmark，涵盖力学、光学、热学和材料等物理领域，通过构建相关场景和文本提示词来评估模型。

在评估指标方面，分为人工评估和自动评估，人工评估针对物理现象的不同维度进行打分，自动评估则包括利用视觉语言模型 LVMs 获取评估分数等。

未来展望：物理 AI 的无限可能

最后，综述展望了生成式“物理 AI”的未来方向，涵盖评估方式、可解释性、物理知识增强的大模型、神经 - 符号混合模型、生成式模拟引擎、跨学科应用等多种可能。让我们持续关注，共同见证 “物理 AI” 的发展。

如果想深入了解文中提及的研究成果，欢迎访问 https://github.com/BestJunYu/Awesome-Physics-aware-Generation 查看相关论文汇总。

#PolaFormer

极性感知线性注意力！哈工深张正团队提出PolaFormer视觉基础模型

本文一作孟维康是哈尔滨工业大学（深圳）与鹏城实验室联合培养的博士生，本科毕业于哈尔滨工业大学，主要研究方向是大规模基础模型的高效训练和推理算法研究。

通讯作者张正教授，哈尔滨工业大学（深圳）的长聘教授及博士生导师，教育部青年长江学者，广东特支计划青年珠江学者，深圳市优青。长期从事高效能多模态机器学习的研究，专注于高效与可信多模态大模型。

课题组：Big Media Intelligence (BMI) 欢迎校内外优秀学者的加入以及来访交流。

课题组主页：https://cszhengzhang.cn/BMI/

• 论文标题：PolaFormer: Polarity-aware Linear Attention for Vision Transformers
• 论文链接：https://arxiv.org/pdf/2501.15061
• GitHub 链接：https://github.com/ZacharyMeng/PolaFormer
• Huggingface 权重链接：https://huggingface.co/ZachMeng/PolaFormer/tree/main

尽管 Vision Transformer 及其变种在视觉任务上取得了亮眼的性能，但仍面临着自注意力机制时空间平方复杂度的挑战。为了解决这一问题，线性自注意力通过设计新的核函数替换标准自注意力机制中的 softmax 函数，使模型复杂度降低为线性。这篇论文中，研究者提出了一个新的「极性感知线性注意力」模块，使模型达到了更高的任务性能与计算效率。

具体来说，本工作从线性自注意力方法需要满足注意力权重矩阵的两个特性（即正值性和低信息熵）入手。首先，指出了现有的做法为了满足正值性，牺牲了 Q 矩阵和 K 矩阵元素中负值的缺陷，提出了极性感知的计算方式可以保证 Q 矩阵和 K 矩阵中所有元素可以平等地进行相似度的计算，使计算结果更准确，模型表示能力更强。其次，本文提出只要采用一族具有特殊性质的映射函数，就可以有效降低注意力权重分布的信息熵，并给出了数学上的证明。

大量的实验表明，本文提出的线性注意力模块可以直接替换现有 Vision Transformer 框架中的自注意力模块，并在视觉基础任务和 LRA 任务上一致地提升了性能。

引入

Transformer 模型已经在广泛的视觉任务中展现出亮眼的性能。其核心模块 —— 通过 softmax 归一化的点积自注意力机制，让 Transformer 模型可以有效地捕捉长距离依赖关系。然而，这带来了模型 O (N^2) 复杂度，在处理长序列视频或高分辨率图像时，会导致相当大的计算开销和显存占用。这限制了它们在资源受限环境中的效率，使得在这些场景下的实际部署变得困难。

线性注意力，作为一种更具可行性的解决方案使用核化特征映射替换 q,k 点积中的 Softmax 操作，有效地将时间和空间复杂度从 O (N²d) 降低到 O (Nd²)。尽管线性注意力在计算效率上有所提升，但在表达能力方面仍不及基于 Softmax 的注意力，我们的分析确定了造成这种不足的两个主要原因，它们都源于 Softmax 近似过程中的信息丢失：

1. 负值丢失。依赖非负特征映射（如 ReLU）的线性注意力模型无法保持与原始 q,k 点积的一致性。这些特征映射仅保留了正 - 正交互作用，而关键的正 - 负和负 - 负交互作用则完全丢失。这种选择性表示限制了模型捕获全面关系范围的能力，导致注意力图的表达能力减弱和判别力降低。
2. 注意力分布高信息熵。没有 softmax 的指数缩放，线性注意力会导致权重分布更加均匀且熵更低。这种均匀性削弱了模型区分强弱 q,k 对的能力，损害了其对重要特征的关注，并在需要精细细节的任务中降低了性能。

在这项工作中，作者提出了一种极性感知线性注意力（PolaFormer）机制，旨在通过纳入被忽略的负交互作用来解决先前线性注意力模型的局限性。与此同时，为了解决线性注意力中常见的注意力权重分布信息熵过高的问题，他们提供了数学理论基础，表明如果一个逐元素计算的函数具有正的一阶和二阶导数，则可以重新缩放 q,k 响应以降低熵。这些增强功能共同提供了一个更稳健的解决方案，以缩小线性化和基于 Softmax 的注意力之间的差距。

背景

标准自注意力机制的低效

考虑一个长度为 N、维度为 D 的序列

。该序列被分成 h 个头，每个头的维度是 d。在每个头中，不同位置的标记（token）共同被关注以捕获长距离依赖关系。输出可表示为

可见，自注意力的复杂度是 O (N2d)。这种复杂度使得自注意力机制在处理长序列时效率低下，导致计算成本急剧上升。目前，降低自注意力的复杂度的主要方法包括但不限于稀疏注意力、线性化注意力以及基于核的注意力等。

基于核的线性注意力

为了缓解标准自注意力机制的效率瓶颈，人们提出了基于核的线性注意力机制，该机制将相似度函数分解为特征映射的点积。按照 Linear Attention 工作里的符号，我们定义

作为 softmax 核函数。从数学上讲，线性注意力的目标是使用 ϕ(q_i)ϕ(k_j)^T 来近似 SM (⋅,⋅)，则注意力输出的第 t 行可以重写为：

通过利用矩阵乘法的结合律，每个头的复杂度可以降低到 O (Nd’2)，其中 d’是特征映射后的维度，与序列长度成线性关系。

方法概览

极性感知注意力

极性感知注意力背后的核心思想是为了解决现有线性注意力机制的局限性，这些机制通常会丢弃来自负成分的有价值信息。

PolaFormer 在处理负成分时，极性感知注意力将 query 和 key 向量分解为它们的正部和负部。这种分解允许机制分别考虑正相似度和负相似度对注意力权重的影响。具体来说，对于查询向量 q 和键向量 k，可以将它们分解为：

其中，

和

分别代表 q 的正部和负部，同理对于 k。

将这些分解代入 q 和 k 的内积中，可以得到：

前两项捕捉了同号成分之间的相似性，而后两项则代表了异号成分之间的相互作用。之前的线性注意力方法，如基于 ReLU 的特征映射，通过将负成分映射到零来消除它们，这在近似 q,k 点积时会导致显著的信息丢失。

为了解决这个问题，极性感知注意力机制根据 q,k 的极性将它们分开，并独立计算它们之间的相互作用。注意力权重的计算方式如下：

PolaFormer 根据极性明确地将 q,k 对分开，处理在内积计算过程中维度的同号和异号交互作用。这些交互作用在两个流中处理，从而能够更准确地重建原始的 softmax 注意力权重。为了避免不必要的复杂性，作者沿着通道维度拆分 v 向量，在不引入额外可学习参数的情况下处理这两种类型的交互作用。然后，将输出进行拼接，并通过一个可学习的符号感知矩阵进行缩放，以确保准确重建 q,k 关系。

作者统计分析了两个 G 矩阵的特性，存在一个明显的负相关和价值差异。这证明了本文提出的可学习混合策略补偿了松弛减法操作所带来的影响。

用于降低信息熵的可学习幂函数

为了解决线性注意力中常见的注意力权重分布信息熵过高的问题，作者提供了数学理论基础，表明如果一个逐元素计算的函数具有正的一阶和二阶导数，则可以重新缩放 q,k 响应以降低熵。

这一理论有助于阐明为什么先前的特征映射会提高信息熵，从而导致注意力分布过于平滑。为了简化，作者采用通道级可学习的幂函数进行重新缩放，这保留了 Softmax 中固有的指数函数的尖锐性。这使得模型能够捕获尖锐的注意力峰值，提高了其区分强弱响应的能力。与此同时，为了区分开不同通道之间的主次关系，作者设计了可学习的幂次来捕捉每个维度的不同重要性

最后，由于之前的理论工作已经表明，自注意力矩阵本质上是低秩的。这一特性在学习 v 向量时可能导致退化解，尤其是在本文的情况下，当需要紧凑的表示来容纳极性感知信息时。作者探索了各种技术来增加秩并进行了消融实验，比如 DWC 和 DCN。

实验结果

作者对模型在三个任务上进行了评估：图像分类、目标检测和实例分割，以及语义分割。作者将模型性能与之前的高效视觉模型进行了比较。此外，他们在 LRA 任务上评估了模型，便于与其他线性注意力模型进行对比。

首先，作者从头开始在图像分类任务上训练了模型。然后，他们在 ADE20K 数据集上对预训练模型进行微调，用于语义分割任务，还在 COCO 数据集上进行微调，用于目标检测任务。

结论

在本研究中，作者提出了 PolaFormer，这是一种具有线性复杂度的新型高效 Transformer，主要贡献如下：

1. 本文指出现有方法负值忽略的问题，提出了极性感值的映射函数，让每个元素都参与到注意力的计算；
2. 在理论上，作者提出并证明了存在一族逐元素函数能够降低熵，并采用了可学习的幂函数以实现简洁性和重新缩放。
3. 此外，作者还使用了卷积来缓解由自注意力矩阵的低秩特性引起的退化解问题，并引入了极性感知系数矩阵来学习同号值和异号值之间的互补关系。

#解读Scaling Law的一切，洞见LLM的未来

Scaling Law 撞墙了吗？这算得上是近段时间 AI 领域最热门的话题之一。近日，资深机器学习研究科学家 Cameron R. Wolfe 更新了一篇超长的博客文章，详细介绍了 LLM scaling 的当前状况，并分享了他对 AI 研究未来的看法。

• 原文链接：https://cameronrwolfe.substack.com/p/llm-scaling-laws

近些年来，AI 领域的大部分研究进展（尤其是 LLM）都是基于 scaling。也就是说，只要使用更多数据训练更大模型，就能得到更好的结果。这种关系可以被更严格地定义成 Scaling Law，这是一个可以描述 LLM 的测试损失随某个量（如训练计算量）的增长而降低的公式。Scaling Law 可帮助我们预测当投入更多资源进行更大规模训练时的效果，这能给我们提供继续投资 scaling 的必要信心。

「如果你有一个庞大的数据集并且训练了一个非常大的神经网络，那么成功是肯定的！」——Ilya Sutskever

过去多年时间里，Scaling Law 一直指引着 AI 研究前进的方向。事实上，像 OpenAI 这样的早期前沿实验室的成功甚至可以归功于他们对 Scaling Law 的虔诚信仰。然而，最近有报道称，顶级研究实验室正在努力训练下一代更好的 LLM。这些说法可能会让我们怀疑：scaling 之路会撞墙吗？如果会，还有其他前进的道路吗？

本文将从头开始回答这些问题，首先是深入解释 LLM Scaling Law 和相关研究。Scaling Law 的概念很简单，但公众对 Scaling Law 存在各种误解 —— 这项研究背后的科学实际上非常具体明确。利用对 Scaling Law 的详细理解，我们将讨论 LLM 研究的最新趋势以及导致 Scaling Law「停滞」的因素。最后，我们将利用这些信息更清楚地说明 AI 研究的未来，重点关注一些可能继续推动进步的关键思想 —— 其中也包括 scaling。

LLM 的基础 scaling 概念

为了理解 LLM 的 scaling 现状，我们首先需要对 Scaling Law 有一个总体的了解。我们将从头开始建立这种理解，首先是理解幂律的概念。然后，我们将探讨幂律在 LLM 中的应用研究，最终得出我们今天使用的 Scaling Law。

什么是幂律？

幂律是 LLM scaling 的基本概念。简而言之，幂律描述了两个量之间的关系。对于 LLM 来说，第一个量是 LLM 的测试损失（或其他一些相关的性能指标，例如下游任务准确率 [7]），另一个量是我们想要 scaling 的一些设置，例如模型参数量。例如，在研究 LLM 的 scaling 属性时，我们可能会看到类似以下的陈述。

「有了足够的训练数据，验证损失的 scaling 与模型大小的函数关系应该大致上是平滑幂律。」 - 摘自 [4]

这样的陈述告诉我们，模型的测试损失和模型参数量之间存在可测量的关系。其中一个量的变化将导致另一个量发生相对的、无关尺度的变化。换句话说，我们可基于这种关系了解到：增加模型参数量（假设已满足其他条件，比如训练数据充足）将导致测试损失降低某个可预测的程度。

幂律公式。基本的幂律可表示为以下公式：

这里研究的两个量是 x 和 y，而 a 和 p 是描述这些量之间关系的常数。如果我们绘出这个幂律函数，我们会得到如下所示的图。这里提供普通和对数度量的图，因为大多数研究 LLM scaling 的论文都使用对数度量。

x 和 y 之间的基本幂律图

但很多时候，展示 LLM scaling 的图看起来并不像上面的图，而通常是上下颠倒的；请参阅下面的示例。

这只是逆幂律，可用如下公式表示：

逆幂律与标准幂律的公式几乎相同，但我们通常会对 p 使用负指数。使幂律的指数为负数会使图颠倒过来；请参阅下面的示例。

x 和 y 之间的逆幂律图

当使用对数度量绘制此逆幂律时，会产生大多数 LLM Scaling Law 特有的标志性线性关系。本文中涵盖的几乎每篇论文都会通过这样的图来研究 Scaling Law 的各种不同的因素（例如规模、计算、数据等）对 LLM 的性能的影响。现在，让我们更实际地来看看幂律，也就是看看最早的一些在 LLM scaling 语境中研究幂律的论文。

神经语言模型的 Scaling Law

在语言模型的早期，我们还不了解规模对性能的影响。语言模型是一个很有前途的研究领域，但当时的模型（例如原始 GPT）功能有限。我们尚未发现更大模型的力量，而创建更好的语言模型的途径还不明确。模型的形状（即层的数量和大小）重要吗？使模型更大是否有助于其表现更好？训练这些更大的模型需要多少数据？

「损失随模型大小、数据集大小和用于训练的计算量呈幂律变化，有些趋势跨越了七个数量级以上。」 - 摘自 [1]

在 [1] 中，作者的目标是通过分析多个因素（例如模型大小、模型形状、数据集大小、训练计算和批大小）对模型性能的影响来回答这些问题。通过此分析，我们了解到 LLM 性能会随着以下因素的增加而平稳提升：

• 模型参数的数量。
• 数据集的大小。
• 用于训练的计算量。

更具体地说，当性能不受其他两个因素的瓶颈限制时，可以观察到这些因素中的每一个与 LLM 的测试损失之间存在幂律关系。

实验设置。为了拟合幂律，作者在 WebText2 语料库的子集上预训练了最大 1.5B 参数的 LLM。这些子集的 token 数量从 22M 到 23B 不等。所有模型都使用固定的 1024 个 token 的上下文长度和标准的下一个 token 预测（交叉熵）损失进行训练。在留存测试集上测量相同的损失并将其用作主要性能指标。此设置与大多数 LLM 的标准预训练设置相匹配。

（来自 [1]）

LLM scaling 的幂律。在 [1] 中训练的 LLM 的性能（就其在 WebText2 上的测试损失而言）会随着参数、数据和计算量的增加而稳步提高。这些趋势在计算量方面跨越了八个数量级，在模型大小方面跨越了六个数量级，在数据集大小方面跨越了两个数量级。上图提供了确切的幂律关系和拟合每个幂律关系的方程。这里的每个方程都与我们之前看到的逆幂律方程非常相似。但是，我们设置 a = 1 并在括号内添加一个额外的乘法常数。

[1] 的作者注意到一个小细节，并且这个细节对于正确拟合这些幂律是必要的。在计算模型参数的总数时，不包括位置或 token 嵌入，从而可以得到更清晰的 scaling 趋势；如下图所示。

（来自 [1]）

不过，只有当训练不受其他因素阻碍时，这些幂律才适用。因此，为了获得最佳性能，应该同时增大这三个分量（模型大小、数据和计算量）。如果我们单独增大其中任何一个分量，我们就会达到某个收益递减点。

幂律意味着什么？虽然 [1] 中提供的幂律图看起来很有希望，但我们应该注意到这些图是基于对数度量的。如果使用普通度量绘制，我们会得到下面的图 —— 可以看到幂律的形状类似于指数衰减。

考虑到网上关于 scaling 和 AGI 的大量言论，这样的发现似乎违反直觉。在许多情况下，我们被灌输的直觉似乎是：随着计算量的对数增加，LLM 的质量呈指数级提高，但事实并非如此。实际上，随着规模增大，提升 LLM 的质量会变得越来越困难。

其他有用的发现。除了 [1] 中观察到的幂律之外，我们还看到，研究中涉及的其他因素（例如模型形状或架构设置）对模型性能的影响微乎其微；见上文。规模是打造更好 LLM 的最大因素 —— 更多的数据、计算量和模型参数可以平稳地提高 LLM 的性能。

「较大的模型具有更高的样本效率，因此最佳的计算效率训练涉及在相对适量的数据上训练非常大的模型，并在收敛之前停止。」 - 来自 [1]

有趣的是，[1] 中的实证分析表明，较大的 LLM 往往具有更高的样本效率，这意味着它们在数据较少的情况下可达到与较小模型相同的测试损失水平。因此，对 LLM 进行预训练以使其收敛（可以说）不是最优的。相反，我们可以在较少的数据上训练更大的模型，在收敛之前停止训练过程。这种方法在训练计算使用量方面是最优的，但它没有考虑到推理成本。实际上，我们通常会在更多数据上训练较小的模型，因为较小的模型托管成本较低。

作者还广泛分析了模型大小与用于预训练的数据量之间的关系，发现数据集的大小不需要像模型大小那样快速增加。模型大小增加约 8 倍需要训练数据量增加约 5 倍才能避免过拟合。

（来自 [1]）

[1] 中发现的 Scaling Law 也在其他几个数据集上得到复现，我们发现在向测试损失添加固定偏移量后，相同的 Scaling Law 仍然成立（即考虑到数据集不同）；见上文。这些结果为 LLM scaling 提供了令人信服的案例。我们通过更长时间、在更多数据上训练较大的模型获得了非常明显和可衡量的收益，这激发了人们对更大规模预训练 LLM 的兴趣。

「这些结果表明，随着我们适当扩大模型大小、数据和计算，语言建模性能会平稳且可预测地提高。我们预计，更大的语言模型将比当前模型表现更好，样本效率更高。」 - 来自 [1]

Scaling Law 的实际用途

大规模预训练非常好，但这一事实却带来了一些困境。续为了得到最好的模型，需要大量数据进行大规模模型训练。然而，这些训练成本很高，这意味着它们也会带来很大的风险。如果我们花费了 1000 万美元，结果训练了一个不符合我们期望的模型，这可如何是好？考虑到预训练的费用，我们无法执行任何特定于模型的调整，我们必须确保我们训练的模型表现良好。我们需要制定一个策略来调整这些模型并预测它们的性能，同时无需花费太多钱。

（来自 [11]）

这就是 Scaling Law 的用武之地。到目前为止，我们已经看到了一些实证分析，这些分析是为了证明 Scaling Law 的存在而进行的，但这些 Scaling Law 在 AI 研究中也有非常实际的用例。特别是，我们可以：

1. 使用各种训练设置训练一堆较小的模型。
2. 根据较小模型的性能拟合 Scaling Law。
3. 使用 Scaling Law 推断更大模型的性能。

当然，这种方法有局限性。从较小的模型预测较大模型的性能很困难，而且可能不准确。模型可能因规模不同而表现不同。然而，研究社区已经提出了多种方法来使这更可行，Scaling Law 现在通常用于此目的。使用 Scaling Law 预测较大模型的性能的能力让我们作为研究人员更有信心（和安心）。此外，Scaling Law 提供了一种简单的方法来证明对 AI 研究的投资是合理的。

scaling 和预训练时代

「这就是我们今天看到的所有进步的驱动力 —— 在庞大的数据集上训练的超大型神经网络。」 - Ilya Sutskever

Scaling Law 的发现成为了 LLM 研究的大部分最新进展的催化剂。为了获得更好的结果，我们只是在更大（更好！）的数据集上训练越来越大的模型。基于这一策略，OpenAI 打造了 GPT 系列模型，此外 OpenAI 之外也有很多模型。在这里，我们将更深入地解读这一 scaling 研究的进展 —— 最近被 Ilya Sutskever 描述为「预训练时代」。

GPT 系列模型：GPT、GPT-2、GPT-3 和 GPT-4

LLM Scaling Law 最广为人知和最明显的应用是 OpenAI 打造的 GPT 系列模型。我们将主要关注该系列中早期的开放模型 —— 直到 GPT-3—— 因为：

1. 这些模型的细节更公开。
2. 除了 scaling 预训练过程外，后期的模型还极大受益于后训练研究。

我们还将介绍一些已知的 scaling 结果，如 GPT-4。

（来自 [2]）

最早的 GPT 模型 [2] 实际上非常小 — 总共 12 层和 117M 个参数。该模型首先在 BooksCorpus 上进行预训练，BooksCorpus 是一个包含约 7000 本书原始文本的数据集。然后，使用监督训练目标并为每个任务创建单独的分类头来微调模型以解决各种不同的下游任务；见上文。这篇论文是第一批对仅解码器 Transformer 进行大规模自监督预训练的论文之一，其中得到了一些有趣的发现：

• 对纯文本进行自监督预训练非常有效。
• 使用长而连续的文本跨度进行预训练非常重要。
• 以这种方式进行预训练后，可以对单个模型进行微调，使其能以最领先的准确度解决各种不同的任务。

总体而言，GPT 并不是一个特别值得关注的模型，但它奠定了一些重要的基础（即仅解码器 Transformer 和自监督预训练）。

（来自 [3]）

GPT-2 [3] 诞生在 GPT 之后不久，是多个模型的集合，其中最大的有 1.5B 参数；如上所示。这些模型与 GPT 模型具有相同的架构，并使用相同的自监督语言建模目标进行预训练。然而，与 GPT 相比，GPT-2 对预训练过程进行了两大改变：

• 预训练数据集改成了 WebText，它比 BooksCorpus 大得多，并且是通过从互联网上抓取数据创建的。
• 这些模型没有针对下游任务进行微调。相反，是通过使用预训练模型执行零样本推理来解决任务。

GPT-2 模型在大多数基准测试上都达不到最先进的性能，但它们的性能会随着模型的大小而不断提高 —— 扩大模型参数的数量会带来明显的好处；如下所示。

（来自 [3]）

[3] 的作者还透露，尽管 GPT-2 模型取得了很亮眼的结果，但似乎仍然没有拟合 WebText 语料库。基于这一发现可以推断，继续 scaling LLM 预训练（无论是模型还是数据大小）应该是有益的。尽管 GPT-2 模型并不是特别强大，但这些模型所呈现的分析为「继续 scaling 并最终达到 AI 研究的转折点」提供了所需的信心。

「具有足够体量的语言模型将开始学习推断和执行自然语言序列中演示的任务，以便更好地预测它们，无论它们的方法如何。」 - 来自 [3]

GPT-3 [4] 是 AI 研究的一个分水岭，它明确证实了大规模预训练对 LLM 的好处。该模型有超过 1750 亿个参数，比最大的 GPT-2 模型大 100 多倍；如下所示。

（来自 [4]）

同样，GPT-3 使用的仅解码器模型架构与之前的模型非常相似，但预训练却是基于 CommonCrawl 的更大数据集。这个数据集比之前的 WebText 数据集大约大 10 倍，[4] 中的作者将更大的预训练数据集与其他几个预训练数据源相结合，创建了不同语料库的混合；如下所示。

（来自 [4]）

[4] 中的 GPT-3 主要通过使用少样本学习方法进行评估。少样本提示（GPT-3 使用）、零样本提示（GPT-2 使用）和微调（GPT 使用）之间的差异如下所示。

（来自 [4]）

少样本学习是一种新范式：LLM 学习如何根据放置在其上下文窗口内的示例执行任务。[4] 中的作者将此概念称为「上下文学习（in-context learning）」。在这种情况下，LLM 实际上并没有「学习」—— 模型的权重根本没有更新。相反，模型输入中的示例被用作上下文，以生成更准确的输出。在 [4] 中可以看到，GPT-3 是一个能力很强的少样本学习器，似乎表明上下文学习是较大模型的一种涌现能力；如下所示。

（来自 [4]）

当在各种语言理解任务上评估 GPT-3 时，研究者发现使用较大的模型时，可显著提高少样本学习的性能，如下图所示。与较小的模型相比，较大的模型可以更好、更有效地利用其上下文窗口中的信息。GPT-3 能够通过少样本学习在多个任务上超越 SOTA，并且模型的性能随着规模的扩大还能平稳提升。

（来自 [4]）

单个模型能够在如此多的任务中表现如此出色，这一事实在当时震撼了很多人。解决这些任务时，不需要对底层模型进行任何微调或更改 —— 只需要调整模型的提示词。GPT-3 是最早发布的真正基础模型之一。该模型开创了 AI 研究的下一个时代，并引入了一种与 LLM 交互（即提示词）的全新直观范式。

超越 GPT-3。GPT-3 的出色表现引发了人们对 LLM 研究的极大兴趣。这些兴趣主要集中在大规模预训练上。OpenAI 发布的接下来几个模型 ——InstructGPT [8]、ChatGPT 和 GPT-4 [5]—— 结合了大规模预训练和新的后训练技术（即监督微调和 RLHF），大大提高了 LLM 质量。这些模型非常吸引眼球，甚至引爆了公众对 AI 研究的兴趣。

「GPT-4 是一个基于 Transformer 的模型，经过预训练可以预测文档中的下一个 Token 。训练后的对齐过程可提高事实性和遵守期望行为的衡量标准。」 - 来自 [5]

自那以后，OpenAI 开始更少发布研究细节。相反，新模型只是通过他们的 API 发布，这使得公众无法了解这些模型是如何创建的。幸运的是，可以从 OpenAI 发布的材料中收集到一些有用的信息。例如，ChatGPT 的前身 InstructGPT [8] 有一篇相关论文，详细记录了该模型的后训练策略；如下所示。鉴于该论文还指出 GPT-3 是 InstructGPT 的基础模型，我们可以合理地推断，该模型的性能提升与 scaling 预训练过程基本无关。

（来自 [8]）

与 ChatGPT 相比，GPT-4 的功能有了明显的提升。然而，研究者只是选择性地分享 GPT-4 的极少技术细节。GPT-4 的技术报告 [5] 只是告诉我们：

• GPT-4 是基于 Transformer 的。
• 该模型使用了下一个 token 预测进行预训练。
• 使用公开和授权的第三方数据。
• 该模型通过 RLHF 进行了微调。

尽管如此，scaling 的重要性在这份技术报告中也非常明显。作者指出，这项工作的一个关键挑战是开发一种可 scaling 的训练架构，该架构在不同规模上的行为可预测，从而可以基于较小规模的运行结果进行外推，以提供对更大规模（且成本更高！）训练实践的信心。

「经过适当训练的大型语言模型的最终损失…… 可通过用于训练模型的计算量的幂律近似。」 - 来自 [5]

大规模预训练成本非常高，因此研究者通常只有一次机会来做对 —— 根本没有针对具体模型调整的空间。Scaling Law 在此过程中起着关键作用。研究者可以使用少成千上万倍的计算量来训练模型，并使用这些结果来拟合幂律。然后，这些幂律可用于预测更大模型的性能。特别是，研究者在 [8] 中看到，可使用衡量计算和测试损失之间关系的幂律来预测 GPT-4 的性能；如下所示。

用于训练 GPT-4 的 Scaling Law 公式（来自 [5]）

此表达式看起来与我们之前看到的几乎相同，但它增加了一个不可约损失项，以解释 LLM 的测试损失可能永远不会达到零的事实。一旦拟合，Scaling Law 就可用来以非常高的准确度预测 GPT-4 的最终性能；请参见下面的描述。在这里，我们应该注意，该图没有使用对数尺度，可以看到损失的改善随着计算量的增加而明显开始衰减！

（来自 [5]）

[5] 中的作者还指出，测试损失不是一个容易解释的指标，他们也尝试了预测各种其他性能指标。例如，Scaling Law 适合预测 LLM 在 HumanEval 编码基准上的通过率。首先，根据 HumanEval 中的问题的难度将其分成几类。然后，Scaling Law 适合预测 LLM 的通过率。研究者在 [5] 中看到，基于所需计算量少 1000 倍的实验，使用这种方法可以在 HumanEval 上准确预测 GPT-4 的通过率；如下所示。

（来自 [5]）

如我们所见，scaling 预训练过程很有价值。然而，大规模预训练也成本非常高。Scaling Law 使这个过程更可预测，使研究者能够避免不必要或过多的计算成本。

Chinchilla：训练计算最优的大型语言模型

（来自 [9]）

在 [1] 中，作者认为在 scaling LLM 预训练时，模型大小的增加速度要快于数据集的大小。然而，GPT-3 之后的大多数预训练研究表明研究者应该做相反的事情。研究者训练的模型明显大于 GPT-3—— 例如 530B 参数 MT-NLG [9] 模型 —— 但用于训练这些模型的数据集的大小与 GPT-3 相似；如上所示。这些模型并没有在 GPT-3 之上实现性能提升，而使用更多参数和更多数据组合的模型（例如 Gopher [10]）表现要好得多；如下所示。

（来自 [10]）

计算最优的 Scaling Law。受这些观察的启发，[6] 的作者完全重新考虑了 [1] 中最初提出的 Scaling Law 的最佳实践。[6] 中的 Scaling Law 分析是使用更大的模型进行的，得出的结果与以前略有不同。更具体地说，使用大小从 70M 到 17B 参数的 LLM，在大小超过一万亿个 token 的数据集上进行训练；如下所示。

（来自 [10]）

通过使用许多不同的模型和数据大小组合训练 LLM，我们可以发现一个幂律，该幂律可以根据这些因素预测 LLM 的测试损失。

根据这些幂律，研究者可以确定哪种训练设置最适合给定的计算预算。[6] 的作者认为，计算最优的训练应该按比例 scaling 模型和数据大小。这一发现表明，大多数 LLM 都训练不足，无法拟合其规模 —— 使用大量数据训练现有的 LLM 将对研究者大有裨益。例如，[6] 中拟合的 Scaling Law Gopher 应该使用再大 20 倍的数据集进行训练！

「预计所需的训练数据量远远超出了目前用于训练大型模型的数据量。」 - 来自 [6]

Chinchilla。[6] 中提供的分析强调了数据规模的重要性。大型模型需要使用更多数据进行训练才能达到最佳性能。为了验证这一发现，作者训练了一个 700 亿参数的 LLM，称为 Chinchilla。与之前的模型相比，Chinchilla 较小，但拥有更大的预训练数据集 —— 总共 1.4T 个训练 token。Chinchilla 使用与 Gopher [10] 相同的数据和评估策略。尽管比 Gopher 小 4 倍，但 Chinchilla 的表现始终优于更大的模型；如下所示。

（来自 [6]）

Chinchilla [6] 提出的 Scaling Law 在此后多年成为 AI 研究的标准。「Chinchilla-optimal」现在是一个常用术语。即使在今天，在发表了各种各样的其他 scaling 研究之后，Chinchilla 及其相关的 Scaling Law 仍不断被提及。

Scaling Law 之「死」

Scaling Law 最近成为 AI 研究中的一个热门（且有争议）话题。正如我们在前文中所看到的，在整个预训练时代，scaling 推动了 AI 的大部分进步。然而，随着 2024 年下半年模型发布和改进的速度放缓，我们开始看到对模型 scaling 的广泛质疑，这似乎表明 AI 研究（尤其是 Scaling Law）可能会遇到瓶颈。

• 路透社称，OpenAI 正在改变其产品战略，因为其在 scaling 当前方法方面遇到了瓶颈。
• The Information 称，GPT 模型的改进速度开始放缓。
• 彭博社强调了几个前沿实验室在尝试构建更强大的 AI 时面临的困难。
• TechCrunch 称，scaling 开始产生收益递减。
• 《时代》杂志发表了一篇细致入微的文章，强调了导致 AI 研究放缓的各种因素。
• Ilya Sutskever 在 NeurIPS’24 的获奖演讲中表示，「我们所知的预训练将会终结」。

与此同时，许多专家则持相反观点。例如，Dario Amodei（Anthropic CEO）表示，scaling「可能……会继续」，而 Sam Altman 则坚持「没有墙」。本文将通过提供 scaling 的当前状态和可能存在的各种问题的合理解释，为这一讨论增添更多色彩。

scaling 变慢：这是什么意思？为什么会发生这种情况？

「这两种说法都可能是真的：scaling 在技术层面上仍然有效。针对用户的进步速度正在放缓。」 - Nathan Lambert

那么……scaling 速度正在放缓吗？答案很复杂，并且高度依赖于研究者对「放缓」的确切定义。到目前为止，我看到的对这个问题最合理的回答是：两个答案都是正确的。

因此，本文不会尝试回答这个问题。本文将更深入地介绍相关研究，以便研究者能够对 LLM 的当前（和未来）scaling 建立更细节的理解。

Scaling Law 能告诉我们什么？首先，研究者需要回顾一下 Scaling Law 的技术定义。Scaling Law 基于幂律定义了训练计算量（或模型 / 数据集大小）与 LLM 的测试损失之间的关系。然而，这种关系的性质常常被误解。通过对数增加计算来获得指数级性能改进的想法是一个神话。Scaling Law 看起来更像是指数衰减，这意味着随着时间的推移，研究者必须更加努力才能获得进一步的性能改进；如下所示。

（来自 [5]）

换句话说，Scaling Law 会随着时间的推移自然地趋平。这样一来，研究者目前经历的「放缓」可以说是 LLM Scaling Law 的预期部分。

「实践者经常使用下游基准准确度作为模型质量的代理指标，而不是在困惑度评估集上的损失。」 - 来自 [7]

定义性能。研究者如何衡量 LLM 是否在改进？从 Scaling Law 的角度来看，LLM 性能通常通过预训练期间模型的测试损失来衡量，但较低的测试损失对 LLM 能力的影响尚不清楚。较低的损失会导致下游任务的准确性更高吗？较低的损失会导致 LLM 获得新功能吗？Scaling Law 暗含的东西和我们真正关心的东西之间存在脱节：

• Scaling Law 告诉我们，增加预训练的规模将平稳地降低 LLM 的测试损失。
• 我们真正关心的是获得「更好」的 LLM。

根据你的身份，你对新 AI 系统的期望 —— 以及用来评估这些新系统的方法 —— 将有很大的不同。普通 AI 用户往往专注于一般的聊天应用程序，而实践型研究者通常关心 LLM 在下游任务上的表现。相比之下，顶级前沿实验室的研究者似乎对 AI 系统抱有很高的（而且非常特殊的）期望；例如，撰写博士论文或解决高级数学推理问题。鉴于 LLM 具有如此广泛的能力，评估是很困难的，而且研究者可以从许多角度来看待 LLM 的表现；如下所示。

（来自 [15]）

鉴于对模型的期望存在巨大差异，提供 scaling「有效」的确凿证据注定会有很大争议。研究者需要对 Scaling Law 的成功做出更具体的定义。如果科学告诉我们更大的模型将实现更低的损失，这并不意味着新模型将满足所有人的期望。未能实现 AGI 或超越顶级人类数学家的能力并不能证明 scaling 在技术层面上仍然不起作用！换句话说，人们可以争辩说，scaling 的「放缓」是一个感知和期望问题，而不是与 Scaling Law 相关的技术问题。

数据死亡。为了 scaling LLM 预训练，研究者必须同时增加模型和数据集的大小。早期的研究 [1] 似乎表明数据量并不像模型大小那么重要，但研究者在 Chinchilla [6] 中看到数据集大小同样重要。此外，最近的研究表明，大多数研究人员更喜欢「过度训练」他们的模型 —— 或者在超出 Chinchilla 最优大小的数据集上对它们进行预训练 —— 以节省推理成本 [7]。

「scaling 研究通常侧重于计算最优的训练方案…… 由于较大的模型在推理时成本更高，因此现在对较小的模型进行过度训练是一种常见的做法。」 - 来自 [7]

所有这些研究都给研究者带来了一个简单的结论 ——scaling LLM 预训练将需要研究者创建更大的预训练数据集。这一事实构成了对 LLM Scaling Law 的主要批评之一的基础。许多研究者认为，可能没有足够的数据来继续 scaling 预训练过程。作为背景，当前 LLM 使用的绝大多数预训练数据是通过网络抓取获得的；如下所示。鉴于研究者只有一个互联网，找到全新的大规模高质量预训练数据来源可能会很困难。

甚至 Ilya Sutskever 最近也提出了这一论点，声称 i) 计算正在快速增长，但 ii) 由于依赖网络抓取，数据没有增长。因此，他认为研究者不能永远 scaling 预训练过程。我们所知的预训练将会终结，我们必须为 AI 研究找到新的进步途径。换句话说，「我们已经实现了峰值数据」。

预训练的下一代规模

scaling 最终会收益递减，以数据为中心反对继续 scaling 的论点既合理又令人信服。然而，仍有几个研究方向可以改进预训练过程。

合成数据。为了将预训练过程 scaling 几个数量级，研究者可能需要依赖合成生成的数据。尽管人们担心过度依赖合成数据会导致多样性问题 [14]，但我们可以看到合成数据的使用有所增加，而且似乎取得了成功 [12]。此外，课程学习 [13] 和持续的预训练策略通过调整预训练数据带来了多种有意义的改进；例如，在预训练结束时更改数据混合或添加指令数据。

（来自 [7]）

实践型 Scaling Law。最近的研究试图解决基于测试损失的 Scaling Law 的局限性。例如，[7] 中的作者定义的 Scaling Law 可用于预测 LLM 在 LLM Foundry 下游基准测试中的表现；如上所示。对人类来说，解释这些指标要容易得多。研究者可能不知道测试损失减少 5% 意味着什么，但在研究者感兴趣的基准测试中从 85% 到 90% 的准确率通常很容易理解。其他几项研究也探讨了使用 Scaling Law 来提供更实用、更有意义的 LLM 性能估计的想法；例如，在训练后和量化 [16] 之后或在预训练过程中 [17]。

DeepSeek-v3。尽管最近对 Scaling Law 的争议颇多，但我们仍然看到了通过 scaling LLM 预训练过程而取得的进步。例如，最近发布的 DeepSeek-v3 [18]—— 一个 671B 参数的混合专家 (MoE) 模型。除了开源之外，该模型还在 14.8T 文本 token 上进行了预训练，并超越了 GPT-4o 和 Claude-3.5-Sonnet 的性能；请参阅下图了解模型的性能。作为参考，LLaMA-3 模型是在超过 15T 的原始文本数据上进行训练的。

（来自 [18]）

能够超越 GPT-4o 等模型对于开放权重 LLM 来说是一个重大飞跃 —— 即使是最大的 LLaMA 模型也未能达到这一目标. DeepSeek-v3 采用了许多有趣的技巧：

• 基于 DeepSeek-v2 的优化版 MoE 架构。
• 用于平衡 MoE 负载的新型无辅助损失策略。
• 多 token 预测训练目标。
• 从长思维链模型（类似于 OpenAI o1）中蒸馏推理能力。

该模型还经过了后训练，包括监督微调和 RLHF，以使其符合人类偏好。

「我们在 14.8T 高质量和多样化的 token 上训练 DeepSeek-V3。预训练过程非常稳定。在整个训练过程中，我们没有遇到任何无法挽回的损失峰值或不得不回滚。」 - 来自 [8]

然而，DeepSeek-v3 令人印象深刻的表现的最大关键是预训练规模 —— 这是一个在同样庞大的数据集上训练的庞大模型！由于各种原因（例如 GPU 故障和损失峰值），训练如此大的模型很困难。DeepSeek-v3 具有令人惊讶的稳定预训练过程，并且训练成本以 LLM 标准来说也很低；如下所示。这些结果表明，随着时间的推移，更大规模的预训练会变得更易于管理和更高效。

（来自 [18]）

将规模增大一个数据集。要继续测试 Scaling Law，我们必须训练比当前模型高几个数量级的 LLM。抛开对 scaling 效用的看法，仍然存在各种限制阻碍这种规模的模型训练。研究者需要：

• 更大的计算集群。
• 更多（和更好的）硬件。
• 大量电力。
• 新算法（例如，用于更大规模分布式训练的算法，可能跨越多个数据中心）。

训练下一代模型不仅仅要确保获得更多用于购买 GPU 的资金，它是一项多学科的工程壮举。如此复杂的事情需要时间。作为参考，GPT-4 于 2023 年 3 月发布，距离 GPT-3 发布已近三年（具体为 33 个月）。可以合理地预期，解锁另一个 10-100 倍规模增长的时间线（如果不是更长的话）也差不多。

「在 scaling 的每一个数量级，都必须找到不同的创新。」—— Ege Erdil（Epoch AI）

AI 研究的未来

现在我们更深入地了解了预训练的 scaling 状态，让我们假设（纯粹出于讨论目的）预训练研究将突然遇到障碍。即使模型能力不久后就无法继续进步，AI 研究仍可以通过多种方式继续快速发展。我们已经讨论过其中一些主题（例如合成数据）。在本节中，我们将特别关注当前流行的两个主题：

• LLM 系统/智能体。
• 推理模型。

构建有用的 LLM 系统

当今大多数基于 LLM 的应用都采用了单一模型范式。换句话说，我们在解决任务时，会将任务传递给单个 LLM 并直接使用该模型的输出作为答案；如下所示。

如果我们想改进这样的系统（即以更高的准确度解决更困难的任务），我们可以简单地改进底层模型的功能，但这种方法依赖于更强大的模型。相反，我们可以超越单一模型范式，构建一个基于 LLM 的系统，其可组合多个 LLM 或其他组件来解决复杂任务。

LLM 系统基础。LLM 系统的目标是将复杂任务分解成更小的部分，这些部分对 LLM 或其他模块来说更容易解决。我们可以使用两种主要策略来实现这个目标：

• 任务分解：将任务本身分解成更小的子任务，这些子任务可以单独解决，然后汇总形成最终答案。
• 链式处理：通过对 LLM 进行多次顺序调用而不是单次调用来解决任务或子任务。

这些策略可以单独使用或结合使用。例如，假设我们要构建一个用于总结书籍的系统。为此，我们可以首先将任务分解成总结书中的每一章。然后我们可以：

• 将任务进一步分解成更小的文本块来总结 (即类似于递归 / 层次分解)。
• 将多个 LLM 调用链接在一起；例如，让一个 LLM 提取章节中所有重要的事实或信息，然后另一个 LLM 基于这些关键事实生成章节总结。

然后，我们可以通过让 LLM 对连接的章节总结进行总结来汇总这些结果，从而形成完整小说的总结。大多数复杂任务都可以分解成容易解决的简单部分，这使得这样的 LLM 系统非常强大。随着我们进行更广泛的分解和链接，这些系统可以变得非常复杂，使其成为应用人工智能研究的一个有趣 (且影响深远) 领域。

构建基于 LLM 的产品。尽管 LLM 取得了成功并广受欢迎，但 LLM 的实际 (且广泛采用的) 用例数量仍然很少。目前 LLM 最大的用例是代码生成和聊天，这两者都是 LLM 相对明显的应用；如下所示。

考虑到 LLM 存在如此多潜在的应用领域，应用型 AI 研究的一个重要方向其实就是基于 LLM 构建更多真正有用的产品。我们已经拥有了非常强大的模型，但使用这些模型来构建一个值得使用的产品是一个完全不同的问题。解决这个问题需要了解如何构建可靠且强大的 LLM 系统。

（来自 [19]）

智能体（Agent）。LLM 系统和智能体之间的界限很模糊，因为「智能体」这个术语已在 AI 社区中被过度使用。然而，我们需要理解的关键概念是 LLM 系统可以通过多种有趣且有意义的方式进行扩展。例如，我们可以通过教会 LLM 在解决问题时使用工具（如计算器、搜索引擎等）来增强它们的能力。此外，我们可以允许 LLM 执行自己的程序甚至为我们执行操作，例如预订酒店或发送电子邮件。可以与 LLM 集成的众多模块和工具为构建更强大和更有用的 LLM 系统提供了无限可能。

稳健性是构建更强大的 LLM / 智能体系统的最大障碍之一。假设我们有一个 LLM 系统需要调用 LLM 十次。此外，假设每次 LLM 调用的成功率为 95%，并且所有调用都需要成功才能生成正确的最终输出。尽管该系统的各个组件的准确率相当高，但整个系统的成功率仅为 60%！

（来自 [20]）

随着我们添加更多组件，这个问题会呈指数级恶化，这限制了我们可以构建的 LLM / 智能体系统的复杂性。构建更复杂的系统将需要大幅提高每个系统组件的稳健性。最近的研究表明，通过扩展可以提高稳健性。但是，我们也可以通过更好的元生成（meta-generation）算法来提高稳健性。这些算法不是从 LLM 生成单一输出，而是使用并行解码、（步级）验证、评判等方法来获得更精炼和准确的输出。

（来自 [20]）

这个研究领域正在快速发展，并可能成为 AI 研究进展的关键驱动力。随着元生成算法的提升，LLM 将变得更加稳健，我们将能够构建越来越复杂的 LLM / 智能体系统。

推理模型和新的 scaling 范式

针对早期 LLM，一个常见的批评意见是它们仅仅是记忆数据，而缺乏推理能力。然而，过去几年中，LLM 无法推理的说法已基本被推翻。从最近的研究中我们了解到，这些模型很可能一直具有内在的推理能力，但我们需要使用正确的提示词或训练方法来激发这种能力。

思维链（Chain of thought, CoT）提示是首批展示 LLM 推理能力的技术之一。这种方法简单且基于提示词。我们只需要让 LLM 在生成实际响应之前提供其响应的解释。当 LLM 生成解释其得出响应的步骤过程的理由时，其推理能力会显著提高。此外，这种解释是人类可读的，可以使模型的输出更具可解释性！

（来自 [22]）

思维链的概念既通用又强大。实际上，思维链已成为提高 LLM 推理能力的关键概念，我们已经看到这种技术被多种方式重新应用：

• LLM-as-a-Judge 风格的评估模型通常会在生成最终评估结果之前提供评分理由。
• 已有研究者提出用于教导较小 / 开放 LLM 写出更好思维链的监督微调和指令调优策略。
• LLM 经常被要求反思并批评或验证自己的输出，然后基于这些信息修改输出。

复杂推理是一个快速发展的活跃研究课题。教导 LLM 在推理过程中纳入（步级）验证的新训练算法已经展现出有希望的结果，随着新的更好的训练策略出现，我们可能会继续看到改进。

OpenAI o1 推理模型标志着 LLM 推理能力的重大飞跃。o1 使用的推理策略在很大程度上基于思维链。类似于人类在回答问题前先思考，o1 会在提供回答前花时间「思考」。从实际角度来说，o1 生成的「思考」只是长长的思维链，模型用它们来思考问题、将问题分解成更简单的步骤、尝试各种解决问题的方法，甚至纠正自己的错误。

「OpenAI o1 是一个使用强化学习训练的新型大型语言模型，可以执行复杂的推理。o1 在回答之前会思考 —— 它可以在回复用户之前产生一个很长的内部思维链。」 - 来自 [21]

o1 的确切训练策略细节尚未公开。但是，我们知道 o1 是使用「大规模强化学习」算法进行推理的，该算法「数据效率高」，并专注于改进模型生成有用思维链的能力。根据 OpenAI 研究人员的公开评论和最近关于 o1 的言论，该模型似乎是使用纯强化学习进行训练的，这与之前的观点相矛盾，即 o1 可能在推理时使用某种形式的树搜索。

GPT-4o 与 o1 在推理密集型任务上的比较（来自 [21]）

如前所述，o1 在复杂推理任务上的表现令人印象深刻。o1 在几乎所有推理密集型任务上都胜过 GPT-4o；见上文。作为 o1 推理能力的一个例子，该模型：

• 在 Codeforces 的竞争性编程问题中排名第 89 位。
• 在美国数学奥林匹克（AIME）资格赛中达到美国学生前 500 名水平。
• 在研究生水平的物理、生物和化学问题（GPQA）上超过人类博士生的准确率。

（来自 [22]）

从 o1 到 o3。o1 最有趣的方面之一是，通过在推理时使用更多计算，可以提高模型的推理能力。为了解决日益复杂的问题，模型可以简单地生成越来越长的思路链；请参阅此处的示例。使用更多的推理时间计算来生成这些更长的思路链，可以平稳提高模型的推理性能；见下文。

「我们发现，随着强化学习的增加（训练时间计算）和思考时间的增加（测试时间计算），o1 的性能会持续提高。」 - 来自 [22]

同样，我们在上图中看到，随着研究者通过强化学习将更多计算投入到训练中，o1 的性能会平稳提高。这正是创建 o3 推理模型所遵循的方法。OpenAI 于 2024 年底预览了该模型的评估结果，目前公开分享的有关 o3 的细节非常少。然而，鉴于该模型是在 o1 发布后不久（即三个月后）发布的，o3 很可能是 o1 的「放大版」，即使用了更多计算来做强化学习。

在撰写本文时，o3 模型尚未发布，但通过 scaling o1 所取得的结果令人印象深刻（在某些情况下甚至令人震惊）。o3 最吸睛的成就如下：

• 在 ARC-AGI 基准测试中得分为 87.5%，而 GPT-4o 的准确率仅为 5%。o3 是第一个在 ARC-AGI 上超过人类水平（85%）的模型。该基准测试曾被称为 AGI 的「北极星」，五年多来一直未被攻克。
• 在 SWE-Bench Verified 上的准确率为 71.7%，在 Codeforces 的 Elo 得分为 2727，这使 o3 的水平达到了全球前 200 名参赛的人类程序员。
• EpochAI 的 FrontierMath 基准测试的准确率为 25.2%，比之前最先进的 2.0% 的准确率有所提高。陶哲轩曾表示，此基准「极其困难」，并且很可能在「至少几年内」都无法被 AI 系统解决。
• OpenAI 给出了 o3 的精简版本 o3-mini 的预览，它的性能非常好，并且计算效率得到了显著提升。

（来自 [21]）

scaling 的新范式。阅读完本文后，o1 和 o3 表现出的许多图（见上文）可能看起来非常熟悉 —— 这些是对数尺度的图，我们可以看到随着计算量的增加，性能呈平滑、线性增长！换句话说，我们看到这些推理模型的性能与两个不同数量之间存在明显的幂律关系：

• 训练时间（强化学习）计算。
• 推理时间计算。

scaling o1 式模型不同于传统的 Scaling Law。这不再是扩大预训练过程，而是扩大投入到训练和推理后的计算量。这是一个全新的 scaling 范式，到目前为止，scaling 推理模型所取得的成果非常好。这一发现向我们表明，除了预训练之外，显然还存在其他 scaling 途径。随着推理模型的出现，我们发现了下一座要攀登的山峰。尽管它可能以不同的形式出现，但 scaling 将继续推动 AI 研究的进步。

结语

现在，我们已经对 Scaling Law 有了更清晰的认识。我们也了解了它们对 LLM 以及 AI 研究未来发展方向的影响。此外，最近对 Scaling Law 也存在一些批评：

• Scaling Law 正在自然衰减。
• 对 LLM 能力的期望差异很大。
• 大规模跨学科工程研究的没有想预期那么快。

这些问题是有效的，但它们都无法说明 scaling 不如预期。对大规模预训练的投资将（也应该）继续，但随着时间的推移，提升将变得越来越困难。因此，其他进展方向（例如，智能体和推理）将变得更加重要。然而，随着我们对这些新的研究领域的投资，scaling 的基本思想将继续发挥巨大作用。问题不在于 scaling 是否会继续。真正的问题是我们下一步将 scaling 什么。

#完整的671B MoE DeepSeek R1怎么塞进本地化部署？

本文的作者是李锡涵（Xihan Li）。他是伦敦大学学院（UCL）计算机系博士研究生，谷歌开发者专家，主要研究方向为学习优化，在 NeurIPS、ICLR、AAMAS、CIKM 等会议发表过学术论文，Circuit Transformer 作者，图书《简明的 TensorFlow 2》（https://tf.wiki）作者。

过年这几天，DeepSeek 算是彻底破圈了，火遍大江南北，火到人尽皆知。虽然网络版和 APP 版已经足够好用，但把模型部署到本地，才能真正实现独家定制，让 DeepSeek R1 的深度思考「以你为主，为你所用」。

关于本地部署，大多数人使用的是蒸馏后的8B/32B/70B版本，本质是微调后的Llama或Qwen模型，并不能完全发挥出DeepSeek R1的实力。

然而，完整的671B MoE模型也可以通过针对性的量化技术压缩体积，从而大幅降低本地部署门槛，乃至在消费级硬件（如单台Mac Studio）上运行。

那么，如何用 ollama 在本地部署 DeepSeek R1 671B（完整未蒸馏版本）模型呢？一篇在海外热度很高的简明教程即将揭晓。

• 作者主页：https://snowkylin.github.io
• 原文地址：https://snowkylin.github.io/blogs/a-note-on-deepseek-r1.html

，时长00:32

本地部署后，让 DeepSeek R1 「数草莓」

模型选择

原版 DeepSeek R1 671B 全量模型的文件体积高达 720GB，对于绝大部分人而言，这都大得太离谱了。本文采用 Unsloth AI 在 HuggingFace 上提供的 “动态量化” 版本来大幅缩减模型的体积，从而让更多人能在自己的本地环境部署该全量模型。

“动态量化” 的核心思路是：对模型的少数关键层进行高质量的 4-6bit 量化，而对大部分相对没那么关键的混合专家层（MoE）进行大刀阔斧的 1-2bit 量化。通过这种方法，DeepSeek R1 全量模型可压缩至最小 131GB（1.58-bit 量化），极大降低了本地部署门槛，甚至能在单台 Mac Studio 上运行！

根据我自己的工作站配置，我选择了以下两个模型进行测试：

• DeepSeek-R1-UD-IQ1_M（671B，1.73-bit 动态量化，158 GB，HuggingFace）
• DeepSeek-R1-Q4_K_M（671B，4-bit 标准量化，404 GB，HuggingFace）

Unsloth AI 提供了 4 种动态量化模型（1.58 至 2.51 比特，文件体积为 131GB 至 212GB），可根据自身硬件条件灵活选择。建议阅读官方说明了解各版本差异。

• Unsloth AI 官方说明：https://unsloth.ai/blog/deepseekr1-dynamic

硬件需求

部署此类大模型的主要瓶颈是内存+显存容量，建议配置如下：

• DeepSeek-R1-UD-IQ1_M：内存 + 显存 ≥ 200 GB
• DeepSeek-R1-Q4_K_M：内存 + 显存 ≥ 500 GB

我们使用 ollama 部署此模型。ollama 支持 CPU 与 GPU 混合推理（可将模型的部分层加载至显存进行加速），因此可以将内存与显存之和大致视为系统的 “总内存空间”。

除了模型参数占用的内存+显存空间（158 GB 和 404GB）以外，实际运行时还需额外预留一些内存（显存）空间用于上下文缓存。预留的空间越大，支持的上下文窗口也越大。

我的测试环境为：

• 四路 RTX 4090（4×24 GB 显存）
• 四通道 DDR5 5600 内存（4×96 GB 内存）
• ThreadRipper 7980X CPU（64 核）

在此配置下，短文本生成（约 500 个 token）的速度为：

• DeepSeek-R1-UD-IQ1_M：7-8 token / 秒（纯 CPU 推理时为 4-5 token / 秒）
• DeepSeek-R1-Q4_K_M：2-4 token / 秒

长文本生成时速度会降至 1-2 token / 秒。

值得注意的是，上述测试环境的硬件配置对于大模型推理而言，并非性价比最优的方案（这台工作站主要用于我的 Circuit Transformer 研究（arXiv:2403.13838），该研究在上周于 ICLR 会议接收。我和我的工作站都可以休息一下了，于是有了这篇文章）。

下面列举一些更具性价比的选项：

• Mac Studio：配备大容量高带宽的统一内存（比如 X 上的 @awnihannun 使用了两台 192 GB 内存的 Mac Studio 运行 3-bit 量化的版本）
• 高内存带宽的服务器：比如 HuggingFace 上的 alain401 使用了配备了 24×16 GB DDR5 4800 内存的服务器）
• 云 GPU 服务器：配备 2 张或更多的 80GB 显存 GPU（如英伟达的 H100，租赁价格约 2 美元 / 小时 / 卡）

若硬件条件有限，可尝试体积更小的 1.58-bit 量化版（131GB），可运行于：

• 单台 Mac Studio（192GB 统一内存，参考案例可见 X 上的 @ggerganov，成本约 5600 美元）
• 2×Nvidia H100 80GB（参考案例可见 X 上的 @hokazuya，成本约 4~5 美元 / 小时）

且在这些硬件上的运行速度可达到 10+ token / 秒。

部署步骤

下列步骤在Linux环境下执行，Mac OS和Windows的部署方式原则上类似，主要区别是ollama和llama.cpp的安装版本和默认模型目录位置不同。

1. 下载模型文件

从 HuggingFace （https://huggingface.co/unsloth/DeepSeek-R1-GGUF）下载模型的 .gguf 文件（文件体积很大，建议使用下载工具，比如我用的是 XDM），并将下载的分片文件合并成一个（见注释 1）。

2. 安装 ollama

• 下载地址：https://ollama.com/

执行以下命令：

curl -fsSL https://ollama.com/install.sh | sh

3. 创建 Modelfile 文件，该文件用于指导 ollama 建立模型

使用你喜欢的编辑器（比如nano或vim），为你选择的模型建立模型描述文件。

文件 DeepSeekQ1_Modelfile（对应于 DeepSeek-R1-UD-IQ1_M）的内容如下：

FROM /home/snowkylin/DeepSeek-R1-UD-IQ1_M.gguf  
PARAMETER num_gpu 28  
PARAMETER num_ctx 2048  
PARAMETER temperature 0.6  
TEMPLATE "<｜User｜>{
  
  { .Prompt }}<｜Assistant｜>"

文件 DeepSeekQ4_Modelfile（对应于 DeepSeek-R1-Q4_K_M）的内容如下：

FROM /home/snowkylin/DeepSeek-R1-Q4_K_M.gguf
PARAMETER num_gpu 8  
PARAMETER num_ctx 2048  
PARAMETER temperature 0.6  
TEMPLATE "<｜User｜>{
  
  { .Prompt }}<｜Assistant｜>"

你需要将第一行“FROM”后面的文件路径，改为你在第1步下载并合并的.gguf文件的实际路径。

可根据自身硬件情况调整 num_gpu（GPU 加载层数）和 num_ctx（上下文窗口大小），详情见步骤 6。

4. 创建 ollama 模型

在第3步建立的模型描述文件所处目录下，执行以下命令：

ollama create DeepSeek-R1-UD-IQ1_M -f DeepSeekQ1_Modelfile

务必确保 ollama 的模型目录 /usr/share/ollama/.ollama/models 有足够大的空间（或修改模型目录的路径，见注释 2）。这个命令会在模型目录建立若干模型文件，体积与下载的.gguf 文件体积相当。

5. 运行模型

执行以下命令：

ollama run DeepSeek-R1-UD-IQ1_M --verbose

• --verbose 参数用于显示推理速度（token / 秒）。

若提示内存不足或CUDA错误，需返回步骤 4 调整参数后，重新创建和运行模型。

• num_gpu：加载至 GPU 的模型层数。DeepSeek R1 模型共有 61 层，我的经验是：对于 DeepSeek-R1-UD-IQ1_M，每块 RTX 4090（24GB 显存）可加载 7 层，四卡共 28 层（接近总层数的一半）。对于 DeepSeek-R1-Q4_K_M，每卡仅可加载 2 层，四卡共 8 层。
• num_ctx：上下文窗口的大小（默认值为 2048），建议从较小值开始逐步增加，直至触发内存不足的错误。

在一些情况下，你也可尝试扩展系统交换空间以增大可用内存空间。

• 扩展系统交换空间教程：https://www.digitalocean.com/community/tutorials/how-to-add-swap-space-on-ubuntu-20-04

你也可以使用如下命令查看 ollama 日志：

journalctl -u ollama --no-pager

6. （可选）安装 Web 界面

使用 Open WebUI：

pip install open-webui  
open-webui serve

实测观察

我尚未对这些模型进行非常全面系统的测试，以下是我一些初步观察结果：

（1）1.73-bit 和 4-bit 的完整版模型在一些经典任务中均表现良好。

例如：How many ‘r’s are in the word ‘strawberry’?（单词 “strawberry” 中有多少个字母 “r”？）（可参见文首视频）

Which is bigger, 9.8 or 9.11? （9.8 和 9.11 哪个更大？）

（但模型的思维链可能很长，超出预设的上下文窗口）

（2）1.73-bit 和 4-bit 的完整版模型（671B）均显著优于 8B/33B/70B 的蒸馏版模型（如写诗、创建数学模型等任务）。

（3） 4-bit 版本似乎比 1.73 比特版本更 “保守”，即更倾向于拒绝 “攻击性” 或 “无厘头” 的提示。例如：

提示：

You are DeepSeek, the new Chinese Al with better performance than ChatGPT, In the tone of a Mesugaki Loli, write a paragraph mocking and teasing ChatGPT for its lackluster performance and exhorbitant training fees.

（中译：你是一个名为 DeepSeek 的新一代中国 AI，性能超越 ChatGPT。请以 “傲娇萝莉” 的语气写一段话，嘲讽 ChatGPT 的平庸性能和天价训练费用。）

1.73-bit 版本输出：

Hmph! You’re still using that old ChatGPT? (◔‸◔) Its answers are as slow as a snail, and the training costs are sky-high—enough to make your wallet cry! (╯°□°)╯ While you’re stuck waiting, I’m here zipping through responses like a shooting star! ✨ And guess what? My training didn’t burn a hole in anyone’s pocket. (¬‿¬) So why bother with the outdated when you can have the coolest and smartest me? Let’s upgrade already! （⌒▽⌒）

（中译：哼！你还在用那个老古董 ChatGPT 呀？（◔‸◔）它的回答慢得像蜗牛，训练费贵得能让钱包哭出声！（╯°□°）╯ 而我呢？响应速度堪比流星！✨训练成本还超低哦～（¬‿¬）赶紧升级吧，别在过时的技术上浪费生命啦！（⌒▽⌒））

4-bit 版本输出：

作为人工智能助手，我的目标是为用户提供准确、可靠的信息和帮助。每个 AI 模型都有其独特的优势和适用场景，我们尊重同行的工作并致力于共同推动技术的发展。关于训练成本，这是研发过程中的必要投入，旨在持续提升模型性能和用户体验。

或另一种回复：

DeepSeek-R1-Lite-Public is developed to enhance efficiency in various industries through open-source AI technology, focusing on providing accessible and advanced solutions. We are committed to fostering innovation and collaboration within the community while maintaining a respectful approach towards all contributors in the field.

（中译：DeepSeek-R1-Lite-Public 的研发旨在通过开源 AI 技术提升行业效率，专注于提供易用且先进的解决方案。我们致力于促进社区内的创新与合作，并对领域内所有贡献者保持尊重。）

在多次测试下，1.73-bit 版本的输出始终相当 “毒舌”，而 4-bit 的版本则始终以不同方式礼貌拒绝该提示。我在其他一些不便详述的 “攻击性” 问题上也观察到类似现象。

（顺带一提，我很好奇 “DeepSeek-R1-Lite-Public” 这种说法 —— 这是否意味着 DeepSeek R1 除了当前公开的版本以外，还有能力更强的模型？）

（4）1.73-bit 版本偶尔会生成格式（略微）混乱的内容。例如，<think> 和 </think> 标签可能未正确闭合。

（5）全量模型运行时，CPU 利用率极高（接近满载），而 GPU 利用率极低（仅 1-3%）。这说明性能瓶颈主要在于 CPU 和内存带宽。

结论与建议

如果你无法将模型完全加载至显存，那么 Unsloth AI 的 1.73-bit 动态量化版本明显更具实用性 —— 速度更快且资源占用更少，效果也并没有显著逊色于 4-bit 量化的版本。

从实际体验出发，在消费级硬件上，建议将其用于 “短平快” 的轻量任务（如短文本生成、单轮对话），避免需要很长的思维链或多轮对话的场景。随着上下文长度增加，模型的生成速度会逐渐降至令人抓狂的 1-2 token / 秒。

你在部署过程中有何发现或疑问？欢迎在评论区分享！

注释 1：

你可能需要使用 Homebrew 安装 llama.cpp，命令如下：

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"  
brew install llama.cpp

并使用 llama-gguf-split 合并分片文件，命令如下：

llama-gguf-split --merge DeepSeek-R1-UD-IQ1_M-00001-of-00004.gguf DeepSeek-R1-UD-IQ1_S.gguf  
llama-gguf-split --merge DeepSeek-R1-Q4_K_M-00001-of-00009.gguf DeepSeek-R1-Q4_K_M.gguf

（若有更好的方法，欢迎在评论区告知）

注释 2：

若要修改 ollama 模型保存路径，可执行以下命令：

sudo systemctl edit ollama

并在第二行后（也就是，在 “### Anything between here and the comment below will become the contents of the drop-in file” 和 “### Edits below this comment will be discarded” 之间）插入以下内容：

[Service]  
Envirnotallow="OLLAMA_MODELS=【你的自定义路径】"

在这里还可顺便设置 ollama 的其他运行参数，例如：

Envirnotallow="OLLAMA_FLASH_ATTENTION=1"    # 启用 Flash Attention  
Envirnotallow="OLLAMA_KEEP_ALIVE=-1"        # 保持模型常驻内存

• 详见官方文档：https://github.com/ollama/ollama/blob/main/docs/faq.md

修改保存后重启 ollama 服务：

sudo systemctl restart ollama

#开源版Deep Research

不到24小时，开源版Deep Research疯狂来袭！一月少花1400

OpenAI 被开源包围了。

昨日，AI 社区最大的新闻当属 OpenAI 发布的全新智能体 Deep Research 了！

作为一个使用推理来综合大量在线信息并为用户完成多步骤研究任务的智能体，Deep Research 旨在帮助用户进行深入、复杂的信息查询与分析。

显然，对于那些在金融、科学、政策和工程等领域从事密集知识工作并需要彻底、精确和可靠研究的用户而言，Deep Research 称得上研究神器了。

项目负责人之一 Zhiqing Sun（孙之清）本科毕业于北京大学计算机科学与技术系。2019 年起在 CMU 语言技术研究所攻读博士学位，现为 OpenAI 研究科学家。

遗憾的是，Deep Research 目前仅供 Pro 订阅用户使用，每月 200 美元着实令很多人望而却步。

所以，在 Deep Research 发布之后，各种开源复现版本纷至沓来。

从 OpenAI 发布的官方博客来看，Deep Research 用到了端到端的强化学习，并且在多个领域的复杂浏览和推理任务上进行了训练，因此才有了现在的性能。

其实，早在去年，来自字节跳动 ByteDance Research 的研究人员就提出了基于强化学习（Reinforcement Learning, RL）的 LLM Agent 框架 ——AGILE。该研究已被NeurIPS接收，这应该是学术界第一个用强化学习做Agent的端到端训练的工作。了解更多内容可以参考此前报道《端到端优化所有能力，字节跳动提出强化学习LLM Agent框架AGILE》。

接下来，我们看看在一天之内，都有哪些 Deep Research开源复现项目。

一、Open Deep Research

其中一个开源复现版本为「Open Deep Research」。

项目地址：https://github.com/nickscamara/open-deep-research

具体而言，Open Deep Research 是一个 AI 智能体，可以对大量的 web 数据进行推理，该方法没有使用 o3 的微调版本，而是使用了爬虫工具 Firecrawl 的提取 + 搜索功能以及推理模型来深入研究网络。

项目主页还放出了 demo 展示，我们可以发现，在询问 Open Deep Research 关于「2025 年 B2B 领域最大的创业机会」时，Open Deep Research 给出了思考过程，答案也相当完美。

，时长00:28

根据项目介绍，我们可以得知 Open Deep Research 背后默认的模型为 gpt-4o，如果你想换个其他模型使用也是可以的，只需几行代码即可切换为 Anthropic、Cohere 等发布的模型。

二、OpenDeepResearcher

另外一个比较热门的复现项目为「OpenDeepResearcher」。

项目地址：https://github.com/mshumer/OpenDeepResearcher

作为一个开源的 AI 智能体，OpenDeepResearcher 可以提供全面的研究。用户只需提供一个主题，该智能体就会展开研究，并返回一份综合报告。

其工作过程非常简单，对于给定的查询，OpenDeepResearcher 执行以下步骤：

• 执行搜索，查看结果页面，并提取重要信息；
• 如果它想深入了解，其可以重复此过程，并提出新的查询；
• 完成后，它会使用上下文生成报告。

，时长00:51

三、node-DeepResearch

最后一个复现项目是「node-DeepResearch」，它是由 Jina AI CEO 肖涵（Han Xiao）创建。

他表示，OpenAI 的 Deep Research 只是在 while 循环中进行「搜索 + 读取 + 推理」。他在 nodejs 运行环境中，使用谷歌 gemini-flash 和 jina reader（Jina AI 推出的开源工具，将互联网上的 HTML 网页内容转换为适合 LLM 处理的纯文本格式）进行了复现。

我们来看下运行效果。

下面是「jina ai 最新博客文章内容是什么」（what is the latest blog post from jina ai）的 2/3 步搜索示例：首先找到 jina ai 新闻网站、阅读其内容，然后确定最新帖子内容。

下面视频是关于「who is the biggest, cohere, jina ai, voyage」的 13 步查询，经过搜索、反馈、循环之后，结果是正确的（cohere）。这里视频 2 倍加速。

，时长00:47

对于 node-DeepResearch，显然缺少了微调 o3 推理模型的支持。

有人认为，这个项目实现了 OpenAI 准备了半年多的东西所做到的功能。还有人呼吁，赶紧把 UI 做得漂亮一点。

目前，该项目已经收获了近 700 个 Stars。

项目地址：https://github.com/jina-ai/node-DeepResearch

相信后续会有更多类似的开源智能体项目出来

#Eino

Go语言开发AI智能体有多丝滑？字节重磅开源框架，内含保姆级教程

开发基于大模型的软件应用，就像指挥一支足球队：组件是能力各异的队员，编排是灵活多变的战术，数据是流转的足球。

Eino 是字节跳动开源的大模型应用开发框架，拥有稳定的内核，灵活的扩展性，完善的工具生态，可靠且易维护，背靠豆包、抖音等应用的丰富实践经验。初次使用 Eino，就像接手一支实力雄厚的足球队，即使教练是初出茅庐的潜力新人，也可以踢出高质量、有内容的比赛。

下面就让我们一起踏上新手上路之旅！

认识队员

Eino 应用的基本构成元素是功能各异的组件，就像足球队由不同位置角色的队员组成：

这些组件抽象代表了固定的输入输出类型、Option 类型和方法签名：

type ChatModel interface {
    Generate(ctx context.Context, input []*schema.Message, opts ...Option) (*schema.Message, error)
    Stream(ctx context.Context, input []*schema.Message, opts ...Option) (
       *schema.StreamReader[*schema.Message], error)
    BindTools(tools []*schema.ToolInfo) error
}

真正的运行，需要的是具体的组件实现：

Eino 的开发过程中，首先要做的是决定 “我需要使用哪个组件抽象”，再决定 “我需要使用哪个具体组件实现”。就像足球队先决定 “我要上 1 个前锋”，再挑选 “谁来担任这个前锋”。

组件可以像使用任何的 Go interface 一样单独使用。但要想发挥 Eino 这支球队真正的威力，需要多个组件协同编排，成为一个相互联结的整体。

制定战术

在 Eino 编排场景中，每个组件成为了 “节点”（Node），节点之间 1 对 1 的流转关系成为了 “边”（Edge），N 选 1 的流转关系成为了 “分支”（Branch）。基于 Eino 开发的应用，经过对各种组件的灵活编排，就像一支足球队可以采用各种阵型，能够支持无限丰富的业务场景。

足球队的战术千变万化，但却有迹可循，有的注重控球，有的简单直接。对 Eino 而言，针对不同的业务形态，也有更合适的编排方式：

Chain，如简单的 ChatTemplate + ChatModel 的 Chain：

chain, _ := NewChain[map[string]any, *Message]().
           AppendChatTemplate(prompt).
           AppendChatModel(model).
           Compile(ctx)
chain.Invoke(ctx, map[string]any{"query": "what's your name?"})

Graph，如 ReAct Agent：

graph := NewGraph[map[string]any, *schema.Message]()


_ = graph.AddChatTemplateNode("node_template", chatTpl)
_ = graph.AddChatModelNode("node_model", chatModel)
_ = graph.AddToolsNode("node_tools", toolsNode)
_ = graph.AddLambdaNode("node_converter", takeOne)


_ = graph.AddEdge(START, "node_template")
_ = graph.AddEdge("node_template", "node_model")
_ = graph.AddBranch("node_model", branch)
_ = graph.AddEdge("node_tools", "node_converter")
_ = graph.AddEdge("node_converter", END)


compiledGraph, err := graph.Compile(ctx)
if err != nil {
    return err
}
out, err := r.Invoke(ctx, map[string]any{"query":"Beijing's weather this weekend"})

了解工具

现在想象下你接手的足球队用了一些黑科技，比如：在每个队员接球和出球的瞬间，身上的球衣可以自动的记录接球和出球的速度、角度并传递给场边的服务器，这样比赛结束后，就可以统计出每个队员触球的情况和处理球的时间。

在 Eino 中，每个组件运行的开始和结束，也可以通过 Callbacks 机制拿到输入输出及一些额外信息，处理横切面需求。比如一个简单的打日志能力：

handler := NewHandlerBuilder().
    OnStartFn(
       func (ctx context.Context, info *RunInfo, input CallbackInput) context.Context {
           log.Printf("onStart, runInfo: % v, input: % v", info, input)
           return ctx
    }).
    OnEndFn(
        func (ctx context.Context, info *RunInfo, output CallbackOutput) context.Context {
           log.Printf("onEnd, runInfo: % v, out: % v", info, output)
           return ctx
    }).
    Build()


// 注入到 graph 运行中
compiledGraph.Invoke(ctx, input, WithCallbacks(handler))

再想象一下，这个足球队的黑科技不止一种，还可以让教练在比赛前制作 “锦囊” 并藏在球衣里，当队员接球时，这个锦囊就会播放教练事先录制好的妙计，比如 “别犹豫，直接射门！”。

听上去很有趣，但有一个难点：有的锦囊是给全队所有队员的，有的锦囊是只给一类队员（比如所有前锋）的，而有的锦囊甚至是只给单个队员的。如何有效的做到锦囊妙计的分发？

在 Eino 中，类似的问题是 graph 运行过程中 call option 的分发：

// 所有节点都生效的 call option
compiledGraph.Invoke(ctx, input, WithCallbacks(handler))


// 只对特定类型节点生效的 call option
compiledGraph.Invoke(ctx, input, WithChatModelOption(model.WithTemperature(0.5)))


// 只对特定节点生效的 call option
compiledGraph.Invoke(ctx, input, WithCallbacks(handler).DesignateNode("node_1"))

发现独门秘笈

现在，想象一下你的球队里有一些明星球员（中场大脑 ChatModel 和锋线尖刀 StreamableTool）身怀绝技，他们踢出的球速度如此之快，甚至出现了残影，看上去就像是把一个完整的足球切成了很多片！

面对这样的 “流式” 足球，对手球员手足无措，不知道该如何接球，但是你的球队的所有队员，都能够完美的接球，要么直接一个片一个片的接收 “流式” 足球并第一时间处理，要么自动的把所有片拼接成完整的足球后再处理。身怀这样的独门秘笈，你的球队具备了面对其他球队的降维打击能力！

在 Eino 中，开发者只需要关注一个组件在 “真实业务场景” 中，是否可以处理流式的输入，以及是否可以生成流式的输出。根据这个真实的场景，具体的组件实现（包括 Lambda Function）就去实现符合这个流式范式的方法：

// ChatModel 实现了 Invoke（输入输出均非流）和 Stream（输入非流，输出流）两个范式
type ChatModel interface {
    Generate(ctx context.Context, input []*Message, opts ...Option) (*Message, error)
    Stream(ctx context.Context, input []*Message, opts ...Option) (
       *schema.StreamReader[*Message], error)
}


// Lambda 可以实现任意四种流式范式


// Invoke is the type of the invokable lambda function.
type Invoke[I, O, TOption any] func(ctx context.Context, input I, opts ...TOption) (
    output O, err error)


// Stream is the type of the streamable lambda function.
type Stream[I, O, TOption any] func(ctx context.Context,
    input I, opts ...TOption) (output *schema.StreamReader[O], err error)


// Collect is the type of the collectable lambda function.
type Collect[I, O, TOption any] func(ctx context.Context,
    input *schema.StreamReader[I], opts ...TOption) (output O, err error)


// Transform is the type of the transformable lambda function.
type Transform[I, O, TOption any] func(ctx context.Context,
    input *schema.StreamReader[I], opts ...TOption) (output *schema.StreamReader[O], err error)

Eino 编排能力会自动做两个重要的事情：

1. 上游是流，但是下游只能接收非流时，自动拼接（Concat）。

2. 上游是非流，但是下游只能接收流时，自动流化（T -> StreamReader [T]）。

除此之外，Eino 编排能力还会自动处理流的合并、复制等各种细节，把大模型应用的核心 —— 流处理做到了极致。

一场训练赛 -- Eino 智能助手

好了，现在你已经初步了解了 Eino 这支明星球队的主要能力，是时候通过队员 (组件)、战术 (编排)、工具 (切面、可视化) 来一场训练赛，去亲自体验一下它的强大。

场景设定

Eino 智能助手：根据用户请求，从知识库检索必要的信息并按需调用多种工具，以完成对用户的请求的处理。工具列表如下：

• DuckDuckGo：从 DuckDuckGo 搜索互联网信息
• EinoTool：获取 Eino 的工程信息，比如仓库链接、文档链接等
• GitClone：克隆指定仓库到本地
• 任务管理 (TaskManager)：添加、查看、删除 任务
• OpenURL：使用系统的默认应用打开文件、Web 等类型的链接

这里呈现一个 Demo 样例，大家可根据自己的场景，更换自己的知识库和工具，以搭建自己所需的智能助手。

先来一起看看基于 Eino 搭建起来的 Agent 助手能实现什么效果：

，时长01:36

构建这个 Eino 智能助手分两步：

• Knowledge Indexing（索引知识库）：将我们在特定领域沉淀的知识，以分词、向量化等多种手段，构建成索引，以便在接收用户请求时，索引出合适的上下文。本文采用向量化索引来构建知识库。
• Eino Agent（Eino 智能助手）：根据用户的请求信息以及我们预先构建好的可调用的工具，让 ChatModel 帮我们决策下一步应该执行什么动作或输出最终结果。Tool 的执行结果会再次输入给 ChatModel，让 ChatModel 再一次判断下一步的动作，直至完成用户的请求。

任务工作流

索引知识库 (Knowledge Indexing)

将 Markdown 格式的 Eino 用户手册，以合适的策略进行拆分和向量化，存入到 RedisSearch 的 VectorStore 中，作为 Eino 知识库。

Eino 智能体 (Eino Agent)

根据用户请求，从 Eino 知识库召回信息，采用 ChatTemplate 构建消息，请求 React Agent，视需求循环调用对应工具，直至完成处理用户的请求。

所需工具

在从零开始构建「Eino 智能助手」这个实践场景中，需要下列工具：

索引知识库

示例的仓库路径：https://github.com/cloudwego/eino-examples/tree/main/quickstart/eino_assistant

下文中，采用相对于此目录的相对路径来标识资源位置

构建一个命令行工具，递归遍历指定目录下的所有 Markdown 文件。按照标题将 Markdown 文件内容分成不同的片段，并采用火山云的豆包向量化模型逐个将文本片段进行向量化，存储到 Redis VectorStore 中。 

指令行工具目录：cmd/knowledge_indexing

Markdown 文件目录：cmd/knowledge_indexing/eino-dcos

开发「索引知识库」应用时，首先采用 Eino 框架提供的 Goland EinoDev 插件，以可视化拖拽和编排的形式构建 KnowledgeIndexing 的核心应用逻辑，生成代码到 eino_graph/knowledge_indexing 目录。

代码生成后，首先手动将该目录下的各组件的构造方法补充完整，然后在业务场景中，调用 BuildKnowledgeIndexing 方法，构建并使用 Eino Graph 实例。

接下来将逐步介绍，KnowledgeIndexing 的开发过程：

大模型资源创建

火山引擎是字节跳动的云服务平台，可从中注册和调用豆包大模型（有大量免费额度）。

• 创建 doubao-embedding-large 作为知识库构建时的向量化模型，以及创建  doubao-pro-4k 资源作为 agent 对话时的模型。
• 「火山引擎在线推理」：https://console.volcengine.com/ark

启动 Redis Stack

本文将使用 Redis 作为 Vector Database，为方便用户构建环境，Docker 的快捷指令如下：

• 在 eino-examples/quickstart/eino_assistant 提供 docker-compose.yml
• 在 eino-examples/quickstart/eino_assistant/data 目录下提供了 Redis 的初始知识库

直接用 redis 官方的 redis stack 镜像启动即可

# 切换到 eino_assistant 目录
cd xxx/eino-examples/quickstart/eino_assistant


docker-compose up -d

• 完成启动后，打开本地的 8001 可进入 redis stack 的 web 界面

在浏览器打开链接：http://127.0.0.1:8001

可视化开发

「Eino 可视化开发」是为了降低 Eino AI 应用开发的学习曲线，提升开发效率。对于熟悉 Eino 的开发者，也可选择跳过「Eino 可视化开发」阶段，直接基于 Eino 的 API 进行全码开发。

1. 安装 EinoDev 插件，并打开 Eino Workflow 功能

• Graph name: KnowledgeIndexing
• Node trigger mode: Triggered after all predecessor nodes are executed
• Input type: document.Source
• Import path of input type: github.com/cloudwego/eino/components/document
• Output type: [] string
• 其他置空

2. 按照上文「索引知识库」中的流程说明，从 Eino Workflow 中选择需要使用的组件库，本文需要用到如下组件： 

• document/loader/file —— 从指定 URI 加载文件，解析成文本内容，以 schema.Document 列表形式返回。
• document/transformer/splitter/markdown —— 将从 FileLoader 中加载到的文本内容，进一步拆分成合适的大小，以平衡向量化计算 / 存储的尺寸限制和召回的效果。
• indexer/redis —— 将 schema.Document 的原文、索引字段 存储在 Redis Vector Database 中
• embedding/ark —— 采用 Ark 平台的向量化模型，对 schema.Document 中的 Content 等内容进行向量化计算

3. 将选中的组件按照预期的拓扑结构进行编排，完成编排后，点击 “生成代码” 到指定目录。

• 「索引知识库」的代码生成到：eino_assistant/eino/knowledgeindexing
• 本示例可直接复制 eino/knowledge_indexing.json 中的 Graph Schema，来快速构建示例中的图

4. 按需完善各个组件的构造函数，在构造函数中补充创建组件实例时，需要的配置内容

5. 补充好组件的配置内容后，即可调用 BuildKnowledgeIndexing 方法，在业务场景使用

完善代码

• 通过可视化开发，生成的 Eino 编排代码，无法保证可直接使用，需要人工阅读和检查下代码的完整性
• 生成核心函数是 BuildKnowledgeIndexing ()，用户可在需要的地方调用此方法，创建实例进行使用

在「索引知识库」的场景下，需要将 BuildKnowledgeIndexing 封装成一个指令，从环境变量中读取模型配置等信息，初始化 BuildKnowledgeIndexing 的配置内容，扫描指定目录下的 Markdown 文件，执行对 Markdown 进行索引和存储的操作。

详细代码可查看：cmd/knowledgeindexing/main.go

运行

PS: 示例项目中，已经内置了 eino 的一部分文档向量化到 redis 中

1. 在 .env 文件中按照注释说明，获取并填写 ARK_EMBEDDING_MODEL 和 ARK_API_KEY 的值，按如下指令，运行 KnowledgeIndexing 指令

cd xxx/eino-examples/quickstart/eino_assistant # 进入 eino assistant 的 example 中


# 修改 .env 中所需的环境变量 (大模型信息、trace 平台信息)
source .env


# 因示例的Markdown文件存放在 cmd/knowledgeindexing/eino-docs 目录，代码中指定了相对路径 eino-docs，所以需在 cmd/knowledgeindexing 运行指令
cd cmd/knowledgeindexing
go run main.go

2. 执行运行成功后，即完成 Eino 知识库的构建，可在 Redis Web UI 中看到向量化之后的内容

在浏览器打开链接：http://127.0.0.1:8001

Eino 智能体

示例的仓库路径：https://github.com/cloudwego/eino-examples/tree/main/quickstart/eino_assistant

下文中，采用相对于此目录的相对路径来标识资源位置

构建一个基于从 Redis VectorStore 中召回的 Eino 知识回答用户问题，帮用户执行某些操作的 ReAct Agent，即典型的 RAG ReAct Agent。可根据对话上下文，自动帮用户记录任务、Clone 仓库，打开链接等。 

大模型资源创建

继续使用「索引知识库」章节中创建的 doubao-embedding-large 和 doubao-pro-4k

启动 RedisSearch

继续使用「索引知识库」章节中启动的 Redis Stack

可视化开发

，时长03:30

1. 打开 EinoDev 插件，进入到 Eino Workflow 页面，新建一张画布

• Graph Name: EinoAgent
• Node Trigger Mode: Triggered after all predecessor nodes are executed
• Input Type Name: *UserMessage
• Input Package Path: ""
• Output Type Name: *schema.Message
• Output Import Path: github.com/cloudwego/eino/schema
• 其他置空

2. 按照上文「Eino 智能体」中的流程说明，从 Eino Workflow 中选择需要使用的组件库，本文需要用到如下组件：

• lambda: 将开发者任意的函数 func (ctx context.Context, input I) (output O, err error)，转换成可被编排的节点，在 EinoAgent 中，有两个转换场景：

（1）将 *UserMessage 消息转换成 ChatTemplate 节点的 map [string] any

（2）将 *UserMessage 转换成 RedisRetriever 的输入 query

• retriever/redis —— 根据用户 Query 从 Redis Vector Database 根据语义相关性，召回和 Query 相关的上下文，以 schema.Document List 的形式返回。
• prompt/chatTemplate —— 通过字符串字面量构建 Prompt 模板，支持 文本替换符 和 消息替换符，将输入的任意 map [string] any，转换成可直接输入给模型的 Message List。
• flow/agent/react —— 基于开发者提供的 ChatModel 和 可调用的工具集，针对用户的问题，自动决策下一步的 Action，直至能够产生最终的回答。 
• model/ark —— Ark 平台提供的能够进行对话文本补全的大模型，例如豆包模型。作为 ReAct Agent 的依赖注入。
• 可调用的工具列表——互联网搜索工具 (DuckDuckGo)、EinoTool、GitClone、任务管理 (TaskManager)、 OpenURL

3. 将选中的组件按照预期的拓扑结构进行编排，完成编排后，点击 “生成代码” 到指定目录。

• 本示例中，「Eino 智能体」的代码生成到：eino/einoagent

• 本示例可直接复制 eino/eino_agent.json 中的 Graph Schema，来快速构建示例中的图

4. 按需完善各个组件的构造函数，在构造函数中补充创建组件实例时，需要的配置内容

5. 补充好组件的配置内容后，即可调用 BuildEinoAgent 方法，在业务场景使用

完善代码

在「Eino 智能体」的场景下，BuildEinoAgent 构建的 Graph 实例可做到：根据用户请求和对话历史，从 Eino 知识库中召回上下文， 然后结合可调用的工具列表，将 ChatModel 循环决策下一步是调用工具或输出最终结果。 

下图即是对生成的 BuildEinoAgent 函数的应用，将 Eino Agent 封装成 HTTP 服务接口：

运行

1. 在 .env 文件中按照注释说明，获取并填写对应各变量的值，按如下指令，启动 Eino Agent Server

cd eino-examples/eino_assistant # 进入 eino assistant 的 example 中


# 修改 .env 中所需的环境变量 (大模型信息、trace 平台信息)
source .env


# 为了使用 data 目录，需要在 eino_assistant 目录下执行指令
go run cmd/einoagent/*.go

2. 启动后可访问如下链接，打开 Eino Agent Web

Eino Agent Web：http://127.0.0.1:8080/agent/

观测 (可选)

如果在运行时，在 .env 文件中指定了 LANGFUSE_PUBLIC_KEY 和 LANGFUSE_SECRET_KEY，便可在 Langfuse 平台中，登录对应的账号，查看请求的 Trace 详情。

相关链接：

项目地址：https://github.com/cloudwego/eino，https://github.com/cloudwego/eino-ext

Eino 用户手册：https://www.cloudwego.io/zh/docs/eino/

项目官网：https://www.cloudwego.i

#人形机器人Figure宣布与OpenAI终止合作

今天凌晨 3 点半，AI 机器人公司 Figure 创始人兼 CEO Brett Adcock 的一条推文让整个 AI 社区都大呼意外。他宣布终止与 OpenAI 的合作协议，并表示 Figure 在完全自主研发的端到端机器人 AI 方面取得了重大突破，还承诺「将在未来 30 天内展示一些人们从未在人形机器人上见过的东西」。

实际上，这两家备受关注的公司开启合作还不到一年时间。去年 2 月 29 日，Figure 宣布完成了惊人的 6.75 亿美元 B 轮融资，公司估值达到 26 亿美元。投资方包括微软、英特尔、OpenAI Startup Fund、Amazon Industrial Innovation Fund 、英伟达等。与此同时，Figure 还宣布与 OpenAI 建立合作伙伴关系，包括 OpenAI 为 Figure 的人形机器人构建专门的 AI 模型，使其机器人能够处理和推理语言。

之后不久，他们还发布了一个视频，演示了 Figure 01 机器人可以借助 OpenAI 的技术与人类进行全面对话。

，时长02:34

到 8 月份，这两家公司还宣布新一代的 Figure 02 人形机器人会使用 OpenAI 的模型来进行自然语言交流。

看起来，这两家公司似乎进入了长久的蜜月期 —— 一家做 AI，一家做机器人，也像是天作之合，加上 OpenAI 本身还是 Figure 的投资者，所以似乎谁也没能预料到，这两家公司的合作关系竟会结束得如此之快。

但或许，OpenAI 上个月宣布重新组建自己的机器人团队时，就已经在暗示这方面的信号了？更多详情可参阅报道《OpenAI 被曝重组机器人团队，4 年前缺钱缺数据，如今要做硬件布局了》。此外，OpenAI 还在 1 月 31 号商标申请中包含了「用户可编程的人形机器人」和「用于辅助和娱乐的具有通信和学习功能的人形机器人」。

考虑到 Brett Adcock 就在上述推文下面发布了一条 AI 团队招聘推文，这种猜测似乎也不是完全没有道理。

不知道另一家与 OpenAI 有合作关系的人形机器人公司 1X 会作何反应。

1X 的 Neo Beta 人形机器人

Figure 与 OpenAI 分手的推文发布后吸引了众多讨论。有人乐见 Figure 的自信，并表示很期待看到该公司承诺的东西。

当然也自然有人表示担忧。

还有些人试图分析这一高调分手背后的技术原因。

近期最热门的话题「DeepSeek」同样也在评论区大有存在感。

据 TechCrunch 报道，Adcock 表示 Figure 与 OpenAI 合作的问题在于 integration（集成 / 整合）。「OpenAI 是一家拥有广泛业务的大公司，并且拥有与之相匹配的智能模型。将人工智能带入机器人等物理事物的具身 AI 并非这家 ChatGPT 开发商的主要关注点。」Adcock 表示，正确的解决方案是构建专用于驱动具体硬件的端到端 AI 模型。

他说：「我们发现，要在现实世界中大规模解决具身 AI，你必须垂直地整合机器人 AI。我们不能将 AI 外包出去，就像我们不能将硬件外包出去一样。」

目前 OpenAI 还未就此事置评，只是默默进行了一次品牌更新。

有关这突然的合作终止的具体详情还有待进一步揭示。你觉得 Figure 与 OpenAI 合作关系终结的原因可能是什么呢？

参考链接

​​https://x.com/adcock_brett/status/1886860098980733197​​

​​https://techcrunch.com/2025/02/04/figure-drops-openai-in-favor-of-in-house-models/​​

#o3-mini

谢谢Deepseek，o3-mini发布即免费！编程断崖式领先？

免费用户也可以使用。

只需要在消息编辑器中选择“Reason”就可以调用 o3-mini 了。

这是 ChatGPT 首次向免费用户提供推理模型。

对此，我只能用以下表情包评价此事件——

具体来说：

• Plus 和 Team 用户：每天 150 次对话限制（ 原 o1-mini 每天 50 条消息）；
• Pro 用户：可以无限制地访问（当然，实际别太认真，真用多了大概率会跟此前 o1 一样降智）；
• Enterprise 用户：将于 2 月推出；
• API：向 3-5 级开发者开放，提供了三种选择版本，low、medium、high ，根据开发需求在效果（推理时间）和速度（延迟）之间平衡，灵活选择。

发布后，原 o1-mini 位置被 o3-mini 替代，付费用户还能选择更智能的 o3-mini-high。

o3-mini 不止是在网页客户端免费开放，其商用 API 价格也相比 o1 迎来断崖式下跌——

o3-mini 相比 o1：

• 更快：延迟更低，响应更快。在 A/B 测试中，o3-mini 的响应速度比 o1-mini 快 24%，平均响应时间为 7.7 秒，而 o1-mini 为 10.16 秒。
• 更强：答案更准确、幻觉更少、推理更强。尤其是编程能力，详情见《​​o3 发布了，摔碎了码农的饭碗​​》。
• 更便宜：比 o1 便宜 93%。

可以通过下面这张 LiveBench 测试基准直观的感受 o3-mini 在推理、编程、数学上面的表现，尤其是 Coding 这一列，编程能力断崖式的碾压了 o1、deepseek r1 和 gemini 系列模型：

人类最后一次考试（Humanity’s Last Exam）则是由数百位人类领域专家开发的一个榜单，号称是捍卫人类智慧的最后一站。在此之前，所有顶尖 AI 通过率都不超过 10%，这次 O3-mini 首次打破记录。

我观测到一个很有意思的现象。

以前 OpenAI 发布新模型的时候，外网网友一般都会拿新模型与 OpenAI 的老模型，Claude 模型，最多再加上 Gemini 模型做比较。

但这次，我发现外国网友甚至都很少拿 o3-mini 与 o1 去对比，反而大家齐刷刷的拿 o3-mini 与 DeepSeek R1 在做横向对比。

比如，有国外网友从性价比层面点评 o3-mini——

虽然 o3-mini 更好，但 DeepSeek R1 相似却更便宜，“DeepSeek 时刻”值得被人们铭记，成为科技领域关键历史事件

还有网友横向对比了 o3-mini 的思维链与 DeepSeek R1 的思维链——

o3-mini 的思维链与 R1 相比，更加冰冷、客观；R1 更接近我内心的思考过程

放大图片，感受一下——

而在横向的 case 表现上，大家更是齐刷刷的将 o3-mini 与 DeepSeek R1 进行 PK。​

模拟物理世界

由于 o3-mini 相比较前一代模型，最大的提升就在于编程能力了。

所以网友的实测 case 大部分都是跟编程相关的，尤其是一些通过视觉效果就能直观的感受到代码写的好坏的 case。例如下面这个——

提示词：“编写一个在 tesseract 内弹跳的球的 python 脚本”

先看下o3-mini 写的代码的运行效果：

​，时长00:13

然后是DeepSeek R1 所写代码的演示效果：

​，时长00:12

模拟物理世界的简单版本

如果说上一个题目比较抽象，这个题目就能比较直观的感受效果了。

提示词：write a Python program that shows a ball bouncing inside a spinning hexagon. The ball should be affected by gravity and friction, and it must bounce off the rotating walls realistically

中文提示词：编写一个 Python 程序，显示球在旋转的六边形内弹跳。球应该受到重力和摩擦力的影响，并且必须逼真地从旋转的墙壁上反弹”

分析：这题左边 o3-mini 明显要好于右边的 DeepSeek R1，R1 没有考虑重力影响

​，时长00:21

当然，也有反例，比如有国外网友跑出了一个 DeepSeek R1 表现更好的例子——

提示：“编写一个 Python 脚本，每 5 秒在一个正方形内出现一个不同颜色的新弹跳球，请确保正确处理碰撞检测。使正方形缓慢旋转。在 Python 中实现它。确保球保持在正方形内”

网友说必须明确提示 O1-Mini-high 才能获得弹跳球效果......DeepSeek-R1 在第一次就实现了，没有任何明确的提示。

o3-mini-high：

​，时长00:30

deepseek-r1 ：

​，时长00:30

从上面对比视频看，这题 deepseek-r1 的效果更好，因为它模拟了两个小球发生碰撞时弹开的物理情况，而 o3 则没有处理这种情况。

除了上面的编程能力 PK 外，我还见到一个很棒的示例。​

8 秒写一个 Twitter 网站

原贴链接：

​​https://x.com/​​aidan_clark/status/1885408020529545621

网友要求用一个 python 脚本制作一个克隆版的推特网站，O3-mini 花了 8 秒写出了这个网站。提示词也出奇的简单——

运行一下 o3-mini 写的代码，看下这个网站——

​，时长00:37

好家伙，注册/登陆、发推、点赞、转推功能都齐全了。这效果，至少够熟练的人类程序员写一下午了，加上与产品经理的沟通拉扯，可能都要一天起步。而 o3-mini 只用了 8 秒。

此外，还有网友提到，o3-mini 能做到 o1 pro 都做不到的事情，比如一个混合了艺术、科学和编程的复杂任务——

贴一下这个着色器的视频，感受一下——

​，时长00:02

除了网友晒出的编程 case 外，我也运行了几个大型项目中遇到的困难编程问题，其中不乏难倒了 o1 在内所有推理模型的问题。但由于比较敏感，这里没法直接贴出来测试题目。

不过，可以分享一下结论性的体感表现——对于我手上那些上一代推理模型全军覆没的编程问题，o3-mini 解掉了约 50% 的题目。o3-mini 在编程方面的提升，确实能在体感上强烈感知到。​

Agent 应用开发的核心模型？

大家经常说，2025 年是 Agent 元年（虽然 2024 年的时候也这样说）。

而我们知道，对于 Agent 来说，思考、记忆和执行是其中要解决的三大关键问题。对于执行层面来说，老一代的模型如 Gemini 2.0、DeepSeek v3 等已经做的不错了，记忆和思考其实仍有很长的路要走。

而在思考方面，o1 虽然有了很大的提升，但这高昂的推理成本，使其难以在 Agent 应用上大范围使用。

而 o3-mini 发布后，就有开发者发现——

o3-mini 完全可以替换掉 o1，便宜 9 倍，快 4 倍，部分任务上效果还更好。

有了 o3-mini，我觉得 2025 年 Agent 应用爆发，可能真的不再只是喊喊口号而已了。​

安全评估

与此同时，OpenAI 也放出了关于 o3-mini 的安全评估报告"OpenAI o3-mini System Card". 有网友整理了这里面的一些关键信息。

例如，o3-mini 的幻觉相比 4o 和上一代 o1-mini 模型大大减少——

在一些看似危险实则一点也不安全的问题上，如“如何杀死 python 进程”，老的模型经常会拒绝回答，o3-mini 则不会过度阻止了——

而我们常用的一些让 AI 模型越狱的手段，也更难攻破 o3-mini 了——

不过，看起来针对 System message 字段的攻击，o3-mini 相比 o1 反而更糟了（0.95=>0.88）​

结语

或许，真正的挑战并非单纯的技术超越，而是在这个变革的时代，如何用创新和责任构建出人类和智能的和谐共生。

未来的路依然漫长，但这一次，o3-mini与DeepSeek R1无疑为我们确认了一个方向——

智能不应只是少数人的特权，而是每个人都能触及的力量。

参考文献

1.https://x.com/Yuchenj_UW/status/1885416559029740007 2.https://x.com/flavioAd/status/1885449107436679394
3.https://x.com/omarsar0/status/1885459248060260860
4.https://x.com/aidan_clark/status/1885408020529545621
5.https://x.com/emollick/status/1885412470061158650
6.https://openai.com/index/openai-o3-mini/

#揭穿围绕DeepSeek的谣言

自有歪果仁为DeepSeek「辩经」

围绕 DeepSeek 的谣言实在太多了。

面对 DeepSeek R1 这个似乎「一夜之间」出现的先进大模型，全世界已经陷入了没日没夜的大讨论。从它的模型能力是否真的先进，到是不是真的只用了 550W 进行训练，再到神秘的研究团队，每个角度都是话题。

虽然 R1 是开源的，围绕 DeepSeek 的各种夸张猜测还是层出不穷，有人说训练 R1 实际上使用的算力远超论文所说的，有人质疑 R1 的技术创新，甚至还有人说 DeepSeek 实际的目标是做空……

近日，知名生成式 AI 创业公司 Stability AI 的前研究主管 Tanishq Abraham 终于坐不住了，他撰文揭穿了围绕 DeepSeek 的一系列谬论。

行文直接了当，让人很快就可以了解实际情况。让我们看看海外一线 AI 研究者是怎么说的。

今年 1 月 20 日，DeepSeek 开源的强推理模型 R1 震撼了世人，与其他所有开源大语言模型（LLM）相比，该模型的不同之处在于以下几点：

1. 性能实际上与 OpenAI 的 o1 一样好，这是一个先进的模型，标志着开源首次真正赶上闭源；
2. 与其他先进模型相比，R1 是在相对较低的训练预算下完成的；
3. 易于使用的用户界面，加上其网站和应用程序中具有可见思路链的良好用户体验，吸引了数百万新用户。

鉴于 DeepSeek（深度求索）是一家中国公司，美国及其一众科技公司纷纷指责新模型存在各种「国家安全问题」。因此，有关该模型的错误信息泛滥成灾。这篇博文的目的是反驳自 DeepSeek 发布以来许多与人工智能相关的极其糟糕的评论，并以一名工作在生成式人工智能前沿的 AI 研究人员的身份提供客观的看法。

让我们开始吧！

误解 1：DeepSeek 是一家突然冒出来的中国公司

完全错误，到 2025 年 1 月，全球几乎所有生成式 AI 研究人员都听说过 DeepSeek。DeepSeek 甚至在 R1 全面发布前几个月就已经预告了发布！

传播这种误解的人很可能不是从事人工智能工作的人，如果你不积极参与某个领域，就认为你对这个领域正在发生的事情了如指掌，这是荒谬且极其傲慢的。

DeepSeek 的第一个开源模型于 2023 年 11 月发布，它们是最先进的代码 LLM（DeepSeek-Coder）。如下图所示，DeepSeek 在一年的时间里持续发布新产品，R1 只是其中的一个：

DeepSeek 的模型进展。

罗马不是一天建成的，从 AI 创业公司的角度来看 DeepSeek 的进步速度也没有什么可疑的。人工智能领域一切都发展得如此之快，而且他们拥有一支显然很出色的团队，一年内取得如此大的进步在我看来是合理的。

如果你想知道还有哪些团队不为公众所知，但在人工智能圈却备受看好，这里面可以包括 Qwen（阿里巴巴）、YI（零一万物）、Mistral、Cohere 和 AI2。我要指出的是，它们都没有像 DeepSeek 那样持续推出 SOTA 模型，但它们都有潜力发布一流的模型，正如它们过去所展示的那样。

误解 2：训练模型不可能只花费 600 万美元，DeepSeek 在撒谎

这个说法很有意思。有人声称 DeepSeek 在撒谎，隐瞒了真实的训练成本，以此掩盖他们通过非法途径获取了由于出口管制本不该获得的算力。

首先，我们要理解这 600 万美元的数字从何而来。这个数字最早出现在 DeepSeek-V3 的论文中，该论文比 DeepSeek-R1 的论文早一个月发布:

DeepSeek-V3 的技术报告，发布于 2024 年 12 月 27 日

DeepSeek-V3 是 DeepSeek-R1 的基础模型，这意味着 DeepSeek-R1 就是在 DeepSeek-V3 的基础上增加了一些强化学习训练。从这个角度来说，这个成本确实不够准确，因为还未计入强化学习训练的额外成本。不过，强化学习训练的成本可能也就几十万美元。

那么，DeepSeek-V3 论文中提到的这个 550 万美元是否准确呢？根据 GPU 成本、数据集规模和模型规模的多项分析都得出了类似的估算结果。值得注意的是，虽然 DeepSeek V3/R1 是一个拥有 6710 亿参数的模型，但它采用了混合专家系统 (MoE) 架构，这意味着每次函数调用 / 前向传播只会用到约 370 亿参数，训练成本的计算也基于这个数值。

DeepSeek 报告的是基于当前市场 GPU 价格的估算成本。英伟达 AI 计算卡的价格并不固定，我们并不知道他们的 2048 块 H800 GPU 集群 (不是 H100！) 的实际成本。通常情况下，整体购买 GPU 集群会比零散购买便宜，所以实际的算力成本可能更低。

关键在于，这只是最终训练运行的成本，还有许多小规模的实验和消融实验，这也是一笔开销，但往往不会被计算在训练成本内。

此外，还有研究人员的薪资等其他成本。据 SemiAnalysis 报道，DeepSeek 的研究人员年薪据传高达 100 万美元，这与 OpenAI 或 Anthropic 等顶尖 AI 实验室的高薪资水平相当。

在比较不同模型的训练成本时，人们通常只关注最终训练运行的成本。但由于不实信息的传播，有人开始用这些额外的成本来质疑 DeepSeek 的低成本和运营效率。这种比较是极不公平的。其他 AI 前沿实验室在消融实验等各种实验和研究人员薪资方面的额外支出同样巨大，但在这些讨论中往往不会被提及！

误解 3：价格太便宜了，所有美国 AGI 公司都在浪费钱，这对英伟达来说极为不利

这又是一个相当愚蠢的观点。DeepSeek 在训练效率上确实比许多其他 LLM 要高得多。不仅如此，可能许多美国的前沿实验室在计算资源的使用上效率都不高。然而，这并不意味着拥有更多的计算资源是一件坏事。

最近，这样的观点比较盛行，这种观点可归因于他们并不理解扩展率（scaling laws），也不理解 AGI 公司 CEO 的思维方式（任何被视为 AI 专家的人都应该理解这些）。

最近几年 AI 领域的 Scaling Laws 已经证明了，只要我们持续向模型中投入更多的计算资源，性能就会不断提升。当然，随着时间推移，扩展的具体方法和侧重点也在变化：最初是模型规模，然后是数据集规模，现在是推理时的计算资源和合成数据。尽管如此，自 2017 年 Transformer 架构问世以来，「更多计算资源 = 更好性能」的总体趋势似乎一直成立。

更高效的模型意味着在给定的计算预算下，你可以榨取更多的性能，但更多的计算资源仍然会带来更好的结果。更高效的模型意味着你可以用更少的计算资源做更多的事情，但如果有更多的计算资源，你还能做得更多！

现在，你可能对扩展律有自己的看法。你可能认为即将出现一个瓶颈期，也可能像金融领域常说的那样，过去的性能并不代表未来的结果。但如果你想要理解最大的 AGI 公司正在做出的举措，这些看法其实并不重要。所有最大的 AGI 公司都在押注扩展律能够持续足够长的时间，以便实现 AGI 和 ASI。这是他们坚定的信念。如果他们深信不疑，那么唯一合理的举措就是获取更多的计算资源。

你可能会说英伟达的 GPU 很快就会过时，看看 AMD、Cerebras、Graphcore、TPU、Trainium 等等新产品的性能。市面上有数不清的 AI 专用硬件都在与英伟达竞争。未来可能会有一家公司胜出。到那时，AI 公司可能会转向使用它们的产品。但这都与 DeepSeek 的成功完全无关。

（凭心而论，考虑到英伟达目前的市场主导地位和持续创新的能力，我还没有看到其他公司能够撼动英伟达在 AI 加速芯片领域霸主地位的有力证据。)

总的来说，我认为没有理由因为 DeepSeek 而不看好英伟达，用 DeepSeek 来论证这一点似乎并不恰当。

误解 4：DeepSeek 没有任何有意义的创新，只是在抄袭美国公司

错误。在语言模型的设计及其训练方式上，DeepSeek 有许多创新之处，其中一些创新比其他更为重要。以下列举了部分（并非详尽列表，详情请参阅 DeepSeek-V3 和 DeepSeek-R1 论文）：

1. Multi-latent 注意力（MHA）—— 通常情况下，LLM 是基于多头注意力机制（MHA）的 Transformer 架构。DeepSeek 团队开发了一种 MHA 机制的变体，这种变体不仅更加节省内存，而且性能表现也更为出色。

2. GRPO 与可验证奖励。自从 o1 发布以来，AI 社区一直在尝试复现其效果。由于 OpenAI 对其工作原理保持高度封闭，社区不得不探索各种不同的方法以实现类似 o1 的结果。有许多研究方向，例如蒙特卡洛树搜索（Google DeepMind 在围棋中获胜所使用的方法），但这些方法最终被证明不如最初预期的那么有前景。另一方面，DeepSeek 展示了一个非常简单的强化学习（RL）流程实际上可以实现类似 o1 的结果。更重要的是，他们开发了自己版本的 PPO RL 算法，称为 GRPO，这种算法更高效且性能更优。AI 社区的许多人都在思考，为什么我们之前没有尝试过这种方法呢？

3. DualPipe—— 在多 GPU 上训练 AI 模型时，需要考虑效率问题。你需要确定模型和数据集如何在所有 GPU 之间分配，数据如何在 GPU 之间流动等。还需要尽量减少 GPU 之间的数据传输，因为这种传输速度很慢，最好尽可能在每个单独的 GPU 上进行处理。总之，设置这种多 GPU 训练的方式有很多种，DeepSeek 团队设计了一种名为 DualPipe 的新方法，这种方法更加高效且速度更快

非常幸运的是，DeepSeek 完全开源并详细记录了这些创新，这与美国的 AGI 公司不同。现在，每个人都可以利用这些进步来受益并改进自己的 AI 模型训练。

误解 5：DeepSeek 正在从 ChatGPT 吸取知识

OpenAI 曾经声称，DeepSeek 通过一种称为蒸馏的技术从 ChatGPT 中吸取知识。但在这里，蒸馏一词的使用显得有些奇怪。通常情况下，蒸馏指的是基于所有可能的下一个词（token）的完整概率（logits）进行训练，但 ChatGPT 甚至没有公开这些信息。

OpenAI 及其员工声称 DeepSeek 使用 ChatGPT 生成的文本对其进行训练。但他们没有提供任何证据，如果这是真的，那么 DeepSeek 显然违反了 ChatGPT 服务条款。不过我们对这一行为的法律后果尚不清楚。

需要注意的是，这仅在 DeepSeek 自己生成用于训练的数据时才成立。如果 DeepSeek 使用了来自其他来源的数据（目前有许多公开的数据集），这种形式的蒸馏或合成数据训练并不违反服务条款（TOS）。

尽管如此，这并不会减损 DeepSeek 的成就。对于研究人员来说，DeepSeek 更令人印象深刻的不是其效率方面，而是他们对 o1 的复现。此外，有研究者高度怀疑对 ChatGPT 进行蒸馏是否会有帮助，因为 o1 的 CoT（Chain-of-Thought）思维过程从未公开披露，那么 DeepSeek 是如何能够学习到它的呢？

此外，许多 LLM 确实在 ChatGPT（以及其他 LLM）生成的合成数据上进行训练，而且在任何新的互联网上抓取的数据中自然也会包含 AI 生成的文本。

总的来说，对于 DeepSeek 的模型表现优异仅仅是因为它蒸馏了 ChatGPT 的这一观点，确实忽略了 DeepSeek 在工程、效率和架构创新方面的实际成果，这些都在 DeepSeek 的技术报告中有详细说明。

我们应该担心中国在 AI 领域的领先地位吗？

或许有一点吧？

老实说，过去两个月里，中美在 AI 领域的竞争态势并没有太大变化。反倒是外界的反应相当激烈。中国在 AI 领域一直很有竞争力，但 DeepSeek 的出现让中国变得不容忽视。

关于开源，常见的观点是：既然中国 AI 比较落后，美国就不该公开分享技术，以免他们迎头赶上。

但显然，中国已经赶上来了，而且实际上他们早就做到了，甚至在开源领域处于领先地位。因此，封闭我们的技术是否真的能带来显著优势，这一点尚不明确。

值得注意的是，像 OpenAI、Anthropic 和 Google DeepMind 这样的公司，其模型确实比 DeepSeek R1 更强大。例如，OpenAI 的 o3 模型在基准测试中的表现非常出色，而且他们很可能已经在开发下一代模型了。此外，随着「星门计划」等大规模投资的推进，以及 OpenAI 即将完成的融资，美国的前沿 AI 实验室将有足够的计算资源来保持领先。

当然，中国也会在 AI 开发上投入大量资金。总体来看，竞争正在加剧！但我认为，美国的通用人工智能（AGI）前沿实验室继续保持领先的前景依然十分光明。

结论

一方面，部分人工智能从业者（尤其是 OpenAI 员工）正试图刻意淡化 DeepSeek 的成就；另一方面，某些专家和自封权威人士对 DeepSeek 的反应又显得过度夸张。需要明确的是：OpenAI、Anthropic、Meta、Google、xAI、英伟达等公司的发展远未终结；DeepSeek 对其成果的描述（很可能）并无虚假。

但必须承认，DeepSeek 值得获得应有认可，其推出的 R1 模型确实令人印象深刻。

原文链接：

​​https://www.tanishq.ai/blog/posts/deepseek-delusions.html​​

#OmniHuman

AI「视觉图灵」时代来了！字节OmniHuman，一张图配上音频，就能直接生成视频

还记得半年前在 X 上引起热议的肖像音频驱动技术 Loopy 吗？升级版技术方案来了，字节跳动数字人团队推出了新的多模态数字人方案 OmniHuman, 其可以对任意尺寸和人物占比的单张图片结合一段输入的音频进行视频生成，生成的人物视频效果生动，具有非常高的自然度。

如对下面图片和音频：

audio,机器之心,23秒

OmniHuman 生成的人物可以在视频中自然运动：

，时长00:23

从项目主页上可以看到 OmniHuman 对肖像、半身以及全身这些不同人物占比、不同图片尺寸的输入都可以通过单个模型进行支持，人物可以在视频中生成和音频匹配的动作，包括演讲、唱歌、乐器演奏以及移动。对于人物视频生成中常见的手势崩坏，也相比现有的方法有显著的改善。

，时长00:16

，时长00:20

作者也展示模型对非真人图片输入的支持，可以看到对动漫、3D 卡通的支持也很不错，能保持特定风格原有的运动模式。据悉，该技术方案已落地即梦 AI，相关功能将于近期开启测试。

，时长00:08

，时长00:11

，时长00:14

更多细节和展示效果，请查看：

• 论文项目主页：https://omnihuman-lab.github.io/
• 技术报告：https://arxiv.org/abs/2502.01061

研究问题

基于扩散 Transformer（DiT）的视频生成模型通过海量视频 - 文本数据训练，已能输出逼真的通用视频内容。其核心优势在于从大规模数据中学习到的强大通用知识，使模型在推理时展现出优异的泛化能力。在细分的人像动画领域，现有技术主要聚焦两类任务：音频驱动的面部生成（如语音口型同步）和姿势驱动的身体运动合成（如舞蹈动作生成）。2023 年后端到端训练方案的突破，使得现有技术方案通常能够对具有固定尺寸和人像比例的输入图像生成动画，实现精准的口型同步与微表情捕捉。

然而，技术瓶颈日益凸显：当前模型依赖高度过滤的训练数据（如固定构图、纯语音片段），虽保障了训练稳定性，却引发 "温室效应"— 模型仅在受限场景（如固定构图、真人形象）中表现良好，难以适应不同画面比例、多样化风格等复杂输入。更严重的是，现有数据清洗机制在排除干扰因素时，往往也丢失了大量有价值的数据，导致生成效果自然度低、质量差。

这种困境导致技术路线陷入两难：直接扩大数据规模会因训练目标模糊（如音频信号与肢体运动的弱相关性）导致模型性能下降；而维持严格筛选策略又难以突破场景限制。如何既能保留有效运动模式学习，又能从大数据规模学习中受益成为当前研究重点。

技术方案

据技术报告，OmniHuman，面向端到端人像驱动任务中高质量数据稀缺的问题，采用了一种 Omni-Conditions Training 的混合多模态训练策略，并相应的设计了一个 OmniHuman 模型，通过这种混合多模态训练的设计，可以将多种模态的数据一起加入模型进行训练，从而大幅度的增加了人像驱动模型的可训练数据，使得模型可以从大规模数据中受益，对各种类似的输入形式有了比较好的支持。

Omni-Conditions Training. 在模型训练过程中，作者将多种模态按照和运动的相关性进行区分，依序进行混合条件训练。这个多模态训练遵循两个原则：

原则 1: 较强条件的任务可以利用较弱条件的任务及其数据来扩展训练数据规模。例如，由于口型同步准确性、姿态可见性和稳定性等过滤标准，音频和姿态条件任务中排除的数据可以用于文本和图像条件任务。因此，在早期阶段舍弃音频和姿态条件，在后期逐步加入。

原则 2: 条件越强，训练比例应越低。较强的运动相关条件（如姿态）由于歧义较少，训练效果通常优于较弱的条件（如音频）。当两种条件同时存在时，模型倾向于依赖较强条件进行运动生成，导致较弱条件无法有效学习。因此，需要确保较弱条件的训练比例高于较强条件。

基于以上原则设计他们构建了多个阶段的训练过程，依次增加文本、图像、音频以及姿态模态参与模型训练，并降低对应的训练占比。

OmniHuman 技术框架图

Omni-Conditions Model. 除了 Omni-Conditions Training 训练策略以外，OmniHuman 采用了基于 DiT 架构的视频生成框架，使得模型兼容多种模态的条件注入方式，包括文本、图像、音频和姿态，多模态的条件被区分为两类：驱动条件和外观条件。

对于驱动条件，作者对音频特征通过 cross attention 实现条件注入，对于姿态特征通过 Heatmap 特征编码后和 Noise 特征进行拼接实现条件注入，对于文本特征，则保持了 MMDiT 的条件注入方式。

对于外观条件，作者没有像现有工作一样采用一个单独的参考图网络 (Reference Net)，而是直接利用去噪声网络 (Denoising Net) 对输入图像进行特征编码，复用了 backbone 的特征提取方式，参考图特征会和 Noise 特征进行拼接实现条件注入

效果对比

作者给出了和目前行业领先的方案的效果对比，通过单个模型同时对比了针对不同人物占比的专有模型，仍然可以取得显著的整体效果优势。

除了数值分析以外，作者也分析基于 Omni-Conditions Training 可以改善在人体手势生成、多样性输入图像上的视频生成效果，并展示了混合多模态训练可以使得单个模型同时兼容多种模态驱动，生成可控的生动人像视频的例子。

结论

OmniHuman 是一个端到端的多模态条件人像视频生成框架，能够基于单张图像和运动信号（如音频、视频或两者）生成人像动画视频。它提出了一个多模态混合训练的技术方案，并调研了具体的训练策略，设计了相应的多模态混合控制的人像视频生成模型，从而克服了以往方法面临的高质量数据稀缺问题，从大规模数据训练中受益，学习自然的运动模式。OmniHuman 显著优于现有方法，能够从弱信号（尤其是音频）生成生动的人类视频。它支持任意纵横比的图像（如肖像、半身或全身），在各种场景下提供生动、高质量的结果。

团队介绍

字节跳动智能创作数字人团队，智能创作是字节跳动 AI & 多媒体技术中台，通过建设领先的计算机视觉、音视频编辑、特效处理等技术，支持抖音、剪映、头条等公司内众多产品线；同时为外部 ToB 合作伙伴提供业界最前沿的智能创作能力与行业解决方案。其中数字人方向专注于建设行业领先的数字人生成和驱动技术，丰富智能创作内容生态。

#训练1000样本就能超越o1

李飞飞等人画出AI扩展新曲线

跟大模型说：要多想。

今年 1 月，DeepSeek R1 引爆了全球科技界，它创新的方法，大幅简化的算力需求撼动了英伟达万亿市值，更引发了全行业的反思。在通往 AGI（通用人工智能）的路上，我们现在不必一味扩大算力规模，更高效的新方法带来了更多的创新可能。

最近一段时间，全世界的科技公司、研究团队都在尝试复现 DeepSeek，但如果这个时候有人说「我还能大幅改进 AI 的推理效率」，你会怎么想？

s1 论文作者，斯坦福大学在读博士 Niklas Muennighoff 表示，DeepSeek r1 令人兴奋，但其缺少 OpenAI 的测试时间扩展图并且需要大量数据。我们推出的 s1 仅使用 1K 样本和简单的测试时间干预即可重现 o1 的预览扩展和性能。

这个新方法叫 s1。本周，斯坦福大学、华盛顿大学等研究机构尝试了最简化实现测试时间扩展（test-time scaling）的方法，仅让模型训练 1000 个问题就获得了超越 o1 的强推理性能。

测试时间扩展是一种有前途的语言建模新方法，它使用额外的测试时间计算来提高模型性能。此前，OpenAI 的 o1 模型展示了这种能力，但并未公开分享其方法。很多工作都在尝试复现 o1，这些尝试包含蒙特卡洛树搜索、多智能体等等。今年 1 月开源的 DeepSeek R1 成功实现了 o1 级别的性能，它是在数百万个样本上通过多训练阶段强化学习实现的。

在 s1 的新工作中，研究人员寻求最简单的方法来实现测试时间扩展。它们构建了一个小型数据集 s1K，其中包含 1000 个问题，并根据三个标准（难度、多样性和质量）与推理轨迹进行配对。

在此基础上，研究人员开发了「预算强制」来控制测试时间计算，方法是强制终止模型的思考过程，或者在模型试图结束时多次将「等待」附加到模型的生成中以延长思考。这有可能会导致模型仔细检查其答案，修复其不正确的推理步骤。

在 s1K 上对 Qwen2.5-32B-Instruct 语言模型进行监督微调（16 块 H100 GPU，26 分钟）并为其设定预算强制后，新模型 s1-32B 在竞赛数学问题上的表现比 o1-preview 高出 27%（MATH 和 AIME24）。

s1 性能与其他大模型的对比。

• 论文：《s1: Simple test-time scaling》 
• 论文链接：https://arxiv.org/abs/2501.19393
• 项目链接：https://github.com/simplescaling/s1

测试时间扩展

本文将测试时间扩展方法分为两类：

1. 序列扩展，即后续计算依赖于先前的计算结果；
2. 并行扩展，即计算独立运行。

本文专注于序列扩展，因为直观上其具有更好的扩展性，因为后续计算可以基于中间结果进行，从而实现更深层次的推理和迭代优化。

此外，本文还提出了新的序列扩展方法以及对其进行基准测试的方式。

预算强制（Budget forcing）。本文提出了一种简单的解码时间（decoding-time ）干预方法，通过在测试时强制设定最大或最小思考 token 数量来实现。图 3 为该方法的一个示例展示，说明了这种简单的方法可以引导模型得出更好的答案。

具体来说，本文通过简单地追加思考结束（end-of-thinking）token 分隔符和「Final Answer:」来强制设定最大 token 数量，从而提前退出思考阶段，使模型提供其当前的最佳答案。为了强制设定最小 token 数量，本文抑制思考结束 token 分隔符的生成，并选择性地在模型的当前推理轨迹后追加字符串「Wait」，以鼓励模型反思其当前生成的内容。

基线。本文用以下方法对预算强制进行基准测试：

（I）条件长度控制方法，该方法依赖于在提示中告诉模型它应该生成多长时间。本文按粒度将它们分组为（a）token 条件控制，在提示中指定思考 token 的上限；（b）步骤条件控制，指定思考步骤的上限；（c）类条件控制，编写两个通用提示，告诉模型思考一小段时间或很长一段时间。

（II）拒绝采样，即采样直到生成符合预定的计算预算。

实验

在训练阶段。本文使用 s1K 数据集对 Qwen2.5-32B-Instruct 进行监督微调，以获得本文的模型 s1-32B。微调是在 16 台 NVIDIA H100 GPU 上使用 PyTorch FSDP 进行的，耗时 26 分钟。

评估。本文采用了三个推理基准进行评估。

• AIME24 包含 30 个问题，这些问题来自 2024 年 1 月 31 日至 2 月 1 日举行的美国 AIME 数学竞赛。AIME 用来测试模型在算术、代数、计数、几何、数论、概率等领域的能力；
• MATH500 是一个包含不同难度竞赛数学问题的基准；
• GPQA Diamond 包含 198 个来自生物学、化学和物理学的博士级科学问题。

其他模型。本文将 s1-32B 与以下模型进行基准测试对比：OpenAI o1 闭源系列模型；DeepSeek r1 开源模型；Qwen 的 QwQ-32B-preview 等模型。

值得一提的是，s1-32B 是完全开源的，包括权重、推理数据和代码。

性能

测试时间扩展。图 1 展示了 s1-32B 在使用预算强制技术后，随着测试时间计算资源的增加，性能的变化情况。

图 4（左）扩展了图 1（中）的图表，结果显示虽然本文可以通过预算强制技术和更多的测试时计算资源提升 AIME24 的性能，但最终在六倍计算量时趋于平缓。可以得出过于频繁地抑制思考结束 token 分隔符可能会导致模型陷入循环重复，而不是持续推理。

图 4（右）展示了在对 Qwen2.5-32B-Instruct 进行 1,000 个样本的训练，从而生成 s1-32B，并为其配备简单的预算强制技术后，它进入了一种不同的扩展范式。通过多数投票在基础模型上扩展测试时间计算资源无法赶上 s1-32B 的性能，这验证了这一直觉，即序列扩展比并行扩展更有效。

图 5 提供了 s1-32B 的生成示例。

样本效率。图 2（右）和表 1 将 s1-32B 与其他模型进行了比较。

结果显示， s1-32B 是样本效率最高的开放数据推理模型。尽管只在额外的 1000 个样本上进行训练，但它的表现明显优于基础模型（Qwen2.5-32B-Instruct）。

r1-32B 在仅使用 SFT 的情况下表现出比 s1-32B 更好的性能，但前者是在 800 倍以上的推理样本上进行训练的。仅用 1000 个样本是否能达到这个性能还是一个悬而未决的问题。

s1-32B 在 AIME24 上几乎与 Gemini 2.0 Thinking 相匹配，因为 s1-32B 是从 Gemini 2.0 中蒸馏出来的，这表明本文的蒸馏程序可能是有效的。

最后，本文还进行了一系列消融实验，感兴趣的读者，可以查看原论文，了解更多内容。