Bolmo 1B Stage 1 e Bolmo 7B Stage 1: protocollo per l’inferenza locale e la valutazione della rappresentazione a byte

Rappresentazione a byte: dai token subword alla codifica UTF-8

La maggior parte dei modelli linguistici opera su unità discrete chiamate token. In genere, questi vengono ricavati dal testo con metodi di tokenizzazione subword, come BPE o WordPiece. È un approccio efficace, ma può nascondere dettagli a livello di singolo carattere. Questo è un limite per dati scientifici, codice e sequenze biologiche, in cui la distinzione tra caratteri può essere determinante. Bolmo, sviluppato da Ai2, è una famiglia di modelli linguistici che opera direttamente sui byte della codifica UTF-8, senza dipendere da un vocabolario subword specifico per lingua o dominio.

La conversione di Bolmo avviene in due fasi: un modello subword esistente viene trasformato in un modello a byte con un addestramento aggiuntivo contenuto. Il repository del progetto descrive i checkpoint Stage 1 come modelli in cui si addestrano i componenti locali di codifica e decodifica a byte, mantenendo congelato il modello globale. Operare sui byte può essere utile nei compiti che richiedono informazioni precise sui caratteri e consente di rappresentare direttamente il testo codificato in UTF-8. Queste proprietà architetturali, tuttavia, non dimostrano da sole che il modello gestisca meglio ogni carattere raro, lingua o compito concreto: per verificarlo servono prove nel contesto d’uso previsto.

Per una valutazione tecnica, è importante distinguere l’unità rappresentata dalle prestazioni effettive. Un modello a byte non usa token subword come unità di ingresso, ma la sua velocità non si può confrontare correttamente con quella di un modello tokenizzato contando soltanto token generati al secondo. La quantità di byte e token elaborata, la lunghezza del contesto e il metodo di misurazione devono essere esplicitati. Anche la generazione con Bolmo usa una convenzione particolare: nel codice di esempio del repository, `max_new_tokens` indica il numero massimo di byte da generare.

Il lavoro di ricerca presenta Bolmo come una famiglia di modelli a byte e descrive la conversione in due fasi. Il repository ufficiale elenca inoltre i checkpoint Stage 1, le rispettive dimensioni e i modelli di base. Queste informazioni permettono di descrivere la configurazione e di impostare un test locale; non forniscono, però, valori universali di memoria, latenza o throughput per ogni dispositivo e configurazione.

Hardware e memoria: cosa si può stimare e cosa no

I checkpoint Bolmo 1B Stage 1 e Bolmo 7B Stage 1 elencati nel repository hanno rispettivamente 1,5 miliardi e 7,6 miliardi di parametri. I modelli di base indicati sono OLMo 2 1B per la variante 1B e Olmo 3 7B per quella 7B. La differenza di dimensione è un elemento utile per pianificare una prova, ma non basta per stabilire la quantità di VRAM o RAM necessaria a un’inferenza efficiente. Le fonti primarie disponibili non pubblicano requisiti minimi esatti per questi checkpoint Stage 1.

Una stima iniziale dei pesi si può ricavare dal numero di parametri e dal formato numerico, ma rappresenta soltanto una parte del fabbisogno. La memoria effettiva dipende anche dalla precisione utilizzata, dalla lunghezza del contesto, dalle dimensioni del batch, dalla cache dei valori e delle chiavi e dalle implementazioni del software. Se il modello non entra in VRAM, l’offload sulla RAM può consentire di avviare un test, ma può modificarne sensibilmente la latenza. Perciò una soglia generica di memoria non va presentata come requisito ufficiale né come garanzia di funzionamento efficiente.

Anche la dicitura Stage 1 va interpretata con precisione. In questa fase si apprendono i parametri dei nuovi componenti locali a byte, mentre il modello globale rimane congelato. Non significa che il modello abbia meno parametri da caricare: le dimensioni riportate sono 1,5B e 7,6B. Non permette neppure di concludere, senza misure, quale variante sarà più veloce o quale avrà prestazioni migliori su uno specifico compito. La scelta tra i due modelli deve partire dai vincoli del dispositivo e dai risultati di un test ripetibile.

Per una prima prova, registrate la configurazione completa: modello e checkpoint, GPU e quantità di VRAM, RAM disponibile, sistema operativo, versioni di PyTorch e Transformers, precisione, lunghezza della sequenza e dimensione del batch. Annotate separatamente il tempo di caricamento, l’uso di memoria durante il prompt e quello durante la generazione. In questo modo, un risultato ottenuto su un dispositivo non viene scambiato per una specifica valida in ogni ambiente.

Privacy e isolamento dei dati

Eseguire l’inferenza su infrastruttura controllata può ridurre la necessità di inviare prompt e dati a un servizio esterno. È un’opzione da valutare quando il carico di lavoro contiene informazioni sensibili o deve rispettare vincoli di trattamento specifici. La privacy, però, non è garantita automaticamente dal fatto che il modello venga eseguito in locale: contano anche la telemetria del software, i log, le autorizzazioni di accesso, la conservazione dei prompt, i backup e le connessioni di rete.

La rappresentazione a byte elimina il passaggio della tokenizzazione subword, ma non rimuove ogni fase di preparazione dei dati. Il testo deve essere codificato correttamente; inoltre, il caricamento del modello e la generazione devono essere configurati e monitorati. La possibilità di rappresentare caratteri tramite UTF-8 non equivale a una prova di maggiore accuratezza su tutte le lingue o su ogni carattere non standard. Questi aspetti vanno inclusi nei test, insieme alla verifica di come il sistema tratta caratteri insoliti, stringhe miste e input malformati.

