Nadat het open source-model openbaar is gemaakt, is het versieslot het eerste dat kwetsbaar wordt.

Nadat een open source-model openbaar is gemaakt, wordt meestal de vaste versie als eerste losgemaakt, terwijl het gewichtsbestand vaak het meest stabiel is.

De magazijnnaam is er nog steeds, en de modelnaam is er nog steeds, maar de daadwerkelijke invoer die wordt gebruikt om evaluaties uit te voeren, regressies uit te voeren en verkeer te verbinden is vaak niet hetzelfde. Wat we vandaag hebben opgehaald is main, en het zal volgende week nog steeds hetzelfde pad zijn, maar de tokenizer, het sjabloon, het kwantiseringspakket, het standaard dtype en zelfs de aanbevolen parameters in de README zijn gewijzigd. Wat u online ziet, is niet “het model verdwijnt”, maar “dezelfde modelnaam wordt een ander product”.

Nadat u de toegang tot het model verschillende keren heeft overgenomen, zult u merken dat de waarde die het gemakkelijkst kan worden genegeerd de standaardwaarde is. Het gewichtsbestand wordt meestal door iemand bekeken, maar de standaardtag, de standaardafbeelding, het standaardsjabloon en de standaardcachemap worden vaak onbeheerd achtergelaten. Wanneer een synchronisatievenster vastloopt, of het spiegelstation alleen de gewichten synchroniseert, maar niet de configuratie, zal het team plotseling merken dat wat ze in handen hebben geen reproduceerbare versie is, maar een reeks drijvende namen.

De standaardingang is gemakkelijker te drijven dan het gewicht.

Het gewichtsbestand is statisch, de invoer niet.

model-name:latest Deze manier van schrijven lijkt eenvoudig, maar het probleem is dat de kwestie “wanneer moet worden bijgewerkt” aan de buitenkant wordt overgelaten. Als de upstream de tokenizer wijzigt, een chatsjabloon toevoegt of het kwantificeringspakket opnieuw typt, zal het gedrag van de toegangspartij dienovereenkomstig veranderen. De evaluatiescores fluctueren misschien maar een klein beetje, maar de online output zal stilletjes van toon veranderen. Het meest martelende deel bij het oplossen van problemen is hier: alles ziet er normaal uit in het logboek, maar in feite wordt er een andere ingang aangeroepen.

Wat echt ongemakkelijk is, is niet de verandering zelf, maar het feit dat de verandering geen grenzen kent. Zolang de naam ongewijzigd blijft, kunnen regressie-, grijswaarden- en ongevalbeoordeling zich alleen op de resultaten concentreren en de redenen raden. De modelnaam blijft daar hangen, maar het team kan niet bevestigen of het product dat ze vandaag hebben gekregen hetzelfde product is als het product dat vorige week in de basislijn draaide.

Afbeeldingen, sjablonen en kwantiseringspakketten moeten samen worden bevroren

Alleen het gewicht vergrendelen is niet voldoende.

Nadat een open source-model daadwerkelijk in de workflow terechtkomt, bevat het meestal meer dan één .bin of .safetensors. Het bevat ook een tokenizer, een chatsjabloon, parameters voor het inferentiekader, kwantificeringsbestanden, downloadafbeeldingen, opstartscripts en cachepaden. Als een van hen afdwaalt, kan dit uiteindelijk aantonen dat “het model slechter is geworden”. Sterker nog: vaak verandert niet het model, maar het leveringspakket.

model:
  repo: example/model
  revision: 8f3c1a2
  tokenizer_revision: 8f3c1a2
  cache_dir: /opt/model-cache

Dit type configuratie lijkt uitgebreid, maar resulteert in drie dingen: de afbeelding is verantwoordelijk voor de beschikbaarheid, het versienummer en de hash zijn verantwoordelijk voor de reproduceerbaarheid, en het opstartscript is verantwoordelijk voor consistente gevolgtrekkingsparameters. Zonder een van deze lagen kan het zogenaamde ‘reeds publieke’ model slechts als een halffabrikaat worden beschouwd. Voor de toegangspartij is het niet van belang of het gedownload kan worden, maar of de gedownloade content drie weken later nog steeds hetzelfde resultaat kan opleveren.

Wat echt behouden moet blijven, is het vermogen om zich voort te planten

Nadat het open source-model openbaar is gemaakt, is wat het team moet beschermen niet een mysterieuze ingang, maar de reproduceerbaarheid.

Zodra de reproduceerbaarheid wordt onderbroken, zal de evaluatiebasislijn afwijken, zullen de A/B-resultaten vervormd zijn en zal de toevallige weergave de referentie verliezen. Tegen de tijd dat iedereen het probleem bespreekt met de uitspraak “vorige week was het normaal”, is het versiebeheer feitelijk mislukt. Het heeft op dit moment niet zoveel zin om over modelmogelijkheden te praten; alleen door het aanscherpen van de vaste versie, beeldsynchronisatie, hash-verificatie en rollback-pad kunnen we gekwalificeerd zijn om over het effect te blijven praten.

Dit type model lijkt meer op een softwareartefact dan op een webservice. Als de webpagina kapot is, kun je nog steeds 500 zien, en de modelversie wijkt af, en in veel gevallen zal deze slechts langzaam veranderen in de uitvoer. Op het eerste gezicht heeft het nog steeds dezelfde naam, maar in feite is de helft van het systeem veranderd.