Baseten Pricing 2026: Model Serving Cost vs Renting GPUs

Baseten's pricing page is refreshingly specific: real per-minute GPU rates, no idle charges, no hidden model markup. That's the pitch, and on paper it's accurate. What the pricing page doesn't spell out is that Baseten's own autoscaling defaults and its own production guidance quietly push most real deployments away from the scale-to-zero number and toward something closer to always-on billing.

This post breaks down Baseten's actual per-minute rates across every GPU tier, what scale-to-zero really saves once you account for the 15-minute scale-down delay and cold starts, and the specific utilization percentage, computed per GPU tier from live rates, where a dedicated GPU rental beats Baseten on cost. If you're weighing Baseten against ten other inference platforms rather than just GPU rental, our Baseten alternatives roundup covers the broader field and the Truss migration path in more depth; this post is the pricing deep dive that sits underneath it.

Baseten's Per-Minute GPU Rates: T4 Through B200 Broken Down

Baseten bills dedicated deployments per minute, by GPU type, with the same rate applying regardless of which model you run on that card. The rates range from $0.01052/min on a T4 up to $0.16633/min on a B200, according to Baseten's pricing page.

The Full Rate Table and What 'No Model Markup' Actually Means

Source: Baseten's pricing page. "No model markup" means the rate is set by the GPU, not the model you deploy on it. A 7B model and a 70B model on the same H100 cost the same per minute. That's a genuine point in Baseten's favor over some replica-hour competitors that price by parameter count, and it's the line Baseten leads with: "you only pay for the time your model is using compute on Baseten," covering deployment, scaling, and prediction time, per the pricing page.

That framing is also, by third-party analysis, close to how Baseten actually makes money. ValueAddVC's breakdown puts roughly 60% of Baseten's revenue on dedicated GPU-minute deployments versus about 30% on per-token Model APIs, with the remainder in enterprise support. The same source reports Baseten crossing $600M ARR in March 2026, up from $200M in December 2025, and a Series F at a $13B valuation in June 2026. Whatever the growth story, the GPU-minute rate table above is where most of that revenue is actually billed.

Replica Multiplication: Why Redundancy Doubles (or Triples) the Bill

The per-minute rate is per replica, and most production deployments run more than one. Each running replica bills independently at the full GPU rate, so two H100 replicas at $6.50/hr each cost $13/hr combined, before either one serves a request that a single replica couldn't have handled. Three replicas triple it. Nothing in the pricing model discounts a second or third replica; it's the same per-minute rate, multiplied.

That's not a hidden fee, it's just easy to miss when you're mentally pricing "an H100" as a single number instead of "however many replicas keep the endpoint up." The next section covers why most production setups end up running at least two.

Scale-to-Zero and Idle Billing: Where the Savings Actually Come From

Baseten's cost advantage over a dedicated GPU rental comes entirely from scale-to-zero: a model with no traffic costs nothing. The size of that advantage depends on how aggressively you can actually run at zero, and Baseten's own defaults and its own production advice both work against running at zero for long.

Default Autoscaling Behavior (min replicas 0, 900-second scale-down delay)

Baseten's default autoscaling configuration sets min_replicas to 0, max_replicas to 1, a concurrency target of 1 request per replica, and a target utilization of 70%, evaluated on a 60-second autoscaling window, per Baseten's autoscaling docs. Scale-to-zero is real: with no traffic, the replica count drops to zero and billing stops.

The detail that matters for cost math is the scale-down delay: 900 seconds, or 15 minutes, after the last request, before the replica actually shuts down. That window is configurable from 0 to 3,600 seconds, but the default means every idle gap of less than 15 minutes doesn't save you anything, and every gap longer than that still bills you for the first 15 minutes of it. For a bursty endpoint that receives requests every few minutes throughout the day, the model may never actually reach zero, since each request resets the 15-minute countdown.

The Cold Start Tradeoff and the Wake Endpoint Workaround

