企业官网建设流程全解析

上个月帮朋友调一台工业平板的端侧缺陷检测模型，一台7瓦功耗的ARM工控机，要把YOLO级别的模型压到30毫秒以内完成单帧推理。调了两周，最后瓶颈居然出在一个很少有人注意的NPU驱动异步接口上。这件事让我重新开始思考一个被严重低估的趋势——本体智能。所谓本体智能，就是让智能能力从云端下沉到设备本体，手机、摄像头、智能座舱、机器人甚至一块嵌入式板卡，都能在本地完成感知、推理和决策。这篇文章不聊炫酷的Demo，就结合我这些年的落地经验和行业观察，拆一拆本体智能为什么在这个时间点爆发，产业底座走到哪一步了，哪些场景真正值得投入，以及实际操作中怎么少踩坑。

1. 本体智能到底在讲什么：从“连脑子”到“自带脑子”

1.1 先分清几个容易混的词

本体智能这个说法，行业内其实还没有一个绝对统一的定义，但它指向的方向很明确：智能能力不再依赖远端服务器的网络连接，而是由设备本体直接承载并完成计算与决策。

这里要先和几个相邻概念做区分：

我把本体智能理解为“设备自身的智能能力”，它包含端侧AI，但比端侧AI更进一步——不仅是在设备上跑一个模型，更是让设备具备独立的感知、推理和行动能力，即使在断网、弱网环境下也能正常工作。

很多刚入行的朋友容易把“具身智能”和“本体智能”混在一起，严格说这是两个不同维度的事。具身智能强调的是智能体要有物理身体、能和环境交互，本体智能强调的是智能体要把计算和决策放在自己体内而不是外部。两者有交集，比如人形机器人既需要具身能力，也必须具备强大的本体智能；但手机拍照增强、车载疲劳监测这类应用，就只属于本体智能，和具身没啥关系。

1.2 为什么这个时间点突然全面爆发

本体智能不是新概念，十年前就有端侧AI的提法，但那时候更多是噱头，因为手机芯片算力弱、模型太大跑不动、工具链不成熟，最后都沦为PPT演示。真正让它变成主流趋势，是最近三五年的事。

根本原因是三重驱动力在同一时间到位。

第一重是算力。手机SoC的NPU算力从当年的不到1TOPS，干到现在的40到70TOPS，一台千元机的端侧算力都超过十年前一台服务器的浮点能力。专用芯片和工控机的算力增长更是激进，英伟达Jetson系列、瑞芯微RK3588、晶晨A311D这些平台，把几十TOPS级别的算力做到了几十瓦甚至十几瓦功耗以内，这给本地跑模型提供了硬件基础。

第二重是模型压缩技术的成熟。量化、蒸馏、剪枝这些技术早年都是学术圈自娱自乐，现在已经是产业标配。一个70亿参数的大模型，经过INT4量化加结构化剪枝，可以压到2GB以内部署在旗舰手机本地跑；一个常规缺陷检测模型，从FP32缩到INT8，体积缩小四倍，推理速度提升三到五倍，精度损失控制在可接受范围。这一点是整个产业从“能做”到“能用”的分水岭。

第三重是需求端的变化。用户对隐私越来越敏感，企业对数据合规越来越重视，很多场景监管明确要求数据不出域。同时网络质量不稳定的问题始终存在，工厂车间、地下停车场、高速行驶的车里、飞行的无人机上，网络状况都不能保证。这些场景天然倒逼智能能力从云端往本地下沉。

我用一个生活化类比来解释这件事：以前设备都像“远程遥控玩具”，信号一断就傻掉，所有命令都靠云端大脑下发；现在设备更像是“随身携带算力的智能体”，就像一个人自己脑子能思考，不需要每件事都打电话问别人。这个转变，就是本体智能。

1.3 本体智能要解决的核心问题

任何技术方向能成为产业趋势，一定是它同时解决了好几个层面的问题。本体智能的核心价值我总结为四个方面。

实时性。端侧推理没有网络往返，延迟从百毫秒级压到十毫秒级甚至更低。自动驾驶紧急制动、工业运动控制、无人机避障，这类对时延极其敏感的任务，根本不可能依赖云端。

隐私与合规。数据在本地处理，不上云，不落盘，天然满足很多行业的数据合规要求。医疗影像分析、人脸识别、企业内部文档处理，数据不出设备是硬指标。

