Nová dovednost pro stávajícího agenta
Amazon Web Services rozšířil službu SageMaker AI optimized generative AI inference o dovednost nazvanou aws-ai-ml. Podle AWS je dostupná přes Agent Toolkit for AWS a míří na vývojáře, kteří už používají kódovacího agenta, tedy program s umělou inteligencí, který za ně píše a spouští kód. Po instalaci má agent podle firmy umět testovat endpointy, doporučovat konfigurace nasazení, porovnávat výsledky měření výkonu a generovat spustitelný kód v SageMaker Python SDK v3. Inferencí se přitom myslí provoz hotového modelu, tedy chvíle, kdy model přijímá dotazy a vrací odpovědi. Nejzajímavější částí oznámení je ukázkové srovnání dvou modelů. Ukazuje, jak snadno se dá z čísel vyčíst víc, než v nich opravdu je.
Co agent po instalaci zvládne
AWS popisuje čtyři okruhy práce. Agent může změřit výkon nasazeného endpointu, tedy modelu dostupného k dotazování. Může také navrhnout konfiguraci nasazení, porovnat dva běhy měření a vše převést do kódu, který lze rovnou spustit. Důležité je slovo „stávající“: podle popisu se nemá nahrazovat agent, který vývojář už používá, jen se mu přidává specializovaná znalost. Prakticky to znamená, že vývojář nemusí ručně skládat měřicí skripty, ale může si je nechat vygenerovat. Z dodaného textu ale nelze posoudit, jak kvalitní jsou doporučení konfigurace. Zdroj je blog samotného dodavatele, nikoli nezávislé ověření, a tak jde o tvrzení AWS, nikoli o změřený fakt.
Jak vypadá zátěžový test
Při benchmarku existujícího endpointu stačí agentovi říct, který endpoint chcete otestovat. Podle AWS pak vygeneruje notebook v Pythonu, který provede zátěžový test pomocí rozhraní Workload.synthetic() a start_benchmark() ze SageMaker Python SDK. Notebook je dokument, v němž se kód spouští po částech a hned vedle se zobrazují výsledky. Zátěžový test znamená, že na model pošleme sérii dotazů a sledujeme, jak rychle odpovídá. Slovo „synthetic“ naznačuje umělě vytvořenou zátěž, nikoli provoz skutečných uživatelů. Výsledkem je tedy kód, který si lze prohlédnout a případně upravit, ne neprůhledné měření skryté v agentovi. Pro opakovatelnost je to výhoda: stejný notebook lze použít znovu a porovnat dva běhy za stejných podmínek.
Bezpečnostní pojistka před spuštěním
Benchmark není neškodné čtení dat. Posílá skutečný provoz na živý endpoint. AWS proto uvádí, že agent před spuštěním ověří, zda je endpoint bezpečné zatěžovat. Zároveň má upozornit na dopad testu a požádat o výslovné potvrzení. Jde o rozumné opatření, protože konečné rozhodnutí zůstává na člověku a agent nespouští zátěž sám od sebe. Zdroj ale v dodaných pasážích nevysvětluje, podle čeho agent bezpečnost endpointu posuzuje, takže jeho spolehlivost nelze z textu vyhodnotit. Potvrzení proto nestačí odkliknout automaticky; vývojář by měl vědět, co endpoint obsluhuje.
Příklad: dva modely, jeden zdánlivý vítěz
AWS ukazuje srovnání modelů Qwen3-1.7B a Qwen3-8B na stejné zátěži: 512 vstupních a 256 výstupních tokenů při souběžnosti 4, tedy se čtyřmi dotazy zpracovávanými současně. Token je zjednodušeně dílek textu, s nímž model pracuje, takže dotaz měl zhruba 512 takových dílků a odpověď 256. Větší Qwen3-8B vyšel v propustnosti výstupních tokenů o 44,1 % lépe, a to 271,2 oproti 188,2 tokenu za sekundu. Vyšší byla i propustnost na jednoho uživatele (69,4 oproti 47,5 tokenu/s, tedy o 45,9 %) a počet obsloužených požadavků (1,08 oproti 0,736 za sekundu, o 46,7 %). Zkrátila se i latence mezi tokeny, z 20,9 na 14 ms, a celková latence požadavku, z 5 382 na 3 658 ms. Latence je zde čas, který uplyne, než se něco stane; kratší je lepší.
Jediná metrika, která šla opačným směrem
Jediná metrika vyšla v neprospěch většího modelu: čas do prvního tokenu, tedy čekání, než se na obrazovce objeví začátek odpovědi. U Qwen3-8B činil 166,3 ms, u menšího modelu 67,5 ms. Tabulka to označuje jako zhoršení o 146,5 %, což odpovídá zhruba dvapůlnásobku původní hodnoty. Pro uživatele chatu může být právě tohle čekání nejvíc znát, zatímco propustnost je důležitější při zpracování velkého množství požadavků. Který model je „rychlejší“, tedy záleží na tom, co se měří. Podle výkladu autora tohoto článku z příkladu plyne, že jediné číslo na takovou otázku neodpoví a že tabulka s více metrikami je poctivější než jedno vítězné skóre.
Jak spolu čísla souvisejí
Hodnoty v tabulce spolu logicky souvisejí, což lze zkontrolovat jednoduchým přepočtem. Je to však jen orientační výpočet autora článku, nikoli tvrzení z blogu AWS. Čtyři souběžní uživatelé při 47,5 tokenu/s na osobu dávají zhruba 190 tokenů za sekundu, což se blíží celkové propustnosti 188,2. U většího modelu vychází čtyřnásobek 69,4 na zhruba 278, kdežto naměřeno bylo 271,2. Podobně 256 výstupních tokenů po 14 ms dává asi 3,6 sekundy, tedy blízko k celkové latenci 3 658 ms. Z toho plyne praktický závěr: u takto dlouhé odpovědi určuje celkovou dobu hlavně generování samotných tokenů, zatímco rozdíl v čase do prvního tokenu je v součtu malý. Pro krátké odpovědi by ale poměr vypadal jinak a příklad to neověřuje.
Pozor na nerovné podmínky
Největší výhradu si AWS do příkladu zapsal sám. Modely neběžely na stejném hardwaru: Qwen3-8B využíval čtyřgrafický stroj ml.g5.12xlarge se čtyřmi GPU A10G, kdežto Qwen3-1.7B jedinou GPU L4 na instanci ml.g6.4xlarge. GPU je grafický procesor, který se při provozu jazykových modelů používá k výpočtům. Rozdíly podle autorů odrážejí zhruba čtyřnásobný výpočetní výkon, nikoli jen vlastnosti modelů. Rychlejší výsledek většího modelu proto nelze číst jako důkaz, že je ze své podstaty efektivnější. Pro čtenáře je to užitečná připomínka, že srovnání bez shodných podmínek měří kombinaci modelu a hardwaru, ne model samotný. Fér srovnání by obě varianty postavilo na stejné instance, jinak čísla slouží spíš jako ilustrace formátu výstupu než jako verdikt.
Úklid, který se snadno zapomene
Experimenty s nasazenými modely stojí peníze i po skončení měření. AWS proto upozorňuje, že je kvůli zbytečným poplatkům nutné smazat endpointy vytvořené při benchmarku nebo při doporučování konfigurace. Pokud jste pracovali v SageMaker Studiu, je třeba zastavit nebo smazat JupyterLab space. Zbývá odstranit objekty v S3, které benchmarkové a doporučovací úlohy uložily do výchozího bucketu SageMaker AI. Vývojář, který agentovi delegoval spouštění testů, by si tedy měl hlídat i úklid. Z dodaného zdroje nevyplývá, že by ho agent provedl automaticky, a po sérii experimentů s více modely se zapomenutých zdrojů může nahromadit víc, než by se čekalo.
Co zdroj nedokládá
Zdroj je popis funkce od jejího výrobce. V dodaných pasážích se objevuje jediný ukázkový případ a nenajdeme v nich údaje o tom, jak často agent navrhne dobrou konfiguraci, jak dlouho měření trvá ani kolik stojí. Nenajdeme tam ani srovnání výsledků agenta s testem, který by vývojář sestavil ručně. Nelze přitom vyloučit, že některé z těchto informací zazní v částech zdroje, které jsme neměli k dispozici. Konkrétní čísla navíc pocházejí z nesrovnatelného hardwaru, takže o modelech Qwen3 nic obecného nevypovídají. Dá se z nich zjistit hlavně to, jaký výstup má agent vytvářet a kde hrozí chybná interpretace. Praktický první krok je jasný: srovnávat modely na shodném hardwaru, číst více metrik najednou a každý test před spuštěním potvrzovat s vědomím, že běží na živém endpointu.
Zdroje
- New agent skill: Amazon SageMaker optimized generative AI inference for your coding agent | Artificial Intelligence — AWS Machine Learning Blog
Článek vznikl s pomocí AI; podklady a odkazy jsou uvedeny výše.