3. 模型Serving基础概念
在额度定价场景中，模型训练完成后并非终点，真正的挑战在于如何将模型高效、稳定地部署到生产环境，实时响应业务请求。这一环节被称为模型Serving。本章将系统讲解模型Serving的定义、在线推理与离线批处理的区别，以及衡量Serving系统质量的核心指标。
3.1 模型Serving的定义
模型Serving（模型服务化）是指将训练好的机器学习模型部署到生产环境中，通过标准化的接口（如RESTful API、gRPC）对外提供预测能力的过程。它不仅仅是简单的模型加载，而是涵盖模型版本管理、资源调度、请求预处理、推理执行、结果后处理以及监控告警的一整套工程化体系。
核心要点：模型Serving是连接“模型开发”与“业务决策”的桥梁，其质量直接影响最终用户的体验和业务收益。
3.2 在线推理与离线批处理的区别
根据业务场景的实时性要求，模型推理分为在线推理和离线批处理两种模式。额度定价场景中，两者各有适用场景，且常常混合使用。
| 对比维度 | 在线推理 (Online Inference) | 离线批处理 (Batch Inference) |
|---|---|---|
| 触发方式 | 用户请求实时触发（如点击“申请额度”） | 定时任务或数据到达触发（如每日凌晨跑批） |
| 延迟要求 | 毫秒级（通常 < 200ms） | 分钟级到小时级 |
| 吞吐量 | 受限于单机或集群的并发处理能力 | 可大规模并行，吞吐量高 |
| 数据规模 | 单条或小批量（1~100条） | 大规模（百万~亿级） |
| 模型更新 | 热加载/蓝绿部署，需保证服务不中断 | 可离线更新，重启服务影响小 |
| 典型场景 | 实时额度审批、欺诈检测 | 批量额度重定价、风险报告生成 |
| 资源消耗 | 需要预留峰值资源，成本较高 | 按需分配资源，成本可控 |
实战建议：在额度定价系统中，通常采用“在线为主、离线为辅”的策略。实时审批走在线推理，而每日的额度调整、风险监控则通过离线批处理完成，以平衡响应速度与计算成本。
3.3 Serving系统的核心指标
衡量一个模型Serving系统的好坏，通常关注三个核心指标：延迟、吞吐量和可用性。这三个指标相互制约，需要在系统设计时进行权衡。
3.3.1 延迟 (Latency)
延迟指从发送请求到收到响应所经历的时间，通常以P50（中位数）、P99（99分位）和P999（99.9分位）来衡量。在额度定价场景中，P99延迟通常要求控制在200ms以内，否则会影响用户体验，导致用户流失。
3.3.2 吞吐量 (Throughput)
吞吐量指系统在单位时间内能处理的请求数量，常用QPS（每秒查询数）或TPS（每秒事务数）表示。吞吐量受模型复杂度、硬件资源、并发数等因素影响。在额度定价中，需要根据业务峰值（如“双11”大促）来预估吞吐量需求。
3.3.3 可用性 (Availability)
可用性指系统在给定时间内正常提供服务的时间比例，通常用几个9来表示（如99.9%、99.99%）。对于金融核心链路，可用性要求通常为99.99%以上，这意味着全年停机时间不超过52.56分钟。
| 指标 | 定义 | 额度定价场景建议值 | 常见瓶颈 |
|---|---|---|---|
| 延迟 (Latency) | 请求响应时间（P99） | < 200ms | 模型计算复杂度、网络IO、特征工程耗时 |
| 吞吐量 (Throughput) | 每秒处理的请求数（QPS） | 根据业务峰值预估（如 5000 QPS） | GPU/CPU资源、模型批处理大小、并发连接数 |
| 可用性 (Availability) | 服务正常运行时间比例 | ≥ 99.99% | 单点故障、依赖服务不可用、模型加载失败 |
注意：三个指标之间存在“不可能三角”关系：提升吞吐量往往会增加延迟，而追求高可用性则需要冗余部署，可能增加延迟。在实际工程中，需要根据业务场景进行取舍，例如通过模型量化降低延迟，通过水平扩展提升吞吐量，通过多副本+负载均衡保障可用性。