为什么从「客户端接入层」切入
本地部署最容易被忽略的一步不是模型，而是客户端怎么指过去。多数 SDK（OpenAI 官方库、LangChain、LlamaIndex、各类 IDE 插件）只认一个 base_url。只要两条后端的 API 形状一致，你就能用一次配置改动，在「轻量 Ollama」和「高并发 vLLM」之间来回切，而不用改业务代码。
这带来两个实际好处：
- 额度可切换：白天多人共用时切到 vLLM，夜间个人调试切回 Ollama，同一份额度按需分配。
- 故障可回滚：vLLM 实例 OOM 或重启时，客户端改一个环境变量就回到 Ollama，不至于整条线断供。
操作步骤
第一步：把 Ollama 开成 OpenAI 兼容端点
Ollama 自带 /v1 兼容层，默认监听 11434。启动后确认：
```bash
ollama serve
curl http://localhost:11434/v1/models
```
客户端侧只需：
```python
from openai import OpenAI
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
```
api_key 填任意非空字符串即可，Ollama 不校验。注意：兼容层覆盖 chat/completions 与 embeddings 的常用字段，但 tools、response_format 的严格 JSON Schema、部分 logprobs 行为在不同模型上支持度不一，先跑通主路径再逐项验证。
第二步：拉一个与 vLLM 侧同名的模型
关键技巧是让两条后端暴露同一个 model 名称，这样切换时客户端代码零改动。Ollama 侧用 Modelfile 起别名：
```bash
ollama pull qwen2.5:7b-instruct
cat > Modelfile <<'EOF'
FROM qwen2.5:7b-instruct
PARAMETER num_ctx 8192
EOF
ollama create team-default -f Modelfile
```
之后请求里统一写 model="team-default"。
第三步：按显存预算决定 vLLM 是否上场
vLLM 的价值在连续批处理与张量并行（TP）。单卡能跑就别上 TP——TP 会引入卡间通信开销，2 卡 TP 的实际吞吐通常明显低于同算力单卡的线性外推。经验判据：
- 单卡显存放得下权重 + KV Cache，且并发 < 约 8：Ollama 足够。
- 需要 10 路以上并发、或要长上下文批处理：上 vLLM 单卡。
- 单卡放不下权重（如 32B 以上 BF16）：才启用 TP=2。
启动示例（2 卡 TP）：
```bash
vllm serve Qwen/Qwen2.5-14B-Instruct \
--tensor-parallel-size 2 \
--served-model-name team-default \
--max-model-len 8192 \
--gpu-memory-utilization 0.90 \
--port 8000
```
--served-model-name team-default 是让客户端无感切换的关键参数。
第四步：用环境变量做「一键切换」
不要在两处硬编码地址，统一走一个变量：
```bash
export LLM_BASE_URL=http://localhost:11434/v1 # 切到 vLLM 时改成 :8000/v1
```
再配一个极简健康检查，决定切不切：
```bash
curl -fsS "${LLM_BASE_URL}/models" >/dev/null && echo UP || echo DOWN
```
把这段塞进启动脚本或 IDE 的 pre-launch task，就能避免「后端没起来、客户端空转」。
第五步：量化档位与显存的对应关系
同一张卡上，量化直接决定「能跑多大模型」：
- Q4_K_M（GGUF，Ollama）：显存占用约为 BF16 的 1/4，质量损失在多数对话任务上可接受。
- AWQ / GPTQ 4bit（vLLM）：显存同样约 1/4，但需要 vLLM 版本支持对应量化后端。
- FP8（vLLM，较新卡）：约 1/2 显存，质量接近 BF16。
实操建议：先用 Ollama + Q4 把业务跑通，等确认模型选型后再决定是否上 vLLM + AWQ。反过来的顺序会让你在量化兼容性上反复踩坑。
第六步：把「额度」记成可观测指标
本地部署的 Token 不是「领来的」，是「产出的」。建议至少记录：
- 每秒输出 token 数（tokens/s）
- 平均首 token 延迟（TTFT）
- 并发峰值与排队时长
vLLM 自带 /metrics（Prometheus 格式），Ollama 可用 --verbose 或外层代理统计。有了这三项，你才知道什么时候该从 Ollama 切到 vLLM，而不是凭感觉。
注意事项
- 兼容层不是等价层：Ollama 的
/v1与 vLLM 的 OpenAI 兼容接口在工具调用、结构化输出、流式分片边界上存在差异。跨后端切换前，用同一组请求做回归测试。 - TP 不是免费的：张量并行需要卡间高速互联（NVLink 最佳，PCIe 也可但效率下降）。两张不同型号的卡做 TP 往往起不来或性能极差，务必同型号。
--gpu-memory-utilization别拉满：0.90 是常见安全值，0.95 以上容易在长上下文时 OOM。- 模型名一致性靠纪律：
served-model-name和 Ollama 的create别名要成对维护，改名时两边一起改，否则切换即失败。 - 许可与合规：本地跑开源权重仍需遵守模型许可证（如 Qwen、Llama 系列各有条款），商用前核对。
- 这不是「白拿额度」：省下的是 API 调用费，付出的是电费、硬件折旧与运维时间。单机小规模自用通常划算，规模化要算总账。
适用场景
- 个人开发者或小团队，已有 1–2 张消费级/工作站显卡，希望把日常调用成本压到接近零。
- 需要在离线或内网环境跑推理，不能依赖外部 API。
- 白天多人共用、夜间单人调试，负载有明显峰谷，适合双后端切换。
- 正在做模型选型对比，需要同一套客户端代码快速切换不同模型与量化档位。
不适合：需要极高可用性（SLA）的生产服务、没有本地 GPU 的环境、以及对工具调用/结构化输出有严格一致性要求的场景——这些情况下托管 API 仍是更省心的选择。