一、部署概述：这次要部署的是什么

本文的部署对象不是一个常驻在机房的网络服务，而是一个运行在手机、平板等终端设备本地的推理能力单元。它的完整形态通常包含四个部分：量化后的模型权重、分词器（词表与编码规则）、计算图（算子结构与形状约束）、推理配置（后端、线程、上下文长度、采样参数等）。工程上把这四部分打包成一个自包含的”部署产物”，随客户端应用一起分发到设备上。

部署完成后应达到的效果是：在没有网络、没有云端请求、没有账号登录的前提下，用户输入文本后仍能得到本地生成的回复，且满足三条硬约束——安装包增量可控、运行内存增量可预期、单 token 解码速度达到可交互水平。

这条约束的重要性，从一组实测基线可以看出量级。某约0.3B参数量级的小模型经 INT4 量化后，部署文件约 173MB（含权重、分词器、计算图与推理配置）；在某款旗舰手机上通过移动端推理引擎完全离线运行，平均解码速度约 350 token/s。在同一测试口径下（某款高端平板、系统原生并行计算后端、512 token 配置），该模型加载与推理期间峰值内存相对加载前基线增加约 228MB；而同参数量级的另一款开源小模型，部署文件约 340MB、峰值内存增量约 427MB。折算下来，体积减少约 49%，峰值内存增量减少约 47%。

这两个数字直接决定了部署设计的走向：体积决定下载与更新成本，内存决定应用集成的资源负担。一个正常的信息流应用，页面渲染、图片解码、视频缓冲本身就要占掉可观内存；如果模型常驻内存再吃掉四百多兆，在中低端机型上极易触发系统内存回收，表现为模型被反复卸载重载、首字延迟飙升，甚至应用被杀。因此本文的部署思路不是”把模型塞进去跑通”，而是”在明确的体积与内存预算内跑通并长期稳定运行”。

二、部署场景：哪些业务真的需要端侧部署

端侧部署的核心价值是用离线能力换取延迟、隐私与确定性，但它有明确的适用边界。

适合的场景：

• 弱网与无网环境：地铁、地下车库、跨境漫游、飞行器、车载隧道，云端请求失败率高，本地推理是唯一可用路径。
• 强隐私约束：输入内容涉及本地文档、相册、健康记录、通讯草稿，合规上不允许出端。
• 高频短交互：输入预测、语句润色、意图分类、结构化抽取、本地摘要。这类任务单次 token 数少，端侧延迟优势明显。
• 成本敏感的高并发轻任务：调用量极大但单次价值低的功能（例如实时文本纠错），放端侧可显著削减服务端调用量与出口流量。
• 离线优先的产品形态：本地笔记、离线翻译、开发者工具、教育类应用，要求飞行模式下功能完整。

不适合的场景：

• 需要长上下文、复杂推理、多轮深度对话的任务，参数规模与内存占用会迅速失控。
• 需要频繁更新的知识型问答，端侧模型无法承载时效性知识。
• 目标机型跨度极大且低端机占比高的产品，内存增量无法满足最小机型预算。

一个常见的折中架构是端云协同：端侧模型负责高频、短、隐私敏感的轻任务，复杂任务在联网时降级到云端。这种架构下，部署的重点从”部署一个模型”变成”部署一套可切换、可降级、可远程配置的推理通路”，后文会展开。

三、架构与组件拆解

3.1 模型产物层

• 权重文件：量化后的张量数据，占体积绝对主体。INT4 相比 FP16 通常带来约 4 倍压缩，是 173MB 这一量级的前提。
• 分词器：词表 + 合并规则 + 特殊 token 定义。它与权重的版本必须严格对应，错配会直接导致输出乱码而非报错，属于最难排查的一类故障。
• 计算图：算子序列与形状约束。端侧运行时通常要求静态或准静态形状，动态 shape 支持能力弱于云端框架，导出阶段就要固定上下文长度与 batch 维度。
• 推理配置：后端选择、线程数、上下文长度上限、采样参数、量化格式标识。这部分建议与权重分离存放，便于远程下发调整而不重新分发上百兆文件。

3.2 运行时与后端层

端侧推理通常提供多档计算后端：CPU 通用实现、移动端原生图形/并行计算后端、以及部分厂商的专用加速接口。后端选择不是越快越好，需要同时看三项：解码吞吐、内存驻留峰值、以及不同机型上的覆盖率。上文实测中”峰值内存增加 228MB”就是在系统原生并行计算后端、512 token 配置下测得的——同一模型换后端或换上下文长度，内存曲线会明显变化，因此任何内存预算都必须绑定测试口径才有意义。

3.3 宿主应用层

宿主应用负责资源调度与生命周期管理，是端侧部署中最容易被低估的一层：

