用 vLLM 本地部署 DeepSeek：从入门验证到高性能服务

99% 想本地跑 DeepSeek 的人，一上来就选错了工具。你可能已经在纠结 vLLM、Ollama、官方 API 选哪个，却还没想清楚：你到底是想“玩玩看”，还是要“自己扛一套生产级服务”。这篇文章专门讲后一种——用 vLLM 在本地或私有服务器上部署 DeepSeek 模型，既不替代官方 DeepSeek API，也不是面向零基础一键安装的教程。

提醒：文中命令和参数基于官方 vLLM 文档、DeepSeek 模型卡和 vLLM DeepSeek 配方整理而来，适合作为技术参考，而不是保证“在你任何硬件上一跑就过”的万能脚本。

如果你只是想快速试英文提示词，直接用浏览器里的 Chat-Deep.ai DeepSeek 聊天页面就够了；想要托管式开发接入，用官方 DeepSeek API 更省心。只有当你明确需要私有部署、高吞吐推理、批量请求、多 GPU 或 OpenAI 兼容本地端点时，vLLM 才是值得认真折腾的选项。

用 vLLM 跑 DeepSeek：适用场景与角色

什么时候该选 vLLM，而不是 Ollama 或官方 API？

遇到这种情况，大多数人的第一反应都是“越专业的工具越好”，结果直接把自己扔进运维地狱。更稳妥的做法，是先对号入座：

• 你需要在自家机房或云服务器上，长期稳定地服务 DeepSeek 开源权重模型。
• 你希望暴露一个 OpenAI 风格的 /v1 接口，方便现有 SDK 和应用直接切换到本地。
• 你在意吞吐量、批处理、并发和多 GPU 利用率，而不仅仅是“能不能跑起来”。
• 你要做模型评测、对比实验或内部平台，而不是单机桌面聊天小玩具。

有用户反馈，在一个 8×A100 的集群上，用 vLLM 跑 DeepSeek-V3.2 做内部代码助手，吞吐量比简单的单卡推理脚本高出 5–8 倍，这就是 vLLM 的价值所在。

谁适合读完这篇指南？

如果你对 Python 虚拟环境、CUDA/ROCm 驱动、Hugging Face 下载、Linux 基本运维不陌生，这篇文章会帮你少踩很多坑。反过来，如果你连 GPU 型号、显存大小都说不清，那更适合先用 Ollama 或 LM Studio 熟悉一下本地大模型的基本概念。

一位朋友刚上来就想在 8GB 显存笔记本上跑 DeepSeek-R1 全量模型，结果不是 OOM 就是进程直接被系统杀掉，折腾两天才意识到：模型选型本身就错了。

vLLM 能为 DeepSeek 做什么？

vLLM 的核心价值：不是“装上 DeepSeek”，而是“高效服务”

很多人以为装了 vLLM 就是“给电脑加了 DeepSeek 功能”，其实不太对。vLLM 的本质是一个高性能推理与服务引擎，它做的事是：

• 把支持的 DeepSeek 模型 checkpoint 挂成一个 HTTP 服务；
• 提供 OpenAI 兼容接口（例如 http://localhost:8000/v1），让现有客户端几乎零改动接入；
• 在底层处理张量并行、数据并行、专家并行、长上下文优化等复杂细节。

对 DeepSeek 这种大体量模型来说（比如 DeepSeek-V3、DeepSeek-R1、DeepSeek-V3.2），真正难的是“怎么高效服务”，而不是“怎么加载权重”。vLLM 正好把这块基础设施能力打包好了。

推理解析：把“思考过程”和最终答案拆开

DeepSeek-R1 这类“推理风格”模型，会输出类似 … 的思考过程文本。如果你在应用里手动用字符串切割这些标签，不仅脆弱，还很难兼容未来格式变化。

vLLM 内置了针对 DeepSeek-R1、DeepSeek-V3.2 等模型的推理解析器：

