从 Docker 到多卡量化vLLM 部署与安装实战指南半小时拿到可用的大模型推理服务【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm模型加载了五分钟第一条回复又等了三十秒——这就是没调过参数的默认部署给你的体验。vLLM 是目前最主流的 LLM 推理服务引擎用 PagedAttention 管理 KV Cache 内存、靠连续批处理把吞吐拉满一条 Docker 命令就能起一个 OpenAI 兼容服务。五分钟拿到第一条回复最短路径是 Docker 一键部署宿主机只需要装好 NVIDIA 驱动和nvidia-container-toolkitPython、CUDA 全都不用自己管。# 拉取官方镜像几 GB耐心等首次之后就是本地秒起 docker pull vllm/vllm-openai:latest # 起容器挂 GPU、绑 8000 端口直接 serve 一个 1.5B 小模型做验证 docker run --gpus all -it --rm -p 8000:8000 \ vllm/vllm-openai:latest \ --model Qwen/Qwen2.5-1.5B-Instruct \ --port 8000--gpus all是把 GPU 透传进容器-p 8000:8000把服务端口映射到宿主机缺了后面排查网络问题时你会非常痛苦这步别跳。看到Application startup complete之后另开一个终端# 先看服务活着没返回 42 是预期行为没有请求体 curl http://localhost:8000/health # 发一条真正的聊天请求验证能出字 curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: Qwen/Qwen2.5-1.5B-Instruct, messages: [{role: user, content: 用一句话介绍你自己}], max_tokens: 64 }响应里choices[0].message.content有内容服务就算跑通了。镜像里 PyTorch 和 CUDA 版本是官方配好的宿主机是什么 Python 版本、装了什么 torch 都无所谓——这正是很多人pip install vllm反复翻车的原因。三种装法对号入座适用场景核心命令优势坑点提示Docker 镜像生产推荐docker run --gpus all -p 8000:8000 vllm/vllm-openai:latest --model 你的模型依赖全打包、版本隔离、重启即恢复镜像体量大频繁切换版本注意磁盘占用多机部署要处理跨节点网络pip 预编译包单机开发/实验uv pip install vllm --torch-backendauto不用 Docker改代码、断点调试方便CUDA 版本必须和已装 torch 对齐不对齐就出CUDA error或导入失败先uv venv隔离环境源码构建魔改内核git clone https://gitcode.com/GitHub_Trending/vl/vllm uv pip install -e vllm可以改csrc/下的 C/CUDA 内核、打私有补丁全量构建耗时最长需要完整编译工具链频繁改内核时走增量编译流程能省大量时间补充两句pip 装完先跑一次python -c import vllm验证环境没炸再谈别的源码构建如果只是偶尔改 Python 层其实-e安装后直接改文件就能生效不用每次重新编译。从 Demo 到生产你真正需要调的开关不列参数大全只讲卡在哪就拧哪个的五个高频场景。显存 OOM服务起不来或跑着跑着挂症状日志里CUDA out of memory常见于加载大模型阶段。vLLM 启动时会做一次显存探测按**--gpu-memory-utilization**默认 0.92划出 KV Cache 空间模型本体、激活值、CUDA context 都要挤在这块里。vllm serve model \ --gpu-memory-utilization 0.85 \ # 先给利用率松口 --max-model-len 8192 # 上限按业务真实长度收别贪为什么有效max-model-len直接决定 KV Cache 预分配上限长上下文的 KV Cache 是显存大头把长度收到业务实际水平往往比换卡便宜得多。并发上不去单请求延迟没问题但吞吐低症状QPS 拉不高GPU 利用率却上不去请求在排队。vllm serve model \ --max-num-batched-tokens 16384 \ # 单步最多处理的 token 总量 --max-num-seqs 512 # 同时在跑的序列上限为什么有效连续批处理的意义就是让预填充和Decode共享同一批步这两个值太保守时 GPU 算不满调大后长 prompt 的切块chunked prefill更充分吞吐和排队延迟同时改善。想省显存直接上量化模型症状模型本身放不进单卡或者想同卡多塞一份。vllm serve TheBloke/Llama-3.1-8B-Instruct-AWQ \ --quantization awq \ # 显式指定量化格式防止被误判 --gpu-memory-utilization 0.9为什么有效AWQ/GPTQ/FP8 这些量化把权重压到 4bit/8bit显存占用几乎线性下降精度损失对多数业务可接受。注意量化模型必须用发布方给的量化 checkpoint别拿原始 bf16 权重指望运行时现压。多卡怎么切TP 还是 DP症状单卡装不下 70B 级别模型或者卡数富余想把吞吐翻倍。# 8×H100 跑大模型TP2 切模型DP4 复制 4 份提吞吐 vllm serve model \ --tensor-parallel-size 2 \ --data-parallel-size 4为什么有效TP 把单层的权重矩阵切开分摊到多卡解决放不下DP 起多份独立引擎各自吃请求解决吞吐不够。一个管容量、一个管并发tensor-parallel-size ×>vllm serve model \ --enable-prefix-caching为什么有效相同前缀的 KV Cache 按块复用第二次请求同一个 system prompt 时直接命中TTFT 明显下降且对输出质量零影响。多轮对话、Agent 长前缀场景基本是必开项纯一次性短 prompt 场景收益则很有限。部署路上最容易翻的三块坑坑一导入 vLLM 直接报 CUDA 相关错误症状pip install vllm成功一import就炸日志里 CUDA 版本对不上。 根因pip 装的 torch 和 vLLM wheel 要求的 CUDA 版本没对齐十个人八个卡这里。 解法卸干净重装或用uv让它替你选pip uninstall -y vllm torch uv venv --python 3.12 --seed source .venv/bin/activate uv pip install vllm --torch-backendauto还不对就干脆回到 Docker那是版本一致性最有保障的路径。坑二启动阶段 OOM模型压根没跑起来症状日志停在 profiling 阶段就CUDA out of memory。 根因默认 0.92 的显存利用率 默认长上下文KV Cache 预留太大和模型权重抢地盘。 解法vllm serve model --gpu-memory-utilization 0.8 --max-model-len 4096先降到 0.8、把长度收紧能起服务再逐步往回加找到你这台机器的实际上限。坑三容器里明明起来了外部就是连不上症状容器日志显示startup complete宿主机 curl 8000 端口超时。 根因多半是-p映射没写或写错也可能是安全组/防火墙只放行了内网。 解法按顺序排查——curl -v http://127.0.0.1:8000/health # 宿主机本机 curl -v http://容器IP:8000/health # 容器网络内 curl -v http://宿主机IP:8000/health # 跨机哪一步开始不通问题就在哪一层不用猜。把 Demo 变成你的线上服务把验证用的 1.5B 换成你的目标模型70B 级别直接套上--tensor-parallel-size显存不够就叠 AWQ/FP8 量化 checkpoint。把现有 OpenAI 客户端的base_url指向http://你的地址:8000/v1、api_key填EMPTY业务代码一行不用改。用 vLLM 自带的vllm bench serve压一轮把吞吐和 TTFT 的拐点记下来再对着上文的旋钮做取舍。跟住上游发版节奏vLLM 内核优化迭代很快定期升级镜像往往白捡一波性能。【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考