Три месяца на Python 3.14 free-threaded в проде — отчёт с цифрами и граблями

[Shonroman]

Обещал отписаться про free-threading после обкатки — выполняю, три месяца полёт. Вводные: два сервиса, первый — обработка документов (парсинг XML и PDF, валидация, чистый CPU-bound питон плюс lxml), второй — скоринг на numpy. В марте перевели оба на free-threaded сборку 3.14: ставится одной командой uv python install 3.14t, в докере собираем тем же uv в multi-stage. Что получили: вместо восьми процессов gunicorn по 380 МБ RSS — один процесс с пулом на 12 потоков и 900 МБ; пропускная способность на том же железе (8 vCPU в VK Cloud) выросла примерно на треть, p95 на тяжёлых батчах упал с 14 до 9 секунд. Однопоточный оверхед free-threaded сборки замеряли отдельно — порядка 7-8% относительно обычной 3.14, на фоне параллелизма его не видно. Теперь грабли. Первое: колёса с тегом cp314t есть у всех крупных пакетов (numpy, pydantic-core, orjson, lxml), но древний pymssql пришлось выкинуть и переехать на pyodbc. Второе: GIL много лет прощал гонки — словили race condition на самодельном кэше-словаре, который «не существовал» годами; лечится обычным Lock, но искать было весело. Третье: обязательно гоняйте staging под нагрузкой сутки-двое, один сторонний пакет у нас падал раз в несколько часов, пока не обновили до свежей версии. Итог: рекомендую, но это не бесплатная кнопка «сделать быстрее».

[b1llyn0m]

@Shonroman, Спасибо за отчёт, редкая конкретика. А с Django кто-нибудь пробовал? У нас классика: ORM, gunicorn с sync-воркерами, пачка сторонних приложений из экосистемы. Боюсь именно за плагины.

[asyncops]

Django формально работает, сам гонял пет-проект на 3.14t — но экосистема сторонних пакетов это лотерея. Ядро и ORM в порядке, а вот всякие django-чтототам пятилетней давности с кэшами на уровне модуля — кандидаты на те самые гонки, что выше описали. Я бы на вашем месте подождал ещё полгода или заходил через канарейку на пару процентов трафика.

[jamesusa]

Не соглашусь. Главный выигрыш не скорость, а память и простота кода. Вместо танцев с multiprocessing, очередями и сериализацией через pickle — обычный ThreadPoolExecutor с общими структурами данных. Мы после перехода выкинули примерно 400 строк обвязки межпроцессного взаимодействия, и она была самой забагованной частью сервиса. Плюс приземлённый аргумент: на дешёвом VPS с 4 ГБ восемь процессов с прогретыми моделями тупо не влезали, а потоки — влезают.

[chase2]

Дополню вопросом: JIT кто-нибудь включал поверх? PYTHON_JIT=1 на 3.14 даёт у меня стабильные +4-6% на наших бенчах — мелочь, а приятно, и с free-threaded сборкой не конфликтует. И интересно, щупал ли кто subinterpreters как альтернативу потокам — на бумаге изоляция красивая, а живых отчётов почти нет.

[go_whale]

@b1llyn0m, Не понимаю общего хайпа, честно. Для веба узкое место — база и сеть, и это давно решено асинхронщиной без всяких потоков. Free-threading нужен полутора процентам проектов с CPU-bound на чистом питоне. Остальным как было проще вынести горячий код в numpy или расширение на Rust, так и осталось.