Model Serving Control Plane - KServe Documentation Website

蓝净云

已于 2023-09-19 16:28:51 修改

阅读量714

点赞数

分类专栏： Kserve 文章标签： Kserve

于 2023-09-08 22:51:48 首次发布

Kserve 专栏收录该内容

16 篇文章 0 订阅

订阅专栏

https://kserve.github.io/website/0.10/modelserving/control_plane/

控制平面

KServe控制平面：负责协调推理服务自定义资源。它为预测器、转换器和解释器创建了Knative无服务器部署，以启用基于传入请求工作负载的自动缩放，包括在没有接收到流量时缩小到零。当启用原始部署模式时，控制平面将创建Kubernetes deployment, service, ingress, HPA。
在这里插入图片描述

控制平面组件

KServe Controller：负责创建服务、入口资源、模型服务器容器和模型代理容器，用于请求/响应日志记录、批处理和模型拉取。
Ingress Gateway：用于路由外部或内部请求的网关。

在无服务器模式下：

Knative Serving Controller：负责服务修订管理，创建网络路由资源，使用队列代理的无服务器容器来公开流量指标并强制执行并发限制。
Knative Activator：带回缩放为零的pod并转发请求。
Knative Autoscaler(KPA)：监视到应用程序的流量，并根据配置的度量向上或向下扩展副本。

数据平面

推理服务数据平面体系结构由组件的静态图组成，这些组件协调对单个模型的请求。Ensembling、A/B测试和Multi-Arm-Bandits等高级功能应共同组成推理服务。

简介

KServe的数据平面协议引入了独立于任何特定ML/DL框架和模型服务器的推理API。这允许推理服务之间的快速迭代和一致性，并支持易于使用和高性能的用例。

通过实现该协议，推理客户端和服务器将通过在围绕该API标准化的平台上无缝操作来提高其实用性和可移植性。Kserve的推理协议得到了NVIDIA Triton推理服务器、TensorFlow Serving和TorchServe的认可。
在这里插入图片描述
注：协议V2使用/infer而不是 :predict

概念

Component：每个endpoint由多个组件组成：“预测器”、“解释器”和“转换器”。唯一需要的组件是预测器，预测器是系统的核心。随着KServe的发展，我们计划增加受支持组件的数量，以实现异常值检测等用例。

Predictor：预测器是推理服务的主力军。它只是一个模型，并且模型服务器使其在网络端点可用。

Explainer：解释器启用了一个可选的替代数据平面，除了预测之外，还提供模型解释。用户可以定义自己的解释容器，该容器使用相关的环境变量（如预测端点）进行配置。对于常见的用例，KServe提供了开箱即用的解释程序，如Alibi。

Transformer：转换器使用户能够在预测和解释工作流之前定义预处理和后处理步骤。与解释器一样，它也配置了相关的环境变量。对于常见的用例，KServe提供了像Feast这样的开箱即用的转换器。

数据平面V1和V2

KServe支持其数据平面的两个版本，V1和V2。V1协议提供了一个具有HTTP/REST的标准预测工作流程。数据平面协议的第二个版本解决了V1数据平面协议中存在的几个问题，包括大量模型框架和服务器的性能和通用性。协议V2通过添加gRPC API扩展了V1的功能。

主要变化

V2当前不支持解释endpoint
V2添加了服务器就绪性/生存性/元数据端点
V2端点路径包含/而不是：
V2已重命名:predict端点到/infer
V2允许请求路径中的模型版本（可选）

V1 APIs

API	Verb	Path
List Models	GET	/v1/models
Model Ready	GET	/v1/models/<model_name>
Predict	POST	/v1/models/<model_name>:predict
Explain	POST	/v1/models/<model_name>:explain

V2 APIs

API	Verb	Path
Inference	POST	v2/models/<model_name>[/versions/<model_version>]/infer
Model Metadata	GET	v2/models/<model_name>[/versions/<model_version>]
Server Readiness	GET	v2/health/ready
Server Liveness	GET	v2/health/live
Server Metadata	GET	v2
Model Readiness	GET	v2/models/<model_name>[/versions/]/ready

[]中的路径内容是可选的
有关更多信息，请参阅V1协议和V2协议文档。

数据平面（V1）

KServe的V1协议提供了跨所有模型框架的标准化预测工作流程。此协议版本仍然受支持，但建议用户迁移到V2协议，以便在服务运行时中获得更好的性能和标准化。然而，如果用例需要比v2协议更灵活的模式，那么v1协议仍然是一种选择。

API	Verb	Path	Request Payload	Response Payload
List Models	GET	/v1/models		{“models”: [<model_name>]}
Model Ready	GET	/v1/models/<model_name>		{“name”: <model_name>,“ready”: $bool}
Predict	POST	/v1/models/<model_name>:predict	{“instances”: []} **	{“predictions”: []}
Explain	POST	/v1/models/<model_name>:explain	{“instances”: []} **	{“predictions”: [], “explanations”: []}

