H200 GPU 服务器部署大语言模型：从容器、显存规划到多机推理

H200 的优势不仅是大显存，还包括高带宽 HBM、GPU 间高速互联和适合多机训练/推理的网络能力。真正部署大语言模型时，需要同时处理模型权重、KV Cache、激活值、通信缓冲、CPU 内存、网络拓扑和服务并发。

版本说明：模型名称、精度、上下文长度和 vLLM 参数会随版本变化。下面命令是可操作的基线模板，生产使用前应在目标模型、目标驱动和目标 CUDA 版本上做兼容性验证。

#一、先做显存与并行规划

模型权重的理论显存约为：参数量乘以每参数字节数。FP16/BF16 通常约 2 字节，FP8 约 1 字节，INT4 权重约 0.5 字节，但实际还要加上量化元数据、运行时工作区和 KV Cache。

KV Cache 与序列长度、并发请求数、层数、注意力头数和 KV 头数有关。上下文越长、并发越高，KV Cache 占用越大。H200 的大显存允许更高并发或更长上下文，但不能把全部显存分配给权重。

建议先回答这些问题：

1. 模型参数量和权重精度是什么？
2. 最大输入加最大输出 token 数是多少？
3. 目标并发、首 token 延迟和 token 吞吐是多少？
4. 单机八卡能否容纳权重和 KV Cache？
5. 需要 Tensor Parallel、Pipeline Parallel 还是 Data Parallel？
6. GPU 间是 NVLink/NVSwitch，节点间是 InfiniBand 还是 Ethernet？

#二、准备 Linux、驱动和容器运行时

宿主机只安装 NVIDIA 驱动，CUDA runtime 和框架优先放在经过验证的容器中。这样可以减少宿主机 Python、CUDA 库和系统包互相污染。

# 确认驱动和 GPU 状态
nvidia-smi
nvidia-smi topo -m

# 安装 NVIDIA Container Toolkit 后验证容器能看到 GPU
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04   nvidia-smi

容器验证失败时先检查 Docker runtime、驱动版本、设备节点和用户权限。不要在容器里再安装一个与宿主机冲突的内核驱动；容器使用宿主机 NVIDIA 内核模块。

#三、准备模型和缓存目录

模型目录应放在本地 NVMe 或高性能并行文件系统，避免每个容器启动时重复下载。生产环境固定模型 revision，并记录文件校验和。

# 创建只允许服务用户访问的缓存目录
sudo install -d -o 1000 -g 1000 -m 0750 /srv/models /srv/hf-cache

# 通过环境变量指定缓存位置，避免写入容器临时层
export HF_HOME=/srv/hf-cache
export HUGGING_FACE_HUB_TOKEN=replace-with-a-short-lived-token

# 预下载模型，实际模型名和 revision 按授权替换
huggingface-cli download org/model-name   --revision main   --local-dir /srv/models/model-name

令牌不要写进镜像、Shell 历史或 Git。受限网络环境可以使用内部镜像仓库或离线制品，不要为了下载模型关闭 TLS 验证。

#四、用 vLLM 启动单机多卡推理

vLLM 适合将模型暴露为 OpenAI 兼容 API。单机八卡的第一步不是直接把 tensor-parallel-size 设置成 8，而是先确认八卡拓扑、模型尺寸和服务端口。

# 查看八卡、显存和拓扑
nvidia-smi --list-gpus
nvidia-smi topo -m

# 启动单机多卡服务，参数需按模型实际能力调整
docker run --rm --gpus all --ipc=host --shm-size=32g   -p 8000:8000   -v /srv/models:/models:ro   -v /srv/hf-cache:/root/.cache/huggingface   -e HF_TOKEN="$HUGGING_FACE_HUB_TOKEN"   vllm/vllm-openai:latest   --model /models/model-name   --tensor-parallel-size 8   --dtype bfloat16   --served-model-name model-name   --max-model-len 32768   --gpu-memory-utilization 0.90   --host 0.0.0.0 --port 8000

参数解释：

• tensor-parallel-size 表示把单个模型层的计算和权重切分到多少张 GPU。
• dtype=bfloat16 通常适合支持 BF16 的数据中心 GPU，最终以模型和框架支持为准。
• max-model-len 会影响 KV Cache 上限，过大可能导致并发下降或 OOM。
• gpu-memory-utilization 不是越高越好，应给 CUDA graph、通信 buffer 和碎片留下空间。
• ipc=host 和足够的 shm-size 有助于多进程通信，但容器权限应按安全策略评估。

