A hyperparameter optimization (HPO) service automates the search for training settings such as learning rate, batch size, and number of hidden layers. These values are chosen before training rather than learned as model weights and biases, yet they can affect model quality and training time or memory use. The service makes large trial runs practical by combining search algorithms with managed training execution. section 5.0 section 5.5
The service approach separates HPO from a training application. A user submits training code, a hyperparameter search space, a training objective, and an HPO algorithm through an API. The system then runs trials remotely and automatically, treating the training workload as a black box rather than requiring changes to its code. section 5.3 section 5.3.2 section 5.2.3
This reference architecture places the API interface at job submission, the job manager at trial orchestration, and the suggestion maker behind a unified algorithm interface. section 5.3.2
A general HPO service has three main components:
- API interface: accepts an experiment request containing training code, hyperparameters and their search space, and an algorithm choice. section 5.3.2
- HPO job manager: starts the trial loop, requests candidate values, launches training, records progress and metrics, and handles distributed setup and failure recovery. section 5.3.2
- Hyperparameter suggestion maker: wraps different search algorithms behind one interface, allowing users to select an algorithm without managing its execution details. section 5.3.2
A production-oriented design is training-code and framework agnostic: it should support arbitrary training code, languages, and frameworks. It also needs extensible algorithm support, parallel trials, distributed training within a trial, autoscaling, fault tolerance, separation of HPO execution from resource consumption, and portability. These concerns address the scale and stability limits of manually managed library-based execution. section 5.3.1 section 5.2.3 section 5.5
Selecting a library or service
For a small team using roughly 1–10 managed servers, an HPO library can be the simpler choice: it is flexible and can be integrated directly with training code. For a large organization running many trials, a service reduces repeated worker setup and centralizes automatic resource management. When building a general-purpose service is under consideration, adopting Kubeflow Katib is recommended over creating a new one. section 5.4 section 5.2.3 section 5.4.4 section 5.5
An HPO algorithm needs an objective function to judge each trial. The function receives a hyperparameter set, runs training, evaluates the resulting model, and returns a numeric score to minimize or maximize in later trials. Different tasks and constraints can favor model-free, Bayesian, or multifidelity optimization; no single algorithm is best in every case. section 5.4 section 5.5
In a production training workflow, the workflow service can call the HPO service instead of invoking the training service directly. This positions HPO as part of the route from training code and datasets to a trained model tracked with metadata and artifacts. section 10.2.4 section 10.0