**=有效载荷是可选的

注意：V1协议中的响应有效载荷没有严格执行。自定义服务器可以定义并返回自己的响应负载。为了保持一致性，我们鼓励使用KServe定义的响应负载。

API定义

API	定义
Predict	“预测”API对模型进行推理。响应是预测结果。所有推理服务都使用Tensorflow V1 HTTP API。
Explain	“解释”API是一个可选组件，除了预测之外，还提供模型解释。标准化解释器接口与Tensorflow V1 HTTP API相同，添加了一个“:explain”谓词。
Model Ready	“模型就绪”健康API指示特定模型是否准备好进行推理。如果模型已下载并准备好为请求提供服务，那么模型就绪端点将返回可访问的列表。
List Models	“模型”API公开模型注册表中的模型列表。

开源推理协议（V2推理协议）

为了使推理服务器符合此协议，服务器必须实现健康、元数据和推理V2 APIs。明确注明的可选功能是不需要的。顺应性推理服务器可以选择实现HTTP/REST API和/或GRPC API。

检查运行时YAML中的模型服务运行时表/protocolVersion字段，以确保您正在使用的模型服务的运行时支持V2协议。

注意：对于本页上的所有API描述，所有上下文中的所有字符串都区分大小写。V2协议支持将扩展机制作为API的必要部分，但本文档没有提出任何具体的扩展。任何具体的延期将单独提出。

关于V1和V2之间变化的说明

V2协议目前不像V1协议那样支持解释endpoint。如果这是您希望在V2协议中具有的功能，请提交github问题。

HTTP/REST

HTTP/REST API之所以使用JSON，是因为它受到广泛支持并且与语言无关。在本文档中显示的所有JSON模式中，$number、$string、$boolean、$object和$array都引用了基本的JSON类型
#optional表示可选的JSON字段。

另请参阅：HTTP/REST端点在REST_predict_v2.yaml中定义

API	Verb	Path	Request Payload	Response Payload
Inference	POST	v2/models/[/versions/<model_version>]/infer	$inference_request	$inference_response
Model Metadata	GET	v2/models/<model_name>[/versions/<model_version>]		$metadata_model_response
Server Ready	GET	v2/health/ready		$ready_server_response
Server Live	GET	v2/health/live		$live_server_response
Server Metadata	GET	v2		$metadata_server_response
Model Ready	GET	v2/models/<model_name>[/versions/]/ready		$ready_model_response

**[]中的路径内容是可选的

有关有效负载内容的更多信息，请参阅Payload Contents。

路径URL的版本部分（[]中）显示为可选，以允许不支持版本控制的实现，或者在用户不想指定特定模型版本的情况下（在这种情况下，服务器将根据自己的策略选择版本）。例如，如果模型没有实现版本，则模型元数据请求路径可能看起来像v2/model/my_mode。如果模型已配置为实现某个版本，那么请求路径可能类似于v2/models/my_model/versions/v10，其中模型的版本为v10。

API定义

API	定义
Inference	/infer 端点对模型执行推理。响应是预测结果。
Model Metadata	“模型元数据”API是每个模型的终结点，它返回路径中传递的模型的详细信息。
Server Ready	“服务器就绪”运行状况API指示是否所有模型都已准备好进行推理。“服务器就绪”健康API可以直接用于实现Kubernetes readinessProbe
Server Live	“服务器实时”健康API指示推理服务器是否能够接收和响应元数据和推理请求。“服务器实时”API可以直接用于实现Kubernetes livenessProbe。
Server Metadata	“服务器元数据”API返回描述服务器的详细信息。
Model Ready	“模型就绪”健康API指示特定模型是否准备好进行推理。URL中必须提供型号名称和（可选）版本。

健康/准备状态/活力探针

Model Readiness调查问题“模型下载了吗？它能满足请求吗？”并用可用的模型名称进行响应。服务器就绪性/生存性调查回答了以下问题：“我的服务及其基础架构是否运行、健康，并且能够接收和处理请求？”

要阅读更多关于活性和就绪探测器概念的信息，请访问Configure liveness，readiness and Startup Probes Kubernetes文档。

有效载荷内容

Model Ready

模型就绪端点返回服务器的就绪探测响应以及模型名称。

模型就绪响应JSON对象

$ready_model_response =
{
  "name" : $string,
  "ready": $bool
}

服务器就绪

服务器就绪端点返回服务器的就绪探测响应。

服务器就绪响应JSON对象

$ready_server_response =
{
  "live" : $bool,
}

Server Live

服务器活动端点返回服务器的活动性探测响应。

服务器实时响应JSON对象

$live_server_response =
{
  "live" : $bool,
}

服务器元数据

