开源模型、本地部署与模型路由

你在 Quest 里用 Ollama 把 Qwen 跑起来那一刻，大概会有种"哇原来本地也能跑大模型"的爽感。但爽完之后真正值钱的问题是：上了生产，到底哪些活该自己托管开源模型、哪些活老老实实调 API？ 答错这题，要么白烧一堆 GPU 钱，要么把该省的成本全交给了 OpenAI。

说个真事。我见过一个团队，老板听说"开源模型免费"，兴冲冲租了两张 A100 自建推理集群，结果日均调用量只有几千次——那两张卡 90% 的时间在空转，一个月账单比直接调 API 贵了四倍多。也见过反面：另一个团队每天几十万次简单分类请求全打 GPT-4 级别的 API，月底 bill 出来财务直接找上门。两边都是没算账。

这篇把 Quest 之后你该想清楚的账算明白——带真实命令、带显存对照表、带成本算例、带模型选型表。

---

为什么要懂它？（不懂会怎样）

• 老板问"我们能不能不用 OpenAI，自己部署一个省钱？"——你得算得出省不省、什么规模才省，而不是拍脑袋。
• 数据合规要求"客户数据不能出公司"——这时候你必须会本地/私有部署，API 这条路直接堵死。
• 一个 Agent 每天几十万次调用，每次都打 GPT-4 级别的模型是纯烧钱——很多请求其实小模型就够，这就是"路由"要解决的。
• 面试时"你们为什么选自托管/选 API？"是 AI Engineer 岗位的高频问题，答"因为开源免费"基本就凉了。

---

先分清三个总被混用的词

术语：开源权重模型 (Open-Weight Model)

• 一句话解释：把训练好的模型参数公开、你能下载下来自己跑的模型。
• 形象比喻：餐厅把做好的菜送你带走（权重），但不一定给你完整菜谱和食材来源（训练数据/代码）。
• 工作中怎么用：Llama、Qwen、Mistral、DeepSeek、Gemma 都是——你能下载、能本地跑、能微调。
• 最常踩的坑：把"开源权重"当成"完全开源"。多数只开权重，不开训练数据，且带商用许可限制（比如某些条款对超大用户量有额外要求），商用前一定看 license。

对照三条路：

主流开源模型速览（挑模型别抓瞎）

尺寸怎么选：7B~8B 是本地/单卡的甜点区，质量够用、显存友好；上 70B 质量更好但要多卡或量化伺候。先从小的验证需求，不够再往上换。我的私房建议：中文业务从 Qwen 7B 起步，英文业务从 Llama 8B 起步，别一上来就盯着 70B 流口水。

---

开源模型从哪拿、怎么跑起来

拿模型：绝大多数在 Hugging Face（模型界的 GitHub）。Ollama 则把常用模型打好包，一条命令就下好跑起来，适合本地试。真实命令长这样：

# 方式一：Ollama —— 本地试玩/单人用，最省事
ollama pull qwen2.5:7b
ollama run  qwen2.5:7b "用一句话解释 RAG"

# 常用管理命令
ollama list          # 看本地已下载的模型
ollama ps            # 看当前加载在显存里的模型
ollama rm qwen2.5:7b # 删掉不用的，别让它吃硬盘

# Ollama 起的服务自带 OpenAI 兼容接口（默认 11434 端口）
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "qwen2.5:7b", "messages": [{"role": "user", "content": "你好"}]}'

# 方式二：Hugging Face CLI —— 下原始权重（要自己写推理/给 vLLM 用）
pip install "huggingface_hub[cli]"
huggingface-cli download Qwen/Qwen2.5-7B-Instruct

# 方式三：vLLM —— 生产级高吞吐服务，起一个 OpenAI 兼容的接口
pip install vllm          # 建议锁版本，vLLM 迭代快，参数名隔几个版本就变
vllm serve Qwen/Qwen2.5-7B-Instruct --port 8000
# 之后就能像调 OpenAI 一样打 http://localhost:8000/v1 ，代码几乎不用改

vLLM 生产上你大概率会用到这几个启动参数：

vllm serve Qwen/Qwen2.5-72B-Instruct-AWQ \
  --port 8000 \
  --tensor-parallel-size 4 \        # 4 张卡切一个大模型（70B 级别单卡放不下）
  --gpu-memory-utilization 0.90 \   # 显存用到 90%，剩的留给系统，默认 0.9
  --max-model-len 8192 \            # 限制 context 长度 = 限制 KV Cache 上限，防 OOM
  --quantization awq                # 加载 AWQ 量化权重

