DeepInfra Pricing 2026: Inference API Cost vs Renting GPUs

DeepInfra runs one of the simplest tier systems of any inference API we've priced in this series: Flex at 0.8x, Standard at 1x, Priority at 1.5x, a flat, symmetric spread with no model-specific exceptions. Per-token rates on the platform span roughly 140x, from $0.02 per 1M input tokens on Llama 3.1 8B up to $2.85 per 1M input tokens on Kimi-K3 (DeepInfra pricing). DeepInfra also sells the underlying hardware directly: dedicated GPU-hour rentals from $0.89/hr for an A100 up to $4.89/hr for a B300, no token metering at all.

That combination is what makes DeepInfra worth a dedicated breakdown. Most serverless APIs give you one comparison to make: per-token billing against a self-hosted deployment on rented GPUs. DeepInfra gives you two, because its dedicated GPU-hour rate is a real, published number you can put next to any GPU marketplace's live rate. We'll work through both: the full per-token rate table and tier system, then the GPU-hour side, then the crossover math that tells you which one actually saves money for your workload.

DeepInfra Pricing: Per-Token Rates Across Popular Open Models

DeepInfra prices each model individually rather than bucketing by parameter count, so the rate table below is the real per-model reference, not a size-tier approximation.

Cheapest to Most Expensive: The Full 2026 Rate Table

Source: DeepInfra pricing and DeepInfra models catalog. That's roughly a 140x spread on input pricing alone, and the gap widens further on output: Kimi-K3's $14.25/1M output rate is over 44x Llama 3.3 70B's $0.32/1M. If you're building on DeepInfra and haven't pinned down which model tier your workload actually needs, that spread is the single biggest lever on your bill, well ahead of tier selection or caching.

Flagship and Reasoning Models Cost the Most

The most expensive models on the catalog aren't accidents of pricing, they're the platform's largest and most capable checkpoints. Kimi-K3, a 2.8-trillion-parameter open-weight model, tops the list at $2.85 input / $14.25 output per 1M tokens (DeepInfra models). DeepSeek-V4-Pro and Qwen3-Max sit a tier below that, both in the $1.20-$1.30 input range but with meaningfully different output pricing, $2.60/1M for DeepSeek-V4-Pro versus $6.00/1M for Qwen3-Max. GLM-5.2 and the Kimi-K2.x line cluster in between, all with output pricing 3x to 5x their input rate.

Notice the pattern: input-to-output ratios widen as models move toward reasoning and agentic use cases. Llama 3.3 70B's output is 3.2x its input rate; Kimi-K3's is exactly 5x. If your workload generates long completions, chain-of-thought traces, tool-call sequences, multi-turn agent loops, the output multiplier matters more than the headline input price, and it's easy to underestimate a bill by pricing off the input number alone.

Embeddings, Image Generation, and Audio Are Priced Separately

Everything above is text-generation LLM pricing. DeepInfra also runs embedding models, image generation, and audio models on its own separate rate cards, priced per embedding request, per image, or per audio minute rather than per text token. If your stack pairs an LLM with a retrieval pipeline or a voice front end, budget those as distinct line items rather than folding them into a token-cost estimate; the per-token math in this post applies to text generation only.

Service Tiers: Flex, Standard, and Priority Explained

The short version: DeepInfra runs three service tiers on top of the base per-token rate, and the spread between them is fixed and simple: Flex costs 0.8x (a flat 20% discount) for best-effort, latency-tolerant requests, Standard is the 1x default, and Priority costs 1.5x for traffic that needs to skip the queue (DeepInfra: Flex service tier). That's the widest and most symmetric tier spread we've documented in this pricing series, and there's no model-specific variance in the multiplier the way Fireworks' Standard-to-Priority premium varies by model.

Flex (0.8x): Cheaper, Patient, Best-Effort

You enable Flex with one field on an OpenAI-compatible request: service_tier: "flex" on /v1/chat/completions or /v1/completions (DeepInfra: Flex service tier). A Flex request waits up to 10 minutes for spare capacity to free up. If it gets served, you pay 0.8x the standard rate. If it times out unserved, you're charged nothing at all, the request returns an HTTP 429 and the token cost never hits your invoice. That's a meaningfully different risk profile than a flat discount: you're not trading latency for a guaranteed lower price, you're trading latency for either a lower price or a free non-answer.

That makes Flex the right default for anything asynchronous or evaluation-shaped: nightly batch scoring, offline classification runs, dataset labeling, model evals where a 10-minute wait costs nothing and a dropped request just gets retried. It's the wrong choice for anything user-facing with a latency budget under 10 minutes, obviously, since a live chat response can't wait that long even in the best case.

Priority (1.5x): Pay More to Skip the Queue

