Variable FUNCTION to a python expression (for example a + b) you can compute an arbitrary loss based on the Hyperdock parameters. By default it outputs 0 as its loss but by setting the environment It is available as a Docker image namedĮrikgartner/hyperdock-demo:latest. See the Dockfile template for an example. /data a read only folder that contains any external data needed.out/ persistent folder, use this to write any other files to the result folder.graphs.json optional file, contains graphs for Web UI plots format described here.params.json parameters for the run format described here.
loss.json write the loss here format described here.
#Hyperdock monterey code#
Write the loss / results and then exit (with error code 0).Ĭommunication between Hyperdock and the target program is handle through a few special files and folders that are mounted and populated by Hyperdock.When running the container the target should: checkout the latest source from Github) but preferably should be reproducible, for example by always checking out a specific commit. # Set Mongo Database URL export MONGO_URL=mongodb://localhost:27017/hyperdockĮach optimization target needs a target image. # Go into the Web UI source folder cd web/ To start the Hyperdock Supervisor using the Docker image run the following command: Finally you can also use the Docker compose file to setup a single host Hyperdock environment useful for testing - this method is very quick way to get started.
You can either use the pre-built Docker images for Hyperdock or run the sub-systems directly on the host(s).
#Hyperdock monterey how to#
See the wiki for details on how to define the parameters space. Hyperdock supports grid search of parameters from lists and distributions. More about how to write a target image can found below. Logs from the target image are periodically tailed from the workers to the WebUI.
Once the target image has evaluated the parameters it simply writes the loss to the file /hyperdock/loss.json with the option of storing important files to /hyperdock/out. Parameters are available in the json file /hyperdock/params.json. They only need to be able to access the same Mongo database and the workers need to have access to any data required by the target image.Įach program that should be optimized needs to have its own Docker image, the target image, that is setup to load the parameters and write progress reports. Supervisor, Workers and WebUI need not run on the same host. The entire Hyperdock system can be distributed, i.e. They continually send status updates to the database to notify the user of progress. The Hyperdock Workers dequeues jobs from the work queue and then evaluates the target image with these parameters. It determines what jobs (a specific hyperparameter combination) need to scheduled, which jobs have failed and should be restarted, and notifies users of results. The Hyperdock Supervisor is a background process that monitors all trials. All trials, their status and results are stored in a Mongo database. The Hyperdock Web UI is the main interface for the end-users from where they can specify trials (a target Docker image and the hyperparameter space to search over). The figure below shows the Hyperdock system and its main components. That means that the target can be written in any language, use any framework or run on any operating system as long as it can be made into a Docker image. Hyperdock is a framework for hyperparameter search that can be used to optimized any target as long as that target can be run in a Docker container. A simple framework for distributed hyperparameter optimization in Docker.
0 kommentar(er)
