Otázka AI stacku, před kterou bude stát každý vývojářský tým

V určitém okamžiku se každý engineering tým začne ptát na věc, která vypadá banálně až v retrospektivě: Proč vlastně předáváme tolik naší vývojářské infrastruktury externím poskytovatelům?

Nejde o řečnickou otázku ani o výzvu k opuštění hosted AI služeb. Je to praktická úvaha o infrastruktuře, kterou se čím dál víc týmů začíná vážně zabývat – hlavně když se AI coding nástroje stávají každodenní součástí workflow.

Nedávno jsem narazil na zajímavou case study, která přesně ukazuje, proč tohle téma dává smysl. Malý tým v Parity se rozhodl vyzkoušet takzvaný „experiment s 20% časem" – v podstatě dali hrstce engineerů prostor zkoušet, jestli by self-hosted AI modely mohly fungovat pro reálné vývojářské úkoly. Co začalo jako odpolední pokus, se táhlo několik týdnů. Dvacet pět inženýrů dohromady zpracovalo téměř 13 miliard tokenů přes self-managed inference infrastrukturu.

Čísla jsou docela působivá. Jenom za první tři dny to bylo přes 3 miliardy tokenů, přičemž náklady na GPU compute se pohybovaly kolem 0,10 USD za milion tokenů. Celkový účet za měsíc? Zhruba 1200 USD. Není to málo, ale taky to rozhodně není ten drahý strašák, kterého si spousta týmů automaticky představuje, když slyší „self-hosted AI".

Skutečné náklady nejsou tam, kde byste čekali

Tady je ten moment, který mě zaujal nejvíc: náklady na GPU compute, ačkoliv reálné, byly vlastně tou menší položkou. Větší investicí byl čas inženýrů – nastavení infrastruktury, benchmarking výkonu a učení se, jak systém spolehlivě provozovat.

Tohle je vzorec, který vidím v infrastrukturních rozhodnutích pořád dokola. Přímé náklady jsou vidět a snadno se rozpočtují. Skryté náklady jsou čas a pozornost, které váš tým věnuje budování operačních znalostí o nových systémech. Parity tým vsadil na to, že tyto znalosti se časem kumulují – že budováním infrastruktury, benchmarků a operačních playbooků teď investují do kapacit, které se vyplatí u budoucích workloadů.

Tahle úvaha by měla znít povědomě každému, kdo někdy řešil cloud hosting, container orchestration nebo managed databáze. Poměřujete operační komplexitu proti kontrole, úspoře nákladů a strategické flexibilitě, kterou získáte. Někdy vyhraje managed řešení. Někdy dává smysl vlastnit celý stack.

Jak ve skutečnosti vypadá „jednoduchá architektura"

Jedna věc, kterou jsem ocenil na Parity článku, byla otevřenost ohledně jejich architektury. Nepouštěli žádný vlastní inference cluster postavený na míru. Jejich stack byl překvapivě přímočarý:

Společná interface vrstva (použili LiteLLM) sedí mezi developer nástroji a modely obsluhujícími požadavky. Za touto vrstvou se o model serving stará vLLM. GPU kapacita běží na pronajatém cloudu. Celé řešení je záměrně navržené tak, aby inženýři mohli dál používat své oblíbené vývojářské prostředí a klienty, zatímco tým si zachovává flexibilitu ohledně toho, které modely a poskytovatelé jsou za společným endpointem.

Tady je klíčový vhled, který spousta týmů přehlíží, když zavrhuje self-hosted možnosti: nemusíte si vybírat mezi kontrolou a pohodlím. Dobře navržená abstrakční vrstva znamená, že vaši vývojáři pracují se stejnými nástroji jako vždy. Rozdíl je v tom, že vy rozhodujete, který model odpoví, jaká data se logují a jak se náklady alokují.

Představte si to jako správu DNS. Vaši vývojáři nepotřebují rozumět všem detailům DNS propagace, aby efektivně používali doménová jména. Pracují s čistým rozhraním. Ale za ním někdo udělal záměrná rozhodnutí o nameserverech, TTL a redundanci. Stejný princip platí tady.

Co nám čísla skutečně říkají

Operační data z Parity experimentu jsou místo, kde to začíná být opravdu užitečné pro týmy, které zvažují podobné setup-y. Sledovali context lengths, request parallelism, throughput a queue times napříč reálnými vývojářskými workflow.

