端侧ai模型部署入门

你想在手机或一块开发板上跑个模型，搜了一圈教程，结果卡在第一步：不知道自己的设备能扛多大的模型，也不知道下载下来的权重该用哪种格式，更不清楚跑通之后怎么确认它真的在端上算而不是偷偷调了云。这篇不讲原理课，只按顺序拆一遍：先看设备底线，再定模型和量化档位，然后准备权重与运行时，最后装进设备跑通并做一次自检。每一步都给你判断依据和卡住时的排查方向。

你想在手机或一块开发板上跑个模型，搜了一圈教程，结果卡在第一步：不知道自己的设备能扛多大的模型，也不知道下载下来的权重该用哪种格式，更不清楚跑通之后怎么确认它真的在端上算而不是偷偷调了云。这篇不讲原理课，只按顺序拆一遍。

顺序是：先看设备底线，再定模型和量化档位，然后准备权重与运行时，最后装进设备跑通并做一次自检。每一步都给判断依据和卡住时的排查方向，你照着往下走就行，遇到不确定的数字就回站内对应页面核对当时的值，别照着别人的旧结论硬套。

先分清：什么算端侧，什么只是「小机器上的云」

端侧的核心特征只有一个：推理在你的设备上完成，断网也能出结果。只要请求走了网络，哪怕跑在一块巴掌大的板子上，本质还是调 API，你遇到的问题会变成网络和配额问题，而不是端侧问题。先把这个界限划清楚，后面所有排查才不会跑偏。

判断标准很简单：拔掉网线还能不能出结果。能，就是端侧；不能，就是远程调用换了个壳。

手机 App 内置

模型随安装包或首次启动下发，受 App 体积、内存上限、系统后台策略约束

单板/开发板常驻

长期通电、散热和功耗是主要矛盾，可以接受稍慢但不能过热降频

PC 本地工具

约束最松，内存和算力都富裕，适合先在这类环境把流程跑通再往小设备搬

动手前先写下四项硬约束：能不能联网、功耗上限、可用内存、有没有 NPU。这四项基本决定了你后面能选什么模型、什么运行时。写不出来的话，先按最保守的那一档估，宁可后面放宽。

• 需要超长上下文的场景，端侧内存会被直接吃光
• 需要频繁更新知识的场景，每次更新都要重新分发权重，成本很高
• 多模态大输入（长视频、高分辨率图批量）在端侧通常跑不动
• 高并发、多用户同时请求的场景，端侧单机吞吐撑不住
• 一句话总结：任务越窄、输入越短、更新越少，端侧越合适

按设备倒推：先量内存，再谈模型

新手最容易犯的错是先挑模型再找设备。正确顺序反过来：先量清楚可用内存的真实数值，再决定模型能有多大。注意是真实可用值，不是标称值——系统占用、内存与显存共享、后台应用都会吃掉一部分，按标称值算出来的结论基本会翻车。

还要区分「能装下」和「能跑动」。权重能塞进内存只是及格线，运行时本身、中间张量、输入输出缓冲都要额外占地方。经验上要留出一块余量给这些开销，具体留多少取决于运行时和输入长度，没有通用数字。

也不要被参数规模迷惑。同样是几十亿参数的模型，量化方式不同，占用能差出一大截，跑起来的体验也完全不是一回事。规模和占用不是一回事，这点后面选量化档位时会再遇到。

选模型与量化档位：一笔占用换质量的账

先定任务再定模型。只做分类、抽取、短问答这类窄任务，就没必要上通用对话大模型；任务越窄，模型可以越小，量化后掉的质量也越不容易被用户感知。反过来，如果你需要它做多步推理、按复杂格式输出，小模型加低比特量化会最先在这两处崩。

量化档位从高到低的取舍顺序大致是：先牺牲长链推理能力，再牺牲少样本指令跟随，最后是细粒度格式输出（比如严格 JSON、固定字段抽取）。所以如果你的业务强依赖结构化输出，量化档位就得往上提。

