On-Premise AI Server: Build, Buy or Rent? A Three-Year Cost Model in Rupees
Own the steady load, rent the peaks, and never rent for data that cannot leave. That is the verdict, and for most Indian enterprises it comes out of one number: how many hours a year the GPUs are doing useful work.
Below roughly half of the hours at today's domestic cloud rates, renting is cheaper than owning. Above it, owning wins, and the gap widens fast. At hyperscaler rates, the crossover drops to a few hours in six. At subsidised national rates, owning never wins on cost at all, but those rates are not available to most enterprises. Many companies get this wrong in both directions: they buy a server for an assistant used in office hours, and they rent for batch work that would keep a machine busy all night.
This post builds a three-year cost model in rupees, shows where the crossover falls under three rental price points, tests which inputs move it, and gives a six-question decision procedure. Every number in the model is an illustrative input to replace with your own quotes, and the code runs. Two sources of caution: GPU rental prices in India vary by a factor of fifteen between routes, and the published figures disagree with each other, so use the model's structure and not my inputs.
What You Are Comparing: Four Ways to Get Inference Capacity
The question is broader than buy versus rent. Four routes are usually on the table.
Route | What you get | Who runs it | Typical commitment |
Build | Components you assemble into your own server | Your team | Capital spend plus the engineering time to integrate and support it |
Buy an appliance | A supplier-integrated server or workstation with support | Your team, with supplier help | Capital spend, a support contract and a delivery lead time |
Colocate | Your hardware, in a third-party data centre | Shared | Capital spend plus a monthly space and power fee |
Rent | Hourly or reserved GPUs from a cloud provider | The provider | Pay as you use, or a reserved term for a discount |
Building is the cheapest in components and the most expensive in people. For a company without hardware engineers, an integrated appliance with a support contract is usually worth its premium. Colocation suits companies without suitable space, power or cooling, and it keeps control of the hardware and the data. Renting is the most flexible and the least controlled.
The model below treats the first three as variations of one thing, owning, and compares them with renting. The differences between building, buying and colocating are mostly a matter of the support and facilities lines.
What India's GPU Rental Market Charges, and Why Sources Disagree
Rental prices are the input people most want and can least trust, so it is worth setting out what the public record shows. All figures below are dated snapshots from 2026 sources, excluding GST, and they change often.
Route | Published H100-class rate per GPU-hour | Notes |
IndiaAI compute portal, on demand | About 153 rupees, 117 on a twelve-month reservation | Read from the portal's calculator on 1 November 2026, with a subsidy of up to 40 percent after approval for eligible users |
IndiaAI headline averages | Reported between about 65 and 150 rupees | Different outlets quote different averages, and a minister cited an average of about 116 rupees per GPU-hour |
Domestic GPU clouds, on demand | About 217 to 250 rupees | Provider list prices in 2026, with spot offers lower |
Global hyperscalers, Indian regions | Roughly 850 to 1,050 rupees per GPU | Per-GPU equivalent when an eight-GPU instance is divided, a snapshot from mid-2026 |
The subsidised route has conditions. It is aimed at eligible Indian startups, researchers and public-interest projects, requires approval, and has queues, so an enterprise should not plan on it. The model uses three round rates to span the market: 100 rupees as a stand-in for the subsidised end, 250 for domestic cloud on demand and 900 for a hyperscaler.
The sources disagree because they measure different things: list prices against bid prices, before and after subsidy, a headline against a reserved rate, and per GPU against per instance. When you build your own comparison, ask each provider for a written quote for the exact GPU, the term and the support, and include the data transfer and storage charges.
There is no single price for a GPU-hour in India. There is a range spanning an order of magnitude, and the route you qualify for decides where you fall in it.
The Model: Inputs You Must Replace
The structure is simple. Owning has a mostly fixed cost: the hardware, the staff and the support. Energy is a small variable cost. Renting is almost entirely variable: pay for what you use.
def tco_owned(gpus, capex_per_gpu, years, kw_load, kw_idle, util, tariff, pue,
ops_pct, staff_per_year, residual_pct):
capex = gpus * capex_per_gpu
avg_kw = gpus * (kw_idle + (kw_load - kw_idle) * util) * pue
energy = avg_kw * 8760 * years * tariff
support = capex * ops_pct * years
staff = staff_per_year * years
residual = capex * residual_pct
return capex + energy + support + staff - residual
def tco_rent(gpu_equivalents, util, years, rate):
return gpu_equivalents * util * 8760 * years * rate
def breakeven(rate, gpus=8, **kw):
lo, hi = 0.0, 1.0
for _ in range(60):
mid = (lo + hi) / 2
owned = tco_owned(gpus=gpus, util=mid, **kw)
rented = tco_rent(gpus, mid, kw["years"], rate)
lo, hi = (mid, hi) if owned > rented else (lo, mid)
return (lo + hi) / 2
kw = dict(capex_per_gpu=3_000_000, years=3, kw_load=0.70, kw_idle=0.12, tariff=9.0,
pue=1.5, ops_pct=0.05, staff_per_year=1_800_000, residual_pct=0.20)
crore = lambda x: round(x / 1e7, 2)
print(crore(tco_owned(gpus=8, util=0.30, **kw))) # 2.9
print(crore(tco_rent(8, 0.30, 3, 250))) # 1.58
print(round(breakeven(250, **kw) * 100, 1)) # 56.1
The inputs are deliberately round and illustrative. Eight GPU-equivalents at 30 lakh rupees each, all in, including the server share, networking and installation. A three-year life. Each GPU drawing 0.70 kilowatts at load and 0.12 idle. A tariff of 9 rupees per kilowatt-hour and a power-usage effectiveness of 1.5 to cover cooling. Five percent of the purchase price per year for support and spares. A staff allowance of 18 lakh rupees a year, standing for a fraction of a few engineers. A residual value of 20 percent of the purchase price at the end. Both sides exclude GST, which a registered business generally recovers on both purchases and rentals.
The decomposition at 30 percent utilisation is the first lesson. Hardware is 2.40 crore rupees. Energy is 0.08. Support is 0.36. Staff is 0.54. Subtract the resale value of 0.48 and the three-year total is 2.90 crore. Electricity is under three percent of the total. Buyers who worry about the power bill are worrying about the wrong line.
Where Owning Beats Renting
Run the model at three utilisation levels against three rental rates, and the structure appears.
Utilisation | Owned, 8 GPUs, 3 years | Rent at 100 rupees | Rent at 250 rupees | Rent at 900 rupees |
10 percent | 2.87 crore | 0.21 crore | 0.53 crore | 1.89 crore |
30 percent | 2.90 crore | 0.63 crore | 1.58 crore | 5.68 crore |
60 percent | 2.95 crore | 1.26 crore | 3.15 crore | 11.35 crore |
The owned column barely moves, from 2.87 to 2.95, because almost everything in it is fixed. The rented columns grow in proportion to use. Where they cross is the break-even utilisation.
Rental rate per GPU-hour | Break-even utilisation | Reading |
100 rupees | Never, owning costs more even at full load | Subsidised or very cheap capacity beats owning on cost |
250 rupees | 56 percent | Owning wins only if the GPUs are busy more than half of all hours |
900 rupees | 15 percent | Against a hyperscaler, owning wins at modest utilisation |
At a domestic cloud rate, you need the hardware to be busy for more than half of every hour of every day for three years before buying wins. That is a high bar for a typical enterprise, and it is why many on-premise projects disappoint financially. At hyperscaler rates, the bar is far lower, which is why companies with steady workloads already inside a hyperscaler find the numbers favour moving them in-house.
Utilisation Is the Whole Argument, and It Is Usually Overestimated
The break-even is a statement about hours. The honest question is how many hours your workload will use.
An assistant used by staff in office hours, eight hours a day on five days, keeps the hardware busy for about 24 percent of the week at best, and the GPUs are rarely saturated even then. At 24 percent, renting at 250 rupees wins comfortably. Add a nightly job, say six hours of document indexing and evaluation on every night of the week, and the figure rises to about 49 percent, near the break-even.
Our earlier post on GPU utilisation reported that average GPU compute use across production clusters is about 5 percent, with the caveat that this is compute activity and not reclaimable capacity. That is a reminder that bought capacity tends to sit idle. Utilisation in a planning spreadsheet is a hope. Utilisation in an operating cluster is a measurement, and the second is usually lower.
Practical steps help. Estimate demand bottom-up: users, requests per user per day, tokens per request, and the hours of GPU time those add up to. Add the batch workloads you will genuinely run. Then discount the total, because forecasts of use run high. Use the model with the discounted figure.
The Hybrid: Own the Floor, Rent the Peak
Most real demand is not flat. There is a base load that runs all the time and a peak that occurs occasionally. Owning for the base and renting for the peak often beats either pure strategy.
Take a workload that needs 3 GPUs around the clock and 8 at peak, with the peak lasting 10 percent of the hours. At 250 rupees per hour, three options compare.
Strategy | Three-year cost | How it works |
Rent everything | 2.30 crore | Pay for 3 GPUs all hours, plus 5 more for 10 percent of hours |
Own 8 | 2.93 crore | Buy for the peak, so utilisation averages 44 percent |
Own 3, rent the peak | 1.80 crore | Buy for the base, rent 5 GPUs for 10 percent of hours |
The hybrid is the cheapest by a clear margin. Owning for the peak means paying for eight GPUs that are mostly idle, and renting everything means paying the rental premium on a base load that never stops. At the hyperscaler rate of 900 rupees the same comparison reads 8.28 crore for renting everything, 2.93 for owning eight and 2.65 for the hybrid, so owning the base wins again by a larger margin.
The hybrid has practical conditions. Your workload must be able to run on rented capacity at peak, which means the data involved can leave, or the peak is on a separate, less sensitive workload. Your software must run on both. And the rented capacity must be available when you need it, which is not guaranteed at a peak.
Owning for the peak buys idle hardware, and renting for the base pays a premium on hours that never stop. Own the floor, rent the ceiling.
What Moves the Answer Most
The break-even is more sensitive to some inputs than others. Varying each input one at a time at the 250-rupee rental rate, from a baseline of 56 percent, gives this.
Input changed | Break-even utilisation | Effect |
Purchase price 30 percent lower | 43 percent | Large, buying cheaper moves the line a long way |
Purchase price 30 percent higher | 70 percent | Large, in the other direction |
Resale value 0 percent | 66 percent | Large, a worthless end-of-life value hurts |
Resale value 40 percent | 47 percent | Large, a good one helps |
Useful life 4 years instead of 3 | 47 percent | Large, longer life spreads the capital |
Staff cost 9 lakh a year | 51 percent | Moderate |
Staff cost 27 lakh a year | 61 percent | Moderate |
Electricity at 6 rupees | 55 percent | Tiny |
Electricity at 12 rupees | 57 percent | Tiny |
Cooling overhead, power-usage effectiveness 2.0 | 57 percent | Tiny |
Three inputs dominate: the purchase price, the resale value and the life. These are also the inputs most uncertain, because GPU prices move sharply, resale markets for AI hardware are thin and new generations arrive every year or so. Spend your effort on those three, and do not agonise over the tariff.
The practical consequences are worth stating. Negotiate the purchase price and the support terms hard, since a 30 percent difference moves the break-even by about 13 points. Ask what a supplier will pay for the hardware back at the end of the term, in writing, and ask what upgrade or trade-in programme exists. And plan for a longer life where you can: a server that stays useful for four years has a materially lower cost per year.
Colocation: Your Hardware in Someone Else's Building
Many companies want to own the GPUs and cannot host them. The office has no spare circuit, the server room cannot take another few kilowatts of heat, or the building's power is not trustworthy. Colocation puts your own hardware in a data centre that sells space, power and cooling.
The cost model changes in one place. The support and facilities lines grow by a monthly fee, usually quoted per kilowatt or per rack, and your own energy and cooling lines shrink, because the facility meters and bills them. The capital cost stays yours.
Colocation item | What to ask | A common surprise |
Power per rack | The committed kilowatts and what happens above them | Dense GPU servers can exceed a standard rack's power and cooling allowance |
Cooling | Whether the facility can remove the heat density you bring | Air cooling limits, with liquid cooling an extra |
Remote hands | Who swaps a failed part at night, and at what charge | Hourly fees and response times that were not in the headline price |
Network | Bandwidth, cross-connects and latency to your offices | Cross-connect fees added monthly |
Security and access | Cages, access logs, escorted visits | Visit restrictions that slow repairs |
Data location and contract | Where the hardware sits and what jurisdiction applies | Residency clauses that matter for regulated data |
Colocation keeps the data on hardware you control, which is why it suits regulated workloads. It adds an operating cost that the break-even model should include, and it suits steady workloads best, because the monthly fee is fixed.
Accounting for the Purchase: Capital, Lease or Rental
The way a purchase is paid for changes the cash flow, and often the decision. Three arrangements are common.
An outright purchase puts the full cost up front and builds an asset that depreciates. A lease or hire-purchase spreads the payments over the term and may include maintenance. A rental or cloud service is an operating expense with no asset. Each treats tax and the balance sheet differently, and the rules on depreciation rates, the recovery of GST on purchases, and the treatment of leases are specific to your company and your accountant.
Two practical points are worth raising with a chartered accountant before the decision. First, whether GST on the hardware and on rental charges is fully recoverable in your case, since the model assumes it is on both sides. Second, how the depreciation of computing equipment is treated for tax, which changes the effective cost of owning.
If cash is the constraint and not cost, leasing the hardware changes the comparison, because a lease payment is a form of rental with an end-of-term option. The model still applies if you replace the capital cost with the lease payments over the term.
Costs the Spreadsheet Forgets
A model with eleven inputs leaves out items that decide real projects. List them before you decide.
Often missed | Why it matters | How to include it |
Power and cooling capacity | A room may need a new circuit, a larger UPS or extra cooling before the server can run | Ask facilities for a written estimate |
Rack space and networking | Switches, cabling and ports for a high-bandwidth cluster are not free | Add to capital cost |
Software licences | Some enterprise AI software and management tools are licensed per GPU or per server | Request quotes per year |
Spares and downtime | One failed component can stop the service for days without spares | Hold critical spares, or buy a support contract with fast replacement |
Procurement lead time | Delivery can take months, and the project waits | Plan the date, or rent while waiting |
Security review and compliance | Audits and assessments of a new system take staff time | Add staff weeks |
Obsolescence | A new generation may make the hardware look expensive within a year | Reflect in the resale assumption |
Insurance and import duty | Hardware carries insurance, and duty and freight apply to imported items | Ask the supplier for a landed price |
None of these changes the structure of the argument. They add to the owned side, which pushes the break-even higher. A careful estimate of them often shifts a marginal case from owning to renting, so include them before you commit.
Reasons That Override the Spreadsheet
Cost is only one of the reasons to own. Four non-cost reasons can settle the question before the model is opened.
Data control is the first. If regulation, contract or policy says the data must not leave your premises, renting from a cloud is not an option for that workload, however cheap. The earlier posts in this series on sovereign AI and on air-gapped deployment set out the levels of control. The model then answers a different question: whether to own the hardware yourself or to colocate it.
Latency is the second. Workloads that sit next to a factory floor, a camera network or a secure facility may not tolerate a round trip to a remote data centre.
Capacity certainty is the third. A project that cannot fail for lack of GPUs on a given day may prefer owned capacity over a rental that depends on availability, particularly in periods of shortage.
And strategy is the fourth. Owning builds a skill set inside the company, in operating inference systems, that a rented service does not, and for companies whose product is the service, that skill may be the point.
Questions to Put to a Vendor Before You Buy
A quote is a list of assumptions. These questions reveal them.
Question | Why it matters | A good answer |
Which GPU, how much memory per GPU, and what interconnect | Memory sets which models run | Exact model names and capacities in writing |
What is the all-in landed price, including duty, installation and GST treatment | The headline hides extras | A line-by-line quote |
What support level, what response time and where are spares held | Downtime costs money | Named response times, local spares |
What is the delivery lead time and is it contractual | Projects wait | A date with a remedy if missed |
What power and cooling does it need | Facilities may need upgrades | Peak and typical figures |
Which software is included and which is licensed | Hidden annual fees | A list with prices |
What buy-back or trade-in is offered | Sets the resale assumption | A written formula or a stated percentage |
Renting Well: Terms That Matter
If you rent, the contract decides much of the cost, and several terms are easy to miss.
Look at data egress and storage charges, which can double a bill for data-heavy work. Look at where the data sits and who can access it, since residency commitments should be in the contract. Compare on-demand with reserved rates: a twelve-month reservation can cut the hourly rate substantially, with the risk that you pay for hours you do not use. Check what GPU you will actually receive, since a cheaper plan may use older or shared hardware. Ask about availability guarantees at peak. And read the termination and data-deletion terms, because getting out cleanly matters as much as getting in.
For the subsidised national route, read the eligibility conditions and the approval timeline. It can be excellent value for those who qualify, and it is a poor plan for those who do not.
A Composite: Two Teams, Same Workload, Different Answers
This is a representative composite, genericised, from several enterprise discussions. The numbers are illustrative.
Two companies each wanted a private assistant for internal documents, using the same type of model.
The first was a design studio with sixty users in one office. Usage was concentrated between ten and six on weekdays, and the data was moderately sensitive but not regulated. Demand estimated bottom-up came to about 24 percent of hours. At a domestic cloud rate of 250 rupees an hour, renting cost roughly 40 percent of the cost of owning over three years. They rented, in an Indian region, with a contract clause on data deletion and residency.
The second was a lender with a regulated document workload. In addition to interactive use, it ran nightly document classification and a continuous batch of scoring jobs. Demand came to about 62 percent of hours across the week, and the data could not leave the company's premises under its own policy. Owning cost less than renting at that utilisation even at the domestic cloud rate, and policy made the choice for them. They bought, with a support contract and a spare.
The lender's first year had a surprise. Utilisation measured in operation was 38 percent, not 62, because the batch jobs took longer to arrive than planned. At 38 percent, owning was no longer cheaper than domestic rental on cost alone. The decision still stood, because policy required it, but the finance review recorded that the business case had overestimated utilisation, and added the nightly jobs that raised it.
The lesson both companies recorded was to measure utilisation monthly from the first week and compare it with the model's assumption.
Pricing Your Own Case in an Afternoon
The model is only useful with your numbers in it. An afternoon is enough to fill it in honestly, if the right people supply each input.
Input | Where to get it | Who owns it |
Number and type of GPUs | A sizing exercise from the model and context length you need | Engineering |
Purchase price, all-in | Written quotes from two suppliers, including installation and landed cost | Procurement |
Useful life and resale value | The supplier's buy-back terms, plus your own judgement on obsolescence | Procurement and finance |
Power draw at load and idle | Datasheets, confirmed by a short test on a rented machine of the same class | Engineering |
Electricity tariff and cooling overhead | Your last twelve months of bills, and the facilities team's view | Facilities |
Support and spares | The supplier's contract terms | Procurement |
Staff time | A candid estimate of the fraction of each engineer's year | Engineering manager |
Rental rates | Written quotes for the exact GPU and term, at two or three providers | Procurement |
Utilisation | A bottom-up demand estimate, then discounted | Engineering and the business owner |
Fill the table first, then the model, and then run three scenarios: your honest utilisation, a pessimistic one at two thirds of it, and an optimistic one at one and a third. If owning wins in the pessimistic case, the decision is safe. If it loses there, the decision depends on a forecast, and the forecast deserves scrutiny.
Write one page for the decision-maker. It should hold the three results, the crossover utilisation, the non-cost reasons, and the three inputs that matter most, with the date on which each will be re-checked.
If the decision survives the pessimistic utilisation case, it is robust. If it needs the optimistic one, it is a bet, and the bet should be stated as such.
A Decision Procedure in Six Questions
Can the data leave? If not, the question is own or colocate, and the model decides between them.
What is the honest utilisation? Estimate bottom-up, then discount it.
What rental rate are you truly eligible for? Ask for written quotes for the exact GPU and term.
Where does the crossover fall for your inputs? Run the model, then vary purchase price, resale value and life.
Is the load flat or peaky? If peaky, price the hybrid.
What do the costs the spreadsheet forgets add? Include them before the final comparison.
Growth, Refresh and What Year Three Looks Like
The model ends at three years, and the business does not. Plan the path beyond it.
If demand grows, add capacity in steps, and decide in advance whether additions are bought or rented. A common pattern is to own the steady base, add owned units only when measured utilisation stays above the crossover for several months, and use rented capacity to absorb growth in between.
Hardware refresh is the other decision. A new generation of accelerators arrives roughly every year, with step changes in memory and speed. A three-year-old server still works, and it may also be the most expensive way to run next year's models. Decide at purchase what happens at the end of the term: extend with a support contract, trade in, or replace. The resale assumption in the model is a promise to yourself that someone will buy the old hardware, so ask the supplier to commit to it.
Finally, schedule a review. Compare actual utilisation, cost and incidents with the model every quarter, and revisit the decision each year. A cost model is a living document, and the discipline of updating it is worth more than any single result.
The most expensive hardware in a company is the machine nobody reviews. Put a date in the diary to compare the model with the meter.
The Hours Decide
The verdict at the top rested on one number. Own the steady load, rent the peaks and keep sensitive data inside. The model's structure shows why: a mostly fixed cost against a mostly variable one, so the hours decide.
Replace the inputs with your own quotes. Measure utilisation from the first week and compare it with your forecast. Revisit the decision when prices move, because they will.
Related service: On-Premise LLM and AI Servers
Related reading: GPU Utilisation Explained: Why Clusters Sit at 5 Percent and How MIG and Time-Slicing Help, Sovereign AI Infrastructure Explained for Indian Enterprises: What You Can Control and Local LLM Hardware Requirements: How Much VRAM and Memory Bandwidth You Need.
EurthTech is an engineering-first product design and embedded systems company with a development center in Hyderabad. To discuss a project, write to connect@eurthtech.com or see https://www.eurthtech.com/case-studies.
Comments