Досвід з Python 3.14 у продакшені: коли free-threading працює, а коли ні

Python 3.14 офіційно завершив епоху експериментів з режимом free-threading. PEP 779 прийняли у червні 2025 року, і з релізу 3.14.0 збірка без GIL отримала офіційну підтримку. Безумовно, це відкриває нові можливості для справжнього паралелізму на багатоядерних процесорах. Однак реальність виявилася складнішою: хоча Python 3.14 працює на 27% швидше за 3.13, режим free-threading усе ще має обмеження.

У цій статті ми поділимося досвідом тестування Python 3.14t у продакшені, розглянемо роботу з NumPy, Pandas, ThreadPoolExecutor та проблеми сумісності бібліотек.

Встановлення free-threading збірки Python відрізняється від стандартної процедури. Офіційні інсталятори для Windows та macOS включають free-threading бінарники як опцію, проте найзручніший спосіб для всіх платформ полягає у використанні менеджера пакетів uv.

Встановлення через uv: команди та перевірка

Інструмент uv дозволяє встановити Python 3.14t однією командою. Суфікс «t» означає «threaded» і вказує на збірку без GIL. Процес встановлення займає близько 19 секунд на сучасних системах.

Базова команда виглядає так: uv python install 3.14t. Після встановлення інтерпретатор доступний як python3.14t, тоді як стандартна збірка залишається під назвою python3.14. У Windows це буде python3.14t.exe проти звичайного python.exe.

Для створення віртуального середовища з free-threading використовується команда uv venv .venv --python 3.14t, після чого можна активувати оточення стандартним способом. Альтернативно, команда uv python pin 3.14t закріплює версію для поточного проєкту.

Перевірити наявність встановлених версій можна через uv python list --only-installed, що показує всі доступні інтерпретатори у системі. Водночас команда python3.14t -VV відобразить повну інформацію про збірку, включаючи позначку «free-threading build».

Перевірка free-threading режиму через sys._is_gil_enabled()

Критичним моментом стала перевірка фактичного стану GIL у запущеному процесі. Функція sys._is_gil_enabled() повертає False для free-threading збірки до імпорту будь-яких пакетів. Якщо результат True, це означає, що GIL увімкнений або був автоматично активований якоюсь бібліотекою.

Існує альтернативний метод перевірки через sysconfig: sysconfig.get_config_var("Py_GIL_DISABLED") повертає значення на основі конфігурації збірки. Цей підхід показує, чи підтримує збірка free-threading взагалі, незалежно від того, чи GIL увімкнений у рантаймі.

Важливо розуміти різницю між цими методами. Перший показує поточний стан GIL у процесі, другий визначає можливості збірки. У продакшені обидва методи доповнюють один одного для діагностики проблем з бібліотеками.

Перший тестовий бенчмарк з ThreadPoolExecutor

Початкове тестування проводилося на I/O-інтенсивних операціях з файлами. Бенчмарк створював тимчасові файли розміром 24 МБ, записував дані чанками по 64 КБ з примусовим fsync() після кожного запису, потім зчитував дані назад.

Конфігурація тесту включала 8 операцій в однопоточному режимі та 12 операцій з ThreadPoolExecutor на 6 потоках. Саме тому цей сценарій моделював реальне навантаження на дискову підсистему.

Запуск ThreadPoolExecutor виконувався стандартним способом через контекстний менеджер. Функція wait() з параметром ALL_COMPLETED забезпечувала завершення всіх завдань перед вимірюванням часу. Результати показали різницю між однопоточним та багатопоточним виконанням, яка варіювалася залежно від апаратної конфігурації.

На восьмиядерному ноутбуці прискорення склало 47% для операцій обробки даних. Однак реальні показники залежали від типу навантаження. У наступних розділах розглянемо результати тестування з NumPy, Pandas та веб-сервісами з базами даних.

Тестування Python 3.14t на реальних робочих навантаженнях розкрило несподівану картину. Наукова екосистема виявилася найбільш готовою до free-threading режиму, тоді як вебсервіси з базами даних показали неоднозначні результати.

Науковий стек першим серйозно підійшов до підтримки free-threading, що помітно відразу. NumPy постачає free-threading збірки з версії 2.1, SciPy з 1.15, а pandas з 2.2.3. PyTorch також включив підтримку у свої дистрибутиви, і трекер сумісності спільноти демонструє переважно зелені позначки.

Практичне тестування пайплайну обробки звітності показало справжні переваги. Процес обробляв кілька гігабайтів CSV та Parquet файлів, виконував складні groupby операції та генерував числові дані для аналітики. Один з етапів пайплайну було перебудовано для використання пулу потоків замість пулу процесів.

