边缘与端侧部署

端侧模型不是塞进手机里的一台小服务器。它只是应用中的一个组件，而这套应用必须适应不同的处理器、操作系统版本、内存状况、电池状态和网络条件。因此，真正需要管理的是一套带版本的设备部署：模型、分词器、提示词模板、编译图、量化方案、运行时、路由策略和支持的设备类别共同决定了最终结果。

当一项功能需要离线路径、更短且可预测的响应链路，或更窄的数据边界时，本地执行可能很有价值。但只有完整功能同时满足质量、内存、能耗、散热和运维支持要求，本地执行才算可行。第 81 章 中的模型选择方法和 第 82 章 中的服务契约仍然适用，区别只在于：这里要验证的是异构设备群，而不是受控的服务器集群。

固定设备支持范围

从功能出发，而不是从参数量或运行时出发。设备支持范围说明功能支持哪些设备和条件，以及怎样才算“受支持”。这样，“在本地运行这个模型”就不再是模糊愿望，而是一项可以测试，也可以撤回的承诺。

支持范围应当比“所有较新的手机”更具体。有效的设备档位必须列出真正影响执行的属性，包括操作系统构建版本、运行时版本、片上系统系列、内存档位、剩余存储空间和可用后端。只写市场名称并不够，同一产品系列中的设备也可能有不同的内存和散热表现。

把支持范围表示成一张验收矩阵。行是受支持的设备档位，列是相关状态，例如刚启动和已经预热的进程、未安装和已安装模型、正常和不足的存储空间、正常和低电量、前台和后台负载、离线和弱网，以及常温和受温控限制的状态。每个单元格都根据同一份功能契约记录通过、失败或不支持。这样，团队能在发布前看到缺口，而不必等用户反馈暴露问题。

算清需要装入内存的全部内容

原始参数体积只是内存预算的第一项。对解码器模型，可以先用下面的式子做规划估算：

$$\begin{aligned} M_{\mathrm{weights}} &\gtrsim \frac{N_{\mathrm{params}} b_w}{8} + M_{\mathrm{metadata}}, \\ M_{\mathrm{KV}} &= \frac{2 B L n_{\mathrm{kv}} d_h S b_{\mathrm{kv}}}{8}, \\ M_{\mathrm{peak}} &= M_{\mathrm{weights}} + M_{\mathrm{KV}} + M_{\mathrm{workspace}} + M_{\mathrm{runtime}} + M_{\mathrm{app}}, \\ M_{\mathrm{peak}} &\le M_{\mathrm{budget}}. \end{aligned}$$

其中，$M_{\mathrm{weights}}$ 是存储权重所占的空间；$N_{\mathrm{params}}$ 是参数量；$b_w$ 是每个参数平均占用的存储位数；常数 $8$ 用来把比特换算成字节；$M_{\mathrm{metadata}}$ 包括量化缩放因子、零点、分块头、张量对齐和其他格式数据。这里特意使用不等式，因为打包张量的计算结果只是下界，而不是安装体积或常驻内存的保证。

$M_{\mathrm{KV}}$ 是未压缩 KV 缓存的规划体积；系数 $2$ 对应键和值；$B$ 是并发序列数；$L$ 是 Transformer 层数；$n_{\mathrm{kv}}$ 是每层的 KV 头数；$d_h$ 是头维度；$S$ 是每个序列缓存的词元数；$b_{\mathrm{kv}}$ 是每个缓存元素占用的存储位数。具体运行时采用的填充方式、缓存布局、滑动窗口或跨层共享都会改变实测结果。

其中，$M_{\mathrm{workspace}}$ 包括激活、临时缓冲区、编译内核和后端工作区。$M_{\mathrm{runtime}}$ 是推理运行时及其已加载的库。$M_{\mathrm{app}}$ 是推理期间应用还需要的其他全部内存。三者与权重、KV 缓存相加，得到峰值常驻内存 $M_{\mathrm{peak}}$；它必须小于功能可用的内存 $M_{\mathrm{budget}}$。这个预算不是设备标称内存，因为操作系统、其他进程、图形、媒体和应用本身都已经占用了一部分。

一个 30 亿参数的四比特模型，原始打包权重约为 1.5 GB。这个数可以迅速排除明显不可行的候选方案，却不能证明模型一定装得下。量化元数据、张量对齐、随上下文增长的缓存、运行时分配和内存压力都可能显著抬高实际峰值。应当在真实进程中测量导出的制品，并覆盖最长的受支持上下文和资源需求最高的受支持输入。

KIVI 说明了为什么 KV 缓存需要单独核算。其作者观察到键和值的分布不同，因此分别评估了按通道量化键、按词元量化值的方案，而没有把缓存当作普通模型权重处理 (Liu et al. 2024)。结果只适用于论文评估过的模型和运行时。它说明两比特缓存值得测试，却不能证明两比特缓存在所有场景都不会损失质量。