服务器元数据端点提供有关服务器的信息。使用HTTP GET向服务器元数据端点发出服务器元数据请求。在相应的响应中，HTTP主体包含服务器元数据响应JSON对象或服务器元数据响应JSON错误对象。

服务器元数据响应JSON对象

成功的服务器元数据请求由200 HTTP状态代码指示。服务器元数据响应对象（标识为$metadata_server_response）在HTTP主体中返回。

$metadata_server_response =
{
  "name" : $string,
  "version" : $string,
  "extensions" : [ $string, ... ]
}

“name”：服务器的描述性名称。
“version”：服务器版本。
“扩展”：服务器支持的扩展。目前，没有定义标准扩展。各个推理服务器可以定义并记录它们自己的扩展。

服务器元数据响应JSON错误对象

失败的服务器元数据请求必须由HTTP错误状态（通常为400）表示。HTTP正文必须包含$metadata_server_error_response对象。

$metadata_server_error_response =
{
  "error": $string
}

“error”：错误的描述性消息。

每个模型的元数据端点提供有关模型的信息。通过HTTP GET向模型元数据端点发出模型元数据请求。在相应的响应中，HTTP主体包含模型元数据响应JSON对象或模型元数据响应JSON错误对象。URL中必须提供型号名称和（可选）版本。如果没有提供版本，服务器可能会根据自己的策略选择一个版本，或者返回错误。

模型元数据

模型元数据响应JSON对象

成功的模型元数据请求由200 HTTP状态代码指示。元数据响应对象，标识为$metadata_model_response，对于每个成功的模型元数据请求，都会在HTTP主体中返回。

$metadata_model_response =
{
  "name" : $string,
  "versions" : [ $string, ... ] #optional,
  "platform" : $string,
  "inputs" : [ $metadata_tensor, ... ],
  "outputs" : [ $metadata_tensor, ... ]
}

“name”：模型的名称。
“versions”：可以通过适当的端点显式请求的模型版本。对于不支持版本的服务器是可选的。对于不允许显式请求版本的模型，此选项是可选的。
“platform”：模型的框架/后端。请参阅平台。
“inputs”：模型所需的输入。
“outputs”：模型产生的产出。

每个模型输入和输出张量的元数据都用$metadata_tensor对象来描述。

$metadata_tensor =
{
  "name" : $string,
  "datatype" : $string,
  "shape" : [ $number, ... ]
}

“name”：张量的名称。
“datatype”：张量数据类型中定义的张量元素的数据类型。
“shape”：张量的形状。可变尺寸标注指定为-1。

模型元数据响应JSON错误对象

失败的模型元数据请求必须由HTTP错误状态（通常为400）指示。HTTP正文必须包含$metadata_model_error_response对象。

$metadata_model_error_response =
{
  "error": $string
}

“error”：错误的描述性消息。

推论

通过HTTP POST向推理端点发出推理请求。在请求中，HTTP主体包含推理请求JSON对象。在相应的响应中，HTTP主体包含推理响应JSON对象或推理响应JSON错误对象。有关HTTP/REST请求和响应的一些示例，请参阅推理请求示例。

推理请求JSON对象

POST请求的HTTP主体中需要一个推理请求对象，标识为$inference_request。URL中必须提供型号名称和（可选）版本。如果没有提供版本，服务器可能会根据自己的策略选择一个版本，或者返回错误。

$inference_request =
{
  "id" : $string #optional,
  "parameters" : $parameters #optional,
  "inputs" : [ $request_input, ... ],
  "outputs" : [ $request_output, ... ] #optional
}

“id”：此请求的标识符。可选，但如果指定，则必须在响应中返回此标识符。
“parameters”：一个包含零个或多个参数的对象，用于表示为键/值对的推理请求。有关详细信息，请参见参数。
“inputs”：输入张量。每个输入都使用Request Input中定义的$request_input模式进行描述。
“outputs”：用于此推理的输出张量。每个请求的输出都使用Request Output中定义的$request_output模式进行描述。可选，如果未指定，则将使用默认的$request_output设置返回模型生成的所有输出。

请求输入

$explorence_request_input JSON描述了对模型的输入。如果输入是分批的，则形状和数据必须表示整个批次的完整形状和内容。

$inference_request_input =
{
  "name" : $string,
  "shape" : [ $number, ... ],
  "datatype"  : $string,
  "parameters" : $parameters #optional,
  "data" : $tensor_data
}

“name”：输入张量的名称。
“shape”：输入张量的形状。每个维度都必须是一个可以表示为无符号64位整数值的整数。
“datatype”：张量数据类型中定义的输入张量元素的数据类型。
“parameters”：一个包含零个或多个参数的对象，表示为键/值对。有关详细信息，请参见参数。
“data”：张量的内容。有关详细信息，请参见张量数据。

请求输出

$request_output JSON用于请求应该从模型返回哪些输出张量。

$inference_request_output =
{
  "name" : $string,
  "parameters" : $parameters #optional,
}