#五、OpenAI 兼容接口和基本验证

# 检查服务是否就绪
curl -f http://127.0.0.1:8000/health

# 查看模型列表
curl -s http://127.0.0.1:8000/v1/models | jq

# 发送一条最小请求
curl -s http://127.0.0.1:8000/v1/chat/completions   -H 'Content-Type: application/json'   -d '{
    "model": "model-name",
    "messages": [{"role": "user", "content": "用一句话解释 NUMA。"}],
    "temperature": 0.2,
    "max_tokens": 64
  }' | jq

上线前还要验证流式输出、超时、并发限制、错误码、上下文截断、中文输入、长文本和恶意提示。不要仅凭一次 curl 成功就判定服务可用。

#六、多机部署与 InfiniBand/NCCL

多机推理需要每台机器加载相同模型和兼容的容器，节点之间需要稳定的高速网络。Tensor Parallel 跨节点会频繁交换张量，网络延迟和带宽直接影响 token 吞吐；如果模型允许，优先把高频通信留在同一 NVLink/NVSwitch 域内。

# 在每个节点检查 HCA、端口和 RDMA
ibdev2netdev
ibstat
ibv_devinfo

# NCCL 调试环境变量，接口和 HCA 按实际拓扑替换
export NCCL_DEBUG=INFO
export NCCL_IB_DISABLE=0
export NCCL_SOCKET_IFNAME=ib0
export NCCL_IB_HCA=mlx5_0:1
export NCCL_NET_GDR_LEVEL=2

# 运行 nccl-tests 验证 AllReduce，再启动模型服务
./build/all_reduce_perf -b 8 -e 4G -f 2 -g 8

如果 NCCL 退化到 TCP，常见原因包括 HCA 名称错误、端口未 ACTIVE、容器没有映射 RDMA 设备、节点间路由不通、驱动与 OFED 不匹配或 GPU/HCA NUMA 绑定不合理。先用 perftest 和 nccl-tests 定位，再看 vLLM 日志。

#七、生产服务化建议

#1. systemd 或 Kubernetes 管理

单机可用 systemd 或 Docker Compose 管理重启、日志和资源；集群环境建议用 Kubernetes 调度 GPU，并使用 NVIDIA device plugin 或 GPU Operator。部署清单应声明 GPU 资源、readinessProbe、livenessProbe、优雅退出和滚动更新策略。

resources:
  limits:
    nvidia.com/gpu: 8
readinessProbe:
  httpGet:
    path: /health
    port: 8000
  initialDelaySeconds: 30
  periodSeconds: 10

#2. 监控和容量保护

至少监控 GPU 利用率、显存、温度、功耗、Xid、请求队列、首 token 延迟、生成 token 吞吐、错误率和 OOM 次数。限制最大并发和最大请求 token，避免一个长上下文请求耗尽整个 KV Cache。

# 持续采集关键 GPU 指标
nvidia-smi dmon -s pucm -d 5

# 查看服务容器日志
docker logs --tail=200 -f llm-server

#3. 常见故障排查顺序

• 启动即 OOM：降低 max-model-len、并发和显存占用比例，确认模型精度与 tensor parallel 配置。
• 多卡通信慢：检查 nvidia-smi topo -m、NCCL 日志、HCA、NUMA 和 RDMA 计数器。
• 请求超时：区分模型加载、首 token、生成阶段和网络代理超时。
• 输出异常：确认 tokenizer、chat template、模型 revision 和服务参数匹配。
• GPU 不可见：检查宿主机 nvidia-smi、容器 --gpus all、NVIDIA Container Toolkit 和设备权限。

最终上线前应做固定数据集压测、长上下文压测、故障重启演练和模型回滚演练，并把驱动、容器、模型 revision、配置和硬件拓扑记录进发布单。

#容量基线与故障演练

上线前固定模型 revision、容器 digest 和测试集，分别测试短、中、长上下文，并记录首 token 延迟、生成吞吐、显存峰值和错误率。readiness 必须在模型加载完成后才成功；超出上下文或并发上限应返回明确错误；OOM 时优先降低上下文、并发或显存比例。