Optimalizace latency pro realtime AI aplikace

Proč je latence rozhodující pro realtime AI

Realtime AI aplikace – od asistenčních agentů přes hlasové asistentky až po systémové automatizace ve firmách – stojí a padají na latenci. Uživatelé vnímají rozdíl mezi 200 ms a 2 s jako propast. Latence ovlivňuje konverzi, spokojenost i provozní náklady (delší běhy zvyšují účty za infrastrukturu). V generativních scénářích navíc záleží nejen na čase první odpovědi (TTFB), ale i na plynulosti streamování a čase do „užitečné části“ (TTUR – time to useful result).

Optimalizace latence není jeden trik, ale vrstvená disciplína: síť, fronty, model, runtime, paměť, cache, orchestrace a řízení provozu. Cílem tohoto článku je dát vám konkrétní návod – jak změřit, kde latence vzniká, a jak postupně snižovat p95/p99 bez degradace kvality a bez explodujících nákladů.

Základní pojmy: p50/p95/p99, TTFB, TTFR, TPS a „tail“

• p50/p95/p99: percentily latence. p99 je „ocas“ – má zásadní vliv na UX i SLA, a proto se na něj zaměřujeme prioritně.
• TTFB (Time To First Byte): čas do prvního znaku/byte. Kritický pro vnímanou rychlost.
• TTFR (Time To First Reasonable – první rozumný obsah): u generativních odpovědí je důležité, kdy se objeví první užitečná část, ne jen první token.
• TPS/Tok/s: rychlost generování tokenů. Vliv má velikost modelu, kvantizace, attention optimalizace i KV cache.
• Tail latence: dlouhé „ocasy“ způsobené vyčerpáním zdrojů, studenými starty, page faulty, nespolehlivými nástroji, zahlcením sítě nebo příliš velkým fan-out.

Praktické SLO pro chatové rozhraní v produkci může znít: p95 TTFB ≤ 400 ms, p95 TTFR ≤ 2,0 s, p99 TTFR ≤ 3,5 s, průměrná plynulost ≥ 25 tokenů/s u odpovědí do 700 tokenů. U hlasových aplikací je cíl často přísnější (TTFB desítky ms díky streamování přes gRPC/HTTP/2 a krátkým bufferům).

Měření a profilace: jak zjistit, kde latence skutečně vzniká

Bez profilace se optimalizace mění v hádání. Každý požadavek sledujte napříč vrstvami: edge → LB → API gateway → auth → context build (retrieval, serializace) → inference → postprocess → policy/validace → stream/doručení. Ke každému kroku logujte čas zahájení, trvání, chybovost a vrácené hodnoty (např. délka kontextu, top-k v RAG, velikost odpovědi).

• Traces: unikátní trace_id a spany pro jednotlivé fáze. Umožní korelaci latencí v čase i mezi službami.
• Profilace modelu: měřte samostatně prefill (zpracování promptu), decode (generování), KV hits a přístupy do paměti.
• Segmentace: rozlišujte dotazy podle délky, jazyka, zařízení, tenantu, přítomnosti nástrojů (tool calls) a velikosti kontextu.
• Drift: sledujte změnu mixu dotazů – latence se často „zhorší“ jen proto, že přibylo dlouhých kontextů nebo více nástrojů.

Zásadní je rozpad latence v dashboardu: stacked graf podle kroků. Jakmile víte, že 45 % času padá na retrieval a 35 % na inference, víte, kam zamířit první iteraci.

Architektura pipeline: od požadavku po doručení

1. Edge & gateway: terminace TLS blízko uživatele, HTTP/2/3, prioritizace, rychlé auth.
2. Context build: normalizace, detekce jazyka, RAG retrieval (vyhledání kandidátů), serializace promptu.
3. Inference: volání modelu, využití KV cache, streaming, spekulativní dekódování.
4. Post-processing: validace formátu (JSON), kontrola citací, bezpečnostní filtry.
5. Doručení: SSE/WebSocket/gRPC streaming a backpressure do UI.

