← Zpět k článkům
Quando l'AI aziendale non sa quello che sa Kapitola 5 z 6
AI 2026-04-16 ProtoMedia

Skrytý náklad cloudu

Přeloženo automaticky z italštiny · přečíst originál

Kapitola 5 — Skrytý náklad cloudu

Dominantní narativ posledních pěti let říká, že cloud je ekonomický, škálovatelný a jednoduchý. Pro mnoho pracovních úloh to platí naprosto. Pro podnikové RAG to však stále častěji není pravda. A moment, kdy si to uvědomíte, je obvykle na konci prvního čtvrtletí, když dorazí faktura.

Vezměme si nejvíce podceňovanou položku účtu: API modelů pro zpracování obrazu. Když společnost načte svůj fotografický archiv do moderního RAG, každou fotografii musí "popsat" multimodální model, který z ní extrahuje obsah, objekty, kontext, případný text, náladu, kompozici. Velký evropský poskytovatel modelů – zatím bez jména – nabízel v roce 2025 vynikající model z rodiny Qwen s 32 miliardami parametrů za zajímavou cenu za obrázek. Problém, který se zjistil až v praxi a po měsících produkce: při zatížení poskytovatel ořezával odpovědi. Ne vždy, ne předvídatelně, ne když tam byl testovací tým: náhodně. Jedna fotografie z deseti, někdy jedna z pěti, se vracela s JSONem useknutým v půli, špatně parsovaným, s částečnými nebo nulovými metadaty. Časy se vyšplhaly z deseti sekund na dvě stě sekund na obrázek, bez vzorce. Účet za opakované pokusy – protože opakované pokusy se platí, každý požadavek, i ten, který server usekne – byl vyšší, než se očekávalo. Databáze byla nehomogenní: některé fotografie bohaté na metadata, jiné useknuté. A tým nedokázal problém reprodukovat v testovacím prostředí, protože v testech bylo nízké zatížení a vše fungovalo.

Řešení přišlo ve třech částech: kompaktnější prompt (stručnější odpovědi se méně ořezávají), inteligentní logika opakování (pokud odpověď trvá déle než padesát sekund a vrátí prázdný výsledek, zkuste to znovu okamžitě) a – když to objem ospravedlňuje – možnost přeskočit cloud a spustit model pro zpracování obrazu na lokální GPU, která je pomalejší, ale deterministická. Správná architektura, jak ukázala tato zkušenost, není "vždy cloud" ani "vždy lokálně". Je to "vyberte pro každý požadavek podle toho, co je v daném okamžiku potřeba".

Pak je tu kapitola dotazů. Každé uživatelské vyhledávání v klasickém cloud-nativním RAG spouští kaskádu placených API volání. Jedno pro vložení dotazu. Jedno pro klasifikaci záměru (o jaký typ dotazu se jedná?). Jedno pro opětovné řazení dokumentů. Jedno pro generování finální odpovědi. Každé stojí zlomek centu. Pro interní službu s padesáti uživateli a deseti tisíci dotazy denně – což není málo, ale ani obrovské číslo pro střední firmu – měsíční účet dosáhne částek, které by zvedly obočí i shovívavému finančnímu řediteli. A růst je lineární: zdvojnásobíte uživatele, zdvojnásobíte účet. Neexistují žádné úspory z rozsahu v použitých tokenech, ne pro vás.

Existuje také problém, který se v roce 2025 rýsoval v pozadí a v roce 2026 se stal zásadní: každá jednotlivá dotaz posílá fragmenty firemních dokumentů – někdy důvěrných, někdy krytých NDA, někdy podléhajících odvětvovým předpisům – na servery externího dodavatele, v jurisdikcích, které se nemusí shodovat s vaší, s pravidly pro uchovávání protokolů, která nejsou vždy průhledná. Více než jedna evropská společnost v posledních osmnácti měsících zjistila během auditu – obvykle vyvolaného znepokojeným zákazníkem nebo kontrolou ISO – že její smlouvy, ceníky a technické specifikace byly zpracovány (a potenciálně protokolovány pro účely „zlepšení služeb“) infrastrukturou mimo EU. Překvapení obvykle stálo více, než úspora na lokálním hardwaru, které se chtěly vyhnout.

Alternativa není opačný dogmatismus. "Ne do cloudu, ano lokálně" je stejně špatně jako "vždy do cloudu". Alternativou je architektura, která vám umožní vybrat si pro každý jednotlivý díl pipeline – embedding, klasifikace, přerovnávání, vidění, finální generování – zda použít cloudový model nebo lokální, a změnit názor během dne, nikoli čtvrtletí. To vyžaduje návrh, ve kterém jsou dodavatelé zaměnitelní, kde žádný díl není pevně spojen se jménem konkrétní společnosti, kde přechod z Regola na Ollamu (nebo naopak) je řádek konfigurace, nikoli přepisování. A to bylo ještě nedávno vzácné. Populární frameworky, navzdory fasádě "nezávislé na poskytovateli", byly ve skutečnosti silně vázány na někoho.

Lekce v kostce: Správná architektura není 'vždy do cloudu' ani 'vždy lokálně'. Je to 'vyberte si pro každý požadavek, podle toho, co je v daném okamžiku potřeba'.

Máte připomínku? Napište nám

Zpráva je určena pouze nám. Pokud bude váš komentář zajímavý, můžeme ho zveřejnit na konci článku, ale až po posouzení.

Zatímco píšete, váš prohlížeč řeší drobný výpočet – to je náš způsob, jak zabránit automatické poště bez použití externích služeb a bez nutnosti rozpoznávat semafory. Nic se vás neptáme a žádná data toto místo neopustí.