小智实战解读-一块板子能上多大的模型，算清端侧大模型的内存账

HuiMinHuang2001

602人浏览 · 2026-10-12 09:54:17

HuiMinHuang2001 · 2026-10-12 09:54:17 发布

本篇速览

端侧跑大模型，第一问题不是"能不能跑"，而是"装得下多大、记得多长"。答案来自一本账：权重 + 键值缓存 + 运行时缓冲 + 框架开销。
llama.cpp 是把这本账算得最细的引擎之一，使用 GGUF 作为单文件模型格式，并提供 llama-bench 这类能直接产出对照数字的基准工具。
键值缓存随上下文长度线性增长——这是"能上多大模型"之外更要紧的隐藏变量：长对话的体感瓶颈往往在缓存而非权重。
量化省的是体积、内存带宽与计算量，代价是困惑度与生成质量，且不同张量类型的取舍不同，要实测不要想当然。
边界：这套换算依赖具体引擎与版本，换引擎或换版本要重算；本文定位是"通用内存账与基准方法"，不与任何具体推理组件做优劣对比。

一、一句话结论

之前把 LLM 换到了本地，但没回答"这块板子到底装得下多大的模型、多长的上下文"。本篇就用 llama.cpp 当作教具，把"权重 / KV Cache / 运行时 / 框架"这本内存账讲清楚，并给出用 llama-bench 做可复现测量的方法。角度始终是"怎么算"，而不是"该用谁"。

二、背景：为什么必须算这笔账

2.1 "能跑"和"跑得动"是两件事

在设备上加载一个模型，最让人误判的是：只要加载不报 OOM，就以为"能跑"。但真实体验取决于更多——首 token 多快、说得快不快、上下文拉到多长会崩。这些都不是"能不能加载"能回答的，必须先把账算清。

举一个工程上反复出现的画面：你在开发机上用 16GB 内存的笔记本把模型加载起来了，顺手问了一句"你好"，模型吐了十几个字，一切正常，于是你签字"本机可跑"。到了只有 4GB 可用内存的板子上，加载同样文件，开局也能对话，但用户聊到第三轮、上下文累积到两千字时，进程被内核 OOM Killer 杀掉，日志里只有一行 Killed。这种"开局能跑、长对话崩"的现象，根子就是没把 KV Cache 算进预算。

2.2 这本账服务于选型

写选型报告或做技术决策时，"我们想上 1.5B"这种话必须有依据。依据就是：目标设备空闲内存多少、模型权重占多少、预留多少给 KV Cache 和多轮对话、剩多少给系统与其他任务。算清楚，才知道 1.5B 是余量充足还是捉襟见肘。

一个有说服力的选型陈述应该是这样的句式：“目标板子可用内存 4GB，1.5B 级模型 Q4 权重约 0.8GB（推算），预留 2k 上下文的 KV Cache 约 0.1GB（推算），运行时与框架零头约 0.5GB（推算），合计约 1.4GB，剩余约 2.6GB 作为系统与多任务余量，因此选择 1.5B Q4 在容量上成立，但最终以真机实测为准。”——注意这里的每一个数字都标了口径（推算），且没有把推算当实测。

2.3 算账的成本远低于翻车

在纸面上算一遍账，成本是一次心算加一张表；在板子上踩一次 OOM 再回头改模型、改上下文、改内存分配，成本是重新分发、重新验证、甚至重新设计对话管理。账先算、事后再验，是端侧落地里投入小、收益实的工程习惯。

三、它是什么（事实层，取自 README 与元数据）

llama.cpp 是 C/C++ 实现的大模型推理引擎，底层为 ggml 张量库，使用 GGUF 作为模型文件格式。GitHub 仓库元数据（核实日期 2026-10-08）显示约 130.6k star，MIT 许可，最近 Release 为 v0.6.0（由根 CMakeLists.txt 的 “bump version to 0.6.0” 提交确认）。

3.1 底层是 ggml

