Egymillió kérés. Ez nem nagy szám az iparág skáláján — Google egy nap alatt többszörösét forgatja le egy keresőterületen. Nálunk három hónapot vett igénybe, és ezalatt elég adat keletkezett ahhoz, hogy a kezdeti hipotéziseinket statisztikailag védhető állításokra cseréljük. Ez egy poszt arról, mit mértünk.
Medián latencia, domain szerint
- Chat: 412ms
- Voice: 280ms
- Illustrate (image generation): 6.8 másodperc
A voice tűnhet meglepetésnek, hogy gyorsabb a chatnél. Nem az — a voice egy streaming pipeline, ahol az első audio chunk a teljes válasz előtt elhagyja a szervert (a felhasználó már hallja a választ, miközben még generálódik). A chat egy teljes válasz-fordulattal mér: token-by-token streaming opció be van kapcsolva, de a medián a teljes válasz időpontján mérve van. Ha a chat-stream first-token-latency-t mérjük, az 180ms — ami a voice-szal összevethető.
Az illustrate hosszú, és nem könnyű lerövidíteni. A DALL-E 3 + post-processing pipeline szinte minden időt az upstream provider-nél tölt. Ezen a fronton csak akkor lesz változás, ha új provider-rel próbálkozunk (FLUX, SDXL-turbo), vagy ha a felhasználó hajlandó alacsonyabb felbontást elfogadni.
Cost per request, eloszlás
A cost-per-request hosszú-farkú eloszlás. A medián 0.0028 EUR. A 95-percentil 0.034 EUR. A 99-percentil 0.21 EUR. Az 1%-os top hozza a havi költségek 38%-át. Ezek a top-tail kérések szinte mindig hosszú multi-turn voice-session-ök, image generation series-ek, vagy nagy context-window-os RAG-kérések olyan ügyfeleknél, akik egy 100K-tokenes dokumentumon kérdeznek.
A 95-percentil felhasználók
A tenant-base 4.3%-a felelős a teljes költség 38%-áért. Nem ők a rosszak — ők a leginkább elköteleződöttek. De a pricing-modellünk lineáris, és ez a torzulás a margin-on érződik. Két lehetőség: (a) tier-alapú pricing (heavy-use plan), (b) per-request optimalizáció ezeknél a tenant-eknél. Most a (b)-t választjuk: ezeknek a tenant-eknek dedikált router-tuningot adunk, amiben a fallback-stratégia agresszívabb (olcsóbb modellek preferenciával, ha az SLO megengedi). Az eredmény: 17%-os költségcsökkenés ezeknek a tenant-eknek, változatlan felhasználói tapasztalat mellett (a megtartási rátájuk nem mozdult).
A „wrong-model” ráta
A wrong-model azt jelenti: a router olyan modellt választott, ami utólag (eval-szuite eldöntése alapján) NEM volt a legjobb választás erre a kérésre. A jelenlegi ráta 3.1%. Ezt úgy mérjük, hogy minden response után egy ALACSONY arányú (1%) sample-en futtatunk egy „shadow request”-et a többi candidate modellre is, és összevetjük a válasz minőségét egy LLM-as-judge segítségével. Ha egy másik modell konzisztensen jobb az adott osztály-kérésre, az feltételezi, hogy a router-szabály frissítendő.
A 3.1% nem rossz — az ipari benchmark (saját, korábbi mérésekből) 8-12%. De minden tizedik wrong-model egy potenciális ügyfél-panasz, ezért negyedévente nézzük át a router-szabályokat ezen az adat alapján, és frissítjük a candidate-listákat.
Amit megmértünk, és csendben marad
A „chat session length distribution”. A medián 4 fordulós, a 95-percentil 18 fordulós. Ez azt mondja: a felhasználók többsége gyorsan megkapja amit akar, és lép. A 18+ fordulós session-ök vagy support-mélyfúrások (jó), vagy a motor circle-be esett (rossz). A kettő megkülönböztetése a következő mérnöki feladat.
Ami meglepett
Három dolog, amit nem jósoltunk meg, mielőtt az adat megérkezett. Először: a time-of-day eloszlás laposabb, mint a consumer-internet baseline. Egy erős nyugat-európai munkaidő-csúcsot (UTC+1 9-18) feltételeztünk, de csak 2.3x peak-to-trough arányt láttunk; a multi-régiós tenantek és az overnight batch workload-ok jobban kisimítják a görbét, mint vártuk. Másodszor: a tool-call gyakoriság inverzben követi a modell-erőt. A katalógus legerősebb modellje 18%-kal kevesebbszer hív tool-t, mint az olcsó gyors modell ugyanazon promptokra — többet old meg in-context. Harmadszor: a voice session-ök 84%-ban tisztán end-of-turn-nel zárulnak, a maradék 16% mid-response abort, szinte mindegyik mobile-userektől gyenge kapcsolaton. A voice retry-with-buffered-context most queue-d feature.
Végszó: minden szám fent egy pillanatkép. A motor, a providerek és az ügyfelek heti szinten változnak. A Grafana board ezekkel a metrikákkal minden mérnök bookmarkjában van, és a heti mérnöki meeting öt perces nézettel nyit: melyik szám mozdult, miért. Ezek nélkül a fegyelem nélkül — heti szinten ugyanazokat a számokat nézni — a mérések semmit nem érnek. Csak akkor használhatóak, ha önmagukhoz hasonlítjuk őket az időben.