端侧 Agent 现在确实是大家盯着的方向。上一篇文章我们聊了 Agent 的整体概念和端侧为什么值得做这篇直接落地讲清楚端侧 LLM 部署这件事。很多朋友一上来就卡在模型跑不起来、推理慢、显存爆掉这些问题上其实本质是对部署链路缺少全局认识。今天这篇文章就把我在 Jetson Orin、RK3588、还有普通 x86 小主机上部署端侧 LLM 的完整思路、工具选型、实测参数和踩坑记录全部摊开讲文章偏长建议先收藏再慢慢看。1. 端侧 Agent 为什么绕不开 LLM 部署这道坎1.1 先把端侧 Agent 的这副拼图摆清楚所谓的端侧 Agent简单说就是把 Agent 的“大脑”——大语言模型 LLM放到设备端运行而不是每次交互都去请求云端 API。一个完整的 Agent 至少要包含LLM 负责理解和规划工具调用负责执行动作记忆模块负责把上下文串起来。这里面 LLM 是核心没有本地模型后面讲工具、讲记忆、讲编排都是空中楼阁。所以“端侧 LLM 部署”是整个端侧 Agent 项目里最先要趟平的一段路。聊到部署大家第一反应可能是“把模型放到板子上跑起来”。这个说法对但只是最浅的一层。真实的端侧部署面对的是一连串决策选哪块硬件跑多大参数的模型用哪种量化精度选哪个推理框架模型服务怎么对外提供 APIAgent 逻辑怎么接进去并发请求怎么扛长时间运行会不会过热。这些环节是环环相扣的模型选大了硬件跑不动量化太狠效果崩了推理框架不支持目标平台又得推倒重来。所以这篇文章不是单纯给一条命令让你把模型跑起来而是给一套决策方法。1.2 为什么一定要本地跑推理从场景反推需求很多人问既然云端有很强的模型为什么还要在端侧折腾这个问题反过来看更合适——先看你的 Agent 用在哪里再决定要不要端侧。我实际做过的一个项目是巡检机器人端侧的故障问答助手现场网络经常断数据又不能出设备这时候云端 API 直接不可用。端侧部署是唯一解。再比如你做个人知识库助手家庭环境里不太可能天天开着服务器一台 NUC 或者 RK3588 开发板把模型塞进去24 小时待命比依赖云端 API 更省心也更隐私。从数据安全、隐私保护、离线可用、低成本、低延迟五个维度来看端侧 LLM 有不可替代的优势。尤其是延迟云端一次调用往返至少几百毫秒端侧首 token 控制在几十毫秒内是可以做到的。对交互式的 Agent 来说这个体感差距是质的飞跃。当然端侧也有明显的劣势比如模型参数量受限导致智力上限不如云端大模型上下文窗口不够大复杂工具调用容易翻车。所以实际选型往往不是非此即彼而是端侧模型处理敏感数据和基础交互敏感度低的高难度任务才走云端。这也是现在比较主流的“端云协同”思路。1.3 我在这篇文章里想讲清楚什么这篇文章假设你已经具备基础的 Linux 操作能力知道 Docker、命令行是怎么回事。核心目标只有一个在你自己手上的端侧设备上把一个大语言模型稳定地跑起来并提供可供 Agent 调用的 API。我不会只给结论会把每个选择背后的理由、参数怎么算、坑在哪里都讲明白因为你下次换硬件、换模型还是得靠自己来做这些决策。2. 部署前的三件大事硬件、模型和工具链2.1 硬件平台怎么选算力、内存带宽与功耗的三角博弈选硬件的时候大家习惯性地盯着“多少 TOPS 算力”这是第一个误区。对于 LLM 推理来说内存带宽往往比峰值算力更重要。因为 LLM 是内存密集型任务推理过程要不断读取模型权重权重在显存里搬来搬去带宽越大token 生成速度才越快。我实测过的几块板子差距就在这里拉开。这里做个简单的理论估算模型权重大小为 W比如 7B 模型 Q4_K_M 量化后约 4.5GB端侧平台有效内存带宽为 B单位 GB/s那么理想情况下推理吞吐的极限大约是 B / W。注意这是理想值实际还要算上 KV Cache 读写和系统开销。Jetson Orin Nano 的 LPDDR5 带宽约 68GB/s理论能支撑 7B Q4 模型跑到 15 token/s 附近实测确实差不多RK3588 的内存带宽大概在 20GB/s 上下跑同一个模型就只能到 3-5 token/s 了这个差距和实际体验完全吻合。所以选硬件先查内存带宽再算算能不能满足你的最低 token 速率这个顺序别搞反。对于主流端侧 Agent 项目我给个个人建议优先级预算充足、要跑 7B-13B 模型NVIDIA Jetson Orin NX 16GB 或 Orin AGX 64GB生态最成熟。预算敏感、跑 1.5B-3B 模型为主RK3588 开发板比如香橙派 5 Plus、Radxa Rock 5B性价比极高但推理速度只能算“能用”。手头有普通 x86 小主机或笔记本也可以核显或 CPU 跑 3B-7B 量化模型完全可行胜在内存可以堆到 32GB。手机端的骁龙 8 系列、天玑 9000用 MLC-LLM 这类框架也能跑 3B-7B但Android 碎片化问题太多建议后置。另外功耗和散热也不要忽视。Jetson Orin NX 满载约 25WRK3588 也能摸到 10W。板子长时间跑推理散热片不够大就会撞温度墙降频速度直接腰斩。我第一次在 RK3588 上跑模型没加风扇跑了十分钟温度飙到 85℃token 速度掉了一半不止这个问题后面细说。2.2 模型选型参数量、量化与上下文窗口的权衡硬件定了模型就是第二个关键决策。端侧模型的选型核心是三个参数参数量、量化精度、上下文长度。参数量上现在端侧可选的范围很宽。以我个人经验做参考1B 量级Qwen2.5-1.5B、Llama-3.2-1B逻辑简单适合做意图识别、实体抽取这类辅助任务。3B-4B 量级Qwen2.5-3B、Phi-3-mini、MiniCPM-3B总体均衡能处理简单对话和工具调用是当前端侧 Agent 的甜点区。7B-14B 量级Qwen2.5-7B、DeepSeek-R1-Distill-Qwen-7B需要专门的硬件Orin 级别以上推理速度偏慢但智能度明显上一个台阶。量化精度上最常见的是 GGUF 格式的 Q4_K_M。4bit 量化能把 7B 模型压缩到 4.5GB 左右相对于原始 fp16 的 14GB 省下近七成内存而质量损失在多数任务上是可以接受的。实际项目里我最常用的就是 Q4_K_M如果模型版本更新、对质量要求高也可以上 Q5_K_M但内存占用会多出 10%-15%。Q8_0 几乎是无损量化但端侧内存紧张时通常不舍得用。上下文窗口也要提前想清楚。Agent 交互往往需要携带系统提示词、历史对话、工具返回结果这些都要吃上下文。Qwen2.5 模型支持 32K 上下文但端侧内存有限实际运行中我会限制为 4K-8K 的上下文长度既保证内存可控也让推理速度不至于被长长的 prompt 拖垮。上下文越长每轮请求要处理的前缀就越多首 token 时延线性增长这个账要算清楚。2.3 工具链llama.cpp、Ollama、RKLLM 与 TensorRT-LLM 的取舍工具链这块是端侧部署中最容易踩坑的地方因为不是所有框架都支持所有硬件。我实测下来基本盘是这几套。llama.cpp 是当之无愧的通用底座。它支持 GGUF 格式模型CPU 和 NVIDIA GPU 都能跑社区更新快新模型出来很快就能适配。绝大多数端侧平台上llama.cpp 都能编译运行包括 Jetson 的 aarch64 Linux 环境。llama.cpp 自带 llama-server提供一个 OpenAI 兼容的 HTTP APIAgent 调用起来非常顺手。Ollama 属于开箱即用的高层封装。它把模型下载、量化、API 服务都统一了一行命令就能拉模型、启动服务底层还是 llama.cpp。在 Jetson 上可以直接安装RK3588 上目前没有官方支持需要凑合跑 llama.cpp 或等社区适配。Ollama 胜在省心适合快速验证方案。RKLLM 是瑞芯微官方工具链专门针对 RK3588 的 NPU 做优化。它的坑在于模型转换流程比较繁复得在 PC 上用 rkllm-toolkit 把模型捣腾成 rkllm 格式然后板子上用 rkllm-runtime 调用。NPU 推理的好处是 CPU 占用低但 RK3588 的 NPU 对算子支持有限精度和速度都不一定能全胜 CPU 混跑。我最终是用 llama.cpp 的 CPU 模式跑通主链路NPU 后面再单独研究。TensorRT-LLM 是 NVIDIA 在 Jetson 和服务器上力推的高性能方案但它对模型格式要求严格转换流程复杂端侧 Agent 项目里我很少一开始就上除非你确实需要榨干 Orin 的每一点性能。对绝大多数项目Jetson 先用 llama.cpp 或 Ollama 足够了性能已经有保障。关于部署形态Docker 也是一个常见选择。Jetson 的 JetPack 环境里可以直接跑dustynv这类现成的镜像里面打包了 PyTorch、CUDA 甚至 ollama省去很多环境折腾的功夫。RK3588 上 Docker 跑 llama.cpp 也没问题镜像选 arm64 架构的就行。docker 的好处是环境隔离、换板子不用重新折腾环境坏处是 GPU/NPU 设备映射偶尔出问题做原型阶段可以生产环境我更倾向直接用系统裸装的方式部署。3. 实操从零把一个 LLM 服务跑起来3.1 通用四步拉模型、搭服务、验证 API、接入 Agent不管目标平台是 x86 小主机还是 Jetson 开发板通用的部署路径都是下面四步。先以一台普通 x86 Ubuntu 机器为例用 Ollama 最省事第一步安装 Ollama。官方命令一行搞定curl -fsSL https://ollama.com/install.sh | sh这里有个小细节默认 Ollama 只在本地监听 127.0.0.1如果你要让同一局域网内的 Agent 设备比如手机或另一台开发板访问需要修改 systemd 服务里的环境变量。通常在/etc/systemd/system/ollama.service里加一行EnvironmentOLLAMA_HOST0.0.0.0:11434然后重启服务这样才能把模型服务暴露给网络里的其他设备。第二步拉模型。这里我建议从 3B 起步ollama pull qwen2.5:3bollama pull的时候你会看到模型分块下载注意 Ollama 拉取的是已经量化过的 GGUF不用自己操心转换。其他值得试的模型还有phi3:mini、llama3.2:1b、deepseek-r1:1.5b。对 Agent 场景建议重点看带工具调用能力的模型比如qwen2.5系列官方就支持 function calling。第三步启动并验证 API。Ollama 启动后默认在 11434 端口提供 API用 curl 测试curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:3b, messages: [{role: user, content: 用一句话介绍你自己}] }返回的 JSON 里choices[0].message.content就是模型回复。这个 API 是 OpenAI 兼容的所以很多 Agent 框架比如 LangChain、LlamaIndex、Dify 甚至自研的 Agent SDK只需要把 base_url 改成http://localhost:11434/v1就能接上。第四步接入 Agent 框架。这一步我放在后面专门讲。但核心逻辑就是Agent 的“思考循环”每一次要调用 LLM 做推理不需要直接操作本地模型而是请求刚才启动的 HTTP API。模型是一个独立服务Agent 是一个独立进程解耦之后你随时可以替换底层模型而不需要改动 Agent 代码。3.2 更底层的玩法llama.cpp 手工部署的完整步骤Ollama 虽然方便但如果你想在 RK3588 这类没有官方支持的平台跑模型或者想控制每个细节就得手工上 llama.cpp。这条路我走了很多遍步骤也不难。环境准备只需要一个 C 编译器和 CMake。以 ARM 开发板为例git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build cd build cmake .. -DGGML_NATIVEON make -j$(nproc)如果板子是 Jetson有 NVIDIA GPUcmake 加上 CUDA 支持cmake .. -DGGML_CUDAON编译完成之后需要一个 GGUF 格式的模型文件。要么直接去 HuggingFace 下载现成的 GGUF比如搜索qwen2.5-3b-gguf要么从原始模型权重自己转换python3 -m pip install -r requirements.txt python3 convert_hf_to_gguf.py /path/to/qwen2.5-3b-hf --outfile qwen2.5-3b.Q4_K_M.gguf --outtype q4_k_m转换要在存储空间充足的机器上做原始 fp16 权重加上转换后的 GGUF 得准备好大约 10GB 空间。模型准备好了启动服务./bin/llama-server -m ../models/qwen2.5-3b.Q4_K_M.gguf \ --host 0.0.0.0 \ --port 8080 \ --n-gpu-layers 0 \ --ctx-size 4096--n-gpu-layers在 Jetson 上可以设成 99 表示全部层都丢给 GPU在 RK3588 上没 GPU 加速留 0 就是纯 CPU 推理。--ctx-size控制上下文长度我一般先按 4096 跑通再细调。注意这个参数直接吃内存4096 的 KV Cache 大概占用 300MB-600MB对 8GB 内存板子影响不小。启动之后同样用 curl 验证 APIllama-server 提供的/v1/chat/completions和 OpenAI 格式完全兼容用法和上面 Ollama 示例一致只是端口变成了 8080。3.3 Jetson Orin 部署从 JetPack 到 Ollama 的完整链路Jetson 平台相比 RK3588 有个大优势——NVIDIA 官方生态踩坑少。以 Jetson Orin NX 16GB 为例部署路径是这样的。先准备 JetPack SDK推荐安装 JetPack 5.1 以上版本里面自带 CUDA、cuDNN、TensorRT。JetPack 6 的更新比较大如果用的是 Orin Nano/NX建议先查一下你手上的模块是否在官方支持列表里避免装上之后驱动不匹配。系统部署完成后安装 Ollama 也简单官方 install 脚本在 aarch64 上直接可用或者下载.deb包手动安装。然后拉一个适合 Orin 的模型。Orin NX 16GB 的内存带宽摆在那里跑 7B Q4 完全可行实测速度可观这也是 Orin 相比 RK3588 最明显的地方。命令和前面一模一样ollama pull qwen2.5:7b ollama run qwen2.5:7bOllama 在 Jetson 上默认会尝试用 CUDA 后端底层是 CUDA 加速的 llama.cpp效果和裸装 llama.cpp 没本质区别但省了编译时间。对性能有极致追求的人还是建议手工编译 llama.cpp可以针对 Jetson 的算力参数做静态编译优化。3.4 Jetson 上 TensorRT-LLM 的进阶尝试如果你要在 Orin 上把模型性能榨干TensorRT-LLM 是绕不开的方向。它相比 llama.cpp 的优势在于模型编译成 TensorRT Engine算子级优化支持 FP8/INT8 量化对显存和带宽的利用更充分。缺点是模型转换流程复杂。TensorRT-LLM 在 Jetson 上的部署需要先安装对应版本的 JetPack然后通过 pip 安装trt-llm再从 HuggingFace 下载原始模型权重最后用convert_checkpoint.py转出 TensorRT Engine。实测对比数据可以参考在 Orin NX 16GB 上跑 Qwen2.5-7Bllama.cpp 的吞吐大约 15-25 token/sTensorRT-LLM 在相同量化下往往能高出 30%-50%但首次转换时间动辄几十分钟而且换一个模型文件就要重新完整转换一遍迭代成本很高。我的建议是原型阶段先用 Ollama 或 llama.cpp 跑通流程确定要上生产环境后再花时间折腾 TensorRT-LLM别一上来就陷入转换泥潭。3.5 RK3588 部署CPU 都跑起来了NPU 是个大坑RK3588 是这一两年最火的端侧板子之一。它的卖点是性能不错、价格便宜、接口全。但跑 LLM 的真实体验要打个折扣。我推荐先在 RK3588 上做好环境预判CPU 是 4 个 A76 大核 4 个 A55 小核GPU 是 Mali-G610NPU 号称 6 TOPS。实际跑 LLM 最靠谱的还是 CPU。先安装基础依赖然后在 RK3588 上编译 llama.cpp。命令和通用步骤一样注意 RK3588 是 aarch64 架构CMake 编译时建议启用 ARM 特性优化cmake .. -DGGML_NATIVEON make -j6模型选择上RK3588 的 16GB 内存版跑 7B Q4 理论放得下但实际推理速度只有 2-4 token/s交互体验比较差基本只能用来验证。真正可用的甜点区是 1.5B-3B 模型Q4_K_M 量化后 1-2GB 内存能跑到 8-15 token/s对话场景勉强够用。CPU 推理跑通之后RK3588 的 NPU 就不得不提了。瑞芯微官方有 RKLLM 工具链可以在 PC 上把模型转换成.rkllm格式板子上跑rkllm_server提供 HTTP 服务。听起来美好实际坑不少第一官方工具链支持的模型很少HuggingFace 上热门模型不一定在列表里第二NPU 对多头注意力的支持可能不完整转换后可能会因为算子不受支持而失败第三NPU 推理的真实速度受限于内存带宽和 NPU 与 CPU 之间的数据搬运未必比 CPU 快多少。我的建议是如果只是做功能验证用 CPU 模式跑 llama.cpp如果你有足够的时间去折腾 RKLLM就去研究它分享经验出来绝对有价值。3.6 端侧 Agent 接入 LLM 的 API 层设计模型服务跑起来只是第一步Agent 怎么接才见真功夫。我习惯的做法是统一抽象一层 LLM Gateway把本地模型、云端模型都封装成同一个接口Agent 业务代码只面向这个抽象接口编程模型在背后怎么换都无所谓。用 FastAPI 写一个代理几百行代码搞定from fastapi import FastAPI import aiohttp app FastAPI() # 本地 Ollama / llama-server 的地址 LOCAL_LLM_URL http://127.0.0.1:11434/v1/chat/completions app.post(/v1/chat/completions) async def chat_completion(payload: dict): async with aiohttp.ClientSession() as session: async with session.post(LOCAL_LLM_URL, jsonpayload) as resp: return await resp.json()这层网关的价值在于你可以做请求路由普通问题走本地复杂问题转发云端、限流控制、Token 计费统计也可以统一做 Prompt 模板管理。对 Agent 开发来说这层抽象能避免你的 Agent 代码和具体推理框架耦合后面换模型的时候只改配置不改逻辑。4. 性能调优把端侧模型的每一分潜力榨出来4.1 量化精度的选择不只是 q4 还是 q8 的问题量化是端侧部署里最关键的决策点选错一步要么内存爆掉要么效果一塌糊涂。我踩过的坑可以总结成几个原则。第一个原则是优先看内存预算。先确定你的 Worker 是哪个硬件内存多大能分给模型多少。比如 Jetson Orin NX 16GB系统占掉 3-4GBKV Cache 占 1-2GB剩下可用内存约 10-11GB那 14B 模型即便是 Q4 量化约 8.5GB也放得下但 7B 用 Q8_0约 7.5GB就不剩多少空间了反而要去设置更小的上下文。所以实际选择不能孤立地看量化档位要综合内存、上下文、并发三者去算。第二个原则是效果优先时选尽量高的量化档位速度优先时选 Q4。在我项目里的实测Q4_K_M 和 Q5_K_M 的指标差距并不大但 Q4 模型的回复偶尔会“偷懒”出现重复短语或者逻辑断线如果目标是做 Agent 的工具调用建议至少 Q5_K_M因为工具调用的 JSON 输出对模型准确性要求高低精度量化很容易出现括号不闭合、字段名写错这种低级故障。4.2 上下文长度、KV Cache 和内存的真实关系很多人忽略 KV Cache 对内存的影响。它的大小跟模型层数、注意力头数、上下文长度成正比并且实际使用的时候是动态增长。比如 Qwen2.5-3B 在 4K 上下文下KV Cache 大约占 500MB拉到 32K直接就多占 3-4GB。端侧板子本来内存就不充裕这个占用往往比模型文件本身还大所以一定要预留。在 llama.cpp 和 Ollama 的参数配置里ctx-size就是给模型设定的最大上下文长度建议从 2048 起步调试。如果是纯对话 Agent历史消息也不多2048 完全够如果要喂长文本 RAG那就要权衡内存和性能。我的一个优化方案是给 Agent 做“滚动窗口”只把最近几轮对话和检索片段拼进 prompt而不是无限堆历史这样既省上下文也让模型的思考更专注。4.3 吞吐、延迟与并发端侧模型离生产还有多远端侧模型的单请求延迟和吞吐测试我建议至少关注三个指标首 token 延迟TTFT、生成吞吐token/s、并发下的稳定性。不同的 Agent 场景对指标的需求完全不同语音助手类要求 TTFT 低因为用户等不了 1 秒批量文本生成类要求吞吐高每多 1 token/s 就意味着省时间多设备共用一套模型服务则要求并发稳定一个慢请求不能拖垮整条链路。我实测的一组典型数据如下可以给各位一个体感参考设备模型量化内存占用生成速度Jetson Orin NX 16GBQwen2.5-7BQ4_K_M约 6GB18-28 token/sJetson Orin Nano 8GBQwen2.5-3BQ4_K_M约 3GB15-22 token/sRK3588 16GBQwen2.5-3BQ4_K_M约 3GB8-12 token/sRK3588 16GBQwen2.5-1.5BQ4_K_M约 1.8GB15-18 token/sx86 i5 笔记本Llama-3.2-3BQ4_K_M约 2.8GB10-16 token/s注意这些数据是单请求顺序生成的指标并发多路请求时每个请求的实际吞吐都会下降。Ollama 和 llama-server 默认是单并发处理的也就是说一个请求生成完才处理下一个多路并发其实是被串行排队了。如果 Agent 场景里会有多个设备同时请求要么加一个简单的请求队列要么换用支持并发的服务端实现但并发上来之后内存占用会线性增加板子很可能撑不住。所以端侧模型的定位还是“小并发、低延迟”真要扛大并发还是得靠服务器集群。4.4 功耗、散热与七天连续运行的稳定性端侧部署里最容易被低估的是散热和稳定性。Jetson Orin 满载功耗约 15-40W发热集中在 SoC 附近不加风扇或主动散热温度到 80℃ 就会触发降频推理速度直接打七折。我的 Jetson 放在一个 30 元的小铝散热壳 涡轮风扇里裸板测试和带散热跑同一个模型速度差距能到 40% 以上。RK3588 也一样第一次跑 7B CPU 推理无风扇 10 分钟就过热装上散热片之后才稳定下来。长时间运行还有两个隐性坑。一是内存泄漏累积llama.cpp 如果长时间高频调用VMA 占用会缓慢增长建议给服务工作线程设置每日自动重启的定时任务。二是系统日志和模型日志会吃满存储尤其是 Jetson默认系统日志轮转策略不够激进跑一周之后/var/log可能膨胀到 GB 级别提前配好 logrotate 是省心关键。这些细节普通教程不会提但实际运维中都是决定成败的点。5. 常见问题与排查技巧把踩过的坑一次性倒给你5.1 模型加载阶段的高频故障速查以下是我在实际部署过程中遇到的最多、最典型的问题整理成速查表建议收藏备查问题现象可能原因解决方法failed to allocate memory或 OOM模型与 KV Cache 占用超过设备内存降低量化档位减小--ctx-size或换更小模型加载时半路崩溃、Segmentation faultGGUF 文件下载不完整或架构不匹配用ollama pull重新拉取或核对模型架构参数服务起来之后 curl 无响应端口监听地址是 127.0.0.1检查启动参数改成--host 0.0.0.0RK3588 编译 llama.cpp 报Illegal instruction编译时启用了板子不支持的 CPU 指令集用-DGGML_NATIVEOFF重新编译Jetson 上 Ollama 拉模型特别慢默认模型仓库网络限速设置镜像源或使用hf-mirror等国内加速渠道下载 GGUF 后手工导入模型回复全部乱码或空串模板格式不匹配或量化精度过低确认 Chat Template 参数切换到 Q8_0 试跑一次做对比5.2 推理阶段性能问题的排查思路如果模型能加载但速度很慢先不要急着怀疑硬件。第一件事看系统资源用htop看 CPU/内存占用用sudo jetson_clocksJetson看频率是否被锁在低档。第二件事看推理日志llama.cpp 启动时会输出load time、eval time、prompt eval等信息如果 prompt eval 特别慢说明 prompt 太长可以压缩提示词或减少历史消息如果 token eval 慢但 CPU 没吃满很可能是内存带宽瓶颈换更小的量化或更小的模型。一个我经常忽略的细节是模型文件存放位置。如果 GGUF 存放在速度慢的 SD 卡上加载阶段会慢得让人怀疑人生实测从 USB3.0 固态和 TF 卡加载同一个 3B 模型加载时间差距能到 10 倍以上。所以模型文件一定放在 SSD 或高速存储里对长时间稳定运行也有帮助。5.3 Agent 与 LLM 集成时的特有坑位Agent 场景里通常不只是简单聊天问答而是高频调用。这时常见的问题包括工具调用的 JSON 输出偶尔不合法导致 Agent 流程中断。我的对策是在系统提示词里给出严格的 JSON 示例格式同时在代码里做好容错解析失败时让模型重试一次而不是直接报错。另外一个问题是上下文窗口被工具返回结果撑爆。比如一个搜索工具返回了一大段网页内容直接拼进对话里上下文长度瞬间涨到几千 token后面的推理就变慢甚至 OOM。解决方法是工具返回结果做截断或摘要后再拼入上下文保留关键信息丢弃无关文本。还有一点值得单独说就是模型的知识储备和幻觉问题。端侧小模型参数少知识截止时间早面对实时信息经常一本正经地胡说八道。Agent 设计时就要默认“模型不知道”对需要准确数据的问题强制走工具调用不要指望模型凭记忆回答。6. 从 LLM 部署到真正端侧 Agent 的进阶拼图6.1 端侧模型服务之外的 Agent 能力组件模型服务跑通只是地基完整的端侧 Agent 还需要三层能力。第一层是感知层处理用户输入可以是文本、语音需要本地 ASR、视觉比如摄像头画面理解RK3588 跑 YOLOv8 这类视觉模型也完全可以NPU 这时候反而很有用。第二层是推理与决策层也就是 LLM 本身负责根据感知结果规划动作。第三层是行动层比如调度传感器、控制 GPIO、调用外部 API、操作数据库。每一层都要通过工具调用的形式接到 Agent 的核心循环里。以我实际做过的一个项目为例Jetson Orin 上跑 Qwen2.5-3B 作为主 Agent接入了温度传感器工具、语音合成工具、日程查询工具。用户说“帮我查一下下午三点的日程并提醒我”Agent 先生成工具调用请求LLM 输出{tool: query_calendar, params: {time: 15:00}}本地代码执行工具后把结果拼回上下文再生成面向用户的自然语言回复。整套链路的延迟主要消耗在 LLM 推理上3B 模型大概 300-600ms 一轮交互体验完全可接受。6.2 RAG 和知识库怎么在端侧落地RAG 是端侧 Agent 最容易出效果的方向。把本地文档向量化之后存进向量库用户提问时先做相似度检索把检索结果拼进 prompt再让 LLM 根据上下文回答。端侧跑 RAG 的瓶颈不是向量检索而是 embedding 模型和 LLM 都要占内存。实测 3B LLM 0.5B embedding 模型整体内存占用约 4GB8GB 板子上还能跑起来16GB 板子就很宽裕了。向量检索本身推荐用轻量级的库比如sqlite-vss、chromadb的本地模式或者干脆自己用 numpy 做余弦相似度计算。端侧文档量一般不大几千条片段全量扫描也就几十毫秒没必要上重型的向量数据库。这项能力和标题里提到的 LLM Wiki 思路是一脉相承的把领域知识组织成本体Ontology工具负责检索LLM 负责生成端侧模型在知识问答场景中就能弥补参数量的劣势。6.3 端云协同才是端侧 Agent 的正解最后说说我的整体判断。端侧 LLM 部署不是要替代云端大模型而是把两者组合起来使用。端侧模型负责高隐私、低延迟、交互频繁的基础任务复杂推理、创意写作、深度规划这类高难度任务由端侧 Agent 判断后转发给云端模型处理。这种端云协同架构在代码层面只需要调整 LLM Gateway 的路由策略而 Agent 业务本身不动。我的一个实践建议是配置路由阈值任务难度低走端侧难度高走云端。具体判断可以用一个小模型做 intent classification也可以用规则匹配比如检测到“帮我写一篇 2000 字的方案”这种长文生成需求就直接转云端。整个端侧 Agent 才能真正具备复杂任务能力。6.4 从部署走向产品化稳定性、可观测性和更新机制最后提一句向产品化演进的方向。LLM 服务跑起来只是技术验证要把它变成一个稳定产品还得补三件事监控、日志、更新。监控方面至少要做到看得到模型推理延迟、吞吐、内存占用和温度这几个核心指标出了异常能及时报警。日志方面把每次请求的 prompt 和 response 存下来特别是 Agent 场景下的工具调用记录这是事后排查问题最重要的依据。更新方面模型文件和推理框架都在快速迭代预留好平滑升级的路径比如用 Ollama 的模型 tag 管理或者把 GGUF 文件放在统一目录下用软链接指向当前版本避免升级时服务中断。写在最后回头看我自己的部署经历踩过最大的坑不是技术细节而是“想一步到位”。最开始总想一口气在板子上跑一个大模型结果被内存、性能、兼容性反复折磨。后来换了思路先用小模型把链路跑通再逐步优化选型反而更快进入正轨。端侧 LLM 部署这件事慢即是快先把最小的闭环转起来再一步步加码。这篇文章写到的硬件选型、量化思路、工具链对比、调优技巧都是我实测过一遍之后沉淀下来的经验希望能帮你少走弯路。下一篇我会继续聊端侧 Agent 里面的工具调用与记忆管理这一篇没讲透的内容咱们下一篇接着掰扯。