Lopeta AI‑infrastruktuurin suunnittelu GPU:n ympärille

Miksi MSP:n tulisi aloittaa työkuormasta, ei laitteistosta

Vietä viisi minuuttia AI‑konferenssissa, niin on helppo lähteä siitä uskomaan, että jokainen menestyksekäs AI‑käyttöönotto alkaa lisäämällä GPU:ita. Tämä on helppo ymmärtää. Laitteisto hallitsee keskustelua. Asiakkaat kuulevat Blackwell‑järjestelmistä, InfiniBand‑verkkojen kankaista, hyper‑skaalauspilveistä ja yhä massiivisemmista AI‑klustereista. Toimittajat suuntautuvat luonnollisesti uusimpiin kiihdyttimiin ja nopeimpiin järjestelmiin, koska ne ovat innostavia, merkityksellisiä ja melko helppoja markkinoida.

Ongelma ei ole, että laskentateho ei merkityisi. Se on äärimmäisen tärkeä.

Ongelma on, että aloittaminen siitä voi saada organisaatiot esittämään väärän kysymyksen. AI‑markkinat eivät ole enää kokeiluvaiheessa. AI siirtyy tuotantoon, yritykset investoivat oikeaa rahaa ja odottavat mitattavissa olevia liiketoimintatuloksia. Infrastruktuuripäätökset ovat paljon merkityksellisempiä kuin kaksi vuotta sitten. Silti liian harvat päätökset perustuvat liiketoimintavaatimuksiin – teknologia‑johtoiset päätökset hallitsevat edelleen.

Ensimmäinen kysymys ei saisi olla “Minkä GPU:n ostamme?”

Keskeisenä tulisi olla “Mitä työkuormaa yritämme tukea?”

Tämä näennäisesti pieni muutos vaikuttaa lähes kaikkiin sen jälkeen tehtäviin infrastruktuuripäätöksiin.

Ei ole olemassa standardoitua AI‑infrastruktuuria

Yksi suurimmista harhaluuloista markkinoilla on, että AI‑infrastruktuurille olisi olemassa standardi‑suunnitelma. Sellaista ei ole.

Puhumme AI:sta ikään kuin se olisi yksi ainoa työkuorma. Todellisuudessa AI kattaa valtavan kirjon liiketoimintasovelluksia, joilla on hyvin erilaiset vaatimukset. Ääniaiopohjainen alusta ei tarvitse samoja infrastruktuurivaatimuksia kuin lääketieteellinen kuvantaminen. Tiedonhaku eroaa kuvageneroinnista. Petosten havaitseminen ei näytä samanlaiselta kuin ennustava analytiikka, eikä kumpikaan muistuta videonkäsittelyä. Ne kaikki käyttävät AI:ta, mutta ne käyttävät infrastruktuuria eri tavoin.

Et siis oikeastaan suunnittele infrastruktuuria “AI:lle”. Suunnittelet infrastruktuuria liiketoimintasovellukselle, joka sattuu käyttämään AI:ta. Tämä ero on merkittävä. Jokainen työkuorma asettaa ainutlaatuisia vaatimuksia sille tukevalle infrastruktuurille. Jotkut vaativat merkittävää laskentatehoa. Toiset riippuvat voimakkaasti tallennuksen suorituskyvystä, koska ne hakevat jatkuvasti suuria tietoaineistoja. Jotkut rajoittuvat verkon läpivientiin, kun taas toinen voi elää tai kuolla viiveen vuoksi, sillä jokainen millisekunti vaikuttaa asiakaskokemukseen.

On myös käytännön todellisuus. Mallille suunniteltu infrastruktuuri ei aina ole saatavilla, kun on aika ottaa se käyttöön. Laitteiston saatavuus, pitkät toimitusajat tai käyttöönotto‑aikataulut voivat pakottaa organisaatiot käyttämään erilaisia GPU:ita, kiihdyttimiä tai infrastruktuurikokoonpanoja kuin alun perin suunniteltiin. Tämä voi tarkoittaa mallin uudelleensäätöä tai jopa sen uudelleensuunnittelua ympärille sen laitteiston mukaan, jonka voi oikeasti ottaa käyttöön.

Turvallisuus‑ ja hallintavaatimukset ovat yhtä lailla työkuormakohtaisia. Julkista tietoa käsittelevällä sovelluksella on hyvin erilaiset vaatimukset kuin rahoitustapahtumia, terveydenhuollon tietoja tai omistusoikeudellista immateriaalioikeutta käsittelevällä sovelluksella. Tietosuoja, identiteetti‑ ja pääsynhallinta, sääntelyn noudattaminen, suvereniteetti, varmuuskopiointi, palautus ja saatavuus eivät voi olla pelkästään jälkikäteen lisättävissä. Ne ovat arkkitehtonisia päätöksiä.

