模型 Serving 基础概念
模型 Serving（模型服务）是将训练好的机器学习模型部署到生产环境，对外提供稳定、低延迟推理接口的过程。在信用评分场景中，Serving 系统直接承载风控决策、额度审批等核心业务，其设计质量决定了模型能否真正产生业务价值。
核心定义：模型 Serving ≠ 模型部署。部署是“把模型放到服务器上”，Serving 是“让模型持续、可靠、高效地对外提供推理能力”，包含资源管理、版本控制、监控告警、弹性伸缩等系统工程能力。
2.1 在线推理与批量推理
信用评分业务同时存在两种推理模式，它们的架构设计、性能要求和适用场景差异显著：
| 对比维度 | 在线推理（Online Inference） | 批量推理（Batch Inference） |
|---|---|---|
| 触发方式 | 用户请求实时触发（如申请信用卡瞬间） | 定时任务或事件驱动（如每日批量跑分） |
| 延迟要求 | 毫秒级（通常 < 200ms） | 分钟级到小时级均可 |
| 数据规模 | 单条或少量请求 | 数万到数千万条 |
| 资源模式 | 常驻服务，持续占用资源 | 按需拉起，任务结束后释放 |
| 典型场景 | 实时审批、交易反欺诈 | 存量客户评分、贷后监控 |
| 版本管理 | 蓝绿部署、金丝雀发布 | 离线任务版本快照 |
实践建议：信用评分系统通常同时部署两套推理链路。在线推理使用 RESTful API 或 gRPC 接口，批量推理使用 Spark/Flink 作业或定时 Python 脚本。两套链路共享同一个模型注册表，但资源池完全隔离。
2.2 Serving 系统的关键性能指标
信用评分 Serving 系统需要同时满足业务、工程和合规三个维度的要求。以下三个指标是评估系统健康度的核心：
延迟（Latency）
从客户端发起推理请求到收到完整响应的时间间隔。在信用评分场景中，延迟直接影响用户体验和转化率。
- P50 延迟：半数请求的响应时间，反映系统正常负载下的表现
- P99 延迟：最慢 1% 请求的响应时间，反映系统尾部性能
- 典型目标：在线推理 P99 < 500ms，P50 < 100ms
吞吐量（Throughput）
单位时间内系统能处理的推理请求数量，通常以 QPS（Queries Per Second）或 TPS（Transactions Per Second）衡量。
- 峰值吞吐：业务高峰期（如双十一、月底账单日）的最大请求量
- 持续吞吐：日常平均负载下的稳定处理能力
- 扩缩容关系：吞吐量通常与实例数线性相关，但受模型复杂度、特征计算量制约
可用性（Availability）
系统在给定时间范围内正常提供推理服务的概率，通常用“几个9”表示。
| 可用性等级 | 年停机时间 | 信用评分场景适用性 |
|---|---|---|
| 99%（2个9） | 87.6 小时 | 非核心辅助评分，可接受 |
| 99.9%（3个9） | 8.76 小时 | 常规风控评分，基本满足 |
| 99.99%（4个9） | 52.56 分钟 | 实时审批、交易反欺诈，推荐 |
| 99.999%（5个9） | 5.26 分钟 | 核心支付决策，需要多活架构 |
常见误区：不要只关注平均延迟而忽略 P99。信用评分场景中，P99 延迟过高会导致部分用户长时间等待，造成审批超时或体验降级。建议同时监控 P50、P99、P999 三个分位值。
2.3 信用评分场景的 Serving 架构要点
结合上述概念，信用评分 Serving 系统在设计时需要关注以下工程实践：
- 特征计算前置：将特征工程逻辑从模型推理中剥离，部署独立的特征服务（Feature Store），降低模型容器的计算负载
- 模型版本灰度：新模型上线时先切 5%-10% 流量，观察 P99 延迟和分数分布，确认无异常后再全量切换
- 超时熔断：设置合理的超时阈值（如 800ms），超过阈值直接返回降级分数或走人工审核，避免请求堆积
- 容量规划：根据历史峰值 QPS × 1.5 冗余系数规划实例数，同时配置 HPA（Horizontal Pod Autoscaler）应对突发流量
信用评分特有指标：除了通用性能指标，还需要监控“评分分布漂移”（Score Drift）和“拒绝率变化”，这些是模型 Serving 层需要暴露给监控系统的业务级指标。