AutoDL+vLLM部署DeepSeek-R1：从环境搭建到性能调优实战指南

1. 为什么选择AutoDL加vLLM这套组合

1.1 本地部署大模型的现实困境

很多人第一次动了“自己部署一个大模型”的念头，往往是因为受够了网页版的各种限制：上下文长度被砍、高峰期排队、敏感数据不敢往上传、想批量跑任务还得按次付费。于是兴冲冲地打开购物网站看显卡，一看价格直接劝退——一张能跑得动主流开源模型的卡，动辄五位数起步，再加上配套的电源、主板、散热，整套下来够买辆代步车了。

就算咬咬牙买了卡，后面还有一堆坑等着你。驱动版本和CUDA版本对不上、PyTorch装完发现和显卡不匹配、显存不够模型加载到一半直接OOM、推理速度慢得像蜗牛爬。我见过太多人卡在环境配置这一步，折腾两三天连模型的第一句话都没生成出来，热情直接消耗殆尽。

所以对绝大多数个人开发者和中小团队来说，租算力才是更理性的选择。按小时计费，用完就关，不用了随时释放，成本可控，还省去了硬件维护的麻烦。而在众多算力租赁平台里，AutoDL算是上手门槛比较低、社区教程也比较多的一个。

1.2 AutoDL解决了什么问题

AutoDL本质上是一个GPU算力租赁平台。你注册账号、充值、选一张卡、选一个基础镜像，几分钟之内就能拿到一台带显卡的远程服务器。它最大的好处是把“环境”这件事简化了——平台提供了大量预装好CUDA、PyTorch、conda的基础镜像，你不需要从零开始配驱动。

对于部署大模型这个场景，AutoDL有几个实打实的优势。第一是按量计费，跑几个小时就付几个小时的钱，测试阶段成本极低。第二是镜像丰富，社区里有人做好了各种大模型相关的镜像，直接选就行。第三是数据盘独立，模型文件放在数据盘里，即使你释放了实例，数据盘还可以保留，下次换个卡接着用，不用重新下载几十GB的模型权重。

当然它也有需要注意的地方。AutoDL的实例分“无卡模式”和“有卡模式”，无卡模式开机不占GPU但可以用来传数据、配环境，有卡模式才真正跑推理。很多人不知道这个区别，一上来就开有卡模式传模型，白白烧钱。这个细节后面会详细讲。

1.3 vLLM凭什么成为推理首选

模型部署的工具其实不少，Ollama、llama.cpp、TGI、SGLang、vLLM各有各的适用场景。Ollama胜在简单，一条命令就能跑，但它的定位偏向个人本地体验，并发能力弱，不适合对外提供服务。llama.cpp主打CPU和量化，在没有显卡的机器上也能跑，但速度嘛，只能说是“能出字”。

vLLM的核心竞争力在于它的PagedAttention技术。传统的推理框架在处理注意力机制的KV缓存时，会预留一大块连续显存，造成大量浪费。vLLM借鉴了操作系统虚拟内存分页的思路，把KV缓存切成固定大小的块，按需分配，显存利用率能提升好几倍。带来的直接好处就是：同样的显卡，vLLM能塞下更大的模型，或者支持更高的并发。

另外vLLM对OpenAI API格式的兼容做得非常好。你部署完之后，客户端代码几乎不用改，把base_url指向你自己的服务地址就能跑。这对已经有基于OpenAI接口开发的应用来说，迁移成本几乎为零。

1.4 DeepSeek-R1为什么值得部署

DeepSeek-R1是推理能力很强的开源模型，尤其在数学、代码、逻辑推理这类任务上表现突出。它的蒸馏版本覆盖了从1.5B到70B的多个尺寸，小尺寸的版本在消费级显卡上就能跑，大尺寸的则需要多卡或者大显存的专业卡。

选择在AutoDL上部署DeepSeek-R1，一个很现实的理由是：你可以根据手头的预算灵活选择模型尺寸。预算少就租一张24G显存的卡跑7B或14B的蒸馏版，预算充足就上多卡跑32B甚至70B。这种弹性是本地买卡很难做到的。

提示：DeepSeek-R1的完整版参数量非常大，个人部署基本不现实。实际落地时选蒸馏版（Distill）就够了，7B和14B的版本在推理任务上的表现已经相当能打。

