Aspect Ratio, Resolution and Training Buckets
10 min read · updated August 4, 2026
Image models are trained at a fixed set of resolutions, and the sizes in that set are not arbitrary: they are the sizes whose sides survive two stages of halving and whose pixel counts fit one budget. Both constraints are derivable, which means you can construct valid sizes for any model rather than hunting for a table.
The short answer
Two rules govern what resolutions work. First, each side must be a multiple of the pipeline’s total downsample factor, which is almost always 64. Second, the total pixel count should sit near the budget the model was trained at, because the model learned its notion of scale and composition at that budget.
Aspect-ratio bucketing is how the second rule is implemented during training: rather than cropping every training image square, the dataset is sorted into a small set of shapes with roughly equal pixel counts, and each batch is drawn from one bucket.
Why 64, derived
Two independent downsampling stages sit between your requested size
and the coarsest feature map:
1. The autoencoder factor 8
1024 pixels → 128 latent positions
2. The denoiser's own downsampling factor 8
a UNet with three 2× downsample stages: 2 × 2 × 2 = 8
128 latent positions → 16 at the bottleneck
Total: 8 × 8 = 64
A side that is not a multiple of 64 cannot be halved cleanly three times
after the eightfold encode. Implementations handle the remainder by
padding or by rounding, and both introduce an edge region the model was
never trained on — which is where the thin band of artefacts along one
side comes from.Transformer backbones downsample differently — a patch size of 2 on the latent gives a total factor of 16 rather than 64 — so their constraint is looser. Sticking to multiples of 64 is safe for both, which is why it remains the general advice.
Deriving a bucket list from a pixel budget
Given a base resolution, the buckets are the multiples of 64 whose product is closest to the budget, at the ratios you care about. Here is the derivation for a 1024-base model.
Budget: 1024 × 1024 = 1,048,576 pixels Rule: both sides multiples of 64, product as close to budget as possible ratio w × h pixels % of budget ---------------------------------------------- 1:1 1024 × 1024 1,048,576 100.0% 9:7 1152 × 896 1,032,192 98.4% 7:9 896 × 1152 1,032,192 98.4% 3:2 1216 × 832 1,011,712 96.5% 2:3 832 × 1216 1,011,712 96.5% 16:9 1344 × 768 1,032,192 98.4% 9:16 768 × 1344 1,032,192 98.4% 21:9 1536 × 640 983,040 93.8% 9:21 640 × 1536 983,040 93.8% Same construction for a 512-base model (budget 262,144): 1:1 512 × 512 262,144 100.0% 4:3 576 × 448 258,048 98.4% 16:9 704 × 384 270,336 103.1% 21:9 768 × 320 245,760 93.8%
To build the list for any model: find its base resolution from the model card, square it for the budget, and search multiples of 64 for the pairs nearest that product at your target ratios. Six lines of arithmetic, and it is correct for the model in front of you rather than for the one somebody wrote a blog post about.
Why generating too large duplicates the subject
Ask a 1024-base model for 2048×2048 and you frequently get two heads, two horizons, or a subject repeated across the frame. The cause is not a bug, and understanding it decides the fix.
The model learned the scale of things relative to the latent grid it was trained on. A face occupied roughly so many latent cells; a horizon sat roughly so far down. At twice the linear size there are four times as many cells, and the structures the model knows how to produce are sized for the smaller grid. The result is that the generated content tiles: the model produces a full composition at its learned scale and then, having more canvas, produces more of one.
Convolutional backbones make this worse because a convolution’s receptive field is fixed in cells, so at a larger grid it covers a smaller fraction of the image and long-range consistency weakens. Transformer backbones have a different version of the same problem: attention entropy shifts as the token count grows, and positional encodings are being asked to extrapolate.
The fix is never a better prompt. Generate at a native size and then enlarge, using the two-stage approach in image-to-image or a dedicated upscaler from image upscaling.
Why generating too small collapses
The opposite failure gets less attention. At 512×512 on a 1024-base model there are 64×64 latent cells, a quarter of the positions the model expects. Faces lose the cells they need, fine structure has nowhere to go, and composition often degenerates into a single centred blob.
This is the same capacity argument as the crop-and-resize trick in inpainting, seen from the other end. Latent cells are the model’s working space, and starving it of them degrades everything at once.
If you need small output, generate at native resolution and downscale. Downscaling is cheap, faithful in the ways that matter, and always better than generating small.
What resolution costs
Resolution is the one parameter whose cost is superlinear, which makes it the most consequential setting in the interface.
Let N be the number of latent tokens; N is proportional to pixel count. dense work (projections, MLPs, convolutions) ∝ N linear self-attention ∝ N² quadratic Going from 1024² to 2048² is 4× the pixels: dense term × 4 attention term × 16 Because the two terms start at different sizes, the combined figure lands between them and shifts as resolution grows. Worked in full, with a stated model size, in the GPU-seconds page: the answer for that model is about 7×, not 4×, and attention goes from a quarter of the work to well over half.
The complete derivation, covering every resolution from 512×512 to 2048×2048, is in the GPU-seconds behind one generated image.
Diagnosing a resolution failure
Resolution problems have distinctive signatures, and reading the signature saves you from trying prompt fixes on a geometry problem.
| Symptom | Description |
|---|---|
| two heads, two horizons, a repeated subject | Generating above the training resolution. The model produced its learned composition twice because it had twice the canvas. Generate smaller and enlarge; no prompt change addresses this. |
| a stretched or squashed subject | An aspect ratio far from any training bucket. The model's learned proportions are being applied to a shape it has no examples of. Move to the nearest bucket and outpaint to the target ratio. |
| a thin band of artefacts along one edge | A side that is not a multiple of the pipeline's downsample factor, so the remainder was padded or cropped internally. Round both sides to a multiple of 64. |
| mushy faces and collapsed composition | Generating below the training resolution. Too few latent cells for the structures the model knows. Generate at native size and downscale. |
| good at 1:1, poor at 21:9 | Bucket population. The extreme ratios have the fewest training examples, so the prior there is weakest. Expected behaviour rather than a fault, and the fix is to generate closer to square and outpaint. |
| sudden slowdown past a certain size | Not a resolution failure at all — memory. Attention memory grows with the square of token count, and past a threshold the runtime falls back to a slower memory-efficient path or starts paging. Check the attention backend before assuming the model is at fault. |
Reaching a size the model does not have
- Pick the nearest bucket to your target ratio. Not the nearest size — the nearest ratio at the correct pixel budget. Getting the ratio close matters more than getting the pixel count close.
- Generate there. This is the only step where the model is doing what it was trained to do.
- Extend the ratio by outpainting, not by stretching. If you need 21:9 and the model handles 16:9 well, generate 16:9 and outpaint the sides. See inpainting and outpainting.
- Reach the final pixel dimensions by upscaling. A refinement pass at low strength on the upscaled result puts detail back where the upscaler could not invent it.
- Crop last. Cropping to an exact delivery size after all generation is finished costs nothing and avoids asking the model for an off-bucket shape.