2. 自动驾驶计算平台与部署约束
自动驾驶系统并不是把服务器上的模型直接搬到车上就能运行。车载环境同时施加了算力、功耗、散热、实时性、功能安全与成本六类约束，它们彼此耦合：提高算力往往带来功耗和散热压力，强化安全机制又会占用算力与内存带宽，而成本上限反过来限制芯片面积与传感器配置。理解这些约束，是低精度推理与量化部署工程的第一性前提。
一、六大约束的耦合关系
车载计算平台的核心矛盾可以概括为“在有限功耗与成本下，稳定地满足实时性与安全性的算力供给”。下面这张约束关系图展示了各要素之间的相互影响路径。
二、典型 SoC 与加速器架构
当前主流车载计算平台普遍采用异构 SoC 架构，把不同任务分配给最合适的计算单元，而不是用单一通用处理器包打天下。典型组成包括：
- CPU 集群：负责感知融合、规划决策、任务调度与安全监控，通常为多核 ARM Cortex-A 系列，强调确定性与通用性。
- GPU：承担图像预处理、部分后处理与并行度高的算子，浮点能力强但能效比一般。
- NPU / DLA / TPU：面向卷积、矩阵乘等深度学习算子的专用加速器，是 INT8/INT4 量化的主要落点，能效比可达 GPU 的数倍。
- ISP 与视觉加速器：处理多路摄像头 RAW 数据，完成去马赛克、降噪、畸变校正。
- 安全岛（Safety Island）：独立供电与时钟域，运行 ASIL-D 监控逻辑，检测主域失效并接管降级。
- 内存子系统：LPDDR5 带宽与容量往往比峰值算力更早成为瓶颈。
以 NVIDIA Orin、地平线征程 5、TI TDA4VM、Mobileye EyeQ 系列为例，它们的共同点是“CPU + 通用 GPU + 专用 NPU + 安全岛”的组合，差异在于 NPU 的编程模型、量化支持粒度与工具链成熟度。
三、部署约束的量化表达
把约束写成可计算的指标，才能指导量化决策。下表给出常见约束维度与工程目标。
| 约束维度 | 典型指标 | 工程目标 | 对量化的影响 |
|---|---|---|---|
| 算力 | 有效 TOPS（非峰值） | 利用率 ≥ 60% | INT8 提升吞吐，减少算子回退 |
| 功耗 | 整机 30～80 W | 不超 TDP，留 20% 余量 | 低比特降低访存与计算能耗 |
| 散热 | 结温 ≤ 105 ℃ | 持续负载不降频 | 降低峰值功耗，避免热节流 |
| 实时性 | 端到端 ≤ 100 ms | P99 抖动可控 | 量化缩短单帧推理时间 |
| 功能安全 | ASIL-B/D | 冗余与监控可验证 | 量化误差需纳入安全分析 |
| 成本 | BOM 与芯片面积 | 满足车型定位 | 低比特可减少片上缓存需求 |
四、场景案例：从 32 位到 8 位的部署决策
某 L2+ 项目在 Orin 平台上部署 BEV 感知模型，初始 FP32 版本单帧耗时 180 ms，整机功耗 95 W，结温触发降频。工程团队按以下流程推进：
- 用工具链统计算子分布，发现卷积与矩阵乘占比超过 85%，适合 NPU 加速。
- 对 NPU 支持的算子做 INT8 量化，对 LayerNorm、Softmax 等敏感算子保留 FP16。
- 用 2000 帧真实路采数据做校准，逐层分析量化误差，对首尾层采用更高精度。
- 重新测量：单帧耗时降至 62 ms，整机功耗 68 W，结温稳定在 92 ℃，不再降频。
# 量化配置片段（示意）
quant:
activation: int8
weight: int8
calibration: entropy
calibration_samples: 2000
keep_fp16_layers:
- layer_norm_1
- softmax_out
fallback: fp16
target: npu
量化不是单纯“压精度换速度”，而是在算力、功耗、散热、实时性、安全与成本之间寻找可行解。任何一项约束被突破，整个部署方案都要重新评估。
五、常见误区与复盘
误区一：只看峰值算力。厂商标称 TOPS 往往是稀疏或理想条件下的峰值，实际有效算力受内存带宽、算子支持度与调度影响，可能只有峰值的 30%～50%。
误区二：忽略散热与持续负载。实验室短时跑分正常，装车后长时间高负载触发降频，实时性急剧恶化。必须按持续工况验证。
误区三：把量化误差排除在安全分析之外。功能安全要求对失效模式可检测、可控制，量化引入的精度损失应作为系统误差纳入监控与降级策略。
复盘建议：在项目早期就建立“算力—功耗—时延—精度”四维基线，每次量化迭代都记录四项指标变化，避免后期返工。