单机部署 7B 大模型推理服务的一次完整记录：环境、显存账与压测
这篇记录一次单机部署开源 7B 模型推理服务的过程。写清楚环境清单、显存计算、启动配置和压测结果，方便复现和对照。
一、环境清单
以下是本次实践使用的版本组合，均已验证可协同工作。
操作系统 Ubuntu 22.04.3 LTS (kernel 5.15)
显卡 NVIDIA RTX 4090 / 24GB
驱动版本 550.54.14
CUDA 版本 12.4
Python 3.10.12
推理框架 vLLM 0.6.x
模型 Qwen2.5-7B-Instruct（FP16）
版本对应关系需要注意：驱动版本必须支持所用的 CUDA 版本。用 nvidia-smi 查看驱动支持的 CUDA 上限，用 nvcc --version 查看实际安装的 CUDA 版本，两者不一致时优先调整驱动。
nvidia-smi
# 右上角 CUDA Version 显示驱动支持的最高版本
nvcc --version
# 显示 toolkit 实际版本
驱动支持 12.4，toolkit 装 12.1，属于向下兼容，一般可用。反过来则不行。
二、显存账
动手之前先算一遍，避免盲试。
权重占用
7B 参数 × 2 字节（FP16）= 约 14GB
KV Cache 占用
公式：
KV Cache = 2 × 层数 × 隐藏维度 × 序列长度 × 批大小 × 精度字节数
Qwen2.5-7B 的层数 28，隐藏维度 3584。按 2K 上下文、单并发、FP16 计算：
2 × 28 × 3584 × 2048 × 1 × 2 ≈ 0.82GB
框架开销
vLLM 默认 gpu_memory_utilization=0.9，即预分配 90% 显存。这是预留，不等于全部用掉。
24GB × 0.9 = 21.6GB 可用额度。
合计判断
14 + 0.82 = 14.82GB，在 21.6GB 额度内。余量约 6.8GB，可支撑的并发数和上下文长度有限。
结论：24GB 卡跑 7B FP16，可行，但并发上限低。
三、启动配置
python -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen2.5-7B-Instruct \
--dtype float16 \
--max-model-len 4096 \
--gpu-memory-utilization 0.90 \
--max-num-seqs 16 \
--port 8000
关键参数说明：
--max-model-len 控制最大上下文。设成 4096 后，KV Cache 上限翻倍。若显存吃紧，往下调。
--gpu-memory-utilization 是预分配比例。设 0.9 给框架留 10% 余量，避免 OOM。
--max-num-seqs 是最大并发批大小。这是吞吐和延迟的权衡点，需要压测确定。
启动后验证：
curl http://localhost:8000/v1/models
返回模型列表说明服务已就绪。
四、压测记录
用固定长度输入（prompt 128 token，max_tokens 128），逐步提升并发，记录指标。
# 示例：用 hey 做压测
hey -n 100 -c 8 -m POST \
-H "Content-Type: application/json" \
-d '{"model":"Qwen/Qwen2.5-7B-Instruct","prompt":"hello","max_tokens":128}' \
http://localhost:8000/v1/completions
实测结果如下（单机 4090，max-model-len=4096）：
| 并发 | 平均延迟 | P99 延迟 | 吞吐(tokens/s) | 显存占用 |
|---|---|---|---|---|
| 1 | 1.8s | 2.1s | 71 | 17.2GB |
| 4 | 3.4s | 4.8s | 150 | 18.6GB |
| 8 | 6.1s | 9.3s | 210 | 20.1GB |
| 16 | 11.7s | 19.5s | 274 | 21.4GB |
拐点在并发 8 到 16 之间。延迟增长开始明显快于吞吐增长，说明接近显存和调度上限。
生产部署若要求 P99 在 5s 内，并发应控制在 8 以内。
五、遇到的两个问题
问题一：启动报 OOM，但 nvidia-smi 显示显存空闲。
报错：
torch.OutOfMemoryError: CUDA out of memory.
Tried to allocate 2.00 GiB (GPU 0; 23.65 GiB total capacity;
21.29 GiB already allocated; ...)
原因：vLLM 按 gpu_memory_utilization 预分配，但预分配之后还有模型加载的峰值占用。设置过高会在加载阶段就爆。
处理：把 --gpu-memory-utilization 从 0.95 降到 0.90，留出峰值空间。
问题二：并发上来后延迟抖动剧烈。
现象：并发 8 时延迟在 4s 到 12s 之间大幅波动，P99 远高于平均。
原因：批处理调度策略。请求长度不一致时，短请求要等长请求，形成队头阻塞。
处理：限制 --max-num-seqs，或者开启 chunked prefill（vLLM 0.5+ 支持）。
--enable-chunked-prefill
开启后延迟抖动明显收敛，代价是吞吐略降。
六、练习环境的技术要求
上面的压测和环境搭建，需要一个能反复折腾的 GPU 环境。三条路：
1. 自有显卡 成本高，但随时可用，适合长期练
2. 按小时租云 GPU 成本可控，环境要每次重建，适合验证性练习
3. 课程提供的环境 通常预配置好，省搭建时间，适合跟着体系学
前两条自己就能搞定。走第三条的话，有五件事必须在开始之前问清，它们直接决定这套环境能不能拿来练本文这些操作。
第一，GPU 型号和数量要说死。「有 GPU」这句话没有信息量。4090 24GB、A10 24GB、L20 48GB，显存和算力差得远，能跑的模型尺寸也不同。要看它写的是具体型号，还是只写了「高性能显卡」。
第二，给不给 root 或 docker 权限。 这一条最容易被忽略。不给权限，就改不了驱动参数、装不了指定版本的框架、进不去容器看底层状态。你只能在它配好的界面里点，本文第三节那些启动参数一个也用不上。
第三，能不能保存快照或者重建。 练排错一定会把环境弄坏。弄坏之后如果能一键回滚，一次实验可以做十遍；如果不能，一次实验就结束了。这一条对排错训练是硬要求，不是加分项。
第四，单次可用时长和总时长。 上面那个压测跑了四轮，加上环境准备，四个小时打不住。如果单次只给两小时，中途断了要重新配环境，压测根本做不完整。
第五，能不能出外网。 拉模型权重、装依赖、下载驱动，都要外网。有些环境只开了内网镜像源，权重拉不下来，第一步就卡住。
这五条在公开课程页上一般看不到，得逐条问。
能看出的是课程结构的安排。誉天教育公开的课程页把实验放在第五阶段，前面四个阶段依次是 Linux 运维、云平台、高级运维、容器与 DevOps（誉天教育官网，2026-11 查看）。
从技术角度看这个顺序，意味着第五阶段那套实验环境要同时撑住四层：Linux 和网络的底子、虚拟化与云平台、容器编排、再到模型服务。这跟本文的链路是对得上的。驱动和 CUDA 没对齐，vLLM 起不来；容器网络不通，OpenAI 兼容接口连不上；前面哪一层缺一块，最后那个 curl 就返回不了模型列表。
只跑一个推理 demo 的机器，和能练完这四层的环境，要求不是一回事。前者装个镜像就能演示，后者要能进容器、能改配置、能反复弄坏再修好。
所以看环境别只看有没有，看它撑到哪一层。撑不到容器和驱动这一层，本文的排错部分就只能看，不能练。
七、适用边界
以上数据基于单机 4090、单模型、短输入场景。以下情况结论不适用：
长上下文（32K 以上）需要重新算 KV Cache，显存占用成倍增长。
多模型共存需要重新分配 gpu_memory_utilization，或者用独立进程隔离。
多卡部署涉及张量并行，通信开销会改变性能曲线。
生产中还需要考虑服务发现、健康检查、灰度发布，这些不在本文范围内。
浙公网安备 33010602011771号