Groq API Pricing 2026: Cost Per Token vs GPU Rental

Groq prices its API by the token, same as every other inference provider. What's unusual is where that price lands: on Llama 3.3 70B, Groq's blended per-token rate sits close to, or below, what a well-tuned vLLM deployment costs to run on a rented H100. We already covered the hardware behind Groq's speed, the LPU architecture and the throughput numbers that make Groq fast. This is the buyer-side follow-up: what Groq actually charges per model, what it won't let you customize, and the exact point where renting a GPU and running the model yourself stops being the cheaper option.

The answer is more nuanced than "API vs GPU, pick one." Groq's per-token price on its own supported models already beats a decently optimized self-hosted deployment in a lot of scenarios. The real argument for self-hosting isn't raw cost per token, it's model choice, fine-tuning access, and control over your serving stack, none of which Groq's catalog gives you today.

Groq's 2026 Price Ladder: Every Model, $0.05 to $0.90 per Million Tokens

Groq's non-enterprise LLM catalog spans six models, priced from $0.05 to $0.90 per million input tokens depending on size and architecture (Groq pricing). That's a narrower range than most serverless inference APIs, mostly because Groq's catalog itself is narrower: six models total, not the hundred-plus checkpoints a platform like Fireworks or Together prices by parameter-count tier.

LLM Pricing Table: Llama, GPT-OSS, Qwen, and Minimax

Source: Groq pricing. Llama 3.1 8B Instant is the cheapest model on the list by a wide margin, at less than a tenth of Llama 3.3 70B's rate. Qwen 3.6 27B is the outlier worth flagging: a $0.60 input / $3.00 output split, a 5x output premium over input, higher than any other model on the price list (Groq pricing). If your workload generates long completions on Qwen 3.6 27B, that output multiplier changes the math fast, and it's easy to miss if you're pricing the model off its input rate alone.

Minimax M2.7 sits outside the self-serve catalog entirely. It's enterprise-only, priced on request, which puts a hard ceiling on what you can evaluate without a sales conversation first.

Whisper and TTS Are Billed Differently: Per-Hour and Per-Character, Not Per-Token

Groq's speech models don't fit the token-pricing model at all. Whisper Large v3 costs $0.111 per hour of audio transcribed, and Whisper Large v3 Turbo costs $0.04 per hour, a rate built around audio duration instead of output tokens (Groq pricing). Text-to-speech runs on a third billing unit again: Groq's Canopy Labs Orpheus voices are priced per character, $22.00 per million characters for the English voice and $40.00 per million characters for Arabic Saudi.

If your workload is voice, not text, none of the crossover math later in this post applies directly, since you're not comparing tokens to tokens. For teams weighing self-hosted transcription instead, we cover GPU sizing and streaming setup for faster-whisper and WhisperX in our production ASR deployment guide.

Batch API (50% Off) and Prompt Caching (50% Off Cached Input)

Two discount programs sit on top of the base rates, and both are flat 50% cuts rather than model-specific sliding scales, which makes the math simple.

Batch API. Async batch processing runs at a flat 50% discount off synchronous pricing, with a completion window you set anywhere from 24 hours to 7 days (Groq batch API docs). It covers chat completions (including vision), audio transcription, and translation, but only on a specific model subset: GPT-OSS 20B and 120B, Llama 3.3 70B, Llama 3.1 8B Instant, Llama Guard 4, and Whisper. Batch files are capped at 50,000 lines and 200MB per .jsonl file, with no limit on how many batch jobs you submit at once. For anything that doesn't need a synchronous response, nightly re-scoring, offline classification, dataset labeling, this is free money left on the table if you're not using it.

Prompt caching. Cached input tokens get a flat 50% discount when a cache hit occurs (Groq pricing). That's a smaller cache discount than some competitors offer on repeated system prompts, but it still matters for any workload with a stable prefix: a fixed system prompt, a repeated tool schema, a RAG pipeline resending the same retrieved context on every call.

What Groq Doesn't Let You Do: Model Choice, Fine-Tuning, Batch Control

The catalog is the real constraint, not the price. Groq's per-token rate is competitive precisely because it's running a small, fixed set of models at fleet-wide scale. That trade-off shows up in three places: which models you can run, whether you can customize them, and how much control you get over how your requests are processed.

A Fixed, Six-Model Catalog vs. Any Open-Weight Checkpoint on Your Own GPU

