Переоценённый король

Почему ИИ-индустрия платит «налог на Python» — и как быстрые компилируемые языки, в частности, Swift, открывают ей новые горизонты

Андрей Сапунов

Дисклеймер: это мнение автора. Автор — заинтересованная сторона: он ведёт открытый проект языковых моделей на Swift/MLX (swift-language-models) и написал книгу, весь код которой — на Swift. Читайте с поправкой на этот конфликт интересов. В качестве противовеса каждое число в статье снабжено ссылкой на первоисточник, а сильнейшим контраргументам отведён отдельный раздел 8.

Аннотация. Python — бесспорный лингва франка искусственного интеллекта: на нём написаны интерфейсы всех главных фреймворков, на нём учат, публикуют и прототипируют. Мы разбираем, как язык, уступающий C по скорости примерно в 70 раз, а по энергопотреблению — в 76 раз [14], оказался у руля самой вычислительно прожорливой индустрии в истории, и утверждаем три вещи. Во-первых, доминирование Python — результат сетевых эффектов экосистемы, а не технического превосходства: производительное ядро «питоновского» ИИ давно написано на C++, CUDA и Rust. Во-вторых, «налог на Python» реален и измерен — от микросекунд на диспатч оператора [24, 25] до трети вычислительного времени ML-флота Google, уходящей на входные пайплайны [26]. В-третьих, там, где рождаются новые горизонты ИИ — локальный инференс, edge, on-device-модели, — индустрия уже тихо голосует ногами: llama.cpp [31], MLX [43], ExecuTorch [34]. Особое внимание мы уделяем Swift — компилируемому языку с «питоновской» читаемостью, скоростью в разы, а не в десятки раз отличимой от C [14], и живой ML-экосистемой (MLX Swift, Foundation Models, differentiable Swift). Спор, как обычно, не «Python против Swift», а «привычка против понимания».

Ключевые слова: Python, Swift, машинное обучение, LLM, энергоэффективность, компилируемые языки, проблема двух языков, on-device AI, MLX.

«Python is not designed to be fast, and it is not designed to be safe» — «Python не проектировался быстрым и не проектировался безопасным». — Джереми Ховард, сооснователь fast.ai [37]

Эта статья — о самом странном компромиссе современной инженерии: индустрия, которая считает быстрее всех в истории человечества, дирижирует этими вычислениями на одном из самых медленных языков в истории программирования. И о том, что произойдёт, когда мы перестанем считать это законом природы.

---

1. Введение: странность, к которой все привыкли

Начнём со сцены, которая повторяется каждый день в тысячах компаний.

Дата-центр. Стойки с ускорителями, каждый из которых выполняет сотни триллионов операций в секунду. Электрическая мощность — как у небольшого города: в 2024 году дата-центры мира съели около 415 ТВт·ч, к 2030-му Международное энергетическое агентство ждёт примерно 945 ТВт·ч — больше, чем сегодня потребляет вся Япония, и главный драйвер этого роста — ИИ [48]. Инженеры, которые всем этим управляют, — возможно, самые высокооплачиваемые программисты планеты.

А теперь заглянем в их код. Он написан на языке, который в классическом исследовании энергоэффективности 27 языков занял 26-е место [14]. На языке, который до октября 2025 года в принципе не умел исполнять байткод в два потока одновременно [20]. На языке, создатель которого честно называл его «клеем» для чужих быстрых компонентов [1].

⚠️ Частая ошибка восприятия. «Раз весь ИИ написан на Python — значит, Python технически лучше всего подходит для ИИ». Это совсем не так, и дальше мы покажем, почему. Python подходит для ИИ исторически и социально: у него была готовая научная экосистема и низкий порог входа. Технически же вся индустрия устроена как матрёшка: снаружи Python, внутри C++ и CUDA. Вопрос статьи — что мы платим за эту матрёшку и что будет, если её раскрыть.

Давайте сразу договоримся о честности — это важнее всего. Мы не будем утверждать, что Python плох: это выдающийся язык с заслуженной победой. Мы не будем предлагать «переписать всё на Swift к пятнице»: так не бывает, и попытки уже проваливались — мы честно разберём, как именно. Мы будем утверждать три вещи, каждая из которых опирается на проверяемые числа:

1. Доминирование Python — это сложившаяся монополия привычки, а не закон природы. Король правит заслуженно, но корона держится на сетевых эффектах, а не на физике.

2. «Налог на Python» реален, измерим и растёт вместе с масштабом индустрии. Его платят микросекундами диспатча, гигаваттами электричества и удвоением инженерного труда.

3. На новых территориях ИИ — локальных, мобильных, энергоэффективных — выбор уже происходит, и происходит не в пользу Python. Swift — один из самых недооценённых кандидатов на роль языка, который закроет разрыв.

---

2. Как Python стал королём (и почему это было заслуженно)

Отдадим королю должное — без этого раздел о его переоценённости был бы дешёвым.

Победа Python в машинном обучении не была случайной. Она была спланирована — причём самим создателем языка. Ещё в январе 1998 года Гвидо ван Россум в позиционной статье «Glue It All Together With Python» описал модель разработки, которую мы сегодня знаем как NumPy и PyTorch: пусть C/C+±программисты пишут эффективные вычислительные компоненты, а учёные «склеивают» их скриптами на Python [1]. Это не пост-фактум оправдание медлительности — это была стратегия, и она сработала блестяще.

