API	方法	路径	请求负载	响应负载
推理	POST	v2/models/[/versions/<model_version>]/infer	$inference_request	$inference_response
模型元数据	GET	v2/models/<model_name>[/versions/<model_version>]	ㅤ	$metadata_model_response
服务器就绪	GET	v2/health/ready	ㅤ	$ready_server_response
服务器存活	GET	v2/health/live	ㅤ	$live_server_response
服务器元数据	GET	v2	ㅤ	$metadata_server_response
模型就绪	GET	v2/models/<model_name>[/versions/]/ready	ㅤ	$ready_model_response

[]中的路径内容为可选

有关负载内容的更多信息，请参见负载内容。

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

API定义

API	定义
推理	`/infer`端点对模型执行推理。响应是预测结果。
模型元数据	"模型元数据"API是一个每模型端点，返回路径中传递的模型的详细信息。
服务器就绪	"服务器就绪"健康API指示所有模型是否准备好进行推理。"服务器就绪"健康API可以直接用于实现Kubernetes就绪探针
服务器存活	"服务器存活"健康API指示推理服务器是否能够接收和响应元数据和推理请求。"服务器存活"API可以直接用于实现Kubernetes存活探针。
服务器元数据	"服务器元数据"API返回描述服务器的详细信息。
模型就绪	"模型就绪"健康API指示特定模型是否准备好进行推理。模型名称和（可选）版本必须在URL中可用。

健康/就绪性/存活性探针

模型就绪性探针回答问题"模型是否已下载并能够服务请求？"并响应可用的模型名称。服务器就绪性/存活性探针回答问题"我的服务及其基础设施是否正在运行、健康并能够接收和处理请求？"

要了解更多关于存活性和就绪性探针概念的信息，请访问配置存活性、就绪性和启动探针Kubernetes文档。

负载内容

模型就绪

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

模型就绪响应 JSON 对象

服务器就绪

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

服务器就绪响应 JSON 对象

服务器存活

服务器存活端点返回服务器的存活探针响应。

服务器存活响应 JSON 对象

服务器元数据

服务器元数据端点提供有关服务器的信息。服务器元数据请求通过对服务器元数据端点发送 HTTP GET 请求进行。在相应的响应中，HTTP 正文包含服务器元数据响应 JSON 对象或服务器元数据响应 JSON 错误对象。

服务器元数据响应 JSON 对象

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

"name"：服务器的描述性名称。

"version"：服务器版本。

"extensions"：服务器支持的扩展。目前尚未定义标准扩展。各个推理服务器可以定义和记录自己的扩展。

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

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

"error"：错误的描述性消息。

每个模型元数据端点提供有关模型的信息。模型元数据请求通过对模型元数据端点发送 HTTP GET 请求进行。在相应的响应中，HTTP 正文包含模型元数据响应 JSON 对象或模型元数据响应 JSON 错误对象。模型名称和（可选）版本必须在 URL 中提供。如果未提供版本，服务器可能会根据其自身策略选择版本或返回错误。

模型元数据

模型元数据响应 JSON 对象

成功的模型元数据请求由 HTTP 状态码 200 表示。元数据响应对象（标识为$metadata_model_response）在每个成功的模型元数据请求的 HTTP 正文中返回。

"name"：模型的名称。

"versions"：可以通过相应端点显式请求的模型版本。对于不支持版本的服务器是可选的。对于不允许显式请求版本的模型是可选的。

"platform"：模型的框架/后端。请参见平台。

"inputs"：模型所需的输入。

"outputs"：模型产生的输出。

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

"name"：张量的名称。

"datatype"：张量元素的数据类型，如张量数据类型中所定义。

"shape"：张量的形状。可变大小维度指定为 -1。

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

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

"error"：错误的描述性消息。

推理

推理请求通过对推理端点发送 HTTP POST 请求进行。在请求中，HTTP 正文包含推理请求 JSON 对象。在相应的响应中，HTTP 正文包含推理响应 JSON 对象或推理响应 JSON 错误对象。有关一些示例 HTTP/REST 请求和响应，请参见推理请求示例。

推理请求 JSON 对象

推理请求对象（标识为$inference_request）必须在 POST 请求的 HTTP 正文中提供。模型名称和（可选）版本必须在 URL 中提供。如果未提供版本，服务器可能会根据其自身策略选择版本或返回错误。

"id"：此请求的标识符。可选，但如果指定，此标识符必须在响应中返回。

