本地运行大模型的门槛这几年快速下降，但很多人第一次尝试时仍会遇到显存不够、速度奇慢的问题。理解显存占用、量化和推理速度三者之间的关系，能让你在选择模型和硬件时少走很多弯路。
显存决定能跑多大的模型
模型加载到显存中的占用，主要由参数量和每个参数占用的字节数决定。一个 70 亿参数的模型，如果用半精度格式存储，大约需要 14GB 显存；如果做 4bit 量化，大约只需要 4GB 左右。这就是量化的意义：用更低的数值精度换取更小的存储占用。
除了模型权重本身，还要预留一部分显存给上下文缓存。这部分占用随对话长度增长，长对话场景下可能达到几个 GB。因此在选择模型时，应该在理论占用之外多留出百分之二十到三十的余量。如果显存不足，系统会调用内存作为补充，但速度会下降到几乎不可用的程度。
量化损失了多少
量化不是免费的。从半精度降到 8bit，多数任务上的质量损失很小，普通人几乎察觉不到；降到 4bit 后，在需要精确推理、代码生成或长文本一致性保持的任务上，会开始出现可感知的退化。常见的表现是逻辑链条偶尔断裂、长文本后半段开始偏离主题。
实践中的建议是：日常对话、摘要、翻译这类容错度高的任务，4bit 完全够用；代码生成、结构化数据提取、需要严格遵循指令的场景，尽量用 8bit 或更高的精度。如果显存紧张，优先考虑选择参数量更小但精度更高的模型，而不是参数量更大却重度量化的版本。
速度瓶颈往往不是显存
很多人以为显存够了速度就快，实际上本地推理的速度主要受显存带宽限制，而不是算力。模型推理过程是逐个生成 token，每一步都要把全部权重从显存读一遍，因此显存带宽直接决定了生成速度的上限。这解释了为什么显存带宽高的卡在推理任务上表现明显更好，而算力更强的计算卡优势并不明显。
另一个影响因素是批处理大小。同时处理多个请求时，可以摊薄权重读取的开销，提高整体吞吐，但单个请求的延迟会上升。如果是个人使用，关注单请求延迟更有意义；如果是多人共享，则应该优化整体吞吐。
入门的务实路径
如果显存在 8GB 左右，建议从 4bit 量化的 70 亿参数模型开始，这个组合在多数消费级显卡上都能跑出可接受的响应速度。显存在 16GB 以上，可以尝试更大规模的模型或者用 8bit 精度换取更好的输出质量。不要一开始就追求最大的模型，先用小模型把工作流跑通，再根据实际需要升级，效率会高得多。