企业官网建设流程全解析

端侧 Agent 这件事，真正开始动手的人很快会发现一个残酷的现实：模型跑不起来，后面所有的规划、工具调用、记忆管理都是空谈。我见过太多团队在云端把 Agent 逻辑调得漂漂亮亮，一到端侧部署就卡在第一步——模型加载失败、显存爆掉、推理速度慢到没法交互。这一篇就专门聊端侧 LLM 部署这件事，把从模型选型、量化、推理引擎到内存调优的完整链路拆开讲，适合正在做端侧 Agent 落地、或者准备把大模型塞进边缘设备的开发者参考。不管你是刚接触端侧部署的新手，还是已经踩过几轮坑的老手，这里面的选型逻辑和实操细节应该都能对上你的场景。

1. 端侧 LLM 部署到底难在哪

1.1 端侧和云端的本质差异不在算力，在约束条件

很多人第一次做端侧部署，习惯性地把云端那套思路搬过来：选个最大的模型、拉满精度、跑个推理服务就完事。结果一上设备就发现完全不是一回事。云端你有几乎无限的显存可以堆，有稳定的供电和散热，有高速网络可以随时拉取数据。端侧这些条件全部反过来——内存可能只有 4GB 到 16GB，功耗被电池或者散热模组死死限制，网络时断时续甚至完全离线。

这些约束直接决定了端侧 LLM 部署的核心矛盾：你必须在模型能力、推理速度、内存占用这三者之间做取舍，而且这个取舍没有标准答案，完全取决于你的 Agent 要干什么。一个只做意图分类和简单问答的 Agent，和一个需要做多轮复杂推理、调用十几个工具的 Agent，对模型的要求天差地别。

我自己的经验是，先别急着选模型，先把 Agent 的任务清单列出来，标注每个任务对模型能力的最低要求，然后再倒推需要多大的模型。这个顺序反了，后面返工的概率极高。

1.2 端侧部署的三个硬指标：首 token 延迟、生成速度、内存峰值

评估一个端侧 LLM 部署方案好不好，我一般看三个指标，这三个指标直接决定用户体验能不能接受。

首 token 延迟（TTFT）是从用户发出请求到模型吐出第一个 token 的时间。这个指标对交互式 Agent 特别关键，超过 1 秒用户就会觉得卡，超过 2 秒基本就失去耐心了。端侧设备因为算力有限，TTFT 往往是大头。

生成速度（TPS）是每秒能生成多少个 token。中文场景下，人正常阅读速度大概是每秒 5 到 8 个字，所以生成速度低于 5 token/s 就会明显感觉模型在"挤牙膏"。端侧设备上，7B 级别的模型在好的 NPU 上能跑到 15 到 30 token/s，在纯 CPU 上可能只有 2 到 5 token/s。

内存峰值是推理过程中占用内存的最高点，不是模型文件大小。很多人只看模型文件是 4GB 就以为 4GB 内存够用，实际上推理时的 KV Cache、中间激活值、框架开销加起来可能是模型文件的两三倍。这个坑我踩过不止一次。

1.3 为什么端侧 Agent 对 LLM 的要求和纯聊天不一样

纯聊天场景下，模型慢一点、偶尔答非所问，用户还能忍。但 Agent 场景完全不能接受这些。Agent 需要模型稳定输出结构化的工具调用指令，需要模型在多轮对话中保持上下文一致性，需要模型在有限的上下文窗口里塞进系统提示、工具定义、历史对话和当前任务。

这就带来一个很现实的问题：端侧 Agent 用的 LLM，往往需要比同级别聊天模型更强的指令遵循能力和结构化输出能力。一个 3B 的模型如果指令遵循做得好，在 Agent 场景下可能比一个 7B 但输出随意的模型更实用。这也是为什么现在很多端侧 Agent 方案会选择专门做过指令微调的小模型，而不是直接拿通用大模型来量化。

2. 模型选型：不是越大越好，是越合适越好

2.1 参数量档位和适用场景的对应关系

端侧 LLM 的参数量选择，基本可以按下面这个档位来划分，这是我实际项目中总结出来的经验值，不是理论推导。

0.5B 到 1.5B 档位：适合做意图识别、槽位填充、简单分类、文本改写这类任务。这个档位的模型在端侧设备上跑起来毫无压力，内存占用通常在 1GB 以内，生成速度可以轻松跑到 30 token/s 以上。缺点是复杂推理能力弱，多轮对话容易跑偏。如果你的 Agent 主要是做任务路由和简单问答，这个档位完全够用。

