Tensorflow Serving 配置

在本指南中，我们将介绍 TensorFlow Serving 的众多配置点。

概述

虽然大多数配置与模型服务器相关，但有许多方法可以指定 TensorFlow Serving 的行为

模型服务器配置：指定模型名称、路径、版本策略和标签、日志记录配置等
监控配置：启用和配置 Prometheus 监控
批处理配置：启用批处理并配置其参数
其他标志：可以提供给微调 TensorFlow Serving 部署行为的许多其他标志

模型服务器配置

服务模型的最简单方法是提供 --model_name 和 --model_base_path 标志（或在使用 Docker 时设置 MODEL_NAME 环境变量）。但是，如果您想服务多个模型，或配置诸如轮询新版本频率之类的选项，则可以通过编写模型服务器配置文件来实现。

您可以使用 --model_config_file 标志提供此配置文件，并指示 TensorFlow Serving 定期轮询指定路径以获取此配置文件的更新版本，方法是设置 --model_config_file_poll_wait_seconds 标志。

使用 Docker 的示例

docker run -t --rm -p 8501:8501 \
    -v "$(pwd)/models/:/models/" tensorflow/serving \
    --model_config_file=/models/models.config \
    --model_config_file_poll_wait_seconds=60

重新加载模型服务器配置

有两种方法可以重新加载模型服务器配置

通过将 --model_config_file_poll_wait_seconds 标志设置为指示服务器定期检查 --model_config_file 文件路径处的新的配置文件。
通过向服务器发出 HandleReloadConfigRequest RPC 调用，并以编程方式提供新的模型服务器配置。

请注意，每次服务器加载新的配置文件时，它都会采取行动来实现新指定配置的内容，并且仅实现新指定配置的内容。这意味着如果模型 A 存在于第一个配置文件中，而该配置文件被替换为仅包含模型 B 的文件，则服务器将加载模型 B 并卸载模型 A。

模型服务器配置详细信息

提供的模型服务器配置文件必须是 ModelServerConfig 协议缓冲区。

对于除最先进用例之外的所有用例，您都希望使用 ModelConfigList 选项，它是一个 ModelConfig 协议缓冲区的列表。在深入了解下面的高级选项之前，这里是一个基本示例。

model_config_list {
  config {
    name: 'my_first_model'
    base_path: '/tmp/my_first_model/'
    model_platform: 'tensorflow'
  }
  config {
    name: 'my_second_model'
    base_path: '/tmp/my_second_model/'
    model_platform: 'tensorflow'
  }
}

配置一个模型

每个 ModelConfig 都指定要服务的模型，包括其名称和模型服务器应查找要服务的模型版本的路径，如上面的示例所示。默认情况下，服务器将服务版本号最大的版本。可以通过更改 model_version_policy 字段来覆盖此默认值。

服务模型的特定版本

为了服务模型的特定版本，而不是总是切换到版本号最大的版本，请将 model_version_policy 设置为 "specific" 并提供您想要服务的版本号。例如，要将版本 42 固定为要服务的版本

model_version_policy {
  specific {
    versions: 42
  }
}

此选项在发现最新版本存在问题时，用于回滚到已知正常版本。

服务模型的多个版本

要同时服务模型的多个版本，例如，为了启用对一小部分流量进行金丝雀测试，请将 model_version_policy 设置为 "specific" 并提供多个版本号。例如，要服务版本 42 和 43

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}

为模型版本分配字符串标签，以简化金丝雀测试和回滚

有时，为模型版本添加一层间接层会很有帮助。与其让所有客户端都知道他们应该查询版本 42，不如将别名（如 "stable"）分配给当前客户端应该查询的版本。如果您想将一小部分流量重定向到暂时的金丝雀模型版本，可以使用第二个别名 "canary"。

您可以像这样配置这些模型版本别名或标签

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}
version_labels {
  key: 'stable'
  value: 42
}
version_labels {
  key: 'canary'
  value: 43
}