llama.cpp 的计算底座是 ggml——一个用 C 写的张量计算库，特点是零依赖、可移植，能在从服务器 CPU 到嵌入式 ARM 的多种架构上编译运行。理解这一点很重要：所谓"llama.cpp 能跑在很多设备上"，本质上是因为 ggml 把算子实现与硬件后端解耦，使得同一份模型文件可以被不同后端的计算路径消费。本文不展开 ggml 的后端细节，只强调它对"一本账"的意义——不同后端会影响计算速度和内存带宽利用率，但不会改变"权重 + KV Cache + 运行时 + 框架"这个账的构成。

3.2 工具链分工

README 明确给出的工具链包括：llama-cli（交互式运行）、llama-server（服务端暴露 API）、llama-bench（基准测量）、llama-quantize（量化）、llama-imatrix（重要性矩阵，用于更好的混合量化）、llama-perplexity（困惑度评估）。批处理接口明确命名为 llama_batch_ext。这几个工具正好对应本篇的三条主线——llama-quantize/llama-imatrix 服务于"怎么省内存"，GGUF 文件本身承载"模型长什么样"，llama-bench/llama-perplexity 服务于"怎么测速度与质量"。

⚠️ 重要事实边界：README 只链接了 “llama-server REST API”（指向仓库 issue 9291），并未声明 OpenAI 兼容。本文不写"OpenAI compatible"，只写"提供 REST 风格的 JSON API"。写稿时这一条最容易写错，必须守住。

四、内存由哪几块构成

4.1 四块拆解

设备上跑一个大模型，内存大致由四块构成：

块	是什么	谁决定它的大小
权重	模型参数本身	参数量 × 每参数字节数（由量化档决定）
键值缓存（KV Cache）	自回归生成时缓存的 K/V 状态	上下文长度 × 层数 × 隐藏维 × 每状态字节数
运行时缓冲	中间激活、工作区	批大小、序列长度
框架开销	引擎与运行时自身	引擎版本、实现

这四块里，权重和 KV Cache 是"大头"，运行时和框架是"零头"，但零头在小内存设备上同样致命。下面分别给一个可代入的算账实例。

4.2 权重：被量化档直接决定

同样参数量的模型，fp16 与 int4 占的内存可以差出数倍。所以"能不能装下"的第一个旋钮就是量化档。llama.cpp 明确列出的张量/量化类型包括 BF16、Q1_0、Q2_0、MXFP4、Q2_K、Q3_K、TQ2_0、IQ4_NL（来自 README 提交信息）。本文只引用这些明确出现的类型，其他常见档位不臆造。

4.3 键值缓存：最容易被忽略的变量

KV Cache 随上下文长度线性增长。一个常见误判：只看权重占了多少，觉得内存够，结果上下文一拉长就 OOM 或被强制造句截断。算账时一定要把"最大上下文长度 × 预计并发"算进 KV Cache，再决定是否要缩上下文或换更小模型。

4.4 运行时与框架：不能忘的零头

中间激活缓冲和框架自身开销看起来是"零头"，但在内存紧张的设备上，这几 GB 的零头可能就是压垮加载的最后一根稻草。预算里必须给它留位置。

4.5 一个 1.5B 级模型的算账实例（推算）

下面用一个示意性架构演示换算，注意所有数字均为推算，用于展示方法，不构成对任何具体商用模型规格的声明，真机数据须实测填入。取一个 1.5B 级模型按典型配置推算：参数量 P ≈ 1.5×10⁹，层数 L ≈ 28，隐藏维 H ≈ 1536。

权重（Q4，约 0.5 字节/参数，推算）：1.5×10⁹ × 0.5 ≈ 0.75 GB
权重（fp16，2 字节/参数）：1.5×10⁹ × 2 ≈ 3.0 GB（可见 fp16 在 4GB 板子上基本装不下）
KV Cache（Q8，约 1 字节/状态，4096 上下文，推算）：2 × L × H × 4096 × 1 字节 ≈ 2×28×1536×4096 ≈ 0.35 GB
运行时与框架零头（推算）：约 0.4～0.6 GB