1.5B 到 4B 档位：这是目前端侧 Agent 的甜点区。这个档位的模型能处理中等复杂度的推理任务，能稳定输出 JSON 格式的工具调用，多轮对话也能保持基本的一致性。量化后模型文件在 1GB 到 3GB 之间，内存峰值控制在 4GB 以内，在主流端侧芯片上生成速度能到 10 到 20 token/s。我个人最推荐这个档位作为端侧 Agent 的主力模型。

4B 到 8B 档位：适合需要较强推理能力的场景，比如复杂的多步规划、代码生成、长文档理解。这个档位对硬件要求明显提高，量化后模型文件 3GB 到 6GB，内存峰值可能到 8GB 以上。只有在设备内存 16GB 以上、有独立 NPU 或者较强 GPU 的情况下才建议上这个档位。

8B 以上：端侧部署这个档位要非常谨慎。除非你的设备是高性能边缘服务器级别，否则推理速度会很难看，内存也容易爆。我一般不建议在真正的端侧设备上跑 8B 以上的模型，除非做了非常激进的量化。

2.2 量化方式的选择：GGUF、AWQ、GPTQ 到底怎么选

量化是端侧部署绕不开的一步，核心思路是用更低的数值精度来表示模型权重，从而减小模型体积、降低内存占用、提升推理速度。代价是精度损失，但好的量化方式能把损失控制在可接受范围内。

GGUF是目前端侧部署最主流的格式，配合 llama.cpp 或者 Ollama 使用。它的优势是支持多种量化等级（从 Q2 到 Q8），可以在 CPU 上高效推理，对硬件要求最低。缺点是 GPU 加速支持相对弱一些，在纯 GPU 场景下不如其他格式。我一般用 Q4_K_M 这个等级，它在体积和精度之间平衡得最好，4B 模型量化后大概 2.5GB。

AWQ是激活感知的权重量化，主要针对 GPU 推理优化。它的优势是在 4bit 量化下精度损失很小，推理速度快，适合有 GPU 或 NPU 的设备。缺点是需要特定的推理框架支持，部署链路比 GGUF 复杂一些。

GPTQ是另一种主流的 GPU 量化方案，和 AWQ 定位类似。实际使用中两者差距不大，选哪个主要看你的推理框架支持哪个。我个人的经验是，如果设备有较强的 GPU，优先考虑 AWQ；如果主要靠 CPU 推理，GGUF 是更稳妥的选择。

2.3 一个容易被忽略的点：tokenizer 和上下文窗口

选模型的时候，大家盯着参数量和量化方式看，但 tokenizer 和上下文窗口这两个东西经常被忽略，而它们对端侧 Agent 的影响其实很大。

tokenizer 的效率直接决定同样的文本会消耗多少 token。中文场景下，不同模型的 tokenizer 效率差异可以到 30% 以上。一个中文 tokenizer 做得好的模型，同样的对话历史可能只占 500 token，而做得差的要占 700 token。端侧设备上下文窗口本来就紧张，这个差异会被放大。选模型的时候，建议实际拿你的业务文本测一下 token 数，别只看模型宣传的上下文长度。

上下文窗口不是越大越好。上下文窗口越大，KV Cache 占用的内存越多。一个 32K 上下文窗口的模型，在长对话下 KV Cache 可能吃掉好几个 GB 内存。端侧 Agent 实际用到的上下文往往没那么长，我一般会把上下文窗口限制在 4K 到 8K，够用就行，省下来的内存留给系统和工具调用。

提示：选模型时先确认它的 tokenizer 对中文是否友好，再确认上下文窗口的实际内存开销。这两个因素在端侧场景下的重要性不亚于参数量。

3. 推理引擎：把模型真正跑起来的那一层

3.1 llama.cpp 和 Ollama：CPU 场景的稳妥选择

llama.cpp 是端侧 LLM 推理的基石项目，用 C++ 写的，对硬件要求极低，能在各种 CPU 上跑起来，还支持部分 GPU 加速。它的核心优势是 GGUF 格式的原生支持、极低的内存开销、以及跨平台的可移植性。如果你要在资源受限的端侧设备上部署，llama.cpp 基本是首选。

