把训练好的 AI 模型从云端数据中心搬到手机里，就像把米其林后厨的招牌菜开进一台移动餐车。数据中心有大机房、用不完的电和随便造的散热；手机却只有一块电池、一小片散热板和一枚必须精打细算的芯片。CPU 是那位什么都会的全能大厨，可它只有一两双手，一次只能顾一口锅；GPU 则是一群只做重复动作的帮厨，人数成百上千，专干切菜、摆盘这类可以拆开同时干的活。神经网络推理的计算，恰恰几乎全是这种“重复劳动”。于是“怎么指挥这支帮厨队伍”，就成了移动端 AI 落地的头号问题。目前主要有两套指挥系统：老牌而通用的 OpenCL，以及新一代、要求提前写好整套作战计划的 Vulkan Compute。前者哪儿都能上岗，但每派一道工序都要喊话等待；后者前期规划繁琐，真正跑起来却行云流水。再加上算子融合、量化与内存布局、功耗热控这几样厨艺优化，就能在小小的餐车里，把原来“全精度大菜”做成“出餐快、不烫手、电池扛得住”的端侧招牌。

岗位关联

对 AI 从业者而言，掌握移动端 GPU 推理意味着能把模型从“云端演示”推向“量产落地”：性能、功耗、兼容性一手抓，正是端侧部署与推理优化岗位最硬核的竞争力。

目录
  1. 可视化演示
  2. GPU推理基础：餐车为什么要请帮厨
  3. OpenCL原理：老牌厨房管理系统的规矩
  4. Vulkan计算：只喊一次的作战计划
  5. 性能对比：两条流水线的时延账本
  6. 算子融合：把四条工序合成一条龙
  7. 量化与精度：用量勺代替电子秤
  8. 内存布局：案板上的摆盘顺序
  9. 功耗与热控：电池与散热的天花板
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

展示GPU并行计算核心调度、OpenCL与Vulkan Compute性能对比，以及算子融合减少内存读写和量化降精度过程。

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

GPU并行计算：32核心波次调度 绿色核心=活跃，灰色=空闲 TBDR架构按Tile分块渲染 底部数据流表示输入/输出带宽 并行度 = 核心数 \u00d7 时钟频率 \u00d7 IPC

GPU推理基础：餐车为什么要请帮厨

大饭店的后厨里，只有一位全能主厨（CPU），什么菜都会做，但一次只能顾一口锅。AI 模型上手机就像把年夜饭开进一台餐车：菜品固定、步骤重复。与其让主厨一勺一勺慢慢来，不如请一群只做重复动作的帮厨（GPU 核心），每人守一个灶台，几百人同时开火，出餐速度立刻不一样。

移动端推理的本质，就是让神经网络在手机芯片上“现做现卖”。网络的每一层都是一道工序，而卷积、矩阵乘法这些核心计算，说白了是一堆高度重复的乘加运算——天然适合帮厨们拆开并行。CPU 再全能也只有几个核，GPU 即使功耗预算被手机压得很低，依然能摆出上百个简单计算单元。这就是移动端推理优先找 GPU 的根本原因。

不过并行不是免费的午餐。用并行加速模型可以这样理解：设任务里可并行的部分占比为 f，p 个核心并行后，总加速比存在一个硬上限：

所以移动端推理的第一课：与其让主厨累到冒烟，不如把工序精确拆开，让帮厨们把重复劳动瓜分干净。主厨只负责调度，剩下的交给人群。

Sp=T1Tp≤1(1−f)+fp\displaystyle S_p = \frac{T_1}{T_p} \leq \frac{1}{(1 - f) + \frac{f}{p}}
  1. T1（串行基线时间）只有主厨一个人干活时做完所有菜的时间，是拿来对比的基线。
    T1T_1
  2. Tp（并行实际时间）p 位帮厨同时上手后，真正做完这桌菜所花的时间。
    TpT_p
  3. f（可并行比例）一顿饭里能分给多人同时做的工序（如切菜、摆盘）占全部工作量的比例。
    f=可并行工作量总工作量f = \frac{\text{可并行工作量}}{\text{总工作量}}
  4. 1-f（必须串行的部分）只能由主厨单独拍板的环节（调味、起锅），这是提速的天然天花板。
    1−f1 - f
  5. 不等式意义无论请多少帮厨，速度上限都被“必须串行的部分”锁死，所以算子必须尽可能并行化。
    Sp≤1(1−f)+f/pS_p \leq \frac{1}{(1 - f) + f/p}