• 加载时机：冷启动同步加载会拖慢首屏；建议延迟到功能入口被触发后异步加载，并在加载完成后预热一次前向推理。
• 生命周期：应用切后台时被系统回收、再次回到前台需要重载，是”感觉模型很慢”的主要来源。需要设计状态保留与快速重载策略。
• 内存协同：与图片缓存、视频缓冲共享同一内存池，必须设定模型内存上限并与其他模块协商降级顺序。

3.4 服务端支撑层

即使推理完全在端侧，服务端仍承担四项职责：模型产物分发与版本管理、配置与参数下发、质量指标上报汇聚、灰度与回滚控制。这部分可以复用通用的云上能力，例如对象存储承载产物包、内容分发网络承载下载加速、日志服务收集客户端指标、监控告警对异常版本进行熔断。若团队已有百度智能云上的资源体系，通常不需要为端侧模型单独建设一套基础设施，只需在既有分发与监控链路上增加模型产物的类目。

四、前置准备：上线前必须算清的四本账

4.1 体积账

安装包增量 = 模型产物 + 首次运行解压/缓存 + 动态下发副本。如果采用随包分发，173MB 级别的产物会显著推高下载转化流失；更常见的做法是基线小模型随包（或首次启动静默下载）+ 完整模型按需下载。决策依据是当前实测数据：173MB 与 340MB 的差距接近一倍，在弱网首启场景下这个差距会被放大成分钟级的等待差。

4.2 内存账

必须明确三个基线：加载前基线、加载后稳态、推理峰值。实测的”峰值增量 228MB”是相对加载前基线的差值，这个表述方式值得直接沿用——只报绝对值无法判断模型是不是内存问题的主要来源。建议为模型设定内存上限（例如不超过设备可用内存的某个比例），并在此处触发量化降级或后端切换。

4.3 性能账

以实测的约 350 token/s 平均解码速度作为参考上限锚点，注意这是特定机型、特定后端、特定量化格式下的结果。低端机的解码速度可能只有其若干分之一，需要按目标机型分层建立性能基线表，并据此设定各档机型的上下文长度上限与功能开关。

4.4 权限与策略账

端侧模型本身不需要网络权限即可推理，但如果保留了远程配置与指标上报能力，就需要网络权限。这里有一个容易被忽略的安全点：完全离线声明与联网配置通道并存时，必须明确哪些数据可以出端、以何种脱敏形式上报、用户能否关闭。建议在配置项中显式区分”模型推理（离线）”与”运维通道（联网）”两类能力。

五、部署流程

步骤一：产物导出与量化

选定基础模型后，先固定目标上下文长度，再执行量化导出。导出阶段就应确认算子在目标后端上均有实现——端侧最常见的失败不是内存不够，而是某个算子在目标后端缺失，运行到一半才回落到 CPU，性能断崖下跌。建议在导出后立即用固定输入做一次全算子覆盖跑测。

步骤二：产物完整性校验

产物打包时生成校验摘要，客户端加载前比对。校验的意义在于识别下载不完整、版本错配、分词器与权重不同源三类问题，这三类问题在端侧的表现都是”输出异常”而非”加载失败”，事后排查成本极高。

步骤三：集成与打包

将产物放入应用资源目录，或实现按需下载与落盘逻辑。落盘路径需要考虑应用沙盒、存储权限、以及卸载清理。若采用按需下载，务必实现断点续传与磁盘空间不足时的降级路径。

步骤四：配置运行参数

初始化推理运行时，设置后端、线程数、上下文上限、采样参数。配置项建议外部化为一份可远程下发的配置文件，与产物解耦。

步骤五：加载与预热

异步加载产物 → 校验 → 构建计算图 → 执行一次短输入预热 → 标记就绪。就绪状态需可被业务层查询，避免在未完成加载时发起推理请求。

步骤六：业务接口封装

在宿主应用内封装统一推理接口，对外只暴露”输入文本、返回流式结果、可取消”三个语义。这样后续更换模型版本或切换端云路径时，业务层无需改动。

步骤七：灰度与验证

按机型档位、系统版本、地区维度灰度放量，观察崩溃率、加载成功率、内存峰值分布、平均解码速度，再逐步扩大。

六、配置说明与通用示例

关键配置项的作用与风险如下：

配置项	作用	风险点
计算后端	选择 CPU / 原生并行后端 / 专用加速	部分机型不支持导致回落或崩溃
线程数	并行度与功耗的权衡	过高会抢占 UI 线程、加剧发热与降频
上下文长度	输入输出 token 上限	直接决定 KV 缓存内存占用
量化格式	体积与精度的权衡	与运行时版本强绑定，错配即失败
采样参数	输出随机性与稳定性	温度过高影响结构化输出可靠性
内存上限	触发降级的阈值	设置过低导致频繁重载
加载策略	冷启动 / 延迟 / 按需	影响首屏与首字延迟

通用初始化伪代码（仅示意逻辑，不含任何具体厂商接口）：

