2.4 模型部署与推理

你手上有一个开源模型（下载的或微调过的），下一步是让它跑起来、对外提供服务。这个环节直接决定了用户体验的两个核心指标：响应延迟和并发能力。

部署方案的选择取决于一个简单的问题：你的场景是"自己用"还是"给别人用"？

一、本地运行：自己用

如果你只是想在自己的电脑上跑模型——做实验、写代码辅助、或者搭个本地知识库——不需要折腾复杂的推理框架。

Ollama

最推荐的本地方案，没有之一。它把模型下载、管理、运行、API 服务全部打包成一个工具，体验接近 Docker。

bash

# 安装后一行命令就能跑起来
ollama run llama3          # 跑 LLaMA 3
ollama run qwen2.5:7b      # 跑 Qwen 2.5 7B
ollama run deepseek-r1:8b  # 跑 DeepSeek-R1 蒸馏版

启动后自动在 localhost:11434 提供 OpenAI 兼容的 API，你的应用代码几乎不需要改动就能从云端 API 切换到本地模型。

Ollama 还支持 Modelfile——类似 Dockerfile 的配置文件，几行代码就能创建自定义模型（预设 System Prompt、调整温度、加载你的 LoRA 等）：

dockerfile

FROM qwen2.5:7b
SYSTEM "你是一个专业的代码审查助手，只关注安全问题和性能问题。"
PARAMETER temperature 0.3

LM Studio

如果你更喜欢图形界面：

直接从 Hugging Face 搜索、下载 GGUF 格式模型
内置类似 ChatGPT 的聊天界面，开箱即用
同样提供 OpenAI 兼容的本地 API 服务器

适合不想碰命令行的场景，或者给非技术同事演示用。

二、生产部署：给别人用

当你需要部署一个高并发的 API 服务——给公司内部用、给客户用、或者作为产品后端——就需要专业的推理框架了。核心诉求是：高吞吐、低延迟、稳定运行。

vLLM：性能标杆

vLLM 是目前生产环境部署的首选方案，几乎所有认真做推理服务的团队都在用它。

核心技术是 PagedAttention——借鉴操作系统的虚拟内存分页思想来管理 KV Cache，显存利用率比传统方案高出数倍，直接转化为更高的并发吞吐量。

bash

# 一行命令启动 OpenAI 兼容的 API 服务
python -m vllm.entrypoints.openai.api_server \
    --model qwen/Qwen2.5-7B-Instruct \
    --tensor-parallel-size 2 \    # 双卡并行
    --max-model-len 32768

python

# 客户端调用，和调 OpenAI API 完全一样
from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="unused")

response = client.chat.completions.create(
    model="qwen/Qwen2.5-7B-Instruct",
    messages=[{"role": "user", "content": "解释一下 PagedAttention 的原理"}]
)
print(response.choices[0].message.content)

vLLM 的优势：

兼容 OpenAI API 格式，客户端代码零改动
支持连续批处理（Continuous Batching），GPU 利用率拉满
支持张量并行（多卡推理）、LoRA 动态加载、流式输出
适用于 A10、A100、H100 等数据中心显卡

TGI（Text Generation Inference）

Hugging Face 官方的推理服务容器，为生产环境设计：

支持分布式推理、量化、流式输出
Docker 一键部署，运维友好
很多云厂商的推理服务底层就是 TGI

和 vLLM 相比，TGI 在极端吞吐场景下略逊一筹，但胜在部署简单、和 Hugging Face 生态无缝集成。

llama.cpp / GGUF：CPU 推理之王

名字带 cpp，但它早已不只是 CPU 方案——支持 CUDA、Metal（Mac）、Vulkan 等多种后端。

它的独特价值在于：唯一能让大模型在纯 CPU 环境下流畅运行的方案。配合 GGUF 量化格式，一台普通服务器（甚至树莓派）就能跑 7B 模型。

适用场景：边缘设备、没有 GPU 的服务器、Mac 本地开发（Metal 加速效果很好）。

Python 绑定：llama-cpp-python，可以直接在 Python 项目中调用。

三、部署优化：榨干每一分算力

模型跑起来只是第一步。要在生产环境中稳定、高效地服务，还需要掌握几个关键优化技术。

量化（Quantization）

把模型权重从高精度（FP16/BF16）压缩到低精度（INT8/INT4），用微小的精度损失换取显著的显存节省和速度提升。

量化方案	适用场景	特点
GGUF	CPU / Apple Silicon / 边缘设备	llama.cpp 生态，格式通用，量化等级灵活（Q4_K_M 最常用）
GPTQ	GPU 推理	离线量化，精度保持好，vLLM 原生支持
AWQ	GPU 推理	比 GPTQ 更快，激活感知量化，精度略优

经验法则：4-bit 量化（Q4）在大多数任务上几乎感知不到质量下降，是性价比最高的选择。

连续批处理（Continuous Batching）

传统批处理的问题：一个 batch 里最慢的请求没生成完，其他已完成的请求也得等着，GPU 在空转。

连续批处理的做法：生成完的请求立即返回，空出的位置立即插入新请求。GPU 始终满载运行，吞吐量提升 2–5 倍。

vLLM 和 TGI 都默认启用，不需要额外配置。

KV Cache 量化

长上下文推理时，KV Cache 会占用大量显存（32K 上下文的 7B 模型，KV Cache 可能占到总显存的 30%+）。对 KV Cache 做 FP8/INT8 量化，可以在几乎不影响质量的前提下显著降低显存占用，让同一张卡能服务更多并发请求。

