The true cost of self-hosting open-source voice AI: a break-even model for STT, LLM and TTS

Why self-hosting looks cheaper than it is

The comparison usually goes wrong because the two sides are quoted in different units. An API charges per minute of audio, per character spoken or per token, so you pay only for the calls you take. A GPU is rented per hour, and it costs the same whether it is carrying fifty calls or none. To compare them you need the cost of one call-minute, meaning one minute of a live call handled by the agent, on each side.

On your own GPU, that cost is the hourly price divided by 60, by the number of calls the card can carry at once, and by its utilisation. Utilisation is the share of that capacity your calls actually use over the month. It is the term most estimates leave out, and for live calls it is usually small, because calls arrive when people dial, not when the GPU is free.

Start with a GPU that is busy all the time. An AWS L4 at $0.805 an hour carrying 48 STT streams costs $0.805 ÷ (60 × 48) = $0.00028 per call-minute. An AWS L40S at $1.861 carrying 32 TTS streams costs $0.00097, and a Lambda H100 at $3.29 carrying 50 LLM sessions costs $0.00110. The STT and TTS stream counts come from NVIDIA's published tables. The LLM figure is a planning value inside Softcery's modelled range of 40 to 75 sessions per H100, and it is the least certain input here.

Those figures look tiny next to API prices of $0.0025 to $0.0048 a minute for streaming STT, $0.0135 to $0.036 for premium TTS and $0.0007 to $0.0052 for a small LLM. The catch is that no voice GPU is busy all the time. At 15% utilisation every self-hosted figure is multiplied by 1 ÷ 0.15, about 6.7, so the L40S's TTS minute becomes $0.0065 and the H100's LLM minute becomes $0.0073. Where those prices come from, and how they move with the commitment you sign, is covered in GPU prices for voice AI in the US and India.

Four formulas carry the rest of this page. Each section works one of them through with real prices, and the editable spreadsheet linked at the end lets you change every input.

cost per call-minute   g  = P / (60 x N x U)
utilisation            U  ~ 1 / (PAR x (1 + h))     at large scale, before N+1 spares
critical utilisation   U* = P / (60 x N x a)
break-even volume      M* = F / (a - g)

P   GPU price, $ per hour            N   concurrent streams or sessions per GPU
PAR peak-to-average ratio of calls   h   headroom above the peak (20%)
a   API price per call-minute        F   fixed monthly cost (people, tooling)

Utilisation comes from your call curve, not from the GPU

How busy a GPU can be is set by how uneven your call volume is across the week, not by the hardware. You have to size the fleet for the busiest hour plus some headroom, but the calls that pay for it arrive at the average rate. So utilisation is roughly 1 ÷ (peak-to-average ratio × (1 + headroom)), where the peak-to-average ratio is the busiest hour's concurrent calls divided by the weekly average.

For business-hours calling this page uses a ratio of 3.5. It comes from Softcery's worked example, in which a 500,000-minute month averages about 12 concurrent calls if spread over the whole day but about 43 if the calls fall in business hours (Softcery, 3 July 2026). With 20% headroom, the ceiling is 1 ÷ (3.5 × 1.2), or 24%.

Redundancy pulls it lower. You need at least one spare GPU per component, known as N+1, so that a failure does not drop live calls. At 1 million minutes a month, average concurrency is 1,000,000 ÷ 43,800 minutes = 22.8 calls, and the sized peak is 22.8 × 3.5 × 1.2 = 95.9. That needs 3 L4s for STT, 4 L40S cards for TTS and 3 H100s for the LLM, each including the spare, and utilisation lands at 15 to 18%. At 100,000 minutes the two-GPU minimum per component sits only 2 to 4% busy, which is why self-hosting at that volume is never a cost decision.

The curve is also the cheapest lever you have. Flattening the ratio from 3.5 to 2, for example with customers in several time zones or outbound campaigns moved into quiet hours, raises utilisation from about 22% to about 40%. At 10 million minutes a month that cuts the GPU bill by about 45%, as much as a large hardware discount. How to measure your own curve before committing is the first step in the guide to self-deploying open-source voice models.

Why TTS pays off first and the LLM last

The order in which the three components pay off depends on two things: how much the API charges for a call-minute, and how cheaply a GPU can produce the same minute. TTS scores well on both counts, while the LLM scores badly on both.

People cost more than GPUs below a few million minutes

The largest line in a self-hosted voice stack is usually the team, not the hardware. Softcery estimates that a dedicated inference team hired for the purpose costs "$300,000–500,000/year", whatever the call volume. Its crossover sits at about 1 million minutes a month on that assumption, and it notes that the crossover falls sharply if an existing team absorbs the work (Softcery).

Adding people turns critical utilisation into a break-even volume, M* = F ÷ (a − g): the fixed monthly cost divided by the saving on each minute. Charge half an engineer to a component and assume the GPU is 60% busy. A US engineer costs $135,980 × 1.4 = $190,372 a year once employment costs are loaded, so F is $7,932 a month. TTS saves $0.018 − $0.00162 = $0.01638 a minute, so it breaks even at 7,932 ÷ 0.01638 = about 484,000 minutes a month.

With an engineer in India at ₹25 lakh a year × 1.25, about $32,881, F falls to $1,370 and the same TTS break-even falls to about 84,000 minutes. The GPUs cost about the same in both countries, so the location of the team moves break-even far more than the location of the hardware.

By the same formula, STT against Deepgram breaks even at about 1.8 million minutes a month with a US team and 0.3 million with an India-cost team. Against AssemblyAI's cheaper $0.0025 it needs about 3.9 million and 0.67 million. The LLM against cached gpt-4.1-mini needs 16.7 million and 2.9 million at 60% utilisation, and never breaks even at 30%. Against nano-class models at $0.0013 it never breaks even, because the GPU minute costs more than the API minute at any utilisation a call curve allows.

Why published estimates of self-hosting cost disagree

Published figures range from a fraction of a cent a minute to several hundred thousand dollars a year, and most of the gap comes from what each source puts in the total, not from different GPU prices. Companies that sell GPU hosting tend to quote the GPU cost at a busy moment. Companies that sell APIs tend to quote the fully loaded cost, people included, at low utilisation. Both can be right about what they chose to count.

The table lists the sources this model drew on, with the interest each has in the answer. Sonex Labs is on it too: it sells speech and LLM APIs billed per character, per second of audio and per token (see Sonex's per-use speech and LLM prices), so a reader who self-hosts may be a customer it does not get. That is why every input on this page is sourced and editable.

What to do at your volume, and what the model leaves out

The scenarios point to three plain verdicts. Under about 300,000 minutes a month, use APIs for everything unless a regulator or customer requires the data to stay on your own hardware. Between about 0.3 and 3 million minutes, self-host TTS on reserved L40S-class GPUs, and STT too if your languages hold up, while the LLM stays on an API. Above 3 to 5 million minutes, self-host all three for the steady base load and send the LLM's overflow to an API.

That overflow pattern pays only for the LLM. Because speech GPUs cross their threshold at 5 to 14% busy, even the GPU that serves only the peak hour earns its keep, so the cheapest speech fleet covers the whole peak. For the LLM, a few GPUs for the base load plus the API for the rest comes out close to the all-API price, which is worth it only for latency, residency or a tuned model. The numbers, and how the same API doubles as a failover path, are in self-hosting the base load and bursting to an API.