Verda

Tensorant creates single-GPU training instances in your Verda account, supplying the startup script, supported CUDA image, and run-specific OS volume. Your organization's separate storage connection keeps datasets and exported adapters.

An Owner can save the connection in Tensorant. Open your name at the foot of the sidebar, then Settings → Connections under Organization. If the page says Provided by Tensorant, ask your platform administrator about using your own account.

1. Prepare your Verda account

1. Sign up or sign in to the Verda console.
2. Select the project you intend to use. Your identity needs access to create and manage instances, OS volumes, and startup scripts there.
3. Open Billing & Top-up and add credit. Pay-as-you-go usage is prepaid; keep enough for compute and retained volumes. See Verda billing.
4. Check that your account's GPU quota permits the intended instance type. Quota and regional capacity are separate requirements.

You do not need to create the training VM, OS volume, or startup script manually. Tensorant creates those when you launch.

2. Create Cloud API credentials

1. In Verda, open Credentials in the sidebar.
2. Under Cloud API credentials, choose + Create.
3. Save both the Client ID and Client Secret securely. The secret is shown once.
4. Keep the credentials active while Tensorant has running or retained resources. Verda ties them to their creator; removing that member from a project deletes their credentials. See credential setup and lifecycle.

Use Cloud API credentials for this integration. Verda's separate Inference API Keys cannot replace the client ID and secret used to manage training machines.

3. Register an SSH key and get its ID

1. Use an existing SSH key pair or generate one locally with ssh-keygen -t ed25519. Choose an unused file name and a passphrase to avoid overwriting another key.
2. Copy the public key from the .pub file. Keep the private key on your computer.
3. In your Verda project, open the SSH key section, documented as Keys → SSH Keys → Create. Paste the public key and save it with a recognizable name. See Verda SSH setup.
4. Obtain its UUID, not just the key name. If the console does not expose it, configure the official Verda CLI with your Cloud API credentials and run this read-only command:

verda ssh-key list

Copy the ID for your registered key. The equivalent API is GET /v1/ssh-keys; see SSH key tools and the API reference. Tensorant checks that your credentials can access this ID.

4. Choose a location and check image support

Choose a location code where the intended GPU is offered, such as FIN-01. Use the code rather than a city name; see Verda locations.

Tensorant currently uses this exact host image:

ubuntu-24.04-cuda-13.0-open-docker

There is no image field in the connection form. Tensorant only lists on-demand, single NVIDIA GPU types that advertise this image in their supported_os catalog and have capacity in your location. ARM/Grace systems are excluded. The trainer additionally requires Ampere or newer; do not select a T4 or another pre-Ampere GPU even if it appears in the catalog. A different Ubuntu or CUDA image cannot be substituted through the current form.

This image is present in Verda's public catalog and CLI instance examples, but availability can change. If the GPU list is empty, check image support and regional capacity in Verda. A catalog check does not launch a VM or inspect packages on a running machine.

5. Save the connection in Tensorant

Open Settings → Connections, choose Connect Verda, and enter:

Choose Connect Verda and wait for Connected. Tensorant checks authentication, SSH-key access, GPU capacity, and prices without creating a paid instance. When updating a connection, reenter its credentials and choose Save connection.

6. Connect permanent storage

Follow the custom S3 guide for a dedicated bucket, or use RunPod network storage. Verda transfers data to either backend; it cannot mount a RunPod volume.

Your organization's own storage credentials are supplied to the training machine for dataset, image, and adapter transfers. Use appropriate storage permissions. If choosing Verda object storage, its S3 credentials are separate from the Cloud API credentials above.

The Verda OS volume is temporary working storage, not a replacement for this connection. Verda integration covers training; managed serving currently uses RunPod.

7. Verify a training trial

1. Create a project and dataset version using the quickstart.
2. Open Tune → Runs → Configure a run and choose Training trial · a small sample.
3. Select the dataset, set Training provider to Verda, and choose an available Ampere-or-newer Training GPU with enough memory. T4 and other pre-Ampere GPUs cannot run the trainer.
4. Review Price limit ($/hour) and trial runtime. Verda's estimate includes the GPU and requested OS-volume capacity; other storage and transfer costs may be separate.
5. Choose Save trial draft. Saving does not launch compute.
6. When ready for a billable test, choose Launch trial, review the confirmation, and confirm.
7. Watch Training logs, then confirm adapter verification and resource cleanup. Availability and price are checked again at launch.

Recovery, hibernation, and billing

Verda shutdown alone does not release GPU billing. On a recoverable failure, Tensorant requests shutdown and then hibernation. Hibernation removes the VM and detaches its OS volume, preserving files while ending the instance allocation. Volume storage remains billable. See the lifecycle operations in the Verda API.

To recover after hibernation:

1. Identify this run's retained OS volume. Tensorant names it tensorant-<startup-script-UUID>; match the run's instance and startup-script records before selecting it.
2. Attach that existing volume to a suitable recovery VM using Verda's volume tools. This helper VM is separately billable. Mount the existing filesystem without formatting it.
3. Copy adapter.zip from var/lib/tensorant/data on the mounted volume. With RunPod storage, look in its runs/<run-id> subdirectory. Tensorant's recovery panel also shows the container path.
4. Unmount and detach the retained volume from the helper VM. Tensorant refuses to delete it while another VM has it attached.
5. Upload the archive under Recover your adapter and choose Verify and recover. After verification, Tensorant deletes remaining run resources, including the retained volume and startup script.
6. Confirm cleanup in Tensorant and Verda. Release any helper VM you created when finished.

If the output is no longer needed, use Cancel run. Keep account credit and credentials valid until cleanup finishes. Startup scripts can contain storage credentials and gated-model tokens, so restrict access and resolve any reported script-cleanup failure.

Common problems