想象你开着一辆房车去露营，晚上要给一家人做一顿四菜一汤。厨房只有巴掌大：一个灶眼、一口炒锅、三只碗，电还得省着用。要做完全家饭，你得像个经验丰富的厨师：爆香后直接下肉，别多洗一次锅；汤炖着的时候顺手切配菜；提前把食材洗好分装；算好每件厨具谁先用谁后用，轮流上岗。这套“小厨房做大餐”的生存智慧，正是把深度学习模型搬到手机、摄像头、机器人上的真实写照——设备又小又省，还要求几十毫秒就给出答案。这篇文章就带你走进这间“房车厨房”，看看那些让模型跑得又快又省的手艺：合并做饭步骤、循环使用锅碗、提前备菜、给厨具排班、最后用计时器验证成果。

岗位关联

掌握边缘推理性能优化，意味着你能让模型在手机、摄像头、机器人的有限资源上跑得又快又省——这是边缘 AI 工程师的核心竞争力。

目录
  1. 可视化演示
  2. 算子融合优化
  3. 内存复用策略
  4. TFLite 优化
  5. ONNX Runtime 优化
  6. GPU 管线调优
  7. 内存分析工具
  8. 性能基准测试
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示算子融合减少内核启动、内存复用降低峰值占用、优化前后基准性能对比，支持三模式切换查看优化细节。

本节配有交互动效（进入视口后自动加载，约 3KB）。

算子融合：Conv+BN+ReLU→FusedOp 三个独立算子融合为单个内核，减少66%内核启动开销 中间结果留在寄存器，避免3次显存读写 加速比 = N / (N-k+1)，k为融合算子数 TFLite与ONNX Runtime均支持自动算子融合Pass。

算子融合优化

房车里炒菜最忌“多起一次锅”。青椒炒肉丝，生手会把肉丝单独炒熟盛出来，再炒青椒，最后再合到一起——多占一个盘、多洗一次锅、多等一轮。老道的厨师用一只锅一气呵成：先滑肉丝，拨到锅边，下青椒，最后混炒出锅。深度学习模型里的卷积、归一化、激活函数，就像这些分步工序。边缘设备内存带宽有限，每多一个中间张量写进写出一回，就像多洗一次锅。

我们把算子理解成一步工序：输入特征图进来，在内存里算出一个新特征图，交给下一步。如果每个算子都单独“落盘”，内存带宽就白白烧掉了。算子融合（Operator Fusion）把相邻的多个算子合并成一个内核（Kernel），让数据尽可能留在寄存器或缓存里算完。在 TFLite 与 ONNX Runtime 的图优化 Pass 里，这一步往往最先执行。

最常见的融合是卷积、批归一化、激活三合一。批归一化（BN）在推理时可以“折叠”进卷积的权重和偏置——因为两者的组合在数学上仍是仿射变换。精确推导如下。

你看，数学上这只锅真的可以一锅端：三个算子变成一次卷积，少了两回中间张量“落盘”。房车厨房里的青椒肉丝，就这么炒出来了。把这个“少起锅”的思路推广到整张计算图，就引出了下一节的内存规划。

y=ReLU(γ(W∗x+b−μ)σ2+ϵ+β)=ReLU(W′∗x+b′)\displaystyle y = \text{ReLU}\left(\frac{\gamma (W \ast x + b - \mu)}{\sqrt{\sigma^2 + \epsilon}} + \beta\right) = \text{ReLU}(W' \ast x + b')
通俗说：把“归一化”的乘除加减全部折算进卷积的权重和偏置，三个算子从此合体为一个。
  1. 卷积输出输入特征图 $x$ 与卷积核 $W$ 做卷积并加偏置 $b$，得到中间结果 $z$。
    z=W∗x+bz = W \ast x + b
  2. 批归一化对 $z$ 减去均值 $\mu$，再除以标准差，加 $\epsilon$ 是为防止除零。
    z^=z−μσ2+ϵ\hat{z} = \frac{z - \mu}{\sqrt{\sigma^2 + \epsilon}}
  3. 反标准化乘缩放因子 $\gamma$、加平移量 $\beta$，得到 BN 的输出。
    ybn=γz^+βy_{bn} = \gamma \hat{z} + \beta
  4. 权重折叠把 $\gamma$ 与标准差合并成一个系数，得到新卷积核 $W'$。
    W′=γWσ2+ϵW' = \frac{\gamma W}{\sqrt{\sigma^2 + \epsilon}}
  5. 偏置折叠原偏置 $b$ 与均值 $\mu$ 做同样折算，再加 $\beta$，得到 $b'$。
    b′=γ(b−μ)σ2+ϵ+βb' = \frac{\gamma (b - \mu)}{\sqrt{\sigma^2 + \epsilon}} + \beta
  6. 激活紧跟ReLU 是逐元素运算，直接在卷积内核里顺带完成。
    y=ReLU(W′∗x+b′)y = \text{ReLU}(W' \ast x + b')