К моменту, когда грянул бум глубокого обучения, Python уже полтора десятилетия обрастал научным стеком: Numeric — 1995, SciPy и IPython — 2001, NumPy — 2005–2006, pandas — 2008, scikit-learn — первый релиз в 2010 [2]. Когда в 2015 году Google открыла TensorFlow, а в 2016-м Facebook — PyTorch, выбор фронтенд-языка был очевиден: учёные уже жили в Python. Дальше сетевой эффект замкнулся сам на себя: NumPy оказался в программном стеке открытия гравитационных волн и первого изображения чёрной дыры [3], каждый учебник и каждый курс писались на Python, каждый новый инженер учил его первым.

Числа доминирования впечатляют:

Против этого бессмысленно спорить — и мы не будем. Заметим лишь две трещины в мраморе. Первая: пик, похоже, пройден — с рекордных 26,98 % в июле 2025 года индекс TIOBE к середине 2026-го сполз к ~19 % (Python всё ещё №1, но отрыв тает) [6], а в Octoverse 2025 на первое место по числу контрибьюторов вышел TypeScript [5]. Вторая трещина интереснее, и ей посвящён следующий раздел.

📜 Из истории: «второй лучший язык для всего». В питон-сообществе давно ходит самоироничная формула, приписываемая Вану Линдбергу: «Python — второй лучший язык для любой задачи». Это комплимент: универсальность побеждает специализацию, потому что цена переключения между нишами — нулевая. Но у комплимента есть обратная сторона, о которой реже говорят вслух: если для каждой задачи существует язык лучше, то по мере роста цены задачи — в деньгах, ваттах и миллисекундах — рано или поздно наступает момент, когда «второй лучший» перестаёт быть достаточным. ИИ-индустрия, как мы увидим, к этому моменту уже подошла.

---

3. Секрет короля: Python в ИИ — это не Python

Приготовьтесь, сейчас будет разочаровывающе просто.

Откройте репозиторий PyTorch — главного инструмента современного ИИ — и посмотрите на официальную статистику языков. Python там — лишь 64 % кодовой базы. Остальное — C++ (28,4 %), CUDA (2,6 %), C, Objective-C++, Metal, ассемблер [9]. Всё производительное ядро eager-режима — тензорная библиотека ATen, ядра CUDA — написано на C++. У NumPy картина та же: 61 % Python, 33 % C. Иными словами, «библиотеки Python для машинного обучения» — это библиотеки на C++, у которых Python — вежливый администратор на ресепшене.

🧪 Попробуйте сами (прямо сейчас): откройте github.com/pytorch/pytorch и кликните на цветную полоску языков под списком файлов. Затем сделайте то же с ollama/ollama (Go) и ggml-org/llama.cpp (C/C++). Три самых популярных инструмента эпохи ИИ — и ни в одном из них производительная часть не написана на Python. Это займёт две минуты и заменит десять абзацев наших уверений.

У этого устройства мира есть имя — проблема двух языков (two-language problem). Канонически её сформулировали создатели Julia: сначала в манифесте 2012 года («мы хотим скорость C с динамизмом Ruby» [10]), затем в программной статье в SIAM Review, где среди «законов природы», которые они отказались принимать, значился и такой: «прототипируй на одном языке, потом переписывай на другом ради скорости или продакшена» [11].

Посмотрим, как этот «закон» выглядит в 2026 году:

• Исследователь пишет модель на Python.

• Скорость обеспечивают ядра на C++/CUDA, которые писали другие люди на другом языке.

• Для продакшена модель конвертируют в третью среду — C+±рантайм, GGUF, Core ML.

• Когда что-то тормозит на стыке (а тормозит регулярно — см. раздел 5), чинить это может только инженер, владеющий обоими мирами.

📐 Аналогия. Python в ИИ — это дирижёр оркестра. Дирижёр не играет ни на одном инструменте, и это нормально: его дело — взмахи палочкой, играет оркестр (C++ и CUDA). Аналогия точна и в другом, о чём реже вспоминают: если дирижёр показывает жесты вдесятеро медленнее, чем оркестр способен играть, — оркестр начинает ждать палочку. Дорогущие музыканты сидят и смотрят на дирижёра. Дальше мы покажем, что это не метафора, а профилировка: у неоптимизированных LLM-движков до половины времени уходило именно на «взмахи» [30].

Важно понимать: эта конструкция — не заговор и не глупость. Это рациональный компромисс своей эпохи. Но у него есть цена, и она поддаётся измерению.

---

4. Цена привычки: измеряем налог

4.1. Сколько стоит интерпретатор

Самое цитируемое измерение — работа Перейры и коллег «Energy Efficiency across Programming Languages» (SLE 2017): 27 языков, 10 задач из Computer Language Benchmarks Game, замеры энергии, времени и памяти [14]. Нормировав всё к C (1,00), авторы получили таблицу, которую стоит повесить на стену каждого, кто произносит слова «энергетический кризис ИИ»:

Python — 26-е место из 27 по энергии (спасибо Perl, прикрывшему тыл). В среднем по исследованию компилируемые языки тратили на задачу 120 Дж, интерпретируемые — 2365 Дж: разрыв примерно в 20 раз [14]. Расширенная журнальная версия 2021 года подтвердила выводы [15].

Разрыв между Python и Swift — тема этой статьи — составляет ~27 раз по энергии и ~17 раз по времени.

Рис. 1. Нормированное энергопотребление языков (C = 1,00), логарифмическая шкала. Данные: Pereira et al., SLE’17, таблица 4 [14].

⚠️ Две честные оговорки (куда же без них). Во-первых, замеры 2017 года: Swift там был версии 3.x, а Python с тех пор ускорился (об этом ниже — спойлер: не в 70 раз). Во-вторых, свежая работа ван Кемпена и коллег (ASE 2025) нашла у методологии Перейры изъяны и показала: энергопотребление языка почти полностью объясняется временем исполнения — «энергоэффективных» языков не существует отдельно от «быстрых» [16]. Заметьте: это уточнение не спасает Python. Оно лишь сводит два его провала к одному — времени. На актуальных замерах Benchmarks Game лучшая Python-программа решает задачу n-body за ~6 минут против 2,10 с у C и 5,45 с у Swift (~170× и ~66×); на spectral-norm — 90,4 с против 0,40 с у C и 1,45 с у Swift (~226× и ~62×) [17, 18]. Да, лучшие C-версии там используют ручные SIMD-интринсики — но Swift-версии обходятся без ассемблерной магии.

