In-House Deployment or API: Where the Break-Even Point Lies

How the calculation works

Two columns are compared at the same volume. On the left, payment per token at the provider's price list. On the right, GPU rental for an open-weights model plus the people who maintain it.

Volume is assembled from two figures. How many requests pass through in a day and how many tokens an average request weighs. That weight includes the prompt, the context pulled in by search and the model's answer. A month is taken as 30.4 days.

The API bill is volume multiplied by the price of a thousand tokens. It is linear. Flow doubles — the bill doubles, and that is exactly the behaviour that usually prompts the calculation in the first place.

The in-house side behaves differently. A server costs the same at any utilisation. The calculation assumes 95,000 RUB per month per card — the median of public GPU instance rental prices, taken in the summer of 2026. Support adds between 36,000 and 120,000 RUB depending on who is on call.

Where the break-even point falls

The break-even point is the volume at which the columns are equal. The monthly cost of the deployment is divided by the price of a thousand tokens, and the result is converted into requests per day. Below that mark it is cheaper to pay the provider. Above it — to run your own.

The strongest lever on the threshold is the token price. A cheap provider model raises the bar several times over, and owned hardware only starts paying for itself at large volumes. An expensive model drops the bar to hundreds of requests a day.

The second strongest factor is request weight. A setup with long context easily reaches 20–40 thousand tokens per call. The threshold in number of requests then falls proportionally, even though the number of people at screens does not change.

Hardware utilisation

The difference in money is half the answer. The other half is whether the chosen configuration can carry the flow.

The estimated capacity of one card is taken as 900 million tokens per month. The figure comes from two assumptions: 2,500 tokens per second of sustained speed with batching and 100 hours of real load per month. Both can be checked on a given model in a single day of measurements.

The utilisation figure in the breakdown answers a practical question. Up to 60% — there is headroom and peaks pass unnoticed. From 80% — a queue builds during rush hour, and the next step is to add a card. The cost of the deployment then rises in a step, and the threshold shifts upward.

What makes an in-house deployment pay off

There are four conditions, and they compound.

Flow is stable and predictable. The hardware is paid for in full even during a quiet week, so a steady load beats rare spikes.

Tasks are uniform. Sorting incoming mail, extracting fields from invoices, classifying enquiries, template-based draft replies — on that class of work, open 8–32B models stay close to external ones.

Data has to stay inside. A requirement from a regulator or a security team removes the comparison question entirely: what gets calculated then is not the saving but the minimum configuration that covers the volume.

Someone is there to be on call. A model in your own perimeter is a service with updates, monitoring and night-time outages. With no one on call, the saving from the calculation turns into downtime.

The hybrid scheme

The choice is rarely binary. Bulk uniform flow moves to the in-house model, rare complex requests stay with the external one. The threshold is then calculated for the portion of the flow that is due to be moved.

That scheme brings one more advantage. The external model stays as a hot standby: if the deployment goes down, traffic switches back and the process keeps working.

What was left out

One-off investments. Deployment, quantisation, a run on in-house data, logging and monitoring setup — those are weeks of work, and they do not average out into a price list.

Quality. An open 14B model falls short of a top external one on long reasoning chains. That has to be measured before the move: a hundred real requests, labelled in advance, shows the gap more honestly than any benchmark.

An owned rack. If cards are bought rather than rented, depreciation, electricity, cooling and a spare unit in case of failure are added to the calculation. The order of magnitude shifts; the logic of the comparison stays the same.