Cílem je minimalizovat synchronní kritickou cestu: každou část, která nemusí být „na cestě“, přesunout asynchronně (přednačítání, cache warm-up, lazy validace za „TTFR hranicí“, pokud to bezpečnost dovolí).

Síť a transport: TLS, HTTP/2, HTTP/3, gRPC, WebSocket a komprese

• Keep-alive a multiplexing: snižují overhead handshaků; u streaming API preferujte HTTP/2/gRPC nebo WebSocket.
• Komprese: u krátkých odpovědí bývá overhead větší než přínos; u delších streamů je rozumné zvolit lehkou adaptivní kompresi.
• Edge kolokace: regionální nasazení blíž k uživateli sníží RTT; vyhněte se zbytečnému egress mezi cloudy.
• Prioritizace streamu: nejdřív metadata pro UI (TTFB), pak payload. Krátké „úvodní tokeny“ zlepšují percepci rychlosti.

Fronty a kapacita: Littleův zákon, backpressure, time-budget

Littleův zákon říká: L = λ × W (počet požadavků v systému = přítok × průměrná doba). Pokud je fronta dlouhá, zkraťte W (rychlejší zpracování) nebo snižte λ (throttling, řízení fronty), případně zvyšte paralelismus (kapacitu), ale s pozorem na přetížení paměti.

• Backpressure: když systém nestíhá, odmítejte, omezujte nebo degradujte (menší kontext, bez rerankingu).
• Time-budget per request: nastavte horní časovou hranici a při jejím blížení aktivujte „degraded mode“.
• Prioritizace: placení zákazníci/urgentní požadavky mohou mít rychlejší frontu a dedikované zdroje.

Batching a micro-batching: kdy, jak a s jakými kompromisy

Batching zvyšuje využití GPU/CPU, ale může zhoršit TTFB, pokud čekáte na „naplnění“ dávky. Ideální je adaptivní micro-batching s limity: maximální latence čekání, maximální velikost dávky, a continuous batching pro generativní modely (přimíchávání nových požadavků mezi kroky dekódování).

• Prefill vs. decode: prefill (dlouhý prompt) škáluje s šířkou dávky jinak než decode (generování); oddělené tunování.
• Heterogenní délky: krátké dotazy v jedné dávce s extrémně dlouhým promptem trpí; zvažte bucketing podle délky.
• SLA-aware batching: rychlé proudy pro „low-latency tier“ a větší dávky pro „throughput tier“.

Klíč je TTFB limit při čekání na dávku (např. ≤ 30–50 ms). Pokud se dávka nenaplní, spusťte menší – udržíte nízkou vnímanou latenci.

Streaming výsledků: TTFB, plynulost a UX

Streamování (SSE/gRPC/WebSocket) dramaticky zlepšuje percepci rychlosti. Uživatelům nezáleží, jestli celá odpověď trvá 3 s, pokud první užitečný obsah dorazí do 300–500 ms a tok je plynulý.

• TTFB optimalizace: posílejte okamžitě „start“ event s metadaty (jazyk, odhad délky), poté první tokeny.
• Plynulost: sledujte průměrný i p95 interval mezi dvěma chunk/tok událostmi; cílem je stabilní „rytmus“.
• Token budgeting: u ořezu odpovědi preferujte dokončení myšlenky před tvrdým stopem.

Caching: prompt cache, KV cache, výsledková cache, embedding cache

Cache je nejrychlejší optimalizace, ale potřebuje pravidla invalidace. Rozlište čtyři vrstvy:

1. Prompt cache: hash normalizovaného promptu a kontextu. Zvažte fuzzy klíče (MinHash/LSH) pro „téměř stejné“ dotazy.
2. KV cache: ukládá klíč-hodnota stavy pozornosti; šetří práci při dekódování a u opakovaných prefixů.
3. Výsledková cache: u deterministických dotazů (FAQ, definice). Pozor na personalizaci a oprávnění.
4. Embedding cache: výrazně zlevňuje retrieval a deduplikuje práci u stejných dokumentů.