Groq's self-serve catalog is Llama 3.1 8B Instant, Llama 3.3 70B Versatile, GPT-OSS 20B, GPT-OSS Safeguard 20B, GPT-OSS 120B, and Qwen 3.6 27B, plus enterprise-only Minimax M2.7 (Groq pricing). If the model you want to run isn't on that list, DeepSeek, Kimi, GLM, Mistral, a fine-tuned checkpoint of anything, Groq doesn't have a path for you. Renting a GPU has no such limit: any open-weight model you can find on Hugging Face runs, provided you size the VRAM correctly and pick a serving stack that supports it. Our VRAM tier guide for self-hosting open-source LLMs breaks down which models fit on which GPU class if you're evaluating what a Groq-alternative deployment would actually cost to run.

No Self-Serve Fine-Tuning: LoRA Is Enterprise-Only, by Request

GroqCloud added LoRA fine-tune support, but it's gated entirely behind the Enterprise tier and a request process, not a self-serve API or UI (GroqCloud LoRA announcement). You contact Groq's sales team or submit an Enterprise request form, and Groq's own team handles uploading and managing the resulting adapters on your behalf. If you're a standard account and your use case needs a fine-tuned checkpoint, adapting a domain vocabulary, a house style, a narrower task, there's no Groq path to that today. Self-hosting is the only option, whether that's LoRA or full-parameter fine-tuning on rented hardware.

Service Tiers Instead of Batch-Size Control

Groq gives you four service tiers in place of the batch-size and GPU-allocation knobs you'd control on your own deployment: performance (enterprise-only, guaranteed low latency for critical production traffic), on_demand (the default tier, Groq's normal fast speeds with occasional queueing during peak load), flex (best-effort, tuned for higher throughput, can return over-capacity errors when demand spikes), and auto (Groq picks whichever tier is available for you) (Groq service tiers docs). Notably, the Batch API runs on its own separate processing window and rate limits, and does not accept the service_tier parameter at all. That's a reasonable trade for most teams, but it's a real constraint if you need to tune --max-num-seqs or KV cache allocation the way you would running vLLM or SGLang yourself.

Cost-Per-Token Crossover: Groq API vs Self-Hosted vLLM/SGLang on Rented GPUs

The short version: Groq's blended rate for Llama 3.3 70B works out to roughly $0.63-$0.67 per million tokens. A naive self-hosted deployment on rented H100s costs around $1.24 per million tokens, clearly worse. A heavily optimized deployment sustaining 85% GPU utilization gets down to about $0.62 per million tokens, essentially tied with Groq's sticker price. That's the crossover: it exists, but it requires the kind of sustained, high-utilization traffic most teams don't actually have.

The Llama 3.3 70B Math: Groq's Blended Rate vs FP8 Continuous-Batching CPM on Rented H100s

Groq prices Llama 3.3 70B Versatile at $0.59 input / $0.79 output per million tokens (Groq pricing). Blending that at a typical 80/20 input-heavy split gives $0.63/M tokens; at a more output-heavy 60/40 split, it climbs to $0.67/M. We use the same cost-per-million (CPM) framework and formula, CPM = ($/hr) / (tokens/sec × 3600) × 1,000,000, that we use across our inference cost economics playbook to keep this comparison apples-to-apples.

On the self-hosted side, our own vLLM continuous batching benchmarks measured Llama 3.3 70B FP8 on a single H100 SXM5 80GB running vLLM v0.18.0. Two configurations, same hardware, very different economics:

Using Spheron's live H100 PCIe on-demand rate of $2.01/hr, fetched 22 Jul 2026, the default configuration serving 1,800 tok/s sustained across 4 GPUs at 40% utilization runs about $1.24 per million tokens, clearly more expensive than Groq's $0.63-$0.67/M blended rate. Tune the same workload with continuous batching, PagedAttention, and chunked prefill, and the optimized 2-GPU configuration at 85% utilization brings that down to roughly $0.62 per million tokens, a near-exact tie with Groq's own sticker price.

That's the finding worth sitting with: Groq's baseline, no-tuning-required price already matches the best-case number a skilled ML infra team gets to only after real optimization work. On top of that, Groq's own throughput is hard to beat outright. Independent benchmarking firm Artificial Analysis measured Groq serving Llama 3.3 70B at 276 tokens/second, "the fastest of all benchmarked providers" for that model (Artificial Analysis via Groq).

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

Why Utilization, Not Volume, Is the Real Crossover Variable

