Gemini 3 Pro API Pricing vs Self-Hosted LLMs: Cost and Privacy (2026)

Gemini 3 Pro API pricing is $2.00 per million input tokens and $12.00 per million output tokens for any prompt up to 200,000 tokens, running under Google's current model name, Gemini 3.1 Pro (ai.google.dev/gemini-api/docs/pricing). Cross that threshold and the entire request, not just the overflow, gets re-rated to $4.00/M input and $18.00/M output. That's a real structural difference from how Claude prices long context, and it changes the math for anyone running RAG pipelines, agentic tool loops, or full-repository code review against Gemini's 1M-token window. This post breaks down what you're actually paying for at each tier, works through the break-even math against the closest open-weight alternatives, and looks at what Google's own privacy terms commit to versus what you get by self-hosting instead. For the budget end of the same model family, see our Gemini 3.1 Flash-Lite vs self-hosted open models breakdown, a different buyer entirely from the flagship Pro tier this post covers.

What You Get With Gemini 3.1 Pro

Gemini 3.1 Pro is Google's flagship model in the Gemini 3.1 family: a 1M-token input context window, a 64K-token output limit, and native multimodal input across text, images, audio, video, and full code repositories (DeepMind model card). That multimodality is the real differentiator from most open-weight competitors, which handle text and often images well but rarely match Gemini's audio and video understanding out of the box.

On release, Demis Hassabis and Koray Kavukcuoglu framed it as a step-change release: "Today we're taking another big step on the path toward AGI and releasing Gemini 3. It's the best model in the world for multimodal understanding and our most powerful agentic and vibe coding model yet" (Google Blog).

The benchmark numbers back up the reasoning claim, if not the AGI framing. On Gemini 3.1 Pro's thinking-high configuration, the model card reports 94.3% on GPQA Diamond, 80.6% on SWE-Bench Verified, 77.1% on ARC-AGI-2, 80.5% on MMMU-Pro, and 84.9% on MRCR v2 at 128K context (dropping to 26.3% at the full 1M-token context, a reminder that "supports 1M tokens" and "reasons well across 1M tokens" are different claims). On Humanity's Last Exam, the no-tools score is 44.4%; with search and code tools enabled, it climbs to 51.4% (DeepMind model card).

None of that is free, and the pricing structure has a specific gotcha worth understanding before you architect around it.

Gemini 3 Pro API Pricing Breakdown: Input, Output, and Context Tiers

Direct answer: Gemini 3.1 Pro costs $2.00/M input and $12.00/M output for prompts up to 200,000 tokens, and $4.00/M input and $18.00/M output for anything larger, with the higher rate applied to the full request rather than just the portion past the threshold (ai.google.dev/gemini-api/docs/pricing).

Source: ai.google.dev/gemini-api/docs/pricing.

At an 80/20 input-to-output ratio, the standard tier blends to $4.00 per million tokens (0.8 x $2 + 0.2 x $12). At a more output-heavy 60/40 split, that climbs to $6.00/M. Those two numbers are the ones to hold in your head, not the $12 headline output rate, because almost no real workload is output-only.

The 200K-Token Cliff (Not a Slope) and Why It Matters

Most usage-based pricing tapers gradually. Gemini's long-context tier doesn't. The moment a prompt crosses 200,000 tokens, Google bills the entire request, input and output both, at the higher rate.

Here's what that looks like on an actual call. Say you send a 250,000-token prompt (a large codebase, a long document set, or an extended agent transcript) and get back 5,000 tokens of output:

• If pricing scaled only on the overflow, you might expect something close to the standard rate: 250,000 x $2/M + 5,000 x $12/M = $0.50 + $0.06 = $0.56.
• What you actually pay, because the whole request crosses the 200K line: 250,000 x $4/M + 5,000 x $18/M = $1.00 + $0.09 = $1.09.

That's roughly 95% more than the naive per-token expectation, for a request that's only 25% over the threshold. If your application occasionally sends prompts that hover around 200K tokens, small variance in prompt length can double the cost of individual calls. Worth checking directly: whether your RAG chunking, tool-call transcripts, or document ingestion pipeline is pushing requests over that line without you noticing.

Thinking Tokens Are Billed as Output, Not Free

Extended reasoning is billed the same way regardless of whether the tokens are visible to the end user. If you set a high thinking budget on a complex debugging or planning task and the model spends 4,000 tokens reasoning before writing a 500-token answer, you're billed for all 4,500 tokens as output (Verdent.ai, Gemini 3.1 Pro pricing guide). At the standard $12/M output rate, that's $0.054 for the call, roughly 9x what you'd pay if only the visible answer counted. On a long-context request at $18/M, the same reasoning trace costs $0.081. Reasoning-heavy agentic workflows (multi-step planning, chained tool calls, self-correction loops) accumulate this cost fast, and it's easy to miss in a budget built around expected answer length rather than actual token usage.

