Hugging Face ці GitHub Models: вялікія вагі мяняюць правілы сховішча

Для публікацыі ўласных вагаў мадэлі выбірайце Hugging Face Hub, а для кода і працэсу распрацоўкі — рэпазіторый GitHub. GitHub Models ужо закрыты: дакументацыя GitHub называе датай поўнага закрыцця 30 ліпеня 2026 года. Каталог мадэляў, пляцоўка для эксперыментаў і API гэтага сэрвісу больш недаступныя; для доступу да шырокага каталога GitHub накіроўвае ў Azure AI Foundry, а для працы з ШІ ў GitHub — да Copilot.

Вялікія вагі мяняюць практычнае рашэнне пра сховішча: месца для зыходнага кода ўжо не абавязкова падыходзіць для файлаў мадэлі. Калі праект выкарыстоўвае абедзве платформы, патрэбен яшчэ і агульны запіс пра рэліз: ён павінен паказваць, якія версіі кода, вагаў, даных і дэма працуюць разам. Без такой прывязкі файлы могуць быць даступныя, але вынік цяжка ўзнавіць.

Дзе месца коду, вагам і даным

GitHub падыходзіць для зыходнага кода, канфігурацый, тэстаў і гісторыі змен. Каманда можа звязваць выпраўленні з камітамі, разглядаць запыты на зліццё і вырашаць, якая версія праграмы ўвайшла ў выпуск. Назва закрытага сэрвісу GitHub Models не змяняе прызначэння звычайнага рэпазіторыя GitHub.

Hugging Face Hub дае асобныя рэпазіторыі для мадэляў і датасетаў. Вагі можна публікаваць разам з апісаннем мадэлі, а набор даных — весці з уласнай гісторыяй і дакументацыяй. Гэта карысна, калі некалькі мадэляў выкарыстоўваюць адзін датасет або код змяняецца без перанавучання: кожны артэфакт захоўвае сваю рэвізію, а сувязь паміж імі фіксуецца пры выпуску.

Размяшчэнне на Hugging Face само па сабе не азначае, што кожны артэфакт трэба адкрываць усім. Спачатку вызначце, ці дазваляюць правы на даныя і вагі іх распаўсюджваць, а затым выбірайце доступ да рэпазіторыя. Для закрытага праекта істотныя таксама ёмістасць сховішча і тое, хто атрымае доступ да файлаў; гэтыя пытанні нельга вырашыць адной пазнакай «прыватны».

Чаму памер вагаў уплывае на выбар

Правілы сховішча Hugging Face рэкамендуюць разбіваць вялікія файлы вагаў на часткі меншыя за 200 ГБ і трымаць менш за 10 тысяч элементаў у адной папцы. Гэта арыенціры для структуры рэпазіторыя, а не абяцанне неабмежаванага месца: загружаныя мадэлі і датасеты ўлічваюцца ў агульнай квоце ўліковага запісу. Пры падрыхтоўцы вялікага выпуску важны таму не толькі памер аднаго файла, але і сумарны аб’ём усіх версій.

Для звычайнага рэпазіторыя GitHub дзейнічае іншая мяжа: правілы GitHub абмяжоўваюць асобны аб’ект Git 100 МБ і раяць выкарыстоўваць Git LFS для бінарных файлаў. Git LFS можа быць дарэчным, калі камандзе патрэбныя вялікія файлы ў працэсе распрацоўкі на GitHub, але яго абмежаванні і выдаткі трэба ацэньваць асобна. Капіраваць кожную версію вагаў у гісторыю зыходнага кода без такой патрэбы нязручна: рэпазіторый цяжэй перадаваць і падтрымліваць.

Калі вагі складаюцца з некалькіх частак, іх трэба лічыць адным выпускам мадэлі, а не наборам незалежных файлаў. Апісанне рэлізу павінна паказваць рэвізію рэпазіторыя, у якой ляжаць усе патрэбныя часткі, і код, здольны іх загрузіць. Тады абнаўленне адной часткі не падменіць незаўважна мадэль, для якой быў выпушчаны астатні набор.

Калі патрэбны датасет і дэма

Датасет варта аддзяляць ад мадэлі, калі ў яго ўласныя правілы доступу, гісторыя выпраўленняў або кола карыстальнікаў. У апісанні выпуску мадэлі тады паказваюць дакладную рэвізію даных, выкарыстаных пры навучанні ці праверцы. Калі даныя змяніліся пасля выпуску вагаў, новая рэвізія датасета не павінна аўтаматычна выдавацца за даныя, з якіх гэтыя вагі атрыманы.

