51c自动驾驶~合集32

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

#Mamba与元学习双管齐下

打造新的语义补全方案！

传统的自动驾驶框架下，现有感知而后又规控，所以可以说感知在这套框架下扮演着非常基础性的工作。然而，动态交通参与者的突发性和可变性，加上静态对象的较大的范围和距离，给自动驾驶车辆在感知复杂驾驶场景时带来了不小的挑战。而在一众提高感知能力的方法中，场景语义补全（Scene Semantic Completion，SSC） 作为一种同时推理驾驶场景的几何形状和语义的技术脱颖而出。如图1所示，与传统的依赖于单个目标检测和跟踪的感知任务不同，SSC通过填补部分或遮挡传感器输入中缺失的信息，提供了对环境更全面的理解。当传感器如激光雷达或摄像头被其他车辆或环境元素遮挡时，这种能力尤其关键。

不过，收集和标注大规模真实世界数据集是一个昂贵且劳动密集型的过程，而且能够收集到多样的真实世界交通情况也是一件比较有挑战的事情，比如一些像是车辆故障 or 行人碰撞的等长尾场景。所以，越来越多的研究人员愿意转向高保真的模拟器，如：CARLA等，来生成一些数据，虽然这些合成的数据与真实世界的数据还是存在一些domain gap。

当前的SSC解决方案通常依赖于 3D CNNs 来编码点云或RGB-D图像等输入数据，这些数据包含了丰富的空间信息。然而，3D CNNs在捕获细粒度场景表示或建模3D块之间的长序列关系方面有些许挑战，而这两者恰恰对于SSC任务至关重要。缺乏时间建模限制了它们跟踪环境动态变化的能力。

• 论文链接：https://arxiv.org/pdf/2411.03672v1

作者这篇工作旨在解决两个关键gap：

• 需要有效利用模拟数据以快速部署在真实世界场景中
• 开发一种新的骨干网络，能够捕获长序列依赖关系和高分辨率空间信息。

所以，相应的，这篇工作的主要贡献主要总结如下：

• 双相训练与元学习 作者采用双相训练策略，通过模型无关的元学习（MAML），在源域（由模拟器生成的数据集）上预训练模型，并在目标域（真实世界数据集）上进行微调。这种方法通过在微调过程中快速学习特定于域的特征，加速了对真实世界环境的适应。通过跨多个域的泛化，MAML减少了过拟合并提高了模型在新情况下的鲁棒性。
• 用于长序列建模的新型骨干网络 作者引入了一种新的骨干架构，该架构集成了Mamba（一种选择性的状态空间模型（SSM）），可变形卷积和大核注意（DLKA）。Mamba提供了一种结构化机制，用于随时间处理序列数据，确保有效地捕获3D体素网格内的长距离依赖关系。可变形卷积允许模型动态调整接受域，增强了检测不同尺度物体的能力。同时，D-LKA增强了网络的注意力机制，专注于场景的关键区域，这提高了空间意识和决策能力。

相关工作3D semantic scene completion for autonomous driving

SSC 任务就是从不完整的传感器输入中，推断大规模户外环境的几何形状和语义。它提供了对驾驶场景的完整理解，并预测缺失的元素，这对于自动驾驶至关重要。

Roldao 等人提出了 LMSCNet，这是一个多尺度网络，结合了 2D U-Net 主干和 3D 分割头。这种设计减少了全 3D 卷积的计算负担，同时保持了竞争性能。同样，Yan 等人引入了一个多任务学习框架，其中语义分割（SS）和 SSC 被联合训练。通过在两个任务之间共享特征，模型改进了几何和语义预测。这些方法使用单目 RGB 摄像头与 LiDAR 相比，可以降低部署成本。然而，在这种像素到点的转换过程中，可能会在 3D 空间的未占用区域引入虚假特征，降低模型性能。为了解决这些限制，最近的研究集中在改进像素到点的转换和提炼特征融合技术。一些方法将深度估计纳入 RGB 输入，而其他方法使用注意力机制来选择性增强相关特征。

Deformable large kernel attention

学习 SSC 任务中不同体素之间相关性的两种主要方法：

第一种方法使用大核和堆叠多层的 3D 卷积，使模型能够捕获 3D 空间中的长距离依赖。然而，随着层数的增加，计算成本呈指数增长，大量的参数需要更多的内存和训练时间。这些限制使其在实时应用中不切实际，尤其是在效率至关重要的自动驾驶场景中。

第二种方法使用自注意力机制，有选择地关注相关特征。自注意力在模拟远距离体素之间的关系方面提供了灵活性。然而，自注意力倾向于忽视场景的固有 3D 结构，将输入数据更多地视为展平的序列而不是结构化的空间信息。此外，自注意力不会动态适应通道维度的变化，限制了其在驾驶环境中表示复杂变换的能力。这些限制，加上基于注意力模型的计算开销，为在资源受限的系统中部署它们提出了挑战。

为了解决这些问题，研究人员探索了可变形卷积，它引入了额外的偏移量，允许网络自适应地重新采样空间特征。这种方法通过关注输入最相关的区域来增强模型处理几何变化的能力，在复杂场景中的鲁棒性得到了提高。

Mamba on 3D semantic scene completion

Mamba 的精简架构减少了通常与 Transformer 相关的计算开销，使其非常适合需要快速推理的应用。它采用了轻量级设计，用更简单的线性变换替换了多头自注意力机制，同时仍然捕获输入元素之间的基本关系。

Zhu 等人开发了一个基于 Mamba 的通用视觉主干，用于模拟图像块之间的关系，展示了 Mamba 在计算机视觉任务中的潜力。通过有效地编码图像区域之间的关系，Mamba 为视觉处理中基于 Transformer 的模型提供了实用的替代方案。此外，Mamba 在 3D 建模任务中可能更加有效，其中 3D 块的序列比 2D 图像块长得多，也复杂得多。这一洞见鼓励研究人员探索将 Mamba 能力扩展到 2D 应用之外的新方法。​

方法论

之前的研究表明，在多任务学习框架中结合语义分割（SS）和场景语义补全（SSC）可以提升两项任务的性能，其中 SS 提供详细的语义特征，补充 SSC 捕获的几何理解，使得两个模块都能从共享的特征提取中受益。同时，一些方法通过使用历史 LiDAR 扫描作为辅助监督来增加语义标签的密度。尽管这些方法提高了模型捕获细粒度语义的能力，但依赖历史扫描增加了计算开销，使得这些解决方案难以在实时自动驾驶场景中部署。

作者的方法不同，将 SS 作为预训练任务来学习 SSC 的元知识。预训练步骤帮助模型更好地泛化于不同域，准备处理真实世界的复杂性，如遮挡和传感器噪声。为了进一步增强监督，作者从附近的 CAV 聚合语义信息，提供更密集的标签，扩展到更大的距离。这种从多辆车聚合的语义信息解决了单个传感器的局限性，后者通常受到数据稀疏和遮挡的限制。它允许模型更有效地推理不完整的区域，从而获得更全面的场景理解。

问题表述

作者将 3D SSC 问题定义如下：给定一个稀疏的 3D 体素网格 ，其中 、 和  分别表示驾驶场景的高度、宽度和深度。每个体素  在  中可以是 0 或 1，表示物体的占用情况，其中 、 和  是体素索引。3D SSC 的目标是学习一个模型 ，为  中的每个  分配一个语义标签，得到 ，其中  是对应位置的标签。这些标签属于集合 ，其中  是语义类别的数量， 表示一个自由标签。

双相训练策略

基于 MAML，作者提出的方法，MetaSSC的工作流程如图 3 所示，包括两个主要阶段：元预训练和适应。这些阶段使得 SSC-MDM 模型能够将知识从模拟环境转移到真实世界驾驶场景，提高 3D SSC 任务的性能。

元预训练阶段（图 3-部分 A）旨在通过从模拟数据中学习，为跨不同任务的泛化做准备。源数据集 OPV2V 和 V2XSIM 提供了一系列 V2V 和 V2X 场景，帮助模型为动态环境开发鲁棒特征。任务从这些数据集中采样，每个任务包括一个支持集和一个查询集。支持集用于内循环中优化任务特定的参数，而查询集评估模型的泛化性能。

元学习器用一组参数  初始化 SSC-MDM 主干，这些参数被分配给每个任务。给定  个任务  从源数据集 ，对于每个任务 ，支持集  在内循环中使用，其中执行多个 k 步梯度下降。这些小步更新使模型能够快速适应任务特定的特征，提高其处理复杂场景的能力。在每一步中，应用数据增强（Aug）来增强学习特征的鲁棒性和泛化能力。

具体元预训练的过程可以详见 Algorithm1：

在适应阶段（图 3-部分 B），元训练的 SSC MDM 模型被适应到目标真实世界数据集，SemanticKITTI。这个阶段微调元学习参数，使其与真实世界条件对齐，解决诸如传感器噪声、遮挡和环境变异性等挑战。允许模型以多种分辨率（1:1、1:2、1:4 和 1:8）生成输出，使其能够捕获驾驶环境的细节和大规模特征。

多尺度输出对于平衡局部精度和全局场景理解至关重要。例如，像行人这样的小物体在更细的尺度上被检测，而像道路和建筑物这样的大物体在更粗的分辨率上被识别。这种分层输出结构确保了模型即使在具有挑战性的真实世界场景中也能提供准确和全面的场景补全。

适应阶段利用元学习参数作为一个强大的起点，最小化了对广泛重新训练的需求。这种高效的迁移学习框架加速了 SSC-MDM 模型在真实世界设置中的部署，确保了高性能和最小的计算开销。适应阶段的过程被作者总结进 Algorithm2中：

D-LKA-M 架构

D-LKA-M 架构如图 4 所示，源自 D-LKA 网络，集成了 Mamba 块，有效地处理 3D 块的长序列建模。该设计遵循与 LMSCNet 类似的层次结构，类似于 U-Net 架构。层次结构使模型能够进行多尺度处理，允许模型捕获来自 3D 场景的细粒度细节和更广泛的上下文信息。

模型通过一系列 3D 模块处理输入数据，不同阶段进行下采样和上采样操作。每个下采样层减少空间维度，压缩输入同时保留关键信息，每个上采样层重建更高分辨率的输出。这种结构使其能够以多种降低的分辨率输出结果。这在 SSC 任务中特别有用，因为它在多个尺度上提供预测，提高了 SSC 的准确性。

在输入阶段使用 Patch 嵌入模块将原始 3D 数据划分为可管理的部分。嵌入在 D-LKA 模块中的 Mamba 块增强了网络对 3D 体素网格长距离依赖关系的建模能力，这对于理解复杂驾驶环境至关重要。这种集成确保了模型在计算效率和准确性之间取得平衡，使其适合实时应用。

可变形卷积

可变形卷积引入了一个偏移场来自适应调整卷积核，这在自动驾驶中特别重要，因为行人、车辆和障碍物等对象通常不符合固定形状或位置。传统的固定核卷积难以有效捕获这种不规则性，限制了模型准确感知复杂驾驶环境的能力。可变形卷积通过动态修改每个输入位置的感受野来解决这个问题。该机制可以总结如下：

其中  表示可变形注意力机制， 表示层归一化。

在可变形注意力中，对于输入特征图  中的任何位置 ，学习到的偏移  被添加到感受野中，定义为 。这种机制允许模型动态转移其焦点，超出固定空间区域。这里， 枚举了规则体素网格中的位置。在位置  的可变形卷积输出由以下给出：

由于偏移  通常是分数，需要插值来计算非整位置的特征值。位置  处的插值值计算如下：

总之，可变形卷积为自动驾驶提供了显著优势，通过提高模型对复杂场景的理解能力，这对于构建在真实世界环境中安全可靠的自动驾驶系统至关重要。

大核注意力

大核注意力（LKA）引入了一种新的方法来有效地捕获局部和全局上下文信息。与传统卷积不同，传统卷积难以平衡局部细节和大感受野，LKA将大  核卷积分解为多个阶段，每个阶段设计用于处理特征提取的不同方面，同时保持计算效率。具体来说，大核卷积被分解为  深度可分离膨胀卷积，膨胀率为 ，一个  深度可分离卷积，以及一个  通道卷积。

这种分解不仅以线性复杂度实现了大感受野，还提供了动态处理能力，使其非常适合于自动驾驶中的 3D SSC 等复杂任务。LKA 的数学公式可以表示为：

其中  是输入特征， 表示深度可分离卷积， 表示深度可分离膨胀卷积， 是通道卷积。LKA 的最终输出是通过注意力权重  和输入特征  之间的逐元素乘积获得的：

其中  表示注意力权重， 表示逐元素乘积。此操作允许模型为不同的空间和通道特征分配不同的重要性，从而提高其关注输入的重要区域的能力。

作者使用可变形卷积和大核注意力作为基本模块（D-LKA）。可变形卷积提供了自适应的感受野来处理不规则的对象形状，而 LKA 确保了局部细节和全局上下文的有效处理。D-LKA 结合增强了模型在 3D 体素网格内准确捕获复杂空间关系的能力。

总之，LKA 与可变形卷积的集成构成了作者提出模型的主干。这个模块在使模型在自动驾驶场景中有效执行中起着至关重要的作用，其中局部细节和大规模上下文都是必需的。

Mamba

与 Vision Mamba不同，作者的方法直接处理来自 D-LKA 块的特征，并与 Mamba 块一起处理，以增强 3D 体素网格的长序列建模。这种直接集成使作者的模型能够有效地捕获来自 D-LKA 的局部特征和通过 Mamba 块的长距离依赖关系，从而实现更强大的自动驾驶场景理解。这个过程的数学公式表示为：

其中  表示从 D-LKA 块提取的输入特征， 表示 Mamba 块。Mamba 块处理序列数据的能力确保了模型有效地捕获 3D 场景内复杂的空间关系，这对于 SSC 任务至关重要。

一旦特征通过 Mamba 块处理，它们会通过前馈网络（FFN）和卷积层进一步细化。最终输出  计算如下：

其中  表示卷积层， 是前馈网络。

总而言之，D-LKA 和 Mamba 模块的集成使模型能够有效地执行局部和长序列建模，同时还能确保局部细节和全局背景之间的平衡，从而做出准确的决策。​

实验及结论

作者在 SemanticKITTI上进行了实验，将数据分割为训练、验证和测试集，确保与以前研究的一致性。

与Baseline模型的比较

如表 1 所总结。所提出的 SSC-MDM 模型在场景补全的交并比（IoU）中排名第一，在精确度中排名第二。它还在 SSC 的平均交并比（mIoU）中排名第二，表明其在场景补全和语义场景补全任务中的优越性能。

然而，SSC-MDM 的召回率低于 TS3D，这可以归因于 TS3D 使用额外的 RGB 输入。这一差异突出了 RGB 辅助性能与像 SSC-MDM 这样的纯 LiDAR 模型之间的权衡。作者的方法在常见类别如道路和建筑中特别出色，超过了其他模型。然而，对于出现频率较低的类别，其性能相当或略低，这突显了解决数据集中类别不平衡问题的必要性。

消融分析

该分析旨在通过比较不同的变体架构，隔离和评估所提出模型的关键组件的影响。这四个变体模型，称为 Multi-scaled、D-LKA、Transfer 和 Mamba，描述如下：

1. Multi-scaled:LMSCNet 作为作者分析的基础模型。这是一个轻量级模型，它在多个分辨率上学习特征，利用多尺度连接捕获细粒度和广泛的上下文信息。作者从这个模型开始逐步改进，以测试不同组件对最终性能的贡献。
2. D-LKA:在这个变体中，作者用可变形大核注意力网络替换了 LMSCNet 主干，以增强特征提取。这一修改旨在提高网络更准确预测复杂 3D 场景的能力。
3. Transfer:这个变体采用了前面讨论的双相训练策略，以提高模型性能并减少训练时间。通过在源数据集上预训练并在目标数据集上微调，"Transfer" 利用来自模拟域的知识来增强真实世界性能，确保更快的收敛和改进的泛化能力。
4. Mamba:在这个最终变体中，作者将 Mamba 块集成到 D-LKA 网络中，以处理 3D 块的长序列建模。Mamba 的优势在于其能够有效地处理序列依赖性，这进一步增强了模型对 3D 空间结构的理解，以实现 SSC。

消融分析的结果总结在表 2 中。随着作者从 "Multi-scaled" 进展到 "Mamba"，所有指标的性能要么提高要么保持一致，引入 DLKA 时召回率的下降除外。D-LKA 阶段召回率的下降可以归因于模型复杂性和泛化能力之间的权衡，因为 DLKA 专注于学习更丰富的特征，但可能需要更多的数据以获得最佳的召回率。总体而言，结果证实了作者工作中使用的技术对 SSC 通常是有益的，显示出在各种性能指标上的一致改进。

