La vera svolta del modello open source cinese è la rete di collaborazione

Quando si parla di “se sarà sigillato” nel modello open source, la cosa più semplice da considerare è considerare il file del peso come tutto.

Dopo aver scaricato i pesi, il modello stesso spesso non scompare così facilmente. Ciò che è più facile da violare per primo è la rete che ruota attorno ad esso: siti mirror, set di valutazione, modelli di inferenza, script di messa a punto, soluzioni di problemi, parametri di distribuzione predefiniti e il consenso nella comunità secondo cui “questa versione può essere eseguita e quella versione non deve essere modificata”.

La parte che può toccare il suolo ha meno paura di rompersi.

Finché un modello open source è entrato in un magazzino locale, in un object storage o in un’immagine intranet, non importa quanto sia stretto il mondo esterno, il file di solito sarà ancora lì. Copie offline, cache interne e prodotti di build storici ritarderanno a lungo la questione “se può ancora essere utilizzato”.

Questa è anche la più grande differenza tra il modello open source e i servizi cloud puri. Una volta bloccato un servizio cloud, spesso l’accesso viene meno; anche se il servizio upstream del modello open source viene interrotto, i pesi, il tokenizzatore e l’immagine di inferenza in mano possono continuare a funzionare. La domanda non è “ce l’hai?” ma “puoi continuare ad usarlo allo stesso modo degli altri?”

Ciò che è veramente interessante è la relazione di sincronizzazione

Solo perché il modello può continuare a funzionare, non significa che il team possa continuare a stargli dietro.

Le prime cose da allentare sono solitamente le relazioni di sincronizzazione:

• L’upstream ha rilasciato una nuova versione, ma il mirror interno non è riuscito a tenere il passo in tempo.
• Il set di valutazione è stato rivisto e i risultati della regressione non possono più essere allineati con i vecchi record.
• Il modello di chat o il tokenizzatore è stato leggermente spostato, ma lo stile di output è cambiato molto.
• Una certa correzione è entrata solo nelle PR della comunità, non nell’immagine della intranet aziendale
• La quantizzazione predefinita, la lunghezza del contesto predefinita e i parametri di campionamento predefiniti vengono spostati l’uno dall’altro.

Queste cose non sembrano grandi da sole, ma impilarle insieme spezzerà lo “stesso modello” in più parti.

In questa fase, il vero danno causato dalle restrizioni esterne non è cancellare dal mondo un documento ponderato, ma spezzare il fatto che “tutti guardano la stessa cosa”. Il team parla ancora dello stesso nome del modello, ma quello che in realtà ottiene è un pacchetto combinato con versioni diverse, modelli diversi e parametri diversi.

Recensioni, correzioni ed esperienza verranno suddivisi insieme

Una volta che un modello open source entra nel flusso di lavoro reale, il valore reale solitamente non è il peso in sé, ma il giudizio accumulato attorno al peso.

Quale versione è più stabile, quale tokenizzatore interromperà il testo lungo, quale insieme di parametri di campionamento è più adatto agli scenari del servizio clienti, quale script di messa a punto aumenterà l’illusione, tutte queste esperienze si basano sullo scambio continuo. Finché persiste la rete di collaborazione, tutti possono ancora armeggiare attorno alla stessa linea di base; una volta interrotta la rete di collaborazione, ogni squadra svilupperà lentamente la propria versione privata.

Le versioni private non sono una brutta cosa, ma il prezzo aumenta:

• Il ritorno ai valori di base diventa sempre più difficile da riutilizzare
• La revisione degli incidenti diventa sempre più difficile da allineare
• Risolto il problema con la patch che diventava sempre più difficile da sincronizzare
• Lo stesso problema apparirà ripetutamente in squadre diverse

In questo momento, sembra che “il modello sia ancora lì”, ma in realtà sono diventate “molte copie locali appena utilizzabili” e non esiste un percorso di aggiornamento comune tra loro.

Ciò di cui vale veramente la pena preoccuparsi non è il blocco, ma la biforcazione

Il modello open source è difficile da sigillare completamente come un’API online perché la replicabilità è presente. Ciò di cui dovremmo davvero essere cauti è che, dopo che la pressione esterna interrompe la distribuzione, la riparazione e la collaborazione, il modello inizia a divergere lungo i ritmi delle diverse organizzazioni.

Una volta che ci sono più fork, non è più la questione “può essere scaricato?” ma “chi può garantire che si tratti sempre dello stesso tipo di cose?” Questa questione aumenterà direttamente il costo di accesso: nuove revisioni devono essere rifatte, vecchi errori devono essere rispiegati, le differenze di versione devono essere riorganizzate e il team deve elaborare le proprie strategie di rollback e congelamento per ogni linea biforcuta.

La resilienza del modello open source è infatti più forte di quella dei servizi cloud puri; ma anche la sua vulnerabilità è molto chiara, non se sia stato tolto peso, ma se la rete di collaborazione possa continuare a mantenere lo stesso nome della stessa cosa.