Per un’installazione locale, stabilite prima del test se il modello può essere scaricato durante l’installazione oppure se i pesi devono essere trasferiti tramite un processo approvato. Una volta preparato l’ambiente, verificate che prompt, risposte ed errori non vengano copiati in log accessibili o inviati a sistemi esterni. L’esecuzione sul dispositivo offre controllo sull’ambiente, ma richiede comunque procedure di sicurezza e governance adeguate.

Un test utile con dati sensibili dovrebbe essere eseguito inizialmente su esempi sintetici o anonimizzati. Dopo aver verificato il percorso dei dati e i log, si può passare a un campione autorizzato e minimizzato, se le policy interne lo consentono. Questo approccio separa due domande diverse: se il checkpoint riesce a elaborare gli input richiesti e se l’intero sistema locale rispetta i requisiti di riservatezza.

Protocollo pilota: confronto in condizioni equivalenti

L’obiettivo del pilota è misurare la fattibilità operativa di Bolmo 1B Stage 1 e Bolmo 7B Stage 1 nell’ambiente in cui potrebbero essere distribuiti, non stabilire quale modello sia migliore in assoluto. Il repository ufficiale documenta i nomi dei checkpoint e include un esempio di inferenza con Transformers. Le istruzioni richiedono di predisporre PyTorch secondo il sistema operativo e l’hardware; alcune dipendenze, come `flash-attn` e `xlstm`, sono facoltative o dipendono dalle funzionalità utilizzate.

Prima di avviare il confronto, definite un insieme di prompt fisso e un protocollo identico per entrambi i checkpoint. Usate lo stesso dispositivo, la stessa precisione, la stessa lunghezza dei prompt, lo stesso criterio di generazione e impostazioni equivalenti. Non confondete il numero massimo di unità generate: nel codice di esempio di Bolmo `max_new_tokens` è riferito ai byte. Se confrontate Bolmo con un modello subword, registrate separatamente byte e token e spiegate il metodo di conteggio.

Misurate il tempo necessario a caricare il modello, la latenza prima del primo byte generato e il tempo complessivo di generazione. Per il throughput, riportate byte al secondo e, se avete una conversione di testo definita e riproducibile, anche caratteri al secondo. Registrate il picco di VRAM e RAM, specificando se la memoria è stata misurata durante il caricamento, la precompilazione, l’elaborazione del prompt o la generazione. Ripetete ogni prova e indicate il numero di esecuzioni, l’eventuale riscaldamento e la variabilità osservata.

Per valutare la robustezza ai caratteri, includete prompt con accenti, alfabeti differenti, simboli tecnici e stringhe di codice. Stabilite prima cosa considerare un esito corretto: una risposta scorretta o una sequenza malformata non andrebbe classificata semplicemente come un problema di latenza. Mantenete separati i risultati prestazionali e quelli qualitativi. Le prove pubbliche disponibili non consentono di assegnare un vincitore sulla qualità di generazione delle due varianti Stage 1.

Conservate un registro delle versioni, dei parametri e degli errori. Se un modello non si avvia, distinguete tra problemi di installazione, incompatibilità di una dipendenza e insufficienza di memoria. Questo rende il test ripetibile e impedisce di attribuire all’architettura un problema causato dalla configurazione.

Lacune nelle prove e limiti del confronto

Le informazioni disponibili consentono di affermare che Bolmo 1B Stage 1 ha 1,5 miliardi di parametri e deriva da OLMo 2 1B, mentre Bolmo 7B Stage 1 ha 7,6 miliardi di parametri e deriva da Olmo 3 7B. Il repository del progetto specifica inoltre che Stage 1 addestra i componenti locali a byte mantenendo congelato il modello globale. Questi dati descrivono configurazione e procedura, ma non forniscono requisiti precisi di memoria né risultati di latenza controllati per una macchina locale specifica.

Il lavoro di ricerca è la fonte primaria per l’inquadramento di Bolmo e per il metodo di conversione in due fasi. Il materiale disponibile non basta, invece, per dedurre valori universali di latenza e throughput per i checkpoint Stage 1, né per stabilire come si comportino su ogni attività o hardware. Non sono quindi giustificate conclusioni definitive sulla qualità comparativa delle due varianti o sulla loro superiorità rispetto a modelli subword in un carico di lavoro non specificato.

La natura di Stage 1 è rilevante per interpretare i risultati: il modello globale non è stato aggiornato in quella fase, mentre sono stati addestrati i componenti locali. Non bisogna equiparare automaticamente queste varianti ai checkpoint sottoposti anche alla fase successiva, né presumere che la qualità di generazione sia la stessa. Per sostenere una conclusione su un compito concreto servono benchmark adeguati e prove ripetibili, con metriche e condizioni dichiarate.

Quando condividete i risultati del pilota, indicate il dispositivo e il software utilizzati, la configurazione di generazione, il metodo di conteggio e le misure raccolte. Segnalate chiaramente ciò che è osservato nel vostro ambiente e ciò che non è documentato dalle fonti pubbliche. In assenza di test empirici comparabili, la scelta fra 1B e 7B deve restare una decisione basata sui vincoli operativi e sui requisiti del carico di lavoro, non un giudizio generale sulla qualità.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.