对于远程存储，您可以选择使用存储在 KServe 示例 GCS 存储桶 gs://kfserving-examples/models/torchserve/image_classifier 中的预构建 MNIST MAR 文件启动示例，或者使用 torch-model-archiver 生成 MAR 文件，并根据上述布局在远程存储上创建模型存储。

对于 PVC 用户，请参考模型存档文件生成以自动生成带有模型和依赖文件的 MAR 文件。

TorchServe 使用 config.properties 文件来存储配置。请查看配置文件支持的属性详情。以下是 KServe 的示例文件：

KServe/TorchServe 集成支持 KServe v1/v2 REST 协议。在 config.properties 中，我们需要打开 enable_envvars_config 标志以启用使用环境变量设置 KServe 信封。

警告

之前的 service_envelope 属性已被弃用，在 config.properties 文件中使用标志 enable_envvars_config=true 以启用在运行时设置服务信封。请求从 KServe 推理请求格式转换为 TorchServe 请求格式，并通过本地套接字发送到配置的 inference_address。

使用 V1 REST 协议部署 PyTorch 模型

创建 TorchServe InferenceService

当您在新模型规范中指定模型格式 pytorch 时，KServe 默认选择 TorchServe 运行时。

新架构旧架构

要在 CPU 上部署模型，请应用以下 torchserve.yaml 来创建 InferenceService。

kubectl

新架构

要在 GPU 上部署模型，请应用 gpu.yaml 来创建 GPU InferenceService。

kubectl

预期输出

模型推理

第一步是确定入口 IP 和端口并设置 INGRESS_HOST 和 INGRESS_PORT。

您可以使用图像转换器将图像转换为 base64 字节数组，对于其他模型，请参考输入请求。

预期输出

模型解释

获取模型解释：

预期输出

使用 V1 gRPC 协议部署 PyTorch 模型¶

注意：由于 kserve 没有 v1 的 grpc 客户端方法，我们使用 torchserve 的 grpc v1 客户端

创建推理服务¶

要使用 gRPC 协议部署InferenceService，您需要在推理服务上开放 gRPC 端口。这里7070是 torchserve 的 gRPC 端口。

应用以下mnist_grpc.yaml来创建InferenceService。

kubectl

预期输出

新架构

自动扩缩容¶

无服务器推理的主要特性之一是根据传入工作负载自动调整InferenceService副本的数量。KServe 默认启用Knative Pod Autoscaler，它会监控流量并根据配置的指标进行扩缩容。

Knative 自动扩缩容器¶

KServe支持实现Knative Pod Autoscaler (KPA)和Kubernetes的Horizontal Pod Autoscaler (HPA)。以下列出了这些自动扩缩容器的特性和限制。

注意

如果要使用Kubernetes Horizontal Pod Autoscaler (HPA)，必须安装HPA扩展

Knative Pod Autoscaler (KPA)

是Knative Serving核心的一部分，安装Knative Serving后默认启用。

支持缩容至零的功能。

不支持基于CPU的自动扩缩容。

Horizontal Pod Autoscaler (HPA)

不是Knative Serving核心的一部分，必须在安装Knative Serving后启用。

不支持缩容至零的功能。

支持基于CPU的自动扩缩容。

创建具有并发目标的推理服务¶

硬/软自动扩缩容限制¶

你可以使用注解autoscaling.knative.dev/target为推理服务配置软限制。软限制是一个目标限制而不是严格执行的边界，特别是在突发请求的情况下，这个值可能会被超过。

新架构旧架构

你也可以使用字段containerConcurrency为推理服务配置硬限制。硬限制是一个强制执行的上限。如果并发达到硬限制，多余的请求将被缓冲，必须等到有足够的容量来执行请求。

新架构

在指定了扩缩容目标的软限制或硬限制后，你现在可以使用autoscaling.yaml部署InferenceService。

kubectl

预期输出

运行并发请求推理¶

第一步是安装hey负载生成器，然后向InferenceService发送并发请求。

检查Pod自动扩缩容¶

hey默认并发生成50个请求，因此你可以看到InferenceService扩展到5个pod，因为容器并发目标设置为10。

预期输出

金丝雀发布¶

金丝雀发布是一种部署策略，当你将新版本的模型发布到生产流量的一小部分时使用。

创建带有金丝雀模型的推理服务¶

在上述实验之后，现在让我们看看如何在不默认将全部流量转移到新模型的情况下发布新模型。

新架构

在这个例子中，我们将storageUri更改为v2版本，并使用canaryTrafficPercent字段，然后应用canary.yaml。

kubectl

预期输出

检查流量状态¶

在部署金丝雀模型后，流量应该在金丝雀模型修订版和"稳定"修订版之间分配，"稳定"修订版最初是以100%的流量部署的，现在检查InferenceService流量状态中的流量分配：

预期输出

流量发布¶

多次运行以下curl请求到InferenceService，你可以看到请求以20/80的比例发送到两个修订版。

预期输出

你可以注意到当请求命中金丝雀修订版时会失败，这是因为新修订版需要v2推理输入mnist_v2.json，这是一个破坏性变更，此外，流量根据指定的流量百分比在两个修订版之间随机分配。在这种情况下，你应该使用0 canaryTrafficPercent部署金丝雀模型，并使用latest标记的url测试金丝雀模型，然后再将全部流量转移到新模型。

kubectl

预期输出

在新模型经过测试和验证后，您现在可以将canaryTrafficPercent调整为100，以便将全部流量转移到新版本，此时latestRolledoutRevision变为torchserve-predictor-default-00002，而previousRolledoutRevision变为torchserve-predictor-default-00001。

kubectl

检查流量状态：

预期输出

回滚模型¶

如果在流量迁移到新版本后发现新模型版本不能正常工作，您仍可以将canaryTrafficPercent修改为0，并将流量迁回之前部署的模型torchserve-predictor-default-00001。

kubectl

检查流量状态：

预期输出

监控¶

指标暴露和Grafana仪表盘设置

模型推理运行时-Tensorflow

模型推理运行时-Scikit-learn

Last update: 2025-04-17

👏欢迎阅读👏