At what monthly request volume does self-hosting an open-source LLM become cheaper than paying per-token API pricing in 2027?

What it is and why it matters

The question of when self-hosting beats per-token API pricing is fundamentally a utilization math problem, not a volume problem in the abstract. A single request to a 70B-parameter model might consume 800 input tokens and 400 output tokens, while a request to an 8B model might consume 300 tokens total. So "monthly request volume" only becomes meaningful once you fix an average token profile per request. For planning purposes in 2027, most teams should model a blended average of 1,000 to 2,500 tokens per request across their workload mix, then convert their request count into a monthly token throughput figure.

Why this matters now more than in earlier years: open-weight models have closed much of the quality gap on narrow, well-scoped tasks. A fine-tuned 8B or 14B model frequently matches a frontier API model on classification, extraction, routing, summarization of short documents, and structured output generation. When the task is narrow, the quality argument for paying frontier API prices evaporates, and the decision collapses to pure economics. That is the regime where self-hosting wins at surprisingly modest volumes.

The second reason it matters is that API pricing itself is not static. Per-token prices have fallen steadily, and 2027 pricing reflects further compression, especially for smaller and mid-tier models. This pushes the crossover volume upward compared to 2024-era analysis. A team that would have broken even at 15 million tokens per month in 2024 might need 60 million or more in 2027, because the API alternative got cheaper at the same time self-hosting costs stayed roughly flat or declined more slowly.

Third, the cost of self-hosting is dominated by fixed costs: GPU rental or purchase, engineering time, and operational overhead. Fixed costs do not scale with volume, which is exactly why the crossover exists. Once you are paying for the GPUs anyway, incremental tokens are nearly free. The entire question is whether your monthly token volume is high enough to amortize that fixed base below the equivalent API bill.

It is also worth being precise about what "cheaper" means. Total cost of ownership for self-hosting includes hardware or cloud GPU spend, electricity or egress, storage for weights and KV cache, load balancing, autoscaling infrastructure, monitoring, on-call engineering time, model update and re-evaluation cycles, and the opportunity cost of the engineers maintaining it. A naive comparison that only counts GPU hours against API token spend will systematically overstate the case for self-hosting. A disciplined comparison includes a realistic engineering overhead line, often 0.25 to 1.0 full-time engineer equivalents for a production deployment.

Finally, the decision is rarely all-or-nothing. Most mature teams in 2027 run a hybrid: a self-hosted small model for high-volume, low-complexity traffic, and an API for frontier reasoning, long-context, or low-volume high-stakes work. The crossover question then becomes "at what monthly request volume does it pay to move this specific workload class off the API," which is a much more tractable and more useful framing than a single global number.

The step-by-step process

To answer the crossover question for your own workload, work through a repeatable estimation process rather than reaching for a generic number. The steps below are the ones a RevOps or platform team can actually execute with data they already have.

Step 1: Profile your request mix. Pull 30 days of API logs. Bucket requests by model, by input token count, by output token count, and by task type. You will almost always find that 60-80% of requests are short, repetitive, and low-complexity, while a small tail drives most of the token spend.

Step 2: Compute monthly token throughput. Multiply requests per month by average total tokens per request, separately for each bucket. This gives you a token volume per workload class, which is the only unit that compares cleanly against both API pricing and GPU capacity.

Step 3: Estimate API cost per class. Apply 2027 per-token pricing for the model tier you would otherwise use. Include any prompt caching discounts, batch discounts, and committed-use discounts you actually qualify for. The discounted effective rate is what you must beat, not the list rate.

Step 4: Size the self-hosted alternative. Pick the smallest open-weight model that passes your quality bar. Estimate throughput per GPU for that model at your target context length. A useful planning figure: a single modern inference GPU can sustain roughly 1,500 to 4,000 output tokens per second on an 8B model at moderate batch sizes, and roughly 150 to 500 output tokens per second on a 70B model, depending on quantization and batching.

Step 5: Compute required GPU count. Divide peak sustained throughput by per-GPU throughput, then add headroom for burst, redundancy, and rolling upgrades. A common rule is to provision for 1.5x to 2x average load so that p95 latency stays acceptable.

Step 6: Price the fixed base. Multiply GPU count by monthly cost per GPU (cloud rental or amortized purchase plus power and cooling). Add storage, networking, and a realistic engineering overhead allocation.

Step 7: Solve for crossover. Set self-hosted monthly fixed cost equal to API cost per token times monthly tokens, and solve for tokens. Convert back to requests using your blended tokens-per-request figure.

The diagram below shows how these inputs flow into a single crossover decision.

A worked example makes this concrete. Suppose your blended average is 1,500 tokens per request and you serve 30 million requests per month, for 45 billion tokens. That is far above any plausible crossover, so self-hosting wins easily. Now suppose you serve 3 million requests per month at the same token profile, for 4.5 billion tokens. At an effective API rate of roughly $0.50 per million blended tokens, that is about $2,250 per month. A self-hosted 8B deployment with two GPUs, storage, and a quarter of an engineer's time will typically run well above that, so the API wins. The crossover sits in the gap between these two examples, and the exact point depends on your token profile and your engineering overhead assumption.

