Profile before choosing more compute
Measure examples per second, accelerator utilization, host CPU, memory, storage throughput, and time spent waiting for input or communication. If an accelerator is idle while batches load, investigate preprocessing and data delivery before adding devices. If device memory is exhausted, reduce memory demand or consider a distribution strategy suited to the model. If workers spend most of their time synchronizing, adding more workers may make scaling less efficient. Compare runs with the same workload and record cost as well as elapsed time.
A job processes 100 examples per second with one GPU and 150 with two GPUs. The two-GPU speedup is 1.5 times and scaling efficiency is 75%. List two reasons it may not double, then name a measurement that could distinguish input starvation from communication overhead.
Define a fair tuning experiment
Choose a metric that reflects the decision, its direction, a representative validation set, parameter ranges, and a maximum budget before starting. A training application must accept each trial’s values and report the named metric to the tuning service. Record the code revision, data snapshot, seed where applicable, environment, hyperparameters, and artifacts. Keep a final test set separate from model and threshold selection. Compare the winning candidate with a simple baseline and assess variability across runs when the result is close.
For an imbalanced fraud classifier, select a validation metric and an operating constraint. Specify two hyperparameters and plausible search ranges, then describe how you will choose a candidate without inspecting the final test set.
Separate parallel trials from distributed training
Parallel trials run independent training jobs with different hyperparameter settings. Distributed training uses multiple workers for one training run. They solve different problems and can be combined, but both consume resources. More parallel trials may finish a search sooner while providing fewer completed results to an adaptive search algorithm before later trials start. Estimate peak resource usage and quota from the resources per trial multiplied by simultaneous trials, including additional workers.
Each trial needs two GPUs and three trials run concurrently. Peak requested GPU capacity is six, excluding any other jobs. If a fourth trial is queued, explain why it does not increase the peak until it starts.
Choose a configuration you can operate
A small improvement in validation quality may not justify a large increase in training time, inference latency, or serving cost. Check slice performance, failure modes, and operational constraints before promotion. Agent Platform documents tuning jobs with trial limits, parallelism, and metric reporting. Its current documentation also states that its hyperparameter tuning jobs do not support TPUs, even though other custom training approaches can use supported TPU configurations. Confirm current regional availability, quotas, and product limitations before planning.
Candidate A has validation recall of 0.81 and meets latency and cost constraints; candidate B has recall of 0.82 but exceeds the latency limit. Which is eligible under those constraints, and what additional evidence would you collect before release?
An accelerator has low utilization and training spends most of its time waiting for batches. What should you investigate first?
Keep exploring
Use the official certification page and its linked resources to validate your coverage. For guided labs, explore the Google Skills learning path. Revisit the practical exercise and explain your decision in your own words before moving on.