Stanovte politiky invalidace: změna modelu, promptu, indexu, oprávnění nebo čerstvosti by měla cache vyloučit. Měřte „cache hit-rate“ per vrstva a podívejte se, jak ovlivňuje p95.

Kvantizace, komprese a optimalizace modelů

Kvantizace snižuje šířku čísel (např. FP16 → INT8/INT4) a tím paměť i šířku pásma. Správně provedená kvantizace přináší výrazné zrychlení s minimální ztrátou kvality.

• PTQ vs. QAT: post-training quantization (rychlá) vs. quantization-aware training (vyšší kvalita). Pro inference-first projekty často stačí PTQ s kalibrační sadou.
• Směrování outlierů: metody, které nechají „výjimkové“ kanály ve vyšší přesnosti (např. mixed-precision), zmenšují dopad na kvalitu.
• INT8/INT4/FP8: INT8 je dobrý „default“, INT4 pro agresivní kompresi (větší ztráta kvality, ale velké zrychlení), FP8 pro moderní GPU.
• Pruning a distilace: drobné ztráty kvality často vyváží zásadní zisk v latenci a paměti – zvlášť u doménových modelů.

Každou změnu měřte na zlaté sadě: nDCG@k/EM/F1 i p95/p99, a porovnejte cost-per-good-answer. Kvantizace nesmí zničit byznysovou kvalitu.

Runtime optimalizace: grafové exekuce, attention optimalizace, spekulace

• Grafové exekuce a kernel fusion: minimalizují overhead plánování a přepínání; vyplatí se pro stabilní topologii.
• Flash/Paged Attention: efektivnější práce s pamětí a cache; zásadní pro dlouhé kontexty.
• Spekulativní dekódování: menší „průkopnický“ model generuje návrh, větší model verifikuje; výrazně zkracuje TTFR.
• Constraint/grammar decoding: omezuje prostor tokenů; může zrychlit a zároveň zlepšit validitu JSON/CSV výstupů.
• Prefix/Prompt caching: sdílení prefixů mezi požadavky (stejný systémový prompt, stejné instrukce) snižuje prefill čas.

Paměť a správné hospodaření s KV cache

KV cache vede k obrovským ziskům latence, ale je to „žrout“ paměti. Potřebujete politiky: kdo může cache používat, jak ji dělit mezi tenanty, jak ji eviktovat a jak předcházet fragmentaci.

• Sliding-window attention: udržujte jen poslední relevantní kontext; staré pozice „odřezávejte“.
• Attention sink tokens: pomohou stabilitě generování po částečném ořezu kontextu.
• Eviction: LRU/LFU podle tenantu a SLA; kritické požadavky mají vyhrazení.
• Fragmentace: plánujte „defragmentační“ okna mimo špičku; pomáhá i bucketing délky požadavků.

Hardware a plánování: GPU/CPU/DPU, NUMA, MIG, kolokace

• Volba akcelerátoru: malé modely (kvantizované) běží dobře i na CPU s vektorizací; velké dekodéry profitují z GPU s rychlou HBM a NVLink.
• MIG/partitioning GPU: izolujte tenantry a SLA; minimalizujte „noisy neighbor“ efekt.
• NUMA a pinning: držte vlákna a paměť lokálně (stejný socket), omezíte latency skoky.
• Kolokace: inference servery ve stejném regionu jako vector DB a klíčová data; snižte egress a RTT.
• Power/clock tuning: extrémní peak výkon není vždy optimální; stabilní profil často lépe drží p95.

RAG a retrieval: jak zrychlit „před“ i „po“ inference

U RAG často padá značná část latence na retrieval→rerank→serializace. Optimalizace:

• Hybridní retrieval: lexical (BM25) + vektor; nejprve agresivní filtr (jazyk, tenant, čas), potom ANN top-k.
• Reranking: používejte adaptivní cutoff; nenechávejte stovky kandidátů, pokud stačí 40–80.
• Chunking: rozumné velikosti (např. 400–1200 tokenů); příliš velké chunky zpomalují i zhoršují relevanci.
• Cache citací: opakovaně kladené otázky mají velmi podobné zdroje; cache na úrovni citací zkrátí čas.
• Paralelní prefetch: pokud UI dovolí, načtěte top-k pasáže „vedle“ inference a slaďte až při streamu.

