基于 vLLM 与 llama.cpp 的高性能本地大模型推理部署

前言

Ollama 适合个人使用，但当你要在生产环境提供 API 服务时——高并发、低延迟、高吞吐——就需要专业的推理框架了。

目前开源社区主流的两个选择是 vLLM（GPU 推理）和 llama.cpp（CPU/GPU 通用推理）。这篇文章讲清楚它们分别怎么用，以及怎么选。

一、vLLM：GPU 高性能推理

vLLM 是目前 GPU 推理的事实标准，主打高吞吐、低延迟。核心优势是 PagedAttention 算法——把 KV Cache 像操作系统管理内存那样分页管理，大大减少了显存碎片。

安装

1	pip install vllm

启动 OpenAI 兼容 API

# 一行命令启动服务
vllm serve Qwen/Qwen2.5-7B-Instruct \
  --host 0.0.0.0 \
  --port 8000 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90

关键参数：

参数	作用	建议
`--max-model-len`	最大上下文长度	根据需求设，越长越吃显存
`--gpu-memory-utilization`	显存使用上限占比	0.85~0.95，留一点给系统
`--tensor-parallel-size`	多卡并行	有几张 GPU 就设几
`--dtype`	推理精度	auto 自动选
`--quantization`	量化方式	awq/gptq/fp8 等

调用

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"
)

response = client.chat.completions.create(
    model="Qwen/Qwen2.5-7B-Instruct",
    messages=[{"role": "user", "content": "介绍一下 Kubernetes"}],
    max_tokens=500
)
print(response.choices[0].message.content)

性能基准参考

在单张 A100 80GB 上，vLLM 部署 Qwen2.5-7B：

并发数	吞吐量 (tokens/s)	平均延迟 (ms)
1	~50	~200
8	~350	~450
32	~1200	~900
64	~1800	~1500

这不是精确数字（取决于 prompt 长度、输出长度等），但足以看出 vLLM 在高并发下的优势。

二、llama.cpp：CPU 和边端推理

llama.cpp 是一个纯 C/C++ 实现的推理引擎，不需要 Python 运行时，不需要 CUDA。它能在 CPU 上跑、在 GPU 上跑、在手机和树莓派上跑。

Ollama 底层用的就是 llama.cpp。

安装

# macOS
brew install llama.cpp

# Linux（从源码编译）
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
make -j

运行模型

# 启动 HTTP 服务
./llama-server \
  -m /path/to/qwen2.5-7b-q4_k_m.gguf \
  --host 0.0.0.0 \
  --port 8080 \
  -c 4096 \
  -ngl 32            # 卸载到 GPU 的层数

关键参数：

参数	作用
`-m`	模型文件路径（GGUF 格式）
`-c`	上下文窗口大小
`-ngl`	多少层卸载到 GPU（0 表示纯 CPU）
`-t`	CPU 线程数
`-b`	batch 大小

llama.cpp 的 HTTP 服务也兼容 OpenAI API 格式：

client = OpenAI(
    base_url="http://localhost:8080/v1",
    api_key="not-needed"
)

三、量化模型

GGUF 量化（llama.cpp 用）

# 1. 将原版 HuggingFace 模型转换为未量化的 f16 精度 GGUF 格式（输出为 model-f16.gguf）
python llama.cpp/convert_hf_to_gguf.py /path/to/original/model --outfile model-f16.gguf

# 2. 将 f16 模型量化为 Q4_K_M 格式（量化器必须同时指定输入、输出及量化级别）
./llama-quantize model-f16.gguf model-q4.gguf Q4_K_M

量化级别	模型大小（7B）	质量损失	适用
Q8_0	~7.5 GB	极小	追求质量
Q4_K_M	~4.5 GB	很小	推荐，平衡之选
Q4_0	~4.0 GB	小	省显存
Q2_K	~2.8 GB	有感知	极致省空间

Q4_K_M 是大多数场景的最佳选择——质量接近无损，体积减半。

AWQ/GPTQ 量化（vLLM 用）

# AutoAWQ 量化
pip install autoawq

from awq import AutoAWQForCausalLM
model = AutoAWQForCausalLM.from_pretrained("Qwen/Qwen2.5-7B-Instruct")
model.quantize(tokenizer, quant_config={"zero_point": True, "q_group_size": 128})
model.save_quantized("./qwen2.5-7b-awq")

四、vLLM vs llama.cpp 选择指南

	vLLM	llama.cpp
运行环境	需要 NVIDIA GPU	CPU 可跑，GPU 加速可选
吞吐量	高（GPU 并行）	中（受限于 CPU 核心数）
延迟	低	CPU 上高，GPU 加速后中等
部署复杂度	中等	低（编译即用，无 Python 依赖）
适合场景	高并发 API 服务	嵌入式设备、低并发、成本敏感
模型格式	HuggingFace 模型 / AWQ/GPTQ	GGUF
量化支持	AWQ、GPTQ、FP8	GGUF 系列
生态集成	好（OpenAI API 兼容）	好（OpenAI API 兼容，Ollama 底层）

简单决策：

有 GPU（A100/A10/4090）→ vLLM
纯 CPU 服务器 → llama.cpp
手机/树莓派/嵌入式 → llama.cpp
需要 100+ 并发 → vLLM
预算紧张 → llama.cpp + CPU 服务器

五、生产部署建议

# vLLM 生产配置示例
vllm serve Qwen/Qwen2.5-7B-Instruct \
  --host 0.0.0.0 \
  --port 8000 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.88 \
  --max-num-seqs 128 \         # 最大并发序列数
  --enable-prefix-caching \     # 前缀缓存（有 system prompt 时效果好）
  --disable-log-requests        # 减少日志量

监控指标：vLLM 自带 Prometheus 指标端点 http://localhost:8000/metrics，可以接入 Grafana 做监控大盘。

前端加 Nginx：生产环境建议把 vLLM 放在 Nginx 后面，做限流、HTTPS、日志记录。

选型上的经验是：有 GPU 环境优先上 vLLM，省事选 Ollama（底层也是 llama.cpp），极致压榨资源才自己编译部署 llama.cpp。