3. 环境搭建与快速上手

在金融多模型 Serving 场景中，Ray Serve 的价值在于把“模型推理”从单机脚本升级为可编排、可扩展、可观测的服务。但在真正部署多模型之前，必须先完成一次最小闭环：安装 Ray、启动 Serve、部署一个模型、发起调用并验证结果。这一节的目标不是追求复杂架构，而是让你亲手跑通第一个可用的推理服务，并理解每一步背后的机制。

核心原理：Ray Serve 的最小运行单元

Ray Serve 的核心抽象是 Deployment。一个 Deployment 本质上是一个可独立扩缩容的服务单元，它封装了模型加载逻辑和请求处理逻辑。当你调用 serve.run() 时，Ray 会在集群中创建对应的副本（Replica），每个副本持有独立的模型实例，并通过 HTTP 或 Python API 接收请求。

整个链路可以概括为：客户端请求 → Serve 代理（Proxy）→ 路由到 Deployment 副本 → 执行模型推理 → 返回响应。理解这条链路，有助于后续排查“请求为什么没到模型”“为什么延迟高”“副本为什么没扩容”等问题。

Ray Serve 最小请求链路 客户端 HTTP / Python Serve Proxy 路由与负载均衡 Deployment 副本 1 模型实例 A Deployment 副本 2 模型实例 B 响应返回 JSON / 预测结果

方法流程：四步跑通第一个服务

  1. 安装 Ray：推荐使用 Python 3.9～3.11，执行 pip install "ray[serve]"。金融场景若需 GPU 推理，应同时确认 CUDA 驱动与 PyTorch/TensorFlow 版本匹配。
  2. 启动 Serve：在 Python 脚本中调用 serve.start()，或在命令行使用 serve start。本地开发默认使用 HTTP 端口 8000。
  3. 部署模型：用 @serve.deployment 装饰类，在 __init__ 中加载模型，在 __call__ 中处理请求，最后通过 serve.run() 发布。
  4. 调用与测试：通过 requests.post 访问 http://localhost:8000/，或使用 Serve 的 Python Handle 直接调用，并检查日志与返回结构。

下面是一个最小可运行示例，部署一个模拟信用评分模型：

import ray
from ray import serve
import requests

ray.init()
serve.start()

@serve.deployment(num_replicas=1)
class CreditScorer:
    def __init__(self):
        self.model_name = "credit_score_v1"

    async def __call__(self, request):
        data = await request.json()
        score = 680 + data.get("income", 0) // 1000
        return {"model": self.model_name, "score": score}

serve.run(CreditScorer.bind(), route_prefix="/score")

resp = requests.post(
    "http://localhost:8000/score",
    json={"income": 25000}
)
print(resp.json())

运行后，终端会输出类似 {"model": "credit_score_v1", "score": 705} 的结果。这说明请求已经成功经过 Proxy、路由到 Deployment 副本并返回。此时你可以打开 http://localhost:8265 查看 Ray Dashboard，观察 Deployment 状态、副本数量和请求指标。

案例/场景：金融风控中的最小验证

假设你正在为一家消费金融公司搭建反欺诈模型服务。第一步不是直接接入生产流量，而是用 Ray Serve 部署一个“影子模型”，只接收内部测试请求。你可以将上面的 CreditScorer 替换为真实的 XGBoost 或 PyTorch 模型，并在 __init__ 中完成模型加载。通过 serve.run() 发布后，用一批历史样本回放调用，对比离线评分与在线评分是否一致。这个最小闭环能提前暴露模型加载失败、输入格式不匹配、依赖缺失等问题。

检查项 命令/方式 预期结果
Ray 是否安装成功 python -c "import ray; print(ray.__version__)" 输出版本号，无报错
Serve 是否启动 serve status 显示 running 状态
Deployment 是否就绪 Dashboard 或 serve status 副本数为 1，状态 HEALTHY
HTTP 调用是否通 curl -X POST ... 返回 JSON 预测结果
日志是否有异常 终端或 Dashboard Logs 无 Traceback、无超时

误区与复盘

误区一：忘记调用 serve.run()。只定义 Deployment 不会自动发布，必须显式运行 serve.run() 或通过 YAML 配置启动。

误区二：在 __init__ 中做耗时操作。模型加载应放在 __init__，但不要在其中发起网络请求或等待外部服务，否则副本启动会超时。

误区三：忽略 route_prefix。多个 Deployment 同时运行时，必须为每个服务指定不同的 route_prefix，否则会冲突。

误区四：本地能跑就认为生产能跑。本地默认单副本、无 GPU 调度，生产环境需考虑资源声明、自动扩缩容和健康检查。

复盘时建议记录三个关键信息：首次部署耗时、单次推理延迟、副本启动日志。这些数据将成为后续多模型编排和性能调优的基线。只有先跑通最小闭环，才能在金融场景中安全地引入多模型路由、A/B 测试和灰度发布。

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