Рис. 2. Время лучших программ на задачах n-body и spectral-norm (Computer Language Benchmarks Game, середина 2026), логарифмическая шкала [17, 18].

4.2. GIL: тридцать лет одиночества (одного потока)

Вторая статья налога — параллелизм. GIL (Global Interpreter Lock), появившийся в 1992 году, разрешает исполнять байткод Python только одному потоку за раз. Тридцать с лишним лет язык главной индустрии параллельных вычислений не умел параллельность на уровне ядер CPU.

Справедливости ради: лёд тронулся. В Python 3.13 (октябрь 2024) появилась экспериментальная сборка без GIL — ценой ~40 % замедления однопоточного кода [19]. В Python 3.14 (октябрь 2025) она стала официально поддерживаемой, штраф снизился до 5–10 % [20]. Но по плану PEP 703 это лишь фаза 2 из 3: сборкой по умолчанию free-threading так и не стал, и весь мир по-прежнему качает Python с GIL.

4.3. «Мы ускорим CPython в пять раз»

Может, подождать — и Python сам станет быстрым? Эту гипотезу индустрия проверила на себе, с бюджетом Microsoft.

В 2021 году по инициативе Гвидо ван Россума в Microsoft собралась команда Faster CPython; «план Шеннона» обещал ускорение примерно в 5 раз за четыре релиза. Результат: Python 3.11 дал в среднем +25 %, 3.12 — ~5 %, новый tail-call-интерпретатор в 3.14 — ещё 3–5 %. Итог подвёл участник команды Кен Джин: Python 3.14 быстрее 3.10 «примерно на 20–40 %» — в 1,2–1,4 раза вместо пяти [21]. А в мае 2025 года Microsoft уволила большую часть команды, включая техлида Марка Шеннона, и проект перешёл на «общественное попечительство» [21].

💡 Главная мысль раздела. Сорокакратный разрыв не закрывается героическими двадцатью процентами. Это не упрёк инженерам CPython — они сделали блестящую работу. Это свойство самой задачи: динамический интерпретируемый язык по построению платит за каждую операцию проверками типов, поиском атрибутов и диспатчем, которые компилируемый язык оплачивает один раз — во время компиляции. Вызов пустой функции в CPython стоит ~37 нс; в компилируемом языке он либо стоит наносекунды, либо инлайнится в ноль.

---

5. «Но ведь всё считает GPU!» — когда это правда, а когда нет

Это сильнейший контраргумент, и разобрать его нужно без соломенных чучел. Звучит он так: Python — лишь оркестратор; 99 % времени работают CUDA-ядра, так что хоть на Бейсике пишите.

Когда модель большая, а батч жирный — это чистая правда. Асинхронный диспатч прячет питоновские накладные расходы: пока GPU минуту перемалывает матрицы, Python успевает неторопливо подготовить следующую команду. Документация JAX прямо описывает этот механизм — и Патрик Киджер метко формулирует итог: JAX использует Python как метаязык, на котором вы пишете программу для настоящего исполнителя — компилятора XLA [12, 13].

Проблема в том, что граница «когда это правда» стремительно сужается, и вот измерения:

• Запуск одного CUDA-ядра стоит микросекунды хост-времени: в классическом примере NVIDIA ядро исполняется 2,9 мкс, а с запуском и синхронизацией выходит 9,6 мкс — накладные расходы больше полезной работы [24]. GPU за шесть лет стали в ~15 раз быстрее по вычислениям [22] — а CPU и Python остались прежними. Ножницы расходятся с каждым поколением железа.

• PyTorch eager на мелких тензорах выдаёт лишь ~280 тыс. операций в секунду — примерно в сто раз меньше, чем тот же цикл в голом Python без тензоров: почти всё съедает диспатч фреймворка [25].

• Данные. Анализ миллионов ML-задач в инфраструктуре Google (VLDB 2021): 30 % всего вычислительного времени уходит на входной пайплайн — чтение, декодирование, аугментации, — а 20 % задач тратят на это больше трети времени [26]. Проект FFCV показал, что со стандартным питоновским загрузчиком «идеализированное» время обучения почти в 30 раз меньше времени, нужного просто на обработку картинок [27].

• LLM-сервинг. Показателен сам состав движков: в оригинальной статье vLLM авторы описывают систему как «8,5 тыс. строк Python и 2 тыс. строк C++/CUDA», где выигрыш в 2–4× по пропускной способности обеспечили именно кастомные CUDA-ядра и управление памятью [28]. Авторы SGLang пишут: неоптимизированный inference-движок может тратить до половины времени на CPU-оверхед — планирование батчей, аллокации, префикс-матчинг [30]. Команда vLLM, переписывая архитектуру в V1, называла цель прямо — почти нулевой CPU-оверхед: шаг генерации Llama-8B на H100 занимает ~5 мс, и питоновские подсистемы просто не успевают за GPU; результат — до 1,7× к пропускной способности [29].

Но самое красноречивое признание сделали сами создатели PyTorch. Анонс PyTorch 2.0 начинается словами: «С первого дня мы знали пределы производительности eager-исполнения» — и объясняет, что существенные части PyTorch пришлось переносить в C++, отдаляя его от «хакабельности» [22]. Ответом стал torch.compile: перехват питоновского байткода и компиляция в Triton и C++ — geomean-ускорение 2,27× на инференсе и 1,41× на обучении на A100 по 180+ реальным моделям (ASPLOS 2024) [23].