Ollama 是在 llama.cpp 基础上封装的一层，提供了更友好的模型管理和 API 接口。它的优势是上手快，一条命令就能拉模型跑起来，适合快速验证。缺点是封装层带来了一些额外的内存开销，而且对推理参数的精细控制不如直接用 llama.cpp 灵活。我的建议是，原型验证阶段用 Ollama 快速跑通，正式部署时如果对内存和性能有严格要求，再切到 llama.cpp 直接调用。

实际使用 llama.cpp 时，有几个参数对端侧性能影响很大。-ngl控制有多少层放到 GPU 上，端侧设备如果 GPU 显存有限，需要仔细调这个值。-c控制上下文窗口大小，直接决定 KV Cache 内存占用。-b和-ub控制批处理大小，影响吞吐和内存的平衡。这些参数没有万能值，需要根据你的设备和模型实测调优。

3.2 MNN、NCNN 和 TFLite：移动端和嵌入式场景的专用方案

如果你的端侧设备是手机、平板或者嵌入式开发板，llama.cpp 可能不是最优解。这些场景下，阿里开源的 MNN、腾讯的 NCNN、以及 Google 的 TFLite 往往能提供更好的性能和更小的包体积。

MNN 在移动端的表现很突出，支持多种量化方式，对 ARM 架构做了深度优化，内存占用控制得很好。NCNN 同样针对移动端优化，在卷积类模型上性能强劲，对 LLM 的支持也在逐步完善。TFLite 的优势是和 Android 生态集成度高，如果你的 Agent 是 Android 应用，用 TFLite 部署会比较顺。

这些框架的共同特点是针对特定硬件做了指令集级别的优化，比如 ARM 的 NEON 指令、高通的 Hexagon DSP 等。代价是模型转换链路比 GGUF 复杂，需要先把模型转成框架专属格式，转换过程中可能遇到算子不支持的问题。我踩过的坑是，某些量化后的模型在转换时会出现精度异常，需要反复调试转换参数。

3.3 有 NPU 的设备：别浪费了专用算力

现在很多端侧芯片都带了 NPU，比如瑞芯微的 RK3588、地平线的征程系列、以及各种带 NPU 的移动 SoC。NPU 的算力往往比 CPU 强一个数量级，功耗还更低，端侧 LLM 部署如果不用 NPU 是很浪费的。

但 NPU 的部署链路和 CPU/GPU 完全不同。你需要用芯片厂商提供的工具链把模型转成 NPU 能识别的格式，比如 RK3588 需要用 RKNN 工具链。这个转换过程对模型结构有要求，不是所有模型都能顺利转过去。常见的坑包括：某些注意力机制的实现 NPU 不支持、量化校准数据没选好导致精度暴跌、算子融合后输出对不上。

我的经验是，如果决定用 NPU，模型选型阶段就要把 NPU 支持度作为硬性筛选条件，优先选那些已经被验证过能在目标 NPU 上跑通的模型。别等模型都调好了才发现转不过去，那时候返工成本很高。

4. 内存优化：端侧部署的生死线

4.1 KV Cache 才是内存大户，不是模型权重

很多人优化端侧内存的时候，盯着模型文件大小看，觉得模型 2.5GB，设备 4GB 内存应该够。结果一跑起来就 OOM。问题出在 KV Cache 上。

KV Cache 是推理过程中缓存注意力机制的 key 和 value 矩阵用的，它的内存占用和上下文长度、批大小、模型层数、隐藏维度都成正比。一个 4B 模型，在 4K 上下文、批大小 1 的情况下，KV Cache 可能占用 1GB 到 2GB。如果上下文拉到 8K，这个数字直接翻倍。再加上模型权重、中间激活值、框架本身的开销，4GB 内存确实很紧张。

优化 KV Cache 有几个方向。限制上下文长度是最直接的，端侧 Agent 实际需要的上下文往往没那么长，把窗口从 8K 降到 4K 能省一半 KV Cache。使用量化 KV Cache是另一个方向，把 KV Cache 也用低精度存储，能再省一半左右，代价是精度略有下降。分页注意力（PagedAttention）这类技术能把 KV Cache 按需分配，减少碎片，但端侧框架支持度参差不齐。

4.2 内存峰值控制的几个实操手段

除了 KV Cache，还有几个手段能有效控制内存峰值，这些都是我在实际项目中验证过的。

分批加载模型权重：不是所有层都需要同时驻留内存，可以按需加载。llama.cpp 的 mmap 机制就是干这个的，它把模型文件映射到内存，用到哪部分加载哪部分，能显著降低峰值内存。开启 mmap 后，模型文件大小不再等于内存占用。