Саме тут проявилася головна перевага: багатопроцесна версія існувала лише через примус з боку GIL. Вона несла витрати на запуск воркерів, серіалізацію всіх даних через межі процесів та інші накладні витрати. Натомість багатопоточна версія безкоштовно ділилася великими DataFrame у спільній пам'яті без податку на серіалізацію. Код став коротшим, а етап виконувався швидше.

Для обробки рядків DataFrame з мільйоном цілих чисел обчислення суми парних значень через lambda s: s.loc[s % 2 == 0].sum() тривалість скоротилася більш ніж на 60%: з 21.3 мс до 7.89 мс у Python 3.14t. Навіть невеликі DataFrame з десятьма тисячами елементів отримували переваги від багатопоточної обробки, хоча широкі DataFrame не показували покращень.

Вебсервіс з базою даних: очікування vs реальність

Тестування невеликого вебсервісу з базою даних Postgres виявило неочікуваний сценарій. Встановлення залежностей, запуск навантажувального тесту та порівняння зі стандартною збіркою дали ідентичний результат. Не трохи кращий чи гірший, а саме ідентичний.

Зрештою, діагностика показала причину: sys._is_gil_enabled() повертав True на free-threading збірці. GIL повернувся і був активний весь час. Кожен C-розширення модуль має явно оголосити здатність працювати безпечно без GIL. Коли імпортується модуль без такого оголошення, інтерпретатор робить безпечну річ: вмикає GIL для всього процесу.

Винуватцем виявився SQLAlchemy 2.0, точніше, його скомпільоване Cython-розширення. Це відома проблема, і творець SQLAlchemy Майк Байєр прямо висловився: «Сумніваюся, що збірка 2.0 робить правильні речі для Cython під free threading. Спробуйте 2.1 якомога раніше». Серія 2.1 дійсно виправила проблему, і після оновлення sys._is_gil_enabled() повернув False.

Для вебсервісу висновок був очевидний: поки що ні. Він орієнтований на I/O-операції, тому переваги мінімальні, а прогалини у psycopg та grpcio означають обмін реальних ризиків сумісності на теоретичні покращення.

Паралелізм у CPU-залежних задачах

CPU-інтенсивні операції продемонстрували найбільш вражаючі результати. Бенчмарк з обчисленням SHA256 хешів на восьмиядерній системі показав суттєву різницю між стандартним та free-threading Python.

Стандартний Python демонстрував деградацію продуктивності з додаванням потоків: один потік виконувався за 1.52 с, два потоки за 3.01 с, чотири за 5.98 с, а вісім за 11.84 с. Free-threading Python підтримував стабільний час виконання незалежно від кількості потоків: 1.61 с для одного потоку, 1.58 с для двох, 1.55 с для чотирьох та 1.59 с для восьми потоків. Прискорення досягло 7.45x для восьми потоків.

Порівняння з Rust показало, що free-threading Python досягає схожої ефективності масштабування: обидві технології показали приблизно 4x прискорення при переході від одного до чотирьох потоків. Однак Rust зберігав перевагу у абсолютних показниках: Python 3.14t був приблизно у 3-3.5 рази повільнішим за Rust для чотирьох потоків.

Обробка даних показала прискорення від 43 секунд до менше ніж 6 секунд за певних умов. Водночас виникла нова проблема: free-threading не додає потокобезпечності автоматично. Лог «обчислено 412 звітів» показував 415 через те, що вісім потоків справді працювали одночасно, і вікно гонки розширилося.

Найбільш підступною особливістю free-threading режиму виявилася не продуктивність, а мовчазне повернення GIL у виробниче середовище. Інтерпретатор захищає стабільність роботи через автоматичне увімкнення блокування, і саме цей механізм потребує ретельного розуміння.

Механізм автоматичного увімкнення GIL

Кожен C-модуль повинен явно оголосити здатність працювати безпечно без GIL через встановлення слота Py_mod_gil під час ініціалізації модуля. Типове значення за замовчуванням становить Py_MOD_GIL_USED, що змушує інтерпретатор увімкнути GIL у рантаймі при імпорті модуля. Налаштування Py_MOD_GIL_NOT_USED дозволяє імпортувати модуль зі збереженням вимкненого GIL.

Коли імпортується модуль без підтримки free-threading, інтерпретатор вмикає GIL для всього процесу. Програма продовжує працювати коректно, але друкується лише одне попередження RuntimeWarning: «The global interpreter lock (GIL) has been enabled to load module 'sqlalchemy.cyextension.collections', which has not declared that it can run safely without the GIL». Технічно це не мовчазно, але практично саме так виглядає: один рядок stderr під час запуску серед банерів фреймворків та шуму конфігурації логування.