OpenCL原理：老牌厨房管理系统的规矩

OpenCL 就像一位资历很老、几乎每家餐厅都在用的厨房管家。主厨（host/CPU）坐在后厨办公室里写任务单（kernel），通过一条传菜通道（命令队列）递给灶台前的帮厨们（device/GPU）。它的规矩清晰，但每派一道菜都要喊一嗓子、等一回话。

这个模型是典型的“主机-设备”两层架构：CPU 是主机，负责发号施令；GPU 是设备，负责闷头算。帮厨做菜前，食材必须从大冰箱（内存）搬上操作台（显存）。OpenCL 把一次计算拆成许多“工作项”（work-item），每个工作项落在 GPU 的某个计算单元上执行。

执行内核时，全局工作规模 G 被分成若干工作组，每个组有本地规模 L。硬件以“组”为单位把活派给计算单元，组内的帮厨还可以共享一张案板（本地内存）互相递料，不用每次去大冰箱取。

OpenCL 最大的优点是“一单通用”：几乎所有手机 GPU 厂商都支持，像老牌管理系统一样哪儿都能上岗。缺点是主厨每发一个算子都要喊话、等回话，算子一多，喊话的成本就盖过了干活的成本。

G=L×Ngroups\displaystyle G = L \times N_{groups}
  1. G（全局工作规模）整道工序的总次数，比如处理一张 224×224 图像时所有像素计算的总数。
    G=全局工作项总数G = \text{全局工作项总数}
  2. L（本地工作规模）每个工作组的规模，相当于一组帮厨的人数，通常设成 64、128 这类 GPU 友好的值。
    L=组内工作项个数L = \text{组内工作项个数}
  3. Ngroups（工作组数量）组数等于总量除以每组人数，硬件按组派活。
    Ngroups=GLN_{groups} = \frac{G}{L}
  4. 调度的意义组太少会空闲灶台，组太多调度开销变大，选 L 就是在平衡这帮厨的排班。
    G=L×NgroupsG = L \times N_{groups}

Vulkan计算：只喊一次的作战计划

Vulkan 是新一代厨房管理系统，理念正好相反：主厨别再频繁喊话。开工之前，把整个晚上的做菜流程、每个灶台的作业、谁先谁后的依赖，全部写成一本“指挥手册”（命令缓冲 command buffer），一次性交给帮厨们。

Vulkan Compute 是这套系统里的“纯计算模式”：不画画面，只埋头算。它有清晰的队列族概念，GPU 上专门划出计算队列；主厨通过管线（pipeline）描述清楚数据结构、线程分工，然后把调度命令（vkCmdDispatch）录进手册。手册里可以连续录几百次调度，帮厨按本子跑完一整条流水线，中途不用停下来等主厨复核。

对比 OpenCL 的“一算子一提交”，Vulkan 把 CPU 和 GPU 之间的来回往返（round-trip）压缩到了极致。这就像传菜员从“一菜一请示”变成了“一次派完整桌菜单”：前期规划多一点，高峰期跑起来就顺得多。

换句话说，OpenCL 像“一菜一请示”的传菜员，Vulkan 像“一次派完整桌菜单”的传菜员——这也是移动端推理越来越偏爱 Vulkan 的原因。

TVK=Trecord+NB×Tsubmit+Twait\displaystyle T_{VK} = T_{record} + \frac{N}{B} \times T_{submit} + T_{wait}
  1. Trecord（录制时间）主厨开工前写指挥手册的一次性成本，录一次可以反复用。
    TrecordT_{record}
  2. N/B（提交批次数）N 个算子按 B 个一批打包提交，批数越少，接触主厨的次数越少。
    NB\frac{N}{B}
  3. Tsubmit（单次提交开销）每次把手册递出窗口的固定开销，Vulkan 把它压得非常低。
    TsubmitT_{submit}
  4. Twait（等待同步）帮厨干完等验收、等别的队列的时间，控制越显式，等待越少。
    TwaitT_{wait}

性能对比：两条流水线的时延账本

同样一桌菜，两套管理系统差在哪里？差在中间环节。OpenCL 每次启动一个算子都要经历“排队、传参、启动、等待”四步，单次开销大；Vulkan 则把中间步骤尽可能砍掉，像流水线改成了直达专线。

