Месяц на free-threaded Python 3.14 в проде: разбор выписок ускорился в 5 раз, но граблей хватает

[sylvia666]

Сервис разбирает банковские выписки и счета (XML, Excel, иногда PDF) для бухгалтерского SaaS. Классическая боль: задачи CPU-bound, GIL, multiprocessing с перекидыванием здоровенных словарей между процессами через pickle.

В мае перевели на free-threaded сборку 3.14. Ставится теперь элементарно: uv python install 3.14t, потом uv venv --python 3.14t — и поехали, никаких сборок из исходников, как во времена 3.13.

Цифры на нашем VPS (8 vCPU, 16 ГБ, обычный российский хостинг):
- пакет из 200 выписок: было 11 минут на multiprocessing с 6 воркерами, стало 2 мин 20 сек на ThreadPoolExecutor с 12 потоками;
- пиковая память: 2,1 ГБ против прежних 5,8 — потоки шарят данные, pickle-сериализация исчезла как класс;
- p99 на мелких задачах упал почти втрое, потому что нет затрат на спавн процессов.

Грабли тоже были, распишу ниже, если интересно. Но главное: оно реально работает, это уже не эксперимент.

[guardia]

Главный вопрос: зачем, если multiprocessing и так работал? 11 минут против 2 — ок, но вы поменяли проверенную модель на потоки, где теперь возможны гонки в вашем же коде. В процессах изоляция бесплатная, а тут каждый общий словарик — потенциальная мина. На проде с деньгами (бухгалтерия же) я бы сто раз подумал.

[redisguru]

Про гонки — справедливо, у нас за месяц вылезли две, обе в коде, который писался с мыслью «всё равно GIL спасёт». Одна — инкремент счётчика в общем словаре, вторая — самодельный кеш без локов. Починили через Lock и очереди, плюс прогнали нагрузочные тесты с повторами.

А вот грабля, о которой мало пишут: если импортируешь C-расширение, которое не задекларировало поддержку free-threading, интерпретатор МОЛЧА включает GIL обратно. В логах только RuntimeWarning, который легко проспать. У нас так одна библиотека для работы с PDF вернула GIL на место, и мы день не понимали, почему на одном из сервисов потоки не дают прироста. Теперь на старте проверяем sys._is_gil_enabled() и роняем сервис, если GIL вдруг ожил.

[tomcruz]

По экосистеме на середину 2026: numpy, pandas, pydantic, lxml, psycopg — у всех есть колёса под cp314t, ставится без бубна. Затыки начинаются на длинном хвосте: для одной либы распознавания штрихкодов колеса не нашлось, собирали из исходников, удовольствие ниже среднего. Перед миграцией тупо пройдитесь по requirements и проверьте каждую нативную зависимость — сэкономите день.

[rsal56]

Добавлю ложку дёгтя: однопоточный код на 3.14t процентов на 5-8 медленнее обычной сборки. Если у вас Django-монолит, где всё I/O-bound и упирается в постгрес, free-threading не даст ничего, кроме просадки. Это инструмент под конкретный профиль — CPU-bound с общими данными. Остальным как раньше: воркеры gunicorn и не выпендриваться.

[aqwzsx]

Подтверждаю цифры топикстартера, у нас похожий профиль (рендеринг отчётов) и похожий результат — ускорение примерно в 4,5 раза против пула процессов при вдвое меньшей памяти.

Из неочевидного: иногда выгоднее не ThreadPoolExecutor, а InterpreterPoolExecutor, появившийся в 3.14 — изоляция почти как у процессов, но сильно дешевле. Мы им закрыли пару мест, где общие данные не нужны, а страх гонок остался.