内存复用策略

房车厨房只有三只碗。聪明的厨师会安排“轮岗”：装过料的碗洗一洗马上装下一道菜，而不是给每道菜配新碗。模型推理也一样——不同张量的“生命周期”往往错开，一个张量用完了，它占的缓冲区就可以给下一个张量用。

内存复用（Memory Reuse）的核心是生命周期分析：每个张量从某个算子产生、到最后一个使用它的算子结束，这一段就是它的“寿命”。只要两个张量的寿命不重叠，它们就能共用同一块内存。框架在加载模型时做一次静态内存规划，把整张图的内存需求压到峰值附近，运行时不再有动态分配。

峰值内存的数学定义很朴素：

对照房车厨房：规划得好的话，三只碗永远够用；规划得差，碗堆成山还不停缺水。TFLite 的内存分配器就是这个“排班表”，它一次性算出谁和谁轮岗，运行时零 malloc、零碎片。

Mpeak=max⁡t∈[0,T]∑i∈live(t)si\displaystyle M_{peak} = \max_{t \in [0,T]} \sum_{i \in \text{live}(t)} s_i
翻译成人话：把推理过程想象成一段录像，每一帧找出“还活着”的张量，把它们的体积加起来，取全程最大的一帧。
  1. 存活集合$\text{live}(t)$ 表示时刻 $t$ 仍被后续算子需要的张量集合。
    i∈live(t)i \in \text{live}(t)
  2. 体积求和把这些“存活”张量的字节数 $s_i$ 相加，得到当前时刻的占用量。
    ∑i∈live(t)si\sum_{i \in \text{live}(t)} s_i
  3. 全程扫描对时间 $t$ 从 0 到 $T$（一次推理的完整周期）取最大值。
    max⁡t∈[0,T]\max_{t \in [0,T]}

TFLite 优化

房车厨房里最忙的时刻是饭点，所以老练的露营者会“提前备菜”：葱姜蒜切好分装、肉片提前腌制。TFLite 的模型转换器就是这位备菜师傅——它在部署之前，就把模型这个“菜谱”加工成最顺手的形态。

TFLite（TensorFlow Lite）是谷歌面向移动和嵌入式设备的推理框架。训练好的 TensorFlow 模型经过 TFLiteConverter 转换，先做图优化 Pass：常量折叠（把能预计算的常量提前算掉）、冗余节点消除、算子融合（如卷积、BN、ReLU 合成一个算子）；再做 INT8 量化，把权重从 float32 压到 int8，模型体积缩到四分之一，推理往往提速 2-4 倍。

量化的数学本质是用整数近似浮点数：

回到房车厨房：备菜师傅把菜提前洗好切好，饭点一到就只是“热锅快炒”。TFLite 的转换加量化把模型在手机、树莓派、摄像头上变成“即点即用”的形态；有 GPU 或 NPU 的设备，还可以用委派（Delegate）把算子派发给专用硬件，就像把炖肉交给高压锅。

q=round(rs+z),s=rmax⁡−rmin⁡qmax⁡−qmin⁡\displaystyle q = \text{round}\left(\frac{r}{s} + z\right), \qquad s = \frac{r_{\max} - r_{\min}}{q_{\max} - q_{\min}}
通俗说：把浮点的取值范围映射到整数的取值区间，每个数字都找一个“最接近的整数”来代表。
  1. 量化映射浮点实数 $r$ 除以缩放因子 $s$ 后平移 $z$，四舍五入成整数 $q$。
    q=round(rs+z)q = \text{round}\left(\frac{r}{s} + z\right)
  2. 缩放因子$s$ 是浮点范围除以整数范围的比值，代表每个量化步长。
    s=rmax⁡−rmin⁡qmax⁡−qmin⁡s = \frac{r_{\max} - r_{\min}}{q_{\max} - q_{\min}}
  3. 零点偏移$z$ 让浮点 0 能映射到整数中一个确定的位置，保证 0 被精确表示。
    r=s(q−z)r = s(q - z)

