1. 课程导入
在金融行业，模型从实验室走向生产环境，往往不是“训练完就结束”，而是刚刚开始。风控评分、反欺诈识别、量化信号生成、智能投顾问答、合规文本审查等场景，都要求模型以稳定、低延迟、可审计的方式对外提供服务。本课程围绕金融Serving API、批量推理与版本编排三条主线展开，帮助你把“能跑的模型”变成“可交付的金融级服务”。
本节定位：这是全课程的第1章，不急于写代码，而是先建立一张“地图”。你需要清楚：金融模型服务化到底要解决什么问题、涉及哪些核心概念、整体框架如何分层、后续29章按什么路线推进。地图清晰，后面的API设计、批量调度、版本灰度才不会变成零散技巧的堆砌。
一、学习目标：从“模型可用”到“服务可信”
金融场景对模型服务的要求，显著高于一般互联网推荐或内容生成。原因在于：金融决策直接关联资金、合规与客户权益，任何一次错误响应都可能带来真实损失。因此，本课程的学习目标可以归纳为四个层次。
- 能交付：掌握用主流框架（如FastAPI、Triton、TorchServe、KServe等）封装模型，形成标准HTTP/gRPC Serving API，支持同步与异步调用。
- 能扛量：理解批量推理的吞吐与延迟权衡，能够设计离线批量打分、微批（micro-batch）与流式推理任务。
- 能控版：掌握模型版本注册、灰度发布、A/B测试、回滚与影子流量，避免“一上线就全量”的高风险操作。
- 能治理：建立输入校验、特征一致性、日志审计、监控告警与降级策略，让服务在异常时仍可控。
换句话说，学完本课程，你应当能独立回答：一个金融风控模型，如何以99.9%可用性、P99延迟低于80ms、支持每日千万级批量打分、并且可以按客户分组灰度上线？
二、核心概念：三条主线与六个关键词
课程名称已经点出三条主线：Serving API负责在线实时服务，批量推理负责离线大规模计算，版本编排负责模型生命周期与流量治理。三者不是孤立模块，而是共享同一套模型仓库、特征口径与监控体系。
| 主线 | 核心问题 | 关键指标 | 典型金融场景 |
|---|---|---|---|
| Serving API | 如何低延迟、高并发地响应单次请求 | P95/P99延迟、QPS、错误率 | 实时反欺诈、授信审批 |
| 批量推理 | 如何高效处理海量样本与定时任务 | 吞吐量、任务时长、资源成本 | 日终评分、贷后监控 |
| 版本编排 | 如何安全地发布、切换与回滚模型 | 灰度比例、回滚时间、一致性 | 模型迭代、A/B实验 |
围绕这三条主线，有六个关键词需要先建立直觉：模型仓库（存版本与元数据）、推理运行时（加载与执行模型）、特征服务（保证线上线下一致）、流量网关（路由与限流）、任务调度（批量作业编排）、可观测性（日志、指标、追踪）。后续章节会逐一展开。
三、整体框架：四层结构与数据流
把上面的概念收拢，金融模型服务化可以抽象为四层结构。第一层是接入层，由API网关承担鉴权、限流、协议转换与灰度路由；第二层是服务层，包含在线推理服务与批量任务服务；第三层是模型与特征层，管理模型版本、特征视图与一致性校验；第四层是基础设施层，提供容器编排、GPU调度、存储与监控。
一次典型的在线请求数据流是：客户端携带业务参数调用Serving API → 网关完成鉴权与路由 → 服务层拉取特征 → 推理运行时执行模型 → 返回评分与解释 → 日志与指标落库。而批量推理的数据流则是：调度器触发任务 → 读取离线特征表 → 分片并行推理 → 结果写回数据仓库 → 生成对账与审计报告。两条链路共享模型仓库与特征定义，这是保证线上线下一致的关键。
教学提示：很多团队把在线和离线做成两套完全独立的系统，导致“离线AUC很高、上线效果骤降”。本课程会反复强调：特征口径、模型版本、预处理逻辑必须统一管理，否则服务化只是把错误放大。
四、实战路线图：30章如何推进
后续章节按“先通原理、再搭服务、后做治理”的节奏展开，大致分为五个阶段。
- 基础与选型（第2-6章）：金融Serving需求分析、框架对比、环境搭建、模型序列化与加载。
- Serving API实战（第7-13章）：接口设计、请求校验、同步/异步、批处理、限流降级、性能压测。
- 批量推理实战（第14-19章）：离线打分、微批调度、分布式推理、成本优化、结果对账。
- 版本编排实战（第20-25章）：模型注册、灰度发布、A/B测试、影子流量、回滚与热更新。
- 治理与综合项目（第26-30章）：监控告警、安全合规、故障复盘，以及一个端到端的金融风控服务化项目。
五、常见误区与复盘视角
在正式进入技术细节前，先列出金融团队最常踩的五个坑，作为后续学习的“预警清单”。
- 误区一：只关注模型精度，忽略服务延迟。金融实时决策往往有硬性时间窗口，P99延迟超标等同于不可用。
- 误区二：版本管理靠文件名。没有注册中心和元数据，回滚时无法定位“到底上的哪个模型”。
- 误区三：批量任务不做幂等。重跑导致重复扣款或重复评分，是金融场景的严重事故。
- 误区四：灰度只看流量比例，不看业务分组。应按客户等级、地区、产品线等维度精细化灰度。
- 误区五：缺少降级预案。模型服务故障时，应有规则兜底或缓存结果，而不是直接报错。
复盘视角：每一次线上事故都值得回看三个问题——模型版本是否可追溯？特征是否与训练一致？降级路径是否被验证过？把这三个问题变成检查清单，能避免大部分金融Serving事故。
本节建立了课程的整体认知框架：以Serving API、批量推理、版本编排为三条主线，以模型仓库、推理运行时、特征服务、流量网关、任务调度、可观测性为六个支点，按五阶段路线图推进。接下来，我们将从金融Serving的需求分析与框架选型开始，进入真正的工程实战。