Stop med at designe AI‑infrastruktur omkring GPU’en

Hvorfor MSP’er bør starte med arbejdsbelastningen, ikke hardwaren

Brug fem minutter på en AI‑konference, så kan du let ende med at tro, at enhver succesfuld AI‑implementering starter med at købe flere GPU’er. Det er let at forstå hvorfor. Hardware dominerer samtalen. Kunder hører om Blackwell‑systemer, InfiniBand‑netværk, hyperskala‑clouds og stadig større AI‑klynger. Leverandører graviterer naturligt mod de nyeste acceleratorer og hurtigste systemer, fordi de er spændende, relevante og relativt nemme at placere på markedet.

Problemet er ikke, at beregning er uvæsentligt. Det er enormt vigtigt.

Problemet er, at hvis man starter der, kan organisationer ende med at stille det forkerte spørgsmål. AI‑markedet er ikke længere i eksperimentfasen. AI bliver sat i produktion, virksomheder investerer rigtige penge, og de forventer målbare forretningsresultater. Beslutninger om infrastruktur er blevet langt mere afgørende end for to år siden. Alligevel drives for få beslutninger af forretningskrav – teknologidrevne beslutninger er stadig i førersædet.

Det første spørgsmål bør ikke være “Hvilken GPU skal vi købe?”

“Hvilken arbejdsbelastning prøver vi at understøtte?” bør være fokus.

Den tilsyneladende lille ændring påvirker næsten hver infrastruktur‑beslutning, der følger.

Der findes ingen standard‑AI‑infrastruktur

En af de største misforståelser på markedet er, at der findes en standard‑plan for AI‑infrastruktur. Det gør der ikke.

Vi taler om AI, som om det var en enkelt arbejdsbelastning. I virkeligheden dækker AI et enormt spektrum af forretningsapplikationer med meget forskellige krav. En stemme‑AI‑platform har ikke de samme infrastrukturkrav som medicinsk billedbehandling. Videns‑genfinding er anderledes end billedgenerering. Svindel‑detektion ligner ikke forudsigende analyse, og ingen af delene ligner videobehandling. De bruger alle AI. De bruger blot infrastrukturen på forskellige måder.

Du designer ikke egentlig infrastruktur til “AI”. Du designer infrastruktur til en forretningsapplikation, der tilfældigvis bruger AI. Den sondring betyder noget. Hver enkelt arbejdsbelastning stiller unikke krav til den understøttende infrastruktur. Nogle kræver betydelige beregningsressourcer. Andre er stærkt afhængige af lager‑performance, fordi de kontinuerligt henter store datasæt. Nogle er begrænset af netværksgennemstrømning, mens andre lever eller dør på grund af latenstid, da hver millisekund påvirker kundeoplevelsen.

Der er også en praktisk realitet. Den infrastruktur, en model er designet til, er ikke altid den infrastruktur, der er tilgængelig, når det er tid til at implementere. Tilgængelighed af hardware, lange leveringstider eller implementeringsfrister kan tvinge organisationer til at bruge andre GPU’er, acceleratorer eller konfigurationer end oprindeligt planlagt. Det kan betyde, at modellen skal re‑optimere. Eller endda redesigne modellen omkring den hardware, de faktisk kan implementere.

Sikkerheds‑ og governance‑krav er lige så arbejdsbelastningsspecifikke. En applikation, der behandler offentlige oplysninger, har meget andre krav end en, der håndterer finansielle transaktioner, sundhedsregistre eller proprietær intellektuel ejendom. Databeskyttelse, identitets‑ og adgangsstyring, compliance, suverænitet, backup, genoprettelse og tilgængelighed kan ikke blot tilføjes efter implementering. De er arkitektoniske beslutninger.

Forretningskrav tilføjer et ekstra lag. Hvor hurtigt skal applikationen kunne skalere? Hvilke driftsomkostninger er bæredygtige? Hvilket tilgængelighedsniveau kræver forretningen? Hvor meget kompleksitet kan organisationen realistisk håndtere? Disse spørgsmål besvares forskelligt af hver kunde. Derfor findes der ingen “one‑size‑fits‑all” AI‑infrastruktur.