The practical takeaway from the process: do not ask "how many requests," ask "how many tokens per month, at what effective API rate, against what fixed self-hosting base." Requests are just the unit your product team thinks in; tokens are the unit the economics live in.

Costs, timelines, and typical ranges

The numbers below are planning ranges for 2027, expressed as ranges rather than point estimates because GPU pricing, model efficiency, and API rates all move. Use them to sanity-check your own model, not as a substitute for it.

API effective rates. For small and mid-tier models, effective blended rates after caching and batch discounts commonly land between $0.10 and $0.80 per million tokens. For frontier-tier models, effective rates are typically $3 to $15 per million tokens, with long-context and reasoning-heavy calls at the top of that range. The tier you would actually use for a given workload is the one that sets your crossover.

Self-hosted fixed base. A minimal production deployment of an 8B model on two cloud GPUs, with storage, load balancing, and monitoring, typically runs $2,000 to $6,000 per month before engineering. A 70B deployment with four to eight GPUs typically runs $8,000 to $30,000 per month before engineering. On-premise purchase changes the shape: capital cost up front, lower monthly run rate, but you carry utilization risk and refresh cycles.

Engineering overhead. Budget 0.25 to 1.0 full-time equivalents for a production self-hosted deployment. At a fully loaded cost of $200,000 to $300,000 per engineer per year, that is $4,000 to $25,000 per month of overhead. This line alone frequently decides the crossover, and it is the line teams most often omit.

Crossover ranges. Combining the above, the crossover for an 8B-class model against a cheap API tier typically falls between 40 million and 120 million tokens per month. For a 70B-class model against a mid-tier API, it typically falls between 150 million and 600 million tokens per month, because the fixed base is much larger. Expressed in requests at 1,500 tokens each, that is roughly 25,000 to 80,000 requests per month for the small model, and 100,000 to 400,000 requests per month for the large model.

Timeline to break even. If you are above the crossover, payback on the initial engineering investment is usually two to four months, because the monthly savings are large relative to the setup effort. If you are near the crossover, payback stretches past a year and the decision is genuinely marginal. If you are below it, there is no payback at any horizon.

Sensitivity. The crossover is most sensitive to three things: your effective API rate (a 2x discount doubles the crossover volume), your engineering overhead assumption (adding half an engineer can push the crossover up by 30-60%), and your utilization (running GPUs at 20% average utilization instead of 60% roughly triples the effective cost per token served).

Quality and latency costs. These do not appear in the dollar comparison but they are real. Self-hosting gives you control over latency, data residency, and model versioning. APIs give you access to frontier capability without maintenance. If your workload needs frontier reasoning even 5% of the time, a hybrid is usually cheaper than a pure self-hosted deployment sized for the frontier case.

Where teams get it wrong

The most common error is comparing list API prices against GPU rental rates and declaring victory. List prices are not what you pay. Prompt caching, batch endpoints, and committed-use discounts routinely cut effective rates by 50% or more on high-volume workloads. If you benchmark against list, you will self-host too early and then discover the API was cheaper all along.

The second error is ignoring engineering overhead entirely, or assuming it is a one-time cost. Self-hosting is a subscription to maintenance: model updates, security patches, dependency drift, capacity planning, incident response, and continuous evaluation. Teams that treat it as a one-time setup routinely find that month six costs more than month one, not less.

The third error is sizing for peak instead of for average plus headroom. Provisioning GPUs for your absolute worst-case burst means you pay for idle capacity 95% of the time, which destroys the economics. The right pattern is average-plus-headroom on dedicated capacity, with API overflow for bursts. This hybrid is usually cheaper than either pure option.

The fourth error is assuming a single crossover number applies to all workloads. Classification at 200 tokens per request and document analysis at 20,000 tokens per request have completely different crossovers. Treating them as one bucket leads to moving the wrong workload.

The fifth error is forgetting the switching cost. Migrating a workload to self-hosting means re-evaluating quality, rebuilding prompts, retuning, and running parallel for a period. That cost is real and should be amortized into the payback calculation. A workload that breaks even in month three on paper may not break even in month twelve once migration effort is counted.

The sixth error is underweighting quality regression. A smaller open-weight model that passes your offline eval may still fail on edge cases in production, generating support load or customer impact that never shows up in the token math. Always run a shadow period before cutting over.

The seventh error, and the most strategic one, is treating the decision as permanent. API prices fall, GPU prices change, and model efficiency improves. A workload that should stay on the API in 2027 may be worth revisiting in 2028. Build the comparison as a quarterly review rather than a one-time architecture decision.

Decision framework: when to choose what

Use the framework below to route each workload class to the right execution model. The inputs are the ones you computed in the step-by-step process: monthly token volume, effective API rate, quality requirements, and data constraints.

Reading the framework: the first gate is volume, because below crossover nothing else matters. The second gate is quality, because a cheap deployment that fails your bar is not cheaper in any meaningful sense. The third gate is constraint, because data residency and latency requirements can force self-hosting even below crossover, and that is a legitimate reason to pay a premium. The fourth gate is capability, because if you cannot staff the deployment, a managed open-weight endpoint is often the correct middle path. The fifth gate is load shape, because bursty traffic benefits from a hybrid that steady traffic does not need.

