本地私有化部署大模型：Ollama 与 vLLM 实战

为什么要本地部署大模型

调用云端大模型 API 很方便，但很多场景下你不想把数据发出去：公司内部文档、医疗病历、用户对话记录，这些数据一旦离开内网，合规和安全风险就说不清。本地私有化部署就是把模型跑在自己的服务器上，数据不出内网，成本也可控——按量调 API 看似便宜，但每天上万次调用下来，比买一张显卡贵得多。

除了数据安全和成本，本地部署还有一个实际好处：延迟可控。云 API 要走公网，网络抖动一来延迟就飘；本地部署请求直接进 GPU，端到端延迟稳定在几百毫秒，对实时交互类应用很重要。当然本地部署也有代价——你得自己管硬件、管模型版本、管推理服务的稳定性，这些事云厂商都替你做了。

本地部署不是为了「不花钱」，而是为了让数据、延迟和成本都握在自己手里。

本文核心知识点

私有化部署解决数据不出内网、延迟可控与长期成本三个核心诉求。
Ollama适合个人开发与小规模试用，一条命令拉起模型。
vLLM适合生产环境，高吞吐、支持并发与 OpenAI 兼容 API。
量化用更低精度跑同样的模型，省显存但要权衡效果损失。

本地部署配图：左侧服务器机柜经数据管线连接中央六边形核心，再连到右侧笔记本，蓝色渐变扁平风格 — 本地部署的典型架构：服务器上跑推理引擎，经内网提供 API，前端应用直接调用。

硬件要求与模型选型

本地部署第一个要面对的现实是：你有什么卡。大模型推理基本靠 GPU 显存，显存不够就跑不起来。7B 量级的模型用 4-bit 量化后大概要 6GB 显存，单张消费级显卡就能跑；70B 量级即使量化后也要 40GB 以上，得上专业卡或者多卡。

模型规模	FP16 显存	4-bit 量化显存	推荐硬件
7B	约 14 GB	约 5 GB	单张 16GB 消费卡
13B	约 26 GB	约 8 GB	单张 24GB 消费卡
70B	约 140 GB	约 40 GB	两张 24GB 卡或专业卡

模型选型上，不要盲目追大。7B 模型在很多垂直任务上经过微调后，效果不输通用大模型。先从开源的中等规模模型试起，用自己业务的数据做一轮指令微调，效果不够再往上加规模。模型越大，推理越慢、成本越高，这个账要先算清楚。

# 显存占用的粗略估算
# 参数量 × 每参数字节数 ≈ 模型权重显存
# 7B 模型 FP16: 7e9 × 2 bytes = 14 GB
# 7B 模型 4-bit: 7e9 × 0.5 bytes = 3.5 GB + KV cache

# 选模型时先想清楚：
# 1. 业务对模型能力的要求有多高？
# 2. 能接受多大的延迟？
# 3. 现有硬件能跑多大的？

Ollama：快速上手的本地推理

Ollama 是目前最省事的本地大模型工具。它把模型下载、推理引擎、API 服务全打包好了，你在本机装完之后，一条命令就能拉起一个模型，并且自动提供一个兼容 OpenAI 格式的 HTTP 接口。适合个人开发、本地测试和小规模内部工具。

# Ollama 基本使用
# 安装后拉取模型
ollama pull qwen2.5:7b

# 直接对话
ollama run qwen2.5:7b

# 它同时会在本机起一个 API 服务，默认端口 11434
# 用 curl 调用：
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen2.5:7b",
    "messages": [{"role": "user", "content": "你好"}]
  }'

Ollama 的好处是几乎零配置：模型自动量化、自动加载、自动服务。但它的局限也很明显：并发能力弱，同一时间只能处理有限的请求；模型加载和切换也比较慢。所以它适合开发调试和个人使用，不适合直接扛生产流量。

Ollama 适用场景

本地开发调试在笔记本上随时拉一个模型试 prompt 和工作流。
内部小工具给团队几十人用的小工具，并发不高时足够。
快速原型验证一个想法能不能跑，不用申请云资源。

vLLM：面向生产的高吞吐服务

vLLM 是面向生产环境的大模型推理引擎。它用了 PagedAttention 等技术，把显存管理做得更高效，单张卡上能同时处理的请求数比原生推理高好几倍。如果你要把模型挂到内网给多个业务系统调用，vLLM 是更合适的选择。

# vLLM 启动 OpenAI 兼容服务
python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-7B-Instruct \
  --port 8000 \
  --max-model-len 4096 \
  --gpu-memory-utilization 0.9

# 启动后和 OpenAI SDK 完全兼容
from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="none")
resp = client.chat.completions.create(
    model="Qwen/Qwen2.5-7B-Instruct",
    messages=[{"role": "user", "content": "你好"}]
)

vLLM 的核心优势是连续批处理：它不会等一个请求生成完再处理下一个，而是把多个请求的生成步骤打包在一起跑，GPU 利用率高很多。代价是部署比 Ollama 复杂——要装 CUDA 环境、下模型权重、配显存利用率，出了问题也得自己排。

量化策略与显存优化

显存不够的时候，最直接的办法是量化：把模型权重从 16 位浮点数压到 4 位甚至更低。数值精度降了，但模型参数的数量级没变，推理效果损失通常很小，而显存占用直接降到原来的四分之一。

常见的量化方案有两类：一类是训练后量化，直接对已经训好的模型做压缩，简单快速但精度损失稍大；另一类是量化感知训练，在训练过程中就考虑量化影响，效果更好但成本高。大多数本地部署场景用训练后量化就够了。

# Ollama 自动量化，拉模型时指定量化等级
ollama pull qwen2.5:7b-q4_0    # 4-bit 量化版本
ollama pull qwen2.5:7b-q8_0    # 8-bit 量化版本

# vLLM 启动时指定量化
python -m vllm.entrypoints.openai.api_server \
  --model TheBloke/Qwen2.5-7B-Instruct-GPTQ \
  --quantization gptq

除了量化，还能通过限制最大上下文长度、减少并发数、用模型并行把大模型拆到多张卡上来进一步省显存。这些手段叠加起来，就能在有限的硬件上跑起比原本大得多的模型。