Když se v softwaru mluví o optimalizaci, většinou tím myslíme rychlejší dotaz, menší latenci, levnější instanci, lepší cache nebo nižší účet za cloud. Frugal computing začíná o jednu otázku dřív: má výpočet proběhnout, kdy, kde a potřebujeme k němu právě tuto architekturu?

V návrhu systému je to víc než drobný posun. Běžná optimalizace vezme existující práci a snaží se ji udělat rychleji. Frugal přístup nejdřív zkoumá, kolik té práce má vůbec vzniknout. Někdy se ukáže, že doporučení stačí přepočítat jednou za hodinu, že analytický záznam nikdo nepoužívá, že modelové volání může nahradit pravidlo, nebo že další služba jen přidá síťové volání, měření a oprávnění navíc.

Co frugal computing znamená

Pojem se opírá hlavně o text Wima Vanderbauwhedeho Frugal Computing, zveřejněný na arXivu v březnu 2023. Jeho základ je jednoduchý: výpočetní zdroje nejsou neomezené. Zahrnují elektřinu a materiál v zařízeních uživatelů, sítích, serverech, úložištích, datových centrech i ve výrobě hardwaru.

Pomalejší software ani nostalgie po starých počítačích nejsou dobrý výklad. Smyslem je stejný užitečný výsledek s menší spotřebou energie, materiálu a technické režie. Pro vývojáře to znamená dívat se na výpočet jako na rozhodnutí, ne jako na samozřejmost. Každý požadavek na API, každá uložená událost, každá dávková úloha a každé volání jazykového modelu má mít důvod.

Frugal computing je střízlivější větev podobného uvažování jako permacomputing. Permacomputing pracuje s širším rámcem dlouhověkosti, opravitelnosti, odolnosti a omezených prostředků. Frugal computing z toho bere část, kterou lze snáz přenést do architektury běžné webové aplikace: méně zbytečných přesunů dat, delší životnost zařízení, jednodušší služby, rozumnější retenci a výpočet přiměřený hodnotě, kterou dostane uživatel.

Proč na tom záleží mimo kód

Důvodem není neurčitý dojem, že software bobtná. Tlak začíná být vidět v infrastruktuře. Mezinárodní energetická agentura v přehledu Key Questions on Energy and AI uvádí, že spotřeba elektřiny datových center má v jejím středním scénáři vzrůst z přibližně 485 TWh v roce 2025 na 950 TWh v roce 2030. To by odpovídalo asi třem procentům světové poptávky po elektřině. IEA k tomu dodává, že spotřeba datových center zaměřených na AI roste rychleji než celková spotřeba datových center.

Ta čísla nemají rozhodovat o každé změně kódu. Přesná stopa jednoho dotazu nebo jednoho zadání pro model se špatně zobecňuje: záleží na hardwaru, vytížení, modelu, délce vstupu a výstupu, místě běhu i energetickém mixu. Pro architekturu stačí skromnější závěr. Když systém dělá méně zbytečné práce, přesouvá méně dat a drží méně nepotřebných kopií, snižuje tím nároky, které jsou reálné i bez dokonalého emisního výpočtu.

Evropa z toho navíc dělá téma pro správce infrastruktury i nákup služeb. Evropská komise na stránce o energetické výkonnosti datových center popisuje databázi pro reportování spotřeby energie a vodní stopy datových center, evropské ukazatele a připravovaný balík, který má zavést hodnocení datových center a otevřít práci na minimálních výkonnostních standardech. Vývojářskému týmu to zatím nepřidává povinnou položku do každého návrhu funkce. Směr je přesto zřejmý: spotřeba infrastruktury se bude častěji měřit, porovnávat a vysvětlovat.

Prime Video jako varování před režií

Frugal computing nejlépe vysvětlují případy, kde se z úsporné úvahy stane konkrétní architektonická oprava. Dobrý příklad dodal v roce 2023 tým Prime Video. Jeho nástroj pro kontrolu kvality videa narazil v distribuované serverless architektuře na limity už kolem pěti procent očekávané zátěže. Náklady táhly hlavně přechody mezi službami, předávání mezivýsledků přes S3 a velký počet stavových přechodů v AWS Step Functions.

Po sloučení částí systému do jednoho procesu a přesunu na EC2 a ECS klesly podle Amazonu náklady na běh systému o 90 procent. Případ dobře shrnuje InfoQ. Devadesát procent tady popisuje konkrétní interní systém, ne obecný argument proti serverlessu nebo mikroslužbám.

