Nebius: GPU cloud infrastructure for training and inference

Nebius is an AI-focused cloud provider for teams that need GPU infrastructure and the services around it. Its practical appeal is access to an environment built around training and inference workloads, without first purchasing a data center’s equipment. The key decision is how much of the model operation the team wants to own. Renting GPU virtual machines and using managed model inference are different routes with different cost and maintenance responsibilities.

01 / ProductA specialist cloud, with infrastructure and managed service choices

Nebius provides GPU infrastructure, orchestration and managed services for AI training and inference. The company page identifies an Amsterdam-headquartered business listed on Nasdaq under NBIS, with a platform spanning data preparation, model training and production deployment. For engineering teams, the practical choice is how much of that stack to operate themselves and which managed services fit the workload.

The infrastructure route gives a team virtual machines and associated resources on which to run its chosen stack. The VM and GPU types describe available configurations and regional constraints. This makes the selected platform and region part of the application design. A GPU family appearing in the product portfolio does not guarantee that the desired quantity is available in every location.

Nebius also promotes Token Factory for managed inference. That route can remove parts of model-serving work, while a GPU VM gives the team more responsibility for software installation, model loading and operations. Keep those choices separate when comparing prices. A compute-hour table is not a per-token tariff for a hosted model endpoint, and the capabilities of one service do not automatically transfer to the other.

02 / AudienceA useful candidate when the workload needs real GPU ownership

A team fine-tuning an open-weight model is a concrete audience. It needs control over the dataset, training code, checkpoints and evaluation, but may not want to buy hardware for an uncertain schedule of experiments. Nebius is worth assessing when the team can define the GPU memory, storage and communication requirements of a representative run.

The fit is weaker when the actual need is a small application making occasional calls to a standard model. Operating a VM adds work that a managed endpoint may already handle. Even an experienced engineering team should distinguish a requirement to control the model runtime from a preference to choose the underlying GPU. The former can justify infrastructure ownership; the latter may not.

The CoreWeave blueprint provides another specialist cloud-infrastructure comparison. The Lambda blueprint is relevant for GPU access and model development. Use the same job, region requirements and storage assumptions across comparisons. A lower displayed hourly price is not a complete result if the job takes longer, fails more often or requires more operational work.

03 / WorkflowA proposed fine-tuning run with recoverable state

For this proposed pilot, choose one bounded fine-tuning job with a fixed dataset and an explicit quality evaluation. Freeze the training code, base-model identifier and data version. Keep a small reference run so that changes in output quality can be separated from infrastructure effects. The experiment should answer whether the platform can execute the intended job reliably and at an understandable total cost.

Select a supported VM configuration and region from the current documentation. Confirm account quota and capacity before scheduling dependent work. For a multi-GPU job, verify the memory and interconnect arrangement required by the framework. A successful single-device notebook is useful setup evidence, but it cannot establish the behavior of a distributed training job with synchronization and shared data access.

Prepare storage deliberately. Keep the source dataset and completed checkpoints on persistent resources appropriate to the job, and distinguish them from temporary working space. Test that a checkpoint can be read by a fresh instance before relying on it for recovery. An artifact that exists only on the machine doing the training does not provide a useful recovery path when that machine disappears.

Run the first job on regular capacity to establish a baseline. Record elapsed time, useful training progress, storage throughput and failures. Preserve the environment definition so that another engineer can reproduce it. The relevant cost is the completed, evaluated run, including setup and idle allocation, rather than the time the model spent in its busiest training step.

Only then test preemptible virtual machines if the workload can tolerate interruption. These resources can be stopped by the platform. Implement checkpointing and a restart procedure, then deliberately rehearse recovery in a test. A lower interruptible rate is useful only when the cost of lost work and recovery remains acceptable for the job.

Compare the resulting model with the reference evaluation, using the same data and criteria. Infrastructure success and model success are separate: a completed run can still produce an unsuitable model. Keep the trained artifact, configuration and evaluation results together, then remove the resources that are no longer needed. This makes the experiment reviewable and limits the amount of paid infrastructure left behind.

Before a larger run, repeat the most important checks at the intended scale. Data loading, checkpoint writes and communication can become bottlenecks that were invisible in a small experiment. Ask the platform team which metrics distinguish compute saturation from storage or network delays. That evidence is more useful for choosing capacity than a generic vendor throughput claim.

04 / PricingThe current compute tariff is only one part of the budget

An illustrative eight-GPU H100 allocation running for ten hours would have a compute subtotal of $308 at the listed regular rate: eight multiplied by ten multiplied by $3.85. This is arithmetic for that assumed allocation, not a quoted training cost or a promise that the job completes in ten hours. Add the actual storage and other chargeable resources before comparing the full experiment.

The pay-as-you-go billing guide explains the account’s usage-based commercial route. Keep account spending and resource state visible during a pilot, especially when several engineers can create workloads. A completed notebook does not necessarily mean its infrastructure has been stopped or deleted. Give one person responsibility for checking the final billable resource inventory.

The compute documentation says stopped VMs no longer incur compute-resource charges, while storage volumes are treated separately. This is an important distinction from deleting the whole environment. Retaining a checkpoint disk may be intentional, but the team should know what it costs and how long it will be kept. Do not apply another cloud provider’s stop-versus-delete behavior without checking Nebius’s rules.

For sustained capacity, obtain the applicable commercial proposal and compare it with measured usage. Any reservation changes the value of flexibility: a lower contracted rate can be poor value if the project cannot use the capacity. Keep managed inference charges separate from these VM assumptions, because an API workload needs its own model-specific cost and latency evaluation.

05 / DistinctionsThe distinction is a platform organized around AI compute

Nebius focuses its cloud offer on the needs of model teams rather than presenting GPUs as a small extension to an unrelated application suite. That can make its deployment and capacity discussions relevant to training and inference engineers. The benefit still has to be demonstrated for the intended workload, especially where regional requirements, data movement or existing cloud integrations determine the practical choice.

The availability of regular and interruptible routes provides another useful design decision. A development job that can resume from a checkpoint has different requirements from a user-facing service with a response-time commitment. Match each workload to the appropriate capacity behavior rather than treating the cheapest rate as the default for all AI work.

06 / QuestionsCapacity, recovery and data location need specific answers

The first open question is whether the required platform, quantity and region can be provisioned on the project’s schedule. Public documentation describes the service, while an actual allocation depends on account and capacity conditions. Confirm those details before making a training deadline dependent on them, and identify the alternative if the preferred configuration is unavailable.

The second is how the workload survives interruption and ordinary operational errors. Confirm the lifecycle of local disks, attached storage, credentials and checkpoints in the chosen configuration. Also determine who handles a failed distributed run outside office hours. A specialist cloud reduces the need to own hardware, but it does not remove the application team’s responsibility to protect its work and understand recovery.

07 / DecisionChoose Nebius with a reproducible job and complete cost record

Nebius deserves consideration when a model team needs cloud GPU infrastructure and can specify the environment it wants to operate. Start with a reproducible job, verify the region and capacity, and record the cost through cleanup. Expand when the completed workload and its recovery behavior justify the choice, rather than relying on a headline GPU price or a vendor comparison.