四项相加，Q4 + 4k 上下文的推算总额约 0.75 + 0.35 + 0.5 ≈ 1.6 GB。若设备可用内存 4GB、系统与其他任务占去 1.5GB，剩余约 2.5GB，则 1.6GB 的推算占用留出了余量；但若把上下文拉到 8k，KV Cache 翻倍到约 0.7GB，总额约 1.95GB，余量被显著压缩。这个"拉一档上下文就吃掉几百 MB"的现象，正是 KV Cache 线性增长最直观的后果。

4.6 一个 7B 级模型的算账实例（推算）

再取 7B 级模型按典型配置推算：P ≈ 7×10⁹，L ≈ 32，H ≈ 4096。

权重（Q4，推算）：7×10⁹ × 0.5 ≈ 3.5 GB
权重（Q2_K，约 0.29 字节/参数，推算）：7×10⁹ × 0.29 ≈ 2.0 GB
KV Cache（Q8，4096 上下文，推算）：2×32×4096×4096×1 ≈ 1.07 GB
运行时与框架零头（推算）：约 0.6～0.9 GB

Q4 总额约 3.5 + 1.07 + 0.8 ≈ 5.4 GB，在 4GB 板子上单是权重就超了；即便压到 Q2_K，总额也约 2.0 + 1.07 + 0.8 ≈ 3.9 GB，刚好贴着 4GB 上限，几乎没有任何余量——这意味着任何后台波动都可能触发 OOM。结论很朴素：7B 级模型在 4GB 设备上属于"容量临界"，要么大幅量化，要么上更大内存的平台，而不是"加载不报错就能用"。

4.7 把账画成一张表

模型量级	量化档（推算字节/参数）	权重（推算）	4k 上下文 KV（Q8 推算）	4GB 设备结论
1.5B 级	Q4 ≈ 0.5	0.75 GB	0.35 GB	余量充足
1.5B 级	fp16 ≈ 2.0	3.0 GB	0.35 GB	基本装不下
7B 级	Q4 ≈ 0.5	3.5 GB	1.07 GB	超容量
7B 级	Q2_K ≈ 0.29	2.0 GB	1.07 GB	临界、无余量

这张表的价值不在精确数字，而在"量级感知"：它让你在动手下载模型前，先用常识判断这条路走不走得通。

4.8 预算里两个常被低估的项

即便四块账都算到了，真机上仍可能比推算更紧张，因为还有两个常被低估的项：

激活峰值：运行时缓冲不是恒定值，某些层（尤其是注意力计算窗口最大时）会出现瞬时峰值，比平均值高出一截。预算只留平均值，就会在峰值处被挤爆。
内存碎片：权重、KV Cache、工作区分别申请释放，长时间运行后堆里会出现碎片，使得"空闲总量够、但连续大块申请失败"。这在对话管理频繁增删上下文时尤其明显。

这两项的存在，进一步说明"推算只是下限、实测才是上限"——预算里给四块账留的余量，有一部分正是用来吸收这些低估项的。

五、GGUF 是什么

5.1 单文件格式

GGUF 是 llama.cpp 使用的模型文件格式。README 的 Quick start 给出形如 llama cli -hf ggml-org/Qwen3.5-0.8B-GGUF 的模型引用（仓库名以 -GGUF 结尾），根目录提供转换脚本 convert_hf_to_gguf.py、convert_llama_ggml_to_gguf.py、convert_lora_to_gguf.py。

5.2 元信息、分词器与模板

一个 GGUF 文件不只装权重，还装了元信息、分词器（tokenizer）与对话模板（chat template）。这意味着加载一个文件就能拿到"模型 + 怎么切词 + 怎么拼对话格式"的全部信息，不用额外拉配置文件。这也是它在工程上方便的地方：分发和部署都是单文件。

5.3 转换来源

从 HuggingFace 格式、legacy ggml、LoRA 都能转换到 GGUF。如果手上的模型不是现成的 GGUF，需要先跑一次转换脚本再测量——转换本身不改变模型能力，只是换格式与（可选的）量化。

5.4 元信息里装着什么

GGUF 的元信息区（metadata）是理解"这个文件到底能不能直接用"的关键。它通常会记录模型架构名、张量维度（层数、隐藏维、注意力头数等）、量化方案、分词器类型、对话模板字符串等。对算账而言，元信息里的层数和隐藏维正好用来反推 KV Cache 的大小——你不必去查外部文档，打开文件读元信息就能算。这也是"单文件即自描述"在工程上的直接好处：账的输入数据随文件自带。

