资源受限的本质：边缘计算的四重枷锁

做边缘计算这些年，我最大的感受就是——资源受限不是一句口号，它是实实在在的枷锁。你想想看，一个摄像头模组，可能只有几百KB的内存，却要跑目标检测算法。这听起来像不像让一个小孩扛起一袋水泥？

我个人习惯把资源受限拆成四个维度来看：计算、内存、存储、网络。这四个维度，每一个都可能成为瓶颈。咱们一个一个聊。

一、计算资源：CPU/GPU/TPU 的取舍

先说计算资源。边缘设备上的CPU，说白了就是低功耗的ARM Cortex系列，主频通常在1GHz以下。我见过不少团队，把服务器上的模型直接往边缘设备上搬，结果跑不起来。为什么？因为服务器有强大的GPU，边缘设备可能连个像样的NPU都没有。

我建议你记住一个原则：能用定点就别用浮点，能用查表就别用计算。举个例子，我在一个项目里需要做softmax，直接算指数太费劲。后来改成查表法，速度提升了3倍，精度只损失了0.1%。

GPU在边缘设备上也有，但别指望它能像服务器那样。像Jetson系列的GPU，虽然能跑CUDA，但显存有限，带宽也低。至于TPU，Google的Coral Edge TPU是个好东西，但它的算子支持有限，不是所有模型都能直接部署。

二、内存资源：SRAM 与 DRAM 的博弈

内存是边缘设备最稀缺的资源。SRAM速度快，但容量小，通常只有几十KB到几MB。DRAM容量大，但速度慢，而且功耗高。

我遇到过最极端的情况：一个传感器节点，SRAM只有64KB，DRAM只有512KB。要跑一个轻量级的神经网络。怎么办？

我的做法是：把模型拆成小块，逐层加载。每次只加载一层需要的权重到SRAM，计算完就释放。这样虽然增加了I/O开销，但至少能跑起来。

内存类型	典型容量	访问速度	典型用途
SRAM	64KB - 4MB	1-5ns	缓存、临时变量
DRAM	64MB - 2GB	50-100ns	主内存、模型权重

三、存储资源：Flash 与 eMMC 的持久化困境

存储资源，说白了就是你的代码和模型放在哪。Flash和eMMC是两种最常见的方案。

Flash容量小，但速度快，适合存代码。eMMC容量大，但速度慢，适合存数据。我建议你把算法模型放在Flash里，因为启动时加载快。但要注意，Flash的擦写次数有限，频繁更新模型会缩短寿命。

我记得有个项目，需要频繁更新模型参数。一开始直接写Flash，结果不到一个月Flash就挂了。后来改成eMMC存储模型，Flash只存引导代码，问题就解决了。

四、网络带宽与延迟约束：最后的瓶颈

网络带宽和延迟，是边缘计算里最容易被忽视的约束。很多人觉得，只要算力够，内存够，存储够，就万事大吉了。但你想过没有，数据怎么传出去？

边缘设备通常通过Wi-Fi、蓝牙、LoRa或者4G/5G传输数据。Wi-Fi带宽高，但功耗大。LoRa功耗低，但带宽只有几十kbps。我做过一个农业项目，传感器节点用LoRa传输，每包数据只有256字节，延迟在秒级。这种情况下，你不可能传原始图像，只能传特征向量。

我的建议是：能本地处理就本地处理，能压缩就压缩。网络带宽是稀缺资源，别浪费在传输无用数据上。

知识体系总览

下面这张图，是我对资源受限本质的理解。四个维度相互制约，任何一个短板都会拖累整体性能。

这张图想表达的是：四个资源维度不是孤立的。比如，计算资源不够，你可以用内存换时间（查表法）。内存不够，你可以用存储换空间（模型分块加载）。网络带宽不够，你可以用计算换带宽（本地预处理）。

说白了，边缘计算的优化，就是在这四个维度之间找平衡。没有银弹，只有权衡。

嗯，这一章就聊到这。记住这四个维度，后面的章节我们会逐一深入，看看每个维度具体怎么优化。