模型部署与服务化：从训完到上线

L7-01/02/03/04 你学了 GPU、分布式训练、推理优化、量化。 但训完只是开始—— 让它在生产环境稳定运行 24/7、服务千万用户、低延迟、低成本——是另一门工艺。

这一篇讲模型部署的工程实战。

部署的三大目标

目标	含义
延迟（Latency）	用户从问到答多久
吞吐（Throughput）	每秒能服务多少请求
成本	每次调用花多少美元

通常三者不能同时最优——是 trade-off：

• 低延迟 → 不能批处理 → 吞吐降
• 高吞吐 → 批处理 → 延迟升
• 极低成本 → 用小模型 / 量化 → 质量降

部署的核心工作就是找到适合业务的平衡点。

部署选项 1：用 API

最简单——直接调 OpenAI / Anthropic / Google：

from openai import OpenAI
client = OpenAI()
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": prompt}]
)

优点：

• 零运维
• 永远最新最强模型
• 按用量付费
• 全球低延迟

缺点：

• 贵（高频调用累积爆炸）
• 数据出公司
• 受厂商节流影响
• 不能定制

适合：低频调用、原型、初创公司。

部署选项 2：自建推理服务

把开源 LLM（Llama / Mistral / Qwen）部署到自己服务器：

简单方案：Ollama

# 启动服务
ollama serve

# 调用
curl http://localhost:11434/api/generate -d '{
  "model": "llama3.3:70b",
  "prompt": "Why is the sky blue?"
}'

优点：

• 极简启动
• 自动量化（GGUF）
• 跨平台

缺点：

• 单机
• 吞吐有限
• 不适合企业级

适合：个人开发、本地测试、小团队。

中等方案：vLLM

L7-03 详讲过—— 高吞吐、PagedAttention、Continuous Batching：

# 启动 vLLM server
python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Meta-Llama-3-70B-Instruct \
    --tensor-parallel-size 4

OpenAI 兼容 API——客户端不改代码。

适合：中型公司、自建推理。

企业方案：Triton Inference Server

NVIDIA 出的—— 生产级、多模型、多框架、性能极致：

# 客户端
import tritonclient.http as httpclient

client = httpclient.InferenceServerClient(url="localhost:8000")
inputs = httpclient.InferInput("text", [1], "BYTES")
inputs.set_data_from_numpy(input_data)
response = client.infer("llama3", inputs=[inputs])

优点：

• 极致性能
• 模型仓库管理
• A/B 测试支持
• 监控完善

缺点：

• 配置复杂
• 学习曲线陡

适合：大公司生产环境。

部署架构模式

模式 1：单机

   ┌────────────────┐
   │  Load Balancer │
   └─────────┬──────┘
             ↓
   ┌────────────────┐
   │  vLLM Server   │  ← 一台 8xH100 服务器
   │   (Llama 70B)  │
   └────────────────┘

简单、足以应对中小规模流量。

模式 2：多副本

   ┌────────────────┐
   │  Load Balancer │
   └────┬───┬───┬───┘
        ↓   ↓   ↓
   ┌────────┐ ┌────────┐ ┌────────┐
   │ Server │ │ Server │ │ Server │  ← N 个副本
   │ vLLM   │ │ vLLM   │ │ vLLM   │
   └────────┘ └────────┘ └────────┘

水平扩展——副本越多，吞吐越大。 通常用 Kubernetes（K8s）管理。

模式 3：模型分层

快速小模型（GPT-3.5 类）   ── 70% 简单请求
   ↓ 难度判断
旗舰大模型（GPT-4 类）     ── 30% 复杂请求

用大模型解难、小模型解简单—— 成本降低 10 倍。

模式 4：缓存 + 回退

用户问题
   ↓
缓存查询（已经回答过类似问题？）
   ↓ 命中
直接返回（不调 LLM）

   ↓ 未命中
调 LLM
   ↓
存入缓存供下次

FAQ 类应用缓存命中率可达 60%+—— 直接砍掉一大半 LLM 调用。

性能优化清单

Layer 1：模型层

• 量化（L7-04）：FP16 → INT4，省 4 倍显存
• 选合适大小：不要 Llama 70B 干 Llama 7B 能干的事
• 蒸馏：用大模型训小模型

Layer 2：推理框架层

• vLLM / TensorRT-LLM：比 HF Transformers 快 10×
• Continuous batching
• PagedAttention / KV cache 管理
• FlashAttention

Layer 3：服务层

• 异步处理（不阻塞）
• 缓存（Redis 存常见问题）
• 速率限制（保护后端）
• 优先级队列（VIP 用户先）

Layer 4：基础设施层

• 用 H100 / B200（比 A100 性价比好）
• Spot instance（便宜 70%，但可能被回收）
• 多 region 部署（就近服务）