Batch and Context-Caching Discounts

Two levers cut the effective rate meaningfully, if your workload can use them.

Batch API runs at 50% of the standard synchronous rate for asynchronous jobs: $1.00/$6.00 per million on the standard tier, $2.00/$9.00 on long-context. Run the math on a 500M-token/day workload at an 80/20 split: at the standard synchronous blended rate ($4.00/M), that's $2,000/day. At the batch rate ($2.00/M blended), it drops to $1,000/day, a difference of roughly $365,000 a year for a workload that can tolerate async processing. If your pipeline is nightly document processing, dataset generation, or offline evals, this is the first thing to check before assuming your only options are the standard rate or a self-hosted cluster.

Context caching charges $0.20/M tokens to read cached content on the standard tier ($0.40/M long-context), plus $4.50/M tokens per hour of storage (ai.google.dev/gemini-api/docs/pricing). For a shared 50,000-token system prompt or tool schema called 1,000 times in an hour: without caching, that's 1,000 x 50,000 x $2/M = $100 for that hour just on the repeated prefix. With caching, storage costs $0.225/hour and reads cost 1,000 x 50,000 x $0.20/M = $10, for a total of roughly $10.23, about a 90% reduction. Caching pays off fastest on agentic pipelines and coding assistants that resend the same large system prompt or codebase context on every turn.

Pricing fluctuates and can change. The Gemini 3.1 Pro rates above are current as of 11 Aug 2026; verify against ai.google.dev/gemini-api/docs/pricing before budgeting a production workload.

Gemini 3 Pro API Pricing at Scale: How the Blended Rate Compounds

The blended rate, not the headline output price, is what actually shows up on your invoice, and it compounds differently depending on your workload shape.

Long-document analysis: 50,000 documents/month, each sending 3,000 input tokens and getting back 400 output tokens, all under the 200K threshold.

• Input: 150M tokens x $2/M = $300. Output: 20M tokens x $12/M = $240. Total: $540/month, effective cost per output token: $27/M, more than double the $12 headline rate.

Agentic coding sessions: an agent that pulls in 180,000 tokens of repository context per session (just under the cliff) and produces 8,000 tokens of output across edits and explanations, run 2,000 times a month.

• Input: 360M tokens x $2/M = $720. Output: 16M tokens x $12/M = $192. Total: $912/month. Nudge that same session's context to 210,000 tokens (crossing the cliff) and input volume rises too, since the same 2,000 sessions now send 420M input tokens: the math becomes 420M x $4/M + 16M x $18/M = $1,680 + $288 = $1,968/month, more than double, for 30,000 extra tokens of context per call.

That second example is the practical risk with Gemini's long-context pricing: it's not the raw cost of more context that hurts, it's crossing the threshold at all. For a deeper look at how these compounding patterns show up across a full production deployment, see AI Inference Cost Economics 2026.

Break-Even Math: Tokens per Month Where Self-Hosting Wins

Apples-to-Apples CPM Formula

The formula for self-hosted cost per million tokens is the same one used across every comparison on this blog:

CPM = (GPU cluster $/hr) / (tokens_per_sec x 3600 / 1,000,000)

This gives cost per million tokens at the throughput you actually measure, not a theoretical peak. Divide the monthly cluster cost by your target blended API rate (in $/M) to get the token volume, in millions per month, where the cluster and the API cost the same. For the underlying cross-GPU, cross-model throughput data behind these figures, see GPU Cost Per Token Benchmarks 2026.

On-Demand vs Spot Break-Even Tables

Using live Spheron GPU pricing (fetched 11 Aug 2026) against each model's published throughput estimate from its own deployment guide:

GPU spot and on-demand rates move with demand, and they've moved a lot since this section was first drafted, which is exactly why this blog always fetches live pricing instead of quoting a fixed number. Against Gemini 3.1 Pro's standard-tier blended rate of $4.00/M (80/20 split), MiniMax M3 is the only model that clears the API's cost on infrastructure alone at on-demand pricing. DeepSeek V4-Flash and DeepSeek V4 both currently run slightly above the API's blended rate on-demand, and only pull ahead once you move to spot pricing. GLM-5.2 remains the outlier at both tiers: even on spot, its CPM sits well above Gemini's blended rate at the throughput its own deployment guide estimates for a single 8-GPU node. That throughput figure is a moderate-concurrency estimate, not a maximum-batch benchmark, so a heavily-tuned, high-concurrency deployment could close some of the gap, but it's not close enough today to call it a win on cost alone.