2. 部署前的准备工作与关键决策

2.1 显卡选型与显存估算

选卡是整个部署流程里最关键的一步，选错了要么跑不起来，要么花冤枉钱。核心指标就一个：显存。模型能不能加载、能加载多大的、能支持多少并发，全看显存够不够。

先给一个粗略的估算公式。模型加载所需的显存，大致等于参数量乘以每个参数的字节数。如果用FP16精度，每个参数占2字节；如果用INT8量化，占1字节；INT4量化则占0.5字节。但实际占用会比这个理论值高，因为还要算上KV缓存、激活值、框架本身的开销。

我整理了一张常用模型尺寸和显存需求的对照表，方便你快速判断：

这张表里的数字是“能加载起来”的底线，实际部署时建议留出20%到30%的余量，否则并发一上来就容易OOM。比如7B模型FP16需要16GB，那用24GB的卡就比较稳妥，用16GB的卡就非常紧张。

AutoDL上常见的卡有RTX 3090（24G）、RTX 4090（24G）、A100（40G/80G）、L20（48G）等。个人测试的话，3090和4090性价比最高，24G显存跑7B的FP16或者14B的INT8都没问题。如果要跑32B以上，就得上A100或者多卡了。

2.2 镜像选择：省下半天配环境的时间

AutoDL创建实例时需要选一个基础镜像。这一步选对了，后面能省掉大量折腾。平台提供的镜像大致分几类：纯系统镜像（只有Ubuntu）、框架镜像（预装PyTorch/TensorFlow）、社区镜像（其他用户分享的定制镜像）。

部署vLLM的话，我建议直接选预装了PyTorch和CUDA的框架镜像，比如PyTorch 2.1以上版本、CUDA 12.1以上的组合。vLLM对PyTorch和CUDA版本有一定要求，版本太低会装不上或者跑不起来。

如果你想更省事，可以在社区镜像里搜“vLLM”，看看有没有人已经做好了带vLLM的环境。但要注意，社区镜像的质量参差不齐，用之前最好看看更新时间和使用评价。我个人的习惯是用官方框架镜像自己装vLLM，这样环境干净可控，出了问题也好排查。

注意：选镜像时一定要看清楚CUDA版本。vLLM较新的版本通常要求CUDA 12.1及以上，如果镜像里是CUDA 11.x，装vLLM时可能会编译失败或者运行报错。

2.3 数据盘规划与模型下载策略

AutoDL的实例分系统盘和数据盘。系统盘容量小，一般就几十GB，装完系统和依赖就差不多了。数据盘可以额外购买，用来放模型权重、数据集这些大文件。模型动辄几十GB，肯定要放数据盘。

这里有个非常实用的技巧：先用无卡模式开机，把模型下载好，再关机切换到有卡模式。无卡模式下GPU不計费，只有CPU和内存的资源费用，价格便宜很多。下载一个几十GB的模型可能要半小时到一小时，用无卡模式能省下不少钱。

模型下载的渠道，国内的话推荐用ModelScope（魔搭社区），速度比HuggingFace快很多，而且不需要额外配置。DeepSeek-R1的蒸馏版在ModelScope上都有，直接搜模型名字就能找到。下载方式可以用git lfs，也可以用modelscope提供的命令行工具。

# 安装modelscope pip install modelscope # 下载模型到指定目录 modelscope download --model deepseek-ai/DeepSeek-R1-Distill-Qwen-7B --local_dir /root/autodl-tmp/models/DeepSeek-R1-Distill-Qwen-7B

/root/autodl-tmp是AutoDL数据盘的默认挂载路径，把模型放这里就对了。下载完成后可以用du -sh命令确认一下文件大小，确保下载完整。

2.4 网络与端口配置的提前规划

vLLM部署起来之后，默认会在某个端口上起一个HTTP服务（通常是8000）。你要从本地访问这个服务，就需要处理网络连通性的问题。AutoDL提供了几种方式：SSH隧道、自定义服务端口映射等。

最稳妥的方式是用SSH隧道。AutoDL的实例详情页会给你SSH登录命令和端口号，你在本地终端执行类似这样的命令：

ssh -L 8000:localhost:8000 -p 12345 root@connect.xxx.autodl.com