Liiketoimintavaatimukset tuovat toisen kerroksen. Kuinka nopeasti sovelluksen täytyy skaalata? Mitkä käyttökustannukset ovat kestäviä? Millainen saatavuustaso liiketoiminta vaatii? Kuinka paljon monimutkaisuutta organisaatio pystyy realistisesti hallitsemaan? Nämä kysymykset saavat erilaiset vastaukset jokaiselta asiakkaalta. Siksi ei ole olemassa yhtä kaikille sopivaa AI‑infrastruktuuria.

Organisaatiot, jotka aloittavat mieluisalla pilvialustalla, laitteistolla tai toimittajalla, eivät saa AI‑infrastruktuuria oikein. Johtajat aloittavat työkuormasta ja suunnittelevat arkkitehtuurin liiketoimintatavoitteen ympärille.

Koulutus saa otsikot. Inferenssi tuo liiketoimintaarvon.

Alan kiehtymys koulutukseen on toinen syy, miksi AI‑infrastruktuurikeskustelut voivat kääntyä väärään suuntaan.

Suuren kielimallin kouluttaminen on poikkeuksellinen insinöörityö. Tarvitaan valtavia tietoaineistoja, massiivisia GPU‑klustereita, merkittävää virrankulutusta ja infrastruktuuria, joka pystyy toimimaan täyskapasiteetissa päiviä, viikkoja tai jopa kuukausia. Se on kallista, teknisesti vaikuttavaa ja luonnollisesti herättää huomiota.

Useimmat organisaatiot eivät kuitenkaan rakenna seuraavaa rajapintamallia. Ne rakentavat asiakaspalvelusovelluksia, ääniaiopohjaisia järjestelmiä, työntekijöiden avustajia, tiedonavustajia, hakutyökaluja, asiakirjojen tiivistämisalustoja, petosten havaitsemisjärjestelmiä ja kymmeniä muita käytännön sovelluksia jo koulutetuilla malleilla.

Nämä ovat inferenssityökuormia, ja inferenssi muuttaa infrastruktuuriyhtälöä. Sen sijaan, että optimoitaisiin pelkästään maksimaalista laskentatehoa, organisaatioiden on ehkä optimoitava nopeita vasteaikoja, alhaista viivettä, ennustettavia käyttökustannuksia ja tasalaatuista suorituskykyä.

Asiakas ei välitä, kuinka voimakas taustalla oleva GPU on, jos chatbot vastaa viidessä sekunnissa. Soittaja ei välitä AI‑klusterin teknisistä tiedoista, jos ääniavustaja ymmärtää jatkuvasti pyyntöjä väärin tai viivyttelee keskustelun aikana. He vain tietävät, että sovellus ei toimi hyvin.

Jokaisen AI‑ympäristön suunnittelu ikään kuin kouluttaisi perusmallia on siis yleensä väärä lähestymistapa ja usein tarpeettoman kallis.

Useimpien MSP‑asiakkaiden tavoite ei ole rakentaa maailman suurinta GPU‑klusteria. Tavoitteena on saada AI‑sovellukset tuotantoon nopeasti, luotettavasti, turvallisesti ja taloudellisesti.

Haasteena on löytää oikea tasapaino suorituskyvyn, turvallisuuden, skaalautuvuuden, resilienssin ja kustannusten välillä niiden työkuormien osalta, joita ne todella ajavat.

Ehkä GPU ei ole pullonkaula

GPU:t ovat nousseet AI‑infrastruktuurin julkkikseiksi. Ne ovat kalliita, hankkimisessa vaikeita ja helppoja vertailla, mikä tekee niistä lukemattomien infrastruktuurikeskustelujen keskipisteen. Kuitenkin GPU ei välttämättä ole se tekijä, joka hidastaa sovellusta, kun se siirtyy tuotantoon.

“Kuinka monta GPU:ta tarvitsemme?” ei ole se kysymys, jonka meidän tulisi esittää, vaan “Mikä hidastaa tätä sovellusta kuusi kuukautta tästä eteenpäin?”

Vastaus voi olla jossain muualla arkkitehtuurissa.

Tallennus on hyvä esimerkki. AI‑työkuormat kuluttavat valtavia määriä dataa – ja nämä tietoaineistot kasvavat ajan myötä. Jopa erittäin tehokas GPU voi menettää arvokasta aikaa odottamiseen sen sijaan, että se tekisi työtä, jos tallennus ei pysty toimittamaan tietoa riittävän nopeasti. Tämä data täytyy myös suojata, varmuuskopioida, säilyttää, turvata ja hallita koko elinkaarensa ajan.

Verkko on yhtä tärkeä. Läpäisykyky, viive, itä‑länsi‑liikenne ja AI‑klustereiden välinen kommunikaatio vaikuttavat kaikki sovelluksen suorituskykyyn. Hyvin suunniteltu laskenta‑ympäristö ei voi korvata loputtomiin huonosti suunniteltua verkkoa.

Turvallisuuden on myös oltava osa arkkitehtuuria alusta alkaen. Ennen tuotantoa on käsiteltävä kysymykset: missä arkaluontoinen data sijaitsee, miten verkot on segmentoitava, kommunikoivatko työkuormat yksityisen vai julkisen yhteyden kautta, ja miten noudatetaan sääntelyn ja suvereniteetin vaatimuksia.

