自动驾驶模型训练基础设施需求，不能只按模型参数量估算：摄像头、激光雷达和毫米波雷达数据的规模、读取方式与训练目标，同样决定存储和算力配置。规划时先弄清数据每天进入多少、训练要读多快，再据此扩展计算资源，避免昂贵算力因等数据而闲置。
先算数据：容量与读取速度分开规划
原始传感器数据、标注结果、筛选后的训练集和模型产物应分别管理。以公开数据集 nuScenes 为例，它包含相机、激光雷达、雷达等传感器信息，适合用来验证多模态数据读取流程；实际车队采集规模则会随传感器数量、采样频率、压缩方式和保留周期明显变化。
用采集速率估算容量
可用“设备数 × 每日采集时长 × 平均写入速率 × 保留天数”估算原始数据量，再为副本、索引、标注及临时处理空间预留余量。举例来说，若规划假设是100台设备每天各采集2小时、平均写入速率20 MB/s，30天原始数据约为432 TB；这只是按假设计算的容量，不代表所有项目的实际采集速率。规划时还要明确是否保存全部原始数据，以及过期数据如何归档或删除。
适合长期保存的数据可放在对象存储或数据湖中，按采集日期、车辆、场景和传感器建立可检索的目录与元数据。训练热数据可缓存到本地高速盘，减少重复读取远端数据的延迟。对象存储扩容灵活、适合大规模归档，但小文件过多时需要优化索引和打包方式；本地高速存储读取更直接，却需要额外管理容量和故障恢复。
算力配置看吞吐，不只看加速卡数量
先用代表性数据跑小规模基准：记录每秒读取样本数、单步训练时间、加速器利用率和显存占用。若加速器常在等待数据，优先检查解码、预处理和存储读取；若显存不足，再考虑减小批量、采用混合精度，或换用显存更大的设备。不同加速器的框架支持、驱动和算子表现也有差别，不能只凭理论峰值比较。
集群还要配足CPU用于解码与数据增强，并根据并行任务配置内存。网络带宽需依据多台训练机器的并发读取量压测：25GbE可作为中小型集群的评估起点，较高并发或集中访问时可测试100GbE；实际需求取决于数据压缩率、缓存命中率和存储端能力。训练集群的节点数量应从任务吞吐目标倒推，而非一次性按最大规模采购。
把数据、任务和结果连成闭环
- 盘点负载：统计采集量、保留周期、传感器类型、训练频率，以及感知、预测或融合任务的资源峰值。
- 做端到端压测：用真实格式的样本验证解码、读取和训练速度；分别测试缓存命中与冷读，找出瓶颈所在。
- 分层部署存储：原始数据进入数据湖，常用训练集进入高速缓存；记录数据版本、标注版本和访问权限。
- 逐步扩算力：先用少量节点跑完整训练流程，再依据加速器利用率和任务排队情况增加节点或调整存储带宽。
- 持续追踪成本与质量：记录每次训练使用的数据、配置、资源时长和评估结果，便于复现并清理无用副本。
数据治理也应纳入设计：限制敏感数据的访问范围，设置保留期限，并让训练数据与标注变更可追溯。最终，自动驾驶模型训练基础设施需求应由实测吞吐、数据保留策略和训练目标共同确定；先建立可观测、可扩展的基础，再按瓶颈投入存储或算力，通常比单纯堆设备更稳妥。
常见问题
存储容量和带宽，应该先满足哪一个？
先保证容量与保留策略可行，再用训练压测判断带宽是否限制任务。容量够但读取慢时，可增加缓存或优化数据组织。
训练数据都要放在高速存储上吗？
不必。原始数据适合放在可扩展的对象存储中，近期反复使用的数据再缓存到高速介质，兼顾成本与读取效率。
什么时候需要增加计算节点？
在数据供给稳定、加速器持续繁忙且任务仍达不到吞吐目标时，再增加节点；如果设备经常等待数据，应先解决读取或预处理瓶颈。
如何避免存储估算偏差？
按真实采集样本测量写入速率，并将副本、标注、索引、缓存和保留周期分别计入；定期用实际增长量修订规划。
