Qwen2.5-7B 在 vLLM 上“跑起来”本身不难，难的是在私有化环境中把它跑稳：不 OOM、不把长上下文配成显存炸弹、不让张量并行和 block size 在初始化阶段互斥。以下从硬件选型、启动参数到生产化配置，整理一条可复现的部署路径。
硬件水位：24GB 是舒适线，16GB 是下限
Qwen2.5-7B-Instruct 在 FP16 精度下权重本身约 14GB。vLLM 还需要预留 KV Cache、激活和工作区，24GB 显存（RTX 4090 / 3090 / A5000）是推荐配置，16GB 是勉强可用的下限。如果使用 AWQ 或 GPTQ 4-bit 量化，显存门槛可以显著下降：AWQ INT4 在 4090 上可以将峰值显存从 FP16 的约 17GB 压到 9GB 左右，同时保留可用的输出质量。
CUDA 版本需要 ≥ 11.8 并完整安装 cuDNN；vLLM 对 CUDA 运行时版本比较敏感，CUDA 12.3 及以上在部分旧版 vLLM 中曾导致 PagedAttention 初始化失败，生产环境建议锁定在 vLLM 官方镜像对应的 CUDA 12.1/12.2 组合。
启动命令：三个参数决定 OOM 与否
一个最小可用的 OpenAI 兼容服务启动命令如下：
bash
vllm serve Qwen/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --max-model-len 8192 \ --gpu-memory-utilization 0.90 \ --dtype bfloat16--max-model-len是最容易出问题的参数。Qwen2.5-7B 原生支持 32K 上下文，可外推到 128K，但 vLLM 会按max_model_len预留 KV Cache。在 16GB 卡上保持默认 32768 几乎必然 OOM，应降到 4096 或 8192；在 24GB 卡上如果业务不需要超长文本，8192–16384 是更务实的选择。--gpu-memory-utilization控制模型权重和 KV Cache 对显存的占用比例，0.90 是常用起点；OOM 时不要只降这个值，先确认max_model_len是否合理。
如果需要量化，AWQ 模型用--quantization awq或awq_marlin加载。awq_marlin在支持时推理更快，但如果显式指定quantization=awq，vLLM 会强制走通用 AWQ 路径。GPTQ-Int4 在 4090 上的实测吞吐可以到 154 tok/s 左右，但这是特定输入输出长度和 batch 条件下的数字，不能直接当作生产承诺。
张量并行与 block size 的兼容性坑
多卡部署时，--tensor-parallel-size不总是和任意--block-size组合兼容。有记录显示 Qwen2.5-7B-Instruct 在TP=4且block_size=8时引擎初始化失败，报 “No common block size for 8”；原因是 KV Cache 的内存布局在 4 路切分下无法对齐到 block size 8。这不是模型 bug，而是需要按模型选择合法的 block size。在 TP>1 的场景下，优先使用默认 block size 或 16 / 32，避免在 8 这种较小粒度上冒险。
如果确实需要调小 block size 来匹配显存或缓存行为，先在单卡上验证模型是否支持，再上多卡。
Docker 部署的生产化细节
Docker 是最省环境依赖的路径，但有几个参数需要显式加上：
bash
docker run --gpus all \ -p 8000:8000 \ --ipc=host \ --shm-size=8g \ -v /data/models:/models \ vllm/vllm-openai:latest \ --model /models/Qwen2.5-7B-Instruct \ --max-model-len 8192 \ --gpu-memory-utilization 0.90--ipc=host或足够大的--shm-size是必须的：vLLM 的 worker 进程之间通过共享内存传递张量，默认 64MB 的/dev/shm在高并发或长上下文下会触发共享内存相关的静默失败。模型路径要避免中文和空格；vLLM 启动时会递归扫描模型目录下的config.json、pytorch_model.bin.index.json等文件，路径异常会在权重加载阶段报出难以定位的OSError。
上线前的四个检查项
第一，显存水位：在压测流量下用nvidia-smi观察峰值显存，而不是只看启动成功后的空闲值。KV Cache 是在请求到达后逐步占用的。
第二，首 token 延迟（TTFT）：7B 模型在 4090 上经过参数调优后 TTFT 可以压到 800ms 以内，但默认配置往往在 1s 以上。如果业务对交互延迟敏感，--enforce-eager在小 batch 场景下可能比 CUDA Graph 更稳，值得实测对比。
第三，量化精度回归：AWQ / GPTQ 不是无损的。上线前用业务 prompt 集做一次人工抽检，重点看结构化输出、代码生成和长文本摘要是否出现明显的质量漂移。
第四，版本锁定：vLLM、CUDA、PyTorch 三者的版本组合一旦验证通过，就用镜像或依赖锁文件固定下来。vLLM 迭代很快，不同版本对block-size、quantization参数的校验逻辑可能不同，未经测试的升级是私有化部署中最常见的“昨天还好好的”来源。
Qwen2.5-7B 在 vLLM 上的私有化部署，本质上是一个显存水位管理问题：max_model_len决定 KV Cache 的上界，量化格式决定权重占用的下界，张量并行和 block size 决定多卡下能否正常初始化。把这几个参数按硬件和业务场景钉死，剩下的就是压测和版本锁定的常规工程工作
本文实践项目由洛阳澜荣科技完成，团队位于洛阳洛龙，专注YOLO工业视觉、大模型微调、内网私有化RAG知识库落地。 技术原文首发：https://www.golamp.cn
