大模型私有化部署实战：Ollama快速验证与vLLM高并发推理服务搭建

大模型私有化部署正在从尝鲜走向企业标配。数据不出内网的合规要求、API按Token计费的成本压力、低延迟响应的业务诉求，共同推动企业把开源大模型迁移到自有服务器上。Ollama与vLLM是当前使用率最高的两套开源方案：前者面向开发调试与中小规模场景，一条命令拉起模型；后者专注生产环境高并发推理，配合量化模型可以在单张GPU上完成部署。

Ollama与vLLM的定位差异与选型依据

Ollama把模型下载、GGUF量化格式转换、API服务封装为一体，接口兼容OpenAI API，适合个人开发者、内部工具与原型验证。vLLM由加州大学伯克利分校团队开源，核心是PagedAttention技术：借鉴操作系统虚拟内存的分页机制管理KV Cache，显存利用率显著高于原生HuggingFace Transformers推理，高并发场景吞吐量可以达到原生推理的数倍。选型判断很直接：并发低于10路且模型在13B以内，Ollama够用；需要支撑几十路以上并发、模型规模30B起步、要求流式输出稳定，选vLLM。

Ollama本地部署：安装、模型拉取与API调用

Linux环境用官方脚本安装，macOS与Windows提供安装包：

curl -fsSL https://ollama.com/install.sh | sh

# 拉取模型（默认下载Q4_K_M量化版本）
ollama pull qwen3:14b

# 查看已下载模型与占用空间
ollama list

# 服务默认监听11434端口
curl http://localhost:11434/api/tags

对外提供服务时需要修改监听地址，编辑systemd服务：

sudo systemctl edit ollama.service

# 写入以下内容
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

sudo systemctl daemon-reload
sudo systemctl restart ollama

调用接口与OpenAI SDK直接对接，只需改base_url：

from openai import OpenAI

client = OpenAI(base_url="http://10.0.0.5:11434/v1", api_key="ollama")
resp = client.chat.completions.create(
    model="qwen3:14b",
    messages=[{"role": "user", "content": "用一句话解释KV Cache"}]
)
print(resp.choices[0].message.content)

GGUF量化等级选择：精度与显存的平衡

Ollama仓库中的模型默认是Q4_K_M量化，4bit量化的显存占用约为参数量的0.6倍再加上下文开销，14B模型约需10GB显存，可以塞进单张16GB显卡。对精度敏感的翻译、代码生成任务可升级Q8_0，显存占用约翻倍。一张24GB显卡跑32B模型的可行方案是Q4_K_M加8K上下文；上下文长度是显存的第二大头，每个Token的KV Cache开销随模型层数与注意力头数量线性增长，把num_ctx配置得过大（如128K）会直接触发OOM。内存够用的机器上，CPU推理跑7B量化模型可用作兜底通道，但吞吐会下降一个数量级以上，只适合低频任务。

vLLM生产级部署：PagedAttention高并发推理服务

vLLM以pip方式安装，依赖CUDA 12以上环境：

pip install vllm

# 启动OpenAI兼容API服务
python -m vllm.entrypoints.openai.api_server   --model /data/models/Qwen2.5-32B-Instruct-GPTQ-Int4   --served-model-name qwen2.5-32b   --tensor-parallel-size 1   --gpu-memory-utilization 0.9   --max-model-len 8192   --port 8000

关键参数的含义与经验值：

• –gpu-memory-utilization：vLLM预分配显存比例，0.9是常规值；与同卡其他进程共存时调低到0.7以下。
• –max-model-len：最大上下文长度，直接决定KV Cache预分配规模，按业务实际需要设置，不要默认拉满。
• –tensor-parallel-size：多卡张量并行数，32B以上模型单卡放不下时按卡数设置。
• –enable-prefix-caching：前缀缓存开关，多轮对话与固定system prompt场景命中率可观，可显著降低首Token延迟。

并发压测：吞吐与首Token延迟指标采集

部署完成后用vLLM仓库自带的benchmark脚本验证，重点看总吞吐量与首Token延迟（TTFT）两个指标：

python benchmarks/benchmark_serving.py   --backend vllm   --model qwen2.5-32b   --num-prompts 200   --request-rate 20   --endpoint /v1/chat/completions

单张24GB卡跑32B GPTQ-Int4模型的参考区间：并发20路时总吞吐约400-800 Token/s，TTFT在1-3秒。压测中若出现大量OOM重试，优先降低gpu-memory-utilization或缩短max-model-len，而不是盲目扩容。Ollama与vLLM的压测结果差异在低并发下并不明显，并发拉到30路以上时vLLM的连续批处理（continuous batching）优势才会充分体现，选型测试要贴近真实流量模型。

部署前资源评估与常见故障处理

显存估算公式：FP16全量约为”参数量×2″GB，Int4量化约为”参数量×0.6″GB，再叠加KV Cache与激活值，规划时在估算值基础上预留30%余量。三个高频报错的处置：CUDA OMM优先检查max-model-len是否超出预算；中文输出异常确认tokenizer与模型权重版本匹配；并发上不去时确认vLLM版本是否支持当前模型架构的新注意力实现，老版本对部分新架构会回退到低效路径。

私有化部署的收尾工作是把服务纳入监控：将指标暴露给Prometheus，对显存水位、请求队列长度、TTFT分位数设置告警，前端再用Nginx或网关做限流与鉴权。模型服务上线不是终点，持续跟踪推理指标与硬件健康，私有化方案才能真正替代API调用，把单位Token成本稳定压在预算之内。