"parameters"：包含零个或多个以键/值对表示的此推理请求参数的对象。更多信息请参见参数。

"inputs"：输入张量。每个输入都使用请求输入中定义的$request_input模式描述。

"outputs"：此推理请求的输出张量。每个请求的输出都使用请求输出中定义的$request_output模式描述。可选，如果未指定，模型产生的所有输出都将使用默认$request_output设置返回。

请求输出

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

"name"：输出张量的名称。

"parameters"：包含零个或多个以键值对形式表示的输出参数的对象。参见参数获取更多信息。

推理响应JSON对象

成功的推理请求由HTTP状态码200表示。推理响应对象（标识为$inference_response）在HTTP正文中返回。

"model_name"：用于推理的模型名称。

"model_version"：用于推理的具体模型版本。不实现版本控制的推理服务器不应在响应中提供此字段。

"id"：请求中提供的"id"标识符（如果有）。

"parameters"：包含零个或多个以键值对形式表示的响应参数的对象。参见参数获取更多信息。

"outputs"：输出张量。每个输出使用在响应输出中定义的$response_output模式描述。

响应输出

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

"name"：输出张量的名称。

"shape"：输出张量的形状。每个维度必须是可以表示为无符号64位整数值的整数。

"datatype"：输出张量元素的数据类型，如张量数据类型中所定义。

"parameters"：包含零个或多个以键值对形式表示的输入参数的对象。参见参数获取更多信息。

"data"：张量的内容。参见张量数据获取更多信息。

推理响应JSON错误对象

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

"error"：错误的描述性消息。

参数

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

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

张量数据

张量数据必须按行主序呈现张量元素。元素值必须以"线性"顺序给出，元素之间没有任何步幅或填充。张量元素可以以其自然的多维表示形式呈现，也可以作为扁平化的一维表示形式呈现。

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

例如，二维矩阵：

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

或者用扁平化的一维表示形式：

张量数据类型

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

数据类型	大小（字节）
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	可变（最大232）
---	ㅤ

推理请求示例

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

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

gRPC

gRPC API严格遵循HTTP/REST API中定义的概念。合规的服务器必须实现本节中描述的健康状态、元数据和推理API。

API	rpc端点	请求消息	响应消息
推理	ModelInfer	ModelInferRequest	ModelInferResponse
模型就绪	ModelReady	[ModelReadyRequest]	ModelReadyResponse
模型元数据	ModelMetadata	ModelMetadataRequest	ModelMetadataResponse
服务器就绪	ServerReady	ServerReadyRequest	ServerReadyResponse
服务器活跃	ServerLive	ServerLiveRequest	ServerLiveResponse

有关每个端点及其内容的更详细信息，请参见API定义和消息内容。

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

API定义

服务的gRPC定义为：

消息内容

健康状态

使用ServerLive、ServerReady或ModelReady端点进行健康状态请求。对于这些端点，错误由请求返回的google.rpc.Status指示。OK代码表示成功，其他代码表示失败。

服务器活跃状态

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

服务器就绪状态

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

模型就绪状态

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

元数据

服务器元数据

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

模型元数据

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

平台

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

tensorrt_plan：编码为序列化引擎或"计划"的TensorRT模型。

tensorflow_graphdef：编码为GraphDef的TensorFlow模型。

tensorflow_savedmodel：编码为SavedModel的TensorFlow模型。

onnx_onnxv1：为ONNX Runtime编码的ONNX模型。

pytorch_torchscript：编码为TorchScript的PyTorch模型。

mxnet_mxnet：MXNet模型

caffe2_netdef：编码为NetDef的Caffe2模型。

推理

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

参数

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

目前尚未定义任何参数。根据需要，未来的提案可能会定义一个或多个标准参数，以便在不同的推理服务器之间实现可移植功能。服务器可以实现服务器特定的参数来提供非标准功能。

张量数据

在所有表示中，张量数据必须扁平化为张量元素的一维、行优先顺序。元素值必须以"线性"顺序给出，元素之间没有任何步长或填充。

使用ModelInferRequest::raw_input_contents和ModelInferResponse::raw_output_contents的张量"原始"表示通常会允许更高的性能，这是由于protobuf分配和重用与GRPC的交互方式所致。例如，请参见https://github.com/grpc/grpc/issues/23231。

"原始"表示的替代方案是使用InferTensorContents来表示与张量数据类型匹配格式的张量数据。

张量数据类型

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

概念-数据面板-推理协议

概念 - 推理运行时

Last update: 2025-04-15

👏欢迎阅读👏