Nemotron 3.5 Embed 1B BF16: capacità, limiti e costi

Che cosa fa esattamente il modello

Nemotron-3.5-Embed-1B-BF16 è un modello di embedding da 1,55 miliardi di parametri progettato da NVIDIA per il recupero di documenti multimodale e multilingue. Può generare embedding di documenti in formato testuale, come immagine di una pagina oppure combinando immagine e testo. Le query, invece, devono essere testuali: il modello non accetta immagini come query di ricerca.

La scheda del modello descrive un encoder visivo Pixtral, inizializzato a partire da Ministral-3-3B-Instruct-2512-BF16, e una componente linguistica inizializzata da Nemotron-3-Embed-1B-BF16. NVIDIA dichiara che il modello è stato distillato da Nemotron-3.5-Embed-8B-BF16 mantenendo congelata la componente linguistica. Secondo la documentazione, ciò consente di condividere lo spazio degli embedding testuali con Nemotron-3-Embed-1B, aggiungendo la capacità di recuperare documenti visivi. Questa descrizione dell’architettura proviene dal produttore; non equivale a una verifica indipendente delle prestazioni o dell’interoperabilità degli embedding.

Il modello restituisce per ogni elemento un vettore di 2.048 dimensioni, ottenuto tramite pooling degli stati nascosti e normalizzazione L2. La documentazione del modello indica che è possibile troncare il vettore a dimensioni inferiori, per esempio 1.024 o 512, e normalizzarlo nuovamente. Il supporto NIM documenta richieste dinamiche da 128 a 2.048 dimensioni. Se si riduce la dimensione, occorre verificare la qualità sul proprio corpus e usare la stessa configurazione per documenti e query.

La finestra massima dichiarata è di 32.768 token e include testo e token associati alle immagini. Per le immagini, la scheda indica un lato maggiore predefinito di 1.120 pixel, aumentabile fino a 1.540. Più risoluzione può preservare dettagli utili in tabelle e scansioni, ma può anche aumentare il consumo di contesto e il costo di calcolo.

Capacità ed esempi per attività

Il caso d’uso più naturale è la ricerca su raccolte in cui il contenuto significativo non si trova soltanto nel testo estratto. Una pagina di PDF può includere grafici, tabelle, layout a colonne o infografiche che un OCR appiattisce o interpreta in modo incompleto. Invece di convertire sempre ogni pagina in testo, si può indicizzare l’immagine della pagina, il testo estratto oppure entrambi; al momento della ricerca, si codifica la query testuale e si confronta il vettore con quelli dei documenti.

Il modello è un bi-encoder: query e documenti vengono trasformati separatamente in vettori, che possono poi essere confrontati in un archivio vettoriale. Questo approccio permette di preparare gli embedding dei documenti prima delle query, ma il risultato è una graduatoria di candidati, non una risposta verificata. Per applicazioni che richiedono precisione, è opportuno valutare un reranker o un’altra fase di controllo dopo il recupero iniziale.

I prefissi sono parte del formato di input previsto: usare `query:` per le query e `passage:` per i documenti. Negli esempi ufficiali si confronta una query testuale con documenti testuali, immagini di pagina e combinazioni di immagine e testo. I punteggi di similarità mostrati nella scheda illustrano il funzionamento su un esempio specifico; non sono un benchmark generale e non dimostrano che una modalità prevalga sempre sulle altre.

Quando si indicizza un’immagine insieme a testo OCR o a una descrizione, va deciso con attenzione che cosa rappresenta quel testo. Può integrare dettagli non leggibili nell’immagine, ma può anche introdurre errori OCR o informazioni ridondanti. La configurazione migliore dipende dal tipo di documento, dalla qualità delle scansioni e dalle query reali; i risultati vanno confrontati su esempi del proprio dominio.

Benchmark e metodologia pubblicata

