AI Infrastructure & CostField engagement

The problem was not the prompts or the model. It was that near-identical work was recomputed every time.

Architecture and delivery lead.
48%
fewer requests to the model
44%
lower average latency
58%
lower monthly cost
60,000+
requests a day
averagep99the kneeloadlatency
Under load the average looks fine while the tail falls off a cliff. Users feel the slowest requests, not the mean.
What was at stake

A platform handling more than 60,000 requests a day where the accuracy was fine but the monthly bill was not, because near-identical requests, repeated prompts, embeddings, retrieval, and reasoning, had no caching anywhere. Runaway inference cost on high request volume, where the bill rather than the accuracy is what threatens the product.

The constraint

The stated problem reads as accuracy or model choice, because those are the levers everyone knows. The real problem is cost architecture: the absence of caching around near-identical work. Optimizing prompts on a system with no cache reduces the price of each redundant computation without reducing the redundancy.

app tier12%
cache8%
waiting on the database74%
network6%
Where the request time actually goes. Scaling the app tier does nothing when the system is waiting on the database.
The fork

The reflex, and the fix.

Road not taken

Optimize the prompts

Pull

It is the accessible lever, it needs no architecture change, and it shows an immediate per-call improvement.

Why not

It lowers the cost of work that should never have been repeated. The savings are bounded by the price of a call, and the problem is the number of calls.

Road taken

Optimize the architecture around the models

Accepted

A layered cache across the request path and a compiled-language rewrite of the high-throughput queue.

Bought

Most requests turning back at a cache layer before they ever reach a model.

Decision

Attack the redundancy rather than the unit price, because the redundancy is where the bill lives.

How it was built
01In-memory
02Semantic
03Embedding
04Prompt prefix
05Vector
06Response
01

A layered cache across the request path

In-memory, then semantic, then embedding, then prompt-prefix, then vector-lookup, then response. Each layer catches a different shape of near-identical work, and only what escapes all six reaches a model.

02

The queue rewritten for throughput

High-throughput queue processing moved to a compiled language, with the scripting layer kept only for inference orchestration, which is what it is actually good at.

03

Tracing before and after

Because a cache that is not measured is a cache that is silently missing, and a hit rate is the only evidence that the architecture is doing what it claims.

How it was measured

A single headline number hides where a system fails. This work was scored on the dimensions that actually decide whether it holds in production, measured on real, held-out cases rather than the demo path.

Requests reaching the modelAverage and tail latencyMonthly inference costThroughput at fixed hardware
figures

Figures confirmed as proven. The rendered client quote associated with this engagement is deliberately not published.

What it produces
Without this discipline

Shorter prompts, a marginally cheaper call, and the same volume of redundant computation, with the bill still growing linearly against usage.

This system

A layered cache across the request path plus a compiled-language rewrite of the high-throughput queue, so near-identical work is served from cache and the scripting layer is reserved for inference orchestration. 48 percent fewer requests to the model, 44 percent lower average latency, 58 percent lower monthly inference cost, and roughly twice the throughput, with the savings paying for the project within weeks.

six cache layerscompiled workersscripting for orchestration onlymeasured hit rates
The operating envelope

What it owns, and what it hands to a person.

Handled with confidence
High-volume near-identical request patterns
Prompt, embedding, retrieval, and response reuse
Flagged for review
Request classes where semantic reuse is not acceptable
Out of scope by design
Workloads with genuinely unique requests
The honest limit

A semantic cache trades a small amount of exactness for a large amount of cost, and that trade has to be chosen deliberately per request class rather than applied globally. The gains are proportional to how much near-identical work exists, which is why the measurement came before the architecture.

What it generalizes to

When a bill grows with usage and the accuracy is already fine, the problem is almost never the model. Measure how much of the work is repeated before optimizing the price of doing it.

How we engage

You have a system like this one.
Tell us where it stands.

Whether it is failing, not yet built, or about to meet a scale it has never seen, we can tell you what we see.

Start a conversation
mostafa@opulion.dev · Response within 24 hours · By inquiry