💡 Главная мысль раздела. Обратите внимание на паттерн: каждый раз, когда «Python-стек» ускоряют, ускорение состоит в том, что Python откуда-то убирают. Из math-ядер (C++/CUDA), из загрузки данных (tf.data, DALI, FFCV), из планировщика сервинга (vLLM V1, SGLang), из самого исполнения модели (torch.compile превращает ваш Python в не-Python). Синтаксис остаётся — семантика исполнения уходит. Король правит, но уже не управляет.

---

6. Индустрия уже голосует ногами

Теперь посмотрим не на бенчмарки, а на поведение — чем индустрия пользуется, когда производительность из «приятно» превращается в «обязательно».

llama.cpp. В марте 2023 года Георгий Герганов выложил движок LLM-инференса на чистом C/C++ — без Python в рантайме вовсе. К июлю 2026-го — 119 тыс. звёзд GitHub и статус фундамента всей экосистемы локального ИИ: на нём работают Ollama (175 тыс. звёзд — больше, чем у самого PyTorch; сам Ollama написан на Go), LM Studio и десятки других инструментов, а формат GGUF стал отраслевым стандартом — только на Hugging Face Hub около 45 тыс. GGUF-чекпоинтов [31, 32]. В феврале 2026 года Hugging Face — сердце питоновской ML-экосистемы — присоединил команду Герганова, назвав llama.cpp «фундаментальным строительным блоком локального инференса» [31].

Rust внутри Python-мира. Тот же Hugging Face системно переписывает собственную инфраструктуру на Rust: токенизатор tokenizers (гигабайт текста менее чем за 20 секунд [33]), формат safetensors, фреймворк candle. Пользователь Python этого не видит — и в этом весь пуант: чтобы Python оставался быстрым, его внутренности делают не-питоновскими.

Apple MLX. Свой ML-фреймворк для Apple Silicon компания построила с ядром на C++ и API на четырёх языках, где Swift — полноправный гражданин. Формулировка инженеров Apple в анонсе MLX Swift заслуживает цитаты: Swift «сочетает простоту использования и высокоуровневый синтаксис языка вроде Python со скоростью компилируемого языка вроде C++» [43].

Edge. ExecuTorch 1.0 — рантайм PyTorch для устройств — это «лёгкий C+±рантайм» с базовым размером 50 КБ, обслуживающий, по заявлению проекта, миллиарды пользователей Meta [34]. На микроконтроллере Python не живёт — и никогда не жил.

Mojo. Крис Латтнер — создатель LLVM и Swift — считает проблему настолько реальной, что строит под неё целый язык: питоновский синтаксис поверх компилятора уровня MLIR, с демонстрациями ускорения Мандельброта до 68 847× относительно CPython (после типизации, векторизации и распараллеливания на 88 ядрах — спортивный результат, но показательный) [35]. К маю 2026-го Mojo дошёл до беты 1.0; компилятор пока закрыт [36].

Честности ради: Swift в этом движении не одинок и не первый. У альтернатив есть настоящие козыри. Rust — чемпион таблицы Перейры среди языков с гарантиями безопасности (1,03× к C [14]): память без сборщика мусора и без сегфолтов — ровно то, что нужно инфраструктуре, и не случайно Hugging Face строит на нём tokenizers, safetensors и candle, а фреймворк Burn доказывает, что полный ML-стек на Rust возможен. JAX — самая элегантная реализация идеи «Python как метаязык»: композиция jit/grad/vmap поверх компилятора XLA даёт исследовательскому коду краткость и скорость одновременно [13]. Mojo бьёт в самое сердце проблемы — компилируемый язык для питонистов без переучивания, — и за ним стоит человек, уже дважды построивший индустриальные компиляторные экосистемы [35].

Почему же статья ставит именно на Swift? Из-за сочетания, которого пока нет у других. Rust блистателен, но borrow checker и кривая обучения — противоположность «читается как псевдокод»; JAX остаётся Python-фронтендом со всеми последствиями для деплоя; Mojo — всё ещё бета с закрытым компилятором [36]. Swift единственный уже сегодня совмещает зрелый промышленный тулчейн, синтаксис уровня «почти Python», скорость компилируемого языка и системную нишу on-device, где за ним стоит целая платформа. Впрочем, для главного тезиса статьи этот спор вторичен: победа любого из четырёх — поражение проблемы двух языков.

📐 Аналогия. Представьте город, где официальный язык — один, но все машинные отделения — электростанции, водоканал, метро — по факту говорят на другом. Именно так выглядит стек ИИ в 2026 году: наверху Python, в машинном отделении C++, CUDA, Rust, Go, Swift. Спор «нужен ли компилируемый язык в ИИ» закрыт самой практикой: он уже там. Открытый вопрос звучит иначе — обязан ли человек писать на двух языках, или один язык может пройти весь путь от идеи до машинного отделения?

---

7. Кандидат Swift: скорость C, синтаксис почти Python

Вот мы и добрались до второй части тезиса. Почему именно Swift? Разберём по пунктам — с числами, а где чисел нет, честно скажем, что их нет.

7.1. Скорость и энергия

В таблице Перейры Swift — 2,79× по энергии и 4,20× по времени против C [14]; напомним, у Python — 75,88× и 71,90×. На актуальных числовых задачах Benchmarks Game лучшие Swift-программы идут вровень с C (n-body: 5,45 с против 2,10 с; на fannkuch-redux — практически паритет), проседая на строковых задачах [17, 18]. Swift компилируется через LLVM в машинный код; здесь нет ни интерпретатора, ни JIT-прогрева.

