Se kysymys, jonka jokainen kehitystiimi joutuu kohtaamaan

Jossain vaiheessa jokainen insinööritiimi törmää kysymykseen, joka tuntuu itsestäänselvyydeltä vasta jälkikäteen: Miksi annamme niin suuren osan kehitysympäristöstämme ulkopuolisten käsiin?

Kyse ei ole retorisesta kysymyksestä tai kehotuksesta luopua kokonaan hallinnoiduista AI-palveluista. Kyse on käytännönläheisestä infrastruktuurikysymyksestä, jonka parissa yhä useammat tiimit painivat, kun AI-työkalut upotetaan päivittäiseen työnkulkuun.

Löysin hiljattain mielenkiintoisen tapausesimerkin, joka valottaa, miksi tämä on tärkeää. Pieni tiimi Parityllä päätti testata niin sanottua "20 %:n kokeilua" – käytännössä muutamille insinööreille annettiin vapaus selvittää, voivatko itse isännöidyt AI-mallit toimia oikeissa kehitystehtävissä. Se, mikä alkoi iltapäivän testinä, jatkui viikkoja. 25 insinööriä prosessoi yhteensä lähes 13 miljardia tokenia omatoimisesti hallinoidun inference-ympäristön kautta.

Luvut ovat silmiä avaavia. Pelkästään ensimmäisten kolmen päivän aikana he prosessoivat yli 3 miljardia tokenia noin 0,10 dollarilla miljoonaa tokenia kohden GPU-laskennassa. Kuukauden kokonaiskustannus jäi noin 1 200 dollariin. Se ei ole vähäpätöinen summa, mutta ei myöskään se prohibitivisen kallis vaihtoehto, joksi monet tiimit olettavat kuulevansa "itse isännöity AI".

Todellinen kustannus ei ole sitä, mitä luulet

Minua eniten kiinnosti yksi oivallus: GPU-kustannukset, vaikka olennaisia, olivatkin pienempi menoerä. Suurempi investointi oli insinöörien aika – infrastruktuurin rakentaminen, suorituskyvyn mittaaminen ja sen opettelu, miten järjestelmää pyöritetään luotettavasti.

Tämä on kaava, jonka näen toistuvan infrastruktuuripäätöksissä. Suorat kustannukset ovat näkyviä ja helppoja budjetoida. Piilossa olevat kustannukset ovat sitä aikaa ja huomiota, jonka tiimisi käyttää uusien järjestelmien operatiivisen osaamisen rakentamiseen. Parity-tiimin veikkaus on, että tämä tieto kasautuu – että infrastruktuurin, mittareiden ja operatiivisten käytäntöjen rakentaminen nyt on investointi kyvykkyyksiin, jotka tuottavat tuottoa tulevissa työkuormissa.

Tämä ajattelu kuulostaa tutulta kaikille, jotka ovat tehneet päätöksiä pilvipalveluista, konttiorkesteroinnista tai hallinnoiduista tietokannoista. Punnitset operatiivista monimutkaisuutta saavuttamaasi kontrollin, kustannussäästöjen ja strategisen joustavuuden kanssa. Joskus hallinointiratkaisu voittaa. Joskus oman pinon omistaminen kannattaa.

Mitä "yksinkertainen arkkitehtuuri" todella tarkoittaa

Arvostin Parity-artikkelissa sitä, miten avoimesti he kuvailivat arkkitehtuuriaan. He eivät pyörittäneet jotain räätälöityä, varta vasten rakennettua inference-klusteria. Heidän pinosuunittelunsa oli virkistävän suoraviivainen:

Yhteinen rajapintakerros (he käyttivät LiteLLM:ää) sijaitsee kehitystyökalujen ja malleja pyyntöjä palvelevien mallien välissä. Tämän rajapinnan takana vLLM hoitaa mallien palvelun. GPU-kapasiteetti pyörii vuokratulla infrastruktuurilla pilvipalveluntarjoajalta. Kokonaisuus on suunniteltu niin, että insinöörit voivat jatkaa tutuilla koodaustyökaluilla ja -asiakkailla, samalla kun tiimi säilyttää joustavuuden siitä, mitkä mallit ja palveluntarjoajat ovat yhteisen päätepisteen takana.

Tämä on keskeinen oivallus, jonka monet tiimit ohittavat, kun ne hylkäävät itse isännöidyt vaihtoehdot: sinun ei tarvitse valita kontrollin ja mukavuuden välillä. Hyvin suunniteltu abstrauktiokerros tarkoittaa, että kehittäjäsi käyttävät samoja työkaluja kuin aina. Ero on siinä, että sinä päätät, mikä malli vastaa, mitä dataa lokitetaan ja miten kustannukset kohdistetaan.

Ajattele tätä DNS-hallinnan tavoin. Kehittäjäsi eivät tarvitse ymmärrystä siitä, miten DNS-propagaatio toimii, käyttääkseen verkkotunnuksia tehokkaasti. He vuorovaikuttavat siistin rajapinnan kanssa. Mutta tuon rajapinnan takana joku on tehnyt tietoisia valintoja nimipalvelimista, TTL-arvoista ja varaohjauksesta. Sama periaate pätee tässä.

Mitä luvut todella kertovat

Parity-kokeilun operatiivinen data on paikka, josta saa todella hyödyllistä tietoa samankaltaisia ympäristöjä harkitseville tiimeille. He seurasivat kontekstipituuksia, pyyntöjen rinnakkaisuutta, suorituskykyä ja jonoaikoja oikeissa kehitystyönkulkuissa.