“name”：输出张量的名称。
“parameters”：一个包含零个或多个参数的对象，用于表示为键/值对的输出。有关详细信息，请参见参数。

推理响应JSON对象

成功的推断请求由200 HTTP状态代码表示。推断响应对象，标识为$explorence_response，在HTTP主体中返回。

$inference_response =
{
  "model_name" : $string,
  "model_version" : $string #optional,
  "id" : $string,
  "parameters" : $parameters #optional,
  "outputs" : [ $response_output, ... ]
}

“model_name”：用于推理的模型的名称。
“model_version”：用于推理的特定模型版本。不实现版本控制的推理服务器不应在响应中提供此字段。
“id”：请求中给定的“id”标识符（如果有的话）。
“parameters”：一个包含零个或多个参数的对象，用于表示为键/值对的响应。有关详细信息，请参见参数。
“outputs”：输出张量。每个输出都使用在响应输出中定义的$response_output模式进行描述。

响应输出

$response_output JSON描述了模型的输出。如果输出是批处理的，则形状和数据表示整个批的完整形状。

$response_output =
{
  "name" : $string,
  "shape" : [ $number, ... ],
  "datatype"  : $string,
  "parameters" : $parameters #optional,
  "data" : $tensor_data
}

“name”：输出张量的名称。
“shape”：输出张量的形状。每个维度都必须是一个可以表示为无符号64位整数值的整数。
“datatype”：张量数据类型中定义的输出张量元素的数据类型。
“parameters”：一个包含零个或多个参数的对象，表示为键/值对。有关详细信息，请参见参数。
“data”：张量的内容。有关详细信息，请参见张量数据。

推理响应JSON错误对象

失败的推理请求必须由HTTP错误状态（通常为400）表示。HTTP正文必须包含$推理_error_response对象。

$inference_error_response =
{
  "error": <error message string>
}

“error”：错误的描述性消息。

参数

$parameters JSON描述零个或多个“name”/“value”对，其中“name”是参数的名称，“value”是$string、$number或$boolean。

$parameters =
{
  $parameter, ...
}

$parameter = $string : $string | $number | $boolean

目前未定义任何参数。根据需要，未来的提议可以定义一个或多个标准参数，以允许跨不同推理服务器的可移植功能。服务器可以实现特定于服务器的参数以提供非标准功能。

张量数据

张量数据必须按张量元素的主要顺序排列。元素值必须以“线性”顺序给出，元素之间没有任何跨步或填充。张量元素可以以其本质的多维表示形式呈现，也可以以扁平的一维表示形式呈现。

显式给出的张量数据在JSON数组中提供。数组的每个元素可以是整数、浮点数、字符串或布尔值。服务器可以决定将每个元素强制为所需的类型，或者在收到意外值时返回错误。请注意，fp16和bf16显式通信是有问题的，因为在后端没有标准的fp16/bf16表示，通常也没有为JSON编号创建fp16/bf6表示的编程支持。

例如，二维矩阵：

[ 1 2
  4 5 ]

可以以其自然格式表示为：

"data" : [ [ 1, 2 ], [ 4, 5 ] ]

或者在扁平的一维表示中：

"data" : [ 1, 2, 4, 5 ]

张量数据类型

张量数据类型以及每种类型的大小（以字节为单位）如下表所示。

Data Type	Size (bytes)
BOOL	1
UINT8	1
UINT16	2
UINT32	4
UINT64	8
INT8	1
INT16	2
INT32	4
INT64	8
FP16	2
FP32	4
FP64	8
BYTES	Variable (max $2^{32}$ )
- - -

推理请求示例

以下示例显示了对具有两个输入和一个输出的模型的推理请求。HTTP Content-Length标头提供JSON对象的大小。

POST /v2/models/mymodel/infer HTTP/1.1
Host: localhost:8000
Content-Type: application/json
Content-Length: <xx>
{
  "id" : "42",
  "inputs" : [
    {
      "name" : "input0",
      "shape" : [ 2, 2 ],
      "datatype" : "UINT32",
      "data" : [ 1, 2, 3, 4 ]
    },
    {
      "name" : "input1",
      "shape" : [ 3 ],
      "datatype" : "BOOL",
      "data" : [ true ]
    }
  ],
  "outputs" : [
    {
      "name" : "output0"
    }
  ]
}

对于上述请求，推理服务器必须返回“output0”输出张量。假设模型返回数据类型FP32的[3,2]张量，则将返回以下响应。

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: <yy>
{
  "id" : "42"
  "outputs" : [
    {
      "name" : "output0",
      "shape" : [ 3, 2 ],
      "datatype"  : "FP32",
      "data" : [ 1.0, 1.1, 2.0, 2.1, 3.0, 3.1 ]
    }
  ]
}

gRPC