Память управляется через ARC (automatic reference counting) — подсчёт ссылок на этапе компиляции вместо трассирующего сборщика мусора. Это не только про скорость, но и про предсказуемость: нет GC-пауз. Насколько это важно в проде, Apple показала на собственном сервисе Password Monitoring, переписанном с Java на серверный Swift: +40 % пропускной способности, латентность <1 мс для 99,9 % запросов при миллиардах запросов в день, память на инстанс упала с десятков гигабайт до сотен мегабайт, высвободив около половины Kubernetes-мощностей [42].

А там, где Python страдал от GIL, Swift 6 пошёл в противоположную сторону: режим strict concurrency, при котором гонки данных диагностируются на этапе компиляции как ошибки [44]. Почувствуйте контраст: один язык тридцать с лишним лет сериализовал потоки глобальной блокировкой, другой — статически доказывает, что ваш параллельный код корректен, до первого запуска.

7.2. Синтаксис: найдите десять отличий

«Компилируемый — значит многословный и страшный»? Вот механизм внимания — сердце трансформера — на обоих языках:

# Python (NumPy-стиль)def attention(q, k, v):    scores = q @ k.T / math.sqrt(k.shape[-1])    return softmax(scores) @ v

// Swift (MLX)func attention(_ q: MLXArray, _ k: MLXArray, _ v: MLXArray) -> MLXArray {    let scores = q.matmul(k.T) / sqrt(Float(k.dim(-1)))    return softmax(scores, axis: -1).matmul(v)}

Разница — сигнатура с типами. Но это не налог, а подарок: компилятор теперь знает, что здесь тензоры, и не даст случайно передать номер токена туда, где ждали вероятность. Типы — это комментарии, которые не устаревают и проверяются машиной.

🧪 Попробуйте сами. Если у вас Mac — компилятор Swift уже установлен, из коробки. Сохраните пару строк в hello.swift, выполните swift hello.swift — и вы уже пишете на компилируемом языке с REPL-лёгкостью скрипта. Готовые, построчно разобранные реализации языковых моделей на Swift — от n-грамм до мини-GPT на MLX — лежат в открытом репозитории github.com/asaptf/swift-language-models: клонируйте и запускайте.

7.3. Урок Swift for TensorFlow: некролог или пролог?

Здесь обязан прозвучать самый неудобный для нашего тезиса факт, и мы приведём его сами: Google уже пыталась сделать Swift языком машинного обучения — и не смогла.

📜 Из истории. Проект Swift for TensorFlow анонсировали в марте 2018 года; вёл его Крис Латтнер, создатель Swift и LLVM. Идея была радикальной: встроить дифференцируемое программирование — автоматическое вычисление градиентов — прямо в компилятор языка общего назначения [38]. Джереми Ховард из fast.ai назвал это «первой серьёзной попыткой, которую я видел, встроить дифференцируемое программирование в самое сердце широко используемого языка, спроектированного с нуля ради производительности», и перевёл часть своего знаменитого курса на Swift [37]. Латтнер ушёл из Google в январе 2020-го; в феврале 2021-го проект отправили в архив [39]. Причина смерти — не техника, а экосистемный разрыв: переписать NumPy-вселенную с нуля не смог даже Google.

Так некролог или пролог? Три обстоятельства говорят за второе.

Во-первых, наследие S4TF не умерло: поддержка автодифференцирования осталась в основном компиляторе Swift как экспериментальная фича, и её развивает индустрия. Компания PassiveLogic строит на differentiable Swift автономные системы управления зданиями и публикует замеры: физическая симуляция теплопередачи на CPU — ~0,03 мс на цикл forward+backward против 8,16 мс у PyTorch (238×) и 11,0 мс у TensorFlow (322×) [40]; в 2024-м они же заявили рекорд энергоэффективности автодиффа — 34 Дж/GOps против десятков тысяч у больших фреймворков [41]. Оговорка честности: это CPU-класс задач с мелкими нерегулярными вычислениями — то есть ровно та территория, где питоновский диспатч убийственен, — и замеры самой компании.

Во-вторых, изменился контекст. В 2018-м Swift в ML был чужаком без железа и без ниши. В 2026-м у него есть и то и другое: вся линейка Apple Silicon с единой памятью, MLX с полноценным Swift API [43], swift-transformers 1.0 от Hugging Face [47] и Foundation Models framework — представленный на WWDC 2025 системный Swift API к on-device LLM, где макрос @Generable гарантирует структурно корректный вывод модели прямо в Swift-типы через constrained decoding [45]. Обратите внимание, чего здесь нет: Python-прослойки. Модель на 3 млрд параметров, квантованная в 2 бита, работает в кармане — и разговаривает с ней Swift напрямую.

В-третьих, сам Swift перестал быть «языком только для Apple»: официальная поддержка Linux и Windows, рабочая группа по Android (2025), Embedded Swift для микроконтроллеров, глубокий C+±interop [44].

💡 Главная мысль раздела. S4TF провалился, штурмуя крепость Python в лоб — на территории серверного обучения, где экосистемный перевес Python абсолютен. Новая партия разыгрывается на другой доске: on-device, edge, локальный инференс — территории, где у Python нет армии, потому что там в принципе нет его рантайма. Именно там компилируемый язык с питоновской читаемостью — не «альтернатива», а кратчайший путь.

---

8. Честные контраргументы (и что они на самом деле доказывают)

Научная добросовестность требует дать слово обвинению — то есть защите Python. Вот четыре сильнейших аргумента и наши ответы.