这条命令的意思是：把本地的8000端口转发到远程服务器的8000端口。执行后保持这个SSH连接不断，然后在本地浏览器或代码里访问http://localhost:8000，就相当于访问远程的vLLM服务了。

AutoDL也提供了“自定义服务”功能，可以在控制台把实例的某个端口映射到一个公网地址。这种方式更方便，不需要保持SSH连接，但要注意公网地址的访问权限设置，别把自己的模型服务暴露给无关的人。

3. vLLM环境搭建与模型加载实操

3.1 创建实例与首次开机

登录AutoDL控制台，点“租用新实例”，然后按下面的步骤操作。首先是选地区，不同地区的机器型号和价格略有差异，选一个有你想要的显卡型号的地区就行。然后是选显卡，根据前面算好的显存需求来选，个人测试推荐RTX 4090或者A100 40G。

选完卡之后是选镜像。在“基础镜像”里找到PyTorch分类，选一个版本较新的，比如PyTorch 2.1.0、Python 3.10、CUDA 12.1的组合。然后配置数据盘，建议至少买50GB，如果模型多的话买100GB以上。系统盘一般默认就行。

确认配置和价格后点创建，等待一两分钟实例就开好了。开好之后先别急着切有卡模式，用无卡模式先连上去把环境配好、模型下好。

3.2 安装vLLM与依赖处理

连上实例之后，第一件事是确认Python和CUDA版本：

python --version nvcc --version

然后安装vLLM。最直接的方式是用pip：

pip install vllm

但这里有个坑：vLLM的依赖比较多，pip安装时可能会自动升级或降级一些包，导致和镜像里预装的PyTorch版本冲突。如果装完之后import报错，大概率是版本冲突了。解决办法是先看清楚vLLM要求的PyTorch版本，然后手动指定版本安装：

pip install vllm --no-deps pip install torch==2.1.0 transformers>=4.38.0

--no-deps的意思是只装vLLM本身，不自动装依赖，然后你手动把关键依赖装上。这样能避免pip乱动你已有的环境。

如果安装过程中遇到编译错误，通常是缺少一些系统库。可以装一下：

apt-get update apt-get install -y build-essential cmake

装完之后验证一下：

python -c "import vllm; print(vllm.__version__)"

能打印出版本号就说明装好了。

3.3 用命令行快速起一个服务

vLLM提供了一个命令行工具，可以一行命令把模型服务跑起来。最基本的用法是这样：

python -m vllm.entrypoints.openai.api_server \ --model /root/autodl-tmp/models/DeepSeek-R1-Distill-Qwen-7B \ --served-model-name deepseek-r1-7b \ --host 0.0.0.0 \ --port 8000 \ --dtype auto \ --max-model-len 8192 \ --gpu-memory-utilization 0.9

逐个解释一下这些参数。--model指定模型路径，可以是本地路径也可以是HuggingFace上的模型名。--served-model-name是服务对外暴露的模型名称，客户端调用时用这个名字。--host 0.0.0.0让服务监听所有网卡，这样外部才能访问。--port是端口号。

--dtype auto让vLLM自动选择精度，有显卡的话一般会用FP16。--max-model-len是最大上下文长度，这个值直接影响KV缓存的显存占用，设得越大占显存越多。7B模型在24G卡上设8192比较稳妥，设太大容易OOM。--gpu-memory-utilization 0.9表示允许vLLM使用90%的显存，留10%给系统和其他进程。

启动过程中会打印一堆日志，看到类似Uvicorn running on http://0.0.0.0:8000的字样就说明服务起来了。第一次启动会花一些时间加载模型权重，7B的模型大概需要一两分钟。

3.4 多卡部署与张量并行配置

如果模型比较大，单卡放不下，就需要用多卡。vLLM支持张量并行（Tensor Parallelism），可以把一个模型拆到多张卡上。加一个--tensor-parallel-size参数就行：

python -m vllm.entrypoints.openai.api_server \ --model /root/autodl-tmp/models/DeepSeek-R1-Distill-Qwen-32B \ --served-model-name deepseek-r1-32b \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 2 \ --dtype auto \ --max-model-len 4096 \ --gpu-memory-utilization 0.9

