判断先说：大多数团队根本不该本地部署，只有数据不能出内网、或者调用量大到云端不划算的时候才值得。真正要本地部署的人，卡点从来不是"怎么装"，而是装完之后怎么扛住并发、怎么不把显存打爆。这篇把从单机跑通到生产化服务这条路走一遍，重点是后一半。

显存是第一道硬约束

模型权重必须完整装进 GPU 显存，放不进去系统会静默回退到内存，速度掉两个数量级。粗略的账是这样：量化后的 7B 模型约 4–5GB，14B 约 8–9GB，30B 约 19GB，70B 约 40GB。这还只是权重，KV cache 要额外吃显存——上下文越长、并发越高，KV cache 越大，得在权重之上再留两三成余量。所以一张 24GB 的 4090 跑 14B 量化版加中等并发是舒服的，跑 70B 就得两张卡，或者退一步用 CPU offload 接受慢。选硬件别盯着参数猜，先算权重加 KV cache 的显存，再定卡。

没有独显也不是不能跑。CPU 加大内存（32GB 起步）配合 llama.cpp 能起小模型，只是速度慢一个量级，适合低频内部工具。Apple Silicon 是另一条路，统一内存能跑比同价位显卡更大的量化模型，适合本机开发验证。

量化在体积和质量之间找平衡

16 位权重直接跑，显存根本放不下，量化是把精度从 16 位降到 8 位、4 位。GGUF 是 llama.cpp 生态的原生格式，Q4_K_M 是公认的质量体积平衡点，7B 模型文件约 4GB，日常使用基本无损；想要更高保真可以上 Q5_K_M。GPU 上追求吞吐的走 AWQ 或 GPTQ 路线，转换要额外一步，而且不是所有模型都有现成的量化权重，小众模型往往要等几天。4 位以下是底线，Q3_K 及更低只在实在放不下的时候用，质量掉得明显。

从 Ollama 跑通

个人测试和开发，Ollama 是零摩擦的默认选择，一个二进制把下载、量化、服务都包了：

curl -fsSL https://ollama.com/install.sh | sh
ollama pull qwen3:8b
ollama run qwen3:8b

它自己会起一个 OpenAI 兼容的服务，监听 11434 端口，curl 就能调：

curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "prompt": "用一句话解释什么是反向代理",
  "stream": false
}'

Ollama 的软肋是并发。它底层调 llama.cpp，请求是排队处理的，适合一个人开发调试，扛不住多用户同时问。到了这一步就该换引擎。

生产化换 vLLM

要上线给一群人用，换 vLLM。它的 PagedAttention 把 KV cache 按页管理，显存碎片少、吞吐高，还支持 continuous batching 和多卡张量并行，接口同样是 OpenAI 兼容的，现有代码几乎不用改：

pip install vllm
python -m vllm.entrypoints.openai.api_server   --model Qwen/Qwen3-14B-Instruct   --tensor-parallel-size 1   --gpu-memory-utilization 0.92   --max-model-len 8192   --port 8000

--gpu-memory-utilization 0.92 是把显存利用率卡在 92%，给 KV cache 和碎片留余地，直接怼满反而容易 OOM。--max-model-len 是上下文上限，砍它能在显存吃紧时救急。

应用侧接入

服务起来之后，接入就是普通 OpenAI SDK 换一个 base_url：

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="none")
resp = client.chat.completions.create(
    model="Qwen/Qwen3-14B-Instruct",
    messages=[{"role": "user", "content": "把这个报错解释一下"}],
)
print(resp.choices[0].message.content)

上线后盯三个数

服务上线之后要盯的不是"能跑"，是三个数：每秒 token 数（吞吐）、首 token 延迟、并发上限。vLLM 用 continuous batching 把并发请求合成一个 batch 喂给 GPU，同样的卡并发上限比 llama.cpp 高一个量级。量化等级和上下文长度会同时影响这三个数，调优时先把上下文卡到业务需要的最小值，再压并发，最后才动量化。

几个容易踩的坑

中文输出乱码或截断，先查 tokenizer 和 chat 模板跟模型是否匹配，别一上来就调参数。显存溢出，先降量化等级，再砍 --max-model-len，最后才考虑换卡。量化不是免费的午餐，4 位以下质量掉得明显。CPU 部署能跑，但慢一个量级，只适合低频内部工具，别拿来对用户。

选型就一句话：一个人折腾用 Ollama，上线给别人用上 vLLM，两者接口兼容，可以先 Ollama 验证效果再迁 vLLM，不用推倒重来。