# 示例规划参数，请替换成候选制品的真实数据。
params = 3_000_000_000
weight_bits = 4
batch = 1
layers = 28
kv_heads = 8
head_dim = 128
cached_tokens = 4096
kv_bits = 8
other_gb = 1.1  # 运行时、应用、工作区和实测格式开销

weights_gb = params * weight_bits / 8 / 1e9
kv_gb = 2 * batch * layers * kv_heads * head_dim * cached_tokens * kv_bits / 8 / 1e9
peak_gb = weights_gb + kv_gb + other_gb
print(f"打包权重：{weights_gb:.2f} GB")
print(f"规划 KV 缓存：{kv_gb:.2f} GB")
print(f"规划总量：{peak_gb:.2f} GB；请在每个设备档位验证峰值 RSS")

测量完整路径和设备状态

本地路径和远程路径包含不同的延迟项。对已经安装在设备上的本地制品：

$$T_{\mathrm{local}} = T_{\mathrm{load}} + T_{\mathrm{prefill}} + \sum_{k=1}^{O} T_{\mathrm{decode},k} + T_{\mathrm{post}},$$

其中，$T_{\mathrm{load}}$ 是加载和专门化模型所需的时间；$T_{\mathrm{prefill}}$ 是处理输入的时间；$O$ 是输出词元数；$T_{\mathrm{decode},k}$ 是生成第 $k$ 个输出词元的时间；$T_{\mathrm{post}}$ 包括验证、渲染和功能特有的后处理。远程路径则包含上传、网络、供应商排队、远程执行和下载。两条路径没有哪一条天然更快。冷启动的本地模型可能慢于已经预热的远程服务，而热状态下的本地模型可以避开不稳定的网络延迟。

对批量为一的自回归解码，可以用带宽估算一个上限：

$$R_{\mathrm{decode}} \lesssim \frac{BW_{\mathrm{eff}}}{D_{\mathrm{token}}}.$$

其中，$R_{\mathrm{decode}}$ 是每秒生成的词元数；$BW_{\mathrm{eff}}$ 是实测设备状态下每秒可用的有效内存带宽，以字节计；$D_{\mathrm{token}}$ 是生成每个词元需要从内存搬运的字节数。这只是带宽上限，不是预测值。预填充可能受算力限制，部分权重或缓存块也可能复用；解包、反量化、不受支持的算子、同步和小型内核都可能成为瓶颈。屋顶线分析只是针对具体工作负载形成假设的一种测量方法，而不是低精度一定能提速的承诺 (Yuan et al. 2024)。

至少要在同一组任务上测量冷启动、热启动、首词元时间、每输出词元时间、端到端延迟、峰值常驻内存、错误率和质量。报告 p50 和 p95，不要只挑最好的一次结果。能耗也应按每项合格任务统计，而不能只看每词元能耗。设备侧可以用下面的式子估算：

$$E_{\mathrm{task}} = \int_{t_0}^{t_1} \left(P(t)-P_{\mathrm{idle}}\right)\,dt,$$

其中，$E_{\mathrm{task}}$ 是任务增加的能耗；$t_0$ 和 $t_1$ 覆盖完整的功能交互；$P(t)$ 是时刻 $t$ 的设备实测功率；$P_{\mathrm{idle}}$ 是可比的空闲基线。如果平台只能提供能耗代理指标，就应明确标注，并在不同候选方案之间保持测量方法一致。

短时突发会掩盖设备最关键的故障模式。应当持续运行，直到延迟、功率和温度达到热稳态，或达到测试时限。记录电池状态、充电状态、环境条件、电源模式、屏幕状态、后台负载和降频情况。Android 和 Apple 都提供应用可以读取的热状态信号，这些信号应纳入受控测试，并在适当情况下参与运行时准入判断 (Android Developers n.d.; Apple n.d.)。MLPerf Mobile 同样把模型、软件栈、设备、准确率目标和运行规则视为一个完整的基准系统 (Reddi et al. 2022)。

压缩是一项系统决策

只有压缩后的制品仍能保持任务质量，而且目标后端能高效执行其表示方式，压缩才有价值。决策记录应分别列出权重格式、激活格式和 KV 缓存格式，因为它们占用不同的内存区域，也依赖不同的内核支持。第 34 章 介绍了底层表示与内核，本节关注的是如何验证导出到设备上的制品。

MobileLLM 为小预算内的架构设计提供了有用证据。其作者研究了深而窄的十亿参数以下模型、嵌入共享、分组查询注意力和相邻计算块共享，而不是只压缩一个大得多的检查点 (Liu et al. 2024)。这个结果说明目标规模内的架构搜索值得尝试，却没有确立一种适用于所有移动设备的形状。