• 启动服务时加上 --reasoning-parser 对应参数；
• 返回结果中会多出结构化字段（如 reasoning），把思考过程和最终回答分开；
• 应用层可以直接读字段，而不是自己拆标签。

我个人用过一段时间这种解析方式，说实话，调试和日志分析舒服太多了。

DeepSeek API、vLLM、Ollama：别乱选武器

三种方案，各自解决不同问题

很多团队一上来就说“我们要自建，不能用云”，但真算成本和人力时又会犹豫。可以先用一个简单对比：

• 官方 DeepSeek API：托管服务，有计费、有 SLA、有最新模型，适合产品上线和快速迭代。
• Ollama / LM Studio：桌面友好，适合个人或小团队在单机上体验、Demo、轻量开发。
• vLLM + DeepSeek 开源权重：适合有 GPU 资源、需要私有化、要做高并发或内部平台的团队。

据一些云厂商公开数据，企业在自建大模型服务时，运维和工程成本往往是显卡租金的 1.5–2 倍，这也是为什么很多团队先用官方 API 验证业务，再考虑自建。

一个简单的决策清单

你可以用下面这几条快速判断：

• 想“先跑起来看看效果” → 选 Ollama 或浏览器聊天。
• 想“上线一个收费产品，但不想管 GPU” → 选官方 DeepSeek API。
• 想“公司内部必须私有部署，有 GPU，有运维” → 选 vLLM + DeepSeek。
• 想“做模型评测、对比不同 checkpoint” → vLLM 会更灵活。

如果你现在正纠结选哪个，不妨先用官方 API 把业务跑通，再用 vLLM 做性能和成本对比，这样更有数据支撑，而不是拍脑袋。

用 vLLM 选 DeepSeek 模型：别一上来就拉满

DeepSeek-V3.2：高阶玩家的主战场

DeepSeek-V3.2 是当前讨论度很高的一支开源权重家族，模型卡里提到：

• 更新了聊天模板；
• 重写了工具调用格式；
• 引入了“带工具的思考”能力。

vLLM 为 V3.2 提供了专门的配方，包括 tokenizer 模式、工具调用解析器、推理解析器等参数。问题在于：V3.2 本身体量巨大，官方配方默认就是面向多 GPU、高端服务器的。

如果你只是想验证流程，直接上 V3.2 往往只会得到一个结果：显存爆掉，或者性能惨不忍睹。更合理的做法是，把 V3.2 当作“目标形态”，先用小模型把链路跑通。

DeepSeek-V3.2-Speciale：只适合“纯推理”场景

Speciale 版本在官方模型卡里写得很清楚：

• 专门为深度推理任务设计；
• 不支持工具调用。

所以如果你的应用需要工具链、Agent 循环、函数调用之类能力，就不要把 Speciale 当默认模型。它更像是“数学/逻辑重度场景”的专用刀，而不是通用助手。

DeepSeek-R1 与 DeepSeek-R1-0528：不是笔记本玩具

DeepSeek-R1 是 DeepSeek 家族里主打“推理能力”的大模型。模型卡里写明：

• DeepSeek-R1 / DeepSeek-R1-Zero 总参数 671B；

• 激活参数约 37B；

• 上下文长度 128K。

这类规模的 MoE 模型，本质上就是为数据中心和多 GPU 集群设计的。DeepSeek-R1-0528 是后续更新版本，具体差异可以看专门的 R1 指南，而不是指望在一篇 vLLM 部署文里讲清所有历史。

DeepSeek-R1-Distill：更现实的第一步

对大多数人来说，R1-Distill 系列才是用 vLLM 起步的最佳选择。这一系列基于 Qwen、Llama 等骨干网络蒸馏而来，包括：

• DeepSeek-R1-Distill-Qwen-1.5B
• DeepSeek-R1-Distill-Qwen-7B
• DeepSeek-R1-Distill-Qwen-14B
• DeepSeek-R1-Distill-Qwen-32B 等

小体量蒸馏模型更适合：

• 验证 vLLM 安装是否正确；
• 测试 OpenAI 兼容接口；
• 检查推理输出字段（如 reasoning）；
• 跑一轮简单基准测试。

