这个方案的定位
前面讨论过的路径（官方 free tier、网关赠额、学生包、云试用金）本质都是「别人给你计量额度」。量化本地部署是另一条线：模型权重下载到本地后，推理不计 Token，只计电费和显卡折旧。
适用前提很明确：
- 你有一块显存 ≥ 8GB 的独立显卡（NVIDIA 最省事；AMD 走 ROCm，Apple Silicon 走 Metal）。
- 你的任务是可离线完成的：代码补全、文档摘要、批量翻译、数据清洗、本地 RAG。
- 你能接受「模型能力上限由你的显存决定」，而不是由厂商最新旗舰决定。
如果你需要 GPT 级别的前沿能力、长上下文或原生多模态，本地量化模型替代不了，请继续走 API 路线。
显存怎么估：先算数，再下载
一个粗略但够用的公式（4-bit 量化，权重部分）：
```
权重显存(GB) ≈ 参数量(B) × 0.6
```
即 7B ≈ 4.2GB，14B ≈ 8.4GB，32B ≈ 19GB。再叠加：
- KV Cache：与上下文长度成正比，8K 上下文下通常是 1–4GB，长上下文会显著膨胀；
- 运行时开销：约 0.5–1.5GB。
经验值（4-bit，8K 上下文）：
| 显存 | 舒适区间 | 说明 |
|---|---|---|
| 8GB | 7B–8B | 需控制上下文 |
| 12GB | 8B–14B | 日常主力 |
| 16GB | 14B | 质量与速度平衡点 |
| 24GB | 32B | 需 4-bit 且上下文克制 |
注意：MoE 架构（例如总参数量大但激活参数小的模型）显存占用看总参数，但速度看激活参数，不要混算。
操作步骤
一、选量化格式
2026 年实际可用的三档：
- GGUF（Q4_K_M / Q5_K_M）：CPU+GPU 混合推理友好，llama.cpp 与 Ollama 原生支持，生态最全。质量损失在 Q4_K_M 上通常可接受，Q5_K_M 更稳但慢一些。
- AWQ / GPTQ（4-bit）：面向 GPU 的权重量化，vLLM 支持良好，吞吐明显高于 GGUF，适合批量离线任务。
- FP8 / INT8：显存换质量，24GB 卡上跑 14B 比较舒服，但 32B 基本放不下。
选型原则：单机交互用 GGUF，批量吞吐用 AWQ + vLLM，显存富裕时优先上更高比特。
二、Ollama：最省事的起步方式
```bash
# 安装后直接拉取量化版本
ollama pull qwen2.5:14b-instruct-q4_K_M
ollama run qwen2.5:14b-instruct-q4_K_M
```
关键参数在 Modelfile 或环境变量里调：
```dockerfile
FROM qwen2.5:14b-instruct-q4_K_M
PARAMETER num_ctx 8192
PARAMETER num_gpu 99 # 尽量全部层放 GPU
PARAMETER num_thread 8 # CPU 线程数
```
显存不够时，Ollama 会自动把部分层留在 CPU，速度会掉到每秒几个 Token，这时应降低 num_ctx 或换更小模型，而不是硬扛。
三、llama.cpp：想要精细控制用这个
```bash
# 编译时开启 CUDA
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j
# 启动服务，暴露 OpenAI 兼容接口
./build/bin/llama-server \
-m ./models/qwen2.5-14b-instruct-q4_k_m.gguf \
-ngl 99 \
-c 8192 \
--host 127.0.0.1 --port 8080
```
-ngl（offload 层数）是核心旋钮：从 99 往下调直到不 OOM，找到显卡能承受的最大值。
四、vLLM：批量任务与高并发
```bash
vllm serve Qwen/Qwen2.5-14B-Instruct-AWQ \
--quantization awq \
--max-model-len 8192 \
--gpu-memory-utilization 0.90 \
--port 8000
```
--gpu-memory-utilization 默认 0.9，显存紧张时下调到 0.8 左右；vLLM 会预分配 KV Cache，所以启动即占满，不是泄漏。
五、接进你的工具链
三种运行时都提供 OpenAI 兼容端点（Ollama 为 http://localhost:11434/v1，llama.cpp 为 :8080/v1，vLLM 为 :8000/v1）。把编辑器插件、脚本里的 base_url 指过去即可，无需改调用代码。
注意事项
- 量化不是无损：Q4 在数学推理、长链逻辑、代码生成上退化较明显；这类任务建议用 Q5/Q6 或缩小模型规模换精度。
- 上下文吃显存：把
num_ctx从 8K 提到 32K，KV Cache 可能翻数倍，直接导致 OOM。先定上下文，再定模型。 - 速度预期要现实：消费级卡上 14B 4-bit 大致在每秒十几到几十 Token 区间，取决于卡型与上下文长度；这不是云端 A100 的体验。
- 电费与散热是真实成本：长时间满载推理的功耗不低，笔记本尤其要注意降频。
- 许可证要看清：开源权重不等于无条件商用，部分模型有自定义许可条款，商用前逐条确认。
- 模型来源要可信：优先从官方组织或高信誉发布者下载权重，避免来源不明的 GGUF 文件。
适用场景
- 隐私敏感：数据不出本机，医疗、法务、内部代码库场景。
- 高频小额调用：每天几千次短请求，本地比按量付费划算。
- 离线环境：无网络或网络受限的机器上做推理。
- 批处理：夜间跑数据清洗、翻译、标注，白天出结果。
不适用场景
- 需要前沿推理能力、超长上下文或原生多模态。
- 没有独立显卡，只有集显或纯 CPU——可以跑，但 7B 以上基本不可用。
- 需要弹性扩缩容的生产服务，本地单机没有冗余。