Overview

a rental contract grants a client access to specified resources (gpu, cpu, ram, disk, io, etc) of a machine for some period of time each rental contract is associated with one or more instances currently implemented via docker containers resources gpu each running instance currently has access to 1 or more gpus currently gpus are exclusive resources they are never shared between multiple users at the same time each contract grants instances exclusive access to specific gpus while that instance is running stopped instances have no gpu reservation cpu each contract/instance is allocated baseline cpu power in proportion to its fraction of attached gpus out of the total for example a 1 gpu instance on a 4 gpu machine will get 25% of cpu baseline instances can burst above their cpu allocation while there are extra cpu cycles to share, but during contention only the baseline is reserved ram system ram is allocated similar to system cpu each instance gets a fraction of ram as baseline in proportion to its fraction of attached gpus instances can temporarily use additional ram above their allocation when free ram is available, but doing so risks having processes killed by the oom killer when free system ram is scarce disk each instance has a disk storage allocation reserved in advance at instance creation time currently this allocation is static can't be changed after creation so make sure to size correctly on start misc misc resources such as shared memory (dev/shm, shm size) are also assigned automatically in proportion to gpu fraction duration each contract and thus instance has a duration/lifetime you can see this max duration on each offer on the search page before you create an instance once an instance hits its end date it expires and is automatically stopped expired instances can not restart while expired expired instances may be deleted 48 hours after expiration, so make sure to get your data off before then hosts can opt to extend contracts and often do, but this is not guaranteed and subjection to market conditions if your contract is extended the duration will update automatically, but this is entirely up to the provider image vast ai currently provides linux docker instances each such docker instance is a container created from a docker image you can use any docker image along with an optional custom repository and login credentials for private images launch modes we support several launch modes entrypoint/args, ssh, and jupyter the entrypoint/args launch mode just runs a container from your image in the obvious way, but also allows you to override the entrypoint and or launch args if you use the entrypoint/args launch mode you are responsible for setting up any connectivity such as ssh, jupyter, or web ui for the ssh and jupyter launch modes, we attempt to inject ssh and or jupyter access into the container our ssh mode attempts to setup both direct (using an open port) and proxy connections our jupyter launch mode supports either proxy or direct, but not both it also includes ssh our jupyter connection is secured with both https and a token using the jupyter direct option first requires installing our https certificate once