尧图网页设计 
1. 端侧 LLM 部署到底在解决什么问题端侧 Agent 这个话题最近一年被聊得很多但真正落到工程上第一道坎从来不是 Agent 的编排逻辑而是模型怎么塞进设备里还能跑得动。我见过太多团队在云端把 Agent 流程跑通之后一到端侧就卡在内存、算力、功耗这三座大山面前。端侧 LLM 部署要解决的核心矛盾其实就一句话在有限的硬件资源下让一个几十亿参数的模型以可接受的延迟和功耗完成推理。这件事为什么现在变得重要因为 Agent 的本质是“感知-决策-执行”的闭环如果每一轮决策都要把数据传到云端再等结果回来那延迟、隐私、离线可用性全都会出问题。端侧 Agent 的价值恰恰在于把决策能力下沉到设备本地而 LLM 作为 Agent 的“大脑”必须跟着一起下沉。这就是端侧 LLM 部署存在的意义。适合看这篇内容的人我大致分三类一是正在做端侧 AI 硬件产品的工程师比如做机器人、智能座舱、工业巡检设备的二是想把本地大模型跑起来的开发者手里有 Jetson Orin、RK3588 这类板子但不知道从哪下手三是做 Agent 应用但对底层推理链路一知半解的想搞清楚模型部署这一层到底有哪些坑。不管你属于哪一类这篇内容都会从选型、量化、推理引擎、内存管理到实际踩坑把整条链路拆开讲清楚。需要提前说明的是端侧 LLM 部署没有“一招鲜”的方案。不同芯片平台、不同模型规模、不同延迟要求对应的技术选型完全不同。我会尽量把每个决策背后的逻辑讲透让你能根据自己的场景做判断而不是照搬某一套配置。2. 端侧 LLM 部署的整体设计思路2.1 为什么不能直接把云端模型搬到端侧很多人第一反应是云端跑得好好的模型直接下载到设备上不就行了实际操作下来会发现根本行不通。一个 7B 参数的模型如果用 FP16 精度存储光权重就要占 14GB 左右的内存。而典型的端侧设备比如 Jetson Orin Nano 只有 8GB 共享内存RK3588 开发板通常配 4GB 到 8GB LPDDR。模型还没加载完内存就爆了。除了内存还有算力问题。云端一张 A100 的 FP16 算力是 312 TFLOPS而 Jetson Orin Nano 大概只有 20 TOPSINT8差距在十五倍以上。这意味着同样的模型端侧推理延迟可能是云端的几十倍。再加上端侧设备通常有功耗墙不能像服务器那样随便堆散热持续高负载推理会导致降频。所以端侧 LLM 部署的第一原则是模型必须经过压缩和适配不能直接搬运。压缩的手段包括量化、剪枝、知识蒸馏适配的手段包括选择适合端侧硬件的推理引擎、调整算子实现、优化内存布局。这些工作构成了端侧部署的核心技术栈。2.2 端侧 LLM 部署的三种典型路线根据硬件平台和需求的不同我把端侧 LLM 部署分成三条路线每条路线的技术选型和优化重点都不一样。第一条是GPU 路线代表平台是 NVIDIA Jetson 系列。Jetson Orin 系列自带 CUDA 和 TensorRT 支持生态最成熟。你可以用 TensorRT-LLM 把模型编译成引擎推理速度在端侧设备里属于第一梯队。缺点是功耗偏高Orin NX 满载大概 25WOrin Nano 也要 10W 到 15W对电池供电的设备不太友好。第二条是NPU 路线代表平台是 RK3588、瑞芯微系列、地平线征程等。这类芯片的 NPU 算力通常在 6 TOPS 到 16 TOPS 之间功耗控制得很好RK3588 的 NPU 满载也就 5W 左右。但 NPU 的算子支持不如 GPU 全面模型需要经过转换工具链比如 RKNN重新编译遇到不支持的算子就得手动替换或者回退到 CPU调试成本比较高。第三条是CPU 路线代表场景是低功耗 MCU 或者手机端。CPU 推理速度最慢但兼容性最好适合跑 1B 以下的小模型或者做兜底方案。常用的推理框架有 llama.cpp、ONNX Runtime 等。llama.cpp 在 ARM CPU 上的优化做得不错配合 4-bit 量化跑 1B 到 3B 的模型勉强能用。选哪条路线取决于你的延迟要求、功耗预算和模型规模。我一般建议如果设备有独立供电且对延迟敏感优先考虑 Jetson TensorRT如果是电池供电的移动设备优先考虑 RK3588 RKNN如果只是做原型验证或者模型很小CPU 方案也能凑合。2.3 模型规模与硬件资源的匹配逻辑选模型的时候不能只看效果得先算一笔账。端侧设备的内存是硬约束模型权重、KV Cache、激活值、系统占用加起来不能超过可用内存。我常用的估算方法是模型权重内存 ≈ 参数量 × 每参数字节数。FP16 是 2 字节INT8 是 1 字节INT4 是 0.5 字节。一个 7B 模型INT4 量化后权重约 3.5GBINT8 约 7GBFP16 约 14GB。KV Cache 的大小取决于序列长度和层数粗略估算公式是2 × 层数 × 隐藏维度 × 序列长度 × 精度字节数。以 7B 模型32 层隐藏维度 4096为例序列长度 2048FP16 精度下 KV Cache 约 1GBINT8 约 0.5GB。把这两部分加起来再加上推理框架本身和系统占用通常 1GB 到 2GB就能判断设备能不能跑。比如 8GB 内存的 Jetson Orin Nano跑 INT4 量化的 7B 模型权重 3.5GB KV Cache 0.5GB 系统 2GB 6GB勉强能跑但留给其他进程的空间就很紧张了。如果换成 3B 模型INT4 量化后权重约 1.5GB整体占用 4GB 左右就宽裕很多。注意很多开发板的“8GB 内存”是 CPU 和 GPU 共享的实际可用内存可能只有 6GB 到 7GB。选型时一定要留出至少 20% 的余量否则跑起来容易 OOM。3. 核心细节解析与实操要点3.1 量化端侧部署的第一道工序量化是端侧 LLM 部署绕不开的一步。它的本质是把模型权重和激活值从高精度浮点数映射到低精度整数从而减少内存占用和计算量。常见的量化精度有 FP16、INT8、INT4端侧最常用的是 INT8 和 INT4。INT8 量化的原理是把 FP16 的权重线性映射到 -128 到 127 的整数范围推理时再反量化回浮点做计算。这种方式的精度损失通常很小困惑度Perplexity上升一般在 0.1 到 0.5 之间实际使用中几乎感觉不到差异。INT4 量化更激进把权重压缩到 16 个离散值内存直接减半但精度损失会明显一些困惑度可能上升 1 到 3。对于 Agent 场景如果任务对精度要求高比如代码生成、数学推理建议用 INT8如果只是做意图识别、简单问答INT4 完全够用。量化的实现方式分两种训练后量化PTQ和量化感知训练QAT。PTQ 不需要重新训练直接对训练好的模型做校准和转换成本低适合快速落地。QAT 在训练过程中模拟量化误差精度更好但需要重新训练成本高。端侧部署绝大多数情况用 PTQ 就够了。具体操作上不同推理框架的量化工具不一样。TensorRT-LLM 用trtllm-build配合量化校准数据集llama.cpp 用quantize工具支持 Q4_0、Q4_K_M、Q5_K_M 等多种量化格式ONNX Runtime 用onnxruntime.quantization模块做动态或静态量化。我一般推荐先用 llama.cpp 的 Q4_K_M 格式做快速验证这个格式在精度和速度之间平衡得比较好社区反馈也最稳定。实操心得量化校准数据集的选取很关键。不要随便拿几百条通用语料就完事最好用你的实际业务数据做校准这样量化后的模型在你的场景下精度损失最小。我试过用通用语料校准的 INT4 模型在专业领域问答上错误率比用业务数据校准的高出近一倍。3.2 推理引擎选型TensorRT、RKNN 还是 llama.cpp推理引擎的选择直接决定了推理速度和开发效率。我把几个主流方案做个对比方便你根据平台选型。推理引擎适用平台支持量化优点缺点TensorRT-LLMNVIDIA GPUINT8/INT4/FP8性能最强算子优化好编译复杂只支持 NVIDIARKNN瑞芯微 NPUINT8/INT4功耗低集成度高算子支持有限调试难llama.cppCPU/GPU/NPUQ4/Q5/Q8跨平台部署简单性能一般大模型吃力ONNX Runtime多平台INT8/INT4生态好兼容性强端侧优化不如专用引擎MNN阿里系芯片INT8/FP16轻量启动快社区相对小TensorRT-LLM 是 NVIDIA 官方方案配合 Jetson 使用效果最好。它的核心思路是把模型编译成针对特定 GPU 架构优化的引擎文件推理时直接加载引擎省去了图优化和算子选择的开销。编译过程需要指定最大 batch size、最大序列长度、量化精度等参数编译一次可能要十几分钟到半小时但编译后的推理速度比原生 PyTorch 快 3 到 5 倍。RKNN 是瑞芯微的 NPU 推理框架需要把模型先转成 ONNX再用 RKNN Toolkit 转成 RKNN 格式。转换过程中会遇到算子不支持的问题比如某些注意力变体、自定义激活函数等。遇到这种情况要么替换成支持的算子要么把不支持的层回退到 CPU 执行。回退到 CPU 会拖慢整体速度所以尽量在模型设计阶段就避开冷门算子。llama.cpp 的优势是部署极其简单编译一个二进制文件下载 GGUF 格式的模型就能跑。它支持 CPU、CUDA、Metal 等多种后端在 ARM CPU 上的 NEON 优化做得很好。缺点是性能上限不高7B 模型在 RK3588 的 CPU 上跑生成速度大概只有 2 到 3 token/s做 Agent 的实时决策会比较吃力。注意推理引擎的版本兼容性是个大坑。TensorRT-LLM 对 CUDA 版本、驱动版本、模型架构都有要求升级任何一个都可能导致编译失败。建议在 Docker 里固定一套版本组合不要轻易动。3.3 内存管理与 KV Cache 优化端侧设备内存紧张KV Cache 的管理直接影响能不能跑长序列。KV Cache 是 Transformer 推理时缓存的历史键值对避免每次生成新 token 都重新计算前面的内容。序列越长KV Cache 越大内存压力越大。优化 KV Cache 有几个常用手段。第一是分页管理类似操作系统的虚拟内存分页把 KV Cache 切成固定大小的块按需分配减少碎片。vLLM 的 PagedAttention 就是这个思路端侧也有类似实现。第二是量化 KV Cache把 KV Cache 从 FP16 压到 INT8内存直接减半精度损失很小。第三是滑动窗口注意力只保留最近 N 个 token 的 KV超出的丢弃适合不需要长程依赖的任务。第四是 MQA/GQA通过减少键值头的数量来降低 KV Cache 大小很多新模型默认就用 GQA。实际部署时我一般会先算一下最坏情况下的 KV Cache 占用。比如最大序列长度设 4096模型 32 层隐藏维度 4096GQA 分组数为 8FP16 精度那 KV Cache 大小约2 × 32 × 4096 × 4096 / 8 × 2 字节 ≈ 256MB。如果不用 GQA这个数字要乘以 8变成 2GB直接爆内存。所以选模型时一定要看它的注意力机制GQA 和 MQA 对端侧非常友好。实操心得Jetson 设备上可以用tegrastats实时监控内存和 GPU 占用跑推理的时候盯着这个输出能快速定位是权重占多了还是 KV Cache 涨太快。我习惯在推理脚本里加一个内存打点每生成 100 个 token 打印一次占用方便调参。4. 实操过程与核心环节实现4.1 环境准备与依赖安装以 Jetson Orin Nano 为例从零开始搭一套端侧 LLM 推理环境。假设你已经刷好了 JetPack 6.0系统是 Ubuntu 22.04CUDA 12.2TensorRT 8.6。第一步是确认硬件状态。跑jetson_release看 JetPack 版本跑nvcc --version看 CUDA 版本跑tegrastats看内存和功耗。这些信息决定了后面能装哪个版本的推理框架。第二步是安装 TensorRT-LLM。NVIDIA 官方提供了 Jetson 的预编译包但版本更新比较慢。我一般用源码编译虽然耗时但版本可控。编译前需要装好 CMake、Ninja、MPI 等依赖然后 clone TensorRT-LLM 仓库切到对应版本的分支执行编译脚本。编译过程在 Orin Nano 上大概要 40 分钟到 1 小时建议挂个散热风扇不然容易过热降频。第三步是准备模型。以 Qwen2.5-3B-Instruct 为例先从 HuggingFace 下载原始权重然后用 TensorRT-LLM 提供的转换脚本把权重转成引擎可读的格式。转换时需要指定量化精度我一般先用 INT8 做基线效果不够再试 INT4。# 下载模型权重 git clone https://huggingface.co/Qwen/Qwen2.5-3B-Instruct # 转换权重格式 python convert_checkpoint.py \ --model_dir ./Qwen2.5-3B-Instruct \ --output_dir ./trt_ckpt/int8 \ --dtype int8第四步是编译引擎。这一步会针对 Orin 的 GPU 架构做算子优化生成.engine文件。编译参数里最重要的是max_batch_size和max_seq_len前者决定并发能力后者决定能处理多长的输入。端侧设备建议max_batch_size设 1 到 4max_seq_len设 2048 到 4096再大内存扛不住。# 编译 TensorRT 引擎 trtllm-build \ --checkpoint_dir ./trt_ckpt/int8 \ --output_dir ./trt_engine/int8 \ --gemm_plugin int8 \ --max_batch_size 2 \ --max_seq_len 2048 \ --max_input_len 1024编译完成后会生成rank0.engine文件大小约 3GBINT8 量化的 3B 模型。加载引擎跑一次推理确认输出正常。4.2 推理服务封装与 Agent 集成引擎编译好之后需要封装成服务供 Agent 调用。最简单的方式是用 Python 写一个 HTTP 服务基于 FastAPI 或者 Flask加载引擎暴露一个/generate接口。from fastapi import FastAPI from pydantic import BaseModel import tensorrt_llm from tensorrt_llm.runtime import ModelRunner app FastAPI() runner ModelRunner.from_dir(./trt_engine/int8) class GenerateRequest(BaseModel): prompt: str max_new_tokens: int 256 app.post(/generate) def generate(req: GenerateRequest): output runner.generate( req.prompt, max_new_tokensreq.max_new_tokens, end_id151643, pad_id151643 ) return {text: output}这个服务启动后占用内存约 4GB留给 Agent 其他模块的空间还有 2GB 到 3GB。Agent 的决策逻辑可以通过 HTTP 调用这个服务把用户输入、工具描述、历史对话拼成 prompt让模型输出下一步动作。这里有个关键点prompt 的长度控制。Agent 的 prompt 通常包含系统提示、工具列表、历史对话、当前观察很容易超过 1024 个 token。如果超过max_input_len推理会报错。解决办法是在 Agent 侧做 prompt 压缩比如只保留最近 3 轮对话工具列表用简短描述或者用模型自己做摘要。实操心得Agent 场景下模型的输出格式稳定性比生成质量更重要。我一般会在 prompt 里加 few-shot 示例明确告诉模型输出 JSON 格式然后在服务端做格式校验解析失败就重试。这样比单纯依赖模型自觉靠谱得多。4.3 性能调优与延迟测量部署完成后必须做性能测量搞清楚瓶颈在哪。我通常关注四个指标首 token 延迟TTFT、生成速度tokens/s、内存峰值、功耗。TTFT 是从输入 prompt 到输出第一个 token 的时间主要受 prompt 长度和 prefill 计算量影响。生成速度是后续每个 token 的平均生成时间受模型大小和内存带宽影响。内存峰值用tegrastats或者nvidia-smi监控。功耗在 Jetson 上用tegrastats看在 RK3588 上用功率计测。以 Qwen2.5-3B INT8 在 Orin Nano 上的实测数据为例prompt 长度 512TTFT 约 800ms生成速度约 12 tokens/s内存峰值 4.2GB功耗约 12W。这个表现做简单的 Agent 决策够用但如果要做多轮工具调用延迟会累积用户体验会打折扣。优化方向有几个。一是减小 prompt 长度把系统提示精简工具描述用短句历史对话做摘要。二是用 INT4 量化生成速度能提升 30% 到 50%但精度会降。三是开启动态批处理如果有多个请求并发合并成一个 batch 推理吞吐量能提升。四是调整 GPU 频率Jetson 可以用nvpmodel和jetson_clocks锁定最高频率避免降频导致的性能波动。# 锁定 Jetson 最高性能模式 sudo nvpmodel -m 0 sudo jetson_clocks注意锁定最高频率会让功耗和温度上升如果设备散热不好长时间跑会触发过热保护。建议先测一下满载温度超过 80 度就得加散热片或者风扇。5. 常见问题与排查技巧实录5.1 模型加载失败与内存不足这是端侧部署最常见的问题。表现是加载引擎时直接报 OOM或者加载成功但推理到一半崩溃。原因通常是内存估算不准或者系统有其他进程占用。排查步骤先用free -h看系统总内存和可用内存再用tegrastats看 GPU 内存占用。如果可用内存小于模型权重的 1.5 倍基本就是内存不够。解决办法有换更小的模型、用更激进的量化、关掉不必要的系统服务、增加 swap但 swap 会拖慢速度只能应急。我遇到过一个坑Jetson 的共享内存默认只给 GPU 分配一部分需要在nvpmodel里调整。如果没调GPU 可用内存可能只有总内存的一半。用sudo nvpmodel -m 0切到最大性能模式GPU 内存分配会宽松一些。5.2 推理速度远低于预期如果实测速度比预期慢很多先确认是不是跑在正确的硬件上。有些推理框架默认用 CPU需要显式指定 GPU 或者 NPU。TensorRT-LLM 要确认引擎编译时用了正确的 GPU 架构RKNN 要确认模型转成了 RKNN 格式而不是跑 ONNX。另一个常见原因是热降频。Jetson 在温度超过 85 度时会自动降频性能可能掉一半。用tegrastats看温度如果持续在 80 度以上就得加散热。我在 Orin Nano 上加了一个 5V 小风扇满载温度从 90 度降到 65 度生成速度稳定了很多。还有可能是量化格式选错了。llama.cpp 的 Q4_0 比 Q4_K_M 快但精度差Q8_0 精度好但慢。TensorRT-LLM 的 INT8 比 INT4 慢但精度好。根据场景权衡不要盲目追求速度。5.3 Agent 调用超时与并发问题Agent 场景下模型推理只是链路中的一环还有工具调用、网络请求、结果解析等步骤。如果模型推理太慢整个 Agent 循环就会超时。我一般会在 Agent 侧设置超时时间比如单次推理超过 5 秒就放弃返回兜底结果。同时限制并发数端侧设备不适合高并发max_batch_size设 1 到 2 就够了再多会排队延迟反而更高。如果确实需要处理多个请求可以用队列串行化或者做请求合并。比如把多个用户的简单查询合并成一个 batch一次推理出所有结果。这种方式适合离线场景实时交互场景不太适用。问题现象可能原因排查方法解决方案加载引擎 OOM内存不足free -h、tegrastats换小模型、INT4 量化、关服务推理速度慢热降频、跑在 CPU看温度、看框架日志加散热、指定 GPU/NPU输出乱码量化精度太低对比 FP16 输出换 INT8 或 Q5_K_MAgent 超时推理延迟高测 TTFT 和生成速度减 prompt、限并发、加超时引擎编译失败版本不兼容看编译日志固定 Docker 版本组合5.4 模型输出格式不稳定Agent 依赖模型输出结构化数据比如 JSON但端侧小模型的格式遵循能力比大模型差很多。常见问题是输出多余的解释文字、JSON 格式错误、字段缺失。解决办法有几个。一是用 few-shot 示例在 prompt 里给 2 到 3 个输入输出对让模型模仿格式。二是用 grammar 约束llama.cpp 支持 GBNF 语法可以强制模型只输出符合 JSON 语法的内容。TensorRT-LLM 也有类似的 logits 处理器。三是后处理兜底用正则提取 JSON 部分解析失败就重试或者返回默认值。我实测下来few-shot 加后处理兜底是最稳的组合。grammar 约束虽然理论上最可靠但配置复杂而且会稍微拖慢速度。对于端侧场景简单可靠比理论最优更重要。6. 端侧 LLM 部署的扩展方向6.1 多模型协同与模型路由单一模型很难同时满足所有任务。端侧 Agent 可能需要一个小的意图识别模型、一个中等规模的对话模型、一个专门的工具调用模型。多模型协同的思路是用小模型做快速筛选把复杂请求路由给大模型。比如用户输入先经过一个 0.5B 的分类模型判断是闲聊、查询还是工具调用。闲聊用 1B 模型回复查询用 3B 模型工具调用用专门的 function calling 模型。这样大部分请求由小模型处理延迟低、功耗低只有少数复杂请求才动用大模型。模型路由的实现可以用简单的规则引擎也可以用一个小分类模型。端侧设备内存有限同时加载多个模型不现实所以通常是按需加载、用完卸载。加载和卸载有开销需要做缓存策略把常用的模型常驻内存。6.2 端云协同的混合架构完全端侧部署受限于硬件有些任务确实跑不动。端云协同的思路是简单任务端侧处理复杂任务上云。这样既保证了隐私和离线可用性又能在需要时借助云端算力。架构上端侧跑一个轻量模型做意图识别和简单回复当识别到复杂任务比如长文档总结、复杂推理时把请求转发到云端。云端返回结果后端侧再做后处理和展示。关键是设计好路由策略什么任务端侧处理、什么任务上云需要根据延迟要求、隐私要求和成本来权衡。这种架构的挑战在于状态同步和体验一致性。端侧和云端的模型能力不同输出风格可能不一致需要做对齐。另外网络不稳定时要有降级策略不能因为云端不可用就整个服务挂掉。6.3 模型更新与 OTA 策略端侧设备部署后模型可能需要更新。OTA 更新的挑战是模型文件大几个 GB网络带宽有限更新过程中不能影响服务。我一般建议做差分更新只传输变化的部分。如果模型是量化后的权重的变化可能不大差分能省不少流量。另外更新要支持回滚新模型有问题能快速切回旧版本。更新时机选在设备空闲时比如夜间或者充电时避免影响正常使用。模型版本管理也很重要。每个模型版本要有明确的标识记录量化精度、编译参数、适用场景。设备上报当前版本服务端决定是否推送更新。这样能避免版本混乱导致的问题。7. 一些实操中的个人体会端侧 LLM 部署这件事我最大的体会是不要追求一步到位。很多人一上来就想在端侧跑 7B 甚至 13B 模型结果卡在内存和速度上项目推进不下去。正确的做法是先跑通最小闭环用一个 1B 到 3B 的模型INT4 量化确认整条链路能工作然后再逐步优化。另一个体会是测量比优化重要。不要凭感觉猜瓶颈在哪一定要用工具测。TTFT、生成速度、内存峰值、功耗这四个指标测清楚优化方向自然就明确了。我见过太多团队花大量时间调参结果发现瓶颈根本不在模型上而在数据预处理或者网络传输。还有就是散热不能省。端侧设备体积小散热空间有限但 LLM 推理是持续高负载发热很厉害。Jetson Orin Nano 不加散热满载几分钟就降频。加一个几十块钱的小风扇性能稳定性提升非常明显。这个投入产出比很高不要省。最后模型选型要看社区活跃度。端侧部署会遇到各种奇怪的问题社区活跃的模型比如 Qwen、Llama 系列遇到问题容易找到解决方案冷门模型可能卡在一个算子上一周都搞不定。选模型时除了看效果也要看生态。如果后续要扩展我建议从两个方向入手一是尝试更激进的量化方案比如 AWQ 或者 GPTQ在精度和速度之间找更好的平衡点二是研究投机采样用一个小模型做 draft大模型做 verify能在不损失精度的情况下提升生成速度。这两个方向在端侧都很有潜力值得花时间折腾。 端侧LLM部署实战：从量化到推理引擎的完整链路
1. 端侧 LLM 部署到底在解决什么问题端侧 Agent 这个话题最近一年被聊得很多但真正落到工程上第一道坎从来不是 Agent 的编排逻辑而是模型怎么塞进设备里还能跑得动。我见过太多团队在云端把 Agent 流程跑通之后一到端侧就卡在内存、算力、功耗这三座大山面前。端侧 LLM 部署要解决的核心矛盾其实就一句话在有限的硬件资源下让一个几十亿参数的模型以可接受的延迟和功耗完成推理。这件事为什么现在变得重要因为 Agent 的本质是“感知-决策-执行”的闭环如果每一轮决策都要把数据传到云端再等结果回来那延迟、隐私、离线可用性全都会出问题。端侧 Agent 的价值恰恰在于把决策能力下沉到设备本地而 LLM 作为 Agent 的“大脑”必须跟着一起下沉。这就是端侧 LLM 部署存在的意义。适合看这篇内容的人我大致分三类一是正在做端侧 AI 硬件产品的工程师比如做机器人、智能座舱、工业巡检设备的二是想把本地大模型跑起来的开发者手里有 Jetson Orin、RK3588 这类板子但不知道从哪下手三是做 Agent 应用但对底层推理链路一知半解的想搞清楚模型部署这一层到底有哪些坑。不管你属于哪一类这篇内容都会从选型、量化、推理引擎、内存管理到实际踩坑把整条链路拆开讲清楚。需要提前说明的是端侧 LLM 部署没有“一招鲜”的方案。不同芯片平台、不同模型规模、不同延迟要求对应的技术选型完全不同。我会尽量把每个决策背后的逻辑讲透让你能根据自己的场景做判断而不是照搬某一套配置。2. 端侧 LLM 部署的整体设计思路2.1 为什么不能直接把云端模型搬到端侧很多人第一反应是云端跑得好好的模型直接下载到设备上不就行了实际操作下来会发现根本行不通。一个 7B 参数的模型如果用 FP16 精度存储光权重就要占 14GB 左右的内存。而典型的端侧设备比如 Jetson Orin Nano 只有 8GB 共享内存RK3588 开发板通常配 4GB 到 8GB LPDDR。模型还没加载完内存就爆了。除了内存还有算力问题。云端一张 A100 的 FP16 算力是 312 TFLOPS而 Jetson Orin Nano 大概只有 20 TOPSINT8差距在十五倍以上。这意味着同样的模型端侧推理延迟可能是云端的几十倍。再加上端侧设备通常有功耗墙不能像服务器那样随便堆散热持续高负载推理会导致降频。所以端侧 LLM 部署的第一原则是模型必须经过压缩和适配不能直接搬运。压缩的手段包括量化、剪枝、知识蒸馏适配的手段包括选择适合端侧硬件的推理引擎、调整算子实现、优化内存布局。这些工作构成了端侧部署的核心技术栈。2.2 端侧 LLM 部署的三种典型路线根据硬件平台和需求的不同我把端侧 LLM 部署分成三条路线每条路线的技术选型和优化重点都不一样。第一条是GPU 路线代表平台是 NVIDIA Jetson 系列。Jetson Orin 系列自带 CUDA 和 TensorRT 支持生态最成熟。你可以用 TensorRT-LLM 把模型编译成引擎推理速度在端侧设备里属于第一梯队。缺点是功耗偏高Orin NX 满载大概 25WOrin Nano 也要 10W 到 15W对电池供电的设备不太友好。第二条是NPU 路线代表平台是 RK3588、瑞芯微系列、地平线征程等。这类芯片的 NPU 算力通常在 6 TOPS 到 16 TOPS 之间功耗控制得很好RK3588 的 NPU 满载也就 5W 左右。但 NPU 的算子支持不如 GPU 全面模型需要经过转换工具链比如 RKNN重新编译遇到不支持的算子就得手动替换或者回退到 CPU调试成本比较高。第三条是CPU 路线代表场景是低功耗 MCU 或者手机端。CPU 推理速度最慢但兼容性最好适合跑 1B 以下的小模型或者做兜底方案。常用的推理框架有 llama.cpp、ONNX Runtime 等。llama.cpp 在 ARM CPU 上的优化做得不错配合 4-bit 量化跑 1B 到 3B 的模型勉强能用。选哪条路线取决于你的延迟要求、功耗预算和模型规模。我一般建议如果设备有独立供电且对延迟敏感优先考虑 Jetson TensorRT如果是电池供电的移动设备优先考虑 RK3588 RKNN如果只是做原型验证或者模型很小CPU 方案也能凑合。2.3 模型规模与硬件资源的匹配逻辑选模型的时候不能只看效果得先算一笔账。端侧设备的内存是硬约束模型权重、KV Cache、激活值、系统占用加起来不能超过可用内存。我常用的估算方法是模型权重内存 ≈ 参数量 × 每参数字节数。FP16 是 2 字节INT8 是 1 字节INT4 是 0.5 字节。一个 7B 模型INT4 量化后权重约 3.5GBINT8 约 7GBFP16 约 14GB。KV Cache 的大小取决于序列长度和层数粗略估算公式是2 × 层数 × 隐藏维度 × 序列长度 × 精度字节数。以 7B 模型32 层隐藏维度 4096为例序列长度 2048FP16 精度下 KV Cache 约 1GBINT8 约 0.5GB。把这两部分加起来再加上推理框架本身和系统占用通常 1GB 到 2GB就能判断设备能不能跑。比如 8GB 内存的 Jetson Orin Nano跑 INT4 量化的 7B 模型权重 3.5GB KV Cache 0.5GB 系统 2GB 6GB勉强能跑但留给其他进程的空间就很紧张了。如果换成 3B 模型INT4 量化后权重约 1.5GB整体占用 4GB 左右就宽裕很多。注意很多开发板的“8GB 内存”是 CPU 和 GPU 共享的实际可用内存可能只有 6GB 到 7GB。选型时一定要留出至少 20% 的余量否则跑起来容易 OOM。3. 核心细节解析与实操要点3.1 量化端侧部署的第一道工序量化是端侧 LLM 部署绕不开的一步。它的本质是把模型权重和激活值从高精度浮点数映射到低精度整数从而减少内存占用和计算量。常见的量化精度有 FP16、INT8、INT4端侧最常用的是 INT8 和 INT4。INT8 量化的原理是把 FP16 的权重线性映射到 -128 到 127 的整数范围推理时再反量化回浮点做计算。这种方式的精度损失通常很小困惑度Perplexity上升一般在 0.1 到 0.5 之间实际使用中几乎感觉不到差异。INT4 量化更激进把权重压缩到 16 个离散值内存直接减半但精度损失会明显一些困惑度可能上升 1 到 3。对于 Agent 场景如果任务对精度要求高比如代码生成、数学推理建议用 INT8如果只是做意图识别、简单问答INT4 完全够用。量化的实现方式分两种训练后量化PTQ和量化感知训练QAT。PTQ 不需要重新训练直接对训练好的模型做校准和转换成本低适合快速落地。QAT 在训练过程中模拟量化误差精度更好但需要重新训练成本高。端侧部署绝大多数情况用 PTQ 就够了。具体操作上不同推理框架的量化工具不一样。TensorRT-LLM 用trtllm-build配合量化校准数据集llama.cpp 用quantize工具支持 Q4_0、Q4_K_M、Q5_K_M 等多种量化格式ONNX Runtime 用onnxruntime.quantization模块做动态或静态量化。我一般推荐先用 llama.cpp 的 Q4_K_M 格式做快速验证这个格式在精度和速度之间平衡得比较好社区反馈也最稳定。实操心得量化校准数据集的选取很关键。不要随便拿几百条通用语料就完事最好用你的实际业务数据做校准这样量化后的模型在你的场景下精度损失最小。我试过用通用语料校准的 INT4 模型在专业领域问答上错误率比用业务数据校准的高出近一倍。3.2 推理引擎选型TensorRT、RKNN 还是 llama.cpp推理引擎的选择直接决定了推理速度和开发效率。我把几个主流方案做个对比方便你根据平台选型。推理引擎适用平台支持量化优点缺点TensorRT-LLMNVIDIA GPUINT8/INT4/FP8性能最强算子优化好编译复杂只支持 NVIDIARKNN瑞芯微 NPUINT8/INT4功耗低集成度高算子支持有限调试难llama.cppCPU/GPU/NPUQ4/Q5/Q8跨平台部署简单性能一般大模型吃力ONNX Runtime多平台INT8/INT4生态好兼容性强端侧优化不如专用引擎MNN阿里系芯片INT8/FP16轻量启动快社区相对小TensorRT-LLM 是 NVIDIA 官方方案配合 Jetson 使用效果最好。它的核心思路是把模型编译成针对特定 GPU 架构优化的引擎文件推理时直接加载引擎省去了图优化和算子选择的开销。编译过程需要指定最大 batch size、最大序列长度、量化精度等参数编译一次可能要十几分钟到半小时但编译后的推理速度比原生 PyTorch 快 3 到 5 倍。RKNN 是瑞芯微的 NPU 推理框架需要把模型先转成 ONNX再用 RKNN Toolkit 转成 RKNN 格式。转换过程中会遇到算子不支持的问题比如某些注意力变体、自定义激活函数等。遇到这种情况要么替换成支持的算子要么把不支持的层回退到 CPU 执行。回退到 CPU 会拖慢整体速度所以尽量在模型设计阶段就避开冷门算子。llama.cpp 的优势是部署极其简单编译一个二进制文件下载 GGUF 格式的模型就能跑。它支持 CPU、CUDA、Metal 等多种后端在 ARM CPU 上的 NEON 优化做得很好。缺点是性能上限不高7B 模型在 RK3588 的 CPU 上跑生成速度大概只有 2 到 3 token/s做 Agent 的实时决策会比较吃力。注意推理引擎的版本兼容性是个大坑。TensorRT-LLM 对 CUDA 版本、驱动版本、模型架构都有要求升级任何一个都可能导致编译失败。建议在 Docker 里固定一套版本组合不要轻易动。3.3 内存管理与 KV Cache 优化端侧设备内存紧张KV Cache 的管理直接影响能不能跑长序列。KV Cache 是 Transformer 推理时缓存的历史键值对避免每次生成新 token 都重新计算前面的内容。序列越长KV Cache 越大内存压力越大。优化 KV Cache 有几个常用手段。第一是分页管理类似操作系统的虚拟内存分页把 KV Cache 切成固定大小的块按需分配减少碎片。vLLM 的 PagedAttention 就是这个思路端侧也有类似实现。第二是量化 KV Cache把 KV Cache 从 FP16 压到 INT8内存直接减半精度损失很小。第三是滑动窗口注意力只保留最近 N 个 token 的 KV超出的丢弃适合不需要长程依赖的任务。第四是 MQA/GQA通过减少键值头的数量来降低 KV Cache 大小很多新模型默认就用 GQA。实际部署时我一般会先算一下最坏情况下的 KV Cache 占用。比如最大序列长度设 4096模型 32 层隐藏维度 4096GQA 分组数为 8FP16 精度那 KV Cache 大小约2 × 32 × 4096 × 4096 / 8 × 2 字节 ≈ 256MB。如果不用 GQA这个数字要乘以 8变成 2GB直接爆内存。所以选模型时一定要看它的注意力机制GQA 和 MQA 对端侧非常友好。实操心得Jetson 设备上可以用tegrastats实时监控内存和 GPU 占用跑推理的时候盯着这个输出能快速定位是权重占多了还是 KV Cache 涨太快。我习惯在推理脚本里加一个内存打点每生成 100 个 token 打印一次占用方便调参。4. 实操过程与核心环节实现4.1 环境准备与依赖安装以 Jetson Orin Nano 为例从零开始搭一套端侧 LLM 推理环境。假设你已经刷好了 JetPack 6.0系统是 Ubuntu 22.04CUDA 12.2TensorRT 8.6。第一步是确认硬件状态。跑jetson_release看 JetPack 版本跑nvcc --version看 CUDA 版本跑tegrastats看内存和功耗。这些信息决定了后面能装哪个版本的推理框架。第二步是安装 TensorRT-LLM。NVIDIA 官方提供了 Jetson 的预编译包但版本更新比较慢。我一般用源码编译虽然耗时但版本可控。编译前需要装好 CMake、Ninja、MPI 等依赖然后 clone TensorRT-LLM 仓库切到对应版本的分支执行编译脚本。编译过程在 Orin Nano 上大概要 40 分钟到 1 小时建议挂个散热风扇不然容易过热降频。第三步是准备模型。以 Qwen2.5-3B-Instruct 为例先从 HuggingFace 下载原始权重然后用 TensorRT-LLM 提供的转换脚本把权重转成引擎可读的格式。转换时需要指定量化精度我一般先用 INT8 做基线效果不够再试 INT4。# 下载模型权重 git clone https://huggingface.co/Qwen/Qwen2.5-3B-Instruct # 转换权重格式 python convert_checkpoint.py \ --model_dir ./Qwen2.5-3B-Instruct \ --output_dir ./trt_ckpt/int8 \ --dtype int8第四步是编译引擎。这一步会针对 Orin 的 GPU 架构做算子优化生成.engine文件。编译参数里最重要的是max_batch_size和max_seq_len前者决定并发能力后者决定能处理多长的输入。端侧设备建议max_batch_size设 1 到 4max_seq_len设 2048 到 4096再大内存扛不住。# 编译 TensorRT 引擎 trtllm-build \ --checkpoint_dir ./trt_ckpt/int8 \ --output_dir ./trt_engine/int8 \ --gemm_plugin int8 \ --max_batch_size 2 \ --max_seq_len 2048 \ --max_input_len 1024编译完成后会生成rank0.engine文件大小约 3GBINT8 量化的 3B 模型。加载引擎跑一次推理确认输出正常。4.2 推理服务封装与 Agent 集成引擎编译好之后需要封装成服务供 Agent 调用。最简单的方式是用 Python 写一个 HTTP 服务基于 FastAPI 或者 Flask加载引擎暴露一个/generate接口。from fastapi import FastAPI from pydantic import BaseModel import tensorrt_llm from tensorrt_llm.runtime import ModelRunner app FastAPI() runner ModelRunner.from_dir(./trt_engine/int8) class GenerateRequest(BaseModel): prompt: str max_new_tokens: int 256 app.post(/generate) def generate(req: GenerateRequest): output runner.generate( req.prompt, max_new_tokensreq.max_new_tokens, end_id151643, pad_id151643 ) return {text: output}这个服务启动后占用内存约 4GB留给 Agent 其他模块的空间还有 2GB 到 3GB。Agent 的决策逻辑可以通过 HTTP 调用这个服务把用户输入、工具描述、历史对话拼成 prompt让模型输出下一步动作。这里有个关键点prompt 的长度控制。Agent 的 prompt 通常包含系统提示、工具列表、历史对话、当前观察很容易超过 1024 个 token。如果超过max_input_len推理会报错。解决办法是在 Agent 侧做 prompt 压缩比如只保留最近 3 轮对话工具列表用简短描述或者用模型自己做摘要。实操心得Agent 场景下模型的输出格式稳定性比生成质量更重要。我一般会在 prompt 里加 few-shot 示例明确告诉模型输出 JSON 格式然后在服务端做格式校验解析失败就重试。这样比单纯依赖模型自觉靠谱得多。4.3 性能调优与延迟测量部署完成后必须做性能测量搞清楚瓶颈在哪。我通常关注四个指标首 token 延迟TTFT、生成速度tokens/s、内存峰值、功耗。TTFT 是从输入 prompt 到输出第一个 token 的时间主要受 prompt 长度和 prefill 计算量影响。生成速度是后续每个 token 的平均生成时间受模型大小和内存带宽影响。内存峰值用tegrastats或者nvidia-smi监控。功耗在 Jetson 上用tegrastats看在 RK3588 上用功率计测。以 Qwen2.5-3B INT8 在 Orin Nano 上的实测数据为例prompt 长度 512TTFT 约 800ms生成速度约 12 tokens/s内存峰值 4.2GB功耗约 12W。这个表现做简单的 Agent 决策够用但如果要做多轮工具调用延迟会累积用户体验会打折扣。优化方向有几个。一是减小 prompt 长度把系统提示精简工具描述用短句历史对话做摘要。二是用 INT4 量化生成速度能提升 30% 到 50%但精度会降。三是开启动态批处理如果有多个请求并发合并成一个 batch 推理吞吐量能提升。四是调整 GPU 频率Jetson 可以用nvpmodel和jetson_clocks锁定最高频率避免降频导致的性能波动。# 锁定 Jetson 最高性能模式 sudo nvpmodel -m 0 sudo jetson_clocks注意锁定最高频率会让功耗和温度上升如果设备散热不好长时间跑会触发过热保护。建议先测一下满载温度超过 80 度就得加散热片或者风扇。5. 常见问题与排查技巧实录5.1 模型加载失败与内存不足这是端侧部署最常见的问题。表现是加载引擎时直接报 OOM或者加载成功但推理到一半崩溃。原因通常是内存估算不准或者系统有其他进程占用。排查步骤先用free -h看系统总内存和可用内存再用tegrastats看 GPU 内存占用。如果可用内存小于模型权重的 1.5 倍基本就是内存不够。解决办法有换更小的模型、用更激进的量化、关掉不必要的系统服务、增加 swap但 swap 会拖慢速度只能应急。我遇到过一个坑Jetson 的共享内存默认只给 GPU 分配一部分需要在nvpmodel里调整。如果没调GPU 可用内存可能只有总内存的一半。用sudo nvpmodel -m 0切到最大性能模式GPU 内存分配会宽松一些。5.2 推理速度远低于预期如果实测速度比预期慢很多先确认是不是跑在正确的硬件上。有些推理框架默认用 CPU需要显式指定 GPU 或者 NPU。TensorRT-LLM 要确认引擎编译时用了正确的 GPU 架构RKNN 要确认模型转成了 RKNN 格式而不是跑 ONNX。另一个常见原因是热降频。Jetson 在温度超过 85 度时会自动降频性能可能掉一半。用tegrastats看温度如果持续在 80 度以上就得加散热。我在 Orin Nano 上加了一个 5V 小风扇满载温度从 90 度降到 65 度生成速度稳定了很多。还有可能是量化格式选错了。llama.cpp 的 Q4_0 比 Q4_K_M 快但精度差Q8_0 精度好但慢。TensorRT-LLM 的 INT8 比 INT4 慢但精度好。根据场景权衡不要盲目追求速度。5.3 Agent 调用超时与并发问题Agent 场景下模型推理只是链路中的一环还有工具调用、网络请求、结果解析等步骤。如果模型推理太慢整个 Agent 循环就会超时。我一般会在 Agent 侧设置超时时间比如单次推理超过 5 秒就放弃返回兜底结果。同时限制并发数端侧设备不适合高并发max_batch_size设 1 到 2 就够了再多会排队延迟反而更高。如果确实需要处理多个请求可以用队列串行化或者做请求合并。比如把多个用户的简单查询合并成一个 batch一次推理出所有结果。这种方式适合离线场景实时交互场景不太适用。问题现象可能原因排查方法解决方案加载引擎 OOM内存不足free -h、tegrastats换小模型、INT4 量化、关服务推理速度慢热降频、跑在 CPU看温度、看框架日志加散热、指定 GPU/NPU输出乱码量化精度太低对比 FP16 输出换 INT8 或 Q5_K_MAgent 超时推理延迟高测 TTFT 和生成速度减 prompt、限并发、加超时引擎编译失败版本不兼容看编译日志固定 Docker 版本组合5.4 模型输出格式不稳定Agent 依赖模型输出结构化数据比如 JSON但端侧小模型的格式遵循能力比大模型差很多。常见问题是输出多余的解释文字、JSON 格式错误、字段缺失。解决办法有几个。一是用 few-shot 示例在 prompt 里给 2 到 3 个输入输出对让模型模仿格式。二是用 grammar 约束llama.cpp 支持 GBNF 语法可以强制模型只输出符合 JSON 语法的内容。TensorRT-LLM 也有类似的 logits 处理器。三是后处理兜底用正则提取 JSON 部分解析失败就重试或者返回默认值。我实测下来few-shot 加后处理兜底是最稳的组合。grammar 约束虽然理论上最可靠但配置复杂而且会稍微拖慢速度。对于端侧场景简单可靠比理论最优更重要。6. 端侧 LLM 部署的扩展方向6.1 多模型协同与模型路由单一模型很难同时满足所有任务。端侧 Agent 可能需要一个小的意图识别模型、一个中等规模的对话模型、一个专门的工具调用模型。多模型协同的思路是用小模型做快速筛选把复杂请求路由给大模型。比如用户输入先经过一个 0.5B 的分类模型判断是闲聊、查询还是工具调用。闲聊用 1B 模型回复查询用 3B 模型工具调用用专门的 function calling 模型。这样大部分请求由小模型处理延迟低、功耗低只有少数复杂请求才动用大模型。模型路由的实现可以用简单的规则引擎也可以用一个小分类模型。端侧设备内存有限同时加载多个模型不现实所以通常是按需加载、用完卸载。加载和卸载有开销需要做缓存策略把常用的模型常驻内存。6.2 端云协同的混合架构完全端侧部署受限于硬件有些任务确实跑不动。端云协同的思路是简单任务端侧处理复杂任务上云。这样既保证了隐私和离线可用性又能在需要时借助云端算力。架构上端侧跑一个轻量模型做意图识别和简单回复当识别到复杂任务比如长文档总结、复杂推理时把请求转发到云端。云端返回结果后端侧再做后处理和展示。关键是设计好路由策略什么任务端侧处理、什么任务上云需要根据延迟要求、隐私要求和成本来权衡。这种架构的挑战在于状态同步和体验一致性。端侧和云端的模型能力不同输出风格可能不一致需要做对齐。另外网络不稳定时要有降级策略不能因为云端不可用就整个服务挂掉。6.3 模型更新与 OTA 策略端侧设备部署后模型可能需要更新。OTA 更新的挑战是模型文件大几个 GB网络带宽有限更新过程中不能影响服务。我一般建议做差分更新只传输变化的部分。如果模型是量化后的权重的变化可能不大差分能省不少流量。另外更新要支持回滚新模型有问题能快速切回旧版本。更新时机选在设备空闲时比如夜间或者充电时避免影响正常使用。模型版本管理也很重要。每个模型版本要有明确的标识记录量化精度、编译参数、适用场景。设备上报当前版本服务端决定是否推送更新。这样能避免版本混乱导致的问题。7. 一些实操中的个人体会端侧 LLM 部署这件事我最大的体会是不要追求一步到位。很多人一上来就想在端侧跑 7B 甚至 13B 模型结果卡在内存和速度上项目推进不下去。正确的做法是先跑通最小闭环用一个 1B 到 3B 的模型INT4 量化确认整条链路能工作然后再逐步优化。另一个体会是测量比优化重要。不要凭感觉猜瓶颈在哪一定要用工具测。TTFT、生成速度、内存峰值、功耗这四个指标测清楚优化方向自然就明确了。我见过太多团队花大量时间调参结果发现瓶颈根本不在模型上而在数据预处理或者网络传输。还有就是散热不能省。端侧设备体积小散热空间有限但 LLM 推理是持续高负载发热很厉害。Jetson Orin Nano 不加散热满载几分钟就降频。加一个几十块钱的小风扇性能稳定性提升非常明显。这个投入产出比很高不要省。最后模型选型要看社区活跃度。端侧部署会遇到各种奇怪的问题社区活跃的模型比如 Qwen、Llama 系列遇到问题容易找到解决方案冷门模型可能卡在一个算子上一周都搞不定。选模型时除了看效果也要看生态。如果后续要扩展我建议从两个方向入手一是尝试更激进的量化方案比如 AWQ 或者 GPTQ在精度和速度之间找更好的平衡点二是研究投机采样用一个小模型做 draft大模型做 verify能在不损失精度的情况下提升生成速度。这两个方向在端侧都很有潜力值得花时间折腾。