A practical way to apply this: list your top ten workload classes by monthly token volume. Run each through the framework. You will typically find two or three classes that clearly belong on self-hosted infrastructure, one or two that clearly belong on the API, and the rest in a gray zone that should be revisited each quarter as prices and model quality shift. This produces a portfolio decision rather than a single bet, which is far more robust to being wrong about any one input.

One more consideration for the framework: the crossover is not a cliff. Between roughly 0.5x and 2x of the crossover volume, the two options are within noise of each other once you account for uncertainty in your estimates. In that band, choose based on strategic factors — control, hiring plans, vendor concentration risk — rather than on the spreadsheet, because the spreadsheet is not precise enough to decide.

Related questions

Does request count or token count determine the crossover?

Token count determines it. Requests are only useful once multiplied by average tokens per request. Two teams with identical monthly request counts can have crossovers 5x apart if one serves short classification calls and the other serves long document analysis.

What is the crossover for a small open-weight model in 2027?

For an 8B-class model against a cheap API tier, plan on roughly 40 million to 120 million tokens per month, or about 25,000 to 80,000 requests at 1,500 tokens each. Below that, the API is almost always cheaper once engineering overhead is counted.

Does the crossover change if I already have GPUs?

Yes, dramatically. If GPUs are already paid for and idle, the marginal fixed cost of self-hosting drops to near zero, and the crossover can fall below 10 million tokens per month. Sunk hardware is the single biggest factor that moves the answer.

How often should I re-run the crossover calculation?

Quarterly at minimum. API prices, GPU rental rates, and open-weight model quality all move fast enough that an annual review will leave you on the wrong side of the decision for months at a time.

Can I self-host below the crossover and still be right?

Yes, when data residency, latency, or vendor concentration constraints apply. Those are legitimate reasons to pay a premium, but they should be stated explicitly rather than hidden inside a cost comparison that does not actually support the decision.

FAQ

At what monthly request volume does self-hosting an open-source LLM become cheaper than paying per-token API pricing in 2027?

There is no single request number, because requests vary in size. Convert to tokens first. For an 8B-class model, the crossover typically falls between 40 million and 120 million tokens per month. For a 70B-class model, it typically falls between 150 million and 600 million tokens per month. At a blended 1,500 tokens per request, that is roughly 25,000 to 80,000 requests per month for the small model and 100,000 to 400,000 for the large one. The exact point depends on your effective API rate, your engineering overhead, and your GPU utilization.

Why is the crossover higher in 2027 than it was a few years ago?

Because API prices fell faster than self-hosting costs. Effective per-token rates after caching and batch discounts dropped substantially, while GPU rental rates and engineering salaries stayed roughly flat or rose. The API side of the equation got cheaper, which pushes the break-even volume upward. A workload that justified self-hosting in 2024 may not justify it in 2027.

What is the biggest hidden cost in self-hosting?

Engineering overhead. A production deployment needs capacity planning, model updates, evaluation, incident response, and security patching. Budget 0.25 to 1.0 full-time equivalents, which is $4,000 to $25,000 per month fully loaded. Teams that omit this line consistently conclude self-hosting is cheaper than it actually is.

Does GPU utilization really change the answer that much?

Yes. Self-hosted cost per token is fixed cost divided by tokens served. Running GPUs at 20% average utilization instead of 60% roughly triples your effective cost per token, which can push the crossover up by 2-3x. This is why hybrid deployments with API overflow for bursts usually beat pure self-hosting.

Should I self-host everything above the crossover?

No. Route workload by workload. High-volume, low-complexity traffic belongs on self-hosted small models. Low-volume, high-complexity, or frontier-reasoning traffic usually belongs on the API even at high total volume, because sizing self-hosted capacity for the frontier case wastes GPU spend on the other 95% of traffic.

How do I know if my quality bar is met by an open-weight model?

Run a shadow evaluation on real production traffic, not a synthetic benchmark. Compare pass rates on your actual task, measure failure modes, and quantify the support or rework cost of errors. A model that is 2% worse on a benchmark may be materially worse on your specific edge cases, and that gap has a dollar cost that belongs in the comparison.

Sources

• NVIDIA — LLM Inference Performance and GPU Sizing
• Hugging Face — Open LLM Leaderboard
• vLLM — Documentation on Throughput and Batching
• AWS — EC2 GPU Instance Pricing
• Google Cloud — GPU Pricing
• OpenAI — API Pricing
• Anthropic — API Pricing
• Meta — Llama Model Cards
• MLCommons — MLPerf Inference Benchmarks

Related on PULSE

• How to build a token-based cost model for LLM workloads
• API versus self-hosted LLM: a quarterly decision review template
• GPU capacity planning for bursty inference traffic
• Evaluating open-weight models against your production quality bar
• Hybrid inference routing: when to overflow to an API
• Total cost of ownership for self-hosted LLM infrastructure