Den AI-stackfråga som varje utvecklarteam kommer att ställas inför

Förr eller senare kommer ditt tekniska team att ställa en fråga som känns uppenbar i efterhand: Varför lämnar vi över så stor del av vår utvecklingsinfrastruktur till externa leverantörer?

Det här är ingen retorisk fråga eller ett rop på att överge hostade AI-tjänster helt och hållet. Det handlar om en praktisk infrastrukturövervägning som allt fler team börjar fundera på i takt med att AI-kodningsverktyg blir en del av den dagliga arbetsprocessen.

Jag stötte nyligen på en intressant fallstudie som illustrerar precis varför det här spelar roll. Ett litet team på Parity bestämde sig för att köra vad de kallade ett "20%-tidsexperiment" – i princip att ge ett par ingenjörer friheten att utforska om självhostade AI-modeller kunde fungera för riktiga utvecklingsuppgifter. Det som började som ett par timmars testande pågick i flera veckor, där 25 ingenjörer tillsammans bearbetade nästan 13 miljarder tokens genom en egenhanterad inferens-setup.

Siffrorna är slående. Bara under de första tre dagarna bearbetade de över 3 miljarder tokens till ungefär 0,10 dollar per miljon tokens i GPU-beräkningskostnader. Under hela månaden landade den totala kostnaden på omkring 1 200 dollar. Det är inte ingenting, men det är heller inte det prohibitivt dyra alternativ som många team förutsätter när de hör "självhostat AI."

Den verkliga kostnaden är inte vad du tror

Här är insikten som slog mig mest: GPU-kostnaderna, trots att de är verkliga, var faktiskt den mindre utgiften. Den större investeringen var ingenjörstid – att sätta upp infrastrukturen, mäta prestanda och lära sig hur man kör systemet pålitligt.

Det här är ett mönster jag ser om och om igen i infrastrukturbeslut. De direkta kostnaderna syns tydligt och är lätta att budgetera för. De dolda kostnaderna är den tid och uppmärksamhet som ditt team lägger på att bygga operativ kunskap kring nya system. Parity-teamets satsning är att denna kunskap växer exponentiellt – genom att bygga sin infrastruktur, sina riktmärken och sina operativa playbook nu investerar de i förmågor som ger avkastning på framtida arbetsbelastningar.

Det här tänkandet borde kännas bekant för alla som har tagit beslut om molnhosting, containerorkestrering eller hanterade databaser. Man väger operativ komplexitet mot den kontroll, kostnadsbesparingar och strategiska flexibilitet man får. Ibland vinner den hanterade lösningen. Ibland lönar det sig att äga stacken.

Vad "enkel arkitektur" faktiskt innebär

En sak jag uppskattade med Paritys genomgång var hur explicit de beskrev sin arkitektur. De drev inte något skräddarsytt, specialbyggt inferenskluster. Deras stack var förvånansvärt rättfram:

Ett gemensamt gränssnitt (de använde LiteLLM) sitter mellan utvecklarverktygen och de modeller som betjänar förfrågningar. Bakom det gränssnittet sköter vLLM modelldistributionen. GPU-kapaciteten körs på hyrd infrastruktur från en molnleverantör. Hela setuppen är medvetet utformad så att ingenjörer kan fortsätta använda sina vanliga kodmiljöer och klienter medan teamet behåller flexibiliteten att välja vilka modeller och leverantörer som sitter bakom den gemensamma endpointen.

Det här är den nyckelinsikt som många team missar när de avfärdar självhostade alternativ: du behöver inte välja mellan kontroll och bekvämlighet. Ett väldesignat abstractionslager innebär att dina utvecklare arbetar med samma verktyg som de alltid har gjort. Skillnaden är att du bestämmer vilken modell som svarar, vilka data som loggas och hur kostnaderna fördelas.

Tänk på det som DNS-hantering. Dina utvecklare behöver inte förstå intricacies hur DNS-propagation fungerar för att effektivt använda domännamn. De interagerar med ett rent gränssnitt. Men bakom det gränssnittet har någon fattat medvetna beslut om nameservrar, TTL-värden och redundans. Samma princip gäller här.

Vad siffrorna faktiskt berättar för oss

Den operativa datan från Paritys experiment är där saker och ting blir genuint användbara för team som överväger liknande setuppar. De mätte kontextlängder, request-parallellism, throughput och kötider över verkliga utvecklingsarbetsflöden.

Några siffror som stack ut:

