Kolik lidí zvládne AI server? Výkon na papíře může klamat a omyly jsou drahé

Kolik lidí zvládne AI server – OBSAH

1. Výkon AI serveru se nepočítá jen z parametrů
2. Proč jedna odpověď nestačí
3. Kolik uživatelů vlastně znamená kolik?
4. Datasheet pomůže, ale kapacitu za vás nespočítá
5. Základní výpočet: kolik tokenů spotřebuje jeden uživatel
6. Model rozhoduje víc než název serveru
7. RAG: když chatbot nehádá, ale hledá ve firemních dokumentech
8. Jeden server může stačit, pokud víte, co od něj čekáte
9. Jak zadat benchmark, který má obchodní hodnotu

Výkon AI serveru se nepočítá jen z parametrů

Výkon AI serveru vypadá na první pohled jako disciplína, kterou lze vyřešit pohledem do technických parametrů. Firma si porovná počet GPU, velikost paměti, hodnoty TFLOPS v datasheetu a snadno získá pocit, že tím má základní kapacitu spočítanou. Jenže u generativní umělé inteligence se právě v tomto bodě často rodí nejdražší omyly, protože samotný hardware ještě neříká, kolik lidí bude službu používat pohodlně, kolik jich začne čekat a kdy se systém dostane na hranici rozumné odezvy.

U AI serveru záleží na tom, jaký model umělé inteligence na něm poběží, jak dlouhé budou dotazy, jak rozsáhlé budou odpovědi, jak rychle má text přibývat na obrazovce a kolik požadavků dorazí ve stejný okamžik. Stejný server tak může být pro jednoduchého interního asistenta výrazně předimenzovaný, zatímco při práci s dlouhými smlouvami, technickou dokumentací nebo větším modelem začne narážet mnohem dříve.

Proč jedna odpověď nestačí

Číslo z datasheetu je užitečný začátek technické debaty, ale samo o sobě nestačí k odpovědi na otázku, kolik uživatelů server skutečně utáhne. U běžné webové aplikace se výkon často přepočítává na požadavky za sekundu, protože server zpracuje dotaz, vrátí výsledek a může se věnovat dalšímu požadavku. U chatbota je situace složitější, protože model odpověď postupně generuje a po celou dobu spotřebovává část výkonu.

Jeden uživatel navíc server nezatěžuje po celou dobu přihlášení, protože chvíli píše dotaz, potom čeká na první slova odpovědi, následně výsledek čte a až poté se vrací s dalším požadavkem. Krátké interní dotazy, jednoduchá klasifikace dokumentů a právní asistent pracující s dlouhými texty jsou proto tři naprosto odlišné scénáře. V prezentaci mohou všechny spadat pod firemní AI, ale z pohledu infrastruktury znamenají jiné nároky na paměť, latenci, propustnost i rezervu pro špičky, a právě proto nemá smysl ptát se jen na to, jak výkonný server je, ale především na to, jakou konkrétní práci má dělat.

Kolik uživatelů vlastně znamená kolik?

První problém vzniká už u samotného slova uživatel. Firma může mít 10 000 zaměstnanců, ale to neznamená, že AI server musí současně generovat 10 000 odpovědí. V jeden okamžik bude většina lidí mimo aplikaci, část bude číst hotový výstup a jen menší skupina bude právě čekat, až model vytvoří další část odpovědi.

Pro kapacitní plánování je proto důležitější počet současně obsluhovaných požadavků než celkový počet lidí s přístupem ke službě. U generativního chatbota je ještě přesnější sledovat počet odpovědí, které model aktivně generuje ve stejném okamžiku. Pokud dvacet lidí čte výsledek a pět lidí v té chvíli dostává novou odpověď, největší zátěž pro GPU představuje zrovna těch pět běžících generování.