等这些都顺利了，再考虑往上切换到更大的 checkpoint 或 V3.2。

开始之前：硬件、系统与心理预期

你需要具备的基础能力

严肃的 vLLM 部署，通常发生在 Linux 服务器或 GPU 工作站上。你至少要能：

• 管理 Python 虚拟环境（venv、uv、conda 等）；
• 搞清楚 CUDA / ROCm 版本与驱动是否匹配；
• 用 Hugging Face CLI 或程序下载模型；
• 启动、停止、排查一个长期运行的服务进程。

我也不太确定这个说法对不对，但从最近一两年的趋势看，能稳定运维大模型服务，已经成了不少后端工程师的“新必备技能”。

开始前要想清楚的 7 件事

• 模型大小决定可行性：1.5B 蒸馏模型和 671B MoE 是完全不同的部署问题。
• 别把全量 DeepSeek 模型当笔记本玩具：不要对普通消费级 GPU 抱太高期待。
• 配方更新很快：Markdown 文档更多是历史记录，最新命令以 https://recipes.vllm.ai/ 为准。
• 驱动和后端兼容性关键：vLLM 版本、PyTorch 后端、CUDA/ROCm 组合不对，很多玄学错误都会出现。
• 机密信息用环境变量：Hugging Face Token、内部 API Key 一律不要写死在脚本里。
• 认真看模型卡和 License：包括可商用范围、推荐参数、聊天模板等。
• 用自己的业务场景做压测：长上下文、工具链、代码生成，各自的瓶颈完全不同。

安装 vLLM：从通用到 DeepSeek 专用

通用安装流程

推荐用干净的 Python 环境安装 vLLM，命令可能会随版本和平台变化，部署前最好再对照一次官方文档：

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

如果你在 AMD、CPU-only 或其他特殊平台上部署，一定要看官方安装页的对应说明，不要照搬 CUDA 示例。

DeepSeek-V3.2：夜版 wheel 与 DeepGEMM

针对 DeepSeek-V3.2，vLLM 配方里曾经使用过 nightly 轮子和 DeepGEMM 相关设置，大致风格如下：

# 高阶 DeepSeek-V3.2 配方示例
# 上生产前务必对照当前官方配方

uv venv
source .venv/bin/activate
uv pip install vllm --extra-index-url https://wheels.vllm.ai/nightly

部分 V3.2 配方会提到 DeepGEMM，用于 MoE 和 MQA logits 计算。有环境会选择通过 VLLM_USE_DEEP_GEMM=0 关闭 MoE 部分。这里的关键点是：

• 不要从旧博客里复制命令直接上生产；
• 以 vLLM 官方 DeepSeek-V3.2 配方为准，按你的 GPU 型号和部署方式调整。

实战 A：用 vLLM 服务一个 DeepSeek-R1-Distill 模型

启动最小可用服务

蒸馏模型是验证链路的最佳起点。下面是基于 vLLM 推理输出工作流的示例命令：

vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B \
  --reasoning-parser deepseek_r1

这会启动一个本地 vLLM 服务，并启用 DeepSeek-R1 推理解析器。更大的蒸馏模型（如 7B、14B、32B）会对显存、上下文长度、并行策略提出更高要求，不能指望 1.5B 能跑的命令，32B 也能原样照抄。

更大蒸馏模型的参考命令

DeepSeek-R1 官方模型卡中给过一个 32B 蒸馏模型的 vLLM 启动示例：

vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-32B \
  --tensor-parallel-size 2 \
  --max-model-len 32768 \
  --enforce-eager

你可以把它当作“参考模板”，再根据自己的 GPU 数量、显存、目标上下文长度和服务形态做调整。比如：

• 显存吃紧时，适当降低 --max-model-len；
• 多卡时尝试不同的 --tensor-parallel-size；
• 有需要时再考虑量化或其他优化手段。

实战 B：用 vLLM 服务 DeepSeek-V3.2

