1. Define a result before choosing the GPU
Choose a sample that runs through your entire application. For inference, start with a few representative inputs and an expected output format. For model adaptation, plan a short run that reads the data, performs an update, and writes a checkpoint. The goal is to verify the full path before entrusting it with the final volume.
Let's take a teaching example: you want to classify documents. Prepare twelve identified documents, with several lengths and one case that the program must reject cleanly. Set the allowed categories and the destination of the results. The twelve identifiers must each appear exactly once in the report, with either an accepted result or an explicit error. This scenario should be adapted to your application; it assumes no particular model or throughput.
Scroll the table to read all columns.| Point to check | Criterion prepared before launch |
|---|---|
| Inputs | 12 unique identifiers; readable files; one invalid case included. |
| Results | One allowed category per accepted document; no invented identifiers. |
| Failures | A reason attached to each rejected document; no silent disappearance. |
| End of the test | Accepted + rejected = 12; report and results re-read from a copy. |
2. Choose the backend, memory, and plan
Start with the project's libraries. A CUDA dependency points you toward an NVIDIA stack; an MI300X offering requires examining ROCm support, particularly for extensions. The official PyTorch selector distinguishes the operating system from the compute platform: copying a command from another machine does not constitute a compatibility check.
Then compare the memory required for a representative task: weights, inputs, intermediate computations, and states specific to your method. The model file size is not enough. If you do not yet know the peak, keep this point as a goal for the pilot, without claiming that a model will fit based on its parameter count alone.
Choose 3, 7, or 30 days and from 1 to 10 lots. One lot contains one card, except the B200, which contains two. Multiple cards do not automatically distribute the program or unify their memory. Plan for installation, checks, computation, and export over the duration; the twelve pilot documents serve to verify the procedure, not to mechanically predict the length of the entire campaign.
3. Prepare a folder that survives a machine change
Gather the code revision, dependencies, data and model references, parameters, and the entry command. Specify how to provide the necessary credentials separately. A path to your home directory is not a transfer procedure: replace implicit assumptions with parameters and verify paths from the project folder.
The Ubuntu, PyTorch, Blender, or custom preparation you choose in the configuration expresses your requirement. It does not prove that your project, its extensions, or its licenses are already installed. Describe what must be present, then check the environment you actually receive before starting the processing.
For our batch of documents, keep an immutable pilot input, a parameters file, and a separate results folder per run. Also write down how to review the summary. This folder does not need to be large; it must prevent success from depending on a forgotten cell, an old terminal, or a file that was not copied.
project/
README.md # installation, launch, check
requirements-rebuild.txt # documented dependencies and provenance
config/pilot.json # parameters with no secrets
data/pilot/ # the 12 authorized inputs
src/ # your application
runs/ # one subfolder per run4. Review the order, then follow the service steps
The summary must match your choice: model, duration, lots, total number of cards, preparation and USD amount. The total is the lot price for the duration, multiplied by the number of lots. The B200 lot price already includes its two cards: do not multiply by the number of GPUs a second time.
For a first order, create your account with first name, last name, email and password. If you already have an account, log in; if you are already logged in, the details are prefilled. The account lets you find your orders and balance from another browser. The flow requires no KYC procedure and no identity document.
To pay in crypto, use the asset, network, address, amount and deadline displayed for the relevant payment. After the transfer, "I paid" records your report. It does not confirm receipt of funds or provisioning. A sufficient USD balance can also pay for the rental in full. Then follow the preparation information and the access details actually provided.
5. Check the launch before the final volume
Once the resource is provisioned, identify the interpreter actually in use and the environment loaded. Run the minimal diagnostic before your application. A successful PyTorch import does not prove GPU compute; a successful simple computation does not validate all model extensions. The diagnostic folder describes this progression and provides a downloadable resource.
Then run your pilot in a fresh output directory. For documents, check the identifiers, categories, number of successes and expected rejections. Examine several results along with their inputs: a syntactically valid output can still be incorrect for the intended use. Only move to the full corpus after writing down what was accepted and what still needs fixing.
If the launch fails, note the first error and the step reached. Check the interpreter before reinstalling; the paths before copying again; the input size before increasing the batch. Change one factor at a time. If the process runs long, organize its monitoring separately from the interactive connection used to start it.
6. Retrieve usable evidence and decide what to do next
Copy the results and their summary to a location you control, then review that copy. Check that it contains the parameters and references needed to understand the result. Do not treat a file present in the compute environment as your only backup. Do this check during the pilot, without waiting for the rental deadline.
For training, add a resume test in a new process. The Kernodeck mini-project demonstrates a method on CPU; your application still needs to qualify its own states, precision and data. For independent documents, resuming instead means identifying the items completed and those to reprocess.
Your final decision may be to launch the planned volume, fix the environment or revise the configuration. Keep this decision with its rationale. A pilot that reveals an incompatibility is useful: it turns a vague problem into a precise condition to resolve before committing more compute.