Lokální LLM, nebo cloud: levnější volbu mění vytížení

Při nepravidelné zátěži obvykle vychází levněji cloudové API: firma platí za zpracované požadavky a nemusí držet vlastní výpočetní kapacitu v pohotovosti. Lokální LLM může získat cenovou výhodu při trvalém vytížení, zejména pokud se o hardware dělí více úloh. Rozhodující je náklad na přijatelně dokončenou práci, nikoli nulová cena lokálně vygenerovaného tokenu.

Do srovnání patří pořizovací cena a provoz zařízení, práce správců, skutečné využití kapacity i čas potřebný k opravám výstupů. Účet za cloudové API zase závisí na zvoleném modelu, poměru vstupních a výstupních tokenů a využití cache. Požadavek na provoz bez internetu nebo na umístění citlivých dat může výběr omezit dříve, než začne cenový výpočet.

Co patří do celkových nákladů

U lokálního modelu je nutné rozpočítat pořízení a obnovu zařízení na dobu jeho používání. Přidává se elektřina, chlazení, úložiště, zálohy a práce lidí, kteří model instalují, aktualizují, zabezpečují a řeší výpadky. Ani již vlastněné GPU není automaticky zdarma: kapacita přidělená inferenci nemůže současně sloužit jiné úloze, která by ji využila.

U API tvoří základ účet za volání, případné placené nástroje a práce na integraci. U obou variant stojí peníze kontrola výsledků, opakování neúspěšných pokusů a lidské opravy. Sazba za token proto sama neříká, kolik stojí hotový úkol: různé sestavy mohou ke stejnému přijatelnému výsledku potřebovat odlišný počet pokusů i zásahů člověka.

V případové studii programovacích agentů vyšel při tchajwanských cenových předpokladech sdílený lokální výkon v celkových nákladech o 40,1 % levněji než API s cache, zatímco vyhrazená kapacita byla o 43,8 % dražší; lokální sestava zároveň vykazovala vyšší zátěž oprav. Srovnání sledovalo navazující období práce jednoho vývojáře s odlišnými agenty a modely. Výsledek tak ukazuje význam přidělení GPU, ale neurčuje univerzální cenový rozdíl mezi lokálním modelem a libovolnou cloudovou službou.

Bod zvratu určuje objem práce a volná kapacita

Pro orientační výpočet označme stálé měsíční náklady lokálního provozu jako F, jeho proměnlivý náklad na dokončený úkol jako L a odpovídající náklad přes API jako C. Do L a C patří také očekávané opakování požadavků a opravy, pokud se mezi variantami liší. Jestliže je C vyšší než L, bod zvratu představuje F dělené rozdílem C a L; při stejném nebo nižším C samotný růst objemu lokální variantě v tomto modelu nepomůže.

V čistě modelovém příkladu by stálý náklad 30 000 Kč měsíčně a úspora jedné koruny na dokončeném úkolu znamenaly bod zvratu při 30 000 úkolech za měsíc. Takový výsledek platí pouze pro zadané předpoklady. Pokud se změní cena API, životnost zařízení, podíl oprav nebo využití cache, změní se i hranice, od níž se investice vyplácí.

Měsíční součet úkolů navíc nepopisuje jejich rozložení v čase. GPU vyhrazené kvůli krátkým špičkám může většinu dne zahálet, zatímco sdílení mezi úlohami s odlišnými špičkami rozloží stálý náklad na více práce. Sdílení má své meze: při příliš velkém souběhu rostou fronty a firma může potřebovat další kapacitu, aby dodržela požadovanou dobu odezvy. Do rozhodnutí proto patří současně průměrné vytížení, špičky i cena čekání.

Cache může změnit účet za cloud

Pro API nestačí vynásobit všechny tokeny jedinou sazbou. Ceník OpenAI API odděluje běžné vstupy, vstupy přečtené z cache, zápisy do cache a výstupy; sazby se navíc liší podle modelu a režimu zpracování. Aplikace, která v mnoha požadavcích používá stejný dlouhý kontext, tak může mít jiný účet než aplikace se stále novými vstupy, přestože obě odešlou podobný počet tokenů.

