L2 · 主题中枢

服务设施

模型部署推理框架服务架构生产运维

服务设施不是部署脚本，而是将模型转化为可治理生产能力的工程中枢

2核心嵌入节点
5关键控制维度
99.9%典型可用性目标
先记住部署只是起点，服务治理才是核心

模型上线不等于服务可用。真正的服务设施需解决版本管理、流量控制、资源调度、可观测性与故障恢复，否则将迅速演变为运维黑洞。

查看下属主题 ↓
LIVE
CORE AI Serving
01 WHAT

是什么

服务设施是将训练好的 AI 模型封装为可调用 API，并提供高可用、可观测、可扩展运行环境的工程体系。

02 WHY

为什么

模型本身无法直接服务业务，需通过标准化接口、资源调度与监控机制，将算法能力转化为稳定、可控、可计量的生产服务。

03 HOW

怎么做

从选定推理框架开始，完成模型转换、服务封装、压测验证，再逐步接入网关、扩缩容与可观测组件。

04 WHEN

什么时候

当模型需对外提供低延迟、高并发或需版本管理、灰度发布时使用；仅做离线批处理或单次实验时不需完整服务设施。

THIS PAGE INCLUDES
模型部署推理框架

FOCUS

先记住这些

只留最重要的判断，细节见下方实践
01 独特价值

为什么需要服务设施

模型训练完成仅具备算法能力，服务设施将其封装为可调用、可监控、可迭代的 API 服务，支撑业务集成与规模化使用。

02 复杂度

真正难在哪里

需同时优化延迟与吞吐、处理硬件异构性、管理多版本共存、实现无损扩缩容，并在故障时快速定位根因。

03 使用判断

什么时候用

当需对外提供稳定 API、要求 SLA、多模型并行或需灰度发布时启用；仅做实验或离线处理时避免过度工程化。

ROUTE

学习路径

建议按此顺序逐步深入
01
理解模型部署流程

掌握模型导出、格式转换、服务封装与基础验证

02
选择推理框架

根据模型类型、硬件平台与性能要求匹配框架

03
构建服务治理

接入网关、监控、扩缩容与版本管理组件

PROBLEM / POSITION / INTERFACE

先弄清它为什么存在，以及谁在使用

不从历史开始，从真实工作关系开始。
  1. 01 解决的问题

    模型训练完成，需接入业务系统或开放给外部调用

    直接运行脚本无法处理并发、缺乏监控、版本混乱、资源浪费、故障难定位

    成功标准
    模型以稳定 API 形式提供服务，具备可观测指标、自动扩缩容、版本隔离与快速回滚能力
  2. 02 AI 生态位

    位于模型训练与业务应用之间，承接模型权重，输出结构化推理结果

    上游
    依赖训练产出的模型文件、量化配置、依赖环境与测试用例
    下游
    为前端应用、Agent 系统、数据管道或第三方 API 提供推理能力
  3. 03 人的生态位

    工程师负责架构选型、部署策略、性能调优与故障响应，不直接干预单次推理

    适合使用
    需对外提供 API、要求 SLA、多版本共存、需灰度发布或资源弹性调度
    不必使用
    仅做本地验证、离线批处理、单次推理或资源极度受限且无运维能力
  4. 04 独特价值

    将算法能力转化为可度量、可治理、可迭代的工程资产，而非一次性实验产物

    需同时平衡延迟、吞吐、成本与稳定性，且不同模型架构对硬件与框架的适配差异极大

    复杂度判断
    复杂度不是功能数量，而是控制与验证成本。

INTERFACE FLOW

谁在操作，信息怎样流动

  1. WHO OPERATES

    HUMAN负责服务架构设计、部署策略制定、性能调优与故障排查

    BACKEND负责请求路由、负载均衡、自动扩缩容与日志采集

    TOOL推理框架执行模型计算，网关处理协议转换与限流

  2. INPUT

    HTTP/gRPC 请求、批处理任务队列、模型权重文件与配置参数

  3. CONTROL

    并发阈值、超时设置、缓存策略、版本路由规则、资源配额、监控告警阈值

  4. OUTPUT

    结构化推理结果（JSON/Protobuf）、服务状态指标、日志与追踪数据、自动扩缩容信号

FLOW

服务上线流程

01模型准备导出训练模型，转换为推理框架支持的格式，验证输入输出一致性
02服务封装编写服务逻辑，定义 API 接口，集成推理框架与预处理/后处理代码
03压测验证模拟真实负载，测试延迟、吞吐、内存占用与错误率，调整批处理与并发参数
04灰度发布小流量接入新版本，对比指标，确认无性能退化或功能异常后全量切换
05接入治理配置监控告警、自动扩缩容、日志采集与版本回滚策略

COMPARE

部署方式对比

维度容器化服务Serverless 推理裸机直跑
维度容器化服务Serverless 推理裸机直跑
维度容器化服务Serverless 推理裸机直跑
维度容器化服务Serverless 推理裸机直跑
维度容器化服务Serverless 推理裸机直跑

PRACTICE

最小可用部署清单

✓确认模型格式与推理框架兼容
✓编写基础服务脚本，暴露健康检查端点
✓定义输入输出 Schema 与错误处理逻辑
✓配置基础监控（延迟、错误率、资源使用）
✓执行压测并记录基线指标
✓设置版本标签与回滚机制
CODE / PYTHON最小服务调用示例
import requests
import os

API_URL = os.getenv("SERVING_API_URL")
HEADERS = {"Authorization": f"Bearer {os.getenv('API_KEY')}"}

payload = {
    "inputs": "What is the capital of France?",
    "parameters": {"max_new_tokens": 50}
}

response = requests.post(f"{API_URL}/v1/generate", json=payload, headers=HEADERS)
response.raise_for_status()
result = response.json()
print(result["generated_text"])

使用 requests 调用已部署的推理 API

JSON / RESPONSE典型 API 返回结构
{
  "generated_text": "The capital of France is Paris.",
  "usage": {
    "prompt_tokens": 8,
    "completion_tokens": 7,
    "total_tokens": 15
  },
  "model": "llama-3-8b-instruct",
  "latency_ms": 142
}

FAQ

常见问题

选型、用法与失败，不复述定义。
01谁在实际负责服务设施的运维？＋

算法工程师提供模型，MLOps/后端工程师负责部署与治理，SRE 保障可用性。

明确责任边界，避免模型上线后无人维护。
02服务设施与直接运行推理脚本有什么区别？＋

服务设施提供 API 封装、并发处理、监控与版本管理，脚本仅支持单次执行。

决定是否需要引入工程化组件。
03最小可用服务需要哪些组件？＋

推理框架 + 基础 HTTP 服务 + 健康检查 + 基础监控。

帮助快速验证，避免初期过度设计。
04生产环境最容易在哪些环节失败？＋

内存泄漏、GPU OOM、冷启动延迟、版本不兼容、监控缺失导致故障扩散。

决定压测重点与监控策略。
05什么时候不需要完整服务设施？＋

仅做本地验证、离线批处理、单次推理或资源极度受限时。

控制系统成本与复杂度。