Nemotron 3.5 Embed 8B BF16: capacità, benchmark e limiti del deployment

Che cosa fa Nemotron 3.5 Embed 8B BF16

Nemotron-3.5-Embed-8B-BF16 è un modello di embedding di NVIDIA progettato per recuperare documenti a partire da query. Non genera risposte conversazionali: converte una query testuale e documenti di testo, immagini o una combinazione dei due in vettori che un sistema di ricerca può confrontare. Il flusso consueto consiste nell’indicizzare i documenti, salvare i vettori insieme al contenuto originale e calcolare il vettore di ogni query per individuare gli elementi pertinenti.

Il checkpoint non genera testo conversazionale: trasforma query testuali e documenti in formato testuale, immagine o misto in vettori per il retrieval. Gli esempi con Transformers, Sentence Transformers e vLLM producono vettori da 4.096 dimensioni, con normalizzazione L2. La matrice di supporto del servizio Embedding NIM indica invece 2.048 dimensioni per il modello 8B. Prima di creare l’indice, verifica la dimensione effettiva restituita dal servizio o dal runtime utilizzato.

La distinzione tra checkpoint e runtime ha conseguenze pratiche. In genere, una base vettoriale richiede che i vettori archiviati e quelli delle query abbiano dimensioni compatibili. È inoltre opportuno mantenere invariati la preparazione degli input, i prefissi di task e la normalizzazione: se questi elementi cambiano tra indicizzazione e ricerca, il confronto diretto potrebbe non essere più valido.

Come elabora testi e immagini

Il modello crea rappresentazioni vettoriali di query e documenti per attività di retrieval semantico. I documenti possono essere composti da testo, immagini di pagine o contenuti misti. Quest’ultima opzione consente di rappresentare elementi visivi — per esempio tabelle, grafici e infografiche — insieme al testo che li accompagna, senza trasformare il sistema in un generatore di risposte.

La scheda specifica che la query viene fornita come testo e che i documenti possono contenere testo, un’immagine o entrambi. Negli esempi, il modello applica prefissi diversi a seconda del task: «query:» per le query e «passage:» per i documenti. Mantenere questa convenzione e lo stesso runtime durante l’indicizzazione e la ricerca aiuta a evitare confronti incompatibili.

La scheda descrive anche un componente linguistico basato su Nemotron-3-Embed-8B, mantenuto congelato durante il fine-tuning multimodale. NVIDIA afferma che i due modelli condividono lo spazio degli embedding testuali e producono embedding di testo identici. Questa compatibilità riguarda il testo alle condizioni descritte per il checkpoint; non autorizza a combinare vettori di dimensioni o configurazioni diverse senza verificarli. L’integrazione deve mantenere coerenti modello, preparazione di query e documenti, normalizzazione e dimensione dell’indice.

Secondo la scheda, il checkpoint accetta input fino a 32.768 token. Nella configurazione descritta per il checkpoint, il lato più lungo predefinito delle immagini misura 1.120 pixel e può essere aumentato fino a 1.540. Questi limiti descrivono capacità di input, ma non garantiscono un recupero corretto per ogni documento lungo o visivamente denso.

Che cosa mostrano i benchmark pubblicati

La scheda di NVIDIA presenta risultati ottenuti su ViDoRe V3 e MIRACL-VISION, due benchmark di retrieval visivo. La metrica riportata è NDCG@10. La scheda descrive ViDoRe V3 come una valutazione del retrieval di documenti visivi e MIRACL-VISION come un dataset multilingue di retrieval visivo. Questi risultati riguardano le prove indicate da NVIDIA e non costituiscono una misura universale delle prestazioni su qualsiasi corpus.

Nei risultati pubblicati, Nemotron-3.5-Embed-8B-BF16 ottiene 60,39 su ViDoRe V3 per immagini, 60,65 per testo e 61,47 per immagini e testo. Su MIRACL-VISION per immagini ottiene 72,64. La scheda riporta anche risultati per Nemotron-3.5-Embed-1B-BF16 e Qwen3-VL-Embedding-8B. I punteggi consentono di confrontare questi modelli nelle condizioni della valutazione, ma non predicono direttamente la qualità del retrieval su una raccolta specifica.

