# intro_dgm teaches eleven generative models as MLP notebooks

> Eleven Jupyter notebook folders covering mixture models through diffusion and a toy transformer, written to be readable line by line rather than competitive, alongside teaching material for instructors. The design goal is clarity, and the cost is an environment: the requirements pin PyTorch 1.7 and NumPy 1.17 and exist only in the README prose.

**jmtomczak/intro_dgm** — "Deep Generative Modeling": Introductory Examples

- Repository: https://github.com/jmtomczak/intro_dgm
- Stars: 1,343 · Forks: 206
- Language: Jupyter Notebook
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/jmtomczak-intro-dgm

## Oversimplified on purpose, and said so

The author pre-empts the obvious criticism. The examples might look oversimplistic, but that is the point, because the idea is that everyone can follow every line of the code and run the experiments within a couple of minutes on almost any laptop or computer. The stated goal is to encourage people who are new to the field to understand and play with deep generative models. More advanced users are addressed too: they could refresh their knowledge or build on top of the examples to check an idea quickly.

That framing explains most of what you find inside. Models are parameterised by multilayer perceptrons rather than by the convolutional or attention machinery a paper would use. There is no training loop written to be efficient, no distributed execution, no checkpointing, no evaluation harness. What you get instead is the structure of each model with nothing hidden behind a framework call.

The repository sits alongside a book, Deep Generative Modeling, published by Springer, with a foreword by Max Welling. The README states the book's aim as outlining the most important techniques in deep generative modeling and eventually enabling readers to formulate new models and implement them, which is the same promise the notebooks make in executable form. The book covers the same territory in eleven chapters plus two appendices of algebra, calculus, probability and statistics facts.

## The requirements pin PyTorch 1.7 and NumPy 1.17

The requirements section is the first thing to read before anything else, and it is short. The examples are described as having used pytorch 1.7.0, numpy 1.17.2, matplotlib 3.1.1, scikit-learn 0.21.3, pytorch-model-summary 0.1.1 and jupyter 1.0.0.

Two things stand out. No Python version is named anywhere, and none of those pins has moved since the code was written against the stack it was written against. The last commit to main is 2026-04-28, and the requirement list is still presented in the present tense as what the examples use. PyTorch 1.7 and NumPy 1.17 both belong to a generation of the ecosystem that predates current releases, and neither ships wheels for recent Python versions, so the practical effect is that a reader on a current interpreter will spend the first part of their time on the environment rather than on the models.

The last entry is the odd one. jupyter 1.0.0 names the Jupyter metapackage rather than a notebook server, which is not the package you want if your goal is to open notebooks. It is the first line to change when an install fails.

None of this makes the examples wrong. It makes them a fixed environment rather than a portable one, and a reader should treat recreating that environment as part of the work rather than as setup friction to ignore.

## There is no requirements file, only a list in prose

Look at what the repository actually contains and the requirement list is not in it. The top level holds a licence file, the README, a YAML configuration file, and thirteen directories: the eleven model folders, a teaching folder, and a figures folder. There is no requirements.txt, no environment.yml, no pyproject.toml, no lockfile and not even a gitignore.

So the dependency list exists in exactly one place, as six inline code spans in the README's prose. To set the project up you copy them out by hand into whatever environment tool you use. For a repository whose entire value proposition is that a beginner can run the experiments in a couple of minutes, that is an avoidable step, and it is the kind of omission that turns into a support question.

The lone YAML file at the root is a Jekyll configuration, which suggests the repository was once or was intended to be a small generated site rather than a plain notebook collection. There is no index file at the root to render, so whatever that configuration was for, it is not what a visitor sees today.

The eleven model directories, by contrast, are exactly what the README promises. Each is a link in a numbered list, each has a one-line description of the model it implements, and each is where you go next.

## Almost every model here is an MLP

Read the eleven descriptions together and one fact dominates: nearly every model is parameterised by a multilayer perceptron. The energy-based model is an MLP. The GAN is an MLP. The reverse diffusion process in the diffusion folder is an MLP, as is the score model, the SDE-based diffusion model and the conditional flow matching model. The VAE uses fully-connected layers with a standard Gaussian prior, the hybrid model uses fully-connected layers with integer discrete flows, and the mixture of Gaussians has either equiprobable components or trainable component probabilities.

The one genuine exception is the autoregressive folder, which contains both a causal convolutional layer in one dimension and transformers. The language model example is a decoder-based transformer, described in the README as an LLM and nicknamed teenyGPT, which sets expectations honestly.

This is a deliberate trade rather than a limitation. An MLP makes the density or the score or the discriminator a function you can read, which is exactly what you want when the goal is understanding the model class. What you cannot learn from these notebooks is anything about architecture choice at scale, since the architecture is fixed to the simplest thing that works.

