Returns the sequence of the latest and not-yet-deleted checkpoint filenames, sorted from oldest to newest.
Returns the sequence of the latest and not-yet-deleted checkpoint filenames, sorted from oldest to newest. You can
pass any of the returned values to restore
.
Recovers the internal saver state (holding the last checkpoints) after a crash.
Recovers the internal saver state (holding the last checkpoints) after a crash.
This method searches for the checkpoints pointed to by checkpoints
(which can also be glob patterns). If the
files exist, the method uses their last modification time as the checkpoint stamp.
Sequence of checkpoint filenames (can also be glob patterns).
Restores previously saved saveables.
Restores previously saved saveables.
This method runs the ops responding for restoring variables. It requires a session in which the saver's graph was launched. The variables to restore do not have to have been initialized, as restoring is itself a way to initialize variables.
The savePath
argument is typically a value previously returned from a save call, or a call to
Saver.latestCheckpoint.
Session to use for restoring the variables.
Path to the checkpoint filename. If the saver is sharded
, this is the prefix of the sharded
checkpoint filenames.
Saves the current value of the saveables this saver is responsible for.
Saves the current value of the saveables this saver is responsible for.
This method runs the ops responsible for saving variables. It requires a session in which the saver's graph was launched. The variables being saved must also have been initialized.
The method returns the path of the newly created checkpoint file. This path can be passed directly to restore.
Session to use for saving the variables.
Path to the checkpoint filename. If the saver is sharded
, this is the prefix of
the sharded checkpoint filenames
If provided, the global step number is appended to savePath
to create the
checkpoint filename.
Optional name for the protocol buffer file that will contain / contains the list of the most recent checkpoint filenames. That file, kept in the same directory as the checkpoint files, and it is automatically managed by the saver to keep track of recent checkpoints.
Meta graph filename suffix.
Boolean value indicating whether or not to write the graph meta information file.
Boolean value indicating whether or not to write the checkpoint state file.
Path of the newly created checkpoint file, if the save operation was successful; None
, otherwise. If the
saver is sharded, the filename ends with "-?????-of-nnnnn"
where "nnnnn"
is the number of shards
created.
Alias for toSaverDef
.
Converts this object to its corresponding ProtoBuf object.
Converts this object to its corresponding ProtoBuf object.
ProtoBuf object corresponding to this object.
Constructs and returns a SaverDef object that represents this saver.
Constructs and returns a SaverDef object that represents this saver.
Optional string specifying the name scope to remove. Only the ops within this name scope will be included in the resulting ProtoBuf object and the export scope will be stripped from their names to allow for easy import into new name scopes.
Constructed SaverDef.
A saver can save and restore variables and other saveable objects.
This class adds ops to save and restore variables to and from *checkpoints*. It also provides convenience methods to run these ops. Checkpoints are binary files in a proprietary format which map variable names to tensor values. The best way to examine the contents of a checkpoint is to load it using a Saver.
Savers can automatically number checkpoint filenames. This lets you keep multiple checkpoints at different steps while training a model. For example, you can number the checkpoint filenames with the training step number. To avoid filling up disks, savers manage checkpoint files automatically. For example, they can make sure to keep only the
N
most recent files, or one checkpoint for everyN
hours of training.You may number checkpoint filenames by passing a value to the optional
globalStep
argument of thesave
method. For example:Also, optional arguments to the
Saver
constructor let you control the proliferation of checkpoint files on disk:maxToKeep
: The maximum number of recent checkpoint files to keep. As new files are created, older files are deleted. If0
, no checkpoints are deleted from the filesystem but only the last one is kept in thecheckpoint
file. Defaults to5
(i.e., only the 5 most recent checkpoint files are kept).keepCheckpointEveryNHours
: In addition to keeping the most recentmaxToKeep
checkpoint files, you might want to keep one checkpoint file for everyN
hours of training. This can be useful if you want to later analyze how a model progressed during a long training session. For example, passingkeepCheckpointEveryNHours = 2
ensures that you keep one checkpoint file for every 2 hours of training. The default value of10000
hours effectively disables the feature. Note that you still have to call thesave
method every time you want to save the model. Passing these arguments to the constructor will not save variables automatically for you.An example training program that saves regularly looks like this:
In addition to checkpoint files, savers keep a protocol buffer on disk with the list of recent checkpoints. This is used to manage numbered checkpoint files. The
latestCheckpoint
method makes it easy to discover the path to the most recent checkpoint. That protocol buffer is stored in a file next to the checkpoint files, with default name"checkpoint"
(can be provided using thecheckpointStateFilename
argument of thesave
method).