GRPC API严格遵循HTTP/REST API中定义的概念。兼容的服务器必须实现本节中描述的运行状况、元数据和推断API。

API	rpc Endpoint	Request Message	Response Message
Inference	ModelInfer	ModelInferRequest	ModelInferResponse
Model Ready	ModelReady	[ModelReadyRequest]	ModelReadyResponse
Model Metadata	ModelMetadata	ModelMetadataRequest	ModelMetadataResponse
Server Ready	ServerReady	ServerReadyRequest	ServerReadyResponse
Server Live	ServerLive	ServerLiveRequest	ServerLiveResponse

有关每个端点及其内容的更多详细信息，请参阅API Definitions和Message Contents。

另请参阅：gRPC端点、请求/响应消息和内容在gRPC_predict_v2.proto中定义

API定义

GRPC对服务的定义是：

//
// Inference Server GRPC endpoints.
//
service GRPCInferenceService
{
  // Check liveness of the inference server.
  rpc ServerLive(ServerLiveRequest) returns (ServerLiveResponse) {}

  // Check readiness of the inference server.
  rpc ServerReady(ServerReadyRequest) returns (ServerReadyResponse) {}

  // Check readiness of a model in the inference server.
  rpc ModelReady(ModelReadyRequest) returns (ModelReadyResponse) {}

  // Get server metadata.
  rpc ServerMetadata(ServerMetadataRequest) returns (ServerMetadataResponse) {}

  // Get model metadata.
  rpc ModelMetadata(ModelMetadataRequest) returns (ModelMetadataResponse) {}

  // Perform inference using a specific model.
  rpc ModelInfer(ModelInferRequest) returns (ModelInferResponse) {}
}

消息内容

健康

运行状况请求是使用ServerLive、ServerReady或ModelReady端点发出的。对于这些端点中的每一个，错误都由google.rpc指示。为请求返回的状态。OK（正常）代码表示成功，其他代码表示失败。

Server Live

ServerLive API指示推理服务器是否能够接收和响应元数据和推理请求。ServerLive的请求和响应消息包括：

message ServerLiveRequest {}

message ServerLiveResponse
{
  // True if the inference server is live, false if not live.
  bool live = 1;
}

服务器就绪

ServerReady API指示服务器是否已准备好进行推理。ServerReady的请求和响应消息为：

message ServerReadyRequest {}

message ServerReadyResponse
{
  // True if the inference server is ready, false if not ready.
  bool ready = 1;
}

Model Ready

ModelReady API指示特定模型是否准备好进行推理。ModelReady的请求和响应消息如下：

message ModelReadyRequest
{
  // The name of the model to check for readiness.
  string name = 1;

  // The version of the model to check for readiness. If not given the
  // server will choose a version based on the model and internal policy.
  string version = 2;
}

message ModelReadyResponse
{
  // True if the model is ready, false if not ready.
  bool ready = 1;
}

元数据

服务器元数据

ServerMetadata API提供有关服务器的信息。错误由google.rpc指示。为请求返回的状态。OK（正常）代码表示成功，其他代码表示失败。ServerMetadata的请求和响应消息为：

message ServerMetadataRequest {}

message ServerMetadataResponse
{
  // The server name.
  string name = 1;

  // The server version.
  string version = 2;

  // The extensions supported by the server.
  repeated string extensions = 3;
}

模型元数据

每个模型的元数据API提供有关模型的信息。错误由google.rpc指示。为请求返回的状态。OK（正常）代码表示成功，其他代码表示失败。ModelMetadata的请求和响应消息为：

message ModelMetadataRequest
{
  // The name of the model.
  string name = 1;

  // The version of the model to check for readiness. If not given the
  // server will choose a version based on the model and internal policy.
  string version = 2;
}

message ModelMetadataResponse
{
  // Metadata for a tensor.
  message TensorMetadata
  {
    // The tensor name.
    string name = 1;

    // The tensor data type.
    string datatype = 2;

    // The tensor shape. A variable-size dimension is represented
    // by a -1 value.
    repeated int64 shape = 3;
  }

  // The model name.
  string name = 1;

  // The versions of the model available on the server.
  repeated string versions = 2;

  // The model's platform. See Platforms.
  string platform = 3;

  // The model's inputs.
  repeated TensorMetadata inputs = 4;

  // The model's outputs.
  repeated TensorMetadata outputs = 5;
}

平台

平台是指示DL/ML框架或后端的字符串。平台作为对模型元数据请求的响应的一部分返回，但仅为信息。所提出的推理API相对于模型使用的DL/ML框架是通用的，因此客户端不需要知道给定模型的平台就可以使用API。平台名称使用“_”格式。允许使用以下平台名称：

