本地大模型部署实战：Ollama + vLLM + 量化指南

读完本文，你将掌握：本地大模型部署的完整技术栈（从模型下载到 API 服务）、主流量化方法对比（GGUF、AWQ、GPTQ 的选择标准）、Ollama 和 vLLM 的适用场景差异，以及显存优化和推理加速的实战技巧。无论你是想在个人电脑上跑 7B 小模型，还是在企业服务器上部署 70B 大模型，本文都能提供可落地的方案。

本文基于 Ollama 最新版本、vLLM 最新版本的实际运行经验编写，所有命令均可直接执行验证。

核心结论先说：本地部署的核心约束是显存，量化是降低显存的唯一有效手段。选择什么量化格式取决于你的硬件和延迟要求。

大语言模型的部署方式主要分为两种：云端 API 调用和本地私有部署。选择哪种方案，取决于你的需求场景。

云端 API 的优势显而易见：无需购买 GPU 硬件、无需关心模型运维、按需付费。OpenAI、Anthropic、Google 等厂商的 API 服务开箱即用。但云端方案有三个致命短板：

第一，数据隐私。任何通过 API 发送的文本都会经过厂商的服务器。金融、医疗、法律等敏感行业的数据不允许离开私有网络。即使厂商承诺"不用于训练"，合规要求也可能禁止数据外传。

第二，成本结构。对于高频调用的场景（如企业内部智能客服、代码补全助手），API 调用的累计成本可能远超购买硬件的费用。一个日均调用 10 万次的企业，月度 API 费用轻松超过万元。

第三，延迟和可用性。网络延迟通常在 100-500ms 之间，对于需要实时响应的场景（如语音对话 Agent）不可接受。而且云端服务存在不可控的停机风险——厂商维护、流量超限、政策变动都可能影响可用性。

本地部署的核心价值是掌控力：数据不出本地、延迟可控制在 10ms 以内、模型版本完全自主、可以深度定制和微调。但代价是需要 GPU 硬件投入和运维能力。

量化（Quantization）是将模型参数从高精度（FP32/FP16）转换为低精度（INT8/INT4）的过程，本质是用精度换显存。这是本地部署的必修课。

模型参数的存储格式决定了显存占用。一个 70 亿参数（7B）的模型，FP16 精度需要约 14GB 显存（7B × 2 字节），而 INT4 量化后仅需约 3.5GB（7B × 0.5 字节）。这就是为什么 24GB 的 RTX 4090 能跑 30B 级别的 INT4 量化模型，但跑不动 FP16 版本。

量化方法主要分为三类：

后训练量化（Post-Training Quantization，PTQ）：在训练完成后对模型权重进行转换，不需要重新训练。这是最常用的方式。代表工具有 llama.cpp（GGUF 格式）、AutoGPTQ（GPTQ 格式）、AWQ（激活感知量化）。PTQ 的优点是简单快速，缺点是精度损失相对较大。

感知训练量化（Quantization-Aware Training，QAT）：在训练过程中模拟量化误差，让模型在量化后表现更好。需要重新训练或微调，精度损失最小但成本最高。

混合精度量化：对敏感层（如注意力层）保持高精度，对不敏感层（如 FFN）使用低精度。这是目前效果最好的方案，但实现复杂度高。

当前主流量化格式的选择标准：GGUF 适合 CPU 推理（Ollama 使用）、GPTQ 适合 NVIDIA GPU（4-bit）、AWQ 适合 NVIDIA GPU（4-bit 且推理速度更快）。

# 查看不同量化格式的显存对比（以 Llama-3-8B 为例）
# FP16:  16 GB
# INT8:  8 GB
# GPTQ 4-bit: 4.5 GB
# GGUF Q4_K_M: 4.9 GB
# GGUF Q8_0:  8.5 GB

# 显存计算公式：参数量 × 每参数字节数
# 7B × 2 bytes (FP16) = 14 GB（加上 KV cache 等额外开销，实际约 16GB）

Ollama 是目前最流行的本地大模型部署工具，它的核心优势是零配置——一条命令就能运行模型。Ollama 基于 llama.cpp，使用 GGUF 量化格式，支持 CPU 和 GPU 混合推理。

Ollama 的架构设计简洁有效：底层是 llama.cpp 的推理引擎，负责加载 GGUF 模型文件并执行前向计算；中间层是 Ollama 的服务封装，提供 REST API（默认 11434 端口）；上层是 Modelfile 系统，类似 Dockerfile，允许自定义系统提示、参数和基础模型。

Ollama 的核心优势有三点：第一，安装极简，macOS/Linux/Windows 一键安装；第二，模型管理方便，ollama pull 自动下载，支持数百种预置模型；第三，兼容性好，CPU 也能跑（虽然慢），适合无 GPU 的开发机。