此外，作者在图 6 中可视化了四个模型在 SemanticKITTI 验证数据集上的 mIoU 训练周期。"Multi-scaled" 和 "D-LKA" 变体直接在目标数据集上训练，而 "Transfer" 和 "Mamba" 变体在源数据集上预训练并在目标数据集上微调。值得注意的是，在微调过程中，仅在第一周期微调输出层以稳定早期训练。可视化清楚地表明，双相训练策略加速了收敛，并在较少的训练周期内获得了更好的性能。这突出了转移预训练知识并在较小的目标数据集上微调以有效实现理想结果的有效性。​

结论

本研究提出了一个基于元学习的框架，用于解决自动驾驶中的场景语义补全（SSC）任务，重点关注从模拟环境到真实世界应用的知识转移。通过利用从模拟环境中获取的元知识，框架减少了对大规模真实世界数据的依赖，显著降低了部署成本并缩短了开发周期。本框架的关键创新在于其集成了大核注意力（LKA）机制和 Mamba 块到主干模型中。这些组件使模型能够有效地从 3D 体素网格提供的稀疏和不规则数据中提取多尺度、长序列关系。LKA 机制允许模型通过扩大感受野来捕获局部细节和全局上下文，而不增加计算复杂性。同时，Mamba 块提高了模型处理 3D 块序列依赖性的能力，通过捕获驾驶场景中的时间空间关系来增强 SSC 任务。

总之，元学习、先进的注意力机制和双相训练的结合为自动驾驶中的 SSC 提供了一种可扩展且鲁棒的解决方案。所提出的框架不仅提高了模型处理复杂和动态驾驶环境的能力，还降低了部署成本。这些结果为 SSC 的未来进步铺平了道路，并为构建更安全、更可靠的自动驾驶系统提供了宝贵的见解。

#蘑菇车联等企业携手编制车路云白皮书

引领车路云一体化试点城市建设

在智能交通的浪潮中，一个全新的里程碑已经到来！11月11日，在第五届中国（无锡）车联网产业发展论坛暨智能网联汽车“车路云一体化”生态大会上，中国汽车工程学会与中国智能网联汽车产业创新联盟联合发布了备受瞩目的《车路云一体化实践应用白皮书》。这份白皮书不仅汇聚了行业的智慧，更是由蘑菇车联等头部企业深度参与编制，共同推动行业发展步入快车道。

《车路云一体化实践应用白皮书》由学会、联盟牵头，联合国家智能网联汽车创新中心、中国移动上海产业研究院、联通智网、蘑菇车联、中国一汽等单位共同编制，从2024年2月研究至今，调研与收录了5家整车企业、13家设备与系统供应商、解决方案供应商等企业的技术实践，以及20个城市、高速、特定区域的地方实践，形成44项典型实践案例集。

车路云一体化，智能交通的新引擎

2024年1月，五部委联合启动智能网联汽车“车路云一体化”应用试点工作，7月公布首批20个试点城市名单。在这个大背景下，各试点城市正积极布局车路云一体化系统建设。《车路云一体化实践应用白皮书》的发布，正是对当前企业实践与地方实践的总结和归纳，为地方政府车路云一体化建设提供了宝贵的样板案例。

蘑菇车联，技术与实践的先行者

蘑菇车联在车路云一体化实践中表现卓越，其自主研发的路侧AI数字道路基站集成了先进的路侧感知设备、高效的直连通信路侧单元（RSU）以及强大的边缘计算系统（RCU）。这一技术成果不仅达到了“SL3”级（自动驾驶类应用）标准，更为智能网联车辆提供了可靠的数据支持，推动自动驾驶技术的飞速发展。

实际应用，成效显著

蘑菇车联的车路云一体化项目已在多个城市落地运营，覆盖城市公开道路、高速公路、景区园区等多种场景。在北京亦庄，蘑菇车联参与北京市高级别自动驾驶示范区（简称“示范区”）3.0阶段建设，AI数字道路基站完成了示范区各项路测验证，自动驾驶乘用车和自动驾驶巴士已在北京亦庄开展常态化测试运营。在大理洱海生态廊道，蘑菇车联投入的L4级自动驾驶巴士等多种自动驾驶车辆，借助车路协同技术，实现了高度自动化的运行，有效缓解了景区交通压力，提升了游客的出行体验。在衡阳，蘑菇车联的小型自动驾驶巴士累计行驶里程超过10万公里，完成运营任务超1万次，处理服务订单超 2 万个，显著提升了当地的交通安全和出行效率。在实际应用场景中，蘑菇车联展现出强大的落地能力。

标准制定，行业引领

蘑菇车联积极参与车路云一体化相关的标准制定和指南编写工作，参与编制全国首个《车路云一体化建设指南》，方案全面符合“工信部车路云一体化试点指南” 要求，凭借其技术实力和实践经验，蘑菇车联始终走在行业前列，助力行业规范化发展。

蘑菇车联CEO朱磊表示：“车路云一体化网络是智能交通发展的关键，我们要构建一个安全、高效、智能的交通生态系统。”蘑菇车联将继续秉持创新精神，加大研发投入，不断提升技术水平，拓展应用场景，积极与行业伙伴合作，共同推动车路云一体化网络的发展，为智能交通领域的变革贡献力量。

#DyGASR

超越所有网格重建方法！速度&内存双双提升！如何降低训练时间和存储成本

通过基于神经隐式技术的渲染监督方法，能够在小场景中取得令人印象深刻的结果，但在复杂或大规模场景中，尤其是在广泛无纹理区域的场景中，这些方法表现不佳。为了解决这些问题，先前的研究在优化过程中引入了诸如深度、法线正则化、点云和语义信息等结构先验，同时采用了精细采样策略，例如体素关键点引导和分层采样。虽然这些策略提高了表面网格重建的准确性，但也显著增加了计算需求并延长了训练时间。

尽管某些方法使用MVS预测的点云作为网格重建的先验，但这些点云稀疏且噪声较大，无法捕获场景的细节特征。在NeRF之后，最近引入了3D高斯点云（3DGS）方法，并迅速流行起来。这种方法擅长生成密集几何点云，并在参数空间中显式存储场景结构，从而能够直接编辑3D场景。然而，通过3DGS优化的高斯点由于其数量庞大、训练速度较慢且主要位于场景内部，因此无法直接用作网格重建的先验，这可能会产生噪声结果。

DyGASR[1]旨在降低训练时间和存储成本，同时超越当前最先进方法的重建质量。我们注意到，3DGS信号建模固有的低通特性在大多数场景中的高频不连续性和由众多微小高斯点导致的内存负担中显得不足。因此，受广义指数点云方法的启发，我们采用广义指数点云（GES），这种方法通过更少的粒子和更高的精度表达各种信号点。然而，由于GES生成的几何点云中心未与实际场景表面对齐，采用SuGaR方法并引入广义表面正则化（GSR），以使这些点云与表面对齐，并通过参数优化控制广义指数点云的形状。

此外，该方法放弃了原始的训练方法，提出了一种从低分辨率逐步过渡到高分辨率的策略，大幅提高了训练的收敛速度和稳定性，同时提升了重建质量。实验结果表明，本方法不仅在训练时间上显著减少，同时在内存使用上表现更优，并且在网格重建的细节质量上领先于其他方法。​

具体方法

总览

图3展示了我们提出的DyGASR框架。最初，利用结构化运动恢复（SfM）生成的稀疏点云初始化高斯点云分布。该方法包括三个关键训练模块：

1. 广义指数点云（GES）： 在整个训练过程中，通过投影和光栅化监督渲染，以生成稠密的广义指数点云。需要注意的是，许多生成的广义指数点云的中心位于表面之内。
2. 广义表面正则化（GSR）： 为了解决实际和理想有符号距离函数（SDF）值之间的差异，引入了协同的GSR优化。此过程使3D广义指数点云扁平化并与表面对齐，同时确保实际法线与表面垂直。
3. 动态分辨率训练（DRT）： 引入了一种从粗到细动态调整图像分辨率的训练策略。

完成训练后，生成的广义指数点云将用于泊松重建，创建场景的带纹理表面网格。

广义指数点云（Generalized Exponential Splatting, GES）

为了加速从3D点云到网格的重建，并受GES方法的启发，我们将广义指数点云（GES）框架引入到我们的3D表面网格重建方法中。该方法通过广义指数函数（GEF）原则，将广义指数椭球投影并栅格化到图像上。通过调整形状参数ϵ，GES能够灵活调整广义指数基元的形状。如图2(c)所示，广义指数函数定义如下：

其中，δ 表示位置参数，γ 表示缩放参数， 表示幅度，ϵ 为形状参数。当 ϵ

在扩展到GES框架时，其核心特性定义了位置 

其中， 表示位置中心， 表示3DGS的协方差矩阵。协方差矩阵  可以分解为旋转矩阵  和缩放矩阵 

对于2D投影，协方差矩阵  通过投影矩阵  及其雅可比矩阵 

为了保持  的半正定性并适应栅格化框架，使用函数 ϕϵ 优化 。在体积渲染中，光线穿过场景的期望颜色通过积分计算，定义为：

其中， 表示从  到  的透射率，κ 表示体密度， 为  处沿方向 

在3DGS中，投影分量的方差 γ 沿光线方向积分，影响渲染颜色强度。在GES中，通过调整函数 ϕϵ 调节缩放矩阵的有效方差 γ，公式为：

γϵϕϵγ

ϕϵρϵϵ

其中，ρ 为形状强度参数，用于缓解视角相关边界效应的潜在误差，并确保不同 ϵ

λλ

其中，λ 取值为0.2，使GES能够通过渲染损失持续优化 ϵ，利用多样的广义指数函数形状描述场景。该方法不仅传递低频信号特征，还能确保覆盖完整3D场景，同时减少所需的GES数量。通过全局计算渲染损失，该框架推导出更适合的稠密点云，从而提高网格重建效率。

显式网格重建

广义表面正则化（Generalized Surface Regularization, GSR）

借鉴A. Guédon提出的SuGaR方法，我们将其与广义指数点云（GES）相结合。在广义指数分布场景中，给定位置  的密度函数  受GES模型灵活的形状参数 ϵ 影响。位置  的函数值由所有点的值按透明度权重系数 

在理想情况下，当广义指数分布完全对齐且均匀分布时，点  的密度主要受最近点  的影响，而忽略其他点。此外，为确保广义指数点云在极薄情况下能够紧贴表面，每个点云的缩放矩阵  的最小因子  应趋近于零，同时将透明度  设置为1。这样，点 

其中， 表示广义指数形状的最小缩放因子，

因此，可将理想和实际条件下的密度融入正则化项。然而，实验表明，基于有符号距离函数（SDF）计算的损失比基于密度的损失更有效。因此，SDF表达式为：

通过分别代入理想场景的  和实际场景的 

其中， 是从广义指数分布场景关键区域采样的点集。观察到某些采样点在  中具有较高的梯度值，且  点的法线与表面垂直。因此，引入第二个正则化损失项，使实际状态的法线更接近 ：

其中， 是点 

最终，模型的总损失函数定义为：

其中， 和 

网格提取

为了快速从正则化后的GES生成网格，使用泊松重建算法。基于密度函数计算的等值面通过3D点集采样确定。具体而言，随机选择广义指数分布深度图中的像素点作为视线方向的起点（深度图通过扩展点云栅格化器获得）。沿选定像素的视线方向 ，生成点 。范围  设置为 σσ，其中，σ 是广义指数分布在方向  上的标准差，覆盖了99.7%的置信区间。计算每个采样点的密度值 ，并标记满足 λ

通过线性插值，确定最近于相机的等值面点 ，满足 α。在每个等值面点 

随后，使用这些等值面点及其法线信息通过泊松算法重建网格。在初步网格提取后，将新生成的广义指数分布绑定到网格三角形上，并进行协同优化。这一过程采用高斯栅格化器，使网格编辑工具可以在保持高质量渲染效果的同时，对广义指数点云展平后的场景进行编辑。

动态分辨率训练（Dynamic Resolution Training, DRT）

传统的高斯点云训练在整个图像上始终以单一分辨率进行，这导致了次优的损失结构。因此，本文引入了一种动态分辨率训练（DRT）策略，通过由粗到细的方式转变传统训练模式。

训练策略

训练从低分辨率开始，随着训练的进行，逐渐提高分辨率，直至达到完整分辨率。这一调整通过余弦调度进行动态控制，缩放因子定义为：

其中：

•  和 
•  和 

优化过程

在训练初期，采用稀疏点云和近似属性进行优化。此时，过早关注细节会阻碍收敛，并可能导致高斯模糊伪影的出现。随着分辨率的提高，模型逐渐适应广义指数分布，从而更好地重建场景的细节特征。

效果

该策略显著减少了训练时长，同时对场景的重建质量产生了积极影响。通过逐步提升分辨率，模型能够在早期快速捕获全局结构，在后期精细化细节，从而实现更高效、更稳定的训练和重建过程。​

实验效果

总结一下

DyGASR是一种基于动态广义指数点云对齐表面的创新方法，用于加速3D网格重建。该方法采用广义指数点云模型代替传统模型，减少了所需粒子数量，并提高了信号特征的精确性。通过引入广义表面正则化模块，确保广义指数分布的质心与实际场景表面更加精确对齐，从而提升了网格重建的精度。此外，动态分辨率调整策略显著加快了训练速度并降低了内存消耗。与现有先进的基于3DGS的方法相比，本文的方法实现了25%的速度提升、30%的内存消耗减少，并在质量上取得了更好的表现，为3D网格重建树立了新的基准。

#2024年11月具身智能人形机器人情报

2024年11月具身智能人形机器人情报第一弹

一次零散更新。

很多美国投资人说李飞飞公司是做三维感知的，不是具身智能。Segery的PI才是具身智能。

北理工黄强的理工华汇完成天使轮融资。硬件很强的团队。

思灵机器人（Agile Robots）宣布完成2.2亿美金C轮融资，软银愿景领投，跟投方包括阿布扎比皇室集团、高瓴创投、红杉中国、线性资本等。

知行机器人完成数千万元B轮融资，由诚美资本与中关村智友基金领投，是专攻机械抓的公司。

自变量机器人新一轮获得一亿融资，投资方包括德联资本、基石资本、啟赋资本、南山战新投，老股东九合创投持续加注。是专注端到端具身模型的公司。

星海图正式官宣获得2亿新融资，宣布发布全球首个机器人Real2Sim2Real引擎。

穹彻下一轮也快close了。

银河通用宣布只用仿真数据，采用英伟达isaac仿真，落地的第一个场景是药店。​

2024年11月具身智能人形机器人情报第二弹

一些零散小更新。

伯克利Physical Intelligence宣布已成功筹集4亿美元资金，融资后估值达24亿美元（约合170亿人民币）。segery极其低调，团队藏龙卧虎。已开始有商业poc。

特斯拉其实也用了一些英伟达的仿真。新特朗普时代马斯克optimus会得到大量支持。正在准备量产，供应链在上海。

最近下肢的技术突破比上肢快、成本也降低，在未来可能轮式机器人没存在必要了。然后上肢采集真实数据可行，上肢技术进步明年要加速了。

新公司灵初智能企查查已更新，传下一轮也快close了将获得一亿融资，估值约1.5亿美金。类似PI的技术路线？传闻估值将冲击3亿美金。不确定细节。

小鹏新机器人发布，宣称没有500亿的投入做不好AI机器人。我不评论。小鹏机器人不独立融资。

南方科技大学郑锋教授创业，有中国科学院、腾讯背景。团队不详、估值不详。

经反馈某厂暂弃药店机器人方案，将采用社区分散部署自动售货机方案。一个小区门口一个售货机不需要包含所有sku，多个门口多个小区可覆盖全部sku。app支持“就近自取导航”和“即时上门派送”两种模式。

继核心零部件知行机器人官宣融资后，千觉智能也开始新一轮融资了，估值翻翻。星动纪元、星海图、千寻、穹彻也在开始新一轮融资，冲击3亿美金估值。说落地有重大突破。招了很多实习生发论文、做开发。

众擎机器人发布新机器人，走路拟人很强、成本低。在开始新一轮融资。

年底融资核心逻辑是商业化成功交付，其他都是假的。要么估值别太高，技术实力强，后入场有机会。

正如我之前文章中分析那样，我现在依然认为国内明年年初将会出现10家，估值3亿美金的新公司。继续往后走要看真实的产品落地情况了，宣传论文对超高估值帮助不大了。