可靠性。断网能继续工作，网络抖动不影响业务。偏远地区的安防监控、野外的巡检机器人、海上作业平台，网络本来就是奢侈品，本地智能是唯一选择。

成本。推理不再按次计费的API，也不占用云服务器资源。当设备量级到十万、百万级别时，端侧推理的成本优势是数量级上的碾压。

这四点不是并列关系，是递进关系。最开始大家关注的是实时性，因为云端确实做不到；后来隐私合规压力上来，端侧成了唯一解；再往下做项目，发现可靠性也是刚需；最后算总账的时候，成本优势让方案从“不得已而为之”变成了“主动选择”。

2. 产业底座已经齐了：芯片、压缩与推理引擎

2.1 端侧算力已经不是瓶颈，功耗才是

很多刚接触端侧项目的朋友，第一个问题是“这个板卡跑得动模型吗”。以我实测过的平台来看，现在市面上主流端侧平台的算力水平大致是这样的：

从这张表能看到，算力这个维度其实已经不太是问题了，真正难的是功耗约束下的持续性能释放。我实测一些边缘盒子，峰值算力确实能跑到标称值的八成以上，但如果持续满负荷跑大模型，两分钟之内就会触发温控降频，实际推理帧率直接腰斩。这也是为什么我在做项目的时候，第一步永远是先确认功耗墙和散热条件，而不是先看算力标称值。

经验法则：判断平台能不能跑一个模型，不要看算力TOPS数字，直接看“持续功耗预算 × 每瓦有效算力”。一个标称30TOPS但只能稳定输出15TOPS的平台，可能还不如一个标称20TOPS能持续输出18TOPS的平台靠谱。

2.2 模型压缩：落地前的必修课

模型压缩是整个本体智能落地链路里最核心的工程环节。不夸张地说，80%的端侧项目成败都取决于这个环节做得好不好。

量化是压缩手段里最常用的一种，逻辑很简单：模型参数和中间激活值从32位浮点数压到16位浮点、8位整数或者4位整数，体积和计算量都成倍下降，速度也能显著提升。但量化之后精度一定会损失，关键是怎么让损失可控。

实操中有三类做法：

我强烈建议，凡是分类任务超过三类、检测任务里存在小目标的项目，不要上来就用PTQ一把梭。先用少量校准数据集跑一遍PTQ，观察每层激活值的分布和量化误差，把敏感层挑出来做混合精度，或者直接上QAT。我最近在做的一个PCB缺陷检测项目，PTQ之后小焊点漏检率飙升到8%，换成混合精度量化后压回1.2%，整个过程多花了三天时间，但精度救回来了。

剪枝和蒸馏也能有效压缩模型体积。剪枝是把贡献低的通道或权重直接删除，适合结构冗余的模型；蒸馏是用一个大教师模型教一个小学生模型，让小学生尽量逼近教师的输出。这两个方案在工程上比量化更费劲，因为要改训练流程，我一般只在模型量化后依然超体积或超帧预算时才考虑。

2.3 推理引擎和工具链：从“能跑”到“好跑”的关键

硬件平台只是舞台，真正决定演员能不能演好戏的是推理引擎。同一张RK3588，用不同推理引擎跑同一个模型，性能差距可以超过两倍。

目前主流的端侧推理引擎各有侧重：

选推理引擎我用一个标准：优先选芯片原厂推荐的引擎。原厂的引擎和自家NPU之间有底层优化，包括算子映射、DMA调度、内存布局，这些第三方引擎很难完全复刻。只有原厂引擎实在不给力（比如算子支持缺失、代码质量差），才考虑引入更通用的开源引擎做兜底。

工具链层面，现在头部芯片厂商已经建得比较齐全了，基本都提供“训练框架模型→模型优化工具→推理引擎→示例代码”的完整链路。以瑞芯微的RKNN为例，PyTorch模型先导出ONNX，再用RKNN-Toolkit2做量化转换，最后生成rknn格式的模型文件交给板端运行时加载，整条链路半天能跑通。这也是端侧落地效率在最近两年大幅提升的核心原因——工具链把原来最费人的工作自动化了。

2.4 端侧大模型：本体智能的新变量

大模型时代的本体智能，和传统CV/小模型路线完全不是一个量级的话题。现在行业内讨论比较多的端侧大模型，主要集中在7B和13B参数规模，通过INT4量化压到3到8GB显存/内存占用，在手机或者高端边缘盒子上跑对话、摘要、知识问答。

