The questions before your first run.

Start from the model and the question you want to settle. Estimate the weights, then add the cache, activations and buffers for your run. An initial 3-day trial can be used to load the model, check dependencies and measure peak memory. Then compare the configurations with sufficient capacity: a newer card does not replace a protocol suited to your workload.

Rentals last 3, 7 or 30 days. You choose from 1 to 10 lots at checkout: one lot contains one card, except B200, which contains two. Three days suit a focused validation, seven days a series of variants and thirty days an organized campaign. Prepare your data and a recovery point before your compute starts, so you can devote the duration to your objective.

The price shown corresponds to one lot for the chosen duration, in USD. The order total multiplies this package by the number of lots. Stock indicates the available cards, or the lots of two cards for B200. For example, two B200 lots represent four GPUs: the lot price must not be multiplied a second time by two.

Choose the GPU, the duration, the number of lots and your environment preference: Ubuntu, PyTorch, Blender or another. Then create your account with your first name, last name, email and a password, or choose "I already have an account" to log in. Check the pre-filled details if you are logged in, then the summary. No identity document is requested.

Each card has its own memory. A distributed program must explicitly place its data or computations on multiple devices; two GPUs do not automatically make one large single GPU. Model duplication, layer distribution and training state sharding address different needs. Choose your strategy before ordering several lots.

Define the essential experiments, the optional variants and your stopping criterion. Get a small complete case working before launching the long lots. Keep the code revisions, parameters, measurements and a checkpoint that you have actually reloaded. Also allow time to check and export the results, so you don't reserve the whole period for compute alone.

IteraGPU requires neither an ID document nor a KYC identity verification procedure for rentals. Checkout nevertheless keeps your first name, last name and contact email. You choose an asset and its network, then make the transfer from your wallet. This path without identity checks does not mean that transactions on a public blockchain become anonymous.

The methods are BTC on Bitcoin, ETH on Ethereum, USDT and USDC on Ethereum, SOL on Solana, TRX and USDT on Tron, as well as LTC on Litecoin. Choose the asset/network pair shown in the order. For a token such as USDT, the name alone is not enough to identify the destination: the instructions distinguish between Ethereum and Tron.

The order keeps its total in USD. The instructions show an exact crypto amount, a rate and an expiry. Use the intention while it is still valid when you prepare the transfer. If it expires before you send, request new instructions from that order; the new amount corresponds to the rate obtained at that time.

After your transfer, click the button on the relevant intention. The message "Payment reported. Verification pending." indicates that the report has been recorded, and remains visible when you return. Settlement then goes through its verification. If you used an old intention, open it in the history and use its own button.

A confirmed crypto top-up funds your USD balance. Then open the rental order and choose settlement with the balance when it covers its amount. The top-up and the rental each keep their own reference, and the ledger lets you track the credit and then the debit. Merely recording a top-up does not add available funds.

Find the record in "My rentals", then in the list of orders. It shows the amount, the settlement and the provisioning stage separately. "Payment reported" corresponds to your declaration; "Paid" corresponds to a confirmed settlement. Then check the preparation status and the access information when it is provided.

Yes. You choose your code, your models, your dependencies and the workloads you run on the rented GPU. Prepare an environment whose versions and requirements you know. To switch hardware family, check the compatibility of your libraries and extensions before transposing a complete protocol.

The service does not inspect the content of your files, prompts or computations. You remain in control of your workloads and your results. Commercial tracking uses order and settlement information; this policy is not a promise of the absence of any technical data or of absolute anonymity.

The notebook gathers the hypotheses, environment versions, parameters and observations that you record in it. Use one entry per experimental question: for example, comparing two precisions at constant batch size or measuring the effect of context on the cache. A clear note links the configuration to the measurement and the conclusion; it does not confuse an estimate with an observed result.

Log in to IteraGPU with your account email and password to find your orders, your balance and your notebook. Logging out only closes the session. Data from a previous guest session may be kept when you sign up from that session, if it is still valid and not already linked. An identical email address is not enough to recover records from another browser. Download the summary of your orders to keep the useful references.

Keep the model, dataset, versions, input length and measurement rules constant. Change one variable at a time. Distinguish first runs from the stabilized state and also measure output quality, not just speed. Document failures: an exceeded memory peak is useful information for choosing the next configuration.

Note the order reference, the GPU model, the library versions and the steps that reproduce the problem. If possible, reduce the case to a representative input and state what was expected. In your private request, remove secrets and attach the useful messages as text; keep your business data and full files under your control.

No. It gives a baseline for parameter storage. The work adds other objects: activations and temporary allocations, gradients and optimizer states during training, and possibly a cache during generation. Prepare an estimate with the dimensions of your workload, then measure a representative trial.

It is a hypothesis calculated from your inputs and the items explicitly displayed. It helps to organize a selection; it guarantees neither that a model will load nor its speed. The dimensions, formats and overheads specific to your software may change the requirement. Keep the estimate with its date, then compare it with the measured peak.

Lower precision changes the trade-off between memory, computation and numerical behavior. Compare it on the same inputs using your quality criteria. Keep the weight format, the compute format and the library versions: their combination makes it possible to reproduce the chosen variant.

The program must distribute the work and, if necessary, the model states across devices. Multiple cards do not automatically become a single memory space. Choose your parallelism strategy based on the model, then record the peak on each GPU. The B200 bundle contains two GPUs; memory is still described per card.

First set the question, the metrics and the quality criterion. Keep the inputs, versions, parameters, measurement method and individual results. Explain what changes between the variants. If several elements change at the same time, you can compare the complete configurations, but you cannot attribute the difference to just one of those elements.

It controls some sources of randomness, not every execution difference. PyTorch does not guarantee full reproducibility across versions, platforms and devices. Document the seeds, the deterministic settings and the environment. Also define what you consider reproducible: exactly the same values, or a comparable result within an explained tolerance.