Nástroje/Tool-use: plánování, backoff a kontrakty

Každé volání nástroje (API, DB, kalkulačka) je latencí i rizikem. Orchestrujte:

• Kontrakty a validace: schéma argumentů a návratových hodnot; chybné volání stojí desítky sekund.
• Backoff a retries: exponenciální, ale s limitem; metriky „tool_fail_rate“ a „loop_rate“.
• Paralelizace vs. sekvence: paralelizujte jen nezávislé kroky; jinak zbytečný fan-out zvyšuje tail.
• Cache nástrojů: deterministické nástroje cachujte na dobu rozumné čerstvosti.

Autoscaling: reaktivní a prediktivní, warm pool a cold start

• Signály škálování: front depth, p95/p99, GPU/CPU util, čekací doba před inference.
• Warm pool: předehřáté instance eliminují studené starty (model už v paměti, cache připravená).
• Prediktivní škálování: u pravidelných špiček (pracovní doba) je účinnější než čistě reaktivní.
• Degradované režimy: při nedostatku kapacity automaticky menší kontext, bez rerankingu, jednodušší model.

OS a runtime: vlákennost, GIL, scheduler, I/O a minimalistické kontejnery

• Asynchronní I/O: snižuje blokování; u Pythonu omezte GIL dopadem (multiprocess, nativní exekuce kritických částí).
• Pinning a affinity: omezte migraci vláken; NUMA awareness.
• Minimalistické runtime obrazy: méně vrstveného balastu → nižší cold-start i menší bezpečnostní plocha.
• Telemetry bez overheadu: sampling traces/matek s ohledem na critical path; příliš mnoho logů zvýší p95.

Testy, benchmarky, SLO/SLI a runbooky

Vytvořte zlaté sady pro výkon i kvalitu. Každý release porovnávejte: p95/p99, TTFB, TTFR, tok/s, cost, kvalitu (nDCG@k/EM/groundedness). SLO nastavte realisticky a navazte na alerty a runbooky.

Příklad SLO/SLI pro chatový asistent

• p95 TTFB ≤ 400 ms; p95 TTFR ≤ 2,0 s; p99 TTFR ≤ 3,5 s.
• Průměrný tok ≥ 25 tok/s pro odpovědi ≤ 700 tok.
• Policy/format pass-rate ≥ 99,5 %; tool_fail_rate ≤ 1 % / den.
• Cost-per-good-answer stabilní v ±10 % po releasu.

Runbook: p99 TTFR > 3,5 s (30 min)

1. Zkontroluj front depth, queueing latency a GPU/CPU util.
2. Změř prefill vs. decode, ověř KV hit-rate a délky kontextů.
3. Dočasně sniž top-k a hloubku ANN, vypni reranking u RAG.
4. Aktivuj „degraded mode“: menší model, kratší kontext, vypni nástroje s chybovostí > X %.
5. Validuj, že policy/format pass-rate zůstává ≥ 99,5 %.
6. Post-mortem: kořenová příčina, prevence, akční body.

Rozhodovací matice: od symptomu k řešení

Kontrolní seznamy: rychlá praxe pro týmy

Checklist: měření a observabilita

• Traces pro každý krok: edge → retrieval → inference → postprocess → stream.
• Metriky: p50/p95/p99, TTFB, TTFR, tok/s; rozpad na prefill/decode.
• Segmentace metrik (jazyk, délka, device, tenant).
• Zlaté sady a replay; spektra dotazů (krátké/dlouhé, s nástroji/bez).

Checklist: rychlé zisky latence

• HTTP/2/gRPC streaming, keep-alive, regionální edge.
• Adaptivní micro-batching s časovým limitem čekání.
• Prompt/prefix cache a KV cache s jasnou politikou.
• Spekulativní dekódování a omezení top-k/top-p, pokud kvalita dovolí.

