1. 课程导入

在金融业务中，模型从来不是孤立存在的。一个典型的智能风控或智能投顾系统，往往同时运行着反欺诈模型、信用评分模型、额度定价模型、营销响应模型、舆情情绪模型，甚至还有大语言模型驱动的智能客服与投研问答。这些模型可能由不同团队用不同框架训练：XGBoost、LightGBM、PyTorch、TensorFlow、Hugging Face Transformers，甚至还有规则引擎和传统评分卡。把它们统一部署、统一扩缩容、统一监控，并保证毫秒级响应与合规审计，就是“多模型 Serving”要解决的核心问题。

一、金融多模型 Serving 的四大挑战

与互联网推荐场景相比，金融场景对 Serving 的要求更苛刻。我们可以把挑战归纳为四类：

  • 异构性：模型格式、运行时、依赖库、GPU/CPU 资源需求差异巨大。一个 BERT 模型可能需要 GPU，而一个评分卡只需要几毫秒的 CPU 计算。
  • 低延迟与高并发：支付反欺诈要求 P99 延迟在 50ms 以内，而营销模型可以容忍秒级。同一套 Serving 平台必须能按模型 SLA 差异化调度。
  • 合规与可审计：每一次推理请求都要可追溯：谁调的、用了哪个模型版本、输入输出是什么、是否命中拒绝规则。金融监管要求模型可解释、可回滚。
  • 弹性与成本：白天客服大模型流量高，夜间批量评分任务重。资源要能动态伸缩，同时避免 GPU 长期空转造成浪费。
核心矛盾：模型数量多、类型杂、SLA 不同，但运维团队希望用一套统一的抽象来管理部署、扩缩容、路由和监控。

二、Ray Serve 的定位：分布式 Python 原生 Serving 框架

Ray Serve 是 Ray 生态中的在线推理服务框架。它的关键定位可以概括为三点：Python 原生、组合式部署、与 Ray 分布式运行时无缝集成。与 TorchServe、Triton 等偏“单模型高性能”的方案不同，Ray Serve 更擅长把多个模型、多个业务逻辑组合成一个可编排的推理图。

在 Ray Serve 中，最核心的抽象是 Deployment。一个 Deployment 就是一个可独立扩缩容的服务单元，内部封装了模型加载与推理逻辑。多个 Deployment 可以通过 bind() 组合成 Application，形成有向无环的调用关系。例如：

from ray import serve
import requests

@serve.deployment(num_replicas=2, ray_actor_options={"num_gpus": 0.5})
class FraudModel:
    def __init__(self):
        self.model = load_fraud_model()
    async def __call__(self, request):
        data = await request.json()
        score = self.model.predict(data)
        return {"fraud_score": score}

@serve.deployment(num_replicas=1)
class CreditModel:
    def __init__(self):
        self.model = load_credit_model()
    async def __call__(self, request):
        data = await request.json()
        return {"credit_score": self.model.predict(data)}

@serve.deployment
class RiskGateway:
    def __init__(self, fraud, credit):
        self.fraud = fraud
        self.credit = credit
    async def __call__(self, request):
        data = await request.json()
        fraud_result = await self.fraud.remote(data)
        credit_result = await self.credit.remote(data)
        return {"fraud": fraud_result, "credit": credit_result}

app = RiskGateway.bind(FraudModel.bind(), CreditModel.bind())

这段代码展示了 Ray Serve 的典型用法：每个模型是一个 Deployment，网关负责编排。扩缩容、副本调度、请求路由由 Ray Serve 自动完成，开发者只需关注业务逻辑。

三、核心原理：从请求到推理的完整链路

理解 Ray Serve 的关键，是理解一次请求在系统中的流转路径。下图展示了金融多模型 Serving 中，请求从入口到多个模型副本的完整数据流与资源分配关系。

金融多模型 Serving 请求流转与资源分配 客户端 HTTP / gRPC RiskGateway Deployment 编排 / 路由 / 聚合 num_replicas=1 FraudModel XGBoost / 实时反欺诈 CPU · P99 < 50ms num_replicas=4 CreditModel LightGBM / 信用评分 CPU · P99 < 100ms num_replicas=2 LLMService 大模型 / 智能客服 GPU · P99 < 2s num_replicas=1 · GPU=1 Ray Cluster Head Node Worker Node 1 CPU × 16 Worker Node 2 CPU × 16 Worker Node 3 GPU × 1 Autoscaler 动态扩缩容 Metrics 延迟 / QPS / 错误率 聚合响应返回

从图中可以看到，Ray Serve 的请求链路包含几个关键环节：入口网关接收请求后，根据 Deployment 的绑定关系将请求分发到下游模型副本；每个副本独立运行在 Ray Actor 中，拥有自己的资源配额；Ray 的 Autoscaler 根据队列长度和延迟指标动态调整副本数。这种架构让“一个网关编排多个异构模型”成为可能。

四、典型金融场景与常见误区

在真实项目中，Ray Serve 常被用于以下场景：

场景 模型组合 关键诉求 Ray Serve 价值
实时反欺诈 XGBoost + 规则引擎 + 图模型 P99 < 50ms，高并发 多副本并行、低延迟路由
智能投顾 LLM + 风险评分 + 组合优化 多模型编排、GPU 共享 组合式 Deployment、GPU 分片
信贷审批 评分卡 + LightGBM + 反欺诈 可审计、版本可回滚 版本化部署、请求日志
舆情监控 BERT + 情感分类 + 摘要 批量与实时混合 弹性扩缩容、队列调度
常见误区一：把 Ray Serve 当成“单模型推理服务器”。 如果只需要部署一个模型，Triton 或 TorchServe 可能更轻量。Ray Serve 的真正优势在于多模型组合、Python 原生编排和与 Ray 生态的集成。
常见误区二：忽视副本资源隔离。 多个 Deployment 共享 Ray 集群时，如果不设置 ray_actor_options 中的 CPU/GPU 配额，可能出现某个模型副本抢占资源，导致关键业务延迟飙升。金融场景务必为每个 Deployment 明确资源边界。
复盘建议： 在项目初期，先用一个最小化的“网关 + 两个模型”原型验证链路，再逐步加入 Autoscaler、监控和版本管理。不要一开始就追求大而全的架构。

五、学习目标与整体框架

本课程围绕“金融多模型 Serving 实战”展开，学习目标如下：

  1. 理解 Ray Serve 的核心抽象：Deployment、Application、Bind、Replica。
  2. 掌握多模型编排、请求路由、资源配额与自动扩缩容的配置方法。
  3. 能够为金融场景设计低延迟、高可用、可审计的 Serving 架构。
  4. 学会使用 Ray Dashboard、日志、指标进行排障与性能调优。
  5. 完成一个包含反欺诈、信用评分和 LLM 客服的端到端实战项目。

整体课程分为五个模块：基础篇（Ray Serve 核心概念与环境搭建）、部署篇（单模型与多模型部署、版本管理）、性能篇（批处理、GPU 共享、Autoscaler、延迟优化）、金融实战篇（反欺诈、信贷、投顾场景落地）、运维篇（监控、日志、灰度发布与故障恢复）。每一章都会围绕一个可运行的最小示例展开，确保你不仅能理解原理，还能直接动手实践。

接下来，我们将从 Ray Serve 的环境搭建与第一个 Deployment 开始，逐步构建属于你自己的金融多模型 Serving 平台。

← 上一章 📖 返回目录 下一章 →