ONNX Runtime 优化

如果说 TFLite 是提前备菜，那 ONNX Runtime 更像一位“现场指挥”——菜已经备好了，但上菜前他会重新编排整个流程：哪道菜先炒、哪个灶眼空着、哪几步可以合到一个锅里，全被他事无巨细地盘过一遍。

ONNX Runtime（简称 ORT）是微软开源的跨平台推理引擎，接受开放的 ONNX 模型格式。它加载图后，会按优化级别执行一系列图优化 Pass：基础层做常量折叠与节点消除，扩展层做算子融合和布局优化，全部优化还会结合具体后端（CPU、GPU、NPU）做适配。级别开得越高，上菜流程越紧凑。

优化效果可以用加速比来度量：

现场指挥的价值在于“鸡蛋里挑骨头”式地抠时间。实测中，一个 YOLOv5s 的 ONNX 模型开启全部优化后，在边缘盒子上往往能快 1.5-2 倍。既然指挥这么努力，我们作为“厨师长”，也该对着整条管线做排产优化——这就是 GPU 管线调优。

S=TbeforeTafter=∑i=1Nti+tio∑j=1Mtj′+tio′,M<N\displaystyle S = \frac{T_{before}}{T_{after}} = \frac{\sum_{i=1}^{N} t_i + t_{io}}{\sum_{j=1}^{M} t'_j + t'_{io}}, \qquad M < N
翻译：优化前 N 个算子逐个跑、中间读写 N-1 次张量；优化后只剩 M 个融合算子，中间读写少了一大截，相除就是提速倍数。
  1. 优化前耗时N 个原始算子的执行时间总和，$t_i$ 是第 $i$ 个算子的耗时。
    ∑i=1Nti\sum_{i=1}^{N} t_i
  2. 调度与读写开销$t_{io}$ 是中间张量的读写、内核调度等额外成本。
    +tio+ t_{io}
  3. 优化后耗时M 个融合算子耗时 $t'_j$ 之和，M 明显小于 N。
    ∑j=1Mtj′\sum_{j=1}^{M} t'_j
  4. 加速比前后总耗时相除，$S > 1$ 代表变快。
    S=TbeforeTafterS = \frac{T_{before}}{T_{after}}

GPU 管线调优

房车厨房只有一个炉子，但你有两只手、一个案板。高手做菜时，锅里炖着汤，手上切着菜，案板上摆着配菜——三件事同时推进，谁也不等谁。嵌入式 GPU 推理也讲究这个：数据拷进显存、GPU 计算、结果拷回来，如果串行做，一个 batch 的延迟就是三段时间相加。

管线调优的核心是把“拷贝-计算-后处理”三阶段重叠起来。经典手段是双缓冲：准备两块输入缓冲区，GPU 计算第 k 块数据时，CPU 同时把第 k+1 块数据拷进另一块缓冲区，两者并行。配合 CPU 与 GPU 的异步执行，整个管线的吞吐就能压满硬件。

流水线的理论延迟由最慢环节决定：

在嵌入式 GPU（如 Jetson、Mali）上，显存管理还要特别抠。显存比内存更金贵，使用锁页内存、纹理内存等技巧能让传输更快。管线排产做得好，房车里三菜一汤能同时上桌；做不好，就是一个人干等炉子。

Tpipeline=Tstart+max⁡(Tcompute, Ttransfer)\displaystyle T_{pipeline} = T_{start} + \max\left(T_{compute},\, T_{transfer}\right)
通俗说：炖汤最慢就等汤的定时器，切菜再快也不影响整桌菜的出锅时间。
  1. 启动时间$T_{start}$ 是第一条数据进入管线的“入场”开销，比如分配缓冲区。
    TstartT_{start}
  2. 计算时间$T_{compute}$ 是 GPU 执行算子的时间。
    TcomputeT_{compute}
  3. 传输时间$T_{transfer}$ 是主机与显存之间搬运数据的时间。
    TtransferT_{transfer}
  4. 取最大值稳态下每帧时间由最慢环节决定，其余环节被流水线隐藏。
    max⁡(Tcompute, Ttransfer)\max\left(T_{compute},\, T_{transfer}\right)

