I find that saving and restoring are of the weirder things with TensorFlow, you can either go all out an decide to save out all the variables, or only the ones needed for the model.
You usually don't want to save out gradients (which are also variables) since they take up a bunch of space and aren't actually that useful to restore. Now on the other, what are model variables -- do you want to save model variables + the moving averages ... or just the averages. But then when you're loading you'll have to "shadow" the moving averages to the real variables that actually run in your model.
Good news though, most of the scaffolding code you can write once and re-use it over and over again.
Models with a few million parameters result in a file around ~50MB, which is still reasonable for modern production use cases.
https://blog.metaflow.fr/tensorflow-saving-restoring-and-mix...
I think that having to use a duck typed language makes it so much harder than it has to be. The API is huge, and you get really no help from the IDE. If I could do tf.train.GradientDescentOptimizer as in the example, and then get autocomplete to what I can do next with that object it would really help. Or list functions that takes that kind of object as input. Now, one is searching in the dark.
However, Estimators are not in TensorFlow core, which means the API isn't fixed quite yet.
For your next tutorial, may I suggest: 1) a list of do's and don'ts for constructing a savable/restorable model, and 2) a wee bit of example code.
Of course, now that I have discovered Keras I'm moving away from low-level direct TensorFlow. But I suspect I'm not the only one a bit foggy about the whole save/restore work flow.