Rychlost AI posuzujte podle toho, kdy člověk dostane použitelnou odpověď nebo kdy automatizace dokončí svůj úkol. První token, začátek odpovědi a uložený výsledek označují různé okamžiky.
Zákazník se zeptá na dostupnost výrobku. Asistent hned potvrdí přijetí dotazu, ale na vlastní odpověď se čeká. Potřebuje vyhledat správnou variantu, ověřit sklad a připravit srozumitelný text.
Jindy model vygeneruje odpověď rychle, jenže automatizace ještě kontroluje údaje a ukládá je do firemního systému. Zaměstnanec může začít pracovat s výsledkem až po dokončení těchto kroků.
Pod jedním slovem „rychlost“ se tak skrývá několik různých údajů. Pro výběr řešení je potřeba vědět, co přesně měříte a jaký okamžik má hodnotu pro člověka, který čeká.
Pět údajů, které se vyplatí rozlišovat
Token je malá část zpracovávaného textu, například část slova, číslo nebo znak. Počet tokenů za sekundu popisuje výkon jen v rámci konkrétně definovaného měření.
| Údaj | Co označuje | Co z něj zjistíte |
|---|---|---|
| Čas do prvního tokenu, TTFT | Prodlevu od odeslání požadavku do příchodu prvního tokenu od služby. | Kdy služba začne vracet výstup. U modelu s uvažováním může jít o token uvažování, pokud ho API vrací. |
| Čas do prvního tokenu odpovědi, TTFA | Prodlevu do začátku vlastní odpovědi po případném uvažování modelu. | Kdy začíná přicházet odpověď na zadání. |
| Rychlost výstupu | Počet tokenů za jednotku času podle metodiky zdroje. | Jakou rychlostí služba vytváří výstup v daném testu. Je potřeba znát započtený čas i druhy tokenů. |
| Čas celé odpovědi modelu | Interval od odeslání požadavku do přijetí poslední části výstupu. | Kdy má aplikace k dispozici úplnou odpověď modelu. |
| Čas dokončení firemního úkolu | Interval od přijetí požadavku do předem určeného výsledku. | Kdy lze použít odpověď, ověřený návrh nebo uložený záznam. |
Artificial Analysis tyto rozdíly popisuje ve své metodice. Důležité je zejména to, že první token vlastní odpovědi může u modelu s uvažováním přijít později než první token služby. A ani začátek odpovědi ještě nemusí obsahovat údaj, na který zákazník čeká. Definice měření Artificial Analysis
Potvrzení „požadavek jsme přijali“ měřte samostatně. Zákazník díky němu ví, že systém pracuje. Pro vyhodnocení služby pak potřebujete zachytit i okamžik, kdy se dozvěděl například skutečnou dostupnost výrobku.
Proč může vysoká rychlost doprovázet dlouhé čekání
Na stránce DeepSeek V4.1 Flash 1017 v nastavení Max uváděl Artificial Analysis při ověření 5. listopadu 2026 rychlost výstupu přibližně 175 tokenů za sekundu a čas do prvního tokenu odpovědi přibližně 50,78 sekundy. Jsou to dva souhrnné údaje z benchmarku. Stránka modelu a výsledky měření
Současná metodika Performance v3 do rychlosti zahrnuje také tokeny uvažování a čas od odeslání požadavku. Souhrn počítá napříč měřenými zátěžemi. Údaje proto nelze číst jako rychlost přibývání viditelných slov v jednom konkrétním chatu. Pro vlastní aplikaci je potřeba ověřit skutečnou odezvu se zvoleným modelem, nastavením a vstupy. Metodika a historie změn
Při porovnávání si vždy poznamenejte datum a definici metriky. Stejný název sloupce může po změně metodiky vyjadřovat něco jiného. U jiného dodavatele si ověřte také to, zda rychlost počítá přes celý požadavek, nebo jen během určité části generování.
Modelový požadavek může trvat čtrnáct sekund
Představme si automatizaci, která z přijatého podkladu připraví návrh interního záznamu ke kontrole. Následující časy jsou ilustrační a slouží k vysvětlení jednotlivých okamžiků.
Načítání schématu…
Přečíst schéma jako text
sequenceDiagram
participant U as Uživatel
participant A as Aplikace
participant M as AI služba
participant S as Firemní systém
U->>A: 0 s — odeslání podkladu
A-->>U: Potvrzení přijetí
Note over A: 0–2 s — načtení podkladů
A->>M: 2 s — odeslání zadání
M-->>A: 3 s — první token služby
M-->>A: 9 s — začátek vlastní odpovědi
M-->>A: 12 s — poslední část odpovědi
A->>S: 12–14 s — kontrola a uložení návrhu
S-->>A: 14 s — potvrzení uložení
A-->>U: Návrh je připravený ke kontroleV tomto příkladu trvá čekání na první token jednu sekundu od zavolání AI služby. Vlastní odpověď začíná po sedmi sekundách od tohoto volání. Celá odpověď modelu je k dispozici za deset sekund a návrh záznamu je připravený za čtrnáct sekund od odeslání podkladu.
Zaměstnanec, který potřebuje otevřít uložený návrh, řeší poslední z těchto časů. U chatu zase může dostat užitečnou informaci už během průběžného zobrazování odpovědi.
Pokud záznam následně čeká na schválení člověkem, sledujte tuto prodlevu zvlášť. Stav „návrh připraven“ a stav „schváleno“ mají ve firemním procesu jiný význam.
Kde se čas v automatizaci ztrácí
Celkovou dobu mohou prodlužovat kroky před samotným modelem i po něm.
- Čekání ve frontě. Požadavek je přijatý, ale na zpracování se dostane až za dalšími úkoly.
- Načítání podkladů. Systém prochází přílohy, vyhledává v dokumentech nebo získává aktuální údaje z jiného programu.
- Další volání služeb. Model může postupně získávat informace z více zdrojů.
- Kontrola výsledku. Aplikace ověřuje povinné údaje, číselné formáty nebo návaznost na firemní pravidla.
- Uložení a potvrzení. Příprava správných údajů a potvrzený zápis do cílového systému jsou další dva kroky.
- Opakovaný pokus. Chyba může spustit další volání a prodloužit celou cestu.
Zrychlení modelu pomůže nejvíc tam, kde právě jeho práce tvoří velkou část čekání. Pokud automatizace většinu času získává údaje z jiného systému, začněte u tohoto napojení.
Při souběhu kroků měřte celkový interval samostatně, aby se překryté časy nezapočetly vícekrát. A pokud aplikace výstup před zobrazením ještě kontroluje, měřte i čekání v prohlížeči. Google v metodice provozního měření upozorňuje, že samotná odezva serveru může přehlédnout zdržení, které zažívá uživatel. Google SRE k měření služby z pohledu uživatele
Medián popisuje běžný případ, p95 ukáže pomalejší část
Medián, označovaný také jako p50, je prostřední hodnota po seřazení měření. Pomáhá popsat typický požadavek. Vedle něj sledujte pomalejší část provozu.
Pokud je například p95 dvacet sekund, přibližně 95 % měřených požadavků se vešlo do této doby. Zbývající část mohla trvat déle. Samotný průměr může takové pomalé případy skrýt. Právě proto provozní metodiky pracují s rozdělením dob odezvy a s percentily. Google SRE k průměrům a percentilům
K časům doplňte počet chyb a nedokončených úkolů. Rychle vrácená chyba nesplní stejný účel jako správný výsledek. Google proto doporučuje rozlišovat odezvu úspěšných a chybových požadavků. Google SRE k odezvě, chybám a zatížení
Pro malou firmu může být srozumitelnější přímo sledovat podíl úloh, které skončí správně v dohodnuté době. Modelový cíl může znít „Alespoň 95 % přijatých platných podkladů připravíme ke kontrole do dvaceti sekund.“ Vlastní hranici určete podle procesu a výsledků testování.
Jak rychlost otestovat před nasazením
1. Určete začátek a konec. U chatu může jít o dobu od odeslání dotazu do zobrazení správné odpovědi. U dokumentu o dobu od přijetí souboru do uložení ověřeného návrhu.
2. Vyberte skutečně používané typy zadání. Zařaďte krátký dotaz, delší dokument, neúplný podklad i případ, který potřebuje doplnit informace z dalšího systému. Pro porovnání variant používejte stejný soubor úloh.
3. Změřte hlavní kroky. Zaznamenejte přijetí požadavku, dokončení vyhledávání, odeslání do modelu, první část odpovědi, dokončení kontroly a potvrzení výsledku. Každému požadavku dejte identifikátor, podle kterého dohledáte celý průchod.
4. Přidejte souběžné požadavky. Ověřte běžný provoz i očekávanou špičku. Zkouška s jedním uživatelem neukáže čekání, které může vzniknout při větším zatížení. Vliv front a zatížení na odezvu popisuje i Google SRE. Měření při různém zatížení
5. Počítejte celý pokus o dokončení. Sledujte i opakovaná volání, chyby a předání člověku. Zapisujte verzi modelu, jeho nastavení a podmínky testu, aby další srovnání mělo stejný základ.
6. Kontrolujte správnost. U každé varianty vyhodnoťte, zda výsledek splňuje zadání a firemní pravidla. Pokud rychlejší nastavení přidá více oprav, zahrňte jejich čas do celkového vyhodnocení.
Výstupem testu může být krátký přehled s mediánem, p95, podílem správně dokončených úloh v limitu a cenou za použitelný výsledek. Na malém vzorku berte zejména vysoké percentily opatrně a uveďte počet měření.
Co se má stát při dlouhém čekání
Domluvte reakci systému ještě při návrhu. Uživatel má dostat informaci o skutečném stavu a možnost pokračovat v práci.
| Situace | Připravená reakce |
|---|---|
| Zpracování potřebuje více času | Uložit požadavek, nabídnout dohledatelný stav a oznámit dokončení vhodným kanálem. |
| Chybí potřebný údaj | Položit konkrétní doplňující otázku. |
| Jedna služba je nedostupná | Použít předem ověřený záložní postup nebo předat úkol odpovědnému člověku. |
| Není potvrzené uložení výsledku | Zjistit stav zápisu před dalším pokusem. |
Doba, po kterou systém čeká na jednotlivou službu, má zapadat do celkového časového limitu. Opakování potřebuje určený počet pokusů a prodlevy. Jinak může rostoucí počet opakování přetíženou službu dále zatěžovat. AWS k časovým limitům a opakování požadavků
U zápisů je důležité zabránit tomu, aby opakovaný požadavek vytvořil další objednávku nebo duplicitní záznam. Opakování stejné operace má mít stejný účinek jako její jediné provedení. Tato vlastnost se označuje jako idempotence a při návrhu jí pomáhá jednoznačná identifikace operace. AWS k bezpečnému opakování operací
Který čas je pro vaši firmu rozhodující
U zákaznického asistenta sledujte první užitečnou informaci, dokončení odpovědi a podíl správně vyřešených požadavků. Průběžné zobrazování textu může část čekání využít ke čtení.
U dávky dokumentů bývá důležitý termín dokončení celé dávky a množství následné ruční kontroly. Rozdíl několika sekund u jedné úlohy posuzujte podle toho, jak ovlivní celou dávku.
U návrhu nabídky nebo jiného schvalovaného výstupu měřte zvlášť přípravu podkladů a čekání na rozhodnutí člověka. Nastavení automatizace pak můžete zlepšovat podle konkrétního místa, kde práce stojí.
Jak může pomoci Kodo
V Kodo můžeme navrhnout automatizaci kolem konkrétního výsledku, který firma potřebuje. Součástí je výběr modelu, napojení podkladů, kontrola výstupu a způsob předání při chybě nebo delším zpracování.
Při ověřování porovnáme kvalitu, čas celého postupu a náklady. Podle typu úlohy můžeme otestovat různé modely nebo nastavení a zjistit, kde rychlejší varianta přinese skutečnou změnu pro uživatele.
Probrat firemní AI a automatizaci s Kodo
Časté otázky
Znamená vysoký počet tokenů za sekundu rychlou odpověď zákazníkovi?
Záleží na tom, jak zdroj rychlost počítá. Do čekání zákazníka navíc vstupuje získání podkladů, případné uvažování modelu, kontrola i zobrazení výsledku. Pro vlastní aplikaci měřte celý průchod požadavku.
Pomůže průběžné zobrazování odpovědi?
Může uživateli umožnit číst už během generování. U výstupu, který aplikace potřebuje nejprve celý zkontrolovat nebo uložit, se použitelný výsledek objeví později. Měřte oba okamžiky podle potřeb procesu.
Kolik sekund je ještě přijatelných?
Hranici určete podle úlohy. Odpověď na jednoduchý zákaznický dotaz, rozbor rozsáhlé přílohy a noční dávka mají jiné nároky. Domluvte dobu pro běžné i pomalé případy a reakci při jejím překročení.
Mám vždy zvolit nejrychlejší model?
Porovnejte správnost, čas dokončení a cenu na stejných úlohách. Rychlejší model může pomoci v části procesu, kterou skutečně zdržuje jeho práce. Zahrňte také opravy a opakované pokusy.
Související čtení
- Stejný AI model, jiná cena a rychlost — záleží na poskytovateli
- Co připravit před nasazením firemního AI asistenta
- Jak ušetřit na AI modelech
Zdroje
- Artificial Analysis — metodika měření výkonu API a historie verzí
- Artificial Analysis — DeepSeek V4.1 Flash 1017 v nastavení Max — údaje na stránce ověřené 5. 11. 2026.
- Google SRE — definice cílů služby a práce s percentily
- Google SRE — sledování odezvy, chyb a zatížení
- AWS Builders’ Library — časové limity a opakování požadavků
- AWS Builders’ Library — bezpečné opakování operací