tensorrt_plan：编码为序列化引擎或“计划”的tensorrt模型。
tensorflow_graphdef：编码为graphdef的tensorflow模型。
tensorflow_savedmodel：编码为savedmodel的tensorflow模型。
onnx_onxv1：为onnx运行时编码的onnx模型。
pytorch_torchscript：编码为torchscript的pytorch模型。
mxnet_mxnet:mxnet模型
caffe2_netdef：编码为netdef的caffe2模型。

推论

ModelInfer API使用指定的模型执行推理。错误由google.rpc指示。为请求返回的状态。OK（正常）代码表示成功，其他代码表示失败。ModelInfer的请求和响应消息如下：

message ModelInferRequest
{
  // An input tensor for an inference request.
  message InferInputTensor
  {
    // The tensor name.
    string name = 1;

    // The tensor data type.
    string datatype = 2;

    // The tensor shape.
    repeated int64 shape = 3;

    // Optional inference input tensor parameters.
    map<string, InferParameter> parameters = 4;

    // The tensor contents using a data-type format. This field must
    // not be specified if "raw" tensor contents are being used for
    // the inference request.
    InferTensorContents contents = 5;
  }

  // An output tensor requested for an inference request.
  message InferRequestedOutputTensor
  {
    // The tensor name.
    string name = 1;

    // Optional requested output tensor parameters.
    map<string, InferParameter> parameters = 2;
  }

  // The name of the model to use for inferencing.
  string model_name = 1;

  // The version of the model to use for inference. If not given the
  // server will choose a version based on the model and internal policy.
  string model_version = 2;

  // Optional identifier for the request. If specified will be
  // returned in the response.
  string id = 3;

  // Optional inference parameters.
  map<string, InferParameter> parameters = 4;

  // The input tensors for the inference.
  repeated InferInputTensor inputs = 5;

  // The requested output tensors for the inference. Optional, if not
  // specified all outputs produced by the model will be returned.
  repeated InferRequestedOutputTensor outputs = 6;

  // The data contained in an input tensor can be represented in "raw"
  // bytes form or in the repeated type that matches the tensor's data
  // type. To use the raw representation 'raw_input_contents' must be
  // initialized with data for each tensor in the same order as
  // 'inputs'. For each tensor, the size of this content must match
  // what is expected by the tensor's shape and data type. The raw
  // data must be the flattened, one-dimensional, row-major order of
  // the tensor elements without any stride or padding between the
  // elements. Note that the FP16 data type must be represented as raw
  // content as there is no specific data type for a 16-bit float
  // type.
  //
  // If this field is specified then InferInputTensor::contents must
  // not be specified for any input tensor.
  repeated bytes raw_input_contents = 7;
}

message ModelInferResponse
{
  // An output tensor returned for an inference request.
  message InferOutputTensor
  {
    // The tensor name.
    string name = 1;

    // The tensor data type.
    string datatype = 2;

    // The tensor shape.
    repeated int64 shape = 3;

    // Optional output tensor parameters.
    map<string, InferParameter> parameters = 4;

    // The tensor contents using a data-type format. This field must
    // not be specified if "raw" tensor contents are being used for
    // the inference response.
    InferTensorContents contents = 5;
  }

  // The name of the model used for inference.
  string model_name = 1;

  // The version of the model used for inference.
  string model_version = 2;

  // The id of the inference request if one was specified.
  string id = 3;

  // Optional inference response parameters.
  map<string, InferParameter> parameters = 4;

  // The output tensors holding inference results.
  repeated InferOutputTensor outputs = 5;

  // The data contained in an output tensor can be represented in
  // "raw" bytes form or in the repeated type that matches the
  // tensor's data type. To use the raw representation 'raw_output_contents'
  // must be initialized with data for each tensor in the same order as
  // 'outputs'. For each tensor, the size of this content must match
  // what is expected by the tensor's shape and data type. The raw
  // data must be the flattened, one-dimensional, row-major order of
  // the tensor elements without any stride or padding between the
  // elements. Note that the FP16 data type must be represented as raw
  // content as there is no specific data type for a 16-bit float
  // type.
  //
  // If this field is specified then InferOutputTensor::contents must
  // not be specified for any output tensor.
  repeated bytes raw_output_contents = 6;
}

参数

Parameters消息描述了一个“name”/“value”对，其中“name”是参数的名称，“value”是与参数对应的布尔值、整数或字符串。

目前，没有定义任何参数。根据需要，未来的提议可以定义一个或多个标准参数，以允许跨不同推理服务器的可移植功能。服务器可以实现特定于服务器的参数以提供非标准功能。

//
// An inference parameter value.
//
message InferParameter
{
  // The parameter value can be a string, an int64, a boolean
  // or a message specific to a predefined parameter.
  oneof parameter_choice
  {
    // A boolean parameter value.
    bool bool_param = 1;

    // An int64 parameter value.
    int64 int64_param = 2;

    // A string parameter value.
    string string_param = 3;
  }
}

张量数据

在所有表示中，张量数据必须被展平为张量元素的一维行主序。元素值必须以“线性”顺序给出，元素之间没有任何跨步或填充。

