1. 端侧LLM与超自动化的碰撞为什么现在值得聊大语言模型从云端往端侧走这件事在最近一年里从“实验室里的尝鲜”变成了“产线上真刀真枪的落地”。我最早接触端侧推理还是在做移动端图像识别的时候那会儿把一个小卷积网络塞进手机里已经算是“优化到极致”了。现在情况完全不一样——7B、8B参数级别的模型经过量化之后能在笔记本、工控机甚至旗舰手机上跑出可用的推理速度。这个变化带来的连锁反应最直接的就是超自动化领域。超自动化这个词听起来有点大拆开看其实很朴素把企业里那些重复、规则明确、跨系统的流程用软件机器人加流程编排加决策引擎串起来自动完成。过去这套体系里“决策”这一环要么靠硬编码规则要么靠云端调API。硬编码规则的问题是脆——业务一变就得改代码云端调API的问题是慢和贵——每次决策都要走网络延迟不可控数据还得往外送。端侧LLM的介入恰好卡在这两个痛点的中间。它把语言理解和轻量推理的能力直接放到流程执行的那台机器上不需要每次决策都请求远端也不要求业务人员把规则写成if-else。我实测下来一个量化到4bit的7B模型在16GB内存的工控机上做意图分类和字段抽取单次推理能压到300毫秒以内这个延迟对于大多数RPA流程来说完全可以接受。这篇文章想聊的就是这件事端侧LLM到底怎么影响超自动化的架构设计、流程编排和实际落地。适合正在做RPA、流程自动化、智能客服、文档处理的朋友参考也适合刚接触LLM部署、想知道“端侧这条路能不能走”的开发者。我会把选型逻辑、量化参数、部署步骤、踩过的坑都摊开讲尽量让不同基础的人都能拿走能用的东西。2. 端侧LLM部署的核心逻辑与超自动化的需求匹配2.1 超自动化到底需要LLM做什么先把需求侧说清楚。超自动化流程里LLM能插进去的位置其实就那么几个非结构化输入的解析比如邮件、合同、工单文本、流程分支的语义判断比如这条投诉该走退款还是走换货、人机交互的自然语言接口比如用户用口语下达自动化指令、执行结果的摘要与报告生成。这四个场景有一个共同特点输入输出都不长但需要一定的语义理解能力。这跟云端LLM的典型用法不一样。云端调用往往是“一次问一大段返回一大段”追求的是生成质量的上限。端侧LLM在超自动化里的用法是“高频、短输入、短输出、低延迟”追求的是稳定和成本可控。理解这个差异后面的选型和优化才有方向。2.2 为什么是端侧而不是继续用云端我一开始也犹豫过云端API已经那么方便了为什么还要折腾端侧部署实际跑过几个项目之后原因变得很具体。数据不出本地。很多企业的流程数据涉及客户信息、合同条款、内部工单这些东西走云端API需要过合规审查周期长且不一定能过。端侧部署之后数据从采集到推理到落库全在本地闭环合规压力小很多。延迟可预期。云端API的延迟受网络波动影响P99延迟经常是P50的好几倍。超自动化流程里一个环节卡住会影响整条流水线。端侧推理的延迟虽然绝对值不一定更低但方差小流程编排的时候更好做超时控制和重试策略。单次成本趋近于零。云端API按token计费流程跑得越多成本越高。端侧部署是一次性硬件投入加电费跑一万次和跑一百万次的边际成本几乎一样。对于高频短请求的场景这个账算下来差距很大。离线可用。工厂车间、野外作业、内网环境这些地方网络本来就不稳定。端侧LLM让自动化流程在这些场景下也能跑起来。2.3 端侧LLM的能力边界在哪里说好处的同时也得把边界划清楚。端侧部署的模型规模通常被限制在3B到14B之间再大就受内存和算力制约了。这个规模的模型在复杂逻辑推理、长文档理解、多轮深度对话上跟云端大模型有明显差距。所以端侧LLM在超自动化里的定位应该是“语义路由器”和“结构化抽取器”而不是“全能决策大脑”。我的经验是把端侧LLM用在它擅长的窄任务上配合规则引擎和传统ML模型做兜底整体效果比硬上一个端侧大模型要好。比如意图分类用端侧LLM金额计算用规则引擎异常检测用轻量ML模型各司其职。3. 端侧部署实操从模型选型到推理服务上线3.1 模型选型别只看榜单选模型这件事我的建议是先看部署约束再看能力榜单。Open LLM Leaderboard这类公开榜单上的排名测试的是模型在标准学术任务上的表现跟你在工控机上跑一个意图分类任务的表现是两回事。实际选型的时候我一般按这个顺序筛筛选维度具体要求常见选择参数量3B-8B优先14B需要评估硬件Qwen2.5-7B、Llama-3.1-8B、Phi-3.5-mini量化支持必须有成熟的4bit/8bit量化方案GPTQ、AWQ、GGUF推理框架支持ONNX Runtime或llama.cppONNX、GGUF格式中文能力如果业务涉及中文必须实测Qwen系列、ChatGLM许可证商用是否受限Apache 2.0优先我踩过的一个坑是看榜单选了一个英文能力很强的模型结果业务数据里大量中文工单模型对中文的理解明显掉档。后来换成Qwen2.5-7B的4bit量化版中文意图分类的准确率从78%提到了91%。所以一定要用你自己的业务数据做小样本测试别偷懒。3.2 量化参数怎么选精度与速度的平衡量化是端侧部署绕不开的一步。简单说就是把模型权重从16位浮点数压到8位、4位甚至更低的整数换来内存占用和推理速度的改善。但量化会损失精度损失多少取决于方法和参数。我常用的量化方案是AWQ 4bit理由是它在4bit量化里精度保持得比较好而且推理时有针对性的kernel优化。具体参数上group_size一般设128zero_point开启。如果硬件支持可以试试GPTQ的act_order对某些模型有额外提升。实测数据供参考Qwen2.5-7B在FP16下需要约14GB显存4bit量化后降到约4.5GB推理速度从每秒18个token提到每秒45个token左右同一台机器。精度方面在意图分类任务上掉了不到2个百分点在字段抽取任务上掉了约3个百分点。这个代价对于端侧场景是可以接受的。注意量化后的模型一定要重新做一轮业务测试不能直接拿原模型的评测结果当准。有些模型对量化特别敏感掉点会超出预期。3.3 推理框架选型ONNX还是llama.cpp这两个框架我都用过适用场景不太一样。ONNX Runtime的优势是跨平台做得好Windows、Linux、ARM都能跑而且跟.NET、Java、Python的集成都很成熟。如果你的超自动化平台是Java或.NET写的ONNX Runtime的接入成本最低。缺点是模型转换步骤稍微繁琐需要先把原始权重转成ONNX格式再做量化。llama.cpp的优势是开箱即用GGUF格式的模型直接下载就能跑量化选项丰富CPU推理效率很高。缺点是服务化封装需要自己做一些工作高并发场景下的调度不如ONNX Runtime成熟。我的选择逻辑是如果部署环境有GPU且平台是Java/.NET选ONNX Runtime如果是纯CPU环境或者需要快速验证选llama.cpp。两者都支持流式输出对于需要实时反馈的交互场景都够用。3.4 部署步骤以ONNX Runtime为例下面走一遍完整的部署流程环境是Ubuntu 22.04加一张RTX 4060 Ti 16GB。第一步准备模型权重。从Hugging Face下载Qwen2.5-7B-Instruct的原始权重然后用AutoAWQ做4bit量化pip install autoawq python -c from awq import AutoAWQForCausalLM from transformers import AutoTokenizer model_path Qwen/Qwen2.5-7B-Instruct quant_path qwen2.5-7b-awq model AutoAWQForCausalLM.from_pretrained(model_path) tokenizer AutoTokenizer.from_pretrained(model_path) model.quantize(tokenizer, quant_config{zero_point: True, q_group_size: 128, w_bit: 4}) model.save_quantized(quant_path) tokenizer.save_pretrained(quant_path) 第二步转ONNX格式。用Optimum的ONNX导出工具pip install optimum[onnxruntime-gpu] optimum-cli export onnx --model qwen2.5-7b-awq --task text-generation-with-past onnx_model/第三步写推理服务。用FastAPI包一层加载ONNX模型暴露一个/generate接口from fastapi import FastAPI from optimum.onnxruntime import ORTModelForCausalLM from transformers import AutoTokenizer app FastAPI() model ORTModelForCausalLM.from_pretrained(onnx_model/, providerCUDAExecutionProvider) tokenizer AutoTokenizer.from_pretrained(onnx_model/) app.post(/generate) async def generate(prompt: str, max_new_tokens: int 128): inputs tokenizer(prompt, return_tensorspt) outputs model.generate(**inputs, max_new_tokensmax_new_tokens) return {text: tokenizer.decode(outputs[0], skip_special_tokensTrue)}第四步压测调优。用locust或者wrk做并发测试观察显存占用和P99延迟。如果显存吃紧可以调小max_batch_size如果延迟偏高可以开启动态批处理。这套流程跑下来从零到服务上线大概需要半天时间主要时间花在模型下载和量化上。4. 端侧LLM如何改变超自动化的流程编排4.1 从“规则驱动”到“语义驱动”的流程分支传统超自动化的流程分支靠规则引擎比如“如果工单类型字段等于‘退款’且金额小于500走快速退款通道”。这套逻辑的问题是规则维护成本高业务一变就要改规则而且规则之间容易冲突。端侧LLM介入之后流程分支可以变成“把工单文本和当前流程状态一起给模型让模型输出下一步该走哪个分支”。模型输出的是一个分支标识流程引擎根据这个标识做路由。这样业务人员调整流程的时候只需要改提示词里的分支描述不需要动代码。我做过一个对比同一个售后工单分流场景规则引擎版本维护了47条规则端侧LLM版本用了一个约200字的提示词。规则版本的准确率是86%LLM版本是89%。更重要的是LLM版本在业务新增分支的时候改动成本几乎为零。4.2 端侧LLM作为“语义网关”的架构设计在超自动化平台里端侧LLM最合适的角色是语义网关——所有非结构化的输入先经过它做一次归一化转成结构化字段之后再进入后续的规则引擎和RPA机器人。这个架构的好处是解耦。后面的流程编排不需要知道输入是邮件、聊天记录还是扫描件它只处理归一化之后的结构化数据。LLM的升级、替换、量化调整都不会影响后面的流程逻辑。具体实现上语义网关对外暴露一个统一的接口输入是原始文本加一个schema描述输出是符合schema的JSON。schema描述告诉模型需要抽取哪些字段、每个字段的类型和取值范围。这样同一个网关可以服务多个不同的流程只需要切换schema。4.3 提示词工程在端侧的特殊考量端侧模型的上下文窗口通常比云端小7B级别的模型常见是8K或32K。这意味着提示词不能写太长few-shot示例要精挑细选。我的做法是每个任务只放2到3个示例示例要覆盖边界情况。比如做字段抽取示例里要包含一个字段缺失的情况、一个字段有歧义的情况、一个正常情况。这样模型学到的不是具体答案而是处理逻辑。另外端侧模型的指令遵循能力比云端大模型弱提示词要写得更直白。避免“请尽可能准确地”这类模糊表述直接说“只输出JSON不要解释”。输出格式约束用JSON Schema或者明确的模板比自然语言描述更可靠。实操心得端侧模型对提示词里的顺序比较敏感。把最重要的指令放在最前面和最后面中间放示例实测比全部堆在前面效果好。5. 常见问题与排查技巧实录5.1 推理速度突然变慢怎么排查端侧部署跑一段时间之后推理变慢最常见的原因是显存碎片化和热节流。排查顺序如下先看GPU利用率和显存占用如果显存占用接近上限但利用率不高大概率是碎片化。解决办法是重启推理服务或者改用支持显存池化的推理框架。如果是CPU推理检查是否有其他进程抢资源。如果GPU温度超过85度检查散热。工控机环境里散热条件往往不好降频之后推理速度会掉一半。我遇到过一台工控机因为风扇积灰导致推理速度从每秒40token掉到每秒12token清灰之后恢复。还有一个容易忽略的点是输入长度。端侧模型对长输入的推理时间增长是非线性的输入从500token涨到2000token推理时间可能涨4倍。如果流程里偶尔出现长文本要做截断或者分段处理。5.2 输出格式不稳定的处理端侧模型输出JSON的时候偶尔会多出解释文字或者格式错误。这个问题在4bit量化之后更明显。我的处理方案是三层防护第一层提示词里用JSON Schema约束并且明确说“只输出JSON”第二层用outlines或者lm-format-enforcer这类库做约束解码强制模型只能输出符合schema的token第三层解析失败的时候做一次重试重试时把上一次的错误输出也放进提示词里让模型修正。约束解码是最可靠的一层它从解码阶段就限制了输出空间基本上能杜绝格式错误。代价是推理速度会慢10%到20%但对于需要稳定解析的场景是值得的。5.3 模型“胡说”怎么控制端侧小模型的幻觉问题比云端大模型严重。在超自动化场景里幻觉的典型表现是抽取了原文里不存在的字段值或者把相似但不相关的信息填进了字段。控制手段有几个降低temperature抽取任务用0.1甚至0在提示词里明确说“如果原文没有相关信息输出null”对关键字段做后验校验比如金额字段用正则再验一遍日期字段用日期解析库再验一遍。还有一个技巧是让模型输出原文中的证据片段。比如抽取金额的时候让模型同时输出金额所在的原文句子。这样后续可以用字符串匹配做校验匹配不上就丢弃。这个方法的代价是输出变长推理时间增加但对于准确性要求高的场景很有效。5.4 常见问题速查表问题现象可能原因排查动作解决方案推理速度逐渐变慢显存碎片、热节流查显存占用、GPU温度重启服务、改善散热输出JSON格式错误量化精度损失检查原始输出约束解码、重试机制抽取字段值不存在于原文模型幻觉对比原文降低temperature、证据校验中文理解明显变差模型中文能力不足用中文测试集验证换中文优化模型并发请求时延迟飙升批处理配置不当查batch size和队列调小batch、加队列限流模型加载失败格式不兼容查框架版本统一模型格式和框架版本6. 端侧LLM在超自动化中的扩展方向6.1 多模型协同的端侧架构单个端侧模型能力有限但多个专精模型协同可以覆盖更广的任务。我目前在一个项目里用的是“小模型路由 专精模型执行”的架构一个0.5B的模型做意图识别判断当前请求属于哪个任务类型然后路由到对应的专精模型字段抽取模型、分类模型、摘要模型。这样每个模型都可以做得更小、更快、更准。这个架构的挑战在于路由模型的准确率。路由错了后面全错。我的做法是路由模型输出一个置信度低于阈值的时候走兜底逻辑或者转人工。实测下来路由准确率能到95%以上整体效果比单个大模型好。6.2 端侧LLM与RAG的结合端侧LLM的知识截止在训练数据的时间点对于企业内部的流程知识、产品信息、历史案例需要靠RAG来补充。端侧RAG的难点在于向量检索也要在本地做而且检索延迟要控制住。我的方案是用轻量嵌入模型比如bge-small做本地向量化向量库用FAISS或者Chroma的本地模式。检索top-3的片段拼进提示词整体延迟增加约100毫秒。对于超自动化流程来说可以接受。需要注意的是端侧模型的上下文窗口有限检索回来的片段要做压缩和筛选不能一股脑全塞进去。我的经验是每个片段控制在200字以内总共不超过800字。6.3 端侧LLM的可观测性建设端侧部署之后模型的表现需要持续监控。我一般会记录这几个指标推理延迟的P50/P95/P99、输出解析失败率、字段抽取的校验通过率、人工复核的修正率。这些指标能反映模型在实际业务中的表现变化。如果发现某个指标的趋势在恶化比如解析失败率从2%涨到8%就要排查是数据分布变了还是模型出了问题。端侧模型不会自己更新数据分布变化是常见原因。这时候需要重新做一轮业务测试必要时重新微调或者换模型。7. 一些实操中的个人体会端侧LLM在超自动化里的落地技术选型只占三成剩下七成是对业务场景的理解和对边界的把控。我见过不少项目一上来就想用端侧LLM做全流程决策结果效果不稳定最后又退回规则引擎。也见过把端侧LLM用在很窄的字段抽取任务上配合规则引擎做后续处理整体准确率做到99%以上。我的建议是从最小的可用场景开始。先找一个输入输出明确、容错空间大的环节把端侧LLM跑通积累提示词、量化参数、部署配置的经验再逐步扩展到更复杂的环节。不要一上来就追求端到端的全LLM流程。硬件方面如果预算允许内存和显存尽量留余量。端侧部署的模型和框架都在快速迭代留出余量后续升级会从容很多。我自己的工控机配置是32GB内存加16GB显存跑7B的4bit模型很宽裕跑14B的4bit模型也能跑但比较紧。最后说一个容易被忽略的点端侧LLM的版本管理。模型文件、量化配置、提示词模板、推理框架版本这些东西要一起做版本控制。我吃过亏线上跑得好好的模型因为换了一个提示词模板效果直接掉档排查了半天才发现是模板里的一个措辞变化导致的。现在我的做法是把提示词也当成代码来管理每次改动都走测试流程。