The other side of scale-to-zero is the cold start on the way back up. Baseten says most models cold-start in seconds and the largest models take "a handful of minutes," and points to its Baseten Delivery Network (BDN) as delivering 2-3x faster cold starts than alternative approaches for models in the 10s-to-100s-of-billions-of-parameters range, largely through owned weight mirrors and multi-tier caching that avoid a "thundering herd" of pods requesting the same weights at once, per Baseten's BDN writeup. In a narrower, best-case benchmark, Baseten reports a 9-second cold start for Stable Diffusion XL on an A100, from an earlier autoscaling features post; treat that as a floor for a comparatively small image model, not a number to extrapolate to a 70B LLM.

Baseten's workaround for user-facing cold-start latency is a wake endpoint: a POST to /models/MODEL_ID/wake, or a manual wake button in the dashboard, that pre-warms a scaled-to-zero model before the real request arrives, per Baseten's wake changelog entry. It works, but it's still a workaround: you're paying for the warm-up time either way, you're just choosing when. Firing the wake call on page load or on the first keystroke shifts the cold start off the critical path, but it doesn't eliminate the underlying billing. For a broader look at cold-start mitigation techniques that apply beyond any single platform, including weight streaming and CUDA graph snapshotting, see our guide to fixing GPU cold starts on serverless inference.

Why Production Deployments Quietly Stop Being 'Serverless' (min_replicas >= 2)

Here's the part that changes the actual cost profile. Baseten's own autoscaling documentation recommends setting min_replicas to at least 2 in production: "This eliminates cold starts and provides redundancy if one replica fails," per the autoscaling overview. That's sound advice for anyone running a real production API. It's also a direct instruction to stop using scale-to-zero for the workload it was supposedly built for.

Once min_replicas is 2, the deployment bills as 2 replicas running continuously at the GPU's hourly rate, all day, regardless of traffic. Two H100 replicas at $6.50/hr each work out to $9,360/month in GPU charges before a single request comes in, using Baseten's own published rate. A single Spheron H100 PCIe on-demand instance, running continuously at $2.01/hr, costs $1,447.20/month for the same 24/7 availability, no scale-to-zero required because there's nothing to scale down from. The "serverless" framing on the pricing page is accurate for the default configuration; it's not the configuration Baseten tells you to run once traffic matters.

Cost Crossover: At What Request Volume Does Renting Your Own GPU Win

There isn't one crossover number for Baseten versus dedicated GPU rental, because the answer depends on which GPU tier you're comparing and what each provider charges for it right now. The honest version of this math is a ratio computed per GPU: Spheron's on-demand rate divided by Baseten's rate for that same GPU. Below that utilization percentage, Baseten's flexible per-minute billing wins because you're not paying for idle time. Above it, a flat-rate dedicated instance wins because it doesn't carry Baseten's per-minute premium on active time.

H100: Baseten $6.50/hr vs Spheron H100 PCIe On-Demand $2.01/hr (~31% Crossover)

Baseten's H100 80GB dedicated rate is $0.10833/min, or about $6.50/hr. Spheron's live on-demand rate for H100 PCIe is $2.01/hr, fetched from the Spheron GPU offers API. The crossover utilization is 2.01 / 6.50 = 0.309, roughly 31%, or about 7.4 hours of active GPU time in a 24-hour day. Below 31% daily utilization, Baseten's per-minute billing costs less than a Spheron on-demand instance running continuously. Above 31%, the dedicated instance is cheaper, and the gap widens the higher utilization climbs.

A100 and B200 Crossover Points (~46% and ~94%)

The same math on A100 80GB puts the crossover higher, and on B200 it puts the crossover close enough to full-time use that the picture genuinely changes.

On A100 80GB, Baseten's $4.00/hr against Spheron's $1.85/hr on-demand rate puts the crossover at 1.85 / 4.00 = 0.4625, about 46% utilization. On B200, Baseten's $9.98/hr sits close to Spheron's $9.36/hr on-demand rate: 9.36 / 9.98 = 0.938, about 94% utilization. That's the exception worth stating plainly rather than glossing over: on the newest, most expensive GPU tier, the two rates are close enough that Baseten's flexible billing stays competitive almost the entire day. A B200 workload would need to run at 94%+ sustained utilization before a dedicated rental pulls ahead, a bar that most inference workloads, with their inherent request-rate variance, rarely clear. The 31% and 46% crossover points on H100 and A100 don't generalize to B200, and treating one blanket percentage across every GPU tier would get the B200 case badly wrong.

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

