- Python hallitsee tekoälyä ekosysteeminsä ansiosta, mutta GIL, dynaaminen tyypitys ja tulkki heikentävät suorituskykyä.
- MLIR:ään perustuva Mojo tarjoaa kääntämisen, todellisen rinnakkaistamisen ja yhteensopivuuden Python-kirjastojen kanssa.
- Modulaarinen yhdistää PyTorchin ja TensorFlow'n suoritusympäristöt integroidulla kiihdytyksellä ja kvantisoinnilla.
- Huikeat kiihtyvyydet (Mandelbrot, SIMD) ovat mahdollisia; haasteena on tuoda tämä etu tuotantoon ja useisiin laitteisiin.
Mojo vs. Python -suorituskykykeskustelu on kiivas, koska se koskettaa modernin tekoälyn ydintä: todellista nopeutta, helppokäyttöisyyttä ja laitteistotukea. Viime vuosina on tullut esiin kiihtyvyyslukuja, jotka paperilla vaikuttavat tieteiskirjallisuudelta, mutta niitä tukevat syvälliset muutokset kääntäjissä ja koodin suorittamisessa suorittimissa, näytönohjaimissa ja tekoälykiihdyttimissä.
Tässä artikkelissa olemme koonneet kattavan yleiskatsauksen kaikesta, mitä eri lähteissä on julkaistu Pythonista, sen suorituskykyrajoituksista ja Mojon lähestymistavasta. Modular-pohjainen ja Chris Lattnerin (LLVM, Clang, Swift) johtama kieli on. Selitämme myös MLIR:n, GIL-pullonkaulojen syyt, CUDA:n ja MPS:n väliset erot, yhteensopivuuden Python-ekosysteemin kanssa ja edessä olevat käyttöönottohaasteet.
Python hallitsee tekoälyä, mutta sen arkkitehtuuri ei auta suorituskykyä
Ei ole yllätys, että Python on tekoälyn universaali kieli : yksinkertainen syntaksi, tuhansia kirjastoja, valtavasti tutoriaaleja ja valtava yhteisö. Tähän suosioon liittyy kuitenkin epämukava todellisuus: Python tulkitaan , tyypitetään dynaamisesti ja siihen sovelletaan Global Interpreter Lock (GIL) -lukkoa , joka rajoittaa puhtaan Python-koodin samanaikaisen suorittamisen yhteen säikeeseen.
Tämä rakenne mahdollistaa nopeamman kehityksen, mutta se heikentää nopeutta ja muistin tehokkuutta verrattuna käännettäviin kieliin, kuten C/C++, Swift tai Rust. ML/DL-työkuormissa, joissa jokainen millisekunti on tärkeä ja laitteisto on uskomattoman nopea, tämä rangaistus on erittäin huomattava.
Kompensoidakseen tätä ekosysteemi on turvautunut kiertotapoihin: NumPy:hen (osia C- ja Fortran-kielillä), kirjastoihin, jotka delegoivat natiivikoodia , ja C/C++-laajennuksiin kriittisiin toimintoihin. Se toimii kyllä, mutta se tuo mukanaan kerroksia, riippuvuuksia ja Frankensteinin hirviön versioita, kehyksiä ja taustapalvelimia, joiden ylläpito tuotannossa voi olla hankalaa.
Lisäksi Pythonin rinnakkaisuus perustuu usein moniajoon tai kirjastoihin, jotka julkaisevat GIL:n natiiveissa osioissa. Tuloksena on, että ellei työmäärää ole delegoitu erittäin hyvin C/C++:lle tai GPU:lle, Pythonin raakasuorituskyvystä tulee pullonkaula.
NumPy ja muut "korjaukset": välttämättömiä, mutta rajoituksin
NumPy on klassinen esimerkki: monet sen kriittisistä operaatioista on kirjoitettu C- tai Fortran- kielellä , mikä on huomattavasti nopeampaa kuin puhdas Python. Kuitenkin, kun on kyse hienojakoisesta rinnakkaisuudesta, skaalautumisesta useisiin ytimiin tai integroinnista uusiin kiihdyttimiin, Pythonin rajoitukset tulevat uudelleen esiin , varsinkin jos ohjausvirta palaa usein tulkkiin.
Tämä kerrostettu lähestymistapa (Python → C/C++-laajennukset → ajurit/laitteisto) on tehokas, mutta monimutkainen virheenkorjauksessa ja käyttöönotossa . Laajassa mittakaavassa tekoälyssä, jossa on koulutus-, päättely- ja jälkikäsittelyputket, tämä operatiivinen monimutkaisuus painaa lähes yhtä paljon kuin käytettävissä olevat FLOPSit.
CUDA, MPS ja siirrettävyysongelma
CUDA -kiihdytys (NVIDIA) on pelastus, mutta myös kullattu häkki: jotkin mallit ja optimoinnit ovat täysin riippuvaisia NVIDIA-piirisarjasta. Jos yrität suorittaa samaa koodia Apple Siliconilla , jossa on Metal Performance Shader (MPS), tai AMD:n näytönohjaimilla, saatat kohdata tukemattomia ohjeita tai epätäydellisiä laskentapolkuja.
Yleisin vertailukohta on selvä: CUDA:n kanssa ajat "Ferrarilla", kun taas MPS voi tuntua rajoitetummalta tietyillä työkuormilla. Silti ala pyrkii standardeihin ja siirrettävyyteen, koska kukaan ei halua sitoa liiketoimintaansa yhteen laitetoimittajaan, ellei se ole ehdottoman välttämätöntä.
MLIR: silta, jota uusi laskennan aikakausi tarvitsee
Ymmärtääksemme, mitä Mojo ehdottaa, meidän on puhuttava MLIR:stä (Multi-Level Intermediate Representation) , LLVM-ekosysteemissä syntyneestä projektista, joka lisää väliesityksen, joka on suunniteltu korkeaa suorituskykyä ja koneoppimista varten . Toisin kuin klassinen LLVM-prosessi, MLIR käsittelee datagraafeja, vektorisointia, tessellointia, DMA-lisäystä ja eksplisiittistä välimuistin hallintaa.
Yksinkertaisesti sanottuna: MLIR mahdollistaa korkean tason koodin muuntamisen toteutuksiksi, jotka ovat hyvin lähellä kohdelaitteistoa (CPU:t, GPU:t, TPU:t, NPU:t, FPGA:t jne.), rinnakkaisuuden purkamisen ja HPC-optimointien soveltamisen , joita klassinen kääntäjä ei kattanut yhtä hyvin näillä aloilla.
Mikä Mojo oikein on?
Mojo on kieli, joka esittäytyy Pythonin supersetinä : se ylläpitää tuttua syntaksia, voi hyödyntää samoja kirjastoja ja integroi modernin käännösmallin, jota MLIR tukee. Se julkaistiin vuonna 2023, aluksi verkkopohjaisena leikkikenttänä , johon oli mahdollista päästä käsiksi pyynnöstä, ja myöhemmin paikallisesti suoritettavana GNU/Linuxissa ja macOS:ssä. Helmikuussa 2025 sen vakiokirjastosta tehtiin avoimen lähdekoodin kieli, vaikka kääntäjä on edelleen suljettu.
Tavoite on kunnianhimoinen: Pythonin yksinkertaisuus yhdistettynä C/C++:n suorituskykyyn sekä Rustin ja Swiftin kaltaisissa ohjelmointikielissä nähty turvallisuus ja käyttäjäystävällisyys. Toisin sanoen, korkealla tasolla kirjoittaminen ja pienten, nopeiden ja helposti käyttöönotettavien binääritiedostojen tuottaminen.
Suunnitteluavaimet: tyypitys, muisti, rakenteet ja funktiot
Silmiinpistävimpiä ominaisuuksiin kuuluvat vahva tyypitys (ja staattinen tyypitys tarvittaessa), let/var- metodin käyttö muuttumattomien ja muokattavien elementtien määrittämiseen sekä tuki käännettävällä suunnittelulla määritellyille rakenteille , jotka helpottavat optimaalisen konekoodin luomista.
Mojossa voit deklaroida funktioita käyttämällä `fn`-muuttujaa `def`-muuttujan lisäksi ; yleisesti ottaen `fn`- muuttujaan liittyy enemmän rajoituksia ja siten parempi optimointipotentiaali kääntäjälle. Se tarjoaa myös "nollakustannusabstraktioita" ja itsevirittyviä ominaisuuksia , joissa kääntäjä valitsee kohdealustalle tehokkaat parametrit.
Ilman GILiä ja todellisella rinnakkaisuudella
Toisin kuin Python, Mojo ei ole riippuvainen GIL:stä . Suoritusympäristö ja kääntäjä on suunniteltu hyödyntämään säikeitä, vektoreita ja kiihdyttimiä ilman, että kehittäjän tarvitsee painida tulkin perussamanaikaisuuden kanssa. Käytännössä tämä tarkoittaa, että tehtävät, jotka Pythonissa "osuvat" GIL:iin, voivat todella toimia rinnakkain.
Tämä seikka on avainasemassa intensiivisessä laskennassa: jos ongelma voidaan jakaa osatehtäviin ja suorittaa ne samanaikaisesti natiivisti, suorituskyvyn parannus ei ole inkrementaalinen, vaan valtava muutos.
Suorituskyky: Mandelbrotista vektoriversioihin
Parannusten mittaamiseksi toistuvana testinä käytetään Mandelbrot- joukkoa , laskennallisesti intensiivistä fraktaaligeneraattoria, joka sopii täydellisesti rinnakkaistamiseen. Puhtaalla Pythonilla on raportoitu yli 1000 sekunnin aikoja , kun taas Mojo-toteutukset ovat pudonneet noin 0,03 sekuntiin peräkkäisten optimointien jälkeen.
Seuraavan tyyppisiä edistysaskelia on dokumentoitu: naiivi Python-versio → NumPy → naiivi Mojo-versio → vektorisoitu Mojo SIMD:llä . Tämän parannusputken myötä on havaittu valtavia kiihtymiä, jotka vaihtelevat 35 000-kertaisesta raportoituun 68 000-kertaiseen lukuun tietyissä tilanteissa. Nämä ovat hämmästyttäviä lukuja, jotka, kuten aina, riippuvat algoritmista, laitteistosta ja optimointiin käytetystä huolellisuudesta.
Yksinkertainen kääntäminen ja käyttöönotto
Mojo noudattaa build-to-binary- filosofiaa : käännät, saat suoritettavan tiedoston ja jaat sen . Jos käytät Pythonia, tämä välttää virtuaaliympäristöjen , pyörien ja kirjastoversioiden yhdistelmien aiheuttamat ongelmat, jotka eivät aina toimi hyvin yhdessä.
Idean antamiseksi "Hello World" voitaisiin kääntää ja suorittaa yksinkertaisella mojo hello.mojo -komennolla . Lisäksi tiedostoilla on .mojo -pääte (liekki-emojista on tullut myös suosittu silmäniskuna), mikä helpottaa niiden tunnistamista hybridiprojekteissa.
Pythonin yhteensopivuus ja ekosysteemi
Osa Mojon viehätyksestä on se, ettei se pakota sinua heittämään pois sitä, mitä sinulla jo on : sen yhteensopivuus Python-ekosysteemin kanssa tarkoittaa, että voit jatkaa kirjastojen, kuten NumPyn, Pandasin tai Matplotlibin, käyttöä ja samalla ottaa käyttöön tehokkaampia rakenteita ja tyyppejä, kun se sinulle sopii.
Käytännössä tämä ”Python++”-strategia tasoittaa käyttöönottokäyrää: ylläpidät koodikantaa , siirrät kuumat palaset Mojoon ja hyödynnät kääntäjää ja MLIR:ää suorituskyvyn parantamiseksi hylkäämättä tuttua syntaksia.
Modulaarinen: PyTorchin ja TensorFlow'n yhdistävä ajonaikainen ympäristö
Kieliversion lisäksi Modular on esitellyt yleismaailmallisen kehyksen/suoritusympäristön , joka pystyy ajamaan PyTorch- ja TensorFlow -malleja ilman molempien pinojen asentamista. Näiden lähteiden mukaan sen arkkitehtuuri voi nopeuttaa TensorFlow'n suoritusta jopa kolminkertaisesti ja PyTorchin suoritusta jopa 2,5-kertaisesti , samalla integroimalla kvantisointityökaluja , mikä edistää tekoälyn skaalautuvuutta.
Visiona on välttää "kolmikerroksinen" helvetti (Python → C/C++ → tietty laitteisto) yhdellä ohjelmointikerroksella ja taustajärjestelmällä, joka kommunikoi minkä tahansa laitteiston kanssa ja saa parhaan irti jokaisesta alustasta ilman, että mallia tarvitsee kirjoittaa uudelleen joka toinen päivä.
Kvantisointi: koon pienentäminen tarkkuudesta tinkimättä
Mallien kvantisointi on kuin neuroverkkojen MP3-tiedosto: tarkkuutta vähennetään tietyissä painoissa/kerroksissa, ja vastineeksi pienennetään kokoa ja nopeutetaan päättelyä. Tarkkuuden menetys on yleensä pieni (esimerkiksi luokittelijassa 94 prosentista 91 prosenttiin), ja käyttöönoton ja nopeuden parantuminen kompensoi sen moninkertaisesti.
Tämä lähestymistapa on avainasemassa mallien tuomisessa paikallisiin laitteisiin yksityisyyttä kunnioittaen. Itse asiassa pinot, kuten Core ML, ja kiihdyttimet, kuten Applen NPU:t (MPS/Acceleraten kautta), pyrkivät kohti pakattuja malleja, jotka sopivat ja toimivat sujuvasti iPhonella tai Macilla lähettämättä tietoja pilveen.
Swiftistä TensorFlow'lle Mojoon: Lattnerin matka
Polku tähän pisteeseen ei ole sattumaa. Applella vietettyään aikaa (LLVM, Clang, Swift ) Chris Lattner työskenteli Teslalla ja Google Brainilla, missä hän johti Swiftiä TensorFlow'lle . Tämä yritys yhdistää moderni ohjelmointikieli koneoppimiseen hyllytettiin, mutta se tuotti oppeja, jotka ovat nyt kiteytyneet MLIR:iin ja Mojon suunnitteluun.
Ennen Modularia Lattner kokeili myös RISC-V- maailmaa (SciFive), mikä sopii yhteen ajatuksen kanssa, että tekoälyn tulevaisuus sisältää monenlaisia laitteistoja ja tarvitsemme kääntäjiä ja suoritusympäristöjä, jotka pystyvät nopeasti mukautumaan niihin kaikkiin.
Projektin tila, tuki ja käyttöönotto
Mojo julkaistiin vuonna 2023, ja vaikka kieli kehittyy nopeasti, se on vielä kypsymisvaiheessa . Sen standardikirjasto avattiin helmikuussa 2025, mutta kääntäjä on edelleen suljettu . Suosioltaan (TIOBE-indeksi) Mojo sijoittuu 50 parhaan alle, mikä on odotettavissa vasta kaksi vuotta vanhalta kieleltä.
"Kuka kukin on" -osiossa on mainittu Amazonin, AMD:n, NVIDIAn ja Inworldin tuki . Silti Pythonin kanssa kilpaillakseen se tarvitsee yhteisön, dokumentaation, paketteja ja tuotannon menestystarinoita , jotka voivat toimia vertailukohtana muille.
Haasteet: yhteisöllisyys, reflektio ja dynaamiset ominaisuudet
Suorituskyvyn lisäksi Python voittaa yhteisön, resurssien ja ekosysteemin suhteen . Mojon on paikattava aukkoja alueilla, joilla Python on erinomainen, kuten tietyissä heijastusmekanismeissa tai laajalti käytetyissä dynaamisissa malleissa. Sen on myös jatkettava käyttäjäystävällisyyden parantamista, jotta siirtyminen Pythonista olisi täysin saumatonta.
Teknisestä näkökulmasta lupaus " kääntämisestä kaikelle " kuulostaa hyvältä, mutta jokaisella taustajärjestelmällä (CUDA, ROCm, MPS, TPU:t, FPGA:t…) on omat vivahteensa. Yhdenmukaisen toiminnallisuuden ja suorituskyvyn ylläpitäminen kaikissa niissä ajonaikana on maraton, ei sprintti.
Mojo ja näytönohjaimet: NVIDIAn tuolla puolen
Yksi Mojon ja MLIR:n vahvuuksista on niiden kyky kohdistaa tuki sekä NVIDIAn että AMD:n näytönohjaimille , ei vain CUDA-ekosysteemille. Jos tämä tuki pysyy ajan tasalla ja kilpailukykyisenä, monet yritykset näkevät strategisen edun siinä, etteivät ne ole sidottuja yhteen toimittajaan.
Samaan aikaan Applen maailma ( MPS:n avulla ) ja muut erikoistuneet kiihdyttimet (NPU:t, FPGA:t ) vaativat sopivia käännöspolkuja ja kirjastoja. "Kirjoita kerran, suorita nopeasti kaikkialla" -lupaus on kunnianhimoinen, ja oikein toteutettuna se mullistaisi kaiken.
Keskustelu: Uusi kieli vai ”Python++”?
Teknisillä foorumeilla keskustellaan siitä, onko Mojo "toinen Pythonin muunnelma" vai uusi kieli, joka jakaa vain syntaksin. Arkikäytössä ratkaisevaa on, että voit käyttää koodiasi ja kirjastojasi uudelleen samalla, kun kirjoitat suorituskykykomponentteja rikkaammilla tyypeillä ja rakenteilla.
Tämä kaksinaisuus yhdistettynä moderniin MLIR-kääntäjään tekee "hello world" -käyttöliittymästä käyttäjäystävällisen ja samalla mahdollistaa laskentaytimien lähestyä tai jopa ylittää C/C++:n suorituskyvyn vektorisoiduissa tilanteissa.
Resurssit, yhteisö ja oppiminen
Jos olet vasta aloittamassa tekoälyn parissa, avoimet oppimisyhteisöt ovat korvaamattomia. Nämä sekä opiskelijoille että opettajille suunnatut tilat tarjoavat mahdollisuuksia esittää kysymyksiä, jakaa resursseja ja edetä perusteista edistyneisiin tekniikoihin. Ne ovat loistavia paikkoja harjoitella, vertailla lähestymistapoja ja saada vastauksia tosielämän tilanteisiin.
Myös tiedotusverkosto auttaa: asiantuntijoiden, kuten Jeremy Howardin, laatimista Mojon julkaisuyhteenvedoista ilmaisiin Python-kursseihin videoalustoilla, joilla pääset koodaamaan ilmaiseksi. Mitä vahvempi yhteisö Mojon ympärillä on, sitä helpompi yritysten ja kehittäjien on omaksua se.
Käytännön vinkkejä ja mielenkiintoisia yksityiskohtia
Myös pienet, elämänlaatua parantavat yksityiskohdat painavat umpeen: .mojo- tiedostot , tuki fn / def- komennolle , suora suoritus mojo -komennolla tai nimenomainen tarkoitus tarjota helposti jaettavia binääritiedostoja . Ne ovat arkipäiväisiä asioita, mutta kun projekteja skaalataan, niillä on suuri merkitys.
Samaan aikaan on tunnustettava Rustin ja Swiftin vaikutus tyyppisuunnitteluun, muistin turvallisuuteen ja nollakustannusabstraktioihin . Tämä ei ole sattumaa: Lattner on Swiftin luoja ja LLVM/Clangin pilottijohtaja; tämä perintö näkyy kääntäjän suunnittelussa.
Laboratoriosta tuotantoon: mitä voit odottaa
Jos aiot kokeilla Mojoa tänään, on järkevää käyttää sitä vaikuttavissa moduuleissa (laskentaytimet, intensiiviset muunnokset tai tiukat silmukat). Pidä orkestrointi ja työkalut Pythonissa ja siirrä kysytyt komponentit Mojoon mitataksesi todellista hyötyä mittareissasi.
Analysoitujen raporttien mukaan Mandelbrot-tyyppiset tehtävät tai SIMD-ytimet ovat saavuttaneet valtavia kiihtyvyyksiä . Todellisissa prosessointiprosesseissa, joissa käytetään I/O:ta, esikäsittelyä ja kolmannen osapuolen kirjastoja, nähdään merkittäviä parannuksia, vaikkakin maltillisempia ja riippuvaisia vallitsevasta pullonkaulasta.
Yhtenäiset kerrokset: hyvästit "Frankenstackille"
Modulaarisen pinon keskeinen lupaus on kerrosten yhdistäminen: hajanaisten Python + C/C++ + tiettyjen taustajärjestelmien sijaan se tarjoaa yhden kielen kaikille kolmelle tasolle ja ajonaikaisen ympäristön, joka neuvottelee laitteiston kanssa . Vähemmän "liimaa", vähemmän yhteensopimattomuuksia ja vähemmän puolustavaa ylläpitoa.
Jos tämä visio toteutuu, koulutus- ja päättelyprosessit voivat siirtyä NVIDIAn, AMD:n, Apple Siliconin, TPU:iden tai NPU:iden välillä ilman, että projektia tarvitsee ohjelmoida kokonaan uudelleen. Ja tämä on enemmän kuin tekninen yksityiskohta, vaan liiketoimintastrategia : vapaus valita laitteisto kustannusten, saatavuuden tai energiatehokkuuden perusteella.
Huomautus äänimalleista ja transkriptiosta
Käytännön toteutuksissa, kun malleja, kuten Whisper (transkriptio), siirretään Pythonista natiiveihin reitteihin tai muihin API-rajapintoihin (MPS/Accelerate), ilmenee yhteensopimattomuuksia: tietyt käskyt ovat olemassa CUDAssa, mutta eivät MPS:ssä, tai päinvastoin. Tässä kohtaa yhtenäinen taustajärjestelmä ja MLIR:ää käyttävä kääntäjä voivat säästää paljon päänvaivaa.
Ilman tätä yhteistä liimaa päädytään koodin haaroihin ja manuaalisiin porttauksiin, jotka hidastavat projektin kehitystä. Sen avulla lupauksena on kirjoittaa vain kerran ja saada tehokas reititys kaikilla tuetuilla alustoilla.
”Meta”-konteksti: tiedotus, sponsorointi ja teknologiayhteisö
Osa tätä keskustelua ruokkivasta materiaalista on peräisin podcasteista ja teknisistä blogeista , jotka yhdistävät koulutussisältöä sponsorointiin ja yhteisöihin (jopa oheistuotteisiin). Anekdoottisten havaintojen (kurssit, sovellukset, Twitch, taustamusiikki, podcast-verkoston tuki...) lisäksi mielenkiintoista on, että tekninen keskustelu on laajentunut oman markkinarakonsa ulkopuolelle ja vetoaa laajaan yleisöön.
Tuo kohina on hyvästä: se tuo esiin vaikeita kysymyksiä, tosielämän käyttötapauksia ja kokemuksia erilaisista laitteistoista. Keskustelun laajentaminen MLIR:n ja Mojon suuntaan nopeuttaa virheiden havaitsemista, migraatio-oppaita ja reseptien luomista, joita voimme kaikki käyttää uudelleen.
Kokonaiskuva on selkeä: Python pysyy tekoälyn porttina , mutta käytännöllinen vaihtoehto on jo olemassa silloin, kun suorituskyky on ensiarvoisen tärkeää. Mojo ei pyri eliminoimaan Pythonia, vaan pikemminkin nostamaan sitä nykyaikaisella kääntäjällä , aidolla rinnakkaisuudella ja ajonaikaisella kerroksella, joka ymmärtää sekä nykypäivän että tulevaisuuden kiihdyttimiä. Jos työskentelet koneoppimisen/levinneisyyden parissa ja päättely- tai koulutusepookkikohtainen aika/kustannus on tärkeä, kannattaa kokeilla omilla tiedoilla ja laitteistolla.
