Что такое TensorFlow Serving и как задеплоить модель в продакшен?

Что такое TensorFlow Serving

TensorFlow Serving — высокопроизводительный serving-сервер для ML-моделей, разработанный Google. Поддерживает gRPC (порт 8500) и REST (порт 8501), горячую замену версий модели без перезапуска, батчинг запросов и A/B-тестирование. Официально поддерживает формат SavedModel.

Шаг 1: Сохранить модель в SavedModel

import tensorflow as tf

model = tf.keras.models.load_model("my_model.keras")

# Сохраняем в нумерованную директорию версии
model.export("models/my_model/1")  # Keras 3.x
# или для tf.keras:
model.save("models/my_model/1")  # tf.saved_model формат

Шаг 2: Запустить TF Serving через Docker

# Структура: models/my_model/1/saved_model.pb
docker run -d \
  --name tf_serving \
  -p 8500:8500 \
  -p 8501:8501 \
  -v "$(pwd)/models:/models" \
  -e MODEL_NAME=my_model \
  tensorflow/serving:2.14.0

Шаг 3: REST-запрос к модели

import requests
import numpy as np
import json

# Подготовка входных данных (например, MNIST)
test_input = np.random.rand(1, 784).tolist()

payload = {"instances": test_input}
response = requests.post(
    "http://localhost:8501/v1/models/my_model:predict",
    data=json.dumps(payload),
    headers={"Content-Type": "application/json"},
)
result = response.json()
print(result["predictions"])

gRPC-запрос

import grpc
import numpy as np
from tensorflow_serving.apis import predict_pb2
from tensorflow_serving.apis import prediction_service_pb2_grpc
import tensorflow as tf

channel = grpc.insecure_channel("localhost:8500")
stub    = prediction_service_pb2_grpc.PredictionServiceStub(channel)

request = predict_pb2.PredictRequest()
request.model_spec.name      = "my_model"
request.model_spec.signature_name = "serving_default"

input_data = np.random.rand(1, 784).astype(np.float32)
request.inputs["input_1"].CopyFrom(
    tf.make_tensor_proto(input_data, shape=input_data.shape)
)

response = stub.Predict(request, timeout=10.0)
print(response.outputs)

Управление несколькими моделями (model_config)

# models.config
model_config_list {
  config {
    name: "my_model"
    base_path: "/models/my_model"
    model_platform: "tensorflow"
    model_version_policy { latest { num_versions: 2 } }
  }
}

docker run -d \
  -p 8501:8501 \
  -v "$(pwd)/models:/models" \
  -v "$(pwd)/models.config:/models/models.config" \
  tensorflow/serving:2.14.0 \
  --model_config_file=/models/models.config

Подводные камни

• Несоответствие имени сигнатуры: по умолчанию Keras сохраняет сигнатуру serving_default, но кастомные модели могут иметь другое имя — проверяйте через saved_model_cli show --dir . --all.
• Версия модели должна быть числовой директорией (1, 2, 3); нечисловые имена игнорируются сервером.
• REST API сериализует большие float32-массивы в JSON — это медленно для крупных батчей. Для production используйте gRPC.
• TF Serving не поддерживает произвольные Python-препроцессинг-шаги за пределами графа — предобработку нужно вшивать в SavedModel через tf.keras.layers.Normalization или @tf.function.
• Батчинг по умолчанию отключён — включите через --enable_batching и batching_parameters_file для высоких нагрузок.
• Горячая замена модели происходит атомарно только при наличии новой числовой версии в base_path; перезапись той же директории не детектируется.
• Метрики сервера (latency, QPS) доступны через Prometheus endpoint /monitoring/prometheus/metrics — не забудьте настроить сбор.

• Объяснять tensorflow serving только синтаксисом без shape, dtype, состояния или режима выполнения.
• Игнорировать leakage, воспроизводимость, пустые входы и скрытые копии данных.
• Не проверять production-симптомы: latency, память, ретраи, дрейф качества и несовпадение версий.

• Может ли связать tensorflow serving с реальным контрактом входов и выходов.
• Упоминает ли тесты, метрики, reproducibility и диагностику ошибок.
• Видит ли различие между demo-кодом в ноутбуке и production-пайплайном.
• Предлагает ли observability, rollback, ограничения стоимости и стратегию incident replay.