开源大模型上线

上线的第一步不是起服务，而是确认你拿到的到底是什么权重

很多部署问题，从第一步就埋下了。

团队常常说“我们要上 DeepSeek”或者“我们要上 Qwen”。

这句话在工程上还不够。

你至少要继续问下去。

是哪一个具体模型。

是 base 还是 instruct。

是原始 Hugging Face 权重，还是 GPTQ、AWQ、GGUF 这种衍生制品。

是否有使用条款、访问控制、Tokenizer 差异或专用推理要求。

如果这些问题没先答清，后面起服务、压测、回滚都会变得混乱。

三类模型家族，交付方式并不完全一样

今天开源部署里最常见的几条线，大概可以粗分为：

• DeepSeek 系列，尤其是 DeepSeek-R1 及其蒸馏版。
• Qwen 系列，覆盖从小模型到较大指令模型，社区兼容性极好。
• Mistral 系列，官方既有开源权重，也有带访问控制的发布方式。

这三类模型都能接进常见推理引擎。

但“拿权重”的路径并不完全相同。

先说 DeepSeek：很多时候你真正拿到的是 distill 版本

很多团队口头上说要部署 DeepSeek-R1。

真正先上线的，往往是 DeepSeek-R1-Distill-Qwen-7B 这类蒸馏版。

原因很现实。

原始大模型体积更大，对硬件要求更高。

蒸馏版则更容易在常规 GPU 上进入可控范围。

如果你的目标是先建立 OpenAI 兼容服务并跑通业务链路，蒸馏版通常是更稳的第一步。

DeepSeek 的一个直接起服命令

以 vLLM 为例，蒸馏版可以直接这样起。

vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 1 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90

如果你要接 reasoning 输出解析，还可以结合客户端层做单独处理。

但在第一阶段，先保证标准文本回答路径稳定更重要。

Qwen 的优势在于生态兼容度很高

Qwen 官方文档长期都对 vLLM、SGLang、Transformers 等生态保持较好的兼容说明。

这给上线带来的最大好处，不是“更强”两个字。

而是路径清楚。

模型能否被主流引擎直接加载。

采样参数有没有特殊要求。

是否有推荐的部署方式。

这些都会显著减少踩坑时间。

Qwen 的标准 vLLM 路线

官方部署文档给出的核心思路非常直接。

先安装 vLLM。

再拉起服务。

pip install -U vllm

vllm serve Qwen/Qwen2.5-7B-Instruct \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 2 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90

Qwen 官方文档还特别提醒一类细节。

不同模型对采样参数可能有各自习惯。

部署时不要默认沿用别的模型的温度与 top-p 配置。

这看起来像使用层问题。

实际会直接影响你在灰度阶段对“模型是否退化”的判断。

Mistral 经常多一步：访问控制与 token

Mistral 的一个常见部署差异，是模型访问路径经常需要先处理认证。

官方自部署文档说明得很清楚。

要先准备带 READ 权限的 Hugging Face token。

并确认自己对对应模型仓库有访问权。

这不是琐事。

因为很多团队在容器里拉模型失败，问题根本不在 CUDA，也不在引擎，而是在制品访问这一步。

Mistral 的一个自部署示例

官方文档目前给出的最直接路线之一，就是在环境里准备 HF_TOKEN 后配合 vLLM。

export HF_TOKEN=hf_xxx_your_token

vllm serve mistralai/Mistral-Small-3.1-24B-Instruct-2503 \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 4 \
  --max-model-len 8192

如果模型受访问控制，这里的环境变量就不是可选项。

它是制品拉取能否成功的前提。

同样的模型，也可能走 CPU 本地部署路径

不是所有上线都在 GPU 服务器里。

有些团队做的是桌面应用、内网工具或边缘服务。

这时候 llama.cpp 路线会变得更实际。

如果已经有 GGUF 制品，起服务命令会非常短。

例如对 Qwen 的 GGUF 版本，可以这样跑。

./build/bin/llama-server \
  -m /models/qwen2.5-7b-instruct-q4_k_m.gguf \
  -c 4096 \
  -np 4 \
  --port 8080 \
  --host 0.0.0.0

如果是 DeepSeek 蒸馏版，也可以使用对应 GGUF 制品。

./build/bin/llama-server \
  -m /models/deepseek-r1-distill-qwen-7b-q4_k_m.gguf \
  -c 4096 \
  -np 2 \
  --port 8080

这一类路径的核心不是极限吞吐。

而是部署门槛低、依赖少、交付简单。