Organisationer, der starter med en foretrukken cloud, hardwareplatform eller leverandør, får ikke AI‑infrastrukturen rigtig. De ledende starter med arbejdsbelastningen og designer en arkitektur omkring forretningsmålet.

Træning får overskrifterne. Inferens leverer forretningsværdien.

Branchens fascination af træning er en anden grund til, at AI‑infrastruktur‑samtaler kan gå i den forkerte retning.

At træne en stor sprogmodel er en ekstraordinær ingeniørudfordring. Enormt datasæt, massive GPU‑klynger, betydelig strømforsyning og infrastruktur, der kan køre på fuld kapacitet i dage, uger eller endda måneder, er påkrævet. Det er dyrt, teknisk imponerende og tiltrækker naturligt opmærksomhed.

De fleste organisationer bygger dog ikke den næste frontier‑model. De bygger kundeservice‑applikationer, stemme‑AI‑systemer, medarbejder‑copiloter, videns‑assistenter, søgeværktøjer, dokument‑opsummeringsplatforme, svindel‑detektionssystemer og dusinvis af andre praktiske applikationer ved hjælp af allerede trænede modeller.

Det er inferens‑arbejdsbelastninger, og inferens ændrer infrastruktur‑ligningen. I stedet for udelukkende at optimere for maksimal beregning kan organisationer have brug for at optimere for hurtige svartider, lav latenstid, forudsigelige driftsomkostninger og konsistent ydeevne.

En kunde er ligeglad med, hvor kraftig den underliggende GPU er, hvis en chatbot tager fem sekunder om at svare. En opkalder er ligeglad med specifikationerne på AI‑klyngen, hvis en stemmeassistent gentagne gange misforstår anmodninger eller tøver under en samtale. De ved blot, at applikationen ikke fungerer tilfredsstillende.

At designe hvert AI‑miljø som om du træner en grundmodel er derfor som regel den forkerte tilgang og ofte unødvendigt dyr.

Målet for de fleste MSP‑kunder er ikke at bygge verdens største GPU‑klynge. At få AI‑applikationer i produktion hurtigt, pålideligt, sikkert og økonomisk er målet.

Udfordringen er at finde den rette balance mellem ydeevne, sikkerhed, skalerbarhed, robusthed og omkostninger for de arbejdsbelastninger, de faktisk kører.

Måske er GPU’en ikke din flaskehals

GPU’er er blevet AI‑infrastrukturens stjerne. De er dyre, svære at skaffe og lette at sammenligne, hvilket gør dem til centrum for utallige infrastruktur‑samtaler. GPU’en er dog måske ikke det, der holder en AI‑applikation tilbage, når den når produktion.

“Hvor mange GPU’er har vi brug for?” er ikke spørgsmålet, vi bør stille, men snarere “Hvad vil bremse denne applikation om seks måneder?”

Svaret kan også ligge et andet sted i arkitekturen.

Lagring er et godt eksempel. Enormt store datamængder forbruges af AI‑arbejdsbelastninger – og disse datasæt vokser over tid. Selv en ekstremt kraftig GPU kan bruge værdifuld tid på at vente i stedet for at arbejde, hvis lagringen ikke kan levere information hurtigt nok. Disse data skal også beskyttes, sikkerhedskopieres, bevares, sikres og administreres gennem deres livscyklus.

Netværk er lige så vigtigt. Gennemstrømning, latenstid, øst‑vest‑trafik og kommunikation mellem AI‑klynger påvirker alle applikationens ydeevne. Et veludformet beregningsmiljø kan ikke uendeligt kompensere for et dårligt netværk.

Sikkerhed skal også indgå i arkitekturen fra starten. Spørgsmål, der skal besvares før produktion, inkluderer: hvor følsomme data befinder sig, hvordan netværk segmenteres, om arbejdsbelastninger kommunikerer over privat eller offentlig forbindelse, og hvordan compliance‑ og suverænitetskrav håndteres.

En anden let overset faktor er konnektivitet. Selvom de måske ikke genererer flashende overskrifter, kan fiber‑diversitet, rutediversitet, peering‑relationer og geografisk nærhed kritisk påvirke brugeroplevelsen – for ikke at nævne platformens robusthed.