端侧大模型的落地意义在于，它让设备本体第一次具备了复杂的语义理解和生成能力，而不只是做分类、检测这类判别式任务。我在智能座舱项目里实测过，一个13B模型量化到INT4之后，本地跑流式对话的延迟在三秒左右，离线状态下依然能完成导航查询、天气播报、车载知识问答，这在两年前是不可想象的。

但要泼一盆冷水：端侧大模型目前还没到大规模商用的成熟期。主要问题在于内存带宽——大模型推理是内存带宽密集型的，即使是高带宽内存的手机SoC，跑7B模型也基本只能做到每秒钟十个token以下的生成速度。所以现阶段我对端侧大模型的建议是，找准场景试水可以，大面积铺开还早。

3. 典型场景拆解：哪些地方真正值得上本体智能

3.1 手机与消费电子：端侧AIGC与隐私计算

手机是本体智能渗透最深、出货量最大的领域。手机上的端侧AI覆盖的面积非常广：相册物体分类、文档扫描增强、语音实时转写、离线翻译、人脸解锁、端侧照片超分，这些功能早年都要联网跑云，现在全部搬到了本机NPU上。

手机端侧大模型是2024到2025年最热的方向之一。头部厂商陆续在旗舰机上集成端侧小模型，主要应用场景包括：通话摘要本地生成、相册自然语言搜索、端侧文本润色、离线语音助手。这类能力共同的特点是，用户对隐私敏感（通话内容、照片、输入文字都不愿意上传），且对实时性有要求，非常适合放在端侧。

从产业链配套看，手机端侧AI是四个场景里最成熟的：高通、联发科、海思都有成熟的端侧AI开发套件，主流推理引擎在手机端的适配已经完全成熟，模型压缩技术在手机端的积累也最丰富。如果团队想切入本体智能赛道但不知道从哪个方向入手，手机端侧应用是最稳妥的练手阵地。

3.2 智能座舱：离线语音与多模态交互

车是本体智能一个极其重要的落地场景。座舱里的语音助手、驾驶员疲劳监测、手势识别、后排儿童状态监测，这些功能天然要求低时延和不依赖网络。在地下停车场、隧道、偏远公路，网络质量没有保障，任何依赖云端的交互都会翻车。

我在座舱项目里遇到过一个典型的用户痛点：高速行驶进入隧道后，云语音助手直接失联，导航和媒体控制全部卡死。后来方案改成端侧语音识别加云端语义兜底，离线状态跑本地模型处理基础指令，联网时再用云端语义补足复杂对话。切换完之后，隧道里的基础指令响应从原来的“完全不可用”变成“延迟0.8秒内可用”，体验提升非常明显。

智能座舱的技术栈现在也比较清楚：DMS疲劳监测通常用轻量级人脸关键点模型加眼睑闭合检测模型，整体压到几百毫瓦功耗；语音交互则是ASR（语音识别）、NLU（语义理解）、TTS（语音合成）三件套，全部端侧化之后可以实现完全的离线交互闭环。座舱是端侧AI里市场空间最大、付费意愿最强的垂直领域之一。

3.3 工业质检与安防边缘：稳定可靠的本地闭环

工业视觉质检是我个人接触最多的落地场景。工厂车间的网络环境普遍不好，产线部署的相机和工控机往往在屏蔽房、地下室，有些车间Wi-Fi都布不了，更别提稳定上云。因此工业质检是最早、最彻底实现本体智能的领域之一。

一个典型的端侧质检项目链路是这样的：相机实时采集图片，工控机内置模型完成缺陷检测和分类，检测结果直接控制PLC执行剔除动作，整个过程完全在产线本地闭环，云端只负责统计报表和模型远程更新。这个架构的优势非常明确：检测延迟从“上传云端等待结果”的上百毫秒，压缩到本地的二三十毫秒；数据不出厂区，满足绝大多数制造企业的数据合规要求。

智慧安防是另一个高度成熟的方向。传统方案是摄像头把视频流全部传回中心机房，用服务器做分析，带宽压力极大，单路1080P视频至少需要4到8Mbps带宽，一个上千路摄像头的园区每天产生的数据量是惊人的。现在的方向是把结构化分析算法直接部署到摄像头或边缘盒子内部，前端直接输出结构化信息（人脸特征、车牌、行为事件），后端只接收结构化数据，带宽开销下降一个数量级。

