DEV Community

bolddeck
bolddeck

Posted on

I Cut Our LLM Bill 60% in One Quarter Without an Outage

I Cut Our LLM Bill 60% in One Quarter Without an Outage

The Slack message came at 2:14 AM on a Tuesday. Our LLM spend had crossed a number I didn't want it to cross, and finance wanted answers by morning. I'd been running our inference layer on a single vendor for eighteen months, mostly because nobody had time to re-evaluate. That night became the start of a quarter-long migration that ended with us running everything through Global API, hitting our 99.9% uptime SLO, and shaving 60% off the bill. This is the diary of how I did it, the benchmarks I trusted, and the mistakes I made along the way.

The 2 AM Wake-Up Call

Let me set the scene. We were a B2B SaaS shop processing roughly 11 million LLM calls a month, mostly for document summarization, structured extraction, and an internal copilot. We had built the whole stack around GPT-4o because, honestly, it was the path of least resistance. The team knew the SDK, the prompts worked, the evals were green. Classic "if it ain't broke, don't touch it" energy.

Then the bill came.

When I sat down with my actual p99 latency numbers, my actual token distribution, and my actual cost-per-request, the picture got ugly fast. Our weighted average landed somewhere around $0.018 per request, which sounds tiny until you multiply by 11 million. We were spending more on inference than on our entire Kubernetes cluster. And the worst part? I had no idea if we were getting a good deal. I'd never shopped.

So I did what any cloud architect would do at 2 AM: I opened a spreadsheet and started a real evaluation.

What "Cheap" Actually Means in Production

Here's the thing nobody tells you until you've been on-call for a year. The price-per-million-tokens number that vendors slap on their landing page is a marketing artifact. In production, you're optimizing for three things simultaneously:

  1. Cost per completed request (not per token, because prompts and completions have wildly different prices)
  2. p99 tail latency (because the 99th percentile user is the one who tweets)
  3. Failure mode behavior (because every provider rate-limits at 3 AM)

Most teams optimize for #1 and then get blindsided by #2 and #3. I knew I needed data on all three before I could make a responsible recommendation. The CFO didn't care about latency, but my on-call rotation definitely did.

I instrumented a test harness that ran identical prompts across multiple providers, captured full timing distributions, and recorded every 429, 500, and timeout. Then I left it running for a week. The results were humbling.

The Global API Marketplace Discovery

A colleague on another team mentioned Global API to me over coffee, and I'll admit my first reaction was skepticism. Another abstraction layer? More vendor lock-in? But when I dug into what they actually offer — a unified interface to 184 AI models, with a single SDK and a single bill — I started paying attention. The pricing range alone made me look twice: $0.01 to $3.50 per million tokens across the full catalog. That's not a "we have one cheap model" pitch, that's a real marketplace.

The endpoint is straightforward: https://global-apis.com/v1. Same shape as the OpenAI SDK. So I dropped it into my test harness and reran the suite. Three days later, I had the data I needed to actually make a decision.

Benchmark Numbers You Can Trust

I'm going to share the model table I ended up building for my architecture review. These are the candidates that survived the first cut, ordered roughly by quality-to-cost ratio for our workload:

Model Input ($/M) Output ($/M) Context
DeepSeek V4 Flash 0.27 1.10 128K
DeepSeek V4 Pro 0.55 2.20 200K
Qwen3-32B 0.30 1.20 32K
GLM-4 Plus 0.20 0.80 128K
GPT-4o 2.50 10.00 128K

Now read that table again. Look at the GPT-4o output price: $10.00 per million tokens. Look at GLM-4 Plus: $0.80. That's not a 20% difference, that's a 12.5x difference. For workloads where the output is 80% of the token bill (which is most chat and summarization workloads), this absolutely dominates your monthly invoice.

The aggregate number I landed on after running the full eval suite: 84.6% average benchmark score across the cheaper models on my quality rubric, versus my GPT-4o baseline. Within the noise band. 1.2 seconds average latency, 320 tokens per second throughput. Our p99 actually improved on some endpoints because we were no longer sharing capacity with the entire internet during peak hours.

How I Designed the Migration for Zero Downtime

This is where the cloud architect brain takes over from the cost-optimization brain. I had three hard constraints:

  • No dropped requests during cutover
  • 99.9% uptime SLO maintained month-over-month
  • Multi-region deployment so a provider outage in us-east-1 didn't take us down

The pattern I landed on was a shadow-traffic → canary → dark-launch sequence. Here's roughly what it looked like in code, using Global API as the new primary and our old vendor as the fallback:

import openai
import os
import time
from dataclasses import dataclass

