本地大模型要多少显存？从权重、KV cache 到推理速度
墓碑科技 MUBEITECH · 核对日期 2026-09-09
模型文件能放进显存，只回答了能不能加载。要判断能否完成你的任务，还要给上下文缓存和运行时留空间，并在相同模型、上下文长度与并发数下测量速度。先按下面的顺序排查，再决定是否需要更大的硬件。
先算权重，再给上下文留空间
一个便于心算的起点：权重字节数约等于参数数量 × 每个参数的位数 ÷ 8。例如，80 亿参数全部按 4 位存储，原始权重约为 4 GB（十进制）。这是算术示例，不是某个模型的实测显存要求；实际量化文件还有分组尺度等额外数据，也可能混用不同精度。
实际运行还需要 KV cache、计算缓冲区和框架开销。KV cache 保存注意力计算中可复用的键和值；它的大小受架构、上下文长度、精度和并发影响。滑动窗口等架构又有不同的增长边界，因此不能给所有模型套一个固定的额外显存百分比。
短对话能跑，长文为什么可能放不下？
下载文件的大小不会随着对话变长而变化，上下文缓存却可能增长。先记录模型、量化格式、上下文上限和同时处理的请求数，再用真实长度的输入测峰值内存。仅凭成功加载或一次短问答，不能判断长文任务是否可用。
缓存量化、把缓存移到 CPU、缩短上下文，都可能减少 GPU 内存压力，但速度与精度的取舍不同。先确认推理框架和具体模型支持哪种策略，再比较相同任务的结果；权重量化和 KV cache 量化是两件事。
多人吞吐量提高，不等于你的回答同比变快
单人使用时，关注等待第一个 token 的时间，以及随后生成的速度。多人服务还要看整个系统每秒完成多少工作、请求排队多久。比较宣传中的加速倍数前，先确认它量的是单请求延迟还是总吞吐量，以及测试的批大小和输入输出长度。
Orca 把服务调度细化到生成迭代，使请求不必全部等到一整批完成后才能调度。vLLM 的 PagedAttention 则着重减少 KV cache 的内存浪费，为更多请求共同运行创造条件。两者改善的是具体服务瓶颈，论文里的加速结果不能直接当作家用电脑的速度承诺。
压缩后还要用真实任务验收
llama.cpp 的重要性矩阵工具会从校准数据收集信息，供量化过程使用。选择更低位数后，文件变小并不自动证明任务质量足够；自然语言问答表现也不能替代代码或工具调用测试。
保留一组你确实会执行的任务，对照不同量化版本的答案、格式正确率和内存用量。如果工具调用失败，分别检查模型能力、聊天模板、工具定义、运行框架与量化影响，不能仅凭一次失败就归因于校准文本。
延伸阅读：连续批处理
这篇解读从权重搬运切入。阅读时请区分模型架构、批大小与缓存策略；不能把所有模型概括为每个 token 都完整读取全部权重。
订阅 · SUBSCRIBE
每周一封独立、不受审查的科技与 AI 深度评论，周一发出。带出处，可核查。