这两个场景我给的建议是：如果公司有现成的数据积累和行业客户，优先从这里切入，因为需求明确、付费能力强、技术验证闭环短。

3.4 机器人与自主设备：本体智能的进阶形态

机器人和无人机是本体智能最具想象空间的场景，也是技术难度最高的方向。

以移动机器人为例：一台AGV在仓库里运行，需要实时完成定位感知、路径规划、动态避障，面对行人、叉车、货架位置变化，决策周期要压缩到几十毫秒级别。这种工况下不可能等云端指令，必须本体智能完成从“看得见”到“走得出”的完整闭环。即使是5G网络条件下，云端规划的往返延迟也在几十到上百毫秒，这个时间足够让机器人和货架撞上了。

自主设备的本体智能还有一个特殊要求：感知决策执行一体化的完整性。机器人不仅要在端侧跑视觉模型、激光雷达的SLAM算法，还要实时输出电机控制指令，这需要一套完整的异构计算架构，CPU负责逻辑调度，GPU或NPU负责视觉推理，MCU负责电机控制，各司其职。

我自己在做巡检机器人项目时，最深的一个体会是：机器人类的本体智能项目，能力瓶颈往往不在模型精度，而在端侧整套软件架构的实时性。ROS等中间件框架本身的开销、各模块间的数据传输拷贝、推理引擎和运动控制的同步，这些系统级的时延加在一起很容易超过业务能容忍的预算法。想入局这个方向的团队，我建议尽早关注系统架构设计，而不是只盯着单个模型的指标。

4. 一次完整落地中的关键工程环节

4.1 第一步先做需求评估，别急着上模型

很多团队拿到一个“上端侧”的需求，第一反应就是“我先训个模型”。这是最容易翻车的路径。我做过太多次项目返工，都是因为前期没把需求拆干净。

需求评估阶段至少要回答下面五个问题：

我实操过的案例里，有个印象很深的项目：客户想把工业质检从云端迁到端侧，原以为把模型瘦身就行了。结果一拆需求发现，客户真正需要的是“换料调整算法参数时，工人自己能在现场完成快速配置”，这个背后的关键需求是工艺变更后调试效率太慢，而这个问题完全可以通过云端加载模型加端侧推理的混合架构解决，压根不需要把训练也搬到现场。如果当初直接做纯端侧训练，整个预算是现在的五倍。

4.2 硬件平台选型要留的余地

硬件选型是另一个决定项目生死的大决策。我见过太多项目因为选错了平台，后面推倒重来。分享几个我常用的选型原则：

第一，算力选型要在满足当前需求的基础上预留一到两倍的余量。端侧项目的模型迭代速度很快，第一版模型的算力需求往往只是未来版本的一半甚至更低。我做过一个项目，第一版模型在6TOPS的平台跑得很轻松，到了第二版加了两个检测头，帧率直接跌了四成，最后只能花两倍的价格换平台。如果当时选12TOPS档位，后面升级就不用换硬件。

第二，要注意平台生态的成熟度。有些新发布的开源硬件算力标得很高，但工具链Sparse算子支持差，部署阶段各种踩坑填坑，项目周期非常容易被拖垮。我的原则是优先选主流平台上经过大量项目验证的成熟方案，新平台可以让研发团队做预研，但主力项目不要冒险。

4.3 部署链路的标准流程

以我在RK3588上部署一个PyTorch检测模型为例，标准部署链路是这样的：

第一步，导出ONNX。PyTorch模型先用torch.onnx.export导出，这里要注意把模型的输入输出名称固定好，动态维度谨慎使用，因为后续转RKNN时动态形状支持很有限。