对训练后量化而言，校准集本身就是制品的一部分。它应覆盖真实的提示词长度、语言、模态、工具 Schema，以及少见但重要的请求类别。AWQ 在仅量化权重的方法中，利用实测激活来保护显著的权重通道 (Lin et al. 2024)。SmoothQuant 则把一部分量化难度从激活转移到权重，以支持 W8A8 执行 (Xiao et al. 2023)。两种方法解决的问题不同，论文中的汇总基准不能替代针对确切制品与后端组合所做的任务专项评估。

当训练后量化无法保持足够质量时，才需要考虑量化感知训练或低比特预训练。Apple 公开的一款约 30 亿参数端侧模型采用了两比特量化感知训练和 KV 缓存共享 (Li et al. 2025)。BitNet b1.58 报告了一类从训练开始就使用 $\{-1,0,1\}$ 三元权重的模型 (Ma et al. 2024)。在数学点积中，三元权重可以把一般乘法替换成取值、变号或置零。但部署后的系统仍然包含缩放因子、激活处理、注意力、归一化、打包和内存传输。零值权重不会自动形成结构化稀疏，只有后端内核真正利用这种表示，设备才会少做运算。越小不一定越快。

构建可部署的制品

源检查点不是移动端制品。导出与图下降会针对特定算子集、内存规划、张量布局、精度和后端专门化计算图。例如，ExecuTorch 将导出和提前图下降与设备端运行时分开，并为所选后端生成程序 (PyTorch Foundation n.d.)。Core ML 可以在 CPU、GPU 和 Neural Engine 之间调度受支持的计算，但实际计算计划和兼容性仍取决于转换后的模型与目标操作系统 (Apple n.d.)。GGUF 之类的容器可以保存张量和模型元数据，但运行时构建版本仍须实现对应架构、分词器语义、量化类型和所需算子 (ggml-org n.d.)。格式不等于兼容性。

至少要在部署指纹中记录：

• 源检查点和不可变修订版本；
• 分词器、特殊词元和提示词模板；
• 适配器集合及其合并状态；
• 导出图和导出器版本；
• 量化配置和校准集修订版本；
• 编译制品格式和密码学摘要；
• 运行时版本和链接的算子集；
• 后端委托器、回退分区和计算策略；
• 支持的操作系统构建版本、ABI 和设备类别；
• 路由、安全、上下文和采样策略。

部署指纹可以避免一种常见的诊断错误：两个构建版本虽然被称为“同一个模型”，实际却使用了不同的模板、导出器、量化方式或后端。每项质量结果和设备指标也都应以这份指纹为索引。

性能测试前，先确认语义一致。让源计算图和编译制品运行同一组黄金提示词，在既定容差内比较分词、结构化输出、停止处理和任务结果。检查分区计划中是否存在不受支持的算子。静默回退到 CPU 可能保住正确性，却会破坏延迟或能耗，因此能力探测必须报告实际后端委托器和每一处 CPU 回退。

明确规定混合路由

混合执行是一项策略决策，不能充当包揽所有故障的异常处理器。应当在执行前确定路由：

$$r(x,d,s,p) \in \{\mathrm{local},\ \mathrm{cloud},\ \mathrm{decline}\},$$

其中，$x$ 是请求及其任务类别；$d$ 是数据分类；$s$ 是当前设备状态，包括模型可用性、内存、热状态、电池和网络连接；$p$ 是带版本的产品策略；$r$ 是所选路由。“拒绝”也包括请用户下载模型、稍后再试、更改设置或换用其他方式完成任务。

对只能本地执行的请求，模型不可用、存储空间不足或设备过热都必须进入本地错误或拒绝路径，绝不能上传。对允许使用云端的请求，传输前必须具备既定的法律与产品依据，并在要求时取得用户明确同意。没有许可就不得静默回退。如果两条路径都可用，应根据实测质量和剩余截止时间选择，而不是笼统猜测请求是否“困难”。

只要可能，就应在执行前完成路由。本地产生部分输出后再回退，可能造成文本重复、语义变化，或上传用户原本以为会留在本地的数据。如果本地运行在产生部分输出后失败，应返回类型明确的失败原因，再由产品契约决定是否允许用户发起新的云端尝试。绝不能在用户无感知的情况下拼接云端续写。返回结果时还要注明执行来源，也就是本地、云端或已拒绝，让界面、遥测和客服工具能够解释实际发生了什么。

本地执行不等于自动获得隐私保障

在应用内执行推理可以减少数据传输和服务器留存，但本身并不能保证隐私。输入或输出仍可能进入临时文件、剪贴板历史、备份、键盘服务、共享缓存、分析 SDK、崩溃报告、遥测、工具或云端回退。如果模型及其个性化数据没有受到应用沙箱和平台机制保护，也可能泄露敏感行为。

