在独享 GPU 上用 vLLM 提供 LLM 推理服务

选择推理引擎

• vLLM：支持广泛的模型，提供 OpenAI 兼容的服务端，有 NVIDIA 和 AMD（ROCm）版本。本指南后续内容均以它为例。
• SGLang：另一个提供 OpenAI 兼容 API 的开源引擎，用 python -m sglang.launch_server --model-path <model> --tp 2 启动；默认监听 127.0.0.1:30000。参见 SGLang 文档。
• TensorRT-LLM：NVIDIA 专为自家 GPU 打造的引擎；trtllm-serve <model> 会开放一个 OpenAI 兼容的接口。参见 TensorRT-LLM 文档。

先按显存来决定 GPU 规模。权重在 BF16 下大约每个参数占用 2 字节（一个 70B 模型约需 140 GB），FP8 下为 1 字节，4-bit 格式下约为半字节。KV 缓存是在此基础上额外增加的部分，会随上下文长度和并发请求数增长。GPU 选型助手会列出适合某个模型的配置方案。

安装 vLLM 并部署第一个模型

按照 vLLM 安装指南的建议，为它创建一个独立的 Python 环境。让模型下载保存在 NVMe 数据盘上：

curl -LsSf https://astral.sh/uv/install.sh | sh     # 然后开一个新终端，让 uv 出现在 PATH 中
uv venv --python 3.12 --seed --managed-python ~/vllm-env
source ~/vllm-env/bin/activate
uv pip install vllm --torch-backend=auto

export HF_HOME=/data/hf                            # 模型缓存放在 NVMe 上
export VLLM_API_KEY=$(openssl rand -hex 32)        # 客户端必须发送这个密钥
echo "$VLLM_API_KEY"                               # 记下它，供客户端使用
vllm serve Qwen/Qwen3-4B --host 127.0.0.1 --port 8000 --max-model-len 8192

在 tmux 中运行服务端（参见 SSH 访问）。需要授权的模型要用 Hugging Face 令牌：执行 hf auth login，或在环境变量中设置 HF_TOKEN。在服务器上打开第二个终端进行测试，同样要导出这个密钥：

curl -s http://127.0.0.1:8000/v1/models -H "Authorization: Bearer $VLLM_API_KEY"

curl -s http://127.0.0.1:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $VLLM_API_KEY" \
  -d '{"model": "Qwen/Qwen3-4B", "messages": [{"role": "user", "content": "Say hello in five words."}], "max_tokens": 64}'

只需把 base_url="http://127.0.0.1:8000/v1"、api_key 设为您的密钥，任何 OpenAI 客户端都能使用。

将模型拆分到 2、4 或 8 块 GPU 上

vllm serve Qwen/Qwen3-32B --tensor-parallel-size 2 --host 127.0.0.1 --port 8000
vllm serve <model> --tensor-parallel-size 8 --host 127.0.0.1 --port 8000

• 张量并行会把每一层都拆分到各个 GPU 上，并在每一步之间交换数据。并行度必须能整除模型的注意力头数；常用取值是 2、4 和 8。
• 在有 NVLink 和 NVSwitch 的平台上（8 块 GPU 的 H100、H200、B200、B300 服务器），张量并行是默认选择。
• 没有 NVLink 的情况下（L40S、RTX PRO 6000、GeForce 显卡），vLLM 的并行指南建议使用流水线并行（--pipeline-parallel-size）以获得更高吞吐量。请在您自己的模型上比较两种方式。
• 如果模型在更少的 GPU 上就能放下，运行多个副本通常比运行一个大实例能处理更多请求：可以用 --data-parallel-size，或者用 CUDA_VISIBLE_DEVICES 把独立的服务端固定在不同端口上。

多 GPU 环境的配置方法参见多 GPU。

FP8 与 4-bit 量化

# 从 BF16 检查点即时转换为 FP8（不需要校准数据）
vllm serve Qwen/Qwen3-32B --quantization fp8 --host 127.0.0.1

# 预量化的检查点会根据其配置自动识别
vllm serve Qwen/Qwen3-32B-AWQ --host 127.0.0.1

# FP8 KV 缓存：每 GB 能容纳更多上下文或更多并发请求
vllm serve Qwen/Qwen3-32B --kv-cache-dtype fp8 --host 127.0.0.1

质量损失取决于模型和任务。切换之前，先用您自己的提示词把量化模型和原始模型做对比。vLLM 的量化文档列出了各种方法分别支持哪些硬件。

在 Docker 中运行 vLLM

docker run --rm --runtime nvidia --gpus all \
  -v /data/hf:/root/.cache/huggingface \
  --env "HF_TOKEN=$HF_TOKEN" --env "VLLM_API_KEY=$VLLM_API_KEY" \
  -p 127.0.0.1:8000:8000 \
  --ipc=host \
  vllm/vllm-openai:latest \
  --model Qwen/Qwen3-4B --max-model-len 8192

该镜像运行的是 vllm serve，所以镜像名之后的参数都会传给 vLLM。请把端口发布在 127.0.0.1 上：Docker 的端口规则会绕过 ufw。在 MI355X 上，使用 vllm/vllm-openai-rocm，并用 --device /dev/kfd --device /dev/dri --group-add=video 代替 --gpus（参见 vLLM 的 Docker 文档和容器）。

安全地对外开放接口

vLLM 的安全指南说得很明确：--api-key 只保护 /v1、/v2 和 /inference 路由，同一服务器上的其他路由——包括某些会运行推理的路由——都没有身份验证。绝不要把 vLLM 的端口直接开放出去。请选择以下两种方式之一。

SSH 隧道：适合个人和小团队

# 在您自己的电脑上执行；之后 API 就在 http://localhost:8000/v1
ssh -N -L 8000:127.0.0.1:8000 gpu1

带 TLS 的反向代理：适合公开接口

把一个 DNS 名称指向服务器，从其官方仓库安装 Caddy，只转发 /v1/ 路由。Caddy 会自动获取并续期 TLS 证书；vLLM 会对每个转发过来的请求检查 API 密钥。

sudo tee /etc/caddy/Caddyfile >/dev/null <<'EOF'
llm.example.com {
    handle /v1/* {
        reverse_proxy 127.0.0.1:8000
    }
    handle {
        respond 404
    }
}
EOF
sudo systemctl reload caddy
sudo ufw allow 80,443/tcp

查看 GPU 利用率

nvidia-smi dmon -s um                         # 利用率和显存占用，每个 GPU 每秒一行
nvidia-smi --query-gpu=index,utilization.gpu,memory.used,memory.total,power.draw --format=csv -l 5
nvtop                                         # 交互式视图（较新版本也能显示 AMD GPU）
watch -n 2 amd-smi monitor                    # AMD MI355X
curl -s http://127.0.0.1:8000/metrics | grep -E '^vllm:(num_requests_running|num_requests_waiting|kv_cache_usage_perc)'

vLLM 启动时会为 KV 缓存预留大部分显存（--gpu-memory-utilization），所以显存占用高是正常现象，并不能说明负载情况。nvidia-smi 里的 GPU-Util 是内核处于运行状态的时间占比，不是 GPU 计算能力被使用的比例。

应该关注运行中和等待中的请求数，以及 KV 缓存的使用率（参见 vLLM 指标说明）。如果缓存快满了，等待中的请求还在堆积，就说明您需要更多 GPU、一个量化模型，或者更短的上下文。