使用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 的大模型跑起来了!
我们来品鉴一下这份日志里几个非常亮眼的数据:
📊 启动日志亮点分析
- 极速加载:
Loading weights took 22.04 seconds- 得益于你使用了
--load-format fastsafetensors和 Grace CPU 的超大内存带宽,73GB 的权重仅用 22 秒就加载完毕了!这在普通服务器上通常需要几分钟。
- 得益于你使用了
- 显存占用健康:
Model loading took 70.15 GiB memory- FP8 权重完美吃掉了 70GB 内存。
- 超大上下文并发:
Available KV cache memory: 30.76 GiB+Maximum concurrency for 32,768 tokens per request: 6.15x- 剩下的 30GB 内存全分给 KV Cache 了,这意味着你可以同时处理 6 个 32K 上下文的长请求,非常强力!
- 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 的回答非常精准,完美遵循了“三句话”的指令,说明模型权重加载和推理逻辑没有任何问题。
我们来看看后端日志透露出的几个有趣信息:
📊 日志分析
-
JIT 编译警告 (首次推理正常现象)
WARNING ... Triton kernel JIT compilation during inference: _compute_slot_mapping_kernel. This causes a latency spike...这是说 vLLM 在第一次遇到这个特定长度的请求时,临时编译了一个 Triton 算子。这会导致第一次请求变慢。 👉 建议:你可以再发一两次同样的请求,或者用 Python 写个循环发 3-5 次请求,把各种 token 长度都“暖”一遍,之后的推理速度就会稳定且飞快。
-
吞吐量数据
Avg generation throughput: 3.2 tokens/s生成速度大约是 3.2 tokens/s。对于在开发板上跑 72B 模型来说,这是一个非常实在的速度。如果后续开启了更底层的 Blackwell 算子优化,速度应该还能提升。
-
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.
- 常用容器管理命令速查
# 查看
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/内存占用