从时延账本看：设每个算子单次启动开销分别为 Lo（OpenCL）和 Lv（Vulkan），固定成本（初始化、编译内核）都是 C，跑 N 个算子。总耗时 ≈ 固定成本 + N×启动开销 + 计算时间。手机上实测（Adreno、Mali 等 GPU），OpenCL 单算子启动常在几十微秒量级，Vulkan 能压到一半甚至更低。

N 越大，这个差距被放大得越明显。当算子数量趋于无穷时，固定成本和计算时间都被摊薄，总耗时之比趋近于纯启动开销之比：

所以要学会看“流水线总账”而不是单算子分数。模型越深、算子越多，Vulkan 的低启动优势越值钱；反过来，浅模型里 OpenCL 的成熟生态和省心程度可能更实际。

lim⁡N→∞TOCLTVK=LoLv\displaystyle \lim_{N \to \infty} \frac{T_{OCL}}{T_{VK}} = \frac{L_{o}}{L_{v}}
  1. TOCL 与 TVK两套系统跑完同样 N 个算子的总时间，是两本账的总额。
    TOCL=C+N×Lo+N×tcomputeT_{OCL} = C + N \times L_o + N \times t_{compute}
  2. 固定成本 C两套都要付的一次性开销（编译内核、建上下文），长流水线里被摊得很薄。
    CC
  3. N×Lo 与 N×Lv启动开销随算子数量线性增长，Lo 比 Lv 大时，差距被 N 不断放大。
    N×Lo>N×LvN \times L_o > N \times L_v
  4. 极限结论算子极多时，固定成本和计算时间相互抵消，最终差距就是启动开销之比。
    lim⁡N→∞C+NLo+NtcC+NLv+Ntc=LoLv\lim_{N \to \infty} \frac{C + N L_o + N t_c}{C + N L_v + N t_c} = \frac{L_o}{L_v}

算子融合：把四条工序合成一条龙

模型推理里的算子就像一道道小工序：卷积完了接 ReLU，再接池化。老派做法是每道工序结束，中间结果都“装盘放回冰箱”（写回显存），下一道工序再“端出来”（读显存）。一来一回，搬货的时间和力气远大于做菜本身。

算子融合就是把这几个相邻算子合并成一个大算子：比如卷积+ReLU 融合成一个内核，算完一个像素立刻激活，中间结果根本不落地。帮厨们一条龙做完，省掉 K 次启动、K-1 次中间回写，只保留“开头读一次、结尾写一次”。

数学上，融合前后计算量完全不变，但内存访问从“每算子读写一遍”降为“整条链读写一遍”。设单个算子读写成本为 Trw，启动成本为 Tlaunch，融合后的账本一目了然：

在移动端，访存往往比算力更贵——就像餐车里“把食材从冰箱端进端出”比“下锅翻炒”更费电更费时。融合就是改菜单：把洗菜、切菜、焯水合成一份“预处理套餐”，一次端上灶台。

Tunfused=K×Tlaunch+K×Trw,Tfused=Tcompute+Trw\displaystyle T_{unfused} = K \times T_{launch} + K \times T_{rw}, \qquad T_{fused} = T_{compute} + T_{rw}
  1. K（融合的算子个数）例如卷积+BN+ReLU 融合时 K=3，三道工序并成一道。
    KK
  2. Tlaunch（启动开销）每个算子独立开会喊话的成本，融合后全家只喊一次。
    TlaunchT_{launch}
  3. Trw（读写内存成本）中间结果进出显存的搬运费，与数据量成正比。
    TrwT_{rw}
  4. 融合后的节省启动从 K 次变 1 次，搬运从 K 次变 1 次，计算量原地不动。
    Tfused=Tcompute+TrwT_{fused} = T_{compute} + T_{rw}

量化与精度：用量勺代替电子秤

FP32 全精度像一位追求完美的厨师，每勺调料都要用电子秤精确到 0.1 克。但移动端餐车地方小、火候有限，大多数街边顾客只在意“味道够好、出餐够快”——这就是量化和半精度存在的理由。

FP16 半精度把每个数字从 32 位减到 16 位，数据量减半、带宽需求减半，GPU 的半数运算单元还能获得翻倍吞吐；INT8 量化更进一步，把数字变成 8 位整数，数据量再砍一半，还能走硬件整数加速指令。代价是动态范围变小，极端值会被“四舍五入”截断。