再次提醒，又有人反映国资背景实习后申美国签证有问题。申请签证的时候简历不要体现出来，论文、专利合作也别被看到。如果去开会就要申请商务签、不要申请旅游签蒙混过关。此外，也有人说尽量不要在加州入境。

#某头部主机厂打响“自研替代战”

据悉，某头部主机厂对智驾业务进行战略调整，自研方案将替代供应商。预计保留两家头部公司（M公司和H公司）做高阶智驾之外，其余的将全部由自研团队来完成。

这对许多供应商来说意味着：Game over，Get out。

这也意味着这家主机厂的智驾战略进入第二个阶段。这家主机厂的智驾战略可谓是两步走的战略，第一步先和智驾供应商合作，补齐经常被消费者诟病的智驾性能的短板，同时投入自研；第二步是用自研去替代供应商。

对于这家主机厂的智驾自研团队来说，这是一次大考。

重金投入两年多了，团队规模也不小，再加上各种供应商“白盒”的加持，在这样的优等条件下，能不能向BOSS证明替换供应商的价值和作用，显得非常重要。比不了M公司和H公司，至少要能做到替代中小Tier 1，这是大考要交的卷子。

自研团队的压力和挑战不小。第一，时间紧、任务重，明年要量产的车型达到几十款，这个量产的任务对于任何团队而言都不小，所以这家主机厂内部也开始做动员，把体系内能做智驾的力量都动员起来去做量产；第二，目前研发进展慢，目前高速NOA搞得还不利索，泊车倒是可以量产落地了，城区NOA还非常遥远。

一位业界朋友表示，自研上车第一步的目标是高速NOA，基于中阶算力芯片来做。按说难度没那么大，许多中小Tier 1都能做出来这样的中阶方案，但是这么多车型要量产，压力不是一般的大。也不排除量产任务紧的时候，玩一把“自研在前面站台，供应商做Tier 2”的路子，这种做法在号称自研的主机厂也不少见。

不过，无论这一次自研上车的成绩表现如何，这家头部主机厂都将在智驾自研的路上坚定走下去。

这是由BOSS的理念决定的，核心技术自研是其底线和红线，也成为这家主机厂最大的政治正确之一。而且以其销量和收入的实力规模，也足够支撑其把自研进行到底，即使中间过程走弯路交不少学费。

再者，随着高阶智驾的大规模普及上车，如果没有自研而主要依靠供应商的话，按照现在高阶智驾license的价格一辆车就达到几千块，以这家主机厂的销售规模体量，每年要付给供应商的成本将巨大。

这笔经济账也是要算的。所以坚持自研这条路是该主机厂始终坚持的战略，也是必须打赢的战役。

#有人要现场拆车，还一下子拆四台

2025年2月21-24日，我们将在中国国际新能源汽车技术、零部件及服务展览会现场拆解四台车，深度揭秘国产车的崛起之路。

雅森新能源

近年来中国新能源车市场迅速扩张，国内厂商都把重心转向新能源汽车。新推出的国产新能源车无论价格、性能都是领先的。同时，供应链企业也紧跟时代，快速发展中。

根据中国设备管理协会新能源产业发展促进中心（简称中设协）发布的数据显示：

截至2023年，企业总量已经超过25000家，行业企业每年仍在以20%的速度增长。

日本人

又双叒拆了一辆中国车

前阵子日本又从国内买了一辆极氪007，并运到了日本进行拆解研究。日本技术人员表示：我们能否在控制成本下实现如此先进技术？

为何日本要大费周章拆解中国电动车？答案是：他们在通过逆向工程剖析并获取中国电动车行业技术。

现场拆解四台车

看看什么是国产化？

新能源汽车市场品牌众多，消费者选择难，且维修难养护难等问题凸显。

为深入展示国产新能源车实力，我们决定拆解4款代表性车型，全面检验和展示技术创新，让观众近距离测量、分析和评估。

造车供应链出圈活动

精彩看点概览！

拆新车、比品质、看实力

2025 年2月21日至24日

北京·中国国际展览中心（顺义新国展二期）

1. 现拆现装四辆热销新车

影响电车性能的关键零部件同台比较

2.供应商产品大PK

新车拆装供应链产品、同类参展供应链产品

供应链上中下游同台竞技

3. 25个核心零部件现拆现装

华为智能驾驶全面升级，释放“无图智驾”全新潜力

现在，我们向热爱探究的你发出邀请：

你最想拆解哪一款车？

#DGS-SLAM

首个基于高斯点云建图的动态SLAM框架！动态环境的挑战何解？​

近年来，基于 NeRF（神经辐射场）的体素表示作为一种有前途的地图表示方式得到了关注，它能够实现高精度的场景重建。这些方法捕获了环境中的稠密光度信息，使得从新视点生成高质量的图像成为可能。在这些进展的基础上，高斯点云建图（Gaussian Splatting）作为一种新颖的体素技术脱颖而出。与 NeRF 等射线匹配方法不同，高斯点云建图采用了 3D 基元的微分光栅化技术，大大提高了重建质量和渲染速度。

高斯点云建图支持高效且精确的地图表示，同时降低了计算开销，使其成为 SLAM 应用中的一种有吸引力的选择。然而，尽管具有上述优势，大多数现有方法仍假设环境是静态的，这在动态场景中会导致精度下降和性能退化。因此，克服这一限制对于将高斯点云建图 SLAM 应用于真实场景至关重要。

另一方面，一些传统的 SLAM 方法已经发展出应对复杂动态环境挑战的技术。这些方法利用了语义分割先验、光流和残差优化等技术来滤除运动物体。尽管这些方法在减轻动态元素影响方面取得了一定成功，但它们也存在局限性。例如，依赖语义先验的方法在真实场景中经常受到分割误差和伪影的影响，而残差优化在面对大幅度的物体移动时往往失效。此外，传统的动态 SLAM 系统通常难以生成详细的场景表示。

为了同时解决动态环境的挑战以及传统动态 SLAM 方法的局限性，一种动态高斯点云建图SLAM：DGS-SLAM[1] 被设计旨在将高斯点云建图与稳健的动态过滤过程相结合，从高斯初始化到联合优化，全流程处理动态物体。我们充分利用高斯点云建图的内在特性，确保在动态环境中具备鲁棒性和效率。

在此框架下，额外提出了一种稳健的掩模生成方法，通过确保关键帧之间的光度一致性，提高动态物体移除的准确性。该方法能够可靠地区分场景中的动态和静态元素，减少分割误差和伪影（如阴影）的影响。我们还提出了一种基于高斯点云唯一关键帧 ID 的循环感知窗口选择策略，从而实现跨越先前关键帧的联合优化。这进一步增强了框架在动态环境中回访场景时的定位准确性。

DGS-SLAM 在多个动态 SLAM 基准上，在相机跟踪和新视点合成方面达到了最先进的性能，证明了其在真实动态场景中处理问题的有效性。​

具体方法

DGS-SLAM 方法如图 2 所示，与现有的高斯点云建图 SLAM 类似，该系统在高斯地图初始化后包含前端的跟踪过程和后端的建图过程。DGS-SLAM 同时优化相机位姿 ，并在动态元素移除的情况下重建 3D 高斯点云，从一系列 RGB-D 帧输入 ​

高斯点云建图

系统采用高斯点云作为地图表示。每个各向异性的高斯  由其 RGB 颜色 、均值位置 、协方差矩阵  和不透明度 

其中 

按照 3D 高斯点云建图，每个 3D 高斯点云通过光栅化为 2D 的斑点，支持场景重建和位姿估计的梯度传递。我们将  个高斯按深度排序，并将其与像素 

深度渲染采用与颜色渲染类似的公式：

位姿跟踪

在前端的跟踪过程中，我们通过最小化输入帧与渲染结果之间的差异来优化相机位姿 。具体来说，对于每一输入帧 ，通过预测位姿  渲染出对应的颜色和深度结果 。为提高位姿估计的准确性，需要剔除动态元素。

动态元素过滤

1. 语义分割掩模生成：我们使用现成的在线实例视频模块【38】生成动态物体的语义分割掩模 ，标识出场景中的动态区域。
2. 不透明度掩模生成：通过不透明度检查生成 ，用于过滤掉映射过程中未填充的空间。
3. 综合掩模生成：将分割掩模和不透明度掩模结合，生成跟踪掩模 ：

其中，

位姿优化
通过最小化以下损失函数来优化当前帧 

其中：​

•  是渲染图像与输入图像之间的光度残差：

• 

•  是渲染深度与输入深度之间的残差：

• 

通过这种方式，DGS-SLAM 能够在过滤动态元素的同时，稳健地优化相机位姿，从而实现高精度的跟踪性能。​

循环感知关键帧管理

关键帧选择
在优化输入帧  的相机位姿  后，我们根据以下标准形成一个包含关键帧的优化窗口 ，以便联合优化高斯点云  和相机位姿 ，其中 ：

1. 高斯点云共视性：我们通过当前帧  与上一个关键帧 

则当前帧被注册为关键帧。

1. **相对位姿 **：如果当前帧与上一个关键帧之间的平移和旋转差异超过预定义阈值，则当前帧被选为关键帧。
2. 唯一关键帧 ID：为维护一致的窗口长度，我们基于类似的标准移除过时的关键帧。

循环感知关键帧插入
当窗口 

1. 关键帧 ID 的分配：为每个生成的高斯点云  分配其来源帧的唯一关键帧 ID，记为 。
3. 循环检测与插入：通过当前帧  中可见的高斯点云 ，检测到与过去帧的循环部分。被识别的循环关键帧 

4. 

这种循环感知关键帧插入策略确保了被移除的关键帧仍然能够通过与当前帧的循环检测，保持全局高斯地图的连续性和一致性。​

建图过程

在建图过程中，DGS-SLAM 实现了动态环境下高斯点云的插入、裁剪和优化，从而构建稠密的 3D 地图，同时保证高效性和准确性。​

高斯点云插入与初始化

• 初始高斯插入
  在相机跟踪和建图过程开始之前，我们使用第一帧输入数据初始化 3D 高斯点云。具体步骤如下：

1. 利用输入帧的深度图  和颜色图 ，计算初始场景的深度对齐值：
   其中  是估计深度， 和 
2. 使用深度补洞技术，完成初始场景的稠密深度信息填充。
4. 将动态元素剔除后，利用以下公式初始化高斯点云的 3D 坐标 ：

5. 

6. 其中 
   
   初始化优化
   初始高斯通过以下损失函数进行优化：

7. 

优化完成后，DGS-SLAM 生成了一组基础高斯点云。

• 增量插入
  在后续的关键帧添加过程中，新生成的高斯点云通过公式计算位置，并以更稀疏的方式插入到现有地图中。每个高斯的尺度按照场景的中位深度调整，从而保证内存效率。

高斯点云裁剪

为了提升效率和减少冗余，系统采用高斯点云裁剪策略：

• 高斯稠密化与裁剪：遵循现有方法，对新增高斯点云进行稠密化，同时移除冗余或无用的高斯点云。

稳健掩模生成

• 问题：在线分割技术在真实环境中可能存在误差，例如动态元素导致的遮挡或伪影。
• 解决方案：在窗口优化过程中，生成稳健掩模以剔除异常值。具体步骤如下：

1. 计算光度残差直方图：
   通过直方图 
3. 设置残差阈值  以区分内点与异常值：

4. 

6. 使用归一化核  对掩模进行平滑，生成稳健掩模：

7. 

窗口优化

在后端建图中，通过窗口优化对 3D 高斯点云和相机位姿进行联合优化。优化目标函数如下：

其中：

通过上述过程，DGS-SLAM 实现了动态环境中高效的稠密场景重建，同时确保了地图的精度与一致性。​

实验效果

总结一下

我们提出了 DGS-SLAM，这是首个动态高斯点云建图 SLAM 框架。该方法不仅在跟踪和建图阶段处理动态元素，还贯穿于整个高斯点云建图系统，确保稳健的位姿跟踪和高斯点云重建。此外，为实现精确的定位与建图性能，我们引入了一种基于光度残差的稳健掩模生成方法。进一步地，我们提出的基于回环的关键帧管理策略能够通过与过去帧的回环，确保高斯地图的一致性。我们的方法在两个典型动态数据集上的性能达到了基于辐射场的 SLAM 方法的最先进水平。

#FilterVit , DropoutVIT

全新注意力机制！改进 MobileViT变体~

在本研究中，作者提出了一种改进的MobileViT变体，该变体在降采样阶段的早期阶段执行基于注意力的QKV操作。直接在高分辨率特征图上执行QKV操作由于其大尺寸和大量 Token 而计算上非常耗时。

为了解决这个问题，作者引入了一种使用卷积神经网络（CNN）生成重要性 Mask （Filter Mask）的滤波注意力机制，该 Mask 用于选择注意力计算中最有信息量的像素。

具体来说，卷积神经网络对特征图的像素进行评分，并按这些评分对像素进行排序，以选择前个像素（在不同网络层中，的值不同）。这种方法有效地减少了参与注意力计算的 Token 数量，从而降低了计算复杂性并提高了处理速度。

此外，作者发现重要性 Mask 具有可解释性，因为模型更关注对结果至关重要的图像区域。

实验结果显示，作者的模型在提高参数效率和计算速度的同时，也实现了高精度的提升。

与其他模型相比，作者的方法在降低计算资源消耗的同时，保持了高性能。

I Introduction

视觉 Transformer （ViT）[1]通过引入基于 Transformer 的架构，对计算机视觉领域进行了革新。ViT利用注意力机制在16x16图像块上进行操作，实现对图像的全局上下文学习。然而，尽管ViT在各种任务上都能实现最先进的结果，但其对大粒子的依赖使其在应用于高分辨率图像时计算成本高昂。QKV操作[2]的二次复杂性意味着，增加粒子的数量会极大地增加计算负担。

为解决此问题，MobileViT [3] 作为一种轻量级的 ViT 版本，在降采样图像后进行注意力计算。这减少了参与注意力的 Token 数量，从而提高了计算效率。然而，MobileViT 通过在降采样特征图（例如，56x56 或 28x28）上操作，牺牲了细粒度，这可能限制了其捕捉更细微细节的能力。此外，并非所有像素对最终预测做出相同贡献。许多像素是噪声或无关的，而其他像素对于决策至关重要。

在本文中，作者提出了一种名为FilterVit的移动ViT的新变体，该变体允许在不进行早期下采样的情况下实现更细粒度的注意力。作者的方法利用卷积神经网络（CNN）生成一个重要性 Mask ，该 Mask 确定特征图中的哪些像素对于注意力最为相关。通过按像素重要性分数对齐并选择前K个像素，作者仅对图像的最重要部分执行注意力，从而降低了QKV操作的计算复杂性。

不同于在GPU上实现稀疏矩阵操作的挑战性任务，作者的方法通过直接选择重要像素提供了一个实际解决方案。这确保了计算负载的降低，同时保持了准确性。

此外，作者的方法具有可解释性，重要性 Mask 突出了模型在注意力过程中关注的图像关键区域。例如，在羊的图片中，该 Mask 有效地突出了羊的轮廓，同时忽略了无关的背景特征。

总之，作者的贡献有三个方面：

1. 作者提出了一种轻量级、更高效的注意力机制，可以在减少计算复杂度的同时实现更细粒度的注意力。
2. 作者的方法天生具有可解释性，因为它专注于图像中最相关的区域，这一点可以通过重要性 Mask 的视觉化进行证明。
3. 通过一次消融研究，作者引入了DropoutVIT，这是作者模型的一个变体，通过随机选择像素来模拟dropout，进一步验证了作者的方法的可扩展性和鲁棒性。

II Related Work

Vision Transformers

视觉 Transformer （ViT）[1]通过将注意力机制应用于图像块（通常为16x16块），在计算机视觉任务上取得了显著成功。

尽管ViT在捕捉图像中的全局依赖关系方面表现出色，但其QKV操作的二次复杂度[2]构成了计算挑战，尤其是在高分辨率图像方面。随着图像分辨率的增加， Token 的数量迅速增加，导致计算成本显著提高。​

MobileViT

MobileViT [3] 针对这个问题，通过在应用基于 Transformer 的注意力之前对图像进行下采样来解决。

通过在较小分辨率（例如，56x56或28x28）上执行注意力，可以减少 Token 的数量，从而降低计算复杂性。然而，这种下采样牺牲了注意力的细粒度，当注意力应用于较低分辨率的特征图时，可能错过一些细微的细节。​

Efficient Attention Mechanisms

几种基于注意力的模型已经被提出以优化计算复杂性。Longformer [4] 采用稀疏注意力机制，限制注意力在每一个 Token 周围的一个局部窗口，从而减少了计算负载，但在图像中可能难以捕捉全局依赖性。

