Hugging Face Inference Endpoints Pricing 2026: Cost vs Renting GPUs

Hugging Face Inference Endpoints pricing looks simple on the rate card: $0.50/hr for a T4, up to $10/hr for a GCP-hosted H100. What the rate card doesn't show you is the billing formula underneath it, and that formula is where most teams get surprised. An endpoint configured with a minimum of one replica bills the full hourly rate around the clock, whether it serves one request or one million. We pulled the numbers straight from Hugging Face's own pricing and autoscaling docs to show what you're actually paying for, and where renting the same GPU directly starts winning on cost.

If you're already evaluating alternatives to HF's managed serving layer, our Hugging Face Inference Endpoints alternatives guide covers 10 self-hosted and managed options side by side. This post focuses narrowly on what HF itself charges, and exactly when that charge stops making sense.

Hugging Face Inference Endpoints Pricing: Per-GPU-Hour Rates by Instance Type

Here's the direct answer: Hugging Face Inference Endpoints prices dedicated GPU instances by the hour, split across two underlying clouds. AWS hosts the wider tier list (T4 through H200); GCP hosts a narrower list that's the only place to get an H100. Rates run from $0.50/hr at the low end to $10/hr for a single H100, and scale close to linearly as you add GPUs to a bundle. All figures below come from Hugging Face's Inference Endpoints pricing docs.

AWS-Hosted Tiers: T4, L4, A10G, L40S, A100, H200

AWS's table has no H100 row at all. It jumps from A100 directly to H200. If you want an H100 on HF Endpoints, AWS isn't the option; you have to switch to GCP.

GCP-Hosted Tiers: T4, L4, A100, H100 (H100 Is GCP-Only)

Two things worth flagging here. First, GCP's A100 costs more per hour than AWS's A100 at the same GPU count ($3.60/hr vs $2.50/hr for x1), for identical 80GB hardware. Cloud choice on HF Endpoints isn't just about availability; it changes the bill directly. Second, H100 pricing scales linearly and exactly: x2 is double x1, x8 is 8x x1. There's no bulk discount for multi-GPU bundles at any tier we checked.

Why H200 ($5/hr on AWS) Can Undercut H100 ($10/hr on GCP)

This is the quirk teams miss when they're comparing HF's own tier list: the "better" GPU can be the cheaper line item. H200 has more VRAM than H100 (141GB vs 80GB) and is generally the faster chip for large-model inference, yet HF prices a single H200 on AWS at $5/hr, half of what a single H100 costs on GCP.

The reason isn't chip economics, it's cloud placement. H100 simply isn't offered on AWS through HF Endpoints, so if your workload needs an H100-class GPU and you don't specifically need H100 architecture, an AWS-hosted H200 endpoint is both more capable and cheaper than the GCP-hosted H100 alternative. Worth checking before you default to "H100" as your target tier out of habit.

The Always-On Billing Trap: Why Idle Endpoints Still Cost Money

The rate card above tells you the price per hour while an endpoint runs. It doesn't tell you how many hours actually get billed, and that's the number that determines your real monthly cost. The short version: if your endpoint has a minimum replica count of 1 or higher, HF bills that GPU's hourly rate 24 hours a day, 7 days a week, regardless of how much traffic it sees. A $10/hr GCP H100 endpoint configured that way costs $7,200/month whether it handles ten requests or ten million.

How the Billing Formula Actually Works (Per-Minute, Not Per-Request)

Hugging Face publishes the exact formula in its pricing docs:

instance hourly rate x ((hours x number of min replicas) + (scale-up hours x number of additional replicas))

Two details in that formula matter more than they look. First, endpoints are billed while in the "initializing" and "running" states, and are not billed while "paused." Manually pausing an endpoint you're not using is the one lever that stops the meter entirely. Second, "while the prices are shown by the hour, the actual cost is calculated by the minute," per HF's own documentation. That's good news at the margins (you're not rounded up to a full hour for a 20-minute job) but it doesn't change the core problem: minute-level billing on a minimum-replicas-of-1 endpoint still adds up to every single minute of every day.

Scale-to-Zero Defaults: 15-Minute Idle Timeout, No Built-In Request Queue

HF Endpoints does support scaling to zero, but only if you explicitly configure the endpoint's minimum replica count to 0. Left at the default, an endpoint that receives no requests for over 15 minutes automatically scales down to zero replicas, and stops being billed once it's there, according to HF's autoscaling documentation.

That protects against a fully idle weekend, but it does nothing for spiky, low-frequency traffic. A support tool that gets a request every 12 minutes never scales to zero. It stays "running" continuously and bills continuously, even though most of those 12-minute windows have no active inference happening. This is the gap between "traffic-aware billing" and what HF actually does: HF's states are running or not, not busy or idle.

There's a second gap worth calling out directly: Hugging Face's own docs state plainly, "there is currently no queueing system in place for incoming requests." HF's official recommendation is to build your own client-side request queue with error handling. If two requests land on a single-replica endpoint at the same moment, HF isn't queuing the second one for you; your application has to handle that.

Cold Starts After Scale-to-Zero Mean 502s, Not Instant Traffic

