我调试骁龙平台AI应用时，遇到一个特别典型的现象：同样的模型，在GPU上跑和用NPU跑，性能差距有时能拉到三四倍，但功耗差距却不是线性变化。早期遇到这种情况，常规做法是手动指定“用GPU”或“用NPU”，结果经常顾此失彼——跑得快了发热压不住，压住功耗了帧率又塌。后来系统学习高通Adreno Neural Fusion之后才明白，真正适合AI推理的方式，不是选边站队，而是让硬件自己“看菜下饭”，把每一帧、每一层计算分给最合适的加速单元。
Adreno Neural Fusion是高通在Snapdragon平台上推的异构AI调度方案，核心变化就是“告别单臂发力”。它不再把推理任务简单丢给某一个核心，而是通过一个硬件级的调度器，把神经网络计算动态拆解，交给Adreno GPU、Hexagon NPU（HTP）、甚至CPU算力池协同处理。这篇文章围绕这个题目，把ANF背后的硬件加速单元设计逻辑、 Kernel侧和用户态的配合方式、以及我做性能调优时的实际操作讲清楚，适合正在做Android图形栈、游戏引擎优化、端侧AI部署的朋友参考。
1. 内容整体设计与思路拆解
1.1 “全新硬件加速单元”到底新在哪里
很多人在看高通新一代移动平台的规格表时，会注意到一个表述频繁出现——“Adreno Neural Fusion通过全新硬件加速单元”。
这句话看着官方，其实信息量不小。传统的高通AI执行路径是“指令分发”，也就是CPU先把神经网络每一层的算子翻译成目标硬件能懂的命令，然后交给指定模块执行。这个模式最大的问题是“目标硬件拆固定”：如果模型里卷积层特别多，而你把整个模型都丢给NPU，那NPU可能是瓶颈；如果某个自定义算子NPU不支持，回退到GPU反而更快。在这个过程里，所有决策都是提前写死的，运行中没有变通余地。
Adreno Neural Fusion的“新”，在于引入了一个融合调度硬件单元，它并不负责计算本身，而是专门做算力感知和任务编排。它在硬件层面实时统计各加速单元的负载、带宽占用、温度预算，然后动态决定把哪个Layer丢给哪个单元。换句话说，旧的执行方式是“人肉分配”，ANF是“现场调度”。
我在测试高通骁龙8 Gen系列GPU频率曲线时发现，ANF生效时，GPU的dgpu_pwr_level和NPU的qos_request会出现联动抬升或回落。这是以前固定分配模式下看不到的硬件间协同信号，也直接说明了这个调度单元的真实存在，它不是软件层的假把式，而是直接参与电源和总线控制。
1.2 异构计算视角下，ANF的设计目标是什么
理解ANF之前，得先对齐一个概念：端侧AI的痛点从来不是“算力不够”，而是“算力无法被有效利用”。
举个具体的例子：模型A有大量3x3卷积，这种算子对GPU特别友好，因为GPU的并行SIMD架构天然适合这类形状规整的计算。模型B却包含不少动态shape的LSTM或Gather算子，这类任务跑在NPU上反而不香，原因在于NPU需要静态编译和内存规划，动态分支会带来大量stall。
如果平台策略是“模型统一走NPU”，那模型B的延迟就会高得离谱。但如果平台策略是“让硬件自己判断”，把模型A的卷积层给GPU、把模型B的动态分支给CPU或DSP，整体帧耗时反而下降。
ANF想要解决的就是这件事，把“异构”从supplier模式变成manager模式。它不光看某一款硬件能不能跑，还要看当前功耗余量、总线拥堵情况、温升趋势，再决定任务切分方式。这一点和电脑上玩混合交火或大小核调度器是一个思路，核心是“动态适配”而不是“静态切分”。
在具体实现上，ANF的调度逻辑照顾三个维度，这也是我在trace里观察到的规律：
- shape依赖：适合并行吞吐的算子优先考虑GPU，例如卷积、GEMM
- 依赖链长度：单层算子延迟敏感、依赖链短的，可丢给专精单元降低排队时间
- 功耗余量：温升接近阈值时，重型任务暂时集中到一个低功耗单元，避免全模块高负载叠加
这套逻辑有点像你做饭时先看燃气灶够不够用、再看烤箱要不要预热、最后决定先炒菜还是先炖汤，绝对不是“一个灶头用到黑”。
2. 核心细节解析与实操要点
2.1 ANF调度链路里的角色分工：GPU、Hexagon NPU与总线
要实际操作ANF，先把它的调度链路拆开看。和高通AI应用直接打交道的主要有三个模块：Adreno GPU、Hexagon NPU（也就是大家常说的HTP，High-Performance Tensor Processor）、以及连接它们的系统总线。
在ANF模式下，GPU和NPU不再各干各的。以我测试过的一个超分辨率模型为例：
- 前几层特征是RGB图像，数值范围固定，数据排布是NCHW格式，这类算子被调度器分给GPU，因为Adreno的纹理单元对连续存储的空间数据读取效率特别高。
- 中间层的残差块包含大量3x3卷积和ReLU激活，计算密集、逻辑简单，非常适合NPU的脉动阵列。
- 最后的上采样层涉及像素重排，对内存读写模式要求高，又回给GPU处理。
从底层机制看，这个调度过程涉及数据在GPU显存与NPU内存之间的来回搬运。ANF能跑得顺，不仅仅因为是“调度算法好”，更主要的原因是硬件单元之间有一条低延迟的缓存一致性总线（在骁龙平台内部叫LLC，Last Level Cache）做支撑。数据不用从DDR绕一个大圈再回来，而是在LLC里直接“交接”，搬运开销小了一个数量级。
这也是为什么很多开发者最开始用老方法直接调GPU或NPU时，会看到性能反而下降——因为那些方案压根没有打通LLC上的数据直传路径，只是把“数据倒腾到内存，再喂给另一个单元”，光拷贝开销就能吞掉所有加速红利。
2.2 CPU在其中扮演什么角色：别把它排除在外
必须说清楚一个容易误判的点：ANF不是GPU+NPU的二人转，CPU也是算力池的一部分。
虽然在高通平台上，CPU自带AI加速指令（类似Arm的Dot Product扩展），但它的算力密度远不如GPU/NPU。ANF把任务交给CPU，往往是以下几种场景：
- 模型里有大量自定义算子，既没有GPU kernel也没有NPU kernel，只能CPU硬扛
- 算子形状特别小，比如1x1卷积或单点Reshape，放到NPU上排队的时间比执行还长，CPU直接处理反而更快
- 等待某个异步任务完成时，用CPU做一个小的前处理再切入主计算流，避免唤醒NPU造成延迟
我在调试一个实时视频抠图模型时遇到过这种情况：模型本身绝大多数算子在NPU上，但输入视频帧的预处理，比如归一化、padding、通道重排，则跑在CPU上。ANF模式下，它会把这部分CPU工作也纳入整体调度视野，而不是像以前那样CPU算完再硬等NPU排队。这样整条流水线的pipeline latency降低了将近30%。
所以不要一提到ANF就只盯着GPU和NPU，CPU在ANF的调度器里是“橡皮图章”，哪里缺位补哪里。
2.3 硬件加速单元如何感知AI负载
好的调度器一定依赖好的“感知机制”。ANF调度器要动态分配任务，前提是它得知道各单元当前的占用率、纹波功耗和温度。
在高通平台上，这些信息从两个通道汇总：一个是Kernel侧的调频调压节点，一个是硬件级的PMU计数器和温度传感器。
Kernel侧会周期上报每个加速单元的负载百分比。比如查看GPU频率节点时，能看到当前档位和真实占用；查看NPU的QoS请求时，能看到是否有高优先级AI任务正在排队。ANF调度单元结合这些数据，估算出“如果把这个算子放到GPU，预计需要多少个cycle；放到NPU，排队延迟是多少”的模型，然后加权比较，选出一个最低预测延迟的路径。
这个感知和预测过程对用户的直观影响，就是系统表现“聪明”：同一款模型在温度低时可能被分给GPU，追求极致性能；在机身发热到42度以上时分给NPU，用功耗换稳定帧率。这就是“全新硬件加速单元”的真正价值——它让AI加速变得有温度感知、有功耗边界。
3. 实操过程与核心环节实现
3.1 如何确认ANF确实在正常工作
很多开发者拿到平台的运行库后，会用老办法验证AI性能：直接跑benchmark，看FPS和延迟。但在ANF架构下，这个做法不够——你看到的FPS只是最终结果，没法分辨是“GPU单独跑出来的”还是“ANF调度器融合跑出来的”。
我自己常用的验证手段是抓取系统trace，越底层越好。高通平台提供了perfetto和systrace等工具，能跑到核间调度、GPU频率、NPU活跃度这些级别。
操作步骤如下：
- 在Android设备上打开开发者选项，开启“GPU渲染模式分析”和“HWUI调试”。
- 连接PC后用
adb shell atrace抓trace，抓取字段要带上sched、gpu、frequency、qos这类标签。 - 运行目标AI应用或benchmark约2到3分钟，确保覆盖到不同负载阶段。
- 拉取trace后用Perfetto UI打开，观察GPU Frequency轨和NPU Active轨是否有交替升压、交替回落的曲线。
我在实际抓trace时见过两种典型的ANF生效特征：一是GPU频率不高但帧耗时依然稳定，这是因为大量计算被分到NPU了；二是GPU频率和NPU活跃度曲线存在互补关系，那边忙这边闲、这边忙那边闲。如果看到某一个硬件长时间满负载而另一个完全空闲，基本可以判断ANF没生效或模型根本没走上ANF通道。
3.2 在用户态调优：限制频率、QoS与任务优先级
ANF虽然能动态调度，但它仍然要“听”用户态的命令。在高通平台上，你可以用sysfs节点或libQnn的接口影响调度策略。
比如在调GPU游戏性能叠加AI特效的场景下，我会用如下命令把GPU频率锁到中高档位，给足性能余量。
# 查看GPU可用频率档位 cat /sys/class/kgsl/kgsl-3d0/gpu_available_frequencies # 设置最大频率，例如锁定到最高档 echo 900000000 > /sys/class/kgsl/kgsl-3d0/max_gpuclk # 查看当前实际频率 cat /sys/class/kgsl/kgsl-3d0/gpuclk这里有个很容易踩的坑：直接写max_gpuclk并不会让GPU保持满频，它只是设了天花板，实际频率仍由系统负载和温控策略决定。如果想要高负载下性能稳定，必须在应用层主动提高工作量优先级，让GPU负载感知阈值尽早跨过升频门槛。
对于NPU侧，高通平台一般通过QoS接口控制。在HTP上跑模型时，可以申请高优先级QoS请求，这样当ANF调度器做拆解时，NPU侧的任务不用长时间排队：
# 通过sysfs查看NPU QoS状态（具体路径平台略有差异） cat /sys/class/devfreq/3d00000.qcom,htp/cur_freq cat /sys/class/devfreq/3d00000.qcom,htp/load注意，QoS请求不是越高越好。如果你的应用只是周期性地做一次超分处理，长期霸占高优先级会干扰其他系统任务，得不偿失。正确的做法是在关键线程开始推理时临时抬优先级，推理结束立刻释放。
3.3 与高通CAF Kernel的配合：调频调压节点与平台功耗管理
Adreno Neural Fusion虽然是硬件级调度，但它的很多边界条件是由Kernel传入的。高通CAF（Code Aurora）内核中，与ANF直接相关的调频调压策略散落在GPU、NPU和DDR的devfreq节点里。
在分析一个发热降频问题时，我通常按下面顺序排查：
- 先看整机温度：
cat /sys/class/thermal/thermal_zone*/temp - 再看GPU和NPU实际频率是否被“压频”：通过
cur_freq节点观察 - 然后看系统是否触发了调度器的
power-aware调度策略：这通常会体现在/proc/sys/kernel/sched_energy_aware或内核日志里的LMh（Limit Management hardware）事件中
有一次我跑AI夜景增强算法，前30秒帧率很好，30秒后速度断崖式下降。排查后发现，温度到了阈值后，LMh硬件限制了整个平台的最大功耗，GPU和NPU都拿不到足够电力，ANF调度器再怎么“智慧”也只能在功率预算内做最小损失选择。解决思路不是改ANF，而是优化算法本身的计算量，让每帧耗时变短，从而降低整体功耗。
所以这里要记住一条经验：ANF不是免费的午餐，它解决的是“如何更好分配算力”的问题，而不是“如何凭空多出算力”的问题。如果模型本身太重、核心循环太臃肿，任何调度器都救不了场。
4. 常见问题与排查技巧实录
4.1 明明支持，为何没有走上ANF通道
开发中最常见的困惑是：硬件支持ANF，但AI推理仍旧没有异构调度迹象。
我遇到过几类原因：
- 驱动版本过旧：支持ANF的GPU驱动和HTP固件必须配套升级，老驱动可能只有固定分配逻辑，没有融合调度通路
- 模型没有经过编译优化：ANF依赖编译期算子分析和融合标记，如果用老版TFLite或ONNX Runtime直接裸跑，很多算子没有被标注为“可融合”，调度器无法下手
- 数据格式不匹配：GPU和NPU各有偏好的数据排布，如果模型输入格式在两者之间切换时需要额外转换，调度器可能会放弃这条路径，因为“迁移损耗大于收益”
排查时可以抓trace看是否有GPU和NPU交替工作的记录。如果完全没有，先更新驱动；更新后仍没有，检查模型是否经过QNN或SNPE等工具链转换。这是最容易被忽略的一步：硬件调度需要软件格式支持，模型不“变形”，调度器也没法发力。
4.2 GPU和NPU迁移损耗太大，怎么办
ANF调度器不会无脑频繁搬运数据。它每做一次跨单元拆分，都意味着有一部分中间结果要经过LLC或DDR搬运到另一个单元。如果算子切分粒度过细，迁移损耗可能大于单单元执行损耗。
我在测试一个轻量人脸检测模型时，模型只有几十层，切分太碎导致每层都在GPU和NPU之间来回倒腾，最终延迟反而比单独用GPU高出15%。后面通过设置调度最小切分阈值，把连续几个相邻层绑定到同一个加速单元，延迟立刻降了下来。
实际操作中，可以通过高通工具链的配置文件调整层融合策略。比如在SNPE或QNN的配置里，指定“允许融合的层类型”和“禁止切割的依赖链长度”。这类参数的调优需要反复对比trace和延迟数据，不能拍脑袋。
4.3 抓trace发现GPU/ NPU负载都不高，但帧率很低
这种情况大概率不是算力瓶颈，而是带宽瓶颈或调度等待。
AI推理中大量中间Tensor体积可能非常大。当GPU和NPU协同工作时，数据流量的爆发峰值会让DDR总线先扛不住。此时即使GPU和NPU每个计算单元都“有空闲”，数据也传不过来，整个流水线等于在干等。
排查方法是查看系统中DDR频点：cat /sys/class/devfreq/3d00000.qcom,ddr/cur_freq，同时对比ANF场景和平常场景下的DDR活跃度。如果DDR频率长期顶在最高档且负载打满，基本可以断定瓶颈在数据搬运路径上。
一个可行的缓解手段是减少中间Tensor的精度：从FP32降到FP16，一个Tensor的占用减半，总线压力立刻缓解。再加上ANF融合调度，效果更明显。我在一个语义分割模型上试过，整体端到端延迟降低40%左右，其中一半来源于精度缩减降低带宽需求，另一半来源于调度更从容。
4.4 ANF和游戏渲染叠加时，帧率为何波动剧烈
如今很多手游会叠加AI超分或插帧特性。这个时候，GPU既要渲染游戏画面，又要跑AI算子，NPU也可能同时被AI任务占用。ANF需要时刻判断“AI计算分多少给GPU、多少给NPU”，才不会把渲染管线挤崩。
我在优化一款竞速类游戏时，观察到AI超分开启后GPU主频飚高但渲染帧率反而下降。原因是游戏画面本身对GPU需求就很大，ANF还给GPU派发了大量AI算子，导致GPU排队时间变长。后来通过限制ANF分配给GPU的最大算力上限，把AI大算子钉在NPU上，渲染帧率回升了20%。
这套思路对应用逻辑层非常重要：不要全权交给调度器决定，关键场景要设置硬边界。ANF提供灵活性，但最终的产品体验需要你用边界条件去约束它。
5. 高通向底层开发者提供的配套工具与工作流
5.1 高通QPM工具：从trace到数据面板的实战用法
自动化性能分析并非只能靠“肉眼盯曲线”。高通的QPM（Qualcomm Performance Monitor）工具，可以把Perfetto抓到的trace文件做深度的硬件计数器解析。
QPM的界面里有比较完整的AI计算任务维度统计，可以把每一层算子的执行时间、硬件归属（GPU/HTP/CPU）、数据搬运大小都拆出来。我用它优化过一个视频人像虚化模型：在QPM里看到某一层在GPU上耗时2.1ms，但迁移到NPU需要额外经过LLC搬运，总耗时3.4ms。肉眼抓trace根本看不出来，但QPM的统计表把归属和传输开销拆开后，问题一目了然。
使用QPM的流程也简单：先用Perfetto抓trace，导出后在QPM里导入，再切换到“AI Accelerator”面板查看算子级别统计。这里有一句实在话：工具只是放大镜，真正下结论还要靠你对硬件架构的理解，没有架构认知，数据再多也转化不成优化方案。
5.2 chi-cdk与摄像头管线的ANF联动
很多人会忽略一个环节：高通相机管线chi-cdk（Camera Hardware Interface CDK）与AI推理是深度绑定的。
现代手机相机里的夜景、人像、HDR，很多效果不是ISP直接算出来的，而是经过专门AI模型后处理。chi-cdk定义了高通平台上摄像头数据如何流转到GPU/NPU做AI后处理。ANF生效时，ISP输出的RAW数据可以直接走LLC到HTP或GPU执行AI算法，链路短、延迟低。
我在调试相机“文档去阴影”功能时，chi-cdk里配置的AI节点指定了处理精度偏好。实测在ANF通道下，从ISP拿到图像到输出增强后的结果，延迟可以控制在20ms以内，比老架构快了很多。这不是魔法，而是数据链路缩短、调度器按需分配算力的结果。
如果你做相机类应用，一定要关注chi-cdk配置和HTP节点参数的匹配关系。配置错位会导致AI节点在CPU和HTP之间来回倒，异常耗电且发热严重。
5.3 底层维修视角：高通9008短接与平台刷写兜底
既然文章标题涉及底层硬件和驱动，那也不得不提很多人在玩机或底层驱动调试时遇到的情况——把Kernel调坏了，设备变砖。
高通平台提供一种特殊的紧急下载模式，就是大家常说的EDL（Emergency Download）模式，在网络上检索时经常会看到“9008短接”的说法。本质上是让SoC进入一种最低级引导状态，等待USB下载工具写入完整的boot镜像。
进入EDL模式的操作方式因机型而异，但原理一致：在设备关机状态下，用镊子或导线短接主板上指定的两个测试点，再连接USB线，设备会被识别为9008端口。这个端口在PC设备管理器里的官方名称通常带有“Qualcomm HS-USB QDLoader 9008”字样。
需要强调的事：9008短接是底层维修的最后手段，操作前务必断开电池排线并做好防静电措施，短接的是两个低电压测试点，不是随便找两个焊点短路。不同主板的短接点位置不同，不能“通用”，网络上流传的“哪两根线可以通用”说法是不严谨的。
进入9008模式后，需要用到高通烧录工具（比如QPST或QFIL）刷入对应机型平台的完整固件。在Windows环境下，安装驱动时有个关键点：第一次插上9008设备时系统可能识别失败，需要在设备管理器里手动指定驱动路径，指向高通驱动安装目录，而不是让Windows自动搜索。
这个兜底流程和高通平台开发的关系是：当你调Kernel调崩了，ANF、驱动、NPU全都没法用的时候，9008是你恢复系统底层逻辑的最后通道。我自己的习惯是在做GPU/NPU驱动调优前，先确认手头设备的9008短接方式可用、烧录工具和驱动包完整，这样即使把系统刷成砖，也能在十分钟内救回来。
6. 性能调优的进阶思路与实战记录
6.1 设置功率边界，利用“温控墙”反向优化
调优不是只往高频率方向走。实践久了你会发现，温控墙和功耗墙才是端侧AI实际性能的最终决定者。
ANF调度器虽然能感知温度，但它不会替你选择“降分辨率”还是“切模型”。如果你希望稳定不掉帧，必须在应用层自己做负载控制。我在跑一个长时间视频流超分时，选择把输入分辨率从720p降到640p，每帧计算量下降约25%，温度稳定，帧率反而比之前长期撞温度墙拼命降频要高。这就是典型的“后退一步海阔天空”。
在调优思路上，建议先摸清目标平台的功耗墙和温度墙，再用ANF调度器去适应这套边界，而不是一味让它全力跑。具体做法是：跑一个递增负载的benchmark，记录温度、频率、延迟的联动曲线，找到“性能崩塌点”，然后把业务负载控制在崩塌点以下10%左右。
6.2 结合系统级调度：把AI任务与渲染任务错峰
如果应用中既有渲染又有AI，强烈建议做任务错峰。
端侧硬件再强，也做不到长时间高性能并行。两个大任务同时跑，总线必然拥堵。ANF虽然在算子层面做了调度，但对于应用层“什么时候发起AI请求”这个更宏观的问题，它管不了。
我现在的做法是：
- 渲染帧率要求不高的界面等待期，启动AI校验、预计算
- 游戏战斗场景中，关闭非必要的AI重计算，只保留关键检测
- 在ANF支持临时调度偏移的场景，把AI大任务主动让给渲染峰值之后
这套配合在优化卡顿和发热上都立竿见影。系统级调度的核心原则就一条：让AI计算在渲染管线的“间隙”里完成，而不是和渲染硬碰硬。
6.3 实测案例：夜景降噪模型的ANF路径调优
给一个完整案例参考。我在骁龙平台上优化一款夜间拍照降噪模型，模型是一个包含10个残差块的U-Net结构。
初始状态把模型整体丢给NPU，单帧耗时42ms，NPU负载打满。我尝试开启ANF让调度器自动分配，结果单帧耗时降到31ms。观察trace发现，调度器把前3个残差块放到了GPU，中间5个留在NPU，后2个又切回GPU。这和模型层本身的运算特性高度吻合：前几层处理大分辨率特征图时GPU纹理带宽优势明显，中间深层通道数多、计算密集，NPU更高效。
之后我又做了一步优化，把可融合的ReLU和卷积层在编译期合并，运行节点少了，调度开销更低，最终单帧耗时稳定在27ms。加上将中间精度从FP32降到FP16后，最终是22ms，比最初的“单NPU硬跑”方案快了接近一倍。
这个案例能说明一件事情：ANF不是开关，而是需要模型结构、编译策略、数据精度一起配合的体系。你投入多少精力去理解它，它就能返还多少性能红利。
7. 避坑指南与实操心得
7.1 别把“调度器”当“性能加速器”
我最想对开发者朋友说的一句话是：别把ANF当成一个“一键开启性能翻倍”的开关。
ANF的定位是调度优化，它能把已有算力利用率提上来，但不会把本来就很慢的模型变成飞快。如果模型本身算子质量差、冗余多，或者数据频繁在CPU和加速器之间倒腾，那么调度器再聪明也是巧妇难为无米之炊。
我的经验是：先用Profiling定位真正瓶颈（算力、带宽还是延迟），再决定是否依赖ANF去优化。顺序反了，你会在错误的优化方向上浪费大量时间。
7.2 驱动、工具链和模型格式要同步升级
ANF不是某个App单独能生效的，它依赖整个软件栈：
- Kernel要有高通的CAF代码基础，不能随便用AOSP主线内核
- GPU驱动和HTP固件版本要配套
- 模型转换工具链版本要新，老工具生成的模型缺乏可融合算子标记
这三个组件差一个版本，ANF就可能回退成普通GPU/NPU模式，而你在上层根本看不出异常，只感觉性能不达预期。所以遇到AI性能问题，第一步永远是确认软件栈版本匹配情况。
7.3 关于温控与电池策略的经验账
最后记录一条运维向的经验。做量产级AI应用，尤其要关注不同温区下的表现一致性。ANF调度器会依据温度实时调整任务分配，这就会导致一个现象：室温25度时性能好，35度时性能下降，但这并不是软件出了问题。
针对这个问题，我习惯在调优时加入“三温区测试法”：分别在低温、常温、高温环境下跑同一套benchmark，记录三者差异。如果三温区帧率波动在15%以内，说明ANF和散热设计配合良好；如果波动过大，就要考虑应用层主动降载，提前为高温工况做规划。
这个思路也解释了为什么“实验室性能”和“真机体验”往往有差距——实验室环境通常低温，山里冰凉；用户真机长时间游戏或导航，温度上来之后调度器自然会收紧分配。提前测试，提前适应，才能保证体验不翻车。
