Edge ML 对尺寸痴迷
I’m happy to help translate the article, but I don’t have the full text of the post. Could you please paste the content you’d like translated (excluding any code blocks or URLs you want to keep unchanged)? Once I have the text, I’ll provide the Simplified Chinese translation while preserving the original formatting and the source line at the top.
UPS Could Deliver Your Amazon Package on a Cargo E‑Bike
在大多数城市里，对于大多数包裹来说，这实际上会更快。没有停车位。没有交通。直接送到你家门口。
相反，一辆 16,000 磅的卡车 在你的公寓楼外怠速等待，而司机则要走上三层楼，手里拿着装有手机充电器的信封。
这并不是说 UPS 笨拙。卡车负责处理复杂的情况：大批量配送、重物以及拥有 200 个站点的商业路线。一旦你为复杂情况建立了基础设施，处理简单情况就会感觉轻而易举。相同的卡车、相同的司机、相同的路线。为什么要优化？
但“轻而易举”并不免费。卡车在怠速时燃烧柴油，需要一个根本不存在的商业停车位，司机有 30 % 的工作时间 并不是在送包裹，而是在管理一辆为比大多数站点更复杂的问题而设计的车辆的运营物流。
The Edge‑ML Parallel
我们为复杂情况（大语言模型、多模态推理、生成式 AI）构建了基础设施，现在正在把它用于所有场景。
- 传感器分类？ 部署一个神经网络。
- 异常检测？ 微调一个 Transformer。
- 预测性维护？ 这肯定需要深度学习。
| Model | Disk Size | RAM |
|---|---|---|
| Quantized Llama 3B | 2 GB | 4 GB |
| 4‑bit quantized 7B model | ~4 GB | – |
| 70B model (aggressive quant.) | ≥ 35 GB | – |
| scikit‑learn Random Forest (same task) | ≈ 50 KB | – |
整个行业花了三年时间才弄清楚如何把卡车挤进更紧的停车位。而大多数配送根本不需要卡车。
两个错误，而不是一个
尺寸执念隐藏了两个不同的问题：
- 选择错误的载具 – 团队常常在轻量级模型足够的情况下，选用过大的模型。
- 路线规划 – 即使使用了合适的模型，糟糕的路由也会导致包裹（或预测）迟到甚至根本不送达。
大多数边缘部署处理的是预测性维护、异常检测、传感器分类和质量控制——表格数据问题。
一篇 NeurIPS 2022 论文 证实了从业者早已猜测的结论：基于树的模型如 XGBoost 和 随机森林 在 45 个基准数据集上，在表格数据上优于深度学习。
- 一项工业物联网研究发现 XGBoost 在预测工厂设备故障方面达到了 96 % 的准确率，将停机时间降低了 45 %。
- 随机森林在设备故障分类上取得了 98.5 % 的成绩。
小模型并未受限；它们恰到好处。
TensorFlow Lite Micro体积仅 16 KB。- TinyML 手势识别模型大小 138 KB，运行速率 30 FPS。
这些是电动自行车，而不是卡车。
但路由更为关键。70 % 的 Industry 4.0 AI 项目在试点阶段停滞，原因是部署层面的编排问题。模型在演示中可以运行；部署时却会出错。
编排缺口
在 Kubernetes 的早期，我们犯了类似的错误：我们以为容器调度是最难的部分。真正困难的是调度之后的所有工作——网络、存储、可观测性、更新、回滚以及整个运维生命周期。
边缘机器学习现在正在汲取这一教训。当 MLOps 在打包模型时结束，编排就开始了——而编排正是边缘机器学习常常失效的地方。
想想是什么让配送物流变得困难。并不是车辆本身，而是要在不断变化的条件下协调成千上万的车辆。当你使用的车辆/制品对使用场景来说过于庞大时，只会让一切变得更难。
关键挑战
| Challenge | Description |
|---|---|
| Model staleness | 边缘模型一旦部署后，可能不会频繁更新。基于 2024 年模式训练的分类器将无法识别 2025 年的异常。无论是推送 50 KB 还是 5 GB，向成千上万设备推送更新都不是件轻松的事。 |
| Fleet heterogeneity | 设备更新不统一，导致舰队碎片化，不同节点运行不同版本的模型且具备不同的能力。云端部署可以在几分钟内完成更新；而边缘部署可能需要数周甚至数月。 |
| Energy constraints | 基准测试往往忽略热节流和电池消耗。即使是运行持续推理的小模型，也会耗尽电池并产生热量，类似于每条路线中看不见的柴油成本。 |
| Network variability | 传统的 MLOps 假设网络稳定且带宽高。边缘推理必须能够在网络中断、间歇性连接或高成本带宽的情况下仍然运行。 |
结论
- 为任务挑选合适的工具。 对于许多边缘任务，轻量级的树模型或 TinyML 推理引擎就是你需要的电动自行车。
- 投资于编排，而不仅仅是模型大小。 稳健的路由、更新流水线和舰队管理才是真正的差异化因素。
- 记住陈旧和异构的成本。 即使是最小的模型，如果无法在所有设备上保持新鲜和一致，也会成为负担。
只要专注于合适的载具以及合适的路线，边缘机器学习就能最终实现快速、低成本且可靠的包裹投递——而不背负柴油卡车的负担。
当您的边缘设备离线一周会发生什么？
它何时会使用过时的模型和排队的数据重新连接？这就像规划假设每条道路始终畅通的路线。一旦桥梁关闭，整个系统就会崩溃。
数据管道问题
这就是“随意”真的不随意的地方。Edge ML 并不是因为模型太大而失败，而是因为 数据管道没有为双向流设计。
物流网络在几十年前就已经领悟到这一点。包裹从仓库流出，但退货会流回。损坏报告会流回。送达确认会流回。逆向物流和正向物流同样重要，而且往往更难。
传统的 ML 假设
Edge Device → Cloud → Inference → ResponseEdge ML 实际需要的方式
Edge Device ↔ Local Inference ↔ Selective Sync ↔ Model Updates ↔ Back to Edge这种双向性会产生大多数团队没有预料到的问题。正如 IBM 边缘部署指南 所指出的：
“在边缘部署场景中，没有直接理由将生产数据发送到云端。这可能导致一个问题：你永远收不到这些数据，也就无法检查训练数据的准确性。通常情况下，你的训练数据不会增长。”
你的模型会根据它看到的数据进行改进。如果这些数据从不离开边缘，模型就永远得不到提升。但如果 所有 数据都流向云端，你就重建了本来想要摆脱的集中式架构——增加了延迟和带宽成本。这就像把每一次退货都路由到你的主配送中心，而不是在本地枢纽处理。技术上是正确的，但在运营上却是噩梦。
边缘到云的 ETL 管道 正在成为关键基础设施。它们需要：
- 实时摄取
- 自适应转换
- 当连接失败时的优雅降级
- 对数据主权约束的尊重
一个 50 KB 的模型和一个 5 GB 的模型在这里面临相同的挑战。管道不在乎参数数量，就像路线不在乎你是开卡车还是骑自行车一样。
实际可行的做法
分层推理
将快速决策与复杂推理分离。
- 边缘向量搜索耗时 5‑10 毫秒 – 参见 RTInsights 文章。
- 无需 GPU。
- 简单分类和缓存在本地完成。
- 复杂推理在网络允许时选择性路由。
这就是用于最后一公里配送的电动自行车，用于大批量仓库转运的卡车。让车辆匹配配送需求，而不是相反。
边缘 MLOps 镜像
在本地复制最小化的云功能。当网络消失时，边缘节点仍然能够：
- 管理模型生命周期
- 从本地缓存处理更新
- 将遥测数据排队以待后续同步
这承认了云原生架构忽视的事实：网络会失效。设备会离线。关键不是是否会失去连接，而是在失去连接时是否还能继续工作。想象一下本地调度中心在总部停电时仍能运作的情形。
数据本地化作为首要原则
- 到 2025 年，超过 50 % 的企业数据将在边缘处理 – 参见 Medium 文章，相较 2021 年的 10 % 有显著提升。
- 已在制造、零售、医疗和物流领域落地。
- 成功的组织把边缘部署视为一等基础设施，构建智能数据编排，将计算迁移到数据所在，而不是把数据搬到计算中心。参见 Telefonica 博客。
选择性同步
解决训练数据的问题。
- 并非所有边缘数据都需要上传至云端——只有代表性样本需要。
- 异常和边缘案例故障必须发送。
- 边缘智能过滤，依据模型置信度和数据新颖性自适应策略，确保训练流水线持续供给，同时不压垮带宽或集中存储。
只发送损坏报告。不要发送每个包裹都完好无损的确认信息。
我们的解决方案：Expanso
我们围绕数据编排而非模型服务构建了 Expanso。无论模型是 50 KB 的决策树还是 4 GB 的量化大语言模型，瓶颈在于在正确的时间把正确的数据送到正确的位置，以及在异构车队之间协调更新并在一半节点间歇连接时保持可观测性。我们的做法把边缘节点视为数据流水线的一等参与者，而不是事后附加在云架构上的补丁。规划路线，而不是设计车辆。
方向概述
- 3780亿美元 预计到 2028 年的边缘计算支出——参见 ITProToday 预测。
- IDC 预计未来三年边缘 AI 部署的复合年增长率为 35 % CAGR。
这些投资并不是用于制造更好的卡车。量化问题基本已得到解决。资金正流向使边缘部署真正可行的 物流层。
联邦学习（来源）正从研究兴趣转向生产需求。它是唯一在不集中数据的前提下，从边缘数据改进模型的实用方式，解决了 IBM 指南警告的训练‑反馈循环问题。标准化的边缘‑云编排协议正在出现，以简化在异构环境中的部署。随着 AI 在成千上万的设备上分布，而不再局限于安全的数据中心，安全攻击面也在急剧扩大。
成功驾驭这些变化的公司并不是拥有最小车辆或最快引擎的公司。它们是那些早早认识到车辆优化只是基本要求，而非竞争优势的公司。真正的难题始终是车队管理、路线规划、包裹追踪以及在条件变化时的优雅降级。
正确的问题
不是 “我该如何压缩神经网络以适配边缘硬件？”
应该从 “解决我实际问题的最简模型是什么？” 开始。对于传感器数据，这通常是决策树——几千字节，而不是几千兆字节。它已**被证明在表格数据上优于神经网络**。
对于语言任务，你确实需要 transformer。Adobe 的 SlimLM 展示了可能性：1.25 亿–10 亿参数，在智能手机上提供文档辅助。
然后再问：
- 我的基础设施真的能够部署并维护它吗？
- 能否向碎片化的设备群推送更新？
- 边缘节点在断网时还能运行吗？
- 我的数据管道是否支持双向流动？
- 能否在成千上万的分布式节点上监控推理质量？
对模型大小的执念错失了两点：
- 在简单模型已经更好时仍追求复杂模型。
- 在部署才是实际瓶颈时却只关注压缩。
UPS 不会很快用电动自行车投递信封。卡车体系已经存在，路线已规划，司机也已培训。切换是有成本的。
但如果你从零开始构建边缘机器学习，你可以自行选择。你可以像严肃的物流公司一样构建卡车车队，或者根据实际交付的内容挑选合适的交通工具。
- 一个50 KB 的可部署模型胜过一个50 MB 的不可部署模型。
- 即使是电动自行车，也需要一条可行的路线。
边缘并不是机器学习项目的“死亡之地”，而是物流需要成熟的地方。
想了解智能数据管道如何降低你的 AI 成本吗？ 查看 Expanso。
注意： 我目前正在写一本关于机器学习数据准备的真实挑战的书，重点关注运营、合规和成本问题。欢迎分享你的想法。
最初发表于 Distributed Thoughts。