AI 基建
0%
第十一部分 · 实践与运营 · 第 83 章

边缘与端侧部署

作者Changkun Ou
阅读时长约 10 分钟

本书大半都在从数据中心服务模型。线的另一端,是口袋里的那台设备。端侧这一档改变了设计问题:模型是「设计得小」的,而不是事后压缩出来的;推断经济学把它们推向过度训练;量化在边缘被推过服务器的 int4 底线,一路降到 2 比特乃至更低;三元权重把能耗预算转成以加法为主的算术。边缘还以 CUDA 数据中心所没有的方式碎片化,于是云与边缘的切分也成了设计的一部分,而不是事后的部署选择。

2026-06-21T23:29:44.468604 image/svg+xml Matplotlib v3.11.0, https://matplotlib.org/ FP16 INT8 INT4 蒸馏后 0.0 0.2 0.4 0.6 0.8 1.0 相对预算 内存 质量损失
图 83.1. 端侧部署压缩的示意图。量化与蒸馏会缩小内存占用,但质量损失曲线成为真正的预算。理想化相对值,非实测。

为什么在边缘运行

有四股拉力把推断挪到设备上。隐私:数据从不离开手机,这对消息、照片与健康数据是决定性的。延迟:没有网络往返,回应可以立刻开始。可用性:在飞机上或没信号的地方也能用。还有成本:没有要付给谁的按词元服务账单。与这四者对立的,是一堵硬墙。一部手机的内存、算力与功率,比一块数据中心加速器小上好几个数量级,没有高带宽内存,热预算也只以个位数瓦特计。这堵墙的形状很要紧:自回归解码是受内存带宽约束的,因为每生成一个词元都要把整套权重流过计算单元,于是在一台没有高带宽内存的设备上,词元率由每个词元要搬多少字节、而非由算术吞吐决定 (Yuan et al. 2024)。这一个事实解释了本章的两个半部,为什么模型被压小、以及为什么它的权重被挤到尽可能少的比特。

天生就小,而非压缩而来

700 亿参数的模型无法直接压到手机上;端侧这一档,从一开始就是为这个区间设计的。MobileLLM 把这一点讲得很清楚:在十亿参数以下,平常那套靠数据与规模的叙事让位给架构,深度比宽度更要紧;在同样参数量下,三十层的模型胜过十二层的 (Liu et al. 2024)。它把输入与输出嵌入绑定(输入的词元查表与输出的投影复用同一个矩阵),收回小模型里约一成多本会被浪费的参数;再利用分组查询注意力(让多个查询头共享键与值的投影、从而缩小缓存,见 第 8 章)节省下来的预算,把这些参数重新投进深度;同时在相邻块之间共享权重,使它们可以驻留在 SRAM 里并被简单算两遍,从而避开 SRAM 到 DRAM 的权重搬运这一项延迟成本。其结果是,一个三亿五千万参数的模型,在 API 调用的意图准确率上追平 LLaMA-2 7B:小二十倍的模型,在适合它的任务上站住了。OpenELM 推的是一个互补的想法,在各层之间非均匀地分配参数,靠近输入处窄、越深越宽;这一逐层缩放在十亿参数预算下带来 2.36% 的准确率增益,却只用均匀基线一半的预训练词元 (Mehta et al. 2024)。

还有两个手段界定了这一档。第一是用数据质量顶替规模:Phi 一脉在过滤与合成的「教科书级」数据上训练,达到了数倍于它的模型的编码与推理分数 (Gunasekar et al. 2023)。第二,也是如今生产中更常见的路线,是蒸馏。Gemma 2 把它的 20 亿与 90 亿模型,对着一个更大的教师那完整的软目标分布训练,而不是对着 one-hot 的下一词元标签,并报告说这即便在相等或更少的词元下也胜过从头训练 (Gemma Team, Google DeepMind 2024)。MiniCPM 添了一个训练调度技术,即 warmup-stable-decay 调度器,其损失只在短短的末段衰减里下降,于是低成本的衰减分支从一个共享的主干分叉出来,让小模型的扩展实验变得负担得起 (Hu et al. 2024)。