La scheda indica che la valutazione del testo ha riguardato 34 lingue e quella delle immagini 18. Questo dato descrive le lingue valutate, non garantisce una qualità equivalente per ogni lingua, dialetto o tipo di documento. NVIDIA afferma che il modello potrebbe supportare anche altre lingue, ma queste non sono incluse negli insiemi di valutazione citati.

I risultati pubblicati da NVIDIA descrivono le valutazioni del fornitore, non una certificazione indipendente né una garanzia di prestazioni su altri corpus. Per decidere se il modello è adatto a uno specifico caso d’uso, un team può preparare un insieme di query e documenti propri e calcolare metriche di retrieval usando giudizi di rilevanza. Il confronto deve mantenere le stesse condizioni e distinguere questi risultati locali dai punteggi del fornitore.

Requisiti e configurazione del deployment

La scheda include esempi d’uso con Transformers, Sentence Transformers e vLLM. La documentazione di NeMo Retriever Embedding NIM specifica invece i requisiti di software, CPU e GPU per i relativi container ed elenca le configurazioni ottimizzate per ciascun modello. I requisiti di NIM non vanno confusi con quelli di ogni possibile modalità di esecuzione del checkpoint: ciascun runtime può avere compatibilità, valori predefiniti e limiti diversi.

Le configurazioni NIM ottimizzate per Nemotron 3.5 Embed 1B includono opzioni FP16, ma quella tabella non stabilisce le combinazioni supportate dal checkpoint 8B. La precisione di inferenza dipende dal modello, dal runtime e dalla GPU. Il suffisso BF16 identifica il checkpoint e non garantisce che un contenitore utilizzi la stessa precisione; prima di distribuire la variante 8B occorre verificarne la configurazione specifica.

La matrice NIM segnala che la selezione di kernel e precisione può dipendere dall’architettura rilevata e dalla configurazione del modello. Una configurazione di fallback può funzionare su alcuni dispositivi compatibili, ma la documentazione non garantisce che offra le stesse funzionalità o prestazioni di una configurazione ottimizzata. La possibilità di eseguire un modello non equivale alla convalida di quella combinazione di hardware e precisione in tutte le condizioni.

La licenza OpenMDW-1.1 stabilisce i termini di utilizzo del checkpoint. Non equivale a una tariffa di servizio né dimostra la disponibilità di uno specifico endpoint gestito. Il costo di un’installazione propria dipende dall’infrastruttura scelta, dal suo utilizzo e dal carico di inferenza.

Limiti e criteri di scelta

Il modello è progettato per il retrieval, non per generare testo, e il retrieval non garantisce che il documento selezionato sia corretto o sufficiente. La scheda del modello avverte che non sempre vengono recuperati i documenti corretti per una query. Nelle applicazioni in cui un errore può avere conseguenze importanti, è opportuno verificare i risultati sul contenuto originale e adottare controlli adeguati al contesto d’uso.

Il limite di 32.768 token non significa che qualsiasi documento di quella lunghezza possa essere elaborato senza perdita o recuperato con precisione. Se un input supera il limite del modello, l’esempio Transformers lo rifiuta e indica di abbreviare il testo o ridimensionare l’immagine; il comportamento può variare tra runtime. L’esempio vLLM per il server tronca il testo dalla fine e, se i token dell’immagine superano da soli il limite, indica di ridurne la risoluzione.

Per confrontare il modello 8B con la variante 1B o altre alternative, valuta le stesse query e gli stessi documenti in condizioni equivalenti. Registra anche la dimensione di output, la latenza e il consumo di risorse per ogni configurazione. I punteggi dei benchmark pubblicati possono orientare il confronto, ma non sostituiscono una prova sul corpus di destinazione e da soli non giustificano la conclusione che una variante sia migliore in ogni caso.

Nemotron-3.5-Embed-8B-BF16 può essere adatto quando un sistema deve rappresentare documenti visivi e testo in un flusso di retrieval e il team può sostenere e convalidare il deployment scelto. Prima di integrarlo in un indice esistente, verifica la compatibilità delle dimensioni e delle configurazioni. Se il caso d’uso riguarda solo il testo o richiede un consumo limitato di risorse, confronta le alternative con una valutazione locale, invece di presumere che un modello più grande offra sempre un vantaggio pratico.

Continua a esplorare

Correzioni e trasparenza

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