1、硬件感知推理优化概述：什么是硬件感知推理、为什么需要硬件感知、核心优化目标

各位同学，咱们今天正式开讲这门课的第一个章节。说实话，我每次带新人或者做技术分享时，都会先问一个问题：“你写出来的模型，真的能在目标硬件上跑得动吗？”

很多人觉得，模型精度高就行了，推理速度慢一点无所谓。但我在实际项目中吃过不少亏——模型在GPU上跑得飞快，一部署到手机端就卡成PPT。嗯，这就是典型的“硬件不感知”带来的问题。

什么是硬件感知推理

硬件感知推理，说白了就是让模型在设计和优化时，主动去适配目标硬件的特性。不是把模型写好再扔给硬件去跑，而是从一开始就考虑：

• 这个算子在这个芯片上快不快？
• 内存带宽够不够用？
• 缓存能不能命中？

我个人的理解是：硬件感知推理 = 算法 + 硬件 + 编译器的协同设计。三者缺一不可。

举个例子。你写一个卷积层，在GPU上可能用cuDNN的implicit GEMM实现最快。但在手机NPU上，同样的卷积可能要用Winograd或者直接拆成矩阵乘。如果你不感知硬件，你根本不知道该怎么选。

为什么需要硬件感知

这个问题我问过很多刚入行的同学。答案五花八门，但核心就三点：

1. 硬件差异巨大——CPU、GPU、NPU、DSP、FPGA，每个架构的“脾气”都不一样。
2. 资源有限——尤其是边缘设备，内存、算力、功耗都是紧巴巴的。
3. 性能瓶颈转移——以前瓶颈在计算，现在瓶颈经常在内存搬运和带宽上。

我曾经接手过一个项目，模型在服务器上推理只要5ms，但部署到嵌入式设备上直接飙到200ms。查了半天，发现是内存访问模式不对，导致缓存频繁miss。你想想看，如果当初做模型优化时能感知一下硬件的缓存结构，这200ms至少能砍掉一半。

核心优化目标

硬件感知推理的优化目标，说白了就是三个词：延迟、吞吐、功耗。但这三个目标之间经常是矛盾的，你得学会权衡。

优化目标	定义	典型场景	我常用的优化手段
延迟	单个请求从输入到输出的时间	自动驾驶、实时语音	算子融合、量化、模型剪枝
吞吐	单位时间内处理的请求数	云端推理、批量处理	动态批处理、流水线并行
功耗	推理过程中消耗的能量	手机、IoT设备	低精度计算、稀疏化、电压频率调节

延迟优化

延迟是用户最直观的感受。我习惯把延迟拆成两部分：计算延迟和内存延迟。很多时候，内存延迟才是大头。

举个例子，一个简单的全连接层，计算本身可能只要0.1ms，但把权重从DDR搬到SRAM就要花0.5ms。所以优化延迟，我第一件事就是看数据流——数据是怎么搬的，搬了几次，能不能复用。

吞吐优化

吞吐和延迟有时候是矛盾的。你为了降低延迟，可能把batch size设成1，但这样吞吐就上不去。反过来，为了提升吞吐，你加大batch size，单个请求的延迟反而会变高。

我一般在做云端推理时，会先定一个延迟SLA（比如99%的请求必须在10ms内返回），然后在这个约束下最大化吞吐。说白了，就是在延迟的“天花板”下面，把吞吐撑到最大。

功耗优化

功耗这块，我是在做手机端部署时才真正重视起来的。以前觉得功耗无所谓，直到客户说“你这模型跑5分钟手机就发烫了”。

功耗优化的核心思路是：能不动的数据就不动，能不做的计算就不做。具体手段包括：

• 使用INT8甚至INT4量化
• 对权重做结构化剪枝
• 利用硬件的低功耗模式
• 减少DRAM访问次数

三者之间的权衡

你可能会问：这三个目标能不能同时优化？我的答案是：很难，但可以做到局部最优。

举个例子。你用INT8量化，延迟降低了，吞吐提升了，功耗也降了——看起来三全其美。但如果你量化得太狠，精度掉了，那就得重新训练或者用混合精度，这时候延迟和吞吐可能又回去了。

所以，我个人的习惯是：先定场景，再定目标。

• 自动驾驶：延迟优先，功耗其次，吞吐最后。
• 云端推荐系统：吞吐优先，延迟其次，功耗最后。
• 智能手表：功耗优先，延迟其次，吞吐最后。

目标定了，后面的优化才有方向。不然你东一榔头西一棒子，最后哪个都没优化好。

小结

这一章咱们聊了硬件感知推理的基本概念、为什么需要它，以及三个核心优化目标。说白了，硬件感知推理就是让模型“懂”硬件，而不是让硬件去“迁就”模型。

下一章，我会带大家深入看看硬件架构的基础知识——CPU、GPU、NPU到底有什么区别，它们的计算单元和内存层次是怎么设计的。这些东西搞懂了，你才能知道优化到底该往哪个方向使劲。

好，今天就到这儿。有什么问题，咱们课后交流。