Torchserve gRPC服务端响应流实现方案咨询

原生支持现状 #

最新版Torchserve不支持原生gRPC服务端流，官方默认的gRPC接口仅提供一元RPC调用（单次请求-单次响应），你提到的客户端流视频示例是反向场景，无法满足“单请求接收实时中间更新”的需求。

实现服务端流的两种可行方式 #

1. 自定义HTTP端点插件（无需修改核心源码） #

这是性价比最高的方案：

• 借助Torchserve的自定义端点插件机制，编写Python自定义Handler，通过HTTP分块传输编码模拟服务端流。
• 在长耗时推理过程中，每生成一个中间结果，就直接向响应流输出数据，Torchserve会自动以分块形式实时返回给客户端。
• 简易伪代码示例：

class StreamingHandler(BaseHandler):
    def handle(self, data, context):
        # 执行分步推理
        for step_result in self.step_by_step_inference(data):
            # 实时输出中间结果
            yield json.dumps({"intermediate_result": step_result}).encode("utf-8")

• 该方案无需修改gRPC proto文件或Torchserve的Java核心代码，仅需扩展Python插件即可实现需求。

2. 修改Torchserve核心源码（原生gRPC服务端流） #

若必须使用gRPC协议实现服务端流，则需要修改核心组件：

• 第一步：修改Torchserve的inference.proto文件，添加服务端流类型的RPC定义，示例：

service InferenceAPIsService {
    // 新增服务端流推理接口
    rpc StreamInfer(InferRequest) returns (stream InferResponse) {}
}

• 第二步：修改Torchserve的Java gRPC服务实现类，添加流处理逻辑，将模型的中间结果逐步写入gRPC响应流。
• 第三步：调整Python端的Handler，支持将推理过程中的中间结果传递给Java服务端的流处理模块。
• 该方案复杂度较高，需要熟悉Torchserve的Java核心架构和gRPC流处理机制，且后续版本升级需维护自定义分支。

无代码修改的临时方案 #

如果不想改动任何代码，可将长任务拆分为多阶段：

• 客户端先发送启动推理的请求，服务端返回唯一任务ID；
• 客户端通过该任务ID定期轮询服务端，获取中间更新和最终结果。
• 此方式并非真正的流处理，但能满足“获取中间状态”的需求，适合快速验证场景。

内容的提问来源于stack exchange，提问作者P_Andre