怎么判断能不能接受？拿你自己的真实输入做十来个 case，量化前后各跑一遍对比，别只看别人的结论。别人的测试集和你线上输入分布差很远，结论经常不通用。

准备权重与运行时：下载、转换、放对目录

1. 确认许可范围从模型库页面看清楚许可，再动手下载。避免做完集成才发现不能商用或不能改，这一步只需要几分钟，但省下的返工很值。
2. 下载并校验完整性大文件容易断流或损坏。下完先检查文件完整性（大小、校验值），别等加载报错才回头怀疑网络。
3. 按运行时说明做格式转换需要转换时严格按运行时的官方说明走，转换参数写错是新手最常见的失败原因之一。转换完先用小输入验证一遍再往下走。
4. 规划目录结构模型文件、运行时、缓存分开放。后面版本升级或换模型时才不会互相污染，也能一眼看出是哪个环节出的问题。

运行时选型看两件事：它支持哪些权重格式，以及在你的设备上有没有可用的加速后端。同一种运行时在不同设备上的表现可能差很多，选之前先去它的文档确认支持列表，再回站内看有没有人踩过同类设备的坑。

跑通第一个推理：一条从简到繁的验证顺序

第一次跑通的目标不是效果好，而是链路通。所以先用最短的输入、最小的输出上限跑一次，看到任何合理输出就算过。这之后再加长输入、加复杂度，这样出问题时你能确定是最近改的那一步导致的。

• 加载权重：能加载成功不报错，说明格式和路径基本对了
• 输出一个 token：能出东西，说明推理链路和运行时可用
• 输出完整句子：检查是否连贯，乱码通常指向量化或 prompt 模板不匹配
• 接上你的真实业务输入：这一步才是判断能不能用的起点

如果在设备上跑和在电脑上跑结果不一样，先怀疑量化方式和运行时版本，而不是模型本身。模型文件通常没变，变的是它们在两边被怎么处理。

跑起来之后怎么量：端侧的三个真实指标

跑通不等于能用。端侧体验由三个数共同决定：首字延迟（用户按下到看到第一个字）、生成速度（每秒出多少字）、内存峰值（会不会被系统杀掉）。只盯其中一个很容易误判——生成速度很快但首字等很久，用户照样觉得卡。

量之前先把设备状态弄一致：同样的电量区间、差不多的温度、清掉后台应用。否则两次测出来的数没法比较，你会以为是自己改的东西起了作用。延迟基线的建法和接口测速是一个思路：先量出「什么算正常」，再判断异常，具体工具和方法可参考 /tools/speed-test。

• 首字延迟偏高：多是加载和预填充阶段的问题
• 生成速度偏低：多是没走加速单元或量化档位不合适
• 内存峰值贴着上限：多半会在真实使用中被系统杀掉
• 三个数里任意一个明显异常，就先查那一个，别同时改三处

什么情况下别硬上端侧：该退出的信号

有些项目一开始就不该走端侧。下面这几条里任意一条成立，就该认真考虑混合方案（端上做轻量预处理、重活交云端），而不是继续往里砸时间。

• 模型再小也放不下，或者放得下但慢到不可用
• 需要频繁更新模型或知识，端侧分发和维护成本压不住
• 权重许可不允许你的使用方式，别把「能下载」当成「能商用」
• 你其实只是想让程序能调用模型，端侧并非必要条件
• 团队没有持续维护端侧版本的人力，上线后没人跟进设备碎片化问题

端侧和云端的边界怎么画，可以结合成本、隐私和迭代速度一起判断。关于设备侧与调用侧的成本口径，到 /compute/tco 看当时的账，别用别人的旧结论套自己的场景。

合规这块要单独核对：权重许可是否覆盖你的使用方式（商用、修改、再分发），和代码许可往往是两回事。看到「开源」两个字先别急着下结论，去许可原文确认。