因为 Ollama 和 vLLM 都暴露 OpenAI 兼容接口，你的业务代码只要改一行 base_url 就能在"本地模型 ↔ 云端 API"之间切换：

from openai import OpenAI

# 指向本地 vLLM / Ollama，代码其余部分和调 OpenAI 一模一样
client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")

resp = client.chat.completions.create(
    model="Qwen/Qwen2.5-7B-Instruct",
    messages=[{"role": "user", "content": "把这句话改写得更正式：明天开会别迟到"}],
)
print(resp.choices[0].message.content)

这也是为什么后面讲的"模型路由"在工程上很好做——接口形状是一样的，路由层只是决定请求发给哪个 base_url。（接口细节回顾 LLM API 基础，多模型网关的统一接入见 LLM 平台与网关。）

跑起来分两个战场，别用错工具：

说实话我踩过这个坑：拿 Ollama 直接上生产，几十个并发一上来就排队卡死。Ollama 是开发体验神器，不是高并发服务器。真要对外扛流量，老实上 vLLM。

服务侧两个必懂概念

• KV Cache：生成时把前面算过的 K/V 缓存起来不重算（见 Transformer 篇的注意力）。它是推理提速的关键，但吃显存，并发越高、context 越长，KV Cache 占的显存越多——这常常才是"显存不够"的真凶，而不是模型本身。
• 连续批处理 (Continuous Batching)：vLLM 的看家本领，把多个请求动态拼到一起喂 GPU，吞吐能比"一个个处理"高好几倍。这就是它能扛并发、Ollama 不能的核心差别。

---

显存怎么估：一张表算清"我的卡跑得动吗"

面试和实战都会遇到的灵魂拷问："7B 模型要多少显存？"先记一个粗算公式：

模型权重显存 ≈ 参数量 × 每参数字节数
  FP16     → 每参数 2 字节
  INT8     → 每参数 1 字节
  4-bit 量化 → 每参数约 0.5 字节

实际要预留 ≈ 权重 + KV Cache（随并发和 context 涨） + 约 1-2GB 框架开销

按这个公式，常见尺寸对照表（权重部分，未含 KV Cache）：

两个实战提醒：

1. 别忘了 KV Cache。 上表只是把模型"装进去"的钱。生产上并发 50、context 8k，KV Cache 可能再吃掉几个到十几 GB。我见过最经典的事故：压测单请求一切正常，上线并发一高就 OOM——模型没变，是 KV Cache 把剩余显存吃光了。
2. Mac 用户看统一内存。 Apple Silicon 的显存就是内存，16GB Mac 跑 7B Q4 很舒服，跑 14B 就开始挤占系统内存变卡。

---

量化格式：GGUF / GPTQ / AWQ 别搞混

术语：量化 (Quantization)

• 一句话解释：把模型参数从高精度（16 位）压成低精度（4/8 位）存，省显存。
• 形象比喻：同一部电影的不同清晰度——4K、1080p、720p，机器弱就选小的。
• 工作中怎么用：4-bit 能把显存占用砍到约 1/4。
• 最常踩的坑：盲目追最高精度。多数对话场景 4-bit 肉眼无差却省一半显存；先跑小的，不够再往上换。

三种常见格式，配错工具会加载失败：

GGUF 的后缀是个小型选择题，展开说一下：

数字越小越省显存但质量越降，K_M 是一种混合精度方案——记不住就用默认 Q4_K_M。

（量化省显存的原理和 QLoRA 同源，见微调篇。）

---

核心决策：自托管 vs 调 API（带算例）

这是本篇的重点。别凭感觉，先看几条判断，再算笔账：

该调 API（闭源）的时候： 调用量不大或波动大（不想为闲置 GPU 付整月钱）、要最强推理能力、团队没人想管 GPU 运维。

该自托管开源的时候： ①数据不能出公司（合规，压倒一切的硬门槛）；②调用量大且稳定；③要深度微调成专用模型；④要可控延迟、不看别人 API 涨价/下线旧模型的脸色。

算笔账：什么调用量下自托管才划算

假设你要一个 7B 级别的能力，粗略对比（数字为示意，实际按当下报价）：

方案 A · 调 API
  假设每 1M token 约 $0.3，平均每次请求 2k token
  → 每次约 $0.0006；每天 10 万次 → 约 $60/天 → 约 $1,800/月

方案 B · 自托管（租一张能跑 7B 的 GPU）
  一张中端推理 GPU 云租 ≈ $1.5/小时 × 24 × 30 ≈ $1,080/月（固定）
  —— 不管你跑 1 次还是 100 万次，钱都得付

