Chapter 3: 总体架构选型：Vision Encoder + Transformer 拓扑

1. 开篇与学习目标

在自动驾驶感知系统的演进中，Hybrid 架构（卷积骨干 + Transformer 颈部/头部）已成为 NVIDIA Orin 平台上的事实标准。纯 CNN 难以处理复杂的长程依赖和多模态融合，而纯 ViT（Vision Transformer）在处理高分辨率图像特征时，不仅计算量呈平方级爆炸，且无法利用 Orin 上极其高效的 DLA（Deep Learning Accelerator）资源。

设计高效架构的核心在于“扬长避短”：

1. DLA 的长处：极高能效比处理固定尺寸的卷积、池化、激活。
2. GPU 的长处：极高吞吐量处理通用矩阵乘法（GEMM）、变长序列、复杂 Attention 及非标算子。
3. 系统的瓶颈：显存带宽（DRAM Bandwidth）与 SRAM 大小。

本章学习目标：

• Backbone 选型：深度剖析为何 ResNet/RegNet 仍是 DLA 的王者，以及 ConvNeXt/EfficientNet 在 Orin 上的落地陷阱。
• Transformer 范式：从 Encoder-only 到 Query-based (DETR-like) 的演进，及其对显存和时延的影响。
• 多尺度策略：如何在不通过带宽墙的前提下，保留小目标（远距离）的感知能力。
• 异构流水线设计：规划数据在 DLA 与 GPU 之间的“交接棒”时刻。

2. 深度论述

3.1 Encoder (Backbone) 选型：DLA 的“舒适区”与“禁区”

在 Orin 上，Vision Encoder 的首要任务是降采样与特征提取。由于图像输入分辨率极高（如 8MP: $3840 \times 2160$），前几个 Stage 的计算密度极大。

3.1.1 纯 ConvNet 仍是首选

尽管学术界 ViT 火热，但在 Orin 工程落地中，前置 Backbone 必须是 ConvNet，且必须跑在 DLA 上。

• 算力卸载：Orin 有两颗 DLA 核心。将 Backbone 移至 DLA，相当于为 GPU 节省了 30%~50% 的算力，这些宝贵的 GPU 算力可以留给后续的 BEVFormer 或 Occupancy Network。
• INT8 成熟度：DLA 的 INT8 校准在标准卷积上非常稳定（PTQ 通常即可），而 Transformer 结构（特别是 LayerNorm/Softmax）在 INT8 下极易溢出或精度崩塌。

3.1.2 候选架构分析

| 架构系列 | Orin DLA 适配度 | 优点 | 缺点/陷阱 |

Rule-of-Thumb 3.1: 在 Orin 上，RegNet-Y 或 ResNet-50/101 是性价比最高的 Backbone 选择。如果你必须使用现代架构（如 ConvNeXt 风格），请务必修改其微结构：将 LayerNorm 换成 BatchNorm，将 GELU 换成 ReLU/SiLU，并将大核卷积（7x7）拆解或替换，以适配 DLA 硬件特性。

3.2 Transformer 拓扑：从特征图到 BEV 空间

特征提取后，进入“View Transformation”或“Feature Fusion”阶段，这是 GPU 接管的主战场。

3.2.1 避免高分辨率 Self-Attention

在像素空间（Pixel Space）做全局 Self-Attention 是计算灾难。 假设特征图为 Stride 16 ($H/16, W/16$)。对于 8MP 图像，Token 数 $N \approx 32,400$。 Self-Attention 复杂度 $O(N^2)$，计算量约为 $10^9$ 级别，且显存占用巨大。

Orin 推荐拓扑：

1. Deformable Attention (DETR style):
   • 原理：每个 Query 只关注参考点周围的少量 Key（例如 4 个采样点）。
   • Orin 优势：TensorRT 8.x+ 提供了 EfficientNMS 和 GridSampler 等插件支持，且有开源的 Deformable Attention TRT Plugin。这使得复杂度降为 $O(N)$。
2. Query-based BEV (BEVFormer style):
   • 原理：预定义一组 BEV Grid Queries（如 $200 \times 200$），利用相机参数将 Query 投影回图像平面采样。
   • 优势：解耦了图像分辨率与计算量。无论图像是 2MP 还是 8MP，Transformer 层的计算量主要取决于 BEV Grid 的大小。

