Before choosing a card, choose your output
Describe the work in one sentence: producing visuals in the right format, finding a procedure in documents, or checking a known calculation. Specify who will decide that the result is acceptable. "Try out AI" leaves too many possibilities open; "produce a set of eighteen legible images in our publishing tool" gives you a concrete endpoint.
Gather a small sample that also includes the project's difficulties. A very large image, a poorly formatted document, or an unusual input can change what you need. Write down what would make you correct or stop: unreadable output, an important detail altered, an answer with no justification. These criteria will serve you during the trial, even if the software reports no errors.
- A precise output and its expected format.
- One person and a few criteria for accepting it.
- Ordinary inputs and difficult cases.
- A saved copy of the starting files.
Prepare the files and the ways to retrieve them
Keep originals, settings, working outputs, and accepted deliverables separate. Give your trial a stable name, for example "visuals-trial-01". Check that the inputs open on your computer and identify any missing files. Preparing this structure up front saves you from spending the first hours hunting for a font, a linked image, or the right version of a document.
Also plan the return destination. Check its available space and who will be able to open it. The volume of data and your connection affect the transfer; an advertised speed for a link is not a guaranteed duration. Once you have access, a small round-trip copy will let you check the method before moving the whole folder.
Match the software, its version, and the memory
Note the exact name of the software, its version, and the required extensions. Check its documentation for the supported GPU and compute interface. PyTorch in particular distinguishes installations by compute platform. A software name in the configurator indicates a preparation preference: it does not certify an already installed version or the compatibility of all your components.
GPU memory is the working memory on the card; it is neither your file storage nor the server's general memory. The 24, 48, or 80 GB markers are compared against your needs. Multiple cards do not automatically pool their memory for a program designed for one GPU. Start with the configuration you can justify, then verify it with the sample.
Example: eighteen visuals and a 3.25-day window
Suppose a project with eighteen visuals, with compatible software and a need that fits on an RTX A5000. The schedule below is a working assumption after provisioning, not a production measurement. A day spent beforehand preparing the originals on your computer remains outside this window.
The total is 0.25 + 1 + 1 + 0.5 + 0.5 = 3.25 days. The 3-day plan therefore does not cover this schedule. For an RTX A5000 batch, the offered rates are 23.57 USD for 3 days and 55 USD for 7 days. If the eighteen deliverables are accepted, the 7-day plan works out to 55 ÷ 18, or about 3.06 USD per deliverable. External costs and your time are not included in this ratio.
Choosing 7 days covers the assumption, without guaranteeing that the project will be finished. If a person can only review the following week, adjust the schedule first. Reducing the estimate to artificially fit the project into 3 days does not resolve this constraint.
| Planned stage | Days elapsed |
|---|---|
| Preparation on the rental | 0,25 |
| Trial and active work | 1 |
| Awaiting validation | 1 |
| Revisions | 0,5 |
| Export and copy check | 0,5 |
| Total window | 3,25 |
Go from configuration to order tracking
In the configurator, review the model, lots, duration, and desired setup. The total multiplies the lot price by the number of lots; included cards are not billed a second time. Create your account with first name, last name, email, and password, or sign in to an existing account. The journey without an ID document or KYC still keeps a tracking account.
To pay, choose the asset and network together. Use the exact amount, destination, and deadline of your order's active request. After sending, "I've paid" keeps your report; this click does not confirm receipt and does not allocate the GPU. Tracking automatically updates the status sent by the server; only its confirmation validates the payment. Making the GPU available remains a separate step. The payment file details this step without asking you to reuse a sample value.
After receiving access, run through a complete flow
Start by checking that you find the expected resources and tools. Note the recognized model, the software version, and any discrepancies with your request. If any information is missing, describe the discrepancy in the order file before building your entire process on an assumption.
Then run a simple example, followed by a representative input. Check the device used and the output produced. In PyTorch, the model and data must be placed on the appropriate device; a program that finishes does not by itself prove that the GPU was used. Finally, retrieve the file and open it in the target tool. This whole journey is your first check.
When the test stalls, choose a precise fix
Keep the error message, the file concerned, and the settings. An installation failure, a lack of memory, and a disappointing output require different fixes. Change one thing at a time, then rerun the same case. That way you can attribute the improvement to an identified change.
Don't continue through the whole batch when the first result shows a major flaw. An error repeated across a hundred files also costs sorting time. Set a session limit and keep some time to retrieve the items that are already useful, even if the final decision is to stop the approach.
| Observation | Next check |
|---|---|
| The GPU is not recognized | Compatibility of the software, the driver, and its components. |
| The batch fails due to a lack of memory | A single file, then a smaller batch size. |
| The output is incorrect | Input, settings, and quality criteria. |
| The transfer fails | Destination, free space, and copy method. |
Finish with a copy and a decision
Keep the accepted outputs, the mapping to the inputs, the settings, and a short handover note. Compare the retrieved copy against the expected folder, then open several representative files from that copy. A preview left in the remote environment is not your archive.
Then write down what the test allowed you to decide: a usable method, a fix that's needed, or a need that is still unknown. The next rental can start from this note instead of beginning the discovery again. To pass the result on to a colleague, separate the deliverables from the technical files and specify what still needs to be validated.