«Экосистема решает, и она у Python». Правда. 582 тысячи новых ИИ-репозиториев за год [5], каждый учебник, каждая вакансия. Ответ: мы и не предлагаем битву за серверное обучение — там Python останется надолго, и это нормально. Тезис в другом: новые ниши (см. раздел 9) свободны от этого сетевого эффекта, и там выбор языка снова открыт. А внутри самой цитадели производительный код уже не питоновский — спор идёт лишь о том, на каком языке написана витрина.

«Julia уже пробовала — и где она?» Урок Julia реален: скорость языка не побеждает качество экосистемы (Киджер описывает уход с Julia после месяцев борьбы с некорректными градиентами [12]). Но заметьте, что именно доказывает этот урок: технически быстрых языков достаточно, дефицит — в инженерной зрелости и спонсоре. У Swift спонсор — компания с капитализацией в триллионы, которой on-device ИИ нужен экзистенциально, плюс живой промышленный тулчейн и миллионы разработчиков. Это не гарантия — это отличие.

«Python тоже ускоряется: free-threading, JIT, torch.compile». Ускоряется — и мы честно привели числа: +20–40 % за пять релизов [21], free-threading со штрафом 5–10 % [20], torch.compile 2,27× [23]. Но вчитайтесь в структуру этих побед: free-threading чинит то, чего в компилируемых языках не было никогда; torch.compile ускоряет Python, переставая его исполнять. Это блестящая инженерия, укрепляющая наш тезис: будущее производительности Python — в том, чтобы Python не исполнялся.

«Оверхед — копейки на фоне GPU». Уже разобрано в разделе 5 с числами; добавим экономику масштаба. ChatGPT обрабатывает 2,5+ млрд запросов в день [55]; по оценке Сэма Альтмана, средний запрос стоит 0,34 Вт·ч [54] (методика не раскрыта — держим скепсис). Перемножение даёт ~0,31 ТВт·ч в год на одни лишь ответы одного продукта. При таких объёмах даже 5–10 % программного оверхеда — это 15–31 ГВт·ч ежегодно, годовое потребление небольшого города. «Копейки» перестали быть копейками, когда счётчик закрутился в миллиардах.

⚠️ Оговорка, которую вы не ждали от этой статьи. Энергоэффективность ИИ на единицу задачи улучшается — по оценке IEA, темпами, «беспрецедентными в истории энергетики» [49]. К громким цифрам об энергии ИИ вообще стоит относиться трезво: знаменитая оценка углеродного следа обучения из работы Струбелл и коллег [52] позже была скорректирована инженерами Google в 18–88 раз в меньшую сторону [53] — урок осторожности, который мы стараемся усвоить. Наш аргумент не в том, что ИИ погубит энергосистему и только Swift её спасёт. Он скромнее и твёрже: когда инференс — это до 90 % стоимости ML-нагрузки (AWS [50]) и ~3/5 её энергии (Google [51]), программные накладные расходы перестают быть вопросом вкуса и становятся статьёй бюджета. Инженерная культура, которая тюнит ядра до микросекунд, но пожимает плечами на 70-кратный разрыв в языке оркестрации, — просто ещё не пересчитала свои привычки в мегаватты.

---

9. Новые горизонты: что открывается за пределами Python

Всё сказанное было бы просто ворчанием на успешный язык, если бы не главное: самые интересные территории ближайших лет лежат там, куда Python физически не дотягивается.

Горизонт 1: ИИ в кармане. Модель Apple Intelligence на ~3 млрд параметров генерирует 30 токенов в секунду прямо на iPhone — офлайн, приватно, бесплатно [46]; третье поколение (июнь 2026) добавило разреженную модель на 20 млрд параметров [56]. Здесь нет и не будет CPython: бюджеты батареи, памяти и латентности оставляют место только компилируемому стеку. Весь этот мир программируется из Swift — включая гарантированно типизированный вывод LLM через @Generable [45].

Горизонт 2: локальный и серверный инференс. Экосистема llama.cpp/GGUF уже показала, что инференс-движку Python не нужен [31]. Серверный Swift с ARC без GC-пауз — готовый кандидат на API-слой того же класса задач, что Apple закрыла в Password Monitoring [42]. Всё чаще узкое место — не матрица на GPU, а оркестрация вокруг неё: агентные циклы, вызовы инструментов, миллионы мелких решений на CPU. Это ровно та территория, где интерпретатор проигрывает компилятору с разгромным счётом.

Горизонт 3: конец проблемы двух языков. Самый глубокий сдвиг — методологический. Сегодняшний путь «прототип на Python → переписывание на C++ → конвертация для устройства» — это удвоение труда и стен между командами. Язык с читаемостью прототипа и скоростью продакшена позволяет одному человеку пройти путь от идеи до устройства — как Julia мечтала в 2012-м [10], как S4TF попытался в 2018-м [38], и как Swift-стек — MLX, differentiable Swift, Foundation Models — впервые позволяет в естественной для себя нише уже сейчас. Способность прочитать и написать весь стек сверху донизу — это не только скорость. Это понимание вместо заклинаний.

📐 Аналогия напоследок. Экосистема Python похожа на imperial units — футы и фунты: исторически заслуженные, вросшие в инфраструктуру, поддержанные привычкой сотен миллионов людей. Жить с ними можно (Америка живёт). Но каждый новый расчёт требует коэффициентов пересчёта, каждый стык систем — источник ошибок, и время от времени об этом разбивается марсианский зонд. Никто не отменит футы указом — но каждый новый мост инженеры молча проектируют в метрах.

---

10. Что мы поняли

• Python победил заслуженно — стратегией «клея» [1], форой научной экосистемы и сетевыми эффектами. Спорить с этим бессмысленно; понимать это — обязательно.

