Principle:Tensorflow Serving Multi Version Export
| Knowledge Sources | |
|---|---|
| Domains | Model_Serialization, Version_Management |
| Last Updated | 2026-02-13 17:00 GMT |
Overview
A versioning strategy that produces multiple numbered SavedModel directories under a shared base path to enable concurrent version serving and zero-downtime model updates.
Description
Multi-version export extends the standard SavedModel export by producing multiple version directories under the same base path. TensorFlow Serving's filesystem source monitors this base path and discovers new versions by scanning for integer-named subdirectories. By exporting successive versions (e.g., 1, 2, 3), operators can leverage TensorFlow Serving's version management to perform canary deployments, A/B testing, and rollback operations.
The key insight is that the version number in the directory name (<base_path>/<version>/) is the sole mechanism for version identity. Higher numbers are treated as newer versions by the default "Latest" version policy.
Usage
Use this pattern when you need to serve multiple model versions simultaneously, perform gradual rollouts, or maintain rollback capability. Each training run or model iteration should produce a new version number.
Theoretical Basis
# Abstract versioning pattern (NOT real implementation)
for version in [1, 2, 3]:
model = train_model(data, hyperparams_v[version])
export_path = f"{base_path}/{version}/"
serialize_model(model, export_path)
# Result: base_path/1/saved_model.pb, base_path/2/saved_model.pb, base_path/3/saved_model.pb
# TF Serving discovers all three and applies version policy
Version discovery is performed by FileSystemStoragePathSource which polls the base path at a configurable interval (default 30 seconds in ServerCore, 1 second via CLI flag).