Performer [5] 使用基于核的方法近似softmax注意力，实现了与序列长度成正比的线性复杂度，这是减少视觉任务中注意力成本的有前景的方法。Linformer [6] 进一步通过将 Key和Value 映射到较低维数来降低复杂度，在保持线性复杂度的同时节省了内存。Reformer [7] 引入局部敏感哈希（LSH）来近似注意力空间中的最近邻居，使计算更高效，尽管当需要高度详细的结构时，这种方法可能面临挑战。​

Lightweight Convolutional Architectures

除了注意力机制外，轻量级卷积架构也被开发出来以平衡效率和性能。MobileNetV2 [8] 引入了反向残差模块以优化信息流，所需参数更少。MobileNetV3 [9] 对此进行了改进，通过神经架构搜索（NAS）设计出高效的结构，优化了延迟和准确性。 

EfficientNet [10] 通过平衡深度、宽度和分辨率来扩展网络，实现了跨配置的最优性能。GhostNet [11] 通过生成更少的特征图来减少特征图冗余，从而提高速度并减少参数数量。最后， LCNet [12] 专注于实现低复杂度的卷积操作，以实现更快的推理时间，同时保持合理的准确性，使其非常适合边缘计算任务。​

Filter Attention Mechanism

作者的工作在这些进展的基础上，引入了Filter Attention机制。与那些降采样或线性化注意力计算的模型不同，作者的方法使用由卷积神经网络生成的滤波器 Mask ，选择性地将注意力应用于最重要的像素。根据像素的重要性对像素进行排序，并选择前K个像素，从而减少了QKV计算中涉及的 Token 数量。

这保持了全局上下文，同时显著降低了计算复杂度，而没有牺牲注意力粒度。作者的方法还具有可解释性，因为可视化滤波器 Mask 可以显示模型有效地关注图像的最相关部分。​

III Method​

Structure

在作者提出的网络架构中，作者将卷积层与 transformer 层相结合，以实现局部特征提取和全局注意力的平衡。作者方法的关键创新在于引入了一种 Filter Attention 机制，该机制可以选择性地关注特征图中的重要区域，从而显著降低基于注意力的计算复杂性。

网络通过卷积神经网络（CNN）处理输入图像，产生特征图。这一特征图被视为一组可 Reshape 的 Token ，通过Transformer Encoder [2]进行传递。与传统注意力机制不同，作者的Filter Attention根据卷积神经网络生成的过滤 Mask 选择性地识别重要 Token ，从而减少在注意力计算中使用的 Token 数量。

这种机制使模型能够忽略图像中不相关的区域，因为并非每个像素对最终预测的贡献相等。理论上，某些像素可能表示噪声或无用的细节，甚至在有用的像素中，它们对预测的贡献也不是均匀的[13]。​

Filter Attention Block

作者的方法的核心是Filter Attention块，该块将卷积块与transformer编码器集成在一起。关键思想是将特征图中的像素视为transformer编码器的token，但不是处理所有token，而是应用一个滤波器 Mask 来选择最重要的几个。

首先，通过卷积神经网络（CNN）模块对图像进行处理，生成一个特征图。CNN同时也产生一个卷积 Mask ，为每个像素分配重要性分数。然后，特征图与 Mask 进行逐元素乘法操作，以过滤掉不太重要的 Token ，公式表示如下：

在这里，表示元素乘法，这确保了只有最相关的像素被保留下来进行进一步的基于注意力的计算。

接下来， 会被 Reshape 成一个适合 Transformer 结构的形状 ，其中 ，其中  是过滤后选定的 Token 数量。过滤后的 Token 通过一个 Transformer 编码器 [2] 传递，产生输出 。

过滤注意力机制（FilterAttention mechanism）详细描述如下。通过计算重要性图并应用Transformer Encoder，该机制能够选择性地关注特征图中最有信息量的像素。这种方法在降低计算复杂度的同时，保留了关键的空间信息。​

Inverted Residual Block

在作者的网络中，作者采用倒置残差模块[8]来提高特征提取的同时保持模型效率。这个模块首先扩展输入通道，应用逐点卷积，然后将输出投影回原始尺寸，创建一个残差连接。这种结构确保了重要空间信息的保留，同时减少了模型中的参数数量，使其在小型和大型视觉任务上具有计算效率。​

Global Self-Attention with Pooling

为了进一步降低注意力机制的计算复杂度，作者在将特征图输入自注意力层之前对其进行平均池化。池化降低了输入特征图的空间维度，从而降低了进入注意力模块的 Token 数量，从而减小了QKV操作的二次成本。尽管进行了这种减少，但全局上下文仍得到保持，确保模型仍能捕捉到图像中最相关区域之间的长期依赖关系。​

Transformer Encoder

选自过滤后的特征图的 Token 被传递给Transformer Encoder [2]进行处理。transformer层应用自注意力机制来捕获 Token 之间的全局依赖关系。通过transformer之后， Token 被 Reshape 回其原始的空间维度，并经过后续的CNN层进行进一步的优化。

最后，输出特征图用于分类或其他下游任务，利用从图像中提取的局部和全局信息。​

IV Experiment

作者使用五个不同的img-100子集进行了实验，每个子集都从ImageNet-1K数据集[14]中随机采样。本文中呈现的结果基于第一个img-100子集。为确保公平比较，所有模型的训练设置和超参数都采用了统一的设置。

本文研究中使用的五个img-100子集的具体类别选择已在GitHub  https://github.com/BobSun98/FilterVIT 中提供，以供参考和可重复性。​

Dataset

img-100子集是从ImageNet-1K数据集[14]中的100个随机选择的类别构建的。在这些子集上进行训练和验证。每个模型在这些五个不同的子集上进行训练，以提高鲁棒性和减少过拟合，确保报告的结果不会因特定子集的选择而产生偏差。较小的img-100数据集允许更快地进行原型设计和算法验证，同时仍然在减少过拟合方面具有挑战性。如果轻量级模型在较小数据集上表现良好，那么它们具有更好的泛化能力的潜力。

Iv-A1 Data Augmentation

为提高所有模型的泛化能力，作者在训练过程中应用了统一的数据增强技术。这些技术包括：随机缩放（224）以随机缩放和调整图像大小至224x224像素，水平翻转（RandomHorizontalFlip）以随机水平翻转图像，引入广泛变化性的简单增强（TrivialAugmentWide [15]）以及使用[0.5, 0.5, 0.5]均值和[0.5, 0.5, 0.5]标准差的归一化。在验证阶段，图像被缩放到256x256像素，然后进行中心裁剪至224x224像素，使用与之前相同的均值和标准差值进行归一化。​

Training and Hyperparameters

所有模型都使用相同的超参数进行训练。将批量大小设置为64，学习率为0.0005，该学习率使用余弦退火计划[16]衰减至最小学习率1e-5。

使用AdamW优化器[17]训练模型120个周期，其中β1设置为0.9，β2设置为0.999，权重衰减为0.01。学习率调度器CosineAnnealingLR的最大周期为120个周期，最小学习率1e-5。​

Hardware Configuration

训练在特斯拉P40 GPU上进行。在CUDA上的性能（以帧每秒（FPS）为单位）在RTX 4090 GPU上测量，而CPU性能则在苹果M1 Pro芯片上评估。这些硬件配置允许对每个模型在高性能和资源受限环境下的效率进行比较。​

V Experiment

作者使用来自ImageNet-1K数据集[14]的五种不同的img-100子集进行了实验。本文中呈现的结果基于第一种img-100子集。为了确保公平比较，所有模型的训练设置和超参数都采用了统一的设置。

本文研究中使用的五种img-100子集的具体类别选择已在GitHub上提供，以便参考和可重复实现：https://github.com/BobSun98/FilterVIT。​

Dataset

从ImageNet-1K数据集中的100个随机选择的类别构建了img-100子集[14]。在这些子集上进行了训练和验证。每个模型都在五个不同的子集中进行训练，以提高鲁棒性和降低过拟合，确保报告的结果不因特定子集的选择而产生偏差。较小的img-100数据集允许更快的原型设计和算法验证，同时仍然具有减少过拟合的挑战。如果轻量级模型在较小的数据集上表现良好，那么它们具有更好的泛化潜力的可能性更大。

V-B1 Data Augmentation

为了提高所有模型的泛化能力，作者在训练过程中应用了统一的数据增强技术。这些技术包括：随机缩放（224）以随机缩放和裁剪图像至224×224像素，随机翻转（水平方向）以随机翻转图像，引入广泛的增强变化[15]（TrivialAugmentWide），以及使用[0.5,0.5,0.5]的平均值和[0.5,0.5,0.5]的标准差进行归一化。在验证阶段，图像被重新缩放到256×256像素，然后进行中心裁剪至224×224像素，使用与之前相同的平均值和标准差值进行归一化。​

Models and Baselines

为了评估作者提出的FilterMobileViT的有效性，作者将它与几种 Baseline 模型进行比较，这些模型代表了高效神经网络领域的各种架构。这些包括MobileNetV2[8]，以其倒置残差块和线性 Bottleneck 而闻名，以及MobileNetV3[9]，它通过神经架构搜索和硬Swish激活函数改进了其前身。作者还包括EfficientNet-Lite0[10]，该模型在网络深度、宽度和分辨率之间实现最佳效率平衡，以及GhostNet[11]，它通过减少特征图中的冗余来提高计算性能。

除了卷积架构，作者还与轻量级的Transformer模型进行了比较，例如TinyViT[18]，这是一种专为高性能和较少的参数设计的小型视觉Transformer，以及LeViT[19]，这是一种结合卷积和Transformer层的混合模型，用于高效的推理。作者还包括了TinyNet[20]，这是一个优化小型参数大小和计算成本的模型家族，以及LCNet[12]，它在轻量级卷积网络设计中优先考虑速度。最后，MobileViTS 被纳入其中，因为它将Transformer层集成到一种适合移动设备架构中，类似于作者的方法。

这些模型被选中，以在不同的架构策略之间进行全面比较，突出作者FilterMobileViT在准确性和效率方面的优势。​

Training Details

所有模型均使用一致的超参数进行训练：批量大小为64，使用AdamW优化器[17]（，，权重衰减为0.01）。初始学习率设置为0.0005，并在遵循余弦退火计划[16]后衰减到最小值，在120个epoch后完成。CosineAnnealingLR被用作学习率调度器，个epoch。训练在Tesla P40 GPU上进行，推理性能则分别测量在CUDA的RTX 4090 GPU和CPU上的Apple M1 Pro芯片上。这些配置允许对不同硬件环境下的模型效率进行全面比较，从高性能GPU到资源受限的CPU。​

Experimental Results

表1显示，FilterMobileViT在准确性和计算效率之间取得了很好的平衡。仅需189万参数，其准确率达到了0.861，超越了除Tiny-ViT[18]之外的大多数模型。Tiny-ViT的准确率略高0.876，但参数数量更多（10.59M）。这表明尽管Tiny-ViT的性能略好，但FilterMobileViT在模型大小方面提供了更高效的解决方案，使其更适合在资源受限的环境中部署。

滤波移动ViT在每秒帧数（FPS）方面也表现出竞争力的性能。尽管它在CPU和CUDA平台上略逊于像LCNet_100这样的模型，后者的FPS更高，但LCNet在速度和准确性之间更注重速度，导致准确性为0.808，而滤波移动ViT在速度和准确性之间实现了更好的折中，保持了高准确性和合理的计算效率。

此外，与轻量级模型如MobileNetV2[8]和GhostNet[11]相比，FilterMobileViT不仅减少了参数数量，还提高了准确性。例如，MobileNetV2具有235万参数，准确率为0.833，而GhostNet具有402万参数，实现了0.842的准确率。这种改进凸显了作者在选择性关注图像最具有信息性的区域方面，Filter Attention机制的有效性，从而在不增加计算成本的情况下实现了更好的性能。

在推理速度方面，尽管EfficientNet_Lite0和MobileNetV3_Small在CUDA上的FPS更高，但与FilterMobileViT相比，它们的准确率较低。这进一步突显了作者方法在实现平衡性能方面的优势，该性能适用于在准确性和效率均为核心需求的应用场景中。

总的来说，FilterMobileViT证明，将Filter注意力机制整合进来可以显著提高准确率和效率，在领域内超越了几个现有的模型。它的参数量较少且速度竞争力强，使其成为具有吸引力的选项，可以在计算资源有限的设备上部署。

例如，[21]提出了注意力展开方法，用于可视化注意力图，提供了模型在预测过程中关注的地方的洞察。同样，[22]开发了通过聚类其学习特征来分析ViTs内部表示的技术。此外，Vit-CX [13]利用ViTs的最后一层表示，并采用聚类来表示模型的关注区域。在作者的实验中，作者发现FilterVIT天生具有可解释性，无需额外的可视化技术。

为了更好地理解FilterMobileVit的行为，作者可视化了每个Filter Attention层生成的滤波器 Mask 。这是通过在预训练模型的测试图像集上进行推理，并提取不同层上的滤波器 Mask 来实现的。然后，这些 Mask 被重新缩放以匹配原始图像的大小，并叠加在输入图像上，以提供模型关注区域清晰的可视化表示[23]。

在第一个滤波器注意力层中，模型倾向于同时关注前景和背景，有时会突出物体的边缘。这表明第一层负责识别图像的广泛和一般特征。随着作者深入到第二个层，关注点更多地转向图像的主要目标或前景，说明模型已经开始优化其注意力并集中关注最显著的特征。在第三个和最后一个层中，注意力转向背景，可能是为了优化整体上下文，并确保无关区域得到适当的加权。

这段合作行为表明，过滤注意力机制不仅选择计算重要区域，还帮助模型在不同粒度上理解图像。通过逐步优化其注意力从边缘到主要物体再到背景，过滤移动Vit在其决策过程中表现出可解释性，如图5所示。

这些观察结果表明，模型的滤波 Mask 并非任意设置，而是反映了一种理解图像的结构性方法。每个层都贡献了图像的独特方面，使模型能够有效地在前景物体和更广泛的环境之间平衡注意力。这种分层注意力结构不仅提高了性能，还提供了模型处理视觉信息的方式的更可解释的理解，同时验证了设计正确性。​

Ablation Study: DropOutVIT

在本研究中，作者介绍了一种名为DropOutVIT的FilterVIT模型的变体。DropOutVIT与FilterVIT之间的关键区别在于模型如何选择像素进行注意力计算。FilterVIT利用CNN生成的过滤器 Mask 来确定性选择最重要的像素，而DropOutVIT用一种随机取样的方法替换了这种机制，即在每次训练步骤中，随机选择一部分像素通过Transformer Encoder。这可以被认为类似于在注意力计算中应用dropout，引入了选择过程的一定程度的随机性[24]。

DropOutVIT的背后的理由是探索随机取样像素是否能导致相似或改进的性能，从而防止对特定特征的过度拟合。通过引入随机性，作者假设模型可能在大规模训练阶段之前（FilterVIT的滤波器 Mask 尚未完全优化）表现更好，特别是泛化能力。

V-1 DropOutVIT vs. FilterVIT

作者在几个训练运行中比较了DropOutVIT和FilterVIT的性能（见图6）。最初，两种模型表现出相似的性能，甚至在前几个epoch中，DropOutVIT的表现略好于FilterVIT。这可能归因于随机采样过程中选择的特征的多样性增加，这可能潜在地防止了过拟合。

然而，随着训练的进行，DropOutVIT似乎在第50个周期左右达到了性能的平稳期，而FilterVIT继续改进。

这种现象的一个可能解释是，FilterVIT中的CNN逐渐学会了生成更有意义的滤波器 Mask ，这使得模型能够专注于计算最重要的像素以进行注意力计算。这种精炼的选择过程可能使得FilterVIT能够实现更好的整体性能，因为模型越来越受益于有针对性的注意力。

#为什么4090速度比A100快很多呢？

（长文预警）这是一个好问题。先说结论，大模型的训练用 4090 是不行的，但推理（inference/serving）用 4090 不仅可行，在性价比上还能比 H100 稍高。4090 如果极致优化，性价比甚至可以达到 H100 的 2 倍。

事实上，H100/A100 和 4090 最大的区别就在通信和内存上，算力差距不大。

NVIDIA 的算力表里面油水很多，比如 H100 TF16 算力写的是 1979 Tflops，但那是加了 sparsity（稀疏）的，稠密的算力只有一半；4090 官方宣传 Tensor Core 算力高达 1321 Tflops，但那是 int8 的，FP16 直只有 330 Tflops。这篇文章的第一版就是用了错的数据，H100 和 4090 的数据都用错了，得到的结论非常离谱。