好在误差可以校准回来：拿一小批真实数据跑一遍，统计各层激活的分布，求出缩放因子（scale）和零点（zero-point），把浮点权重映射到整数域。敏感层（如最后几层）则保留高精度，把损失压到几乎尝不出来。

就像餐车启用“标准化量勺”：少数挑剔顾客（敏感层）吃得出差别就单独精做，大多数路人只觉得“出餐快、味道够”。量化校准就是试菜阶段调配方，把那点误差抹平。

Bfp16=Bfp322,Bint8=Bfp324\displaystyle B_{fp16} = \frac{B_{fp32}}{2}, \qquad B_{int8} = \frac{B_{fp32}}{4}
  1. Bfp32（全精度数据量）FP32 下权重加激活的字节数，每个数占 4 字节。
    Bfp32B_{fp32}
  2. Bfp16（半精度搬运量）每个数占 2 字节，同样数据量只需一半带宽，搬运明显更快。
    Bfp16=Bfp322B_{fp16} = \frac{B_{fp32}}{2}
  3. Bint8（8 位量化搬运量）每个数占 1 字节，带宽需求降为四分之一，还能用整数加速单元。
    Bint8=Bfp324B_{int8} = \frac{B_{fp32}}{4}
  4. 敏感层保留高精度不是所有层都适合压精度，输出层和关键分支常单独保留 FP16/FP32。
    敏感层保留高精度\text{敏感层保留高精度}

内存布局：案板上的摆盘顺序

同样一堆食材，摆在案板上的顺序直接影响出餐速度。张量在内存里也有“摆盘姿势”：NCHW 把同一通道的所有像素码在一起，像土豆全放一筐、胡萝卜全放一筐；NHWC 按像素位置把几个通道放成一碟四拼。

GPU 访存按“行突发”（burst）读取连续地址，连续读得越多，带宽利用率越高。卷积在 GPU 上常用 NHWC，因为同一像素的通道数据正好连续命中缓存；而 CPU 侧和不少框架习惯 NCHW。布局一旦选错，搬运效率可能差好几倍。

端侧部署的常见手段是“显式重构”：推理开始前，用一次布局转换把输入和权重摆成 GPU 最爱的姿势，之后计算全程不再变布局；或者干脆让算子原生支持目标布局，在算子内部悄悄完成转置，避免额外搬运。

一句话总结：餐车备菜时把“每桌一碟的四拼”提前配好，高峰期直接端盘，比临时翻箱倒柜找食材快得多。内存布局优化就是这种“备菜哲学”。

Tmem=DBburst×λ\displaystyle T_{mem} = \frac{D}{B_{burst}} \times \lambda
  1. D（张量数据量）要读写的字节总数，布局选哪种都不会改变它。
    DD
  2. Bburst（突发带宽）单次内存突发能连续搬的字节数，连续布局能打满，跳跃布局打不满。
    BburstB_{burst}
  3. λ（延迟因子）每一笔突发访问的延迟，地址越跳、缓存命中越差，λ 越大。
    λ\lambda
  4. 布局优化的本质让数据“排成长队”按行扫过，而不是“插花乱采”，就是把 D/Bburst 压到最小。
    Tmem=DBburst×λT_{mem} = \frac{D}{B_{burst}} \times \lambda

功耗与热控：电池与散热的天花板

移动餐车和饭店最大的区别：电源只有一块电池，炉子开太猛会跳闸、烫手。手机 GPU 满血推理时功耗能冲到好几瓦，芯片一热就撞温度墙、频率骤降，帧率延迟全线雪崩——这就是“飘移”（throttling）。

功耗这笔账要算“功率×时间”：频率提 20%，动态功耗往往涨 40% 甚至更多（动态功耗与电压、频率近似平方乃至高次关系），性能却只涨 20%。与其顶着热墙反复横跳，不如找一个“甜点频率”：同样的推理任务，功耗低一大截，帧率只掉一点点。

端侧推理的成熟套路是：先跑基准，画出“频率-时延-功耗”曲线，再按需求选档（性能档/均衡档/省电档）；配合温控驱动，高温时主动限频，而不是被被动降频打得措手不及；长任务用小批次穿插空闲，给芯片留喘息机会。

好的移动端推理框架像有经验的车手：知道电池的边界、温度的红线，在“多踩一点油门”和“稳住不烫手”之间找最优路线。性能数字再好看，手机一发热降频，一切归零。