为完整功能绘制数据流图。对每个数据接触面记录用途、数据类别、保留期限、保护措施、接收方、删除路径，以及离线时是否工作。沿用其他移动数据的安全审查方法，包括应用沙箱边界、安全存储、经过身份验证的网络传输、最小权限、日志脱敏和依赖审查。OWASP 移动应用安全验证标准把存储、网络、平台、代码、韧性和隐私控制分开，正是因为“在本地处理”只解决了系统的一部分问题 (OWASP Foundation n.d.)。更完整的信任与授权模型见 第 56 章。

设备群遥测默认只收集不含内容的指标，例如部署指纹、路由及原因、设备档位、耗时区间、峰值内存区间、热状态、加载错误、取消，以及能够在不采集内容的前提下得到的质量结果。默认不收集提示词或模型输出内容。如果调试计划确实需要样本，应当单独授权、少量抽样、脱敏、限制访问、限定期限且可删除。OpenTelemetry 的生成式 AI 约定也明确提醒，模型输入和输出很可能含有敏感信息 (OpenTelemetry n.d.)。

安全交付模型版本

大型制品通常与应用分开下载，这会引入一整套软件更新问题，包括下载不完整、存储损坏、回滚攻击、运行时不兼容、磁盘空间不足，以及模型、分词器和适配器版本不一致。把整个制品包视为不可变对象，只有所有组件齐备后才能激活。

每个发布版本都需要一份签名的兼容性清单，其中列出制品名称、大小、密码学摘要、签名信息、部署指纹、支持的应用和运行时版本、目标设备类别，以及过期或退役策略。The Update Framework 规范了签名元数据、哈希与大小验证、版本递进，以及针对回滚、冻结和混搭攻击的防御。即使传输由平台的资源服务完成，它仍然是一套很有参考价值的方法 (The Update Framework n.d.)。

把新版本下载到当前活动制品包旁边的非活动位置。激活前，检查剩余空间和磁盘配额，验证大小、密码学摘要、签名、兼容性清单和许可证声明，再运行一次最小加载和黄金输出冒烟测试。使用原子激活，确保进程看到的要么是完整旧版本，要么是完整新版本。发布确认健康前保留上一已知正常版本。垃圾回收不能删除当前版本或回滚目标，也必须能处理下载中断留下的文件。

按代表性设备档位分阶段发布，不能只按账户百分比划分群组。当加载失败、崩溃、质量拒绝、p95 延迟、峰值内存、能耗或热事件超过既定阈值时，停止发布或回滚。服务端终止开关可以撤销该版本的可用资格，但离线行为仍必须有明确定义。如果不安全的版本已经安装，应用可能需要内置本地禁用逻辑或过期策略，不能依赖永远无法到达的网络响应。

运营设备群

这套运营闭环可以明确写成八步：

1. 固定支持范围。 记录任务类别、数据边界、质量门槛、受支持的设备档位、最低操作系统版本、离线行为和回退策略。
2. 建立指纹。 把源检查点、分词器、提示词模板、导出图、量化配置、编译制品、运行时、后端和策略作为一个候选版本统一管理。
3. 验证完整制品。 检查源模型与端侧制品的一致性、任务质量、算子覆盖、CPU 回退、存储空间、峰值常驻内存，以及验收矩阵中的每个单元格。
4. 测量持续运行表现。 在代表性设备档位上测量冷启动和热启动延迟、p50 和 p95、每项合格任务的能耗、内存压力和热稳态。
5. 注入设备故障。 覆盖模型不可用、离线启动、弱网、存储空间不足、下载损坏、后端拒绝、取消、后台负载和温控降频。
6. 分阶段交付。 验证非活动制品包，为一个小型设备档位群组原子激活，再与上一已知正常版本比较。
7. 观察并回滚。 监控不含内容的路由、质量、可靠性、延迟、能耗和热状态信号；一旦触及记录的阈值就回滚。
8. 登记每项重新验证触发条件。 模型、分词器、模板、量化方式、导出器、运行时、后端、操作系统、设备策略或功能契约发生变化时，重新执行受影响的矩阵部分。

NIST 的生成式 AI 风险管理框架把部署环境评估、上线后监控、事故响应、变更管理和退役视为贯穿生命周期的工作，而不是发布前的一次检查 (Autio et al. 2024)。这里也应采用同样的方法。质量与可观测性方法见 第 87 章，分阶段发布和回滚的详细做法见 第 89 章。

最终产物是一份部署决策记录，其中包括支持范围、准确指纹、验收矩阵、实测结果、隐私数据流、路由策略、交付计划、回滚阈值、负责人和重新验证触发条件。它可以支持本地发布、混合发布，也可以记录为何不应在端侧发布。

延伸阅读