很多企业在用了一段时间 OpenAI API 之后，都会面临同一个问题：数据不能出境、成本居高不下、依赖外部服务风险太高。私有化部署大模型，逐渐从"尝鲜"变成了越来越多公司的刚需。
但私有部署的坑也不少。本文从工程实践角度，梳理 2026 年主流方案的选型逻辑与落地细节。—## 为什么要私有化部署在谈方案之前，先明确驱动力，因为这直接决定你该选哪种方案：| 驱动力 | 优先方案 ||--------|---------|| 数据合规/隐私 | 完全私有化（不联网） || 成本控制 | 自托管 + 开源模型 || 低延迟 | 本地推理（GPU/CPU 就近部署） || 定制化 | 私有微调后部署 || 高并发 | 分布式推理集群（vLLM） |—## 方案全景目前主流的私有部署方案分为三个层次：开发/个人 小团队/PoC 生产/企业级 │ │ │ Ollama LM Studio vLLM / TGI（最简单） （桌面友好） （高性能） │ LocalAI（API兼容层）—## 方案一：Ollama（开发和原型首选）### 适用场景- 开发环境、原型验证- 单机 CPU/GPU 推理- 团队内部工具### 安装与启动bash# macOS / Linux 一键安装curl -fsSL https://ollama.com/install.sh | sh# Windows 下载安装包，或使用 WSL2# 拉取模型ollama pull qwen2.5:7b # 阿里通义千问，中文能力强ollama pull llama3.2:3b # Meta Llama，轻量版ollama pull deepseek-r1:8b # 推理能力强ollama pull nomic-embed-text # 向量化模型# 启动服务（默认 11434 端口）ollama serve### 配置环境变量bash# 允许远程访问（默认只监听 localhost）export OLLAMA_HOST=0.0.0.0:11434# 设置模型存储路径export OLLAMA_MODELS=/data/ollama/models# 设置 GPU 使用（自动检测，也可手动指定）export CUDA_VISIBLE_DEVICES=0,1# 生产建议：写入 systemd servicecat > /etc/systemd/system/ollama.service << 'EOF'[Unit]Description=Ollama ServiceAfter=network-online.target[Service]ExecStart=/usr/local/bin/ollama serveUser=ollamaGroup=ollamaRestart=alwaysRestartSec=3Environment="OLLAMA_HOST=0.0.0.0:11434"Environment="OLLAMA_MODELS=/data/ollama/models"[Install]WantedBy=default.targetEOFsystemctl enable ollamasystemctl start ollama### API 使用（兼容 OpenAI）Ollama 提供 OpenAI 兼容接口，代码几乎不用改：pythonfrom openai import OpenAI# 只需改 base_urlclient = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama", # 随便填)response = client.chat.completions.create( model="qwen2.5:7b", messages=[ {"role": "system", "content": "你是一个专业的Python工程师"}, {"role": "user", "content": "写一个快速排序算法"}, ], temperature=0.3,)print(response.choices[0].message.content)# 流式输出stream = client.chat.completions.create( model="qwen2.5:7b", messages=[{"role": "user", "content": "解释什么是RAG"}], stream=True,)for chunk in stream: if chunk.choices[0].delta.content: print(chunk.choices[0].delta.content, end="", flush=True)### Ollama 的局限性- 并发性能有限：适合低并发（5 QPS 以下），高并发会明显排队- 不支持张量并行：单卡装不下的大模型无法跨卡并行- 无生产级监控：缺少请求追踪、Token 统计等生产必备特性—## 方案二：vLLM（生产级高并发首选）### 适用场景- 生产环境，需要支撑 10+ QPS- 多用户并发访问- 需要精确的 Token 计费和监控### 为什么 vLLM 快vLLM 引入了 PagedAttention 技术：传统推理把 KV Cache 预分配为固定大小的连续内存块，浪费严重；PagedAttention 按页动态管理 KV Cache，内存利用率提升 3-5 倍，吞吐量比 HuggingFace Transformers 高 20x 以上。### 安装部署bash# 安装（需要 CUDA 12.1+）pip install vllm# 单 GPU 启动python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --dtype auto \ --max-model-len 8192 \ --gpu-memory-utilization 0.9# 多 GPU 张量并行（适合 70B+ 大模型）python -m vllm.entrypoints.openai.api_server \ --model meta-llama/Llama-3.1-70B-Instruct \ --tensor-parallel-size 4 \ # 4张GPU并行 --host 0.0.0.0 \ --port 8000# Docker 方式（推荐生产使用）docker run --runtime nvidia --gpus all \ -v /data/models:/root/.cache/huggingface \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model Qwen/Qwen2.5-7B-Instruct \ --max-model-len 8192### 关键参数调优bash# 生产配置示例（7B 模型，单 A100 80G）python -m vllm.entrypoints.openai.api_server \ --model /models/qwen2.5-7b-instruct \ --host 0.0.0.0 \ --port 8000 \ --served-model-name qwen2.5-7b \ # API 中使用的名称 --dtype bfloat16 \ # bf16 精度（A100支持） --max-model-len 16384 \ # 最大上下文长度 --max-num-seqs 256 \ # 最大并发请求数 --gpu-memory-utilization 0.88 \ # GPU 内存利用率（留点余量） --enable-chunked-prefill \ # 减少长 prompt 的延迟 --max-num-batched-tokens 8192 \ # 批处理 token 上限 --quantization awq # 使用 AWQ 量化（可选，省显存）### vLLM 监控集成python# 访问内置 metrics 端点（Prometheus 格式）# http://localhost:8000/metrics# 关键指标：# vllm:num_requests_running - 当前运行请求数# vllm:num_requests_waiting - 排队等待请求数# vllm:gpu_cache_usage_perc - KV Cache 使用率# vllm:avg_prompt_throughput_toks_per_s - Prompt 吞吐量# vllm:avg_generation_throughput_toks_per_s - 生成吞吐量# Grafana Dashboard 模板：https://grafana.com/grafana/dashboards/21079—## 方案三：Text Generation Inference（TGI）HuggingFace 出品，适合 HuggingFace 生态深度用户：bash# Docker 启动docker run --gpus all --shm-size 1g \ -p 8080:80 \ -v /data/models:/data \ ghcr.io/huggingface/text-generation-inference:latest \ --model-id /data/qwen2.5-7b-instruct \ --num-shard 1 \ --max-input-length 4096 \ --max-total-tokens 8192 \ --max-batch-prefill-tokens 16384TGI vs vLLM 选型：- TGI：HuggingFace 模型更新快，与 HF Hub 集成无缝，适合需要快速跟进最新模型的场景- vLLM：高并发性能更好，商用场景主流选择—## API 网关层：统一入口不管底层用什么推理引擎，建议在前面加一个 API 网关：python# 使用 LiteLLM 作为统一网关# pip install litellm[proxy]# config.yamlmodel_list: - model_name: gpt-4o # 对外的统一名称 litellm_params: model: openai/gpt-4o # 实际调用 OpenAI api_key: os.environ/OPENAI_API_KEY - model_name: gpt-4o # 同名，自动负载均衡 litellm_params: model: openai/qwen2.5-7b # 调用私有 vLLM api_base: http://localhost:8000/v1 api_key: no-keyrouter_settings: routing_strategy: "least-busy" # 按繁忙程度路由 num_retries: 3 timeout: 30# 启动网关litellm --config config.yaml --port 4000这样做的好处：- 应用代码统一调用 http://gateway:4000/v1，不感知后端切换- 可以在不修改代码的情况下，从 OpenAI 切换到私有模型- 内置 Token 计费、请求日志、限流—## 硬件选型参考| 模型规模 | 推荐 GPU | 显存要求（bf16） | 适合并发 ||---------|---------|----------------|---------|| 3B | RTX 3060 12G | 6G | 5 QPS || 7B | RTX 4090 24G | 15G | 10-20 QPS || 14B | A10G 24G | 28G | 10-15 QPS || 32B | A100 40G | 64G | 15-20 QPS || 70B | 4x A100 80G | 140G | 20-30 QPS |量化可以大幅降低显存需求：7B 模型 4-bit 量化后只需 4G 显存，虽然精度略有损失，但对大多数任务影响可接受。—## 生产化 Checklist部署完推理服务，还差最后一步：生产化改造。必须有的：- [ ] 健康检查端点（/health）- [ ] Prometheus 指标暴露- [ ] 请求日志（包含 Token 用量）- [ ] GPU 监控（nvidia-smi 集成）- [ ] 自动重启（systemd / k8s）建议有的：- [ ] 限流（防止单用户打满）- [ ] API Key 鉴权（LiteLLM 内置）- [ ] 多副本 + 负载均衡（高可用）- [ ] 模型版本管理（灰度切换）可选的：- [ ] 请求队列（Redis/RabbitMQ，削峰填谷）- [ ] 模型热加载（不停服更新）- [ ] 推理结果缓存（相同请求复用）—## 成本对比：私有 vs SaaS以 GPT-4o 级别能力对比（按 1 亿 Token/月估算）：| 方案 | 月成本估算 | 备注 ||------|-----------|------|| OpenAI GPT-4o API | ¥50,000 | $0.005/1K token 均值 || 租用 A100 + Qwen2.5-72B | ¥8,000 | 两台 A100，约3倍速度 || 自建服务器（3年折旧） | ¥3,000 | 4x A100，一次性投入 |结论：用量超过 500 万 Token/月，私有部署开始有经济价值；超过 1 亿 Token/月，私有部署节省 80% 以上。—## 总结2026 年的私有部署已经非常成熟，不再是"极客专属"：- Ollama：开发环境首选，5 分钟跑起来- vLLM：生产环境首选，高并发、高稳定- TGI：HuggingFace 重度用户首选- LiteLLM：任何场景都值得加一层 API 网关选型建议：先用 Ollama 验证模型效果，确认方案可行后再上 vLLM 的生产集群，加 LiteLLM 做统一入口，这条路线在工程实践中已经被反复验证。