3.2.2 架构界线 (Cut Point)

在哪里将数据从 DLA（Backbone）传给 GPU（Transformer）？

[ DLA Domain ]                         [ GPU Domain ]
Image (N,3,H,W)                        (N, 256, H/32, W/32)
   |                                          |
   v                                          v
Stage 1 (Stride 2/4) --> Keep on DLA      Transformer Encoder (Optional)
   |                                          |
   v                                          v
Stage 2 (Stride 8)   --> Keep on DLA      BEV / Fusion Queries
   |                                          |
   v                                          v
Stage 3 (Stride 16)  --> MEMORY COPY -->  Cross-Attention Helper
   |                                          |
   v                                          v
Stage 4 (Stride 32)  --> MEMORY COPY -->  Cross-Attention Helper

Rule-of-Thumb 3.2: 切分点选在 Stride 16 或 32。如果在 Stride 4 或 8 处将数据切回 GPU，巨大的 Tensor 体积（Batch x Channel x H/8 x W/8）会瞬间挤爆 DLA 到 DRAM 的写带宽，以及 DRAM 到 GPU 的读带宽，导致严重的流水线气泡（Pipeline Bubble）。

3.3 多尺度设计 (Multi-scale) 与 Token 策略

单尺度特征难以同时兼顾“近处大目标”和“远处小目标”。FPN (Feature Pyramid Network) 是标准解法，但在 Transformer 时代需要改良。

3.3.1 为什么 FPN 在 Transformer 中很昂贵？

在 CNN 中，FPN 只是简单的 Conv + Upsample，计算量很小。 在 Transformer 中，如果对多尺度特征做 Attention：

• Token 数量增加：$N_{total} = N_{s32} + N_{s16} + N_{s8} \approx N_{s8}$。
• Stride 8 的 Token 数量是 Stride 32 的 16 倍。加入 Stride 8 会导致 Attention 计算量激增。

3.3.2 Orin 优化策略

1. 非对称输入：
   • Query: 只使用低分辨率（Stride 32）或稀疏的 Object Queries。
   • Key/Value: 使用多尺度特征（Stride 8/16/32）。
   • 这样维持了 Query 数量少，但用了高分辨率的 Key/Value 细节。
2. 两段式处理 (Two-stage Processing)：
   • Stage 1 (DLA): 使用轻量级 CNN FPN（如 BiFPN 或 YOLOF Neck）融合多尺度信息，输出单一的高质量 Stride 16 特征图。
   • Stage 2 (GPU): Transformer 仅处理这一层特征图。
   • 收益：极大减少了 GPU 的负担和内存拷贝量。

3.4 Head 设计：任务解耦

3.4.1 Dense Head (DLA 友好)

• 适用：语义分割、简单的 2D 检测、车道线分割。
• 实现：全卷积结构。
• 位置：可以完全保留在 DLA 上。如果 Backbone 在 DLA，Head 也在 DLA，中间无需回传 GPU，效率极高。

3.4.2 Sparse Head (GPU 友好)

• 适用：3D 检测 (BBox)、端到端轨迹预测。
• 实现：MLP (Multilayer Perceptron) 处理 Object Queries。
• 位置：必须在 GPU。因为 Queries 的产生通常依赖于前面的 Transformer Decoder。

3.4.3 辅助训练头 (Auxiliary Heads)

• 训练时：为了加速收敛，通常在 Transformer 的每一层 Decoder 后都接一个 Head 计算 Loss。
• 部署时：必须剪枝。只保留最后一层 Decoder 的输出 Head。这是一个常见的“新手错误”，导致推理计算量增加 6 倍（如果是 6 层 Decoder）。

3. 本章小结

1. DLA 决定下限，GPU 决定上限：Backbone 必须为了适配 DLA 而妥协（选用 ResNet/RegNet，避免 Swin/ConvNeXt-Original）。这是 Orin 架构设计的第一公理。
2. 带宽是隐形杀手：架构图上的一条连线，在硬件上可能是昂贵的 DRAM 读写。务必在低分辨率（Stride 16/32）处进行 DLA-GPU 的数据交接。
3. Transformer 需“稀疏化”：避免全图 Self-Attention。使用 Deformable Attention 或 BEV Queries 将计算复杂度与图像分辨率解耦。
4. 混合精度与混合设备：最强架构通常是：DLA(INT8 Backbone + Neck) + GPU(FP16 Transformer + Head)。