Muutama numero, jotka nousivat esiin:

99 % pyynnöistä käytti alle 500 000 tokenia kontekstia. Yli puolet ajasta järjestelmä palveli täsmälleen yhtä samanaikaista pyyntöä. Huipussa he näkivät prefill-prosessointia 168 000 tokenia sekunnissa, ja keskimääräinen aika ensimmäiseen tokeniin oli noin 3,34 sekuntia.

Pyyntöjen jakauma kertoo tärkeän tarinan. Suurimman osan ajasta inference-infrastruktuurisi käsittelee suhteellisen vaatimattomia, yksisäikeisiä pyyntöjä kehittäjiltä. Rinnakkaiset pyyntöskenaariot, jotka kuormittavat järjestelmää, ovat poikkeus eikä sääntö.

Tällä on käytännön vaikutuksia kapasiteetin suunnitteluun. Ei välttämättä tarvitse varustella huippukuormaa varten suurimman osan aikaa. Hyvin suunniteltu järjestelmä skaalautuu dynaamisesti pitäen samalla peruskustannukset kohtuullisina.

Strateginen kysymys: kontrolli vs. mukavuus

Tässä piilee kokeilun todellinen arvo: ne opettavat alalle, miltä "AI-infrastruktuurin itsenäisyys" käytännössä näyttää.

Elämme mielenkiintoista siirtymäkautta. AI-työkalut ovat tulleet välttämättömiksi ohjelmistojen rakentamisessa, mutta ala yhä miettii, mitä näiden työkuormien vastuullinen pyörittäminen tarkoittaa. Kysymykset datan säilytyksestä, kustannusten ennustettavuudesta, mallien saatavuudesta ja toimittajalukituksesta ovat kaikki todellisia huolenaiheita, joita kehitystiimit alkavat ottaa vakavasti.

Parity-kokeilu viittaa siihen, että itse isännöity inference on saavutettavampi kuin monet olettavat. Ei tarvita valtavaa insinöörijoukkoa tai räätälöityä laitteistoa aloittaakseen. Tarvitaan selkeät vaatimukset, järkevä arkkitehtuuri ja halukkuus investoida operatiiviseen osaamiseen.

Onko tämä vaihtokauppa järkevä, riippuu täysin kontekstistasi. Mutta se, että se on ylipäätään varteenotettava vaihtoehto, on syytä ymmärtää – etenkin kun AI-työkalut integroituvat yhä syvemmälle ohjelmistojen toimitukseen.

Missä tämä sijoittuu pilvihosting-kenttään

Pilvi-infrastruktuurin näkökulmasta tällä trendillä on mielenkiintoisia implikaatioita. Mahdollisuus vuokrata GPU-kapasiteettia fyysisen laitteiston ostamisen sijaan madaltaa kynnystä merkittävästi. Saat itse isännöidyn infrastruktuurin operatiivisen joustavuuden ilman pääomamenon laitteiston hankkimiseen.

Tämä on sama kehityskaari, jonka olemme nähneet muualla pilvilaskennassa. Hallitut palvelut abstrahoivat monimutkaisuutta, mutta myös kontrollia. Itse isännöidyt vaihtoehdot pilvi-infrastruktuurissa antavat enemmän kontrollia ilman, että tarvitsee rakentaa ja ylläpitää fyysistä laitteistoa.

Niille, jotka rakentavat alustoille kuten Vibe Hosting, kysymys on: miten haluat käyttää AI-kyvykkyyksiä? Arvostatko täysin hallinnoidun AI-palvelun yksinkertaisuutta? Vai arvostatko mahdollisuutta vaihtaa malleja, hallita kustannuksia ja ymmärtää tarkasti, mitä konepellin alla tapahtuu?

Rehellinen vastaus useimmille tiimeille tänään on todennäköisesti hybridilähestymistapa – hallittuja palveluita joihinkin työkuormiin, itse isännöityjä kyvykkyyksiä toisiin. Avain on ymmärtää, mitä kumpaankin suuntaan luovutat.

Kaiken ydin

Itse isännöity AI ohjelmistokehityksessä ei ole enää teoreettinen harjoitus tai lähestymistapa, joka on varattu suurille yrityksille, joilla on omistettuja ML-infrastruktuuritiimejä. Työkalut ovat kypsyneet, kustannukset ovat laskeneet ja operatiiviset mallit ovat selkiytymässä.

Päätät sitten pyörittää omaa inference-infrastruktuuria tai pysyä isännöidyissä palveluntarjoajissa, trade-offien ymmärtäminen on tulossa oleelliseksi tiedoksi teknologiajohtajille. Tiimit, jotka käyttävät aikaa näiden oppien omaksumiseen nyt, ovat paremmassa asemassa tekemään infrastruktuuripäätöksiä AI-työkalujen kehittyessä.

AI:n tulevaisuus kehityksessä ei ole vain siitä, mitä malleja käytät – se on siitä, kuka kontrolloi pinoa, jolla nuo mallit pyörivät. Ja tuo kysymys ansaitsee vakavan harkinnan jokaiselta tiimiltä, joka suhtautuu vakavasti kehitysinfrastruktuuriinsa.

Miten tiimisi lähestyy AI-infrastruktuuria? Oletko täysin sitoutunut isännöityihin palveluihin, tutkitko itse isännöityjä vai etsitkö tasapainoa? Keskustelu AI-infrastruktuurin itsenäisyydestä on vasta alkamassa.