H100 这个售价其实是有 10 倍以上油水的。

2016 年我在 MSRA 的时候，见证了微软给每块服务器部署了 FPGA，把 FPGA 打到了沙子的价格，甚至成为了供应商 Altera 被 Intel 收购的重要推手。2017 年我还自己挖过矿，知道什么显卡最划算。后来在华为，我也是鲲鹏、昇腾生态软件研发的核心参与者。因此，一个芯片成本多少，我心里大概是有数的。

鲲鹏的首席架构师夏 Core 有一篇知名文章《谈一下英伟达帝国的破腚》，很好的分析了 H100 的成本：

据说微软和 OpenAI 包下了 H100 2024 年产能的一半，猜猜他们会不会发挥当年跟 Altera 砍价的传统艺能？会真的花 $40,000 * 500,000 = 200 亿美金去买卡？

可以说，H100 就像是中国一线城市的房子，本身钢筋水泥不值多少钱，房价完全是被供求关系吹起来的。我在 LA 已经住了两周，公司租的房子使用面积是我北京房子的 4 倍，但售价只贵了 30%，还带个小院，相当于单位面积的房价是北京的 1/3。我跟本地的老外聊天，他们都很吃惊，你们的平均收入水平比 LA 低这么多，怎么买得起北京的房子的？

问题来了，如果 4090 这么香的话，为啥大家还要争着买 H100，搞得 H100 都断货了？甚至 H100 都要对华禁售，搞出个 H800 的阉割版？​

大模型训练为什么不能用 4090

GPU 训练性能和成本对比

LambdaLabs 有个很好的 GPU 单机训练性能和成本对比，在此摘录如下。

首先看吞吐量，看起来没有什么违和的，在单卡能放下模型的情况下，确实是 H100 的吞吐量最高，达到 4090 的两倍。看算力和内存也能看出来，H100 的 FP16 算力大约是 4090 的 3 倍，内存带宽是 3.35 倍，训练过程中由于 batch size 比较大，大多数算子是 compute bound（计算密集型），少数算子是 memory bound（内存密集型），这个结果是不意外的。

LambdaLabs PyTorch 单卡训练吞吐量对比图

LambdaLabs PyTorch 单卡训练吞吐量对比表

然后看性价比，就有意思了，原来排在榜首的 H100 现在几乎垫底了，而且 4090 和 H100 的差距高达接近 10 倍。这就是因为 H100 比 4090 贵太多了。

由于 H100 货源紧张，云厂商的 H100 租用价格就更黑了，按照标价大约 7 个月就可以回本。就算大客户价能便宜一半，一年半也足够回本了。

在价格战中过惯了苦日子的 IaaS 云服务商看到这样的 H100 回本速度，估计要感叹，这真是比区块链挖矿回本还快呐。

LambdaLabs PyTorch 单卡训练单位成本吞吐量对比图

LambdaLabs PyTorch 单卡训练单位成本吞吐量对比表​

大模型训练的算力需求

既然 4090 单卡训练的性价比这么高，为啥不能用来做大模型训练呢？抛开不允许游戏显卡用于数据中心这样的许可证约束不谈，从技术上讲，根本原因是大模型训练需要高性能的通信，但 4090 的通信效率太低。

大模型训练需要多少算力？训练总算力（Flops）= 6 * 模型的参数量 * 训练数据的 token 数。

我今年初第一次看到有人煞有介事地讲这个公式的时候，觉得这不是显然的吗？又看到 OpenAI 的高级工程师能拿 90 多万美金的年薪，顿时整个人都不好了，还是 AI 香呀。之前我也面试过一些做 AI 的工程师，包括一些做 AI 系统优化的专家，连 Q、K、V 是啥都说不清楚，LLaMA 每个 tensor 的大小也算不出来，就这样还能拿到 offer。

APNet 2023 panel 的主题是 Network, AI, and Foundational Models: Opportunties and Challenges。前面几个问题都中规中矩的，panelists 有点放不开，我就提了一个问题，网络历史上的重要成就基本上都基于对应用场景深刻的理解，但我们现在做网络的很多都不了解 AI，甚至连每个 tensor 的大小和每个 step 传输的数据量都不知道，如何让 network community 更了解 AI 呢？

这下热闹了，台下的谭博首先发言，说我在华为肯定能知道所有这些东西；然后传雄老师也跟了一句，要是做网络的懂了太多 AI，那可能他就变成一个 AI guy 了。接着主持人陈凯教授问，你们有谁真的训练过大模型？沉默了一会儿，阿里的兄弟先说，我算是半个训练过大模型的，我们做的东西是支撑阿里大模型 infra 的。后面又有 panelist 说，做 AI 系统的网络优化是否有必要自己懂 AI 呢，是不是只要会做 profiling 就行了？

我个人观点仍然是，AI 并不难学，要想做好 AI 系统优化，可以不懂 attention 的 softmax 里面为什么要除以 sqrt(d_k)，但不能不会计算模型所需的算力、内存带宽、内存容量和通信数据量。Jeff Dean 就有个很有名的 Numbers Every Programmer Should Know，数量级的估算对任何系统优化来说都很关键，不然根本不知道瓶颈在哪里。

回到大模型训练所需的总算力，其实很简单，6 * 模型的参数量 * 训练数据的 token 数就是所有训练数据过一遍所需的算力。这里的 6 就是每个 token 在模型正向传播和反向传播的时候所需的乘法、加法计算次数。

一堆矩阵相乘，简单来想就是左边若干个神经元，右边若干个神经元，组成一个完全二分图。选出其中任意一个左边的神经元 l 和右边的神经元 r，正向传播的时候：

1. 把它的输出乘上 l 和 r 之间的权重 w，发给 r；
2. r 不可能只连一个神经元吧，总要把多个 l 的加到一起，这就是 reduce，需要一次加法。

反向传播的时候：

1. r 把它收到的梯度乘上 l 和 r 之间的权重 w，发给 l；
2. 也不可能只连一个 r，需要把梯度 reduce 一下，做个加法；
3. 别忘了权重 w 需要更新，那就要计算 w 的梯度，把 r 收到的梯度乘上 l 正向传播的输出（activation）；
4. 一个 batch 一般有多个 sample，权重 w 的更新需要把这些 sample 的梯度加到一起。

一共 3 次乘法，3 次加法，不管 Transformer 多复杂，矩阵计算就是这么简单，其他的向量计算、softmax 之类的都不是占算力的主要因素，估算的时候可以忽略。

想起来我 2019 年刚加入 MindSpore 团队的时候，领导让我开发一个正向算子的反向版本，我求导给求错了，搞得算子的计算结果总是不对，还以为是我们的编译器出 bug 了。当发现求导求错的时候，领导像以为我没学过微积分一样看着我，确实我的微积分学的不好，这也是我从数学专业转到计算机专业的原因之一。

在 MindSpore 的时候，自动微分一共就不到 1000 行代码，按照微分公式递归计算下去就行了，但自动微分作为一个重要特性被吹了半天，我都感觉不好意思了。

模型的参数量和训练数据的 token 数之间也有个比例关系，这也很容易理解，只要把模型想象成数据的压缩版本就行了，压缩比总是有极限的。模型的参数量太小，就吃不下训练数据里面所有的知识；模型的参数量如果大于训练数据的 token 数，那又浪费，还容易导致 over-fitting。​

训练 LLaMA-2 70B 需要多少张卡

有了模型训练所需的总算力，除以每个 GPU 的理论算力，再除以 GPU 的有效算力利用比例，就得到了所需的 GPU-hours，这块已经有很多开源数据。LLaMA 2 70B 训练需要 1.7M GPU hours（A100），要是用 1 个 GPU，那得算 200 年。要在一个月这种比较能接受的时间周期内训练出来，就得至少有 2400 块 A100。

如果用 4090，单卡 FP16 算力是跟 A100 差不多（330 vs 312 Tflops），但是内存带宽比 A100 低一半（1 vs 2 TB/s），内存容量更是差好几倍（24 vs 80 GB），计算梯度时需要使用的 TF32 算力也低一半（83 vs 156 Tflops），综合起来 4090 单卡的训练速度还比 A100 稍低（参考前面 LambdaLabs 的评测）。

就按照 2048 块 4090 算吧，这 2048 块 4090 之间的通信就成了最大的问题。

为什么？一般有 tensor parallelism、pipeline parallelism、data parallelism 几种并行方式，分别在模型的层内、模型的层间、训练数据三个维度上对 GPU 进行划分。三个并行度乘起来，就是这个训练任务总的 GPU 数量。

三种并行方式从三个维度划分计算空间的示意图，来源：DeepSpeed

Data parallelism（数据并行）

数据并行是最容易想到的并行方式。每个 GPU 分别计算不同的输入数据，计算各自的梯度（也就是模型参数的改变量），再把梯度汇总起来，取个平均值，广播给各个 GPU 分别更新。

Data Parallelism 示意图，来源：Colossal AI

但只用数据并行是肯定不行的，因为一块 GPU 放不下整个 LLaMA 70B 模型。

就模型训练需要多少 GPU 内存，我发现能算清楚的人就不多。有的人甚至以为只需要把模型的参数和反向传播的梯度存下来就够了。事实上，训练需要的内存包括模型参数、反向传播的梯度、优化器所用的内存、正向传播的中间状态（activation）。

优化器所用的内存其实也很简单，如果用最经典的 Adam 优化器，它需要用 32 位浮点来计算，否则单纯使用 16 位浮点来计算的误差太大，模型容易不收敛。因此，每个参数需要存 4 字节的 32 位版本（正向传播时用 16 位版本，优化时用 32 位版本，这叫做 mixed-precision），还需要存 4 字节的 momentum 和 4 字节的 variance，一共 12 字节。如果是用类似 SGD 的优化器，可以不存 variance，只需要 8 字节。

正向传播的中间状态（activation）是反向传播时计算梯度必需的，而且跟 batch size 成正比。Batch size 越大，每次读取模型参数内存能做的计算就越多，这样对 GPU 内存带宽的压力就越小。可是不要忘了，正向传播的中间状态数量是跟 batch size 成正比的，GPU 内存容量又会成为瓶颈。

大家也发现正向传播中间状态占的内存太多了，可以玩一个用算力换内存的把戏，就是不要存储那么多梯度和每一层的正向传播的中间状态，而是在计算到某一层的时候再临时从头开始重算正向传播的中间状态，这样这层的正向传播中间状态就不用保存了。如果每一层都这么干，那么就只要 2 个字节来存这一层的梯度。但是计算中间状态的算力开销会很大。因此实际中一般是把整个 Transformer 分成若干组，一组有若干层，只保存每组第一层的中间状态，后面的层就从该组第一层开始重新计算，这样就平衡了算力和内存的开销。

如果还是算不清楚，可以读读这篇论文：Reducing Activation Recomputation in Large Transformer Models。

当然有人说，GPU 内存放不下可以换出到 CPU 内存，但是就目前的 PCIe 速度，换出到 CPU 内存的代价有时候还不如在 GPU 内存里重算。如果是像 Grace Hopper 那种极高带宽的统一内存，那么换入换出倒是一个不错的主意，不管训练的正向传播中间状态还是 KV Cache，都有很多优化的空间。

Pipeline parallelism（流水线并行）

既然一块 GPU 放不下，用多块 GPU 总行了吧？这就是 model parallelism（模型并行），可以大致分为 pipeline parallelism 和 tensor parallelism。

大家最容易想到的并行方式就是 pipeline parallelism，模型不是有很多层吗，那就分成几组，每组算连续的几层，穿成一条链。

Pipeline Parallelism 示意图，来源：Colossal AI

这样就有个问题，一条链上只有一个 GPU 在干活，剩下的都在干等。当然聪明的你一定也想到了，既然叫 pipeline，那就可以流水线处理，可以把一个 batch 分为若干个 mini-batch，每个 mini-batch 分别计算。

Pipeline Parallelism 示意图，来源：GPipe

这可好，是不是把 pipeline 搞的越深越好，每个 GPU 只算一层？

首先，正向传播中间状态（activation）的存储容量会成倍增加，加剧内存容量不足的问题。比如流水线的第一级算出了正向传播的中间状态，如果有 N 个流水级，那就要正向流过后面的 N - 1 个流水级，再等反向传播 N - 1 个流水级，也就是 2N - 2 轮之后才能用到这个正向传播的中间状态。不要忘了每一轮都会产生这么多中间状态，因此一共是保存了 2N - 1 个中间状态。如果 N 比较大，这个存储容量是非常恐怖的。

其次，pipeline 的相邻流水级（pipeline stage）之间是要通信的，级数越多，通信的总数据量和总时延就越高。

最后，要让这样的 pipeline 流起来，batch size 需要等于 Transformer 里面的层数，一般是几十，再乘以 data parallelism 的并行数，batch size 会很大，影响模型收敛的速度或模型收敛后的精度。

因此，在内存容量足够的情况下，最好还是少划分一些流水级。

对于 LLaMA-2 70B 模型，模型参数需要 140 GB，反向传播的梯度需要 140 GB，优化器的状态（如果用 Adam）需要 840 GB。

正向传播的中间状态跟 batch size 和选择性重新计算的配置有关，我们在算力和内存之间取一个折中，那么正向传播的中间状态需要 token 长度 * batch size * hidden layer 的神经元数量 * 层数 * (10 + 24/张量并行度) 字节。假设 batch size = 8，不用张量并行，那么 LLaMA-2 70B 模型的正向传播中间状态需要 4096 * 8 * 8192 * 80 * (10 + 24) byte = 730 GB，是不是很大？

总共需要 140 + 140 + 840 + 730 = 1850 GB，这可比单放模型参数的 140 GB 大多了。一张 A100/H100 卡也只有 80 GB 内存，这就至少要 24 张卡；如果用 4090，一张卡 24 GB 内存，就至少需要 78 张卡。

LLaMA-2 模型一共就只有 80 层，一张卡放一层，是不是正好？这样就有 80 个流水级，单是流水线并行就有 80 个并行的 batch 才能填满流水线。

这样，正向传播的中间状态存储就会大到无法忍受，这可是 80 * 2 = 160 轮的中间状态，翻了 160 倍。就算是使用选择性重新计算，比如把 80 层分成 8 组，每组 10 层，中间状态存储仍然是翻了 16 倍。

除非是用最极端的完全重新计算，反向传播到每一层都重新从头开始计算正向传播的中间结果，但这样计算开销可是随模型层数平方级别的增长，第 1 层算 1 层，第 2 层算 2 层，一直到第 80 层算 80 层，一共算了 3240 层，计算开销可是比正常算一次 80 层翻了 40 倍，这还能忍？

中间状态存储的问题就已经够大了，再看这 2048 张卡之间的通信开销。按照一张卡放一层，并且用不同的输入数据让它完全流水起来的做法，这 2048 张卡分别在计算自己的 mini-batch，可以认为是独立参与到 data parallelism 里面了。前面讲过，在数据并行中，每一轮需要传输的是它计算出的梯度和全局平均后的梯度，梯度的数据量就等于模型的参数数量。

把 70B 模型分成 80 层，每一层大约有 1B 参数，由于优化器用的是 32 bit 浮点数，这就需要传输 4 GB 数据。那么一轮计算需要多久呢？总的计算量 = batch size * token 数量 * 6 * 参数量 = 8 * 4096 * 6 * 1B = 196 Tflops，在 4090 上如果假定算力利用率 100%，只需要 0.6 秒。而通过 PCIe Gen4 传输这 4 GB 数据就已经至少需要 0.12 秒了，还需要传两遍，也就是先传梯度，再把平均梯度传过来，这 0.24 秒的时间相比 0.6 秒来说，是占了比较大的比例。

当然我们也可以做个优化，让每个 GPU 在 pipeline parallelism 中处理的 80 组梯度数据首先在内部做个聚合，这样理论上一个 training step 就需要 48 秒，通信占用的时间不到 1 秒，通信开销就可以接受了。当然，通信占用时间不到 1 秒的前提是机器上插了足够多的网卡，能够把 PCIe Gen4 的带宽都通过网络吐出去，否则网卡就成了瓶颈。假如一台机器上插了 8 块 GPU，这基本上需要 8 块 ConnectX-6 200 Gbps RDMA 网卡才能满足我们的需求。

最后再看 batch size，整个 2048 张卡的集群跑起来，每个 GPU 的 mini-batch 我们刚才设置为 8，那可真是 batch size = 16384，已经是大规模训练中比较大的 batch size 了，如果再大，可能就影响模型的收敛速度或收敛后的精度了。

因此，单纯使用流水线并行和数据并行训练大模型的最大问题在于流水线并行级数过多，导致正向传播中间状态（activation）存储容量不足。

