1. 端侧 LLM 部署到底在解决什么问题把大模型塞进手机、开发板、车机或者一台离线工控机里这件事从 2023 年下半年开始就不再是实验室里的玩具了。我最早接触端侧 LLM 是在一块 RK3588 的开发板上当时想跑一个 7B 的模型结果发现光是模型文件就 4 个多 G内存直接吃满推理速度慢到没法用。后来换了量化版本又折腾了推理框架才勉强跑通。这个过程让我意识到端侧 LLM 部署和云端部署完全是两套逻辑——云端你可以堆 A100、堆 H100端侧你只有有限的算力、有限的内存、有限的功耗预算还得考虑发热和续航。所谓端侧 LLM 部署说白了就是把大语言模型的推理过程放在本地设备上完成不依赖网络请求数据不出设备。它解决的核心问题有三个第一是隐私用户的对话内容、文档内容不需要上传到任何服务器第二是延迟本地推理没有网络往返首 token 延迟可以做到很低第三是可用性断网环境下依然能工作。适合谁来参考如果你是做 AI Agent 开发的端侧 LLM 可以作为 Agent 的“大脑”跑在本地如果你是做嵌入式或者边缘计算的端侧 LLM 能帮你把智能能力下沉到设备端如果你只是对本地部署大模型感兴趣想在自己的电脑上跑一个玩玩那这篇文章里的思路同样适用。但端侧 LLM 部署不是简单地把模型文件拷过去就完事了。它涉及模型选型、量化、推理框架选择、内存管理、算子优化、硬件加速等一系列工程问题。我见过太多人卡在第一步——模型下载下来跑不起来或者跑起来慢得没法用。所以这篇文章我会从实际工程角度出发把端侧 LLM 部署的完整链路拆开讲清楚包括每一步为什么这么做、怎么做、踩过哪些坑。2. 端侧 LLM 部署的整体架构与方案选型2.1 端侧推理的三种典型架构端侧 LLM 部署的架构大致可以分成三类选择哪一种取决于你的硬件条件和应用场景。第一种是纯 CPU 推理。这是最通用的方案几乎任何设备都能跑不需要额外的加速硬件。llama.cpp 就是这类方案的代表它通过 GGUF 格式的量化模型在 CPU 上实现高效的推理。我实测下来在一块 8 核 ARM 处理器上跑 3B 的 Q4 量化模型大概能到 5-8 token/s日常对话够用了。优点是兼容性极好缺点是速度受限于 CPU 算力大模型跑不动。第二种是GPU/NPU 加速推理。如果你的设备有独立的 GPU 或者 NPU比如 RK3588 自带 NPU、高通骁龙有 Hexagon、苹果有 Neural Engine那就可以把推理负载卸载到这些加速器上。这类方案速度提升明显但需要专门的推理框架支持比如 RKNN、NCNN、MNN、Core ML 等。难点在于模型转换和算子适配不是所有模型都能顺利转过去。第三种是混合推理。一部分层跑在 GPU 上一部分跑在 CPU 上或者用 CPU 做预处理、GPU 做矩阵运算。这种方案在内存受限的设备上比较常见比如把 embedding 层和输出层放在 CPU中间的 transformer 层放在 GPU。实现复杂度最高但能最大化利用硬件资源。2.2 模型选型不是越大越好端侧部署的第一个决策就是选哪个模型。很多人一上来就想跑 7B、13B结果发现根本跑不动。我的经验是端侧模型选型要看三个指标参数量、量化后的体积、以及在你目标硬件上的实测速度。目前端侧比较常见的模型规格有 0.5B、1.5B、3B、7B 这几档。0.5B 到 1.5B 适合手机、手表这类内存和算力都极其有限的设备能做一些简单的意图识别、文本分类、短对话。3B 是一个甜点区间量化后大概 1.5-2G在 8G 内存的设备上跑起来比较舒服能处理大部分日常对话和简单的 Agent 任务。7B 量化后大概 3.5-4G需要至少 8G 内存而且推理速度会明显下降适合有 GPU 加速的设备。模型架构方面现在主流的是 Llama 系、Qwen 系、Phi 系、Gemma 系。Qwen 系列在中文端侧场景下表现比较好Qwen2.5-3B 和 Qwen2.5-1.5B 是我用得比较多的。Phi-3-mini 在英文场景下效率很高3.8B 的参数但推理速度接近 3B 模型。Gemma 2 的 2B 版本在端侧也有不错的表现。选模型的时候不要只看榜单分数一定要在自己的目标硬件上实测因为不同模型对算子的优化程度不一样榜单上分数高的模型不一定在你的设备上跑得快。2.3 量化方案精度与速度的平衡量化是端侧 LLM 部署绕不开的一步。所谓量化就是把模型权重从 FP16 或者 FP32 转换成 INT8、INT4 甚至更低精度的格式从而减小模型体积、降低内存带宽需求、提升推理速度。代价是精度损失但通过合理的量化策略损失可以控制在可接受范围内。目前主流的量化方案有几种。GGUF 格式支持 Q2_K、Q3_K、Q4_K、Q5_K、Q6_K、Q8_0 等多种量化等级数字越小体积越小、速度越快、精度损失越大。我一般推荐 Q4_K_M这是一个比较平衡的选择体积大概是 FP16 的 1/4精度损失在 1-2 个百分点以内。如果设备内存特别紧张可以上 Q3_K_M但中文场景下 Q3 有时候会出现明显的胡言乱语需要实测。AWQ 和 GPTQ 是另外两种常见的量化方案它们主要针对 GPU 推理优化在端侧 GPU 上表现不错。AWQ 的激活感知量化对精度保持比较好GPTQ 的推理速度在部分硬件上有优势。但这两个方案对推理框架的支持要求比较高不是所有端侧框架都支持。还有一种量化方式是动态量化比如把激活值保持 FP16只量化权重。这种方式精度损失最小但内存节省也有限。实际部署中我一般先用 Q4_K_M 跑一遍看看效果能不能接受不行再往上调。2.4 推理框架选型对比推理框架的选择直接决定了部署的难易程度和最终性能。下面这张表是我实际用过的几个框架的对比供你参考。框架适用硬件模型格式优点缺点llama.cppCPU/GPUGGUF兼容性好量化支持全GPU 加速有限MNNCPU/GPU/NPUMNN阿里出品端侧优化好模型转换有门槛NCNNCPU/GPUNCNN腾讯出品移动端友好LLM 支持较新RKNNRK NPURKNN瑞芯微官方NPU 加速仅限 RK 芯片ONNX RuntimeCPU/GPUONNX通用性强生态好端侧优化一般MLXApple SiliconMLX苹果官方M 系列优化仅限苹果设备选框架的原则是先看你的硬件有没有官方支持的框架有就用官方的因为官方框架对硬件的算子优化最到位。如果没有那就选 llama.cpp它的兼容性最好几乎什么设备都能跑。如果你用的是瑞芯微的芯片那 RKNN 是首选NPU 加速效果很明显。苹果设备上 MLX 是首选M 系列芯片的统一内存架构对 LLM 推理非常友好。3. 核心实操从模型下载到跑通第一个端侧 LLM3.1 环境准备与依赖安装不管你用什么框架第一步都是把基础环境搭好。我以 llama.cpp 为例因为它的通用性最强学会了之后换其他框架也能触类旁通。首先确认你的设备架构和操作系统。Linux 下用uname -m看是 x86_64 还是 aarch64macOS 下用uname -m看是 x86_64 还是 arm64。然后安装编译工具链Ubuntu/Debian 系用apt install build-essential cmake gitmacOS 用xcode-select --install和brew install cmake。接下来克隆 llama.cpp 仓库并编译。这里有个关键点编译时要根据你的硬件开启对应的加速选项。比如在苹果 M 系列芯片上要开-DLLAMA_METALON在 NVIDIA GPU 上要开-DLLAMA_CUBLASON在支持 AVX2 的 x86 CPU 上要开-DLLAMA_AVX2ON。不开这些选项也能编译但推理速度会差很多。git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build cd build cmake .. -DLLAMA_METALON -DCMAKE_BUILD_TYPERelease make -j$(nproc)编译完成后你会得到main、server、quantize等可执行文件。main用于命令行推理server用于启动 API 服务quantize用于模型量化。3.2 模型下载与格式转换llama.cpp 使用的是 GGUF 格式的模型。如果你从 Hugging Face 上下载的是原始 PyTorch 格式的模型需要先转换成 GGUF。不过现在很多模型社区已经直接提供了 GGUF 版本省去了转换步骤。下载模型的时候要注意GGUF 文件通常有多个量化等级文件名里会标注比如qwen2.5-3b-instruct-q4_k_m.gguf。我一般会下载 Q4_K_M 和 Q5_K_M 两个版本对比一下效果和速度再决定用哪个。如果你需要自己转换模型流程是这样的先把原始模型转成 GGUF 的 FP16 格式然后再量化到目标精度。转换脚本在 llama.cpp 的convert.py或者convert-hf-to-gguf.py里。量化的时候用quantize工具指定目标量化类型。# 转换 FP16 GGUF python convert-hf-to-gguf.py /path/to/model --outtype f16 --outfile model-f16.gguf # 量化到 Q4_K_M ./quantize model-f16.gguf model-q4_k_m.gguf Q4_K_M这里有个坑要注意转换脚本对模型架构的支持是逐步添加的新出的模型架构可能还没被支持。遇到这种情况要么等社区更新要么自己改转换脚本。我遇到过好几次转换失败最后发现是模型用了新的 attention 实现转换脚本还没适配。3.3 推理参数调优与实测模型跑起来之后参数调优是提升体验的关键。llama.cpp 的main和server都支持一系列参数下面这几个是我实际调优时最常改的。-ngl控制有多少层卸载到 GPU。如果你有 GPU这个值设得越大越好直到显存吃满。比如 3B 模型大概 28 层全部卸载到 GPU 上速度能提升 3-5 倍。-c控制上下文长度默认是 512端侧场景下我一般设 2048 或 4096再大内存吃不消。-b控制 batch size影响 prompt 处理速度端侧一般设 512 就够了。-t控制线程数设成 CPU 物理核心数比较合适设太多反而会因为线程切换开销导致速度下降。温度参数--temp和 top-p--top-p对生成质量影响很大。端侧模型因为参数量小温度设太高容易胡言乱语我一般设 0.7 左右top-p 设 0.9。重复惩罚--repeat-penalty设 1.1 左右能有效减少重复输出。实测数据方面我在 RK35884 核 A76 4 核 A558G 内存上跑 Qwen2.5-3B-Q4_K_M纯 CPU 推理速度大概是 6-7 token/s开启 NPU 加速后能到 15-20 token/s。在苹果 M1 MacBook Air8G 内存上跑同样的模型Metal 加速下能到 25-30 token/s。在树莓派 54 核 A768G 内存上跑 Qwen2.5-1.5B-Q4_K_M速度大概是 8-10 token/s。这些数据供你参考实际速度会受散热、后台负载等因素影响。3.4 内存管理与优化技巧端侧设备内存有限内存管理是部署成功的关键。我踩过最大的坑就是模型加载到一半 OOMOut of Memory被系统杀掉。后来总结了几条经验。第一模型文件大小不等于运行时内存占用。GGUF 格式的模型在加载时会把权重映射到内存实际占用会比文件大小多一些因为还有 KV cache、中间激活值等开销。一般来说运行时内存占用大概是模型文件大小的 1.2-1.5 倍。所以 8G 内存的设备跑 4G 的模型文件已经是极限了。第二KV cache 是内存大户。上下文长度设得越长KV cache 占用越大。以 3B 模型为例2048 上下文大概需要 500M-1G 的 KV cache4096 上下文就要 1-2G。如果内存紧张可以开启 KV cache 量化把 KV cache 从 FP16 量化到 INT8内存占用直接减半精度损失很小。第三mmap 是个好东西。llama.cpp 默认使用 mmap 加载模型这样模型权重不会全部常驻内存而是按需从磁盘加载。这在内存受限的设备上非常有用代价是首次推理会慢一些因为要从磁盘读权重。如果你的设备磁盘速度慢可以关掉 mmap但内存占用会上升。第四及时释放不用的资源。如果你在 Agent 里同时加载了多个模型比如一个 embedding 模型加一个生成模型要注意在不用的时候释放掉。我见过有人同时加载了三个模型结果内存直接爆掉。4. 端侧 LLM 与 Agent 的结合实践4.1 端侧 Agent 的架构设计端侧 LLM 部署只是第一步真正让它发挥作用的是和 Agent 结合。端侧 Agent 的架构和云端 Agent 有本质区别云端 Agent 可以随意调用各种 API端侧 Agent 必须在本地完成所有推理和决策。一个典型的端侧 Agent 架构包含几个模块LLM 推理引擎负责理解和生成工具调用模块负责执行本地操作比如读写文件、查询本地数据库、控制设备记忆模块负责维护对话历史和长期记忆规划模块负责拆解任务。这些模块全部跑在本地不依赖网络。我实际做过一个端侧 Agent 项目跑在 RK3588 上用 Qwen2.5-3B 作为推理引擎通过 function calling 的方式调用本地工具。整个流程是用户语音输入 - ASR 转文字 - LLM 理解意图 - 决定调用哪个工具 - 执行工具 - LLM 生成回复 - TTS 输出。整个链路延迟在 2-3 秒左右其中 LLM 推理占了大部分时间。4.2 Function Calling 在端侧的落地Function Calling 是 Agent 的核心能力但端侧模型对 function calling 的支持参差不齐。大模型经过专门训练后 function calling 能力很强但 3B 以下的小模型经常输出格式错误的 JSON或者干脆不按格式输出。我的解决方案是第一选择对 function calling 有专门优化的模型比如 Qwen2.5 系列在训练时就包含了 function calling 数据表现比同尺寸的其他模型好很多。第二在 prompt 里把工具定义写得非常明确包括参数类型、取值范围、必填项减少模型犯错的空间。第三加一层输出解析和校验如果模型输出的 JSON 格式不对就重试或者用规则兜底。还有一个技巧是用 grammar-based 解码。llama.cpp 支持 GBNF 语法可以强制模型输出符合特定 JSON schema 的内容。这样即使模型本身 function calling 能力不强也能保证输出格式正确。我实测下来开启 grammar 约束后function calling 的成功率从 70% 左右提升到了 95% 以上。4.3 多轮对话与上下文管理端侧 Agent 通常需要维护多轮对话但上下文长度有限不可能把所有历史都塞进去。我的做法是分层管理最近几轮对话保留完整内容更早的对话做摘要压缩再早的只保留关键信息。摘要压缩可以用 LLM 本身来做让模型把之前的对话总结成几句话。但端侧模型做摘要也会消耗推理时间所以我会在对话轮次达到一定数量后才触发摘要比如每 10 轮压缩一次。压缩后的摘要会作为 system prompt 的一部分注入到后续对话中。另外端侧 Agent 的记忆模块可以用向量数据库来实现。把历史对话和知识库内容做 embedding存到本地的向量数据库里需要的时候检索相关片段注入到 prompt 中。embedding 模型可以用小尺寸的比如 bge-small 或者 text-embedding-3-small 的端侧版本几十兆大小推理速度很快。4.4 性能与功耗的平衡端侧设备通常靠电池供电功耗是必须考虑的因素。LLM 推理是计算密集型任务CPU/GPU 满载运行时功耗会飙升。我实测过RK3588 跑 LLM 推理时整板功耗在 5-8W如果持续推理电池很快就没了。优化功耗有几个方向。第一控制推理频率不是每次都需要调用 LLM简单的意图识别可以用规则或者小分类模型搞定。第二动态调整推理精度对延迟不敏感的场景可以用更低精度的量化模型。第三利用硬件的低功耗模式比如在等待输入时让 CPU 进入 idle 状态。第四控制上下文长度上下文越长KV cache 越大内存带宽消耗越高功耗也越大。还有一个容易被忽略的点是散热。端侧设备散热能力有限长时间推理会导致芯片降频速度越来越慢。我在一个项目里给 RK3588 加了散热片和风扇持续推理速度从 5 token/s 提升到了 12 token/s效果非常明显。如果你做的是产品级部署散热设计一定要提前考虑。5. 常见问题排查与避坑指南5.1 模型加载失败与内存溢出这是端侧部署最常见的问题。表现是程序启动后直接崩溃或者被系统 OOM killer 杀掉。排查思路是先看模型文件大小和可用内存的比值如果模型文件超过可用内存的 60%基本就会出问题。然后看是不是 KV cache 设得太大把上下文长度调小试试。再看是不是同时加载了多个模型释放掉不用的。如果确认是内存不够有几个解决方向换更小的模型、用量化等级更低的版本、减小上下文长度、开启 KV cache 量化、关掉 mmap 改用按需加载。我遇到过一次怎么都跑不起来的情况最后发现是系统本身占用了太多内存清理掉后台进程就好了。5.2 推理速度慢的排查路径推理速度慢的原因很多需要逐项排查。先确认有没有开启硬件加速比如 GPU 卸载层数-ngl是不是设成了 0。然后看线程数设置是否合理设成 CPU 物理核心数试试。再看模型量化等级Q8 肯定比 Q4 慢很多。还要看上下文长度上下文越长attention 计算量越大速度越慢。如果以上都排查了还是慢那可能是硬件本身算力不够。这时候只能换更小的模型或者接受这个速度。我见过有人在树莓派 4 上跑 7B 模型速度只有 0.5 token/s这已经没法用了换 1.5B 模型后速度提升到 5 token/s体验就好很多。5.3 输出质量差的调优方法端侧小模型输出质量差是普遍问题表现为胡言乱语、重复输出、不遵循指令。调优方法有几个第一调整温度参数温度太高容易胡言乱语温度太低容易重复我一般设 0.7 左右。第二加重复惩罚设 1.1-1.2 能有效减少重复。第三优化 prompt把指令写得更明确给出示例。第四换模型有些模型在特定任务上就是比其他模型好多试几个。还有一个技巧是用 few-shot 示例。在 prompt 里给几个输入输出示例模型会模仿示例的格式和风格。这对小模型特别有效能显著提升输出质量。但 few-shot 会占用上下文长度需要权衡。5.4 常见问题速查表问题现象可能原因排查方法解决方案启动即崩溃内存不足查看系统日志 OOM 记录换小模型/降低量化/减小上下文推理速度极慢未开启硬件加速检查 -ngl 参数开启 GPU/NPU 加速输出重复重复惩罚太低检查 repeat-penalty调到 1.1-1.2输出胡言乱语温度太高/量化太低检查 temp 和量化等级降低温度/提高量化等级Function calling 失败模型能力不足检查输出 JSON 格式加 grammar 约束/换模型长时间运行后变慢芯片降频监控温度加散热/降低推理频率首次推理特别慢mmap 按需加载观察磁盘 IO预热/关掉 mmap5.5 独家避坑经验第一个坑是模型文件损坏。下载大文件的时候网络不稳定可能导致文件不完整但文件大小看起来是对的。我遇到过好几次模型加载报错最后发现是下载不完整。解决办法是下载后校验 SHA256或者用支持断点续传的工具下载。第二个坑是量化脚本版本不匹配。llama.cpp 的量化格式在版本之间有过变化用旧版 quantize 工具量化出来的模型新版可能加载不了。解决办法是保持转换、量化、推理三个环节用同一个版本的 llama.cpp。第三个坑是 NPU 算子不支持。把模型转到 RKNN 或者 NCNN 的时候有些算子这些框架不支持转换会失败或者推理结果不对。解决办法是查框架的算子支持列表不支持的算子用 CPU 兜底或者换模型架构。第四个坑是上下文长度设得太大导致速度骤降。attention 的计算复杂度是 O(n^2)上下文从 2048 加到 4096attention 计算量翻四倍。端侧设备算力有限上下文设太大速度会慢到没法用。我的建议是端侧场景下上下文不要超过 4096一般 2048 就够了。第五个坑是忽略了 tokenizer 的差异。不同模型的 tokenizer 不一样同一个 prompt 在不同模型上的 token 数可能差很多。端侧上下文有限tokenizer 效率高的模型能塞更多内容。Qwen 系列的 tokenizer 对中文比较友好同样一段中文Qwen 的 token 数比 Llama 少 20% 左右。6. 端侧 LLM 部署的进阶方向6.1 多模态端侧模型纯文本的端侧 LLM 已经比较成熟了下一步是多模态。端侧多模态模型能处理图像、语音、文本的联合输入在智能家居、车载助手、工业质检等场景下很有价值。但目前端侧多模态模型还比较早期模型体积大、推理速度慢、算子支持不完善。我试过在 RK3588 上跑一个 2B 的视觉语言模型处理一张 224x224 的图片大概需要 3-5 秒速度还不太理想。但随着 NPU 算力提升和模型优化这个速度会逐步改善。如果你现在就要做端侧多模态建议把视觉编码和语言生成分开视觉编码用专门的轻量模型语言生成用端侧 LLM这样能降低整体复杂度。6.2 模型蒸馏与端侧专用模型通用大模型蒸馏到端侧是一个重要方向。通过知识蒸馏把大模型的能力迁移到小模型上让小模型在特定任务上达到接近大模型的效果。现在很多端侧模型都是蒸馏出来的比如 Qwen2.5-3B 就是从更大的 Qwen2.5 蒸馏而来。如果你有特定场景的数据还可以做领域微调。用 LoRA 在端侧模型上做轻量微调让模型更适应你的场景。LoRA 的好处是训练成本低微调后的权重文件很小可以动态加载。我做过一个客服场景的端侧 Agent用 LoRA 微调后意图识别准确率从 85% 提升到了 94%。6.3 端云协同架构纯端侧部署有算力上限纯云端部署有隐私和延迟问题端云协同是一个折中方案。简单的、隐私敏感的任务在端侧处理复杂的、需要大模型能力的任务在云端处理。端侧模型负责意图识别和任务路由判断哪些任务可以本地处理哪些需要上云。这种架构的关键是路由策略。路由太激进什么都上云就失去了端侧的意义路由太保守什么都本地处理体验又不好。我的做法是给每个任务类型设一个置信度阈值端侧模型置信度高于阈值就本地处理低于阈值就上云。阈值根据实际效果调整。6.4 端侧 Agent 的安全考量端侧 Agent 因为跑在本地能访问本地文件和设备安全风险比云端 Agent 更高。一个被恶意 prompt 注入的端侧 Agent 可能被诱导删除文件、泄露本地数据、甚至控制设备。防护措施有几个层面。第一工具调用加权限控制敏感操作需要用户确认。第二输入输出加过滤检测并拦截恶意 prompt。第三Agent 的行为加审计日志记录所有工具调用和文件访问。第四模型本身做安全对齐拒绝执行危险指令。我实际部署的时候会在 Agent 和工具之间加一层权限网关所有工具调用都要经过网关校验确保不会执行未授权的操作。6.5 硬件选型建议如果你正在选端侧 LLM 的硬件平台下面是我用过的一些平台的实际体验。RK3588 是目前端侧 AI 比较热门的芯片8 核 CPU 6 TOPS NPU8G/16G 内存可选价格适中社区支持好。缺点是 NPU 对 LLM 的算子支持还在完善中不是所有模型都能顺利跑。树莓派 5 是入门级选择4 核 A768G 内存价格便宜生态好。但没有 NPU纯 CPU 推理速度有限适合跑 1.5B 以下的模型。苹果 M 系列芯片是端侧 LLM 的体验天花板统一内存架构对 LLM 推理非常友好Metal 加速效果好。缺点是价格贵而且只能跑在苹果设备上。高通骁龙系列在手机端侧 AI 上布局很早Hexagon NPU 对 LLM 有专门优化。如果你做手机端 Agent骁龙平台是首选。英伟达 Jetson 系列在边缘计算场景下很常见CUDA 生态完善推理框架支持好。缺点是功耗和价格都比较高。选硬件的时候不要只看峰值算力要看内存带宽、算子支持、功耗、散热、以及社区生态。我见过太多人买了高算力芯片结果发现模型跑不起来最后只能换平台。7. 我个人的一些实操体会端侧 LLM 部署这件事我从 2023 年开始折腾到现在最大的体会是不要追求一步到位要迭代式推进。先跑通最小的闭环哪怕模型小一点、速度慢一点先让整个链路跑起来然后再逐步优化。我见过很多人一上来就想部署 7B 模型加多模态加 Agent结果卡在第一步就放弃了。另一个体会是端侧部署的瓶颈往往不在模型本身而在工程细节。内存管理、算子适配、散热设计、功耗控制这些看起来不起眼的问题实际决定了部署能不能成功。我花在调这些工程问题上的时间比调模型参数的时间多得多。还有一点端侧 LLM 的评估不能只看榜单分数。榜单上的模型是在特定数据集上评测的和你的实际场景可能差很远。一定要在自己的数据上、自己的硬件上实测。我遇到过榜单分数很高的模型在实际场景下表现很差的情况也遇到过榜单分数一般但实际用起来很顺手的模型。最后分享一个小技巧端侧 LLM 部署的时候准备一个“降级方案”。如果目标模型跑不起来立刻切换到更小的模型或者更低的量化等级保证功能可用。等硬件升级或者模型优化后再切回来。这个思路在资源受限的端侧场景下特别实用能让你在有限条件下先把产品做出来再逐步优化体验。