这些模型小的深层原因是经济性,而且这种经济性会反过来决定训练时长。Chinchilla 提出的每参数约 20 词元计算最优比,最小化的是训练成本,但一个部署的模型在它的整个生命里、对每一个请求都要付推断成本。摊到十亿个请求上,总成本由一个被训练得远过计算最优的更小模型来最小化,因为那随参数量增长的、每请求的推断成本,盖过了一次性的训练成本 (Sardana et al. 2024)。这正是这一档里每个模型都被过度训练的缘故:Gemma 2 的小模型跑过其计算最优词元数的五十多倍,而 MiniCPM 把它自己的最优数据对模型比测到约 192 比 1,比 Chinchilla 高出一个数量级。来自服务成本的那条约束,曾在 第 5 章 里为过度训练一个前沿模型撑腰,在这里咬得最狠。

训练后压缩也可行,但产出的是另一种系统。Sheared LLaMA 把一个 7B 模型剪枝到 13 亿与 27 亿、再在一小部分词元上继续预训练 (Xia et al. 2024),这是一条真实而高效的路,但它继承的是一个云模型的架构,而非得到 MobileLLM 那种缓存驻留的块共享、或下一节所需的量化感知训练。厂商把这个「设计得小」的档位做成了产品。Gemini Nano 是端侧的尺寸:最初的 Gemini 1.0 Nano 有 18 亿与 32.5 亿参数两档,从更大的 Gemini 模型蒸馏而来、并做 4-bit 量化 (Gemini Team, Google 2023);到 2026 年年中,这条线已经从 Nano v3 走到基于 Gemma 4 的 Nano 4,多模态覆盖文本、图像与音频,仍经 Android 的 AICore 提供 (Android Developers 2026)。Apple 的端侧基座模型约 30 亿参数,以 2-bit 量化感知训练与 KV 缓存共享来训练,并按功能换入一个个小的 低秩适配(LoRA) 适配器,而一个更大的模型则在 Private Cloud Compute 里等着接那些困难请求 (Apple 2025)。它们共同的模式是:一个小的本地模型应付常见情形,再留一道通向云端的暗门去接其余。这两条产品线都深度绑定各自厂商;读者自己能部署的「设计得小」档位,是开放许可的那一批:Gemma 4 的边缘尺寸 E2B 与 E4B(Apache-2.0,也是 Nano 4 的底座),以及 Qwen3.5 阶梯上 1B 以下的那一端 (Google 2026)。

req 用户请求 route 对小模型 来说难吗? req->route dev 端侧模型 ~2-3B,2-4 比特 + 按功能的 LoRA route->dev 否(常见情形) cloud 更大的云模型 (Private Cloud Compute) route->cloud 是(长尾) out 回应 dev->out cloud->out
图 83.2. 端侧这一档与它的暗门。一个小的量化模型把常见请求整个在设备上办掉,并在一个驻留的基座上按功能换入 LoRA 适配器;它办不了的请求,路由到一个更大的云模型,在 Apple 的栈上跑在一个保护隐私的 Private Cloud Compute 飞地里。取材自 Gemini Nano 与 Apple Intelligence 的设计。

把量化做到极致

服务器端的量化(第 34 章)以一点质量换吞吐;在一块内存有余的 A100 上,int8 主要换来更多并发请求。在边缘,预算反了过来:内存是主导约束,既决定几个 GB 统一内存中能放下多少静态权重,也决定每个词元流过这些权重时需要多少带宽。支配这里的恒等式很直白,weight memory=Nparams×bbits/8\text{weight memory} = N_{\text{params}} \times b_{\text{bits}} / 8,其中 NparamsN_{\text{params}} 是参数个数,bbitsb_{\text{bits}} 是每个参数占用的比特数,除以 8 是把比特换成字节。于是一个 3B 模型在 16 比特下是 6 GB、在 4 比特下 1.5 GB、在三元下 0.6 GB,而因为解码受内存约束,更少的比特也直接意味着每个词元搬更少的字节、从而更低的延迟与能耗。同一项压缩既让模型放得下,又让它跑得快。

