Ollama v0.40.2 Fixes Duplicate Model Entries and Clarifies GGUF Migration and Downgrade Backups

Ollama released v0.40.2 on October 8, officially fixing duplicate entries in the model list after migration of older models. The update affects local model files and inference backend compatibility: according to the release notes, models downloaded with earlier versions are upgraded in the background the first time they run to improve performance and compatibility with the llama.cpp runtime, though no quantitative performance data was provided. Release announcement

In the merged fix, maintainers further explained that some older GGUF files depend on Ollama’s own llama.cpp patch set and require a deferred on-disk conversion when loaded. To support downgrades, the system temporarily retains both the old and new GGUF files and creates a hidden-purpose v1 manifest tag to prevent older servers from deleting the new model data. These internal entries previously appeared in the model list, potentially leading users and API consumers to believe there were extra models; this fix hides both the duplicate entries and the downgrade-protection entries. Maintainer explanation

As a result, a normal-looking model list does not mean disk space has been reclaimed. The release notes explicitly state that the original copies are retained as backups and will only be removed automatically in a future version. The cleanup method currently provided identifies old backups using /api/tags, /api/show, and the manifest’s runner field. If you delete them and then downgrade to a version earlier than 0.40, you will need to download the affected models again. Backup handling details

For operations teams, this means the model list and actual storage usage should be monitored separately. Ollama’s official FAQ lists the model directories for each platform and supports specifying a storage location with OLLAMA_MODELS; teams using a dedicated model disk or a container-mounted directory can use this information to check storage changes before and after migration. Storage configuration documentation

Engineering validation should cover first-time loading of older models, reading the model list, and restoring after a downgrade. Teams should next track when automatic backup cleanup is implemented, as well as load times and output consistency after different model conversions. Public evidence currently confirms the fix and backup strategy, but is not sufficient to estimate performance gains across all models.