高阶启动示例：Tokenizer + 工具 + 推理解析

DeepSeek-V3.2 的部署明显更复杂，vLLM 官方配方中通常会包含一组专门的参数：

vllm serve deepseek-ai/DeepSeek-V3.2 \
  --tensor-parallel-size 8 \
  --tokenizer-mode deepseek_v32 \
  --tool-call-parser deepseek_v32 \
  --enable-auto-tool-choice \
  --reasoning-parser deepseek_v3

这里有几个关键点：

• --tokenizer-mode deepseek_v32：适配 V3.2 的特殊聊天模板和分词行为；
• --tool-call-parser deepseek_v32：让工具调用结构化输出；
• --enable-auto-tool-choice：允许模型自动选择工具；
• --reasoning-parser deepseek_v3：解析 V3.2 的思考过程输出。

如果你在新版本 vLLM 中发现这些参数有变化，优先以官方配方为准，不要凭感觉删减。

EP/DP 模式与多 GPU 部署

vLLM DeepSeek-V3.2 配方中还会提到 EP/DP（专家并行 / 数据并行）模式，在某些场景下推荐使用，因为内核主要针对 TP=1 做了优化。一个简化示例是：

vllm serve deepseek-ai/DeepSeek-V3.2 \
  -dp 8 \
  --enable-expert-parallel

这类命令明显不是给单机笔记本准备的，而是面向多卡服务器：

• GPU 代际（A100、H100、L40S 等）会影响最佳配置；
• 显存大小决定你能承受的上下文长度和 batch；
• 不同注意力后端、量化格式也会改变性能表现。

官方 DeepSeek 配方页已经明确：Markdown 文档更多是历史记录，最新、按硬件定制的命令请去 https://recipes.vllm.ai/ 用交互式生成器查看。

用 OpenAI Python SDK 调用你的 vLLM DeepSeek 服务

把 base_url 指向本地 vLLM

很多团队选 vLLM 的一个直接原因，就是它提供 OpenAI 兼容接口。模型一旦用 vllm serve 跑起来，就可以用 OpenAI 官方 Python 客户端这样调用：

from openai import OpenAI

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

response = client.chat.completions.create(
    model="deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B",
    messages=[
        {"role": "user", "content": "Explain vLLM in one paragraph."}
    ],
)

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

如果你在启动 vLLM 时加了 --api-key token-abc123，这里就要用对应的 Key。很多人会把本地 vLLM 的 Key 和官方 DeepSeek API Key 搞混，结果调错地址、错怪服务挂了。

读取推理字段：reasoning vs reasoning_content

DeepSeek 官方 API 在“思考模式”下，用的是 reasoning_content 字段；而 vLLM 当前文档中推荐使用 reasoning 字段，并说明 reasoning_content 是旧名称。不同第三方封装可能还会有自己的命名习惯。

在 vLLM 场景下，你可以这样读取：

from openai import OpenAI

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

response = client.chat.completions.create(
    model="deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B",
    messages=[
        {"role": "user", "content": "Which is greater, 9.11 or 9.8?"}
    ],
)

message = response.choices[0].message
reasoning = getattr(message, "reasoning", None)
content = message.content

print("reasoning:", reasoning)
print("content:", content)

不要写那种只会用字符串拆 … 的脆弱逻辑，既难维护，又不利于兼容未来格式变化。更稳妥的做法是：

• 优先读结构化字段（reasoning / reasoning_content）；
• 做好字段不存在时的兜底处理；
• 必要时再对原始文本做轻量解析。

思考模式与工具调用：vLLM 与官方 API 的差异

开启思考模式：thinking vs chat_template_kwargs

在官方 DeepSeek API 中，思考模式通常这样开启：

response = client.chat.completions.create(
    model="deepseek-chat",
    messages=messages,
    extra_body={"thinking": {"type": "enabled"}}
)

而在 vLLM + DeepSeek-V3.2 场景下，官方配方推荐通过聊天模板参数来控制：