Formulace typu „server zvládne 500 uživatelů“ tak má smysl jen tehdy, pokud je jasné, o jaké uživatele jde. Může jít o přihlášené účty, aktivní session, souběžné dotazy nebo současně generované odpovědi. Pro nákupní rozhodnutí je nejpraktičtější poslední možnost, protože právě ta se dá spojit s rychlostí generování, latencí a reálným pocitem uživatele z aplikace.

Datasheet pomůže, ale kapacitu za vás nespočítá

Parametry GPU mají při návrhu AI serveru jasnou hodnotu. Výpočetní výkon ukazuje, jak silný čip server používá, kapacita VRAM určuje, jak velký model a kontext se vejdou do paměti, paměťová propustnost ovlivňuje rychlost generování a interconnect rozhoduje o tom, jak efektivně spolupracuje více GPU. Problém nastává ve chvíli, kdy se z těchto údajů udělá jediný nákupní argument a zbytek provozní reality zůstane mimo výpočet.

U jazykových modelů se výkon v praxi láme na metrikách, které jsou bližší chování aplikace. Latence říká, jak dlouho uživatel čeká, throughput ukazuje, kolik práce systém zvládne celkově, a tokens/s popisují, jak rychle model generuje výstup. Důležitý je také TTFT, tedy time to first token, protože čas do první viditelné části odpovědi často rozhoduje o tom, zda aplikace působí svižně, nebo pomalu.

Nejlepší číslo z benchmarku bývá často méně důležité než podmínky, za kterých vzniklo. Test s krátkým promptem, krátkou odpovědí a ideálním batchingem může vypadat výborně, ale o firemním asistentovi s dokumenty, češtinou a ranní špičkou řekne jen omezenou část pravdy. Rozhodující je proto testovat výkon při podobné délce dotazů, podobné délce odpovědí a podobné souběžnosti, jakou bude mít budoucí produkční služba.

Základní výpočet: kolik tokenů spotřebuje jeden uživatel

U generativní AI se dá začít jednoduchým kapacitním modelem. Pokud server zvládne například 6 000 výstupních tokenů za sekundu a firma chce, aby jeden aktuálně obsluhovaný uživatel dostával odpověď rychlostí 15 tokenů za sekundu, vychází hrubá kapacita na 400 současně generovaných odpovědí. V produkci je potřeba z tohoto čísla odečíst rezervu na špičky, delší dotazy, práci s kontextem, nerovnoměrné chování uživatelů a režii celé aplikace.

Takový výpočet není přesná předpověď reálného provozu, ale velmi dobrý rozhodovací filtr. Rychle ukáže, zda se firma baví o serveru pro pilotní projekt, interního asistenta pro menší tým nebo infrastrukturu pro stovky lidí ve špičce. Zároveň donutí zadavatele definovat, jaká rychlost odpovědi je pro danou službu ještě pohodlná a jaká už bude působit jako brzda v práci.

Důležitá je také provozní rezerva, protože produkční systém nemůže být navržený tak, aby při běžné špičce trvale běžel na hranici možností. Stačí delší dokument, složitější dotaz, pomalejší část aplikační vrstvy nebo servisní zásah a odezva se začne rychle zhoršovat. Rezerva proto není luxus, ale pojistka, že služba zůstane použitelná i mimo ideální podmínky.

U negenerativních úloh se kapacita počítá jiným způsobem. Klasifikace, embeddingy nebo jednoduché vyhledávání se často dají vyjádřit přes požadavky za sekundu, protože odpověď nevzniká postupným generováním dlouhého textu. Pokud služba zvládne 2 000 požadavků za sekundu a jeden aktivní uživatel posílá průměrně jeden požadavek za deset sekund, vychází kapacitní model úplně jinak než u chatbota, který vytváří dlouhou odpověď token po tokenu.

Model rozhoduje víc než název serveru