If your question is which model class suits a problem, this repository answers it. If your question is which architecture to deploy, it does not, and does not claim to.

## Eleven folders and eleven abbreviations

The folder names are compact to the point of needing a glossary. mog is the mixture of Gaussians. arms is autoregressive models. ddgms is the diffusion-based folder. sbgms is the score-based folder. ebms is energy-based. flows is flow-based with RealNVP and integer discrete flows. vaes is the VAE folder with three separate examples. hybrid_modeling, neural_compression, gans and llms are spelled out.

The abbreviation pairs have a logic worth learning once. A model class and the plural or singular of its acronym form most of the names, so arms rather than autoregressive and ebms rather than energy_based. Two exceptions break the pattern, ddgms and sbgms, where the extra letter carries the distinction between deep generative models generally and score-based generative models specifically.

Inside the folders the structure is consistent and useful. vaes holds three examples in order of difficulty: a fully-connected VAE with a standard Gaussian prior, then a set of variations on the prior, then a hierarchical VAE. sbgms holds three in the same shape, moving from score matching to SDE-based diffusion to conditional flow matching. The flows folder pairs RealNVP, built from coupling and permutation layers, with integer discrete flows, which the hybrid model then reuses.

So the naming is terse, but the progression inside each folder is deliberate and worth following in order.

## Teaching material, with a citation request attached

There is a folder for instructors containing two things. The first is a set of assignment examples, three of them: one on autoregressive models, one on VAEs, and one designed as a group assignment. The second is a figures folder, offered on the understanding that teachers preparing lectures might find them useful. The README asks that the book be cited as the source when using this material.

There is a small inconsistency worth flagging for anyone planning a course. The README links the lecture figures to a path inside the teaching folder, while the repository also carries a figures directory at the top level. Whether that is a leftover, a duplicate, or a link that has drifted, it means the path in the README is not the one you would guess from browsing the tree.

Group assignments and lecture figures together suggest the material has been used the way it was intended, which is a reasonable signal about quality for a teaching resource. The citation request is the part to honour: the notebooks accompany a commercial book, and the README is explicit that using the code in any way should refer to it by citing the book.

The citation is given in two forms, an author-date reference and a BibTeX entry for the book, both naming Springer Cham and the year 2024:

```
Tomczak, J. M. (2024). Deep Generative Modeling. Springer Cham
```

## Conclusion

intro_dgm is the right repository for someone who wants to understand what each generative model class actually computes rather than how to train one at scale, because every line is meant to be followed and the models are small enough to run on a laptop. Plan for the setup, not the concepts: there is no requirements file, the listed pins belong to an older generation of Python and PyTorch, and no Python version is named, so budget an afternoon for the environment. And if you plan to teach from it, note that the figures directory referenced for lectures sits at the top level rather than inside the teaching folder the README links to.

## FAQ

### What does intro_dgm contain?

Eleven folders of Jupyter notebook examples covering mixture of Gaussians, autoregressive models, RealNVP and integer discrete flows, VAEs, diffusion, score-based and flow-matching models, a hybrid model, energy-based models, GANs, neural compression, and a decoder-based transformer nicknamed teenyGPT.

### What packages do the intro_dgm examples require?

The README lists pytorch 1.7.0, numpy 1.17.2, matplotlib 3.1.1, scikit-learn 0.21.3, pytorch-model-summary 0.1.1 and jupyter 1.0.0. There is no requirements file in the repository and no Python version is named.

### Are the intro_dgm models realistic implementations?

No, and the author says so. The examples are described as oversimplistic on purpose so that every line can be followed, and almost every model is parameterised by an MLP. The autoregressive folder and the teenyGPT transformer example are the exceptions with real architecture.

### Can I use intro_dgm for teaching?

Yes. The teaching folder holds three assignment examples covering autoregressive models, VAEs and a group assignment, plus figures for preparing lectures. The README asks that the book Deep Generative Modeling be cited as the source when using the code in any way.

### How do I cite the code in intro_dgm?

By citing the book. The README gives an author-date reference to Tomczak, Deep Generative Modeling, Springer Cham, 2024, and a BibTeX entry for the same, and asks that any use of the code refer to it that way.

## Sources

- [Issues](https://github.com/jmtomczak/intro_dgm/issues)
- [jmtomczak/intro_dgm on GitHub](https://github.com/jmtomczak/intro_dgm)
- [License: MIT](https://github.com/jmtomczak/intro_dgm/blob/main/LICENSE)
- [README](https://github.com/jmtomczak/intro_dgm/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jmtomczak-intro-dgm