使用vLLM部署大模型

$ pip install -U "huggingface_hub[cli]"
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.
    
    If you wish to install a non-Debian-packaged Python package,
    create a virtual environment using python3 -m venv path/to/venv.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
    sure you have python3-full installed.
    
    If you wish to install a non-Debian packaged Python application,
    it may be easiest to use pipx install xyz, which will manage a
    virtual environment for you. Make sure you have pipx installed.
    
    See /usr/share/doc/python3.12/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

这个错误是因为你正在使用 ‌Ubuntu 23.04+‌、‌Debian 12+‌ 或其他遵循 ‌PEP 668‌ 标准的现代 Linux 发行版。系统为了保护自身稳定性，禁止直接使用 pip 向系统级 Python 环境中安装第三方包，以防止与系统包管理器（apt）发生冲突。

针对你想安装 huggingface_hub[cli] 的需求，以下是三种推荐解决方案，按‌推荐程度‌排序：

推荐使用虚拟环境（最推荐，标准做法）：
这是 Python 开发的最佳实践，既能隔离依赖，又不会破坏系统环境。

‌创建虚拟环境‌：

python3 -m venv hf-env

‌激活虚拟环境‌：

source hf-env/bin/activate

此时你的终端提示符前会出现 (hf-env)，表示已进入隔离环境。
‌在虚拟环境中安装‌：

pip install -U "huggingface_hub[cli]"

‌使用 CLI 工具‌：
只要虚拟环境处于激活状态，你就可以直接使用 hf 或 huggingface-cli 命令。

下载docker镜像：

# export LATEST_VLLM_VERSION=26.01-py3
# docker pull nvcr.io/nvidia/vllm:${LATEST_VLLM_VERSION}
sudo docker pull vllm/vllm-openai:nightly-aarch64

确认一下：

# $ sudo docker inspect nvcr.io/nvidia/vllm:${LATEST_VLLM_VERSION} | grep Architecture
 $ sudo docker inspect vllm/vllm-openai:nightly-aarch64 | grep Architecture
        "Architecture": "arm64",

如果此前有失败窗口，先清理：

sudo docker rm -f vllm-qwen

运行：

# 确保设置了 API Key
export VLLM_API_KEY=$(openssl rand -hex 32)
echo "你的 API Key 是: $VLLM_API_KEY"

# 启动容器
sudo docker run -d --name vllm-qwen \
  --gpus all \
  --ipc=host \
  --restart unless-stopped \
  -p 8000:8000 \
  -v $HOME/data/models:/models \
  -e HF_HUB_OFFLINE=1 \
  -e VLLM_API_KEY=$VLLM_API_KEY \
  vllm/vllm-openai:nightly-aarch64 \
  --model /models/Qwen2.5-72B-Instruct-FP8 \
  --served-model-name Qwen2.5-72B-Instruct \
  --host 0.0.0.0 \
  --port 8000 \
  --api-key $VLLM_API_KEY \
  --tensor-parallel-size 1 \
  --trust-remote-code \
  --kv-cache-dtype fp8 \
  --attention-backend flashinfer \
  --gpu-memory-utilization 0.85 \
  --max-model-len 32768 \
  --max-num-seqs 4 \
  --max-num-batched-tokens 8192 \
  --enable-chunked-prefill \
  --enable-prefix-caching \
  --load-format fastsafetensors

查看日志：

sudo docker logs -f vllm-qwen

启动成功：

(APIServer pid=1) INFO:     Started server process [1]
(APIServer pid=1) INFO:     Waiting for application startup.
(APIServer pid=1) INFO:     Application startup complete.

完整启动日志

下面是AI/glm5.2对日志的分析：

🎉🎉🎉 完美启动！大功告成！

太棒了！看到最后一行 Application startup complete.，意味着这台 GB10 已经成功把 72B 的大模型跑起来了！

我们来品鉴一下这份日志里几个非常亮眼的数据：

📊 启动日志亮点分析

1. 极速加载：Loading weights took 22.04 seconds
   • 得益于你使用了 --load-format fastsafetensors 和 Grace CPU 的超大内存带宽，73GB 的权重仅用 22 秒就加载完毕了！这在普通服务器上通常需要几分钟。
2. 显存占用健康：Model loading took 70.15 GiB memory
   • FP8 权重完美吃掉了 70GB 内存。
3. 超大上下文并发：Available KV cache memory: 30.76 GiB + Maximum concurrency for 32,768 tokens per request: 6.15x
   • 剩下的 30GB 内存全分给 KV Cache 了，这意味着你可以同时处理 6 个 32K 上下文的长请求，非常强力！