但 Ollama 也有局限性：它适合个人开发和原型验证，不适合生产环境。并发能力有限（默认单实例）、不支持动态批处理优化、缺乏细粒度的显存管理。如果你的需求是高并发 API 服务，vLLM 是更好的选择。

Ollama 已集成 Kimi K2.6 和 GLM-5.1 等国产模型，国内开发者可以直接 ollama pull 使用。

# 安装 Ollama（macOS/Linux）
curl -fsSL https://ollama.com/install.sh | sh

# 运行模型（首次会自动下载）
ollama run llama3.1:8b        # 8B 模型，约需 5GB 显存
ollama run qwen2.5:7b         # Qwen 2.5 7B
ollama run kimi-k2.6:latest    # Kimi K2.6（已集成）
ollama run glm-5.1:latest      # GLM-5.1（已集成）

# 查看已下载的模型
ollama list

# 自定义 Modelfile
cat > Modelfile << 'EOF'
FROM qwen2.5:7b
SYSTEM "你是一个专业的技术助手，擅长代码生成和问题解答。"
PARAMETER temperature 0.7
PARAMETER num_ctx 4096
EOF
ollama create my-assistant -f Modelfile
ollama run my-assistant

# 作为 API 服务使用
curl http://localhost:11434/api/generate -d '{
  "model": "qwen2.5:7b",
  "prompt": "什么是 Transformer？",
  "stream": false
}'

vLLM 是目前性能最强的开源 LLM 推理框架，由 UC Berkeley 开发。它的核心技术是 PagedAttention——一种将操作系统的虚拟内存分页机制引入 KV Cache 管理的创新方法。

PagedAttention 解决了传统推理框架的一个关键瓶颈：KV Cache 的内存碎片化。在传统的 attention 实现中，每个请求的 KV Cache 需要在连续内存中分配，这导致大量内存浪费（20-40％）。PagedAttention 允许 KV Cache 在非连续内存块中存储，就像操作系统的虚拟内存分页一样，显存利用率提升 2-4 倍。

vLLM 的核心特性：第一，连续批处理（Continuous Batching）——不是等所有请求都到达再批量处理，而是动态地将新请求插入到当前批次中，大幅提升吞吐量；第二，支持多种量化格式（AWQ、GPTQ、FP8）；第三，兼容 OpenAI API 格式，可以无缝替换云端 API。

vLLM 的适用场景是：需要高并发、低延迟的生产环境。典型场景包括：企业内部 API 网关、多租户模型服务、需要与现有系统集成的 AI 应用。

当前最新版本已支持 Kimi K2.6 和 GLM-5.1 等国产模型，以及 Ollama 格式的模型转换。

# 安装 vLLM
pip install vllm

# 启动 OpenAI 兼容的 API 服务
python -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen2.5-7B-Instruct \
    --dtype half \
    --max-model-len 8192 \
    --tensor-parallel-size 1 \
    --port 8000

# 使用 OpenAI SDK 调用（无缝切换）
python -c "
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': '解释 Transformer'}]
)
print(response.choices[0].message.content)
"

# 使用 AWQ 量化模型启动
python -m vllm.entrypoints.openai.api_server \
    --model hugging-quants/Llama-3.1-8B-Instruct-AWQ \
    --quantization awq \
    --max-model-len 4096

如果你有一个 HuggingFace 格式的模型（FP16 权重），想在 Ollama 上运行，需要转换为 GGUF 格式。这个转换过程就是量化。

转换流程分为三步：第一，从 HuggingFace 下载原始模型权重；第二，使用 llama.cpp 的 quantize 工具进行量化；第三，将 GGUF 文件导入 Ollama。

关键注意事项：量化不是简单的精度降低——好的量化工具（如 llama.cpp 的 Q4_K_M）会对不同参数使用不同的量化策略。Attention 层的 QKV 矩阵使用稍高精度（K_M），FFN 层使用标准精度，嵌入层保持较高精度。这种混合策略使得 Q4_K_M 的实际精度远高于理论上的 4-bit 均值。

如果你想自己制作量化模型，推荐使用 llama.cpp 官方工具链，它提供了最稳定的量化流程和最好的精度保留效果。

# 第一步：安装 llama.cpp（需要 CMake）
git clone https://github.com/ggerganov/llama.cpp.git
cd llama.cpp
cmake -B build && cmake --build build --config Release

# 第二步：转换 HuggingFace 模型到 FP16 GGUF
python convert_hf_to_gguf.py /path/to/hf-model/ \
    --outfile model-fp16.gguf

# 第三步：量化为 Q4_K_M
./build/bin/quantize model-fp16.gguf model-q4k_m.gguf Q4_K_M