推测解码（Speculative Decoding）

用一个小模型（draft model）快速生成候选 token，再用大模型一次性验证。命中率高时，推理速度可以提升 2–3 倍，且输出质量和纯大模型完全一致。

适合场景：大模型推理成本高、但有对应的小模型可用（比如 70B + 7B 的组合）。

四、云端部署：没有 GPU 怎么办

不是每个团队都有自己的 GPU 集群。好消息是，云端方案已经非常成熟。

Serverless 推理平台

按用量付费，不用管基础设施：

Replicate / Modal：按秒计费，冷启动优化好，适合低频或突发流量场景
Hugging Face Inference Endpoints：独占实例，按小时计费，一键部署任意 HF 模型
硅基流动 / 火山引擎：国内平台，延迟更低，合规更方便

GPU 云服务器

租 GPU 机器，自己搭 vLLM 服务：

AutoDL：国内性价比最高的 GPU 租赁平台，适合实验和中小规模部署
阿里云 PAI / 腾讯云 TI：企业级方案，有完整的 MLOps 工具链
Lambda / RunPod：海外方案，H100 资源相对充裕

自建的好处是完全可控，代价是需要自己处理运维、扩缩容、监控等问题。

五、选型速查

你的情况	推荐方案
个人实验 / Mac 用户	Ollama
想要图形界面	LM Studio
企业高并发 / 有 N 卡服务器	vLLM
没有 GPU / 边缘设备	llama.cpp（GGUF 量化）
不想运维	Serverless 平台（Replicate / Modal）或直接用闭源 API
需要快速上线 + HF 生态	TGI Docker 部署

一个务实的建议：先用闭源 API 把产品跑通，确认有真实需求后再考虑自部署。过早优化部署架构是创业团队最常见的资源浪费。

六、GPU 选型指南

GPU	显存	能跑的模型	参考价格	适用
RTX 4090	24 GB	7B（FP16）/ 13B（INT4）	¥16,000	个人开发/小团队
A10	24 GB	7B（FP16）/ 13B（INT4）	云：¥3-5/小时	云端小规模
A100 40G	40 GB	13B（FP16）/ 34B（INT4）	云：¥15-25/小时	生产中规模
A100 80G	80 GB	34B（FP16）/ 70B（INT4）	云：¥30-50/小时	生产大规模
H100	80 GB	70B（FP16）/ 140B（INT4）	云：¥50-80/小时	大规模高性能

显存估算公式：

FP16 推理：显存 ≈ 参数量 × 2 bytes × 1.2（KV Cache 开销）
INT4 推理：显存 ≈ 参数量 × 0.5 bytes × 1.2

示例：Qwen2.5-7B
  FP16：7B × 2 × 1.2 ≈ 16.8 GB → 需要 24 GB 卡
  INT4：7B × 0.5 × 1.2 ≈ 4.2 GB → 消费级显卡即可

七、性能监控

python

# vLLM 自带 Prometheus 指标
# 启动时添加：--enable-metrics

# 关键指标：
# vllm:request_latency_seconds     — 请求延迟
# vllm:num_requests_running        — 并发请求数
# vllm:num_requests_waiting        — 排队请求数
# vllm:gpu_cache_usage_perc        — GPU KV Cache 利用率
# vllm:avg_generation_throughput   — 生成吞吐量（tokens/s）

yaml

# Grafana 仪表盘核心面板：
# 1. 请求延迟分布（P50/P95/P99）
# 2. 吞吐量趋势（tokens/s）
# 3. GPU 显存使用率
# 4. 排队请求数（>0 说明需要扩容）
# 5. 错误率

健康检查端点：

python

# FastAPI 健康检查（包装 vLLM）
@app.get("/health")
async def health():
    try:
        resp = await httpx.AsyncClient().get("http://localhost:8000/health")
        gpu_usage = get_gpu_memory_usage()
        return {
            "status": "healthy",
            "vllm": resp.status_code == 200,
            "gpu_memory_used_pct": gpu_usage
        }
    except Exception as e:
        return {"status": "unhealthy", "error": str(e)}

2.4 模型部署与推理 ​

一、本地运行：自己用 ​

Ollama ​

LM Studio ​

二、生产部署：给别人用 ​

vLLM：性能标杆 ​

TGI（Text Generation Inference） ​

llama.cpp / GGUF：CPU 推理之王 ​

三、部署优化：榨干每一分算力 ​

量化（Quantization） ​

连续批处理（Continuous Batching） ​

KV Cache 量化 ​

推测解码（Speculative Decoding） ​

四、云端部署：没有 GPU 怎么办 ​

Serverless 推理平台 ​

GPU 云服务器 ​

五、选型速查 ​

六、GPU 选型指南 ​

七、性能监控 ​

2.4 模型部署与推理

一、本地运行：自己用

Ollama

LM Studio

二、生产部署：给别人用

vLLM：性能标杆

TGI（Text Generation Inference）

llama.cpp / GGUF：CPU 推理之王

三、部署优化：榨干每一分算力

量化（Quantization）

连续批处理（Continuous Batching）

KV Cache 量化

推测解码（Speculative Decoding）

四、云端部署：没有 GPU 怎么办

Serverless 推理平台

GPU 云服务器

五、选型速查

六、GPU 选型指南

七、性能监控