1. 端侧LLM与超自动化的碰撞点在哪把大语言模型塞进手机、工控机、车机、一体机这类终端设备这件事在两年前还属于“实验室里跑着玩”的阶段现在却成了不少自动化团队认真评估的落地方案。原因不复杂超自动化这套东西本质上追求的是把跨系统、跨流程、跨角色的重复劳动压缩到接近零人工干预而LLM恰好补上了传统RPA最缺的那块——对非结构化信息的理解与决策能力。两者一结合端侧部署又进一步把延迟、隐私、离线可用性这三个长期卡脖子的问题往前推了一大步。我先把结论摆出来LLM端侧部署不会取代超自动化的流程编排层但它会重塑超自动化的“感知层”和“决策层”。以前RPA只能处理结构化数据遇到PDF、聊天记录、手写单据就歇菜现在端侧跑一个7B到14B量化模型配合OCR和轻量级RAG就能在本地完成意图识别、字段抽取、异常判断再把结果交给自动化引擎去执行。整个链路不需要把原始数据传到云端响应时间从秒级压到百毫秒级这对工业质检、医疗录入、金融风控这类场景来说是质变。适合谁看这篇内容如果你正在做RPA、流程自动化、智能客服、边缘计算相关的项目或者你是一个对“大模型怎么真正落地”感兴趣的技术负责人那接下来的拆解应该能帮你少走不少弯路。我会从架构选型、模型压缩、推理引擎、与自动化平台的对接方式、实际踩坑记录这几个维度展开尽量把每个决策背后的“为什么”讲清楚。2. 为什么端侧部署突然成了超自动化的刚需2.1 云端LLM在自动化场景里的三个硬伤过去一年我参与过几个超自动化项目最开始大家清一色走云端API路线调用GPT-4或者国内某家大模型的接口效果确实好但跑着跑着问题就暴露了。第一个是延迟不可控。RPA流程里一个环节等3秒和等300毫秒体验完全是两回事。比如客服工单自动分类云端往返加上排队高峰期单次调用能到5到8秒自动化流水线直接堵死。端侧推理把网络传输和排队时间砍掉之后同样的7B模型量化版本在骁龙8 Gen 3上跑分类任务可以做到200毫秒以内。第二个是数据合规与隐私。医疗、金融、政务这些领域的自动化流程原始数据根本不允许出内网。你不可能把病历、身份证号、交易流水发给外部API。端侧部署让数据在本地完成推理只把结构化结果传给下游系统合规审计这一关就好过得多。第三个是离线可用性。工厂车间、野外作业、移动巡检这些场景网络本身就不稳定甚至完全没有。超自动化系统如果依赖云端LLM断网就等于瘫痪。端侧模型虽然能力上限低一些但胜在随时可用这对业务连续性来说是底线保障。2.2 端侧硬件算力已经跨过临界点很多人对端侧跑LLM的印象还停留在“卡顿、发热、跑不动”但硬件迭代速度比想象中快。我整理了一下目前主流端侧推理平台的实测数据供你选型参考硬件平台内存带宽典型可跑模型7B INT4推理速度功耗表现高通骁龙8 Gen 377 GB/s7B-14B量化15-20 tokens/s中等持续推理会降频苹果M3 Pro150 GB/s7B-30B量化30-40 tokens/s优秀风扇基本不转英特尔酷睿Ultra 7120 GB/s7B-14B量化20-25 tokens/s中等NPU加持后改善明显英伟达Jetson Orin NX102 GB/s7B-13B量化18-25 tokens/s较高需主动散热瑞芯微RK358832 GB/s3B-7B量化5-8 tokens/s低适合轻量任务这张表里最关键的指标是内存带宽不是算力TOPS。LLM推理是典型的memory-bound任务每生成一个token都要把整个模型权重过一遍带宽不够算力再强也白搭。所以你在选端侧硬件时先看内存带宽能不能喂饱模型再看NPU的算力。2.3 超自动化对LLM的真实需求画像不是所有自动化环节都需要LLM也不是所有LLM任务都适合端侧。我根据实际项目经验把超自动化里常见的LLM任务按“是否适合端侧”做了个分类适合端侧的任务意图分类、实体抽取、表单字段映射、简单问答、文本摘要、异常检测、工单路由。这些任务的特点是输入短、输出确定性强、对模型推理能力要求不高7B量化模型完全够用。适合云端的任务复杂多步推理、长文档深度分析、代码生成、创意写作、需要世界知识的开放问答。这些任务端侧模型力不从心强行上只会得到一堆似是而非的结果。可以端云协同的任务RAG检索增强生成。端侧做检索和初步筛选云端做最终生成或者端侧跑小模型做路由判断哪些请求需要升级到云端。这种混合架构在成本和体验之间取得了不错的平衡。实操心得不要试图用一个端侧模型解决所有问题。我见过团队硬要把14B模型塞进RK3588结果推理速度掉到2 tokens/s自动化流程比人工还慢。正确的做法是按任务分级端侧只承接高频、短输入、低复杂度的推理请求。3. 端侧LLM部署的核心技术拆解3.1 模型选型不是越大越好而是越合适越好端侧部署第一步是选模型。目前开源社区里适合端侧的LLM主要有几个梯队第一梯队3B以下Qwen2.5-1.5B、Phi-3-mini、Gemma-2-2B、TinyLlama。这些模型在INT4量化后体积不到1GB可以在手机、树莓派上流畅运行。适合做意图分类、简单抽取这类任务。缺点是知识容量有限稍微复杂一点的推理就容易出错。第二梯队7B-9BQwen2.5-7B、Llama-3.1-8B、InternLM2.5-7B、ChatGLM3-6B。这是目前端侧部署的主力区间INT4量化后约4-5GB需要8GB以上内存的设备。在Jetson Orin、M3 Pro、酷睿Ultra上都能跑到可用速度。适合大多数超自动化场景。第三梯队13B-14BQwen2.5-14B、Llama-3.1-13B。量化后约8-9GB需要16GB内存。推理速度明显下降但在高端边缘设备上仍可接受。适合对准确率要求较高的抽取和判断任务。选型时我一般会做一个任务适配测试拿100条真实业务数据分别用不同模型跑一遍看准确率、速度、内存占用三个指标的平衡点。很多时候3B模型在特定任务上经过微调后效果不输7B通用模型速度却快一倍。3.2 量化端侧部署的必经之路量化是把模型权重从FP16压缩到INT8或INT4的过程直接决定模型能不能塞进端侧设备。目前主流的量化方案有几种GPTQ训练后量化需要校准数据集INT4下精度损失较小。适合GPU推理场景在Jetson系列上表现稳定。AWQ激活感知权重量化对重要通道保留更高精度INT4下效果通常优于GPTQ。我实测下来AWQ量化后的7B模型在抽取任务上比GPTQ高2-3个百分点。GGUFllama.cpp生态的量化格式支持从Q2到Q8多种精度CPU推理友好。适合没有独立NPU的设备比如普通x86工控机。ONNX Runtime量化微软主推的方案支持动态量化和静态量化和Windows生态结合紧密。如果你做的是Windows端的自动化工具这条路比较顺。量化过程中有个关键参数叫group size一般设128或64。group size越小量化精度越高但模型体积和推理开销也越大。我的经验是7B模型用group size 128、INT4精度在准确率和速度之间平衡最好。# 以AutoAWQ为例的量化脚本核心逻辑 from awq import AutoAWQForCausalLM from transformers import AutoTokenizer model_path Qwen/Qwen2.5-7B-Instruct quant_path qwen2.5-7b-awq-int4 model AutoAWQForCausalLM.from_pretrained(model_path) tokenizer AutoTokenizer.from_pretrained(model_path) quant_config { zero_point: True, q_group_size: 128, w_bit: 4, version: GEMM } model.quantize(tokenizer, quant_configquant_config) model.save_quantized(quant_path) tokenizer.save_pretrained(quant_path)注意事项量化不是无损的。INT4量化后模型在数学计算、长链推理上的能力会明显下降。如果你的自动化任务涉及金额计算、逻辑判断建议至少用INT8或者保留一个FP16的小模型专门处理这类请求。3.3 推理引擎选型不同硬件走不同路线端侧推理引擎的选择直接决定部署难度和运行效率。我按硬件平台梳理一下主流方案NVIDIA Jetson系列TensorRT-LLM是首选能把模型编译成高度优化的engine推理速度比原生PyTorch快3-5倍。缺点是编译过程复杂对模型结构有要求。备选方案是llama.cpp的CUDA后端部署简单但性能略逊。高通骁龙平台QNN SDK是高通官方推理框架能调用Hexagon NPU。但生态相对封闭模型转换工具链不够成熟。目前比较务实的做法是用ONNX Runtime的QNN执行提供器或者直接用llama.cpp的CPU后端。苹果平台MLX框架是苹果硅上的最优解专为统一内存架构设计7B模型跑起来非常流畅。Core ML也可以但LLM支持不如MLX成熟。x86工控机/PCllama.cpp是万能选择支持CPU和多种GPU后端GGUF格式模型即拿即用。如果机器有独立显卡可以用TensorRT-LLM或vLLM。国产NPU平台瑞芯微、寒武纪等一般厂商会提供自己的推理SDK需要把模型转成专用格式。这条路坑比较多建议先跑通官方demo再上业务模型。3.4 与超自动化平台的对接方式端侧LLM部署好之后怎么跟现有的超自动化平台对接我见过三种主流模式API封装模式在端侧设备上起一个轻量HTTP服务比如FastAPI把LLM推理封装成REST接口。自动化平台通过HTTP调用和调云端API的体验一致。这种模式解耦最好但多了一层网络开销。SDK嵌入模式把推理引擎编译成动态库直接嵌入自动化平台的执行器进程。延迟最低但耦合度高升级模型需要重新编译。消息队列模式端侧LLM作为独立消费者从Kafka或RabbitMQ拉取任务处理完把结果写回队列。适合异步、高并发的自动化场景但架构复杂度最高。我一般推荐API封装模式因为超自动化平台通常已经支持HTTP节点改造成本最低。而且端侧服务可以独立重启、独立升级不影响主流程。4. 完整实操从零搭建一个端侧LLM自动化节点4.1 环境准备与依赖安装我以Jetson Orin NX 16GB为例走一遍完整部署流程。这套流程在Ubuntu 22.04上验证过其他Linux发行版大同小异。首先刷好JetPack 6.0系统确认CUDA和TensorRT版本# 检查环境 nvcc --version dpkg -l | grep tensorrt python3 --version然后安装Python依赖。注意Jetson上不要直接用pip装tensorrt要用JetPack自带的版本sudo apt-get update sudo apt-get install -y python3-pip python3-dev pip3 install --upgrade pip pip3 install fastapi uvicorn pydantic pip3 install transformers accelerate如果要走TensorRT-LLM路线还需要编译安装TensorRT-LLM这个过程比较耗时建议预留2小时以上。4.2 模型下载与量化转换从HuggingFace下载Qwen2.5-7B-Instruct然后做AWQ量化。Jetson上量化比较慢可以在PC上量化好再拷贝过去# 在PC上执行量化 pip install autoawq python3 quantize.py # 使用前面提到的量化脚本 # 量化完成后拷贝到Jetson scp -r qwen2.5-7b-awq-int4/ jetson192.168.1.100:/home/jetson/models/如果不想自己量化也可以直接下载社区已经量化好的模型。HuggingFace上搜“Qwen2.5-7B AWQ”能找到不少现成版本。但要注意量化配置是否匹配你的推理引擎有些AWQ模型是为vLLM优化的在TensorRT-LLM上可能跑不起来。4.3 推理服务封装用FastAPI封装一个简单的推理服务支持流式和非流式两种模式from fastapi import FastAPI from fastapi.responses import StreamingResponse from pydantic import BaseModel from transformers import AutoModelForCausalLM, AutoTokenizer import torch app FastAPI() model_path /home/jetson/models/qwen2.5-7b-awq-int4 tokenizer AutoTokenizer.from_pretrained(model_path) model AutoModelForCausalLM.from_pretrained( model_path, device_mapauto, torch_dtypetorch.float16 ) class GenerateRequest(BaseModel): prompt: str max_new_tokens: int 256 temperature: float 0.1 app.post(/generate) async def generate(req: GenerateRequest): inputs tokenizer(req.prompt, return_tensorspt).to(model.device) outputs model.generate( **inputs, max_new_tokensreq.max_new_tokens, temperaturereq.temperature, do_samplereq.temperature 0 ) result tokenizer.decode(outputs[0], skip_special_tokensTrue) return {result: result} app.get(/health) async def health(): return {status: ok}启动服务uvicorn llm_server:app --host 0.0.0.0 --port 8000 --workers 1注意端侧设备内存有限workers不要设太多一般1个就够。多个worker会导致模型被加载多次内存直接爆掉。4.4 与自动化流程串联假设你用某个超自动化平台在流程里加一个HTTP节点调用端侧LLM服务。以工单自动分类为例流程是这样的监听工单系统新工单事件提取工单标题和描述调用端侧LLM服务prompt设计为“请判断以下工单属于哪个类别网络故障、硬件故障、软件问题、账号问题、其他。只输出类别名称。”解析LLM返回结果根据类别路由到不同处理队列记录处理日志这个流程里LLM只做分类不做复杂推理7B模型完全胜任。实测在Jetson Orin NX上单次分类请求从发出到收到结果约350毫秒其中模型推理占280毫秒网络和序列化占70毫秒。4.5 性能调优的几个关键参数端侧推理性能调优我一般关注这几个参数max_new_tokens控制生成的最大长度。分类任务设32就够抽取任务设128摘要任务设256。设太大不仅慢还容易生成无关内容。temperature自动化任务建议设0.1以下甚至直接贪心解码。温度越高输出越随机对确定性要求高的流程是灾难。batch size端侧一般设1除非你有大量并发请求且内存充足。批处理能提升吞吐但会增加单次延迟。KV Cache开启KV Cache能显著加速长文本生成但会占用额外内存。7B模型在4K上下文下KV Cache约占用1GB内存需要提前算好。线程数CPU推理时线程数设为物理核心数不要超线程。Jetson Orin NX有8个核心设8即可。5. 踩坑记录与常见问题排查5.1 模型加载失败内存不足的几种表现端侧部署最常见的问题就是内存不够。表现有好几种模型加载到一半进程被kill、推理时突然OOM、系统整体卡死。排查思路是先用free -h看可用内存再用nvidia-smi如果有GPU看显存占用。7B模型INT4量化后权重约4GB加上KV Cache、中间激活值、Python运行时开销实际需要8GB以上可用内存。Jetson Orin NX 16GB版本跑7B没问题8GB版本就很勉强。如果内存实在不够有两个选择换更小的模型或者用CPU offload把部分层放到内存里慢慢算。5.2 推理速度慢先看是不是memory-bound推理速度慢很多人第一反应是算力不够其实大多数情况是内存带宽瓶颈。判断方法很简单用tegrastatsJetson或intel_gpu_topIntel看推理时的内存带宽利用率。如果带宽跑满而算力利用率很低那就是memory-bound换更强算力也没用得换带宽更高的硬件或者更小的模型。另一个常见原因是量化格式和推理引擎不匹配。比如你用GPTQ量化的模型去跑TensorRT-LLM引擎需要先做格式转换转换过程中可能回退到FP16速度直接掉一半。所以量化时就要确定目标推理引擎按它的要求来。5.3 输出不稳定prompt设计和解码策略端侧小模型比云端大模型更容易出现输出不稳定同样的输入有时候给不同结果。除了降低temperatureprompt设计也很关键。我的经验是明确输出格式比如“只输出JSON不要有其他内容”给出少量示例few-shot2-3个就够限制输出长度避免模型自由发挥用系统提示词固定角色和行为边界如果还是不稳定可以考虑用约束解码比如Outlines或Guidance库强制模型按指定格式输出。这在抽取任务里特别有用能保证输出一定是合法JSON。5.4 常见问题速查表问题现象可能原因排查方法解决方案模型加载OOM内存不足free -h查看可用内存换小模型或增加内存推理速度5 tokens/smemory-bound或量化不匹配查看内存带宽利用率换硬件或重新量化输出乱码/重复量化精度过低对比FP16和INT4输出提高量化精度到INT8服务无响应进程卡死或端口占用ps aux查看进程状态重启服务检查端口首次推理特别慢模型编译/加载查看日志时间戳预热一次后续正常多并发时崩溃内存竞争监控内存曲线限制并发数或加队列5.5 几个容易被忽略的细节散热端侧设备持续推理发热严重Jetson Orin NX不加散热片跑10分钟就会降频。工业场景一定要做好散热设计否则标称性能根本跑不出来。电源高性能推理时功耗飙升电池供电的设备续航会断崖式下降。如果做移动端自动化要算好功耗预算。模型更新端侧设备分散在各处模型更新是个麻烦事。建议设计一套OTA更新机制或者把模型放在可挂载的存储上远程替换。日志与监控端侧服务出问题时现场往往没人会排查。一定要把关键日志写到本地文件并支持远程拉取。监控指标至少包括推理延迟、内存占用、错误率。6. 端云协同更务实的超自动化架构纯端侧方案虽然诱人但实际项目里我更多采用端云协同架构。核心思路是端侧处理高频、简单、隐私敏感的任务云端处理低频、复杂、需要世界知识的任务。具体分工可以这样设计端侧跑一个3B模型做意图路由判断请求类型。如果是简单分类或抽取端侧直接处理如果是复杂推理或长文档分析端侧把请求转发到云端。这样既保证了大部分请求的低延迟和隐私安全又保留了云端大模型的能力上限。端云协同的另一个好处是成本可控。云端API按token计费高频简单任务走端侧后云端调用量能降60%以上。对于大规模自动化部署来说这个成本差异非常可观。实现上端侧服务可以做一个简单的路由逻辑def route_request(prompt, task_type): if task_type in [classification, extraction, routing]: return local_llm.generate(prompt) elif task_type in [reasoning, summarization, qa]: if len(prompt) 500: return local_llm.generate(prompt) else: return cloud_llm.generate(prompt) else: return cloud_llm.generate(prompt)这个路由逻辑可以根据实际业务数据不断调整阈值找到端侧和云端的最优分界点。7. 我个人的一些实操体会端侧LLM部署这件事技术门槛正在快速降低但工程门槛依然不低。我踩过的坑里最浪费时间的是硬件选型失误——一开始用RK3588跑7B模型速度慢到无法接受后来换Jetson Orin NX才跑通。教训是选硬件前先算内存带宽别只看算力参数。另一个体会是不要追求一步到位。很多团队想直接上14B模型做复杂推理结果端侧跑不动项目卡住。正确的做法是从3B模型做简单任务开始跑通链路后再逐步升级模型和任务复杂度。端侧部署是个迭代过程不是一次性工程。最后分享一个小技巧用llama.cpp的server模式做快速验证。它支持GGUF格式模型一条命令就能起服务不需要写任何代码。在正式开发前用llama.cpp快速验证模型在目标硬件上的速度和效果能帮你省掉大量试错时间。# llama.cpp快速验证 ./llama-server -m qwen2.5-7b-instruct-q4_k_m.gguf -c 4096 -t 8 --host 0.0.0.0 --port 8080这个命令跑起来后直接用curl测试curl http://localhost:8080/completion -d { prompt: 判断以下工单类别网络无法连接只输出类别名称。, n_predict: 32, temperature: 0.1 }如果这个速度你能接受再考虑用TensorRT-LLM或AWQ做进一步优化。如果这个速度就不行那说明硬件选错了趁早换方案。
1. 端侧LLM与超自动化的碰撞点在哪把大语言模型塞进手机、工控机、车机、一体机这类终端设备这件事在两年前还属于“实验室里跑着玩”的阶段现在却成了不少自动化团队认真评估的落地方案。原因不复杂超自动化这套东西本质上追求的是把跨系统、跨流程、跨角色的重复劳动压缩到接近零人工干预而LLM恰好补上了传统RPA最缺的那块——对非结构化信息的理解与决策能力。两者一结合端侧部署又进一步把延迟、隐私、离线可用性这三个长期卡脖子的问题往前推了一大步。我先把结论摆出来LLM端侧部署不会取代超自动化的流程编排层但它会重塑超自动化的“感知层”和“决策层”。以前RPA只能处理结构化数据遇到PDF、聊天记录、手写单据就歇菜现在端侧跑一个7B到14B量化模型配合OCR和轻量级RAG就能在本地完成意图识别、字段抽取、异常判断再把结果交给自动化引擎去执行。整个链路不需要把原始数据传到云端响应时间从秒级压到百毫秒级这对工业质检、医疗录入、金融风控这类场景来说是质变。适合谁看这篇内容如果你正在做RPA、流程自动化、智能客服、边缘计算相关的项目或者你是一个对“大模型怎么真正落地”感兴趣的技术负责人那接下来的拆解应该能帮你少走不少弯路。我会从架构选型、模型压缩、推理引擎、与自动化平台的对接方式、实际踩坑记录这几个维度展开尽量把每个决策背后的“为什么”讲清楚。2. 为什么端侧部署突然成了超自动化的刚需2.1 云端LLM在自动化场景里的三个硬伤过去一年我参与过几个超自动化项目最开始大家清一色走云端API路线调用GPT-4或者国内某家大模型的接口效果确实好但跑着跑着问题就暴露了。第一个是延迟不可控。RPA流程里一个环节等3秒和等300毫秒体验完全是两回事。比如客服工单自动分类云端往返加上排队高峰期单次调用能到5到8秒自动化流水线直接堵死。端侧推理把网络传输和排队时间砍掉之后同样的7B模型量化版本在骁龙8 Gen 3上跑分类任务可以做到200毫秒以内。第二个是数据合规与隐私。医疗、金融、政务这些领域的自动化流程原始数据根本不允许出内网。你不可能把病历、身份证号、交易流水发给外部API。端侧部署让数据在本地完成推理只把结构化结果传给下游系统合规审计这一关就好过得多。第三个是离线可用性。工厂车间、野外作业、移动巡检这些场景网络本身就不稳定甚至完全没有。超自动化系统如果依赖云端LLM断网就等于瘫痪。端侧模型虽然能力上限低一些但胜在随时可用这对业务连续性来说是底线保障。2.2 端侧硬件算力已经跨过临界点很多人对端侧跑LLM的印象还停留在“卡顿、发热、跑不动”但硬件迭代速度比想象中快。我整理了一下目前主流端侧推理平台的实测数据供你选型参考硬件平台内存带宽典型可跑模型7B INT4推理速度功耗表现高通骁龙8 Gen 377 GB/s7B-14B量化15-20 tokens/s中等持续推理会降频苹果M3 Pro150 GB/s7B-30B量化30-40 tokens/s优秀风扇基本不转英特尔酷睿Ultra 7120 GB/s7B-14B量化20-25 tokens/s中等NPU加持后改善明显英伟达Jetson Orin NX102 GB/s7B-13B量化18-25 tokens/s较高需主动散热瑞芯微RK358832 GB/s3B-7B量化5-8 tokens/s低适合轻量任务这张表里最关键的指标是内存带宽不是算力TOPS。LLM推理是典型的memory-bound任务每生成一个token都要把整个模型权重过一遍带宽不够算力再强也白搭。所以你在选端侧硬件时先看内存带宽能不能喂饱模型再看NPU的算力。2.3 超自动化对LLM的真实需求画像不是所有自动化环节都需要LLM也不是所有LLM任务都适合端侧。我根据实际项目经验把超自动化里常见的LLM任务按“是否适合端侧”做了个分类适合端侧的任务意图分类、实体抽取、表单字段映射、简单问答、文本摘要、异常检测、工单路由。这些任务的特点是输入短、输出确定性强、对模型推理能力要求不高7B量化模型完全够用。适合云端的任务复杂多步推理、长文档深度分析、代码生成、创意写作、需要世界知识的开放问答。这些任务端侧模型力不从心强行上只会得到一堆似是而非的结果。可以端云协同的任务RAG检索增强生成。端侧做检索和初步筛选云端做最终生成或者端侧跑小模型做路由判断哪些请求需要升级到云端。这种混合架构在成本和体验之间取得了不错的平衡。实操心得不要试图用一个端侧模型解决所有问题。我见过团队硬要把14B模型塞进RK3588结果推理速度掉到2 tokens/s自动化流程比人工还慢。正确的做法是按任务分级端侧只承接高频、短输入、低复杂度的推理请求。3. 端侧LLM部署的核心技术拆解3.1 模型选型不是越大越好而是越合适越好端侧部署第一步是选模型。目前开源社区里适合端侧的LLM主要有几个梯队第一梯队3B以下Qwen2.5-1.5B、Phi-3-mini、Gemma-2-2B、TinyLlama。这些模型在INT4量化后体积不到1GB可以在手机、树莓派上流畅运行。适合做意图分类、简单抽取这类任务。缺点是知识容量有限稍微复杂一点的推理就容易出错。第二梯队7B-9BQwen2.5-7B、Llama-3.1-8B、InternLM2.5-7B、ChatGLM3-6B。这是目前端侧部署的主力区间INT4量化后约4-5GB需要8GB以上内存的设备。在Jetson Orin、M3 Pro、酷睿Ultra上都能跑到可用速度。适合大多数超自动化场景。第三梯队13B-14BQwen2.5-14B、Llama-3.1-13B。量化后约8-9GB需要16GB内存。推理速度明显下降但在高端边缘设备上仍可接受。适合对准确率要求较高的抽取和判断任务。选型时我一般会做一个任务适配测试拿100条真实业务数据分别用不同模型跑一遍看准确率、速度、内存占用三个指标的平衡点。很多时候3B模型在特定任务上经过微调后效果不输7B通用模型速度却快一倍。3.2 量化端侧部署的必经之路量化是把模型权重从FP16压缩到INT8或INT4的过程直接决定模型能不能塞进端侧设备。目前主流的量化方案有几种GPTQ训练后量化需要校准数据集INT4下精度损失较小。适合GPU推理场景在Jetson系列上表现稳定。AWQ激活感知权重量化对重要通道保留更高精度INT4下效果通常优于GPTQ。我实测下来AWQ量化后的7B模型在抽取任务上比GPTQ高2-3个百分点。GGUFllama.cpp生态的量化格式支持从Q2到Q8多种精度CPU推理友好。适合没有独立NPU的设备比如普通x86工控机。ONNX Runtime量化微软主推的方案支持动态量化和静态量化和Windows生态结合紧密。如果你做的是Windows端的自动化工具这条路比较顺。量化过程中有个关键参数叫group size一般设128或64。group size越小量化精度越高但模型体积和推理开销也越大。我的经验是7B模型用group size 128、INT4精度在准确率和速度之间平衡最好。# 以AutoAWQ为例的量化脚本核心逻辑 from awq import AutoAWQForCausalLM from transformers import AutoTokenizer model_path Qwen/Qwen2.5-7B-Instruct quant_path qwen2.5-7b-awq-int4 model AutoAWQForCausalLM.from_pretrained(model_path) tokenizer AutoTokenizer.from_pretrained(model_path) quant_config { zero_point: True, q_group_size: 128, w_bit: 4, version: GEMM } model.quantize(tokenizer, quant_configquant_config) model.save_quantized(quant_path) tokenizer.save_pretrained(quant_path)注意事项量化不是无损的。INT4量化后模型在数学计算、长链推理上的能力会明显下降。如果你的自动化任务涉及金额计算、逻辑判断建议至少用INT8或者保留一个FP16的小模型专门处理这类请求。3.3 推理引擎选型不同硬件走不同路线端侧推理引擎的选择直接决定部署难度和运行效率。我按硬件平台梳理一下主流方案NVIDIA Jetson系列TensorRT-LLM是首选能把模型编译成高度优化的engine推理速度比原生PyTorch快3-5倍。缺点是编译过程复杂对模型结构有要求。备选方案是llama.cpp的CUDA后端部署简单但性能略逊。高通骁龙平台QNN SDK是高通官方推理框架能调用Hexagon NPU。但生态相对封闭模型转换工具链不够成熟。目前比较务实的做法是用ONNX Runtime的QNN执行提供器或者直接用llama.cpp的CPU后端。苹果平台MLX框架是苹果硅上的最优解专为统一内存架构设计7B模型跑起来非常流畅。Core ML也可以但LLM支持不如MLX成熟。x86工控机/PCllama.cpp是万能选择支持CPU和多种GPU后端GGUF格式模型即拿即用。如果机器有独立显卡可以用TensorRT-LLM或vLLM。国产NPU平台瑞芯微、寒武纪等一般厂商会提供自己的推理SDK需要把模型转成专用格式。这条路坑比较多建议先跑通官方demo再上业务模型。3.4 与超自动化平台的对接方式端侧LLM部署好之后怎么跟现有的超自动化平台对接我见过三种主流模式API封装模式在端侧设备上起一个轻量HTTP服务比如FastAPI把LLM推理封装成REST接口。自动化平台通过HTTP调用和调云端API的体验一致。这种模式解耦最好但多了一层网络开销。SDK嵌入模式把推理引擎编译成动态库直接嵌入自动化平台的执行器进程。延迟最低但耦合度高升级模型需要重新编译。消息队列模式端侧LLM作为独立消费者从Kafka或RabbitMQ拉取任务处理完把结果写回队列。适合异步、高并发的自动化场景但架构复杂度最高。我一般推荐API封装模式因为超自动化平台通常已经支持HTTP节点改造成本最低。而且端侧服务可以独立重启、独立升级不影响主流程。4. 完整实操从零搭建一个端侧LLM自动化节点4.1 环境准备与依赖安装我以Jetson Orin NX 16GB为例走一遍完整部署流程。这套流程在Ubuntu 22.04上验证过其他Linux发行版大同小异。首先刷好JetPack 6.0系统确认CUDA和TensorRT版本# 检查环境 nvcc --version dpkg -l | grep tensorrt python3 --version然后安装Python依赖。注意Jetson上不要直接用pip装tensorrt要用JetPack自带的版本sudo apt-get update sudo apt-get install -y python3-pip python3-dev pip3 install --upgrade pip pip3 install fastapi uvicorn pydantic pip3 install transformers accelerate如果要走TensorRT-LLM路线还需要编译安装TensorRT-LLM这个过程比较耗时建议预留2小时以上。4.2 模型下载与量化转换从HuggingFace下载Qwen2.5-7B-Instruct然后做AWQ量化。Jetson上量化比较慢可以在PC上量化好再拷贝过去# 在PC上执行量化 pip install autoawq python3 quantize.py # 使用前面提到的量化脚本 # 量化完成后拷贝到Jetson scp -r qwen2.5-7b-awq-int4/ jetson192.168.1.100:/home/jetson/models/如果不想自己量化也可以直接下载社区已经量化好的模型。HuggingFace上搜“Qwen2.5-7B AWQ”能找到不少现成版本。但要注意量化配置是否匹配你的推理引擎有些AWQ模型是为vLLM优化的在TensorRT-LLM上可能跑不起来。4.3 推理服务封装用FastAPI封装一个简单的推理服务支持流式和非流式两种模式from fastapi import FastAPI from fastapi.responses import StreamingResponse from pydantic import BaseModel from transformers import AutoModelForCausalLM, AutoTokenizer import torch app FastAPI() model_path /home/jetson/models/qwen2.5-7b-awq-int4 tokenizer AutoTokenizer.from_pretrained(model_path) model AutoModelForCausalLM.from_pretrained( model_path, device_mapauto, torch_dtypetorch.float16 ) class GenerateRequest(BaseModel): prompt: str max_new_tokens: int 256 temperature: float 0.1 app.post(/generate) async def generate(req: GenerateRequest): inputs tokenizer(req.prompt, return_tensorspt).to(model.device) outputs model.generate( **inputs, max_new_tokensreq.max_new_tokens, temperaturereq.temperature, do_samplereq.temperature 0 ) result tokenizer.decode(outputs[0], skip_special_tokensTrue) return {result: result} app.get(/health) async def health(): return {status: ok}启动服务uvicorn llm_server:app --host 0.0.0.0 --port 8000 --workers 1注意端侧设备内存有限workers不要设太多一般1个就够。多个worker会导致模型被加载多次内存直接爆掉。4.4 与自动化流程串联假设你用某个超自动化平台在流程里加一个HTTP节点调用端侧LLM服务。以工单自动分类为例流程是这样的监听工单系统新工单事件提取工单标题和描述调用端侧LLM服务prompt设计为“请判断以下工单属于哪个类别网络故障、硬件故障、软件问题、账号问题、其他。只输出类别名称。”解析LLM返回结果根据类别路由到不同处理队列记录处理日志这个流程里LLM只做分类不做复杂推理7B模型完全胜任。实测在Jetson Orin NX上单次分类请求从发出到收到结果约350毫秒其中模型推理占280毫秒网络和序列化占70毫秒。4.5 性能调优的几个关键参数端侧推理性能调优我一般关注这几个参数max_new_tokens控制生成的最大长度。分类任务设32就够抽取任务设128摘要任务设256。设太大不仅慢还容易生成无关内容。temperature自动化任务建议设0.1以下甚至直接贪心解码。温度越高输出越随机对确定性要求高的流程是灾难。batch size端侧一般设1除非你有大量并发请求且内存充足。批处理能提升吞吐但会增加单次延迟。KV Cache开启KV Cache能显著加速长文本生成但会占用额外内存。7B模型在4K上下文下KV Cache约占用1GB内存需要提前算好。线程数CPU推理时线程数设为物理核心数不要超线程。Jetson Orin NX有8个核心设8即可。5. 踩坑记录与常见问题排查5.1 模型加载失败内存不足的几种表现端侧部署最常见的问题就是内存不够。表现有好几种模型加载到一半进程被kill、推理时突然OOM、系统整体卡死。排查思路是先用free -h看可用内存再用nvidia-smi如果有GPU看显存占用。7B模型INT4量化后权重约4GB加上KV Cache、中间激活值、Python运行时开销实际需要8GB以上可用内存。Jetson Orin NX 16GB版本跑7B没问题8GB版本就很勉强。如果内存实在不够有两个选择换更小的模型或者用CPU offload把部分层放到内存里慢慢算。5.2 推理速度慢先看是不是memory-bound推理速度慢很多人第一反应是算力不够其实大多数情况是内存带宽瓶颈。判断方法很简单用tegrastatsJetson或intel_gpu_topIntel看推理时的内存带宽利用率。如果带宽跑满而算力利用率很低那就是memory-bound换更强算力也没用得换带宽更高的硬件或者更小的模型。另一个常见原因是量化格式和推理引擎不匹配。比如你用GPTQ量化的模型去跑TensorRT-LLM引擎需要先做格式转换转换过程中可能回退到FP16速度直接掉一半。所以量化时就要确定目标推理引擎按它的要求来。5.3 输出不稳定prompt设计和解码策略端侧小模型比云端大模型更容易出现输出不稳定同样的输入有时候给不同结果。除了降低temperatureprompt设计也很关键。我的经验是明确输出格式比如“只输出JSON不要有其他内容”给出少量示例few-shot2-3个就够限制输出长度避免模型自由发挥用系统提示词固定角色和行为边界如果还是不稳定可以考虑用约束解码比如Outlines或Guidance库强制模型按指定格式输出。这在抽取任务里特别有用能保证输出一定是合法JSON。5.4 常见问题速查表问题现象可能原因排查方法解决方案模型加载OOM内存不足free -h查看可用内存换小模型或增加内存推理速度5 tokens/smemory-bound或量化不匹配查看内存带宽利用率换硬件或重新量化输出乱码/重复量化精度过低对比FP16和INT4输出提高量化精度到INT8服务无响应进程卡死或端口占用ps aux查看进程状态重启服务检查端口首次推理特别慢模型编译/加载查看日志时间戳预热一次后续正常多并发时崩溃内存竞争监控内存曲线限制并发数或加队列5.5 几个容易被忽略的细节散热端侧设备持续推理发热严重Jetson Orin NX不加散热片跑10分钟就会降频。工业场景一定要做好散热设计否则标称性能根本跑不出来。电源高性能推理时功耗飙升电池供电的设备续航会断崖式下降。如果做移动端自动化要算好功耗预算。模型更新端侧设备分散在各处模型更新是个麻烦事。建议设计一套OTA更新机制或者把模型放在可挂载的存储上远程替换。日志与监控端侧服务出问题时现场往往没人会排查。一定要把关键日志写到本地文件并支持远程拉取。监控指标至少包括推理延迟、内存占用、错误率。6. 端云协同更务实的超自动化架构纯端侧方案虽然诱人但实际项目里我更多采用端云协同架构。核心思路是端侧处理高频、简单、隐私敏感的任务云端处理低频、复杂、需要世界知识的任务。具体分工可以这样设计端侧跑一个3B模型做意图路由判断请求类型。如果是简单分类或抽取端侧直接处理如果是复杂推理或长文档分析端侧把请求转发到云端。这样既保证了大部分请求的低延迟和隐私安全又保留了云端大模型的能力上限。端云协同的另一个好处是成本可控。云端API按token计费高频简单任务走端侧后云端调用量能降60%以上。对于大规模自动化部署来说这个成本差异非常可观。实现上端侧服务可以做一个简单的路由逻辑def route_request(prompt, task_type): if task_type in [classification, extraction, routing]: return local_llm.generate(prompt) elif task_type in [reasoning, summarization, qa]: if len(prompt) 500: return local_llm.generate(prompt) else: return cloud_llm.generate(prompt) else: return cloud_llm.generate(prompt)这个路由逻辑可以根据实际业务数据不断调整阈值找到端侧和云端的最优分界点。7. 我个人的一些实操体会端侧LLM部署这件事技术门槛正在快速降低但工程门槛依然不低。我踩过的坑里最浪费时间的是硬件选型失误——一开始用RK3588跑7B模型速度慢到无法接受后来换Jetson Orin NX才跑通。教训是选硬件前先算内存带宽别只看算力参数。另一个体会是不要追求一步到位。很多团队想直接上14B模型做复杂推理结果端侧跑不动项目卡住。正确的做法是从3B模型做简单任务开始跑通链路后再逐步升级模型和任务复杂度。端侧部署是个迭代过程不是一次性工程。最后分享一个小技巧用llama.cpp的server模式做快速验证。它支持GGUF格式模型一条命令就能起服务不需要写任何代码。在正式开发前用llama.cpp快速验证模型在目标硬件上的速度和效果能帮你省掉大量试错时间。# llama.cpp快速验证 ./llama-server -m qwen2.5-7b-instruct-q4_k_m.gguf -c 4096 -t 8 --host 0.0.0.0 --port 8080这个命令跑起来后直接用curl测试curl http://localhost:8080/completion -d { prompt: 判断以下工单类别网络无法连接只输出类别名称。, n_predict: 32, temperature: 0.1 }如果这个速度你能接受再考虑用TensorRT-LLM或AWQ做进一步优化。如果这个速度就不行那说明硬件选错了趁早换方案。
