Какие есть альтернативы pip, чтобы каждый venv не весил гигабайты?

--system-site-packages?

Можно же сделать симлинками из какого-то общего «хранилища»

Зачем симлинками? Рефлинками нужно. С помощью duperemove -dr дедуплицируется любой набор дублирующихся файлов без расставления граблей для завтрашнего себя.

В _venv.owui и _venv.sd есть некоторые пакеты разных версий. И если то, что в этих venv’ах гоняется, затребует другие, оно начнёт постепенно засирать venv, если всё больше отличий от системных.

Про _venv.llm я уже ничего не помню, я его забросил полгода назад, уже не помню что тогда llama.cpp тащило (оно обновляется быстрее, чем я успеваю следить ☺) для всякого питонового у себя.

Эти venv’ы обновляются независимо друг от друга, файлов там ОЧЕНЬ много, дедупликация, тем более внешняя, будет ОЧЕНЬ медленной.

Нужен максимально универсальный и простой способ.

Ну и симлинки могут быть даже с другого диска.

То есть, например, если запрошен torch-2.5.1 из двух разных venv’ов, то он будет просто линком в обоих, а если в одном venv’е нужно его обновить/откатить, то в какой-то "кэш" скачивается-устанавливается другая версия и снова симлинком добавляется. В идеале чтобы оно ещё и подчищало этот общий "кэш", если версия более никем не используется.

Эти venv’ы обновляются независимо друг от друга, файлов там ОЧЕНЬ много, дедупликация, тем более внешняя, будет ОЧЕНЬ медленной.

Поставить на крон по ночам или по выходным, смотря как часто там что-то меняется. Если файлов реально много, поможет запуск duperemove c опцией типа -B 104857600 (по умолчанию он заточен под экономию памяти и жёстко тупит на гигантских массивах мелких файлов). А, ещё можно сохранить файл с хэшами и использовать при последующих запусках, поможет сэкономить время.

Ну и симлинки могут быть даже с другого диска.

Это да, но тогда есть смысл просто все venv’ы на тот диск переместить и там дедуплицировать спокойно.

жёстко тупит на гигантских массивах мелких файлов