在上面的示例中，您正在服务版本 42 和 43，并将标签 "stable" 与版本 42 关联，并将标签 "canary" 与版本 43 关联。您可以让您的客户端使用 ModelSpec 协议缓冲区的 version_label 字段将查询直接到 "stable" 或 "canary" 之一（可能基于对用户 ID 的哈希），并在服务器上向前移动标签，而无需通知客户端。一旦您完成对版本 43 的金丝雀测试并准备将其提升为稳定版本，您可以将配置更新为

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}
version_labels {
  key: 'stable'
  value: 43
}
version_labels {
  key: 'canary'
  value: 43
}

如果您随后需要执行回滚，您可以恢复到将版本 42 作为 "stable" 的旧配置。否则，您可以通过卸载版本 42 并加载新的版本 44（准备就绪时），然后将金丝雀标签推进到 44，等等，继续前进。

请注意，标签只能分配给已经加载并可供服务的模型版本。一旦模型版本可用，就可以动态重新加载模型配置，将标签分配给它。这可以通过 HandleReloadConfigRequest RPC 来实现，或者如果服务器设置为定期轮询文件系统以查找配置文件，如上面所述。

如果您想将标签分配给尚未加载的版本（例如，在启动时同时提供模型版本和标签），那么您必须将 --allow_version_labels_for_unavailable_models 标志设置为 true，这允许将新标签分配给尚未加载的模型版本。

请注意，这仅适用于新的版本标签（即尚未分配给当前版本的标签）。这是为了确保在版本交换期间，服务器不会过早地将标签分配给新版本，从而在加载新版本时丢弃所有针对该标签的请求。

为了遵守此安全检查，如果重新分配正在使用的版本标签，您必须仅将其分配给已加载的版本。例如，如果您想将标签从指向版本 N 移动到指向版本 N+1，您可以先提交包含版本 N 和 N+1 的配置，然后提交包含版本 N+1、指向 N+1 的标签且不包含版本 N 的配置。

REST 使用

如果您使用 REST API 表面进行推理请求，而不是使用

/v1/models/<model name>/versions/<version number>

只需通过以下方式构建您的请求路径，使用标签请求版本

/v1/models/<model name>/labels/<version label>.

请注意，版本标签限制为单词字符序列，由字母数字字符和下划线组成（即 [a-zA-Z0-9_]+）。

监控配置

您可以通过使用 --monitoring_config_file 标志指定包含 MonitoringConfig 协议缓冲区的文件，为服务器提供监控配置。以下是一个示例

prometheus_config {
  enable: true,
  path: "/monitoring/prometheus/metrics"
}

要从上面的监控 URL 读取指标，您首先需要通过设置 --rest_api_port 标志来启用 HTTP 服务器。然后，您可以通过将 --rest_api_port 和 path 的值传递给它，将您的 Prometheus 服务器配置为从模型服务器拉取指标。

Tensorflow Serving 收集 Serving 和核心 Tensorflow 捕获的所有指标。

批处理配置

模型服务器能够在各种设置中对请求进行批处理，以实现更高的吞吐量。此批处理的调度是在服务器上针对所有模型和模型版本全局完成的，以确保最佳利用底层资源，无论服务器当前服务多少个模型或模型版本（更多详细信息）。您可以通过设置 --enable_batching 标志启用此行为，并通过将配置传递给 --batching_parameters_file 标志来控制它。

示例批处理参数文件

max_batch_size { value: 128 }
batch_timeout_micros { value: 0 }
max_enqueued_batches { value: 1000000 }
num_batch_threads { value: 8 }

请参阅批处理指南以深入讨论，并参阅参数部分以了解如何设置参数。

其他标志

除了本指南中介绍的标志之外，这里列出了其他一些值得注意的标志。有关完整列表，请参阅源代码。

--port: 用于监听 gRPC API 的端口
--rest_api_port: 用于监听 HTTP/REST API 的端口
--rest_api_timeout_in_ms: HTTP/REST API 调用的超时时间
--file_system_poll_wait_seconds: 服务器轮询文件系统以查找每个模型各自的 model_base_path 中的新模型版本的周期
--enable_model_warmup: 使用资产中提供的 PredictionLogs 启用模型预热。extra/ 目录
--mixed_precision=bfloat16: 启用 BF16 自动混合精度