Scale-to-zero isn't free in a different sense. When a scaled-down endpoint gets a new request, HF's docs are explicit that "the HTTP server will respond with a status code 502 Bad Gateway while the new replica is initializing." Cold start duration depends on model size and isn't fixed. For a 7B model that might be a handful of seconds; for a 70B model with a large weight download, it can stretch well past what a synchronous request timeout will tolerate.

For a user-facing API, that means your first caller after any idle period gets a 502, not a slow-but-successful response. Teams running scale-to-zero endpoints in production generally build retry logic around this specifically, treating the first 502 after an idle window as expected behavior rather than an error to alert on.

Hub Subscription Costs Stack on Top of Compute (PRO/Team/Enterprise)

Inference Endpoints compute is billed as a separate line item from your Hugging Face Hub subscription. PRO runs $9/month for individual accounts, Team is $20/month per user, and Enterprise is $50/month per user with custom terms, per Hugging Face's pricing page. None of these plans include free GPU compute for dedicated endpoints. They cover Hub storage limits, inference credits for the shared Serverless Inference API, and access controls like SSO and resource groups.

If you're budgeting for a production HF Endpoints deployment, the real monthly number is Hub subscription plus GPU-hour billing, not one or the other. A team on the Team plan running a single always-on A100 GCP endpoint is paying at least $20/user/month plus roughly $2,592/month in compute ($3.60/hr x 720 hours), not just the compute figure alone.

Hugging Face Inference Endpoints Pricing vs Renting Your Own GPU Cloud

Renting the GPU yourself removes the managed layer, the per-GPU markup that comes with it, and the always-on billing trap, at the cost of handling deployment, scaling, and restarts yourself. Whether that trade is worth it comes down to one number: how many hours a day your endpoint is actually doing work.

The Break-Even Math: 24/7 Endpoint vs Hourly GPU Rental

For an always-on HF endpoint (minimum replicas of 1), there's no break-even calculation needed. You're paying the full rate every hour either way, so the cheaper hourly rate wins from hour one. As of this writing, Spheron lists on-demand GPU rates at $3.94/hr for H100, $1.43/hr for A100, $4.79/hr for H200, and $0.96/hr for L40S. Running an always-on HF GCP H100 endpoint costs roughly $7,200/month ($10/hr x 720 hours); the same H100 rented directly on Spheron runs about $2,837/month, a savings of roughly $4,360/month for identical GPU hardware.

The more interesting comparison is against a scale-to-zero HF endpoint, where HF only bills for active minutes. Here the question becomes: at what point does a fixed-rate 24/7 rental beat paying HF's higher per-hour rate for only the hours you're actually serving traffic? Setting the two costs equal and solving for daily active hours gives a rough break-even point:

Once your endpoint is actively serving traffic for more hours per day than the figure in that table, a fixed 24/7 rental at the lower hourly rate costs less than paying HF's higher rate only while running. And that break-even point is generous to HF: it assumes every billed minute is a minute of real request-serving, with no allowance for the 15-minute idle buffer before scale-down or the extra "initializing" minutes billed during each cold start. In practice, both of those push the real crossover lower, meaning a dedicated rental usually starts winning sooner than the table above suggests. The H200 row is the exception: HF's AWS H200 rate is close enough to Spheron's on-demand H200 rate that the managed option holds up at nearly any utilization level.

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.

What You Give Up Renting Direct (Managed Restarts, One-Click Deploy)

None of this is an argument that HF Endpoints is a bad product. It's a fair trade for what it does well: pick a model from the Hub, choose a GPU tier, deploy in a few minutes, and HF handles health checks, automatic restarts, and infrastructure management for you. No Docker knowledge required. For a team early in development, or one running a low-traffic internal tool where engineering time is worth more than the compute delta, that's a reasonable price to pay.

The calculation flips once your traffic is steady enough to fill most of the day. At that point you're paying HF's premium for infrastructure management you're not really using anymore, since the endpoint stays running most of the time either way.

Migration Path if You're Already Running TGI

HF Inference Endpoints runs TGI (Text Generation Inference) under the hood by default, which means moving off HF's managed layer doesn't mean changing your inference stack. You can pull the same ghcr.io/huggingface/text-generation-inference Docker image and run it on a directly rented GPU with the same flags and the same OpenAI-compatible API surface. Our TGI production deployment guide walks through the Docker setup, tensor parallelism flags, and flash attention configuration for running TGI on rented GPU hardware.

If you'd rather move to a different serving engine while you're migrating anyway, since TGI is now in maintenance mode, the TGI to vLLM or SGLang migration guide covers flag translation and performance validation for that path. Either way, the model weights and API contract stay the same. Only the billing and the infrastructure owner change.

For teams evaluating the lower end of HF's tier list specifically, T4 and A10G are the two smallest GPU options on the rate card above. Our A10G vs T4 comparison breaks down when the cheaper T4 is enough and when the extra A10G cost buys real throughput. And if you want the fuller picture of what GPU cloud pricing looks like across providers beyond HF, our GPU cloud pricing comparison tracks on-demand and spot rates across the major GPU cloud providers. For the FinOps framing behind the break-even math in this post, the AI inference cost economics guide covers how inference spend typically outpaces training spend once a model ships to production.

If your HF Inference Endpoints bill is climbing because your endpoint runs closer to 24/7 than it does to occasional bursts, the same GPU rented directly usually costs less starting from the first billed hour.

Check H100 availability →

Get started on Spheron →