Для інтэрактыўнага паказу мадэлі прызначаны Hugging Face Spaces. Дакументацыя Spaces тлумачыць, што код дэма захоўваецца ў Git-рэпазіторыі, а рэжымы public, protected і private па-рознаму адкрываюць зыходны код і саму праграму. Напрыклад, protected хавае код ад старонніх, але пакідае працоўнае дэма даступным праз яго адрас; такі рэжым патрабуе адпаведнага платнага плана.

Space мае ўласную гісторыю змен, таму дэма можа абнавіцца незалежна ад вагаў. Каб паказ заставаўся звязаным з апублікаваным рэлізам, у яго канфігурацыі або апісанні трэба замацаваць рэвізію мадэлі. Калі дэма выкарыстоўвае закрытыя вагі ці даныя, асобна правяраюць, што адкрыты інтэрфейс не раскрывае тое, што не прызначана для публікацыі.

Рашэнне паводле артэфакта і доступу

Пачынайце з таго, што менавіта трэба выдаць іншым. Такое рашальнае дрэва захоўвае розніцу паміж сховішчам файлаў мадэлі і працэсам распрацоўкі:

• Калі ёсць толькі код, канфігурацыі і невялікія тэставыя прыклады, вядзіце іх на GitHub. Асобны рэпазіторый мадэлі з’явіцца, калі будуць вагі, якія трэба захоўваць і распаўсюджваць.
• Калі трэба публікаваць вагі, асабліва вялікія, размяшчайце іх у рэпазіторыі мадэлі на Hugging Face. Код навучання або прымянення пакідайце на GitHub і звязвайце яго рэліз з рэвізіяй вагаў.
• Калі датасет выкарыстоўваецца незалежна ад адной мадэлі, дайце яму асобны рэпазіторый і версію. Для закрытых даных спачатку вызначце правы доступу і неабходную ёмістасць.
• Калі карыстальніку патрэбна працоўнае дэма, стварыце Space і прывяжыце яго да канкрэтнай мадэлі. Калі дастаткова кода і аўтаматычных праверак, асобнае дэма не патрабуецца.

Магчымы і больш просты выбар. Калі распаўсюджванне вагаў забаронена, іх месца вызначаюць патрабаванні да доступу і захоўвання, а не зручнасць публічнага каталога. Калі каманда выпускае толькі праграму для працы з чужой мадэллю, уласны рэпазіторый вагаў ёй не патрэбны; важна зафіксаваць мадэль і яе версію як залежнасць праграмы.

Адна крыніца версіі для сумеснага рэлізу

Сувязь паміж рэпазіторыямі патрабуе асобнага правіла. Даследаванне сінхранізацыі ахапіла 325 сямействаў моўных мадэляў і выявіла выпадкі, калі абнаўленні на GitHub і Hugging Face былі ўзгодненыя толькі часткова. У вывучанай выбарцы асобныя выпраўленні заставаліся на адной платформе, таму карыстальнік мог атрымаць код, апісанне і вагі з розных станаў праекта.

Для ўласнага праекта вызначце адну крыніцу рашэння пра выпуск — напрыклад, зацверджаны рэліз кода на GitHub. Побач з ім захоўвайце маніфест: ідэнтыфікатар каміта кода, дакладную рэвізію мадэлі, рэвізію датасета, калі ён уваходзіць у выпуск, і рэвізію Space, калі ёсць дэма. Апісанні на Hugging Face могуць спасылацца на гэты запіс, але не павінны самастойна задаваць іншую камбінацыю «актуальных» файлаў.

Перад абвяшчэннем выпуску падрыхтуйце патрэбныя вагі і даныя, запусціце код з указанымі рэвізіямі і абнавіце дэма, калі яно ўваходзіць у выпуск. Умоўны прыклад: пасля выпраўлення скрыпту папярэдняй апрацоўкі мадэль яшчэ не перанавучалі. Каміт кода ўжо новы, рэвізія вагаў ранейшая — і маніфест павінен паказваць менавіта гэтую пару, пакуль не будзе выпушчаны наступны ўзгоднены набор.

Чытайце таксама:

• Cursor ці GitHub Copilot: тып задачы важнейшы за агульны рэйтынг
• GitHub Copilot атрымаў чатыры мадэлі і лакальную пясочніцу
• GitHub Actions без ключоў AWS: адна ўмова не пусціць чужы рэпазіторый