盈亏平衡点粗算：
  $1,080 ÷ $0.0006 ≈ 180 万次/月 ≈ 每天 6 万次
  → 日调用量稳定超过 ~6 万次，自托管开始便宜
  → 低于这个量级，API 稳赢

把不同量级摆一起看更直观：

* 量再大可能要加卡，但自托管成本是台阶式上涨，API 是线性上涨——量越大差距越拉开。

算例之外：三笔容易漏算的隐性成本

1. 运维人力。 GPU 驱动、CUDA 版本、vLLM 升级、半夜 OOM 报警——都得有人管。如果团队没人愿意做这个，把一个工程师 20% 的时间折成钱加进"自托管"那栏，账可能立刻翻盘。
2. 冗余和高可用。 API 挂了是供应商的锅（还有 SLA 赔偿）；自托管挂了是你的锅。生产级要至少两个实例，成本 ×2。
3. 质量差距的机会成本。 7B 开源模型答不好的请求，用户流失的钱不会出现在 GPU 账单里，但它真实存在。

结论：调用量小或忽高忽低，API 稳赢（你只为用掉的付费）；调用量大且平稳，自托管把固定成本摊薄后单次趋近免费，才划算。

一句话私房建议：先用 API 把产品跑通、验证需求，量起来了、账算得过来了、或者合规逼你了，再考虑自托管。 一上来就自建 GPU 集群，多半是过早优化。更完整的推理成本控制手段（缓存、batch、降级）见部署与成本优化。

---

模型路由：一个系统里用好几个模型

术语：模型路由 (Model Routing)

• 一句话解释：根据请求难易，自动把它派给合适（便宜/贵）的模型。
• 形象比喻：医院分诊台。头疼脑热分给普通门诊（小模型），疑难杂症才转专家（大模型），不让专家看感冒。
• 工作中怎么用：简单意图识别/分类/改写走本地小模型或便宜 API；复杂推理/长文档才上旗舰模型。
• 最常踩的坑：路由判断本身又调了一次大模型，省下的钱全搭进"判断"里。判断要用极轻量的规则或小模型。

一个典型的省钱路由：

用户请求
   │
   ▼
[轻量分类器]  ── 简单/常见? ──▶ 本地小模型（Qwen 7B / Llama 8B）  便宜、快
   │
   └── 复杂/高价值? ──▶ 旗舰 API（GPT / Claude）  贵、强

落到代码上，最朴素的版本就是一个 if/else——因为两边都是 OpenAI 兼容接口，路由只是换 client：

LOCAL = OpenAI(base_url="http://localhost:8000/v1", api_key="x")
CLOUD = OpenAI()  # 官方 API

SIMPLE_TASKS = {"classify", "rewrite", "extract", "faq"}

def route(task_type: str, prompt: str):
    # 判断逻辑用"规则 + 请求元信息"，零成本；别为了路由再调一次大模型
    if task_type in SIMPLE_TASKS and len(prompt) < 2000:
        return LOCAL, "Qwen/Qwen2.5-7B-Instruct"
    return CLOUD, "gpt-5"

client, model = route("classify", user_input)
resp = client.chat.completions.create(model=model, messages=[...])

那"简单请求"到底怎么判断？给一个实战可用的下放清单：

进阶两步走：

1. 加降级/兜底路径：本地模型超时或质量置信度低 → 自动升级到旗舰 API 重跑。用户只感觉"这次慢了一点"，不会看到失败。
2. 加统一网关：模型多了以后，路由、限流、日志、计费统计放在一个网关层做，业务代码不用知道背后是几个模型。这一层怎么建见 LLM 平台与网关。

实测里，很大比例的请求其实是简单的，把它们从旗舰模型上摘下来，账单常常能砍掉一大半，而用户几乎无感。这就是为什么"会跑开源模型"在工程上真正值钱——不是为了取代 API，而是为了和 API 搭配着用。哪些任务适合下放小模型、怎么系统性评估，见 AI Model 选型与对比的分层表和 scorecard。

---

自托管不等于自动安全

一个容易想歪的点：模型部在自己机器上 ≠ 安全问题消失了，只是换了一批。

