Spørgsmålet om AI-infrastruktur som ethvert udviklingsteam vil stille sig

På et tidspunkt vil dit udviklingsteam stille et spørgsmål, der føles indlysende i bakspejlet: Hvorfor overlader vi så meget af vores udviklingsinfrastruktur til eksterne udbydere?

Dette er ikke et retorisk spørgsmål eller en opfordring til at droppe hosted AI-tjenester helt. Det er en praktisk overvejelse om infrastruktur, som flere og flere teams begynder at tage alvorligt, efterhånden som AI-kodningsværktøjer bliver en integreret del af den daglige arbejdsgang.

Jeg stødte for nylig på en interessant case, der illustrerer præcis, hvorfor dette er relevant. Et lille team hos Parity besluttede at køre det, de kaldte et "20%-tid eksperiment" – i bund og grund gav de et par ingeniører friheden til at undersøge, om selvhostede AI-modeller kunne fungere til rigtige udviklingsopgaver. Hvad der startede som et eftermiddagseksperiment løb over flere uger, hvor 25 ingeniører tilsammen behandlede næsten 13 milliarder tokens gennem et selvhustillet inferens-setup.

Tallene er slående. I blot de første tre dage behandlede de over 3 milliarder tokens til cirka $0,10 per million tokens i GPU-computeomkostninger. Over den fulde måned landede den samlede udgift på omkring $1.200. Det er ikke ubetydeligt, men det er heller ikke det forbuddy dyre projekt, som mange teams antager, når de hører "selvhostet AI."

De virkelige omkostninger er ikke, hvad du tror

Her er den indsigt, der sprang mest i øjnene på mig: GPU-computeomkostningerne var virkelige nok, men de var faktisk den mindre udgift. Den større investering var ingeniørtid – opsætning af infrastruktur, benchmarking af performance og læring af, hvordan man driver systemet pålideligt.

Dette er et mønster, jeg ser gentagne gange i infrastrukturbeslutninger. De direkte omkostninger er synlige og nemme at budgettere for. De skjulte omkostninger er den tid og opmærksomhed, dit team bruger på at opbygge operationel viden om nye systemer. Parity-teamets indsats er, at denne viden bliver større over tid – ved at bygge deres infrastruktur, benchmarks og operationsmanualer nu investerer de i kompetencer, der giver afkast på tværs af fremtidige arbejdsbelastninger.

Denne tænkning bør lyde bekendt for alle, der har truffet beslutninger om cloud-hosting, containerorkestrering eller administrerede databaser. Man vejer den operationelle kompleksitet op mod den kontrol, omkostningsbesparelser og strategiske fleksibilitet, man opnår. Nogle gange vinder den administrerede løsning. Nogle gange giver det mening at eje stacken.

Hvad "simpel arkitektur" faktisk betyder

En ting, jeg satte pris på i Paritys artikel, var hvor eksplicit de beskrev deres arkitektur. De drev ikke et eller andet skræddersyet, specialbygget inferenscluster. Deres stack var forfriskende ligetil:

Et fælles grænsefladelag (de brugte LiteLLM) sidder mellem udviklerværktøjerne og de modeller, der betjener forespørgsler. Bag den grænseflade håndterer vLLM model-servingen. GPU-kapaciteten kører på lejet infrastruktur fra en cloud-udbyder. Hele opsætningen er bevidst designet, så ingeniørerne kan blive ved med at bruge deres velkendte kodeeditorer og klienter, mens teamet bevarer fleksibilitet omkring hvilke modeller og udbydere der sidder bag det fælles endpoint.

Dette er nøgleindsigten, mange teams går glip af, når de afviser selvhostede muligheder: du behøver ikke vælge mellem kontrol og bekvemmelighed. Et veldesignet abstraktionslag betyder, at dine udviklere arbejder med de samme værktøjer som altid. Forskellen er, at du bestemmer, hvilken model der svarer, hvilke data der logges, og hvordan omkostninger fordeles.

Tænk på det som DNS-håndtering. Dine udviklere behøver ikke forstå intricacies af, hvordan DNS-propagation fungerer, for at bruge domænenavne effektivt. De interagerer med en ren grænseflade. Men bag den grænseflade har nogen truffet bevidste beslutninger om navneservere, TTL'er og redundans. Det samme princip gælder her.

Hvad tallene faktisk fortæller os

De operationelle data fra Paritys eksperiment er, hvor tingene bliver virkelig nyttige for teams, der overvejer lignende opsætninger. De trackede kontekstlængder, request-parallelisme, throughput og køtider på tværs af rigtige udviklings workflows.

Nogle tal, der stak ud:

Nioghalvfems procent af forespørgslerne brugte mindre end 500k tokens kontekst. Mere end halvdelen af tiden betjente systemet præcis én konkurrent forespørgsel. På toppen så de prefill-behandling ved 168k tokens per sekund med en gennemsnitlig tid til første token på omkring 3,34 sekunder.

Fordelingen af request-typer fortæller en vigtig historie. Det meste af tiden håndterer din inferensinfrastruktur relativt beskedne, single-threadede forespørgsler fra udviklere. De parallelle request-scenarier, der stress-tester din opsætning, er undtagelsen, ikke reglen.

Dette har praktiske implikationer for kapacitetsplanlægning. Du behøver ikke nødvendigvis at provisionere til den maksimale parallelle belastning det meste af tiden. Et veldesignet system kan skalere dynamisk, mens baseline-omkostninger holdes rimelige.

Det strategiske spørgsmål: Kontrol vs. bekvemmelighed

Her er, hvor jeg mener, den virkelige værdi ligger i eksperimenter som dette: de lærer industrien, hvad "AI-infrastrukturuafhængighed" faktisk betyder i praksis.

Vi er i en interessant overgangsperiode. AI-kodningsværktøjer bliver essentielle for, hvordan teams bygger software, men industrien finder stadig ud af, hvad det betyder at køre disse arbejdsbelastninger ansvarligt. Spørgsmål om datalagring, omkostningsforudsigelighed, modeltilgængelighed og vendor lock-in er alle reelle bekymringer, som udviklingsteams begynder at tage alvorligt.

Parity-experimentet antyder, at selvhostet inferens er mere tilgængelig, end mange antager. Du behøver ikke en massiv ingeniørorganisation eller specialhardware for at komme i gang. Du har brug for klare krav, en fornuftig arkitektur og en vilje til at investere i operationel viden.

Om denne afvejning giver mening, afhænger helt af din kontekst. Men det faktum, at det er en levedygtig mulighed overhovedet, er værd at forstå – især når AI-værktøjer bliver mere dybt integreret i, hvordan vi leverer software.

Hvor dette passer ind i cloud-hosting landskabet

Fra et cloud-infrastruktur perspektiv har denne trend interessante implikationer. Muligheden for at leje GPU-kapacitet i stedet for at købe den direkte sænker barrieren for adgang markant. Du får den operationelle fleksibilitet af selvhostet infrastruktur uden kapitaludgifterne ved at købe hardware.

Dette er den samme udvikling, vi har set på andre områder af cloud computing. Administrerede tjenester abstraherer kompleksitet væk, men de abstraherer også kontrol væk. Selvhostede muligheder på cloud-infrastruktur giver dig mere kontrol, uden at du behøver at bygge og vedligeholde fysisk hardware.

For teams, der bygger på platforme som Vibe Hosting, bliver spørgsmålet: hvordan vil I forbruge AI-kapabiliteter? Foretrækker I enkelheden i fuldt administrerede AI-tjenester? Eller værdsætter I evnen til at skifte modeller, kontrollere omkostninger og forstå præcis, hvad der sker under overfladen?

Det ærlige svar for de fleste teams i dag er nok en hybrid tilgang – bruger administrerede tjenester til nogle arbejdsbelastninger, mens I opbygger selvhostede kapabiliteter til andre. Nøglen er at forstå, hvad I ofrer i hver retning.

Konklusionen

Selvhostet AI til softwareudvikling er ikke længere et teoretisk øvelse eller en tilgang reserveret til store virksomheder med dedikerede ML-infrastrukturteams. Værktøjerne er modnet, omkostningerne er faldet, og de operationelle mønstre bliver tydeligere.

Uanset om du beslutter at køre din egen inferensinfrastruktur eller holde fast ved hosted udbydere, bliver det at forstå afvejningerne essentiel viden for teknisk ledelse. De teams, der tager sig tid til at lære disse lektioner nu, vil være bedre positioneret til at træffe infrastrukturbeslutninger, efterhånden som AI-værktøjer fortsætter med at udvikle sig.

Fremtiden for AI i udvikling handler ikke kun om, hvilke modeller du bruger – det handler om, hvem der kontrollerer den stack, modellerne kører på. Og det spørgsmål fortjener seriøs overvejelse fra ethvert team, der tager deres udviklingsinfrastruktur alvorligt.

Hvilken tilgang tager dit team til AI-infrastruktur? Er I fuldt committed til hosted services, udforsker I selvhostede muligheder, eller finder I en balance mellem de to? Samtalen om AI-infrastrukturuafhængighed er kun lige begyndt.