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

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

snapshot_download это официальная обертка над официальным huggingface-cli которая стягивает сразу весь репозитарий последней ревизии. Просто вопрос удобства, под капотом тоже самое.

Ну или как там в анаконде

Это не в анаконде, модели отдельно лежат, окружения - отдельно. Получается отношение many-to-many: одно окружение для многих моделей и многие окружения для одной модели (редко, но пригождается, в основном для определения что быстрее для инференса).

я её никогда не видел. (=

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

Ну или как там в анаконде

Это не в анаконде, модели отдельно лежат, окружения - отдельно

Это было в контексте установки huggingface-cli, не стянивания моделей.

вопрос удобства

У меня виртуалка изолирована от внешней сети, так что модели скачиваются кликом по иконке скачивания из git-lfs, и уже после заливаются в виртуалку по scp SFTP. А jail с LLM на FreeBSD, туда просто захожу по ssh и качаю из git-lfs с помощью штатной утилиты fetch(1).

Нет у нас никаких удобств, всё лапками! (=

А, я понял. У меня все проще, я к себе на железо тяну.

У меня оно наружу торчит, в интернеты, потому безопасность превыше удобств.

Я даже как-то (среди своих) объявлял вознаграждение за поиск уязвимостей, но ничего не нашли. (= Впрочем, тем, кто действительно мог, было не до того. Да и вознаграждение было весьма скромным для их профессиональной деятельности. (= За профессиональный аудит моей homelab меня жаба задушит насмерть. (=

У меня есть хомлаб, но порты наружу открываются только по праздникам. С 14 года постоянно щупают НОАК по очереди с АНБ. Причем АНБ так, для видимости, а китайские товарищи прям обстоятельно. А когда начинают ддосить соседи то вообще - всем полуостровом окукливаемся так что туннели загибает к товарищу майору.

Так у меня напрямую ничего не торчит. У меня даже белого IP нет. (%

У меня есть…

Соболезную. (%

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

зачем? просто отформатируй этот мусор.

кури qubes os :)

пихаеш в темплейт

запускаешь в диспоз

ps : у докера же похожее есть

pps: uv вроде чёт умеет в

qubes os

Оно влезет в 8G?

uv вроде чёт умеет в

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

Но всё равно пасиба. (=

если постараться то и 2Gb хватат

точнее на их форуме и в телеге

в целом имхо хватит uv/docker - сделать цепочку(дерево)доустанавливаемых пакетов - через контейнеры :(

если постараться то и 2Gb хватат

точнее на их форуме и в телеге

А на диске?

docker

И в каждом по жЫрному venv’у, ага. (%

Poetry. Но размер это не уменьшит

в репах арча вся эта хрень для датасосаенса есть

Poetry.

Это прожект менежмент, он как бы не упёрся для чужих проектов.

размер это не уменьшит

Задача стоит как раз именно в том, чтобы все N→100500 venv’ов для N/2 чужих проектов так сказать дедуплицировать. И с этим uv вроде бы справился. Я, правда, ещё не разобрался во всех тонкостях, но его uv pip install вполне ставит в venv нужное симлинками (можно хардлинками или даже простой толстый venv, крутится переменной) из $XDG_CACHE_HOME/uv, где общее хранилище всех версий.

До этого я вручную выяснял какие версии кому нужны, экспериментальным путём разруливал конфликты и выяснял, можно ли некоторые проекты гонять в одном venv, и если да, то клал всё в один venv, чтобы не занимать лишние ≈7G места под каждый из них. НО! Обновление одного из проектов вполне может сломать venv для других проектов банальным изменением версии torch.

Это всё совсем неудобно. А большинство предоставляют список зависимостей не в project-формате, а тупым requirements.txt, так что взяв Poetry мне ещё и прожект придётся писать… и переписывать его при каждом обновлении используемого проекта (в котором может оказаться не один requirements.txt под разные кейсы, плюс сабмодули со своими requirements.txt), которого в pip нет.

И все нужные версии Torch и компании? Мне нужны как минимум 2.6.0, 2.5.1, и это я ещё в requirements.txt сабмодулей не заглядывал.

Ну и конечно же арч это не про стабильность. Да и роллинг требует постоянного обновления, в то время как дебиан будет работать годами и почти без плясок потом успешно обновится на следующий релиз.

зашел написать про uv, но тут уже :-)

добавлю кроме uv ещё conda тоже типа должна экономить место (нет)

ещё conda тоже типа должна экономить место (нет)

Это мы уже успели выяснить, выше Obezyan рассказывал про вес своих venv’ов, и там с этим всё печально.

uv

Да, оно оказалось лучшим вариантом.

А ещё выяснилось что в некоторых проектах захардкожен pip, и при старте они начинают тащить всякое всё в активный venv. Кретины! >_<

Вообще если речь про ML-проекты, то надо всё в докеры собирать, и базовые библиотеки - в базовый образ. Иначе один фиг проекты будут хардкодить версии cuda/pytorch и т.п. кто во что горазд, и будут у тебя 10 venv с 9-ю разными версиями pytorch. А если будет один базовый образ, раз в пару месяцев обновляемый, будет общая точка для синхронизации версий.

надо всё в докеры собирать

Не надо! (=

Иначе один фиг проекты будут хардкодить версии cuda/pytorch и т.п. кто во что горазд, и будут у тебя 10 venv с 9-ю разными версиями pytorch.

Так не один только торч они тянут. Тут кэш uv весит 7.3G для двух venv’ов, а там два venv’а по ≈7.3G. Хотя я немножко обманул один venv по поводу версий, потому что то что проект тянет по умолчанию, немножко сломано.