SQLAlchemy 2.0 та Cython-розширення

Конкретний випадок виявив SQLAlchemy 2.0 як винуватця через скомпільоване Cython-розширення. Майк Байєр, творець SQLAlchemy, відповів прямо на репорт: «Сумніваюся, що збірка 2.0 робить правильні речі для Cython під free threading. Спробуйте 2.1 якомога раніше». Офіційний changelog для SQLAlchemy 2.1 підтверджує початкову підтримку free-threaded Python з оновленими тестами для Python 3.13t та 3.14t. Оновлення до серії 2.1 повернуло sys._is_gil_enabled() до значення False.

Як виявити модуль, який увімкнув GIL

Діагностика вимагає порівняння стану GIL до та після імпорту. Функція може зберегти початковий стан через original = sys._is_gil_enabled(), потім імпортувати модуль через importlib.import_module(module_name) та перевірити зміну. Альтернативний підхід використовує sysconfig.get_config_var("Py_GIL_DISABLED") для перевірки збірки та sys._is_gil_enabled() для стану рантайму.

Перевірка у коді застосунку виконується після всіх імпортів у кінці запуску програми. Якщо sysconfig.get_config_var("Py_GIL_DISABLED") повертає істину, але sys._is_gil_enabled() також істина. Можна викинути RuntimeError з повідомленням про залежність, яка увімкнула GIL.

Перевірка RuntimeWarning у CI/CD

Попередження можна перетворити на помилки, тому у CI тепер запускається набір тестів з фатальним RuntimeWarning через python -W error::RuntimeWarning -m pytest. Це змінює режим відмови з «ваш сервіс таємничо повільніший за бенчмарк» на «ваш деплой падає з повідомленням про причину». П'ять рядків коду після імпортів створюють захист від мовчазної деградації продуктивності у продакшені.

Поточний стан сумісності популярних бібліотек

Екосистема станом на середину 2026 року має змішану картину. Спеціалізовані трекери відстежують статус популярних пакетів: py-free-threading.github.io/tracking/ та hugovk.github.io/free-threaded-wheels/ надають актуальну інформацію. Драйвер psycopg не підтримує free-threaded Python, з відкритим GitHub issue #1095, створеним 19 травня 2025 року, де прямо зазначено відсутність підтримки збірок без GIL. Пакет grpcio не має free-threaded wheels на PyPI, а спроби pip побудувати з вихідних кодів завершуються невдачею після кількох хвилин виводу компілятора.

Фундаментальні бібліотеки демонструють готовність: більшість популярних пакетів або постачають cp314t wheels або є чистим Python та не потребують змін. Однак залишаються ті, хто вперто пасуть задніх, що визначає реальну форму екосистеми у 2026 році.

Еволюція free-threading між версіями 3.13 та 3.14 показала драматичне покращення базової продуктивності. Водночас вибір між збірками залишається компромісом з чіткими межами застосування.

Overhead у single-threaded коді: 35% vs 8%

Найболючішою проблемою експериментальної збірки Python 3.13 став overhead у однопоточному коді. Ранні збірки демонстрували деградацію приблизно на 40%, що робило їх непридатними для продакшену. Python 3.14 кардинально змінив ситуацію: штраф за потокобезпечні механізми зменшився до приблизно 5–10% залежно від платформи та C-компілятора.

Офіційна документація вказує діапазон від близько 1% на macOS aarch64 до 8% на x86-64 Linux-системах у бенчмарковому наборі pyperformance. Інші джерела підтверджують діапазон 1–8% та 5–10%. Різниця пояснюється типом навантаження: обчислювально орієнтовані бенчмарки залишаються в межах ±2%, демонструючи або невелике прискорення, або відсутність змін.

Free-threading збірки замінили грубе блокування GIL на блокування окремих об'єктів, зміщений підрахунок посилань та складнішу логіку координації пам'яті. Збільшений overhead від атомарних операцій особливо помітний на однопоточних запусках, де продуктивність може деградувати на 6–15% залежно від навантаження. Покращення циклічного збирача сміття окремо додає приблизно 14% overhead.

У багатопоточних сценаріях Python 3.14 суттєво перевершив попередника. Бенчмарки показали, що Python 3.13t досягав приблизно 2.2x прискорення, тоді як 3.14 досягає близько 3.1x. На CPU-залежних навантаженнях Python 3.13t демонстрував приблизно 4.8x прискорення з п'ятьма потоками порівняно з GIL-версією, яка не показувала покращень взагалі.