response = client.chat.completions.create(
    model="deepseek-ai/DeepSeek-V3.2",
    messages=messages,
    tools=tools,
    extra_body={"chat_template_kwargs": {"thinking": True}}
)

同时要记住：

• vLLM 推荐用 reasoning 字段承载思考输出；
• 官方 DeepSeek API 用的是 reasoning_content；
• vLLM 在没有工具调用时，tool_calls 可能是空列表 []，而官方 API 可能返回 None。

处理工具调用返回：兼容两种“没有工具”的情况

你可以用类似下面的代码处理工具调用结果：

tool_calls = response.choices[0].message.tool_calls

if tool_calls:
    for call in tool_calls:
        print("Tool call:", call)
else:
    print("No tool calls returned.")

再提醒一次：DeepSeek-V3.2-Speciale 官方说明不支持工具调用，如果你的 Agent 强依赖工具链，就不要选 Speciale 当主力模型。

OpenAI 兼容接口：别想当然以为“完全一样”

支持与差异点一览

vLLM 的定位是“OpenAI 兼容”，而不是“所有厂商 API 的完美克隆”。在设计产品时，最好提前确认：

• Chat Completions：支持有聊天模板的文本生成模型。
• Completions：支持，但 suffix 参数不支持。
• 额外参数：可以通过 extra_body 传入非 OpenAI 标准参数。
• generation_config：默认可能会读取 Hugging Face 仓库中的 generation_config.json；如果你想用 vLLM 默认值，可以在文档中查 --generation-config vllm 相关说明。
• 聊天模板：如果模型缺少合适的聊天模板或解析器，聊天请求可能报错或行为异常。

有团队在迁移时忽略了 generation_config 差异，结果发现本地 vLLM 输出和官方 API 差一大截，最后才发现是温度、top_p 等采样参数完全不一致。

性能与压测：不要被“一条命令”骗了

用 vLLM 自带工具做基准测试

不要只在终端里敲一条 prompt，看着“好像挺快”的错觉就结束。vLLM 自带了服务压测工具，DeepSeek-V3.2 配方中类似这样：

vllm bench serve \
  --model deepseek-ai/DeepSeek-V3.2 \
  --dataset-name random \
  --random-input 2048 \
  --random-output 1024 \
  --request-rate 10 \
  --num-prompt 100 \
  --trust-remote-code

压测时重点关注：

• TTFT（Time To First Token）：首 token 延迟，影响交互体验；
• TPOT（Time Per Output Token）：单 token 生成时间，影响整体速度；
• 输出 token 吞吐量：对批量和高并发场景尤为关键；
• 失败请求数：可能是过载、配置错误或内存不足的信号；
• 并发曲线：并发数上去之后性能是否断崖式下降；
• 上下文长度影响：长 prompt 对显存和延迟的放大效应非常明显；
• 工具链开销：Agent 工作流中，很多时间其实花在外部工具而不是模型本身。

不要直接拿本地 vLLM 和云端 API 生比

云端官方 API 通常有：

• 更强的硬件（H100 集群、专用加速卡等）；
• 更激进的内核优化和缓存策略；
• 更靠近你用户的网络位置。

如果你要比较延迟或吞吐，至少要控制这些变量：

• 模型版本与权重是否一致；
• 上下文长度、采样参数是否一致；
• 请求形状（单轮、多轮、工具调用）是否一致；
• 是否有缓存、预热等差异。

安全：把 vLLM 当“生产服务”看待

暴露服务前要做的防护

本地 vLLM 服务，本质上就是一个 API 服务。如果有其他人或网络能访问它，就要按生产标准来对待：

• 不要直接把 localhost:8000 / 0.0.0.0:8000 暴露到公网；
• 内部访问用防火墙、私有网络、VPN 或服务网格隔离；
• 对共享端点启用 --api-key 或上游网关鉴权；
• 对外或团队共享部署前，加上反向代理、TLS、请求大小限制和限流；
• 日志中避免记录敏感 prompt、客户数据、密钥或私有代码；
• 对工具调用参数做严格校验，尤其是涉及 Shell、文件、数据库、网络操作的工具；
• 把模型服务权限和代码仓库、CI、数据库、生产账号隔离开；
• 监控失败请求、异常 token 使用、超长生成和异常工具调用模式。