Most API-vs-self-host comparisons frame the crossover as a token-volume threshold: push past X million tokens/day and self-hosting wins. That framing breaks down here, because the deciding variable isn't volume, it's utilization, and those are not the same thing.

A rented H100 costs the same $2.01/hr whether it's serving 1 request or 100 concurrent requests. High daily token volume only helps you if it arrives steadily enough to keep the GPU near 85% utilization around the clock. Bursty traffic with the same total daily volume, heavy during business hours, near-zero overnight, never gets there, no matter how many tokens you push in aggregate. That's the trap: a team can hit "high volume" on paper and still be running at 30-40% utilization in practice, paying the $1.24/M rate instead of the $0.62/M rate, and losing to Groq's flat price the whole time.

Groq doesn't have this problem because it isn't sizing capacity for your traffic pattern, it's running a shared fleet across every customer on the platform, which smooths out exactly the burstiness that kills single-tenant utilization. Our billing-model breakdown for serverless, on-demand, and reserved GPU capacity covers this utilization-vs-billing-model tradeoff in more depth if you're deciding between managed inference and owning the stack for a workload beyond what's in this post.

Where Self-Hosting Still Wins: Unsupported Models, Fine-Tuned Checkpoints, and Full Batch/Latency Control

None of the above means self-hosting doesn't make sense, it means cost alone rarely gets you there for a model Groq already serves well. The real reasons to self-host are the ones the pricing section above already surfaced:

• Model choice. Anything outside Groq's six-model catalog, DeepSeek, Kimi, GLM, Mixtral, a community fine-tune, only runs if you host it yourself.
• Fine-tuning access. Standard Groq accounts have no self-serve fine-tuning path at all. If your use case needs an adapted checkpoint, self-hosting is the only route unless you're Enterprise.
• Full serving control. Batch size, KV cache allocation, quantization format, latency SLA tuning, all of it is yours to set on a self-hosted deployment. Groq's four service tiers are a coarser lever. vLLM vs SGLang covers the tradeoffs between the two leading serving stacks if you're picking one for this path.
• Data residency and infrastructure control. Some compliance requirements need prompts and completions to never leave your own infrastructure, a constraint no third-party API, Groq included, can satisfy.

A marketplace model helps here too: renting GPU capacity across multiple providers instead of locking into one vendor's availability and pricing keeps your self-hosted option flexible. Spheron aggregates live GPU capacity from 5+ providers into one marketplace, so you're not stuck with a single data center's pricing or supply constraints if you go the self-host route.

When Speed-as-a-Service Beats Owning the Serving Stack

Decision Framework: Bursty/Low-Volume vs Sustained High-Utilization Workloads

What Groq's Speed Actually Buys You (and Where GPU Rental Still Fits Alongside It)

The reason Groq's price holds up against a tuned self-hosted deployment traces back to the hardware, not just fleet-scale efficiency. Groq's LPU architecture is built for exactly one thing, the decode phase of autoregressive generation, and it's fast enough at that one thing that NVIDIA structured a non-exclusive licensing deal for the underlying inference technology, worth roughly $20 billion, in December 2025. Jonathan Ross, Groq's founder, moved to Nvidia as part of that agreement to help scale the licensed technology, while Simon Edwards, previously Groq's CFO, became Groq's CEO. Groq continues operating as an independent company and GroqCloud keeps running without interruption (Groq newsroom, GovConWire).

That scale shows up in the developer numbers too: GroqCloud has grown to more than 1.5 million registered developers, according to Mohsen Moazami, Groq's President (International), attributing the growth to raw performance rather than marketing spend (TechJournal). Moazami put the business case plainly: "You have to optimize on two dimensions. You have to be fast and you have to be cheap. These token factories are all about token production at the most economical unit and as fast as possible" (TechJournal).

For most teams, the practical move isn't picking one path and abandoning the other. Run Groq for the models it supports well, where sustained 85% utilization on your own hardware isn't realistic anyway. Reach for rented GPUs when you need a model, a fine-tune, or a level of serving control Groq's catalog doesn't offer. Spheron's docs cover deployment for vLLM, SGLang, and five other serving frameworks if you're setting up the self-hosted half of that split.

If Groq's sticker price already matches what a tuned vLLM deployment costs per token, the real reason to rent your own GPU is the model, checkpoint, or serving control Groq's catalog doesn't give you.

Spheron H100 instances →