Over fall break, I worked on quantizing a model. This post collects what I learned while trying to understand Qwen-Image-2.1-Turbo: what each part does, where the memory goes, and what changes when you store the weights with fewer bits.
Claude helped me build the interactive explainers below. Being able to change a setting and see the shapes, noise levels, or memory estimates made the pieces easier to connect. I wanted to keep all of those tools and examples together, so this includes the full guide, not just the final memory calculator.
A text prompt goes in. An image comes out. The part I wanted to understand was everything in between: what represents the prompt, what changes during sampling, and what finally becomes pixels.
Explore the model
Open the interactive guide in a full page. This is the easiest way to explore the diagrams on a phone or read the whole manual without scrolling inside the embed.
The guide's token vectors, attention grid, and images are teaching illustrations, not outputs from a running model. Its model-specific figures are reproduced from the supplied guide; the memory calculator estimates working memory rather than measuring a device. Treat its fit indicators as estimates, not guarantees.
All the tools and examples
The full guide contains ten figures. You can jump directly to any of them:
- Prompt-to-image pipeline: select a stage and change the image size to inspect its output shape.
- Tokens and vectors: enter a prompt and compare illustrative vectors before and after contextual encoding.
- One word, two meanings: compare “bank” in a river sentence and a money sentence.
- Pixels and the latent: explore the illustrated relationship between image blocks and latent channels.
- Image sizes and token counts: compare resolutions, latent grids, and numbers of image tokens.
- Eight denoising steps: play the animation or move the slider through the noise schedule.
- Inside the transformer: follow image tokens, text tokens, and the noise level through its blocks.
- Attention and the KV cache: select token rows and compare the first step with later steps.
- Transformer runs per image: compare the guide's illustrative base-model workload with the Turbo schedule.
- Memory calculator: change weight precision, resolution, staged loading, and tiled decoding.
Three parts, three different jobs
The text encoder turns the prompt into contextual vectors. Those vectors give the image model a numerical representation of the words and their relationships. In the guide, try changing the prompt and switching between the vectors before and after the encoder. The values are illustrative, but the distinction is the point: a token's meaning depends on its context.
The diffusion transformer repeatedly updates a noisy latent representation using that prompt information. Move the denoising slider to see how the illustrated noise level changes across the sampling schedule. The model works in a compressed space; it does not redraw every output pixel directly at each step.
The VAE decoder turns the resulting latent into pixels. The latent visualization connects the image's spatial dimensions to the number of values that the transformer works with. Its block view is a simplified illustration of compression, not a claim that a learned decoder reconstructs each block independently.
This guide focuses on how the components fit together at inference time. For the idea behind training a faster model to imitate a slower one, see Model Distillation.
Explore the memory tradeoff
The last figure lets you change text encoder precision and transformer precision separately. It also lets you compare keeping the components loaded with releasing the text encoder after it has encoded the prompt. Toggle tiled VAE decoding to see how a different execution strategy changes the estimated peak.
That distinction matters: weight size is only part of the memory budget. Activations, temporary buffers, image resolution, and which components remain resident all affect the peak. A smaller checkpoint file does not by itself establish that a generation will fit.
My post on fitting big models on small GPUs covers the broader quantization tradeoff. Here, the useful question is more specific: which component occupies memory at the moment the pipeline needs the most of it?