一个 AI 服务有多个处理步骤，Ray Serve 让它们分别部署再接起来

一个 AI 接口可能先整理输入，再运行模型，最后查询业务数据或重新排序。这些步骤不一定需要相同资源：模型要 GPU，格式处理可能只需 CPU。Ray Serve 的组合接口，让它们分别成为部署，再由一个入口接起来。

这篇面向已经有多阶段推理任务的 Python 开发者。值得看的不是再加几个“代理角色”，而是步骤之间的数据怎样传、谁等待谁，以及哪一步可以独立配置。

先连部署，再在运行时调用

官方组合指南使用 bind 将部署传入另一个部署的构造器。运行后，接收方拿到的是 DeploymentHandle，可以用 remote 调用对应方法。

Handle 返回 DeploymentResponse，代表未来结果，而非已经算好的值。程序可以 await 等待，也可以把它作为后续调用的顶层参数交给下游部署。把响应嵌在列表或其他对象里直接传递的旧方式已经不受支持。Ray Serve 会在前一步结束后，将真实输出送到下一步。

文档用一条算术链展示这个关系：输入5，先加1，再乘2，得到12。它是部署数据流的教学程序，没有运行语言模型；它说明的重点是两步不需要各自暴露成外部 HTTP 地址，再由客户端来回搬运结果。

Serve 总览将模型与任意 Python 业务逻辑放在同一编程方式里。部署拆开后，可以分别设置副本与资源，而不必把整条流程都按最重模型的条件配置。

教学情境中，一条检索回答服务可以有资料处理、模型推理和结果整理几步。拆分的价值，是让繁忙步骤独立扩容，让不同计算各有资源配置；这不是官方已经交付的一份中文知识库，也不证明拆开一定更快。

部署间仍会有调度、传输和失败处理。适合拆到什么程度，需要看步骤本身有多少计算和复用需求，而不是把每一个小函数都变成远端调用。

指南提醒，在部署内部用 await 等结果；直接调用 result() 会阻塞，影响同一副本处理其他代码和请求。接口看起来相近，等待行为却不同。

流式调用还有另一份约定：方法用生成器，Handle开启stream后，返回 DeploymentResponseGenerator。应用可逐段读取，但不能把它像普通单次响应一样直接传给下一次Handle调用。

因此，最终返回一份完整对象的流程，与逐字交回回答的流程，需要分别安排中间步骤。不能只在最后加一个stream开关，就期待整条多服务链自动变成流式。

Ray采用Apache-2.0，模型与集群资源另行准备。对多阶段AI应用，这套机制留下的实际成果是一张可运行的调用关系：入口接谁，前一步结果到哪里，哪一步能独立增加资源，都可以在程序里明确表达。