Nittionio procent av förfrågningarna använde mindre än 500k tokens kontext. Mer än hälften av tiden körde systemet exakt en concurrent request. Vid topp såg de prefill-bearbetning på 168k tokens per sekund, med en genomsnittlig tid till första token på omkring 3,34 sekunder.

Fördelningen av request-typer berättar en viktig historia. Det mesta av tiden hanterar din inferensinfrastruktur relativt blygsamma, enkeltrådade förfrågningar från utvecklare. De parallella request-scenarier som stressar din setup är undantaget, inte regeln.

Det här har praktiska konsekvenser för kapacitetsplanering. Du behöver inte nödvändigtvis provisionera för toppbelastningen mestadels. Ett väldesignat system kan skala dynamiskt samtidigt som baslinjekostnaderna hålls rimliga.

Den strategiska frågan: Kontroll vs. bekvämlighet

Här är var jag tycker det verkliga värdet ligger i experiment som detta: de lär industrin vad "AI-infrastrukturoberoende" faktiskt innebär i praktiken.

Vi befinner oss i en intressant övergångsperiod. AI-kodningsverktyg blir avgörande för hur team bygger mjukvara, men industrin håller fortfarande på att lista ut vad det innebär att köra dessa arbetsbelastningar ansvarsfullt. Frågor om datalagring, kostnadsförutsägbarhet, modelltillgänglighet och leverantörslåsning är alla verkliga bekymmer som utvecklingsteam börjar ta på allvar.

Parity-experimentet antyder att självhostad inferens är mer tillgänglig än många föreställer sig. Du behöver inte en enorm ingenjörsorganisation eller specialbyggd hårdvara för att komma igång. Du behöver tydliga krav, en förnuftig arkitektur och en vilja att investera i operativ kunskap.

Huruvida den här avvägningen är meningsfull beror helt på ditt sammanhang. Men det faktum att det är ett livskraftigt alternativ överhuvudtaget är värt att förstå – särskilt när AI-verktyg blir mer integrerade i hur vi levererar mjukvara.

Var detta passar in i molnhostinglandskapet

Ur ett molninfrastrukturperspektiv har den här trenden intressanta implikationer. Möjligheten att hyra GPU-kapacitet snarare än att köpa den direkt sänker tröskeln avsevärt. Du får operativ flexibilitet hos självhostad infrastruktur utan kapitalutgiften för att köpa hårdvara.

Det här är samma utveckling vi har sett inom andra områden av molnbaserad databehandling. Hanterade tjänster abstraherar bort komplexitet, men de abstraherar också bort kontroll. Självhostade alternativ på molninfrastruktur ger dig mer kontroll utan att kräva att du bygger och underhåller fysisk hårdvara.

För team som bygger på plattformar som Vibe Hosting blir frågan: hur vill du konsumera AI-kapaciteter? Föredrar du enkelheten hos fullständigt hanterade AI-tjänster? Eller värderar du möjligheten att byta modeller, kontrollera kostnader och förstå exakt vad som händer bakom kulisserna?

Det ärliga svaret för de flesta team idag är förmodligen en hybrid approach – att använda hanterade tjänster för vissa arbetsbelastningar medan man bygger självhostade förmågor för andra. Nyckeln är att förstå vad du ger upp i varje riktning.

Sammanfattningen

Självhostat AI för mjukvaruutveckling är inte längre en teoretisk övning eller ett tillvägagångssätt reserverat för stora företag med dedikerade ML-infrastrukturteam. Verktygen har mognat, kostnaderna har sjunkit och de operativa mönstren blir tydligare.

Oavsett om du bestämmer dig för att köra din egen inferensinfrastruktur eller hålla dig till hostade leverantörer, är det att förstå avvägningarna blivande baskunskap för tekniska ledare. De team som tar sig tid att lära sig de här lärdomarna nu kommer att vara bättre positionerade för att fatta infrastrukturbeslut i takt med att AI-verktygen fortsätter att utvecklas.

Framtiden för AI i utveckling handlar inte bara om vilka modeller du använder – det handlar om vem som kontrollerar stacken som dessa modeller körs på. Och den frågan förtjänar allvarlig övervägning från varje team som är seriöst med sin utvecklingsinfrastruktur.

Vilken approach har ditt team för AI-infrastruktur? Är ni fullt engagerade i hostade tjänster, utforskar ni självhostade alternativ, eller hittar ni en balans mellan de två? Samtalet om AI-infrastrukturoberoende har bara börjat.