GPUs for your projects · crypto payment without KYC How to rent
English
Open the console
Environments / KERNODECK

Describe the expected preparation, then verify the environment you receive.

Choose a preparation based on the work to be performed and provide a precise description of its requirements. The label Ubuntu, PyTorch, Blender, or custom expresses your request; it does not certify that all your dependencies are actually installed. To get started smoothly, pair each requirement with an observable check.

1. Choose the starting point that matches the project

An Ubuntu base works when you know how to organize your software stack and describe its system dependencies. A PyTorch preparation lets you indicate the project's core framework. Blender indicates a need for creation or rendering. The custom preparation is useful when your application already has specific conditions that these labels describe poorly.

These choices do not automatically include your code, weights, data, or licenses. Write down what must be available, what you provide, and what you will verify at startup. The name of a preparation should not excuse you from checking the version actually running.

A good request is not about listing every known tool. Describe the useful path: read an input, load a resource, compute, then write a result. This helps distinguish a mandatory dependency from a convenience tool and diagnose the missing step.

Scroll the table to read all columns.
Choose a starting point without attributing any implicit guarantee to it
SetupRequirement to describeProject-specific check
UbuntuExpected version and essential system dependenciesYour program starts with the necessary libraries.
PyTorchPython, framework variant, and extensionsImport, computation on the backend, then a representative task.
BlenderVersion, extensions, related resources, and export formatOpened project and verified processing step.
CustomProcedure, versions, and reference filesEvery criterion in the preparation specification is checked.

2. Write a compact preparation brief

For a Python project, distinguish the system, the interpreter, the packages, and the application resources. Keep exact versions when a dependency requires them. When you accept a range, explain the check that will validate it. "Install the latest versions" is hard to match against a reference environment.

Teaching example: your project classifies images with a native extension. Your request states the Python version, the chosen PyTorch variant, the project reference, and the extension's prerequisites. It provides three authorized control images and describes the expected output format. It does not claim sufficient throughput or memory without a test.

The preparation brief can stay short: a README, a dependencies file, and a code reference are enough if the steps and accesses are clear. Keep tunable parameters in a separate file so that a new batch size does not turn the request into a different installation.

Illustrative form to fill in with your references
Goal: classify a small sample of images
Code: project repository and revision
Python: version required by the application
PyTorch: chosen version and CUDA or ROCm variant
Extensions: versions, source, and build prerequisites
Inputs: authorized sample and expected identifiers
Check: output by identifier, valid format, reproducible result
Provision of accesses: separate procedure, no secrets in this form

3. Review PyTorch-specific dependencies

Check the compute stack before multiplying packages. The official PyTorch selector lets you choose an installation for your platform. CUDA and ROCm are not two interchangeable names for the same binary. The main framework may work while a specialized operator or a project extension remains incompatible.

If an extension must be compiled, its build may require additional tools and libraries. The PyTorch documentation states that installing the torch package does not automatically provide the compilation toolchains needed for all extensions. State these prerequisites in the procedure; an install command that attempts to compile is not an anomaly to hide.

Plan three separate checks: framework import, a small computation on the device, and an operation using the extension. If the first two pass and the third fails, you have a more precise diagnosis than a plain "PyTorch doesn't work". Note the first complete error and the versions involved.

4. Choose how to describe the environment

For Python packages, a rebuild procedure with a virtual environment is often a simple foundation. It targets one interpreter and separates the project's dependencies. It does not describe the whole machine: keep system requirements in the README and do not present a copy of an installed directory as a portable procedure.

If your project already uses a container, provide its recipe, its reference, and the parameters essential to launching it. A tag can change; a digest reference identifies a given image more precisely. Updates must still be organized and the project revalidated. The container alone does not prove GPU access or the presence of your data.

Choose the mechanism you know how to maintain. A very complete image can hide unnecessary dependencies; too minimal a recipe can leave manual installs outside the brief. In both cases, the application check remains the point of comparison. These guidelines describe your preparation, without presuming how the service will provide an image.

5. Prepare notebooks and graphics projects

A notebook helps explore data and visualize output. Its file and the process that runs its cells are separate things, though: the variables from an old session are not a documented dependency. Before transferring, restart the kernel and run the cells in order; note the Python version used.

When the trial becomes a regular workload, prepare an entry point that does not require handling cells one by one. The guide dedicated to moving from notebook to script details this transformation. Your preparation request must identify the need for a notebook, without confusing the working interface with a successful control of the program.

For Blender or another graphics application, add the related assets, extensions and export procedure. A project that opens on your machine may depend on files stored elsewhere. Ask yourself how another machine will find each of them and what small result will verify the chain before the full workload.

6. Receive with criteria and a reviewed result

When the environment is provisioned, compare the observed versions with your spec sheet. Run the diagnostic, then the intended application case. For the three images in the example, check that each identifier has an output, that the categories are valid and that the generated files can be read back. A screen with no errors does not replace this review.

Keep the useful discrepancies: different version, missing extension, inaccessible input, output written elsewhere. Distinguish what prevents you from starting from what simply calls for a documentation update. To ask for help, include the order reference and a minimal excerpt; there is no need to send your entire corpus.

A preparation validated for the sample guarantees neither memory capacity nor the behavior of all future workloads. Then increase the volume with a defined objective and examine the first limit encountered. Finally, keep the corrected procedure: it becomes your reference for the next rental.

Your questions

Does the PyTorch preparation guarantee that my model is installed?

No. It expresses the desired framework. Specify the weights, dependencies, access rights and steps of your project, then verify the environment actually provisioned.

Can I request several applications in a custom preparation?

Describe the applications actually needed and their role in the same procedure. Avoid incompatible versions and associate each dependency with a check. The exact preparation terms must be confirmed for your request.

Does a container replace GPU verification?

No. The image reference describes part of the environment. Device access and application operation must be checked under the actual launch conditions.

What should I do if the versions received differ from my spec sheet?

Note the difference before modifying the environment. Check its impact on your minimal control and your application, then have the necessary preparation clarified. Do not change all dependencies at once without keeping a reference.