由于protobuf分配和重用与GRPC交互的方式，使用具有ModelInferRequest::raw_input_contents和ModelInferResponse::raw_output_content的张量的“原始”表示通常将允许更高的性能。例如，请参见https://github.com/grpc/grpc/issues/23231.

“原始”表示的另一种选择是使用InferTensorContents以匹配张量数据类型的格式表示张量数据。

//
// The data contained in a tensor represented by the repeated type
// that matches the tensor's data type. Protobuf oneof is not used
// because oneofs cannot contain repeated fields.
//
message InferTensorContents
{
  // Representation for BOOL data type. The size must match what is
  // expected by the tensor's shape. The contents must be the flattened,
  // one-dimensional, row-major order of the tensor elements.
  repeated bool bool_contents = 1;

  // Representation for INT8, INT16, and INT32 data types. The size
  // must match what is expected by the tensor's shape. The contents
  // must be the flattened, one-dimensional, row-major order of the
  // tensor elements.
  repeated int32 int_contents = 2;

  // Representation for INT64 data types. The size must match what
  // is expected by the tensor's shape. The contents must be the
  // flattened, one-dimensional, row-major order of the tensor elements.
  repeated int64 int64_contents = 3;

  // Representation for UINT8, UINT16, and UINT32 data types. The size
  // must match what is expected by the tensor's shape. The contents
  // must be the flattened, one-dimensional, row-major order of the
  // tensor elements.
  repeated uint32 uint_contents = 4;

  // Representation for UINT64 data types. The size must match what
  // is expected by the tensor's shape. The contents must be the
  // flattened, one-dimensional, row-major order of the tensor elements.
  repeated uint64 uint64_contents = 5;

  // Representation for FP32 data type. The size must match what is
  // expected by the tensor's shape. The contents must be the flattened,
  // one-dimensional, row-major order of the tensor elements.
  repeated float fp32_contents = 6;

  // Representation for FP64 data type. The size must match what is
  // expected by the tensor's shape. The contents must be the flattened,
  // one-dimensional, row-major order of the tensor elements.
  repeated double fp64_contents = 7;

  // Representation for BYTES data type. The size must match what is
  // expected by the tensor's shape. The contents must be the flattened,
  // one-dimensional, row-major order of the tensor elements.
  repeated bytes bytes_contents = 8;
}

张量数据类型

张量数据类型以及每种类型的大小（以字节为单位）如下表所示。

Data Type	Size (bytes)
BOOL	1
UINT8	1
UINT16	2
UINT32	4
UINT64	8
INT8	1
INT16	2
INT32	4
INT64	8
FP16	2
FP32	4
FP64	8
BYTES	Variable ( $max 2^{32}$ )

服务运行时

KServe使用两个CRD来定义模型服务环境：

ServingRuntimes和ClusterServingRuntime

两者之间唯一的区别是，一个是命名空间范围的，另一个是集群范围的。

ServingRuntime定义了Pod的模板，这些模板可以服务于一个或多个特定的模型格式。每个ServingRuntime都定义了关键信息，例如运行时的容器映像和运行时支持的模型格式列表。运行时的其他配置设置可以通过容器规范中的环境变量来传达。

这些CRD允许提高灵活性和可扩展性，使用户能够快速定义或自定义可重用运行时，而无需修改控制器名称空间中的任何控制器代码或任何资源。

以下是ServingRuntime的示例：

apiVersion: serving.kserve.io/v1alpha1
kind: ServingRuntime
metadata:
  name: example-runtime
spec:
  supportedModelFormats:
    - name: example-format
      version: "1"
      autoSelect: true
  containers:
    - name: kserve-container
      image: examplemodelserver:latest
      args:
        - --model_dir=/mnt/models
        - --http_port=8080

KServe提供了几个现成的ClusterServingRuntime，这样用户就可以快速部署通用模型格式，而不必自己定义运行时。

Name	Supported Model Formats
kserve-lgbserver	LightGBM
kserve-mlserver	SKLearn, XGBoost, LightGBM, MLflow
kserve-paddleserver	Paddle
kserve-pmmlserver	PMML
kserve-sklearnserver	SKLearn
kserve-tensorflow-serving	TensorFlow
kserve-torchserve	PyTorch
kserve-tritonserver	TensorFlow, ONNX, PyTorch, TensorRT
kserve-xgbserver	XGBoost

除了这些包含的运行时之外，您还可以通过添加自定义运行时来扩展KServe安装。这在AMD推理服务器的示例中得到了演示。

等级库属性

ServingRuntime规范中的可用属性：

