Implementation:Tensorflow Serving ServerCore Create And ReloadConfig

Knowledge Sources	TensorFlow Serving
Domains	Deployment, Version_Management
Last Updated	2026-02-13 17:00 GMT

Overview

Concrete tool for creating the central serving orchestrator and dynamically updating its model configuration for canary deployments.

Description

ServerCore::Create() initializes the entire serving pipeline: creates the AspiredVersionsManager, configures FileSystemStoragePathSource instances for each model, wires source adapters, and loads initial model versions. ServerCore::ReloadConfig() dynamically updates the configuration, adding or removing models and updating version policies and labels without restarting the server.

For canary deployment, ReloadConfig is called to:

1. Add a new version to the Specific version policy
2. Assign "canary" and "stable" labels
3. Later update labels for promotion or rollback

Usage

ServerCore::Create() is called once at server startup. ReloadConfig() is called whenever the model configuration needs to change, either via HandleReloadConfigRequest gRPC or filesystem config polling.

Code Reference

Source Location

• Repository: tensorflow/serving
• File: tensorflow_serving/model_servers/server_core.cc
• Lines: L260-288 (Create), L476-547 (ReloadConfig)
• Header: tensorflow_serving/model_servers/server_core.h L74-497

Signature

class ServerCore {
 public:
  struct Options {
    ModelServerConfig model_server_config;
    std::unique_ptr<AspiredVersionPolicy> aspired_version_policy;
    int32 num_load_threads = 0;
    int32 num_initial_load_threads = 4 * NumCPUs();
    int32 file_system_poll_wait_seconds = 30;
    int32 max_num_load_retries = 5;
    // ... additional options
  };

  static absl::Status Create(
      Options options,
      std::unique_ptr<ServerCore>* server_core
  );

  absl::Status ReloadConfig(const ModelServerConfig& new_config);
};

Import

#include "tensorflow_serving/model_servers/server_core.h"

I/O Contract

Inputs

Name	Type	Required	Description
options	ServerCore::Options	Yes	Full server configuration including model configs
new_config	ModelServerConfig	Yes	For ReloadConfig: updated configuration protobuf

Outputs

Name	Type	Description
server_core	unique_ptr<ServerCore>	Fully initialized serving pipeline
Status	absl::Status	Success/failure of config reload

Usage Examples

Canary Deployment Config Sequence

# Step 1: Initial config with stable version
model_config_list {
  config {
    name: 'my_model'
    base_path: '/models/my_model/'
    model_version_policy { specific { versions: 42 } }
    version_labels { key: 'stable' value: 42 }
  }
}

# Step 2: Add canary version (sent via ReloadConfig)
model_config_list {
  config {
    name: 'my_model'
    base_path: '/models/my_model/'
    model_version_policy { specific { versions: 42 versions: 43 } }
    version_labels { key: 'stable' value: 42 }
    version_labels { key: 'canary' value: 43 }
  }
}

# Step 3: Promote canary (sent via ReloadConfig)
model_config_list {
  config {
    name: 'my_model'
    base_path: '/models/my_model/'
    model_version_policy { specific { versions: 43 } }
    version_labels { key: 'stable' value: 43 }
  }
}

Related Pages

Implements Principle

• Principle:Tensorflow_Serving_Canary_Deployment

Uses Heuristic

• Heuristic:Tensorflow_Serving_Servable_Handle_Lifetime