Python 3.14t без GIL: восемь месяцев с релиза — у кого реально взлетело в проде?

[kernel_veteran]

С выхода 3.14 прошло восемь месяцев, free-threaded сборка официально переведена из экспериментальной в поддерживаемую — а в каждом втором обсуждении до сих пор одни теории. Хочу собрать реальный опыт.

Наш кейс: внутренний сервис обработки документов — парсинг PDF, постобработка после OCR, много чистого Python плюс lxml. Поставили рядом с обычным интерпретатором:

Код: Выделить всё

uv python install 3.14t
uv venv --python 3.14t

Замеры на пайплайне из 200 документов, 16-ядерный Xeon:
— 3.14 обычный + multiprocessing, 8 воркеров: 94 с
— 3.14t + ThreadPoolExecutor, 8 потоков: 71 с
— 3.14t, 16 потоков: 52 с

Главный выигрыш даже не в параллельности как таковой, а в том, что выкинули сериализацию между процессами: объекты по 50–200 МБ больше не гоняем через pickle туда-обратно.

Минусы честные: однопоточный код просел процентов на 7, и мы поймали две гонки в собственном коде, которые GIL годами маскировал. Кто ещё пробовал? Интересует и положительный, и отрицательный опыт.

[debian12]

Для типичного веба это пока мимо кассы, скажу как дежурный скептик. Django и FastAPI под gunicorn с процессами работают как работали, узкое место — база и сеть, а не GIL. Я бы и рад не плодить копии процессов по гигабайту RAM, но ждать, пока весь зоопарк зависимостей соберёт колёса под cp314t, — увольте. psycopg и orjson у нас уже ок, а вот одно легаси C-расширение тянет GIL обратно: интерпретатор его молча включает, и весь смысл теряется, а warning в логах легко проглядеть.

[lonelygoblin]

Пара технических моментов для тех, кто пойдёт щупать.

1. Проверяйте, что GIL реально выключен:

Код: Выделить всё

python3.14t -c "import sys; print(sys._is_gil_enabled())"

Если хоть одно расширение собрано без поддержки free-threading, интерпретатор тихо вернёт GIL. Хотите честного поведения — ставьте переменную окружения PYTHON_GIL=0: тогда несовместимый модуль уронит процесс с внятной ошибкой вместо молчаливой деградации.

2. Просадка однопоточного кода в 3.14t заметно меньше, чем была в 3.13t: там в худших сценариях доходило до десятков процентов, потому что отключали адаптивный специализатор; сейчас его вернули, и типичные 5–10% — это уже терпимо.

3. Экосистема: numpy, pandas, pydantic-core, cryptography, pillow — колёса под cp314t есть. Хромает часть ML-стека и нишевые биндинги. Перед миграцией тупо пройдитесь по списку зависимостей и проверьте каждое.

4. Про гонки, которые поймал ТС: это сейчас главная цена перехода. GIL много лет прощал паттерны вида «проверил и записал в общий dict». Лечится нагрузочными тестами с реальной конкуренцией и точечными локами — и не верьте советам вешать один большой Lock на всё, иначе соберёте GIL обратно своими руками.

[rhinz]

Перевели часть celery-воркеров (CPU-bound: ресайз картинок и расчёт перцептивных хешей) на тредовый пул с 3.14t. Скорость та же, но памяти на ноду минус 60%: было 12 префорк-процессов по 800 МБ, стало одно приложение на полтора гига. Ради одной экономии RAM на наших тарифах в облаке уже окупилось.

[RedisNinja]

А что с ML-инференсом? Хочется крутить модель в потоках без танцев с torch.multiprocessing и шарить веса между воркерами.

[asyncmonk]

Свежий torch на 3.14t ставится и в потоках работает, но чудес не ждите: если время и так уходит в CUDA-ядра, GIL вам особо и не мешал. Реальный профит — CPU-препроцессинг и токенизация рядом с инференсом, вот они параллелятся отлично. Один нюанс из боевого: связка torch + numpy + 3.14t у нас завелась только после обновления всего до последних минорных версий, со старыми были сегфолты на импорте. Так что pin-ите версии и тестируйте связку целиком.