Slutbrugere ved ikke og er ligeglade med, hvilken GPU der sidder i rack’en. De vil vide, om applikationen svarer øjeblikkeligt eller lader dem vente.

Fysisk infrastruktur fortjener også opmærksomhed. Strømforsyning, kølekapacitet, rack‑tæthed og udvidelseskapacitet bestemmer, om dagens succesfulde implementering kan rumme morgendagens vækst.

Der er også data‑tyngdekraft. Når datasæt udvides, bliver det stadig mere ineffektivt at flytte petabytes af information mellem lokationer, blot fordi beregningen befinder sig et andet sted. I mange situationer kan det være både mere praktisk og billigere at bringe beregningen tættere på dataene.

Derfor betyder arkitektur noget.

Forestil dig en racerbils motor – blot fordi den har den bedste motor betyder det ikke, at den vinder. Transmissionen, dækkene, affjedringen, banen og især føreren er også vigtige. AI‑infrastruktur fungerer på samme måde.

Organisationerne, der skaber størst værdi fra AI, er ikke nødvendigvis dem med de største GPU‑klynger. Det er dem, der forstår, hvordan hver lag af infrastrukturen arbejder sammen.

Det er forskellen mellem at købe infrastruktur og at designe den.

Et arbejdsbelastning‑først planlægnings‑rammeværk

MSP’er har en mulighed for at ændre infrastruktur‑samtalen.

I stedet for at begynde med:

• Hvilken GPU?
• Hvilken cloud?
• Hvilken leverandør?

Start med arbejdsbelastningen:

• Hvilket forretningsproblem løser vi?
• Er dette en trænings‑ eller inferens‑arbejdsbelastning?
• Hvor meget latenstid kan applikationen tolerere?
• Hvor befinder dataene sig, og hvor hurtigt vil de vokse?
• Hvilke sikkerheds‑, compliance‑ og suverænitetskrav gælder?
• Hvordan vil arbejdsbelastningen skalere?
• Hvilket tilgængelighedsniveau kræver forretningen?
• Hvilket niveau af operationel risiko er acceptabelt?
• Hvad vil det koste at drive dette miljø, efterhånden som brugen vokser?

Svarene bør bestemme arkitekturen. Ikke omvendt.

Muligheden for MSP’er

Denne ændring ændrer MSP’ens rolle.

Kunder har ikke brug for en ny partner, der kan sælge dem infrastruktur. En partner, der kan hjælpe dem med at træffe bedre infrastruktur‑beslutninger, er det, de har brug for.

En arbejdsbelastning‑først tilgang er et must, da den giver MSP’er mulighed for at vurdere beregning, lager, netværk, konnektivitet, sikkerhed, datalokation, tilgængelighed og omkostninger som dele af en samlet arkitektur – i stedet for separate indkøbsbeslutninger.

På denne måde kan du styre omkostninger, forbedre ydeevne og identificere operationelle og sikkerhedsmæssige risici, før applikationerne når produktion.

Der skabes også en bedre forretningsmodel for MSP’en.

MSP’er kan bygge højere‑værdi gentagne tjenester omkring arkitektur, implementering, optimering, sikkerhed, livscyklus‑styring, kapacitetsplanlægning og løbende forbedring – i stedet for primært at konkurrere på faldende hardware‑marginer.

Værdien ligger ikke i at anbefale den nyeste GPU eller den nyeste cloud‑platform. Den ligger i at vide, hvornår en kunde har brug for dem, hvornår de ikke har brug for dem, og hvad der ellers skal designes omkring dem.

AI‑infrastruktur er i sidste ende ikke en hardware‑beslutning. Det er en arkitektur‑beslutning, der drives af arbejdsbelastningen, dataene og forretningsresultatet, som kunden forsøger at opnå.

De MSP’er, der forstår denne sondring, vil blive placeret som noget langt mere værdifuldt end infrastruktur‑leverandører.

De vil blive de personer, som kunderne stoler på for at hjælpe med at afgøre, hvilken infrastruktur de faktisk har brug for.