自定义Transformer推理

type

status

date

slug

summary

创建自定义图像转换器

使用 KServe 模型 API 实现预处理/后处理¶

KServe.Model 基类主要定义了三个处理器：preprocess、predict 和 postprocess，这些处理器按顺序执行，其中 preprocess 处理器的输出作为输入传递给 predict 处理器。当传入 predictor_host 时，predict 处理器会调用预测器并获取响应，然后将响应传递给 postprocess 处理器。KServe 自动为 Transformer 填充 predictor_host 并将调用移交给 Predictor。默认情况下，转换器通过 REST 调用预测器，如需通过 gRPC 调用预测器，可以传递值为 grpc-v2 的 --protocol 参数。

要实现 Transformer，您可以从基础 Model 类派生，然后重写 preprocess 和 postprocess 处理器以实现自定义转换逻辑。对于 Open(v2) Inference Protocol，KServe 为 predict、preprocess、postprocess 处理器提供 InferRequest 和 InferResponse API 对象，以抽象化 REST/gRPC 在网络传输中的编码和解码实现细节。

请参见此处的代码示例。

Transformer 服务器入口点

对于单个模型，您只需创建一个transformer对象并将其注册到模型服务器。

对于多模型场景，如果所有模型都可以共用同一个转换器，您可以为不同模型注册相同的转换器；如果每个模型都需要自己的转换逻辑，则可以注册不同的转换器。

配置服务运行时的日志记录

KServe允许用户覆盖服务运行时和uvicorn服务器的默认日志记录配置。您可以参考日志配置文档来配置日志记录器。

构建Transformer Docker镜像

在kserve/python目录下，使用Dockerfile构建transformer docker镜像

使用REST预测器部署推理服务

创建推理服务

默认情况下，InferenceService使用TorchServe来服务PyTorch模型，这些模型可以根据TorchServe模型仓库布局从云存储中的模型仓库加载。在本例中，模型仓库包含一个MNIST模型，但您可以在其中存储多个模型。

新架构

📔

注意 : STORAGE_URI是一个内置的环境变量，用于为自定义容器注入存储初始化器，其功能类似于预打包预测器的StorageURI字段。

下载的工件存储在/mnt/models目录下。

应用InferenceService transformer-new.yaml

预期输出

运行预测

首先，下载请求输入数据。

然后，确定入口IP和端口并设置INGRESS_HOST和INGRESS_PORT。

预期输出

使用gRPC协议部署调用预测器的推理服务

与REST相比，由于Protocol Buffer的紧密打包和gRPC对HTTP/2的使用，gRPC的速度更快。在许多情况下，gRPC可以成为Transformer和Predictor之间更高效的通信协议，因为您可能需要在它们之间传输大型张量。

创建推理服务

使用以下yaml创建包含Transformer和Triton预测器的InferenceService。由于KServe默认使用TorchServe作为PyTorch模型的服务运行时，这里您需要将服务运行时覆盖为kserve-tritonserver以使用gRPC协议。transformer通过指定--protocol参数使用V2 gRPC协议调用预测器。

新架构

应用InferenceService grpc_transformer.yaml

预期输出

运行预测

首先，下载请求输入数据。

然后，确定入口IP和端口并设置INGRESS_HOST和INGRESS_PORT

预期输出

gRPC和REST性能对比

从以下transformer和predictor的延迟统计数据可以看出，对于REST而言，transformer到predictor的调用时间比gRPC更长（92ms对比55ms）。REST在序列化和反序列化3*32*32形状的张量时需要更多时间，而使用gRPC时，数据以紧密打包的numpy array序列化字节形式传输。

Transformer-Feast

Transformer和Predictor的协同部署