Priority does the opposite: service_tier: "priority" costs 1.5x the Standard rate and queues your requests ahead of Standard traffic, protecting admission under load (DeepInfra pricing). This is the lever for latency-critical production traffic during peak hours, when shared-tenancy contention would otherwise show up as tail latency spikes on the default tier. It's the same trade every "skip the line" pricing lever makes across this space, Fireworks' Priority tier and Groq's performance tier both do a version of it, just at DeepInfra's flat 1.5x instead of a model-dependent multiplier.

Run the math before defaulting to Priority for everything: a 1.5x multiplier on a $1.30/1M input flagship model like DeepSeek-V4-Pro adds up fast at volume. Reserve it for the slice of traffic that actually has a hard SLA, not the whole workload.

Cached Input Discounts Stack on Top of Tier Pricing

Cached input pricing is a separate discount from the tier system, and it's steep on the models that publish it: DeepSeek-V4-Pro's cached input runs $0.10/1M against a $1.30/1M standard input rate, roughly 92% off. Qwen3-Max's cached rate is $0.24/1M against $1.20/1M standard, an 80% discount. Kimi-K3 caches at $0.285/1M against $2.85/1M standard, also 90% off (DeepInfra pricing). For any workload with a stable system prompt, a repeated tool schema, or a RAG pipeline resending the same retrieved context on every call, cache hit rate on that fixed prefix is a bigger lever on your bill than which tier you're on. Check whether your client library sends prompts in a cache-friendly order (fixed prefix first, variable content last) before assuming the discount applies automatically.

DeepInfra Pricing for Dedicated GPU Rental (A100 to B300)

Past the per-token API, DeepInfra sells the hardware itself. Dedicated deployments are billed per GPU-hour, not per token, and the rate card runs from entry-level to current-generation Blackwell parts:

Source: DeepInfra pricing. This is the model to reach for when you need a fine-tuned checkpoint served, a model outside DeepInfra's serverless catalog, or full control over batch size and quantization that a shared serverless tier won't give you. But it comes with the standard dedicated-GPU catch: you pay for uptime, not usage. DeepInfra's own docs put it plainly: "you pay for the time your GPUs are running, regardless of traffic," and give a concrete cautionary example: forgetting to shut down a 2-GPU deployment over a weekend (64 hours) costs roughly $256 (DeepInfra private model deployment docs). That's not a hypothetical, it's the exact failure mode every dedicated-GPU platform warns about, set spending limits before you spin one up.

Here's how that rate card compares against Spheron's live on-demand pricing, fetched the same day this post published:

Spheron rates are live on-demand minimums fetched from the Spheron GPU offers API on 17 Aug 2026. Unlike some of the other API providers we've priced in this series, where the provider's own GPU rental turned out to be marked up several times over a marketplace rate, DeepInfra's dedicated tier is genuinely competitive at today's snapshot. GPU rental pricing moves with regional supply and demand on both platforms, capacity in one region or provider tightens and rates rise, capacity opens up elsewhere and rates fall, so this comparison is a snapshot, not a standing fact. Spheron's model is a marketplace aggregating live capacity from 5+ providers rather than a single vertically-integrated fleet, which is the reason to check it before committing to a single vendor's dedicated tier: if the provider behind today's cheapest offer tightens capacity tomorrow, the marketplace has other supply to route to instead of leaving you stuck on one operator's price. Run your own numbers against both before committing capacity, and bill granularity matters too: Spheron bills per minute with no commitment, while a dedicated DeepInfra GPU-hour deployment bills for the full time it's running, whether or not a request ever hits it.

Pricing fluctuates based on GPU availability. The prices above are based on 17 Aug 2026 and may have changed. Check current GPU pricing → for live rates.

The Volume Point Where Renting Your Own GPUs Gets Cheaper

The short version: for a cheap, high-volume model like Llama 3.3 70B, there isn't a realistic crossover point today. DeepInfra's $0.10/$0.32 per 1M blended rate is low enough that self-hosting on a rented H100, even a well-optimized deployment, would need throughput far beyond what a single GPU can produce to break even at current GPU rental prices. The case for self-hosting shows up elsewhere: pricier flagship models, fine-tuned checkpoints, or control DeepInfra's catalog doesn't offer.

The Cost-Per-Million-Tokens Math on Llama 3.3 70B

Blend DeepInfra's Llama-3.3-70B-Instruct-Turbo rate at a typical 80/20 input-heavy split: $0.10 x 0.8 + $0.32 x 0.2 = $0.144 per 1M tokens. At a more output-heavy 60/40 split, that climbs to $0.188 per 1M (DeepInfra pricing). We use the same cost-per-million (CPM) framework across this pricing series, CPM = ($/hr) / (tokens/sec × 3600) × 1,000,000, laid out in our inference cost economics playbook.

