ViT 与 CNN 的 TensorRT 对比实测：层数差 3.7 倍，谁受益更多

一句话答案可直接引用在同机同输入224×224、3M 参数级下实测三个模型模型参数量PyTorchTRT FP32TRT FP16相对 PyTorchengine 层数contextViT patch163.05 M1.863 ms0.782 ms0.633 ms2.9×5514 MBViT patch83.05 M1.744 ms1.703 ms0.673 ms2.6×5418 MBCNN1.67 M0.496 ms0.801 ms0.395 ms1.3×1510 MB三条最值得记的结论① ViT 从 TensorRT 拿到的加速2.9×明显大于 CNN1.3×因为 PyTorch 里 attention 是多算子拼接、开销大② ViT 的 engine 有 55 层CNN 只有 15 层——attention 与 LayerNorm 天然难融合③ 小 CNN 在 TRT FP32 下比 PyTorch 还慢0.801 vs 0.496 ms不开 FP16 的 TensorRT 对小卷积网没有意义。FP16 精度方面ViT 的 max|Δ| 约 0.003、余弦 0.999999分类任务可接受。开头Transformer 在 TensorRT 上到底好不好前十二篇的模型全是 CNNTinyCNN、MidCNN、ResNet-18、一个轻量检测器。有读者问ViT/Transformer 这类模型TensorRT 还能带来同样的收益吗这个问题不好靠经验回答因为两边都有反例一方面Transformer 在 PyTorch 里由大量小算子拼成LayerNorm、QKV 投影、softmax、残差Python 与 kernel 启动开销大理论上 TensorRT 的编译优化收益应该更大另一方面attention 的结构本身就是必须分开的softmax 前后无法融合层数多、融合空间小理论上收益又应该更小。所以这次直接测。为了公平我构造了两个参数量接近的模型都输出 1000 类、输入 224×224TinyViTpatch embed 6 个 Transformer blockdim 192、3 头 分类头3.05M 参数SmallCNN4 段 ConvBNReLU 全局池化 全连接1.67M 参数已是同量级里能对齐的最近值。另外加一个patch8 的变体token 从 196 涨到 784用来看 attention 规模变化的影响。一、三方延迟ViT 受益更多模型PyTorchTRT FP32TRT FP16FP16 vs PyTorchFP16 vs FP32ViT patch161.863 ms0.782 ms0.633 ms2.9×1.24×ViT patch81.744 ms1.703 ms0.673 ms2.6×2.53×CNN0.496 ms0.801 ms0.395 ms1.3×2.03×三个读数都反直觉逐个说① ViT 的加速比更高2.9× vs 1.3×。因为 PyTorch 里一个 Transformer block 要跑十几个小 kernelLayerNorm、三个 QKV 线性、attention、输出投影、两个 MLP 线性、两次残差每次都有 Python 调度与 kernel 启动开销TensorRT 把它编译成更紧凑的执行图收益自然更大。② CNN 在 TRT FP32 下反而更慢。0.801 ms vs PyTorch 的 0.496 ms——慢了 61%。原因PyTorch 背后是 cuDNN对 FP32 卷积已经高度优化还会自动挑算法而 TensorRT 在 FP32 下没有额外优势反而多了一层自己的调度。只有开到 FP16TensorRT 才有明显优势0.395 ms。这条对实践的意义很直接如果你的模型是小 CNN别用 TensorRT 的 FP32 引擎——要么开 FP16/INT8要么直接用 PyTorch。③ patch8 的 FP32 直接崩到 1.703 mspatch16 是 0.782但 FP16 只到 0.673。说明 attention 的规模上来之后FP32 完全顶不住必须靠 Tensor Core。二、层数55 vs 15用Engine Inspector数一下实际层数模型engine 层数ViT patch1655ViT patch854CNN15ViT 的 55 层怎么来的6 个 block每块约 9 层LayerNorm、QKV 投影、attention、输出投影、两个 MLP 线性、两次残差相加再加 patch embed 与分类头。而 CNN 的 15 层里ConvBNReLU 被整块融合——一个Conv2d BatchNorm2d ReLU在 TensorRT 里就是 1 层而在 PyTorch/ONNX 图里是 3 个节点。这就是为什么层数是判断 TensorRT 优化空间的一个粗略指标CNN ConvBNReLU 可融合 → 层数 ≈ 卷积个数 ViT attention/softmax/LayerNorm 结构上必须分开 → 层数 ≈ 算子个数层数多不等于性能差ViT 仍然拿到了 2.9 倍加速但它意味着kernel 启动次数多、每次启动的固定开销更难摊薄。这也解释了为什么 ViT 在小 batch 下更吃亏——如果 batch1 时 kernel 启动开销占主导55 层的启动成本就是 15 层的 3.7 倍。三、patch 越小越好吗patch 从 16 缩到 8token 数从 196 涨到 7844 倍attention 的计算量按 token 数平方增长。实测指标patch16patch8变化token 数1967844 倍FP32 延迟0.782 ms1.703 ms2.2 倍FP16 延迟0.633 ms0.673 ms1.06 倍context 显存14 MB18 MB1.3 倍engine 体积7.51 MB7.53 MB几乎不变最值得注意的一行是 FP16token 翻 4 倍延迟只涨 6%。因为在 FP16 下 attention 走的是 Tensor Core算力不是瓶颈真正吃时间的是 kernel 启动与调度层数没变。而 FP32 下没有 Tensor Core 加持计算量直接体现在延迟上2.2 倍。实践含义如果你的模型在 FP16 下跑用更小的 patch更高分辨率特征几乎不要钱但如果是 FP32patch 减半就要付 2 倍延迟。显存的增长比想象中温和token 从 196 到 784context 只从 14 MB 涨到 18 MB1.3 倍。对比第 6 篇的结论context ≈ 3 × 峰值激活体积ViT 的激活主要是[B, N, dim]的 token 序列N 翻 4 倍但 dim 固定所以只是线性增长而 CNN 的高分辨率特征图是[B, C, H, W]H×W 翻 4 倍时激活会翻 4 倍。所以 ViT 的显存比同规模 CNN 更温和本次 14–18 MB vs CNN 10 MB但 CNN 的输入只有 224 且降采样很快。四、FP16 精度都在安全区但差两个数量级以各自的 FP32 engine 输出为基准模型余弦相似度max|Δ|mean|Δ|ViT patch160.9999990.002970.000104ViT patch80.9999990.002660.000101CNN1.0000000.000030.000001ViT 的偏差比 CNN 大两个数量级0.003 vs 0.00003但余弦相似度都是 0.999999方向完全一致。这个差异是结构性的Transformer 里 LayerNorm 与 softmax 对数值范围敏感FP16 的 10 位尾数在这些位置容易丢精度CNN 的卷积是累加运算误差不容易放大。结论分类任务上ViT 的 FP16 可以直接用余弦 0.999999top-1 基本不变回归 / 检测 / 生成类任务必须跑验证集对比业务指标第 7 篇的方法论不能只看余弦。五、五条部署建议一定开 FP16ViT 从 0.782 → 0.633 ms1.24×patch8 更是 2.53×FP32 的 TensorRT 对 Transformer 收益很小。别用小 patch 硬堆精度token 翻 4 倍FP16 延迟只涨 6%可接受但 FP32 涨 2.2 倍。FP16 才让细粒度 patch 变得可用。显存按 token 数估ViT 的 context 与 token 数近似线性196→784 时 14→18 MB比 CNN 的H×W增长温和。接受层数多的事实55 层意味着 kernel 启动多、融合空间小attention 与 LayerNorm 天然难融合别指望调 builder 参数解决。小 CNN 先别上 TRT FP32实测 CNN 的 TRT FP320.801 ms比 PyTorch0.496 ms还慢只有 FP16 才有优势。一段可以直接用的构建配置importtensorrtastrt configbuilder.create_builder_config()config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE,51220)# Transformer 必须开 FP16FP32 几乎拿不到收益patch 小时还会更慢config.set_flag(trt.BuilderFlag.FP16)# 动态 batchTransformer 通常按请求 batchprofbuilder.create_optimization_profile()prof.set_shape(input,min(1,3,224,224),opt(8,3,224,224),max(32,3,224,224))config.add_optimization_profile(prof)# 若精度敏感可对 LayerNorm/softmax 相关层保持高精度需逐层设置# 注意ViT 的 attention 通常已由 TensorRT 内部处理不必手动拆enginebuilder.build_serialized_network(network,config)常见问题FAQQ1ViT 在 TensorRT 上的加速比 CNN 高还是低更高。实测 ViT patch16 是 2.9×1.863 → 0.633 msViT patch8 是 2.6×而同规模 CNN 只有 1.3×0.496 → 0.395 ms。原因是 PyTorch 里 attention 由多个小算子拼成Python 与 kernel 启动开销更大TensorRT 的编译收益也更明显。Q2为什么小 CNN 在 TensorRT FP32 下比 PyTorch 还慢因为 PyTorch 背后的 cuDNN 对 FP32 卷积已高度优化会自动挑算法而 TensorRT 在 FP32 下没有额外优势还多了一层自己的调度。实测 CNN 的 TRT FP32 是 0.801 msPyTorch 是 0.496 ms慢了 61%只有开 FP160.395 ms才有优势。Q3ViT 的 engine 为什么有 55 层6 个 Transformer block每块约 9 层LayerNorm、QKV 投影、attention、输出投影、两个 MLP 线性、两次残差再加 patch embed 与分类头。对比之下 CNN 只有 15 层因为 ConvBNReLU 可以被整块融合成一层。Q4patch 越小延迟会线性增长吗不是。实测 patch 从 16 缩到 8token 196 → 784FP32 延迟涨 2.2 倍但 FP16 只涨 6%。因为 FP16 下 attention 走 Tensor Core算力不是瓶颈真正吃时间的是 kernel 启动与调度层数不变。所以 FP16 下用更细的 patch 几乎不要钱。Q5ViT 的 FP16 精度会比 CNN 差吗会差两个数量级但通常仍可接受。实测 ViT 的 max|Δ| 约 0.003、mean|Δ| 约 1e-4而 CNN 是 3e-05 / 1e-06两者余弦相似度都是 0.999999。LayerNorm 与 softmax 对数值范围敏感是主因。分类任务可直接用回归/检测/生成任务必须跑验证集。Q6ViT 部署时该给多大的 max batch按第 6 篇的公式估context ≈ 3 × max_batch × 峰值激活。ViT 的激活是[B, N, dim]比 CNN 的[B, C, H, W]增长温和——实测 patch16 的 max_batch1 时 context 只有 14 MB。但 attention 的计算量随 token 数平方增长batch 放大后延迟会明显上升建议先用 trt_doctor 扫一遍。Q7能不能把 attention 拆出来单独优化不建议手工拆。TensorRT 内部的 builder 已经会处理 attention 的模式手工拆图往往会让融合更差。如果确实遇到 attention 相关的性能问题优先考虑① 换 FP16② 减小 token 数更大的 patch③ 检查是否被强制走了 FP32 fallback构建日志里会有提示。Q8这个结论对 BERT 这类纯编码器同样成立吗方向一致但程度不同。BERT 没有 patch embedtoken 数由序列长度决定通常 128–512远少于 ViT 的 196–784所以 attention 的计算量更小、layer 比例更高预计加速比与 ViT 接近但延迟绝对值更低。想确认的话把本文的vit_vs_cnn.py换个模型定义即可复测。小结ViT 从 TensorRT 受益更多2.9× vs CNN 的 1.3×同为 3M 参数级、224×224 输入。ViT 的 engine 有 55 层、CNN 只有 15 层attention 与 LayerNorm 天然难融合ConvBNReLU 可以整块融合。小 CNN 别用 TRT FP320.801 ms 比 PyTorch 的 0.496 ms 还慢只有 FP160.395 ms才有优势。FP16 让细 patch 变便宜token 翻 4 倍FP16 延迟只涨 6%FP32 涨 2.2 倍。ViT 的 FP16 偏差比 CNN 大两个数量级0.003 vs 3e-05但余弦都是 0.999999分类可用回归要验。下一篇开始进入系列的第二部分从单机到生产——多卡分片、模型版本热更新、以及一条推理服务上线前的完整验收清单。