推理服务的基本概念与高可用架构基础
2.1 推理服务的基本概念
推理服务（Inference Service）是指将训练完成的机器学习模型部署到生产环境，对外提供实时或批量的预测能力。与训练阶段不同，推理服务面向的是持续到达的业务请求，需要满足确定的延迟、吞吐和可用性要求。一个典型的推理服务请求链路包含以下环节：
- 客户端请求：来自 Web 应用、移动端或下游微服务的 HTTP/gRPC 调用。
- 网关层：负责鉴权、路由、限流和负载均衡，将请求分发到推理实例。
- 推理引擎：加载模型权重，执行前向计算（如 TensorRT、ONNX Runtime、vLLM 等）。
- 模型存储：模型文件通常存放在对象存储或文件系统中，实例启动时加载。
- 特征/上下文存储：部分推理需要查询实时特征或历史上下文（如推荐系统）。
推理服务与训练服务在资源特征上有本质差异。训练任务通常以分钟或小时为单位运行，允许失败重试；而推理请求往往在毫秒到秒级内必须返回结果，且请求量随时间波动明显。因此，推理服务的高可用设计需要围绕“请求不失败、延迟不超时、容量可扩展”三个核心目标展开。
2.2 常见推理服务架构模式
根据业务场景和部署环境的不同，推理服务架构通常分为以下三种模式：
2.2.1 单体式推理服务
将模型加载、预处理、推理和后处理封装在同一个服务进程中，通过 REST/gRPC 对外提供接口。这种模式适合模型数量少、逻辑简单的场景，部署和运维成本低，但扩展性受限——当多个模型共存时，资源无法隔离，一个模型的流量高峰可能影响其他模型。
2.2.2 流水线式推理服务
将推理链路拆分为多个独立阶段（如预处理 → 特征工程 → 模型推理 → 后处理），每个阶段独立部署和扩缩容。这种模式适合复杂推理场景（如视频理解、多模型融合），但增加了链路延迟和运维复杂度。
2.2.3 模型网格/路由式架构
借鉴 Service Mesh 思想，在推理引擎前增加一层智能路由。路由层根据模型版本、请求特征、实例负载等条件，将请求动态分发到不同的模型副本或推理引擎。这是当前大模型推理平台（如 KServe、Seldon Core）的主流架构，支持金丝雀发布、A/B 测试和自动扩缩容。
下图展示了三种架构的演进关系与核心组件：
2.3 高可用性定义与衡量指标
推理服务的高可用性（High Availability, HA）是指系统在给定时间内持续提供正确推理结果的能力。衡量高可用性不能只看“服务是否活着”，还需要从多个维度综合评估。以下是推理服务场景下最核心的衡量指标：
| 指标类别 | 指标名称 | 定义与计算方式 | 典型目标值 |
|---|---|---|---|
| 可用性 | 服务可用率 | 成功请求数 / 总请求数 × 100%（排除客户端错误） | ≥ 99.9% |
| 故障恢复时间 | 从故障发生到服务完全恢复的时间（MTTR） | < 5 分钟 | |
| 性能 | P99 延迟 | 99% 的请求在多少毫秒内完成 | 视业务而定（通常 < 200ms） |
| 吞吐量 | 单位时间（每秒）能处理的请求数（QPS/TPS） | 满足峰值流量 × 1.5 冗余 | |
| 准确性 | 推理正确率 | 模型输出与预期结果一致的比率 | 与离线评测一致 |
| 漂移检测 | 输入数据分布变化导致准确率下降的监控 | 持续监控，及时告警 | |
| 弹性 | 扩容时间 | 从触发扩容到新副本完全就绪的时间 | < 3 分钟 |
2.4 高可用设计核心原理
推理服务的高可用设计遵循三个核心原理：冗余、隔离和快速失败。
- 冗余（Redundancy）：通过多副本、多可用区部署消除单点故障。但需要注意，模型服务的副本并非越多越好——每个副本都需要加载模型到内存/显存，资源开销大，且模型加载时间可能长达数十秒甚至数分钟。
- 隔离（Isolation）：不同模型、不同租户、不同优先级任务之间需要资源隔离。在 GPU 环境中，隔离尤为重要——一个模型的显存溢出不应导致同一块 GPU 上的其他模型崩溃。
- 快速失败（Fail Fast）：当某个实例或依赖组件出现异常时，应尽快暴露问题并触发熔断，而不是让请求长时间挂起等待。快速失败能避免线程池耗尽、连接池泄漏等级联故障。