~/ai/ai-application-performance-latency-cost.md

AI Application Performance: Stream First, Shrink the Context, Route the Model

4 min readNovember 01, 2026by Gorav Singal#ai#llm#performance
// TL;DR

LLM apps have two performance budgets — latency and cost — and both are driven by TOKENS. For latency, the biggest win is STREAMING: total work might be ~8.5 s for a 400-token answer, but with streaming the user sees the first token in ~0.5 s (TTFT) instead of staring at a spinner. Then shorten the OUTPUT (you pay per output token in time and money), shrink the CONTEXT (a bloated prompt slows prefill), use a smaller/faster model when it's good enough, and parallelise independent calls. For cost (≈ tokens × price), the big leaks are the context you resend every call, the expensive model you use by reflex, and the identical questions you answer from scratch: fix them with PROMPT CACHING (pay ~0.1× for a cached prefix), MODEL CASCADES (cheap model handles the easy 80%, escalate the hard 20% → ~4× cheaper than flat-expensive), and a SEMANTIC CACHE for repeated questions. Batch and quantize when self-hosting. Measure cost-per-request like you measure latency — most teams find 3–5× of easy savings the first time they look.

AI Application Performance: Stream First, Shrink the Context, Route the Model

LLM applications have two performance budgets that classic backends don’t worry about together: latency (it feels slow) and cost (every request costs real money in tokens). Both are driven by the same thing — tokens — and both have a handful of high-leverage levers. The good news, echoing the measure-first method: most teams find 3–5× of easy savings the first time they actually look. (Numbers below are illustrative but typical; measure your own.)

Latency: stream first, then shrink

The latency of a single LLM call is roughly:

latency ≈ TTFT + (output tokens ÷ tokens-per-second)

TTFT (time to first token) is the wait before anything appears; after that, tokens stream at some tokens-per-second. Output length drives the wait, not input — a long answer is slow to generate, token by token.

LLM latency, stream first and shrink the context: without streaming the user stares at a spinner for the whole ~8.5 s generation; with streaming, the first token appears at ~0.5 s (TTFT) and tokens stream in as they're generated so the UI feels alive — same total work, but felt at 0.5 s. latency is roughly TTFT plus output tokens divided by tokens-per-second, so output length drives the wait, not input. The levers in order that pays off: stream the response, shorten the output, shrink the context, use a smaller or faster model when it's good enough, and do independent work in parallel while caching repeated prompt prefixes.

The levers, in the order that pays off:

  1. Stream the response. This is the single biggest perceived-latency win. The total work might be ~8.5 s for a 400-token answer, but with streaming the user sees the first token at ~0.5 s and reads along as it generates — instead of staring at a spinner for 8 seconds. Same total time, a completely different experience.
  2. Shorten the output. You pay per output token in both time and money. Ask for less, set max_tokens, and don’t make the model restate the question.
  3. Shrink the context. A bloated prompt costs input tokens and slows the prefill step. Send only what’s needed — good RAG that retrieves the right few chunks, not the whole document dumped in “just in case.”
  4. Use a smaller/faster model when it’s good enough, and reserve the big one for hard calls (see routing below).
  5. Parallelise independent work — fire independent tool calls or sub-queries concurrently rather than in series — and cache repeated prompt prefixes so prefill is near-free.

For the latency-critical end of this (voice), the voicebots course treats every one of these as life-or-death.

Cost: cache, route, and right-size the model

LLM cost is mostly tokens × price, and you control both. Three leaks account for most waste: the context you resend on every call, the expensive model you reach for by reflex, and the identical questions you answer from scratch.

LLM cost — cache, route, and right-size the model: prompt caching, where a 2,000-token system prompt resent on every call is pure waste so you cache the prefix and pay about 0.1× for it after the first hit; model cascade and routing, where a cheap model handles the easy 80% and escalates the hard 20% to the big one, so 0.8×$0.25 plus 0.2×$5 is $1.20 versus a flat $5, about 4× cheaper, routing by difficulty not by default; semantic cache, where you cache answers by meaning so a 30% hit-rate means 30% fewer calls and near-instant responses; plus batch and quantize when you self-host. LLM cost is mostly tokens times price and you control both — measure cost per request, set a budget, and alert when it drifts.

  • Prompt caching. A 2,000-token system prompt resent on every call is pure waste. Cache the prefix and you pay roughly 0.1× for it after the first hit — a large saving for apps with big, stable system prompts or shared context.

  • Model cascade / routing. Don’t send everything to the biggest model. Let a cheap model handle the easy 80% and escalate only the hard 20% to the expensive one:

    0.8 × $0.25  +  0.2 × $5   =   $1.20 per 1M tokens (blended)
    vs flat $5                 →   ~4× cheaper

    Route by difficulty (a classifier, a confidence check, or the cheap model saying “I’m not sure”), not by default.

  • Semantic cache. Many users ask the same thing in different words. Cache answers by meaning — embed the query, reuse the answer on a near-match. A 30% hit-rate is 30% fewer model calls and near-instant responses for those users.

  • Batch + quantize when self-hosting. Batch concurrent requests to fill the GPU (throughput up), and quantize (16-bit → 4-bit) to fit a cheaper box — covered in open LLMs in production.