内存分析工具

想优化房车厨房，先得知道锅碗瓢盆都放哪、用了多久。最笨的办法是每次用完一件厨具就记一笔：几点拿来、几点放下、占了多大地方。这个“记账”动作，就是内存分析工具干的事。

边缘推理框架的内存分析工具分两类。一类是框架内置的 Profiler：TFLite 的 Profiler 可以记录每个算子的执行时间和张量大小，Interpreter 还提供张量内存偏移和 arena 分配信息；ONNX Runtime 的 profiling 能输出每个节点的耗时。另一类是系统级内存分析：Android Studio Profiler、Perfetto、Valgrind/Massif 能看到整个进程的堆内存曲线，定位是不是推理引擎把内存吃爆了。

内存随时间变化的数学模型是：

有了账本，房车厨房一目了然：哪件厨具囤着不用（内存泄漏）、哪段时间碗不够用（峰值超限），统统现形。这也是性能优化的第一步——先测量，再优化；测不准，就是瞎忙活。

M(t)=Mstatic+∑i: tstart(i)≤t<tend(i)si\displaystyle M(t) = M_{static} + \sum_{i:\,t_{start}^{(i)} \le t < t_{end}^{(i)}} s_i
通俗说：每个张量都是一件“借来的厨具”，用的时候才占地方；把同一时刻所有借着的厨具体积加起来，就是这条曲线。
  1. 静态基数$M_{static}$ 是权重、常量等加载后常驻的内存。
    MstaticM_{static}
  2. 存活区间张量 $i$ 在 $t_{start}^{(i)}$ 产生、$t_{end}^{(i)}$ 释放，区间内它“活着”。
    tstart(i)≤t<tend(i)t_{start}^{(i)} \le t < t_{end}^{(i)}
  3. 动态叠加把当前存活的所有张量体积 $s_i$ 求和。
    ∑i: tstart(i)≤t<tend(i)si\sum_{i:\,t_{start}^{(i)} \le t < t_{end}^{(i)}} s_i
  4. 时间曲线$M(t)$ 的峰值就是峰值内存，也是内存规划要压平的对象。
    M(t)=Mstatic+∑i: tstart(i)≤t<tend(i)siM(t) = M_{static} + \sum_{i:\,t_{start}^{(i)} \le t < t_{end}^{(i)}} s_i

性能基准测试

房车厨房里的大餐做完，总要放个计时器：这道菜花了多久、耗了多少电？下次烧同样的菜，才能知道改进有没有用。在边缘 AI 里，这就是性能基准测试——给推理流程装上计时器和温度计。

基准测试的指标通常有三类：延迟（单次推理耗时，看 p50/p90/p99 分位数而不是平均值）、吞吐（每秒推理次数 FPS）、资源（内存峰值和功耗）。方法上讲究“预热”：先在设备上跑几十次让缓存和频率热起来，再正式计时，否则首跑慢得吓人，测出来的全是假数据。TFLite 官方提供 benchmark_model 工具，ORT 提供 onnxruntime_perf_test，都是开箱即用的秒表。

核心度量公式如下：

回到房车厨房：计时器让你知道“炖牛肉从 40 分钟压到 25 分钟”，温度计让你知道“电没超蓄电池负荷”。只有量化，才谈得上决策——融合做不做、量化压不压、GPU 换不换，全部用数据说话。至此，一间“房车厨房”的优化全流程就走完了。

Tavg=1n∑k=1ntk,S=TbaselineToptimized,FPS=1Tavg\displaystyle T_{avg} = \frac{1}{n}\sum_{k=1}^{n} t_k, \qquad S = \frac{T_{baseline}}{T_{optimized}}, \qquad \text{FPS} = \frac{1}{T_{avg}}
通俗说：做十遍菜取平均耗时，改进前后对比，看看省了多少时间、一小时能出几桌。
  1. 平均延迟n 次推理延迟取平均，抑制随机抖动。
    Tavg=1n∑k=1ntkT_{avg} = \frac{1}{n}\sum_{k=1}^{n} t_k
  2. 加速比优化前后平均延迟相除，是汇报给老板的关键数字。
    S=TbaselineToptimizedS = \frac{T_{baseline}}{T_{optimized}}
  3. 吞吐率平均延迟的倒数，单位是“帧每秒”。
    FPS=1Tavg\text{FPS} = \frac{1}{T_{avg}}