Velikost modelu dramaticky mění nároky na infrastrukturu. Menší modely zhruba do 10 miliard parametrů mohou při dobré optimalizaci obsloužit velmi slušný počet interních dotazů, zvlášť pokud firma nepotřebuje extrémně dlouhý kontext. Větší modely mohou nabídnout vyšší kvalitu odpovědí u náročnějších úloh, ale zároveň výrazně zvyšují nároky na VRAM, paměťovou propustnost a efektivní provoz přes více GPU.

Samotné parametry modelu jsou přitom jen první část paměťové rovnice. Do paměti se musí vejít také KV cache, tedy průběžná paměť modelu pro už zpracované tokeny. Další prostor potřebuje inference engine a dávkové zpracování požadavků. Pokud server obsluhuje více modelů najednou, je nutné počítat i s jejich samostatnou paměťovou rezervou.

Kvantizace dokáže nároky snížit, ale měla by se ověřovat na konkrétním úkolu, nejen podle obecného benchmarku. U interního asistenta, který odpovídá na opakované provozní dotazy, může být úspornější konfigurace rozumným kompromisem. U právních, technických nebo finančních výstupů je naopak potřeba zkontrolovat, zda zvolená přesnost neovlivňuje práci s detaily, například jestli model nezačne hůř rozlišovat podobné smluvní formulace, nepřehlíží malé rozdíly v technické specifikaci nebo nezjednodušuje číselné údaje způsobem, který v krátkém laboratorním testu nemusí vyjít najevo.

RAG: když chatbot nehádá, ale hledá ve firemních dokumentech

Firemní AI asistent často nemá odpovídat jen z obecných znalostí modelu. Mnohem užitečnější je, když si před odpovědí najde relevantní informace v interních dokumentech, manuálech, smlouvách nebo znalostní bázi. Tomu se říká RAG, tedy retrieval-augmented generation. Jednoduše řečeno jde o kombinaci vyhledávání a generování: systém nejdřív najde podklady a teprve potom z nich model sestaví odpověď.

Pro firmu je to zásadní rozdíl. Model nemusí mít všechno „v hlavě“, tedy uložené v natrénovaných parametrech, a může pracovat s aktuálními daty, která se ve firmě průběžně mění. Chatbot tak může odpovídat podle poslední verze interní směrnice, produktové dokumentace nebo obchodních podmínek, nejen podle toho, co se model naučil při tréninku.

Z hlediska výkonu ale přibývá další práce, kterou musí systém stihnout před samotnou odpovědí. Nejdřív je potřeba dotaz převést do podoby vhodné pro vyhledávání, najít relevantní pasáže, někdy je ještě znovu seřadit podle přesnosti, což se označuje jako reranking, a potom je vložit do promptu pro jazykový model. Teprve poté začne samotné generování odpovědi.

To je důvod, proč může být RAG asistent pomalejší a náročnější než jednoduchý chatbot bez napojení na dokumenty. Kapacitu neurčuje jen rychlost generování tokenů, ale i vyhledávání, databáze, práce s delším kontextem, kvalita dokumentů a aplikační vrstva kolem modelu. Tady se často ukáže rozdíl mezi pěkným demem a nástrojem, který se dá nasadit do každodenní práce. Demo může pracovat s několika připravenými otázkami a krátkými dokumenty. Produkční provoz ale přinese dlouhé soubory a nepřesné dotazy, které systém musí správně pochopit. Přidají se také různé verze dokumentů a více lidí, kteří budou asistenta používat ve stejný čas.

Demo proto může být dobrý začátek, ale nemělo by být posledním krokem před nákupem serveru. V praxi dává smysl chtít po dodavateli nebo interním IT týmu praktické ověření na realistickém scénáři, například s podobnými dokumenty, podobnou délkou dotazů a očekávaným počtem souběžných uživatelů. Může jít o technický proof of concept, tedy krátké ověření, zda řešení funguje v daných podmínkách, nebo o pilotní provoz pro vybraný tým. Forma se liší podle dodavatele i velikosti projektu, cílem je ale vždy zjistit ještě před investicí, zda se výkon z prezentace potká s realitou firmy.

Jeden server může stačit, pokud víte, co od něj čekáte

