本地 LLM 生产部署实践：从 Ollama 到可维护架构

本地运行大语言模型已经不只是玩具实验。Ollama、LM Studio、vLLM、llama.cpp 等工具让团队可以在自己的机器或服务器上部署模型，用于客服、内部知识库、代码助手、批量处理和隐私敏感场景。

但“能跑起来”和“能稳定生产使用”是两回事。生产部署需要考虑模型选择、硬件、并发、监控、限流、降级、更新和成本。

这篇文章整理本地 LLM 生产部署的判断框架和落地步骤。

什么时候适合本地部署

本地部署最大的价值不是“免费”，而是可控。

维度	云 API	本地部署
计费方式	按 token / 请求计费	固定硬件和电费成本
数据隐私	数据经过供应商	数据留在内网或本机
可用性	依赖网络和供应商	可离线运行
模型能力	前沿模型更强	取决于本地模型和硬件
运维成本	低	高，需要维护

适合本地部署的场景：

高频、成本敏感的内部任务；
隐私要求高的数据；
离线或内网环境；
固定、可预测的工作负载；
可以接受非前沿模型能力的场景。

不适合本地部署的场景：

低频但高复杂度任务；
必须使用最新前沿模型；
流量波动很大；
团队没有基础设施维护能力；
对质量上限要求高于成本控制。

从 Ollama 开始

Ollama 是最适合开发者快速开始的本地 LLM 工具之一。

安装和启动

# macOS
brew install ollama

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

# 拉取模型
ollama pull llama3.2

# 运行模型
ollama run llama3.2

Ollama 默认提供本地 API：

curl http://localhost:11434/api/generate -d '{
  "model": "llama3.2",
  "prompt": "Hello"
}'

这对开发环境足够，但生产环境还需要更多配置。

生产部署架构

单机架构

适合内部工具、小团队、低并发任务。

应用服务
  ↓ HTTP
Ollama / vLLM Server
  ↓ GPU/CPU
本地模型

优点：简单、成本低。缺点：单点故障、扩展有限。

多实例架构

适合较高并发：

应用服务
  ↓
负载均衡
  ├─ LLM Server 1
  ├─ LLM Server 2
  └─ LLM Server 3

需要处理：

健康检查；
请求超时；
模型版本一致；
日志聚合；
GPU 资源监控。

队列架构

适合批量任务：

1	任务队列 → worker → 本地 LLM → 结果存储

这种方式不要求低延迟，适合摘要、分类、内容处理、离线分析。

模型选择

模型选择要看任务，而不是只看参数量。

任务	推荐模型类型	注意点
分类/路由	小模型	要评估准确率
摘要	中等模型	注意长文本截断
代码辅助	代码模型	测试真实项目代码
中文内容	中文能力强的模型	不只看英文 benchmark
RAG 问答	指令跟随好	检索质量比模型大小更关键

本地模型不要盲目追大。一个更小但稳定、延迟低、可并发的模型，可能比大模型更适合生产。

硬件和性能

GPU 内存

GPU 显存决定能跑多大的模型和上下文。

模型规模	粗略需求	适合用途
3B-7B	6-12GB	简单问答、分类、摘要
14B-32B	24-48GB	稍复杂任务、代码辅助
70B+	64GB+	高质量推理，部署成本高

量化选择

量化能降低显存需求，但会影响质量。

格式	优点	风险
Q8	质量更稳	显存较高
Q5	平衡	大多数场景可接受
Q4	更省显存	复杂任务质量下降
Q2/Q3	极省资源	生产风险大

生产环境建议先从 Q5/Q8 测试，不要为了省显存直接上极低量化。

生产配置要点

1. 超时和重试

本地模型可能卡住或响应变慢。必须设置：

请求超时；
最大重试次数；
fallback 策略；
失败日志。

2. 并发控制

不要让所有请求同时打到模型。

max_concurrent_requests
queue_size
request_timeout
worker_count

这些参数决定稳定性。

3. 日志和监控

至少记录：

请求量；
平均延迟；
P95 / P99 延迟；
错误率；
GPU 利用率；
显存占用；
每类任务成功率。

4. 模型版本管理

不要直接覆盖生产模型。应该保留版本：

model_name
model_version
quantization
context_length
prompt_template_version

这样出现质量问题时可以回滚。

常见坑

坑 1：只测 demo prompt

Demo prompt 跑得好，不代表生产任务好。必须用真实数据集测试。

坑 2：忽略上下文长度

上下文越长，显存和延迟越高。很多本地模型不是“塞越多越好”。

坑 3：没有队列

没有队列的系统在高峰期会直接被打爆。

坑 4：没有人工兜底

本地模型质量不稳定时，要有人工复核或云端 fallback。

本地 LLM 部署检查清单

上线前确认：

明确任务类型；
选择合适模型和量化；
用真实样本评估质量；
设置超时和重试；
控制并发；
记录延迟和错误；
保留模型版本；
定义 fallback；
有回滚方案。

总结

本地 LLM 生产部署的关键，不是把模型跑起来，而是把它纳入可靠的工程系统：有路由、有队列、有监控、有版本、有回滚。

如果你的任务高频、稳定、隐私敏感，本地部署很值得；如果你追求最强模型能力或流量不稳定，云 API 仍然更简单。