Inference Providers vs. Endpoints

Part of a series on running AI workflows across model providers — this one clears up a naming confusion that trips up a lot of people new to Hugging Face.

Hugging Face ships two genuinely different ways to run inference against a model, and the names don't make the distinction obvious: Inference Providers, a serverless routing layer across multiple third-party infrastructure vendors, and Inference Endpoints, dedicated infrastructure Hugging Face itself provisions and manages just for you. Picking the wrong one isn't fatal, but it does mean paying for the wrong shape of infrastructure for your actual traffic pattern.

Inference Providers: pay per call, share the infrastructure

Inference Providers is what most of this series has been describing so far — a single Hugging Face token that routes your request to one of sixteen-plus backing infrastructure providers (Groq, Together AI, Fireworks, Cerebras, and others), with automatic failover and provider-selection policies like :fastest or :cheapest. You're calling shared, serverless infrastructure someone else runs, and paying per request at the underlying provider's rate — Hugging Face doesn't add a markup.

This is the right shape for unpredictable, request-by-request traffic: a chat feature with variable usage, a background job that runs occasionally, anything where provisioning dedicated capacity ahead of time would mean paying for idle infrastructure most of the time.

Inference Endpoints: dedicated infrastructure, provisioned for you

Inference Endpoints is a different product entirely. You pick a model from the Hub, and Hugging Face provisions dedicated, autoscaling infrastructure — your choice of cloud vendor, region, accelerator (CPU, GPU, or specialized chips), and instance size — that's yours alone, not shared with other customers' requests.

from huggingface_hub import create_inference_endpoint

endpoint = create_inference_endpoint(
    "support-classifier",
    repository="your-org/fine-tuned-classifier",
    framework="pytorch",
    task="text-classification",
    accelerator="gpu",
    vendor="aws",
    region="us-east-1",
    instance_size="x2",
    instance_type="nvidia-a10g",
).wait()

You pay for the running instance, not per request — which flips the earlier tradeoff around: predictable, high-volume traffic gets cheaper on dedicated infrastructure than paying per call, and you get lifecycle control a serverless call doesn't offer — pausing an endpoint entirely (free while paused), or configuring it to scale to zero after a period of inactivity and auto-restart on the next call, accepting a cold-start delay in exchange for near-zero cost while idle.

Side by side

Same Hub, same models — a different infrastructure shape underneath depending on your traffic pattern.

A real use case: a document-processing pipeline with predictable volume

Imagine a company processing a steady, high volume of scanned documents every night — a batch job, not a live user-facing feature, running on a schedule with a known, roughly constant workload. Running that through Inference Providers' per-request pricing works, but at real volume, the per-call cost adds up in a way that dedicated infrastructure, provisioned just for the batch window and paused the rest of the time, doesn't.

endpoint = create_inference_endpoint(
    "nightly-doc-processor",
    repository="your-org/doc-classifier",
    accelerator="gpu",
    vendor="aws",
    region="us-east-1",
    instance_size="x4",
    instance_type="nvidia-a10g",
).wait()

results = [endpoint.client.text_classification(doc) for doc in tonights_batch]

endpoint.pause()

Which one to reach for, honestly

Default to Inference Providers unless you have a specific reason not to. It's simpler, requires no infrastructure decisions, and covers the majority of real-world traffic patterns — including most production chat and agent workloads — without you ever thinking about instance types or regions.

Reach for Inference Endpoints when: you're serving your own private fine-tuned model that isn't available through any backing provider; you have genuinely high, predictable volume where dedicated infrastructure is cheaper than per-call pricing; you need a specific compliance posture around exactly where and how the model runs; or you're running batch jobs on a schedule, where pause/resume control matters.

How this connects to DNotifier

DNotifier's sendAI() call doesn't need to know which of these two you're using — both are just an inference URL and credentials from DNotifier's perspective. What changes is what you point the app's model configuration at: a Hugging Face model ID routed through Inference Providers for the common case, or a dedicated Endpoint's URL for the workloads described above. The application code calling sendAI() doesn't change either way.

Frequently asked questions

Can I use both in the same application?

Yes — a common pattern is Inference Providers for interactive, unpredictable traffic and a dedicated Endpoint for a specific high-volume or custom-model workload, both connected to the same DNotifier app under different agents.

Is Inference Endpoints more expensive than Inference Providers?

It depends entirely on volume and usage pattern — dedicated infrastructure is more expensive when mostly idle and cheaper at sustained high volume, which is exactly why the pause/scale-to-zero controls exist, to avoid paying for idle dedicated capacity.

Do I need my own cloud account to use Inference Endpoints?

No — Hugging Face provisions and manages the infrastructure on your behalf across supported cloud vendors; you're not separately managing an AWS or GCP account for this.

Can I run a private, unpublished model through Inference Endpoints?

Yes — this is one of Inference Endpoints' clearest advantages over Inference Providers, which only serves models a backing provider has chosen to host.

What happens to my dedicated endpoint if I forget to pause it?

It keeps running and billing at the instance rate until you pause, scale to zero, or delete it — worth setting up inactivity-based scale-to-zero if your workload has predictable idle periods, so cost doesn't silently accumulate.

The Bottom Line

Next in this series: how Hugging Face's own lightweight agent framework, smolagents, compares to building agents on DNotifier.

Read part five: Smolagents vs. DNotifier. Explore dnotifier.com.