12 – Cost és Latency¶

Az AI applicationök runtime cost profilja jelentősen eltér a hagyományos application code-tól.

Sok rendszerben nem a saját service CPU ideje a drága rész, hanem a külső model inference.

Alap mentális modell:

request volume
×
input tokens
×
output tokens
×
model price

Ez leegyszerűsítés, de elég ahhoz, hogy lássuk: az architecture decision közvetlenül befolyásolja a costot.

Token-based cost¶

A model API-k gyakran input és output token alapján számláznak.

Koncepcionálisan:

cost = input_tokens × input_price
     + output_tokens × output_price

Példa:

input:  8,000 tokens
output: 1,000 tokens

Ha az application minden requestnél ugyanazt a nagy contextet küldi, a cost gyorsan nő akkor is, ha maga a válasz rövid.

Ezért a context engineering egyben cost engineering is.

A több context nem ingyenes¶

Tegyük fel, hogy egy support assistant ezt küldi:

system prompt          2,000 tokens
conversation history   8,000 tokens
retrieved documents   20,000 tokens
user question            100 tokens

Total input:

30,100 tokens

Ha valójában csak 3 000 token volt releváns, felesleges contextért fizetünk, és a quality is romolhat.

Ezért:

better retrieval
+ better summarization
+ better context selection
=
lower cost and often better quality

Az output token is drága lehet¶

Hosszabb answer több időt és tokent fogyaszt.

Ha az applicationnek csak erre van szüksége:

{
  "category": "billing"
}

akkor explanationt, reasoning summaryt és részletes prose-t kérni felesleges latency és cost.

Az output length igazodjon a product valódi igényéhez.

A cost/request nem elég¶

Production cost a volumetől függ.

Példa:

$0.01 per request
× 100 requests/day
= $1/day

De:

$0.01 per request
× 10,000,000 requests/month
= $100,000/month

Kis per-request inefficiency nagy scale-en jelentőssé válik.

Model selection és cost¶

Nem minden task igényli a legerősebb modellt.

Lehetséges routing:

simple classification → small model
complex reasoning      → stronger model
embedding              → embedding model
image understanding    → multimodal model

Gyakori architecture:

cheap model first
      ↓
can solve?
  ├── yes → return
  └── no  → escalate to stronger model

De a routingot is evaluálni kell. A cheap first step nem hasznos, ha gyakran rosszul dönt vagy felesleges latencyt ad hozzá.

A latency több komponensből áll¶

A teljes user-visible latency tartalmazhatja:

network
+ model queueing
+ model inference
+ retrieval
+ tool calls
+ retries
+ application processing

Hasznos decomposition:

request
 ↓
retrieval      150 ms
 ↓
model call    1800 ms
 ↓
tool call      400 ms
 ↓
second model  1600 ms
 ↓
response

A total nem csak az első model call.

Time to first token vs total time¶

Streaming response esetén két latency fontos.

Time to first token¶

Mennyi idő múlva kezdi látni a user a választ.

Time to completion¶

Mennyi idő kell a teljes answerhez.

Példa:

time to first token: 700 ms
full completion:      6.2 s

Streaming UI reszponzívnak érződhet akkor is, ha a total generation több másodperc.

Streaming¶

A streaming incrementálisan adja vissza az outputot.

model generates
   ↓
token chunks
   ↓
UI displays progressively

A streaming javítja a perceived latencyt, de nem feltétlen csökkenti a compute costot vagy a total completion time-ot.

Főleg user-experience technika.

Parallelism¶

Independent operationök néha párhuzamosan futtathatók.

Sequential:

retrieve docs     500 ms
 ↓
get user profile  400 ms
 ↓
get permissions   300 ms

Total before LLM ≈ 1200 ms

Parallel:

retrieve docs ───────┐
get profile ─────────┼─→ combine
get permissions ─────┘

A total közelíthet a leglassabb operation idejéhez az összeg helyett.

Ne parallelizálj olyan operationt, amely más eredményétől függ.

Az agentic loop megsokszorozza a latencyt¶

Normál call:

user → LLM → answer

Agentic flow:

LLM
 ↓
tool
 ↓
LLM
 ↓
tool
 ↓
LLM
 ↓
answer

Ha minden model call 2 s és minden tool 500 ms:

3 model calls = 6.0 s
2 tool calls  = 1.0 s
---------------------
minimum       = 7.0 s

network overhead és retry előtt.

Az agentic flexibilitynek valós latency costja van.

Az agentic loop a pénzügyi costot is szorozza¶

Egy user request több model callt triggerelhet.

1 user request
 ↓
planner model
 ↓
tool selection
 ↓
result interpretation
 ↓
final generation

Ezért a costot taskonként érdemes követni, nem csak model callonként.

Hasznos metric:

