A SavedModel is a directory containing a complete TensorFlow program, including trained model weights, a serialized computation graph, and the functions and assets needed for inference or retraining. It is the standard interchange format for TensorFlow ecosystems, serving as the primary input for deployment tools like the TFLite Converter and TensorFlow Serving. Its self-contained nature ensures model portability across different environments and versions.
Glossary
SavedModel

What is SavedModel?
SavedModel is TensorFlow's universal serialization format for storing a complete, portable machine learning model.
The format encapsulates one or more MetaGraphs, which are tagged subsets of the model (like serve for inference or train for training). Internally, it uses protocol buffers for graph definition and a variables directory for checkpointed weights. This design enables advanced deployment workflows, such as signature-based serving for different inputs and outputs, and is foundational for model serialization within TensorFlow's toolchain for both cloud and edge deployment.
Key Features of the SavedModel Format
SavedModel is TensorFlow's universal serialization format, encapsulating a complete, portable model with its weights, computational graph, and assets.
Complete Model Portability
A SavedModel is a standalone directory containing everything needed for inference or continued training. This includes:
- The model's architecture (computation graph) defined as a TensorFlow GraphDef.
- The model's learned weights (variables) in a checkpoint.
- Assets (e.g., vocabulary files) required for preprocessing.
- SignatureDefs that define the model's input and output tensor specifications. This self-contained nature allows a model to be moved between training and serving environments, different programming languages (Python, C++, Java), and deployment platforms without the original Python code.
Graph and Concrete Functions
SavedModel stores the model's execution logic as a TensorFlow Graph, which is a language-agnostic, optimized dataflow representation. For models built with TensorFlow 2.x APIs, it saves Concrete Functions—tensor-traceable, compiled versions of tf.function-decorated Python code. This enables:
- Performance: Graph execution is typically faster and more memory-efficient than eager execution.
- Deployment Flexibility: The graph can be executed by runtimes that don't have a Python interpreter, such as TensorFlow Serving or TensorFlow Lite.
- Optimization: The graph can be transformed by compilers like TensorRT or XLA for hardware-specific acceleration.
SignatureDefs for Standardized APIs
SignatureDefs provide named entry points into the SavedModel's graph, formally defining the model's inference API. Each signature specifies:
- Inputs: A map from logical input names (e.g.,
'image') to TensorInfo protos describing the expected tensor (dtype, shape). - Outputs: A map from logical output names (e.g.,
'probabilities') to their corresponding tensors. - Method Name: Typically
tensorflow/serving/predict,tensorflow/serving/classify, etc. This standardization is critical for serving systems like TensorFlow Serving, which uses theserving_defaultsignature to automatically generate a gRPC/REST API, ensuring clients know exactly how to format requests and parse responses.
Versioning and Multiple Graphs
A SavedModel directory includes a saved_model.pb (or saved_model.pbtxt) file and subdirectories named with version numbers (e.g., 1/, 2/). This structure supports:
- Model Versioning: Multiple versions of the same model can coexist in one directory, allowing serving systems to roll out updates or rollbacks seamlessly.
- Tagging: Each version is associated with tags (e.g.,
'serve','train') that identify the graph's intended use. The'serve'tag typically contains a graph optimized for inference, while'train'may include additional ops like dropout and gradient computation. - Flexible Loading: APIs like
tf.saved_model.loadcan load a specific graph version by specifying its tag set.
Assets and Initialization via Assets.extra
SavedModel can bundle external files, known as assets, which are copied into the model directory and whose TensorFlow-relative paths are stored in the graph. Common use cases include:
- Lookup Tables: Vocabulary files for text processing models.
- Initialization Files: Data needed to initialize resources when the model is loaded.
These assets are accessed via the
Assets.extradirectory or through dedicated asset tensors in the graph. This ensures all model dependencies are colocated, eliminating runtime file path errors and simplifying deployment to containerized or remote serving environments.
Foundation for Downstream Toolchains
The SavedModel format is the primary entry point for TensorFlow's deployment and optimization toolchains. It serves as the standard source format for:
- TensorFlow Lite Converter: Converts SavedModels to the
.tfliteformat for mobile/embedded deployment. - TensorFlow.js Converter: Converts models for execution in web browsers or Node.js.
- TensorFlow Serving: The high-performance serving system for production environments.
- Compilation Targets: Frameworks like TensorRT and OpenVINO often consume SavedModels (or ONNX conversions thereof) for further hardware-specific graph optimizations, fusion, and quantization.
How SavedModel Works
SavedModel is TensorFlow's universal serialization format for a complete machine learning model, serving as the primary artifact for deployment across diverse environments.
A SavedModel is a directory containing a complete, serialized TensorFlow program, including its trained model weights, a computation graph describing the model's architecture, and essential metadata like signatures that define input/output tensors. This self-contained format is the standard output of tf.saved_model.save() and serves as the primary interchange format for TensorFlow Serving, TensorFlow Lite, and TensorFlow.js, enabling consistent deployment from cloud to edge. Its structure ensures all necessary components for inference or further training are preserved in a language-agnostic way.
The format's core is the saved_model.pb (or saved_model.pbtxt) file, a GraphDef protocol buffer storing the model's MetaGraph. This includes the graph structure, collections, and SavedModel signatures which define concrete functions for serving. Accompanying assets (e.g., vocabulary files) and a variables directory holding checkpointed weights complete the package. This design allows downstream tools, like the TFLite Converter, to parse, optimize, and transform the model for specific runtimes, making SavedModel the foundational source format for on-device deployment pipelines.
SavedModel vs. Other Model Formats
A technical comparison of TensorFlow's universal serialization format against other common formats used for deploying compressed models to edge and mobile devices.
| Feature / Metric | TensorFlow SavedModel | TensorFlow Lite (TFLite) | ONNX | PyTorch TorchScript |
|---|---|---|---|---|
Primary Framework | TensorFlow | TensorFlow | Framework-Agnostic | PyTorch |
Serialization Format | Protocol Buffers | FlatBuffers | Protocol Buffers | TorchScript IR |
Portability | High (within TF ecosystem) | Very High (cross-platform) | Very High (cross-framework) | High (within PyTorch/C++ runtime) |
Hardware Delegate Support | ||||
Built-in Quantization Support | ||||
Graph Optimization Passes | ||||
AOT Compilation Support | ||||
Model Size (Typical) | Largest | < 50% of SavedModel | ~60% of SavedModel | ~70% of SavedModel |
Memory Footprint at Runtime | Highest | Lowest | Low | Medium |
Inference Latency (Relative) | Baseline | < 1.5x Baseline | ~1.3x Baseline | ~1.2x Baseline |
Primary Deployment Target | Servers / Cloud | Mobile & Embedded | Cross-Platform Servers & Edge | Servers & Mobile (via PyTorch Mobile) |
Human-Readable Metadata | ||||
SignatureDef Support (for multiple inference functions) | ||||
Versioning & Asset Management |
Where is SavedModel Used?
SavedModel serves as the central, versioned artifact in the TensorFlow ecosystem, bridging model development with diverse production deployment targets.
Frequently Asked Questions
SavedModel is TensorFlow's universal serialization format for complete machine learning models. This FAQ addresses its core purpose, structure, and role in the on-device deployment pipeline.
A SavedModel is TensorFlow's universal, language-neutral serialization format that encapsulates a complete, portable TensorFlow program, including its trained parameters (weights), the computation graph defining its architecture, and the assets needed for inference or training resumption. It works by serializing the model's variables, graph definition, and signatures (defined input/output functions) into a directory containing a protocol buffer (saved_model.pb) file for the graph and a variables subdirectory for the weights. This self-contained format allows the model to be loaded and executed independently of the original Python code that created it, enabling deployment across diverse environments from cloud servers to mobile devices via conversion tools like the TFLite Converter.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
SavedModel is the core serialization format for TensorFlow, but deploying models to production involves a suite of complementary tools, runtimes, and hardware interfaces.
TFLite Converter & Optimization
The toolchain that transforms a SavedModel into a deployable .tflite file. Critical optimization steps include:
- Quantization: Reduces model size and accelerates inference by converting
float32parameters toint8orfloat16. Uses a representative dataset for post-training quantization (PTQ). - Pruning: Can be applied prior to conversion to create sparse models.
- Selective Ops Registration: Strips unused operators to minimize the runtime binary size for microcontrollers (TFLite Micro).
Hardware Delegates & Accelerators
Interfaces that allow inference frameworks to leverage specialized silicon. A SavedModel converted for edge deployment often executes via these:
- GPU Delegate (TFLite/Android): Offloads ops to mobile GPUs.
- Hexagon DSP Delegate: Executes quantized models on Qualcomm's DSP via the Snapdragon Neural Processing Engine (SNPE).
- Apple Neural Engine (ANE): Accelerates models deployed via Core ML on Apple Silicon.
- Edge TPU Delegate: Runs compiled models on Google's Edge TPU ASIC.
- Android NNAPI: A system-level API that acts as a hardware abstraction layer for accelerators on Android devices.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us