E=Pavg×T=∫0TP(t) dt\displaystyle E = P_{avg} \times T = \int_{0}^{T} P(t)\, dt
  1. E（总能耗）跑完一次推理消耗的电池能量，决定手机续航。
    EE
  2. Pavg（平均功率）整段时间的平均用电功率，约等于电压乘电流。
    PavgP_{avg}
  3. T（推理耗时）完成任务的总时间，频率越高 T 越小，但 P 涨得更快。
    TT
  4. 积分视角功耗-时间曲线下的面积才是真能耗，“快而烫”未必比“稳而凉”划算。
    E=∫0TP(t) dtE = \int_{0}^{T} P(t)\, dt

AI 应用场景

实时视频人像虚化：Vulkan 管线的低延迟舞台

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

解决的问题：人像分割模型如果放云端，一帧要往返几十毫秒还要看网络脸色，用户完全无法接受。用 Vulkan Compute 把整个模型的所有算子提前录成一条命令缓冲，再叠加卷积+BN+ReLU 融合和 FP16 半精度，把延迟压进一帧的预算内。

具体案例：某美颜 App 在旗舰机上用 Vulkan 录制 30 条调度的命令缓冲，把 U-Net 风格的人像分割模型从 25ms 压到 6ms，实现 60fps 实时虚化，且手机温度稳定。

离线语音唤醒词检测：OpenCL 守护老机型

阶段：模型量化与多端兼容适配

解决的问题：中低端车机、旧手机往往不支持 Vulkan 或驱动有 bug，必须用 OpenCL 保底；同时唤醒模型常驻内存，INT8 量化能把模型从 40MB 压到 10MB，功耗大幅下降。

具体案例：某车载语音助手在 Mali GPU 的低端车机上跑唤醒模型，INT8 量化 + OpenCL 部署，唤醒时延从 300ms 降到 120ms，待机听写功耗下降 60%。

户外安防摄像头目标检测：甜点频率守住续航

阶段：推理性能调优与功耗热控

解决的问题：设备靠电池供电、无风扇散热，满频跑检测必然过热降频，导致白天高温时画面掉帧。需要通过基准曲线选甜点频率，配合主动温控，保证 7×24 小时稳定。

具体案例：某户外摄像头在骁龙平台上跑 YOLO 变体，把频率降到最高频的 85%，功耗降 40%，帧率只掉 8%，正午高温不再触发被动降频雪崩。

Python 演示

python34 行
def simulate_launch_overhead(num_ops, launch_us, compute_us, rw_us, fused=False):    # simulate total latency of launching and running operators    if fused:        ops = 1  # fused kernel launches only once    else:        ops = num_ops    launch_total = ops * launch_us    # unfused writes intermediate result back to memory for every op    rw_total = rw_us if fused else rw_us * num_ops    compute_total = compute_us * num_ops  # compute amount stays unchanged    return launch_total + rw_total + compute_total  def main():    num_ops = 20    compute_us = 50      # pure compute per op in microseconds    rw_us = 30           # memory read/write cost per op    opencl_launch = 40   # OpenCL per-launch overhead    vulkan_launch = 15   # Vulkan per-launch overhead     t_ocl = simulate_launch_overhead(num_ops, opencl_launch, compute_us, rw_us)    t_vk = simulate_launch_overhead(num_ops, vulkan_launch, compute_us, rw_us)    t_fused = simulate_launch_overhead(        num_ops, vulkan_launch, compute_us, rw_us, fused=True)     print("OpenCL total: %.0f us" % t_ocl)    print("Vulkan total: %.0f us" % t_vk)    print("Vulkan+fused: %.0f us" % t_fused)    print("Vulkan is %.1fx faster than OpenCL" % (t_ocl / t_vk))    print("Fused is %.1fx faster than unfused Vulkan" % (t_vk / t_fused))  if __name__ == "__main__":    main()
目的：用一张简化的“开销账本”模拟 20 个算子在 OpenCL、Vulkan 以及 Vulkan+融合三种方案下的总耗时，直观量化启动开销和内存搬运的影响。
  1. def simulate_launch_overhead(num_ops, launch_us, compute_us, rw_us, fused=False):模拟器核心，把启动、搬运、计算三类成本分开记账。
  2. ops = 1 # fused kernel launches only once融合后只需启动一次内核，对应“一次喊话派完整桌菜”。
  3. rw_total = rw_us if fused else rw_us * num_ops融合省掉中间 K-1 次内存回写，未融合则每个算子都要搬运一次。
  4. compute_total = compute_us * num_ops计算量融合前后不变，符合“融合只省启动和搬运”的原理。
  5. opencl_launch = 40` 与 `vulkan_launch = 15两组启动开销参数，体现两套管理系统的差别。
  6. t_fused = simulate_launch_overhead(..., fused=True)叠加融合后的最优场景，最终输出三者的加速比对比。