The meta-lesson: measure cost-per-request like you measure latency. Put it on a dashboard, set a budget per feature, and alert when it drifts — the same RED/USE discipline as any backend.

Where AI apps actually get slow and expensive

  • Dumping everything into context. The lazy “stuff the whole document in” approach is the #1 cause of both high cost and slow prefill. Retrieve precisely.
  • Agents that loop too much. Each step in an agent is a full round trip. Cap the steps, parallelise independent tool calls, and cache tool results.
  • No streaming on a chat UI. Users will forgive 8 seconds of streaming; they won’t forgive 8 seconds of blank screen.
  • One model for everything. Using a frontier model for spell-check-grade tasks is where budgets quietly die. Route.
  • Ignoring output length. Verbose system prompts (“explain your reasoning in detail”) multiply output tokens — and thus latency and cost — on every single call.

Takeaways

  • LLM performance is two budgets — latency and cost — both driven by tokens.
  • Latency: stream first (0.5 s TTFT beats an 8 s spinner), shorten output, shrink context, use smaller models, parallelise.
  • Cost (≈ tokens × price): prompt-cache the stable prefix (~0.1×), cascade/route easy traffic to a cheap model (~4× cheaper), add a semantic cache for repeat questions, batch + quantize when self-hosting.
  • Measure cost-per-request on a dashboard with a budget and alerts — most teams find 3–5× of easy savings the first time they look.

This is the AI-specific instalment of the performance series: Performance, Measured (the method), backend performance, and scaling infrastructure. To build on these patterns, see the AI Agent Development and LLM Engineering in Production courses, and the AI engineering vocabulary if any term here was new.

$ subscribe --weekly

One deep dive a week, in your inbox

System design, AI engineering, trading systems and interview prep. Tested code, real numbers. Free, and you can unsubscribe any time.

or read it on gyanbyte.substack.com

Share

Related Posts

Your AI Bill Just Spiked: How to Debug It and Pinpoint the Cause

Your AI Bill Just Spiked: How to Debug It and Pinpoint the Cause

The invoice email lands and your AI spend is 4× last week. The instinct is to…

The AI Engineering Vocabulary: Evals, Guardrails, RAG and the Words That Actually Matter

The AI Engineering Vocabulary: Evals, Guardrails, RAG and the Words That Actually Matter

Every field has a vocabulary you have to own before anything else makes sense…

Building an AI FAANG Interview Coach: Run the Code, Don't Let the LLM Grade It

Building an AI FAANG Interview Coach: Run the Code, Don't Let the LLM Grade It

Ask ChatGPT to “review this solution and tell me if I’d pass the interview” and…

Building an AI Astrology (Kundali) Chatbot: Let the LLM Talk, Let the Ephemeris Do the Math

Building an AI Astrology (Kundali) Chatbot: Let the LLM Talk, Let the Ephemeris Do the Math

Ask ChatGPT “where was Saturn when I was born, 2:30 pm on 15 August 1990 in New…

How to Stay Valuable as a Software Engineer in the AI Era: A Practical Playbook

How to Stay Valuable as a Software Engineer in the AI Era: A Practical Playbook

In the previous article I argued that AI is not killing software engineering…

How to Review AI-Generated Code: A Checklist for Catching What the Model Missed

How to Review AI-Generated Code: A Checklist for Catching What the Model Missed

A few months back I approved a PR that was almost entirely AI-generated. It…

Latest Posts

How to Stay Valuable as a Software Engineer in the AI Era: A Practical Playbook

How to Stay Valuable as a Software Engineer in the AI Era: A Practical Playbook

In the previous article I argued that AI is not killing software engineering…

How to Review AI-Generated Code: A Checklist for Catching What the Model Missed

How to Review AI-Generated Code: A Checklist for Catching What the Model Missed

A few months back I approved a PR that was almost entirely AI-generated. It…

How to Debug AI-Generated Code: Understand First, Fix Last

How to Debug AI-Generated Code: Understand First, Fix Last

In the last article I wrote about reviewing AI code before it goes in. This one…

The Future of Software Engineering: What AI Changes, What Stays, and Where the Jobs Go

The Future of Software Engineering: What AI Changes, What Stays, and Where the Jobs Go

Every few weeks somebody sends me a scary headline — “AI will replace all…

The Transactional Outbox Pattern: Never Lose an Event Again

The Transactional Outbox Pattern: Never Lose an Event Again

This is one of those patterns that looks like nothing until you get burnt once…

Event Sourcing, Explained: Store What Happened, Not Just the Final State

Event Sourcing, Explained: Store What Happened, Not Just the Final State

Here is a question I like to ask in interviews: your bank account shows a…