Rychlá odpověď na jedinou krátkou otázku ukazuje, že lokální jazykový model v zásadě funguje. Pro rozhodnutí o infrastruktuře je mnohem užitečnější test s budoucími úlohami a jejich skutečnou zátěží. Patří sem kvalita odpovědí, čekací doby, delší vstupy, souběžné používání a provoz po chybě.
Pilot je zvlášť užitečný, pokud se předem určí, jaké rozhodnutí má jeho výsledek umožnit. Například: stačí současné prostředí, je potřeba jiný hardware, nebo se lépe hodí externí či hybridní služba? Plán testování vychází z této otázky.
Začít malým souborem reprezentativních úloh
Vhodné testovací úlohy vycházejí z plánovaného pracovního postupu: krátká odborná otázka, shrnutí delšího schváleného dokumentu nebo návrh skriptu ke kontrole. U každé úlohy se stanoví, podle čeho poznat použitelný výsledek.
U znalostních otázek patří do testu očekávané zdroje i případy bez dostatečného podkladu. Kód vyžaduje odbornou kontrolu a vhodné testy. Důvěrná původní data se používají pouze v prostředí schváleném pro tento účel; pro přípravu mohou stačit vhodně očištěná nebo zvlášť vytvořená testovací data.
Posuzovat kvalitu a rychlost odděleně
Model, který rychle vrací chybné výsledky, nesplňuje cíl. Nejprve se proto hodnotí odborná použitelnost, nutné opravy a zacházení s chybějícími informacemi. Poté lze porovnat dobu odezvy a úsilí potřebné k dosažení této kvality.
Zaznamenává se verze modelu, kvantizace, inferenční software, nastavení a testovací data. Jinak může rychlejší odpověď vycházet ze změněné úlohy nebo jiné úrovně kvality. Také měnící se soubor dokumentů může ovlivnit porovnání aplikace RAG.
Rozdělit čekání na jednotlivé části
- Doba do prvního tokenu
- Popisuje, kdy začíná výstup. Ovlivnit ji může fronta a zpracování vstupu. Měřit by se měla i uživatelem vnímaná doba od odeslání v aplikaci po zobrazení odpovědi.
- Průběžné generování
- Rychlost generování ovlivňuje délku vytváření delší odpovědi. Vysoká celková propustnost serveru sama neříká, jak rychle dostane odpověď jednotlivý uživatel.
- Celková doba
- Zahrnuje celou aplikační operaci. Přidat se může vyhledávání, příprava dokumentů, volání nástrojů a síťové přenosy.
- Rozptyl a chyby
- Typické hodnoty se posuzují společně s pomalejšími okrajovými případy. Do výsledku patří počet měření, překročené časové limity a přerušené úlohy.
Dokumentace oficiálních metrik vLLM (externí odkaz) rozlišuje mimo jiné čekání, zpracování vstupu a výstup. U konkrétního běhového prostředí je třeba ověřit metriky dostupné v používané verzi. Měření různých komponent musí popisovat stejné období a stejnou úlohu.
Testovat krátké chaty, dlouhé kontexty a souběh
Dlouhý kontext vyžaduje další výpočty a paměť. Souběžné požadavky sdílejí dostupné prostředky. Dokumentace kontextu v Ollama (externí odkaz) a dokumentace optimalizace vLLM (externí odkaz) vysvětlují související vztahy; konkrétní nastavení závisí na verzi a hardwaru.
Smysluplný test proto kombinuje krátké a delší vstupy se souběhem odpovídajícím plánovanému využití. Vedle rovnoměrně přicházejících požadavků se posuzují i očekávané špičky. Pokud dávkové zpracování zvýší propustnost, je stále nutné ověřit, zda jednotlivé doby odezvy vyhovují uživatelům.
Možný plán testování
Nejprve spustit stejné odborné úlohy jednotlivě. Poté společně otestovat krátké požadavky a úlohy se schválenými dokumenty. Následně napodobit očekávanou špičku a sledovat chování při přetížení. Cílové hodnoty se předem dohodnou s uživateli.
Tento plán je přizpůsobitelným příkladem. Neobsahuje naměřené výkonové údaje DAXS a nenahrazuje posouzení konkrétního prostředí.
Rozlišovat start, běžný provoz a obnovu
Po restartu může být nejprve nutné načíst model. Tento studený start se měří odděleně od provozu s již načteným modelem. Rychlé disky NVMe mohou pomoci s načítáním a datovými operacemi; neznamená to obecné zrychlení generování tokenů u modelu uloženého celý v paměti GPU.
Do pilotu patří také výpadek spojení, přerušená úloha a restart služby. Aplikace by měla srozumitelně zobrazovat svůj stav a nabídnout vhodné opakování nebo předání. Přetížení nesmí bez upozornění vést k neúplným výsledkům.
Převést výsledky do rozhodnutí o architektuře
Porovnávají se použitelné výsledky, náročnost oprav, latence, kapacita a průběžný provoz. Do celkových nákladů patří také správa, údržba, energie, zálohování a požadovaná dostupnost. U externích služeb přistupují skutečné náklady na používání a dohodnuté cesty dat.
Výsledkem může být menší vhodný model, další prostředky, omezená fronta nebo jiný provozní model. Lokální, externí a hybridní přístupy se hodnotí podle stejné úlohy. Pilot má umožnit podložené další rozhodnutí, nikoli dodatečně ospravedlnit nákup předem předpokládaného hardwaru.
DAXS naplánuje test, připraví vhodné prostředí a vyhodnotí výsledky s vaším IT. Technické základy vysvětluje naše odborná stránka o lokálních LLM a infrastruktuře. U připojených znalostních zdrojů patří kvalita vyhledávání, zdrojů a oprávnění do stejného rámce ověřování.
