Паспорт генерации изображения
Промт генерации изображения
Dark neon 'underside of progress' scene, cyberpunk workshop mood. Two version-serpents, one cold teal-cyan and one warm amber, interlocked as an intricate two-sided latch-lock: cannot separate, cannot merge, held precisely because kept apart; not chaos but forced symmetry. Ornate brass mechanism teeth, engraved version numerals, a warm workbench lamp, tools and metal filings on dark wood. Deep shadow, volumetric haze, warm amber and cyan color palette, shallow depth of field, cinematic film still on 35mm, intricately detailed, ultra-detailed, fine textures, rich layered background, ornate mechanical detail, sharp focus, moody atmosphere.
Не бардак, а защёлка с двух сторон: история о том, как попытка «прибраться» в системе едва не сломала единственно возможную конфигурацию.
На домашнем сервере одновременно живут две вещи: Home Assistant, который держит умный дом, и детектор объектов, который смотрит в камеру. Обе написаны на Python. И однажды я решил навести в этом хозяйстве порядок.
В Activity Monitor висит странная картина. Два разных интерпретатора Python - версии 3.11 и 3.13 - одновременно едят ресурсы сервера. Оба активны, оба потребляют память. Первая мысль любого, кто хоть раз пытался настроить окружение на macOS: «Опять какой-то хвост».
Кажется, что в системе поселился бардак. Забытый дубль, какой-то старый скрипт, который должен был умереть год назад, но продолжает жрать ресурсы в фоне. В голове уже рисуется план зачистки: снести лишнее, объединить всё под актуальную версию 3.13 и вернуть машине немного воздуха.
Иллюзия чистого монитора
Начал с привычного анализа процессов, но Activity Monitor оказался слишком «вежливым». Он рапортовал о двух процессах Python, хотя по факту их было три. Один из них - Home Assistant, второй - Telegram-поллер для уведомлений. Оба они работали на Python 3.13, но в интерфейсе монитора слились в одну строку, создавая ложное ощущение, что ресурсов тратит всего один сервис.
Затем взгляд упал на процесс 3.11. Он занимал около 279 МБ памяти. Для голого интерпретатора это много, почти абсурдно. Списал это на «раздутость» старой версии и неоптимизированные библиотеки. Казалось, что удаление этого «лишнего» Питона мгновенно освободит память и упростит топологию системы.
Всё выглядело как классический кейс избыточности: зачем держать две версии одного и того же языка, если можно всё перенести на свежую?
Диагностика через «тупые» вопросы
Вместо того чтобы просто нажать kill и переписывать конфиги, решил прогнать ситуацию через ИИ. Не для того, чтобы получить совет «обновите всё», а чтобы заставить машину проверить факты, которые я пропустил из-за уверенности в собственной правоте.
ИИ предложил не гадать по именам процессов, а вытащить полные пути к исполняемым файлам и проверить содержимое виртуальных окружений (venv) каждого сервиса.
Оказалось, что ps видит гораздо больше:
88702 88700 279104 62.0 python3 -u /tmp/277/objectDetectServerYolo.pyЗаглянув внутрь venv, обнаружил жесткое разделение:
/homeassistant/venv/bin/python3→ Python 3.13.14/firescrew/venv/bin/python3→ Python 3.11.15
Внутри второго окружения обнаружились torch 2.2.2 и numpy 1.26.4. Вот где прятались те самые 279 МБ. Это был не «раздутый Питон», а вес нейросетевых весов YOLO и библиотек глубокого обучения.
Физический предел железа
Когда возник вопрос «почему нельзя всё перенести на 3.13», ИИ помог перевернуть рамку. Я видел в этом бардак, а на деле это была единственно возможная конструкция.
Проблема оказалась в «колесах» (wheels) - скомпилированных бинарниках библиотек. Home Assistant требует версию 3.13 и выше для стабильной работы. В то же время последнее существующее колесо PyTorch под Intel-Mac (версия 2.2.2) собрано только под cp311 - то есть строго под Python 3.11.
Версии физически не пересекались. Чтобы запустить детектор объектов на Python 3.13, пришлось бы собирать PyTorch из исходников прямо на этом железе.
Два ядра, частота 1.4 ГГц. Компиляция заняла бы несколько часов, чтобы в итоге дать несопровождаемую самосборку, которая может отвалиться при любом обновлении. Это был путь в никуда.
Решение оказалось максимально простым: не трогать.
Топология вынужденности
Эта история оставила один конкретный вывод. Наличие двух версий одного интерпретатора в системе - не всегда признак лени или хаоса.
Когда у тебя есть два потребителя с несовместимыми требованиями, где нижняя граница одного (3.13 для HA) находится выше верхней границы поддержки железа у другого (3.11 для PyTorch на Intel-Mac), раздельные venv становятся единственной физически существующей топологией.
Цена такого дублирования - смешная. Сам бинарник интерпретатора занимает единицы мегабайт. Основной вес создают библиотеки, которые в любом случае не пересекаются и живут в своих папках.
Иногда то, что выглядит как «грязный» конфиг, на самом деле является точной защёлкой, которая удерживает систему от распада. Главное - не пытаться «прибраться» там, где порядок поддерживается именно таким специфическим раздвоением.
Часть темы «Вторая жизнь железа» - там собраны остальные разборы про слабое и старое железо.