项目
调用大模型推理
在 A100 上部署了 Qwen3-8B,记下如何调用大模型推理,以及一些知识点。
项目设置
运行环境
qwen3-lora
运行环境用 uv 安装在 /mnt/nfs/home/zhanghao/envs/qwen3-lora/;
使用时:
conda deactivate; # 先退出bash环境
source /mnt/nfs/home/zhanghao/envs/qwen3-lora/bin/activate
vLLM
vLLM 安装在 /mnt/nfs/home/zhanghao/envs/qwen3-serving/,负责加载大模型,提供推理服务。
Qwen3-8B信息
| 参数/配置项 | 值 |
|---|---|
| 模型架构 | 自回归 |
| 实际参数量 | 8,190,735,360 |
| 权重精度 | BF16 |
| 权重文件大小 | 约 16.38 GB |
| 上下文窗口 | 32K,YaRN可扩展128K |
| Transformer 层数 | 36 |
| 隐藏层、词向量维度 | 4,096 |
| FFN 中间维度 | 12,288 |
| Query 头数 | 32 |
| Key / Value 头数 | 8 |
| 每头维度 | 128 |
背景知识
部署在服务器的模型如何加载
可以代码中直接加载模型;
项目中用的:一个独立进程加载到GPU;Notebook通过 HTTP 向他提问;相当于把大模型包装成了一个服务端,客户端向他请求,这是为了让接口更好扩展;
启动模型推理并观察显存占用
磁盘权重 → vLLM 服务加载到 GPU → Notebook 通过 HTTP 调用
-
1 启动脚本:加载模型需要等待一段时间;
cd /mnt/nfs/home/zhanghao/code/Unitary-Agent/demo1/unitary-agent-demo bash scripts/start-qwen.sh # 不用激活环境,脚本会激活环境; -
2 新建另一个终端,检验是否已加载模型;也可检验显存占用;
curl --fail --max-time 10 http://127.0.0.1:8000/v1/models nvidia-smi就可以运行Unitary-Agent/demo1/unitary-agent-demo/demo.ipynb 调用Qwen模型
-
在加载模型的终端里面按 ctrl-C ,释放缓存占用;
模型(80 亿参数,稠密模型)权重文件只占16GB,但是加载后占用了36G显存?
除了权重文件大小,vLLM 还会主动分配KV Cache ;
解释启动脚本:
cd /mnt/nfs/home/zhanghao/code/Unitary-Agent/demo1/unitary-agent-demo
bash scripts/start-qwen.sh
脚本文件设置了一些模型参数:
export CUDA_DEVICE_ORDER=PCI_BUS_ID
export CUDA_VISIBLE_DEVICES="${CUDA_VISIBLE_DEVICES:-0}" #只能用卡0
export HF_HUB_OFFLINE=1
export TRANSFORMERS_OFFLINE=1 # 强制使用本地模型文件
exec "$serving_env/bin/vllm" serve "$model_dir" \
--served-model-name Qwen3-8B \
--host 127.0.0.1 --port "${QWEN_PORT:-8000}" \
--dtype bfloat16 --max-model-len 16384 \
--gpu-memory-utilization 0.6 --max-num-seqs 1 \
--enable-auto-tool-choice --tool-call-parser hermes \
--generation-config vllm --enforce-eager
--dtype bfloat16:以BF16精度加载模型;原模型就是BF16,vLLM设置了还能以更大的精度加载;但是不能以更小的精度加载,涉及到量化了;
--max-model-len 16384 :这是vLLM强制将模型的上下文控制在16K token以内。
清楚模型的上下文窗口:
Qwen3-8B 原生上下文32K,配置 YaRN 扩展之后可以达到 128K;
为什么要截断 到16 K: 减少显存暂用。
模型的上下文长度包括哪些?为什么是训练时候就决定的?上下文会影响显存占用,会影响 token 用量;
--gpu-memory-utilization 0.6 vLLM 最多只能占用该机器 0.6 的显存;
--max-num-seqs 1 vLLM 可以并行处理用户请求,这里设置为 1 等于说只能串行解决用户请求;
知道 vLLM 能控制的参数有很多:设置 GPU 显存预算上限、甚至能将模型权重分片到多张 GPU、还能将模型不同层放在不同的 GPU 上、设置上下文窗口、以什么精度加载等等;
function calling
项目使用大模型以 function calling 的形式。
传给模型的上下文包含有工具描述。function calling 希望大模型的回答是格式化的,比如明确的工具调用请求:
{
"name": "AQC",
"arguments": {
"target_id": "M01",
"parameters": {
"depth": 28,
"maxiter": 500
},
"reason": "尝试另一条综合路线"
}
}
而不是一个文本:可以先尝试 QSD,再尝试 AQC,比较它们的结果。
相当于多了一个步骤:在原始大模型回答后,多了一步,把模型输出解析成指定的格式。
- 如果是调 API 的,那调用方的服务端会处理这一步骤;
- 如果本地部署模型,需要下载 vLLM,由 vLLM 中的工具解析器做;