有团队在内部测试时，把 vLLM 端口直接暴露在公司公网 IP 上，结果被安全团队一顿追问，教训非常深刻。

常见错误与排查思路

1. 模型太大或显存不够

表现：启动时报 OOM、进程被系统杀掉、服务随机崩溃。

处理思路：

• 换成更小的蒸馏模型；
• 降低 --max-model-len；
• 降低 batch 或并发；
• 考虑多 GPU 部署或更大显存机器。

2. 并行配置不当（TP/DP/EP 搞混）

大规模 DeepSeek MoE 模型对并行策略很敏感：

• Tensor Parallel（TP）在某些场景能改善延迟；
• Data Parallel（DP）+ Expert Parallel（EP）在高负载下更适合 MoE；
• 建议从官方 vLLM 配方起步，再结合压测结果微调。

3. vLLM 版本太旧或不匹配

DeepSeek-V3.2 依赖的特性包括：

• 特定 tokenizer 模式；
• 工具调用解析器；
• 推理解析器；
• 模型专用内核。

如果你遇到模板、解析相关报错，优先检查 vLLM 版本和安装方式，必要时升级并对照最新配方。

4. CUDA / ROCm / 驱动不兼容

症状可能包括：

• 启动时报奇怪的 GPU 错误；
• 某些算子不支持；
• 同一命令在另一台机器上却能跑。

排查时：

• 对比 GPU 驱动版本、CUDA/ROCm 版本；
• 检查 PyTorch 后端是否和 vLLM 安装方式匹配；
• 非 CUDA 平台务必按官方安装说明操作。

5. 推理字段缺失

如果你在响应里找不到 reasoning：

• 确认模型本身是推理模型（如 R1、V3.2 等）；
• 启动时是否加了正确的 --reasoning-parser；
• 客户端 SDK 是否支持访问非标准字段。

对 DeepSeek-R1-Distill，记得使用 --reasoning-parser deepseek_r1。

6. 工具调用行为和官方 API 不一致

常见差异包括：

• tool_calls 为 [] vs None；
• 字段名或结构略有不同。

建议在代码里同时兼容这两种“无工具调用”情况，并根据你实际使用的是官方 API 还是 vLLM 做分支处理。

7. 上下文长度设得太高

长上下文会显著增加显存占用和延迟：

• 测试阶段可以先把 --max-model-len 调低；
• 真正需要长上下文时，再逐步拉高并观察性能变化；
• 对于只需要短对话的应用，不必盲目追求 128K、200K 之类的数字。

8. 首 token 很慢

影响首 token 延迟的因素包括：

• 模型加载和冷启动；
• prompt 过长；
• 前缀缓存策略；
• 并发过高导致排队。

压测时要区分“冷启动”和“预热后”的表现，不要只看其中一种。

9. 输出和官方 DeepSeek API 差异明显

可能原因：

• 使用的是开源 checkpoint，而不是官方托管模型；
• vLLM 读取了 Hugging Face 仓库里的 generation_config.json；
• 采样参数（温度、top_p 等）不同；
• 聊天模板或解析器不一致；
• 量化或其他推理优化带来的细微差异。

如果你业务上必须“和官方 API 行为几乎一致”，那最稳妥的方案还是直接用官方 DeepSeek API，而不是自建近似版本。

vLLM、Ollama、官方 DeepSeek API：如何做最终选择？

三者定位再对比

• Ollama / LM Studio：
  • 优点：安装简单、界面友好、适合个人和小团队；
  • 适用：体验模型、做 Demo、小规模本地开发。
• 官方 DeepSeek API：
  • 优点：托管、计费清晰、OpenAI 风格接口、免运维；
  • 适用：产品上线、快速迭代、对稳定性要求高的场景。
