为什么本地部署是「免费 Token」里最稳的一档

平台赠额会过期、会限速、会改规则；本地推理的成本结构不同——它把「按 token 计费」换成了「一次性硬件投入 + 电费」。只要机器在跑，Token 的边际成本接近于零。2026 年开源权重模型（Llama 系、Qwen 系、Mistral 系、Gemma 系、DeepSeek 蒸馏版等）在 7B–32B 区间的质量已足以覆盖摘要、改写、分类、抽取、代码补全、RAG 问答等绝大多数日常任务。

关键不是「能不能跑」，而是把轻量交互与高吞吐批处理分成两层：日常对话走 Ollama（省心、秒起、模型管理方便），批量任务走 vLLM（连续批处理、PagedAttention、吞吐高数倍）。两者都提供 OpenAI 兼容接口，现有客户端几乎零改动。

硬件门槛与量化选型

先按显存反推能跑多大的模型（以下为经验值，实际受上下文长度影响）：

| 显存 | 现实可跑 | 建议量化 |

|---|---|---|

| 8 GB | 7B–8B，短上下文 | Q4_K_M |

| 12–16 GB | 7B–14B，中等上下文 | Q4_K_M / Q5_K_M |

| 24 GB | 14B 舒适，32B 勉强（低量化+短上下文） | Q4_K_M |

| 48 GB+ | 32B 舒适，可开较大上下文 | Q5_K_M / Q6_K |

CPU 也能跑，但 7B Q4 在纯 CPU 上通常只有每秒几个 token，仅适合离线批处理或低频调用。Apple Silicon 统一内存是性价比路线之一，Ollama 对其 Metal 后端支持成熟。

选型原则：先选「够用」而不是「最强」。分类/抽取用 7B–8B，写作与代码用 14B–32B，长文档摘要优先看上下文窗口而不是参数量。

操作步骤

第一步：用 Ollama 建立日常推理层

  1. 从 ollama.com 安装对应平台版本，确认 ollama --version 正常。
  2. 按显存拉取模型，例如 ollama pull qwen3:8b、ollama pull llama3.3:latest、ollama pull mistral-small（具体 tag 以官方模型库当前列表为准）。
  3. 验证本地接口：默认监听 http://localhost:11434，OpenAI 兼容端点为 http://localhost:11434/v1，API Key 可填任意非空字符串。
  4. 用任意 OpenAI SDK 指向该 base_url 测试一次 chat completions，确认返回正常。
  5. 需要局域网共享时，设置环境变量 OLLAMA_HOST=0.0.0.0:11434 后重启服务；注意这会暴露到网络，务必配合防火墙或反向代理加鉴权。

第二步：用 vLLM 建立批处理层

  1. 在带 NVIDIA GPU 的机器上安装 vLLM（官方推荐用独立 Python 环境或官方容器镜像）。
  2. 启动 OpenAI 兼容服务，示例：

```

python -m vllm.entrypoints.openai.api_server \

--model Qwen/Qwen3-14B-Instruct \

--served-model-name qwen3-14b \

--max-model-len 16384 \

--gpu-memory-utilization 0.90 \

--port 8000

```

  1. 访问 http://localhost:8000/v1，同样用 OpenAI SDK 验证。
  2. 若显存吃紧，降低 --max-model-len 或 --gpu-memory-utilization；vLLM 启动失败最常见的原因就是 KV cache 预留不足。
  3. 批量任务用较大 batch 提交，vLLM 的连续批处理会显著提升吞吐；单条交互式请求反而不如 Ollama 省事。

第三步：做一层简单路由

在客户端或本地网关（如 LiteLLM 代理）里配置两个 provider：

  • 交互式、低延迟、单条请求 → Ollama
  • 离线批量、长文本、需要高吞吐 → vLLM

按任务类型而非按模型名路由，能让两层各发挥所长，也避免小机器被批量任务拖死。

第四步：把「免费」变成可计量

本地不是没有成本，只是成本前移。建议记录：单次任务的 token 数、耗时、GPU 占用。用这些数据判断某类任务是否值得本地跑，还是该交给有免费额度的云端接口。

注意事项

  • 质量不是无限接近闭源旗舰。7B–32B 开源模型在复杂推理、长链条工具调用上仍有差距，关键任务建议保留人工复核或云端兜底。
  • 上下文长度是硬约束。量化模型开大上下文会显著吃显存，长文档任务要先估算 KV cache 占用。
  • 许可证要看清。多数开源权重可商用，但部分模型有使用条款限制（如月活门槛、署名要求），部署前核对模型卡。
  • 电费与散热是真实成本。长时间满载的台式机功耗不可忽视，笔记本长时间推理会降频。
  • 不要暴露到公网。Ollama 与 vLLM 默认无强鉴权，直接暴露端口是常见安全事故来源。
  • 版本迭代快。模型 tag、vLLM 启动参数在不同版本间可能变化，以官方文档当前说明为准。

适用场景

  • 高频、低价值的文本处理：分类、打标、清洗、字段抽取
  • 内部知识库 RAG 问答，数据不出内网
  • 代码补全与本地 IDE 助手
  • 批量翻译、摘要、改写等离线作业
  • 作为云端免费额度的「兜底与分流」，额度用尽时业务不中断

不适合的场景

  • 需要顶级推理能力的复杂任务
  • 需要多模态高精度理解的重度场景（本地可跑但质量与成本需权衡）
  • 没有稳定电力与散热条件的临时环境

一句话结论

本地部署不是「薅额度」，而是把 Token 从「消耗品」变成「自有产能」。Ollama 负责日常，vLLM 负责吞吐，配合一层按任务类型的分流，就能在 2026 年获得一条不依赖任何平台规则变化的稳定供给线。