3、计算瓶颈分析：实时推理场景下的性能瓶颈
好，咱们进入第三章。这一章我打算聊聊实时推理场景下，MobileViT到底卡在哪里。
你可能会想，模型都压缩了，量化也做了，怎么跑起来还是不够快？
嗯，这里有个误区。很多人以为模型小就等于推理快。其实不然。在移动端，真正的瓶颈往往不是算力，而是内存带宽和算子效率。我见过不少项目，模型体积压到1MB以内，结果跑起来还是卡成PPT。为什么？因为数据搬运比计算本身更耗时。
3.1 内存带宽：被忽视的隐形杀手
先说说内存带宽。这个概念其实很简单：单位时间内，处理器能从内存里读出或写入多少数据。
在实时推理场景下，MobileViT的Transformer部分有个特点：它需要频繁地做全局注意力计算。这意味着大量的中间特征图需要在内存和计算单元之间来回搬运。
举个例子。假设输入特征图是64x64，通道数是256。一次自注意力计算，需要生成Q、K、V三个矩阵。每个矩阵的大小是4096x64（假设头数为4）。这三个矩阵加起来，光存储就需要大约3MB。而移动端芯片的L2缓存通常只有几百KB。结果就是，数据频繁地在L2缓存和主存之间交换。
我曾经在一个项目中，把MobileViT部署到某款中端手机上。模型跑一次前向推理，内存带宽占用率直接飙到90%以上。CPU核心大部分时间都在等数据，真正算的时间反而很少。
怎么解决？我个人习惯用这几招：
- 算子融合：把连续的矩阵乘法和激活函数合并成一个算子。减少中间结果的写回和读取。
- 内存复用：尽量复用已有的缓冲区，避免频繁申请和释放。
- 数据布局优化：把NCHW格式转成NHWC。后者在移动端更友好，能提高缓存命中率。
关键指标：实时推理场景下，内存带宽利用率超过70%就要警惕了。超过85%基本就是瓶颈。
3.2 算子效率：为什么你的模型跑不快
算子效率，说白了就是每个计算单元在单位时间内能干多少活。
MobileViT里有个很典型的低效算子：reshape和transpose。这两个操作本身不涉及计算，但它们会打乱数据在内存中的排列。一旦数据排列不连续，CPU的SIMD指令（比如NEON）就很难发挥威力。
我记得有一次，我优化一个MobileViT-S模型。原始实现里，每次自注意力计算前都要做两次transpose。我一看，这不行。每次transpose都会导致缓存miss率上升30%以上。
我的做法是：把transpose操作提前到数据加载阶段。在数据从内存读入寄存器时，直接按目标格式读取。这样，后续的计算就不用再折腾数据布局了。
另一个常见问题是小算子过多。MobileViT的MobileNet部分有很多depthwise卷积。每个depthwise卷积的参数量很小，但启动开销很大。你想想看，每次调用一个算子，都要经历函数调用、内存分配、上下文切换。如果算子本身计算量很小，那启动开销就占了主导。
怎么优化？我建议：
- 算子合并：把多个连续的depthwise卷积合并成一个大的卷积操作。虽然计算量不变，但启动次数减少了。
- 使用手工汇编：对于关键算子，比如自注意力中的矩阵乘法，直接用NEON指令写。效率能提升20%-40%。
- 避免动态shape：MobileViT的输入尺寸如果变化，会导致算子重新编译。尽量固定输入尺寸。
个人经验：我一般先用profiler跑一遍，找出耗时最长的前5个算子。然后针对它们逐个优化。不要一开始就想着全盘重写，那样效率反而低。
3.3 量化误差：精度和速度的博弈
量化，就是把模型参数从FP32压缩到INT8甚至INT4。好处是模型变小了，推理速度变快了。坏处是精度会下降。
在实时推理场景下，量化误差的影响会被放大。为什么？因为MobileViT里既有卷积层，又有Transformer层。卷积层对量化比较鲁棒，但Transformer层里的softmax和LayerNorm对量化非常敏感。
我曾经踩过一个坑。把MobileViT量化到INT8后，在ImageNet上Top-1准确率只掉了0.5%。我心想，这没问题啊。结果部署到实际场景中，发现模型经常输出一些莫名其妙的分类结果。后来一查，原来是softmax量化后，概率分布变得不均匀。原本应该是0.3和0.7的分布，变成了0.1和0.9。这就导致模型过于自信，容易误判。
怎么避免？我总结了几条经验：
- 逐层量化：不要一刀切。对卷积层用INT8，对Transformer层用FP16或者混合精度。
- 校准数据集：量化时用的校准数据集要尽量覆盖实际场景。我见过有人用ImageNet的校准集去量化，结果部署到安防场景，效果一塌糊涂。
- 量化感知训练：如果精度损失太大，就用QAT（量化感知训练）。虽然训练时间会长一点，但效果确实好。
避坑指南：我曾经在量化后忽略了LayerNorm的量化参数。结果模型输出全是NaN。后来花了整整两天才定位到问题。所以，量化后一定要做端到端的验证，不要只看单项指标。
3.4 知识体系：一张图看懂瓶颈分析
下面这张图是我自己画的，把实时推理场景下的性能瓶颈梳理了一遍。你可以对照着看，方便理解。
3.5 实战建议：从分析到优化
好了，理论讲完了。咱们来点实际的。
如果你现在手头有个MobileViT模型要部署，我建议你按这个步骤来：
- 先跑profiler：用Android的Systrace或者iOS的Instruments，看看CPU和内存的占用情况。
- 定位瓶颈：是内存带宽高？还是某个算子慢？还是量化后精度崩了？
- 针对性优化：带宽高就做算子融合和内存复用。算子慢就用手工汇编或者合并小算子。量化误差大就用逐层量化或者QAT。
- 验证效果：优化后一定要在真实设备上跑一遍。模拟器上的数据不准。
一个小技巧：我习惯在优化前后各跑一次profiler，然后对比两张火焰图。哪里变好了，哪里还有问题，一目了然。
嗯，这一章就到这里。内容不少，但都是实战中会遇到的坑。你消化一下，下一章咱们聊聊具体的优化工具和流程。