--tensor-parallel-size 2表示用两张卡。注意这个值要能整除模型的注意力头数，否则会报错。一般2、4、8这些2的幂次是比较安全的选择。

多卡部署时有个细节要注意：AutoDL的多卡实例，卡之间的通信走的是PCIe还是NVLink，对性能影响挺大的。NVLink的带宽比PCIe高很多，张量并行的效率也更高。如果对速度有要求，选实例时留意一下卡的互联方式。

提示：张量并行不是越多越好。卡越多，卡之间的通信开销越大，有时候两张卡的效率反而不如一张大显存的卡。能用单卡解决就尽量单卡。

4. 服务验证与客户端调用

4.1 用curl做第一轮连通性测试

服务起来之后，先用最简单的curl命令测一下能不能通。vLLM兼容OpenAI的接口格式，所以可以直接调/v1/chat/completions：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-r1-7b", "messages": [ {"role": "user", "content": "用一句话解释什么是递归"} ], "temperature": 0.6, "max_tokens": 256 }'

如果返回了一段JSON，里面有模型生成的文本，说明服务是正常的。如果返回连接拒绝，检查一下服务是不是还在启动中，或者端口是不是被占用了。如果返回模型不存在的错误，检查--served-model-name和请求里的model字段是否一致。

DeepSeek-R1这类推理模型有个特点，它会在正式回答前先输出一段思考过程（用<think>标签包起来）。这是正常的，说明模型的推理链路在起作用。如果你不想要这段思考过程，可以在客户端做后处理把它过滤掉。

4.2 Python客户端调用示例

实际开发中更多是用Python代码调用。因为vLLM兼容OpenAI接口，直接用openai这个库就行：