Worked Examples: Bursty (2 hrs/day) vs Sustained (24/7) Inference

Bursty inference, one 2-hour window a day, scale-to-zero the rest of the time. With min_replicas at 0 and a single daily traffic window, Baseten bills roughly the active time plus one 15-minute scale-down tail: (2 + 0.25) x $6.50 x 30 = $438.75/month on H100. A Spheron on-demand instance left running continuously to avoid reload latency costs $2.01 x 24 x 30 = $1,447.20/month. Baseten wins by a wide margin here, which is exactly the pattern scale-to-zero billing is built for. The caveat: if that traffic arrives in multiple short bursts rather than one clean window, each burst resets the 15-minute countdown, and the effective billed time creeps toward continuous the more frequently requests arrive.

Sustained inference, 24/7, following Baseten's own min_replicas ≥ 2 production guidance. Two H100 replicas at $6.50/hr each: $6.50 x 2 x 24 x 30 = $9,360/month. One Spheron H100 PCIe on-demand instance running continuously: $2.01 x 24 x 30 = $1,447.20/month. Spheron costs about 85% less. Even a single Baseten replica with no redundancy, at $6.50 x 24 x 30 = $4,680/month, still runs more than 3x Spheron's on-demand rate for the same always-on availability. For the underlying utilization-to-cost-per-token math behind these figures, see our AI inference cost economics playbook, and for cost-per-token benchmarks across model sizes and GPU tiers, see GPU cost per token: benchmarking 7 major LLMs.

Moving a Baseten Deployment to a Dedicated GPU Instance

Once utilization is past the crossover point for your GPU tier, or once you're already running min_replicas at 2 for production reliability, the math above stops being theoretical. Moving off Baseten mainly means replacing Truss with a standard inference server.

Porting a Truss Model to vLLM/SGLang

Baseten's Truss framework wraps a model in a Python class with load() and predict() methods, plus a config.yaml describing hardware requirements. Most Truss deployments wrap a standard HuggingFace model with little or no custom preprocessing, which means the port is mechanical: pull the base model weights, provision a Spheron A100 instance or an H100 depending on model size, and start vLLM with the model path and a served model name. The exact migration steps, including the vllm serve command and how to swap base_url in existing client code without touching request formatting since vLLM's OpenAI-compatible endpoint matches Baseten's API shape, are covered in our self-hosted OpenAI-compatible API guide. The vLLM production deployment guide covers tensor parallelism and FP8 quantization once the model is running.

For teams standardizing on a serving stack rather than a single deployment platform, Spheron's docs cover provisioning an on-demand or spot instance end to end. Spot pricing on H100 PCIe runs $1.68/hr and A100 spot runs $0.85/hr, both from the live GPU offers API, useful for non-latency-sensitive batch inference where interruption is an acceptable tradeoff for a lower rate.

When Baseten Still Makes Sense

Baseten's premium buys something real for a specific kind of team: a managed serving layer, Truss packaging, and enterprise SLA contracts, without owning the deployment stack. That's worth paying for when:

• Traffic is genuinely bursty with long idle gaps and no requirement for sub-second latency on the first request after a gap.
• Your team has no bandwidth to operate vLLM or SGLang directly and values not owning GPU infrastructure.
• Compliance or contractual requirements call for a vendor-managed serving layer with formal SLAs.
• Utilization on your GPU tier sits below the crossover point calculated above, meaning scale-to-zero billing is genuinely saving money rather than masking always-on cost.

Once utilization climbs past that line, or once min_replicas ≥ 2 makes the deployment always-on in practice, the per-minute rate stops being the advantage it looks like on the pricing page. For a wider comparison of billing models beyond just Baseten, our serverless vs on-demand vs reserved GPU guide covers the general framework across platforms.

If your Baseten deployment already runs 2 warm replicas around the clock, you're paying for always-on capacity without an always-on rate. Spheron's H100 on-demand instances give you the same 24/7 availability at a flat per-minute rate with no replica markup.

Check H100 availability →