5.5 分词器为什么卡脖子

端侧语音助手的全链路里，分词器（tokenizer）是容易被低估的一环。GGUF 内嵌的分词器决定了"一句话切成多少个 token"，而 token 数直接影响两件事：一是 KV Cache 的上下文占用（token 越多、占得越久），二是 llama-bench 里 pp 指标的分母（处理同样一句话，token 数不同，pp 吞吐的天花板就不同）。如果分词器与对话模板不匹配，你会看到"模型能加载、能生成，但拼出来的对话格式乱掉、回答质量断崖"。所以拿到一个 GGUF 后，先确认它的分词器和模板是自洽的，再谈速度与质量。

5.6 对话模板的坑

对话模板（chat template）定义了 system / user / assistant 三段怎么拼成模型期望的输入串。GGUF 把模板内嵌，本意是免去外部配置，但坑在于：不同版本、不同来源的 GGUF 可能用不同的模板约定。如果你在小智链路里把 LLM 从云端换成端侧 GGUF，而模板拼法没对齐，模型就可能把整段对话当成一段无结构文本，丢失角色边界。排查这类问题时，第一步应是把 GGUF 实际用的模板打印出来，和你的编排代码拼出的字符串逐字对比，而不是先怀疑模型能力。

5.7 GGUF 版本与向后兼容

GGUF 自身有版本号。新版本 loader 通常能读旧版本文件，但反过来不一定。在板子上部署前，确认引擎版本支持你手头 GGUF 的版本，是避免"文件打不开"这类低级故障的基本动作。这也是第二章"换引擎或换版本要重算"边界的具体落地之一。

六、量化到底省了什么

6.1 省了三样，代价一样

量化把每参数从 fp16（2 字节）压到更低位宽，省下的是：存储体积、内存带宽、计算量。三者都影响速度。代价是困惑度（perplexity）上升与生成质量下降。

6.2 不同张量类型取舍不同

README 提交信息里列出的 BF16、Q1_0、Q2_0、MXFP4、Q2_K、Q3_K、TQ2_0、IQ4_NL，各有不同的压缩比与质量曲线。不能泛泛说"量化一定可接受"。务实做法是：在目标设备、目标任务的测试集上，对候选档位各测一遍困惑度与生成质量，选质量还能接受的最低档。

6.3 不能只看体积

量化档位的选择如果只看"体积最小"，很容易掉进质量坑。llama-perplexity 这类工具的存在，正是为了把"质量变化"也量化出来，让权衡有据可循。

6.4 张量类型取舍对照表（推算）

下表按量化命名惯例给出各类型的"每参数字节数（推算）"，并标出典型取舍方向。注意：字节数为基于命名约定的推算值，最终以项目实现的位宽定义为准；质量评价为定性方向，需真机困惑度实测确认。

类型（README 已列）	位宽约定	每参数字节（推算）	相对 fp16 压缩比（推算）	典型取舍方向
BF16	16-bit	2.0	1.0×	保真但体积大，端侧少用
Q1_0	1-bit + 缩放	~0.13	~15×	极紧凑，质量退化大
Q2_0	2-bit	~0.27	~7.4×	紧凑，需实测质量
MXFP4	4-bit 微缩放	0.5	4×	新方案，看实现成熟度
Q2_K	2-bit 混合	~0.29	~6.9×	比纯 Q2 略优的混合量化
Q3_K	3-bit 混合	~0.375	~5.3×	体积/质量折中档
TQ2_0	2-bit 栅格	~0.27	~7.4×	与 Q2_0 同类思路
IQ4_NL	4-bit 改进无查表	0.5	4×	4-bit 中质量较稳的候选

这张表的读法：先按设备容量挑出"装得下"的档（例如 4GB 设备基本只能在 Q2~Q4 区间选），再在同一区间内用困惑度测出"质量还行"的最低档。容量和质量是两个独立约束，顺序是先容量后质量，不要反过来。

6.5 混合量化与重要性矩阵