• vLLM + DeepSeek 开源权重：
  • 优点：私有部署、高吞吐、可控性强、易于扩展；
  • 风险：需要自己承担 GPU 成本、运维、安全和监控。

这套判断方法在不少团队里被反复验证有效，建议你收藏下来，给未来要做技术选型的同事参考。

一个现实的行动路径

• 先用小型 DeepSeek-R1-Distill 模型 + vLLM 验证链路；
• 再根据业务需求和硬件条件，评估是否要上 V3.2 或更大模型；
• 同时用官方 API 做一轮对比测试，看性能、成本、维护负担；
• 最后再决定长期是“完全自建”“完全托管”还是“混合方案”。

如果你正站在“要不要自建 DeepSeek 服务”的十字路口，这套路径往往比问身边人更有参考价值。

常见问题

Q：只有一张 24GB 显存的显卡，还值得用 vLLM 跑 DeepSeek 吗？

A：可以，但要控制预期，更适合从小模型和蒸馏模型起步。24GB 显存跑 DeepSeek-R1-Distill-Qwen-1.5B、7B 这类模型，一般问题不大，但上到 32B 或 V3.2 就会非常吃紧。原因在于，大模型不仅占显存，还要为 KV Cache、并发请求和长上下文预留空间。建议做法是：先用 1.5B/7B 验证链路和性能，再根据显存占用和延迟情况，谨慎尝试更大模型，必要时考虑多卡或云端 GPU。

Q：如何判断该用官方 DeepSeek API 还是自建 vLLM 服务？

A：看你更在意“省心”还是“可控”。如果你希望快速上线、按量付费、不想管 GPU 和运维，官方 API 更合适；如果你有稳定的 GPU 资源、对数据隐私和内部网络有严格要求，或者需要高度定制的推理配置，自建 vLLM 更有价值。判断依据包括：团队是否有运维能力、预计调用量是否足以摊薄自建成本、是否有合规或数据出境限制。建议先用官方 API 验证业务，再用 vLLM 做成本与性能对比。

Q：vLLM 的 OpenAI 兼容接口会不会和官方 SDK 不兼容？

A：大部分基础功能是兼容的，但细节上确实存在差异。比如 suffix 参数在 vLLM 的 Completions 接口中不支持，推理输出字段名（如 reasoning vs reasoning_content）也可能不同。原因在于 vLLM 只实现了 OpenAI API 的核心子集，并扩展了 extra_body 等自定义参数。建议做法是：在接入前列出你依赖的所有参数和字段，逐一在 vLLM 文档中确认支持情况，并在代码中对关键差异做适配层封装。

Q：为什么我本地 vLLM 的 DeepSeek 输出和官方 DeepSeek 网页版差很多？

A：这是常见现象，原因通常有几方面：使用的是开源 checkpoint 而非官方托管模型；vLLM 可能读取了 Hugging Face 仓库中的 generation_config.json，导致采样参数不同；聊天模板和系统提示词不一致；量化或推理优化带来细微差异。要缩小差距，可以对照模型卡中的推荐采样参数、系统提示和模板配置，尽量对齐；但如果你需要“几乎一模一样”的行为，最稳妥的还是直接用官方 DeepSeek API。

Q：部署 DeepSeek-V3.2 时，怎么避免踩到并行和显存的坑？

A：关键是不要盲目照抄别人的 8 卡命令。DeepSeek-V3.2 是大规模 MoE 模型，对 TP/DP/EP 配置非常敏感。原因在于不同 GPU 代际、显存大小和网络带宽会影响最佳并行策略。建议步骤是：先去 recipes.vllm.ai 选择你的 GPU 型号和目标模型，生成官方推荐命令；在小并发下验证稳定性和显存占用；再逐步提高并发和上下文长度做压测。过程中记录每次修改的配置和指标，避免“改着改着不知道哪里出问题了”的情况。

在你真正把 DeepSeek 跑进自家服务器之前，这些准备和判断会帮你省下很多返工时间。愿你在折腾 vLLM 的路上，多一点好奇，少一点瞎忙。