标准的底线是只对权重做的 int4 训练后量化,把权重保在 4 比特、激活保在更高精度,靠像 GPTQ 那样的二阶误差最小化 (Frantar et al. 2022) 与 AWQ 对那些乘上大激活的显著权重通道的缩放 (Lin et al. 2023) 来做准。底线之所以落在权重、而非激活上,缘由在离群值问题:少数涌现的激活维度携带巨大的幅度,直接低比特量化会把它们毁掉,LLM.int8() 的办法是把那些维度保在更高精度 (Dettmers et al. 2022),SmoothQuant 则用一个逐通道的重新缩放,把难处从激活迁进权重 (Xiao et al. 2022)。权重量化得优雅,激活则不然,这正是最激进的边缘方案把激活保得比权重宽的缘故。

到 4 比特以下,训练后量化掉下悬崖,因为舍入误差不再是训练好的权重能吸收的小扰动。于是边缘转向量化感知训练,它在前向里模拟舍入、却用一个直通估计器让梯度穿过它(把不可导的舍入这一步当作恒等映射、好让梯度照常回传),于是网络学到的是对「被量化」稳健的权重、而非把权重事后舍入。Apple 的端侧模型给出生产实例,用量化感知训练加可学习的权重裁剪把权重压到每权重 2 比特、把嵌入表压到 4 比特、把 KV 缓存压到 8 比特,再用适配器把丢掉的质量找回来 (Apple 2025)。

最激进的方向是 1 比特。BitNet 从头训练二值权重 (Wang et al. 2023),而 BitNet b1.58 把它们松弛为取自 {1,0,1}\{-1, 0, 1\} 的三元值,每个约 1.58 比特,据报告在大约 30 亿参数往上,能以相同大小与训练词元在困惑度(模型对留出文本的「意外」程度,越低越好)与下游任务准确率上都追平一个全精度 transformer (Ma et al. 2024)。收益来自权重取值本身。当权重取自 {1,0,1}\{-1, 0, 1\},点积 iwixi\sum_i w_i x_i 里没有乘法:每一项是 +xi+x_ixi-x_i 或零,于是矩阵乘法退化为条件加法,零值自然带来结构化稀疏,而内核变成纯整数的,这恰是一块没有强浮点吞吐的 CPU 或 NPU 所要的。报告出的增益随之而来:在 3B 上,内存少 3.55 倍、解码快 2.71 倍,而在 7nm 硅上,矩阵乘法的算术能耗约低 71 倍。后续的工作把激活推到 4 比特 (Wang et al. 2024),并发出一个整数内核的 CPU 推断栈 (Wang et al. 2024)。一比特级的训练能否在前沿规模上成立,尚无定论,因为现有追平证据顶到约三十亿参数、且这套配方要求从头训练、没有训练后的退路,但边缘一侧的内存与能耗理由是直接的:设备的预算,是按每权重的比特数来数的。

边缘另一个内存手段是 KV 缓存,它随上下文增长、在长上下文下能盖过权重。把它非对称地量化到 2 比特(键缓存按通道、值缓存按词元,因为它们的分布不同),能把峰值内存降低一半多,而质量几无损失 (Liu et al. 2024)。

params = 3e9                        # 一个 3B 端侧模型
phone_budget_gb = 4.0              # 可以花在权重上的内存
for bits in [16, 8, 4, 2, 1.58]:
    gb = params * bits / 8 / 1e9
    fits = "fits" if gb <= phone_budget_gb else "too big"
    print(f"{bits:>4} bits/weight -> {gb:4.1f} GB weights  ({fits})")
print("memory is the budget: quantization is what makes a model fit on the edge")

运行时