Translating CPM into monthly break-even volume against a 24/7 spot cluster (730 hours/month), at Gemini's standard $4.00/M blended rate:

At Gemini's long-context blended rate of $6.80/M (>200K tier, 80/20 split), every one of those break-even volumes drops, since the API side gets more expensive while the self-hosted cluster's cost doesn't change with context length: MiniMax M3 drops to roughly 552M tokens/month, DeepSeek V4-Flash to roughly 1.1B, DeepSeek V4 to roughly 1.8B, and GLM-5.2 to roughly 2.2B.

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

If your Gemini usage is concentrated in long-context calls, that's the scenario where self-hosting an open-weight alternative pays off fastest, both because the API side gets more expensive and because a self-hosted cluster's KV cache cost scales with actual context used, not a pricing-tier cutoff. At today's GPU rates, though, the break-even point sits at meaningfully higher volume than it would have a day earlier: run your own numbers against current pricing before committing hardware, rather than budgeting off any fixed figure in this post.

Closest Open-Weight Alternatives and VRAM Requirements

Matching Gemini 3.1 Pro by capability class, not raw parameter count, points to four open-weight models: native multimodality, a long context window, and frontier-adjacent reasoning or coding performance.

MiniMax M3, GLM-5.2, DeepSeek V4, and DeepSeek V4-Flash Compared

MiniMax M3 is the closest structural match to Gemini's positioning: native multimodality, a 1M-token context window, and the lightest hardware footprint of the four, with FP8 fitting on 2x H200 SXM5 (~230GB) or 4x H100 SXM5. MiniMax published a 59.0% SWE-Bench Pro score for the open-weight checkpoint, which the company reports exceeds both GPT-5.5 and Gemini 3.1 Pro on that benchmark. Full deployment details, including vLLM and SGLang setup, are in the MiniMax M3 deployment guide.

GLM-5.2 targets agentic coding specifically, with a coding-first training focus and a 1M-token context window on top of a 744B-total, ~40B-active MoE architecture. FP8 needs 8x H200 SXM5 (744GB of weights alone); AWQ INT4 drops that to roughly 372GB, fitting 4x H200 or a single 8x H100 node. It's MIT-licensed, no usage restrictions. See the GLM-5.2 deployment guide for the full VRAM and vLLM configuration breakdown.

DeepSeek V4 is the largest of the four (1T total, 37B active), with a 1M-token context window enabled by DeepSeek Sparse Attention. FP8 weights need roughly 500GB, putting the practical entry point at 4x H200 SXM5 (564GB) or 8x H100 SXM5 (640GB). It's the strongest general-reasoning match to Gemini 3.1 Pro's benchmark profile among the four. Full hardware sizing and expert-parallel vLLM setup are in the DeepSeek V4 deployment guide.

DeepSeek V4-Flash is the lighter sibling: 284B total, 13B active, same 1M-token context via a hybrid sparse attention mechanism, but a fraction of the hardware. FP8 fits on 4x H100 SXM5 (320GB, tight KV headroom) or 4x H200 SXM5 for full 1M-context serving. It's the right pick when inference cost per agentic step matters more than peak reasoning quality. See the DeepSeek V4-Flash deployment guide for the exact vLLM flags and KV cache tuning.

None of the four replicate Gemini 3.1 Pro's native audio and video understanding out of the box; all four handle text and images well. If audio/video input is a hard requirement for your product, that's a real capability gap self-hosting doesn't currently close, independent of the cost math above.

Privacy and Data Residency Gaps in the Gemini API

On the paid Gemini API and Vertex AI, Google states plainly that it doesn't use your prompts or responses to train its models: "Google doesn't use your prompts... or responses to improve our products" when using paid services, and for those paid services, Google "logs prompts and responses for a limited period of time, solely for detecting and preventing violations of the Prohibited Use Policy... and any required legal or regulatory disclosures" (Gemini API additional terms of service). Google's own Gemini data governance page separately confirms that prompts and responses aren't used to train its models (Gemini data governance). Users in the European Economic Area, Switzerland, or the UK get additional protections applied across all services, including the free tier.

That's a genuinely stronger baseline privacy posture than several Chinese-lab APIs this blog has covered, where training-on-your-data is the default with no opt-out. But "we don't train on it" and "we don't retain it" are different claims, and the second one, exactly how long, in what form, and under what access controls, is not something Google publishes down to specifics on the pages a typical engineering team would read before signing up. If your compliance review needs a contractual data-processing agreement, a specific retention SLA, or a signed BAA, that's a conversation with Google's enterprise sales team, not something the public API terms settle on their own.