Чотирипоточне виконання у Python 3.14 працює приблизно в 4 рази швидше за однопоточне, досягаючи Rust-подібної ефективності масштабування з приблизно 4.0x прискоренням. Спільнотні бенчмарки підтверджують прискорення 2-3.5x на 4 ядрах для задач з паралелізмом без залежностей. Найбільший діапазон показав прискорення приблизно 2.8x при чотирьох потоках.

Asyncio та альтернативи для I/O операцій

Python 3.14 надав asyncio першокласну підтримку free-threading, зробивши реалізацію безпечною для багатопоточного середовища. Кожен потік може запускати власний цикл подій, що дозволяє використовувати переваги кількох CPU-ядер у free-threading-оточенні. Один цикл подій на одному ядрі обробляє багато з'єднань одночасно, але Python-код для обробки кожного все одно виконується послідовно.

Комбінування asyncio з потоками стає корисним, коли запити потребують нетривіальних обчислень на запит: запуск циклу подій на потоці дозволяє обробляти різні запити паралельно на кількох CPU-ядрах. Альтернативи включають uvloop як швидку заміну циклу подій, Trio та Curio як незалежні реалізації асинхронного API.

Витрати пам'яті та інші компроміси

Free-threading збірка зазвичай використовує більше пам'яті порівняно зі стандартною, з overhead приблизно 10%. Інтернування рядків через sys.intern() робить їх безсмертними у free-threading збірці, на відміну від стандартної версії. Структура PyObject змінилася: на AMD64-платформі None використовує 32 байти у free-threading проти 16 байтів у стандартній збірці.

Free-threading збірка використовує алокатор пам'яті mimalloc для всіх Python-об'єктів замість pymalloc. Підрахунок посилань на потік для вибраних типів об'єктів означає, що об'єкти звільняються пізніше, ніж у стандартній збірці. Час обходу збирача сміття погіршується приблизно на 2%, а збірка може викликати паузи «stop-the-world» під час GC або синхронізації блокувань.

Перехід на free-threading вимагає методичного підходу. Екосистема станом на середину 2026 року перебуває у фазі активного переходу, і рішення про міграцію залежить від конкретного стека технологій.

Аудит залежностей проєкту

Насамперед потрібно перевірити сумісність залежностей через спеціалізовані трекери. Ресурс py-free-threading.github.io/tracking/ відстежує статус пакетів з активною роботою над підтримкою free-threading. Автоматичний трекер hugovk.github.io/free-threaded-wheels/ перевіряє наявність wheels на PyPI для ширшого діапазону пакетів.

Інструмент pip-audit сканує залежності на наявність вразливостей через базу даних OSV. Команда uvx pip-audit -r requirements.txt перевіряє файл залежностей, а uv run pip-audit аналізує поточне середовище. Водночас це не перевіряє сумісність з free-threading, лише безпеку версій.

Контейнеризація: Docker та Python 3.14t

Спільнота активно працює над інтеграцією free-threading збірок в офіційні Docker-образи. Проте станом на поточний момент потрібен власний Dockerfile з явним встановленням Python 3.14t через uv або збірку з вихідних кодів.

Коли варто переходити на free-threading

Переконливі аргументи існують для CPU-залежних багатопоточних робочих навантажень. Прискорення 3.1x для обчислювально орієнтованих задач робить міграцію привабливою. Науковий стек з NumPy, SciPy, pandas демонструє готовність до продакшену.

Коли залишитися на стандартній збірці

Вебзастосунки з орієнтацією на I/O-операції не отримують переваг. Залежності від бібліотек без підтримки free-threading означають автоматичне повернення GIL. Overhead 5–10% у однопоточному коді робить стандартну збірку кращим вибором для послідовних навантажень. Зрештою, рекомендація проста: залишайтеся на кілька версій позаду для стабільності продакшену.

Наш досвід тестування Python 3.14t у продакшені підтвердив суттєве покращення порівняно з експериментальним 3.13. Overhead у однопоточному коді зменшився з 35% до 5–10%, а багатопоточні CPU-інтенсивні завдання отримали прискорення 3.1x. Науковий стек з NumPy, pandas та SciPy продемонстрував готовність до реального використання. Водночас вебсервіси з орієнтацією на I/O-операції не показали переваг через обмеження сумісності бібліотек.

Головна проблема залишається у мовчазному поверненні GIL через несумісні залежності. Саме тому рекомендація проста: переходьте на free-threading лише для CPU-залежних багатопоточних навантажень з перевіреним стеком залежностей. Для решти сценаріїв стандартна збірка залишається кращим вибором у 2026 році.