- Python dominerer AI på grund af sit økosystem, men GIL, dynamisk typing og fortolkeren hæmmer ydeevnen.
- Mojo, baseret på MLIR, tilbyder kompilering, ægte parallelisering og kompatibilitet med Python-biblioteker.
- Modular forener runtime for PyTorch og TensorFlow med integreret acceleration og kvantisering.
- Store hastighedsforøgelser (Mandelbrot, SIMD) er mulige; udfordringen er at bringe den fordel til produktion og flere hardwaretyper.
Debatten om Mojo vs. Python-ydeevne raser, fordi den berører kernen i moderne AI: reel hastighed, brugervenlighed og hardwareunderstøttelse. I de senere år er der dukket accelerationstal op, der på papiret virker som science fiction, men de er bakket op af dybtgående ændringer i compilere og i, hvordan kode udføres på CPU'er, GPU'er og AI-acceleratorer.
I denne artikel har vi samlet en omfattende oversigt over alt, der er publiceret på tværs af forskellige kilder om Python, dets ydeevnebegrænsninger og tilgangen bag Mojo , sproget drevet af Modular og anført af Chris Lattner (LLVM, Clang, Swift). Vi forklarer også MLIR, årsagerne bag GIL-flaskehalse, forskellene mellem CUDA og MPS, kompatibilitet med Python-økosystemet og de udfordringer, der stadig ligger forude.
Python dominerer AI, men dens arkitektur hjælper ikke på ydeevnen
Det er ikke overraskende, at Python er det universelle sprog inden for kunstig intelligens : simpel syntaks, tusindvis af biblioteker, tonsvis af tutorials og et enormt fællesskab. Denne popularitet kommer dog med en ubehagelig realitet: Python fortolkes , types dynamisk og er underlagt Global Interpreter Lock (GIL) , som begrænser samtidig udførelse af ren Python-kode til en enkelt tråd.
Dette design muliggør hurtigere udvikling, men det går på kompromis med hastighed og hukommelseseffektivitet sammenlignet med kompilerede sprog som C/C++, Swift eller Rust. I ML/DL-arbejdsbelastninger, hvor hvert millisekund tæller, og hardwaren er utrolig hurtig, er denne ulempe ekstremt mærkbar.
For at kompensere har økosystemet tyet til løsninger: NumPy (med dele i C og Fortran), biblioteker, der delegerer til native kode , og C/C++-udvidelser til kritiske operationer. Det virker, ja, men det introducerer lag, afhængigheder og et Frankensteins monster af versioner, frameworks og backends, der kan være vanskelige at vedligeholde i produktion.
Derudover er parallelisme i Python ofte afhængig af multiprocessering eller af biblioteker, der frigiver GIL'en i native sektioner. Resultatet er, at medmindre arbejdsbyrden er meget veldelegeret til C/C++ eller GPU'en, bliver Pythons rå ydeevne en flaskehals.
NumPy og andre "patches": essentielle, men med begrænsninger
NumPy er det klassiske eksempel: mange af dens kritiske operationer er skrevet i C eller Fortran , hvilket er betydeligt hurtigere end ren Python. Men når det kommer til fin parallelisme, skalering til flere kerner eller integration med nye acceleratorer, dukker Pythons begrænsninger op igen , især hvis kontrolflowet ofte vender tilbage til fortolkeren.
Denne lagdelte tilgang (Python → C/C++-udvidelser → drivere/hardware) er effektiv, men kompleks at debugge og implementere . I stor skala med AI, med trænings-, inferens- og efterbehandlingspipelines, vejer denne operationelle kompleksitet næsten lige så tungt som de tilgængelige FLOPS.
CUDA, MPS og portabilitetsproblemet
CUDA- acceleration (NVIDIA) er en livredder, men også et forgyldt bur: nogle modeller og optimeringer er helt afhængige af NVIDIA-stakken. Hvis du forsøger at køre den samme kode på Apple Silicon med Metal Performance Shaders (MPS) eller på AMD GPU'er, kan du støde på ikke-understøttede instruktioner eller ufuldstændige beregningsstier.
Den mest almindelige sammenligning er klar: med CUDA kører du en "Ferrari", mens MPS kan føles mere begrænset til bestemte arbejdsbyrder. Alligevel presser branchen på for standarder og portabilitet , fordi ingen ønsker at binde deres forretning til en enkelt hardwareleverandør, medmindre det er absolut nødvendigt.
MLIR: Broen, som den nye æra inden for datalogi behøvede
For at forstå, hvad Mojo foreslår, er vi nødt til at tale om MLIR (Multi-Level Intermediate Representation) , et projekt, der er opstået i LLVM-økosystemet, og som tilføjer en mellemliggende repræsentation designet til høj ydeevne og maskinlæring . I modsætning til den klassiske LLVM-pipeline håndterer MLIR datagrafer, vektorisering, tessellation, DMA-indsættelse og eksplicit cachestyring.
Kort fortalt: MLIR tillader transformation af højniveaukode til implementeringer, der ligger meget tæt på målhardwaren (CPU'er, GPU'er, TPU'er, NPU'er, FPGA'er osv.), udvinding af parallelisme og anvendelse af HPC-optimeringer , som den klassiske compiler ikke dækkede lige så godt for disse domæner.
Hvad er Mojo egentlig?
Mojo er et sprog, der præsenterer sig selv som et supersæt af Python : det opretholder en velkendt syntaks, kan udnytte de samme biblioteker og integrerer en moderne kompileringsmodel understøttet af MLIR. Det blev lanceret i 2023, i første omgang som en weblegeplads tilgængelig on-demand, og senere med lokal udførelse på GNU/Linux og macOS. I februar 2025 blev dets standardbibliotek gjort til open source, selvom compileren stadig er lukket den dag i dag.
Målet er ambitiøst: Pythons enkelhed med C/C++'s ydeevne , plus den sikkerhed og brugervenlighed, vi har set i sprog som Rust eller Swift. Med andre ord, at skrive på et højt niveau og producere små, hurtige og let-implementerede binære filer.
Designnøgler: indtastning, hukommelse, strukturer og funktioner
Blandt de mest slående funktioner er stærk typing (og statisk typing når det er nødvendigt), brugen af let/var til at deklarere uforanderlige og muterbare elementer og understøttelse af strukturer med kompileringsdefinerede designs, hvilket letter genereringen af optimal maskinkode.
Mojo giver dig mulighed for at deklarere funktioner med `fn` ud over `def` ; generelt set indebærer `fn` flere begrænsninger og derfor bedre optimeringspotentiale for compileren. Den kan også prale af "omkostningsfrie abstraktioner" og selvjusterende funktioner , hvor compileren vælger effektive parametre til målplatformen.
Uden GIL og med reel parallelisering
I modsætning til Python er Mojo ikke afhængig af GIL . Runtime og compiler er designet til at udnytte tråde, vektorer og acceleratorer uden at udvikleren behøver at kæmpe med fortolkerens grundlæggende samtidighed. I praksis betyder det, at opgaver, der i Python "støder op" med GIL, virkelig kan køre parallelt.
Dette punkt er nøglen i intensiv databehandling: hvis du kan opdele et problem i underopgaver og køre dem samtidigt på en indbygget måde, er præstationsspringet ikke trinvis, det er et ligaskift.
Ydeevne: fra Mandelbrot til vektoriserede versioner
For at måle forbedringer er en tilbagevendende test Mandelbrot- sættet , en beregningsintensiv fraktalgenerator, der er perfekt til parallelisering. Med ren Python er der rapporteret tider på over 1000 sekunder , mens implementeringer i Mojo er faldet til omkring 0,03 sekunder efter successive optimeringer.
Følgende progressioner er blevet dokumenteret: naiv Python-version → NumPy → naiv Mojo-version → vektoriseret Mojo med SIMD . Med denne pipeline af forbedringer er der observeret enorme hastighedsforøgelser, lige fra 35.000x til rapporterede tal på 68.000x i specifikke scenarier. Disse er spektakulære tal, der som altid afhænger af algoritmen, hardwaren og den omhu, du lægger i optimeringen.
Simpel kompilering og implementering
Mojo følger filosofien om at bygge binært : du bygger, du får en eksekverbar fil, og du distribuerer den . Hvis du bruger Python, undgår du hovedpinen med virtuelle miljøer , hjul og kombinationer af biblioteksversioner, der ikke altid fungerer godt sammen.
For at give dig en idé, kunne "Hello World" kompileres og køres med en simpel mojo hello.mojo . Derudover har filerne filtypenavnet .mojo (flamme-emojien er også blevet populær som et blink), hvilket gør dem lettere at identificere i hybridprojekter.
Python-kompatibilitet og økosystem
En del af Mojos charme er, at det ikke tvinger dig til at smide det væk, du allerede har : dets kompatibilitet med Python-økosystemet betyder, at du kan fortsætte med at bruge biblioteker som NumPy, Pandas eller Matplotlib, mens du anvender mere effektive strukturer og typer, når det passer dig.
I praksis udjævner denne "Python++"-strategi adoptionskurven: du vedligeholder din kodebase , flytter aktive komponenter til Mojo og udnytter compileren og MLIR til at presse ydeevnen ud uden at opgive den syntaks, du kender.
Modulær: en runtime til at forene PyTorch og TensorFlow
Ud over sproget har Modular introduceret et universelt framework/runtime , der er i stand til at køre PyTorch- og TensorFlow -modeller uden at kræve installation af begge stakke. Ifølge disse kilder kan arkitekturen accelerere TensorFlow-eksekveringen med op til 3x og PyTorch med op til 2,5x , samtidig med at kvantiseringsværktøjer integreres og dermed bidrager til AI - skalerbarhed.
Visionen er at undgå "trelags"-helvede (Python → C/C++ → specifik hardware) med et enkelt programmeringslag og en backend, der kommunikerer med al hardware og får det bedste ud af alle platforme uden at skulle omskrive din model hver anden dag.
Kvantisering: reduktion af størrelse uden at ofre nøjagtighed
Kvantisering af modeller er som en MP3-fil til neurale netværk: man reducerer nøjagtigheden i bestemte vægte/lag, og til gengæld reducerer man størrelsen og fremskynder inferensen. Tabet af nøjagtighed er normalt lille (for eksempel at gå fra 94% til 91% i en klassifikator), og gevinsten i implementering og hastighed kompenserer mere end rigeligt.
Denne tilgang er nøglen til at bringe modeller til lokale enheder , samtidig med at privatlivets fred respekteres. Faktisk bevæger stakke som Core ML og acceleratorer som Apples NPU'er (via MPS/Accelerate) sig mod komprimerede modeller, der passer og kører problemfrit på en iPhone eller Mac uden at sende data til skyen.
Fra Swift til TensorFlow til Mojo: Lattners rejse
Vejen til dette punkt er ikke tilfældig. Efter sin tid hos Apple (LLVM, Clang, Swift ) arbejdede Chris Lattner hos Tesla og Google Brain, hvor han stod i spidsen for Swift for TensorFlow . Forsøget på at kombinere et moderne sprog med maskinlæring blev lagt på hylden, men det gav erfaringer, der nu har krystalliseret sig i MLIR og designet af Mojo.
Før Modular beskæftigede Lattner sig også med RISC-V- verdenen (SciFive), hvilket passer med ideen om, at fremtiden for AI involverer mange typer hardware , og at vi har brug for compilere og runtime-programmer, der hurtigt kan tilpasse sig dem alle.
Projektstatus, støtte og implementering
Mojo blev lanceret i 2023, og selvom sproget udvikler sig hurtigt, er det stadig i en modningsfase . Standardbiblioteket blev åbnet i februar 2025, men compileren er fortsat lukket . Med hensyn til popularitet (TIOBE-indeks) rangerer Mojo under top 50, hvilket er forventeligt for et sprog, der kun er to år gammelt.
I afsnittet "Hvem er hvem" er support fra Amazon, AMD, NVIDIA og Inworld blevet nævnt . Alligevel skal Python, for at kunne konkurrere med det, have et fællesskab, dokumentation, pakker og succeshistorier inden for produktion , der kan tjene som benchmark for andre.
Udfordringer: fællesskab, refleksion og dynamiske karakteristika
Ud over ydeevne vinder Python med hensyn til fællesskab, ressourcer og økosystem . Mojo bliver nødt til at lukke huller på områder, hvor Python udmærker sig, såsom visse refleksionsmekanismer eller udbredte dynamiske mønstre. Det bliver også nødvendigt at fortsætte med at forfine sin brugervenlighed for at gøre overgangen fra Python fuldstændig problemfri.
Fra et teknisk synspunkt lyder løftet om " kompilering til alt " fantastisk, men hver backend (CUDA, ROCm, MPS, TPU'er, FPGA'er...) har sine nuancer. At opretholde ensartet funktionalitet og ydeevne på tværs af dem alle under runtime er et maraton, ikke en sprint.
Mojo og GPU'er: Ud over NVIDIA
En af Mojo og MLIR's styrker er deres evne til at målrette mod GPU'er fra både NVIDIA og AMD , ikke kun CUDA-økosystemet. Hvis denne understøttelse forbliver opdateret og konkurrencedygtig, vil mange virksomheder se den strategiske fordel ved ikke at være bundet til en enkelt leverandør.
Samtidig kræver Apple-verdenen (med MPS ) og andre specialiserede acceleratorer (NPU'er, FPGA'er ) passende kompileringsstier og biblioteker. Løftet "skriv én gang, kør hurtigt overalt" er ambitiøst, og hvis det leveres korrekt, ville det være banebrydende.
Debat: Nyt sprog eller “Python++”?
I tekniske fora er der debat om, hvorvidt Mojo er "endnu en variant af Python" eller et nyt sprog, der kun deler syntaks. Til daglig brug er det afgørende, at du kan genbruge din kode og dine biblioteker, samtidig med at du skriver performance-komponenter med mere omfattende typer og strukturer.
Denne dualitet, kombineret med den moderne MLIR-compiler, er det, der gør "hello world" brugervenligt, samtidig med at det gør det muligt for dine computerkerner at nærme sig eller endda overgå C/C++'s ydeevne i vektoriserede scenarier.
Ressourcer, fællesskab og læring
Hvis du er nybegynder inden for kunstig intelligens, er åbne læringsfællesskaber uvurderlige. Disse rum, der er rettet mod både studerende og lærere, giver mulighed for at stille spørgsmål, dele ressourcer og komme videre fra det grundlæggende til avancerede teknikker. De er fantastiske steder at øve sig, sammenligne tilgange og få svar fra den virkelige verden.
Det opsøgende økosystem hjælper også: fra Mojo-lanceringsresuméer af eksperter som Jeremy Howard til gratis Python-kurser på videoplatforme, der får dig til at kode uden omkostninger. Jo stærkere fællesskabet omkring Mojo er, jo lettere vil det være for virksomheder og udviklere at anvende det.
Praktiske noter og interessante detaljer
Små detaljer om livskvalitet spiller også en rolle: .mojo- filer , understøttelse af fn / def , direkte udførelse med mojo- kommandoen eller den eksplicitte intention om at tilbyde binære filer, der er nemme at distribuere . Det er hverdagsagtige ting, men når man skalerer projekter, gør de hele forskellen.
Samtidig skal Rust og Swifts indflydelse på typedesign, hukommelsessikkerhed og omkostningsfri abstraktioner anerkendes . Dette er ikke tilfældigt: Lattner kommer fra at skabe Swift og afprøve LLVM/Clang; denne arv er tydelig i compilerens design.
Fra laboratorium til produktion: Hvad du kan forvente
Hvis du skal prøve Mojo i dag, giver det mening at bruge det i moduler med stor effekt (computerkerner, intensive transformationer eller tætte loops). Behold din orkestrering og værktøjer i Python, og migrer komponenter med høj efterspørgsel til Mojo for at måle den reelle fordel i dine metrikker.
Ifølge de analyserede rapporter har Mandelbrot-lignende opgaver eller SIMD-kerner opnået enorme hastighedsforøgelser . I virkelige pipelines, med I/O, forbehandling og tredjepartsbiblioteker, vil man se betydelige gevinster, omend mere beskedne og afhængige af den dominerende flaskehals.
Samlede lag: farvel til "Frankenstacken"
Et centralt løfte ved Modular-stakken er foreningen af lag: i stedet for spredte Python + C/C++ + specifikke backends, tilbyder den et enkelt sprog til alle tre lag og en runtime, der forhandler med hardwaren . Mindre "lim", færre inkompatibiliteter og mindre defensiv vedligeholdelse.
Hvis denne vision slår igennem, kan trænings- og inferensprocesser flyttes mellem NVIDIA, AMD, Apple Silicon, TPU'er eller NPU'er uden at kræve en fuldstændig omprogrammering af projektet. Og det er mere end en teknisk detalje en forretningsstrategi : frihed til at vælge hardware baseret på omkostninger, tilgængelighed eller energieffektivitet.
En bemærkning om stemmemodeller og transskription
I implementeringer i den virkelige verden, når man porterer modeller som Whisper (transkription) fra Python til native ruter eller andre API'er (MPS/Accelerate), opstår der inkompatibiliteter: visse instruktioner findes i CUDA, men ikke i MPS, eller omvendt. Det er her, at en samlet backend og en compiler med MLIR kan spare dig for en masse hovedpine.
Uden den fælles lim ender man med kodeforgreninger og manuelle porteringer, der forsinker projektets udvikling. Med den er løftet at skrive én gang og få effektiv routing på alle understøttede platforme.
"Meta"-kontekst: opsøgende arbejde, sponsorater og tech-miljøet
Noget af det materiale, der nærer denne debat, kommer fra podcasts og tekniske blogs , der kombinerer uddannelsesmæssigt indhold med sponsorater og fællesskaber (endda merchandising). Ud over det anekdotiske (kurser, apps, Twitch, baggrundsmusik, support af podcastnetværk...) er det interessante, at den tekniske debat har bevæget sig ud over sin niche og resonerer med en bred vifte af målgrupper.
Den støj er god: den bringer vanskelige spørgsmål, brugsscenarier fra den virkelige verden og erfaringer med en række forskellige hardwaretyper. At øge rækkevidden af samtalen mod MLIR og Mojo accelererer fejldetektion, migreringsvejledninger og oprettelsen af opskrifter, som vi alle kan genbruge.
Det overordnede billede er klart: Python vil forblive porten til AI, men et pragmatisk alternativ findes allerede, når ydeevne er altafgørende. Mojo sigter ikke mod at eliminere Python, men snarere at forbedre det med en moderne compiler , ægte parallelisering og et runtime-lag, der forstår både nutidens og morgendagens acceleratorer. Hvis du arbejder i ML/DL, og tid/omkostning pr. inferens eller træningsepoke er vigtig, er det værd at prøve med dine egne data og hardware.