llama-imatrix 的存在说明了一件事：不是所有参数对输出的影响都一样大。重要性矩阵（importance matrix）的思路，是在校准数据上统计每个张量对损失的敏感度，然后让敏感张量保留更高精度、不敏感的压更低，从而在同体积下拿到更好的质量。这把"量化"从"一刀切换位宽"升级成"按重要性分配位宽"。对小模型尤其有意义——本来余量就薄，每一档精度都要花在刀刃上。

6.7 量化为什么也影响速度（带宽视角，推算）

量化省内存这件事直观，但它也影响速度，原因要在"带宽瓶颈"里找。自回归生成时，每生成一个 token，都要把全部权重从内存搬到计算单元参与一次矩阵乘。当模型权重体积超过缓存容量、必须反复从主存读取时，推理速度往往受限于内存带宽而非算力——这就是所谓的"带宽受限（memory-bandwidth bound）"。在这种情形下，权重体积减半，等于每次生成要搬的数据减半，tg 吞吐就有机会近似成倍提升。

需要强调的是，这是基于"带宽受限"前提的定性推算，不是对具体设备的承诺：当模型足够小、能整个放进缓存时，瓶颈会转移到算力，此时再量化对速度的帮助就有限。所以"量化既省内存又提速"成立是有条件的——它的前提写在账里：权重多大、缓存多大、带宽多宽。把这三件事列出来，你才知道量化到底是解了内存的围，还是同时解了速度的围。

6.6 困惑度怎么测（llama-perplexity）

困惑度（perplexity）是语言模型质量的经典指标，越低通常表示越"会说话"。llama-perplexity 让你在同一份校准/测试文本上，对两个量化档各算一次困惑度，差额就是量化的"质量代价"。测量纪律和速度基准一致：同一文本、同温度（困惑度通常取贪心或固定温度）、记录引擎版本。把"体积省了多少"和"困惑度涨了多少"并排放，权衡就不再靠拍脑袋。

七、上下文长度与内存的换算

7.1 一个可代入的式子

KV Cache 的内存 ≈

上下文长度 × 批大小 × 层数 × 隐藏维度 × 2(K和V) × 每状态字节数

这只是一个框架性式子，具体系数依赖引擎实现与量化。给出它的意义不是让你心算出精确数，而是让你看清"上下文长度这一项是可以线性伸缩的旋钮"，以及"缩上下文比换模型便宜得多"——换模型要重新分发与验证，缩上下文通常只是改一个配置值。

7.2 实操建议

当加载成功但长对话崩溃或变慢时，优先缩上下文长度，再考虑换更小模型，最后才考虑换硬件。这个顺序和第一章模型加载失败篇的建议一致：最灵活、代价可控的旋钮先动。

7.3 两个具体场景的 KV Cache 推算

沿用 4.5 的 1.5B 示意架构（L≈28，H≈1536），取 Q8（1 字节/状态）算 KV Cache：

2048 上下文：2 × 28 × 1536 × 2048 × 1 ≈ 0.18 GB（推算）
4096 上下文：≈ 0.35 GB（推算）
8192 上下文：≈ 0.70 GB（推算）

可以看到，上下文从 2k 翻到 8k，KV Cache 翻了约 4 倍，权重却一分没变。这就是为什么"长对话崩"和"权重装不下"是两件事：你可能在 4k 上下文下余量充足，一到 8k 就被缓存拖垮。

7.4 并发的乘法效应

式子里的"批大小"在语音助手场景通常是 1（单用户单路），但如果板子要并发接多路（比如一个设备服务多个小智终端），KV Cache 会按并发数近似线性叠加。两路并发意味着 KV Cache 直接翻倍；四路就是四倍。算账时"预计并发"不是可选项，是乘法因子。一个常见的规划失误是：按单路预算定下模型，上线后发现要并发三路，内存当场见底。

7.5 与第一章的呼应

第一章讲"首 token 延迟"和"生成吞吐"，本篇的 KV Cache 正是这两者的内存侧镜像：上下文越长，KV Cache 越大，pp（prompt processing）阶段要搬的数据越多、tg（token generation）阶段要查的缓存越大，速度也会随之变化。所以"算内存账"和"测速度账"是同一枚硬币的两面，不能只算其一。

