为什么先算显存，再谈模型
本地推理的「免费」来自零边际成本，但成本并没有消失，只是前置成了显存。同一张卡上，模型权重占多少、KV Cache 还能剩多少，直接决定你能开多长的上下文、能并发几个请求，也就决定了实际 tokens/s。所以第一步不是挑模型，而是算预算：
- 权重占用 ≈ 参数量 × 每参数字节数（FP16 约 2 字节，Q8 约 1 字节，Q4 约 0.5 字节，另有少量 overhead）。
- KV Cache 占用随上下文长度和并发数线性增长，长上下文场景往往比权重更吃显存。
- 还要给框架本身、CUDA context 留出约 1–2GB。
据此把方案分成三档，每档给出可复制的配置。
操作步骤
第一档：8GB 显存，日常问答与轻量 Agent
适用条件：单张 8GB 消费级卡（如 RTX 3060 Ti / 4060），或 16GB 统一内存的轻薄本。目标是稳定跑 7B–8B 级别的量化模型。
- 用 Ollama 拉取量化版本，默认 tag 通常已是 Q4 级别：
```bash
ollama pull qwen3:8b
ollama pull llama3.1:8b
```
- 调整上下文与并发。默认上下文偏小，长文档场景需要显式设置：
```bash
# 环境变量方式
OLLAMA_NUM_PARALLEL=2 OLLAMA_CONTEXT_LENGTH=8192 ollama serve
```
- 用 Modelfile 固化参数，避免每次手写：
```text
FROM qwen3:8b
PARAMETER num_ctx 8192
PARAMETER num_predict 1024
PARAMETER temperature 0.3
```
```bash
ollama create qwen3-8b-ctx8k -f Modelfile
```
- 验证吞吐：
ollama run qwen3-8b-ctx8k --verbose，关注 eval rate（生成速度），8GB 卡上 7B Q4 通常在每秒十几到三十几 token 区间，具体取决于卡型与上下文长度。
限制：这一档不适合长上下文检索和高并发；上下文拉到 16K 以上时 KV Cache 会明显挤压权重空间，可能触发 CPU 回退，速度骤降。
第二档：24GB 显存，vLLM 做多用户共享
适用条件：单张 24GB 卡（如 RTX 4090 / L4 / A10），需要同时服务多个客户端，或跑 14B–32B 量化模型。
- 安装 vLLM（建议独立虚拟环境）：
```bash
python -m venv venv && source venv/bin/activate
pip install vllm
```
- 以 OpenAI 兼容模式启动，关键是把显存利用率与并发上限显式写出来：
```bash
vllm serve Qwen/Qwen3-14B-AWQ \
--quantization awq \
--max-model-len 16384 \
--gpu-memory-utilization 0.90 \
--max-num-seqs 16 \
--port 8000
```
- 客户端按 OpenAI 协议调用，把 base_url 指向本地：
```python
from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="local")
```
- 调参顺序建议：先固定
--max-model-len，再调--max-num-seqs。并发数过高会拉长单请求延迟，但总吞吐上升；交互式场景优先保延迟，批处理场景优先保吞吐。
限制：AWQ / GPTQ 量化需要模型有对应权重；若只有 FP16 权重，24GB 卡跑 14B 尚可，跑 32B 会非常紧张。vLLM 对显卡架构有要求，较老的卡可能不支持部分 kernel。
第三档：多卡或大统一内存，长上下文与批处理
适用条件：两张以上 24GB 卡，或 64GB 以上统一内存的机器（如 Mac Studio 级别），需要 32B–70B 量化模型或超长上下文。
- 多卡张量并行：
```bash
vllm serve Qwen/Qwen3-32B-AWQ \
--quantization awq \
--tensor-parallel-size 2 \
--max-model-len 32768 \
--gpu-memory-utilization 0.92
```
- 统一内存机器用 Ollama 更省事，可通过环境变量控制并行与内存驻留：
```bash
OLLAMA_NUM_PARALLEL=4 OLLAMA_MAX_LOADED_MODELS=1 ollama serve
```
- 长上下文场景务必先做一次压力测试，确认 KV Cache 不会把权重挤出显存。可以用固定长度输入反复请求，观察延迟是否随请求数增长而失控。
限制：张量并行有通信开销，卡间互联差时扩展效率不高；统一内存带宽远低于显存，长上下文下的生成速度会明显低于同参数量的独显方案。
注意事项
- 量化不是越小越好。Q4 在多数任务上损失可接受，但代码生成、数学推理对量化更敏感，建议这两类任务用 Q6/Q8 或 FP16。
- 上下文长度是隐性成本。把
num_ctx从 8K 提到 32K，KV Cache 可能翻数倍，务必按实际需求设置。 - 本地部署省的是调用费，不省电费和硬件折旧；长期高负载运行时要把这两项算进去。
- 不同框架的默认参数差异很大，Ollama 偏保守，vLLM 偏吞吐，迁移时不要直接沿用对方的并发假设。
- 模型许可证各不相同，商用前确认权重许可条款。
适用场景
- 8GB 档：个人日常问答、轻量 Agent、离线环境下的草稿生成。
- 24GB 档：小团队共享一个本地端点、批量文档处理、私有数据不出内网的推理。
- 多卡/大内存档：长文档分析与摘要、需要 32B 以上模型质量的复杂任务、离线批处理流水线。
一句话总结：先按显存算出「权重 + KV Cache + 框架开销」的余量，再选量化档位和框架，本地这条 Token 供给线才能稳定跑起来。