Slevu však nelze automaticky připsat každému opakovanému požadavku. Dokumentace ke cache promptů váže opětovné použití na shodný způsobilý prefix, dostupnost uložené položky a směrování požadavku; podmínky se liší podle modelu. V kalkulaci má proto místo skutečně dosažený podíl zásahů do cache a cena jejího zápisu. Pouhé opakování podobného tématu úsporu nezaručuje.

Lokální provoz má jinou proměnlivou část nákladů: energie a práce spojená s jednotlivými úlohami mohou růst, zatímco pořizovací výdaj se rozpočítává na více dokončené práce. Krátký test maximální rychlosti ale neukáže, kolik souběžných úloh zařízení zvládne při požadované odezvě. Obě varianty je třeba počítat za stejné období a při srovnatelné kvalitě služby.

Kvalita se promítá do ceny oprav

Levnější generování nepřináší úsporu, pokud výstupy častěji vyžadují kontrolu, nové zadání nebo ruční přepracování. U programovacích agentů může oprava zahrnovat čtení změn, další spuštění testů a hledání chyby; u práce s dokumenty může jít o ověření tvrzení a opravu nepoužitelného návrhu. Smysluplnou jednotkou srovnání je proto přijatý výsledek se započtením času člověka.

Praktické srovnání Tom’s Guide popsalo výhody testovaného lokálního nástroje pro soukromí, práci offline a přizpůsobení; ChatGPT v tomto spotřebitelském testu lépe zvládal náročné otázky a nabízel integrovaný přístup k aktuálním informacím. Podnikové API může používat jiné modely a nástroje. Pro firemní volbu je proto podstatné, zda konkrétní sestava zvládne její vlastní úlohy v požadované kvalitě, nikoli obecné pořadí lokálních a cloudových modelů.

Soukromí a dostupnost mění přípustné varianty

Lokální model může zpracovávat vstupy i výstupy uvnitř firemní infrastruktury a fungovat bez připojení k poskytovateli API. Záleží ovšem na zapojení externích nástrojů, nastavení sítě, logování a záloh. Firma zároveň přebírá odpovědnost za přístupy, zabezpečení sdíleného prostředí a obnovu po výpadku. U citlivých úloh může být tato kontrola důležitější než rozdíl v ceně.

Cloudové API je nutné hodnotit podle podmínek konkrétní služby. Pravidla OpenAI pro data v API uvádějí, že zákaznický obsah se standardně nepoužívá k trénování modelů, provozní záznamy však mohou obsahovat prompty a odpovědi a přísnější režimy uchovávání vyžadují schválení. Požadavek na regionální zpracování je třeba posoudit zvlášť podle podporovaného modelu, funkce a sjednaných podmínek.

Do provozního srovnání patří také dostupnost. Vlastní zařízení potřebuje plán pro poruchu a údržbu; API zase závisí na připojení, limitech služby a dostupnosti poskytovatele. Záložní kapacita může zlepšit spolehlivost obou řešení, ale zvyšuje náklady. Nejlevnější varianta podle běžného měsíčního účtu nemusí splnit požadavek na nepřerušenou práci při výpadku.

Kdy dává smysl kombinace

Hybridní provoz může směrovat opakované nebo citlivé úlohy na místní model a náročnější úlohy do cloudu. Vyplatí se, pokud rozdíl v ceně nebo kvalitě převýší náklady na směrovací pravidla, správu obou prostředí a případné opakování práce po nevhodné volbě modelu. Citlivý vstup přitom nemá automaticky přejít do cloudu jen proto, že lokální odpověď neuspěla.

Výběr tak stojí na skutečném objemu přijatelně dokončené práce, průběhu zátěže a požadavcích na data a dostupnost. Kolísavá poptávka často nahrává platbě za API; stabilní zátěž a dobře sdílený hardware mohou převážit ve prospěch lokálního provozu. Kombinace má hodnotu tam, kde firma dokáže úlohy rozdělit podle jejich nároků a započítat cenu tohoto rozdělení.