1.2 核心术语拆解：token、量化位宽与上下文窗口

1.2 核心术语拆解：token、量化位宽与上下文窗口

本节摘要：token 是计费与测速的单位，量化位宽决定模型体积与精度，上下文窗口决定一次能读多少字。这三个词是全书所有实验的自变量：第 3 章调位宽，第 6 章调窗口，每一章都在测 token 速度。本节把它们的因果链一次讲透，并给你一套「看到数字就能心算体积」的技能。

上一节结尾的日志里出现了 tokens、layers、offload 这些词。这一节承接 1.1 的历史脉络，把术语底座补齐——它是 1.3 选型对比的前置：不懂位宽与窗口，就无法判断一个推理框架的参数是否匹配你的硬件。

先说结论：三个术语的因果链

token 是模型眼里的文字碎片。 模型不认识「字」，它认识词表里的编号。一句中文进模型前会先被词表切成若干 token，可能是单字、词组，也可能是一个英文单词被切成两三段。生成速度按每秒 token 数计——你看到的「每秒 15 个 token」，换算成中文大约是每秒十几个字。还有一条容易忽略的换算：中文在主流词表里通常一个汉字对应一到两个 token，所以「4K 上下文」翻译成中文容量时不能按 4096 个汉字算，按两三千字估更稳妥。

量化位宽决定每个参数占多少比特。 训练好的权重本来是 16 位或 32 位浮点数；量化把它们映射成 8 位、5 位、4 位甚至更低的整数。位宽减半，模型体积与内存带宽占用大致同步减半——这是第 3 章全部实验的理论地基。

上下文窗口是一次推理的「工作台面」。 参数 n_ctx 指定模型一次能处理的 token 总量：你的提问、历史对话、模型自己的回答都摊在这个台面上。台面越大，占的显存越多——因为模型要为每个位置的中间状态留位置，这块开销叫 KV 缓存，第 6 章的主角。

学习目标

读完本节，你应当能够：

1. 用「字节每参数」心算任意位宽下模型的内存占用，误差在一成以内；
2. 解释为什么 4 比特模型的速度常常快于 16 比特，而精度只小幅下降；
3. 说清 n_ctx 与 KV 缓存的正比关系，并估算上下文对显存的额外开销；
4. 区分 prompt processing 速度与生成速度这两个完全不同的指标；
5. 看懂困惑度（perplexity）数字的含义与它的局限。

一、心算体积：字节每参数就够了

推理阶段模型占用的内存，大头是权重。权重总量等于参数量，每个参数占用的字节数由位宽决定：16 位浮点占 2 字节，8 位整数占 1 字节，4 位整数占 0.5 字节。于是有一条心算公式：

权重内存 ≈ 参数量 × 每参数字节数

以 8B（80 亿参数）模型为例：
  FP16  → 8e9 × 2 字节 = 16 GB
  INT8  → 8e9 × 1 字节 = 8 GB
  INT4  → 8e9 × 0.5 字节 = 4 GB
​

实际体积会比纯权重略大：4 比特量化里每个块还要存缩放因子等元数据（第 3 章细讲），所以 Q4_K_M 的 8B 模型实际约 4.7 到 5 GB，而不是理论的 4 GB。用一小段脚本把常见档位一次算全：

# 位宽-体积对照速算：以 8B 模型为例
PARAMS = 8e9
layouts = {
    "FP16":   16 / 8,   # 每参数 2 字节
    "Q8_0":   8 / 8 + 0.03,   # 1 字节 + 约一成块内元数据
    "Q6_K":   6.6 / 8,  # 平均 6.5625 比特
    "Q5_K_M": 5.5 / 8,
    "Q4_K_M": 4.5 / 8,
    "Q3_K_M": 3.5 / 8,
}
for name, bytes_per in layouts.items():
    print(f"{name:8s} 约 {PARAMS * bytes_per / 1024**3:4.1f} GB")
# 输出（量级参考）：
# FP16     约 14.9 GB
# Q8_0     约  8.2 GB
# Q6_K     约  6.6 GB
# Q5_K_M   约  5.5 GB
# Q4_K_M   约  4.5 GB
# Q3_K_M   约  3.5 GB
​

