4. 计算资源维度：CPU/内存受限场景下的算法选择
做算法选型，很多时候不是「哪个效果更好」的问题，而是「手里的硬件能不能跑得动」的问题。我见过不少团队，模型在服务器上精度漂亮得不行，一部署到边缘设备上直接 OOM 崩溃。说白了，资源受限才是工业界的常态。
这一章，我们就聊聊 CPU 和内存吃紧的时候，怎么在传统算法和深度学习之间做取舍。
4.1 资源受限场景的典型画像
先给个定义。什么样的场景算「资源受限」？我个人习惯看三个指标：
| 资源维度 | 宽松环境 | 受限环境 | 典型设备 |
|---|---|---|---|
| CPU 主频 | > 2.5 GHz | < 1.5 GHz | ARM Cortex-A53 / MIPS |
| 可用内存 | > 8 GB | < 512 MB | 路由器 / 智能传感器 |
| 功耗预算 | 不限 | < 5 W | 电池供电设备 |
| 实时性要求 | 秒级 | 毫秒级 | 工业控制 / ADAS |
嗯，这里要注意：内存限制往往比算力限制更致命。算力不够可以等，内存不够直接崩。
4.2 传统算法在受限场景下的优势
为什么很多嵌入式老工程师对深度学习嗤之以鼻？不是他们保守，是吃过亏。
传统算法的内存占用，通常是 O(n) 甚至 O(1)。 比如一个 Canny 边缘检测，整张图跑下来也就几百 KB 的临时缓冲区。而一个轻量级 CNN，光模型参数就要几 MB 到几十 MB。
我举个例子。之前做一个工业质检项目，设备是 ARM Cortex-A7，内存只有 256 MB。用 YOLO-tiny 做缺陷检测，模型加载完内存就剩 30 MB 了，跑一次推理要 2 秒。后来换成传统形态学处理 + 阈值分割，内存占用不到 10 MB，单帧处理 15 毫秒。效果虽然差一点，但客户要的是实时性，不是 99.9% 的精度。
核心结论：当内存预算 < 1 MB 或 CPU 主频 < 1 GHz 时，优先考虑传统算法。深度学习不是不能用，但需要做大量裁剪和量化，性价比往往不如传统方案。
4.3 深度学习的「瘦身」策略
当然，有些任务传统算法确实搞不定。比如人脸识别、语义理解，这些场景必须上深度学习。那怎么办？硬着头皮优化。
我总结了一套「四步瘦身法」，在多个项目里验证过：
- 模型剪枝：去掉权重接近 0 的连接，通常能压缩 50%-80% 的参数。
- 权重量化：FP32 转 INT8，模型体积直接缩到 1/4，推理速度提升 2-4 倍。
- 知识蒸馏：用大模型教小模型，小模型精度能接近大模型，但参数量少一个数量级。
- 网络结构搜索：自动找计算量和精度之间的帕累托最优解。
不过要提醒一句：量化不是万能的。我曾经在一个项目里把 MobileNetV2 量化到 INT8，结果精度掉了 5 个点，客户直接拒收。后来发现是某个层的激活值分布太宽，量化后信息丢失严重。解决办法是做了逐通道量化 + 校准集优化，才把精度拉回来。
避坑指南：量化前一定要做激活值分布分析。如果分布范围超过 [-6, 6]，建议先做 BatchNorm 融合或改用逐通道量化。我曾经因为跳过这一步，浪费了两周调试时间。
4.4 选型决策矩阵
说了这么多，到底怎么选？我画了一张决策矩阵，你可以直接拿来用：
4.5 实战案例：智能门锁的人脸识别
讲个真实案例。去年帮一家智能家居公司做门锁上的人脸识别。硬件参数：
- CPU：ARM Cortex-M4，主频 240 MHz
- 内存：512 KB SRAM + 8 MB Flash
- 功耗：整机 < 1 W
你想想看，这个配置跑深度学习？连 MobileNetV1 都装不下。模型参数 4.2 MB，Flash 只有 8 MB，还要存系统、存人脸库，根本放不下。
我们最终方案是这样的：
- 人脸检测：用传统 Haar Cascade，模型只有 200 KB，单帧检测 30 ms。
- 特征提取：用 LBP（局部二值模式）直方图，计算量极小，内存占用 < 50 KB。
- 人脸比对：用卡方距离 + 阈值判断，O(1) 时间复杂度。
最终效果：识别率 92%，单次识别耗时 < 100 ms，内存峰值 180 KB。客户很满意。
我的经验：在极端受限场景下，不要一上来就想「怎么优化深度学习」。先问自己三个问题：
- 这个任务传统算法真的做不了吗？
- 能不能用传统算法做预处理，深度学习只做最后一步？
- 精度要求到底是多少？90% 够不够？
很多时候，90% 的精度 + 100% 的实时性，比 95% 的精度 + 50% 的掉帧要好得多。
4.6 性能预算分配策略
最后分享一个我常用的预算分配表。不管选传统还是深度学习，先把资源算清楚：
| 资源项 | 传统算法占比 | 深度学习占比 | 说明 |
|---|---|---|---|
| 模型存储 | 5% - 15% | 40% - 70% | 传统算法模型小，深度学习模型大 |
| 运行时内存 | 10% - 30% | 30% - 60% | 深度学习需要中间特征图缓存 |
| CPU 算力 | 20% - 40% | 60% - 90% | 卷积计算是算力大户 |
| I/O 带宽 | 5% - 10% | 10% - 20% | 数据搬运开销 |
| 预留余量 | 20% | 20% | 防止极端情况 OOM |
嗯，这个表不是死的。但有一条铁律：预留余量不能省。我见过太多项目，预算算得刚刚好，一上线遇到复杂场景直接崩。留 20% 的余量，是给自己留条活路。