关于vllm的模型部署的一些总结
本文对比了OpenAI API、vLLM和Ollama三大AI服务框架的主要特性。OpenAI API是商业云服务，适合企业用户；vLLM是生产级推理引擎，适合技术团队本地部署；Ollama则定位为个人开发者工具，使用最简单。重点介绍了vLLM的关键参数--gpu-memory-utilization的调优策略，建议根据GPU型号、模型大小和使用场景设置0.6-0.9之间的值，以平衡性能和稳定性。
·
openai vllm ollama的对比
| 维度 | OpenAI API | vLLM | Ollama |
|---|---|---|---|
| 定位 | 商业云服务 | 生产级推理引擎 | 个人/开发者工具 |
| 部署 | 云端 | 本地/服务器 | 本地桌面 |
| 用户 | 企业/开发者 | 企业/技术团队 | 个人开发者/爱好者 |
| 复杂度 | 最简单 | 复杂 | 非常简单 |
执行命令查看显卡信息：
(base) root@iZbp1xxxxxg3Z:~# nvidia-smi
Fri Jan 16 10:46:24 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.127.08 Driver Version: 550.127.08 CUDA Version: 12.4 |
|-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA L20 On | 00000000:00:03.0 Off | 0 |
| N/A 34C P0 76W / 350W | 43799MiB / 46068MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+
| 1 NVIDIA L20 On | 00000000:00:04.0 Off | 0 |
| N/A 34C P0 73W / 350W | 30173MiB / 46068MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+
+-----------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
| 0 N/A N/A 1661569 C /root/miniconda3/envs/ocr/bin/python 6058MiB |
| 0 N/A N/A 2068344 C Model: bge-reranker-base-0 916MiB |
| 0 N/A N/A 2070129 C /usr/bin/python3.10 28386MiB |
| 0 N/A N/A 3157164 C /root/miniconda3/envs/ocr/bin/python 3564MiB |
| 0 N/A N/A 3473300 C ...niconda3/envs/model_test/bin/python 4854MiB |
| 1 N/A N/A 2068803 C Model: bge-large-zh-v1.5-0 1038MiB |
| 1 N/A N/A 2089143 C Model: qwen2.5-instruct-1m-0 15002MiB |
| 1 N/A N/A 3171820 C VLLM::EngineCore 14120MiB |
+-----------------------------------------------------------------------------------------+
我来详细对比 HuggingFace 和 ModelScope 这两个重要的AI模型平台。
核心定位对比
| 维度 | HuggingFace（抱抱脸） | ModelScope（魔搭社区） |
|---|---|---|
| 起源 | 法国初创公司，2016年成立 | 阿里巴巴达摩院，2022年发布 |
| 定位 | 全球AI开源社区 | 中国AI模型开源社区 |
| 语言侧重 | 英语为主，多语言支持 | 中文优先，中文优化 |
| 用户规模 | 全球1000万+开发者 | 中国开发者为主，快速增长 |
ollama适合个人pc自己玩一下，不是所有模型都支持
vllm不适合embedding模型，只适合生成模型
嵌入模型请使用 Text Embedding Inference 或者https://github.com/FlagOpen/FlagEmbedding.git等
ref:
vllm
https://vllm.hyper.ai/docs/
Xinference 可以快速部署vllm模型
https://inference.readthedocs.io/en/latest/
LoRA 适配器与 vLLM 结合使用。
https://arxiv.org/abs/2106.09685
vllm lora部分
https://huggingface.co/fal/Qwen-Image-Edit-2511-Multiple-Angles-LoRA
lora 依赖于 vllm外挂lora适配器，可以在启动的时候指定lora适配器
LoRA 适配器可与任何实现 SupportsLoRA 的 vLLM 模型一起使用。
CUDA_VISIBLE_DEVICES=1 vllm serve Qwen/Qwen1.5-1.8B-Chat \
--port 8008 \
--gpu-memory-utilization 0.3 \
--max-model-len 8192 \
--max-num-batched-tokens 8192 \
--dtype half \
--tensor-parallel-size 1 \
--enforce-eager \
--api-key "123456" \
--trust-remote-code \
--disable-log-requests \
--disable-log-stats
后台执行
# 将0.3调整为更合理的0.7-0.8
CUDA_VISIBLE_DEVICES=1 nohup vllm serve Qwen/Qwen1.5-1.8B-Chat \
--port 8008 \
--gpu-memory-utilization 0.75 \ # ✅ 从0.3提高到0.75
--max-model-len 8192 \
--max-num-batched-tokens 16384 \ # ✅ 提高批次处理能力
--dtype half \
--tensor-parallel-size 1 \
--enforce-eager \
--api-key "123456" \
--trust-remote-code \
--disable-log-requests \
--disable-log-stats \
> vllm_qwen_1.8b.log 2>&1 &
如果部署不起来，显存不够
1、选用量化模型
2、调节–gpu-memory-utilization 0.3 的值
--gpu-memory-utilization 是 vLLM中最重要的性能调优参数之一，它控制vLLM如何使用GPU显存。
核心作用
控制vLLM分配和管理GPU显存的方式，特别是如何平衡：
- 模型权重存储
- KV缓存（用于加速推理）
- 请求处理空间
详细解释
1. 工作原理
text
GPU显存总大小 = 24GB (例如RTX 4090)
--gpu-memory-utilization 0.8 表示：
vLLM可用的显存 = 24GB × 0.8 = 19.2GB
剩下的20% (4.8GB) 留给：
- 系统开销
- CUDA上下文
- 其他应用
2. 显存分配组成
python
# vLLM显存分配结构
Total GPU Memory (100%)
├── vLLM可用部分 (由 --gpu-memory-utilization 控制)
│ ├── 模型权重 (Model Weights)
│ ├── KV缓存 (Key-Value Cache)
│ ├── 激活内存 (Activation Memory)
│ └── 批次处理空间 (Batch Processing)
└── 保留部分 (Reserved for system)
├── CUDA驱动
├── PyTorch/TensorFlow框架
└── 其他进程
3. 不同设置的效果
低值设置 (0.3-0.5)
bash
--gpu-memory-utilization 0.3
- 优点：
- 显存充足，不容易OOM
- 适合多模型同时运行
- 系统稳定性高
- 缺点：
- KV缓存空间小
- 批次处理能力弱
- 吞吐量低
- 适用场景：
- 开发调试
- 小规模测试
- 多任务环境
中等值设置 (0.6-0.8) ✅ 推荐
bash
--gpu-memory-utilization 0.7
- 优点：
- 平衡性能和稳定性
- 足够的KV缓存
- 较好的批次处理
- 缺点：
- 需要合理设置其他参数
- 适用场景：
- 生产环境
- 中等负载服务
- 单模型部署
高值设置 (0.85-0.95)
bash
--gpu-memory-utilization 0.9
- 优点：
- 最大化KV缓存
- 最高吞吐量
- 最佳性能
- 缺点：
- 容易OOM（内存溢出）
- 系统不稳定
- 可能影响其他进程
- 适用场景：
- 专用推理服务器
- 高并发需求
- 性能压测
实际示例对比
示例1：8B模型在24GB GPU上
bash
# 设置 0.3（太保守）
可用显存：24GB × 0.3 = 7.2GB
模型权重：8B × 2bytes = 16GB ❌ 不够！
# 设置 0.8（合理）
可用显存：24GB × 0.8 = 19.2GB
模型权重：16GB
剩余：3.2GB给KV缓存 ✅ 够用
# 设置 0.9（激进）
可用显存：24GB × 0.9 = 21.6GB
模型权重：16GB
剩余：5.6GB给KV缓存 ✅ 性能更好
示例2：1.8B模型在8GB GPU上
bash
# 设置 0.6（安全）
可用显存：8GB × 0.6 = 4.8GB
模型权重：1.8B × 2bytes = 3.6GB
剩余：1.2GB给KV缓存 ✅
# 设置 0.85（最大化性能）
可用显存：8GB × 0.85 = 6.8GB
模型权重：3.6GB
剩余：3.2GB给KV缓存 ✅ 更高并发
与KV缓存的关系
--gpu-memory-utilization 直接影响KV缓存大小：
python
# KV缓存计算公式（简化）
kv_cache_size = available_memory - model_weights - system_overhead
# 示例：24GB GPU，8B模型
if utilization = 0.3: # 7.2GB可用
kv_cache = 7.2GB - 16GB(模型) = ❌ 负值，无法加载！
if utilization = 0.8: # 19.2GB可用
kv_cache = 19.2GB - 16GB = 3.2GB ✅ 可支持约8个并发请求
if utilization = 0.9: # 21.6GB可用
kv_cache = 21.6GB - 16GB = 5.6GB ✅ 可支持约15个并发请求
最佳实践建议
1. 根据GPU型号推荐
yaml
# NVIDIA RTX 4090/3090 (24GB):
推荐: 0.8-0.85
说明: 充足显存，可设置较高
# NVIDIA RTX 4080/3080 (16GB):
推荐: 0.7-0.8
说明: 中等显存，平衡设置
# NVIDIA RTX 4060/3060 (8GB):
推荐: 0.65-0.75
说明: 有限显存，需保守
# A100/H100 (40-80GB):
推荐: 0.85-0.95
说明: 大显存，可最大化利用
2. 根据模型大小调整
bash
# 大模型 (>13B)
--gpu-memory-utilization 0.8-0.85 # 需要更多KV缓存
# 中模型 (7B-13B)
--gpu-memory-utilization 0.75-0.8 # 平衡设置
# 小模型 (<7B)
--gpu-memory-utilization 0.7-0.75 # 可较保守
3. 根据使用场景
bash
# 生产环境（稳定性优先）
--gpu-memory-utilization 0.7-0.75
# 测试/开发环境
--gpu-memory-utilization 0.6-0.7
# 性能压测（最大化吞吐）
--gpu-memory-utilization 0.85-0.9
# 多模型部署
--gpu-memory-utilization 0.5-0.6
与其他参数的关系
与 --max-model-len 的交互
bash
# 长上下文需要更多KV缓存
--max-model-len 32768
--gpu-memory-utilization 0.85 # 需要更高值
# 短上下文可降低
--max-model-len 4096
--gpu-memory-utilization 0.7 # 可降低
与 --swap-space 的配合
bash
# 启用CPU卸载，可设置更高utilization
--gpu-memory-utilization 0.9
--swap-space 8 # 8GB CPU内存作为交换
以下为量化模型的说明
量化版是指对大型语言模型进行精度降低和压缩处理的版本。让我详细解释：
什么是模型量化？
模型量化是一种模型压缩技术，通过降低模型参数的数值精度来：
- 减少显存占用
- 提高推理速度
- 降低部署成本
量化原理（通俗比喻）
text
原始模型（FP16）：每个参数用 2字节 存储
量化模型（INT4）：每个参数用 0.5字节 存储
就像：
- 原始：用高清图片（质量好，文件大）
- 量化：用压缩图片（质量稍降，文件小很多）
常见量化类型
1. 权重量化（Weight Quantization）
python
# 原始权重：FP16（16位浮点数）
weight = 3.1415926535 # 占用2字节
# 量化到INT8（8位整数）
weight_quantized = 3 # 占用1字节（压缩50%）
# 量化到INT4（4位整数）
weight_quantized = 3 # 占用0.5字节（压缩75%）
2. 激活量化（Activation Quantization）
- 对中间计算结果也进行量化
- 进一步减少显存和计算量
主流量化方法对比
| 量化方法 | 精度 | 显存减少 | 速度提升 | 质量保持 | 常用格式 |
|---|---|---|---|---|---|
| FP16 | 16位浮点 | 基准 | 基准 | 100% | 原始模型 |
| INT8 | 8位整数 | ~50% | 10-30% | 98-99% | .bnb |
| INT4 | 4位整数 | ~75% | 30-50% | 95-98% | .gguf, .ggml |
| GPTQ | 4位整数 | ~75% | 30-50% | 97-99% | .gptq |
| AWQ | 4位整数 | ~75% | 40-60% | 98-99% | .awq |
实际示例：Qwen3-8B 量化对比
显存占用对比
text
原始版本（FP16）：
├── 模型权重：8B × 2字节 = 16GB
├── KV缓存：~2GB
├── 其他：~2GB
└── 总计：~20GB
INT4量化版：
├── 模型权重：8B × 0.5字节 = 4GB ⬇️ 减少75%！
├── KV缓存：~2GB
├── 其他：~2GB
└── 总计：~8GB
模型名称识别
text
# HuggingFace上的量化版本命名：
Qwen/Qwen3-8B-Instruct # 原始版本（FP16）
Qwen/Qwen3-8B-Instruct-AWQ # AWQ量化版
Qwen/Qwen3-8B-Instruct-GPTQ # GPTQ量化版
Qwen/Qwen3-8B-Instruct-Int8 # INT8量化版
Qwen/Qwen3-8B-Instruct-GGUF # GGUF格式（通用）
# 社区其他量化：
TheBloke/Qwen3-8B-Instruct-GGUF # GGUF各种量化等级
如何使用量化模型
方法1：使用vLLM直接加载量化模型
bash
# AWQ量化
vllm serve Qwen/Qwen3-8B-Instruct-AWQ --quantization awq
# GPTQ量化
vllm serve Qwen/Qwen3-8B-Instruct-GPTQ --quantization gptq
方法2：使用llama.cpp（GGUF格式）
bash
# 下载GGUF格式（各种量化等级）
# q4_0、q4_1、q5_0、q5_1、q8_0等
./llama-cli -m qwen3-8b-instruct-q4_0.gguf \
-p "Hello" -n 100 -t 8
方法3：使用Transformers + bitsandbytes
python
from transformers import AutoModelForCausalLM, AutoTokenizer
import torch
# 4位量化加载
model = AutoModelForCausalLM.from_pretrained(
"Qwen/Qwen3-8B-Instruct",
torch_dtype=torch.float16,
load_in_4bit=True, # 4位量化
device_map="auto"
)
量化等级详解（GGUF为例）
text
q2_K # 2位量化，最小，质量损失明显
q3_K_L # 3位量化，低精度
q4_0 # 4位整数，平衡选择
q4_1 # 4位，稍高质量
q5_0 # 5位，质量更好
q5_1 # 5位，高质量
q6_K # 6位，接近原始质量
q8_0 # 8位，几乎无损
选择建议
根据硬件选择：
yaml
# 24GB+ GPU（RTX 4090/3090）：
推荐：FP16或INT8，保持最高质量
# 16GB GPU（RTX 4080/3080）：
推荐：AWQ或GPTQ（4位）
# 8GB GPU（RTX 4060/3060）：
推荐：INT4或GGUF q4_0
# CPU推理：
推荐：GGUF格式，q4_0或q5_0
根据使用场景：
yaml
# 聊天对话：
推荐：q4_1或q5_0，需要较好语义理解
# 代码生成：
推荐：q5_1或q6_K，需要精确性
# 文本摘要/翻译：
推荐：q4_0或q4_1，平衡即可
# 研究/评估：
推荐：FP16原始版本
实际部署命令示例
bash
# 1. AWQ量化部署（最优推荐）
CUDA_VISIBLE_DEVICES=1 vllm serve Qwen/Qwen3-8B-Instruct-AWQ \
--port 8008 \
--quantization awq \
--gpu-memory-utilization 0.8 \
--max-model-len 16384
# 2. GGUF格式CPU部署
./server -m qwen3-8b-instruct-q4_0.gguf \
-c 4096 -ngl 99 # ngpu layers
# 3. 8位量化（Transformers）
python -c "
from transformers import AutoModelForCausalLM
model = AutoModelForCausalLM.from_pretrained(
'Qwen/Qwen3-8B-Instruct',
load_in_8bit=True,
device_map='auto'
)
"
量化模型下载
bash
# 从HuggingFace下载量化版
# 方法1：直接下载（需要transformers>=4.35）
from huggingface_hub import snapshot_download
# AWQ版本
snapshot_download("Qwen/Qwen3-8B-Instruct-AWQ")
# 方法2：使用huggingface-cli
huggingface-cli download Qwen/Qwen3-8B-Instruct-AWQ
# 方法3：从TheBloke下载GGUF
# https://huggingface.co/TheBloke/Qwen3-8B-Instruct-GGUF
注意事项
- 兼容性：确保框架支持对应的量化格式
- 质量评估：对关键应用要先测试量化效果
- 混合精度：有些层可能保持高精度（如embedding层）
- KV缓存：量化主要减少权重显存，KV缓存仍需显存
总结：量化版是通过降低参数精度来大幅减少显存占用的模型版本，是在有限硬件上部署大模型的必备技术。推荐优先选择AWQ或GPTQ格式，在质量和效率间取得最佳平衡。
腾讯云面向开发者汇聚海量精品云计算使用和开发经验，营造开放的云计算技术生态圈。
更多推荐
16
0- 0
已为社区贡献4条内容
所有评论(0)