Několik čísel, která vystoupila:

Devadesát devět procent požadavků využívalo méně než 500k tokenů contextu. Více než polovinu času systém obsluhoval přesně jeden konkurenční požadavek. V peaku viděli prefill processing na 168k tokenech za sekundu, s mean time to first token kolem 3,34 sekundy.

Distribuce tvarů požadavků říká důležitý příběh. Většinu času vaše inference infrastruktura zpracovává relativně modestní, single-threaded požadavky od vývojářů. Paralelní scénáře, které provětrávají váš setup, jsou výjimkou, ne pravidlem.

To má praktické dopady na capacity planning. Nemusíte nutně provisionovat pro peak paralelní zatížení pořád. Dobře navržený systém může škálovat dynamicky a zároveň držet baseline náklady rozumně.

Strategická otázka: Kontrola vs. Pohodlí

Tady vidím tu skutečnou hodnotu experimentů jako je tenhle: učí celé odvětví, jak vlastně vypadá „AI infrastrukturová nezávislost" v praxi.

Jsme v zajímavém přechodném období. AI coding nástroje se stávají nezbytnou součástí toho, jak týmy staví software, ale industrie pořád zjišťuje, co znamená tyto workloady provozovat zodpovědně. Otázky ohledně data retention, cost predictability, model availability a vendor lock-in jsou všechno reálné obavy, které vývojářské týmy začínají brát vážně.

Parity experiment naznačuje, že self-hosted inference je dostupnější, než si spousta lidí myslí. Nepotřebujete obří engineering org ani custom hardware na začátek. Potřebujete jasné požadavky, rozumnou architekturu a ochotu investovat do operačních znalostí.

Jestli ten trade-off dává smysl, záleží úplně na vašem kontextu. Ale fakt, že je to vůbec životaschopná varianta, stojí za pochopení – obzvlášť když se AI nástroje integrují čím dál hlouběji do toho, jak software shipujeme.

Kde to zapadá do cloud hostingového landscape

Z pohledu cloud infrastruktury má tenhle trend zajímavé implikace. Možnost pronajímat GPU kapacitu místo ji nakupovat znamená výrazně nižší barrier to entry. Dostanete operační flexibilitu self-hosted infrastruktury bez kapitálových výdajů za hardware.

Tohle je stejná evoluce, kterou jsme viděli jinde v cloud computingu. Managed služby abstrahují komplexitu, ale taky abstrahují kontrolu. Self-hosted varianty na cloud infrastruktuře vám dávají víc kontroly bez nutnosti stavět a udržovat fyzický hardware.

Pro týmy stavějící na platformách jako Vibe Hosting se otázka posouvá jiným směrem: jak chcete AI schopnosti konzumovat? Preferujete jednoduchost plně managed AI služeb? Nebo si ceníte možnosti měnit modely, kontrolovat náklady a přesně rozumět tomu, co se děje pod kapotou?

Upřímná odpověď pro většinu týmů dneska je pravděpodobně hybridní přístup – používání managed služeb pro některé workloady a budování self-hosted kapacit pro jiné. Klíčové je rozumět tomu, co přesně v každém směru obětujete.

Závěr

Self-hosted AI pro software engineering už není teoretické cvičení ani přístup vyhrazený pro velké podniky s dedikovanými ML infrastrukturními týmy. Nástroje dospěly, náklady klesly a operační vzorce se stávají čím dál jasnějšími.

Ať už se rozhodnete provozovat vlastní inference infrastrukturu nebo zůstat u hosted providerů, pochopení trade-offů se stává esenciální znalostí pro engineering leadery. Týmy, které si teď udělají čas na pochopení těchto principů, budou lépe připravené na infrastrukturní rozhodování, jak se AI nástroje budou dál vyvíjet.

Budoucnost AI ve vývoji nespočívá jen v tom, které modely používáte – jde o to, kdo kontroluje stack, na kterém ty modely běží. A tahle otázka si zaslouží vážné zamyšlení od každého týmu, který to se svojí vývojářskou infrastrukturou myslí vážně.

Jaký přístup k AI infrastruktuře zaujímá váš tým? Jste plně committed k hosted službám, zkoušíte self-hosted možnosti, nebo hledáte rovnováhu mezi oběma? Diskuze o AI infrastrukturní nezávislosti teprve začíná.