常见误区

误区手机发布会说 GPU 有几百上千个核，那我模型丢上去肯定飞快，核数就是性能的全部。

正解核数只是“帮厨人数”，出餐速度还取决于传菜通道（内存带宽）、主厨喊话频率（启动开销）和工序能否拆开（算子并行度）。Amdahl 定律里那个“必须串行的部分”才是天花板；有时算子访存密集，带宽不足，加再多核也是帮厨们排队等菜。

为何常见：厂商宣传最爱突出核数，加上我们习惯了 CPU 多核“核越多越快”的直觉，忽略了移动端真正的瓶颈常在搬运和调度。

误区既然测试说 Vulkan 快，那所有项目统一上 Vulkan 就完了，OpenCL 可以退休。

正解Vulkan 的优势主要来自更低的启动开销，模型越深、算子越多才越明显；浅模型上两者可能打平甚至 OpenCL 因生态成熟更稳。更关键的是，大量老旧中低端机型 Vulkan 驱动不完善或干脆不支持，OpenCL 的兼容性优势依然不可替代。

为何常见：只看到旗舰机 benchmark 上的峰值差距，忽视了真实用户机型分布和驱动质量。

误区拿 Python 把模型权重 round 一下存成 int8，跑起来又快又省，精度差点无所谓。

正解直接截断会剧烈损失精度。正确流程要用真实校准数据跑一遍，统计每层激活分布，算出缩放因子和零点；敏感层还要保留 FP16/FP32。推理时也要做反量化，否则整数域和浮点域对不上，结果全错。

为何常见：听到“INT8 成熟方案”就以为是个自动开关，忽略了量化是“数据分布感知”的精细活。

误区融合能省启动和搬运，那把整张网络所有算子都塞进一个内核，岂不是起飞？

正解融合会增加单内核的寄存器压力和占用，导致并行度下降、占用率变低；某些结构（如需要全局信息的算子）强行融合反而更慢。融合与否要看 GPU 资源上限和算子特性，通常 Conv+BN+ReLU 这类“局部流水”最划算。

为何常见：看到融合加速的案例就推广到所有情况，忽视了“寄存器、占用率、并行度”之间的互相牵扯。

误区功耗跟着频率走，那把 GPU 锁到最低频率，电池肯定最耐用。

正解能耗是功率乘时间（E=P×T）。频率降 20%，功耗可能只降 10%，但耗时长 30%，总能耗反而更高，体验也更卡。正确做法是画“频率-时延-功耗”曲线找甜点频率，而不是一味求低。

为何常见：凭“低速省电”的生活直觉做判断，忘了总能量是功率对时间积分，快而短有时比慢而长更省。

面试题

Q1. 移动端推理为何更青睐 GPU 而不是 CPU？

单选题 · easy

  • A.逻辑分支控制能力更强
  • B.拥有大量并行计算单元← 正确答案
  • C.天然功耗比 CPU 更低
  • D.数据无需经历内存搬运

答案：B。神经网络里大量矩阵乘法和卷积是重复运算，像切菜一样可分给几百个帮厨（GPU 核）同时做；CPU 再全能也只有几双手，串行执行是瓶颈。A 把 CPU 的优势说反，C 忽略功耗取决于频率设计，D 忽略 GPU 计算也要从内存取数。

Q2. OpenCL 的“主机-设备”模型中，负责下发内核命令的是？

单选题 · easy

  • A.GPU 加速计算单元
  • B.CPU 主控端← 正确答案
  • C.神经网络权重数据
  • D.手机屏幕显示驱动

答案：B。OpenCL 把 CPU 当主机、GPU 当设备：主机像后厨办公室里的主厨，负责写好内核、排队下发命令；设备像灶台前等活的帮厨。GPU 是被指挥方，权重只是数据，屏幕驱动与计算无关，故选 B。

Q3. Vulkan Compute 相对 OpenCL 的核心优势是？

