端侧大模型推理：规格表不会告诉你的真实取舍

在设备端运行大语言模型，常被误以为只是"没有网络的云"。但事实远非如此——内存是固定的、精度是一个需要权衡的杠杆、延迟里藏着冷启动，而且没有自动扩容来替你掩盖错误。本文梳理那些决定端侧推理究竟是"演示"还是"产品"的关键取舍。

On-Device LLM Inference

为什么要把推理放到设备上

把推理搬到端侧，通常有三个驱动力：数据不能离开本地、运行环境没有可靠网络、以及延迟不能依赖一次网络往返。工厂车间、安全设施或野外设备往往同时满足这三点。

当其中任意一条成立时，云就不再是选项，问题随之变成：在本地究竟能塞进多少能力。这是一种与云端完全不同的设计思维——不是追求无限扩展，而是在有限资源里做减法。

内存是一堵硬墙

在云上，内存可以按需租用；在设备上，你没有这个选择。模型权重、用于保存上下文的 KV 缓存（key-value cache）以及运行时，必须在设备现有的内存里同时容纳下来。

这让上下文长度从一个"自由参数"变成了"预算决策"。更长的提示词会让缓存膨胀，而缓存与权重争夺的是同一块固定内存。原文给出的务实建议是：按设备来确定上下文长度，而不是按模型理论上的最大值。

这是最容易被忽视、也最常"爆雷"的地方——上下文长度会悄悄把缓存撑大，直到它与权重发生内存碰撞。

KV 缓存（Key-Value Cache）是 Transformer 架构在自回归生成时的核心加速机制：模型在处理每个新 token 时，需要"回顾"之前所有 token 的注意力键（Key）和值（Value）向量。若每步都重新计算，代价极高；KV 缓存的做法是把这些中间结果保存在内存中，以空间换时间。问题在于，缓存大小与上下文长度成正比——上下文越长，缓存占用越大。具体来说，缓存占用约等于 2 × 层数 × 注意力头数 × 每头维度 × 序列长度 × 精度字节数。以一个中等规模的 7B 参数模型为例，在 4096 token 的上下文下，KV 缓存就可能达到数百 MB，与模型权重本身直接竞争同一块物理内存。这正是为什么在端侧场景中，上下文长度不是一个可以随意调大的参数，而是必须根据设备可用内存精确规划的预算项。

精度是最主要的调节杠杆

降低数值精度能缩小模型体积、提升速度，但要付出一定的质量代价。真正的功夫在于：选一个既能装进内存、又能保住你所需行为的精度。

原文强调了两点警示：

用你真正要发布的精度做基准测试，而不是实验室里测过的那个更高精度版本。同一个模型在更低精度下，行为可能截然不同。
量化带来的质量损失在不同任务上并不均匀，所以要在你自己的任务上测试，而不是用一个通用基准。

换句话说，精度能压到多低，是一个经验性问题，答案只能靠在真实任务上实测得出，没有一个放之四海皆准的固定数字。

模型量化（Quantization）是端侧部署最常用的压缩手段，其核心思路是用更少的比特数来表示模型权重。常见格式包括：FP32（32位浮点，训练标准精度）、FP16/BF16（16位浮点，推理常用基线）、INT8（8位整数，体积减半、速度提升显著）、以及更激进的 INT4 甚至 INT3/INT2。以一个 7B 参数模型为例：FP16 约需 14GB 内存，INT8 降至约 7GB，INT4 则可压缩到约 3.5GB，这对于端侧设备往往是能否运行的分水岭。量化的关键挑战在于误差的非均匀分布——不同层、不同任务对精度损失的敏感度差异极大。例如，推理类任务往往比文本摘要更容易因量化出现退化，而模型中的某些关键层（如注意力输出层）对精度损失尤为敏感。这也解释了为什么不能依赖通用基准来判断量化效果，必须在自己的下游任务上实测。

延迟里包含冷启动

云端延迟通常是在"热"状态下测量的。而在设备上，模型往往要先加载进内存，这个冷启动时间可能主导用户的第一印象。一个在模型就绪前到达的请求，要么失败，要么等待。

解决思路是把"加载"当成一个可见状态来对待：

显示模型正在预热
对首个请求采用退避重试（backoff）
不要把预热期间的错误当成崩溃上报

加载过程中返回的 503，应被视为一个正常信号，而非故障。冷启动之所以如此关键，是因为它常常主导第一个请求——而第一个请求恰恰塑造了用户的整体印象。

没有自动扩容，错误无处遁形

在云上，一个糟糕的容量估算会被自动扩容悄悄抹平；在设备上，你没有任何可以扩容的空间。这把门槛抬高到了三件事上：

发布前测量真实的内存余量（headroom）
用均值而非中位数来估算吞吐量，这样一个慢用例不会被平均掉
观察负载下到底是哪种资源在饱和，而不是盲目相信某个比例

设备会惩罚每一个走捷径的决定。这句话几乎可以作为端侧工程的座右铭。

用均值而非中位数来估算吞吐量，背后有严格的工程理由。在云端，自动扩容机制会在请求高峰时拉起更多实例，慢请求的尾延迟被"稀释"在整体流量中。但端侧只有一个实例、固定的资源上限，一次长上下文推理或内存压力峰值就可能阻塞后续全部请求。中位数会过滤掉这些"慢但真实存在"的用例，让容量估算看起来比实际情况乐观。均值则保留了长尾的影响，使估算结果更接近最坏情况下的真实负载。此外，"观察哪种资源在饱和"也至关重要——端侧设备可能同时存在 CPU、GPU/NPU、内存带宽等多种瓶颈，盲目优化推理速度却忽视内存带宽饱和，往往只会把瓶颈从一处转移到另一处，而非真正提升整体性能。

一份简短的落地清单

原文给出的检查清单极具操作性，值得贴在工位上：

在你的目标上下文长度下，模型、缓存和运行时能否同时装进设备内存？
你是否在自己的任务上，用将要发布的确切精度做了基准测试？
冷启动是否被设计成一个可见、可重试的状态，而不是一个错误？
上下文长度是否按设备而非模型最大值来设定？
你是否在真实负载下测量了余量和吞吐，而不是在空闲时测？

几个常见问题

端侧推理一定值得吗？ 不一定。只有当数据不能离开、网络不可靠、或延迟不能依赖往返时才值得。否则，用云更简单。

精度能压到多低？ 低到你的任务能容忍的程度。这是靠实测回答的经验问题，不是固定数字。

最常出问题的是什么？ 内存。上下文长度会悄悄撑大缓存，直到与权重相撞。

端侧推理奖励那些对固定资源心存敬畏的人：先满足内存、发布你测过的精度、把冷启动做成可见状态、在真实负载下测量。做到这几点，你的端侧模型才真正从"演示"走向了"产品"。