NVIDIA presenta risultati su ViDoRe V3, un benchmark di recupero di documenti visivi, e MIRACL-VISION, un insieme multilingue per il recupero visivo. La metrica riportata è NDCG@10: valuta l’ordinamento dei risultati nelle prime dieci posizioni, tenendo conto della rilevanza. Non è una misura universale della qualità di un sistema RAG e non informa da sola sulla latenza, sul costo o sulla correttezza delle risposte generate.

La scheda riporta quattro configurazioni di confronto e specifica impostazioni diverse per le immagini: il modello Nemotron è stato valutato con il lato maggiore predefinito di 1.120 pixel, mentre Qwen3-VL-Embedding-2B e Qwen3-VL-Embedding-8B sono stati valutati con `max_pixels` pari a 1.843.200. Questa differenza è importante: il confronto pubblicato non usa necessariamente lo stesso trattamento delle immagini per tutti i modelli. NVIDIA non fornisce, nella documentazione qui verificata, tutti i dettagli necessari per riprodurre integralmente il benchmark.

I punteggi seguenti sono dichiarati dal produttore. Non risultano, nelle fonti verificate per questa analisi, risultati riprodotti in modo indipendente sul medesimo protocollo. La tabella permette di leggere i valori riportati, ma non basta a concludere che il modello sarà migliore su ogni lingua, tipo di documento o distribuzione di query. Il modello da 8B della stessa famiglia ottiene punteggi più alti in tutte le colonne mostrate; l’eventuale vantaggio va bilanciato con requisiti e costi di deployment che dipendono dalla configurazione concreta.

Per un confronto interno corretto, mantenere invariati corpus, query, criteri di rilevanza, risoluzione delle immagini, dimensione dei vettori e normalizzazione. Registrare anche la versione del modello e dello stack software. Separare il recupero iniziale dal reranking consente di capire se un errore nasce dall’assenza del documento tra i candidati o dal suo ordinamento scorretto.

Prezzo e requisiti di deployment

I pesi sono pubblici su Hugging Face. L’uso è regolato dalla licenza OpenMDW 1.1; la disponibilità dei pesi non significa che siano privi di condizioni, quindi occorre leggere i termini applicabili, conservare gli avvisi richiesti e verificare gli obblighi per il proprio impiego. La scheda indica inoltre che alcuni modelli di base Ministral sono soggetti alla licenza Apache 2.0: la licenza delle componenti di base non sostituisce quella dichiarata per l’uso del modello distribuito.

Non è stata verificata una tariffa API ufficiale NVIDIA per questa variante. Di conseguenza non è corretto attribuire al modello un prezzo per token o presentare un prezzo di un servizio di terze parti come tariffa ufficiale. Nel deployment autonomo, i costi dipendono da GPU, memoria disponibile, utilizzo, dimensione dei batch, risoluzione delle immagini, throughput richiesto e gestione operativa. Anche un checkpoint scaricabile comporta costi infrastrutturali e di manutenzione.

La documentazione NIM elenca più GPU supportate, ma le configurazioni ottimizzate variano per modello e precisione. Per il checkpoint BF16, il nome indica la precisione dei pesi, non una modalità d’inferenza BF16 esplicitamente supportata da NIM: la documentazione specifica che il checkpoint denso viene eseguito con FP16. Per selezionare quella configurazione, NIM richiede il nome del modello e `NIM_ENGINE_PRECISION=fp16`; la documentazione avverte di non impostare `bf16` come precisione esplicita.

La matrice NIM documenta configurazioni ottimizzate FP16 per A100 80 GB, H100 80 GB, H100 NVL, L40S, A10G e GB10, oltre a FP16 e NVFP4 per alcune GPU Blackwell, tra cui GB200, B300 e RTX PRO 6000 Blackwell Server Edition. L’elenco va letto come insieme di configurazioni validate nella versione documentata, non come garanzia che ogni combinazione di GPU, runtime e precisione offra lo stesso comportamento o prestazioni equivalenti.

Limiti, sicurezza e alternative