八、用 llama-bench 做可复现的测量

8.1 工具与用法

README 提交信息里给出 llama-bench 的用法示例：llama-bench -p 512 -n 128 -r 2，其中 -p 是 prompt token 数、-n 是生成 token 数、-r 是重复次数。输出形如 pp512 与 tg128 的 tokens/s。

8.2 两个指标的物理意义

pp（prompt processing）：处理输入 prompt 的吞吐，决定"读完你的话要多久"。
tg（token generation）：生成 token 的吞吐，决定"说得快不快"。

这两个指标对应第一章区分过的"首 token 延迟"与"生成吞吐"的工程化版。体感上，pp 影响响应起点，tg 影响说完的节奏，两者不能混为一谈。

8.3 三个测量纪律

沿用第一章的纪律：测试集用不同内容（避免缓存）、第一轮（预热）单独处理或标记、记录温度与后台负载。只报平均数的做法要谨慎——长尾（P90）往往更能反映真实体验，因为设备降频和后台任务会让后半段变慢。

8.4 输出怎么读

拿到 pp512 与 tg128 两个 t/s 后，换算成"单 token 多少毫秒"更直观：例如 tg 为 26 t/s，意味着每生成一 token 约 38ms，一句话 20 个 token 约 760ms。用这种方式把基准数字翻译成用户能感知的延迟，结论才站得住。

8.5 JSON 输出与多模型对比

llama-bench 支持把结果以结构化形式输出，便于把多组测量并排成表。这在"同设备比不同量化档"时尤其有用：你把 Q2_K、Q3_K、Q4 三档各跑一遍，把 pp/tg 和对应权重体积摆在一起，选型就有了一张可复现的对照表，而不是凭印象说"Q4 更快"。把测量脚本化、把结果落表，是让第二章所有"推算"最终被"实测"替换的前提。

8.6 为什么只报平均数危险

设备上的平均数会掩盖两类问题：一是降频——长时间推理后 SoC 温度上来了，后半段速度掉一截，平均数把这段掉速稀释掉了；二是后台抖动——系统任务或日志写入偶发占用 CPU，让某几次测量明显变慢。所以测量时至少关注两件事：一是保留多次重复的逐次数值（而非只留均值），二是报告 P90/长尾，让"最坏情况"也看得见。对语音助手这种实时场景，用户记住的往往是"最慢那一次"。

8.7 把 t/s 翻译成体感延迟

继续用 8.4 的算法，但把它做成一张"延迟换算卡"：tg 30 t/s ≈ 每 token 33ms；tg 20 t/s ≈ 50ms；tg 10 t/s ≈ 100ms。一句 30 token 的回答，在 tg 30 时约 1 秒说完，在 tg 10 时约 3 秒说完。这个换算的意义是：把"t/s"这个工程单位翻译成"用户等多久"这个产品单位，让技术和产品在同一张表上对话。

8.8 决策树：缩上下文 / 换模型 / 换硬件

当实测发现"跑不动"（加载失败、长对话崩、或 tg 慢到不可接受）时，按代价从小到大依次尝试，不要一上来就换硬件：

1. 加载即 OOM？
   → 先降量化档（Q4→Q3_K→Q2_K），同等质量优先选体积更小的混合量化
2. 加载成功但长对话崩 / 变慢？
   → 先缩上下文长度（改一个配置值，几分钟可验）
   → 仍崩则降量化档或换更小模型
3. 容量够但 tg 慢到不可接受？
   → 确认是否带宽受限：换更低量化档看 tg 是否提升
   → 提升有限则属于算力瓶颈，再考虑换更大算力的平台
4. 以上都试过仍不达预期？
   → 才进入换硬件评估，并重新跑完整内存账

这条顺序和第一章"最灵活的旋钮先动"一脉相承：配置值优于模型替换，模型替换优于硬件替换。每一步都配有可复现的测量，而不是凭感觉换。

九、边界