务实的基底是像 llama.cpp 这样的软件,一个依赖极少的 C/C++ 推断引擎,能在普通 CPU 上、以及通过 Metal 与 NEON 在 Apple silicon 上运行 (ggml-org 2023),用单文件的 GGUF 格式携带量化后的权重、以及加载它们所需的全部元数据,架构、分词器与特殊词元,于是一个模型无需外部配置就能加载 (ggml-org 2023)。它的每比特质量来自一个 k-quant 方案,它在超块里以 2 到 6 比特量化、并把更多比特花在最要紧的张量上 (Kawrakow 2023)。别的栈下别的注。Apple 的 MLX 利用 Apple silicon 的统一内存,数组住在共享内存里、在 CPU 与 GPU 之间无拷贝地分派 (Apple 2023)。MLC-LLM 把一个模型编译到许多后端、包括经由 WebGPU 进浏览器,建在 TVM 编译器之上 (mlc-ai 2023; Chen et al. 2018),而 ExecuTorch 则把一个 PyTorch 模型下降到从手机一路到微控制器上运行 (PyTorch Foundation 2024)。

那些专用加速器每瓦更快,却把边缘弄碎了。Apple 的 Neural Engine 经由 Core ML 触及,要把模型重写才能映上去 (Apple Machine Learning Research 2022);Qualcomm 的 Hexagon NPU 经由一个单独的 SDK 触及 (Qualcomm Technologies, Inc. 2024);来自 Arm 与 Qualcomm 的移动 GPU 经由 OpenCL 或 Vulkan;而 Google 的 Tensor SoC 带着自己的 TPU。各有自己的运行时、算子支持与量化格式,于是边缘碎片化到了数据中心所没有的程度:在那里一切以 CUDA 为中心,一套工具链就能横跨几乎每块加速器。一个可移植的、跑在 CPU 上的 GGUF 模型,往往是处处都能依赖的底线,再在硬件与工具链允许处加上一条 NPU 路径。

有三种技术在设备上抠回速度。投机解码让一个微小的草稿模型提出若干词元、由更大的模型在一次并行前向里验证,把一个串行的、受内存约束的解码变成部分批处理的,而不改变输出分布 (Leviathan et al. 2023)。跨层的 KV 缓存共享,缩小了设备上第二大的内存消耗者 (Apple 2025)。而 LoRA 适配器换入让一个冻结的基座驻留、由小的低秩适配器按功能把它特化 (Hu et al. 2022),正是 Apple 按功能行为背后的机制。当一个请求确实逃到云端,那道隐私的缺口由架构补上:Apple 的 Private Cloud Compute 让更大的模型跑在无状态计算、无特权运行时访问、以及一个可验证的透明日志之下,于是处理数据的那段代码可被审查 (Apple Security Engineering and Architecture 2024)。

争议所在

有多少推断最终落到设备上,尚无定论。一种看法认为,随着手机内存增长、小模型质量攀升,端侧模型会吸收掉大多数日常请求,把云端留给困难任务。另一种看法认为,与前沿模型的能力差距很大,且其拉开的速度快过设备预算的增长,于是边缘仍是一个隐私与离线的小众,主要工作仍会留在云端。两股拉力都是真的,而一个产品所画的切分,取决于它最难请求、而非中位数请求,是否必须在本地跑。还有一场更窄的争议坐在量化故事内部:三元配方在约三十亿参数前追平全精度,但一比特级的训练能否够到前沿规模、以及值不值得为了一探究竟而从头训练一个没有训练后退路的模型,是一个开放的经验问题。

下层约束

设备的内存预算一路反向约束到预训练。一个在手机内存里放不下、或放得下却跑不到可用词元率的模型,在那里根本无法被服务,于是端侧这一档是从一开始就被训练得小、被过度训练得远过计算最优(因为推断成本主宰它一生的账单)、并从一开始就量化感知,而非事后剪枝。Apple 的 2-bit 量化感知训练,正是把这条约束做成了一个训练目标,而一个三元权重格式更深一层,决定了一个只做加法、无乘法的内核。硬件的内存不只决定模型的大小,还决定它被训练多久、以多少比特训练、乃至它内层循环的那套算术,这是贯穿全书的约束传导里最清晰的一个版本。

延伸阅读

  • Android Developers, “Announcing Gemma 4 in the AICore Developer Preview” (Gemini Nano 4 基于 Gemma 4 E2B/E4B;多模态,经 AICore 提供), 2026. android-developers.googleblog.com
  • Google, “Gemma 4: Byte for byte, the most capable open models” (E2B、E4B、26B MoE、31B 稠密;Apache-2.0), 2026. blog.google

评论

登录后评论