1. 端侧Agent为什么需要一把“本地大脑”先说结论端侧Agent和端侧LLM不是打包出售的组件而是“大脑”和“身体”的关系。Agent负责拆任务、调工具、做决策LLM负责理解意图、生成文本、抽取关键信息。没有LLM的Agent本质上就是一堆硬编码的if-else条件一变就歇菜。而把LLM真正部署到设备端意味着Agent第一次具备了在离线环境下独立推理的能力。1.1 先把云端的三个老问题说清楚我最初做Agent系统时第一反应也是“大脑放云端不就行了”但实际跑了几轮之后发现三个问题会卡死你。第一个是延迟。云端推理的完整链路是设备采集数据 - 上行到服务器 - 排队推理 - 结果回传。即使网络状况良好一次往返也要300毫秒起步如果走的是公网500到800毫秒都很常见。对于需要多轮工具调用的Agent来说单轮对话就得调用三次以上LLM整个链路变成秒级响应交互体验直接崩了。第二个是成本。Token费用看着不贵但Agent场景是“高频短调用”一次简单任务可能消耗几百个token设备一多、调用一勤账单涨得比跑代码还快。我见过一个做巡检机器人项目的朋友云端API一个月烧掉四千多块就为了传几句“继续走”“左转”这种指令后来换端侧部署一次性硬件成本之后只是电费。第三个是隐私和断网。工业设备、医疗设备、家居设备很多场景数据根本不允许出设备。我接触过的几个智能门禁、健康监测项目客户直接要求“数据零上云”这种情况下云端方案在起步阶段就被否了。1.2 端侧LLM的能力边界别一厢情愿端侧LLM不是万能的。先说清楚它能干什么意图分类、槽位提取、短对话、JSON生成、代码片段理解、工具调用参数填充这些都是它的舒适区。3B到7B的量化模型配合结构化Prompt和Function Calling约束在设备上完全能担当“小助手”的角色。但它不擅长什么也很明显长文总结、复杂推理、多轮深度对话、最新知识问答。这些任务上下文太长推理太深端侧算力顶不住。所以我的经验是端侧Agent的架构不能搞“一切皆AI”而是把任务分级轻量任务交给端侧模型需要深度推理的内容再走云端补充。我自己的处理方式是加一道“路由层”先让端侧模型做一个二分类判断当前请求本地能否处理能处理就直接出结果拿不准的再向云端请求。这样既保住了离线能力又不会因为硬扛高难度任务导致响应质量崩掉。1.3 端侧Agent的典型分工方式一个务实的端侧Agent系统通常这样分工本地LLM承担语音/文本指令的意图识别工具调用的JSON参数生成设备状态信息的自然语言描述本地知识库的检索式回答简单决策链路如“电量低于20%就提醒充电并规划路线”云端LLM承担需要大量常识的开放问答多文档对比总结需要联网的实时信息查询这套分工的好处是即使完全断网Agent的“生活自理能力”依然在线。举一个我实际做过的例子一个室内配送机器人本地部署了一个3B模型用户说“帮我到A点取个东西中途如果电量低于30%就先回充电桩”。这句指令里包含意图识别取件任务、条件判断电量阈值、行为规划中途充电纯靠本地模型做到了整个决策链路跑在一个Jetson Orin Nano上延迟在500毫秒左右完全可接受。2. 端侧LLM模型选型与框架选型选型这件事最怕的是上来就问“哪个模型效果最好”。端侧场景里效果只是及格线真正决定项目成败的是“模型大小、量化等级、硬件资源、推理延迟”四个变量之间的动态平衡。2.1 模型挑法:参数量、量化、上下文一个都不能少参数量先定上限。端侧设备的存储和内存是硬约束我一般按“模型文件大小 运行时开销”来倒推。一个3B模型FP16格式大约6GB量化到Q4需要2GB左右加上KV Cache和运行时buffer整个推理要吃掉3到4GB内存。7B模型量化后也要4到5GB基本就得16GB内存的设备才跑得舒服。我日常的选择逻辑是这样的2GB以内内存余量选1.5B到3B的量化模型比如Qwen2.5-1.5B、Phi-3-mini4GB左右内存余量选3B到4B模型Qwen2.5-3B、Llama-3.2-3B8GB以上内存余量可以考虑7B到8B模型Qwen2.5-7B、Llama-3.1-8B量化等级看任务不是越低越好。我实测过Q4_K_M和Q8在意图分类任务上差距不大但在代码生成和结构化输出上Q4会出现JSON格式不那么稳定的情况。所以我的默认方案是通用对话类任务用Q4_K_M涉及结构化输出、Function Calling的任务尽量上Q5或Q6牺牲一点速度换稳定性。上下文长度决定Agent的“记性”。端侧模型受限于KV Cache上下文越长内存占用越高。8K上下文的KV Cache大约占用几百MB32K就要1GB以上。我的建议是Agent场景下4K到8K足够用了。因为端侧Agent的核心是处理当前指令而不是长文档阅读。硬上32K上下文不仅内存爆表注意力分散还会让工具调用准确率下降。2.2 推理框架怎么选Ollama、llama.cpp、MLC-LLM三选一框架选择这块我踩过不少坑最后形成了自己的判断标准。Ollama追求零门槛上线。适合快速验证、原型开发一条命令就能把模型跑起来还自动管理模型缓存和端口服务。对开发者来说它就是“本地大模型界的Docker”。网上那些“本地部署deepseek”的教程案例里用Ollama跑模型是最常见的方案这足以说明它在部署环节的易用性。Ollama暴露的OpenAI兼容接口让Agent框架接入只需改base_url几乎不用改代码。llama.cpp追求极致性能和精细控制。这是部署界的老牌框架也是GGUF格式的源头。它能精确控制GPU层数、线程数、内存映射方式对嵌入式设备友好。Jetson、树莓派、RK3588上跑模型我最终都是回到llama.cpp或者基于它的衍生方案因为Ollama有时不能细粒度地调底层参数。MLC-LLM追求利用专用硬件。它支持把模型编译到Vulkan、Metal、CUDA等后端尤其在苹果芯片和部分移动GPU上有优势。如果目标设备是手机或者带GPU的平板MLC-LLM值得研究但它的学习曲线更陡编译环节也比较折腾。我把三者的适用场景整理成了一张表方便直接对照框架适合场景启动难度性能释放典型设备Ollama原型验证、快速集成极低中家用PC、Mac、开发者板llama.cpp生产级部署、嵌入式中高Jetson、RK3588、树莓派MLC-LLM移动端GPU优化高高手机、平板、苹果芯片设备选框架不要追求新潮我的原则是设备上有CUDA就用llama.cpp求省事就用Ollama搞移动端再碰MLC。2.3 硬件适配Jetson Orin和RK3588代表了两个方向设备端部署LLM目前最具代表性的两块硬件是Jetson Orin系列和RK3588系列。Jetson Orin Nano的8GB版本是我最常用的端侧Agent开发平台。它有一个Ampere架构的GPU虽然不像桌面显卡那么强但在8GB统一内存的帮助下跑Q4量化的3B模型能达到20到30 token/s跑7B模型在10到15 token/s左右。配合JetPack 5.1以上版本自带的CUDA环境llama.cpp的原生CUDA加速直接可用不折腾。我在这块板上跑过Qwen2.5-3B-Q4_K_M测试Function Calling场景单次工具调用耗时控制在1秒以内基本能满足实时决策。RK3588是另一个方向这颗SoC有6 TOPS的NPU但问题在于NPU对LLM的支持不如GPU那么通用。官方提供的RKLLM工具套件专门用来在NPU上跑LLM但支持的模型种类有限部署流程也更封闭。我的建议是在RK3588上宁可先用CPU跑哪怕速度慢一点也不要一上来就死磕NPU。CPU上跑Qwen2.5-1.5B-Q4模型速度大约8到12 token/s做轻量指令识别够用了。如果非要上NPU提前查好RKLLM的模型列表确认你选的模型在支持范围内免得白折腾。3. 端侧LLM完整部署实操从启动到接入Agent下面这部分是我实际反复操作过的流程每一步都踩过坑把它们串成一条完整链路分享给你们。3.1 第一步用Ollama在五分钟内把模型先跑起来无论你最终生产环境用什么方案第一步我都建议先用Ollama把模型跑起来先把Agent逻辑验证通了再考虑性能调优这个顺序能帮你节省大量排查时间。安装很简单Linux和macOS执行官方脚本即可。装完之后最重要的就是指定模型存储位置防止模型把系统盘塞满。我更习惯用模型路径和端口绑定来管理多设备这里有一个关键点Ollama默认只监听本机要让局域网内的设备能访问推理服务必须显式设置宿主监听。我用的启动方式是export OLLAMA_HOST0.0.0.0 ollama serve这样配置后局域网内其他设备就能通过http://设备IP:11434访问推理服务这一条对调试Agent联调非常关键不然你电脑上的Agent代码总在连本机一上真机就断连。服务起来之后拉取模型ollama pull qwen2.5:3b ollama run qwen2.5:3b这里有个判断标准如果你的设备只有4GB内存建议直接用qwen2.5:1.5b哪怕是3B量化版在重负载下也会OOM。我用Jetson Orin Nano8GB版测试过3B模型的Q4版本占用约2.5GB剩5GB后台给Agent业务逻辑刚刚好。3.2 第二步手动部署llama.cpp拿到精细控制权Ollama跑通之后要正式上生产环境我就换llama.cpp了。原因很简单Ollama为了通用性封装了不少逻辑占用内存更多而且对CPU线程、GPU层数的控制粒度不够细。llama.cpp可以做到“模型少占一份内存性能多提一截”。llama.cpp编译并不复杂在Jetson上需要确保CUDA环境可用我通常在JetPack自带的环境里直接编译带CUDA支持版本。编译配置项里最关键的是GPU计算能力参数Jetson Orin的GPU需要指定对应的架构代号否则编译出来无法调用CUDA核心。RK3588这类ARM设备我建议不要加任何GPU加速选项纯CPU版本反而更稳定。模型获取方面llama.cpp直接消费GGUF格式。大多数主流模型的GGUF版本都可以从Hugging Face上找到我习惯用Qwen2.5系列的GGUF文件。下载后放到固定目录然后用llama.cpp自带的server程序启动推理服务./llama-server -m /models/qwen2.5-3b-q4_k_m.gguf \ --host 0.0.0.0 --port 8080 \ --n-gpu-layers 999 --ctx-size 8192其中--n-gpu-layers 999的意思是尽可能多地把层放到GPU上计算--ctx-size设置上下文长度。服务启动后同样可以通过OpenAI兼容接口访问和Ollama的无缝切换度很高。3.3 第三步让Agent真正会“用工具”——Function Calling的接入这是我认为整个端侧Agent部署里最核心的一步也是最容易翻车的地方。端侧Agent和纯聊天机器人最大的区别就是它要调用工具。而工具调用依赖的是LLM输出结构化JSON的能力模型太小、量化太狠、Prompt没约束好输出就会不听话。在Ollama和llama.cpp的OpenAI兼容接口中Function Calling的用法与云端接口几乎一致构造请求体时在messages之外传入tools参数并指定tool_choice强制模型返回工具调用。实现代码大致是import requests payload { model: qwen2.5:3b, messages: [{role: user, content: 帮我把客厅空调调到26度}], tools: [{ type: function, function: { name: set_temperature, description: 设置空调温度, parameters: { type: object, properties: { temperature: {type: number} }, required: [temperature] } } }], tool_choice: auto, temperature: 0.2 } resp requests.post(http://localhost:11434/v1/chat/completions, jsonpayload)关键点在于temperature要压低我实测在0.2以下结构化输出稳定性明显提升0.7以上模型就爱“自由发挥”偶尔给你回一段自然语言而不是JSON导致下游解析直接报错。工具调用拿到结果后进行二次校验我强烈建议在Agent代码里加一个“工具参数落地前的JSON校验语义校验”环节防止模型返回了一个数值上合理但单位错误的参数这种低级错误在端侧小模型上出现的概率比我预期的高不少。3.4 第四步性能调优把端侧体验拉满调优主要围绕三件事内存占用、推理速度、并发能力。内存方面优先使用mmap方式加载模型。llama.cpp默认支持mmap内存复用机制能减少重复分配我实际对比过mmap加载方式可以让多个进程共享同一份模型内存部署多个实例时省一半内存。推理速度方面我常用的招数有三个一是调低--batch-size在CPU端侧设备上过大的batch不会提速反而增加延迟二是开启Flash AttentionJetson的CUDA环境直接支持三是把--threads设置为物理核心数而不是逻辑核心数超线程反而会因为锁竞争拖慢速度。并发能力方面端侧设备不是服务器不要指望它能拖几十路并发。我的经验是单实例并发控制为2到3即可再多就排队吧。Ollama可以直接设置OLLAMA_NUM_PARALLEL2llama.cpp则用--parallel 2。超过这个阈值token生成速度会急剧恶化延迟飙升Agent响应全线超时。4. 常见问题与排查技巧实录这部分是踩坑经验浓缩每一个都是我在真实项目中遇到并解决的按出现频率排序。4.1 服务起来但推理不动内存映射与OOM现象模型拉取成功服务启动正常但一发起推理请求进程直接退出日志里出现Killed或OOM。原因端侧设备内存紧张模型加载时没有考虑KV Cache的额外开销。比如8GB内存的设备模型占2.5GB系统本身占1.5GB剩下的空间不够KV Cache扩展进程直接被OOM Killer拎走。解决先降低--ctx-size比如从8192降到4096再选更低的量化等级。我遇到最极端的一次是在4GB内存的RK3588上跑3B模型把上下文降到2048才稳定。不要执着于模型尺寸稳定运行比“看起来厉害”更重要。4.2 输出慢得像挤牙膏每秒几个Token现象Agent的一个简单决定模型生成答案要15秒以上整条链路没法用。原因最常见的根因是模型在CPU上纯软件推理而Prompt又写得冗长Decoder阶段只能逐token生成速度天花板很低。解决三条路同时走。第一条换更小的模型第二条把Prompt潜规则化减少输入长度比如把角色设定从300字的描述压缩成20字的关键词第三条查一下是否真的用上了GPU加速。Jetson上最容易出的问题是用nvidia-smi看GPU占用是0说明模型层全部跑在CPU上当时就是--n-gpu-layers没配置完全GPU只加载了前几层。4.3 Function Calling时灵时不灵输出非法JSON现象同一个工具调用指令有时候返回正确的JSON有时候返回一段自然语言甚至返回一个空内容的对象下游解析直接抛异常。原因模型太小对JSON格式的约束能力弱量化等级低时输出token的稳定性下降temperature太高Prompt里没有给出明确的JSON输出示例。解决我的四板斧是temperature压到0.1到0.2工具描述里加上输入输出示例用tool_choice: required强制模型走工具调用而非自由对话输出解析失败时做一次重试重试时的Prompt额外附注“请严格遵守JSON格式不要输出任何解释”。这套组合拳下来成功率从80%拉到了95%以上。4.4 Agent陷入死循环连续触发错误工具调用现象Agent不断调用同一个工具每次都返回错误然后它又根据错误信息继续调用陷入死循环消耗大量token和时间。原因端侧模型对“错误恢复”的理解能力弱。云端大模型遇到空返回值可以自我修正3B小模型经常把错误信息当成正常输入反复重试。解决在Agent编排层设置工具调用的最大重试次数例如3次超过直接失败并向用户返回兜底话术。另外把工具的描述写得更精确比如“只有当传感器数值异常时才调用该工具”减少模型误触发。我在某个设备状态监控Agent里加过一道规则如果同一个工具连续报错2次强制跳过该工具并要求模型重新规划路径这样循环问题基本根除。4.5 冷启动速度和长时间运行稳定性现象设备重启后首次推理极慢运行数小时后推理速度明显下降甚至出现卡顿。原因首次推理要完成模型加载之后系统缓存逐渐被日志和Session数据占满长时间运行后显存碎片化也影响性能。解决给服务设置预加载和预热启动时后台跑一次空请求把模型常驻内存定时清理推理日志和旧会话数据在代码层面对每个会话做超时释放避免KV Cache泄漏式增长。我实测Jetson平台上加上定时释放策略后连续跑72小时性能衰退率从明显的30%降到了基本无感。写在最后的一点点实际经验端侧LLM部署这件事我做了小半年最大的体会是别把端侧当成“弱化版云端”。它的目标不是追平云端的智力水平而是在资源受限的前提下把Agent的实时性、离线可用性和可私有化部署这三点做到极致。项目启动时先选一个最小可行组合优先推荐Jetson Orin系列加Qwen2.5-3B加llama.cpp的搭配把全链路跑通再考虑优化。如果目标是RK3588这类带NPU的板子先接受CPU推理的现实把CPU路径调顺再研究NPU迁移。最后提醒一句模型效果好坏不要只看网上的跑分榜单把它接到你自己的Agent、你真实的数据、你真实的工具链里跑几天再下结论。 
长河君 · 2026/10/1 2:32:16 · 阅读 1.2k 端侧Agent本地部署LLM：从模型选型到Function Calling实战
1. 端侧Agent为什么需要一把“本地大脑”先说结论端侧Agent和端侧LLM不是打包出售的组件而是“大脑”和“身体”的关系。Agent负责拆任务、调工具、做决策LLM负责理解意图、生成文本、抽取关键信息。没有LLM的Agent本质上就是一堆硬编码的if-else条件一变就歇菜。而把LLM真正部署到设备端意味着Agent第一次具备了在离线环境下独立推理的能力。1.1 先把云端的三个老问题说清楚我最初做Agent系统时第一反应也是“大脑放云端不就行了”但实际跑了几轮之后发现三个问题会卡死你。第一个是延迟。云端推理的完整链路是设备采集数据 - 上行到服务器 - 排队推理 - 结果回传。即使网络状况良好一次往返也要300毫秒起步如果走的是公网500到800毫秒都很常见。对于需要多轮工具调用的Agent来说单轮对话就得调用三次以上LLM整个链路变成秒级响应交互体验直接崩了。第二个是成本。Token费用看着不贵但Agent场景是“高频短调用”一次简单任务可能消耗几百个token设备一多、调用一勤账单涨得比跑代码还快。我见过一个做巡检机器人项目的朋友云端API一个月烧掉四千多块就为了传几句“继续走”“左转”这种指令后来换端侧部署一次性硬件成本之后只是电费。第三个是隐私和断网。工业设备、医疗设备、家居设备很多场景数据根本不允许出设备。我接触过的几个智能门禁、健康监测项目客户直接要求“数据零上云”这种情况下云端方案在起步阶段就被否了。1.2 端侧LLM的能力边界别一厢情愿端侧LLM不是万能的。先说清楚它能干什么意图分类、槽位提取、短对话、JSON生成、代码片段理解、工具调用参数填充这些都是它的舒适区。3B到7B的量化模型配合结构化Prompt和Function Calling约束在设备上完全能担当“小助手”的角色。但它不擅长什么也很明显长文总结、复杂推理、多轮深度对话、最新知识问答。这些任务上下文太长推理太深端侧算力顶不住。所以我的经验是端侧Agent的架构不能搞“一切皆AI”而是把任务分级轻量任务交给端侧模型需要深度推理的内容再走云端补充。我自己的处理方式是加一道“路由层”先让端侧模型做一个二分类判断当前请求本地能否处理能处理就直接出结果拿不准的再向云端请求。这样既保住了离线能力又不会因为硬扛高难度任务导致响应质量崩掉。1.3 端侧Agent的典型分工方式一个务实的端侧Agent系统通常这样分工本地LLM承担语音/文本指令的意图识别工具调用的JSON参数生成设备状态信息的自然语言描述本地知识库的检索式回答简单决策链路如“电量低于20%就提醒充电并规划路线”云端LLM承担需要大量常识的开放问答多文档对比总结需要联网的实时信息查询这套分工的好处是即使完全断网Agent的“生活自理能力”依然在线。举一个我实际做过的例子一个室内配送机器人本地部署了一个3B模型用户说“帮我到A点取个东西中途如果电量低于30%就先回充电桩”。这句指令里包含意图识别取件任务、条件判断电量阈值、行为规划中途充电纯靠本地模型做到了整个决策链路跑在一个Jetson Orin Nano上延迟在500毫秒左右完全可接受。2. 端侧LLM模型选型与框架选型选型这件事最怕的是上来就问“哪个模型效果最好”。端侧场景里效果只是及格线真正决定项目成败的是“模型大小、量化等级、硬件资源、推理延迟”四个变量之间的动态平衡。2.1 模型挑法:参数量、量化、上下文一个都不能少参数量先定上限。端侧设备的存储和内存是硬约束我一般按“模型文件大小 运行时开销”来倒推。一个3B模型FP16格式大约6GB量化到Q4需要2GB左右加上KV Cache和运行时buffer整个推理要吃掉3到4GB内存。7B模型量化后也要4到5GB基本就得16GB内存的设备才跑得舒服。我日常的选择逻辑是这样的2GB以内内存余量选1.5B到3B的量化模型比如Qwen2.5-1.5B、Phi-3-mini4GB左右内存余量选3B到4B模型Qwen2.5-3B、Llama-3.2-3B8GB以上内存余量可以考虑7B到8B模型Qwen2.5-7B、Llama-3.1-8B量化等级看任务不是越低越好。我实测过Q4_K_M和Q8在意图分类任务上差距不大但在代码生成和结构化输出上Q4会出现JSON格式不那么稳定的情况。所以我的默认方案是通用对话类任务用Q4_K_M涉及结构化输出、Function Calling的任务尽量上Q5或Q6牺牲一点速度换稳定性。上下文长度决定Agent的“记性”。端侧模型受限于KV Cache上下文越长内存占用越高。8K上下文的KV Cache大约占用几百MB32K就要1GB以上。我的建议是Agent场景下4K到8K足够用了。因为端侧Agent的核心是处理当前指令而不是长文档阅读。硬上32K上下文不仅内存爆表注意力分散还会让工具调用准确率下降。2.2 推理框架怎么选Ollama、llama.cpp、MLC-LLM三选一框架选择这块我踩过不少坑最后形成了自己的判断标准。Ollama追求零门槛上线。适合快速验证、原型开发一条命令就能把模型跑起来还自动管理模型缓存和端口服务。对开发者来说它就是“本地大模型界的Docker”。网上那些“本地部署deepseek”的教程案例里用Ollama跑模型是最常见的方案这足以说明它在部署环节的易用性。Ollama暴露的OpenAI兼容接口让Agent框架接入只需改base_url几乎不用改代码。llama.cpp追求极致性能和精细控制。这是部署界的老牌框架也是GGUF格式的源头。它能精确控制GPU层数、线程数、内存映射方式对嵌入式设备友好。Jetson、树莓派、RK3588上跑模型我最终都是回到llama.cpp或者基于它的衍生方案因为Ollama有时不能细粒度地调底层参数。MLC-LLM追求利用专用硬件。它支持把模型编译到Vulkan、Metal、CUDA等后端尤其在苹果芯片和部分移动GPU上有优势。如果目标设备是手机或者带GPU的平板MLC-LLM值得研究但它的学习曲线更陡编译环节也比较折腾。我把三者的适用场景整理成了一张表方便直接对照框架适合场景启动难度性能释放典型设备Ollama原型验证、快速集成极低中家用PC、Mac、开发者板llama.cpp生产级部署、嵌入式中高Jetson、RK3588、树莓派MLC-LLM移动端GPU优化高高手机、平板、苹果芯片设备选框架不要追求新潮我的原则是设备上有CUDA就用llama.cpp求省事就用Ollama搞移动端再碰MLC。2.3 硬件适配Jetson Orin和RK3588代表了两个方向设备端部署LLM目前最具代表性的两块硬件是Jetson Orin系列和RK3588系列。Jetson Orin Nano的8GB版本是我最常用的端侧Agent开发平台。它有一个Ampere架构的GPU虽然不像桌面显卡那么强但在8GB统一内存的帮助下跑Q4量化的3B模型能达到20到30 token/s跑7B模型在10到15 token/s左右。配合JetPack 5.1以上版本自带的CUDA环境llama.cpp的原生CUDA加速直接可用不折腾。我在这块板上跑过Qwen2.5-3B-Q4_K_M测试Function Calling场景单次工具调用耗时控制在1秒以内基本能满足实时决策。RK3588是另一个方向这颗SoC有6 TOPS的NPU但问题在于NPU对LLM的支持不如GPU那么通用。官方提供的RKLLM工具套件专门用来在NPU上跑LLM但支持的模型种类有限部署流程也更封闭。我的建议是在RK3588上宁可先用CPU跑哪怕速度慢一点也不要一上来就死磕NPU。CPU上跑Qwen2.5-1.5B-Q4模型速度大约8到12 token/s做轻量指令识别够用了。如果非要上NPU提前查好RKLLM的模型列表确认你选的模型在支持范围内免得白折腾。3. 端侧LLM完整部署实操从启动到接入Agent下面这部分是我实际反复操作过的流程每一步都踩过坑把它们串成一条完整链路分享给你们。3.1 第一步用Ollama在五分钟内把模型先跑起来无论你最终生产环境用什么方案第一步我都建议先用Ollama把模型跑起来先把Agent逻辑验证通了再考虑性能调优这个顺序能帮你节省大量排查时间。安装很简单Linux和macOS执行官方脚本即可。装完之后最重要的就是指定模型存储位置防止模型把系统盘塞满。我更习惯用模型路径和端口绑定来管理多设备这里有一个关键点Ollama默认只监听本机要让局域网内的设备能访问推理服务必须显式设置宿主监听。我用的启动方式是export OLLAMA_HOST0.0.0.0 ollama serve这样配置后局域网内其他设备就能通过http://设备IP:11434访问推理服务这一条对调试Agent联调非常关键不然你电脑上的Agent代码总在连本机一上真机就断连。服务起来之后拉取模型ollama pull qwen2.5:3b ollama run qwen2.5:3b这里有个判断标准如果你的设备只有4GB内存建议直接用qwen2.5:1.5b哪怕是3B量化版在重负载下也会OOM。我用Jetson Orin Nano8GB版测试过3B模型的Q4版本占用约2.5GB剩5GB后台给Agent业务逻辑刚刚好。3.2 第二步手动部署llama.cpp拿到精细控制权Ollama跑通之后要正式上生产环境我就换llama.cpp了。原因很简单Ollama为了通用性封装了不少逻辑占用内存更多而且对CPU线程、GPU层数的控制粒度不够细。llama.cpp可以做到“模型少占一份内存性能多提一截”。llama.cpp编译并不复杂在Jetson上需要确保CUDA环境可用我通常在JetPack自带的环境里直接编译带CUDA支持版本。编译配置项里最关键的是GPU计算能力参数Jetson Orin的GPU需要指定对应的架构代号否则编译出来无法调用CUDA核心。RK3588这类ARM设备我建议不要加任何GPU加速选项纯CPU版本反而更稳定。模型获取方面llama.cpp直接消费GGUF格式。大多数主流模型的GGUF版本都可以从Hugging Face上找到我习惯用Qwen2.5系列的GGUF文件。下载后放到固定目录然后用llama.cpp自带的server程序启动推理服务./llama-server -m /models/qwen2.5-3b-q4_k_m.gguf \ --host 0.0.0.0 --port 8080 \ --n-gpu-layers 999 --ctx-size 8192其中--n-gpu-layers 999的意思是尽可能多地把层放到GPU上计算--ctx-size设置上下文长度。服务启动后同样可以通过OpenAI兼容接口访问和Ollama的无缝切换度很高。3.3 第三步让Agent真正会“用工具”——Function Calling的接入这是我认为整个端侧Agent部署里最核心的一步也是最容易翻车的地方。端侧Agent和纯聊天机器人最大的区别就是它要调用工具。而工具调用依赖的是LLM输出结构化JSON的能力模型太小、量化太狠、Prompt没约束好输出就会不听话。在Ollama和llama.cpp的OpenAI兼容接口中Function Calling的用法与云端接口几乎一致构造请求体时在messages之外传入tools参数并指定tool_choice强制模型返回工具调用。实现代码大致是import requests payload { model: qwen2.5:3b, messages: [{role: user, content: 帮我把客厅空调调到26度}], tools: [{ type: function, function: { name: set_temperature, description: 设置空调温度, parameters: { type: object, properties: { temperature: {type: number} }, required: [temperature] } } }], tool_choice: auto, temperature: 0.2 } resp requests.post(http://localhost:11434/v1/chat/completions, jsonpayload)关键点在于temperature要压低我实测在0.2以下结构化输出稳定性明显提升0.7以上模型就爱“自由发挥”偶尔给你回一段自然语言而不是JSON导致下游解析直接报错。工具调用拿到结果后进行二次校验我强烈建议在Agent代码里加一个“工具参数落地前的JSON校验语义校验”环节防止模型返回了一个数值上合理但单位错误的参数这种低级错误在端侧小模型上出现的概率比我预期的高不少。3.4 第四步性能调优把端侧体验拉满调优主要围绕三件事内存占用、推理速度、并发能力。内存方面优先使用mmap方式加载模型。llama.cpp默认支持mmap内存复用机制能减少重复分配我实际对比过mmap加载方式可以让多个进程共享同一份模型内存部署多个实例时省一半内存。推理速度方面我常用的招数有三个一是调低--batch-size在CPU端侧设备上过大的batch不会提速反而增加延迟二是开启Flash AttentionJetson的CUDA环境直接支持三是把--threads设置为物理核心数而不是逻辑核心数超线程反而会因为锁竞争拖慢速度。并发能力方面端侧设备不是服务器不要指望它能拖几十路并发。我的经验是单实例并发控制为2到3即可再多就排队吧。Ollama可以直接设置OLLAMA_NUM_PARALLEL2llama.cpp则用--parallel 2。超过这个阈值token生成速度会急剧恶化延迟飙升Agent响应全线超时。4. 常见问题与排查技巧实录这部分是踩坑经验浓缩每一个都是我在真实项目中遇到并解决的按出现频率排序。4.1 服务起来但推理不动内存映射与OOM现象模型拉取成功服务启动正常但一发起推理请求进程直接退出日志里出现Killed或OOM。原因端侧设备内存紧张模型加载时没有考虑KV Cache的额外开销。比如8GB内存的设备模型占2.5GB系统本身占1.5GB剩下的空间不够KV Cache扩展进程直接被OOM Killer拎走。解决先降低--ctx-size比如从8192降到4096再选更低的量化等级。我遇到最极端的一次是在4GB内存的RK3588上跑3B模型把上下文降到2048才稳定。不要执着于模型尺寸稳定运行比“看起来厉害”更重要。4.2 输出慢得像挤牙膏每秒几个Token现象Agent的一个简单决定模型生成答案要15秒以上整条链路没法用。原因最常见的根因是模型在CPU上纯软件推理而Prompt又写得冗长Decoder阶段只能逐token生成速度天花板很低。解决三条路同时走。第一条换更小的模型第二条把Prompt潜规则化减少输入长度比如把角色设定从300字的描述压缩成20字的关键词第三条查一下是否真的用上了GPU加速。Jetson上最容易出的问题是用nvidia-smi看GPU占用是0说明模型层全部跑在CPU上当时就是--n-gpu-layers没配置完全GPU只加载了前几层。4.3 Function Calling时灵时不灵输出非法JSON现象同一个工具调用指令有时候返回正确的JSON有时候返回一段自然语言甚至返回一个空内容的对象下游解析直接抛异常。原因模型太小对JSON格式的约束能力弱量化等级低时输出token的稳定性下降temperature太高Prompt里没有给出明确的JSON输出示例。解决我的四板斧是temperature压到0.1到0.2工具描述里加上输入输出示例用tool_choice: required强制模型走工具调用而非自由对话输出解析失败时做一次重试重试时的Prompt额外附注“请严格遵守JSON格式不要输出任何解释”。这套组合拳下来成功率从80%拉到了95%以上。4.4 Agent陷入死循环连续触发错误工具调用现象Agent不断调用同一个工具每次都返回错误然后它又根据错误信息继续调用陷入死循环消耗大量token和时间。原因端侧模型对“错误恢复”的理解能力弱。云端大模型遇到空返回值可以自我修正3B小模型经常把错误信息当成正常输入反复重试。解决在Agent编排层设置工具调用的最大重试次数例如3次超过直接失败并向用户返回兜底话术。另外把工具的描述写得更精确比如“只有当传感器数值异常时才调用该工具”减少模型误触发。我在某个设备状态监控Agent里加过一道规则如果同一个工具连续报错2次强制跳过该工具并要求模型重新规划路径这样循环问题基本根除。4.5 冷启动速度和长时间运行稳定性现象设备重启后首次推理极慢运行数小时后推理速度明显下降甚至出现卡顿。原因首次推理要完成模型加载之后系统缓存逐渐被日志和Session数据占满长时间运行后显存碎片化也影响性能。解决给服务设置预加载和预热启动时后台跑一次空请求把模型常驻内存定时清理推理日志和旧会话数据在代码层面对每个会话做超时释放避免KV Cache泄漏式增长。我实测Jetson平台上加上定时释放策略后连续跑72小时性能衰退率从明显的30%降到了基本无感。写在最后的一点点实际经验端侧LLM部署这件事我做了小半年最大的体会是别把端侧当成“弱化版云端”。它的目标不是追平云端的智力水平而是在资源受限的前提下把Agent的实时性、离线可用性和可私有化部署这三点做到极致。项目启动时先选一个最小可行组合优先推荐Jetson Orin系列加Qwen2.5-3B加llama.cpp的搭配把全链路跑通再考虑优化。如果目标是RK3588这类带NPU的板子先接受CPU推理的现实把CPU路径调顺再研究NPU迁移。最后提醒一句模型效果好坏不要只看网上的跑分榜单把它接到你自己的Agent、你真实的数据、你真实的工具链里跑几天再下结论。