及时释放中间张量：推理框架一般会管理中间张量的生命周期，但有些实现不够激进，中间结果用完不及时释放。如果框架支持，可以手动控制释放时机，或者选择那些内存管理做得好的框架。

降低批大小：批大小对内存的影响是线性的，端侧 Agent 通常不需要高吞吐，批大小设为 1 就行。有些框架默认批大小比较大，需要手动调小。

关闭不必要的功能：比如一些框架默认开启的日志、监控、缓存功能，在端侧都可以关掉，能省一点是一点。

注意：内存优化不是一次性的工作，需要在部署后持续监控。建议在设备上跑一个内存监控脚本，记录推理过程中的内存曲线，找出峰值出现的时机，针对性优化。

4.3 一个真实的内存优化案例

我之前做过一个基于 4B 模型的端侧 Agent，设备是 8GB 内存的嵌入式板子。初始部署时，模型用 Q4_K_M 量化，上下文窗口设了 8K，结果一跑长对话就 OOM。

排查过程是这样的：先用监控工具看内存曲线，发现内存是在对话进行到第 5 轮左右开始飙升的，说明问题出在 KV Cache 的累积上。然后把上下文窗口从 8K 降到 4K，OOM 的频率降低了但没完全解决。接着开启 KV Cache 量化，内存峰值又降了一截。最后把批大小从默认的 4 调到 1，同时开启 mmap 加载模型，内存峰值终于稳定在 5GB 左右，留出了足够的余量给系统和其他模块。

这个案例说明，内存优化往往是多个手段组合使用，单一手段很难彻底解决问题。而且优化过程中要有监控数据支撑，不能凭感觉调。

5. 部署后的性能调优与稳定性保障

5.1 首 token 延迟的优化思路

首 token 延迟是端侧 Agent 体验的关键，优化它需要从多个环节入手。

prompt 长度直接影响 TTFT。prompt 越长，模型需要处理的输入 token 越多，TTFT 越长。端侧 Agent 的系统提示和工具定义往往很长，这部分是固定的，可以考虑做 prompt 缓存，避免每次重新计算。有些推理框架支持 prompt cache，能把固定前缀的 KV Cache 缓存下来复用。

模型预热很重要。设备刚启动时，模型权重还没加载到内存，第一次推理会特别慢。可以在 Agent 启动时先跑一次空推理，把模型预热好，用户第一次交互时就不会感觉卡。

硬件加速要用上。如果设备有 GPU 或 NPU，确保推理框架真的在用它们，而不是回退到 CPU。我见过不少案例是配置没写对，框架默默用了 CPU，性能差了好几倍。

5.2 生成速度的调优

生成速度主要受硬件算力和量化精度影响，但也有一些软件层面的优化空间。

量化等级的选择要在速度和精度之间平衡。Q4 通常比 Q8 快不少，精度损失在 Agent 场景下往往可以接受。如果实测发现 Q4 精度不够，可以试试 Q5 或者 Q6，找到那个刚好满足精度要求的最低量化等级。

投机采样（Speculative Decoding）是提升生成速度的有效手段，用一个小的草稿模型先猜几个 token，再用大模型验证。端侧场景下，草稿模型可以选一个 0.5B 的小模型，验证模型用 4B 的主模型，实测能提升 1.5 到 2 倍速度。代价是需要额外加载一个草稿模型，内存占用增加。

批处理在端侧 Agent 场景下通常用不上，因为 Agent 的请求往往是串行的。但如果你的 Agent 有并行任务，适当批处理能提升吞吐。

5.3 长时间运行的稳定性问题

端侧 Agent 往往需要长时间运行，稳定性问题会在运行几个小时后才暴露出来，这类问题最难排查。

内存泄漏是最常见的。推理框架、工具调用模块、日志模块都可能有泄漏。排查方法是定期记录内存占用，看是否有持续上升的趋势。如果发现泄漏，用内存分析工具定位到具体模块。

温度降频是另一个常见问题。端侧设备散热能力有限，长时间高负载运行会导致芯片降频，推理速度突然变慢。应对方法是控制推理频率，或者在 Agent 设计上避免持续高负载。

模型输出异常也时有发生。长时间运行后，模型可能开始输出乱码或者重复内容，这通常是 KV Cache 累积误差或者数值精度问题导致的。定期重置对话上下文能缓解这个问题。

6. 端侧 LLM 和 Agent 框架的衔接