from openai import OpenAI client = OpenAI( base_url="http://localhost:8000/v1", api_key="token-abc123" # vLLM默认不校验，随便填一个 ) response = client.chat.completions.create( model="deepseek-r1-7b", messages=[ {"role": "system", "content": "你是一个严谨的助手，回答要简洁准确。"}, {"role": "user", "content": "写一个Python函数，判断一个数是否为质数"} ], temperature=0.6, max_tokens=1024 ) print(response.choices[0].message.content)

api_key这里随便填一个就行，vLLM默认不做鉴权。但如果你把服务暴露到公网，强烈建议加上鉴权，否则任何人都能白嫖你的算力。vLLM支持通过--api-key参数设置密钥：

python -m vllm.entrypoints.openai.api_server \ --model /root/autodl-tmp/models/DeepSeek-R1-Distill-Qwen-7B \ --api-key your-secret-key \ ...

设置之后，客户端调用时就要带上正确的key了。

4.3 流式输出与参数调优

对话场景下，流式输出（streaming）体验会好很多，用户不用等整段生成完才看到内容。vLLM是支持流式的，客户端加一个stream=True就行：

stream = client.chat.completions.create( model="deepseek-r1-7b", messages=[{"role": "user", "content": "介绍一下杭州"}], stream=True ) for chunk in stream: if chunk.choices[0].delta.content: print(chunk.choices[0].delta.content, end="", flush=True)

关于参数调优，有几个值值得关注。temperature控制随机性，推理任务建议设低一点（0.3到0.6），创意写作可以设高一点（0.8到1.0）。top_p是核采样，一般设0.9到0.95。max_tokens限制生成的最大长度，设太小会导致回答被截断，设太大则浪费显存和时间。

还有一个vLLM特有的参数--max-num-seqs，控制同时处理的最大请求数。默认值通常够用，但如果你的并发很高，可以适当调大。不过调大之后每个请求分到的显存就少了，可能影响长文本的生成。

5. 性能调优与成本控制

5.1 显存不够时的量化方案

显存不够是最常见的问题。24G的卡跑7B的FP16刚好够，但想跑14B就得上量化了。vLLM支持AWQ和GPTQ两种量化格式，需要模型本身有对应的量化版本。DeepSeek-R1的蒸馏版在ModelScope上能找到AWQ量化的版本。

用AWQ量化模型时，启动命令加一个--quantization awq：

python -m vllm.entrypoints.openai.api_server \ --model /root/autodl-tmp/models/DeepSeek-R1-Distill-Qwen-14B-AWQ \ --quantization awq \ --dtype float16 \ ...

量化之后显存占用能降到FP16的一半左右，代价是精度有轻微损失。实测下来，INT4量化在推理任务上的表现下降不明显，日常使用完全够用。

如果连量化版本都跑不动，那就只能换更小的模型，或者租更大显存的卡。这里没有太多取巧的空间，显存是硬约束。

5.2 并发能力与吞吐量优化

vLLM的强项就是高并发。它的PagedAttention和连续批处理（continuous batching）机制，能让多个请求共享计算资源，吞吐量比朴素实现高很多。但并发能力也受显存限制，因为每个并发请求都要占一份KV缓存。

想提升并发，有几个方向。一是降低--max-model-len，上下文短了，每个请求的KV缓存就小，能同时处理的请求就多。二是用量化模型，省下来的显存可以分给更多并发。三是调大--gpu-memory-utilization，但别超过0.95，否则容易OOM。

可以用vLLM自带的benchmark工具测一下吞吐量：

python -m vllm.entrypoints.benchmark_throughput \ --model /root/autodl-tmp/models/DeepSeek-R1-Distill-Qwen-7B \ --num-prompts 100

这个命令会跑100个请求，然后报告每秒能处理多少个token。根据结果再决定要不要调整参数。

5.3 按小时计费下的省钱技巧

AutoDL是按小时计费的，用得好能省不少钱。几个实用的技巧：

第一，无卡模式传数据。前面提过，下载模型、装环境这些不需要GPU的操作，都在无卡模式下做。无卡模式每小时可能就几毛钱，有卡模式一小时几块到几十块，差距很大。

第二，用完就关机。AutoDL的实例关机后不计GPU费用，只收数据盘的存储费。测试完就关机，下次用再开，别让它一直跑着。

第三，选对计费方式。AutoDL有按量和包周包月两种，短期测试用按量，长期稳定用包月更划算。

第四，数据盘复用。模型下到数据盘里，释放实例时选择保留数据盘，下次开新实例直接挂载，不用重新下载。

注意：释放实例时一定要看清楚“是否保留数据盘”的选项。选错了数据盘会被一起删掉，几十GB的模型就白下了。

6. 常见问题排查与避坑实录

6.1 启动报错速查表

部署过程中会遇到各种报错，我把常见的整理成一张表，方便对照排查：

这张表覆盖了八成以上的常见问题。遇到报错先查表，查不到再看日志。vLLM的日志信息比较详细，报错位置和原因通常都能看出来。

6.2 模型下载中断与文件校验

模型下载是个耗时操作，网络波动导致中断很常见。用git lfs下载时，中断后重新执行命令会续传，但有时候会卡住。这时候可以删掉.git目录重新下，或者换用modelscope的命令行工具。

下载完成后一定要校验文件完整性。最简单的方法是看文件大小，和模型主页上标注的大小对比。如果差得比较多，说明没下完。也可以用git lfs ls-files查看lfs文件的状态。

还有一种情况是下载完了但加载时报错，提示某个文件找不到或格式不对。这通常是下载过程中文件损坏了。解决办法是删掉那个文件重新下，或者整个模型重新下。

6.3 服务运行中的稳定性问题

服务跑起来之后，可能会遇到一些运行时的稳定性问题。比如跑了一段时间后响应变慢，或者突然OOM崩溃。

响应变慢通常是显存碎片化导致的。vLLM虽然有PagedAttention，但长时间运行后还是可能产生碎片。解决办法是定期重启服务，或者调低--gpu-memory-utilization留更多余量。

突然OOM则可能是某个请求的上下文特别长，超出了预留的KV缓存空间。可以在启动时把--max-model-len设小一点，或者在客户端限制输入长度。另外--max-num-seqs设太大也会导致OOM，因为同时处理的请求太多，KV缓存不够分。

如果服务频繁崩溃，建议把日志级别调高，看看具体是什么原因：

python -m vllm.entrypoints.openai.api_server \ --model ... \ --disable-log-requests \ ...

--disable-log-requests会关掉每个请求的日志，减少日志量。排查问题时可以反过来，把日志开得更详细。

6.4 我踩过的几个坑

说几个我自己实际踩过的坑，都是文档里不会写的。

第一个坑是镜像里的Python版本和vLLM不兼容。有次选了个Python 3.8的镜像，装vLLM时提示需要3.9以上。换镜像重来，浪费了半小时。所以选镜像时一定要看清楚Python版本，3.10是比较稳妥的选择。

第二个坑是数据盘路径搞错。AutoDL的数据盘挂载在/root/autodl-tmp，但我有次把模型下到了/root下面，结果系统盘爆了，实例直接卡死。模型一定要放数据盘，系统盘只放代码和配置。

第三个坑是SSH隧道断了没发现。用SSH隧道访问服务时，如果网络波动导致SSH断开，本地就访问不了远程服务了。后来改用AutoDL的自定义服务端口映射，稳定多了。但自定义服务要注意设置访问密码，别裸奔。

第四个坑是忘了关实例。有次测试完忘了关机，第二天一看账单，跑了一整晚。虽然钱不多，但也是教训。现在养成了习惯，测试完立刻关机，需要长期跑的就设个提醒。

7. 从部署到应用：下一步可以做什么

7.1 接入自己的应用

服务部署好之后，接入自己的应用其实很简单。因为接口是OpenAI兼容的，任何支持自定义base_url的客户端都能接。比如用LangChain的话：

from langchain_openai import ChatOpenAI llm = ChatOpenAI( base_url="http://localhost:8000/v1", api_key="token-abc123", model="deepseek-r1-7b" ) result = llm.invoke("帮我写一个快速排序的Python实现") print(result.content)

如果是做RAG应用，可以把vLLM作为生成模型，配合向量数据库做检索增强。DeepSeek-R1的推理能力在RAG场景下很有优势，尤其是需要多步推理的问题。

7.2 多模型共存与切换

有时候一个项目需要用到多个模型，比如一个通用对话模型加一个代码专用模型。vLLM支持在一个服务里加载多个模型吗？答案是部分支持。较新版本的vLLM支持通过--model参数指定多个模型，但显存占用会叠加，对显卡要求比较高。

更实际的做法是起多个vLLM服务，每个服务监听不同端口，客户端根据任务类型路由到不同的服务。这样每个服务可以独立配置参数，互不影响。缺点是显存要分给多个服务，单卡的显存可能不够。

如果显存有限，可以考虑用LoRA适配器的方式。vLLM支持在基础模型上动态加载LoRA，这样只需要加载一份基础模型权重，不同的LoRA适配器切换使用。这对需要多个微调版本的场景很实用。

7.3 监控与日志

服务跑起来之后，最好加一些监控，方便了解运行状态。vLLM暴露了Prometheus格式的metrics接口，可以用Prometheus加Grafana做可视化监控。关注几个关键指标：请求数、token吞吐量、显存使用率、请求延迟。

如果不想搞那么复杂，至少把日志收集起来。vLLM的日志会记录每个请求的处理情况，出问题时可以回溯。日志量大的话，可以配置日志轮转，避免把磁盘写满。

AutoDL的控制台也能看到实例的GPU使用率、显存占用这些基础指标，日常巡检够用了。但要做精细化的性能分析，还是得自己搭监控。

7.4 安全加固建议

最后说几个安全方面的建议。如果服务只在本地用，通过SSH隧道访问，安全性基本没问题。但如果要把服务暴露到公网，就需要注意几点。

第一，一定要设API key。vLLM的--api-key参数可以设置访问密钥，客户端调用时必须带上。不设的话任何人都能调用你的服务。

第二，限制访问来源。如果知道调用方的IP，可以在防火墙层面做限制。AutoDL的自定义服务功能支持设置访问白名单。

第三，控制请求频率。防止有人恶意刷请求把你的算力跑满。可以在vLLM前面加一层反向代理（比如Nginx），做限流和鉴权。

第四，定期更新vLLM版本。新版本会修复一些安全漏洞，也会优化性能。但更新前先在测试环境验证，别直接在生产环境升级。

这套AutoDL加vLLM的组合，我从去年开始用到现在，跑了七八个不同的模型，整体稳定性还是不错的。最大的感受是：部署大模型这件事，门槛已经比一年前低太多了。以前要折腾好几天的环境配置，现在一两个小时就能搞定。真正花时间的反而是模型选型、参数调优这些需要经验积累的部分。希望这篇内容能帮你少走一些弯路，把时间花在更有价值的事情上。