AI 应用场景

智能安防摄像头的实时检测优化

阶段：模型部署与推理优化

解决的问题：传统做法直接把训练好的 ONNX 模型灌进摄像头边缘盒子，单帧目标检测延迟 120ms，内存峰值 800MB，而设备总内存只有 1GB，还要为其他业务留空间。这就像房车厨房只有“一只灶眼”却要同时烧好几个菜。用 ONNX Runtime 全部图优化加算子融合，再走 INT8 量化，最后用内存分析工具压峰值。

具体案例：某园区智能摄像头部署 YOLOv5s，使用 ORT 全部优化加动态内存规划后，延迟降到 46ms，内存峰值降到 230MB，并开启 GPU 委派。

工业质检流水线的稳定低延迟

阶段：推理管线调优

解决的问题：传送带速度要求每件检测小于 50ms，CPU 推理时快时慢，和“炖汤时干等锅”一样浪费时间。使用 TFLite GPU 委派加双缓冲流水线，把预处理、推理、后处理三个阶段重叠起来，让拷贝与计算并行。

具体案例：某 3C 产线质检工位用 TFLite 在 Jetson Nano 上跑缺陷检测，双缓冲加多线程后 p95 延迟从 72ms 降到 39ms，吞吐提升到 25 FPS。

智能音箱唤醒模型的内存瘦身

阶段：内存优化

解决的问题：语音唤醒模型要常驻内存，原来的 40MB 挤占了固件空间。用内存分析工具定位峰值张量，配合框架的共享缓冲区规划，让不同生命周期张量“轮流上岗”，就像三只碗轮着用。

具体案例：某智能家居设备用 TFLite 部署唤醒词模型，通过 arena 内存复用把常驻内存从 40MB 压到 15MB，加载时间也缩短了一半。

Python 演示

python75 行
import numpy as np  class ConvBNFuser:    # 演示 Conv 与 BN 折叠为单次卷积的算子融合    def __init__(self, in_ch, out_ch, ksize):        self.W = np.random.randn(out_ch, in_ch, ksize, ksize) * 0.1        self.b = np.random.randn(out_ch) * 0.1        self.gamma = np.random.randn(out_ch)        self.beta = np.random.randn(out_ch)        self.mean = np.random.randn(out_ch) * 0.1        self.var = np.random.rand(out_ch) + 0.5        self.eps = 1e-5     def conv(self, x):        # 简化卷积实现        n, c, h, w = x.shape        out_ch = self.W.shape[0]        oh, ow = h - 3 + 1, w - 3 + 1        out = np.zeros((n, out_ch, oh, ow))        for i in range(oh):            for j in range(ow):                patch = x[:, :, i:i + 3, j:j + 3]                for o in range(out_ch):                    out[:, o, i, j] = (patch * self.W[o]).sum(axis=(1, 2, 3))        return out + self.b.reshape(1, -1, 1, 1)     def bn(self, z):        # 批归一化推理形态        scale = self.gamma / np.sqrt(self.var + self.eps)        shift = self.beta - self.mean * scale        return z * scale.reshape(1, -1, 1, 1) + shift.reshape(1, -1, 1, 1)     def fold(self):        # 折叠 BN 参数进卷积        scale = self.gamma / np.sqrt(self.var + self.eps)        w_fused = self.W * scale.reshape(-1, 1, 1, 1)        b_fused = (self.b - self.mean) * scale + self.beta        return w_fused, b_fused     def conv_fused(self, x, w_fused, b_fused):        # 融合后的单次卷积        n, c, h, w = x.shape        out_ch = w_fused.shape[0]        oh, ow = h - 3 + 1, w - 3 + 1        out = np.zeros((n, out_ch, oh, ow))        for i in range(oh):            for j in range(ow):                patch = x[:, :, i:i + 3, j:j + 3]                for o in range(out_ch):                    out[:, o, i, j] = (patch * w_fused[o]).sum(axis=(1, 2, 3))        return out + b_fused.reshape(1, -1, 1, 1)  def main():    np.random.seed(42)    x = np.random.randn(2, 3, 8, 8)    fuser = ConvBNFuser(in_ch=3, out_ch=4, ksize=3)     # 原始两步工序    y_orig = fuser.bn(fuser.conv(x))     # 折叠后的单步工序    w_fused, b_fused = fuser.fold()    y_fused = fuser.conv_fused(x, w_fused, b_fused)     # 对比误差验证数学等价    err = np.abs(y_orig - y_fused).max()    print("fold max error:", err)    assert err < 1e-6, "fold failed"    print("BN fold verified: fused into one conv")  if __name__ == "__main__":    main()
目的：用 NumPy 实现卷积加批归一化的原始两步执行，再通过 BN 折叠合并成一次卷积，验证两者数学上完全等价——这正是算子融合背后的数值原理。
  1. def fold(self):折叠的核心方法，把 BN 的缩放与平移折算进卷积的权重和偏置。
  2. scale = self.gamma / np.sqrt(self.var + self.eps)计算每个通道的缩放因子，对应公式里的 $\gamma / \sqrt{\sigma^2 + \epsilon}$。
  3. w_fused = self.W * scale.reshape(-1, 1, 1, 1)把缩放因子按通道乘进卷积核，得到新权重 $W'$。
  4. b_fused = (self.b - self.mean) * scale + self.beta偏置做同样的折算，得到新偏置 $b'$。
  5. y_orig = fuser.bn(fuser.conv(x))融合前的“两步工序”：先卷积再批归一化，中间张量要落盘一次。
  6. err = np.abs(y_orig - y_fused).max()检查融合前后输出的最大误差，验证数学等价性。

