Understand the technology
Balance quality with time and resources.
For May and November 2027. This introductory lesson is shared SL and HL content.
01 | A BEAUTIFUL IMAGE CAN STILL BE AN EXPENSIVE RESULT
Visionary Studios needs images that meet a creative brief, but also a workflow that fits its resources. A configuration that produces excellent candidates slowly may suit a final concept review but frustrate a designer exploring many ideas.
The case study highlights diffusion’s ability to produce photorealistic images alongside its iterative computational demands. Evaluating that trade-off means asking what the company obtains for the time and resources it spends.
All numerical examples in this lesson are invented classroom estimates, not measured performance figures from the booklet or a particular product.
02 | DEFINE QUALITY BEFORE MEASURING SPEED
Quality is suitability for the task. A photorealistic output is not automatically better than an illustration when the client has requested an illustrated campaign.
Review resolution, visual defects, prompt adherence, style and any required character consistency. Also check whether essential objects and layout features are correct.
Agree acceptance criteria before a trial. Otherwise, a fast system might appear efficient simply because reviewers quietly accept weaker results.
03 | WHY ITERATION TAKES TIME
Diffusion sampling repeatedly evaluates a trained predictor and applies update rules to an evolving sample. Later states commonly depend on earlier updates.
More evaluations generally mean more work when the model and other conditions are comparable. However, step count and model-call count are not always identical: some guidance procedures perform multiple evaluations within one sampling step.
There is also work outside the denoiser, including prompt processing, decoding where relevant and application operations. Raw denoising time is only part of the user experience.
04 | MORE STEPS DO NOT GUARANTEE MORE QUALITY
A sampler needs a configuration suitable for its model. Too few steps can give poor results, but increasing the count may eventually provide little benefit or change outputs in unhelpful ways.
Different sampling methods can make useful outputs with different numbers of evaluations. A 20-step result from one system cannot be ranked against a 40-step result from another using those counts alone.
The studio should compare accepted output quality and measured time under documented conditions. It should not treat the largest step count as a universal quality setting.
05 | RESOLUTION CHANGES THE WORKLOAD
A 512 × 512 image contains 262,144 pixels. A 1024 × 1024 image contains 1,048,576 pixels: four times as many, because both dimensions doubled.
More spatial data can increase memory and computation. The exact increase depends on the architecture, representation and implementation; it is not safe to conclude that generation time must increase by exactly four times.
Resolution also is not the same as correctness. A larger image may still contain distorted objects or fail the required layout.
06 | MODEL SIZE AND INTERMEDIATE VALUES
A model needs memory for learned parameters. Running it also requires intermediate computed values, temporary buffers and other state.
Larger models can require more memory and computation, but parameter count alone does not determine runtime or output suitability. Architecture, numerical precision and software implementation also matter.
Distinguish storage on disk from working memory. Having enough disk space to download a model does not prove that the available device can run it efficiently.
07 | GPU MEMORY IS A CAPACITY LIMIT
A GPU can perform many numerical operations in parallel. Its own memory, often called VRAM, holds data needed by GPU computations.
If a workload exceeds available memory, it may fail or require a different arrangement, such as a smaller batch or moving some data between memory locations. Such changes can affect speed.
There is no single GPU specification that suits every model. Visionary Studios should test the actual model, resolution and workload rather than buy hardware from an unsupported rule of thumb.
08 | LATENCY AND THROUGHPUT ANSWER DIFFERENT QUESTIONS
Latency is the time taken for a request to complete. Throughput is the amount of completed work per unit time, such as images per minute.
A designer waiting for one revision cares about latency. A team generating a large set of candidates may also care about throughput.
A system can improve throughput without reducing the waiting time for an individual request. State which measure matters rather than using “faster” without defining it.
09 | BATCHING AND QUEUES
Batching processes several examples together. It can improve use of hardware and increase throughput, but usually requires more working memory.
A larger batch does not guarantee lower individual latency. Requests may also wait in a queue before processing begins, especially when several designers use the system at once.
Measure under realistic demand. A single-user trial can hide delays that occur when the studio’s workload grows.
10 | TRAINING AND GENERATION HAVE DIFFERENT COSTS
Training includes repeated predictions, loss calculations, gradient computation and optimizer updates. It also needs suitable data preparation and evaluation.
Generation uses a trained model without ordinary parameter updates, but still performs repeated computations. A high volume of requests can make inference a substantial ongoing workload.
Using a pretrained model avoids the need to repeat its original training, but does not make generation free. Fine-tuning introduces additional learning work that should be considered separately.
11 | MEASURE THE COMPLETE CREATIVE WORKFLOW
The user’s time can include preparing a prompt or sketch, waiting in a queue, generating candidates, reviewing them and editing selected outputs.
Brief, guidance inputs and queue delay.
Model evaluations and supporting processing.
Reject unsuitable candidates and correct selected work.
A configuration that produces images quickly may still be inefficient if few meet the brief. Measure time and cost per acceptable result as well as per generated image.
12 | A SIMPLE SEQUENTIAL WORKLOAD ESTIMATE
Suppose a configuration performs 30 model evaluations per candidate, each estimated at 0.08 seconds. Add 0.6 seconds of other processing per candidate. Estimated time is (30 × 0.08) + 0.6 = 3 seconds per candidate .
Generating 12 candidates one after another takes 36 seconds under these assumptions. If three are accepted, generation time per accepted candidate is 36 ÷ 3 = 12 seconds .
This assumes constant timings and sequential execution. It excludes preparation, queues and editing. Real batching, caching, hardware variation and service behaviour can change results.
13 | TRY THE WORKLOAD CALCULATOR
Change the assumptions to explore estimated sequential generation time. Enter the number of model evaluations, not a step count that may hide extra model calls.
The calculator is an arithmetic model, not a benchmark or image-quality predictor. It does not simulate batching, queueing or a real GPU. Accepted outputs must be observed or explicitly assumed; the calculator cannot infer them from step count.
14 | A SLOWER CANDIDATE CAN BE MORE USEFUL
| Measure | Configuration A | Configuration B |
|---|---|---|
| Seconds per candidate | 2 | 4 |
| Sequential generation time | 40 seconds | 80 seconds |
| Accepted candidates | 2 | 8 |
| Generation time per accepted candidate | 20 seconds | 10 seconds |
B is slower per generated candidate but uses less generation time per accepted candidate in this trial. The acceptance criteria must be the same, and editing time and repeated trials still matter.
15 | OPTIMISE THE TASK, THEN TEST THE EFFECT
The studio could investigate fewer evaluations with a suitable sampler, lower-resolution drafts, smaller batches when memory is limited or a latent representation where supported.
Each change needs evaluation. Lower-resolution drafts may help exploration but fail final delivery requirements. Lower numerical precision can reduce memory in compatible implementations but may introduce accuracy or stability trade-offs.
These are possible engineering choices, not guaranteed improvements. Change relevant factors deliberately, record conditions and compare output acceptance as well as resource use.
16 | LOCAL OR HOSTED COMPUTATION
Local execution can offer control over the environment and reduce dependence on an external generation service, but requires suitable equipment, maintenance and capacity planning.
A hosted service can provide access to remote computation without owning all the hardware. It introduces service costs, network dependencies, data-handling questions and possible usage limits.
The booklet supplies no current prices or selected hosting arrangement. A recommendation should identify what the studio needs to investigate instead of inventing exact costs or declaring one option universally better.
17 | DESIGN A FAIR STUDIO TRIAL
Use representative briefs and agreed acceptance criteria. Record the model version, sampler, evaluation count, resolution, guidance, hardware or service conditions and relevant settings.
Generate repeated candidates, record latency and throughput, monitor resource limits and track rejection and editing. Test representative concurrent demand rather than only an idle system.
18 | MAKE A JUSTIFIED RECOMMENDATION
In your book, recommend a trial strategy for early concept exploration and final campaign assets. Explain which quality requirements remain essential and which resource measures you would collect.
Use the A/B example to explain why seconds per generated image alone can mislead. State one limitation of the calculator.
Reveal a possible response
Test a responsive draft configuration for concept exploration while preserving enough quality to judge the idea. Compare final-asset configurations using style, defects, resolution and consistency criteria. Record generation and editing time, acceptance rate and realistic queue delay.
Configuration B takes longer per candidate but yields more accepted work in the invented trial. The calculator assumes constant sequential timings, so it cannot predict real batching or concurrent service behaviour.
Read alongside the computational efficiency and diffusion challenges in the official 2027 booklet. All timing figures and trial results here are classroom illustrations.
CHECK YOUR UNDERSTANDING | WHAT ARE YOU MEASURING?