Pro vývoj, testování menších modelů nebo interního asistenta pro omezený počet lidí může být jeden výkonný AI server velmi dobré řešení. Firma získá kontrolu nad daty, stabilnější nákladový rámec a možnost ladit modely bez neustálého posílání citlivých vstupů do externí služby. U předvídatelné zátěže může vlastní infrastruktura dávat ekonomicky větší smysl než dlouhodobé placení cloudové kapacity.

U jedné mašiny je potřeba myslet hlavně na špičky a dostupnost služby. Pokud server obsluhuje kritickou aplikaci, musí mít část výkonu vyhrazenou pro provozní rezervu. Potřebné jsou také aktualizace modelu, ovladačů nebo inference enginu, které mohou dočasně změnit chování celé služby a ovlivnit její výkon. Jakmile se AI asistent přesune z omezeného nasazení do každodenní práce více týmů, začíná dávat smysl replikace modelu, více GPU nebo cluster více serverů.

Cloud zůstává silný tam, kde se pracovní zátěž mění, roste skokově nebo se teprve hledá správný model. Vlastní server je vhodnější ve chvíli, kdy už firma zná provozní profil a ví, že bude infrastrukturu využívat pravidelně. Rozhodnutí proto nemá stát jen na srovnání pořizovací ceny serveru a cloudového ceníku, ale také na tom, jak stabilní bude vytížení, jak citlivá jsou data a jak náročná bude správa celého prostředí.

Jak zadat benchmark, který má obchodní hodnotu

Dobrý kapacitní test začíná popisem služby, ne výběrem GPU. Firma by měla vědět, jaký typ uživatelů bude systém používat, jaké dotazy budou pokládat, jak dlouhé dokumenty se budou zpracovávat a jaká odezva je ještě přijatelná. Bez těchto vstupů se z benchmarku stane technické cvičení, které s budoucím provozem nemusí mít mnoho společného.

Technický tým by měl měřit nejen průměrnou odezvu, ale také p95 a p99 latenci. Tyto hodnoty ukazují, do jakého času se vejde 95 nebo 99 % požadavků, takže lépe odhalí pomalé odpovědi, které průměr snadno zakryje. Ve firemním provozu přitom často rozhodují špičky, dlouhé dokumenty a méně typické dotazy, protože tam se ukáže skutečná rezerva infrastruktury. V testu by měly být stejné komponenty jako v produkci. Pokud bude aplikace používat RAG, musí být v benchmarku i vyhledávání v dokumentech. Pokud se má odpovídat česky, mají být v testu české dotazy, a pokud budou uživatelé posílat dlouhé přílohy, krátký ukázkový prompt je pro kapacitní rozhodnutí zavádějící.

Prakticky stačí začít pěti čísly, která přeloží technický výkon serveru do reálného provozu firmy.

Jakmile tato čísla existují, dá se server porovnávat podle reality, ne podle marketingových parametrů. Bez nich se z výběru infrastruktury snadno stane drahá sázka na to, že výkon v datasheetu bude odpovídat skutečnému firemnímu provozu.

Nejlepší otázka při výběru AI serveru tedy nezní, jak výkonnou GPU má uvnitř. Mnohem užitečnější je zjistit, kolik tokenů za sekundu dokáže dodat v konkrétní aplikaci, při konkrétním modelu, s konkrétní délkou kontextu a s rezervou na špičku. Právě tam vzniká rozdíl mezi AI serverem, který v prezentaci vypadá skvěle, a infrastrukturou, která bude lidem skutečně zrychlovat práci. Firma, která chce AI používat seriózně, by proto měla začít malým kapacitním modelem a reálným pilotem, ale ne proto, aby se nákup zdržoval. Smyslem je utratit peníze za výkon, který bude vidět v provozu a který půjde dál rozumně škálovat. U AI serverů totiž nejdráže nevychází slabší hardware, ale výkon, který nikdo neumí správně využít.