端侧LLM与超自动化：混合AI架构下的端云职责切分与落地实践

1. 当模型开始往设备里钻超自动化的地基正在被重写过去两年大语言模型的主战场一直在云端。千亿参数、万卡集群、动辄几十毫秒的首包延迟大家比拼的是谁的模型更大、谁的推理集群更猛。但从去年下半年开始一个明显的变化出现了模型开始往端侧走。手机、PC、车机、工控盒子、边缘网关这些原本只负责采集和转发的设备突然被要求自己会思考。这件事对超自动化Hyperautomation的影响远比表面看起来要深。超自动化这个词本身不新鲜它指的是把RPA、流程挖掘、iPaaS、低代码、AI能力打包在一起让企业里那些重复、跨系统、需要判断的流程自动跑起来。过去这套体系里AI只是一个外挂——流程走到某个节点调用一次云端API拿回一个结果继续往下走。端侧LLM的成熟正在把这个外挂变成内置。我先把结论摆在这里端侧部署LLM不会取代云端大模型但它会重新划分超自动化里谁来做决策、在哪里做决策、决策延迟能压到多低这三件事的边界。混合AIHybrid AI不是一句口号而是端侧和云侧各自承担不同职责之后自然形成的架构。这篇文章我会从端侧部署的真实约束讲起拆解它对超自动化流程编排、任务分发、数据回流的具体影响再给出一套可以落地的混合推理架构思路最后聊聊我实际踩过的坑。适合谁看如果你在做RPA、流程自动化、边缘计算、智能硬件或者你是一个正在评估要不要把模型塞进设备里的技术负责人这篇内容应该能帮你少走一些弯路。如果你只是好奇端侧LLM是什么也能从里面拿到足够的基础认知。2. 端侧LLM到底能跑什么先搞清楚能力边界再谈自动化2.1 参数量、量化与显存的三方博弈端侧部署的第一个现实问题是设备就那么点内存和算力。一台主流安卓旗舰手机可用运行内存大概8到12GB一台入门级工控机内存可能只有4GB车机稍微好一点但也要和座舱系统抢资源。在这种条件下你能跑的模型规模是被硬约束的。目前端侧常见的选择是1B到8B参数区间的模型经过4bit或8bit量化之后权重占用可以压到以下水平模型规模FP16权重占用4bit量化后典型可运行设备1B约2GB约0.6GB手机、树莓派53B约6GB约1.8GB中高端手机、边缘盒子7B约14GB约4GB旗舰手机、PC、车机13B约26GB约7GB高性能PC、工作站这张表是估算值实际占用还要看量化方案和推理框架的开销。但核心逻辑很清楚4bit量化是端侧部署的默认选项没有它7B模型根本进不了手机。量化带来的代价是精度损失。我在实测中发现4bit量化后的7B模型在通用对话上表现还能接受但在需要严格遵循格式输出的任务上比如生成结构化JSON给自动化流程消费出错率会明显上升。这一点后面会展开讲。2.2 端侧模型擅长的和不擅长的不是所有任务都适合丢给端侧模型。我总结了一个简单的判断标准端侧模型擅长的短文本分类和意图识别比如判断用户这句话是要查订单还是改地址实体抽取从一段话里抽出时间、地点、金额简单的格式转换和字段映射本地知识库的轻量问答配合RAG对延迟敏感的交互式任务语音助手、实时字幕端侧模型不擅长的长上下文推理超过8K token之后质量下降明显复杂多步逻辑推理需要大量世界知识的开放域问答高精度代码生成需要严格格式约束的结构化输出这个边界直接决定了超自动化流程该怎么切分。一个流程里哪些节点交给端侧哪些节点回传云端不是拍脑袋决定的而是根据任务类型和延迟要求来分配的。2.3 延迟账要算清楚很多人以为端侧部署的最大好处是不依赖网络其实更实际的收益是延迟可控。云端API调用网络往返加上排队首token延迟通常在300ms到2s之间波动高峰期更差。端侧推理7B模型在手机NPU上首token延迟可以压到100ms以内后续token生成速度大概10到20 token/s。这个差异对超自动化的意义在于流程里那些需要即时判断的节点终于可以做到无感。比如RPA机器人在操作界面时需要实时判断当前页面状态、决定下一步点哪里这种场景下每步等500ms和等50ms体验完全是两回事。但要注意端侧推理的功耗和发热是真实存在的。手机跑7B模型持续推理十分钟以上机身温度会明显上升系统可能触发降频。所以在设计自动化流程时不能假设端侧模型可以7x24小时满负荷运行要有任务队列和降级策略。3. 超自动化流程被切成了两半端云职责怎么分3.1 从云端决策、端侧执行到端侧决策、云端兜底传统超自动化的架构很清晰RPA机器人或者流程引擎在端侧执行操作遇到需要判断的地方调用云端AI服务拿回结果继续执行。这个模式下端侧是手云端是脑。端侧LLM的介入让端侧也长出了小脑。一些原本必须回传云端的判断现在本地就能完成。这带来的变化是流程编排逻辑的重构第一层端侧即时判断意图识别、实体抽取、简单分类、格式校验。这些任务端侧模型直接处理延迟低不依赖网络。第二层端侧RAG本地知识库检索加端侧模型生成。适合那些知识范围有限、更新不频繁的场景比如设备操作手册问答、内部流程规范查询。第三层云端复杂推理多步推理、长文档理解、跨领域知识整合。端侧搞不定的回传云端。第四层云端模型训练与分发云端负责持续训练和优化模型定期把更新后的端侧模型推送到设备。这个分层不是理论推演是我在实际项目里验证过的。关键在于每一层之间的切换要足够顺滑不能让用户感觉到刚才很快现在突然卡了。3.2 什么任务必须留在端侧有几类任务我强烈建议留在端侧不要回传云端第一类是涉及隐私数据的。比如医疗设备采集的患者信息、工厂产线上的工艺参数、金融终端上的交易明细。这些数据出设备本身就存在合规风险端侧处理完只上传脱敏后的结果是最稳妥的做法。第二类是对延迟极度敏感的。比如机械臂的视觉引导、自动驾驶的决策辅助、实时语音交互。这些场景下网络抖动就是事故。第三类是高频低价值的。比如每隔几秒就要判断一次设备状态这种任务如果每次都调云端API成本会爆炸。端侧模型跑一次的电费几乎可以忽略。3.3 什么任务必须回传云端反过来有些任务端侧真的做不了需要长上下文理解的。端侧模型上下文窗口通常只有4K到8K处理一份几十页的合同或者一整套工单记录根本放不下。需要最新知识的。端侧模型是离线固化的训练数据有截止日期。涉及实时信息今天的汇率、当前的库存、最新的政策的任务必须回云端。需要高可靠性的。端侧模型受量化影响输出稳定性不如云端大模型。涉及金额计算、合规判断这类不能出错的任务云端更靠谱。需要多模态深度理解的。虽然端侧多模态模型在进步但处理复杂图像理解、视频分析云端仍然有明显优势。3.4 一个实际的切分案例我拿一个智能工单处理流程举例。传统做法是工单进来全部送到云端LLM做分类和抽取然后分派给对应处理人。端侧LLM加入后流程变成工单在端侧设备比如客服的PC上先做一次本地预处理判断工单类型投诉/咨询/报修、抽取关键实体订单号、产品型号、时间。如果端侧模型置信度高于阈值比如0.85直接生成结构化数据进入分派逻辑。如果置信度低或者工单内容超出端侧模型处理范围比如超长文本、多语言混合才回传云端。云端处理完把结果和修正后的标签回传用于后续端侧模型的增量优化。这个切分带来的效果是大约70%的工单在端侧就处理完了云端只处理30%的复杂case。整体延迟下降云端成本也降了。4. 混合AI架构落地从模型选型到流程编排的完整链路4.1 端侧推理框架怎么选端侧跑LLM绕不开推理框架。目前主流的选择有几类ONNX Runtime通用性强支持多种硬件后端社区活跃。适合需要跨平台部署的场景。llama.cpp轻量对量化支持好CPU上也能跑。适合资源极度受限的设备。厂商专用框架比如高通的QNN、苹果的Core ML、华为的MindSpore Lite。这些能充分利用NPU性能最好但绑定硬件。我的建议是如果设备型号固定优先用厂商专用框架性能差距可能是几倍。如果需要跨多种设备用ONNX Runtime做统一抽象层再针对重点设备做专用优化。模型格式方面GGUF和ONNX是端侧最常见的两种。GGUF适合llama.cpp生态ONNX适合更广泛的部署场景。转换过程中要注意量化校准校准数据集要贴近实际业务数据否则量化后的模型在实际任务上可能掉点严重。4.2 端侧RAG怎么做才不鸡肋端侧RAG是很多人的第一反应既然模型小那就外挂一个知识库补足。但端侧RAG有几个坑第一个坑是向量库的存储和检索效率。端侧设备存储有限向量库不能太大。我一般建议控制在几千到几万条文档块用轻量级向量索引比如HNSW的小规模配置。超过这个量级检索延迟会明显上升。第二个坑是嵌入模型的选择。端侧嵌入模型要比生成模型更小通常用几十MB的模型。但小嵌入模型的语义区分能力有限检索召回率会下降。解决办法是混合检索向量检索加关键词检索两者结果融合后再送给生成模型。第三个坑是上下文长度。端侧模型上下文窗口小检索回来的文档块不能太多。我通常只取Top 3到Top 5每块控制在200字以内。这要求文档切分策略要精细不能简单按固定长度切。4.3 流程编排引擎需要改什么传统流程编排引擎比如基于BPMN的假设每个任务节点是确定性的输入确定输出确定。但LLM节点是概率性的同样的输入可能得到不同输出。这给编排带来了新问题重试逻辑要改。传统重试是失败了再试一次LLM节点可能需要换一种提示词再试一次或者降级到云端再试一次。超时设置要改。端侧推理时间波动大受设备负载影响。超时阈值不能设死要根据设备当前状态动态调整。结果校验要加。LLM输出不能直接信任要有格式校验和业务规则校验。校验不通过走兜底逻辑。状态管理要改。端侧模型可能中途被系统杀掉内存回收流程状态要能持久化恢复后能继续。我在项目里用的做法是在流程引擎里增加一个AI任务节点类型专门处理LLM调用。这个节点内置了重试策略、降级策略、结果校验和状态持久化。业务人员编排流程时只需要配置用什么模型、什么提示词、校验规则是什么底层细节由节点封装。4.4 模型更新与版本管理端侧模型不是部署完就不管了。业务变化、数据分布漂移、云端模型迭代都要求端侧模型能更新。但端侧设备数量可能成千上万更新是个工程问题。我的经验是分层更新提示词层最容易更新通过配置文件下发不需要动模型。适配器层如果用LoRA等轻量微调方案适配器文件很小可以频繁更新。基座模型层更新成本最高通常几个月一次走完整的OTA流程。版本管理上每台设备要记录当前模型版本、提示词版本、适配器版本。流程执行时结果要带上版本信息方便问题追溯。5. 那些文档不会告诉你的坑端侧LLM在自动化里的真实翻车记录5.1 量化后的模型在结构化输出上翻车前面提过4bit量化对格式遵循能力有影响。我遇到过一个具体案例流程要求端侧模型输出JSON格式的实体抽取结果提示词里写得很清楚few-shot示例也给了。云端模型未量化输出稳定端侧量化模型大概有5%到8%的概率输出格式错误的JSON——有时候多一个逗号有时候字段名拼错有时候干脆输出一段自然语言。这个错误率在demo里看不出来但放到生产环境每天处理几千条就是几百条失败。解决办法有两个一是加一层输出解析和修复用规则或者小模型把错误JSON修回来二是关键任务不走端侧直接回云端。5.2 设备休眠导致流程中断移动端设备手机、平板有休眠机制。流程跑到一半设备息屏推理进程被挂起流程就卡住了。这个问题在PC和工控机上不明显但在移动设备上很常见。我的处理方式是长流程拆成短任务每个任务完成后立即持久化状态。同时流程引擎要能感知设备状态设备休眠时暂停任务分发唤醒后恢复。另外对于必须在后台运行的任务要申请系统的后台执行权限但要注意功耗和系统限制。5.3 端侧模型的幻觉更难发现云端模型的幻觉通常可以通过交叉验证或者调用更强的模型来发现。端侧模型没有这个条件它自信地输出一个错误结果流程可能就照着执行了。我踩过一次坑端侧模型在抽取订单号时把订单号12345错误地抽取成了订单号12346而且置信度很高。流程用这个错误订单号去查询返回空结果后续逻辑全部走偏。后来我加了两道防线一是格式校验订单号必须是特定长度和格式二是业务校验订单号必须在本地缓存的有效订单列表里。两道校验都通过才认为抽取成功。5.4 多模型共存时的资源竞争一台设备上可能同时跑多个模型一个用于语音识别一个用于意图理解一个用于图像分类。这些模型共享CPU、GPU、NPU和内存。如果调度不当会出现互相抢资源导致所有任务都变慢。我的做法是给模型分优先级。交互式任务用户正在等待的优先级最高后台批处理任务优先级最低。同时限制同时运行的模型数量避免内存溢出。在安卓上还要注意不同模型的NPU权限有些设备不允许同时有多个模型占用NPU。5.5 端侧模型的知识截止问题端侧模型是离线固化的它的知识停留在训练数据截止的那一天。如果自动化流程涉及最新的信息——最新的产品价格、最新的政策规定、最新的库存状态——端侧模型给不出正确答案。这个问题没有技术上的完美解法只能在流程设计时明确区分静态知识任务和动态知识任务。静态知识任务比如操作手册问答可以走端侧动态知识任务必须回云端或者查实时数据库。6. 端侧LLM给超自动化带来的新可能6.1 从流程自动化到意图自动化传统超自动化是流程驱动的预先定义好步骤系统按步骤执行。端侧LLM让意图驱动成为可能用户说一句话端侧模型理解意图动态生成执行步骤然后调用相应的自动化能力。比如用户对着设备说帮我把上个月的报销单整理一下没贴发票的挑出来提醒我。端侧模型解析出意图查询报销单、筛选未贴发票、生成提醒。然后调用本地的自动化能力执行。整个过程不需要预先编排流程模型根据意图动态组合能力。这要求自动化平台把能力原子化、API化并且提供清晰的描述让模型能理解每个能力是干什么的。这其实就是工具调用Tool Use在端侧的落地。6.2 离线场景下的自动化闭环很多工业场景、野外场景、保密场景网络条件差或者根本不允许联网。过去这些场景下的自动化只能做确定性的规则判断。端侧LLM让这些场景也能有智能判断能力。比如野外的设备巡检巡检人员用离线设备拍照端侧模型识别设备状态、判断是否有异常、生成巡检报告。整个过程不需要网络数据也不出设备。6.3 端侧模型作为云端模型的过滤器端侧模型可以承担预处理和过滤的职责减少回传云端的数据量。比如监控场景下端侧模型先判断画面里有没有异常只有异常片段才回传云端做精细分析。这样既降低了带宽消耗也降低了云端推理成本。这个模式在超自动化里的应用是端侧做粗筛云端做精判。端侧模型负责把大量正常case过滤掉只把疑似异常的case回传。云端的负载大幅下降整体吞吐量上升。7. 如果你现在要动手我的几条实操建议第一不要一上来就追求全端侧。混合架构是更现实的选择。先把任务分类明确哪些必须端侧、哪些可以云端、哪些端云都行。从端云都行的任务开始试点风险最低。第二量化方案要针对业务数据校准。不要直接用通用的量化模型拿你的业务数据做校准集量化后的模型在你的任务上表现会好很多。这一步花的时间比后面调提示词的时间值得多。第三输出校验是必须的不是可选的。端侧模型的输出稳定性不如云端任何直接消费模型输出的流程都要加校验层。校验规则可以从简单到复杂逐步完善。第四监控和回传机制要提前设计。端侧模型在用户设备上跑出了问题你未必知道。要有机制把推理延迟、失败率、校验不通过率这些指标回传方便持续优化。第五模型更新通道要留好。业务会变模型会迭代。端侧模型的更新通道要在架构设计阶段就考虑进去不要等上线了再补。第六功耗和热管理要纳入流程设计。端侧推理不是免费的功耗和发热会影响设备寿命和用户体验。流程设计时要有任务队列和降级策略避免设备长时间满负荷运行。第七隐私合规要前置。端侧处理数据虽然减少了传输风险但设备本身的安全、模型本身的安全、本地存储的安全都是新的合规点。这些要在项目初期就和法务、安全团队对齐。端侧LLM和超自动化的结合现在还在早期。很多能力边界在快速变化今天做不了的事情可能半年后就能做了。保持架构的灵活性比追求一时的最优解更重要。我在实际项目里的体会是先把端云切分做对再逐步优化端侧模型最后才是追求极致的端侧体验。顺序反了容易在细节里打转看不到整体收益。