1. 端侧 Agent 为什么非要在本地跑 LLM1.1 端侧 Agent 的工作链路先把概念对齐一下。Agent 不是单个模型而是一套“感知—决策—行动”的闭环系统。放在端侧手机、机器人、车载盒子、边缘工控机上这套链路通常长这样摄像头/麦克风/传感器负责感知把图像、音频、文本转成结构化输入中间那颗 LLM 负责理解和决策比如理解“帮我把客厅灯调暗”这句话并拆解成动作序列最后再通过 API 或本地总线把指令发出去控制设备执行。所以 LLM 在这个链路里的角色相当于人的“大脑皮层”——所有感知数据最终都要汇聚到这里做语义理解和规划。如果这颗大脑放在云端那就意味着设备上每个交互动作都要把数据传到远程服务器再等结果回来。延迟、隐私、断网、成本四个问题会同时压过来。这也是为什么现在做端侧 Agent 的项目几乎都绕不开一个核心课题在算力有限的设备上把 LLM 跑起来而且要跑得能看。1.2 三条硬理由延迟、隐私、成本先说延迟。人对话的自然节奏是几百毫秒以内有反馈超过两秒人就会觉得“卡”。云端方案即使在 5G 网络下一次完整请求也要经历“上行传输—排队推理—下行回传”三个环节实测最理想也要 800ms 到 1.5s。而用本地模型7B 参数量级在 Jetson Orin 或者带 NPU 的 RK3588 上稳定做到 15~30 token/s首 token 延迟可以压到 300ms 以内。这个差距在语音交互场景里体感是“能直接聊”和“像对讲机”的区别。再说隐私。端侧 Agent 要处理的往往是设备本地的数据——通讯记录、相册、传感器数据、家中摄像头画面。这些数据一旦出了设备哪怕走了加密通道合规风险和用户心理门槛都是真实存在的。很多实际项目里客户明确要求“数据不许出园区”这时候本地部署不是可选项是硬性条件。第三是成本。云端 API 按 token 计费看起来一次几厘钱不贵但如果 Agent 是常驻的——比如车载助手每次启动都要做上下文摘要、智能终端每隔几分钟跑一次意图识别——累积账单会非常可观。自己部署本地模型一次性购买硬件之后边际成本几乎为零。尤其团队在做 PoC 阶段调接口调试模型的时候本地部署能省掉大量测试费用。1.3 什么场景适合端侧什么场景别硬上端侧 LLM 不是万能的得承认它的边界。我自己的判断标准很简单任务中如果 80% 是“识别、提取、语义匹配”这类结构化操作适合端侧如果 80% 是“复杂推理、创意生成、长程规划”老老实实接云端大模型。比如设备端的指令理解、槽位抽取、意图分类、敏感信息过滤这些小模型完全能胜任但你要 Agent 写一篇文章、做一个方案、推理一道复杂数学题端侧 7B 模型确实吃力。另外多模态场景要单独评估——视觉编码器会占掉不少内存带宽如果任务既要有视觉又要长上下文现阶段建议把基础识别放到专用小模型比如 YOLOv8LLM 专注做意图决策。2. 硬件选型先把显存和算力账算明白2.1 部署前必做的内存预算我在不少项目里看到过同一个问题模型选好了硬件买了一跑就 OOM。根子上是没提前算内存账。这里分享一个经验公式适配大多数 transformer 架构的 LLM模型权重显存 ≈ 参数量( B ) × 每参数字节数推理峰值内存 ≈ 权重显存 × 1.6~2.0多出来的部分给 KV cache、激活值和临时张量以 7B 模型用 Q4_K_M 量化为例每参数约 0.6 字节4bit 权重加少量 overhead权重约 4.2GB。但实际跑推理时如果上下文窗口开到 4096KV cache 还要额外占 1~2GB加上推理中间变量建议至少留出 8GB 可用内存。所以 Jetson Orin Nano 8GB 版本跑 7B 量化模型属于“卡着边用”想舒服一点就上 16GB 版本或者 Orin NX 16GB。13B 模型 Q4 量化权重约 8GB那就必须 16GB 起步而且上下文窗口不能开太大。2.2 主流端侧硬件横评硬件平台内存算力适配模型规模优势主要坑Jetson Orin Nano 8GB8GB LPDDR5约 40 TOPSINT81.5B~7BQ4CUDA 生态成熟兼容 llama.cpp 全套工具链8GB 跑 7B 上下文窗口受限Jetson Orin NX 16GB16GB LPDDR5约 100 TOPS7B~13BQ4性能强能跑视觉模型价格高功耗约 15~25WRK358816GB 版本16GB LPDDR4XNPU 6 TOPS CPU 8核1.5B~7B需特定工具链价格便宜NPU 功耗低需用 RKLLM 工具链不支持常见 GGUF 直接复用树莓派 58GB8GB约 0.7 TOPS1.5B~3BQ4生态友好适合原型验证算力太弱7B 跑起来只有 1~3 token/s选型这块我的核心建议是不要只看 TOPS要看“生态成熟度”和“社区踩坑数量”。Jetson 系列因为沿袭 CUDAllama.cpp 和 Ollama 对它的支持最完善很多问题搜得到答案。RK3588 的优势是便宜且能效比高但 NPU 工具链相对封闭YOLOv8 这类模型部署已经有成熟方案LLM 部署则需要厂家专门适配的 RKLLM 工具包GGUF 模型需要转换后才能在 NPU 上跑工作量多出不少。2.3 从业务场景反推硬件配置具体选哪块板子建议从业务场景反推如果做的是车载/机器人需要连续行进中推理建议 Jetson Orin NX 16GB性能余量足掉帧和卡顿容忍度高。如果做的是智能家居中枢设备固定、功耗敏感RK3588 更合适NPU 在跑视觉任务时功耗控制出色。如果只是原型验证先拿树莓派或者你的 Mac 笔记本跑通逻辑再考虑换目标硬件。千万不要一上来就买高配板子——模型跑不通、Agent 链路没走顺之前硬件就是吃灰。另外提一个容易被忽略的点电源和散热。Jetson Orin 满载时发热明显如果装在密闭壳子里拷机 20 分钟就会降频。我做过一个项目因为散热没做好推理速度从 25 token/s 掉到 8 token/s排查了半天才发现是温度墙。所以选硬件时把散热方案的预算一并算进去工业级场景直接买带主动散热的载板。3. 模型选型与量化别把 7B 模型看成“缩小版 GPT”3.1 模型规模怎么定7B、3B 还是 1.5B部署之前先想清楚一个事情端侧模型承担的任务边界在哪里。我的经验是——能用 3B 解决的不要用 7B能用 1.5B 解决的不要用 3B。推理速度、内存占用、功耗、散热全部跟模型规模正相关。1.5B~3B 模型适合做简单意图分类、指令槽位提取、闲聊回复7B 模型适合做需要一定推理能力的任务编排、多步指令理解超过 13B 的模型在端侧跑现阶段基本属于自虐。实测下来中文场景里目前很值得试的模型包括Qwen2.5 系列有 0.5B/1.5B/3B/7B 多档中文能力强、DeepSeek 蒸馏版7B 级别在推理任务上表现超出同尺寸平均水平、Llama 3.2 3B偏英文但通用能力强。如果跑 DeepSeek 本地部署7B 蒸馏版在 Jetson Orin NX 上 Q4 量化后大概 28 token/s能用3B 版能到 60 token/s响应几乎无感。3.2 量化方案Q4_K_M 几乎是默认答案量化这个东西很多新手容易把它理解成“模型压缩后变差了”。实际上对于 7B 级别的模型从 FP16 量化到 Q4 后智力下降非常有限——实测在中文意图理解和指令跟随任务上准确率差距在 2%~5% 以内但内存占用和推理速度提升是肉眼可见的。我的经验Q4_K_M 是性价比最高的量化档位。量化档位每参数字节7B 权重占用推理速度相对 FP16适用场景Q8_01.06约 7.4GB约 1.2 倍内存充足追求较高精度Q5_K_M0.72约 5GB约 1.5 倍精度与体积平衡Q4_K_M0.58约 4.1GB约 1.8 倍端侧首选兼顾质量与体积Q3_K_M0.47约 3.3GB约 2 倍实在内存不够再考虑另一个实操细节量化不是模型精度的决定性因素训练数据覆盖度才是。同一作者的同一个模型4bit 量化版本可能比另一个团队训练不充分的 7B 高精度模型好用得多。所以选模型优先看社区评价和数据质量量化位数排其次。3.3 工具链横向对比Ollama 最省事llama.cpp 最可控端侧部署 LLM 目前主流是三套工具链Ollama最省事一条命令拉模型、启动服务、跑推理。官方仓库里的 GGUF 模型可以直接拉取也支持自定义 Modelfile。如果你想快速把环境搭起来验证思路选它没商量。llama.cpp最灵活。支持细粒度参数控制、多线程调优、KV cache 量化还能配合各种自写脚本做自定义推理逻辑。生产环境我做 Agent 服务时更倾向 llama.cpp因为它暴露的控制参数全方便做性能调优和异常排查。RKLLM瑞芯微官方 NPU 方案。RK3588 上想让 LLM 在 NPU 上跑只能用这个工具链。它支持把 Hugging Face 模型转成 RKLLM 格式但转换过程有一些坑后面专门说。还有个补充方案在 Jetson 平台上你可以直接用CUDA 版 llama.cpp 或者带 CUDA 后端的 Ollama这也是 Jetson 最香的一点——生态完全对齐桌面 Linux几乎所有开源推理工具开箱即用。4. 端侧部署实操Jetson 和 RK3588 两条路都走一遍4.1 第一步把基础环境打磨干净不管哪块板子第一步都是把系统环境和依赖装干净。以 Jetson Orin 为例JetPack SDK 和 Docker 环境Jetson 建议直接用官方 JetPack 镜像自带 CUDA、cuDNN、TensorRT。推荐用 Docker 方式部署好处是环境隔离、方便回滚。这里有个坑网上很多教程让你装 x86 架构的 CUDA 镜像但 Jetson 是 ARM64 架构镜像必须选带有l4t标签的 JetPack 专属版。Docker 安装用官方脚本一步到位然后拉镜像这样操作# 在 Jetson 上安装 DockerARM64 版本 curl -fsSL https://get.docker.com | sh sudo usermod -aG docker $USER # 拉取 JetPack 官方基础镜像注意 l4t 标签 docker pull nvcr.io/nvidia/l4t-jetpack:r36.2.0 # 启动容器并挂载数据目录 docker run -it --rm \ --runtime nvidia \ --network host \ -v /home/user/models:/models \ nvcr.io/nvidia/l4t-jetpack:r36.2.0RK3588 的 NPU 环境RK3588 上你首先需要在板子上安装 RKLLM 工具包。官方给的是一个完整的 runtime 库和 Python 推理脚本安装流程不长但要注意 RKLLM 目前只支持特定版本的 NPU 驱动安装前务必备份原有系统因为驱动升级可能导致其他功能异常。我建议在这类板子上先跑通官方自带的 demorkllm 测试模型确认 NPU 可以正常推理再替换成自己的模型。4.2 用 Ollama 十分钟跑一个端侧模型在 Jetson Orin 上如果你选了 Ollama部署流程非常快# 安装 OllamaJetson 上是 ARM64 版本 curl -fsSL https://ollama.com/install.sh | sh # 拉取 Qwen2.5 7B 量化版 ollama pull qwen2.5:7b-q4_K_M # 启动服务默认端口 11434 ollama serve # 在另一个终端测试 curl http://localhost:11434/api/generate \ -d {model: qwen2.5:7b-q4_K_M, prompt: 用一句话解释什么是端侧Agent, stream: false}测试通了之后我建议做一个 10 分钟连续推理压力测试观察设备温度。Jetson 上 Ollama 默认配置没有针对 CUDA 做过特别调优实测可能只有 15~20 token/s但这只是开始后面还有调优空间。4.3 性能调优线程数、KV cache 和批处理这是最容易被忽略但其实影响最大的部分。以 llama.cpp 为例我常用的调优思路线程数CPU 推理时线程数不是越高越好。实测 RK3588 的 A76 核心用 6 线程跑 3B 模型反而比 8 线程快 20%因为线程切换开销超过了额外并行收益。Jetson 上如果走 CUDACPU 线程影响较小但--threads依然建议设为物理核心数而非逻辑核心数。KV cache 量化llama.cpp 支持--cache-type-k q8_0 --cache-type-v q8_0把 KV cache 从 FP16 降到 8bit内存能省 30% 左右速度还有小幅提升。上下文长度端侧 Agent 很多场景用不到 32K 上下文。把--ctx-size 4096甚至 2048内存和首 token 延迟都会明显改善。我的经验是上下文窗口越大内存分配越多KV cache 的预分配还会拖慢首 token。没有特殊需求不要盲目开大窗口。下面是一个我在 Jetson Orin NX 上实测过的一套 llama.cpp 启动命令./llama-server \ --model /models/qwen2.5-7b-instruct-q4_k_m.gguf \ --ctx-size 4096 \ --threads 6 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --port 8080实测效果7B Q4、上下文 4096单请求稳定 22~28 token/s首 token 延迟 420ms 左右。如果把模型换成 3B速度直接翻倍到 55 token/s 以上——这说明 Agent 场景里选小一号的模型往往体验反而更好。4.4 RK3588 部署 YOLOv8 做视觉 Agent 的感知层刚才提到端侧 Agent 是“感知—决策—行动”闭环那感知层的视觉识别在 RK3588 上最常见的方案就是部署 YOLOv8。这个过程也踩过不少坑记录一下能绕开的弯路RKNN 工具链的核心步骤RK3588 用的模型格式是 RKNN不是 ONNX 直接能跑。官方推荐流程是先训练/导出 ONNX然后用rknn-toolkit2转成 .rknn 模型最后在板子上用 RKNN Python API 或 C API 加载推理。我在实际项目中遇到的最大问题出在“归一化层”上——RKNN 转换器对模型输入尺寸和通道顺序很敏感YOLOv8 默认的输出格式和官方工具要求不一致容易直接报错。实操中有个通用解法先在模型导出环节固定输入尺寸选 640×640 或者 320×320优先选 32 的倍数并在导出 ONNX 时把opset版本设置为 12 以下RKNN 工具链对 opset 12 支持最好。转换命令大概长这样# 在 x86 开发机上安装 rknn-toolkit2执行转换 from rknn.api import RKNN rknn RKNN(verboseTrue) # 加载 ONNX 模型 rknn.config( target_platformrk3588, mean_values[[0, 0, 0]], std_values[[255, 255, 255]] ) rknn.load_onnx(model./yolov8n.onnx, input_size_list[[1, 3, 640, 640]]) # 构建并导出 RKNN 模型 rknn.build(do_quantizationTrue, dataset./dataset.txt) rknn.export_rknn(./yolov8n.rknn)转换完之后在板子上推理时注意两点一是输入图像要按 RGB 排列别弄成 BGR二是输出解析时 YOLOv8 的格式是“中心点宽高分类概率”自行写后处理时别和 YOLOv5 的格式混淆。我一开始用 YOLOv5 的解析逻辑跑 YOLOv8结果检测框偏了三天最后查代码才发现是后处理公式差了一个维度。如果你希望 YOLOv8 的检测结果和 LLM 的语义决策打通可以把检测结果输出为 JSON 字符串塞进 LLM 的 system prompt。比如“画面中有 2 个人、1 只猫位置坐标分别是...”让 Agent 模型基于这个结构化信息生成行动指令。这个思路在智能监控和巡检场景中很实用。4.5 用 Docker 封装一套可复现的 Agent 服务项目一旦跑通下一步就是固化环境。我最推荐的做法是把 Agent 服务拆成两个容器一个跑推理服务Ollama 或 llama.cpp一个跑 Agent 编排逻辑负责调用模型、解析工具调用、控制设备。这样定位问题时能快速判断是推理变慢还是编排逻辑卡住。docker-compose 大致长这样version: 3.8 services: llm: image: nvcr.io/nvidia/l4t-llama:latest runtime: nvidia command: [./llama-server, --model, /models/qwen2.5-7b-q4_k_m.gguf, --ctx-size, 4096] ports: - 8080:8080 volumes: - /home/user/models:/models agent: build: ./agent-app depends_on: - llm environment: - LLM_ENDPOINThttp://llm:8080 ports: - 8000:8000这里有个细节如果你用的是 Ollama容器编排时要避免把ollama serve和ollama run混在一起前者是常驻服务后者是交互式运行在 Docker 里跑交互式会直接导致容器秒退。生产部署一律用ollama serve方式。5. 常见问题与排查技巧实录5.1 内存不足和设备重启端侧设备内存是稀缺资源OOM 是最高频问题。排查顺序看看是不是同时跑了视觉模型和语言模型。RK3588 上 YOLOv8 和 LLM 同时跑很容易内存爆掉建议给视觉模型固定用 NPU、语言模型用 CPU两者内存隔离。检查上下文窗口。有个项目里我很奇怪为什么推理一长就重启后来发现 Ollama 默认上下文 2048但我的提示词加上历史记录涨到了 3000 多内存迅速耗尽。如果还不行降低量化档位从 Q5 换到 Q4或者换更小的模型。5.2 推理速度慢排除散热墙推理速度从 25 token/s 掉到 8 token/s第一反应先查温度。# Jetson 查看核心温度命令 sudo cat /sys/devices/virtual/thermal/thermal_zone0/temp # RK3588 同理如果温度超过 80°C基本确定是撞上温度墙降频。解决办法加强散热加风扇/散热片、降低满载时的模型并发、在系统层面做核心调度把推理进程绑到高性能核心上NPU 任务单独绑定。5.3 模型胡言乱语先查采样参数有时候模型推理结果完全离谱第一反应别怀疑量化先看 temperature 和 top_p。很多端侧场景直接用默认参数但默认 temperature 0.7 在设备任务上偏“发散”。做 Agent 决策时我建议调低到 0.2~0.3让模型更确定性。另外注意 system prompt 的设计比调参更重要——把设备能力列表、限制条件写清楚比反复调采样参数管用得多。5.4 并发请求卡死Agent 扛并发要排队端侧设备不是服务器一次顶多跑一两个推理请求。如果你做的是多用户服务同时调用端侧 Agent就会出现排队雪崩。解决办法有两个方向一是应用层加请求队列比如用 Redis 或异步任务队列保证 LLM 一次只接一个请求二是把 LLM 模型服务拆出多个实例比如一个模型在 CPU、一个在同板 NPU 上但这不是所有板子都支持。我的建议是端侧 Agent 的设计目标应该是“个人专属助手”而不是“多人共享服务”架构上避免并发是高性价比方案。5.5 常见问题速查表现象大概率原因排查/解决模型加载即崩内存不足减小模型、降低量化、关上下文动态分配推理速度远低于预期散热/降频、线程数不当查温度调整线程尝试 CUDA 后端输出语义混乱温度过高、提示词不清temperature 调至 0.2重构 system prompt首 token 延迟高KV cache 预分配过大减小 ctx-size启用 KV cache 量化量化后效果崩塌量化和任务场景不匹配换 Q6/Q8 再试数据分布窄的模型谨慎 Q4摄像头推理丢帧输入分辨率过高YOLOv8 输入降到 320×320Docker 容器秒退服务与交互模式混用一律使用常驻模式如ollama serve最后分享一个我的体会端侧 LLM 部署这件事真正难的不是“跑起来”而是“持续稳定地跑在真实业务里”。我见过太多项目demo 阶段 30 token/s 引以为傲一上产线就被温度、内存、并发这些“不太性感”的问题绊倒。以我的经验做端侧 Agent 一定要先想清楚模型规模边界再谈优化——很多时候换 3B 比纠结 7B 的调优更划算。把这个系列的思路拿去对照自己的项目先跑通最小闭环再慢慢加感知层和工具调用这条路走起来才踏实。