换引擎或换版本要重算：本文的换算方法与工具是通用的，但具体数字依赖实现。从 llama.cpp 换到另一个引擎，或从一版本换到另一版本，内存账与基准都要重测。
KV Cache 是隐藏变量：长上下文场景的瓶颈常在缓存而非权重，算账时务必纳入。
量化质量要实测：不同张量类型、不同模型的退化程度不同，不能套用别人的结论。
推算不是实测：本文所有数字（容量表、KV Cache 推算、字节/参数）均为基于公式与命名约定的推算，用于演示方法；落到真机前必须用 llama-bench / llama-perplexity 实测，并把推算列替换为实测列。
不与具体推理组件做优劣对比：本文选 llama.cpp 当教具，是因为它的工具链把"算账"这件事暴露得最清楚；不因此得出"它比某组件更好"的结论，选型仍以你的实测为准。

十、常见问题（FAQ）

问：llama.cpp 是 OpenAI 兼容的吗？
README 只链接了 “llama-server REST API”（指向仓库 issue 9291），并提到服务端有 /apply_template 等端点，但未声明 OpenAI 兼容。本文只描述其提供 REST 风格的 JSON API，不臆造 OpenAI 兼容性。若你的编排代码依赖 OpenAI 风格的 /v1/chat/completions 路由，需确认接入层的适配方式，而不是默认它天然兼容。

问：GGUF 和旧格式有什么区别？
GGUF 是 llama.cpp 当前使用的单文件模型格式，除了权重还内嵌元信息、分词器与对话模板，分发与部署都是单文件。仓库提供从 HuggingFace、legacy ggml、LoRA 转换到 GGUF 的脚本。

问：上下文长度拉到多长会爆内存？
取决于权重大小、层数、隐藏维与预留的其他内存。KV Cache 随上下文长度线性增长，算账时要按"最大上下文 × 预计并发"预留，而不是只看权重。

问：为什么缩上下文比换模型划算？
缩上下文通常只改一个配置值，几分钟可验证；换模型要重新分发、重新测质量，还可能引入新的兼容问题。所以在长对话崩溃时优先缩上下文。

问：pp 和 tg 哪个更重要？
都重要但影响不同：pp 决定响应起点（首字快慢），tg 决定说完的节奏。用户感知的是两者叠加，不能只优化其一就宣称"变快了"。

问：量化后质量掉多少才算可接受？
没有统一阈值。做法是固定一份测试文本，用 llama-perplexity 测各档困惑度，再人工核验若干典型问答的可读性，把"体积省了多少"和"困惑度涨了多少"并排评估。质量底线由你的任务决定——闲聊可以更激进，专业问答要更保守。

问：为什么 4GB 板子上 fp16 的 1.5B 装不下？
按本文 4.5 的推算，1.5B fp16 权重约 3.0GB，加上 KV Cache 和框架零头就逼近甚至超过 4GB 可用内存，系统与其他任务几乎没有空间，因此实践中端侧几乎都用量化档而非 fp16。

问：并发多路时内存怎么估？
KV Cache 随并发数近似线性叠加，权重和框架开销基本不变。两路并发 KV Cache 约翻倍，四路约四倍，算账时把"预计并发"当作乘法因子纳入。

问：GGUF 内嵌的分词器会不会和我的编排代码冲突？
会。如果编排代码自己又拼了一遍对话格式，而 GGUF 模板的拼法和你不一致，就会出现格式重复或角色错乱。排查时先把 GGUF 实际模板打印出来逐字对比，再谈模型能力。

问：llama-bench 的 -r 重复次数设多少合适？
至少 2～3 次以便观察波动；若要取 P90/长尾，建议 5 次以上并保留逐次数值。重复次数越多，平均数和长尾越稳，但耗时也越长，按设备空闲度权衡。

问：imatrix 一定要用吗？
不是必须，但它能在同体积下改善质量，对小模型意义更大。若你在 Q2/Q3 区间纠结质量，跑一次 llama-imatrix 再做混合量化是值得的对照实验。

问：从 HuggingFace 转 GGUF 会改变模型质量吗？
纯格式转换（不改量化）理论上不改变权重数值，因此不改变能力；只有当你在转换时顺带做量化，才会引入精度变化。排查"换格式后变傻"时，先确认转换是否动了量化档，而不是先怀疑转换本身。