OpenAI 兼容层为什么几乎成了默认要求

今天大多数上层应用不会愿意为每个推理引擎重写一次接口集成。

因此 OpenAI 兼容层几乎已经成了事实标准。

它的价值并不在于“长得像 OpenAI”。

而在于应用、网关、SDK、测试脚本和回放工具都能复用。

无论你用的是 vLLM、TGI、SGLang 还是 llama.cpp，只要兼容层稳定，上层接入就简单很多。

一次最小的兼容层验收

服务拉起来之后，最先做的不是 UI 联调。

而是直接用 curl 和官方 Python SDK 验证协议。

curl http://127.0.0.1:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen2.5-7B-Instruct",
    "messages": [
      {"role": "system", "content": "You are a helpful assistant."},
      {"role": "user", "content": "请用三点概括开源模型上线前最容易遗漏的问题。"}
    ],
    "temperature": 0,
    "max_tokens": 128
  }'

Python 侧也建议直接用同一套客户端来验。

from openai import OpenAI

client = OpenAI(
    api_key="EMPTY",
    base_url="http://127.0.0.1:8000/v1",
)

resp = client.chat.completions.create(
    model="Qwen/Qwen2.5-7B-Instruct",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "请解释为什么部署前要先确认权重来源。"},
    ],
    temperature=0,
    max_tokens=128,
)

print(resp.choices[0].message.content)

如果这一步都不稳定，后面的流量切换和业务回放没有意义。

上线前的性能调优，先抓最有用的几项

很多团队一上来就去微调几十个参数。

这通常不是效率最高的方式。

第一轮调优应当先抓下面这些最有影响的项。

• max_model_len 是否远大于真实请求分布。
• tensor_parallel_size 是否与 GPU 数量和模型规模匹配。
• gpu_memory_utilization 是否过激，导致高峰期 OOM。
• batch 与并发上限是否让 TTFT 变得不可接受。
• 是否真的需要流式返回，还是可以批量离线处理。

这些参数解决的是大头。

不是细枝末节。

模型家族不同，优化重心也会偏移

DeepSeek 蒸馏版的优化重点，通常是尽快跑通 reasoning 风格输出和足够稳定的响应延迟。

Qwen 的优化重点，往往是把通用生态兼容、量化版本和上下文长度配置好。

Mistral 的优化重点，除了性能，还经常包括制品拉取、授权与版本固定。

也就是说，上线不是在部署“一个抽象大模型”。

而是在部署一个有自己制品形态和生态边界的具体模型家族。

一份更务实的上线检查清单

如果要把问题压缩成最有用的上线前清单，通常至少包括这些项。

• 权重来源是否可复现，模型 ID 与版本是否固定。
• tokenizer 与聊天模板是否和预期一致。
• OpenAI 兼容层是否通过 curl 和 SDK 双重验收。
• TTFT、TPOT、OOM 边界是否已经压测。
• 日志里是否记录 prompt token、output token、错误类型和耗时。
• 灰度路由是否能在异常时快速切回旧模型。

为什么真正难的是“长期上线”，不是“第一次上线”

很多部署 demo 都能在一天内跑起来。

真正困难的是两周以后。

当权重升级。

当业务方改 prompt。

当并发模式变化。

当 GPU 节点被回收或迁移。

这时候你会发现，上线不是一个命令。

而是一条持续运营的链路。

因此越早把权重管理、兼容层、性能边界和观测指标收拢成标准流程，后面的成本越低。

本篇要点

• 开源模型上线的第一步是确认具体模型、权重形态、访问权限和版本固定，而不是直接起服务。
• DeepSeek、Qwen、Mistral 都能接入主流引擎，但权重获取与部署细节并不完全相同。
• vLLM 适合标准 GPU 在线服务，llama.cpp 则适合 GGUF 本地或边缘部署路径。
• OpenAI 兼容层几乎是默认要求，它决定上层 SDK、网关和业务代码能否低成本复用。
• 上线前最关键的调优项通常集中在显存预算、上下文长度、并发上限和版本可复现性。

下一篇

上一篇比较了引擎，这一篇把模型真正拉起来了。下一篇会进入最后一层工程化问题：限流、动态批处理、QPS/TPS/TTFT/TPOT 监控、VRAM OOM 恢复，以及为什么灰度发布对推理服务和普通 HTTP 服务一样重要。

参考资料

• Qwen Deployment with vLLM
• Mistral Self-Deployment
• DeepSeek-R1-Distill-Qwen-7B Model Card
• vLLM Serve CLI
• llama.cpp README