监控（很重要！）

部署后必须监控——以下指标：

业务指标

• QPS：每秒请求数
• 延迟 P50/P95/P99：用户感知
• 错误率：5xx / 超时
• token 使用量：成本核算
• 缓存命中率：优化效果

质量指标

• 输出质量：每天 sample 一些回答人工评
• 用户反馈：thumbs up/down 率
• 拒绝率：模型多频繁拒答

资源指标

• GPU 利用率：60-80% 算好
• 显存使用：留 buffer，OOM 是灾难
• 网络带宽：跨机器通信是否瓶颈

常用工具：Prometheus + Grafana。

A/B 测试

生产 LLM 应用必备—— 用一部分流量测试新版：

def route_request(user_id, prompt):
    if hash(user_id) % 100 < 5:  # 5% 用户进 B 组
        model = "new_model_v2"
    else:
        model = "current_model_v1"

    response = call_model(model, prompt)
    log_metric(model, user_id, response)
    return response

观察：

• B 组用户反馈
• B 组延迟、错误
• B 组成本

确认 B 不比 A 差——再全量推。

灾难恢复

1. Fallback 链

主模型（A）
   ↓ 失败 / 超时 / 限流
备用模型（B）
   ↓ 失败
最后的兜底（C，可能是简单回答）
   ↓
返回错误信息（最坏情况）

总要有 fallback——不能 down。

2. 健康检查

async def health_check():
    try:
        result = await call_model("hello", timeout=5)
        return result is not None
    except:
        return False

# 每 30 秒检查一次

不健康的副本要立刻从负载均衡里移除。

3. 数据备份

• 模型权重：定期备份
• 用户对话：日志保留（合规要求）
• 配置文件：版本控制

安全 / 合规

生产 LLM 部署的安全清单：

1. 输入验证

• 长度限制（防止超长 prompt）
• 频率限制（防止滥用）
• 内容过滤（敏感词检测）

2. 输出过滤

• 检测 PII 泄露（个人身份信息）
• 检测有害内容
• 必要时 redact（涂黑）

3. 访问控制

• API key 管理
• 用户权限分级
• 审计日志（谁调了什么）

4. 合规

• GDPR：欧盟用户数据
• PIPL：中国个人信息
• HIPAA：医疗（如适用）
• SOC 2：企业部署

真实案例：一个 LLM 服务的栈

某中型 AI 创业公司的实际部署（已脱敏）：

┌──────────────────────────────────────┐
│  Cloudflare CDN + Workers (边缘)      │
└─────────────────┬────────────────────┘
                  ↓
┌──────────────────────────────────────┐
│  Kong API Gateway (限流、认证)        │
└─────────────────┬────────────────────┘
                  ↓
┌──────────────────────────────────────┐
│  Redis (缓存常见问题)                │
└─────────────────┬────────────────────┘
                  ↓ (缓存未命中)
┌──────────────────────────────────────┐
│  路由层                              │
│  - 简单问题 → 小模型 (Llama 7B)      │
│  - 复杂问题 → 大模型 (GPT-4 API)     │
└──────┬──────────────┬────────────────┘
       ↓              ↓
  ┌────────┐    ┌────────────┐
  │ vLLM   │    │ OpenAI API │
  │ 自建   │    │            │
  └────────┘    └────────────┘
       ↓              ↓
┌──────────────────────────────────────┐
│  PostgreSQL（对话历史）              │
│  Prometheus（监控）                  │
│  ELK（日志）                         │
└──────────────────────────────────────┘

成本结构：

• GPU 服务器：60%（10 张 H100）
• OpenAI API：25%（兜底大模型）
• 基础设施（DB、监控等）：10%
• 人工运维：5%

**单次平均成本 $0.003**——用户付$0.01——毛利约 70%。

未来趋势

1. 边缘推理

LLM 跑在手机 / 浏览器：

• Apple MLX（M 系列）
• WebGPU（浏览器）
• Qualcomm / 联发科芯片

2026 年旗舰手机本地跑 7B 模型不是问题。

2. 专用推理芯片

不再用 GPU 做推理—— Groq LPU、Cerebras、AWS Inferentia 等专用芯片。 比 GPU 便宜 5-10 倍。

3. 推理即服务（IaaS）

云厂商提供”模型托管”：

• AWS Bedrock
• Azure OpenAI
• Google Vertex AI
• 阿里云、火山引擎、腾讯云

用户不管 GPU，只调 API——但比直接 OpenAI 便宜或更稳定。

4. 多模态部署复杂度增加

文 + 图 + 视频 + 音频 + 工具—— 部署的工程复杂度爆炸。 MLOps 工程师价值持续上升。

下一篇推荐：L7-06 训练优化进阶 或 L7-07 监控与可观测性。