• 端口别裸奔。 vLLM / Ollama 起的服务默认没有鉴权，直接绑公网 IP 等于把 GPU 白送给全网薅。至少加反向代理 + API key，内网部署就老实待在内网。
• Prompt injection 一个不少。 攻击的是"模型 + 你的系统提示词"这套组合，跟模型托管在哪无关。自托管模型的安全评估往往还更弱，边界要靠你自己兜。
• 合规是自托管的理由，不是免死金牌。 数据不出公司只解决"传输/存储位置"这一条，日志脱敏、访问控制、审计这些一样要做。

完整的威胁清单和防护思路见安全威胁建模。

---

决策速查：一张图带走

把全篇的判断压缩成一条决策链，下次老板再问"要不要自己部署"，照着走一遍：

数据能不能出公司？
   │
   ├── 不能（合规硬门槛） ──▶ 自托管，没得选。直接去算显存和卡数
   │
   └── 能 ──▶ 日调用量稳定超过盈亏平衡点吗？（照本文算例算你自己的）
            │
            ├── 没超过 / 忽高忽低 ──▶ 调 API。别买卡，把精力花在产品上
            │
            └── 超过了 ──▶ 团队有人愿意管 GPU 运维吗？
                     │
                     ├── 没有 ──▶ 还是 API，或托管推理服务（别人帮你养卡）
                     │
                     └── 有 ──▶ 自托管 + 模型路由：
                                简单请求 → 本地小模型
                                复杂请求 → 旗舰 API 兜底

注意最后一格：自托管和 API 不是二选一。生产里最常见的终局是混合架构——大头流量走自己的小模型，难题和兜底走 API。

---

⚠️ 常见陷阱

---

🔧 动手练习

练习 1：小模型够不够用（约 15 分钟）

1. 用你 Quest 里的 Ollama，同一个问题分别问大小两档模型：

ollama run qwen2.5:7b   "把这段话总结成 3 个要点：……"
ollama run qwen2.5:1.5b "把这段话总结成 3 个要点：……"

2. 换三类任务各测一次：总结、分类（"这条评论是正面还是负面"）、代码解释。
3. 记下每类任务里 1.5B 和 7B 的差距——你会发现分类几乎无差、代码解释差很多。这份手感就是你以后设计路由的依据。

练习 2：算你自己的盈亏平衡点 + 写一条路由规则（约 20 分钟）

1. 拿本文的成本算例，把数字换成你项目的真实量级（每天 N 次、每次多少 token、当下 API 报价），算出你的"自托管盈亏平衡点"在每天多少次调用。
2. 列出你项目里的请求类型，标出哪些能下放给小模型、哪些必须走旗舰，照本文的 route() 写成一段真的能跑的 if/else。
3. 附加题：给路由加一条降级规则——本地模型超时 3 秒自动改打旗舰 API。

---

📚 小结

1. 开源权重 ≠ 完全开源：多数只给参数、带商用限制，用前看 license；选型从 7B~8B 甜点区起（Qwen 中文强、Llama 生态大）。
2. 拿模型上 Hugging Face；本地试玩 Ollama/LM Studio，生产高并发必须 vLLM/TGI（靠连续批处理扛量）；两者都暴露 OpenAI 兼容接口，业务代码换个 base_url 就能切换。
3. 显存粗算：FP16 每参数 2 字节、4-bit 约 0.5 字节，7B Q4 约 4-5GB；但KV Cache 才是显存大户，压测必须带上真实并发和 context。量化格式别配错：GGUF→Ollama、AWQ/GPTQ→GPU，记不住就 Q4_K_M。
4. 自托管 vs API 算账：量小/波动大 → API 稳赢；量大且稳（示意算例里约日 6 万次以上）、或合规硬要求、或要深度微调 → 自托管；别漏算运维人力和高可用冗余，否则先用 API 跑通别过早自建。
5. 模型路由才是开源模型在工程上的真正价值——简单请求下放小模型、难的才上旗舰，账单常砍一大半而用户无感；路由判断用规则/小模型，别让"分诊"本身又烧一次大模型。

---

相关阅读

• LLM API 基础 — OpenAI 兼容接口的请求结构，本地/云端切换的前置知识
• AI Model 选型与对比 — 哪些任务下放小模型、怎么建 eval 评估
• LoRA / QLoRA / PEFT 微调 — 自托管的下一步：把开源模型调成你的专用模型
• LLM 平台与网关 — 多模型统一接入、限流、计费的网关层
• 部署与成本优化 — 缓存、batch、降级等推理成本控制手段
• 生产环境部署 — 把推理服务放进完整的生产架构
• 安全威胁建模 — 自托管服务的威胁清单与防护
• Transformer 与注意力 — KV Cache 为什么存在、为什么吃显存