Helposti unohdettava tekijä on yhteyskyky. Vaikka ne eivät tuota näyttäviä otsikoita, kuitujen monimuotoisuus, reittien monimuotoisuus, verkko‑partnerisuhteet ja maantieteellinen läheisyys voivat ratkaisevasti vaikuttaa käyttäjäkokemukseen – puhumattakaan alustan resilienssistä.

Loppuasiakkaat eivät tiedä eikä välitä, mikä GPU on hyllyssä. He välittävät siitä, vastaako sovellus välittömästi vai joutuvatko he odottamaan.

Fyysinen infrastruktuuri ansaitsee myös huomiota. Virran saatavuus, jäähdytyskapasiteetti, hyllytiheys ja laajennuskapasiteetti määräävät, pystyykö tämän päivän menestyksekäs käyttöönotto tukemaan huomisen kasvua.

Sitten on kyse datan gravitaatiosta. Kun tietoaineistot laajenevat, petatavujen siirtäminen paikasta toiseen pelkästään siksi, että laskenta sijaitsee jossain muualla, muuttuu yhä tehottomammaksi. Monissa tilanteissa laskennan tuominen lähemmäs dataa on sekä käytännöllisempää että edullisempaa.

Tämä on syy siihen, miksi arkkitehtuuri on tärkeä.

Ajattele kilpa‑autoa – pelkkä paras moottori ei takaa voittoa. Vaihteisto, renkaat, jousitus, rata ja erityisesti kuljettaja vaikuttavat myös. AI‑infrastruktuuri toimii samalla tavalla.

Ne organisaatiot, jotka tuottavat suurimman arvon AI:sta, eivät välttämättä ole niitä, joilla on suurimmat GPU‑klusterit. Ne ovat ne, jotka ymmärtävät, miten jokainen infrastruktuurin taso toimii yhdessä.

Tämä on ero infrastruktuurin ostamisen ja sen suunnittelun välillä.

Työkuormapainotteinen suunnittelukehys

MSP:illä on mahdollisuus muuttaa infrastruktuurikeskustelua.

Sen sijaan että aloitettaisiin:

• Mikä GPU?
• Mikä pilvi?
• Mikä toimittaja?

Aloita työkuormasta:

• Mikä liiketoimintaongelma ratkaistaan?
• Onko kyse koulutus‑ vai inferenssityökuormasta?
• Kuinka paljon viivettä sovellus kestää?
• Missä data sijaitsee, ja kuinka nopeasti se kasvaa?
• Mitä turvallisuus‑, sääntely‑ ja suvereniteettivaatimuksia sovelletaan?
• Miten työkuorma skaalautuu?
• Minkä tason saatavuutta liiketoiminta vaatii?
• Minkä tason operatiivista riskiä voidaan hyväksyä?
• Mitä tämä ympäristö maksaa ylläpitää käyttömäärän kasvaessa?

Vastausten tulisi määrittää arkkitehtuuri. Ei päinvastoin.

Mahdollisuus MSP:ille

Tämä muutos muuttaa MSP:n roolia.

Asiakkaat eivät tarvitse toista kumppania, joka vain myy heille infrastruktuuria. He tarvitsevat kumppanin, joka auttaa heitä tekemään parempia infrastruktuuripäätöksiä.

Työkuormapainotteinen lähestymistapa on välttämätön, koska se antaa MSP:ille mahdollisuuden arvioida laskentaa, tallennusta, verkkoa, yhteyksiä, turvallisuutta, datan sijaintia, saatavuutta ja kustannuksia yhtenä arkkitehtuurina – eikä erillisinä ostopäätöksinä.

Tällä tavoin pystytään hallitsemaan kustannuksia, parantamaan suorituskykyä ja tunnistamaan operatiiviset ja turvallisuusriskit ennen kuin sovellukset siirtyvät tuotantoon.

Myös MSP:n liiketoimintamalli paranee.

MSP:t voivat rakentaa arvokkaampia toistuvia palveluita arkkitehtuurin, käyttöönoton, optimoinnin, turvallisuuden, elinkaaren hallinnan, kapasiteettisuunnittelun ja jatkuvan parantamisen ympärille – sen sijaan että kilpailisivat ensisijaisesti laitteistomarginaalien kutistumisella.

Arvo ei ole uusimman GPU:n tai uusimman pilvialustan suositteleminen. Arvo on tietää, milloin asiakas tarvitsee niitä, milloin ei, ja mitä muuta on suunniteltava niiden ympärille.

AI‑infrastruktuuri ei lopulta ole laitteistopäätös. Se on arkkitehtuuripäätös, jonka ohjaavat työkuorma, data ja liiketoiminnan tavoite, jonka asiakas pyrkii saavuttamaan.

MSP:t, jotka ymmärtävät tämän eron, asemoituvat tulemaan paljon arvokkaammiksi kuin pelkät infrastruktuuritoimittajat.

Heistä tulee ne ihmiset, joihin asiakkaat luottavat päätöksenteossa siitä, millaista infrastruktuuria he todella tarvitsevat.