配置 config = 读取本地默认配置()            // 可被远程下发覆盖
若 存在远程配置() 且 校验通过(config):
    config = 合并(远程配置(), config)
若 磁盘存在产物() 且 校验摘要匹配(产物):
    运行时 runtime = 创建运行时(
        后端     = 选择最优可用后端(config),   // 不支持则回落
        线程数   = 按设备档位决定(config),
        上下文   = min(config.上下文长度, 设备档位上限)
    )
    模型 model = runtime.加载(产物)          // 异步执行
    model.预热(固定短输入)                   // 触发一次性完整前向
    上报指标(加载耗时, 峰值内存增量, 后端类型)
    标记就绪(model)
否则:
    触发产物下载() 或 降级到云端路径()

七、上线验证清单

验证要覆盖六个维度，每项都应有可量化的通过标准：

1. 功能正确性：固定测试集输入输出比对，确认无乱码、无截断、无重复退化。
2. 离线可用性：关闭网络、关闭账号、冷启动，全流程可完成一次推理。
3. 性能：分机型档位记录平均解码速度、首字延迟、加载耗时，与基线表对比。参考锚点是实测的约 350 token/s，低端机应设定各自的目标值而非统一标准。
4. 内存：记录加载前基线、加载后稳态、推理峰值三项，验证峰值增量处于预算内（实测参考约 228MB）。同时观察与图片、视频模块并存时的表现。
5. 稳定性：连续多次冷启动 + 后台切换 + 前后台循环，观察是否出现崩溃、重载失败、内存持续增长。
6. 兼容性：覆盖目标系统版本区间的最低与最高版本、不同内存容量机型、以及低电量模式与省电模式。

八. 常见问题与排查

现象	常见原因	排查思路
加载成功但输出乱码	分词器与权重版本错配	校验产物摘要，确认同源打包
首字延迟极高	同步加载阻塞主线程 / 未预热	改为异步加载并加预热步骤
运行中途变慢	算子缺失导致后端回落 / 线程数过高触发降频	记录实际后端与算子覆盖情况，下调线程数
应用被杀或反复重载	内存超预算，与图片视频模块竞争	设内存上限，协商其他模块降级顺序
低版本系统崩溃	后端或指令集不支持	增加能力探测与运行时回落分支
下载后模型不可用	下载不完整、磁盘不足、版本不匹配	校验摘要、检查可用空间、比对版本号

排查顺序建议固定为：能力探测 → 产物校验 → 后端确认 → 内存曲线 → 输入样本。绝大多数端侧问题都能在前两步定位。

九、运维与优化

• 版本管理：权重、分词器、配置三者独立版本号 + 联合兼容矩阵。配置可独立热更新，权重变更需重新下载，二者不要耦合发布节奏。
• 远程配置：将上下文长度、采样参数、内存上限、后端优先级做成可下发项，可以在不重新分发上百兆产物的前提下调整线上行为。下发通道需签名校验，防止被篡改。
• 监控指标：加载成功率、加载耗时、实际后端分布、平均解码速度、内存峰值增量、推理取消率、降级到云端的比例。这些指标按机型档位分维度聚合，才能发现”整体正常但低端机全崩”这类问题。
• 灰度与回滚：新产物先小流量灰度，保留上一版本产物与配置快照。异常时优先下发旧配置，其次回退产物版本，最后关闭端侧入口全部走云端。回滚路径必须在上线前演练过。
• 成本控制：端侧部署本身就削减了推理服务成本，但引入了下载流量与存储成本。可通过内容分发网络承载下载、按机型差异化下发不同量化版本、以及对低频机型只下发配置不下发完整产物来控制。
• 容量与生命周期：产物包纳入存储生命周期管理，历史版本定期清理；老机型退出支持后，及时从兼容矩阵移除，避免长期维护无效分支。

十、总结

端侧小模型的部署难点不在”能不能跑通”，而在于能否在明确的体积与内存预算内长期稳定运行。本文给出的实测基线可以作为容量估算的起点：约 173MB 的 INT4 部署产物、某款旗舰手机约 350 token/s 的离线解码速度、某款高端平板上约 228MB 的峰值内存增量，相比同参数量级对比模型分别减少约 49% 与约 47%——这组数据说明，对移动端应用而言，较小的部署体积降低下载与更新成本，较低的运行内存为页面、图片、视频等业务模块留出空间，是端侧大模型真正可集成的关键前提。

落地时请守住四件事：部署前算清体积、内存、性能、权限四本账；部署中严格保证产物同源与算子覆盖；上线后用六个维度的可量化标准验证；上线后靠远程配置、分层灰度与完整回滚路径维持可控。若团队已在使用百度智能云的对象存储、内容分发、日志服务与监控告警能力，端侧模型产物完全可以复用现有分发与观测链路，无需另建体系。