Rent GPU Capacity or Buy a Server: Finding Local AI Break-Even

Choose the workload’s financial model, not a GPU

The question “rent GPU capacity or buy a server” often begins by comparing an hourly rate with a hardware price tag. That comparison is convenient but incomplete. Rental provides elasticity and transfers part of the operating risk to a provider. Ownership creates fixed costs, but every additional productive hour may become cheaper under a stable load.

The decision therefore depends less on the accelerator brand than on the workload profile: required GPU-hours per month, demand variability, memory capacity, acceptable queuing, failure handling and the cost of moving a project to another configuration.

The FinOps Foundation defines total cost of ownership as a comprehensive view that includes acquisition, management, support, communication, labour, downtime and other costs. This matters for an AI environment because the GPU is a visible line item, not the whole budget. A server also needs CPUs, memory, storage, networking, power, cooling, redundancy, monitoring and somebody who updates the driver before the update decides to revise the weekend plan.

Describe the workload first

Before calculating money, collect at least four weeks of telemetry on a rented or test environment. For each use case, record:

• actual GPU-hours and calendar availability hours;
• peak concurrent requests;
• input and output tokens or another unit of work;
• p50 and p95 response time, queue length and time-outs;
• the share of outputs accepted by users;
• idle time between batches;
• engineering hours spent on operations, fixes and quality evaluation.

A GPU may be booked for a whole month while producing value only a few hours per day. Conversely, a nightly accounting-document batch may fully use the accelerator for eight hours. Their average utilisation can look similar even though the rental and ownership requirements differ.

Public benchmarks establish a performance range but do not replace a test with the company’s model. MLPerf separates scenarios by workload behaviour and measures throughput and latency under defined quality requirements. The business implication is straightforward: compare the same model, quantisation, context length, batching policy and target SLA.

Full monthly cost of an owned server

Convert all ownership costs into a monthly figure. A simplified formula is:

`Owned monthly cost = (purchase price − residual value) / useful period + hosting + electricity + support + labour + failure reserve + licences`

The purchase price must include the full server, not only the GPU. Residual value is a conservative estimate of what can be recovered through resale or reuse. The useful period should reflect how long the hardware will remain useful for the selected models rather than the longest accounting schedule.

Power cannot be estimated from the GPU specification alone. NVIDIA, for example, lists 48 GB of memory and maximum power consumption of 350 W for the L40S, but a complete server includes other components and cooling losses. Measure real power on the intended workload, then add rack space, networking and backup power.

The failure reserve depends on business requirements. If a one-day interruption is acceptable, the company may rely on a replacement contract or temporary rental. A continuously available service needs a spare node, on-call support or an agreed external fallback. Do not price ownership as a single machine while treating rental as a ready-made resilient platform: both options must provide the same service level.

Full rental cost

Rental uses a different formula:

`Monthly rental cost = GPU hourly rate × billed hours + persistent resources + storage + traffic + capacity reservation + labour`

A billed hour is not necessarily a productive hour. Loading weights, warming up, indexing, gaps between jobs and failed runs all consume time. When an instance runs continuously for occasional requests, rental gradually becomes ownership without the box.

Check the billing increment, minimum term, stopped-disk cost, outbound traffic, snapshots and static addresses. Confirm whether the required GPU is guaranteed or available only when the provider has spare capacity. For confidential data, include protected connectivity, logging and provider assessment.

Selectel’s documentation, for example, describes fixed and custom cloud GPU server configurations and the need for correct NVIDIA drivers. Prices and availability change, so they belong in the model on the decision date rather than being copied from somebody else’s article. The same rule applies to every provider.

A model break-even point

The following is not a market quote. It is a worked example with explicit hypothetical assumptions.

Assume a complete server costs RUB 2.4 million. After 36 months, the company expects to reuse or sell it for RUB 300,000. The monthly depreciable amount is about RUB 58,300. Hosting, electricity, support, administrator labour and a failure reserve add another RUB 82,000 in the model. Total ownership cost is therefore about RUB 140,300 per month.

For rental, assume RUB 450 per GPU-hour plus RUB 20,000 in fixed monthly storage, network and operating expenses. The equality point is:

`(140,300 − 20,000) / 450 ≈ 267 GPU-hours per month`

That is roughly 37% of 730 calendar hours. At 120 billed hours, rental costs RUB 74,000 in the model versus RUB 140,300 for ownership. At 400 hours, rental reaches RUB 200,000 while ownership remains near RUB 140,300—until a second server or an additional support shift is required.

The result changes linearly with the hourly rate and non-linearly with resilience requirements. If the SLA requires two owned nodes, the fixed amount almost doubles. If rental capacity must be reserved in advance, part of its elasticity disappears. The spreadsheet should therefore include at least three scenarios: low, expected and peak demand.

Calculate cost per accepted outcome

FinOps recommends connecting technology spend to a measurable unit of value such as a request, transaction, customer or completed process. For AI, a useful unit may be an accepted answer, verified document, resolved support case or correctly completed agent step.

The comparison formula is:

`Cost per accepted outcome = full monthly cost / number of outputs that pass validation`

If a cheaper configuration produces more errors and requires manual rework, its GPU-hour price proves little. Include reviewer labour, the cost of false decisions and repeated runs. Buying a powerful server does not become economical merely because it produces answers quickly when nobody uses them.

Costs should also be allocated by use case. One platform may serve RAG, document extraction and nightly classification. Without tags, queues and ownership metrics, process owners see one bill and start optimising one another. The FinOps Foundation recommends allocating shared technology costs to products and business units through an agreed strategy supported by usage data.

When rental is usually more sensible

Rental often wins when:

• demand is unknown or changes quickly;
• the pilot may stop after several weeks;
• work runs in short batches;
• experiments require different GPU types;
• rapid launch matters more than procurement and installation;
• the company is not ready to operate its own resilience;
• data requirements permit the selected external environment.

For a pilot, rental buys both compute time and the right to make an inexpensive sizing mistake. That option matters because a server that turns out to be too small rarely scales through presentation skills.

When ownership begins to win

An owned server becomes a candidate after demand has remained stable for several months, growth is forecastable, the configuration has been validated, data requires local placement, and the team can operate both hardware and software. Ownership is particularly attractive when several coordinated workloads can fill a consistent base load.

High utilisation must not mean an endless queue. If p95 latency violates the SLA, one fully occupied GPU is economical only in a spreadsheet. Define acceptable latency first, then the required capacity and reserve, and only then compare cost.

A hybrid model is often more practical

There is a useful middle ground between renting everything and buying forever. A company can run stable base demand on its own server and rent capacity for peaks, re-indexing, experiments or disaster recovery—provided the data policy permits such movement.

The team can begin fully rented, collect telemetry, freeze the validated configuration and purchase capacity for the stable minimum. Recalculate the model quarterly: how GPU-hours changed, whether accepted-output rates moved, how much operations really cost and how often external fallback was used.

Executive takeaway

Do not approve a purchase from the GPU price alone and do not renew rental from a single invoice. Ask for one table with an equal SLA, three demand scenarios and cost per accepted business outcome. Show the break-even point, failure reserve and team hours separately.

A practical first step is to measure billed and productive GPU-hours for four weeks. When stable base demand clears the break-even point and does not hide the need for a second server, ownership has an economic case. While the workload profile keeps moving, rental is the price of flexibility, not evidence that the company has failed to “grow up” into its own hardware.