属性	描述
multiModel	此ServingRuntime是否与ModelMesh兼容，并适用于多模型使用（与KServe单模型服务相反）。默认为false
disabled	禁用此运行时
containers	与运行时关联的容器列表
containers[].image	当前容器的容器图像
containers[].command	在提供的映像中找到可执行命令
containers[].args	作为字符串的命令行参数列表
containers[].resources Kubernetes	限制或请求
containers[].env	要传递到容器的环境变量列表
containers[].imagePullPolicy	容器映像拉取策略
containers[].workingDir	当前容器的工作目录
containers[].livenessProbe	用于检查容器活性的探针
containers[].readinesProbe	用于检查容器准备情况
supportedModelFormats	当前运行时支持的模型类型列表
supportedModelFormats[].name	模型格式的名称
supportedModelFormats[].version	模型格式的版本。用于验证运行时是否支持预测器。建议此处仅包括主要版本，例如“1”而不是“1.15.4”
storageHelper.disabled	禁用存储助手
nodeSelector	影响Kubernetes调度为节点分配pod
affinity	影响Kubernetes调度为节点分配pod
tolerations	允许将pod调度到具有匹配污点的节点上

ModelMesh利用此处未列出的其他字段。点击此处了解更多信息。

注意：ServingRuntimes支持在容器规范中使用形式为{{.Variable}}的模板变量。这些变量应该映射到InferenceService的元数据对象中的字段。它的主要用途是将特定于推理服务的信息（如名称）传递给运行时环境。一些现成的ClusterServingRuntimes通过在运行时容器args中设置–model_name＝{{.name}}来利用这一点，以确保当用户部署推理服务时，名称会传递给服务器。

使用服务运行时间

ServingRuntimes既可以显式使用，也可以隐式使用。

显式：指定运行时

当用户在其推理服务中定义预测器时，他们可以显式指定ClusterServingRuntime或ServingRuntime的名称。例如：

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: example-sklearn-isvc
spec:
  predictor:
    model:
      modelFormat:
        name: sklearn
      storageUri: s3://bucket/sklearn/mnist.joblib
      runtime: kserve-mlserver

这里，指定的运行时是kserve-mlserver，因此kserve控制器将首先在命名空间中搜索具有该名称的ServingRuntime。如果不存在，则控制器将搜索ClusterServingRuntimes的列表。如果找到，控制器将首先验证预测器中提供的modelFormat是否在supportmodelFormat列表中。如果在，那么运行时提供的容器和pod信息将用于模型部署。

隐含：自动选择

在supportedModelFormats列表的每个条目中，可以选择性地指定autoSelect:true，以指示如果没有明确指定运行时，则可以考虑给定的ServingRuntime来自动选择具有相应模型格式的预测器。例如，kserve-sklearnserver ClusterServingRuntime支持SKLearn版本1，并启用了autoSelect：

apiVersion: serving.kserve.io/v1alpha1
kind: ClusterServingRuntime
metadata:
  name: kserve-sklearnserver
spec:
  supportedModelFormats:
    - name: sklearn
      version: "1"
      autoSelect: true
...

在未指定运行时部署以下推理服务时，控制器将查找支持sklearn的运行时：

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: example-sklearn-isvc
spec:
  predictor:
    model:
      modelFormat:
        name: sklearn
      storageUri: s3://bucket/sklearn/mnist.joblib

由于kserve-sklearnserver在其supportedModelFormats列表中有一个带有sklearn和autoSelect:true的条目，因此该ClusterServingRuntime将用于模型部署。

如果还指定了版本：

...
spec:
  predictor:
    model:
      modelFormat:
        name: sklearn
        version: "0"
...

然后，supportedModelFormat的版本也必须匹配。在本例中，kserve-sklearnserver将不符合选择条件，因为它只列出了对sklearn版本1的支持。

警告
如果多个运行时将相同的格式和/或版本列为可自动选择，则无法保证将选择哪个运行时。因此，用户和集群管理员应该谨慎地启用autoSelect。

上一个架构

目前，如果用户使用旧模式来部署预测器，其中您指定了一个框架/格式作为键，那么KServe webhook将自动将其映射到现成的ClusterServingRuntimes。这是为了向后兼容性。例如：

上一个架构

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: example-sklearn-isvc
spec:
  predictor:
    sklearn:
      storageUri: s3://bucket/sklearn/mnist.joblib

等效新架构

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: example-sklearn-isvc
spec:
  predictor:
    model:
      modelFormat:
        name: sklearn
      storageUri: s3://bucket/sklearn/mnist.joblib
      runtime: kserve-sklearnserver

以前的模式将变为新的模式，其中显式指定了kserve-sklearnserver ClusterServingRuntime。

警告
旧模式最终将被删除，取而代之的是新的模型规范，用户可以在其中指定模型格式和相应的版本。在KServe的早期版本中，支持的预测器格式和容器映像是在控制平面名称空间的ConfigMap中定义的。从v0.7、v0.8和v0.9升级的现有推理服务需要转换为新的模型规范，因为预测配置在v0.10中被逐步淘汰。