Tensor parallelism（张量并行）

那就没办法了吗？我们还有最后一招，就是 Tensor parallelism（张量并行）。它也是模型并行的一种，但不像流水线并行那样是在模型的层间划分，而是在模型的层内划分，也就是把一层内的 attention 计算和 Feed Forward Network 划分到多个 GPU 上处理。

有了张量并行，就可以缓解 GPU 放不下模型导致的流水级太多的问题。分到 80 个 GPU 才能放下的模型，如果用单机 8 卡张量并行，就只需要划分 10 个流水级。同时，张量并行还可以降低 batch size，因为张量并行的几个 GPU 是在算同一个输入数据。

Tensor、Pipeline、Data 三种并行方式从模型层内、模型层间、训练数据三个维度上划分计算空间，来源：DeepSpeed

Attention 的计算过程是比较容易并行的，因为有多个 head，用来关注输入序列中的不同位置的，那么把这些 head 分别拆开就行了。

Attention 的计算过程，来源：The Illustrated Transformer

但是我们做任何并行计算的时候都不要忘记通信开销。

每个 head 里面的 Q、K 两个矩阵的大小是 batch size * token 长度 * key 的大小，V 矩阵的大小是 batch size * token 长度 * value 的大小。key/value 的大小一般等于 embedding size / heads 数量，例如在 LLaMA-2 70B 中就是 8192 / 64 = 128，矩阵大小是 batch size * 4096 * 8192 / 64（注意，这只是一个 head 的）。而 Q、K、V 参数矩阵在每个 head 上的大小是 embedding size * embedding size / heads num = 8192 * 8192 / 64。

我们前面推导过，正向的计算量基本上就是每个 token 过一遍所有参数的计算量，2 * 3 (Q, K, V) * batch size * token 长度 * 参数个数 = 2 * 3 * batch size * 4096 * 8192 * 8192 / 64。可以跟矩阵的大小对一下，看看有没有算错。

那么通信量是多少呢？输出矩阵 Z 是由每个 head 拼起来的，每个 head 的大小是 batch size * token 长度 * embedding size / heads num = batch size * 4096 * 8192 / 64。输入矩阵 X 的大小是 batch size * token 长度 * embedding size = batch size * 4096 * 8192。注意这里的 X 大小跟所有 heads 合并在一起后的 Z 大小是一致的，而我们在这里算的是每个 head 的 Z 大小。这里的单位是参数数量，如果按照字节算，还要乘以每个参数的大小。

如果我们采用最极端的方式，每个 head 交给一个 GPU 去算，那么计算量和通信量的比例是多少？大概是 2 * 3 * embedding size / heads num / bytes per param = 2 * 3 * 8192 / 64 / 2 = 384。代入 4090 的 330 Tflops，如果想让通信不成为瓶颈，那么通信带宽至少需要是 330T / 384 = 859 GB/s，发送接收双向还得乘以 2，就是 1.7 TB/s。太大了，远远超过 PCIe Gen4 x16 的 64 GB/s，就算 NVLink 的 900 GB/s 都撑不住。

所以，tensor parallelism 不能切得太细，每个 GPU 需要多算几个 heads。如果每个 GPU 多算几个 attention heads，输入矩阵 X 就是这些 heads 共享的了，因此输入矩阵的通信开销就被多个 heads 平摊了，计算量和通信量的比例就可以提高。

还是按照 4090 的算力 / 单向通信带宽 = 330T / (64GB/s / 2) 来算，计算量和通信量的比例最少需要是 10000，也就是 2 * 3 * (embedding size / 张量并行 GPU 数量) / bytes per param = 2 * 3 * 8192 / 张量并行 GPU 数量 / 2 >= 10000，解得：张量并行 GPU 数量 <= 2.4。也就是告诉你，要是用了张量并行，最多用 2 个 GPU，如果用更多的 GPU，算力就肯定跑不满理论值。这让我怎么玩？

但是，如果把 H100 的参数代入进去，马上就不一样了。H100 的峰值算力是 989 Tflops，NVLink 双向带宽是 900 GB/s，计算量和通信量的比例最少需要是 1100，也就是 2 * 3 * (embedding size / 张量并行 GPU 数量) / bytes per param = 2 * 3 * 8192 / 张量并行 GPU 数量 / 2 >= 1100，解得：张量并行 GPU 数量 <= 11，也就是单机 8 卡做张量并行，对于 embedding size = 8192 的模型，刚刚好，通信不会成为瓶颈！

阉割版的 H800 相比 H100 卡的就是网络带宽，把网络带宽从 900 GB/s 降到 400 GB/s 了。我们再代入一次，计算量和通信量比例最少需要是 5000，那么张量并行 GPU 数量 <= 4.8。这样单机 8 卡做张量并行，就会导致网络成为瓶颈。当然，计算量 989 Tflops 是理论值，并行切分方式也可以优化，因此实际训练 70B 的模型 8 卡 H800 网络不一定真的是瓶颈。这就是 H800 精准打击大模型训练，让张量并行过得不舒服。

Feed Forward Network 的计算过程，虽然这是 encoder 的，但 decoder 也差不多，来源：Step-by-Step Illustrated Explanations of Transformer

如果在 Feed Forward Network 这里做张量并行，也是可以做类似的推导，在这里就不赘述了。大凡神经网络里的矩阵乘法，MN 的矩阵乘上 NK 的矩阵，总的计算量是 MNK，输入输出的总大小是 (MN + NK)，多摞几个矩阵那也是常数（就像 Q、K、V），也就是计算和通信的比例跟矩阵的边长（dimension）是一个量级的。

这么分析完了，如果你是要做大规模大模型训练，你还会买 A100/H100/H800 的 PCIe 版吗？PCIe Gen5 虽然比 Gen 4 快一倍，但对 H100 而言，计算量和通信量的比例仍然最少需要是 989T / (128G / 2) = 15000，解出来张量并行 GPU 数量 <= 1.6，也就是只要用了张量并行，就是损失算力的！

等到 H100 的下一代出来了，比如 GH200，算力又翻了一倍，NVLink 还是 900 GB/s，这时候 NVLink 就也开始有点吃力了。所以 GH200 不失时机的推出了统一大内存，号称 144 TB，就是为了更好的做换入换出，用内存换网络通信。如果禁令保持不变，国内版本还是卡住 400 GB/s 的通信，那性能差距会有多大？

上面的推导当然都是简化的，实际上可能不会这么夸张，但数量级是差不多的。​

训练部分小结

4090 不容易做大模型训练的原因除了前面分析的内存小，通信慢，license 不支持数据中心，还有很多其他问题。

比如，A100/H100 支持 ECC 显存容错，据说 4090 也支持 ECC，但是不知道故障率会不会比 A100/H100 更高。不要小看了容错，2048 张卡的集群就算每张卡 1 个月出一次故障，平均 20 分钟就会有一张卡出故障！要是没有自动化的故障恢复方式，炼丹师就别想睡觉了。

就算是自动从上一个 checkpoint 恢复，这可是要时间的，如果不考虑丢弃故障 GPU 梯度这种比较暴力的方式，当前这个 step 就算是白算了，还要从上一个 checkpoint 加载梯度，一般需要 10 来分钟的时间才能搞定。这样，每 20 分钟就浪费 10 分钟，这 10 分钟恢复过程中可能又有新的卡故障，总的算下来要浪费掉一半的有效算力。

因此，保持大规模训练集群的低故障率是非常重要的，这些 GPU 卡都非常金贵，可不能像挖矿机房那样，动不动就过热死机了。

据说 3090 是支持 NVLink 的，但 4090 就把 NVLink 给砍掉了。更老的卡，甚至还有支持 PCIe P2P 的，现在也都被砍掉了。谁感兴趣可以测一测 3090 的 NVLink 性能怎么样，是不是真的能达到标称的 600 GB/s，如果真的能达到的话，是否又可以用来做大模型训练了呢。

我们年会的时候，海哥讲了个段子，我们找老婆都希望又漂亮，又能挣钱，还一心一意爱自己。可同时满足这三个条件的老婆就很难找到了。类似的，在分布式系统中，我们都希望性能又高，通用性又强，成本还低。这三个条件的交集也很小。海哥讲到这里，谭博补充了一句，同时满足这三个条件的分布式系统根本就不存在。

Tensor、Pipeline、Data Parallelism 就像是这样的不可能三角，相互牵制，只要集群规模够大，模型结构仍然是 Transformer，就很难逃出内存容量和网络带宽的魔爪。​

大模型推理为什么 4090 很香

推理和训练有什么区别？

首先，训练不仅需要存储模型参数，还需要存储梯度、优化器状态、正向传播每一层的中间状态（activation），后面几个比参数更大，对模型内存的需求量也更大。

其次，训练任务是一个整体，流水线并行的正向传播中间结果是需要存下来给反向传播用的。为了节约内存而使用流水线并行，流水级越多，要存储的中间状态也就更多，反而加剧内存的不足。而推理任务中的各个输入数据之间并没有关系，正向传播每一层的中间状态也不需要保存下来，因此流水线并行不需要存储很多中间状态。

首先我们需要计算一下推理需要多少算力。前面针对训练算力的估算，为了简单起见，忽略了两个事情，首先是没有考虑 KV Cache，其次是没有考虑内存带宽。​

KV Cache

什么是 KV Cache？对于每个输入的 prompt，在计算第一个 token 输出的时候，每个 token 的 attention 肯定是都要从头计算。但是在后续 token 的生成中，都需要计算 self-attention，也就是输入 prompt 以及前面输出的 token 的 attention。这是就需要用到前面每一个 token 的 K 和 V，由于每一层的参数矩阵是不变的，此时只有刚生成的那个 token 的 K 和 V 需要从头计算，输入 prompt 和之前生成的 token 的 K 和 V 其实是跟上一轮一样的。

这时，我们就可以把每一层的 K、V 矩阵缓存起来，生成下一个 token 的时候不再需要重新计算，这就是所谓的 KV Cache。Q 矩阵每次都不一样，没有缓存的价值。前面讲的训练中的选择性保存正向 activation 是个拿计算换内存的把戏，这里的 KV Cache 就是一个拿内存换计算的把戏。

KV Cache 需要多少存储容量呢？每一层，每个 token 的 K、V 矩阵都是 embedding size 这么大，再乘上 token 数量和 batch size，就是这一层的 KV Cache 所需的存储容量了。一定要记住 batch size，在正向和反向传播的几乎所有阶段，都不会涉及到对 batch size 中各个 sample 的合并处理，因此它始终是存储量和计算量计算中的一个系数。

例如，如果 batch size = 8，在 LLaMA 2 70B 中，假设输入和输出的 token 数量达到了模型的极限 4096，80 层的 KV Cache 一共需要 2 (K, V) * 80 * 8192 * 4096 * 8 * 2B = 80 GB。如果 batch size 更大，那么 KV Cache 占据的空间将超过参数本身占的 140 GB。

KV Cache 能省下来多少计算量？每一层计算 K、V 矩阵一共需要 2 (K, V) * 2 (mult, add) * embedding size * embedding size = 4 * 8192 * 8192 这么多计算量，乘以之前输入过的 token 数量、层数和 batch size，就是 4096 * 80 * 8 * 4 * 8192 * 8192 = 640 Tflops。相当于每存储 1 个字节，节约了 16K 次计算，还是很划算的。

事实上，KV Cache 节约的远远不止这些。计算 K、V 矩阵的过程是个典型的内存密集型过程，它需要加载每一层的 K、V 参数矩阵。也就是如果不做任何缓存，假设 prompt 长度很短而输出长度接近 token 的最大长度 4096，到了最后一个 token 的时候，单是重复计算前面每个 token 的 K、V 矩阵，就需要读取内存 4096 * 80 * 2 * 8192 * 8192 = 40T 次，每次 2 个字节，要知道 H100 的内存带宽只有 3.35 TB/s，4090 更是只有 1 TB/s，这单是最后一个 token 就得耗掉一张卡几十秒的时间来做重复计算。这样，token 的输出就会越来越慢，整个输出时间是输出长度平方级别的，根本没法用。​

推理是计算密集还是存储密集

接下来我们就可以计算推理所需的计算量了。总的算力很好算，前面讲过，大概就是 2 * 输出 token 数量 * 参数数量 flops。如果想看细节，可以看下面这张图，来源是这里。

Transformer 推理过程中每一步的矩阵形状、所需算力和内存访问量，来源：Lequn Chen，Dissecting Batching Effects in GPT Inference

但算力并不能说明一切，模型还需要访问 GPU 内存，内存带宽也可能成为瓶颈。至少需要把参数从内存里面读出来吧？事实上，内存带宽的估算就这么简单，内存访问量 = 参数数量 * 2 bytes。中间结果有一部分是可以放在缓存里面的，缓存放不下的部分也需要占内存带宽，我们先不算。

如果不做任何批量输入，也就是模型专门服务一个 prompt，batch size = 1，整个 context 的长度很短（例如只有 128），那么整个推理过程中，每载入一个参数（2 字节），就只进行 128 次乘法和加法计算，那么计算 flops 和访问内存 bytes 的比例就只有 128。基本上任何 GPU 在这种情况下都会变成 memory bound，时间都耗在加载内存上了。

对于 4090 来说，计算 flops 和内存带宽之比是 330 / 1 = 330；对于 H100 来说，计算 flops 和内存带宽之比是 989 / 3.35 = 295。也就是说，如果 context 中的 token 数量小于 330 或者 295，那么内存访问就会成为瓶颈。

虽然 LLaMA 2 的理论上限是 4096 个 token，但很多输入 prompt 用不了这么多，因此内存访问是有可能成为瓶颈的。此时，就需要靠 batch size 来补足了。推理中的批量处理，就是把几乎同时到达后端服务的 prompt 放到一起处理。不用担心，batch 里面的不同 prompt 的处理是完全独立的，不用担心会互相干扰。但这些 prompt 的输出是步调整齐划一的，每一轮整个 batch 中的每个 prompt 都会输出一个 token，因此如果有的 prompt 先输出完了，那就只能等其他的输出结束，造成一定的算力浪费。

有的人问，批量处理所需的算力跟分别单独处理所需的算力是一样的呀，那推理时为什么需要批量处理？答案就在访问内存的带宽上。

如果同时到达服务器的 prompt 很多，是不是 batch size 越大越好？也不是，因为 KV Cache 的大小可是正比于 batch size 的，batch size 大了，KV Cache 占据的 GPU 内存容量就很可观，比如在 LLaMA-2 70B 中，每个 prompt 都要占据 5 GB 的 KV Cache，如果 batch size 搞到 32，那么 KV Cache 就会占掉 160 GB 的 GPU 内存，比参数都大了。​

70B 推理需要多少张卡？

总的存储容量也很好算，推理的时候最主要占内存的就是参数、KV Cache 和当前层的中间结果。当 batch size = 8 时，中间结果所需的大小是 batch size * token length * embedding size = 8 * 4096 * 8192 * 2B = 0.5 GB，相对来说是很小的。

70B 模型的参数是 140 GB，不管 A100/H100 还是 4090 都是单卡放不下的。那么 2 张 H100 够吗？看起来 160 GB 是够了，但是剩下的 20 GB 如果用来放 KV Cache，要么把 batch size 压缩一半，要么把 token 最大长度压缩一半，听起来是不太明智。因此，至少需要 3 张 H100。

对于 4090，140 GB 参数 + 40 GB KV Cache = 180 GB，每张卡 24 GB，8 张卡刚好可以放下。​

推理用流水线并行可以吗？

推理使用流水线并行，最主要的问题是串行处理的推理延迟，网络延迟倒是小问题。

首先是推理延迟。虽然流水线的不同阶段可以塞进不同的 prompt，但同一个 prompt 的处理仍然永远在单个 GPU 上轮转，这样相比 Tensor parallelism 而言，单个 prompt 的延迟就增大了。

对于很小的 batch size，GPU 内存带宽是瓶颈，此时每张卡计算每个 token 的时延就是 2 byte * 参数量 / 卡的数量 / 内存带宽，例如 8 卡 4090 跑 LLaMA-2 70B，就是 2 * 70G / 8 / 1 TB/s = 0.0175 秒。这里没有考虑 KV Cache 带来的节约。注意，8 张卡是串行处理的，因此每个 token 的时延还要乘以 8，也就是 0.14 秒。每秒只能输出 7 个 token，对于 70B 这么小的模型来说是有点慢了。

对于很大的 batch size，GPU 算力是瓶颈，此时每张卡计算每个 token 的时延就是 batch size * 2 * 参数量 / 卡的数量 / 算力，例如 batch size = 1024，同样的 8 卡例子，就是 1024 * 2 * 70G / 8 / 330 Tflops = 0.0543 秒。事实上，对于这么大的 batch size，KV Cache 和正向传播的中间结果先把 GPU 内存给吃满了。