• Python в ИИ — это витрина, а не двигатель: 36 % кодовой базы PyTorch — компилируемые языки [9], и каждый успешный «ускоритель Python-стека» работает, убирая Python из исполнения — от tf.data до torch.compile [22, 23, 26].

• Налог реален и измерен: ~70× по времени и энергии на языковых бенчмарках [14, 17], до половины времени inference-движка на CPU-оверхед [30], 30 % вычислительного времени ML-флота Google на входные пайплайны [26]. На масштабе миллиардов запросов в день проценты превращаются в гигаватт-часы [54, 55].

• Индустрия уже голосует ногами: llama.cpp и GGUF [31, 32], Rust внутри Hugging Face [33], MLX [43], ExecuTorch [34], Mojo [35] — везде, где производительность обязательна, компилируемые языки уже стоят у руля.

• Swift — редкое сочетание: скорость в разы от C (а не в десятки раз) [14], синтаксис, честно сравнимый с Python, ARC и compile-time-проверка гонок [44], продакшен-доказательства [42] и единственная в индустрии системная интеграция с on-device LLM [45]. Уроки S4TF [39] и Julia [12] учтены: не штурм цитадели, а новые территории.

• Главный горизонт — один язык от идеи до устройства. Проблема двух языков [11] — не закон природы, а исторический компромисс. Компромиссы пересматривают.

Король не умер, и свергать его никто не собирается. Но корона — не аргумент в инженерном споре. В следующий раз, когда вы будете выбирать инструмент для модели, которая должна жить на устройстве, в агентном цикле или в бюджете на электричество, — просто посчитайте. Числа в этой статье к вашим услугам.

А лучше — проверьте сами. Ничто не учит так, как эксперимент.

---

Об авторе

Андрей Сапунов — автор книги «Как работает LLM: от нуля до своего трансформера» — руководства «для чайников» с инженерными вставками, в котором читатель строит собственную языковую модель. Весь код книги написан на Swift и MLX — по причинам, которые после этой статьи не нуждаются в пояснении.

• Книга «Как работает LLM» — от нуля до своего трансформера — простыми словами, но без упрощений, за которые потом стыдно — amazon.com/dp/B0H7BPJLHC

• Код: языковые модели на Swift — рабочие реализации «с нуля»: n-gram, autograd, GPT на MLX, RAG — github.com/asaptf/swift-language-models

---

Литература

1. van Rossum G. «Glue It All Together With Python». Position paper, OMG-DARPA-MCC Workshop, 1998. https://www.python.org/doc/essays/omg-darpa-mcc-position/

2. Virtanen P. et al. «SciPy 1.0: fundamental algorithms for scientific computing in Python». Nature Methods 17, 261–272, 2020. https://arxiv.org/abs/1907.10121

3. Harris C. R. et al. «Array programming with NumPy». Nature 585, 357–362, 2020. https://arxiv.org/abs/2006.10256

4. GitHub Octoverse 2024: «AI leads Python to top language». https://github.blog/news-insights/octoverse/octoverse-2024/

5. GitHub Octoverse 2025: «AI leads TypeScript to #1». https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/

6. InfoWorld. «Python is slipping in popularity — Tiobe», февраль 2026. https://www.infoworld.com/article/4129615/python-is-slipping-in-popularity-tiobe.html

7. Stack Overflow Developer Survey 2025: Technology. https://survey.stackoverflow.co/2025/technology

8. AssemblyAI. «PyTorch vs TensorFlow in 2023» (данные Papers with Code, Q4 2022). https://www.assemblyai.com/blog/pytorch-vs-tensorflow-in-2023

9. GitHub API: языковой состав pytorch/pytorch (снято 03.07.2026). https://api.github.com/repos/pytorch/pytorch/languages

10. Bezanson J., Karpinski S., Shah V., Edelman A. «Why We Created Julia», 2012. https://julialang.org/blog/2012/02/why-we-created-julia/

11. Bezanson J. et al. «Julia: A Fresh Approach to Numerical Computing». SIAM Review 59(1), 65–98, 2017. https://julialang.org/assets/research/julia-fresh-approach-BEKS.pdf

12. Kidger P. «JAX vs Julia (vs PyTorch)». https://kidger.site/thoughts/jax-vs-julia/

13. JAX documentation: «Asynchronous dispatch». https://docs.jax.dev/en/latest/async_dispatch.html

14. Pereira R. et al. «Energy Efficiency across Programming Languages: How Do Energy, Time, and Memory Relate?». SLE’17, 2017. https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf

15. Pereira R. et al. «Ranking programming languages by energy efficiency». Science of Computer Programming 205, 2021. https://www.sciencedirect.com/science/article/pii/S0167642321000022

16. van Kempen N. et al. «It’s Not Easy Being Green: On the Energy Efficiency of Programming Languages». ASE’25, 2024. https://arxiv.org/abs/2410.05460

17. The Computer Language Benchmarks Game: n-body. https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/nbody.html

18. The Computer Language Benchmarks Game: spectral-norm. https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/spectralnorm.html

19. «What’s New in Python 3.13» (free-threaded CPython). https://docs.python.org/3/whatsnew/3.13.html

20. «What’s New in Python 3.14» (PEP 779: official support of free-threaded Python). https://docs.python.org/3/whatsnew/3.14.html

21. Jin K. «Community Stewardship of Faster CPython». discuss.python.org, май 2025. https://discuss.python.org/t/community-stewardship-of-faster-cpython/92153

22. PyTorch. «Get Started: PyTorch 2.x» (анонс PyTorch 2.0 и torch.compile). https://pytorch.org/get-started/pytorch-2.0/

23. Ansel J. et al. «PyTorch 2: Faster Machine Learning Through Dynamic Python Bytecode Transformation and Graph Compilation». ASPLOS’24, 2024. https://docs.pytorch.org/assets/pytorch2-2.pdf