单选题 · mid

  • A.支持更多老款手机
  • B.驱动自动完成调度
  • C.降低每次启动算子开销← 正确答案
  • D.减少训练所需算力

答案：C。Vulkan 的理念是“提前写好整套作战计划”，用命令缓冲一次提交大量调度，减少 CPU-GPU 回合，把单算子启动开销压低。老机型兼容其实是 OpenCL 的强项；调度自动化反而违背 Vulkan 显式控制的设计；训练与推理无关。

Q4. 下列哪个属于典型算子融合操作？

单选题 · mid

  • A.卷积与 ReLU 合成一个内核← 正确答案
  • B.把 FP32 权重压成 INT8
  • C.把 NCHW 布局转成 NHWC
  • D.把 GPU 频率调到甜点区间

答案：A。算子融合是把相邻算子合并成一个内核，像把“洗菜、切菜”合成一道工序，避免中间结果回内存。量化是改数据精度，布局转换是改内存排列，调频是功耗控制，三者都不是算子融合。

Q5. 算子融合主要省掉了什么成本？

单选题 · mid

  • A.模型下载的网络流量
  • B.中间结果的内存搬运与启动← 正确答案
  • C.手机屏幕渲染的耗电
  • D.训练数据标注的成本

答案：B。未融合时每个算子结束都要把中间张量写回显存，下一个算子再读出来，像每道小菜都先装回冰箱。融合后这条链只在开头读一次、结尾写一次，启动也从 K 次变 1 次。与网络流量、渲染、训练均无关。

Q6. 融合 K 个算子后，中间张量的访存总量约为？

单选题 · hard

  • A.仍约为原来的 K 倍
  • B.降为原来的 K 分之一
  • C.接近原来一次读写量← 正确答案
  • D.可以完全减少到为零

答案：C。融合后 K 个算子在寄存器或片上高速内存里接力完成，中间结果不再每步回全局内存，所以访存量从 K 次读写变成接近“一次输入、一次输出”。但并非零：输入输出总要有一次搬运，故 C 对、D 错；A 是未融合形态，B 把收益夸大了。

Q7. 由 E=P×T 可知，单纯把 GPU 频率调低可能？

单选题 · hard

  • A.总能耗必定越来越低
  • B.耗时变长反而更费电← 正确答案
  • C.电压不再影响动态功耗
  • D.与功耗曲线完全无关

答案：B。降频让功率 P 下降，但耗时会拉长。若功率只降 20% 而耗时长 50%，E=P×T 反而变大，像小火慢炖比大火快炒更费燃气。动态功耗与电压频率的非线性关系也说明 C、D 错误；“必定更低”失之绝对。

Q8. 以下哪些手段能有效降低移动端推理的内存搬运开销？

多选题 · mid

  • A.融合算子减少中间张量回写← 正确答案
  • B.选择连续内存布局用满带宽← 正确答案
  • C.提高 CPU 主频加速调度
  • D.增加网络层数提升精度

答案：AB。内存搬运的敌人是“中间结果反复回流”和“不连续访问”。算子融合砍掉中间回写，连续布局让突发读打满带宽，都直击要害。提 CPU 主频只是让调度更快，并没有减少搬运量；加深网络反而增加搬运量。

Q9. 关于 INT8 量化，下列说法正确的是？

多选题 · hard

  • A.数据搬运量降为 FP32 的四分之一← 正确答案
  • B.需要校准数据统计激活分布← 正确答案
  • C.所有层量化后精度完全无损
  • D.量化后权重无需再做缩放

答案：AB。INT8 用 1 字节代替 4 字节，搬运量变四分之一；但动态范围小，要先拿真实数据跑校准，算出缩放因子和零点，敏感层还要保留高精度，所以并非无损。推理时要用 scale 和 zero-point 反量化，D 说法错误。

Q10. 移动端 GPU 推理的功耗热控常用实践有哪些？

多选题 · hard

  • A.依据基准曲线选择甜点频率← 正确答案
  • B.高温时主动降频避免撞墙← 正确答案
  • C.关闭并行核去节省电能
  • D.忽略温控让芯片满频运行

答案：AB。手机推理讲究“稳”，先测出频率-时延-功耗曲线，选能耗最划算的甜点频率；温度高时主动限频，防止被动降频造成掉帧雪崩。关闭并行核会摧毁 GPU 并行优势，反而更慢更耗；满频跑必然撞温度墙，都不可取。