为何全球头部自动驾驶企业均采用 VAST Data 平台

汽车行业正在演变为一个软件行业。随着高级驾驶辅助系统（ADAS）从基础的车道保持、自适应巡航，逐步演进至全自动驾驶决策能力，汽车制造厂商及其技术合作伙伴正在转型为软件定义的企业。支撑这一变革的 AI 模型复杂度大幅提升，用于模型训练、验证和持续迭代优化的数据量飞速增长，传统基础设施已完全无法承载。

在行业竞争中脱颖而出的企业，不只是在优化算法，更在重新构建支撑网联自动驾驶车辆及其生态体系的数据平台。

一台搭载多传感器的测试车辆，每天通过摄像头、激光雷达（LiDAR）、毫米波雷达、超声波传感器等产生的数据，可以高达数 TB 规模。如果将这个数据量扩展到遍布全球的海量数据采集车队，叠加相关的合成数据生成、仿真业务负载等，企业需管理的数据规模可达数百 PB 级别。

然而，ADAS 数据基础设施的难点不仅在于数据体量，更在于业务全链路访问模式的高度差异化。

原始传感器数据的采集场景，与向 GPU 集群随机推送视频片段用于模型训练的场景截然不同；针对安全关键型边缘案例运行验证工作负载所需的性能特征，与通过空中下载技术（OTA）更新将优化后的模型输出同步回车辆所需的特征，也截然不同。

不仅如此，如今平台还需承载上路行驶的智能网联车辆的实时远程信息数据处理，这些源源不断的遥测数据既会被用于分析仪表板，也为下一代模型训练提供数据源。

这条业务链路中的每个阶段，对吞吐量、延迟、数据合规治理的要求各不相同。传统架构往往迫使团队为每个场景单独搭建和维护独立的系统，造成全球研发中心严重的数据孤岛与碎片化。当数据分散在互不兼容的独立系统中，庞大的数据规模让整合变得几乎不切实际。

数据不仅规模大、还分布过散，难以在站点间、本地与云端之间高效流转。而数据碎片化导致无法建立统一“单一权威数据源”，也减缓了全球研发人员与数据科学家之间的协作效率。

最终的结果就是，企业只能拼凑搭建一套脆弱的架构：高性能计算文件系统、自行管理的对象存储、云端缓存环境，依靠各种定制 ETL（数据提取、转换、加载） 流程勉强维持。研发团队耗费大量工程精力在数据流转治理上，反而无暇优化模型本身。

行业普遍面临同样困境：早期采用 GPFS 等传统 HPC 文件系统的企业，在业务初期尚可满足需求，但数据增长至数百 PB 后，运维复杂度陡增、架构稳定性变差。

这类“无共享"并行文件系统，专为传统 HPC 模拟所需的顺序 I/O 模式设计，而不是为深度学习的随机 I/O 需求设计的。其结果是引发严重的 I/O 饥饿，即昂贵的 GPU 集群因为存储层根本无法提供足够快的数据，来确保其满负荷运转而闲置。

为了补救而硬性添加的独立 S3 兼容对象存储，又造成新的协议孤岛；面对数十亿小文件（如单帧标注视频）的元数据扩容需求，只能超额配置存储容量来规避性能瓶颈。

一家全球自动驾驶软件企业就遭遇了类似的情形。目前，该公司在本地机房与云端环境中，部署了数百颗英伟达 H100 级别 GPU、超 10 万 CPU 核心，但是其原有 GPFS 加自建的 S3 集群却无法支撑需求——在扩容时，运维复杂度会同步飙升；每一次业务扩张都意味着要管理更多系统、同步更多数据副本，还要排查更多的潜在故障点。

结果就是，存储架构跟不上公司在算力上的投入节奏， GPU 的利用率受到了严重影响。

另一家专注安全领域的 ADAS 软件厂商，则面临另一类不同但是相关联的挑战。他们的团队正在经历一次技术跨越，从基于静态图像训练感知模型，转向基于动态视频进行训练。这一转变让系统的吞吐量与数据体量同步暴增。