total tokens and cost per completed user task

Caching¶

Caching csökkentheti a costot és latencyt, ha requestek vagy intermediate resultok ismétlődnek.

Lehetséges cache target:

embeddings,
document parsing,
retrieval results,
deterministic tool results,
model responses, ahol biztonságos,
stable prompt prefixes, ha a provider/platform támogatja.

Figyelj:

user-specific data,
authorization,
gyorsan változó information,
stale model output.

A caching correctness decision is, nem csak performance decision.

Embedding cost¶

RAG systemben további cost component van.

Ingestion:

documents
 ↓
chunking
 ↓
embedding generation
 ↓
vector storage

Query time:

query embedding
+ vector search
+ reranking
+ generation

Az embedding cost sokszor jóval kisebb a generation costnál, de large-scale ingestion és gyakori re-indexing mellett számíthat.

Reranking trade-off¶

Retrieval pipeline:

vector search → 50 candidates
      ↓
reranker → top 5
      ↓
LLM

A reranker latencyt és costot ad hozzá, de lehetővé teheti kisebb és relevánsabb final LLM context használatát.

Egy drágább retrieval stage így csökkentheti a total system costot, ha jelentősen javítja a downstream efficiencyt.

Retry csendben megszorozhatja a costot¶

Tegyük fel, egy request $0.02.

Automatic retry:

attempt 1 → timeout
attempt 2 → malformed result
attempt 3 → success

Az actual cost megközelítheti három model call árát.

Trackeld a retry countot és total task costot.

A hosszú prompt infrastruktúrává válik¶

Egy nagy system prompt milliószor ismételve már nem csak documentation.

Recurring runtime cost.

Példa:

system prompt: 4,000 tokens
× 1,000,000 requests
=
4 billion input tokens

Ez nem azt jelenti, hogy a prompt mindig legyen rövid. Hanem hogy a prompt size gazdasági consequence-szel jár.

Cost budgetek¶

Agentic applicationben explicit budget kell.

Példák:

max 8 model calls per task
max 20 tool calls
max 50,000 total tokens
max $0.50 per task
max 30 seconds wall-clock time

Limit elérésekor:

stop
 ↓
return partial result / ask user / escalate

Ez a bounded probabilistic behaviourt kontrollált rendszerré alakítja.

Latency budgetek¶

Indulj a product requirementből.

Példa:

interactive chat response: target < 3 s to first useful output
background document analysis: 30–60 s may be acceptable
nightly offline evaluation: minutes may be acceptable

Az architecture az interaction modeltől függ.

Ami background jobként kiváló, synchronous UI-ban elfogadhatatlan lehet.

Quality, cost és latency trade-off triangle¶

Gyakran:

stronger model
→ better quality
→ higher cost
→ higher latency

Nem mindig, de elég gyakran ahhoz, hogy competing dimensionként kezeljük őket.

Evaluation során mindhármat hasonlítsd össze.

Példa:

Model A
quality: 88%
latency: 1.2 s
cost:    $0.004/task

Model B
quality: 92%
latency: 4.5 s
cost:    $0.040/task

B nem automatikusan jobb product choice.

Példa: document Q&A¶

Version A:

retrieve 20 chunks
send all 20 to strong model

Version B:

retrieve 50 cheap candidates
 ↓
rerank
 ↓
select 5 chunks
 ↓
use medium model

B plusz retrieval stage-dzsel is lehet:

olcsóbb,
gyorsabb,
pontosabb,

mert a final context kisebb és tisztább.

Az architecture-t end-to-end kell mérni.

Példa: classification scale-en¶

Task: 20 millió message/hó klasszifikálása.

Architecture A:

strong reasoning model for every message

Architecture B:

small classifier model
 ↓
ambiguous cases only
 ↓
strong model

Már mérsékelt sikerű routing strategy is nagy pénzügyi hatású lehet ilyen volumen mellett.

A cost legyen production metric¶

Hasznos metric:

input tokens/request,
output tokens/request,
model calls/task,
tool calls/task,
cost/task,
cost/user,
cost/feature,
p50/p95 latency,
time to first token,
retry rate,
cache hit rate.

Ne a havi számlából derüljön ki az architecture problem.

Mérj, aztán optimalizálj¶

Premature optimization itt is kockázat.

Ésszerű progression:

1. make it work
2. evaluate quality
3. measure cost and latency
4. identify dominant cost
5. optimize the bottleneck

Ne cserélj reliable modellt olcsóbbra pusztán token price alapján a teljes system evaluation nélkül.

Mentális modell¶

Minden AI workflow-t graphként képzelj el, ahol minden node-nak van:

quality contribution
latency
cost
failure probability

A cél nem a model price minimalizálása.

A cél a total task economics és user experience optimalizálása a szükséges quality és safety megtartásával.