4. Blackwell 专属优化生效：
   • Using AttentionBackendEnum.FLASHINFER backend (FlashInfer 注意力后端启动)
   • Using fp8 data type to store kv cache (KV Cache 也被压缩成 FP8 了，极其省内存)

---

🚀 现在立刻测试一下！

不要停，趁着服务正在运行，开一个新终端窗口，发个请求测试一下它的智商和速度：

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $VLLM_API_KEY" \
  -d '{
    "model": "Qwen2.5-72B-Instruct",
    "messages": [{"role": "user", "content": "用三句话解释什么是统一内存架构，并说明它对AI推理的好处。"}],
    "max_tokens": 300,
    "temperature": 0.7
  }'

如果能看到 Qwen 流畅的回复，那就彻底打通了全流程！

---

💡 关于日志里的一条小提示（可选）

日志里有这么一句：

WARNING ... Default vLLM sampling parameters have been overridden by the model's `generation_config.json`: `{'repetition_penalty': 1.05, 'temperature': 0.7, 'top_k': 20, 'top_p': 0.8}`. If this is not intended, please relaunch vLLM instance with `--generation-config vllm`.

这是说 Qwen 官方的默认生成配置（温度 0.7，top_p 0.8 等）覆盖了 vLLM 的默认值。这通常是好事，能让模型按照官方调好的性格说话。如果你以后想要纯粹由 API 参数控制，可以加上 --generation-config vllm，但现在不用管它。

---

辛苦了！从下载踩坑、网络重连、到驱动版本不匹配换镜像，一路过关斩将。好好享受这台强大的 Blackwell 机器带来的极致推理体验吧！有什么使用上的问题随时交流！

上述测试返回：

{"id":"chatcmpl-b773b0fe715a2447","object":"chat.completion","created":1782311775,"model":"Qwen2.5-72B-Instruct",
"choices":[{"index":0,"message":{"role":"assistant","content":"统一内存架构是一种内存管理技术，它允许CPU和GPU等不同处理器共享同一块物理内存空间，
无需数据在各自独立的内存之间复制传输。这种架构显著减少了数据交换的延迟，提高了处理效率，特别是在需要频繁交换大量数据的应用中，如深度学习模型的推理过程。
因此，统一内存架构能够加速AI推理的速度，同时简化编程复杂度，使得开发和优化更加高效。",
"refusal":null,"annotations":null,"audio":null,"function_call":null,"tool_calls":[],"reasoning":null},"logprobs":null,
"finish_reason":"stop","stop_reason":null,"token_ids":null,"routed_experts":null}],
"service_tier":null,"system_fingerprint":"vllm-0.23.1rc1.dev301+g04c2a8dea-68441cd4","usage":"prompt_tokens":45,
"total_tokens":134,"completion_tokens":89,"prompt_tokens_details":null},"prompt_logprobs":null,"prompt_token_ids":null,
"prompt_text":null,"kv_transfer_params":null}

log显示：

(EngineCore pid=138) WARNING 06-24 14:36:15 [jit_monitor.py:106] Triton kernel JIT compilation during inference: _compute_slot_mapping_kernel. This causes a latency spike; consider extending warmup to cover this shape/config.
(APIServer pid=1) INFO 06-24 14:36:23 [loggers.py:273] Engine 000: Avg prompt throughput: 4.5 tokens/s, Avg generation throughput: 2.2 tokens/s, Running: 1 reqs, Waiting: 0 reqs, GPU KV cache usage: 0.0%, Prefix cache hit rate: 0.0%
(APIServer pid=1) INFO 06-24 14:36:33 [loggers.py:273] Engine 000: Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 3.2 tokens/s, Running: 1 reqs, Waiting: 0 reqs, GPU KV cache usage: 0.1%, Prefix cache hit rate: 0.0%
(APIServer pid=1) INFO 06-24 14:36:43 [loggers.py:273] Engine 000: Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 3.1 tokens/s, Running: 1 reqs, Waiting: 0 reqs, GPU KV cache usage: 0.1%, Prefix cache hit rate: 0.0%
(APIServer pid=1) INFO:     172.17.0.1:49252 - "POST /v1/chat/completions HTTP/1.1" 200 OK

AI/glm-5.2解析如下：

🎉 完美通关！模型回复完全正确！

恭喜！从大模型下载、环境配置、镜像踩坑到最终跑通，整个链路彻底打通了！Qwen2.5-72B 的回答非常精准，完美遵循了“三句话”的指令，说明模型权重加载和推理逻辑没有任何问题。

我们来看看后端日志透露出的几个有趣信息：

📊 日志分析

