4. vLLM部署配置：Docker镜像选择、启动参数详解、模型加载与缓存
好，咱们进入实战环节。这一章我打算把vLLM的部署配置掰开揉碎了讲清楚。说白了，你模型选得再好，配置不对照样跑不起来。我在生产环境里见过太多人卡在这一步——镜像拉错、参数写反、缓存没配，结果显存直接爆掉。
4.1 Docker镜像选择：别小看这一步
vLLM官方提供了好几个Docker镜像。嗯，这里要注意，不是随便拉一个就能用。我个人习惯按场景来选：
| 镜像标签 | 适用场景 | 我的建议 |
|---|---|---|
vllm/vllm-openai:latest |
兼容OpenAI API接口 | 生产首选，稳定 |
vllm/vllm-openai:cuda-12.4 |
需要最新CUDA支持 | 新卡必选，比如H100 |
vllm/vllm-openai:rocm |
AMD GPU用户 | 我还没踩过这个坑 |
vllm/vllm-openai:arm |
ARM架构服务器 | 比如AWS Graviton |
注意：千万别用
:latest标签上生产。我曾经有一次半夜被叫起来，就因为latest镜像自动更新了CUDA版本，结果驱动不兼容，整个推理服务挂了两个小时。
拉镜像的命令很简单：
docker pull vllm/vllm-openai:cuda-12.4你想想看，如果团队里有人手滑用了:latest，第二天镜像变了，大家的环境全对不上。所以我的规矩是——锁定具体版本号。
4.2 启动参数详解：每个参数都是钱
vLLM的启动参数，说白了就是你在跟GPU讨价还价。参数设大了显存爆，设小了性能差。我一个个讲清楚。
4.2.1 核心参数
docker run --gpus all \
-v /models:/models \
-p 8000:8000 \
vllm/vllm-openai:cuda-12.4 \
--model /models/llama-2-7b \
--tensor-parallel-size 2 \
--gpu-memory-utilization 0.9 \
--max-model-len 4096 \
--dtype auto这几个参数我挨个说：
--tensor-parallel-size：张量并行度。我建议设成GPU卡数。比如你有4张A100，就设4。设少了浪费算力，设多了通信开销反而变慢。--gpu-memory-utilization：GPU显存利用率。默认0.9，意思是留10%给KV Cache和其他开销。我遇到过有人设成0.99，结果模型加载完直接OOM。保守点，0.85到0.9之间最稳。--max-model-len：最大序列长度。这个参数直接影响显存占用。你想想看，长度翻倍，KV Cache占的显存也翻倍。我一般先设4096，不够再加。--dtype：数据类型。设auto会自动检测，但我建议明确指定。比如bfloat16对A100/H100更友好。
我的小技巧：启动前先用
nvidia-smi看看显存总量。然后心里算一笔账——模型权重占多少，KV Cache占多少，留点余量。这样参数设起来心里有底。
4.2.2 高级参数
| 参数 | 作用 | 踩坑记录 |
|---|---|---|
--max-num-batched-tokens |
限制单次批处理token数 | 设太小影响吞吐，设太大显存爆 |
--max-num-seqs |
最大并发请求数 | 我一般设256，够用 |
--block-size |
KV Cache块大小 | 默认16，短序列场景可以改8 |
--swap-space |
CPU交换空间大小 | 显存不够时用，但性能下降明显 |
为什么会关注--block-size？因为KV Cache是按块分配的。块越小，内存碎片越少，但管理开销越大。我做过测试，对于平均长度512的短文本场景，块大小设8比16能省15%的显存。
4.3 模型加载与缓存：别每次都重新加载
模型加载是vLLM最耗时的环节之一。一个7B模型加载可能要30秒，70B模型得几分钟。你想想看，每次重启服务都等这么久，谁受得了？
4.3.1 模型加载方式
vLLM支持三种加载方式：
- 从HuggingFace直接加载：
--model meta-llama/Llama-2-7b-hf。第一次会下载，之后会缓存到~/.cache/huggingface。 - 从本地路径加载：
--model /models/llama-2-7b。我推荐这种方式，因为可以提前下载好，避免启动时网络波动。 - 从S3/GCS加载：需要额外配置，适合大规模集群。
重点：无论哪种方式，vLLM都会把模型权重加载到GPU显存。如果显存不够，它会尝试用CPU内存做swap，但性能会断崖式下降。
4.3.2 缓存机制
vLLM的缓存分为两层：
- 权重缓存：模型权重加载后，除非你手动清理，否则一直留在显存里。所以同一个模型重复加载不会额外耗时。
- KV Cache：这是动态分配的。每次推理请求都会占用一部分，请求结束后释放。但释放不是立即的，vLLM会保留一部分缓存来加速后续请求。
我曾经遇到过一个坑：服务跑了一天后，显存占用越来越高，最后OOM了。排查了半天，发现是--gpu-memory-utilization设得太高，KV Cache的缓存池把显存撑爆了。从那以后，我养成了一个习惯——监控显存使用趋势，而不是只看瞬时值。
4.3.3 缓存优化建议
# 启动时指定缓存目录
export VLLM_CACHE_DIR=/data/vllm_cache
docker run --gpus all \
-e VLLM_CACHE_DIR=/data/vllm_cache \
-v /data/vllm_cache:/data/vllm_cache \
...这样做的好处是：
- 缓存可以持久化，重启后不用重新下载模型
- 多个容器可以共享缓存，节省磁盘空间
- 方便清理——直接删目录就行
注意：缓存目录的磁盘空间要留够。一个7B模型大约15GB，70B模型要140GB。我见过有人把缓存放在根分区，结果磁盘满了，服务直接挂掉。
4.4 知识体系总览
这一章的内容比较多，我画了张图帮你理清思路：
这张图把三个核心模块串起来了。你从左边开始，先选好镜像，再配参数，最后搞定模型加载。每一步都跟显存挂钩——说白了，整个部署过程就是一场显存管理游戏。
最后说一句：配置这东西，没有银弹。我建议你每次改一个参数，然后跑个压测看看效果。别一次性改一堆，出了问题都不知道是哪个参数导致的。
公众号:蓝海资料掘金营，微信deep3321