FluxML/model-zoo: Julia deep learning examples you can run

What FluxML/model-zoo solves for Julia users

The README opens by describing the repository as containing demonstrations of the Flux machine learning library, and states that any of them may be used as a starting point for your own models. That sentence is the whole pitch. Flux's own documentation explains APIs; this repository shows complete training scripts with data loading, a loss function, an optimizer loop and an evaluation step. The audience is a Julia programmer who knows the language and wants to see how a convolutional network, a recurrent network or a diffusion model is written in Flux rather than in PyTorch.

The examples are grouped into vision, text, games and other. Vision covers MNIST and CIFAR10: a multi-layer perceptron, LeNet, a variational auto-encoder, DCGAN and its conditional variant, a score-based diffusion model, a spatial transformer, VGG 16/19 and ConvMixer. Text covers CharRNN, NanoGPT, character-level language detection, a seq2seq phoneme model and a recursive net on the IMDB sentiment treebank. Tutorials include a 60 minute blitz, a DataLoader example and transfer learning. The games folder is listed under contrib.

This is not a model registry. There are no pretrained weights distributed here, and the repository does not claim to offer any. It is source code you read and run.

How the per-model Julia project pins versions

The mechanism is Julia's environment system. Each model lives in its own folder with a project and manifest file, and the README says activating and instantiating that environment installs all needed packages at the exact versions when the model was last updated. That is the design decision worth noticing: the zoo does not try to keep every example on one shared dependency set. Each folder freezes its own world.

The consequence is that the repository as a whole spans a wide range of Flux releases. The README marks entries with symbols and version numbers. A sun symbol means v0.13 or v0.14, the current line; a sun-behind-cloud means v0.11; a snowflake means v0.7 or v0.6. Models upgraded to explicit gradients, which the README ties to Flux v0.13.9 or later and v0.14, carry a plus sign. So the ConvNet LeNet example is marked v0.14, NanoGPT is marked v0.14, and the meta-learning contribution is marked v0.7.

That mix is honest but it means the zoo is not a single coherent codebase. Reading two examples side by side can show you two different Flux idioms.

Installing a model and running your first training script

There is no package to add. You clone the repository, enter a model folder, and activate that folder's environment. The README gives this exact sequence:

using Pkg; Pkg.activate("."); Pkg.instantiate()

Run it from inside the model directory, not from the repository root. `Pkg.activate(".")` switches Julia to the project file in the current folder, and `Pkg.instantiate()` resolves and installs everything the manifest records. Expect the first run to spend time downloading and precompiling, because it is building a full environment rather than reusing a shared one.

Once that finishes, the README says you run the model with `include("<model-to-run>.jl")`, or by running the model script line by line. The placeholder is literal: substitute the file name of the model you activated. Running the script line by line in the REPL is worth doing the first time, because you can inspect the model object and the parameter tree between steps, which is the part a PyTorch user is usually trying to understand.

GPU support is not a separate install path. The README states that models may be run with NVIDIA GPU support if CUDA is installed, and that most models have this capability by default through calls to `gpu` in the model code. If you have no CUDA device, those calls are the place to look when adapting a script.

The version drift problem, and when this is the wrong tool

The clearest limitation is stated in the README itself: older examples need older Flux. To run them you install Flux v0.11 on Julia 1.6, the long-term support release; Flux v0.12 works on Julia 1.8; v0.14 is current. That means a model marked v0.11 is not merely stylistically dated. It expects a Julia version you may not have installed, and its manifest pins packages that predate several rounds of Flux API changes. The README points contributors at the Flux NEWS page and at the MLUtils and MLDatasets release pages as the way to understand what moved.

This is where the zoo stops being a convenience. If you want one environment where every example runs, this repository will not give you that. You will juggle Julia versions, or you will upgrade examples yourself, which the README frames as a learning exercise rather than a supported path.

It is also the wrong tool for production work. There is no pretrained model to download, no inference API, no serving story. If you need weights and a stable interface, this is not it. And if you are not already comfortable with Julia environments and package resolution, the setup friction will dominate the learning you came for.

How this differs from weight hubs and framework zoos

The natural comparison is a model hub in the Hugging Face sense, or a framework's own example gallery. The difference is what is being distributed. A weight hub ships trained parameters plus a loading API; you get a model you can call. FluxML/model-zoo ships training code plus a pinned environment; you get a model you can read, modify and retrain. The README's own framing supports this: these are demonstrations and starting points, and the contribution guide asks for short, clean, self-explanatory code with as little boilerplate as possible, plus a README explaining what the model is about and what results it achieves.

Against a framework's bundled examples, the difference is distribution. Framework examples usually live inside the framework repository and move with it. Here each example is a separate project with its own frozen dependency set, which is why the versions diverge so visibly. You trade uniformity for the ability to run an old example exactly as it was written.

There is also an adjacent project worth knowing about. The README points to MLJFlux, described as a bridge to MLJ.jl, a package for mostly non-neural-network machine learning, and notes that its examples likewise each include a local project and manifest file. If your workflow is MLJ pipelines rather than raw Flux training loops, that is the closer fit.

Maintenance, licensing and the cost of upgrading an example

The repository is not archived, and the last push was on 2026-07-01. That is recent enough that the project is still receiving changes, but the README's own version table shows that maintenance is uneven across folders: the vision and text directories carry current tags, while the games and audio contributions sit at v0.7 and v0.6. Treat the version marker next to each model, not the repository's overall activity, as the signal for whether that particular example is current.

Upgrade cost is real and it is per model. Bringing an example forward means reading the Flux NEWS page, checking the MLUtils and MLDatasets release notes, and then reworking the script for explicit gradients if it predates v0.13.9. The plus sign in the README is the marker for models that already made that transition, so those are the cheaper starting points.

On licensing, the repository's LICENSE.md is present at the top level, but the metadata records the licence as NOASSERTION, meaning the repository's own licence file could not be mapped to a standard identifier. Read LICENSE.md directly before reusing code, and check whether individual model folders carry their own terms, since datasets such as MNIST, CIFAR10 and IMDB come with their own conditions that this repository does not restate. That is a factual gap to close yourself, not a legal opinion.

One more operational note: the README describes a Gitpod online IDE option, opened via a URL of the form `https://gitpod.io/#https://github.com/FluxML/model-zoo`. It states that free access is limited under Gitpod's policies, that your work lives in Gitpod's cloud, and that this is not an officially maintained feature.

Editorial conclusion

Adopt FluxML/model-zoo if you are learning Flux or want a working reference for a specific architecture, and start with a model marked v0.14 or v0.13 with the + symbol, since those use explicit gradients. Skip it if you need a maintained library of pretrained weights or a production training framework; this is example code, not a package. Before running anything, check the version tag next to the model in the README and confirm your Julia release matches it, because the older v0.11 entries require Julia 1.6 and Flux v0.11 while the current entries expect Flux v0.14.

Frequently asked questions

Official sources

1. FluxML/model-zoo on GitHub
2. Issues
3. Project website
4. README