为什么是「池化」而不是「单卡大模型」

2026 年本地部署的常见误区，是把目标定成「一张卡跑一个 70B」。现实是：多数人手上是 1–3 张显存不等的卡（例如一张 24GB、一张 12GB、一张 8GB），单卡谁都跑不动大模型，但合起来可以同时承载多个中小模型，并把大模型切到两张卡上做张量并行。

这套方案的核心不是「免费」，而是把已有硬件的闲置算力变成可计量的 Token 产能，边际成本只剩电费。是否值得做，取决于你的调用量是否稳定——见文末「适用场景」。

操作步骤

第一步：盘点显存，画出「实例地图」

  1. 用 nvidia-smi 或 rocm-smi 记录每张卡的显存与算力代际。
  2. 按「模型权重 × 量化位宽 ÷ 8 + KV Cache 预留」估算单模型占用。经验值：7B 的 Q4 量化权重约 4–5GB，Q8 约 7–8GB；14B 的 Q4 约 8–9GB；32B 的 Q4 约 18–20GB。KV Cache 随上下文长度线性增长，长上下文场景建议按权重的 30%–50% 额外预留。
  3. 得出实例地图，例如：
  • 卡 A（24GB）：vLLM，单卡跑 14B 或 32B 量化模型；
  • 卡 B + 卡 C（12GB + 8GB）：Ollama，跑 7B 级小模型与 Embedding 模型，供路由、分类、摘要等高频轻任务使用。
  1. 注意：vLLM 的张量并行要求各卡显存与型号尽量一致，异构卡混跑容易在启动阶段失败或吞吐骤降。异构时优先「一卡一实例」，不要强行 TP。

第二步：用 Ollama 起常驻小模型层

  • 通过 OLLAMA_HOST 与 OLLAMA_MODELS 指定监听地址与模型目录，便于多实例共存。
  • 用 OLLAMA_NUM_PARALLEL 控制单实例并发，用 OLLAMA_KEEP_ALIVE 让高频小模型常驻显存，低频模型设短保活以让位给大模型。
  • 小模型层承担三件事：请求分类与路由判断、Embedding 与重排、以及大模型排队时的兜底回答。

第三步：用 vLLM 起大模型层

  • 启动参数关注四项：--tensor-parallel-size（等于参与并行的卡数）、--gpu-memory-utilization（建议 0.85–0.9，留出系统余量）、--max-model-len（按业务真实上下文设定，不要盲目拉满）、--max-num-seqs（并发上限，直接决定显存峰值）。
  • 若模型有官方量化权重（AWQ / GPTQ / FP8），优先用官方量化版本，比自行转换更稳定。
  • vLLM 的连续批处理是这套方案吞吐的主要来源：并发上来后，单位 Token 的算力开销明显下降。

第四步：加一层反向代理做分层调度

在 Ollama 与 vLLM 前面放一个轻量代理（Nginx、LiteLLM Proxy 或自写 FastAPI 均可），实现三件事：

  1. 按模型名路由：请求里的 model 字段映射到具体实例，对外暴露统一入口。
  2. 按队列长度降级：轮询 vLLM 的 metrics 端点，排队超过阈值时，把非关键请求转到 Ollama 小模型层。
  3. 按调用方限流：给每个内部调用方分配每分钟请求数与并发上限，避免单个脚本打满整个池。

一个可用的降级伪代码如下：

```python

if vllm_queue_depth > THRESHOLD and not request.critical:

route_to("ollama/small-model")

else:

route_to("vllm/large-model")

```

第五步：把「产能」记成账

  • 在代理层记录每个请求的输入/输出 Token 数、耗时与命中实例，按天汇总。
  • 有了这张表，你才能判断池化是否真的省钱：如果每天总输出 Token 只有几万，本地池的折旧与运维成本很可能高于直接买 API。

注意事项

  • 异构卡不要强行张量并行。型号、显存、算力代际不一致时，优先一卡一实例，用代理层做模型分流。
  • 上下文长度是显存杀手。--max-model-len 拉满会让 KV Cache 吃掉全部余量，并发一上来就 OOM。按业务真实长度设定。
  • 消费级卡没有 ECC，长时间高负载下出错概率高于数据中心卡，关键任务建议保留一条外部 API 兜底。
  • 电费与散热是真实成本。多卡常驻推理的功耗不容忽视，建议用 OLLAMA_KEEP_ALIVE 与实例休眠策略控制空转。
  • 模型许可要看清。部分开源权重对商用有附加条款，内部使用与对外提供服务的要求不同。
  • 不要对外暴露裸端口。至少加认证与限流，否则你的池子会成为别人的免费 API。

适用场景

适合：内部工具链的批量摘要、分类、Embedding 与重排；对延迟不敏感的后台任务；数据不便出内网的场景；日均调用量稳定且较大的团队。

不适合：日均调用量很小、只有一张低端卡、或需要顶级模型能力的场景——这些情况下直接用云端 API 更省事也更便宜。

一条务实的判断线

先跑两周，把代理层记录的 Token 账本拿出来。如果本地池每天稳定输出数十万级 Token、且任务以中小模型可胜任的批处理为主，这套池化方案就成立；否则，把它当作「数据不出内网」的合规备份，而不是省钱手段。