1. JIT 编译警告 (首次推理正常现象)

   WARNING ... Triton kernel JIT compilation during inference: _compute_slot_mapping_kernel. This causes a latency spike...

   这是说 vLLM 在第一次遇到这个特定长度的请求时，临时编译了一个 Triton 算子。这会导致第一次请求变慢。 👉 建议：你可以再发一两次同样的请求，或者用 Python 写个循环发 3-5 次请求，把各种 token 长度都“暖”一遍，之后的推理速度就会稳定且飞快。

2. 吞吐量数据

   Avg generation throughput: 3.2 tokens/s

   生成速度大约是 3.2 tokens/s。对于在开发板上跑 72B 模型来说，这是一个非常实在的速度。如果后续开启了更底层的 Blackwell 算子优化，速度应该还能提升。

3. KV Cache 和 Prefix Cache

   GPU KV cache usage: 0.1%, Prefix cache hit rate: 0.0%

   内存非常充裕，只用了 0.1% 的 KV 缓存。Prefix cache 还没命中是因为这是第一次问这个问题，如果你再问一遍同样的话，Prefix cache hit rate 就会变成 100%，处理速度会瞬间提升。

• 注：第一次使用的是 nvcr.io/nvidia/vllm:26.01-py3镜像：

sudo docker run -d --name vllm-qwen \
  --gpus all \
  --ipc=host \
  --restart unless-stopped \
  -p 8000:8000 \
  -v $HOME/data/models:/models \
  -e HF_HUB_OFFLINE=1 \
  -e VLLM_API_KEY=$VLLM_API_KEY \
  nvcr.io/nvidia/vllm:26.01-py3 \
  --model /models/Qwen2.5-72B-Instruct-FP8 \
  --served-model-name Qwen2.5-72B-Instruct \
  --host 0.0.0.0 \
  --port 8000 \
  --api-key $VLLM_API_KEY \
  --tensor-parallel-size 1 \
  --trust-remote-code \
  --kv-cache-dtype fp8 \
  --attention-backend flashinfer \
  --gpu-memory-utilization 0.85 \
  --max-model-len 32768 \
  --max-num-seqs 4 \
  --max-num-batched-tokens 8192 \
  --enable-chunked-prefill \
  --enable-prefix-caching \
  --load-format fastsafetensors

结果报错：

ERROR: This container was built for NVIDIA Driver Release 590.48 or later, but
       version 580.159.03 was detected and compatibility mode is UNAVAILABLE.

再试一个35B的大模型：

# 1. HF Token(下载模型用)
export HF_TOKEN="hf_hxxxxx"

# 2. 确认 VLLM_API_KEY 还在(之前设置的)
export VLLM_API_KEY=$(openssl rand -hex 32)
echo "你的 API Key 是: $VLLM_API_KEY"

# 3. 启动(加上了 API Key)
sudo docker run -d --name vllm-qwen3-nvfp4 \
  --gpus all \
  --ipc=host \
  -p 8001:8000 \
  -e HF_TOKEN="$HF_TOKEN" \
  -e VLLM_API_KEY="$VLLM_API_KEY" \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:nightly-aarch64 \
  nvidia/Qwen3.6-35B-A3B-NVFP4 \
  --host 0.0.0.0 \
  --port 8000 \
  --api-key "$VLLM_API_KEY" \
  --tensor-parallel-size 1 \
  --trust-remote-code \
  --kv-cache-dtype fp8 \
  --attention-backend flashinfer \
  --moe-backend marlin \
  --gpu-memory-utilization 0.4 \
  --max-model-len 262144 \
  --max-num-seqs 4 \
  --max-num-batched-tokens 8192 \
  --enable-chunked-prefill \
  --async-scheduling \
  --enable-prefix-caching \
  --speculative-config '{"method":"mtp","num_speculative_tokens":3,"moe_backend":"triton"}' \
  --load-format fastsafetensors \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_xml \
  --enable-auto-tool-choice

• 常用容器管理命令速查

# 查看
sudo docker ps                    # 运行中的
sudo docker ps -a                 # 所有的

# 停止 / 启动 / 重启
sudo docker stop vllm-qwen        # 停止(保留)
sudo docker start vllm-qwen       # 启动已停止的
sudo docker restart vllm-qwen     # 重启

# 删除
sudo docker rm vllm-qwen          # 删除已停止的容器
sudo docker rm -f vllm-qwen       # 强制删除(运行中也删)

# 日志
sudo docker logs -f vllm-qwen     # 实时日志
sudo docker logs --tail 50 vllm-qwen  # 最后 50 行

# 资源监控
sudo docker stats                 # 看所有容器的 CPU/内存占用