Vezetői összefoglaló
A felhasználók nem várnak. A Google kutatása szerint 53% elhagyja a weboldalt, ha 3 másodpercnél többet kell várni. Az AI válaszideje — különösen az LLM-alapú rendszereké — természeténél fogva másodpercektől percekig terjedhet. Egy komplex kérdés megválaszolása tool calling-gel, RAG kontextussal és több iterációval 5–15 másodpercig tarthat.
A kérdés nem az, hogyan gyorsítsuk fel az AI-t (az LLM válaszideje fizikai korlát). A kérdés: hogyan tegyük a várakozást észrevétlenné?
Ez a whitepaper a valós idejű AI kommunikáció teljes architektúráját mutatja be:
- Streaming protokollok — SSE, WebSocket, HTTP/2 Server Push
- Token streaming — az LLM válasz karakterenként való megjelenítése
- Multi-fázisú streaming — tool calling + gondolkodás + válasz kombinálása
- Latency optimalizáció — TTFB, cold start, connection pooling
- Produkciós kihívások — load balancing, reconnect, error handling
- UX pattern-ek — skeleton, typing indicator, progressive rendering
- Az iparági irány — 2025–2026 trendek, szabványok
1. Miért más az AI streaming, mint a hagyományos streaming?
1.1 A klasszikus web: request-response
A hagyományos web kommunikáció egyszerű: a kliens küld egy kérést, a szerver válaszol. A válasz teljes egészében megérkezik, és a kliens megjeleníti.
Kliens ── GET /api/data ──▶ Szerver
│ (feldolgozás: 50ms)
Kliens ◀── 200 OK + JSON ── Szerver
Működik, ha a válasz milliszekundumok alatt kész. Nem működik, ha a szerver 8 másodpercig gondolkodik.
1.2 Az LLM válasz természete
Az LLM-ek (GPT-4o, Claude, Gemini) token-ról token-ra generálják a választ. Egy 500 tokenes válasz nem egyszerre készül el — hanem egyenként, bal→jobb irányban, ~20–80ms/token sebességgel.
Idő: 0ms 50ms 100ms 150ms 200ms ... 8000ms
Token: "A" "z" "ügyfél" "már" "3" ... "[END]"
Ha megvárod, amíg az egész válasz elkészül, és utána küldöd el a kliensnek, a felhasználó 8 másodpercig egy üres képernyőt néz. Ha token-ról token-ra küldöd, az első karakter 50ms alatt megjelenik — és a felhasználó azt érzékeli, hogy az AI „azonnal" válaszol.
1.3 A percepció pszichológiája
A streaming nem csökkenti a tényleges válaszidőt. Csökkenti a Time to First Byte (TTFB)-t — azt az időt, amíg a felhasználó az első karaktert látja. Ez a különbség 50ms és 8s között — és ez a különbség az „azonnali" és az „elfogadhatatlan" élmény között.
2. A streaming protokollok: SSE, WebSocket, és a többiek
2.1 Server-Sent Events (SSE)
Az SSE a legegyszerűbb streaming protokoll: a szerver egyirányú adatfolyamot küld a kliensnek HTTP-n keresztül.
HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive
Transfer-Encoding: chunked
event: message
data: {"type":"token","content":"A"}
event: message
data: {"type":"token","content":"z"}
event: done
data: {"type":"done","usage":{"input":150,"output":87}}
Előnyök:
- HTTP-alapú — átmegy proxy-n, CDN-en, load balancer-en
- Automatikus újrakapcsolódás (a böngésző
EventSourceAPI beépítetten kezeli) - Egyszerű implementáció (szerver:
res.write(), kliens:EventSource) - Tűzfalbarát — a legtöbb vállalati tűzfal engedi a HTTP-t
Hátrányok:
- Egyirányú (szerver → kliens). A kliens nem küldhet adatot a stream-en
- Szöveges protokoll — bináris adathoz (hang, kép) nem ideális
- Böngészőnként max 6 párhuzamos SSE kapcsolat per domain (HTTP/1.1 limit)
- Nincs beépített heartbeat — a proxy timeout-olhatja a csendes kapcsolatot
2.2 WebSocket
A WebSocket kétirányú, full-duplex kommunikációt biztosít. Előnye a bináris támogatás és a kétirányúság (a kliens is küldhet pl. „stop generating" üzenetet). Hátránya a komplexebb infrastruktúra, a problémás proxy/CDN kompatibilitás és a manuális reconnect.
2.3 HTTP/2 Server Push és HTTP/3
A HTTP/2 multiplexelt stream-eket támogat egyetlen TCP kapcsolaton — ez megoldja az SSE 6-kapcsolat korlátját. A HTTP/3 (QUIC) tovább javít: 0-RTT kapcsolat-felépítés, nincs Head-of-Line blocking, jobb mobilos teljesítmény.
2.4 Mikor melyiket?
Az iparági konszenzus 2026-ban: az AI chat streaming-hez az SSE az alapértelmezett. Az OpenAI, Anthropic, Google és Mistral API-k mind SSE-t használnak. A WebSocket akkor jön képbe, ha hangalapú AI-t (voice agent) vagy bináris adatot kell streaming-elni.
3. Token streaming: az LLM válasz valós idejű megjelenítése
3.1 A token streaming alapmechanizmusa
Az LLM provider-ek a stream: true paraméterrel token-ról token-ra küldik a választ.
OpenAI format:
data: {"choices":[{"delta":{"content":"A"},"finish_reason":null}]}
data: {"choices":[{"delta":{"content":"z"},"finish_reason":null}]}
data: [DONE]
Anthropic format:
event: content_block_delta
data: {"type":"content_block_delta","delta":{"type":"text_delta","text":"A"}}
event: message_stop
data: {"type":"message_stop"}
3.2 A proxy réteg: provider → alkalmazás → kliens
Produkciós rendszerben az LLM stream nem megy közvetlenül a kliensnek. Köztes réteg:
- Fogadja az LLM provider stream-jét
- Transzformálja az alkalmazás saját formátumára
- Továbbítja a kliensnek
- Logol (token count, latency, error)
- Menti a teljes választ az adatbázisba
3.3 A Markdown streaming probléma
Az LLM-ek gyakran Markdown formátumban válaszolnak. A Markdown nem karakter-kompatibilis — egy félig érkezett kódrészlet vagy táblázat eltöri a renderelést.
Megoldási stratégiák:
- Delayed rendering: 100–200ms-os puffer
- Incremental Markdown parser: részleges Markdown-ot is kezel
- Dual rendering: stream közben plain text, végén Markdown újrarendereles (ChatGPT)
- Token batching: mondatonként/bekezdésenként küld a kliensnek
4. Multi-fázisú streaming: tool calling + gondolkodás + válasz
4.1 A valódi kihívás: nem csak szöveg jön
Egy AI ágens válasza nem egyetlen szövegfolyam. A tipikus flow:
Fázis 1: Gondolkodás (tool selection) ← 200–500ms
Fázis 2: Tool hívás (CRM query, RAG) ← 100–2000ms
Fázis 3: Tool eredmény feldolgozása ← nem látható
Fázis 4: Második gondolkodás ← 200ms
Fázis 5: Esetleg újabb tool hívás ← 100–2000ms
Fázis 6: Végső válasz generálása (stream) ← 2000–8000ms
4.2 A két-fázisú streaming architektúra
Fázis 1: Tool calling (státusz események)
Kliens ← {"type": "status", "message": "Keresem az információt..."}
Kliens ← {"type": "status", "message": "CRM adatok lekérdezése..."}
Kliens ← {"type": "status", "message": "3 találat a tudásbázisban..."}
Fázis 2: Válasz streaming (token események)
Kliens ← {"type": "token", "content": "Kiss"}
Kliens ← {"type": "token", "content": " Anna"}
Kliens ← {"type": "done", "usage": {...}}
4.3 A „thinking" stream
Egyes LLM-ek (Claude 3.5, o1-preview) gondolkodási lánc-ot is stream-elnek. UX döntés:
- Megmutatás (Claude, DeepSeek): „Átlátható AI", tech-savvy felhasználóknak
- Elrejtés (ChatGPT): tisztább UX, általános közönségnek
- Összefoglalás (kompromisszum): rövid státusz-üzenetek
5. Latency optimalizáció: minden milliszekundum számít
5.1 A latency anatómiája
Teljes TTFB (Time to First Byte):
- Best case: ~300ms (gyors RAG, nincs queue, gyors LLM)
- Típikus: ~800ms–2s
- Worst case: ~5–15s (lassú RAG, LLM queue, tool calling iterációk)
5.2 A 8 optimalizációs pont
- Connection pooling az LLM provider-hez — ~100ms megtakarítás hívásonként
- RAG context prefetch — párhuzamos végrehajtás, max(200ms, 50ms, 30ms)
- Streaming-first LLM hívás — mindig
stream: true, alacsonyabb TTFT - Prompt optimalizáció — rövidebb prompt = gyorsabb prefill
- Edge computing — szerver közelebb a felhasználóhoz, EU régió
- Cold start eliminálás — dedicated szerver vagy konténer
- Response caching — FAQ, system prompt cache (Anthropic ~75% megtakarítás)
- LLM provider failover — adapter pattern, OpenAI → Claude → Gemini
5.3 A latency budget
6. Produkciós kihívások
6.1 Load balancing SSE-vel
Az SSE stream long-running HTTP connection — a load balancer idle timeout-tal dolgozik. Ha az SSE stream 30 másodpercig nem küld adatot (mert az LLM gondolkodik), a load balancer bontja a kapcsolatot.
Megoldások:
- Heartbeat/keepalive SSE event — rendszeres üres
commentsor (:) a stream-ben - Proxy timeout növelés — Nginx
proxy_read_timeout, HAProxytimeout server - Sticky sessions — több backend szerver esetén session affinity
6.2 Reconnect kezelés
A valós világban a kapcsolat megszakadhat. Az SSE EventSource API automatikus reconnect-et ad Last-Event-ID támogatással. A kihívás: az LLM provider stream nem visszajátszható — az addig érkezett tokeneket el kell tárolni (memóriában vagy Redis-ben) és a kliens reconnect-jénél visszaküldeni.
6.3 Párhuzamos stream-ek és erőforrás-kezelés
6.4 Error handling a stream közepén
Best practice: Error event küldése + a részleges válasz mentése + kliens-oldali „Újragenerálás" gomb.
6.5 Backpressure: amikor a kliens lassabb, mint a szerver
A Node.js stream pipe() mechanizmusa természetesen kezeli a backpressure-t — de explicit tesztelni kell edge case-eken.
7. UX pattern-ek a valós idejű AI-hoz
7.1 Pattern-ek áttekintése
8. Hangalapú AI: a következő határ
8.1 A voice streaming más
A szöveges streaming „luxus" — a felhasználó látja a szöveget megjelenni. A hang más: a latency közvetlenül érezhető.
8.2 A voice AI pipeline
Felhasználó ──[hang]──▶ STT (Speech-to-Text) ~200–500ms
│
▼
LLM (szöveg generálás) ~500–2000ms
│
▼
TTS (Text-to-Speech) ~200–500ms
│
Felhasználó ◀──[hang]───────┘
Teljes latency: 900–3000ms
8.3 A latency csökkentés voice AI-nál
- Streaming TTS — mondatonként generál hangot
- Filler sounds — „Hmm...", „Szóval..." (Google Duplex óta ismert trükk)
- Sentence boundary detection —
.,!,?detektálása + azonnali TTS - Speculative execution — a rendszer előre megjósolja a kérdést
8.4 Protokollok voice AI-hoz
A WebSocket a voice AI alapértelmezett protokollja 2026-ban. A WebRTC akkor jön képbe, ha P2P hang kell minimális latency-vel.
9. Az iparági irány: 2025–2026
9.1 A provider streaming API-k fejlődése
- OpenAI Realtime API (2024 okt.): WebSocket-alapú, szöveg + hang, full-duplex
- Anthropic prompt caching: ~75% input token megtakarítás → gyorsabb prefill
- Gemini 2.0 Flash: ~20ms/token, a leggyorsabb TTFT a piacon
- Mistral EU-hosted: GDPR-kompatibilis streaming
9.2 Az edge AI — streaming LLM nélkül
A legradikálisabb latency-csökkentés: ne hívj távoli LLM-et. Kis modellek (Gemma 2B, Phi-3 Mini, Llama 3 8B) futtathatók mobil eszközön (Apple Neural Engine, Qualcomm NPU), edge szerveren (Cloudflare Workers AI), vagy on-premise GPU-n.
2026-os trend: hibrid megközelítés — egyszerű kérdéseket helyi (edge) modell (~50ms TTFT), komplex kérdéseket cloud LLM (~800ms TTFT). A routing döntést egy kis classifier modell hozza meg.
9.3 Speculative decoding — az LLM-ek belső gyorsítása
Egy kis draft modell (~1B) gyorsan generál 5–10 tokent → a nagy target modell (~70B) egyszerre validálja. Eredmény: ~2–3x sebességnövekedés minőség-romlás nélkül. A Gemini 2.0 és a Claude 3.5 már használják.
9.4 A structured output streaming
Az OpenAI 2025-ben bevezette a response_format: { type: "json_schema" } streaming-et — a JSON struktúrának megfelelő tokeneket generál, és a kliens részleges JSON-t is tudja értelmezni. Az AI ágens Evaluator-ánál hasznos: az Executor azonnal elkezdheti a végrehajtást, miközben a többi akció még generálódik.
10. Gyakorlati döntési keretrendszer
10.1 A streaming döntési fa
Az AI válasz interaktív (felhasználó várja)?
│
├─ Igen → Szöveges vagy hangalapú?
│ │
│ ├─ Szöveges → SSE (alapértelmezett)
│ │ HTTP/2 + SSE, ha elérhető
│ │ WebSocket, ha kétirányúság kell
│ │
│ └─ Hangalapú → WebSocket (bináris)
│ WebRTC ultra-low latency-hez
│
└─ Nem (háttérfeladat) → Nincs streaming szükséges
Queue-alapú (BullMQ) + webhook
10.2 A monitoring checklist
11. Összefoglalás — a 7 legfontosabb takeaway
- SSE az alapértelmezett: Az AI chat streaming-hez az SSE egyszerű, megbízható és kompatibilis.
- TTFB > teljes válaszidő: Az első token megjelenésének ideje fontosabb, mint a teljes válasz ideje.
- Multi-fázisú streaming: A tool calling + RAG + válasz fázisait kommunikáld a kliensnek.
- Latency budget: Definiáld, mérd, optimalizáld. Legnagyobb nyereség: párhuzamos RAG/history + prompt méret.
- Produkciós edge case-ek: Heartbeat, reconnect + token puffer, backpressure, error handling.
- Voice AI más kategória: < 500ms TTFB, WebSocket, sentence-level TTS, filler sounds.
- Edge AI + speculative decoding: Hibrid jövő — egyszerű feladatok lokálisan, komplex feladatok cloud-ban.
Az egyetlen szabály
A legjobb streaming implementáció az, amit a felhasználó nem vesz észre — csak azt érzékeli, hogy az AI „azonnal" válaszol.
Tervez valós idejű AI chat-et vagy voice agent-et?
Az Atlosz csapata segít a streaming architektúra, az SSE/WebSocket megvalósítás, a latency optimalizáció és a produkciós edge case-ek (reconnect, backpressure, error handling) megtervezésében és implementálásában — az Ön rendszeréhez szabva.
Beszéljünk az AI stratégiájáról →