# 第四步：创建 Ollama 模型
cat > Modelfile << 'EOF'
FROM ./model-q4k_m.gguf
PARAMETER temperature 0.7
PARAMETER num_ctx 4096
EOF
ollama create my-quantized-model -f Modelfile

# 验证量化结果
ls -lh model-*.gguf
# model-fp16.gguf    15GB  (FP16)
# model-q4k_m.gguf    4.9GB (Q4_K_M)

部署大模型时，显存不仅仅是模型权重的容器。KV Cache、激活值、优化器状态（训练时）都会占用显存。理解显存的完整分配，是避免 OOM（Out of Memory）的关键。

显存分配的三个主要部分：

模型权重：这是最直观的部分。一个 7B 参数的模型，FP16 约 14GB、INT4 约 3.5GB。这部分是固定的，不会因为输入变化而改变。

KV Cache：这是被很多人忽略的"显存杀手"。在自回归生成过程中，模型需要缓存每个 token 的 Key 和 Value 向量，以便后续 token 的 attention 计算。KV Cache 的大小与上下文长度 × 批处理大小成正比。一个 7B 模型在 4096 上下文长度下，KV Cache 可能需要额外 1-2GB 显存。在 vLLM 中，使用 PagedAttention 技术可以减少 KV Cache 的碎片化浪费，但总量仍然与上下文长度成正比。

激活值：前向计算过程中的中间结果。推理时这部分相对较小，但在大 batch 或长上下文时会显著增长。对于 MoE 模型，激活值还包括门控网络的中间状态，这部分通常不大但在极端 batch size 下也不容忽视。

减少显存占用的实战技巧：第一，控制上下文长度——不要默认开到最大，按需设置。如果你的用户只问短问题，没有必要将 max_model_len 设为 128K。第二，使用滑动窗口 Attention——如 Mistral 的 4K 滑动窗口，只关注最近的 token，不需要缓存整个上下文。第三，量化 KV Cache——vLLM 支持 KV Cache 量化（fp8），可以减少 30-50％ 的缓存显存。第四，动态批处理——不要让所有请求都使用最大上下文，而是根据实际输入长度动态分配。

显存监控实战：在生产环境中，建议使用 nvtop 或 nvidia-smi 实时监控 GPU 显存使用。如果发现显存长期接近上限（>90％），说明配置过于激进，需要降低 max_num_seqs 或 max_model_len。如果显存长期低于 50％，说明资源浪费，可以增加并发量来提升吞吐量。

# vLLM 中控制显存使用
python -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen2.5-7B-Instruct \
    --max-model-len 4096 \
    --max-num-batched-tokens 8192 \
    --gpu-memory-utilization 0.90 \
    --max-num-seqs 32 \
    --kv-cache-dtype fp8

# 关键参数说明：
# --max-model-len: 最大上下文长度（影响 KV Cache）
# --max-num-batched-tokens: 批处理最大 token 数
# --gpu-memory-utilization: GPU 显存利用率上限
# --max-num-seqs: 最大并发序列数
# --kv-cache-dtype fp8: KV Cache 量化（节省显存）

选择推理框架时，需要从部署场景、硬件条件、性能要求、运维能力四个维度综合评估。

个人开发/原型验证：Ollama 是最佳选择。零配置、跨平台、模型即装即用。不需要写代码就能跑起来，适合快速验证想法。缺点是并发能力弱、不适合生产。

生产环境 API 服务：vLLM 是最佳选择。高吞吐、低延迟、OpenAI 兼容 API、支持量化和并行。需要一定的运维能力（Docker、GPU 驱动配置），但换来的是企业级性能。

研究和实验：HuggingFace Transformers 最灵活。可以深入控制模型行为的每一个环节，适合需要定制注意力机制、修改模型结构的研究场景。但性能不如专门的推理框架。

边缘设备部署：llama.cpp（Ollama 的底层引擎）支持纯 CPU 推理，可以在树莓派、MacBook Air 等无 GPU 设备上运行。速度虽慢但可用。

本地部署只是 AI 工程的起点。掌握部署后，你可能还想了解以下方向：

模型微调：使用 LoRA（llm-003）在自有数据上微调模型，让通用模型变成你的专属模型。微调后的模型同样可以部署到 Ollama 或 vLLM。微调的关键是数据质量——与其用 10 万条低质量数据，不如用 1000 条高质量数据。微调后的模型通常需要重新量化（因为 LoRA 权重与原模型权重合并后可能需要调整量化策略）。

