Amazon tager et nyt skridt i konkurrencen om den infrastruktur, som kunstig intelligens bliver bygget på. Med TorchNeuron vil selskabet gøre det lettere for udviklere at bruge deres eksisterende PyTorch-kode på AWS Trainium-chips. Den offentlige beta og open source-lanceringen er annonceret til tirsdag den 20. oktober ved PyTorch Conference North America.

Det centrale er ikke en ny chatbot eller en model, som almindelige brugere kan åbne i browseren. Nyheden ligger i forbindelsen mellem software og hardware: Det lag, der bestemmer, hvordan udviklernes beregninger bliver udført på en bestemt chip. Hvis den forbindelse bliver enklere, kan det blive mindre krævende at afprøve en anden computerplatform.

Software er en del af konkurrencen om chips

I Amazons præsentation er løftet, at eksisterende PyTorch-kode kan køre på Trainium med meget få ændringer. Selskabet fremhæver især udviklernes tid som en omkostning ved at flytte mellem forskellige typer hardware.

Det er leverandørens egen vurdering af gevinsten, ikke en uafhængig måling af, hvad alle virksomheder vil spare. Amazon har en direkte kommerciel interesse i at gøre sine chips mere attraktive. Derfor er det relevant både at læse produktbudskabet og undersøge, hvad den tekniske dokumentation faktisk understøtter.

For en virksomhed er valget af beregningsplatform nemlig mere end en sammenligning af chipnavne. Et tænkt udviklingshold kan have måneder investeret i modeller, test og driftsrutiner. Hvis et platformsskifte kræver omfattende ændringer i disse dele, bliver selve flytningen et projekt. Det er den type barriere, en tættere integration potentielt kan reducere.

Trainium bliver en enhed i PyTorch

Den tekniske introduktion på PyTorchs hjemmeside blev offentliggjort den 19. oktober. Her beskrives TorchNeuron som en indbygget backend til Trainium2 og Trainium3. Integrationen bruger PyTorchs officielle udvidelsesmuligheder, herunder PrivateUse1, frem for at kræve et helt andet programmeringsmiljø.

I introduktionens enkle eksempel flyttes en model til enheden med udtrykket .to('neuron'). Det illustrerer den ønskede brugeroplevelse, men bør ikke læses som en garanti for, at enhver eksisterende kodebase kan flyttes med præcis én ændring. Det afhænger blandt andet af de funktioner og afhængigheder, som projektet bruger.

PyTorch-præsentationen beskriver både direkte udførelse af operationer, kaldet eager execution, og optimering gennem torch.compile. Den første tilgang er relevant, når udviklere eksperimenterer og finder fejl. Den anden samler beregninger i en form, som kan optimeres til udførelse på hardwaren. TorchNeuron er annonceret under Apache 2.0-licensen.

Hugging Face ændrer sin anbefalede vej

Et andet vigtigt element er understøttelsen i de biblioteker, udviklere allerede bruger. Hugging Face beskriver, at blandt andet Transformers, Diffusers, Accelerate, PEFT og TRL kan arbejde direkte med den nye backend.

Hidtil har Hugging Faces integration med Trainium i høj grad været formidlet gennem Optimum Neuron. Ifølge platformens gennemgang var den løsning baseret på PyTorch XLA og havde særskilt kode til at håndtere kompleksiteten. Med TorchNeuron anbefaler Hugging Face i stedet, at Neuron-brugere anvender de almindelige biblioteker direkte.

Det er en konkret ændring i den anbefalede softwarevej, men ikke det samme som et løfte om, at samtlige modeller og alle kombinationer af biblioteker allerede virker uden tilpasning. Hugging Face er desuden en integrationspartner i lanceringen. Dens beskrivelse er værdifuld som teknisk førstehåndsoplysning, men er ikke en uafhængig sammenligning med konkurrerende chips.

Betaudgaven har klare begrænsninger

De officielle udgivelsesnoter gør det muligt at se bag om det brede budskab. De beskriver blandt andet, at understøttelse af dynamiske inputformer fortsat er under udvikling. I den aktuelle version kræver torch.compile indstillingen dynamic=False, og en ny inputform kan udløse en ny kompilering.

Dokumentationen nævner også PyTorch-områder, som endnu ikke understøttes, herunder torch.sparse, torch.func, torch.nested og torch.distributions. Ved første kørsel kan der desuden komme kompileringstid oven i beregningen, hvis den nødvendige version ikke allerede findes i cachen.

Disse forhold er ikke i sig selv et bevis på, at produktet er uegnet. De betyder, at kompatibilitet skal vurderes for den konkrete opgave. Et eksempel, som fungerer godt med én bestemt model og faste input, dokumenterer ikke nødvendigvis oplevelsen i et andet projekt med mere varierende data og særlige operationer.

Hvad bør en praktisk sammenligning undersøge?

Elektronikas vurdering er, at den mest nyttige test vil være en afgrænset, repræsentativ opgave fra virksomhedens eget arbejde. Først skal man fastslå, om resultatet er korrekt. Derefter giver det mening at undersøge hastighed, stabilitet og ressourceforbrug. Et hurtigt svar er ikke en fordel, hvis det bygger på en ændret opgave eller en kvalitet, som ikke er acceptabel.

Opstart og efterfølgende drift bør også holdes adskilt. En første kørsel kan indeholde arbejde, som senere genbruges. Omvendt kan hyppige ændringer i model eller input gøre opstartsarbejdet vigtigt i praksis. Det relevante målepunkt afhænger derfor af, om systemet skal bruges til korte eksperimenter eller gentage den samme beregning mange gange.

En samlet økonomisk vurdering bør tilsvarende omfatte mere end prisen for beregningstid. Arbejdet med opsætning, fejlfinding, overvågning og vedligeholdelse kan påvirke regnestykket. Det er generelle vurderingspunkter, ikke beregnede besparelser ved TorchNeuron. Elektronika har ikke gennemført egne ydelsestest af betaudgaven.

Mere valgfrihed er målet – ikke et bevist udfald

Nyheden er interessant, fordi den viser, hvordan konkurrencen om AI-hardware også føres gennem software. En chip kan have attraktive egenskaber, men det er afgørende, om udviklere kan få deres egne modeller til at fungere på den uden uforholdsmæssigt meget ekstra arbejde.

En open source-licens er heller ikke det samme som gratis adgang til beregningskraft. Licensen vedrører softwaren; udgifterne til at køre modellerne må vurderes særskilt. Tilsvarende siger en tilgængelig beta ikke i sig selv noget om en bestemt organisations krav til support, oppetid eller langsigtet drift.

Der er desuden forskel på at kunne flytte modelkoden og at kunne flytte en hel tjeneste. Data, adgangsstyring, logning og øvrige cloudkomponenter kan være knyttet til en bestemt driftsløsning. En mere flytbar beregning er derfor kun én del af den samlede arkitektur. Det er værd at holde fast i, når en enkel demonstration bliver omsat til beslutninger om et større produktionssystem.

Med TorchNeuron bliver der en ny mulighed at undersøge i det eksisterende PyTorch-miljø. Hvor stor en forskel den gør, må vise sig gennem konkrete erfaringer med kompatibilitet, drift og omkostninger. Det dokumenterede skridt nu er den annoncerede offentlige beta og integrationsarbejdet omkring den – ikke at én platform dermed har vundet markedet.