边缘模型内存预算要看长请求与峰值并发

8 GB 内存的设备，能不能跑一个 2 GB 的模型？作者的结论是：光看这两个数字，答不了。模型文件只占存储账本的一项，推理时还要容纳驻留权重、KV cache、计算缓冲区，以及操作系统和配套服务。

这篇文章的价值在于给出一套容量验收方法：先算理论下限，再测最长请求和真实并发。文中的 3B 模型、512 MiB 缓存和 2 GB／8 GB 都是假设算例，没有具体开发板的实测成绩。

为什么 8 减 2，算不出剩余推理内存

「模型需要 4 GB」可能指文件大小、驻留权重、进程峰值、GPU 显存，也可能指整机需求。口径没对齐，减法就没有意义。GGUF 文件能放进磁盘，只能说明存储过关。

以三十亿参数的假想模型为例，每个参数恰好占四位，裸权重下限是：

3,000,000,000 × 4 ÷ 8 = 1,500,000,000 bytes

约为 1.40 GiB；八位约 2.79 GiB，十六位约 5.59 GiB。这里必须区分十进制 GB 和二进制 GiB。实际文件还有量化比例因子、零点、较高精度张量、文件头和对齐等开销，Q4 与 INT4 也不是跨格式通用的字节承诺。

因此，作者要求固定模型文件的哈希，记录准确字节数，再检查运行时加载了什么。权重量化不会让操作系统、计算图和 KV cache 按相同比例缩小。llama.cpp server 把加载方式、上下文、设备卸载和 K/V 类型分开配置，正说明它们需要分别记账。

内存映射（memory mapping）也没有绕过物理内存：推理访问的文件页仍可能驻留，而且可能被多个进程共享。RSS 会包含共享页，PSS 按比例分摊共享页，但两者都不能独自回答整机是否够用。

容量验收要看同一配置、同一时刻的内存占用，不能把文件大小和不同监控口径直接相加减。

512 MiB 的 KV cache，到底怎么算出来

自回归生成会复用此前 token 的键和值，避免每一步重新计算历史内容。保存这些中间结果的 KV cache，是长上下文和并发请求需要单独预算的部分。

下面的公式用来估算标准注意力结构下的缓存数据量：

KV bytes ≈ 2 × attention layers
         × KV heads × dimensions per head
         × allocated tokens per session
         × bytes per K/V element
         × simultaneous independent sessions

要看准 KV heads 这一行：它不是 query heads。Grouped-query attention 和 multi-query attention 的 KV 头数可能更少；K、V 类型不同时应分别计算。滑动窗口、混合架构或跨层共享状态，也不能直接套这个统一公式。

假设有 32 层注意力、8 个 KV 头，每头 128 维，K/V 元素各占 2 bytes，单会话分配 4,096 tokens：

2 × 32 × 8 × 128 × 4,096 × 2 = 536,870,912 bytes ≈ 512 MiB

要留意其中的 4,096：它表示假定的分配长度，不是用户实际输入的字符数，更不是开发板测量值。

两个独立会话各分配 4,096 tokens，理论 KV 基线为 1,024 MiB；单会话改为 8,192 tokens，在其他假设不变时也会翻倍。如果两个会话分别分配 4,096 和 2,048 tokens，则是 512 MiB 加 256 MiB，共 768 MiB。

但运行时若提前预留两个完整的 4,096-token 槽位，就不能按 768 MiB 算。共享模型权重，也不代表不同对话历史能共享 KV。

缓存量化还要另算。降低 K/V 精度可以减少名义数据量，但比例因子、残余存储、转换缓冲区和延迟会影响实际收益。把缓存从 GPU 卸载到 CPU，则是改变内存位置并增加传输工作。llama.cpp server 可以分别选择 K、V 类型，所以一句「用了四位量化」，未必说清缓存精度。

怎样把一次短聊，变成可复现的容量验收

业务输入与模型配置之间，还差一次完整的 token 核算。

作者举的例子是：最长输入 3,000 tokens，回答额度 800，指令和模板再占 200，合计已经达到 4,000。对于 4,096-token 上下文，再多 150 tokens 就可能触发截断，甚至还没走到内存不足。改成 8,192 可以缓解上下文限制，也可能增加运行时预留的 KV。

所以，100-token 演示无法证明产品可用。验收至少要把四个阶段并排记录：静态估算、加载后空闲、最长单请求、最大预期并发。静态阶段可以填文件字节数和理论 KV；计算工作区、系统占用没有测过，就留空或写「待测」，不要随手加一个安全百分比。

测试应从正常系统镜像启动，保留检索、音频、显示等日常服务。固定文件哈希、tokenizer、架构、运行时与后端版本、上下文限制和 K/V 类型，再运行最长请求、真实重叠请求，并重复几轮观察恢复情况。

并发必须有明确形状，例如两个最长输入在提示词处理阶段重叠。线程数和在线人数都不能代替这个定义，因为运行时可能排队、复用缓存或提前预留。如果产品选择串行处理长请求，等待时间和超时也要一起验收。

Linux 可以记录 /proc/meminfo 中的 MemAvailable，以及推理进程 smaps_rollup 的 RSS/PSS；容器还要记当前用量与上限，有设备内存计数器也应保留。每个值都带采集时间，同时记录 swap、OOM 和失败请求。运行时没报告的字段，就写「未报告」。

进程 RSS/PSS 可能已经包含权重映射、KV 和缓冲区，不能把这些明细再加一遍。统一内存上的 GPU 计数与 RSS 可能重叠；独立显存则可能先耗尽，而系统 RAM 仍有余量。

我的判断

我赞同作者把「能跑」改成一个有条件的结论：固定模型、配置和业务负载之后，最长请求及目标并发都完成，峰值、失败记录和恢复行为才有验收意义。对需要检索长手册、同时驱动显示或音频服务的设备，这比模型文件大小更接近真实需求。

但这是一套测试设计，不是硬件选型榜单。作者没有目标板运行记录，也没有 3B 与 7B、不同量化格式的成对测试。它不能证明某种格式更省内存，也不能支持「8 GB 足够」或「至少需要 16 GB」这样的采购结论。

相比按参数量估算或给文件大小乘倍数，这套方法更可追溯，代价是必须拿到目标设备实测。静态估算仍适合初筛，只是不能越级成为验收结果。

故障阶段也需要分清：长输入被截断，应先检查 tokenizer 和输出额度；仅并发 OOM，应检查独立 KV、重叠时段和容器或设备限制；首轮成功、后续恶化，则检查缓存释放与排队。改一个变量，再复跑原负载，才知道改动是否解决原问题。

压缩权重、缩短上下文或串行化请求，都可能换来容量空间，也可能损害答案和响应时间。容量筛选之后，还要用业务题集验证答案，并单独检查首 token 延迟 TTFT、每输出 token 耗时 TPOT、内存与功耗。原文没有这些对照结果，不能替它补结论。

能拿来做什么

• 给本地推理或 Node 接入的边缘模型整理一份可复现记录，写明模型哈希、运行时与后端版本、tokenizer、上下文、K/V 类型和卸载设置，避免只留下「四位模型」。
• 从业务允许的最长输入出发，合并系统指令、检索文本和输出额度计算 token 预算，再验证是否截断，以及扩大上下文后的内存变化。
• 按真实请求时序压测，让最长请求实际重叠，并保留配套服务；如果采用串行策略，同时记录等待和超时。
• 为每个候选配置保留四阶段记录和原始日志。遇到 OOM，先定位加载、输入处理、生成还是并发阶段，再决定调整配置或更换设备。