那么要平衡利用 GPU 算力和内存带宽，batch size 需要是多少呢？这就是 2 byte * 参数量 / 卡的数量 / 内存带宽 = batch size * 2 * 参数量 / 卡的数量 / 算力，左右两边参数量和卡的数量互相抵消，得到 batch size = 算力 / 内存带宽。对于 4090，就是 330 / 1 = 330；对于 H100，就是 989 / 3.35 = 295。也就是说，对 4090 而言，batch size 小于 330 的时候 GPU 内存带宽是瓶颈，大于 330 的时候 GPU 算力是瓶颈。当 batch size = 330 的时候，理想情况下，内存带宽和算力恰好都打满，每张卡处理每个 token 的时间就是 17.5 ms。

其次是网络延迟。流水线并行相比张量并行的优点就是网络传输量小，流水级之间只需要传输 batch size * embedding size 这么多数据。例如 batch size = 8，embedding size = 8192，只需要传输 128 KB 数据，在 32 GB/s 的 PCIe Gen4 x16 上，只需要 4 us 就可以传输完成。当然，还需要考虑到通信库本身的开销，加上 4090 不支持 GPU 之间 P2P 传输，需要通过 CPU 中转，实际上需要几十 us 的时间，相比计算部分动辄几十 ms 的时延，可以忽略不计。

即使 batch size = 330，这 5.28 MB 数据在 PCIe 上也只需要传输 0.16 ms，相比计算部分的 17.5 ms 仍然可以忽略不计。

如果可以忍受流水线并行的推理延迟，甚至可以用多台主机来做流水线并行。我们假设主机间只有 1 Gbps 的普通以太网络，每台主机只有一张 4090。对于 batch size = 1，16 KB 数据需要 0.25 ms 才能传输完成，再加上 0.25 ms 两端网络协议栈的处理时间，每个流水级就需要 0.5 ms 的时延，8 张卡花在通信上的时间只有 4 ms，相比整体计算时延 140 ms 来说可以忽略，不会显著影响系统的推理延迟。

当 batch size 很小时，流水线推理中的网络流量是突发性（bursty）的，每过 18 ms 只会进行 0.25 ms 数据传输，只有 1/72 的占空比，不用担心流水线推理把局域网全部给占满了，搞得没法正常上网了。

如果为了充分利用算力，把 batch size 设置得很大，比如 330，那么 16 KB * 330 = 5.28 MB 数据需要传输 41 ms，8 张卡花在通信上的时间高达 0.33 秒，这样就只有 3 token/s 的输出速度了，难以忍受。因此，如果用主机间通信来做流水线并行，主机间又没有很高的通信带宽，就势必需要牺牲一定的吞吐量。

例如，我们设置输出速度不小于 5 token/s，这时留给通信的时间是 60 ms，每个流水级至多 7.5 ms，1 Gbps 网络可以传输 960 KB 数据，这时 batch size 至多设置为 60，也就是这 8 张 4090 的总吞吐量是 2400 token/s。此时的有效算力利用率只有不到 20%。

最近有一个比较火的 Petals 开源项目，就是利用流水线并行，把 GPU 做成了一个类似 BitTorrent 的分布式网络。虽然推理延迟确实比较高，但至少说明了分布式 GPU 推理的可行性。​

推理用张量并行怎么样？

前面讲到，流水线并行的最大缺点是 GPU 串行处理，延迟较高，导致输出 token 比较慢。而张量并行的最大缺点是传输数据量大，网络带宽低的设备不一定 hold 得住。

但是推理要传输的数据量跟训练要传输的数据量可不是一回事啊！推理只需要传输正向传播的中间结果（activation），而训练还需要传输所有参数的梯度，梯度才是数据量的大头。

在推理中，如果使用张量并行，Transformer 的每一层都需要传输把自己负责的结果向量（大小为 batch size * embedding size / num GPUs）广播给其他所有 GPU，并接受来自所有其他 GPU 广播来的数据。计算 attention 的时候需要传输一次，计算 feed-forward network 的时候又需要传输一次，也就是总共需要传输 2 * 层数这么多次。

每次发送就是 batch size * embedding size（发送和接收是不同的方向，不能算两次），对于 batch size = 1, embedding size = 8192，只需要传输 16 KB 数据，在 32 GB/s 的 PCIe Gen4 上传输只需要 1 us。当然，考虑到前面讨论的 CPU 中转开销，还是需要大约 30 us 的。一共 160 次传输，需要 4.8 ms。

我们再考虑计算的开销。还是考虑 batch size = 1 的情形，GPU 内存带宽是瓶颈，此时每张卡计算每个 token 的时延就是 2 byte * 参数量 / 卡的数量 / 内存带宽，代入我们前面的数值，仍然是 17.5 ms。但是这里 8 张卡是并行处理的，因此总的处理时长就是计算时间 + 通信时间 = 17.5 ms + 4.8 ms = 22.3 ms。这就意味着每秒可以生成 45 个 token，这个 token 生成速度已经很不错了，至少人类的阅读速度是很难赶上生成的速度了。

如果 batch size 更大会怎样？例如 batch size = 330，把 GPU 算力和内存带宽都充分利用起来，每次需要传输的数据量是 330 * 8192 * 2 = 5.4 MB，在 32 GB/s 的 PCIe Gen4 上需要 0.17 ms。一共 160 次传输，就是 27 ms。这下网络通信开销成了延迟的大头，总处理时长为 27 + 17.5 = 44.5 ms，每秒只能生成 22 个 token 了，但也不算慢。

注意，不管用多少个 GPU 做并行推理，只要用的是张量并行，网络传输的总数据量是相同的，因此增加 GPU 的数量只能加速计算，不能加速通信。

因此，A100/H100 的 NVLink 在降低推理延迟方面还是有很大作用的。如果用 H100，取 batch size = 295 达到算力和带宽的平衡利用，这 4.72 MB 数据只需要 4.72 MB / 450 GB/s = 0.01 ms。一共 160 次传输，也只有 1.6 ms。由于内存带宽大了，计算时间也可以大幅缩短，例如 H100 的计算时间为 2 * 70G / 8 / 3.35 TB/s = 5.2 ms。总处理时长只有 5.2 ms + 1.6 ms = 6.8 ms，每秒可以生成 147 个 token，非常棒！

可以说，如果论单个 prompt 的 token 生成速度，无论用多少块 4090 也追不上 8 卡 H100。​

用 4090 做推理的成本怎么样？

对于推理，不管用流水线并行还是张量并行，batch size 不算高到太离谱的情况下内存带宽都是瓶颈。

假如 batch size 能够高到把算力 100% 利用起来，并且还能解决 KV Cache 不够大的问题，能解决中间结果占用内存过多的问题，那么这 8 张 4090 可以达到多少吞吐量？

当然，这两个问题都不好解决，因此推理优化才是一个热门的研究领域，存在很多的 trade-off 和奇技淫巧。如果只是用标准的 PyTorch，那推理性能距离把算力 100% 利用起来还远得很呐。

假设都解决了，在张量并行的通信过程中我们可以利用 double buffer 做另外一个 batch 的计算，也就是计算和通信并行，进一步提高吞吐量。通信和计算分别是 27 ms 和 17.5 ms，传输的 27 ms 是瓶颈，也就是每 27 ms 输出一组 token，一个 batch 330 个 prompt，那这 8 张 4090 真是可以达到每秒 330 / 0.027 = 12.2K token 的吞吐量。

8 张 4090 的成本是 12800 美金，8 卡 PCIe Gen4 服务器本身要 2 万美金，加上网络设备，平均每台 4 万美金的设备成本。固定资产按照 3 年摊销，每小时 1.52 美元。整机功耗大约 400W * 8 + 2 kW = 5 kW，按照 0.1 美元一度电算，每小时 0.5 美元。一个机架可以放 4 台这样的 8 卡服务器，数据中心机柜租用成本（不含电费）一个月 1500 美元算贵的了，合每小时 0.5 美元。这 2.5 美元一小时的机器，满打满算能生成 12.2K * 3600 = 44M tokens，也就是说 1 美元能生成 17.6M tokens。

是不是比 GPT-3.5 Turbo 的 $0.002 / 1K tokens，也就是 1 美元 0.5M tokens 便宜 35 倍？当然，账不能这么算。

• 首先，GPU 的算力利用率到不了 100%；
• 其次，如同所有 SaaS 服务一样，用户的请求数量有波峰有波谷，用户是按量付费的，平台提供方可是不管有没有人用都在烧钱的；
• 此外，每个 batch 中不同 prompt 的长度和响应 token 数量都不同，消耗的算力是 batch 中最大的那个，但收的钱是用户实际用的 token 数；
• 再次，GPT-3.5 是 175B 的模型，比 70B 的 LLaMA 很可能推理成本更高；
• 最后，OpenAI 开发 GPT-3.5 是烧了不知道多少钱的，人家至少要赚回训练成本和研发人员的工资吧。

其实 GPT-3.5 Turbo 的 $0.002 / 1K tokens 真的挺良心的，有的卖 API 的，LLaMA-2 70B 都敢比 GPT-3.5 Turbo 卖得贵。

如果换成用 H100 做推理，重新算一下这笔账。一张 H100 至少要 3 万美金，一台 8 卡 H100 高配服务器加上配套的 IB 网络，起码要 30 万美金，同样按照 3 年摊销，每小时 11.4 美元。10 kW 功耗，电费每小时 1 美元。一个普通供电和散热的机架只能放 2 台 8 卡 H100，机柜租用成本（不含电费）还按 1500 美元算，合每小时 1 美元。一共 13.4 美元一小时。

这其实已经是非常良心的价格了，你在任何云服务商都不可能租得到这么便宜的 8 卡 H100。所以说从云服务商租卡卖没有护城河的 SaaS 服务，比如开源模型的推理 API，除非有一种提高推理性能的独门绝技，很难赚得了什么大钱，二房东的生意不是这么好做的。

再算算这台 8 卡 H100 机器的吞吐量，张量并行也采用传输和计算并行，H100 的通信比较快，因此计算是瓶颈，每 5.2 ms 可以输出一组 token，一个 batch 295 个 prompt，满打满算可以达到每秒 295 / 0.0052 = 56K token 的吞吐量。理想情况下，一小时能生成 204M tokens，也就是 1 美元能生成 15.2M tokens，H100 单位 token 的成本比 4090 仅仅高 16%，可以算打个平手吧。

为什么 8 卡 H100 机器是 4090 机器生命周期价格的 5 倍，性价比却跟 4090 差不多？因为一张 H100 的算力是 4090 的 3 倍，内存带宽是 4090 的 3.35 倍，不管按延迟还是按带宽算，单卡的性能就基本上是 3 倍。而且，H100 比 4090 的网络带宽强太多了，导致 4090 在张量并行中网络通信成了瓶颈，浪费了有效算力。因此，同样的 8 卡机器吞吐量可以达到 4090 的 4.6 倍。虽然一张 H100 卡的价格是 4090 的 20 倍以上，但算上服务器本身的成本、电费和数据中心托管费用，整机的成本只是 5 倍左右。​

用最便宜的设备搞出最高的推理性能

我们发现在 8 卡 4090 机器中，3 万美金的设备成本，GPU 卡只占了 1.28 万美金，不像 H100 机器那样 GPU 成本占了大头。还有办法进一步降低吗？

如果我们可以忍受 5 token/s 的输出速度，甚至可以利用流水线并行，用家用台式机和 4090 攒出个推理集群来。

遥想我当年在 MSRA 的时候，在一台只用 1000 美金攒出来的机器上插了 10 块 FPGA，做出个世界最快的 Key-Value Store。其实如果让我去设计一个性价比最高的 4090 推理集群，有很多种方案可以尝试：

• 用流水线并行，台式机 + 10 Gbps 网卡，足够在 5 ms 内传输 batch size = 330 的 5.28 MB 数据了，通信 40 ms，计算 140 ms，达到 5 token/s 的单 prompt 输出速度，同时又能充分利用 4090 的算力。10 Gbps 的网卡和交换机都很便宜，Intel X710 网卡只要 150 美金，20 口交换机只要 1500 美金（每 8 个口 750 美金），一台家用台式机 700 美金，这只要 2 万美金就可以搞定原本需要 4 万美金的设备。
• 用张量并行，台式机 + 200 Gbps ConnectX-6 网卡，上 RoCE，可以把 batch size = 330 的 5.28 MB 数据在 0.22 ms 内传完，160 次传输是 35 ms，加上计算的 17.5 ms，一个 token 52.5 ms，可以达到 19 token/s 的单 prompt 输出速度，这个速度已经不错了。网卡 1000 美金，200G 交换机 2 万美金 40 个端口，平均每 8 个端口 4000 美金，一台家用台式机 700 美金，这只要 3 万美金就能搞定原本 4 万美金的设备。
• 主机内用张量并行，主机间用流水线并行，4 卡 PCIe Gen4 服务器主板只要 1000 美金而且能跑满 PCIe 带宽（因为 8 卡就需要 PCIe switch 了，价格会贵很多），两台主机之间用 25 Gbps 网卡直连，主机内张量并行的时延是 27 ms，主机间流水线并行只需 2 次 8 ms 的传输（注意 25G 的网络带宽是 4 张 GPU 卡共享的），加上两次流水线计算各 17.5 ms，总共 78 ms，可以达到 13 token/s 的单 prompt 输出速度。网卡 300 美金 * 2，服务器 3000 美金 * 2，这只要 1.95 万美金就可以搞定原本需要 4 万美金的设备。

2 万美金按照 3 年摊销是每小时 0.76 美元。按照 0.1 美元/度的电价，每小时的电费都要 0.5 美元，接近设备成本了，这有点挖矿的味道了。矿场里面可没有中央空调和 UPS，只有暴力风扇，托管费用比数据中心低很多，整机的成本是有可能压到 1.5 美元/小时的。如果跑满了 44M tokens 的吞吐量，1 美元能生成 30M tokens，正好是 8 卡 H100 的 15M token per dollar 的 2 倍。

为什么 H100 以 20 倍于 4090 的 GPU 价格，性价比却只差一倍？首先是因为能耗成本更低，8 卡 H100 的功耗是 10 kW，但 9 台 8 卡 4090 的功耗是 45 kW；其次是因为主机和网络设备成本更低，一台 8 卡 H100 准系统虽然贵，但只占整机价格的 20% 左右；但 4090 因为卡多，除非像 GPU 矿机那样压成本，只要还是用数据中心级的设备，准系统价格就要占到 35% 以上。

其实，这个世界上不止有 A100/H100 和 4090，还有 A10、A40 等计算卡和 3090 等游戏卡，还有 AMD 的 GPU 和很多其他厂商的 AI 芯片。H100 和 4090 大概率都不是性价比的最优解，例如 A10、A40 和 AMD GPU 的性价比有可能就更高。

我都想搞一个推理性价比挑战赛，看谁能用最便宜的设备搞出最强的推理吞吐量，同时延迟不能太高；或者用最便宜的设备搞出最低的推理延迟，同时吞吐量不能太低。

这一切都是在假设使用 LLaMA-2 70B 模型，没有做量化压缩的前提下。如果做了量化压缩，那性能就更高，甚至在 Unified Memory 够大的 MacBook Pro 上都能单机跑了。​

License 问题怎么办？

我把这个问题放到最后。NVIDIA Geforce driver 的 License 里写道：

No Datacenter Deployment. The SOFTWARE is not licensed for datacenter deployment, except that blockchain processing in a datacenter is permitted.

既然机器都是用台式机攒起来的，这能叫 data center 吗？还是叫矿场比较合适吧。人家也说了，4090 用来做区块链是允许的。

我有一个大胆的想法，如果未来的区块链不再用挖矿来做 proof of work，而是用大模型推理来做 proof of work，这是不是很有意思？每个人买几块显卡，接到矿池上，既可以自己用来玩游戏，闲时又可以贡献算力。矿池直接就是个卖大模型推理 SaaS 服务的公司，提供前所未有的低价 API。甚至需要大模型推理服务的人可以在区块链里自己 P2P 玩起来，谁要用大模型就付点 gas。

当然，目前的 proof of work 都是计算很复杂，验证很简单的。如果真用大模型推理做 proof of work，必须防止用户随意编造一个结果交上去。当然这也是有解决方案的，就像 BitTorrent 和其他一些去中心化网络一样，采用信用机制，新人只能做验证别人计算结果的工作，积攒信用；老人每次算错了，都有比较严厉的惩罚。

