Understand the technology
Separate speed, stability and generalisation.
For May and November 2027. This introductory lesson is shared SL and HL content.
01 | TWO QUESTIONS ABOUT A MODEL
A model may train quickly yet produce poor results. Another may improve reliably but require more computing time than Visionary Studios can support. These are related concerns, but they are not the same.
Computational efficiency concerns how effectively resources are used to achieve a useful result. Training stability concerns how reliably the learning process progresses towards useful behaviour.
The case study asks the studio to consider both. A good evaluation measures the work required and checks whether learning is progressing usefully.
02 | DEFINE THE RESULT BEFORE THE EFFICIENCY
Efficiency needs a goal. A configuration that processes many examples per second is not necessarily best if it fails to reach an acceptable model.
Compare resource use against a defined target, such as an agreed validation criterion and acceptable generated outputs. Keep quality requirements consistent across trials.
The booklet gives no numerical performance target for the company. Any targets and figures used in this lesson are classroom examples, not reported company results.
03 | TRAINING DOES MORE THAN RUN PREDICTIONS
A training step can include preparing a batch, making predictions, calculating loss, computing gradients and updating parameters. Data loading and saving checkpoints can add work.
Gradient computation and optimizer state introduce requirements beyond ordinary inference. Working memory must accommodate more than the saved model file.
Using a pretrained system, fine-tuning it and training from scratch therefore have different costs. The studio should identify which activity its proposal actually requires.
04 | MEASURE TIME AND RESOURCE USE
Useful measurements include elapsed training time, examples processed per second, peak working memory and the resources needed to reach a defined target.
A busy GPU does not automatically mean the whole process is efficient. Work can be wasted on unsuitable examples, unstable updates or repeated failed runs.
Measure the complete relevant scope. Reporting only model computation while excluding a severe data-loading delay can misrepresent the practical workflow.
05 | DATA CAN BECOME THE BOTTLENECK
A bottleneck is a part of the process that limits overall progress. If images arrive from storage too slowly, the processor may wait for data.
Preparation can include decoding, resizing and forming batches. Improving the pipeline may help when that pipeline is the limiting factor; it will not fix every training problem.
Before buying faster hardware, investigate where time is spent. A more powerful processor cannot solve a persistent shortage of ready input data by itself.
06 | BATCH SIZE AND MEMORY
A batch groups examples for a training calculation. Larger batches can improve hardware utilisation, but require memory and change the statistical behaviour of the update.
A smaller batch may fit available hardware but produce noisier gradient estimates. The best arrangement depends on the model, objective and optimizer.
Changing batch size can require other training adjustments. It is not safe to assume that doubling it always doubles useful learning speed or leaves the learning behaviour unchanged.
07 | WHAT DOES STABLE LEARNING LOOK LIKE?
Stable learning makes useful progress without persistent numerical failure or uncontrolled deterioration. A training loss may fluctuate while its longer-term pattern improves.
Different batches and sampled noise levels can have different difficulty, so every point need not be lower than the previous one. Look at trends and variation over an appropriate interval.
A smooth loss curve is not sufficient evidence on its own. A model can settle into poor behaviour or overfit while appearing numerically calm.
08 | LEARNING RATE AFFECTS UPDATE BEHAVIOUR
The learning rate influences the scale of parameter updates. Excessive updates can cause overshooting, large oscillations or divergence. Very small updates can make progress slow.
The same numerical value is not equally suitable for every optimizer and setup. A schedule may change the rate during training, but no schedule guarantees success.
When investigating instability, change and record settings deliberately. Do not treat one lucky run after several simultaneous changes as proof of the cause.
09 | NUMERICAL FAILURES NEED INVESTIGATION
Training may produce extremely large values, infinities or “not a number” values, often written NaN. These can stop useful learning.
Possible causes include unsuitable updates, problematic inputs or numerical limits. The cause needs diagnosis; “the GPU is too slow” is not an explanation for every failure.
Techniques such as gradient clipping or appropriate precision settings can help particular problems, but they are not substitutes for checking the data, objective and implementation.
10 | TRAINING STABILITY IS NOT CHARACTER CONSISTENCY
Training stability describes learning behaviour. Character consistency describes recognisable appearance across generated images. A stable training run does not automatically preserve the same face across a campaign.
Likewise, efficient generation does not prove efficient training. Seconds per image and time to train a suitable model measure different activities.
Use precise terms in written answers. Explain which stage and outcome your evidence concerns.
11 | USE VALIDATION TO CHECK TRANSFER
Training loss describes performance on the learning examples and objective. Separate validation examples help assess whether improvements transfer beyond those updates.
If training loss keeps falling while appropriate validation performance worsens, overfitting is a concern. This differs from numerical divergence.
Keep a final evaluation appropriately independent. If a test set repeatedly guides model selection, it has become part of development rather than a fresh final check.
12 | READ THREE TRAINING LOGS
| Run | Training observations | Validation observations | Interpretation |
|---|---|---|---|
| A | Loss fluctuates around a declining trend | Improves across checkpoints | Encouraging progress; still inspect generated outputs |
| B | Large increases followed by non-finite loss | Cannot complete evaluation | Investigate numerical instability |
| C | Loss continues falling | Worsens after earlier improvement | Investigate overfitting and checkpoint selection |
These patterns suggest investigations, not unique diagnoses. Loss values from unrelated objectives or noise sampling schemes may not be directly comparable.
13 | CHECKPOINTS MAKE RECOVERY AND REVIEW POSSIBLE
A checkpoint can save learned parameters and, for resuming training, relevant state such as optimizer and scheduling information.
Checkpoints allow comparison of stages and recovery after interruptions. A deployment may use an earlier well-validated checkpoint rather than simply the last one saved.
Resuming closely can also require random-state and data-position information, depending on the system. A saved image output is not a complete training checkpoint.
14 | COMPARE TIME TO AN AGREED TARGET
Consider two invented runs. A takes 0.5 seconds per step and reaches an agreed validation target in 2,000 steps: 1,000 seconds . B takes 0.8 seconds per step and reaches that target in 1,000 steps: 800 seconds .
B has slower individual steps but a shorter estimated time to target. Its reduction relative to A is (1,000 − 800) ÷ 1,000 × 100 = 20% .
This comparison assumes the target is genuinely comparable and excludes other overheads. Repeat runs and report failures as well as successful runs before drawing a strong conclusion.
15 | AN OPTIMISATION CAN CHANGE THE TRADE-OFF
Compatible lower-precision computation can reduce memory or improve speed, but needs evaluation for numerical behaviour and output quality. Changes to the data pipeline can help a data bottleneck without changing the learning objective.
Changing architecture, batch size or the optimizer can affect both speed and learning. Evaluate the combined effect rather than reporting only faster steps.
A sensible trial asks whether the change reduces resources needed for an acceptable result, not whether one number improved while other outcomes were ignored.
16 | KEEP AN EXPERIMENT RECORD
Record the data version and splits, model checkpoint, objective, optimizer, learning-rate settings, batch arrangement, precision and execution environment.
Keep timing, memory, training and validation records together. Generate samples using documented evaluation conditions so that apparent changes are not simply different sampling settings.
Repeated runs help reveal variation. A seed supports reproducibility under compatible conditions, but does not guarantee identical behaviour across all hardware and software.
17 | APPLY IT TO VISIONARY STUDIOS
The studio may instead use a pretrained service. In that case it should investigate the provider’s evidence and evaluate deployed outputs, rather than assume it must reproduce all original training itself.
18 | WRITE A DIAGNOSIS AND A DECISION
Choose a run from the log table. Describe the evidence, suggest a plausible investigation and explain what additional information would be needed before changing the setup.
Then use the A/B timing example to explain why slower steps can still reach a useful model sooner.
Reveal a possible response
Run C has falling training loss but worsening validation behaviour. Investigate overfitting, dataset separation and checkpoint choice before assuming a numerical failure. Inspect representative generated outputs as well as loss records.
Timing run B takes 800 seconds to the agreed target compared with A’s 1,000 seconds, despite taking longer per step. This is a 20% reduction under the stated assumptions; repeated trials and overhead measurements are still needed.
Read alongside computational efficiency and training stability in the official 2027 booklet. Logs, timings and detailed training practices here are independent teaching examples.
CHECK YOUR UNDERSTANDING | WHAT DOES THE EVIDENCE SHOW?