常见误区

误区“把几个算子的代码合到一起写，编译器优化一下不就好了？省不了多少吧。”

正解编译器的代码合并和推理框架的算子融合是两回事。算子融合省的是运行时中间张量在内存里的整块读写——边缘设备上内存带宽有限，这一项常常是延迟的大头。实测卷积加 BN 加 ReLU 融合可以省掉三分之二的中间访存，端到端提升非常明显。

为何常见：桌面和服务端机器内存带宽充足，中间张量读写几乎不花时间，容易让人低估访存成本。

误区“我写代码时用完就释放，不就是在做内存复用吗？”

正解运行时 malloc 和 free 既有开销又产生碎片，而且无法保证新分配落在同一块地址。框架级内存复用是在加载图时做生命周期分析，一次性规划出“谁和谁共享哪块缓冲”，运行时零动态分配，就像房车厨房的排班表提前排好三只碗的轮岗。

为何常见：桌面开发中内存太便宜了，换到只有几十 MB 内存的嵌入式设备，才体会到差距。

误区“INT8 量化之后模型准确率肯定崩，反正又不能重训，还是别动了。”

正解现代后训练量化（per-channel 加校准数据集）在多数视觉模型上掉点小于 1%，换来 3-4 倍提速和四分之一体积。前提是用有代表性的校准数据算好缩放因子和零点，而不是随手一压。确有对量化敏感的模型，可以先用逐层敏感性分析定位。

为何常见：早期用过无校准的朴素量化吃了亏，从此以偏概全。

误区“边缘设备带 GPU 的，直接把所有算子都放 GPU 上跑就完事了。”

正解嵌入式 GPU 的算子调度、内存拷贝、驱动开销都不小。模型轻、算子少时，GPU 可能不如 CPU 快，甚至更慢。正确姿势是先把能合并的算子融合、减少拷贝，再让 GPU 与 CPU 分工，用基准测试对比数据说话。

为何常见：手机厂商宣传 GPU 性能深入人心，但那是旗舰机满血状态，嵌入式 GPU 的资源差得多。

误区“我 run 一次推理，用 time 记个总耗时就是延迟了，挺准的。”

正解第一次推理包含模型加载、内核初始化、缓存冷启动和频率爬升，不能代表稳态。需要在预热后多次运行，记录 p50、p90、p99 分位延迟，并固定 CPU 或 GPU 频率排除变频干扰，否则优化前和优化后根本没有可比性。

为何常见：追求快速跑通省事，忽略了测量方法论，导致优化方向被假数据带偏。

面试题

Q1. 算子融合主要优化的目标是？

单选题 · easy

  • A.中间张量的读写开销← 正确答案
  • B.模型文件的磁盘大小
  • C.训练数据的采集成本
  • D.网络反向传播的误差