由于数百颗 GPU 需要由数百名数据科学家组成的庞大研究团队共享，他们的既有基础设施无法独立扩容性能以匹配业务增速。元数据的性能瓶颈频繁引发业务中断。此外，他们沿用的传统压缩算法对 JPEG、PNG 训练数据集仅能实现 1.1：1 的数据缩减，这意味着其存储成本几乎随数据量线性增长

前述这家全球自动驾驶软件企业，将其原有 GPFS 与自建 S3 集群整体迁移至 VAST Data AI OS，搭配英伟达 DGX SuperPOD，支撑 ADAS 与大模型研发，落地效果立竿见影：

如今，该企业在 VAST Data 平台上的有效容量已超 10PB，并计划两年内实现规模翻倍。其能够以厘米级精度，实现车辆间实时路况风险识别与共享的实时地图系统，如今拥有了能够匹配庞大数据增速的基础设施支撑。

另一家专注安全的 ADAS 软件厂商同样收获显著收益：

企业在多个数据中心部署 VAST Data 集群后，借助 VAST DataSpace 全局快照功能，无需进行数据复制就能在各地之间共享完整的数据集，从根源解决数据割裂问题，提升跨地域协同效率。

研发人员可在任意站点调取所需数据，快速生成用于模型变体训练的数据，并在不同地域间无缝协作，完全不用担心数据冗余膨胀。对于一个拥有数百名数据科学家，需要在共享调度器中争抢 GPU 资源的庞大团队来说，这种无摩擦的数据访问能力，已形成核心竞争优势。

关于 ADAS 的讨论往往聚焦于模型训练，但训练只是其中一环。支撑场景理解、行为预测、路径规划的模型，最终必须被投入生产环境运行，持续处理传感器流式数据并实时决策。

因此，训练基础设施必须同时承载推理业务；而车辆、边缘节点与数据中心间的数据，需要作为连续流模式进行实时采集、加工和调度，而非传统的隔夜批处理模式。

这正是 VAST Data 架构超越传统存储的核心优势：VAST DataBase 可作为实时事件流平台，兼容 Kafka、原生支持 Apache Arrow 接口，规模化采集与查询车联网、传感器流式数据。同一套承载 PB 级训练数据的平台，可同时接入车辆实时遥测、运行实时分析、支撑推理负载，无需单独搭建流式架构。

对 ADAS 研发团队而言，这意味着从数据采集、模型训练到验证的闭环，不再止步于模型导出。识别施工区域的感知模型、规划绕行路线的决策模型、预判周边车辆行为的预测模型，均依托同一底层数据平台，以快速获取上下文数据。

此外，OTA 更新验证、数字孪生仿真、车队运行实时看板，都无需单独搭建新架构，可直接运行在支撑模型训练的同一套 VAST Data AI OS 之上。

这种端到端全链路能力，正是数据平台（或者说操作系统）与普通存储系统的本质区别。ADAS 研发不能只停留在仿真环境训练模型，更需要一套统一基础设施，以支撑模型从验证、部署到现实场景持续迭代的全生命周期，这一切，都必须建立在同一个平台之上。

ADAS 只是一个更大规模技术变革的前沿缩影。除汽车行业外，机器人、工业自动化、无人机集群运营企业，都面临同一核心挑战：构建能够在物理世界中感知、推理并行动的 AI 系统，其产生的数据规模与复杂度，远超传统基础设施设计上限。

ADAS 当下所需的架构要求——海量流式数据采集、实时推理、全局数据访问、模型持续迭代等能力，正成为所有打造“物理 AI”企业的标配基础能力。

只有那些将数据基础设施视作战略投资，而非单纯成本中心的企业，才能够更快推出更安全、更智能的系统。自动驾驶行业已经证明：模型底层的 AI 操作系统，其重要性不亚于模型本身。

本文作者：Aaron Chaisson，VAST Data 产品与解决方案营销副总裁