Рассмотрим следующую ситуацию. Вы работаете на линуксе с библиотеками HuggingFace на платформе Anaconda3. У вас есть два накопителя - маленький
Поиск в интернете дает несколько советов, но я приберегу их на конец поста, поскольку они имеют ограниченную применимость, а сначала расскажу про хак, до которого мне пришлось догадаться самостоятельно и который решает проблему радикально.
Этот хак - тупое перемещение директорий
Например:
Теперь перейду к советам из интернета.
1) Использовать опцию
2) Проверять состояние общежития под названием
3) Переустановить анаконду, заранее прописав ей путь на
4) Переустановить библиотеки huggingface, прописав им в конфигах нужные адреса для кэша (этого делать никогда не пробовала).
Минусы последних двух способов очевидны.
#хозяйке_на_заметку #библиотеки
system_drive (смонтированный в точке /) и большой storage_drive (смонтированный в /storage/). Домашняя папка /home/my_user/ живёт на system_drive. Чем дольше вы работаете, тем сильнее разбухают кэш HuggingFace и директория Anaconda3 в домашней папке, и с какого-то момента маленький диск так и норовит переполниться и сломать все расчеты. Что делать?Поиск в интернете дает несколько советов, но я приберегу их на конец поста, поскольку они имеют ограниченную применимость, а сначала расскажу про хак, до которого мне пришлось догадаться самостоятельно и который решает проблему радикально.
Этот хак - тупое перемещение директорий
~/anaconda3/ и ~/.cache/huggingface/ на storage_drive и создание символических ссылок на них там, где они лежали изначально.Например:
mv /home/my_user/anaconda3 /storage/Все. Больше ничего менять не нужно. Все скрипты с расчетами будут работать как раньше, анаконда и huggingface transformers будут вести себя как ни в чем ни бывало (главное, следить, чтобы
ln -s /storage/anaconda3/ /home/my_user/anaconda3
mv /home/my_user/.cache/huggingface /storage/
ln -s /storage/huggingface/ /home/my_user/.cache/huggingface
storage_drive всегда был смонтирован куда нужно и чтобы к нему были полные права доступа).Теперь перейду к советам из интернета.
1) Использовать опцию
cache_dir при скачивании тяжелой модели: model.from_pretrained(<model_name>, cache_dir=<cache_dir_name>). В этом случае модель будет скачиваться не в кэш-директорию по умолчанию ~/.cache/huggingface/models/, а в ту, которую вы укажете. Эта же опция работает для скачиваемых токенизаторов, датасетов и всего остального. При использовании этой опции приходится постоянно проявлять внимательность, т.к. если вы забудете ее проставить всего один раз для большой модели или датасета, главная кэш-директория будет беспощадно засрана. С другой стороны, эта полезная опция позволяет легко локализовать и разносить кэш, соответствующий конкретной модели или датасету, по разным дискам, регулируя нагрузку на них. Далее можно переносить скачанные сокровища на другие сервера - например, это может понадобиться, если у другого сервера есть проблемы с подключением к хабу huggingface, но при этом сохранена связь с рабочей сетью. Тогда можно скопировать папку с кэшем туда через scp и подцеплять кэш на том сервере опять через опцию cache_dir.2) Проверять состояние общежития под названием
~/anaconda3/envs/. Если окажется, что там поселились толстые жильцы (окружения с большим количеством пакетов), переселять их оттуда в /storage/. Главный недостаток: если у вас есть ядра юпитер ноутбука, завязанные на окружения анаконды, они сломаются от переноса окружений. Впрочем, это можно исправить, если после переноса вашего окружения (допустим, ~/anaconda3/envs/myenv) на другой диск оставлять на него символическую ссылку в ~/anaconda3/envs/ так же, как было описано выше. К сожалению, этот способ не поможет, если самым жирным в домике является основное окружение (base). 3) Переустановить анаконду, заранее прописав ей путь на
/storage/ во время установки.4) Переустановить библиотеки huggingface, прописав им в конфигах нужные адреса для кэша (этого делать никогда не пробовала).
Минусы последних двух способов очевидны.
#хозяйке_на_заметку #библиотеки