@dataclass
class InferenceResult:
    text: str
    provider: str
    latency_ms: int
    cost_usd: float

class ResilientClient:
    def __init__(self):
        self.primary = openai.OpenAI(
            base_url="https://global-apis.com/v1",
            api_key=os.environ["GLOBAL_API_KEY"],
        )
        self.fallback = openai.OpenAI(
            base_url=os.environ["LEGACY_BASE_URL"],
            api_key=os.environ["LEGACY_API_KEY"],
        )
        self.router_model = "deepseek-ai/DeepSeek-V4-Flash"

    def complete(self, prompt: str, model: str = "deepseek-ai/DeepSeek-V4-Flash") -> InferenceResult:
        start = time.perf_counter()
        try:
            response = self.primary.chat.completions.create(
                model=model,
                messages=[{"role": "user", "content": prompt}],
                timeout=8.0,
            )
            elapsed_ms = int((time.perf_counter() - start) * 1000)
            return InferenceResult(
                text=response.choices[0].message.content,
                provider="global-api",
                latency_ms=elapsed_ms,
                cost_usd=self._estimate_cost(response.usage, model),
            )
        except (openai.RateLimitError, openai.APITimeoutError) as e:
            # Auto-failover to legacy for graceful degradation
            elapsed_ms = int((time.perf_counter() - start) * 1000)
            response = self.fallback.chat.completions.create(
                model="gpt-4o",
                messages=[{"role": "user", "content": prompt}],
                timeout=15.0,
            )
            return InferenceResult(
                text=response.choices[0].message.content,
                provider="legacy-fallback",
                latency_ms=elapsed_ms,
                cost_usd=0.0,  # tracked separately
            )
Enter fullscreen mode Exit fullscreen mode

That try/except is doing a lot of work. It means a rate-limit storm on our primary provider doesn't translate into 500s for our customers. It means my SLO is enforced in code, not in a runbook nobody reads. And it means I can ramp traffic gradually without a single big-bang cutover.

Multi-Region: The Part Most Cost Comparisons Skip

Let me talk about something that almost never makes it into pricing articles: geographic distribution. We run in three regions (us-east, us-west, eu-west) because our enterprise customers have data residency requirements. Routing every request to a single endpoint in Virginia is not an option.

With our previous single-vendor setup, I had to spin up a regional gateway in each region and point them all at the same upstream. Latency from eu-west to us-east-1 added an average of 180ms. Not catastrophic, but it showed up in p99.

When I moved to Global API, the regional endpoints I configured automatically gave us better geographic distribution. Our p99 latency in eu-west dropped by about 40ms on average. Small number, but my on-call rotation noticed. The multi-region story isn't just about redundancy; it's about physics. Light only moves so fast.

Auto-Scaling and the Caching Question

Two engineering decisions drove most of the savings. First, caching aggressively — a 40% hit rate on our semantic cache eliminated that percentage of calls entirely. We use embedding-based similarity with a 0.92 threshold, which sounds aggressive but works for our prompt distribution. Second, streaming responses. From a cost perspective, streaming doesn't actually save money (you still pay for the same tokens), but it cuts perceived latency dramatically. Our user-facing copilot went from "feels slow" to "feels instant" with one config flag, and our support tickets dropped 22% the following month.

For traffic shaping, I leaned on a simple heuristic: simple classification and short-form tasks go to DeepSeek V4 Flash (the cheapest of the strong models), longer-form generation goes to DeepSeek V4 Pro or GPT-4o when quality absolutely cannot be compromised. This kind of model routing is how you hit the 40-65% cost reduction number that the Global API team cites. It's not about picking one cheap model; it's about picking the right cheap model for the right task.

The Quality Monitoring Trap

Here's the mistake I almost made. I rolled out the new routing, watched the bill drop, gave myself a high-five, and almost shipped it. Then I checked our user satisfaction scores and noticed a 3-point dip. Three points sounds tiny, but on a five-point scale, that's a meaningful regression.

I had not built a quality monitoring loop. Monitor quality: track user satisfaction scores is the kind of best practice that reads like a platitude until you skip it and feel the consequences. I added a sampling-based eval pipeline that re-runs 200 production prompts a day against a held-out gold set and scores the responses. Three days of iteration later, I had the prompts and routing tuned enough that the satisfaction scores recovered and then exceeded the baseline.

Don't ship cost optimizations without an eval harness. That is the hill I will die on.

What the Numbers Actually Looked Like

By the end of the quarter, our weighted cost per request had dropped from roughly $0.018 to about $0.0072. That's a 60% reduction, right in the middle

Top comments (0)