从另一个角度看，家庭局域网络的速度也越来越快，比如我家就自己部署了 10 Gbps 的网络。家中的智能设备越来越多，算力越来越强。光纤入户也越来越普遍，小区和城市的运营商机房里部署了越来越多的边缘计算节点。前面我们用 1 Gbps 的网络就足以把多台主机上的 GPU 组成流水线并行，那么在未来的家庭高速网络中，流水线并行甚至张量并行都将成为可能。

大多数搞 AI 推理的都只关心数据中心，忽略了家中的分布式算力。只要解决了安全、隐私和经济动机问题，我家的 Siri，也许就跑在邻居家里的 GPU 上。

很多人都在说要 democratize AI。但现在大模型平民化的最大障碍就是成本，而成本最大的来源又是 GPU 市场上计算卡和游戏卡价格的剪刀差。这并不是指责某家公司，其他做 AI 芯片的公司，AI 芯片的算力也并不便宜。毕竟芯片、软件和生态的研发都是白花花的银子。

就像本文开头提到的微软给每台服务器部署 FPGA 一样，大规模量产的芯片价格就像沙子一样。到时候，能限制大模型推理算力的就只有能源了，就像区块链挖矿和通用 CPU 的云计算一样，都在找最便宜的电力供应。我在之前的一个采访中就表示，长期来看，能源和材料可能是制约大模型发展的关键。让我们期待廉价的大模型走进千家万户，真正改变人们的生活。

#P-Mapnet

深度揭秘量产杀器：SDMap直接暴涨20个点！

在线高精地图是当下无图NOA的算法核心，而现有的算法在大感知范围下的表现依然较差。

P-MapNet PipeLine

为此北理工&清华提出了P-MapNet，其中的“P”强调我们专注于融合地图先验以提高模型性能。具体来说，我们利用了SDMap和HDMap中的先验信息：一方面，我们从OpenStreetMap中提取了弱对齐的SDMap数据，并将其编码为单独的条件分支输入。尽管改输入与实际HD Map存在弱对齐的问题，我们基于Cross-attention机制的架构能够自适应地关注SDMap骨架，并带来显著的性能提升；另一方面，我们提出了一种用MAE来捕捉HDMap的先验分布的refine模块，该模块有助于让生成的HD Map更符合实际Map的分布，有助于减小遮挡、伪影等影响。

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

代码链接：https://jike5.github.io/P-MapNet/

结果表明，P-Mapnet在nuScenes和Argoverse2数据集上取得了相当不错的效果，尤其是在240 x 60m的超大感知范围上表现惊艳！

#端到端自动驾驶xxx

前言：端到端自动驾驶目前尚不成熟，作为做感知算法的同学，我的视角和理解也不一定很全面。我这里放一些个人理解的端到端自动驾驶的文字，希望和大家多多讨论。后续这篇文章会持续更新我对端到端的理解

端到端自动驾驶的现状1. 端到端自动驾驶是什么

• 端到端感知：输入是图像和传感器的数据，直接输出速度、tracking 结果，避免 Rule-based 的测速测距
• 感知到 Planning 的端到端：输入是图像和传感器的数据，直接输出方向盘、油门刹车的控制信号

而端到端算法又分为显式端到端和隐式端到端，显式端到端指的是类似 UniAD 那种有中间的感知结果输出的，可以用于 HMI 以及排查 corner case，隐式端到端指的是不输出中间结果，直接出控制信号，会更加的黑盒。以下讨论的感知到 Planning 的端到端，包括显式端到端和隐式端到端

2. 关于 UniAD

在 2023 年，UniAD 获得了 CVPR 2023 Best Paper，虽说不算是众望所归，但也给自动驾驶行业注入了一剂强心剂。但国内对 UniAD 的褒贬不一，这种褒贬不一不仅仅体现在感知预测规控各个人群独立的视角上。还体现在自动驾驶领域学术界和工业界的 gap，工业界的迭代真实性远高于学术界，corner case 也远多于学术界。论文里面的各个模块其实是自驾团队都会去做的事情，所以将这些串起来做端到端的创新性看起来确实没有那么革命性，不过故事确实讲的很流畅。量产的自驾团队都很看重落地性，因为预研的技术是要落到实车上才能最终体现价值。但论文里面没有提供实车数据（不包含 nuScenes）的数据和 demo，所以令人遗憾吧。以及 Planning 出身的同学经常诟病的一点是：端到端模型可解释性差，而 UniAD 又只放了开环评测的结果，所以实际效果难以令人信服

3. 关于 Tesla 的端到端

Tesla

国内自动驾驶总体还是 follower，从业者都非常关注每年的 Tesla AI Day 或者 Tesla 相关的技术报告，在感知范式、预测、规划、基建上的分享都会有新启发。个人是做感知方向的，所以见证了 BEV、Occupancy 的技术路线一经发布，在学术界卷起的新浪潮。所以在自动驾驶领域，我个人感受到的还是工业界在推着学术界往前进，而目前来看 Tesla 在这方面应该是毫无疑问的 leader。而在 2023 年，Tesla 放出来的新内容包含 World model 和 E2E，注定会成为未来几年的热门话题。但是值得我们注意的是，就算是敢于放出实车 Demo 的 Tesla，视频里的 MTBF（Mean-Time-Between-Failures） 也不过一小时左右，而 MPI（Mileage Per Intervention）也不会特别高。一众媒体宣扬的 2024 年是大家比拼端到端的一年，但我感觉今年的智驾节奏顶多是放端到端的 demo 出来，端到端模型的真正量产上实车还需要走很长的路，这其中需要踩很多坑。

更新：图森的王峰大佬对 Tesla FSD v12 演示视频做了分析：王峰：特斯拉端到端演示视频分析​

端到端自动驾驶的预期优势

优势 1：减少 rule-based 的过多后处理，系统简洁，减少人为偏见

传统的自动驾驶系统通常是分为例如感知、预测、规控等子系统，每块之间常常会有部分 Rule-based 的后处理流程，端到端自动驾驶可以做到全流程可微，系统变得相当简洁。减少了很多后处理模块例如传感器后融合的的维护成本，并且还能避免编写大量规则引入的人为偏见

优势 2：数据驱动（Software2.0）的范式去迭代模型

Software 2.0

"Software 2.0" 这个术语是由 Andrej Karpathy 提出的，简单来讲，就是以数据驱动的方式来解决问题，迭代模型。例如遇到了 Badcase，之前的模型需要先定位是规控还是感知的问题，并且有些问题只能基于规则去解。而端到端的优势是全流程可微，理想情况下，我们就可以去采集类似的数据加入训练集来解决泛化问题。​

端到端自动驾驶的挑战

挑战 1：可解释性差

深度学习黑盒模型的可解释性差

以端到端模型目前的实现方式，就是把一些小黑盒级联起来，组装一个大黑盒，可解释性实在太差。而可解释性差导致的就是端到端模型的下限不可控，我们无法预知大风吹来的塑料袋以及纸箱子会诱导模型做出怎样的决策。在之前的实车中，我们可以比较清楚的划分是感知的问题还是规控的问题，而在端到端范式下，实车的工程师们应该怎么分锅解 case 就是一个新的范式了。

可能的解决路径：

• 无法知道模型能力边界的情况下，或许还是需要手工规则去保证整个系统的下限。
• 利用语言模型来获得模型的决策动机，之前 naiyan 所写文章 中测试的 GPT-4V 其实是有这种能力的，对于提升可解释性或许有些帮助，但是否实用依然要进行仔细评估

挑战 2：评测手段不成熟，闭环训练不充分

端到端自动驾驶的评测分为云端评测和路测，路测需要大量时间去验证，云端评测可以复用之前积累下来的感知及规控的 Badcase，会更加全面和实用。但云端评测如何做到闭环是一个难题，下面介绍一下开环评测和闭环评测：

1. 开环评测：系统被置于一个不受外部反馈控制的环境中，系统的输入被改变以模拟不同的情况，但系统本身的输出不会影响评测环境。例如模型输出的 planning 指令做出了加减速动作，由于路测的感知视频是录制的，这个动作无法反映到图像上去，这导致开环评测只能在每一帧都会重置到数据集中录制那一刻的评测环境，并且是安全的轨迹，不存在误差累积。学术界最常见的就是在 nuscenes 数据集上进行开环评测。
2. 闭环评测：模型的输出会影响评测环境，同时评测环境的反馈会影响系统的输入，形成一个反馈循环。闭环评测模拟了真实世界中系统与环境的相互作用，例如自车发生变道行为，反应到图像上就是视角切换，前车切换等等，最常用的就是 Carla 模拟器。
3. 开环评测的问题最近被讨论很多了，感兴趣的可以去看 文章 1 和 文章 2，简单来讲就是不靠谱，存在数据泄露，数据分布不足，错误恢复能力差，碰撞率指标本身有问题等等

Carla 模拟器

而闭环测试的问题是什么呢，借用 文章 3 中的比喻，WorldSim（用虚拟数据做仿真）像在玩游戏，而 LogSim（用真实道路数据做仿真）则更像是电影，无法解决交互的问题。基于虚拟仿真场景的闭环评测（如 Carla），对规控会更加合适，因为仿真数据的感知图像和真实道路上存在 domain gap，这会导致无法真正获得带感知的端到端模型性能。

所以最大的难点是如何解决真实数据的云端闭环评测。具体来讲，对于每次模型做出指令后，评测环境要能够执行相应的指令，并且给出当前的各种参数，包括新视角下的感知图像，自车状态等，涉及到两方面的技术，仿真及交互。

• 仿真的一种技术路径是三维重建 + 场景编辑，能够获得简单的场景视角转换能力。但是依然是有限的，只有 planning 结果不超过所录制场景太多才有一定可用性。例如超车场景，这个指令完成后，多视角的图像里需要渲染出前车的侧面及车头，假设录制时自车就是一直跟车，是压根没见过前车的侧面及车头的，应该如何提升渲染的真实性呢。可能需要用到图形学中的渲染才能让目标更加真实，但场景偏离太多时，静态环境也会发生崩坏，是比较难解决的。另外，多视角图像渲染下，多视角及时序的一致性在复杂场景下难以保证，这也是 world model 做的不太好的地方。
• 交互的问题是如何构建合理的他车运动模型，博弈论里面假设大家都是理性人，但真实场景中的交通参与者或保守或激进，个性十足。如果他车运动模型过于单一，最终的评测性能不太可靠。

可能的解决路径：

• 对于仿真来讲：尝试图形学仿真和深度学习的仿真相结合，加入物理先验；或是利用 Sora 等生成模型，做可控的视频片段生成；
• 对于交互来讲：或许利用训好的 planner 作为他车的控车程序是可行的路径，多智能体情况下场景就会变得更复杂了。并且要注意 planner 是否有偏，他车的策略是偏保守还是偏激进，这都会对最终的评测性能有影响。

另外还想谈谈闭环训练，上述闭环评测中的问题闭环训练都有。而模型若仅在开环条件下训练，无法适应环境中的变化和未知情况，泛化性会强受限于数据场景，模型的鲁棒性会是个问题，所以闭环训练也是必需的。

其实关于闭环评测和闭环训练，可以关注 Openpilot 这个开源项目（https://github.com/commaai/openpilot），给出了参考路径以及真实的路测视频，并且用一部旧手机就可以在简单的真实场景下跑 work，还是令人惊喜的。但是对于复杂的道路场景下的量产，闭环训练和评测是我们需要重点关注的问题。另外，国内 OpenDriveLab 团队前两年就写了 Openpilot 的系列技术博客（OpenDriveLab：Openpilot EP1：Openpilot开源项目深度解析），能看到，UniAD 的成功也不是偶然。

挑战 3：Learning-based 方法对数据多样性的要求很高，并且如何引入先验

端到端模型的优势是全流程可微，基于学习的系统该有的问题他都有，简单列举两个。第一是数据多样性要求高，例如假设数采数据中自车是理性人，没有包含车辆发生碰撞等紧急场景，那模型对于这类场景学习不足，就学不到应对事故的修正能力。第二个是应该如何引入人为先验，例如不应该闯红灯，虚实车道线等交规信息就是规控的强先验，这类先验应当以何种形式加入到模型中去，以实现加速收敛和约束输出的目的。

针对这些 Learning-based 方法的固有问题，解决路径就需要非常深的业务理解了，数据仿真合成可以有效解决场景丰富度缺失的问题，如何引入先验就因人因场景而异了。

挑战 4：端到端解 corner case 的路径是否清晰

虽然我们希望端到端解 corner case 可以通过加数据来解决，这种方式有效但不可控程度较高。在模型容量有限的情况下，是否会存在遗忘现象？在端到端范式下，之前能解掉的 case 有可能会发生回退，并且可能还找不清楚回退的原因，而 rule-based 的方法能够保证 case 绝大多数场景下是不会发生回退的。所以端到端模型想要摒弃掉中间环节，那么解决 corner case 的技术路径，当前并不太明晰，或许还是需要 rule-based 来兜底。​

端到端未来到底应该怎么去做？

这边不讨论具体的模型设计，只谈端到端在落地侧怎么去发挥作用。正向来看，作为一种新的范式，好像没有什么是非得用端到端去解决的，而端到端范式本身也解决不了什么新出现的问题。但是从结果反推过程的角度去考虑，做出端到端 demo 背后所证明的事情却很多，例如数据、评测、基建已经为类似的 learning-based 方案准备好了，闭环训练测试和解 Badcase 的技术路径都尝试过了，这种经验以及在落地过程中所搭建好的平台是更为宝贵的东西。所以端到端模型可能最大的作用是促进各个厂商内部基建完善的一个契机，促进对数据驱动的理解，闭环评测，规控的 Badcase 如何流转到感知等等，这都是智驾深水区，每一块做好了都需要花功夫，这是我个人觉得大家去做端到端最有价值的地方。

非常感谢和一个学长讨论得到的观点：“L2 的产品里感知端到端效率上会更优，L4 产品需要安全冗余因此还需要考虑不同算法的失效模式，仅使用现有的端到端方法可能还不够”，并且所推荐的 mobieye 的文章 写的也很好，从产品定义角度进一步完善了我的视角。所以最终我感受到的是，端到端一种最可能的落地方向是作为冗余模型存在，产出的规控结果作为 proposal，与现有的感知-预测-规控的链路并行。为了节省算力和便于收敛，从现有链路中提取 feature 或者中间结果用于端到端模型也是应当可行。最后需要一个决策模块从并行的两个链路中选择最终用哪个 planning 的结果。

另外还要提醒大家的是，还是不要对端到端的预期过高，从几个小黑盒变成一个大黑盒，没有规则的兜底，量产实车很难有特别亮眼的表现，甚至其下限都不可控。去年校招培训中我印象非常深的一个画面是，饭桌上项目经理向我展示了各家企业路测中暴露出的 case 视频，有的对行人造成了甚至很严重的伤害。交通事故中没有受益者，这对我触动很大，在这之后有实车的机会我都会尽量去争取，去实际地感受所开发的算法真实的性能，从产品的角度感受算法稳定性和可靠性的必要，这远比在工位上看路测视频要来的真实。

我相信，我们开发的算法不会主动作恶，但我们需要意识到，我们所开发的智能驾驶系统在和具体的交通参与者在交互，那是一个个具体的鲜活的人。我们还是应该要有技术情怀和责任心，避免为了技术噱头不顾实际的人文关怀，实实在在的提高交通参与者的安全。​

参考资料

• 端到端自动驾驶算法在 nuScenes 数据集上的开环评测或许并不靠谱：https://zhuanlan.zhihu.com/p/654533840
• 开环端到端自动驾驶：从入门到放弃：https://zhuanlan.zhihu.com/p/669454065
• 2万字长文说清自动驾驶仿真的8大问题：https://zhuanlan.zhihu.com/p/604135266
• CVPR2023 rule based planning：https://www.zhihu.com/question/350679956/answer/3298582147
• 关于Planning，特别是端到端Planning：https://zhuanlan.zhihu.com/p/681400608
• GPT-4V在自动驾驶中初探：https://zhuanlan.zhihu.com/p/660940512
• Openpilot 项目：https://github.com/commaai/openpilot
• Are we on the edge of a “ChatGPT moment” for autonomous driving?：https://www.mobileye.com/opinion/are-we-on-the-edge-of-a-chat-gpt-moment-for-autonomous-driving/
• Openpilot EP1：Openpilot开源项目深度解析：https://zhuanlan.zhihu.com/p/497686355
• OpenDriveLab | 关于自动驾驶感知决策一体化架构设计思考：https://zhuanlan.zhihu.com/p/586714950
• 特斯拉端到端演示视频分析：https://zhuanlan.zhihu.com/p/68