问：KV Cache 能不能跨多轮对话复用？
可以也必须复用——这正是 KV Cache 存在的意义：第一轮算出的 K/V 状态缓存下来，第二轮只需对新 token 增量计算，避免每轮把整段历史重算一遍。但复用意味着缓存随对话累积增长，这正是"长对话吃内存"的来源；编排层需要做上下文裁剪或摘要，把缓存控制在预算内。

问：imatrix 的校准数据怎么选？
选和你目标任务同源的文本。给语音助手做校准，就用它实际会遇到的对话/指令语料，而不是通用维基百科；分布越贴近真实输入，重要性矩阵分配精度越准。校准数据量不必很大，几百到几千条样本通常就够，关键是"同源"而非"海量"。

问：为什么我的实测和本文推算差很多？
推算用的是通用公式与示意架构，真实模型在层数、隐藏维、GQA 头数、缓存实现上各不相同，差出 20%～50% 都正常。推算的作用是"先判断路走不走得通"，实测才是"拍板"的依据——本文所有容量数字都应在你的真机上用基准工具重测后替换。

十一、总结与可带走物

本篇把"设备能上多大模型"这件看似玄学的事，拆成权重 / KV Cache / 运行时 / 框架四块账，并指出最容易被忽略的隐藏变量——随上下文线性增长的 KV Cache。量化、GGUF、llama-bench 三件工具分别服务于"怎么省内存"“模型长什么样”“怎么测速度”。

可带走的产出：

四块内存账框架：权重 + KV Cache + 运行时 + 框架，任一项都不能漏。
容量判断表模板：先按设备容量挑"装得下"的量化档，再在同一区间用困惑度挑"质量还行"的最低档。
KV Cache 换算视角：上下文长度与并发是乘法因子，缩上下文比换模型便宜得多。
llama-bench 测量纪律：不同内容、标记预热、记录负载、报告 P90，把 t/s 翻译成体感延迟。
推算→实测替换清单：本文所有数字标了口径，落真机前用基准工具把推算列替换为实测列。

最后落到定位：本篇是"通用内存账与基准方法"，不是"该用哪款引擎"。算账的方法与工具可以跨引擎复用，具体的数字则必须在你的设备上实测。

把本篇放回系列里看：第一章解决了"本地能不能加载、首 token 多快"，A 类文章解决了"全链路怎么把云端组件换成本地"，而本篇补上的，是贯穿两者的"容量与速度到底受什么约束"。三篇合起来，才构成一个完整的端侧 LLM 落地判断：装得下、跑得动、接得进链路。

附录 A：内存预算工作表（模板）

把下面这张表填进你的设备数据，就是一份可复用的选型底稿（容量数字示例为推算，需替换为实测）：

目标设备可用内存：        ______ GB
系统与其他任务预留：      ______ GB
可分配给模型的内存：      ______ GB

模型量级：                ______ B
量化档：                  ______ （字节/参数 ______ 推算）
权重占用量（推算）：      ______ GB

上下文长度上限：          ______ tokens
层数 / 隐藏维：           ______ / ______
KV Cache 字节/状态：      ______ （Q8=1）
KV Cache 占用量（推算）： ______ GB

运行时与框架零头（推算）：______ GB
预计并发：                ______ 路

合计（推算）：            ______ GB
结论：余量 ______ GB → 容量成立 / 临界 / 超容量（以实测为准）

附录 B：控制变量测量模板

用 llama-bench 做对照时，固定除目标变量外的一切，才能得出可信结论：

固定项：设备型号、引擎版本、温度、后台负载、测试文本
变动项：量化档（Q2_K / Q3_K / Q4）

记录每行：
  量化档 | 权重体积 | pp512(t/s) | tg128(t/s) | P90 tg | 困惑度
  ------|---------|-----------|-----------|--------|-------
  Q2_K  |  ______ |  ______   |  ______   | ______ | ______
  Q3_K  |  ______ |  ______   |  ______   | ______ | ______
  Q4    |  ______ |  ______   |  ______   | ______ | ______

判读：在容量允许的档位里，选困惑度可接受且 tg 达标的最低档。