Il limite di 32.768 token si applica al checkpoint, ma non va confuso con il valore di default del server. La documentazione NIM indica che il deployment `nemotron-embed` imposta `NIM_PIPELINE_MAX_SEQ_LEN=32768`; se la variabile non viene impostata, il server può ricadere su 512. Un operatore può scegliere un limite inferiore, ma un override non estende il massimo supportato dal checkpoint. Inoltre, per i dispatch di testo esiste un budget di token distinto che non riduce il limite di lunghezza per singola riga.

Le immagini competono con il testo per il contesto condiviso e possono essere rappresentate con un numero di token che dipende dalla loro risoluzione e dal preprocessing. Se immagini o testi superano la finestra disponibile, occorre ridimensionare o suddividere il materiale con una strategia coerente. Il taglio automatico del testo, per esempio dall’inizio o dalla fine, può eliminare informazioni necessarie alla ricerca; verificare il comportamento effettivo del runtime e la semantica dell’API.

La scheda del modello avverte che il sistema non garantisce di recuperare sempre i documenti corretti. La stessa documentazione dichiara che non sono state indicate misure specifiche di mitigazione del bias e che non è applicabile una metrica di bias. Per impieghi in ambiti sensibili, questo rende necessarie valutazioni separate su dati rappresentativi, gruppi interessati, errori di recupero, privacy e uso improprio; non basta affidarsi ai benchmark generali.

NVIDIA raccomanda inoltre di verificare i diritti e i permessi relativi ai contenuti immagine usati in input. Le immagini possono contenere informazioni personali, sanitarie o materiale protetto. L’elaborazione da parte del modello non conferisce automaticamente il diritto di usare quei contenuti né costituisce una misura di anonimizzazione.

Tra le alternative citate nel confronto del produttore figurano Qwen3-VL-Embedding-2B e Qwen3-VL-Embedding-8B; la stessa famiglia include Nemotron-3.5-Embed-8B. I risultati pubblicati possono aiutare a scegliere i candidati da testare, ma non dimostrano quale sia il migliore per un corpus specifico. Per raccolte esclusivamente testuali, un encoder testuale può risultare più semplice da gestire; la scelta va misurata sul carico effettivo, senza trasferire automaticamente a una variante capacità o prestazioni documentate per un’altra.

Criteri pratici per decidere

Nemotron-3.5-Embed-1B-BF16 è un candidato da valutare quando il corpus comprende molte pagine visive e si vuole interrogare il contenuto senza dipendere esclusivamente dal testo OCR. È particolarmente pertinente se tabelle, grafici, layout o scansioni hanno un ruolo centrale. Per una raccolta prevalentemente testuale, il vantaggio multimodale potrebbe non giustificare la complessità aggiuntiva: confrontarlo con un modello testuale usando lo stesso insieme di query e giudizi di rilevanza.

Il modello da 1B è più piccolo di quello da 8B, ma i punteggi dichiarati dal produttore sono inferiori in tutte le colonne della tabella di benchmark. Non si può dedurre da questi soli numeri quanto costerà o quanto sarà più veloce in produzione: la latenza dipende anche da GPU, runtime, batch, lunghezza e risoluzione degli input. Misurare throughput e costo per documento e per query sul proprio hardware, includendo il preprocessing e l’aggiornamento dell’indice.

La condivisione dichiarata dello spazio testuale con Nemotron-3-Embed-1B può essere utile per valutare una migrazione, ma non va interpretata come garanzia che ogni indice già esistente sia intercambiabile senza verifiche. Prima di sostituire un encoder, controllare che query e documenti siano codificati con il modello, il prefisso, la dimensione e la normalizzazione previsti. Se il modello cambia, spesso è necessario rigenerare gli embedding dei documenti; verificare l’interoperabilità sul sistema concreto.

Infine, una valutazione di adozione dovrebbe coprire sia la qualità del recupero sia le condizioni operative e di licenza. Una prova utile include query reali in più lingue, documenti testuali e visivi, casi difficili con OCR imperfetto, immagini di diversa risoluzione e misure di latenza e memoria. Questo consente di decidere se la modalità immagine aggiunge valore sufficiente e se il deployment resta sostenibile.

Continua a esplorare

Correzioni e trasparenza

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