2. 模型Serving架构总览：离线训练与在线推理的差异、Serving系统的核心组件、常见的Serving架构模式

在信用评分模型从研发到上线的全生命周期中，模型Serving（模型服务）是连接离线训练与在线业务决策的关键桥梁。本章将系统梳理离线训练与在线推理的核心差异，拆解Serving系统的三大核心组件，并对比三种主流的架构模式，帮助您建立完整的Serving架构视野。

2.1 离线训练 vs 在线推理：核心差异

信用评分模型的离线训练与在线推理在目标、环境、性能要求等方面存在本质区别。理解这些差异是设计Serving架构的前提。

2.2 Serving系统的核心组件

一个生产级的信用评分Serving系统通常由以下三大核心组件构成，它们协同工作以保障服务的稳定、高效与可维护性。

2.3 常见的Serving架构模式

根据业务规模、团队组织和技术栈的不同，信用评分模型的Serving架构通常有以下三种模式。每种模式在灵活性、运维成本和性能上各有取舍。

2.3.1 单体架构（Monolithic）

将API网关、推理引擎、模型管理等功能打包在同一个进程中部署。适用于模型数量少、调用量小的初期阶段。

• 优点： 部署简单，调试方便，延迟最低（无网络调用）。
• 缺点： 扩展性差，模型更新需全量发布，故障隔离性弱。
• 适用场景： 单一评分卡模型、内部工具或POC验证。

2.3.2 微服务架构（Microservices）

将API网关、推理引擎、特征计算、模型管理等拆分为独立的微服务，通过REST/gRPC通信。适用于多模型、多策略并行的生产环境。

• 优点： 独立部署与扩展，技术栈灵活，故障隔离，支持A/B测试。
• 缺点： 运维复杂度高，网络延迟增加，需要服务治理（注册发现、链路追踪）。
• 适用场景： 多模型评分、实时风控决策引擎、大型金融平台。

2.3.3 Serverless架构

将推理逻辑封装为函数（如AWS Lambda、阿里云函数计算），由云平台自动管理资源伸缩。适用于调用量波动大、追求极致资源利用率的场景。

• 优点： 零运维，按需付费，自动弹性伸缩。
• 缺点： 冷启动延迟（尤其对于大模型），执行时长受限，不适合长尾高并发。
• 适用场景： 轻量级评分、批量异步推理、事件驱动型风控。