Path: blob/master/site/en-snapshot/hub/common_issues.md
25115 views
Common issues
If your issue is not listed here, please search the github issues before filling a new one.
Note: This documentation uses TFhub.dev URL handles in examples. See more information regarding other valid handle types here.
TypeError: 'AutoTrackable' object is not callable
This error frequently arises when loading models in TF1 Hub format with the hub.load()
API in TF2. Adding the correct signature should fix this problem. See the TF-Hub migration guide for TF2 for more details on moving to TF2 and the use of models in TF1 Hub format in TF2.
Cannot download a module
In the process of using a module from an URL there are many errors that can show up due to the network stack. Often this is a problem specific to the machine running the code and not an issue with the library. Here is a list of the common ones:
"EOF occurred in violation of protocol" - This issue is likely to be generated if the installed python version does not support the TLS requirements of the server hosting the module. Notably, python 2.7.5 is known to fail resolving modules from tfhub.dev domain. FIX: Please update to a newer python version.
"cannot verify tfhub.dev's certificate" - This issue is likely to be generated if something on the network is trying to act as the dev gTLD. Before .dev was used as a gTLD, developers and frameworks would sometimes use .dev names to help testing code. FIX: Identify and reconfigure the software that intercepts name resolution in the ".dev" domain.
Failures to write to the cache directory
/tmp/tfhub_modules
(or similar): see Caching for what that is and how to change its location.
If the above errors and fixes do not work, one can try to manually download a module by simulating the protocol of attaching ?tf-hub-format=compressed
to the URL to download a tar compressed file that has to be manually decompressed into a local file. The path to the local file can then be used instead of the URL. Here is a quick example:
Running inference on a pre-initialized module
If you are writing a Python program that applies a module many times on input data, you can apply the following recipes. (Note: For serving requests in production services, consider TensorFlow Serving or other scalable, Python-free solutions.)
Assuming your use-case model is initialization and subsequent requests (for example Django, Flask, custom HTTP server, etc.), you can set-up the serving as follows:
TF2 SavedModels
In the initialization part:
Load the TF2.0 model.
In the request part:
Use the embedding function to run inference.
This call of a tf.function is optimized for performance, see tf.function guide.
TF1 Hub modules
In the initialization part:
Build the graph with a placeholder - entry point into the graph.
Initialize the session.
In the request part:
Use the session to feed data into the graph through the placeholder.
Cannot change a model's dtype (e.g., float32 to bfloat16)
TensorFlow's SavedModels (shared on TF Hub or otherwise) contain operations that work on fixed data types (often, float32 for the weights and intermediate activations of neural networks). These cannot be changed after the fact when loading the SavedModel (but model publishers can choose to publish different models with different data types).
Update a model version
The documentation metadata of model versions can be updated. However, the version's assets (model files) are immutable. If you want to change the model assets, you can publish a newer version of the model. It's a good practice to extend the documentation with a change log that describes what changed between versions.