3. Model Serving 架构设计：整体架构分层与关键组件选型

在风控评分通道中，Model Serving 架构需要同时满足高并发、低延迟、高可用和可观测四大核心要求。本章从整体架构分层出发，逐层拆解设计要点，并对比主流推理框架的选型策略。

3.1 整体架构分层

我们将 Model Serving 系统划分为三个核心逻辑层：接入层、推理层和存储层。每一层职责清晰，层间通过轻量级协议（HTTP/gRPC）解耦，便于独立扩缩容与灰度发布。

3.2 接入层设计要点

接入层是流量的第一道关卡，在风控场景中需要处理每秒数千到数万次评分请求。接入层的主要职责包括：

• 协议转换：客户端通常使用 HTTP/JSON，推理层内部推荐使用 gRPC/Protobuf 以获得更好的序列化性能和强类型约束。
• 限流与熔断：基于令牌桶或滑动窗口算法，防止突发流量冲垮推理节点。熔断策略采用半开状态自动恢复。
• 灰度路由：根据请求头、用户 ID 或模型版本标签，将流量按比例分发到不同推理集群，支持 A/B 测试和金丝雀发布。
• 请求校验与鉴权：校验必填字段、签名、API Key，拒绝无效请求，降低推理层无效计算开销。

3.3 推理层核心设计

推理层是 Model Serving 的心脏，直接承载模型计算。设计时需要重点考虑模型加载策略、批量推理和资源隔离三个维度。

3.3.1 模型加载与热更新

• 冷启动加载：服务启动时从对象存储（S3/MinIO）拉取模型文件到本地缓存，加载到 GPU/CPU 内存。
• 热更新：通过监听模型仓库的版本变更事件（etcd watch / 文件系统 inotify），在不重启服务的情况下切换模型版本。
• 版本管理：每个模型保留最近 N 个版本，支持按版本号或标签（stable/canary）路由请求。

3.3.2 批量推理策略

风控评分模型通常为轻量级树模型或浅层神经网络，单次推理延迟在 1-10ms 量级。批量推理可以显著提升吞吐量：

• 动态批处理：推理框架自动收集请求，在最大延迟容忍度内组成 batch，减少内核启动开销。
• 队列管理：为每个模型维护独立请求队列，设置最大 batch size 和最大等待时间（如 32 条 / 5ms）。
• 优先级调度：高优先级请求（如实时交易评分）可跳过队列直接推理，或插入队列头部。

3.4 关键组件选型：Flask vs FastAPI vs Triton

在推理框架选型上，需要根据模型类型、部署规模和性能要求做出权衡。下表从多个维度对比三个主流选项：

3.5 混合架构推荐：FastAPI + Triton

在风控评分通道的实际落地中，我们推荐采用FastAPI 作为推理编排层，Triton 作为模型计算引擎的混合架构。FastAPI 负责请求解析、特征预处理、结果后处理、调用链追踪；Triton 负责模型加载、GPU 资源调度和批量推理。两者通过 gRPC 通信，兼顾灵活性与性能。

# FastAPI 编排层示例：调用 Triton 进行推理
import tritonclient.grpc as grpcclient
from fastapi import FastAPI, Request
from pydantic import BaseModel

app = FastAPI()
triton_client = grpcclient.InferenceServerClient(url="triton:8001", verbose=False)

class ScoreRequest(BaseModel):
    user_id: str
    features: list[float]

@app.post("/v1/score")
async def score(request: ScoreRequest):
    # 1. 特征预处理（归一化、缺失值填充）
    processed_features = preprocess(request.features)

    # 2. 构造 Triton 请求
    inputs = [grpcclient.InferInput("input", [1, len(processed_features)], "FP32")]
    inputs[0].set_data_from_numpy(np.array([processed_features], dtype=np.float32))
    outputs = [grpcclient.InferRequestedOutput("output")]

    # 3. 调用 Triton 推理
    result = triton_client.infer(model_name="xgb_score", inputs=inputs, outputs=outputs)
    score = result.as_numpy("output")[0][0]

    # 4. 结果后处理（分数映射、阈值判断）
    final_decision = postprocess(score)

    return {"user_id": request.user_id, "score": float(score), "decision": final_decision}

3.6 存储层设计要点

存储层在 Model Serving 中承担特征缓存、评分结果持久化和模型元数据管理三类职责：

• 特征缓存（Redis）：缓存实时特征（如设备指纹、IP 画像），减少重复计算。设置 TTL 过期策略，避免冷数据堆积。
• 评分结果持久化（MySQL / ClickHouse）：记录每次评分的请求 ID、用户 ID、模型版本、输入特征摘要、输出分数、决策结果、耗时。用于离线分析、模型监控和审计。
• 模型元数据（etcd / ZooKeeper）：存储模型版本、路由规则、健康状态。推理层通过 watch 机制感知元数据变更，实现热更新。