Checklist: RAG optimalizace

• Filtry před ANN (jazyk, tenant, čas); menší top-k.
• Adaptivní rerank cutoff, cache citací.
• Chunking 400–1200 tokenů a deduplikace.

Checklist: stabilita a tail

• Backpressure a time-budget per request.
• Warm pool, prediktivní škálování.
• Degradované režimy; „kill switch“ pro nástroje s chybovostí.

Roadmapa zavedení krok za krokem

1. V1 – Viditelnost: zaveďte tracing a metriky; postavte dashboard s rozpadovou latencí.
2. V2 – Síť & streaming: HTTP/2/gRPC, keep-alive, regionální edge; stream první token do 300–500 ms.
3. V3 – Cache: prompt/prefix/KV/výsledková cache s invalidací; sledujte hit-rate.
4. V4 – Batching: adaptivní micro-batching s limitem čekání; bucketing podle délek.
5. V5 – Model: kvantizace, spekulativní dekódování, attention optimalizace; měřte kvalitu.
6. V6 – RAG: filtry, menší top-k, adaptivní rerank; citace cache a prefetch.
7. V7 – Provoz: autoscaling signály, warm pool, degraded módy a runbooky.
8. V8 – Zralost: SLA/SLO, pravidelné load testy, post-mortem disciplína, plán verzí modelů a indexů.

Antipatterny a nejčastější chyby

• Měření průměru místo p95/p99: průměr lže; optimalizujte tail.
• Jeden velký batch bez limitu čekání: zabijete TTFB.
• Bez invalidace cache: vracíte zastaralé nebo neautorizované výsledky.
• Přehnaný fan-out do nástrojů: latence i náklady vyletí, tail trpí.
• RAG bez filtrů: top-k zbytečně velké, rerank drahý a pomalý.
• Žádné degradované režimy: při špičce spadnete místo zhoršení kvality.
• Bez regionální kolokace: platíte egress a RTT, které nepotřebujete.

FAQ: stručné odpovědi pro stakeholdery

Jak rychle můžeme zlepšit TTFB pod 500 ms?

Streaming přes HTTP/2/gRPC, adaptivní micro-batching s limitem čekání, warm pool a prefix cache často stačí během jedné iterace.

Kde bývá „největší ztráta“?

U dlouhých promptů (prefill), v RAG (pomalé filtry/rerank) a u přehnaného fan-outu do nástrojů.

Nezničí kvantizace kvalitu?

INT8 je bezpečný start. Vždy měřte na zlaté sadě; u doménových modelů zvažte distilaci a mixed-precision pro outliery.

Proč p99 tolik bolí?

Uživatelé si pamatují nejhorší zkušenost. p99 rozhoduje o NPS i o tom, zda vaše SLA dává smysl.

Jak řídit náklady a latenci zároveň?

Routing (levnější model pro jednoduché případy), cache, adaptivní cutoff u rerankingu, prediktivní škálování a degradované režimy.

Závěr: architektura pro nízkou latenci

Optimalizace latency u realtime AI není jednorázová akce, ale systém. Začněte měřením a rozpadovým pohledem, nastavte streaming a síť, zaveďte cache s jasnou invalidací, dolaďte micro-batching a KV management, kvantizujte a použijte moderní attention a spekulativní dekódování. U RAG nejprve filtrujte, zmenšete top-k a omezte reranking; u nástrojů hlídejte kontrakty a backoff. Stabilitu drží backpressure, time-budgety, warm pool a prediktivní škálování. Nad tím vším stojí SLO/SLI a runbooky, které dělají z výkonu proces, ne jednorázový „hack“.

Pokud se budete rozhodovat podle dat – p95/p99, TTFB/TTFR, tok/s, cost-per-good-answer a kvalita na zlaté sadě – dojdete k architektuře, která je rychlá, předvídatelná a ekonomicky udržitelná. To je skutečný standard realtime AI: rychlost bez kompromisu bezpečnosti a kvality.