Но ведь питон это всегда гигантский массив мелких файлов. (=

$ find _venv.owui/ -type f -print | wc -l
65662

Поставить на крон по ночам или по выходным

Под venv’ы хотелось бы что-то более… предметное. Но если не найдётся, то и для этого вооружусь. Правда, я боюсь что оно что-нибудь сломает, так как обновление и дедупликация будут происходить в разное время (.py-файлы как бы пофиг, а вот .pyc…).

А пока для duperemove у меня есть другая задача — дедуплицировать идентичные изображения, сгенерированные StableDiffusion, уж там-то он точно ничего не сломает!

Под venv’ы хотелось бы что-то более… предметное. Но если не найдётся, то и для этого вооружусь. Правда, я боюсь что оно что-нибудь сломает, так как обновление и дедупликация будут происходить в разное время (.py-файлы как бы пофиг, а вот .pyc…).

Не сломает. Худшее, что может произойти — дедуплицируется позже, чем надо. А вот расстановка симлинков может сломать, если по ним разрешена запись.

А вот расстановка симлинков может сломать, если по ним разрешена запись.

Резонное замечание, кстати. Я как-то не подумал об этом.

С помощью duperemove -dr дедуплицируется любой набор дублирующихся файлов

Но в мане английским по чёрному написано:

-d    De-dupe the results - only works on btrfs and xfs.

Но в мане английским по чёрному написано:

Ага, нужна нормальная фс

Ну тогда твой вариант мне совершенно не подходит:

".../_venv.llm/lib/libblosc2.so.2.15.0": Can only dedupe files on btrfs or xfs (experimental)

нужна нормальная фс

Мне нужна надёжная файловая система, потому Btrfs отпадает сразу. (=

Тогда выбор очевиден - XFS

Подержишь 855G моделей и 3×7.3G venv’ов, пока я переразмечаю диск? (%

Есть pipx, вроде оно. Сам почти не пробовал его - после всей свистопляски, где дистрибутивы говорят «ты слишком тупой --user прописывать, поднимать виртуальное окружение гораздо проще и опрятнее» урезал свои потребности в питоне до такой степени, где мне пакетного менеджера системы хватает.

800G моделей

Чем ты там занят, скажи. Не иначе вселенную порабощаешь.

Ух ё

При таких объёмах мб zfs стоит попробовать, возможно даже выделить под неё сервачок на бзде с достаточным количеством рамы и экспортировать по нфс

урезал свои потребности в питоне

Увы, со SD/LLM и прочим ML это не прокатит — всё в первую очередь пишется на Python, и уже потом, может быть переписывается на C++ (и почти всё господином Гергановым ☺).

pipx

Сейчас потыкаем, пасиба.

Чем ты там занят, скажи. Не иначе вселенную порабощаешь.

Ну… в принципе да! Я генерирую котиков! (=

Попробуй https://github.com/astral-sh/uv там что-то про агрессивное кэширование заявляют.

При таких объёмах мб zfs стоит попробовать, возможно даже выделить под неё сервачок на бзде с достаточным количеством рамы

Этот Debian 12 крутится в виртуалке с 48G RAM.

Хост 2×E5-2697v2, 12 ядер, 24 потока каждый (24 ядра, 48 потоков в сумме), 256G RAM.

На хосте крутится FreeBSD, естественно с ZFS. (=
Виртуальные диски — zvol.

и экспортировать по нфс

Ну во-первых это будет дико медленно, даже если это виртуальная сеть в пределах одной железки. А во-вторых мне не удалось настроить на Debian NFS-клиент, который дружит с NFSv4-сервером на базе FreeBSD. )=

У тебя наверняка сейчас ext4, а её можно уменьшать. Ну и, значит, такой алгоритм действий:

1. уменьшаешь ФС на основном разделе настолько, насколько возможно;
2. уменьшаешь основной раздел;
3. создаёшь на пустом месте новый раздел и новую ФС;
4. переносишь часть файлов с первого раздела на новый.

Повторяешь действия, пока первый раздел не станет пустым.

В результате у тебя образуется куча разделов, причём основной (первый) — с пустой ФС.

ФС на основном разделе сносишь, создаёшь там XFS. Затем:

1. переносишь файлы с ближайшего к основному разделу на основной;
2. удаляешь ближайший раздел, который теперь с пустой ФС;
3. расширяешь основной раздел, расширяешь ФС на нём.

Повторяешь действия, пока основной раздел не будет расширен до его изначального размера.

Вот так можно сменить ФС без использования отдельного накопителя. Если перенос данных между разделами делать в два этапа, копирование и только потом удаление исходных файлов, то процесс получается устойчивым к внезапной потере питания. Плюс в том, что если порубить работу на небольшие части, можно прерываться без особых проблем. Минус в том, что довольно много ручной работы.

что-то про агрессивное кэширование

Читал, но так и не понял, они про сами пакеты (архивы), или уже про распакованное.

В дебиане его нет, потому разбираться буду чуть позже, когда появится желание компилять. (=

Там есть собранные бинари.

3.14-здец наркоманство… (=

Это как раз по разделу на модель получится. (%

Nix уже советовали?

типа

{ pkgs ? import <nixpkgs> {} }:
pkgs.mkShell {
  buildInputs = [
    pkgs.python3
    (pkgs.python3.withPackages (ps: with ps; [
      numpy_1_21_0
      requests_2_25_1
    ]))
  ];
}

Вот он точно залинкует то что надо, и не залинкует то, что не надо, но ЕМНИП там будут засады с тем что это именно shell

Ага, есть…

Под armv6, armv7, aarch64, s390x и ppc64le. (%
x86_64 не завезли!

Nix уже советовали?

Он умеет работать с requirements.txt? Нет? Тогда иди, доказывай тем же huggingface что им необходимо предоставлять конфиги для Nix. Когда будет — приноси, обсудим. (%

uv-x86_64-unknown-linux-gnu.tar.gz 15.5 MB 2025-02-14T18:22:05Z

uv-x86_64-unknown-linux-musl.tar.gz 15.6 MB 2025-02-14T18:22:05Z

Эээ… А в списке их нет.

Пасибки, ща потыкаю.

Там список разворачивается по кнопке «Show all 42 assets»

Он умеет работать с requirements.txt?

Да https://github.com/nix-community/dream2nix

Когда будет — приноси, обсудим. (%

$ mkdir my-project
$ cd ./my-project
$ nix flake init -t github:nix-community/dream2nix#simple

# добавляешь requirements.txt

$ nix run .#default.lock

Скинь какой-нибудь requirements.txt сейчас и попробуем и посмотрим что он там наставит и как. А то может он тупо его venv скормит.

Ушел с venv+llama.cpp сначала на vllm, затем на anaconda+кастомные инференсы на transformers. Если не просто запускаете, а еще и доучиваете или делаете LORA то все равно скорее всего придете к тому же.

Все модели лежат в папке models в подпапках названных также как на Huggingface. Модели скачиваются простым скриптом на питоне из мануала. Окружения лежат в /opt/anaconda3 c подпапками. Окружений штук 5, не больше, вес не считал, завтра гляну если интересно. Общий вес моделей также не считал, пока в 2TB nvme влезают, но я удаляю неиспользуемые/неудачные.

Чай не первый день гитхабом пользуюсь. (=
У меня пишет что их всего 8.

странно

одно окружение на всех, зачем для каждого проекта своё держишь,
скорее всего я чего то не знаю? может конфликтуют (я в одно запихал проблем нет), но pygame из дебиана притянул для удобства разработки - и установки потом.

Ну во-первых это будет дико медленно, даже если это виртуальная сеть в пределах одной железки.

Почему это? Все используемые файлы питоновых модулей закэшируются в page cache и далее будут читаться из памяти.

А во-вторых мне не удалось настроить на Debian NFS-клиент, который дружит с NFSv4-сервером на базе FreeBSD

А если NFSv3 попробовать?

Да

Вот прям внезапно! Серьёзно, не ожидал.

Скинь какой-нибудь requirements.txt сейчас и попробуем и посмотрим что он там наставит и как. А то может он тупо его venv скормит.

ComfyUI.
АХТУНГ! АЛЯРМ! Это притащит ≈7.3G всякого всего. (=

одно окружение на всех, зачем для каждого проекта своё держишь,

Мы тут недавно пытались с нуля развернуть свежий ferminet, оказалось, что с последними версиями зависимостей, которые подтягивались из его setup.py, работать он в принципе не мог из-за конфликтов между зависимостями. После репорта разработчики это починили, но прошло полторы недели. Так что с этим мл-говном в состоянии вечной альфы лучше не рисковать, никогда не знаешь, что отвалится после обновления.

Ушел с venv+llama.cpp сначала на vllm, затем на anaconda+кастомные инференсы на transformers. Если не просто запускаете, а еще и доучиваете или делаете LORA то все равно скорее всего придете к тому же.

У меня llama.cpp давно уже на FreeBSD в jail крутится, там Python почти не нужен. А вот Stable Diffusion перетащить на FreeBSD пока не удаётся, потому и приходится держать виртуалку с Debian. А так как бэкендов несколько (и я всеми пользуюсь), то и venv’ов несколько, и там хаос в зависимостях (некоторые ещё и конфликтуют).

Окружений штук 5, не больше, вес не считал, завтра гляну если интересно.

Интересно. С no follow symlinks.

Сорян, я протупил и нажал Packages вместо Releases. 🤦‍♂️

Да, в релизах лежат i686 и x86_64.

одно окружение на всех, зачем для каждого проекта своё держишь

Затем, что некоторые по зависимостям конфликтуют. Если установить зависимости из одного, то ломается другой и наоборот.

А ещё в одном проекте приходится на gradio патч накладывать, потому что эти тормоза до сих пор не удосужились починить.

Все используемые файлы питоновых модулей закэшируются в page cache и далее будут читаться из памяти.

Ну это если venv’ы положить на NFS. Один раз все эти 7.3G сгрузил в память и норм.

А модели приходится часто переключать, они жЫрные (≈6.5G весит SDXL, ≈25G весит FLUX.1), их лучше на NFS не класть.

А если NFSv3 попробовать?

У меня он не отключен, но Debian его в упор не видит (showmount выдаёт пустоту). Но с NFSv3 есть такая штука, что оно вешает наглухо процесс, который обратился к зависшей шаре. Настолько наглухо, что даже kill -9 его не убивает, только ребут.

pipx

Оно создаёт venv’ы и делает бинари из них доступными без необходимости делать . venv/bin/activate и deactivate. Ставит он всё так же как и pip, то есть venv’ы получаются жЫрными.

Глянул, окружения от 5.2GB до 16GB в зависимости от напиханного внутрь. Каждое окружение подходит для работы с кучей сетей определенного вида, т.е. это не один образ - одна сеть. Сама Анаконда у меня под 80GB, но там еще R и куча обвязки под него, те голую анаконду выделить не могу, это при чистой установке смотреть нужно.

Сами модели - 904GB. Скачиваю их простым скриптом вида:

#!/usr/bin/env python3

from huggingface_hub import snapshot_download

models_path = '/data/ai/models/'

models = [
  'NousResearch/Yarn-Mistral-7b-128k', 
  'meta-llama/Llama-3.2-11B-Vision-Instruct'
]

for repo_id in models:
    local_dir = models_path + repo_id
    snapshot_download(repo_id=repo_id, local_dir=local_dir)

Инференсы поднимаю также просто:

from transformers import AutoTokenizer, AutoModelForCausalLM

models_path = '/data/ai/models/'
model_name = models_path + "NousResearch/Yarn-Mistral-7b-128k"

tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True)
model = AutoModelForCausalLM.from_pretrained(model_name, device_map="cuda", trust_remote_code=True)
...

Не знаю, насколько вам это подойдет тк вы стремитесь ужать объем как я понял. Просто поделился как у себя организовал.

Но с NFSv3 есть такая штука, что оно вешает наглухо процесс, который обратился к зависшей шаре

-o nolock не помогает?

А не маловато?

Да и насколько я знаю нейронки же через гпу работают

Глянул, окружения от 5.2GB до 16GB в зависимости от напиханного внутрь.

Значит анаконда просто скидывает всё в venv, как pip и pipx.

Не знаю, насколько вам это подойдет

Из этой виртуалки давно съехало LLM, но не исключено что когда-нибудь пригодится.

Скачиваю их простым скриптом вида

Чем не устроил официальный huggingface-cli?

pip install huggingface_hub[cli]

Ну или как там в анаконде, я её никогда не видел. (=

Но с NFSv3 есть такая штука, что оно вешает наглухо процесс, который обратился к зависшей шаре

-o nolock не помогает?

Не всегда. NFSv3 же тупенькое, оттого я и стараюсь использовать NFSv4.

А не маловато?

48 гигов для Stable Diffusion? Пока хватает. Будет мало — докину ещё, до 128G RAM вполне могу выделить без каких-либо ущемлений всего остального. А если и этого окажется мало — докуплю оперативки, это железо поддерживает до 1.5T RAM.

Да и насколько я знаю нейронки же через гпу работают

И на CPU работают, только мееееедленно. (%
Но мне торопиться некуда, накидал очередь и занимаюсь своими делами.

uv

$ du -hs ../_venv
196K	../_venv

$ du -hs ../.cache/uv
2.4G	../.cache/uv

АГОНЬ!

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