6.1 推理服务的接口设计

端侧 LLM 部署好之后，需要暴露一个接口给 Agent 框架调用。这个接口的设计直接影响 Agent 的响应速度和稳定性。

我一般会用本地 HTTP 服务的方式，把推理引擎包装成一个 REST API。这样做的好处是 Agent 框架和推理引擎解耦，可以独立升级和调试。接口设计上，除了标准的生成接口，还会加一个健康检查接口和一个取消接口。健康检查用于监控推理服务状态，取消接口用于用户中断生成时及时释放资源。

接口的并发控制也很重要。端侧设备算力有限，同时处理多个推理请求会拖慢所有请求。我一般会限制并发数为 1，请求排队处理。Agent 框架那边要做好超时和重试逻辑，避免请求堆积。

6.2 流式输出在端侧的实现

流式输出对 Agent 体验很重要，用户能实时看到模型在生成内容，感知延迟大大降低。端侧实现流式输出，需要推理引擎支持逐 token 返回，接口层用 SSE 或者 WebSocket 推送给 Agent 框架。

llama.cpp 和 Ollama 都支持流式输出，配置一下就行。需要注意的是，流式输出会增加一些开销，因为每个 token 都要走一次网络传输。端侧设备上这个开销相对明显，如果对延迟极度敏感，可以权衡是否用流式。

6.3 工具调用和结构化输出的端侧适配

Agent 的核心能力是工具调用，这要求 LLM 能稳定输出结构化的 JSON。端侧小模型在这方面的能力往往不如大模型，需要做一些适配。

用约束解码是有效的手段。约束解码能在生成时限制模型只能输出符合特定语法（比如 JSON schema）的内容，从根本上避免格式错误。llama.cpp 支持 GBNF 语法约束，可以定义 JSON 的输出格式，实测能大幅提升结构化输出的成功率。

prompt 工程也很关键。端侧小模型对 prompt 格式更敏感，工具定义的写法、示例的数量、指令的清晰度都会影响输出质量。我一般会给每个工具配一个简短的调用示例，让模型照着格式输出。

后处理兜底不能少。即使做了约束解码，偶尔还是会有格式问题，Agent 框架那边要有解析失败的处理逻辑，比如重试、降级到文本解析等。

7. 一些踩坑之后的经验总结

7.1 别在模型选型上省时间

我见过太多项目在模型选型上草草决定，随便拿个热门模型就开始部署，结果后面发现各种不匹配，返工成本极高。模型选型应该花足够的时间，把候选模型在你的实际业务数据上跑一遍，看输出质量、看 token 效率、看推理速度、看内存占用。这个前期投入绝对值得。

7.2 量化不是越激进越好

量化等级的选择要在精度和资源之间找平衡点。我一般会从 Q4 开始试，如果精度不够就往上调，如果资源还是紧张就往下调。关键是每次调整都要用实际业务数据验证精度，不能只看 benchmark 分数。有些模型在 benchmark 上 Q4 和 Q8 差距很小，但在你的具体任务上差距可能很大。

7.3 监控和日志是端侧部署的生命线

端侧设备不像云端那样容易调试，出了问题往往只能靠日志和监控数据定位。部署时一定要把监控和日志做扎实，记录推理延迟、内存占用、温度、错误率这些关键指标。这些数据不仅能帮你排查问题，还能指导后续的优化方向。

7.4 留足资源余量

端侧设备上，系统和 Agent 框架本身也要占资源，别把内存和算力算得太满。我一般会留 30% 以上的内存余量，CPU 和 NPU 的利用率也控制在 70% 以内。这样在负载波动时系统还能稳定运行，不会因为一个突发请求就崩掉。

7.5 端侧部署是一个持续迭代的过程

没有一次部署就能完美的事情。端侧 LLM 部署需要在真实设备上持续运行、持续监控、持续优化。每次优化都要有数据支撑，改了什么、效果如何、有没有副作用，都要记录清楚。这样积累下来，你对自己设备的脾气会越来越了解，部署方案也会越来越稳。

我在实际项目中最深的体会是，端侧 LLM 部署的难点不在于某个单点技术，而在于把模型选型、量化、推理引擎、内存优化、稳定性保障这些环节串起来，让它们协同工作。任何一个环节没做好，整个 Agent 的体验都会受影响。所以别指望一步到位，把每个环节都做扎实，遇到问题用数据说话，慢慢调，最终一定能跑出一个稳定可用的端侧 Agent。