本地大模型部署：一张消费级显卡能做什么

本地跑大模型这件事，门槛比想象中低，天花板也比想象中低。一台带 16GB 显存的游戏本，已经能跑不少实用任务；但想用它替代云端旗舰模型，通常会失望。

这篇文章不讨论跑分，只回答三个问题：显存够不够、量化选哪个、什么任务值得放在本地。

一、先算显存，再选模型

一个够用的估算公式是：显存 ≈ 参数量 × 每参数字节 + KV Cache + 框架开销。

精度	每参数字节（约）	说明
FP16	2.0 B	原始精度，最占显存
8-bit	1.0 B	几乎无损，适合小模型
4-bit	0.55 B	主流选择，性价比最高

按这个估算，7B 模型 4-bit 大约需要 4GB，14B 约 8GB，32B 约 18GB，70B 则接近 40GB。再给 KV Cache 和上下文留出 2 到 6GB，就能判断自己的卡能不能装下。

注意，上下文越长，KV Cache 越大。同一张卡跑 2K 上下文很轻松，开到 32K 可能直接爆显存。很多「本地跑不动」的问题，其实是上下文设置过大。

二、量化：用一点精度换可用性

GGUF 格式的 Q4_K_M 是当前最平衡的选择：体积约为 FP16 的四分之一，中文理解和写作的损失通常可以接受。如果显存允许，Q8_0 更接近原模型，代码和数学任务的表现会更稳。

不建议使用 Q2 或 Q3。省下来的显存，往往会以明显的逻辑错误和格式崩坏作为代价。GPU 上的 AWQ、GPTQ 也是常见方案，推理速度更快，但生态兼容性不如 GGUF 广。

三、推理框架怎么选

框架	适合场景	特点
Ollama	个人使用、快速验证	安装即用，模型管理省心
llama.cpp	精细控制、CPU 与混合推理	参数丰富，可深度调优
vLLM	多用户服务、批量推理	吞吐高，显存要求也高
LM Studio	图形界面、非工程用户	上手快，适合体验

个人起步直接用 Ollama；要做产品后端、并发较高时再考虑 vLLM。不要为了「更专业」一上来就搭复杂的服务，先把任务跑通更重要。

四、三档硬件配置建议

显存	可跑模型（量化）	适合的任务
8GB	7B 到 8B，Q4	摘要、分类、简单问答
12 到 16GB	14B Q4，或 8B Q8	写作、代码补全、RAG
24GB	32B Q4	复杂推理、Agent 原型
48GB 以上	70B Q4，或 32B Q8	接近云端小模型的体验

显存不够时，可以用 CPU 加内存做混合推理，但速度会明显下降。如果任务是批处理、不追求实时，这仍然是一种可行的省钱方案。

五、真实体感：能做什么，不能做什么

以 14B Q4 为例，本地跑得比较稳的任务包括：会议纪要整理、邮件草稿、文本分类、结构化抽取、简单 RAG 问答。这些任务的共同点是上下文短、判断标准明确。

不太适合的任务也很明确：多步复杂推理、长文档跨章节对比、要求极高的代码生成、需要稳定工具调用的 Agent。模型不是不能做，而是错误率会高到需要大量人工兜底。

32B 是一个明显的台阶，复杂指令遵循和中文表达都会好不少。但即便如此，它也替代不了云端旗舰模型。最可靠的做法，是拿自己的真实任务做一套小评测集，而不是只看别人的体感。

六、上手命令

以 Ollama 为例，安装完成后只需要两行：

ollama pull qwen2.5:14b
ollama run qwen2.5:14b

需要从程序调用时，它默认在 127.0.0.1:11434 提供 HTTP 接口：

curl http://127.0.0.1:11434/api/generate -d '{
  "model": "qwen2.5:14b",
  "prompt": "用三句话解释什么是模型量化",
  "stream": false
}'

默认上下文往往偏小。可以写一个 Modelfile，把常用参数固化下来：

FROM qwen2.5:14b
PARAMETER num_ctx 8192
PARAMETER temperature 0.3

ollama create qwen-local -f Modelfile
ollama run qwen-local

本地部署最大的价值，不是省钱，而是让你拥有一块完全可控、可以随时实验的模型空间。对学习和隐私敏感场景来说，这已经足够。