On the self-hosted side, take Spheron's live H100 SXM5 on-demand rate of $3.94/hr (per-GPU minimum, fetched 17 Aug 2026) and run the same CPM formula across three throughput scenarios:

Even the most aggressive throughput figure we've measured for Llama 3.3 70B on a single H100 SXM5, the 2,200-2,400 tok/s range from our continuous batching and PagedAttention benchmarks, lands around $0.48/1M tokens, still roughly 2.5x to 3x above DeepInfra's $0.144-$0.188/1M blended rate. Closing that gap would require single-GPU throughput north of 7,600 tok/s at the cheaper $0.144/1M blend, or north of 5,800 tok/s at the pricier $0.188/1M blend, neither of which is a serving-optimization problem, it's beyond what current single-H100 throughput ceilings for a dense 70B model support. At today's live GPU market price, there's no realistic crossover for this specific model: DeepInfra's per-token rate stays cheaper than self-hosting no matter how well you tune the deployment.

That's a different finding than we've reported against other APIs in this series, where a crossover existed at high sustained utilization. The reason is DeepInfra's Llama 3.3 70B rate is simply low, priced closer to a commodity than a premium API tier, and GPU rental prices have moved up since our earlier posts in this series ran the same math at $2.01/hr. Both factors push the crossover further out of reach.

Why Utilization, Not Token Volume Alone, Decides the Crossover

The trap in framing this as a volume question is that a rented GPU's cost is fixed per hour regardless of how many requests actually hit it. A team pushing genuinely high daily token counts but with bursty, spiky traffic, heavy during business hours, idle overnight, never gets near the 85%+ sustained utilization the optimized CPM numbers above assume. That team could be serving millions of tokens a day and still be paying closer to the $2.74/1M naive-config rate than the $0.48/1M tuned rate, because utilization, not aggregate volume, is what the CPM formula is actually sensitive to. Our Groq pricing analysis and Fireworks AI pricing breakdown walk through this same utilization-not-volume argument against two other inference APIs, and the conclusion holds here too: don't estimate a crossover from your daily token count alone. Model your actual request arrival pattern first.

Where the crossover argument gets stronger is on the flagship end of DeepInfra's catalog. A model like Qwen3-Max at $1.20/$6.00 per 1M, or Kimi-K3 at $2.85/$14.25, carries a per-token rate high enough that a dedicated GPU cluster running at genuinely high, sustained utilization has real room to compete, provided the model is one you can self-host at all. DeepSeek, GLM, Kimi, and Qwen are all open-weight families available for self-hosting; a model like Anthropic's Claude or Google's Gemini isn't, no matter how the token math works out, since neither ships open weights.

When to Use DeepInfra's API vs Rent Your Own GPU

DeepInfra's own numbers back up why the API path is the default choice for most teams: the company said it had grown token processing volume 25x since its April 2025 Series A, on the way to a $107 million Series B in May 2026 led by 500 Global and Georges Harik, with A.Capital Ventures, Crescent Cove, Felicis, NVIDIA, Peak6, Samsung Next, Supermicro, and Upper90 participating (DeepInfra Series B announcement). That kind of growth curve is what you'd expect if the serverless tier is genuinely winning the cost argument for most workloads, not just a subsidized loss leader. DeepInfra also describes owning its own infrastructure rather than reselling capacity: "We own and operate our GPU infrastructure across eight U.S. data centers, with more locations rolling out globally," and points to agentic workloads as the reason inference volume keeps climbing: "a single agentic task can require 50 to 100+ model calls and run nonstop" (DeepInfra Series B announcement).

That last point is the one worth sitting with if you're building agents rather than single-turn chat. Fifty to a hundred model calls per task means your effective cost multiplier is the per-call price times the call count, not the per-call price alone, and it's exactly the kind of bursty, unpredictable traffic pattern that keeps a self-hosted GPU's utilization low and its effective CPM high. That's the case for staying on a per-token API even at meaningful scale: the infrastructure risk of running your own fleet under agentic traffic patterns is real, and DeepInfra's pricing is built to absorb it for you.

If you decide the flagship-model math or the fine-tuning requirement pushes you toward self-hosting, bare-metal H100 instances on Spheron bill per minute with no long-term commitment, and an OpenAI-compatible vLLM endpoint is a base-URL swap away from whatever client code you're already running against DeepInfra. Spheron's docs cover that deployment path end to end. For a wider look at how DeepInfra and other third-party hosts price the same open-weight models against each other, see our LLM API pricing comparison covering GPT, Claude, Gemini, and DeepSeek-family rates across providers.

If DeepInfra's per-token bill is climbing on a flagship model rather than a commodity one, that's the point to actually run the self-hosting math, not before.

Rent H100 SXM5 →