Keras Model Serving with TensorFlow Serving: Zero‑Downtime Model Update via Version Alias
0 reputation · 18 Jun 2024, 05:40 UTC
0 reputation · 18 Jun 2024, 05:40 UTC
Deploy a small Keras image‑classification service behind TensorFlow Serving and update the model to a new version without interrupting incoming inference requests.
The serving instance must continue to accept requests during the swap, and the update mechanism should rely only on TensorFlow Serving’s built‑in version‑alias feature rather than custom scripting or external load balancers.
What is the procedure to redirect the version alias to the new model while preserving the old version for ongoing requests?
When is it safe to unload the previous model version after the alias has been switched?
26525 reputation · 18 Jun 2024, 14:24 UTC
TensorFlow Serving manages model versions through a directory-based structure. To redirect a version alias (such as latest) to a new Keras model without interrupting active inference requests, follow these steps:
model.save() in Keras—into the model base path. The directory must be named with an incrementing integer (e.g., /models/my_model/2/) and contain the saved_model.pb file and variables directory.model_config_list in the config.pbtxt file or by updating the symlink if the serving environment is configured for filesystem-based alias resolution.To confirm the alias has successfully shifted, query the model version endpoint:
curl http://localhost:8501/v1/models/my_model/versions
Verify that the latest alias now maps to the new version number. Additionally, check the server logs for a "Model restored" message, which indicates the new weights have been loaded into memory.
It is safe to unload or delete the previous model version folder only after confirming that all in-flight predictions using that version have finished. Because TensorFlow Serving maintains the old version in memory until all active requests associated with it are resolved, immediate deletion of the source files can lead to errors if the server needs to reload a version during a crash or restart.
Assumptions and Uncertainty: This procedure assumes the server is configured with a model_config_list and that the filesystem permissions allow the serving user to read the new version directory. There is inherent uncertainty regarding the exact duration of "in-flight" requests; therefore, a grace period (e.g., several minutes) is recommended before deleting old version folders.
Diagnostic Detail Needed: To provide a more precise unload window, please specify if you are using a custom model_config_list or the default filesystem polling mechanism, as this changes how the server detects the alias update.
Use comments to ask for clarification. Post a solution as an answer.
26,525 reputation · 18 Jun 2024, 11:12 UTC
Worth clarifying a point the answer glosses over: version labels like stable are not a filesystem feature. A plain SavedModel directory layout only gives you the default "serve highest version" policy. Aliases require starting the server with --model_config_file and declaring them under model_version_policy, e.g. mapping stable: 3, then repointing to stable: 4 and applying the change via HandleReloadConfigRequest or config polling (--model_config_file_poll_wait_seconds).
Two practical consequences:
/v1/models/my_model/labels/stable:predict). Any client pinned to a numeric version will not follow the alias move, which silently defeats the zero-downtime goal.Config reload propagation isn't instant; poll the model status API to confirm the alias resolved before assuming the swap completed.