RAG 架构（llm-002）：将本地模型与向量数据库结合，实现基于私有知识库的问答。这是企业内部 AI 应用最常见的架构。RAG 的核心是将私有文档切分为向量（使用嵌入模型），存储到向量数据库（如 Milvus、Chroma、Qdrant），然后在用户查询时检索相关文档，拼接为上下文后交给本地模型生成回答。RAG 的优势是不需要微调——只要文档更新了，向量数据库自动同步，模型就能回答最新问题。

Agent 开发（agent-001）：在本地模型基础上构建智能体，让模型能够自主调用工具、规划任务。Ollama 和 vLLM 都兼容主流 Agent 框架（LangChain、LlamaIndex、AutoGen）。Agent 开发的关键是工具设计——每个工具的输入输出格式必须清晰，错误处理必须健壮。一个设计糟糕的工具会让整个 Agent 循环陷入死循环。

模型评估（llm-010）：部署后如何评估模型质量？需要建立自动化评估流程，定期检测模型的准确率、延迟和稳定性。评估方法包括：基准测试（在标准数据集上跑分）、人工评估（抽样检查模型回答质量）、A/B 测试（对比新旧模型在实际场景中的表现）。建议每周至少跑一次基准测试，及时发现模型性能回退。

多模型路由：在生产环境中，可以用一个路由器根据请求复杂度分发到不同大小的模型——简单问题走小模型（快速便宜），复杂问题走大模型（慢但准确）。路由策略可以是基于规则的（如关键词匹配、长度判断），也可以是基于分类模型的（训练一个小模型判断请求复杂度）。这是控制成本和性能的最佳实践。一个典型的路由配置是：80％ 的简单请求走 7B 模型（延迟 < 1s），20％ 的复杂请求走 70B 模型（延迟 < 5s），整体平均延迟控制在 1.5s 以内。

如果你准备将本地模型部署到生产环境，以下是一份完整的上线检查清单，涵盖了从硬件准备到上线监控的所有关键步骤。

硬件准备阶段：第一，确认 GPU 型号和显存。NVIDIA A100（80GB）适合 70B 级别模型，RTX 4090（24GB）适合 7-14B 级别，RTX 3090（24GB）也可以但推理速度稍慢。第二，确认 CPU 和内存。CPU 主要负责数据预处理和后处理，内存用于加载模型权重（CPU 推理时）。建议至少 32GB 系统内存。第三，确认存储。模型文件通常很大（FP16 的 70B 模型约 140GB），建议使用 NVMe SSD 以减少加载时间。

软件配置阶段：第一，安装 GPU 驱动和 CUDA。确保驱动版本与推理框架兼容（vLLM 通常需要 CUDA 12.1+）。第二，安装推理框架（vLLM 或 Ollama）。第三，下载模型权重。建议从 HuggingFace 官方仓库下载，避免第三方镜像的安全风险。第四，编写部署脚本和 Docker 配置，确保环境可复现。

测试验证阶段：第一，功能测试——跑 10-20 个典型查询，确认模型回答质量符合预期。第二，性能测试——使用 wrk 或 locust 进行压力测试，确认在目标并发量下的延迟和吞吐量。第三，异常测试——输入异常数据（超长文本、特殊字符、恶意 prompt），确认系统不会崩溃。第四，安全测试——确认 API 有鉴权机制，模型权重文件没有暴露在公网。

上线监控阶段：第一，部署监控——使用 Prometheus + Grafana 监控 GPU 利用率、显存使用、请求延迟、错误率。第二，告警配置——设置延迟 > 5s 或错误率 > 1％ 时告警。第三，日志记录——记录每个请求的输入输出（脱敏后），便于问题排查和模型评估。第四，定期评估——每周跑一次基准测试，每月评估一次模型质量。

# 生产环境部署脚本示例
#!/bin/bash

# 1. 环境检查
echo "检查 GPU 驱动..."
nvidia-smi --query-gpu=name,memory.total --format=csv,noheader

echo "检查 CUDA 版本..."
nvcc --version

echo "检查磁盘空间..."
df -h / | awk 'NR==2 {print "可用空间: " $4}'

# 2. 启动推理服务
nohup python -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen2.5-7B-Instruct \
    --dtype half \
    --max-model-len 4096 \
    --gpu-memory-utilization 0.90 \
    --port 8000 > /var/log/vllm.log 2>&1 &

echo "等待服务启动..."
sleep 10

# 3. 健康检查
curl -s http://localhost:8000/health
if [ $? -eq 0 ]; then
    echo "服务启动成功 ✅"
else
    echo "服务启动失败 ❌"
    exit 1
fi

# 4. 功能测试
curl -s http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen2.5-7B-Instruct", "messages": [{"role": "user", "content": "你好"}]}'

# 5. 性能基准
wrk -t4 -c100 -d30s http://localhost:8000/v1/chat/completions \
    -s post.lua  # post.lua 包含请求 body