答案：A。融合把多个算子合并成单个内核，中间输出不再“落盘”内存，省的主要是访存。磁盘大小由量化负责，训练成本与推理无关，误差也不是融合的对象。

Q2. 折叠 BN 后，卷积新偏置 b' 的正确表达式是？

单选题 · easy

  • A.直接把旧偏置原样保留继承
  • B.偏置结合均值折算再加平移项← 正确答案
  • C.直接将新偏置置为零向量
  • D.完全沿用折叠前的旧偏置值

答案：B。折叠公式是 $b' = \frac{\gamma (b - \mu)}{\sqrt{\sigma^2 + \epsilon}} + \beta$，把 BN 的平移和缩放全部折算进一次仿射，而不是保留旧偏置或置零。

Q3. 内存复用规划的核心依据是？

单选题 · easy

  • A.生命周期是否相互重叠← 正确答案
  • B.数值大小之间的比较
  • C.算子执行顺序是否固定
  • D.输入图像通道数的多少

答案：A。只要两个张量的生命周期不重叠，它们就可以共享同一块缓冲。框架在加载时做静态规划，与数值大小、输入通道数等无关。

Q4. 下面哪一项属于 TFLite 的优化手段？

单选题 · mid

  • A.动态语言运行时的解释
  • B.训练时自动混合精度
  • C.图优化与 INT8 量化← 正确答案
  • D.服务端多机并行推理

答案：C。TFLite 转换器做图优化 Pass（常量折叠、算子融合）和 INT8 量化压缩，再配合委派加速。其余选项分别属于解释执行、训练阶段和服务端场景。

Q5. 下列关于 ONNX Runtime 优化级别说法正确的是？

单选题 · mid

  • A.级别越高训练的轮数越多
  • B.级别越高图优化力度越强← 正确答案
  • C.级别越高数据增强越丰富
  • D.级别越高损失函数越复杂

答案：B。ORT 的优化级别从基础到扩展再到全部，控制的是图优化 Pass 的执行力度，与训练轮数、数据增强、损失函数完全无关。

Q6. GPU 推理管线中双缓冲的主要作用是？

单选题 · mid

  • A.重叠数据拷贝与计算← 正确答案
  • B.减少模型总体的参数量
  • C.提高量化使用的比特数
  • D.增加输入图像的分辨率

答案：A。双缓冲准备两块输入区，一块在 GPU 计算时，另一块同时接收 CPU 拷贝，让传输与计算重叠。参数量、量化位数、分辨率都与管线结构无关。

Q7. 内存曲线 M(t) 的峰值直接对应什么？

单选题 · hard

  • A.模型训练过程的收敛点
  • B.推理过程中的峰值内存← 正确答案
  • C.数据集样本数量的多少
  • D.网络参数稀疏化的程度

答案：B。M(t) 是推理过程中存活张量体积的叠加曲线，其峰值就是峰值内存，是内存规划和优化的目标。它与训练收敛、样本数、稀疏度不是同一层面。

Q8. 下面哪些属于性能基准测试的正确做法？

多选题 · mid

  • A.只取最快的单次成绩
  • B.预热后多次运行取统计← 正确答案
  • C.固定设备频率后再作对比← 正确答案
  • D.记录延迟的 p90 分位数← 正确答案

答案：BCD。正确做法是预热、多次运行、取分位延迟、固定频率保证可复现。只取最快一次是“运气值”，会被频变和调度干扰，不能代表稳态性能。

Q9. 算子融合能带来哪些方面的收益？

多选题 · hard

  • A.减少中间张量的读写开销← 正确答案
  • B.降低内核调度的总次数← 正确答案
  • C.提升模型训练的准确率
  • D.减小推理的峰值内存占用← 正确答案

答案：ABD。融合减少中间张量落盘、减少内核调度次数，也让峰值内存下降。训练准确率属于训练阶段的问题，与部署期的算子融合无关。

Q10. 边缘推理性能优化的常用手段包括哪些？

多选题 · hard

  • A.内存复用与缓冲规划手段← 正确答案
  • B.量化压缩与委派加速方案← 正确答案
  • C.扩大训练集样本的规模
  • D.算子融合与图优化技术← 正确答案

答案：ABD。内存复用、量化压缩、委派加速、算子融合与图优化都是推理侧经典优化。扩大训练集属于数据工程，不改变已训练模型的推理性能。