4. 练习题

基础题

Q1: 架构带宽估算 你设计了一个 Backbone，在 Stride 4 处输出 256 通道的特征图。输入图像为 $1920 \times 1080$，Batch Size = 1。 a) 该特征图的数据量是多少（FP16 格式）？ b) 如果系统 FPS 为 30，仅传输这一层特征图需要多少带宽（GB/s）？ c) Orin 的理论带宽约为 204GB/s（实际可用约 130GB/s），这单一操作占用了多少比例？

Q2: DLA 算子兼容性 以下哪些操作会导致网络无法在 Orin DLA 上完全运行，从而导致 fallback 到 GPU（甚至 CPU）？（多选） A. torch.nn.Hardswish B. torch.nn.AdaptiveAvgPool2d C. torch.nn.Conv2d(..., groups=in_channels) (Depthwise Conv) D. 动态 shape 的 view/reshape 操作

挑战题

Q3: BEV Grid 分辨率决策 (Open Question) 你的产品经理要感知距离达到 100米，且能分辨 0.5米 的障碍物。

1. BEV Grid 的物理尺寸（米）和分辨率（格）应如何设置？
2. 如果你的 Transformer 显存预算只有 2GB，且使用 Dense BEV Queries ($C=256$, FP16)，你能支持多大的 Grid？
3. 如果满足不了 PM 的需求，你会采用什么技术手段来解决分辨率与显存的矛盾？

Q4: 延迟瓶颈定位 模型部署后发现 DLA 利用率 90%，但 GPU 利用率只有 30%，且整体 FPS 很低。使用 Nsight Systems 抓取 Trace 发现：GPU 大部分时间在等待（Idle），每隔一段时间有一小段密集的 Compute。这是什么典型症状？可能的原因是什么？

5. 常见陷阱与错误 (Gotchas)

1. 盲目自信的 "Re-training"

• 错误: "我选个 ConvNeXt，虽然 DLA 跑得慢点，但我重新训练一下，剪枝一下不就行了？"
• 现实: DLA 的限制是硬件架构级的（如内部 Buffer 大小、支持的算子指令集）。这不是通过训练能解决的。如果 DLA 不支持某个 LayerNorm 算子，它就会强制回退（Fallback）到 GPU。这会产生 DLA -> Memory -> GPU -> Memory -> DLA 的乒乓效应，导致性能比纯 GPU 还慢。
• 对策: 在模型设计初期，必须对照《NVIDIA DLA Supported Layers》文档，确保 Backbone 是 "DLA-Native" 的。

2. 忽视 Padding 带来的计算浪费

• 错误: 随意设计通道数，如 100, 300。
• 现实: Orin 的 Tensor Core 和 DLA 都有对齐要求（通常是 32 或 64 字节对齐）。如果通道数是 100，硬件可能会将其 Pad 到 128 进行计算。
• 对策: 始终将 Channel 数设置为 $2^n$ 或 32 的倍数（如 32, 64, 96, 128, 256）。这能确保存储和计算效率最大化。

3. "View Transform" 的显存爆炸

• 错误: 在 LSS (Lift-Splat-Shoot) 类方法中，为了追求高精度，将深度分布（Depth Bin）设置得过密（如 100 档）。
• 现实: LSS 生成的视锥点云（Frustum Point Cloud）张量大小为 $B \times N_{cams} \times D \times H \times W \times C$。对于 100 档深度，这个张量会瞬间吃光 Orin 的 32GB/64GB 显存，导致 OOM (Out of Memory)。
• 对策: 严格控制 Depth Bin 的数量，或者使用 BEVFormer 类方法（它是 Backward Projection，不需要显式构建巨大的深度体素）。

4. TensorRT 插件陷阱

• 错误: 在 PyTorch 里写了复杂的 Grid Sample 逻辑，导成 ONNX 后发现有一堆 Gather/Scatter 算子。
• 现实: 这些零碎算子在 TensorRT 上效率极低。
• 对策: 必须编写或使用现成的 TensorRT Plugin 来替换这些逻辑块。对于 Orin 开发，掌握 Custom Plugin 的编写（或熟练使用 mmdeploy / TensorRT-OSS 里的插件）是架构师的必修课。