端侧 LLM 部署这事，如果说上一篇文章讨论的是 Agent 的架构和意图，那今天要聊的就是这个"脑子"到底怎么落到一块板子上、一台手机上、一个摄像头后面。做端侧 Agent 的人应该都有同感：云端大模型接口封装得再好，真到产品化阶段，延迟、隐私、流量成本、甚至断网场景，每一项都在逼你把模型往设备端推。而端侧 LLM 部署，恰恰是这条路上最硬的那块骨头——它不是在服务器上装个模型跑个测试，而是要在算力、内存、功耗三重约束下，让模型稳定、持续、可靠地提供服务。
这篇文章我准备把从模型选型、框架选择、量化到实际对接 Agent 的完整链路讲透，适合两类人看：一类是正在做端侧 Agent 产品、需要把 LLM 真正部署到设备上的开发者；另一类是刚接触大模型部署、想了解端侧和云端到底差在哪的后端工程师。文章里没有那种"下一步、再下一步"的空洞教程，全是我实际踩过坑之后的复盘和可以直接抄作业的方案。
1. 端侧部署先想清楚：模型、硬件与场景三方匹配
很多人在端侧部署上翻车，不是因为技术不够，而是第一步就没想明白。拿到一个 7B 模型就往设备上塞，结果推理速度慢到没法用，或者内存直接爆掉，然后开始怀疑自己代码写得有问题。实际上，问题往往出在"需求和硬件根本没有对齐"。
1.1 端侧 Agent 对 LLM 的真实诉求
端侧 Agent 跟普通的端侧 AI 应用不一样，它对 LLM 有一组独特的需求，我列一下我在产品里实际感受到的：
- 低延迟：Agent 要跟用户交互，用户说一句话，Agent 得在可感知的范围内给出响应。云端 300ms 的 API 延迟可以接受，但端侧如果跑到 5 秒以上，用户会直接认为设备"卡了"。具体指标要看场景，语音交互的 Agent 要求更高，文本类的 Agent 相对宽裕一些。
- 流式输出：Agent 的"思考过程"如果能让用户看到，体验会好很多。端侧模型因为速度本身不快，如果还要等整段输出完再说，交互会非常难受，所以流式几乎是必需能力。
- 可控性：端侧 Agent 往往要执行操作，比如控制设备、读取传感器、调用工具，所以模型得能按结构化格式输出，也就是要有基本的功能调用能力。
- 长会话保持：Agent 和用户的对话通常不是一问一答就结束，而是要持续几轮、几十轮。这意味着上下文窗口不能太小，同时 KV Cache 的开销必须要有预期。
有朋友会问："那到底多大模型才够用？"这个问题没有标准答案，但我可以给你一个可参照的结论：做简单工具调用和意图识别，1B~3B 的量化模型就能跑；做通用对话和复杂任务规划，7B~8B 是体验底线；14B 以上在高端手机上勉强能跑，在嵌入式设备上基本不现实。这个判断不是我拍脑袋，而是经过多个平台实测之后的经验。
1.2 主流端侧硬件的算力边界
当前端侧推理的主力平台，我分成三档来说：
手机 SoC 阵营，高通骁龙 8 系列、联发科天玑 9000 系列、苹果 A 系列和 M 系列，这几类都有独立的 NPU 或加强的 GPU，内存普遍 8GB~16GB，理论算力跨度从 20 TOPS 到 60 TOPS 以上。这类平台适合跑到 7B 量级的量化模型，苹果 M 系列甚至可以跑 14B 甚至更大。
嵌入式 AI 板卡阵营，典型代表是瑞芯微 RK3588（8 TOPS NPU）、Jetson Orin 系列（最高 275 TOPS）、树莓派加 AI 加速模块等。这些平台内存小，但胜在功耗可控、接口丰富，适合做固定位置的 Agent 设备，比如桌面助手、机器人的"大脑"。其中 Jetson Orin 因为显存可以和内存统一寻址，跑 7B 模型做 Agent 是目前嵌入式里最舒服的方案。RK3588 的 NPU 对 LLM 支持的算子还有一些限制，我后面会专门讲。
MCU 或者低功耗 SoC 阵营，能跑 0.5B~1B 的模型就已经是极限，适合做唤醒词、简单意图识别这类"轻 Agent"。这类平台跑不了通用对话，别硬上。
这里有个核心认知要建立：端侧部署不是"选最强的"，而是"选瓶颈最小的"。算力再强，内存不够一样白搭；内存够大，算力不够推理慢到怀疑人生。所以要三方匹配，模型大小、硬件算力、场景需求，缺一个环节不对，整个产品都立不住。
1.3 模型选型：从 0.5B 到 14B 的分级思路
模型选型我建议按"任务复杂度 × 设备等级"来分，不要一味看参数数量。下面是我实际使用过的几个模型和它们在端侧的表现，整理成一个表格供参考：
| 模型 | 参数量 | 推荐设备 | 实际效果 | 我踩过的坑 |
|---|---|---|---|---|
| Qwen2.5-0.5B / 1.5B | 0.5B~1.5B | MCU、低端手机 | 意图识别勉强，通用对话不顶用 | 对话稍微拐个弯就答非所问 |
| Qwen2.5-3B / Phi-3-mini | 3B~3.8B | RK3588、中端手机 | 简单 Agent 工具调用勉强可用 | 上下文一长就"失忆"，需要做压缩 |
| Qwen2.5-7B / Llama-3-8B | 7B~8B | 骁龙 8 Gen 2+、Jetson Orin、Apple Silicon | 通用 Agent 的入门线，Function Calling 可用 | 内存占用大，KV Cache 要精打细算 |
| Qwen2.5-14B | 14B | Apple Silicon、大内存旗舰 | 体验接近云端小模型 | 功耗发热明显，长时间运行会降频 |
我做 Agent 项目时，最低敢用的线是 3B，但如果是用户直接对话的产品，我建议至少 7B 量化。有人说 3B 够用，那是任务太简单，Agent 一旦涉及多步推理、记忆、工具调用，小模型立刻露馅，这不是调 prompt 能解决的，是模型本身的容量天花板。
2. 部署框架选型：llama.cpp、MLC-LLM、Ollama 到底怎么选
很多人以为端侧部署就是"下载一个 Ollama，跑一条命令"，实际上工程化落地时，你要考虑的东西比这多得多。Ollama 只是最上层的一个封装，它底层用的还是 llama.cpp 这类推理引擎，而不同推理引擎在端侧的表现差异巨大。
2.1 三大主流框架的能力边界对比
- llama.cpp：目前端侧部署事实上的标准。纯 C/C++ 实现，依赖少，对 CPU 的优化做到了极致，支持 AVX/NEON 等指令集加速，量化方案 GGUF 格式的生态非常成熟。它的核心优势是"在哪儿都能跑"，树莓派能跑、x86 边缘网关能跑、安卓手机配合 Termux 也能跑。劣势是 GPU/NPU 加速需要自己折腾，默认主要走 CPU。
- MLC-LLM：基于 TVM 编译器生态，主打"一次编写、多端部署"，对手机 GPU（OpenCL/Metal）和部分 NPU 做了统一抽象。我在骁龙平台上测试过，GPU 加速效果比 llama.cpp 纯 CPU 快不少，但环境配置复杂，遇到算子不兼容时报错会非常抽象。
- Ollama：严格说它不是一个推理引擎，而是一个模型服务 + 管理工具。它是把 llama.cpp 包了一层，提供 HTTP API、模型管理、多模型并发等能力，特别适合快速验证想法。但端侧产品化时我一般不直接用 Ollama，因为它的进程管理和资源占用控制不够细，定制空间小。不过 Ollama 在 x86 小主机和开发板上的部署速度确实快，做原型很香。
如果你有印象的话，AMD 的 ROCm 生态也有自己的推理路径，NVIDIA 的 Jetson 平台则是以 TensorRT-LLM 和 PyTorch/ExecuTorch 为主。所以框架选型本质上是在"生态成熟度""加速性能""定制灵活性"三个维度上权衡。我的建议是：
- 快速验证、原型演示：直接上 Ollama，别犹豫。
- 产品化落地、CPU 推理为主：llama.cpp，自己编译，控制一切。
- 手机 GPU 加速、追求极致性能：MLC-LLM 或 ExecuTorch，但要接受折腾。
- Jetson 平台：TensorRT-LLM 优先，配合 PyTorch 生态做 Agent 编排。
2.2 移动端与嵌入式平台的差异化选型
手机和平板这类移动端，跟 RK3588 这类嵌入式板卡，在框架选择上差异非常大。手机端不要直接上 Ollama，因为它主要面向桌面和服务器环境，安卓上要跑也是通过 Termux 套一层，性能和稳定性都不理想。正确做法是在安卓端用 ExecuTorch 或 MLC-LLM 的 Android SDK，通过 JNI 层把推理引擎嵌入到 App 进程里，模型文件放在 assets 或下载目录，走 app 的生命周期管理。
嵌入式板卡反而是 Ollama 的舒适区。RK3588 和 Jetson 系列跑的都是 Linux 系统，Ollama 可以直接 systemd 管理，GPU 或 NPU 驱动装好之后，模型加载和服务化一条龙。尤其是 Jetson Orin 上，Ollama 配合 CUDA 后端，跑 Qwen2.5-7B Q4 量化能到每秒 15~30 个 token 的生成速度，这对一个端侧 Agent 的"大脑"来说已经够用了。RK3588 的 NPU 就得另说，它的 RKNN 工具链对 LLM 支持度还在完善，很多情况下反而不如直接用 CPU 跑 llama.cpp，NPU 的算子转换时间可能比 CPU 推理时间还长。
2.3 框架之外还要解决的运行时问题
说实话，框架只是端侧部署的第一步。实际产品上线前，这些问题你都得自己处理：
- 模型热加载与卸载：端侧内存宝贵，你不能让一个 7B 模型常驻内存占掉 6GB，否则其他进程没法活。需要做模型按需加载、空闲自动卸载的机制。
- 接口统一：Agent 框架调用的是 OpenAI 风格的
/chat/completions接口，但 llama.cpp 和 MLC-LLM 原生接口都不完全兼容 OpenAI 格式，中间要加一层适配服务。 - 模型文件管理：GGUF 文件动辄几个 GB，升级、回滚、完整性校验都要有方案。
- 并发控制：端侧设备通常一次只能跑一路推理，多用户接入时要排队，这个后面专门讲。
这些都不是框架帮你解决的，得自己在工程层做设计。
3. 量化与内存：把模型塞进有限显存的关键一仗
端侧部署的物理瓶颈基本就是内存和算力，而内存问题是"数学上可以预判"的。我见过太多人一上来就下原版 FP16 模型，然后内存爆了，才开始研究量化。早知道这些公式，根本不用走弯路。
3.1 内存需求的估算方法
一个模型的内存占用，主要由三块构成：模型权重、KV Cache、运行时开销。
模型权重的计算公式很简单：参数量 × 每个参数的字节数。以 7B 模型为例：
- FP16（每参数 2 字节）：7B × 2 ≈ 14GB
- INT8（每参数 1 字节）：7B × 1 ≈ 7GB
- INT4（每参数 0.5 字节）：7B × 0.5 ≈ 3.5GB
KV Cache 的估算稍微复杂一点：2（K 和 V） × 层数 × 隐藏维度 × 上下文长度 × 字节数。不同模型的隐藏维度差异很大，Qwen2.5-7B 是 3584，Llama-3-8B 是 4096。以 Qwen2.5-7B 为例，上下文 8192、FP16 时，KV Cache 大约 2 × 28 × 3584 × 8192 × 2 ≈ 3.2GB。如果你开 32K 上下文，这块直接翻四倍。这就是为什么长上下文在端侧那么奢侈。
运行时开销包括激活值、临时缓冲区、推理中间结果等，一般额外预留 20%~30%。
所以一个实际的生产经验是：7B 模型 Q4 量化，想要 8K 上下文稳定运行，设备可用内存最好在 6GB~8GB 以上。14B 模型 Q4 量化，需要 12GB 以上可用内存。低于这个数，不是不能跑，而是会频繁触发内存回收或直接被杀进程。
3.2 常见量化方案及精度影响
量化方案几大主流选择，各有各的应用场景：
| 量化格式 | 精度 | 模型体积（7B） | 推荐场景 | 风险点 |
|---|---|---|---|---|
| Q8_0 | 接近无损 | 约 7GB | 对精度敏感、内存充裕 | 体积大，端侧不常用 |
| Q6_K | 高精度 | 约 5.5GB | 通用端侧、效果优先 | 内存压力中等 |
| Q5_K_M | 较高精度 | 约 5GB | 平衡之选 | 无明显短板 |
| Q4_K_M | 可接受精度 | 约 4.4GB | 端侧主力方案 | 复杂推理偶尔输出颠三倒四 |
| Q3_K_M | 精度明显下降 | 约 3.7GB | 内存受限时的妥协 | 逻辑推理能力显著变弱 |
| IQ2_XXS | 极限压缩 | 约 2.5GB | 演示、极端内存受限 | 基本不能用于 Agent |
这里我想多说一句：很多论文宣称 INT4 量化精度损失可以忽略，那是拿评测集测出来的"均值"结论，实际做 Agent 时你会遇到评测集测不出来的问题——模型生成 JSON 时偶尔多一个字段、工具调用参数偶尔串位、长上下文的注意力偶尔崩掉。这些在"平均指标"上看不出来，但对产品体验是致命的。所以我的建议是：Agent 场景至少用 Q5_K_M 起步，Q4_K_M 是底线，不要因为省几十 MB 内存去用 Q3 以下。
3.3 实测数据：不同精度下的内存与速度对照
我在 Jetson Orin Nano 8GB 上做过一组实测，模型是 Qwen2.5-7B-Instruct，数据如下：
| 量化等级 | 模型加载内存 | 速度（token/s） | 首 token 延迟 |
|---|---|---|---|
| Q8_0 | 约 7.5GB | 6~8 | 2.5s |
| Q6_K | 约 6GB | 8~10 | 1.8s |
| Q5_K_M | 约 5.2GB | 9~12 | 1.5s |
| Q4_K_M | 约 4.6GB | 11~15 | 1.2s |
需要说明的是，Orin Nano 的 GPU 是 Ampere 架构，llama.cpp 的 CUDA 后端能比较好的发挥。如果是纯 CPU 跑，7B Q4 的速度可能只有每秒 2~4 个 token，体验会大打折扣。所以在嵌入式平台上，能不能用上 GPU 加速，往往比选什么量化格式更影响体验。
另一个容易被忽略的点是：不同的 GGUF 量化版本之间，也存在差异。比如 Q4_K_M 比 Q4_0 更精细，同体积下质量更好；K-quants 方案专门优化了重要张量的精度分配，所以在模型文件大小差不多的情况下，优先选带 K 的版本。
4. 实操实录：Ollama + llama.cpp 部署一个端侧 Agent 底座
前面理论讲了不少，这部分我给一份可以直接落地的实操方案。我用的是组合拳：Jetson Orin + Ollama + 一个轻量适配层，对接 Agent 框架。
4.1 环境准备与启动模型
首先安装 Ollama。在 Jetson 系列上，Ollama 官方安装脚本会尝试探测 CUDA，你只要保证 JetPack 系统里已经装好了 NVIDIA 驱动和 CUDA 运行时就行。
# 安装 Ollama curl -fsSL https://ollama.com/install.sh | sh # 启动服务 systemctl start ollama systemctl status ollama然后拉取量化后的模型。以 Qwen2.5-7B-Instruct 为例，Ollama 默认会拉取 Q4_K_M 版本，也可以显式指定：
ollama pull qwen2.5:7b-instruct-q5_K_M ollama run qwen2.5:7b-instruct-q5_K_M这里的坑在于：默认拉取的模型版本可能不是你想要的那个。Ollama 有两个 tag 体系，一个是官方默认的（比如qwen2.5:7b），另一个是社区上传的带完整量化标识的版本。我的经验是生产环境要用带.gguf标识的球队格式，或者直接从 Hugging Face 下载 GGUF 文件然后创建自定义 Modelfile。这样可以完全锁定文件版本和量化参数，不会因为上游更新导致行为漂移。
如果你用的是 llama.cpp 而不是 Ollama，那编译和启动方式是这样的：
git clone https://github.com/ggml-org/llama.cpp cd llama.cpp mkdir build && cd build cmake .. -DGGML_CUDA=ON make -j$(nproc) # 启动 server 模式 ./bin/llama-server -m /path/to/qwen2.5-7b-instruct-q5_K_M.gguf \ --host 0.0.0.0 --port 8080 \ -ngl 99 \ -c 8192 \ --jinja-ngl 99是让模型尽可能多地放 GPU，--jinja是启用模型的模板语法。这个参数对工具调用能否正确生效非常关键。
4.2 OpenAI 兼容接口与 Agent 框架对接
不管用 Ollama 还是 llama.cpp server，最终都要让 Agent 框架以 OpenAI SDK 的方式访问模型。Ollama 的接口不完全是 OpenAI 风格，需要设置环境变量让它启用兼容模式：
export OLLAMA_HOST=0.0.0.0:11434 # 新版 Ollama 直接支持 /v1/chat/completions curl http://127.0.0.1:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b-instruct-q5_K_M", "messages": [{"role": "user", "content": "你好"}] }'Agent 框架对接时，只需要把 base_url 指向 Ollama 或 llama.cpp server 即可：
from openai import OpenAI client = OpenAI( base_url="http://127.0.0.1:8080/v1", # llama.cpp 或 Ollama api_key="none" ) response = client.chat.completions.create( model="qwen2.5:7b-instruct-q5_K_M", messages=[{"role": "user", "content": "帮我查一下今天的天气并设置提醒"}], tools=[{ "type": "function", "function": { "name": "get_weather", "description": "查询指定城市的天气", "parameters": { "type": "object", "properties": { "city": {"type": "string"} }, "required": ["city"] } } }], stream=True )这里要注意，llama.cpp 的 server 需要开启--jinja并且模型本身支持 chat template 才会正确处理 tools 字段。如果模型没有正确的 tool-use prompt 模板，tools 会被忽略，模型还是会按照普通对话的方式回复。实测中，Qwen2.5 系列对 tools 的支持是开箱即用的，Llama-3 需要确认模板版本，老版本模型往往不支持。
4.3 流式输出与并发控制的细节
流式输出对端侧 Agent 不是"锦上添花"，而是"必不可少"。因为端侧 LLM 推理速度本来就慢，如果用户要等 5 秒才看到第一个文字，基本等于不可用。流式输出能把首 token 的时间压缩到 1~2 秒内，用户心理感受完全不同。
实现流式输出时，OpenAI SDK 直接传stream=True即可，但真正做产品时有两个细节：
第一个细节是 SSE 与端侧设备的网络栈兼容性。很多嵌入式设备的 HTTP 客户端对 SSE 支持不完善，连接容易被网关断开，需要设置合理的 keep-alive 参数，或者自己解析 chunk 而不是依赖封装的 SDK。
第二个细节是"取消生成"的机制。用户可能在 Agent 生成到一半时打断（比如说"别说了，直接执行"），如果你的端侧推理服务不支持立即停止生成，模型还会继续算好几百个 token，既浪费算力又导致后续指令延迟。Ollama 的 API 支持中断，llama.cpp 需要自己实现 slot 的释放逻辑。我在做产品时专门加了一个"打断控制器"，一旦检测到用户新意图，立即释放推理槽位。
并发方面，端侧设备和服务器不一样，不要指望多路并发。7B Q5 模型在 Jetson Orin 上占掉大半内存后，多路推理会导致每路都变慢，总吞吐反而下降。我的处理方式是单路推理 + 请求排队。实际用消息队列把请求串行化，一次只处理一个会话，其他请求排队等待。这个方案在大多数端侧 Agent 场景下已经够用——毕竟端侧服务的就是一两个用户，不像云端要扛几千路并发。
4.4 Function Calling 在端侧模型上的现实表现
做 Agent 的人绕不开 Function Calling。端侧模型的工具调用能力，确实比云端小模型弱，但量化后还能不能保住这个能力，取决于两个因素：一是模型的原始能力，二是量化的精度等级。
实测下来，Qwen2.5-7B 在 Q5_K_M 量化下，工具调用的格式正确率还能维持在 90% 以上；降到 Q4_K_M 时，格式正确率会掉到 80%~85%；降到 Q3 以下，直接不建议做工具调用，因为经常会输出半截 JSON 或者漏掉参数。Llama-3-8B 的情况类似，但它的 JSON 风格输出整体比 Qwen 要弱一些，做工具调用时需要更强的提示词约束。
还有个实际经验是：端侧模型做 Function Calling，最好把工具的数量控制在 5 个以内，每个工具的 description 写清楚但不要啰嗦。工具太多会让小模型的注意力涣散，选择工具时出错率显著上升。我在项目里试过给模型塞 10 个工具，结果它经常选错工具或者把参数填错位置。把工具精简到 4 个之后，准确率回到可接受水平。
另外提一嘴"llm 的知识库检索"问题。热词里提到的 RAG 和 GraphRAG 也是端侧 Agent 常见配套。端侧做 RAG 不能原样搬云端方案，因为 embedding 模型也要在端侧跑，向量库也不能太重。推荐用embedding小模型（0.5B 级别）加 SQLite-Vec 这类轻量方案，把文本向量化后存在本地，满足检索需求即可。不要为了追求效果好就上重型向量数据库，端侧吃不动。
5. 端侧部署的常见问题与排查记录
这部分我尽量把平时最容易踩的坑整理出来，每条都是真实项目中遇到过的，不是编出来的。
5.1 启动失败与依赖缺失
典型症状：llama-server启动后提示 CUDA 相关错误，或者 Ollama 显示 GPU 不可用。
排查思路：先确认驱动和 CUDA 版本，再确认 llama.cpp 编译时是否真的启用了 CUDA。
nvidia-smi # 检查驱动和 GPU 是否可见 ollama ps # 查看模型实际运行在 CPU 还是 GPU有一个很隐蔽的坑：Jetson 的 JetPack 版本和 CUDA 版本是绑定的，如果你从官网下载的 llama.cpp 预编译包带着桌面版 CUDA 依赖，在 Jetson 上会直接起不来。解决办法是必须用 JetPack 自带的 CUDA 工具链自己编译，别偷懒用预编译包。
另外在 RK3588 上经常遇到的问题是：NPU 驱动没装好但 CPU 推理正常，你以为是 NPU 在跑，实际上一直是 CPU 在干活。用top看 CPU 占用率如果接近 100%，基本可以断定 NPU 没有参与计算。
5.2 推理速度异常的排查思路
速度慢的排查优先级，我建议这样排：
- 先看模型是否真用上了 GPU：
ollama ps或者 llama.cpp 的启动日志里是否有 CUDA offload 到 GPU 的打印。如果 GPU 显存不够，部分层跑在 CPU，速度会断崖式下降。 - 看内存是否触发了 swap：嵌入式设备经常启用 swap，但 swap 上跑 LLM 推理，速度会慢 10 倍以上。要观察
free -h和swapon的输出，如果 swap 使用率一直在涨，说明物理内存不足，需要降量化等级或减小上下文长度。 - 看是否被降频：Jetson 的 GPU 有功率墙，长时间满负荷跑会触发降频。用
tegrastats查看，如果 GPU 频率掉到一半以下，说明散热或供电出了问题。 - 看数据和代码优化选项：llama.cpp 编译时是否加了
-O3、-march=native，是否开了GGML_CUDA，这些对性能影响很大。默认没编译优化的 llama.cpp 跑起来，速度差 20% 起步。
5.3 输出质量崩坏的量化背锅现场
有段时间我们的 Agent 总是突然答非所问，排查了提示词模板、对话历史、上下文截断逻辑，最后发现是模型加载的量化版本变了——之前一直用的 Q5_K_M，某次自动更新之后变成 Q3_K_M，参数文件大小一下子小了几百 MB，但界面上没有明显提示，所以一直没发现。
这件事给我提了个醒：端侧模型的版本管理必须严格，模型的加载路径和量化标识要打进日志里，每次启动都打印一行，方便日后排查。另外，模型文件的哈希值要校验，下载中断导致文件损坏时，加载过程可能不报错，但推理结果会胡言乱语。GGUF 文件如果没有正确下载完整，llama.cpp 启动时可能只报一个警告，后面输出全是乱的。
另一个常见问题是：上下文对话轮次过多时，Agent 开始丢失指令。这通常是 KV Cache 溢出后的"静默截断"导致的。我建议在应用层主动做对话历史裁剪，把超过 N 轮的早期对话压缩成摘要，而不是任由模型填充 KV Cache 后被截断。这和云端上的上下文管理类似，但端侧因为缓存更小，更依赖上层的主动管理。
5.4 热管理、省电与长时间运行稳定性
端侧设备不是数据中心服务器，散热和功耗是实打实的问题。Jetson Orin Nano 满负荷跑 7B 模型，功耗能到 15W~20W，如果设备是在一个密闭外壳里，半小时后就会触发降频。实测一个案例：刚开始跑 Agent 时首 token 延迟 1.2 秒，运行 20 分钟后变成 2.8 秒，这就是降频导致的，散热片一加回去马上恢复。
省电策略上，我的做法是把推理服务拆成"热态"和"冷态"。热态是模型常驻内存、等待请求，适合交互频次高的场景；冷态是模型空闲超时自动卸载，需要时重新加载，适合交互频次低的场景。模型重新加载虽然要花几秒，但平均功耗能降一半以上。
还有一个很容易忽略的问题：长时间运行的日志膨胀。llama.cpp 的日志如果开了 debug 级别，几天下来能吃掉几百 MB 存储，这对嵌入式设备是致命的。生产环境务必把日志级别调到 warn 以上，并配置日志轮转。
6. 浅谈端侧 Agent 的未来：模型占用与云端协同
端侧 LLM 部署并不是孤立的，它最终要为 Agent 服务的完整链路提供支撑。有一个观点我想分享一下：端侧 Agent 的产品形态，大概率不是"一切都跑在端上"，而是"端侧为主、云端为辅"的混合架构。
6.1 三层模型的端云协同结构
根据我的实践，端侧 Agent 至少有三种任务粒度需要不同规模的模型处理：
- 端侧常驻小模型（0.5B~1.5B）：负责意图粗分类、语音唤醒、敏感信息过滤、简单指令执行。这个模型始终在内存里，毫秒级响应。
- 端侧按需中模型（3B~7B）：负责通用对话、Agent 规划、工具调用。有任务时加载，空闲时卸载。
- 云端大模型（量级更大）：负责复杂推理、长文档处理、跨设备协同等端侧搞不定的任务，仅在端侧模型"判定自己能力不足"时才调用，或主动选择。
这套结构的好处是可以做到"绝大多数请求在端侧闭环"，隐私数据不出设备，无网环境也能提供服务。成本上也非常划算：一个 7B 模型的端侧推理相比按 token 计费的云 API，长期跑下来省钱得多，而且一旦模型在本地，响应速度快一个量级。
6.2 端侧 Agent 的记忆与状态管理
回到热词里的那张图——"LLM 的 token 三个点：key 我是谁、query 我在找什么、value 我能提供什么"。这个概念在端侧 Agent 里同样适用，端侧模型本身没有持续记忆，Agent 的记忆要靠外部状态管理来做。
我的做法是维护一个本地记忆库，按三类组织：
- key（自述信息）：记录设备 ID、用户偏好、环境配置；
- query（意图查询）：记录当前任务的上下文、目标；
- value（执行结果）：记录工具调用的返回值、对话摘要。
每次 Agent 会话开始时，从记忆中构建 system prompt 的"身份块"，让模型知道"我是谁"；会话中把 query 转化成工具调用的参数语义；会话结束后把结果写回 value。这套机制让 3B 的小模型也能表现出"我记得你"的效果，实际上模型本身没有任何记忆能力，是外层状态管理补上的。
6.3 关于 Agent 开发的几点建议
热词里有"吴恩达 Agent 教程"也有"Agent 框架与编排"，说明大家都在往这个方向探索，但端侧 Agent 的开发和云端 Agent 开发很不一样，这里给几条建议：
第一，端侧 Agent 的功能范围要做减法人。设备端的 Agent 不需要什么都会，只要把几个核心场景做到极致，体验就好。贪多嚼不烂，端侧尤其如此。
第二，要让 Agent 的"能力边界"变得可见。如果用户的请求超出了端侧模型的能力范围，要明确告诉用户"这个操作需要联网才能完成"或者"这个功能当前设备不支持"，而不是让模型硬答。硬答的结果一定是我前面提到的"一本正经胡说八道"，这在 Agent 场景下比在对话场景下危害大得多——它会直接驱动设备执行错误动作。
第三，端侧 Agent 必须留好人工兜底通道。任何自动化 Agent，最终必须有用户可以一键手动接管或取消操作的路径。这在功能安全上不是可选项，而是必须项。我在做设备控制类 Agent 时，所有危险操作都会二次确认，在 model 层做不了，就在应用层做。
写在最后
按惯例不写总结了，分享两个我最近在实际操作中的感受。
第一个是：做端侧 LLM 部署，别神话量化、也别小看量化的影响。它确实是端侧落地的唯一解，但"唯一解"不等于"免费午餐"。每一步精度的下降，最后都会以你看不到的方式反映在 Agent 的行为上。如果你负责的产品稳定性要求很高，那么量化上线前做一轮专门的工具调用压力测试非常值得，成本不高，收益很大。
第二个是：端侧 LLM 部署的调试，最大的敌人是环境不透明。同样的模型文件，在 A 设备上跑得好好的，到 B 设备上就疯狂输出乱码，查来查去发现是 B 设备的非统一内存架构 + 低配 GPU 导致部分层没有 offload。所以在每一台设备上，第一步永远是打印"模型跑在哪、内存用了多少、量化是什么版本"这三条信息，比什么优化技巧都重要。
这套流程走完，端侧 Agent 的底座基本上就稳了。剩下的事情——Agent 的规划、记忆、工具链编排——都是在这个底座之上的锦上添花。底座不稳，上面再漂亮也白搭。