Z případu neplyne obecné pravidlo. Pro architekturu je cenný hlavně detail: každá hranice mezi službami něco stojí. Serializaci, síť, oprávnění, logy, metriky, opakování neúspěšných volání, latenci a často i fakturační položku. Distribuovaná architektura má smysl, když odděluje vlastnictví, škálování nebo doménu. Když jen rozseká jednu úlohu na několik kroků bez skutečného důvodu, systém pálí zdroje na předávání stavu místo na výsledek, který má uživatel vidět.

Kde se ztrácí práce v běžné aplikaci

Frugal revize nemusí začít měřením uhlíku. Často stačí projít místa, kde systém vyrábí práci ze zvyku.

První jsou data. Každý analytický záznam, auditní stopa, log a uložená odpověď API má mít vlastníka, účel a dobu života. Věta „mohlo by se to někdy hodit“ je slabé zadání pro systém, který běží roky. Dlouhá retence zvětšuje úložiště, indexy, zálohy a repliky; při úniku dat pak roste škoda.

Druhé jsou přesuny dat. AWS ve svém Sustainability Pillaru doporučuje omezovat pohyb dat po síti, komprimovat data před přenosem a vracet jen ta data, která klient opravdu potřebuje. V běžné architektuře to znamená menší odpovědi API, méně duplicitních kopií, lepší umístění dat vůči službám a méně detailních záznamů tam, kde stačí agregace.

Třetí je čas. Ne každá úloha musí být synchronní a ne každá informace musí dorazit v sekundách. Doporučení, report, přepočet skóre nebo interní kontrola mohou často počkat na dávku, nižší zátěž nebo levnější časové okno. Systém, který rozlišuje sekundy, minuty a hodiny, má víc možností šetřit než systém, který všechno považuje za urgentní.

Čtvrté jsou modelová volání. Velký jazykový model může být správný nástroj, když přináší hodnotu, kterou jednodušší postup nedá. U úzkých a opakovaných úloh ale často stačí menší model, vyhledávání, pravidlo, šablona nebo ruční potvrzení. Úspornější varianta dává smysl jen tehdy, když nezhorší výsledek pro uživatele ani nepřesune práci na podporu.

Kde má úspornost hranice

Frugal computing se nesmí změnit v nové dogma. Monolit pomůže jen tam, kde sníží režii bez ztráty vlastnictví a jasných hranic. Lokální výpočet dává smysl jen u úloh, které zařízení uživatele zvládne bez znatelného dopadu na baterii, výkon nebo odezvu. Kratší retence nesmí zničit auditní dohled. Menší model nepřinese úsporu, pokud kvůli němu roste počet oprav, reklamací nebo ruční práce.

Stejně tak samotná efektivita nezaručuje menší celkovou spotřebu. Když zlevní jedno modelové volání, produkt ho může začít používat všude. Když zlevní úložiště, data se přestanou mazat. Když se zrychlí služba, začne obsluhovat víc vedlejších scénářů. U úsporného návrhu proto rozhoduje i počet operací, které v systému vůbec vzniknou.

Měření pomáhá. Nesmí ovšem předstírat přesnost, kterou nemá. Green Software Foundation ve specifikaci Software Carbon Intensity pracuje s uhlíkovou intenzitou vztaženou k funkční jednotce: požadavku, uživateli, transakci nebo dávkové úloze. Je to užitečné vodítko i tam, kde tým nemá dokonalá data. Nejdřív pojmenujte hodnotu, kterou software dodává. Teprve potom měřte, kolik výpočtu, energie, hardwaru a přesunů dat k ní spotřebujete.

Jak z toho udělat revizi návrhu

Praktická podoba frugal computingu je prostá: přidat několik přesných otázek do návrhu funkce nebo architektonické revize.

• Musí se výpočet spustit při každém požadavku, nebo stačí dávka, cache či přepočet při změně?
• Musí být výsledek synchronní, nebo má produkt toleranci minut či hodin?
• Musí data opustit zařízení, datové centrum nebo region?
• Musí služba vracet celý objekt, nebo klient potřebuje jen několik polí?
• Musí se použít jazykový model, nebo stačí pravidlo, vyhledávání, SQL dotaz či menší model?
• Musí být výstup uložen trvale?
• Musí mít tahle část systému vlastní službu?
• Víme, kdo daná data, metriky a logy používá a kdy je smažeme?

Zkušené týmy si podobné otázky kladou už dnes, často kvůli ceně, výkonu nebo jednodušší správě systému. Frugal computing jim dává společné jméno a širší souvislost. Každá abstrakce má režii, každý uložený záznam náklady, každé modelové volání cenu a každá distribuovaná hranice musí mít důvod. Když ho nemá, nemá tam být.

Frugal computing nevrací software do minulosti. Vrací do návrhu otázku, kterou éra levného cloudu a snadno dostupných modelů často přeskočila: co přesně se tady vyplatí počítat?