旧电脑跑本地AI模型：量化、上下文与CPU推理实战

很多人第一次尝试在本地运行语言模型时，会直接下载榜单上最大的那个——比如70B参数模型。结果在8GB内存的机器上，模型要么加载失败，要么慢到每秒不到一个token，进程被交换到磁盘，风扇狂转，整台机器卡死。这不是硬件不够的问题，而是选型思路错了。

本文基于一位开发者在2012年老笔记本（4核CPU、8GB内存、无独立显卡）上的长期实践，梳理出一套真正可行的本地推理策略：选对量化、限制上下文、只跑适合自己机器的模型。

核心策略：从7B到9B、Q4量化起步

对于8GB内存的机器，正确的起点是7B到9B参数模型，配合Q4或Q3量化。这个组合占用约6到8GB内存，能在纯CPU上以可用速度运行。听起来是妥协，但实际体验是：你能真正用起来，而不是折腾几天后放弃。

关键在于，一个7B或8B的指令微调模型，在大多数实际任务上会优于一个根本加载不了的更大模型。训练质量好的小模型，比勉强塞进内存的“大块头”实用得多。

量化到底在做什么

模型本质是一个巨大的数字矩阵。全精度用16或32位存储每个权重，量化则用更少的位来存，代价是精度略有损失。

命名规则并不直观：Q4_K_M大约表示每个权重4位，并对异常值采用特定方案；Q5稍大稍好；Q2极小但明显变差。对内存受限的机器，Q4_K_M通常是甜点，因为它把位数花在模型最需要的地方。

一条实用规则：如果模型文件超过可用内存的约60%，就难以跑好。必须给操作系统、上下文窗口和其他工作留出空间。

量化位宽与常见格式的实际差异

量化后的模型权重通常以整数存储，位宽越低，压缩率越高，但精度和稳定性下降也越明显。Q4_K_M中的“K”指k-quant方案，它把权重分成块，并为每块存储缩放因子与零点，从而在低位数下保留更多信息；后缀“M”表示中等混合精度，即对部分敏感层或异常值采用更高位数。与之并列的还有Q5_K_M、Q3_K_S等变体，数字表示大致平均位数，字母组合则说明块内混合策略。

实际选择时，Q4_K_M在7B-9B模型上常能在内存占用和输出质量间取得较好平衡；Q5_K_M质量略优但占用更高；Q3_K_S更省内存，适合更紧的预算，但复杂推理或长回答中更容易出现质量下降。文件后缀中的“GGUF”是当前CPU推理工具广泛采用的格式，便于按需加载和内存映射。

上下文长度：被忽视的内存黑洞

很多人只盯着模型大小，忘了上下文同样消耗内存，而且消耗量随模型规模放大。一个7B模型在32K上下文下，内存占用可能接近一个更大模型在短上下文下的水平。

解决办法是主动设置上下文窗口。多数本地推理工具默认给32K甚至128K，在受限硬件上应设为4096或8192，然后观察回答质量是否仍然够用——对大多数任务来说通常够用，而内存节省非常可观。

如果任务确实需要长文档，分块加载比强行拉长上下文更靠谱：速度慢一些，但能跑完。

KV缓存与上下文内存的关系

上下文长度之所以消耗大量内存，核心在于KV缓存（Key-Value Cache）。模型在生成每个token时，需要缓存此前所有token在注意力层中的键和值向量，避免重复计算。缓存大小与层数、注意力头维度、上下文长度以及批大小成正比，因此上下文翻倍，KV缓存通常也近似翻倍。

对7B级模型，在4K上下文下KV缓存可能只占数百MB到1GB左右，但拉到32K时可能增长到数GB，直接挤压模型权重和系统内存。部分推理工具支持KV缓存量化或分页管理，但在8GB机器上最直接有效的办法仍是主动调低上下文窗口，或者把长文档切块后逐段处理。

纯CPU推理：线程数和批大小最关键

CPU推理没有死，只是玩法不同。现代多核CPU上，根据模型大小和量化不同，大约能跑到每秒5到20个token。这足够写作、摘要和问答，但不够实时聊天。

两个设置比什么都重要：线程数应设为物理核心数，而非逻辑核心数，因为超线程通常会拖累推理吞吐；批大小应保持较小，大批次在GPU上有助于吞吐，在CPU上几乎没有好处。

物理核心、超线程与内存带宽

CPU推理的性能瓶颈通常不在浮点算力，而在内存带宽和缓存命中率。模型权重每生成一个token都要被大量读取，若线程数超过物理核心数，超线程带来的逻辑核心会争抢同一物理核心的执行资源和缓存，反而增加调度开销，导致吞吐下降。因此把线程数固定为物理核心数，通常比“用满所有逻辑核心”更稳。

批大小也是同理：GPU上大批次能提高并行度和吞吐，但CPU上每个批次的序列都要额外占用KV缓存并增加内存访问，小批次甚至单条推理往往延迟更低、内存更省。对8GB机器，优先保证“能连续生成”比追求峰值吞吐更有意义。

先试哪些模型，去哪下载

从训练良好的小型指令模型开始，优先选择文件名中清楚标注量化方式、并注明训练上下文长度的模型。一个用短上下文训练却被拉长使用的模型，表现会差于一个按你实际需要长度训练的模型。

模型文件托管在Hugging Face上，多数仓库公开且无需账号。下载你需要的具体量化版本，而不是全精度文件，并在花时间之前核对文件大小是否与页面描述一致。

如果重来一次，我会怎么做

我会花一天时间，对三个小模型各测两种量化，选出“每瓦回答质量”最好的那个，而不是能加载的最大模型。这一小时左右的基准测试，能省下几周的挫败。

另一件事是停止把本地机器当作云API的替代品。本地模型的价值在于隐私、离线工作，以及不想把数据发出去的任务；当你需要尽可能好的回答时，它并不是托管大模型的对手。分清自己处在哪种场景，本身就是大部分技能所在。