- Python доминира в областта на изкуствения интелект благодарение на своята екосистема, но GIL, динамичното типизиране и интерпретаторът възпрепятстват производителността.
- Mojo, базиран на MLIR, предлага компилация, истинска паралелизация и съвместимост с Python библиотеки.
- Модулната среда обединява времената за изпълнение на PyTorch и TensorFlow, с интегрирано ускорение и квантуване.
- Огромни ускорения (Манделброт, SIMD) са възможни; предизвикателството е това предимство да се приложи в производството и при множество хардуерни решения.
Дебатът за производителността между Mojo и Python е ожесточен, защото засяга същността на съвременния изкуствен интелект: реална скорост, лекота на използване и хардуерна поддръжка. През последните години се появиха данни за ускорение, които на хартия изглеждат като научна фантастика, но са подкрепени от дълбоки промени в компилаторите и в начина, по който кодът се изпълнява на процесори, графични процесори и ускорители на изкуствен интелект.
В тази статия сме съставили подробен преглед на всичко публикувано в различни източници за Python, неговите ограничения в производителността и подхода на Mojo , езикът, задвижван от Modular и ръководен от Крис Латнър (LLVM, Clang, Swift). Обясняваме също MLIR, причините за GIL затрудненията, разликите между CUDA и MPS, съвместимостта с екосистемата на Python и предизвикателствата пред приемането, които все още предстоят.
Python доминира в изкуствения интелект, но архитектурата му не помага за производителността
Не е изненадващо, че Python е универсалният език на изкуствения интелект : прост синтаксис, хиляди библиотеки, тонове уроци и огромна общност. Тази популярност обаче е съпроводена с една неудобна реалност: Python се интерпретира , типизира динамично и е обект на Global Interpreter Lock (GIL) , което ограничава едновременното изпълнение на чист Python код до една нишка.
Този дизайн позволява по-бърза разработка, но прави компромис със скоростта и ефективността на паметта в сравнение с компилирани езици като C/C++, Swift или Rust. При ML/DL натоварвания, където всяка милисекунда е от значение и хардуерът е изключително бърз, това наказание е изключително забележимо.
За да компенсира, екосистемата е прибягнала до заобиколни решения: NumPy (с части на C и Fortran), библиотеки, които делегират към native код , и C/C++ разширения за критични операции. Работи, да, но въвежда слоеве, зависимости и чудовище на Франкенщайн от версии, рамки и бекендове, които могат да бъдат трудни за поддръжка в продукция.
Освен това, паралелизмът в Python често разчита на многопроцесорност или на библиотеки, които пускат GIL в нативни секции. Резултатът е, че освен ако работното натоварване не е добре делегирано на C/C++ или GPU, суровата производителност на Python се превръща в пречка.
NumPy и други "пачове": от съществено значение, но с ограничения
NumPy е класическият пример: много от критичните му операции са написани на C или Fortran , което е значително по-бързо от чистия Python. Когато обаче става въпрос за фин паралелизъм, мащабиране до множество ядра или интеграция с нови ускорители, ограниченията на Python се появяват отново , особено ако потокът от контрол често се връща към интерпретатора.
Този многопластов подход (Python → C/C++ разширения → драйвери/хардуер) е ефективен, но сложен за дебъгване и внедряване . В ИИ в голям мащаб, с конвейери за обучение, извод и последваща обработка, тази оперативна сложност тежи почти толкова, колкото и наличните FLOPS.
CUDA, MPS и проблемът с преносимостта
CUDA ускорението (NVIDIA) е спасение, но и златна клетка: някои модели и оптимизации са изцяло зависими от стека на NVIDIA. Ако се опитате да изпълните същия код на Apple Silicon с Metal Performance Shaders (MPS) или на AMD графични процесори, може да се сблъскате с неподдържани инструкции или непълни изчислителни пътища.
Най-често срещаното сравнение е ясно: с CUDA карате „Ферари“, докато MPS може да се усеща като по-ограничен за определени натоварвания. Въпреки това индустрията се стреми към стандарти и преносимост, защото никой не иска да обвързва бизнеса си с един-единствен доставчик на хардуер, освен ако не е абсолютно необходимо.
MLIR: мостът, от който се нуждае новата ера на изчисленията
За да разберем какво предлага Mojo, трябва да поговорим за MLIR (Multi-Level Intermediate Representation - Многостепенно междинно представяне) , проект, роден в екосистемата на LLVM, който добавя междинно представяне, предназначено за висока производителност и машинно обучение . За разлика от класическия LLVM конвейер, MLIR обработва графи от данни, векторизация, теселация, вмъкване на DMA и изрично управление на кеша.
Казано по-просто: MLIR позволява трансформирането на код от високо ниво в имплементации, много близки до целевия хардуер (процесори, графични процесори, TPU, NPU, FPGA и др.), извличайки паралелизъм и прилагайки HPC оптимизации , които класическият компилатор не покриваше толкова добре за тези области.
Какво точно е Mojo?
Mojo е език, който се представя като надмножество на Python : той поддържа познат синтаксис, може да използва същите библиотеки и интегрира модерен модел на компилация, поддържан от MLIR. Стартира през 2023 г., първоначално като уеб площадка, достъпна при поискване, а по-късно с локално изпълнение на GNU/Linux и macOS. През февруари 2025 г. стандартната му библиотека е направена с отворен код, въпреки че компилаторът остава затворен и до днес.
Целта е амбициозна: простотата на Python с производителността на C/C++ , плюс сигурността и удобството за потребителя, които сме виждали в езици като Rust или Swift. С други думи, писане на високо ниво и създаване на малки, бързи и лесни за внедряване двоични файлове.
Дизайнерски ключове: писане, памет, структури и функции
Сред най-забележителните характеристики са силното типизиране (и статичното типизиране, когато е необходимо), използването на let/var за деклариране на непроменяеми и изменяеми елементи и поддръжката на структури с дефинирани при компилиране дизайни, които улесняват генерирането на оптимален машинен код.
Mojo ви позволява да декларирате функции с `fn` в допълнение към `def` ; най-общо казано, `fn` има тенденция да предполага повече ограничения и следователно по-добър потенциал за оптимизация за компилатора. Той също така се гордее с „абстракции с нулева цена“ и възможности за самонастройка , където компилаторът избира ефективни параметри за целевата платформа.
Без GIL и с реална паралелизация
За разлика от Python, Mojo не разчита на GIL . Runtime и компилаторът са проектирани да използват нишки, вектори и ускорители, без разработчикът да се налага да се бори с основната паралелност на интерпретатора. На практика това означава, че задачи, които в Python „се сблъскват“ с GIL, наистина могат да се изпълняват паралелно.
Този момент е ключов при интензивните изчисления: ако можете да разделите даден проблем на подзадачи и да ги изпълнявате едновременно по естествен начин, скокът в производителността не е постепенен, а промяна от порядъка на класата.
Производителност: от Манделброт до векторизирани версии
За измерване на подобренията, повтарящ се тест е множеството на Манделброт , изчислително интензивен фрактален генератор, идеален за паралелизация. С чист Python са съобщени времена над 1000 секунди , докато имплементациите в Mojo са спаднали до около 0,03 секунди след последователни оптимизации.
Документирани са прогресии от следния тип: наивна версия на Python → NumPy → наивна версия на Mojo → векторизиран Mojo със SIMD . С този конвейер от подобрения са наблюдавани огромни ускорения, вариращи от 35 000 пъти до отчетени цифри от 68 000 пъти в специфични сценарии. Това са впечатляващи числа, които, както винаги, зависят от алгоритъма, хардуера и грижата, която влагате в оптимизацията.
Лесно компилиране и внедряване
Mojo следва философията „сглобяване към двоичен файл“ : компилираш, получаваш изпълним файл и го разпространяваш . Ако идвате от Python, това избягва главоболията от виртуални среди , колела и комбинации от версии на библиотеки, които не винаги работят добре заедно.
За да ви дам представа, „Hello World“ може да се компилира и изпълни с простото mojo hello.mojo . Освен това, файловете имат разширение .mojo (емоджитото с пламъка стана популярно и като намигване), което ги прави по-лесни за разпознаване в хибридни проекти.
Съвместимост и екосистема на Python
Част от чара на Mojo е, че не ви принуждава да изхвърлите това, което вече имате : съвместимостта му с екосистемата на Python означава, че можете да продължите да използвате библиотеки като NumPy, Pandas или Matplotlib, като същевременно приемате по-ефективни структури и типове, когато ви е удобно.
На практика, тази стратегия „Python++“ изглажда кривата на приемане: вие поддържате кодовата си база , премествате горещи части в Mojo и използвате компилатора и MLIR, за да извлечете максимална производителност, без да се отказвате от синтаксиса, който познавате.
Модулна: среда за изпълнение, обединяваща PyTorch и TensorFlow
В допълнение към езика, Modular представи универсална рамка/време за изпълнение , способна да изпълнява модели на PyTorch и TensorFlow, без да е необходимо инсталирането и на двата стека. Според тези източници, архитектурата ѝ може да ускори изпълнението на TensorFlow до 3 пъти и на PyTorch до 2,5 пъти , като същевременно интегрира инструменти за квантуване , като по този начин допринася за мащабируемостта на изкуствения интелект.
Визията е да се избегне „трислойният“ ад (Python → C/C++ → специфичен хардуер) с един програмен слой и бекенд, който комуникира с всеки хардуер и извлича най-доброто от всяка платформа, без да се налага да пренаписвате модела си през ден.
Квантиране: намаляване на размера без жертване на точността
Квантоването на модели е като MP3 за невронни мрежи: намалявате точността в определени тегла/слоеве и в замяна намалявате размера и ускорявате извода. Загубата на точност обикновено е малка (например, от 94% на 91% в класификатор) и печалбата в разгръщането и скоростта повече от компенсира.
Този подход е ключов за пренасянето на модели до локални устройства , като същевременно се зачита поверителността. Всъщност, стекове като Core ML и ускорители като NPU на Apple (чрез MPS/Accelerate) се насочват към компресирани модели, които се побират и работят гладко на iPhone или Mac, без да изпращат данни в облака.
От Swift за TensorFlow до Mojo: Пътешествието на Латнър
Пътят до тази точка не е случаен. След времето си в Apple (LLVM, Clang, Swift ), Крис Латнър е работил в Tesla и Google Brain, където е ръководител на Swift за TensorFlow . Този опит за комбиниране на модерен език с машинно обучение е отложен, но той дава поуки, които сега са кристализирани в MLIR и дизайна на Mojo.
Преди Modular, Латнър се е занимавал и със света на RISC-V (SciFive), което се вписва в идеята, че бъдещето на изкуствения интелект включва много видове хардуер и се нуждаем от компилатори и среди за изпълнение, способни бързо да се адаптират към всички тях.
Състояние, подкрепа и приемане на проекта
Mojo беше пуснат през 2023 г. и въпреки че езикът се развива бързо, той все още е във фаза на съзряване . Стандартната му библиотека беше отворена през февруари 2025 г., но компилаторът остава затворен . По популярност (индекс TIOBE), Mojo се нарежда под топ 50, което е очаквано за език, който е само на две години.
В раздела „кой кой е“ е спомената подкрепата от Amazon, AMD, NVIDIA и Inworld . Въпреки това, за да се конкурира с Python, ще му е необходима общност, документация, пакети и истории за успех в производството , които могат да служат като еталон за другите.
Предизвикателства: общност, рефлексия и динамични характеристики
Освен производителността, Python печели по отношение на общността, ресурсите и екосистемата . Mojo ще трябва да запълни пропуските в области, където Python се отличава, като например определени механизми за рефлексия или широко използвани динамични модели. Също така ще трябва да продължи да усъвършенства своята удобство за потребителя, за да направи преходът от Python напълно безпроблемен.
От техническа гледна точка, обещанието за „ компилиране за всичко “ звучи страхотно, но всеки бекенд (CUDA, ROCm, MPS, TPU, FPGA...) има своите нюанси. Поддържането на постоянна функционалност и производителност във всички тях по време на изпълнение е маратон, а не спринт.
Mojo и графични процесори: Отвъд NVIDIA
Една от силните страни на Mojo и MLIR е способността им да се насочват към графични процесори както от NVIDIA, така и от AMD , а не само към екосистемата CUDA. Ако тази поддръжка остане актуална и конкурентна, много компании ще видят стратегическото предимство да не са обвързани с един-единствен доставчик.
В същото време, светът на Apple (с MPS ) и други специализирани ускорители (NPU, FPGA ) изискват подходящи пътища за компилация и библиотеки. Обещанието „пиши веднъж, изпълнявай бързо навсякъде“ е амбициозно и ако бъде изпълнено правилно, би променило играта.
Дебат: Нов език или „Python++“?
В техническите форуми се води дебат дали Mojo е „друг вариант на Python“ или нов език, който споделя само синтаксис. За ежедневна употреба най-важното е, че можете да използвате повторно кода и библиотеките си, като едновременно с това пишете компоненти за производителност с по-богати типове и структури.
Тази двойственост, комбинирана със съвременния MLIR компилатор, е това, което позволява „hello world“ да бъде лесен за използване, като същевременно позволява на вашите изчислителни ядра да се доближат или дори да надминат производителността на C/C++ във векторизирани сценарии.
Ресурси, общност и обучение
Ако тепърва започвате работа с изкуствен интелект, отворените учебни общности са безценни. Тези пространства, насочени както към ученици, така и към учители, предлагат възможности за задаване на въпроси, споделяне на ресурси и напредък от основите към напреднали техники. Те са фантастични места за практикуване, сравняване на подходи и получаване на отговори от реалния свят.
Екосистемата за работа с обществеността също помага: от обобщения на пускането на Mojo от експерти като Джереми Хауърд до безплатни курсове по Python на видео платформи, които ви помагат да програмирате безплатно. Колкото по-силна е общността около Mojo, толкова по-лесно ще бъде за компаниите и разработчиците да го възприемат.
Практически бележки и интересни подробности
Малки детайли, влияещи върху качеството на живот, също се натрупват: .mojo файлове , поддръжка за fn / def , директно изпълнение с командата mojo или изричното намерение да се предлагат лесни за разпространение двоични файлове . Това са банални неща, но когато мащабирате проекти, те правят цялата разлика.
В същото време, влиянието на Rust и Swift върху дизайна на типове, безопасността на паметта и абстракциите с нулева цена трябва да се признае . Това не е случайно: Латнър идва от създаването на Swift и пилотирането на LLVM/Clang; това наследство е очевидно в дизайна на компилатора.
От лабораторията до производството: какво можете да очаквате
Ако ще изпробвате Mojo днес, има смисъл да го използвате в модули с голямо въздействие (изчислителни ядра, интензивни трансформации или тесни цикли). Запазете оркестрацията и инструментариума си в Python и мигрирайте компонентите с голямо търсене към Mojo, за да измерите реалната полза във вашите показатели.
Според анализираните доклади, задачите от типа на Манделброт или SIMD ядрата са постигнали огромни ускорения . В реални конвейери, с I/O, предварителна обработка и библиотеки на трети страни, ще видите значителни подобрения, макар и по-скромни и зависими от доминиращото пречка.
Унифицирани слоеве: сбогом на „Франкенстака“
Ключово обещание на модулния стек е обединяването на слоевете: вместо разпръснати Python + C/C++ + специфични бекендове, той предлага един език за всичките три слоя и среда за изпълнение, която договаря с хардуера . По-малко „лепило“, по-малко несъвместимости и по-малко защитна поддръжка.
Ако тази визия се осъществи, процесите на обучение и извод могат да се движат между NVIDIA, AMD, Apple Silicon, TPU или NPU, без да се изисква пълно препрограмиране на проекта. И това, повече от технически детайл, е бизнес стратегия : свобода за избор на хардуер въз основа на цена, наличност или енергийна ефективност.
Бележка относно гласовите модели и транскрипцията
В реални реализации, при пренасяне на модели като Whisper (транскрипция) от Python към native маршрути или други API (MPS/Accelerate), възникват несъвместимости: определени инструкции съществуват в CUDA, но не и в MPS или обратното. Тук унифициран backend и компилатор с MLIR могат да ви спестят много главоболия.
Без това общо „лепило“, ще се сблъскате с разклонения на код и ръчни портове, които забавят еволюцията на проекта. С него обещанието е да се напише веднъж и да се получи ефективно маршрутизиране на всяка поддържана платформа.
„Мета“ контекст: работа с обществеността, спонсорства и технологичната общност
Част от материалите, подхранващи този дебат, идват от подкасти и технически блогове , които съчетават образователно съдържание със спонсорства и общности (дори мърчандайзинг). Отвъд анекдотичните (курсове, приложения, Twitch, фонова музика, поддръжка на мрежата от подкасти...), интересното е, че техническият дебат е излязъл извън своята ниша и резонира с широк кръг от аудитории.
Този шум е добър: той носи трудни въпроси, реални случаи на употреба и опит с разнообразен хардуер. Увеличаването на обхвата на разговора към MLIR и Mojo ускорява откриването на грешки, ръководствата за миграция и създаването на рецепти, които всички можем да използваме повторно.
Цялостната картина е ясна: Python ще остане вратата към изкуствения интелект, но вече съществува прагматична алтернатива, когато производителността е от първостепенно значение. Mojo не се стреми да елиминира Python, а по-скоро да го подобри с модерен компилатор , истинска паралелизация и слой за изпълнение, който разбира както днешните, така и утрешните ускорители. Ако работите с ML/DL и времето/цената на извод или епохата на обучение са от значение, струва си да опитате със собствените си данни и хардуер.
