尧图网页设计 
你有没有遇到过这种情况在 Ollama 里跑一个 7B 模型单条对话响应飞快可一旦开并发做评测、或者想架个服务给团队用速度立刻掉到没法看我去年做内部私有化部署时也卡在这一步后来换到 vLLM同一个模型、同一张 3090吞吐直接翻了差不多十倍。vLLM 是目前最主流的开源大模型推理加速引擎它的核心价值就一句话把你手上的 GPU 显存榨干同时把并发吞吐拉满。无论是部署 DeepSeek 蒸馏版、Qwen 系列开源模型还是给 RAG 应用、Agent 后端做 OpenAI 兼容服务它都是绕不开的第一选项。但这东西也是出了名的能装起来容易调好很难——版本、CUDA、显存利用率、KV Cache 这些概念新手第一次接触很容易在启动阶段就被一堆报错劝退。这篇文章我就把安装、启动、显存调优这条路完整走一遍包括我真实踩过的坑和验证过有效的参数模板你照着操作就能从 0 跑到一个能对外提供服务的实例。1. vLLM 的定位它到底比 Ollama、LM Studio 强在哪先别急着装搞清楚一个问题本地跑模型明明有 Ollama、LM Studio 这种开箱即用的工具为什么还要折腾 vLLM我见过太多人装完 Ollama 用得挺好一上 vLLM 就各种报错最后得出结论vLLM 就是个坑。其实不是 vLLM 坑是这两个东西的定位压根不一样。1.1 PagedAttention 与 Continuous Batching 带来的吞吐量差异Ollama 底层用的是 llama.cpp它的优化思路是把单用户交互做到极致显存占用小、启动快、CPU 也能跑。但它在调度层面有个硬伤——它处理一批请求时一个 batch 里的请求要等全部生成完才能释放槽位新请求只能排队。这就像一家只能翻桌不能拼桌的快餐厅人一多必然堵门口。vLLM 解决这个问题靠的是两板斧。第一板斧是 PagedAttention。大模型推理时会把历史 token 的 Key 和 Value 缓存下来这个缓存叫 KV Cache。传统方案给每条请求分配一整块连续显存但实际生成过程中缓存是逐步增长的于是大量显存被预留着却用不上碎片化严重。vLLM 把 KV Cache 切成固定大小的 block默认 16 个 token 一块像操作系统管理内存页一样按需分配、随时回收显存利用率从 40%-60% 直接拉到 90% 以上。它最大的优势是可以多个序列共享同一个物理 block这在做并行采样的时候特别明显。第二板斧是 Continuous Batching也就是连续动态批处理。vLLM 在每个推理 iteration 都会重新检查队列有新请求进来就插队有请求生成完了就立刻腾出槽位给下一条而不是等整批结束。效果就像快餐厅改成流水线出餐吞吐自然就上来了。我实测同一个 Qwen2.5-7B 模型在单张 3090 上Ollama 的并发吞吐大概在 800-1200 token/s 这个区间换成 vLLM 单并发差不太多但 8 并发下能到 4000 token/s延迟还更稳定。这还没算 PagedAttention 对显存的节省。1.2 什么场景才值得上 vLLM我自己总结了一个很粗暴的决策标准你只是本地聊天、代码补全、一个人玩请继续用 Ollama 或 LM Studio省心是第一位你要开 API 服务给多个用户、跑评测脚本、做 Agent 并发调度、搞 RAG 批量文档处理或者用到长上下文vLLM 是效率上限最高的选择你要部署 DeepSeek 蒸馏版、Qwen2.5/3 这类热门开源模型vLLM 的社区适配是最快的新架构发布后通常第一批支持另外注意一点vLLM 的吞吐优势是并发越大越明显。如果你只是单请求、单并发它和 llama.cpp 的差距很小甚至因为 CUDA Graph 初始化慢首 token 延迟还略高。所以别拿单条对话的响应速度来评判 vLLM那不是它的主场。2. 安装前的关键决策环境矩阵与三条安装路径vLLM 的安装本身不难难的是环境匹配。我见过太多人直接在服务器上 pip install结果装完一跑就报 CUDA error、No kernel image 之类的错最后全盘重来。以下这些前置决策你提前想清楚能省一整天。2.1 Python、CUDA、GPU 驱动的最低门槛先说系统vLLM 官方对 Linux 支持最完善Windows 属于社区维护的能用但不保证状态。如果你在 Windows 上我建议直接用 WSL2 或者 Docker后面的踩坑章节会细说。然后是软件版本我把核心要求整理成了这张表项目最低要求我的建议Python3.9 - 3.123.10 或 3.11 最稳别用 3.13 以下的太新版本CUDA12.112.4 / 12.6 均可50 系显卡看 2.3 节NVIDIA 驱动525用 nvidia-smi 先确认驱动版本对应 CUDA 版本GPU显存 8GB 起跑 7B 模型建议 24GB追求体验就上 48GB 以上这里的核心逻辑是vLLM 的 wheel 包是绑定 CUDA 版本编译的你的 CUDA 环境如果跟 wheel 不匹配装完大概率跑不起来。所以在安装之前先把显卡驱动升级到位再确认 nvidia-smi 显示的 CUDA Version 在 12.1 以上。2.2 pip、Docker、源码编译三条路怎么选pip 安装是最快的路径适合绝大多数人python -m venv vllm-env source vllm-env/bin/activate pip install vllm为什么一定要用虚拟环境因为 vLLM 会依赖特定版本的 torch、transformers如果和你的全局环境里其他项目冲突会出现各种诡异的报错。我见过有人在 conda 根环境里装 vLLM结果把 torch 版本干回旧版其他项目全部崩溃。装完验证一下python -c import vllm; print(vllm.__version__)能打印出版本号基本就过了大半。Docker 路线适合两种情况一是你不想动宿主机环境想隔离得干干净净二是你需要特定版本的镜像配合特定 CUDA。官方镜像用法docker pull vllm/vllm-openai:latest docker run --runtime nvidia --gpus all \ -p 8000:8000 \ -v ~/.cache/huggingface:/root/.cache/huggingface \ vllm/vllm-openai:latest \ --model Qwen/Qwen2.5-7B-Instruct \ --gpu-memory-utilization 0.85这里有个容易忽略的细节挂载~/.cache/huggingface到容器里模型权重才不用重复下载。我第一次用 Docker 跑的时候忘了这步启动日志一直在走下载流程还以为卡住了。源码编译则只推荐给要改算子、做二次开发、或者需要特定 FlashAttention 版本配合的人。编译 vLLM 依赖 CUDA toolkit、ninja、gcc一份工作量大几十倍不止产出还未必比预编译包快。普通用户真没必要走这条路。2.3 CUDA 12.8 与 RTX 50 系显卡的特殊处理这一节专门写给用 RTX 50 系或者 CUDA 12.8 环境的人。网上搜索热词里频繁出现cuda128 vllm原因很简单RTX 50 系Blackwell 架构算力代号 sm_120需要 CUDA 12.8 以上才能发挥完整算力但很多 pip wheel 默认是基于 CUDA 12.4/12.6 编译的装在 12.8 环境里可能直接报no kernel image is available。我的处理办法是先看自己的 CUDA 版本再决定用哪种 wheel。vLLM 新版本会同步发布 cu128 对应的构建产物具体安装方式以官方 release notes 为准。如果你用的是 50 系卡装之前搜一下vllm cu128相关的官方说明别盲目 pip install latest。装好之后跑一下python -c import torch; print(torch.version.cuda)确认 torch 内部的 CUDA 版本跟你系统环境一致。这一步比什么都管用很多装好了但跑不了的坑都是 torch 和系统 CUDA 版本对不上导致的。3. 启动模型全流程serve 命令参数逐项拆解环境弄好之后最激动人心的时刻来了把模型真正跑起来。这里我强烈建议第一次跑就用vllm serve因为它把整个服务端封装好了你不需要自己写代码就能拿到一个 OpenAI 兼容接口前端、测试工具可以直接对接。3.1 最小启动命令与启动日志解读拿 Qwen2.5-7B-Instruct 举例最小可用命令长这样vllm serve Qwen/Qwen2.5-7B-Instruct \ --port 8000 \ --host 0.0.0.0 \ --gpu-memory-utilization 0.85 \ --max-model-len 8192--host 0.0.0.0是为了让局域网内其他机器也能访问如果你只在本机测试可以省略默认 127.0.0.1。--port 8000是默认端口改也行。第一次启动会先下载模型权重这个过程取决于网速和模型大小7B 模型大概 15GB。下载完会看到一段 memory profiling 日志大概长这样INFO: Memory profiling results: total_gpu_memory23.6GiB, used_gpu_memory14.1GiB, kv_cache_size9.2GiB这行日志特别关键它告诉你总共 24GB 显存、模型权重占 14GB、拿出来给 KV Cache 的是 9GB。如果这里显示 kv_cache_size 特别小说明你的--gpu-memory-utilization设置太保守或者显存被其他进程占了。启动成功的标志是日志出现Uvicorn running on http://0.0.0.0:8000这一行后面跟Application startup complete.。看到这两行你的服务就算真正起来了。3.2 用 OpenAI 兼容接口验证服务是否正常服务起来了用三个请求验证# 1. 查看模型列表 curl http://localhost:8000/v1/models # 2. 基础对话 curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: Qwen/Qwen2.5-7B-Instruct, messages: [{role: user, content: 用一句话介绍你自己}], max_tokens: 256 }/v1/models如果返回模型 ID说明服务活着/v1/chat/completions能返回内容说明推理链路正常。这里注意model字段必须跟启动时的模型名完全一致很多人在这卡半天其实只是名字拼错了。如果你用 Python 调用直接上 openai SDKfrom openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY, # vLLM 默认不校验 key随便填 ) resp client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct, messages[{role: user, content: 你好}], max_tokens128, ) print(resp.choices[0].message.content)这套接口跟 OpenAI 完全兼容意味着你之前写好的 LLM 调用代码只要把 base_url 改一下就能切到本地 vLLM 服务改动量趋近于零。3.3 不开网络服务直接用 Python API 做离线推理不是所有场景都要开 HTTP 服务。跑批量评测、处理离线文本、做脚本实验时直接走 Python API 更省事from vllm import LLM, SamplingParams llm LLM( modelQwen/Qwen2.5-7B-Instruct, gpu_memory_utilization0.85, max_model_len8192, ) params SamplingParams( temperature0.7, top_p0.8, max_tokens512, ) prompts [写一段关于秋天的散文, 解释一下什么是 KV Cache] outputs llm.generate(prompts, params) for output in outputs: print(output.outputs[0].text)这个方式的优势是没有网络开销适合大批量处理。注意sampling_params是每次调用单独设置的而不是在LLM()里设置新手容易搞混。LLM()管理的是模型加载和显存分配真正的生成参数全在SamplingParams里。4. 显存调优的核心原理显存到底花在哪了当你跑通了基本流程紧接着就会碰到最核心的问题显存怎么调。调优之前必须先搞清楚一件事——你的显存被谁吃掉了。我见过太多人一遇到 OOM 就无脑调低--gpu-memory-utilization结果模型反而跑不动了因为他们根本不理解这个参数控制的是什么。4.1 显存的四笔开销权重、KV Cache、激活值与临时缓冲一次推理中显存主要有四个去向。第一是模型权重。权重大小 参数量 × 每个参数占的字节数。7B 模型用 FP162 字节就是7 × 2 14GB13B 是 26GB。这是固定开销模型一加载就占住了除非换量化版本否则省不掉。第二是 KV Cache这是 vLLM 里最需要理解的部分。它的计算公式是每 token 的 KV Cache 大小 2 × 层数 × KV 头数 × head_dim × 精度字节数我拿 7B 规模的老架构模型举例MHA 注意力32 层、32 头、head_dim 128、FP162 × 32 × 32 × 128 × 2 524,288 字节 ≈ 512KB/token这意味着单条请求跑 4096 上下文的对话光 KV Cache 就要吃掉 2GB。而新一代 GQA 架构模型比如 Qwen2.5-7B28 层、4 个 KV 头明显更省2 × 28 × 4 × 128 × 2 57,344 字节 ≈ 56KB/token同样 4096 上下文只要 224MB。这就是为什么新模型在长上下文场景下显存压力小很多。所以网上那些7B 模型 16GB 显存就能跑的说法实际要打个问号——那只是权重加上 KV Cache 和上下文24GB 显卡才算是舒服起步线。第三是激活值就是每一层前向计算时的中间张量。vLLM 用 CUDA Graph 优化后这部分开销被压得很低但--enforce-eager模式下会明显增大。第四是 CUDA context 和 torch 的缓存分配器碎片这部分一般在 500MB 到 1GB 之间属于系统性开销。4.2 gpu-memory-utilization 到底在控制什么--gpu-memory-utilization的默认值是 0.9意思是vLLM 启动时会做一次内存探针算出当前 GPU 空闲显存然后最多允许 vLLM 占用其中的 90%。模型权重先扣掉剩下的全部用于 KV Cache 预分配。所以这个参数其实是个总预算不是KV Cache 占比。它的关键行为是调高它KV Cache 可用空间变大意味着能支持更长的上下文和更多的并发序列调低它KV Cache 变小但给其他进程留了空间GPU 上可以同时跑别的任务我在 24GB 的 4090 上跑 7B 模型的经验是权重 14GB系统开销 1GB 左右剩下 9GB 给 KV Cache。9GB 除以 56KB/tokenQwen 架构约等于 16 万个 token 的缓存空间但这个空间还要按max_num_seqs并发切分。所以真正限制你的往往不是模型大小而是你能开多长的上下文和多大的并发。4.3 max-model-len 与 max-num-seqs 的联动关系启动日志里有个容易被忽略的关键参数--max-model-len。它默认从模型配置里读但很多时候模型配置的 max_position_embeddings 很大比如 32K、128K如果显存不够vLLM 启动时会直接报错让你手动指定更小的值。它的本质是vLLM 会按照max_model_len × max_num_seqs一次性预分配最大 KV Cache 空间。所以 KV Cache 的天花板是KV Cache 总上限 每 token KV 大小 × max_model_len × max_num_seqs举个例子Qwen2.5-7B 每 token 56KBmax_model_len8192、max_num_seqs32时KV 上限 56KB × 8192 × 32 14GB。这已经逼近 24GB 卡上权重之外的全部余量了。所以你会看到这样的权衡参数调大效果调小效果max-model-len支持长文档/长对话KV 空间缩小短任务够用max-num-seqs并发吞吐更高同时处理的请求变少二者乘积决定了 KV Cache 峰值峰值越低越不易 OOM实用口诀短任务就把 max-model-len 压到需要的长度即可比如只想跑代码补全设为 4096 完全够做长文档分析再放长。千万别无脑拉满那是在糟蹋显存。5. 一套可复现的调优流程从 OOM 到稳定服务理论讲完给一套可以直接抄的操作路径。我的调优方法论只有三步先跑起来、再压测、最后做针对性优化。顺序不能乱跳过压测直接堆参数一定会踩坑。5.1 第一步先跑起来用安全配置模板一个 24GB 显存 7B 模型的新环境我建议直接用这套保守配置起手vllm serve Qwen/Qwen2.5-7B-Instruct \ --gpu-memory-utilization 0.85 \ --max-model-len 8192 \ --max-num-seqs 32 \ --dtype bfloat16解释几个选择。--dtype bfloat16比 FP16 在 30 系以上显卡上更稳不容易溢出而且 vLLM 对 BF16 的 kernel 优化已经很成熟。--max-num-seqs 32是为了把并发先压住等确认显存充裕再往上加。--gpu-memory-utilization 0.85是给 CUDA context 和系统开销留了安全边际。如果 7B 都 OOM要么你的卡不是 24GB 级要么环境里有别的进程占显存。先用nvidia-smi看清楚空余显卡再启动别急着怀疑参数。等到模型启动后运行状态稳定再做下一步。5.2 第二步压测找天花板而不是拍脑袋调参很多人调显存全靠感觉这是最大的坑。vLLM 仓库自带压测脚本叫benchmark_serving.py用法大致是python benchmark_serving.py \ --model Qwen/Qwen2.5-7B-Instruct \ --endpoint /v1/chat/completions \ --num-prompts 200 \ --concurrency 8 \ --max-tokens 512它会输出几个关键指标TTFT首 token 延迟、TPOT每个输出 token 的延迟、总吞吐。同时开着nvidia-smi -l 1盯着显存变化。如果压测跑完显存一直都在安全线上就逐步把--max-num-seqs加一倍再测一旦接近 OOM 的临界点你会看到显存值顶到 utilization 上限附近此时再压回去一档。这个逐级探测的过程比任何理论估算都靠谱因为每台机器的显存碎片情况不一样。压测时注意区分两个指标吞吐量和延迟。vLLM 的典型特征是吞吐很高但单请求延迟未必最低。如果业务对延迟敏感你可能反而要限制max-num-seqs让每个请求跑得更快。这是很多新手没意识到的反直觉点。5.3 第三步针对瓶颈上进阶手段压测发现瓶颈在哪里再对症下药通常有几个方向第一是权重量化。如果 7B 的 14GB 权重让你的 KV Cache 空间很小可以考虑 AWQ 或 GPTQ 量化版。比如Qwen/Qwen2.5-7B-Instruct-AWQ4bit 权重直接把 14GB 砍到 4GB 左右权重省下来的 10GB 全给 KV Cache 和并发。代价是生成质量轻微下降、部分场景速度略慢。我用 AWQ 做过 A/B 对比质量差异在评测集上通常不到 1 个点但吞吐和并发上限提升明显。第二是--kv-cache-dtype fp8。把 KV Cache 从 FP16 压成 FP8KV 空间直接翻倍。注意这需要显卡硬件支持 FP8 计算Ada 架构以上老卡别硬开。第三是--enable-chunked-prefill。这个参数把长 prompt 的预填充阶段拆成小 chunk跟 decode 阶段交错执行避免一条长请求进来把整个服务卡住的情况。多用户场景强烈建议开代价是极少量吞吐损失。第四是--enforce-eager。它关闭 CUDA Graph 优化能省一点显存因为不用缓存 graph但牺牲 20%-30% 的推理速度。只有当显存实在挤不下了才用别默认开。6. 高频踩坑记录与完整排查链路跑过的服务多了你会发现来来回回就那么几个坑。这里分享我踩过的、也帮别人排查过的典型案例并给出完整排查思路而不是直接丢一个标准答案。6.1 CUDA OOM 的两种根源如何区分OOM 分两种排查路径完全不同。第一种是启动期 OOM日志在加载权重的阶段直接报CUDA out of memory。这通常意味着权重本身放不进显存或者--gpu-memory-utilization设置的余量不够 CUDA context。解法是换更小的模型、用量化版、或者换大显存卡。你不需要调max-model-len因为还没走到 KV 分配那一步。第二种是服务期 OOM服务起来没问题并发一上来或者来了条长上下文请求才崩。这种八成是 KV Cache 预算被击穿了。排查步骤看启动日志里的 kv_cache_size确认你的max_num_seqs × max_model_len乘积是否超出了这个预算看当时nvidia-smi的显存峰值是否顶到上限如果超了优先降低--max-num-seqs而不是--max-model-len——除非你的业务确实需要长上下文我见过一个典型的案例有人把并发调到 256一直跑得好好的某天来了几个 8K 长文本请求服务直接崩了还以为是模型问题。其实就是长请求把 KV 预算瞬间占满了。这类问题在日志里能看到OutOfMemoryError: No available memory for the cache blocks这行提示看到它就知道了KV Cache 不够了不是权重不够。6.2 模型下载失败、缓存路径与磁盘权限问题第二个高频坑集中在模型下载环节。服务启动时卡在 Downloading ... 半天不动或者反复重试失败通常是网络或缓存路径的问题。我的标准做法是提前把模型下到本地pip install huggingface_hub huggingface-cli download Qwen/Qwen2.5-7B-Instruct --local-dir /data/models/qwen2.5-7b然后指定本地路径启动vllm serve /data/models/qwen2.5-7b \ --trust-remote-code注意如果模型目录里有自定义配置代码别漏了--trust-remote-code这个参数否则会报 requires remote code 的错误。另外国内网络环境下设置镜像站下载会快很多具体做法是配置HF_ENDPOINThttps://hf-mirror.com环境变量。这只是一个合规的开源镜像服务不放心的也可以选择夜深人静时慢慢下。还有一个隐蔽的坑默认缓存路径~/.cache/huggingface所在磁盘满了或者权限不对。我用nvme装系统、数据盘挂载在/data时踩过这个坑解决办法是把缓存指过去export HF_HOME/data/hf_cacheDocker 场景下则是挂载卷权限问题容器内用户和宿主机 UID 不一致时写缓存会报 Permission denied直接用-v挂个有写权限的目录最省事。6.3 Windows 与多卡场景的额外注意Windows 用户先说结论能上 WSL2 就上 WSL2。vLLM 官方不提供 Windows 原生支持社区版虽说能用但部分自定义算子、并行调度功能会缺失性能也有折扣也只适合尝鲜。WSL2 里装个 Ubuntu按前面 Linux 流程走几乎不会遇到怪问题。唯一要注意的是 WSL2 里记得装 Windows 侧的显卡驱动驱动装在 Windows 侧WSL 里不需要重复装然后确认 WSL 里nvidia-smi能识别显卡。多卡场景最常见的报错是 NCCL 通信问题比如Failed to initialize NCCL或者Timeout waiting for NCCL communicator ready。如果你用--tensor-parallel-size 2在两张卡上跑出现这类问题先检查两件事卡间是否存在 P2P 通信限制用nvidia-smi topo -m看拓扑以及显存是否都是空闲的。另一个常见错误是两张卡显存不一致会导致 vLLM 直接拒跑要求每张卡完全同型号同容量。多卡场景还有一个很多人搞错的概念--tensor-parallel-size必须等于参与推理的卡数不是你想让它用几张就用几张。写错了你轻则报错重则有卡空闲着却在疯狂排队。7. 实战案例DeepSeek 蒸馏版与 Qwen 的部署配置参考最后给两个直接可抄的部署模板覆盖最近最热的两类模型。7.1 用 vLLM 部署 DeepSeek-R1-Distill-Qwen-7BDeepSeek 全员开源之后很多人想在本地跑推理模型。注意完整的 DeepSeek-R1 是 671B 参数的 MoE 架构单机普通硬件别想那是企业级多机部署的范畴。日常使用跑蒸馏版就好R1-Distill-Qwen-7B 是性价比最高的一个。单卡 24GB 配置vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --gpu-memory-utilization 0.9 \ --max-model-len 16384 \ --max-num-seqs 32 \ --dtype bfloat16特别提醒推理模型的服务端参数DeepSeek 官方建议推理模型用temperature0.6、top_p0.95而且不要喂 system prompt。很多人在服务端把 temperature 设成 0.7 以上推理模型就开始胡言乱语这不是模型坏了是采样参数没调对。在客户端请求里显式带上这两个参数即可curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-ai/DeepSeek-R1-Distill-Qwen-7B, messages: [{role: user, content: 9.11 和 9.8 哪个大}], temperature: 0.6, top_p: 0.95, max_tokens: 2048 }如果是 R1-Distill-Llama-70B 这种 140GB 权重的大蒸馏版单卡就别想了。我的建议配置是 4 张 A100 80GB配合张量并行vllm serve deepseek-ai/DeepSeek-R1-Distill-Llama-70B \ --tensor-parallel-size 4 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192四张 80GB 合计 320GB权重 140GBKV 预算和并发空间都很充裕。7.2 Qwen2.5 系列配置参考Qwen 系列是体验最省心的开源模型因为 vLLM 官方对它的适配最积极。以 Qwen2.5-7B-Instruct 为例单卡 24GB 建议配置vllm serve Qwen/Qwen2.5-7B-Instruct \ --gpu-memory-utilization 0.9 \ --max-model-len 32768 \ --max-num-seqs 64 \ --enable-chunked-prefill这里我把max-model-len放到 32K因为 Qwen2.5 的 GQA 架构 KV 开销小24GB 卡能扛住--enable-chunked-prefill则是为了长文档场景下不至于被一条大请求卡死。如果是 72B 的大模型操作路径是两条要么 4 张 24GB 卡张量并行要么单卡用 AWQ 量化。我实测过 Qwen2.5-72B-Instruct-AWQ 在单张 48GB 卡A6000上能跑 8K 上下文吞吐还能维持在 1500 token/s 左右性价比相当高vllm serve Qwen/Qwen2.5-72B-Instruct-AWQ \ --quantization awq \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --max-num-seqs 167.3 部署后接入业务的几个落地建议服务搭好之后真正接业务时还有几个细节值得注意。首先vLLM 服务最好用 systemd 或 supervisor 做守护加个--port固定端口别让它裸奔在终端里。其次vLLM 自带/metrics端点Prometheus 可以直接抓我在生产环境就是靠这个监控吞吐和显存趋势的比肉眼盯nvidia-smi高效得多。其次一台 GPU 只起一个 vLLM 实例是最稳定、最推荐的做法。很多人为了用满显存在一张卡上起两个进程分别加载两个小模型结果互相挤逼性能反而不如一个进程里配置两个模型来的稳。vLLM 支持一个服务内多模型共存用--served-model-name区分对外名称但新手阶段建议还是别折腾。最后别忘了设置--max-paddding-token如果有或者合理的中断重试逻辑。长上下文请求在 vLLM 里会占用大量 KV 块如果业务里经常有极端长输入服务端做一个长度上限校验好过让用户直接撞 OOM。我现在的固定套路是新模型先在 24GB 测试卡上用 5.1 节的安全配置起然后 5.2 节的压测脚本跑一遍根据日志里的 kv_cache_size 和压测结果做一次针对性调整最后换上生产参数并接监控。这套流程下来我在 3090、4090、A100 上都部署过不同规模的服务还没有一次启动失败后需要全盘重装的。你也照这个节奏来vLLM 从 0 到 1 这条路不会太难走。 vLLM部署与显存调优实战：从Ollama到高并发推理加速
你有没有遇到过这种情况在 Ollama 里跑一个 7B 模型单条对话响应飞快可一旦开并发做评测、或者想架个服务给团队用速度立刻掉到没法看我去年做内部私有化部署时也卡在这一步后来换到 vLLM同一个模型、同一张 3090吞吐直接翻了差不多十倍。vLLM 是目前最主流的开源大模型推理加速引擎它的核心价值就一句话把你手上的 GPU 显存榨干同时把并发吞吐拉满。无论是部署 DeepSeek 蒸馏版、Qwen 系列开源模型还是给 RAG 应用、Agent 后端做 OpenAI 兼容服务它都是绕不开的第一选项。但这东西也是出了名的能装起来容易调好很难——版本、CUDA、显存利用率、KV Cache 这些概念新手第一次接触很容易在启动阶段就被一堆报错劝退。这篇文章我就把安装、启动、显存调优这条路完整走一遍包括我真实踩过的坑和验证过有效的参数模板你照着操作就能从 0 跑到一个能对外提供服务的实例。1. vLLM 的定位它到底比 Ollama、LM Studio 强在哪先别急着装搞清楚一个问题本地跑模型明明有 Ollama、LM Studio 这种开箱即用的工具为什么还要折腾 vLLM我见过太多人装完 Ollama 用得挺好一上 vLLM 就各种报错最后得出结论vLLM 就是个坑。其实不是 vLLM 坑是这两个东西的定位压根不一样。1.1 PagedAttention 与 Continuous Batching 带来的吞吐量差异Ollama 底层用的是 llama.cpp它的优化思路是把单用户交互做到极致显存占用小、启动快、CPU 也能跑。但它在调度层面有个硬伤——它处理一批请求时一个 batch 里的请求要等全部生成完才能释放槽位新请求只能排队。这就像一家只能翻桌不能拼桌的快餐厅人一多必然堵门口。vLLM 解决这个问题靠的是两板斧。第一板斧是 PagedAttention。大模型推理时会把历史 token 的 Key 和 Value 缓存下来这个缓存叫 KV Cache。传统方案给每条请求分配一整块连续显存但实际生成过程中缓存是逐步增长的于是大量显存被预留着却用不上碎片化严重。vLLM 把 KV Cache 切成固定大小的 block默认 16 个 token 一块像操作系统管理内存页一样按需分配、随时回收显存利用率从 40%-60% 直接拉到 90% 以上。它最大的优势是可以多个序列共享同一个物理 block这在做并行采样的时候特别明显。第二板斧是 Continuous Batching也就是连续动态批处理。vLLM 在每个推理 iteration 都会重新检查队列有新请求进来就插队有请求生成完了就立刻腾出槽位给下一条而不是等整批结束。效果就像快餐厅改成流水线出餐吞吐自然就上来了。我实测同一个 Qwen2.5-7B 模型在单张 3090 上Ollama 的并发吞吐大概在 800-1200 token/s 这个区间换成 vLLM 单并发差不太多但 8 并发下能到 4000 token/s延迟还更稳定。这还没算 PagedAttention 对显存的节省。1.2 什么场景才值得上 vLLM我自己总结了一个很粗暴的决策标准你只是本地聊天、代码补全、一个人玩请继续用 Ollama 或 LM Studio省心是第一位你要开 API 服务给多个用户、跑评测脚本、做 Agent 并发调度、搞 RAG 批量文档处理或者用到长上下文vLLM 是效率上限最高的选择你要部署 DeepSeek 蒸馏版、Qwen2.5/3 这类热门开源模型vLLM 的社区适配是最快的新架构发布后通常第一批支持另外注意一点vLLM 的吞吐优势是并发越大越明显。如果你只是单请求、单并发它和 llama.cpp 的差距很小甚至因为 CUDA Graph 初始化慢首 token 延迟还略高。所以别拿单条对话的响应速度来评判 vLLM那不是它的主场。2. 安装前的关键决策环境矩阵与三条安装路径vLLM 的安装本身不难难的是环境匹配。我见过太多人直接在服务器上 pip install结果装完一跑就报 CUDA error、No kernel image 之类的错最后全盘重来。以下这些前置决策你提前想清楚能省一整天。2.1 Python、CUDA、GPU 驱动的最低门槛先说系统vLLM 官方对 Linux 支持最完善Windows 属于社区维护的能用但不保证状态。如果你在 Windows 上我建议直接用 WSL2 或者 Docker后面的踩坑章节会细说。然后是软件版本我把核心要求整理成了这张表项目最低要求我的建议Python3.9 - 3.123.10 或 3.11 最稳别用 3.13 以下的太新版本CUDA12.112.4 / 12.6 均可50 系显卡看 2.3 节NVIDIA 驱动525用 nvidia-smi 先确认驱动版本对应 CUDA 版本GPU显存 8GB 起跑 7B 模型建议 24GB追求体验就上 48GB 以上这里的核心逻辑是vLLM 的 wheel 包是绑定 CUDA 版本编译的你的 CUDA 环境如果跟 wheel 不匹配装完大概率跑不起来。所以在安装之前先把显卡驱动升级到位再确认 nvidia-smi 显示的 CUDA Version 在 12.1 以上。2.2 pip、Docker、源码编译三条路怎么选pip 安装是最快的路径适合绝大多数人python -m venv vllm-env source vllm-env/bin/activate pip install vllm为什么一定要用虚拟环境因为 vLLM 会依赖特定版本的 torch、transformers如果和你的全局环境里其他项目冲突会出现各种诡异的报错。我见过有人在 conda 根环境里装 vLLM结果把 torch 版本干回旧版其他项目全部崩溃。装完验证一下python -c import vllm; print(vllm.__version__)能打印出版本号基本就过了大半。Docker 路线适合两种情况一是你不想动宿主机环境想隔离得干干净净二是你需要特定版本的镜像配合特定 CUDA。官方镜像用法docker pull vllm/vllm-openai:latest docker run --runtime nvidia --gpus all \ -p 8000:8000 \ -v ~/.cache/huggingface:/root/.cache/huggingface \ vllm/vllm-openai:latest \ --model Qwen/Qwen2.5-7B-Instruct \ --gpu-memory-utilization 0.85这里有个容易忽略的细节挂载~/.cache/huggingface到容器里模型权重才不用重复下载。我第一次用 Docker 跑的时候忘了这步启动日志一直在走下载流程还以为卡住了。源码编译则只推荐给要改算子、做二次开发、或者需要特定 FlashAttention 版本配合的人。编译 vLLM 依赖 CUDA toolkit、ninja、gcc一份工作量大几十倍不止产出还未必比预编译包快。普通用户真没必要走这条路。2.3 CUDA 12.8 与 RTX 50 系显卡的特殊处理这一节专门写给用 RTX 50 系或者 CUDA 12.8 环境的人。网上搜索热词里频繁出现cuda128 vllm原因很简单RTX 50 系Blackwell 架构算力代号 sm_120需要 CUDA 12.8 以上才能发挥完整算力但很多 pip wheel 默认是基于 CUDA 12.4/12.6 编译的装在 12.8 环境里可能直接报no kernel image is available。我的处理办法是先看自己的 CUDA 版本再决定用哪种 wheel。vLLM 新版本会同步发布 cu128 对应的构建产物具体安装方式以官方 release notes 为准。如果你用的是 50 系卡装之前搜一下vllm cu128相关的官方说明别盲目 pip install latest。装好之后跑一下python -c import torch; print(torch.version.cuda)确认 torch 内部的 CUDA 版本跟你系统环境一致。这一步比什么都管用很多装好了但跑不了的坑都是 torch 和系统 CUDA 版本对不上导致的。3. 启动模型全流程serve 命令参数逐项拆解环境弄好之后最激动人心的时刻来了把模型真正跑起来。这里我强烈建议第一次跑就用vllm serve因为它把整个服务端封装好了你不需要自己写代码就能拿到一个 OpenAI 兼容接口前端、测试工具可以直接对接。3.1 最小启动命令与启动日志解读拿 Qwen2.5-7B-Instruct 举例最小可用命令长这样vllm serve Qwen/Qwen2.5-7B-Instruct \ --port 8000 \ --host 0.0.0.0 \ --gpu-memory-utilization 0.85 \ --max-model-len 8192--host 0.0.0.0是为了让局域网内其他机器也能访问如果你只在本机测试可以省略默认 127.0.0.1。--port 8000是默认端口改也行。第一次启动会先下载模型权重这个过程取决于网速和模型大小7B 模型大概 15GB。下载完会看到一段 memory profiling 日志大概长这样INFO: Memory profiling results: total_gpu_memory23.6GiB, used_gpu_memory14.1GiB, kv_cache_size9.2GiB这行日志特别关键它告诉你总共 24GB 显存、模型权重占 14GB、拿出来给 KV Cache 的是 9GB。如果这里显示 kv_cache_size 特别小说明你的--gpu-memory-utilization设置太保守或者显存被其他进程占了。启动成功的标志是日志出现Uvicorn running on http://0.0.0.0:8000这一行后面跟Application startup complete.。看到这两行你的服务就算真正起来了。3.2 用 OpenAI 兼容接口验证服务是否正常服务起来了用三个请求验证# 1. 查看模型列表 curl http://localhost:8000/v1/models # 2. 基础对话 curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: Qwen/Qwen2.5-7B-Instruct, messages: [{role: user, content: 用一句话介绍你自己}], max_tokens: 256 }/v1/models如果返回模型 ID说明服务活着/v1/chat/completions能返回内容说明推理链路正常。这里注意model字段必须跟启动时的模型名完全一致很多人在这卡半天其实只是名字拼错了。如果你用 Python 调用直接上 openai SDKfrom openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY, # vLLM 默认不校验 key随便填 ) resp client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct, messages[{role: user, content: 你好}], max_tokens128, ) print(resp.choices[0].message.content)这套接口跟 OpenAI 完全兼容意味着你之前写好的 LLM 调用代码只要把 base_url 改一下就能切到本地 vLLM 服务改动量趋近于零。3.3 不开网络服务直接用 Python API 做离线推理不是所有场景都要开 HTTP 服务。跑批量评测、处理离线文本、做脚本实验时直接走 Python API 更省事from vllm import LLM, SamplingParams llm LLM( modelQwen/Qwen2.5-7B-Instruct, gpu_memory_utilization0.85, max_model_len8192, ) params SamplingParams( temperature0.7, top_p0.8, max_tokens512, ) prompts [写一段关于秋天的散文, 解释一下什么是 KV Cache] outputs llm.generate(prompts, params) for output in outputs: print(output.outputs[0].text)这个方式的优势是没有网络开销适合大批量处理。注意sampling_params是每次调用单独设置的而不是在LLM()里设置新手容易搞混。LLM()管理的是模型加载和显存分配真正的生成参数全在SamplingParams里。4. 显存调优的核心原理显存到底花在哪了当你跑通了基本流程紧接着就会碰到最核心的问题显存怎么调。调优之前必须先搞清楚一件事——你的显存被谁吃掉了。我见过太多人一遇到 OOM 就无脑调低--gpu-memory-utilization结果模型反而跑不动了因为他们根本不理解这个参数控制的是什么。4.1 显存的四笔开销权重、KV Cache、激活值与临时缓冲一次推理中显存主要有四个去向。第一是模型权重。权重大小 参数量 × 每个参数占的字节数。7B 模型用 FP162 字节就是7 × 2 14GB13B 是 26GB。这是固定开销模型一加载就占住了除非换量化版本否则省不掉。第二是 KV Cache这是 vLLM 里最需要理解的部分。它的计算公式是每 token 的 KV Cache 大小 2 × 层数 × KV 头数 × head_dim × 精度字节数我拿 7B 规模的老架构模型举例MHA 注意力32 层、32 头、head_dim 128、FP162 × 32 × 32 × 128 × 2 524,288 字节 ≈ 512KB/token这意味着单条请求跑 4096 上下文的对话光 KV Cache 就要吃掉 2GB。而新一代 GQA 架构模型比如 Qwen2.5-7B28 层、4 个 KV 头明显更省2 × 28 × 4 × 128 × 2 57,344 字节 ≈ 56KB/token同样 4096 上下文只要 224MB。这就是为什么新模型在长上下文场景下显存压力小很多。所以网上那些7B 模型 16GB 显存就能跑的说法实际要打个问号——那只是权重加上 KV Cache 和上下文24GB 显卡才算是舒服起步线。第三是激活值就是每一层前向计算时的中间张量。vLLM 用 CUDA Graph 优化后这部分开销被压得很低但--enforce-eager模式下会明显增大。第四是 CUDA context 和 torch 的缓存分配器碎片这部分一般在 500MB 到 1GB 之间属于系统性开销。4.2 gpu-memory-utilization 到底在控制什么--gpu-memory-utilization的默认值是 0.9意思是vLLM 启动时会做一次内存探针算出当前 GPU 空闲显存然后最多允许 vLLM 占用其中的 90%。模型权重先扣掉剩下的全部用于 KV Cache 预分配。所以这个参数其实是个总预算不是KV Cache 占比。它的关键行为是调高它KV Cache 可用空间变大意味着能支持更长的上下文和更多的并发序列调低它KV Cache 变小但给其他进程留了空间GPU 上可以同时跑别的任务我在 24GB 的 4090 上跑 7B 模型的经验是权重 14GB系统开销 1GB 左右剩下 9GB 给 KV Cache。9GB 除以 56KB/tokenQwen 架构约等于 16 万个 token 的缓存空间但这个空间还要按max_num_seqs并发切分。所以真正限制你的往往不是模型大小而是你能开多长的上下文和多大的并发。4.3 max-model-len 与 max-num-seqs 的联动关系启动日志里有个容易被忽略的关键参数--max-model-len。它默认从模型配置里读但很多时候模型配置的 max_position_embeddings 很大比如 32K、128K如果显存不够vLLM 启动时会直接报错让你手动指定更小的值。它的本质是vLLM 会按照max_model_len × max_num_seqs一次性预分配最大 KV Cache 空间。所以 KV Cache 的天花板是KV Cache 总上限 每 token KV 大小 × max_model_len × max_num_seqs举个例子Qwen2.5-7B 每 token 56KBmax_model_len8192、max_num_seqs32时KV 上限 56KB × 8192 × 32 14GB。这已经逼近 24GB 卡上权重之外的全部余量了。所以你会看到这样的权衡参数调大效果调小效果max-model-len支持长文档/长对话KV 空间缩小短任务够用max-num-seqs并发吞吐更高同时处理的请求变少二者乘积决定了 KV Cache 峰值峰值越低越不易 OOM实用口诀短任务就把 max-model-len 压到需要的长度即可比如只想跑代码补全设为 4096 完全够做长文档分析再放长。千万别无脑拉满那是在糟蹋显存。5. 一套可复现的调优流程从 OOM 到稳定服务理论讲完给一套可以直接抄的操作路径。我的调优方法论只有三步先跑起来、再压测、最后做针对性优化。顺序不能乱跳过压测直接堆参数一定会踩坑。5.1 第一步先跑起来用安全配置模板一个 24GB 显存 7B 模型的新环境我建议直接用这套保守配置起手vllm serve Qwen/Qwen2.5-7B-Instruct \ --gpu-memory-utilization 0.85 \ --max-model-len 8192 \ --max-num-seqs 32 \ --dtype bfloat16解释几个选择。--dtype bfloat16比 FP16 在 30 系以上显卡上更稳不容易溢出而且 vLLM 对 BF16 的 kernel 优化已经很成熟。--max-num-seqs 32是为了把并发先压住等确认显存充裕再往上加。--gpu-memory-utilization 0.85是给 CUDA context 和系统开销留了安全边际。如果 7B 都 OOM要么你的卡不是 24GB 级要么环境里有别的进程占显存。先用nvidia-smi看清楚空余显卡再启动别急着怀疑参数。等到模型启动后运行状态稳定再做下一步。5.2 第二步压测找天花板而不是拍脑袋调参很多人调显存全靠感觉这是最大的坑。vLLM 仓库自带压测脚本叫benchmark_serving.py用法大致是python benchmark_serving.py \ --model Qwen/Qwen2.5-7B-Instruct \ --endpoint /v1/chat/completions \ --num-prompts 200 \ --concurrency 8 \ --max-tokens 512它会输出几个关键指标TTFT首 token 延迟、TPOT每个输出 token 的延迟、总吞吐。同时开着nvidia-smi -l 1盯着显存变化。如果压测跑完显存一直都在安全线上就逐步把--max-num-seqs加一倍再测一旦接近 OOM 的临界点你会看到显存值顶到 utilization 上限附近此时再压回去一档。这个逐级探测的过程比任何理论估算都靠谱因为每台机器的显存碎片情况不一样。压测时注意区分两个指标吞吐量和延迟。vLLM 的典型特征是吞吐很高但单请求延迟未必最低。如果业务对延迟敏感你可能反而要限制max-num-seqs让每个请求跑得更快。这是很多新手没意识到的反直觉点。5.3 第三步针对瓶颈上进阶手段压测发现瓶颈在哪里再对症下药通常有几个方向第一是权重量化。如果 7B 的 14GB 权重让你的 KV Cache 空间很小可以考虑 AWQ 或 GPTQ 量化版。比如Qwen/Qwen2.5-7B-Instruct-AWQ4bit 权重直接把 14GB 砍到 4GB 左右权重省下来的 10GB 全给 KV Cache 和并发。代价是生成质量轻微下降、部分场景速度略慢。我用 AWQ 做过 A/B 对比质量差异在评测集上通常不到 1 个点但吞吐和并发上限提升明显。第二是--kv-cache-dtype fp8。把 KV Cache 从 FP16 压成 FP8KV 空间直接翻倍。注意这需要显卡硬件支持 FP8 计算Ada 架构以上老卡别硬开。第三是--enable-chunked-prefill。这个参数把长 prompt 的预填充阶段拆成小 chunk跟 decode 阶段交错执行避免一条长请求进来把整个服务卡住的情况。多用户场景强烈建议开代价是极少量吞吐损失。第四是--enforce-eager。它关闭 CUDA Graph 优化能省一点显存因为不用缓存 graph但牺牲 20%-30% 的推理速度。只有当显存实在挤不下了才用别默认开。6. 高频踩坑记录与完整排查链路跑过的服务多了你会发现来来回回就那么几个坑。这里分享我踩过的、也帮别人排查过的典型案例并给出完整排查思路而不是直接丢一个标准答案。6.1 CUDA OOM 的两种根源如何区分OOM 分两种排查路径完全不同。第一种是启动期 OOM日志在加载权重的阶段直接报CUDA out of memory。这通常意味着权重本身放不进显存或者--gpu-memory-utilization设置的余量不够 CUDA context。解法是换更小的模型、用量化版、或者换大显存卡。你不需要调max-model-len因为还没走到 KV 分配那一步。第二种是服务期 OOM服务起来没问题并发一上来或者来了条长上下文请求才崩。这种八成是 KV Cache 预算被击穿了。排查步骤看启动日志里的 kv_cache_size确认你的max_num_seqs × max_model_len乘积是否超出了这个预算看当时nvidia-smi的显存峰值是否顶到上限如果超了优先降低--max-num-seqs而不是--max-model-len——除非你的业务确实需要长上下文我见过一个典型的案例有人把并发调到 256一直跑得好好的某天来了几个 8K 长文本请求服务直接崩了还以为是模型问题。其实就是长请求把 KV 预算瞬间占满了。这类问题在日志里能看到OutOfMemoryError: No available memory for the cache blocks这行提示看到它就知道了KV Cache 不够了不是权重不够。6.2 模型下载失败、缓存路径与磁盘权限问题第二个高频坑集中在模型下载环节。服务启动时卡在 Downloading ... 半天不动或者反复重试失败通常是网络或缓存路径的问题。我的标准做法是提前把模型下到本地pip install huggingface_hub huggingface-cli download Qwen/Qwen2.5-7B-Instruct --local-dir /data/models/qwen2.5-7b然后指定本地路径启动vllm serve /data/models/qwen2.5-7b \ --trust-remote-code注意如果模型目录里有自定义配置代码别漏了--trust-remote-code这个参数否则会报 requires remote code 的错误。另外国内网络环境下设置镜像站下载会快很多具体做法是配置HF_ENDPOINThttps://hf-mirror.com环境变量。这只是一个合规的开源镜像服务不放心的也可以选择夜深人静时慢慢下。还有一个隐蔽的坑默认缓存路径~/.cache/huggingface所在磁盘满了或者权限不对。我用nvme装系统、数据盘挂载在/data时踩过这个坑解决办法是把缓存指过去export HF_HOME/data/hf_cacheDocker 场景下则是挂载卷权限问题容器内用户和宿主机 UID 不一致时写缓存会报 Permission denied直接用-v挂个有写权限的目录最省事。6.3 Windows 与多卡场景的额外注意Windows 用户先说结论能上 WSL2 就上 WSL2。vLLM 官方不提供 Windows 原生支持社区版虽说能用但部分自定义算子、并行调度功能会缺失性能也有折扣也只适合尝鲜。WSL2 里装个 Ubuntu按前面 Linux 流程走几乎不会遇到怪问题。唯一要注意的是 WSL2 里记得装 Windows 侧的显卡驱动驱动装在 Windows 侧WSL 里不需要重复装然后确认 WSL 里nvidia-smi能识别显卡。多卡场景最常见的报错是 NCCL 通信问题比如Failed to initialize NCCL或者Timeout waiting for NCCL communicator ready。如果你用--tensor-parallel-size 2在两张卡上跑出现这类问题先检查两件事卡间是否存在 P2P 通信限制用nvidia-smi topo -m看拓扑以及显存是否都是空闲的。另一个常见错误是两张卡显存不一致会导致 vLLM 直接拒跑要求每张卡完全同型号同容量。多卡场景还有一个很多人搞错的概念--tensor-parallel-size必须等于参与推理的卡数不是你想让它用几张就用几张。写错了你轻则报错重则有卡空闲着却在疯狂排队。7. 实战案例DeepSeek 蒸馏版与 Qwen 的部署配置参考最后给两个直接可抄的部署模板覆盖最近最热的两类模型。7.1 用 vLLM 部署 DeepSeek-R1-Distill-Qwen-7BDeepSeek 全员开源之后很多人想在本地跑推理模型。注意完整的 DeepSeek-R1 是 671B 参数的 MoE 架构单机普通硬件别想那是企业级多机部署的范畴。日常使用跑蒸馏版就好R1-Distill-Qwen-7B 是性价比最高的一个。单卡 24GB 配置vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --gpu-memory-utilization 0.9 \ --max-model-len 16384 \ --max-num-seqs 32 \ --dtype bfloat16特别提醒推理模型的服务端参数DeepSeek 官方建议推理模型用temperature0.6、top_p0.95而且不要喂 system prompt。很多人在服务端把 temperature 设成 0.7 以上推理模型就开始胡言乱语这不是模型坏了是采样参数没调对。在客户端请求里显式带上这两个参数即可curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-ai/DeepSeek-R1-Distill-Qwen-7B, messages: [{role: user, content: 9.11 和 9.8 哪个大}], temperature: 0.6, top_p: 0.95, max_tokens: 2048 }如果是 R1-Distill-Llama-70B 这种 140GB 权重的大蒸馏版单卡就别想了。我的建议配置是 4 张 A100 80GB配合张量并行vllm serve deepseek-ai/DeepSeek-R1-Distill-Llama-70B \ --tensor-parallel-size 4 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192四张 80GB 合计 320GB权重 140GBKV 预算和并发空间都很充裕。7.2 Qwen2.5 系列配置参考Qwen 系列是体验最省心的开源模型因为 vLLM 官方对它的适配最积极。以 Qwen2.5-7B-Instruct 为例单卡 24GB 建议配置vllm serve Qwen/Qwen2.5-7B-Instruct \ --gpu-memory-utilization 0.9 \ --max-model-len 32768 \ --max-num-seqs 64 \ --enable-chunked-prefill这里我把max-model-len放到 32K因为 Qwen2.5 的 GQA 架构 KV 开销小24GB 卡能扛住--enable-chunked-prefill则是为了长文档场景下不至于被一条大请求卡死。如果是 72B 的大模型操作路径是两条要么 4 张 24GB 卡张量并行要么单卡用 AWQ 量化。我实测过 Qwen2.5-72B-Instruct-AWQ 在单张 48GB 卡A6000上能跑 8K 上下文吞吐还能维持在 1500 token/s 左右性价比相当高vllm serve Qwen/Qwen2.5-72B-Instruct-AWQ \ --quantization awq \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --max-num-seqs 167.3 部署后接入业务的几个落地建议服务搭好之后真正接业务时还有几个细节值得注意。首先vLLM 服务最好用 systemd 或 supervisor 做守护加个--port固定端口别让它裸奔在终端里。其次vLLM 自带/metrics端点Prometheus 可以直接抓我在生产环境就是靠这个监控吞吐和显存趋势的比肉眼盯nvidia-smi高效得多。其次一台 GPU 只起一个 vLLM 实例是最稳定、最推荐的做法。很多人为了用满显存在一张卡上起两个进程分别加载两个小模型结果互相挤逼性能反而不如一个进程里配置两个模型来的稳。vLLM 支持一个服务内多模型共存用--served-model-name区分对外名称但新手阶段建议还是别折腾。最后别忘了设置--max-paddding-token如果有或者合理的中断重试逻辑。长上下文请求在 vLLM 里会占用大量 KV 块如果业务里经常有极端长输入服务端做一个长度上限校验好过让用户直接撞 OOM。我现在的固定套路是新模型先在 24GB 测试卡上用 5.1 节的安全配置起然后 5.2 节的压测脚本跑一遍根据日志里的 kv_cache_size 和压测结果做一次针对性调整最后换上生产参数并接监控。这套流程下来我在 3090、4090、A100 上都部署过不同规模的服务还没有一次启动失败后需要全盘重装的。你也照这个节奏来vLLM 从 0 到 1 这条路不会太难走。