24. Gray A. «Getting Started with CUDA Graphs». NVIDIA Technical Blog, 2019. https://developer.nvidia.com/blog/cuda-graphs/

25. He H. «Making Deep Learning Go Brrrr From First Principles». https://horace.io/brrr_intro.html

26. Murray D. et al. «tf.data: A Machine Learning Data Processing Framework». PVLDB 14(12), 2945–2958, 2021. https://vldb.org/pvldb/vol14/p2945-klimovic.pdf

27. Leclerc G. et al. «FFCV: Accelerating Training by Removing Data Bottlenecks». CVPR 2023. https://arxiv.org/abs/2306.12517

28. Kwon W. et al. «Efficient Memory Management for Large Language Model Serving with PagedAttention». SOSP 2023. https://arxiv.org/abs/2309.06180

29. vLLM Blog. «vLLM V1: A Major Upgrade to vLLM’s Core Architecture», 2025. https://blog.vllm.ai/2025/01/27/v1-alpha-release/

30. LMSYS Org. «SGLang v0.4: Zero-Overhead Batch Scheduler», 2024. https://lmsys.org/blog/2024-12-04-sglang-v0-4/

31. Hugging Face Blog. «GGML and llama.cpp join HF to ensure the long-term progress of Local AI», 2026. https://huggingface.co/blog/ggml-joins-hf

32. Hugging Face Hub documentation: GGUF. https://huggingface.co/docs/hub/gguf

33. huggingface/tokenizers (Rust). https://github.com/huggingface/tokenizers

34. PyTorch Blog. «Introducing ExecuTorch 1.0: Powering the next generation of edge AI», 2025. https://pytorch.org/blog/introducing-executorch-1-0/

35. «Mojo (programming language)» — Wikipedia (документирует серию Modular «A journey to 68,000x speedup over Python», 2023). https://en.wikipedia.org/wiki/Mojo_(programming_language)

36. Modular Blog. «Modular 26.3: Mojo 1.0 Beta», май 2026. https://www.modular.com/blog/modular-26-3-mojo-1-0-beta-max-video-gen-and-more

37. Howard J. «fast.ai — Embracing Swift for Deep Learning», 2019. https://www.fast.ai/posts/2019-03-06-fastai-swift.html

38. Saeta B. et al. «Swift for TensorFlow: A portable, flexible platform for deep learning», 2021. https://arxiv.org/abs/2102.13243

39. tensorflow/swift — официальный архив проекта Swift for TensorFlow. https://github.com/tensorflow/swift

40. Larson B. «Benchmarking Differentiable Swift». PassiveLogic, 2024. https://medium.com/passivelogic/benchmarking-differentiable-swift-270da84f4fe4

41. GlobeNewswire. «PassiveLogic Advances Swift AI Compiler to Deliver Superior Energy Efficiency…», 2024. https://www.globenewswire.com/news-release/2024/08/20/2933037/0/en/PassiveLogic-Advances-Swift-AI-Compiler-to-Deliver-Superior-Energy-Efficiency-Over-Industry-Giants-TensorFlow-and-PyTorch.html

42. Swift.org Blog. «Swift at Apple: Migrating the Password Monitoring service from Java», 2025. https://www.swift.org/blog/swift-at-apple-migrating-the-password-monitoring-service-from-java/

43. Swift.org Blog. «On-device ML research with MLX and Swift», 2024. https://www.swift.org/blog/mlx-swift/

44. Swift.org Blog. «Announcing Swift 6», 2024. https://www.swift.org/blog/announcing-swift-6/

45. Apple WWDC25, session 286: «Meet the Foundation Models framework». https://developer.apple.com/videos/play/wwdc2025/286/

46. Apple ML Research. «Introducing Apple’s On-Device and Server Foundation Models», 2024. https://machinelearning.apple.com/research/introducing-apple-foundation-models

47. Hugging Face Blog. «Swift Transformers Reaches 1.0», 2025. https://huggingface.co/blog/swift-transformers

48. IEA. «Energy and AI». World Energy Outlook Special Report, апрель 2025. https://www.iea.org/reports/energy-and-ai/executive-summary

49. IEA. «Data centre electricity use surged in 2025…», апрель 2026. https://www.iea.org/news/data-centre-electricity-use-surged-in-2025-even-with-tightening-bottlenecks-driving-a-scramble-for-solutions

50. Barr J. «Amazon EC2 Update — Inf1 Instances with AWS Inferentia Chips…». AWS News Blog, 2019. https://aws.amazon.com/blogs/aws/amazon-ec2-update-inf1-instances-with-aws-inferentia-chips-for-high-performance-cost-effective-inferencing/

51. Patterson D. et al. «The Carbon Footprint of Machine Learning Training Will Plateau, Then Shrink». IEEE Computer 55(7), 2022. https://arxiv.org/abs/2204.05149

52. Strubell E., Ganesh A., McCallum A. «Energy and Policy Considerations for Deep Learning in NLP». ACL 2019. https://arxiv.org/abs/1906.02243

53. Patterson D. et al. «Carbon Emissions and Large Neural Network Training», 2021. https://arxiv.org/abs/2104.10350

54. Altman S. «The Gentle Singularity», июнь 2025. https://blog.samaltman.com/the-gentle-singularity

55. TechCrunch. «ChatGPT users send 2.5 billion prompts a day», июль 2025. https://techcrunch.com/2025/07/21/chatgpt-users-send-2-5-billion-prompts-a-day/

56. Apple ML Research. «Introducing the Third Generation of Apple’s Foundation Models», июнь 2026. https://machinelearning.apple.com/research/introducing-third-generation-of-apple-foundation-models