torch.onnx.export( model, dummy_input, "model.onnx", input_names=["input"], output_names=["output"], opset_version=11, dynamic_axes=None # 频率不高的场景，优先禁用动态轴 )

第二步，转RKNN并量化。用RKNN-Toolkit2加载ONNX，先跑一遍fp16确认模型本身能跑通，再准备几百张典型场景的校准图做INT8量化，这一步是整个流程里波动最大的环节，量化后必须做逐层精度分析。

from rknn.api import RKNN rknn = RKNN() rknn.load_onnx(model="model.onnx") rknn.config(target_platform="rk3588") rknn.build(do_quantization=True, dataset="calibration.txt") rknn.export_rknn("model_int8.rknn")

第三步，板端验证。把生成的rknn模型烧到板子上，先用官方demo跑通纯推理性能，再接入业务主流程。这里有一个很关键的细节：验证性能的时候要模拟真实负载，单独跑模型的帧率和实际业务里跑模型的帧率经常相差非常大，因为还要叠加图像采集、预处理、后处理、显示输出、日志存储这些环节的开销。

4.4 端侧性能调优三板斧

模型转换完不是就万事大吉了，性能通常离目标还有距离，需要做三轮优化。

第一轮是算子融合优化。现在的推理引擎对常见模型结构都会自动做算子融合，比如把卷积后面的批归一化和激活函数融合进卷积算子，减少算子间数据搬运。如果你发现你的模型里存在大量小算子，比如自定义注意力模块里有很多逐元素的加法乘法，就得看看是不是手动重构成融合友好的结构。

第二轮是内存复用和Buffer优化。端侧设备内存带宽有限，频繁分配和拷贝Tensor是性能杀手。我把推理过程跑一遍内存分析后发现，大量时间花在了预处理图像拷贝上。后来一次性分配好输入输出Buffer全程复用，帧率直接提升20%。内存优化在端侧大模型上尤其重要，KV Cache、中间激活、输入Token缓冲都必须精心设计复用策略。

第三轮是异构调度和并发处理。多数端侧平台有CPU、GPU、NPU等多个计算单元，可以用CPU做预处理，NPU跑模型，GPU再做渲染或后处理，三个阶段用流水线方式重叠执行。从串行到流水线，整体吞吐量往往能提升一倍以上。

调优的过程中要全程关注功耗和温度曲线。一个常见的坑是：推流测试帧率达标了，但跑半小时后帧率开始下降，因为发热触发降频。正确的调优目标是“持续帧率”而不是“峰值帧率”，验证方式是要至少连续跑一个小时以上，观察帧率和功耗曲线是否平稳。

5. 常见问题与排查经验实录

5.1 问题速查表

我把实际项目的常见问题整理成一张速查表，在项目里我都是直接把这张表打印出来贴在工位上：

5.2 我踩过的几个大坑

第一个坑是用训练后量化一把梭。之前做一个表计读数识别项目，觉得PTQ方便，直接在验证集上看到精度损失只有2%，就上了生产。结果上线后真实场景的复杂背景一多，识别错误率飙升到两位数。排查了两天才发现是校准数据太单一，现实场景的分布和校准集完全不一致。后来老老实实做了QAT，还建了一套覆盖真实分布的校准集，才把精度拉回来。这个教训让我定了一条团队规矩：量化后必须用一个独立于训练集和校准集的真实业务测试集来做最终验收。

第二个坑是只测了峰值性能，没测持续性能。有个安防项目，单路视频流的推理帧率在刚开机时能跑到25帧，客户测试很满意。但同样负载跑了半小时后，帧率降到14帧，整个画面明显卡顿。原因就是整机散热设计不合理，SoC温度上来后触发频率下降。后来改了散热片并调整了风扇策略，持续帧率稳定在了22帧。从此以后我验收端侧平台性能，一律是加压跑一小时看稳定曲线，不看头三分钟的数据。

第三个坑是依赖默认融合策略。有一次在NCNN上跑一个自研注意力模型，速度一直上不去，profile发现很多逐元素算子没有被融合，原因是NCNN的图优化覆盖不了非标准结构，需要手动重写部分算子实现。最后不得不把一部分逻辑从前处理阶段用OpenCV做掉，才把基准速度追上。这个例子说明：开源引擎的自动优化能力不等于无限优化能力，遇到复杂的模型结构，必须配合手工重写或结构改造。

5.3 量化的一个核心判断标准：算子敏感度

量化精度和敏感度分析是端侧模型落地最核心的技术活。关于“哪个层不该被量化”，比较直接的办法是逐层或分组做量化敏感性分析：把某一层保持FP32，其他层量化INT8，跑一遍精度，记录精度变化，然后逐层遍历。精度掉得最狠的那几层，就是敏感层，下一轮要做混合精度处理。

这个操作看起来繁琐但值得做。我最近一个分割模型的例子：一共78层，有5层是高敏感层（中间层、注意力层、大卷积核层）。把这5层保留FP16，其余层量化成INT8，最终体积只比全量化大7%，但mIoU指数从0.83回升到0.95。如果一开始就全盘INT8，整个模型基本不可用。

5.4 端侧大模型的内存和带宽预算

端侧跑大模型，一般团队最容易低估的是内存和带宽要求。一个7B模型量化到INT4之后大约有3.5GB参数，这还不算激活值和KV Cache。如果设备只有8GB内存，模型占掉4GB之后，业务进程可用内存就已经非常紧张了，即便能跑，系统卡顿也是大概率事件。

另一个容易被忽视的点是内存带宽决定生成速度上限。理论上一台30GB/s内存带宽的设备，跑7B INT4模型，即使算力足够，Token生成速度的物理上限也就是30GB除以大概3.5GB权重再乘上一些约束系数，大致每秒8到10个token。如果业务对生成时延要求高，光换大算力没用，必须上更高内存带宽的平台。这也是我判断端侧大模型设备可行性时首先要问的问题：带宽多少。

6. 成本账怎么算：本体智能比云端便宜多少

很多人决策是否上本体智能，卡在“端侧硬件要花钱买算力”这一关。其实把账算完，优势是非常清晰的。

我以一个一千路像素的智慧安防项目为例做个粗略估算。传统云端推理方案，一路摄像头每秒需要一次结构分析调用，每天按二十四小时算，单路一天八万六千四百次调用，按云成本折算，单路一年云推理成本在几百元量级。一千路一年的云端推理成本就是数十万元。

端侧方案则是把一台带推理能力的边缘盒子摊到若干路摄像头后面，按每四路一台盒子算，一千路需要两百五十台盒子，单台盒子按两千块、生命周期三年算，一次性投入约五十万，摊到每年十六万多，再加上维护和折旧，整体和云端一年的推理费用基本打平甚至更优。但端侧还并行解决了带宽、隐私、实时性、断网可用性四个问题，这些都是云端方案花钱也未必能解决的。

核心公式非常简单：当单设备请求频率高、设备数量大、持续运行时间长时，端侧的单位推理成本远低于云端。做项目前先算帐，算完再决定架构方向，切勿为了“追热点”盲目上端侧。

对于端侧大模型场景也值得一提。云端一次大模型推理调用的成本从几厘到几分钱不等，如果设备持续高频调用，一个月下来就超过本地部署的硬件成本。只要业务不是低频偶发调用，端侧大模型的经济账通常算得拢。

7. 给准备入局团队的三条实在建议

第一，从成熟场景切入，不要一上来就碰最难的。手机端侧增强、工业质检、边缘安防这几个领域技术栈已经成熟，客户需求明确，付费意愿强。团队做完一到两个成熟项目后，再挑战座舱、机器人这些高难度场景，能力积累和信心都会更稳。

第二，算法团队必须补硬件的课。端侧项目不是训练完模型就交付了，部署过程中的量化、推理引擎适配、性能调优、功耗控制才是真正的战场。我见过太多算法工程师在云上各种秀操作，到了端侧连板卡都点不亮。建议团队至少有一两个人能独立走通从训练到端侧部署的全链路，这个能力是整个团队在端侧领域立足的关键。

第三，建立自己的性能基准库。每做一个项目，就把平台型号、芯片型号、模型结构、参数量、量化方式、帧率、功耗、精度损失记录下来，按平台维护成一份内部性能报告。几个月后你会拥有一份非常值钱的参考数据：新项目一来，你翻库就能预估出“这个模型在这个平台上大概能跑到多少帧、精度损失多少”，不需要每次从零试错。

这个习惯帮我省掉了很多预研时间，也让团队在和客户谈方案的时候更有底气。

我在实际项目里最大的体会是，本体智能不是云计算的替代品，更像是云计算的“最后一公里”补位。真正稳定的架构，绝大多数是端云协同：端侧负责实时、隐私、可靠性敏感的部分，云端负责重算力和全局知识的部分。要做端侧项目，先想清楚哪些能力必须下沉，哪些保持云端更划算。

最后再分享一个小习惯：凡是上端侧的方案，我都会在第一页纸上写下功耗、内存、延迟三个指标，任何一项如果超过预期两倍，就必须回头重新拆需求，而不是硬着头皮调模型。这个习惯帮我避开了好几次项目延期。如果你也正准备把模型从云上搬到设备上，不妨先按这套思路把前期的账算清楚，理清需求边界再动手，会少走很多弯路。