这条公式是全书用得最频繁的工具：第 5 章算显存账本、第 3 章选位宽，起点都是它。

二、为什么低位宽常常更快

直觉上「精度低了应该更差」，但推理的瓶颈往往不是算力而是搬运：每生成一个 token，都要把全部权重从内存过一遍。8B 模型 FP16 要搬 16GB，Q4 只搬 4GB——在内存带宽固定的前提下，搬运量直接决定速度下限。这就是 llama.cpp 的核心赌注：用可以接受的精度损失，换四倍的搬运节省。

精度损失用什么衡量？最常用的是困惑度（perplexity）：让模型在固定测试文本上预测下一个词，预测得越犹豫，困惑度越高。它不是人类评分，而是与「模型内部对文本的把握程度」强相关的代理指标。第 3.3 节的位宽实测会给出同一模型从 FP16 到 Q3 的困惑度对照表，你会看到 Q4 到 Q6 区间的损失通常在百分之几的量级，而体积只剩四分之一。

三、两个速度，别混为一谈

启动日志里 prompt processing 与 generation 是分开计时的，对应推理的两个阶段。喂进去的一段长文本（提示词）要被一次性并行处理，这段速度叫预填充速度，通常每秒数百到上千 token；之后模型逐词生成回答，每次生成都要回顾之前的全部上下文，这段速度叫生成速度，通常每秒个位数到几十个 token。第 5.2 节的 offload 实验会展示：GPU 分层对预填充速度的提升远比生成速度显著——这个不对称性直接影响你怎么设计实验。

与窗口相关的开销也要先有个数：KV 缓存的显存占用约等于「每 token 每层两份向量」的总量，随上下文长度线性增长。8B 模型在 4K 窗口下 KV 缓存大约数百 MB，16K 就要按 GB 计——第 6 章会给出这台 2060 小本上的实测账目。

术语误用辨识

社区讨论里的高频混淆集中在此，逐对辨识。模型大小与显存需求：说「7B 模型」只声明了参数量，显存需求还取决于位宽——同一个 7B，16 位版要 14GB、4 位版只要 4GB 多，谈需求必须连位宽一起说。上下文与记忆：窗口是单次会话的容量上限，不是持久记忆；会话结束，缓存清空，模型对刚才的对话毫无留存。量化与压缩：模型量化与常见的文件压缩不是一回事——压缩是可逆的编码变换，量化是有损的数值映射，不可逆。生成速度与响应速度：体感等待由预填充加首 token 延迟决定，长提示词场景下预填充才是大头，只盯生成速度会误判瓶颈。

常见问题

中文 token 换算为什么偏低估？

主流词表的中文压缩率通常在一个汉字对应一到两个 token 之间，且标点与数字也各占额度。工程上按「窗口 token 数除以一点五」估中文容量，比直接按字数估更接近真实可用量。

困惑度低为什么有时还不如人感觉好？

困惑度度量的是「对下文的统计惊讶度」，与指令遵循、安全性、风格偏好并不强相关。两个模型困惑度接近时，好用程度可以差很远——它是必要参考，不是充分判据。

位宽里为什么常见 4.5、5.5 这种非整数？

块内元数据摊销的结果：标称 4 比特的格式加上缩放因子的均摊，等效位宽就是 4.5 上下。谈体积时看文件实际大小最可靠，谈带宽预算时用等效位宽最准确。

收束：带走的四个判断

• 看到模型名先做体积心算：参数量乘每参数字节，加上一成元数据余量，就得到内存需求的大头；
• 4 比特是本地推理的默认起点，因为它在体积、速度、精度三角上是消费级硬件的甜点位；
• 困惑度看趋势不看绝对值：同一测试集上同一模型的相对变化才有意义；
• 预填充与生成是两个速度：长文档问答看预填充，聊天流式输出看生成，优化手段各不相同。

下一节把镜头从概念拉回决策：同样能本地跑模型，llama.cpp、Ollama、vLLM、MLC 各自站在哪个生态位，你的场景该把票投给谁。