Self-hosting removes the ambiguity entirely: prompts and completions never leave your own infrastructure. On Spheron, GPU instances come with full SSH root access and no shared GPU tenancy, so there's no third-party data path to audit in the first place. For teams under GDPR data-residency requirements, HIPAA, or handling proprietary source code and unpublished research, that structural difference tends to matter more than whatever the cost math above says.

Latency: API Round-Trip vs Dedicated GPU Inference

Gemini's API latency has two structural components that don't apply to a self-hosted endpoint the same way. First, network round-trip to Google's serving infrastructure, unavoidable for any call. Second, prefill time that scales with context length: a 1M-token prompt requires meaningfully more compute before the first output token appears than a 2,000-token prompt does, regardless of how fast the decode phase runs afterward. That's a property of transformer attention, not a Gemini-specific quirk, but it matters more here because Gemini's context window is large enough that teams actually use it.

A self-hosted vLLM deployment removes the network hop entirely when the inference endpoint lives in the same VPC as your application, and gives you direct control over concurrency and queuing rather than sharing capacity with every other Gemini API customer during peak load. Continuous batching, the technique that lets a GPU server process new requests as soon as prior decode steps free up capacity, is the single biggest lever for closing any latency gap at scale; see LLM Serving Optimization: Continuous Batching and PagedAttention for the implementation details. The trade-off is that you own the capacity planning: a self-hosted cluster has predictable latency because it's not shared, but it also doesn't autoscale the way a managed API does without you building that layer yourself.

Decision Framework: When Gemini 3.1 Pro Wins vs Self-Hosting

If your workload is genuinely long-context (RAG over large document sets, full-codebase agentic coding, extended multi-turn sessions), the break-even math above shifts in self-hosting's favor faster than it does for short, output-only calls, simply because Gemini's long-context tier gets more expensive while your cluster's hourly cost stays flat. If a rival frontier lab's API is also on your shortlist, GPT-6 vs self-hosted LLMs and Kimi API pricing vs self-hosted LLMs run the same framework at different price points, and the full cross-provider pricing comparison lines up Gemini 3.1 Pro's rates against every other major API in one table.

Deployment Quickstart on Spheron

1. Provision a GPU cluster

Go to app.spheron.ai and pick the config matching your chosen model: 4x H100 SXM5 or H200 SXM5 for DeepSeek V4-Flash, 2x H200 SXM5 for MiniMax M3, 8x H100 SXM5 or 4x H200 SXM5 for DeepSeek V4, or 8x H200 SXM5 for GLM-5.2. For SSH setup, follow the Spheron SSH connection guide.

2. Install vLLM and serve

pip install "vllm>=0.9.0"

For DeepSeek V4-Flash on 4x H100/H200:

vllm serve deepseek-ai/DeepSeek-V4-Flash \
  --tensor-parallel-size 4 \
  --enable-expert-parallel \
  --dtype fp8 \
  --kv-cache-dtype fp8_e5m2 \
  --max-model-len 131072 \
  --gpu-memory-utilization 0.90 \
  --host 0.0.0.0 \
  --port 8000

For MiniMax M3 on 2x H200:

vllm serve MiniMaxAI/MiniMax-M3 \
  --tensor-parallel-size 2 \
  --dtype fp8 \
  --kv-cache-dtype fp8_e5m2 \
  --max-model-len 131072 \
  --gpu-memory-utilization 0.90 \
  --host 0.0.0.0 \
  --port 8000

Swap --dtype fp8 for --dtype bfloat16 on GPUs without Hopper-class FP8 tensor cores.

3. Point your existing Gemini SDK code at the self-hosted endpoint

vLLM exposes an OpenAI-compatible API, so migrating from a Gemini or OpenAI-style client is a base URL and API key swap:

from openai import OpenAI

client = OpenAI(
    base_url="http://YOUR_INSTANCE_IP:8000/v1",
    api_key="not-required",
)

See the OpenAI-compatible self-hosted API guide for the full migration checklist if your application currently talks to a managed API SDK.

4. Benchmark and compute your real CPM

wget https://raw.githubusercontent.com/vllm-project/vllm/main/benchmarks/benchmark_serving.py
python benchmark_serving.py \
  --backend vllm \
  --model deepseek-ai/DeepSeek-V4-Flash \
  --request-rate 20 \
  --num-prompts 500

Divide GPU $/hr by (measured tokens/sec x 0.0036) to get your actual CPM, then compare it against your blended Gemini rate from the usage export in step 1. That comparison, not the headline $2/$12 sticker price, is the one that should drive the decision.

If your Gemini 3.1 Pro spend is climbing into the hundreds of millions of tokens a month, or your prompts can't legally leave your own infrastructure, benchmark an open-weight alternative on a rented H200 or H100 cluster before your next contract renewal.

H200 SXM5 on Spheron → | Spheron H100 instances → | View all GPU pricing →