KI-Hinweis: Dieser Artikel wurde mit Unterstützung generativer KI erstellt. Redaktionell verantwortlich: Florian Zimmermeister (flozi00). Impressum und Kontakt.
NVIDIA veröffentlichte die Open-Weight-Familie Nemotron 3.5 Embed am 20. Oktober 2026: Checkpoints mit 8B BF16, 1B BF16 und 1B NVFP4 sowie einen multimodalen 8B-Reranker. Das sind herunterladbare Modelle mit dokumentierten Pfaden für Transformers, Sentence Transformers, vLLM und NIM, keine reine API-Vorschau. Maßgeblich ist die Modelllizenz OpenMDW-1.1.12
Technisch nützlich ist eine Migrationseigenschaft: Für jede Größe stammt die Sprachkomponente aus dem entsprechenden reinen Textmodell Nemotron 3 Embed und bleibt eingefroren, während Vision-Encoder und multimodaler Projektor lernen. NVIDIA zufolge bleiben reine Text-Embeddings deshalb unverändert; ein bestehender Textindex kann beim Ergänzen von Bilddokumenten weiterverwendet werden. Diese Aussage ist enger und wertvoller als „alle Modelle teilen einen Raum“. Die Veröffentlichung verspricht nicht, dass beliebige 1B- und 8B-Vektoren, unterschiedliche Dimensionen, Präfixe oder Vorverarbeitungspfade gemischt werden dürfen.13
Dieser Guide verfolgt die öffentlichen Artefakte mit Stand 22. Oktober 2026. Die folgenden Gleichungen erklären den Mechanismus unter genannten Annahmen. Sie rekonstruieren keine unveröffentlichten Verlustgewichte und berichten keinen unabhängigen Qualitäts- oder Durchsatzbenchmark.
Was tatsächlich veröffentlicht wurde
| Checkpoint | Parameter | Native Ausgabe laut Model Card | Laufzeitfokus |
|---|---|---|---|
| Nemotron-3.5-Embed-8B-BF16 | 8.38B | 4,096 | Qualitätsorientiertes BF16-Retrieval |
| Nemotron-3.5-Embed-1B-BF16 | 1.55B | 2,048 | Kleinerer BF16-Index- und Query-Dienst |
| Nemotron-3.5-Embed-1B-NVFP4 | 1.55B | 2,048 | vLLM auf NVFP4-fähiger Blackwell-Hardware |
| Nemotron-3.5-Rerank-8B-BF16 | 8.38B | ein Relevanz-Logit pro Paar | Zweite Ranking-Stufe für Top-k |
Queries sind ausschließlich Text. Ein Dokument kann aus Text, einem Seitenbild oder Bild plus Text bestehen. Die Embedding-Modelle sind Bi-Encoder: Query und Dokument werden unabhängig kodiert, Dokumentvektoren lassen sich also einmal berechnen und wiederholt durchsuchen. Der Reranker ist ein Cross-Encoder: Er verarbeitet je ein Query-Dokument-Paar gemeinsam und liefert einen Skalar. Er gehört deshalb hinter die erste Retrieval-Stufe und nicht über den gesamten Korpus.24
Die dokumentierte Eingabegrenze beträgt 32.768 kombinierte Text- und Bildtokens. Für Bilder gilt standardmäßig longest_edge: 1120, erhöhbar bis 1.540 Pixel. Das sind Prozessorgrenzen, keine Zusage, dass Kleindruck immer erhalten bleibt oder die Tokenzahl vom Seitenverhältnis unabhängig wäre.2
Der Datenpfad: viele Tokenzustände werden zu einem Vektor
Die Referenzimplementierung der Model Card setzt das gespeicherte Template mit query: oder passage: ein, führt den multimodalen Transformer aus, mittelt alle nicht gepaddeten Tokenzustände und L2-normalisiert das Ergebnis. Für die endgültige Tokenzustandsmatrix und die Attention-Maske lautet der veröffentlichte Pfad:
Da und Einheitsnorm besitzen, entspricht das Skalarprodukt der Cosinusähnlichkeit. Dies ist dichtes Single-Vector-Retrieval: Pro indexierter Einheit wird ein Vektor gespeichert, anders als bei Tokenmatrix und MaxSim-Scorer von pplx-embed-v2. Mean Pooling ist günstig, verdichtet aber alle Seitenbereiche zu einem Punkt; es zeigt nicht, welche Tabellenzelle einen Match auf Tokenebene gewonnen hätte.2
Die Model Card nennt einen Pixtral-Vision-Encoder und eine multimodale Projektion. Sie veröffentlicht nicht genug Formdetails, um jeden visuellen Zwischentensor sicher herzuleiten. Belegt ist die Grenze: Der trainierte visuelle Pfad liefert Tokenrepräsentationen, die zu derselben Art normalisierten Vektor wie Text gemittelt werden; beim 8B-Modell wurden nur Vision-Encoder und Projektor angepasst.3
Warum das Einfrieren des Textpfads Index-Wiederverwendung ermöglicht
bezeichne den alten reinen Textencoder einschließlich Retrieval-Präfix, Tokenizer, Pooling und Normalisierung; sei der reine Textpfad des neuen Modells. Wenn alle Parameter und die Vorverarbeitung des Textpfads unverändert bleiben, folgt aus dem Einfrieren die funktionale Identität
Das ist stärker als gleiche Dimensionalität: Zwei unabhängige Encoder können beide 2.048 Zahlen ausgeben und trotzdem gedrehte oder anderweitig inkompatible Koordinaten verwenden. Hier bleibt die alte Textabbildung erhalten, während eine trainierbare visuelle Abbildung in dieses Koordinatensystem eingepasst wird. Ein schematisches kontrastives Ziel für einen Batch aus gepaarten Queries und Dokumenten lautet
Die Veröffentlichung nennt kontrastives Training des visuellen 8B-Pfads, legt aber genaue Batches, Temperatur oder alle Verlustterme nicht offen; die Gleichung ist erklärend. Entscheidend ist ihre Geometrie: Relevante visuelle Dokumente werden zu ihren Textqueries gezogen, Batch-Negative erhalten niedrigere Werte, während das Textkoordinatensystem selbst fix bleibt.1
Im Betrieb gilt „Index wiederverwenden“ für den entsprechenden Vorgänger gleicher Größe mit identischen Präfixen, Tokenizer, Pooling, Normalisierung, Dimension und Dokumentvorverarbeitung. Ein Byte-für-Byte-Regressionstest an repräsentativem Text bleibt sinnvoll: Laufzeitkernel und Gleitkommareihenfolge können kleine numerische Unterschiede erzeugen, obwohl die mathematische Abbildung gleich bleibt. Schon der Wechsel von passage: zu query: verändert die Eingabe und hebt die Identität auf.
Warum Cosinus plus MSE dem 1B-Studenten hilft
Das multimodale 1B-Modell wurde vom 8B-Teacher destilliert. NVIDIA nennt die Kombination aus Cosinusdistanz und Mean Squared Error über mehrsprachigen Text- und Bild-Retrievaldaten.21 Dabei gilt eine wesentliche Formbedingung: Die Cards beschreiben native Ausgaben mit 2.048 beziehungsweise 4.096 Koordinaten. Diese Rohvektoren lassen sich nicht direkt subtrahieren. Die Veröffentlichung legt weder die Dimensionsangleichung noch die genauen Repräsentationen offen, auf die diese Verluste angewandt werden.
Um den Verlust zu erklären, ohne die fehlende Brücke zu erfinden, seien bereits angeglichene Repräsentationen in einem gemeinsamen -dimensionalen Raum. Nur unter dieser ausdrücklich gesetzten Annahme ist das folgende illustrative Ziel wohldefiniert:
Der Cosinusterm richtet die Richtung aus. Bei unnormalisierten Eingaben bestraft MSE zusätzlich Skalierungsunterschiede. Sind beide Eingaben dagegen auf Einheitsnorm gebracht, gilt : MSE und Cosinusdistanz unterscheiden sich dann nur durch einen konstanten Faktor. Die veröffentlichten Verlustnamen belegen für sich nicht, welcher Fall beim Training vorliegt.
Für einheitsnormierte Teacher-/Student-Repräsentationen von Query und Dokument in demselben gemeinsamen Raum besitzt die Score-Abweichung eine einfache Schranke:
Sie folgt, indem addiert und subtrahiert und anschließend Cauchy-Schwarz angewandt wird. Weicht jeder Kandidatenscore höchstens um vom Teacher ab, bleibt die Reihenfolge eines Paars bei einer Teacher-Marge größer erhalten. Diese bedingte Schranke gilt nicht direkt für die unterschiedlich breiten nativen API-Ausgaben, belegt keine unveröffentlichte Projektion und erlaubt kein Mischen von 1B- und 8B-Vektoren. Die Veröffentlichung liefert weder diese Brücke noch Fehlergrenzen pro Vektor. Die Wiederverwendung des gleich großen Vorgängerindex folgt unabhängig von diesem illustrativen Distillationsmodell aus dem Einfrieren des Textpfads.
Dynamische Dimensionen: kleinere Indizes, anderer Vertrag
Die 1B-Model-Card dokumentiert einen nativen Vektor mit 2.048 Dimensionen und Abschneiden am Ende, gefolgt von zwingender erneuter Normalisierung. NIM Release 2.4 akzeptiert jede angeforderte Dimension von 128 bis 2.048. Für erhaltene Koordinaten und Bytes pro Komponente beträgt die rohe Vektorspeicherung schlicht .25
| 100 Millionen Vektoren | 2,048 Dimensionen | 512 Dimensionen | 128 Dimensionen |
|---|---|---|---|
| float32-Payload | 819.2 GB | 204.8 GB | 51.2 GB |
| int8/uint8-Payload | 204.8 GB | 51.2 GB | 12.8 GB |
Diese Zahlen schließen HNSW-Kanten, Metadaten, Replikate und Allokator-Overhead aus. Alle in einem Index verglichenen Vektoren müssen dieselbe erhaltene Dimension und Normalisierung besitzen. Die Veröffentlichung liefert keine allgemeine Recall-Kurve für 128, 512 und 2.048 Dimensionen. Die Dimension auf einem gelabelten Validierungssatz wählen und die Collection anschließend neu aufbauen oder versionieren, statt Shapes still zu mischen.
Ein Widerspruch in der offiziellen Dokumentation ist ein Stoppsignal fürs Deployment: Die 8B-Model-Card nennt 4.096 native Dimensionen, während die aktuelle NIM-Supportmatrix für das 8B-Profil 2.048 aufführt. Das kann ein Serving-Projektions- oder Trunkierungsprofil beschreiben, doch die zitierten Seiten lösen es nicht auf. Vor der Indexallokation die tatsächliche Response-Form prüfen und Modell- sowie Laufzeitrevision fixieren. Aus der NIM-Tabelle keine Austauschbarkeit von 1B und 8B ableiten.35
NVFP4 quantisiert die Modellausführung, nicht automatisch den Index
Der 1B-NVFP4-Checkpoint quantisiert Gewichte und Aktivierungen geeigneter linearer Schichten in Sprach- und Vision-Komponenten auf NVFP4. Quantization-Aware Distillation soll vor allem Genauigkeit bei langen Eingaben zurückgewinnen. Ziel sind vLLM 0.32.0 und NVIDIA-Blackwell-Hardware mit NVFP4-Unterstützung. BF16 ist der portable Checkpoint für die dokumentierte Nutzung mit Transformers und Sentence Transformers.6
Drei Präzisionsentscheidungen müssen getrennt bleiben:
- Checkpoint-Präzision bestimmt gespeicherte Modellgewichte;
- Kernel-Aktivierungspräzision bestimmt geeignete Matrixoperationen;
- Embedding-Ausgabetyp bestimmt die Payload der Vektordatenbank.
NIM bietet für diese Familie float-, int8- und uint8-Ausgaben. Base64 ist nur ein Kodierungsformat und ändert die Vektorpräzision nicht. Ein Vier-Bit-Checkpoint kann also weiterhin float32-Vektoren ausgeben; eine int8-Ausgabe lässt inkompatible Hardware nicht plötzlich NVFP4 ausführen.5
NIM 2.4 trennt außerdem Checkpoint-Bezeichnung und Ausführungspräzision: Sein 1B-BF16-Checkpoint läuft in FP16; ein explizites Override NIM_ENGINE_PRECISION=bf16 ist nicht implementiert. Das Deployment setzt die 32.768-Token-Grenze ausdrücklich. Ohne NIM_PIPELINE_MAX_SEQ_LEN fällt der Server auf 512 zurück. Daher aufgelöste Präzision und Sequenzgrenze protokollieren, statt das Model-Card-Maximum als Servicestandard anzunehmen.5
NVIDIA berichtet auf GB200 101,3 Dokumente/s für 1B BF16 und 128,8 Dokumente/s für 1B NVFP4; dabei seien 99,85 % des berichteten ViDoRe-v3-Scores erhalten. Das sind Herstellermessungen; der Fließtext spezifiziert Batchzusammensetzung, Bildgrößen und Parallelität nicht vollständig. Sie sind ein dokumentierter Betriebspunkt, keine Kapazitätsprognose.1
Checkliste für den Produktionsbetrieb
- Exakte Modell-, Prozessor- und Laufzeitversionen fixieren; die Cards dokumentieren getrennte Umgebungen für Transformers 5.20.0 und vLLM 0.32.0.
- Die Rollen
query:undpassage:beibehalten. Gleiche Dimension ohne dasselbe Template ist keine Kompatibilität. - Vor Wiederverwendung eines Nemotron-3-Textindex alte und neue Textvektoren sowie Top-k-Ergebnisse an repräsentativen Dokumenten vergleichen. Nur entsprechende Modellgröße und Ausgabedimension wiederverwenden.
- Bildskalierung, kombinierte Tokenzahl und Trunkierung protokollieren. Die Grenze von 32.768 Tokens enthält Bildtokens.
- Reine Text-, reine Bild- und Bild-plus-Text-Teilmengen separat validieren. Ein aggregierter Score kann eine Regression einer Modalität verdecken.
- Bei reduzierter Dimension oder int8-Ausgabe Recall nach jeder Änderung messen; nicht beide Änderungen kombinieren und das Ergebnis nur einer zuschreiben.
- Den 8B-Cross-Encoder nur auf eine begrenzte Kandidatenmenge anwenden. Seine Kosten wachsen mit Zahl und Länge der Paare.
- Quellseite oder Chunk neben jedem Vektor speichern. Ähnlichkeit liefert einen Kandidaten, nicht Evidenzherkunft oder eine generierte Antwort.
Der praktische Gewinn der Architektur ist kontrollierte Erweiterung: ein bewährtes Textkoordinatensystem erhalten, Bilder hineintrainieren und ein kleineres Serving-Modell gegen den großen Teacher destillieren. Ebenso wichtig ist die Grenze: Kompatibilität ist ein versionierter numerischer Vertrag, keine Eigenschaft, die aus einem gemeinsamen Familiennamen folgt.
Für Indexspeicher, ANN-Overhead und Latenzuntergrenzen geht es im Guide zur RAG-Retrieval-Mathematik weiter. Eine Architektur, die bewusst einen kleinen Query-Encoder mit einem größeren Dokumentencoder kombiniert, behandelt pplx-embed-v2.
Primärquellen
Footnotes
-
NVIDIA, Nemotron 3.5 Embed, Rerank, and Parse release article, veröffentlicht am 21. Oktober 2026; Architektur-, Trainings-, Benchmark- und Deploymentabschnitte. ↩ ↩2 ↩3 ↩4 ↩5
-
NVIDIA, Nemotron-3.5-Embed-1B-BF16 model card, Veröffentlichungsdatum 20. Oktober 2026; Architektur, Ausgabe und getestete Laufzeiten. ↩ ↩2 ↩3 ↩4 ↩5 ↩6
-
NVIDIA, Nemotron-3.5-Embed-8B-BF16 model card, abgerufen am 22. Oktober 2026; eingefrorener Textpfad, 4.096-dimensionale Ausgabe und dynamische Trunkierung. ↩ ↩2 ↩3
-
NVIDIA, Nemotron-3.5-Rerank-8B-BF16 model card, Veröffentlichungsdatum 20. Oktober 2026; Cross-Encoder-Architektur und Top-50-Auswertungsbedingungen. ↩
-
NVIDIA, NeMo Retriever Embedding NIM support matrix, abgerufen am 25. Oktober 2026; Dimensionen, Ausgabetypen, Hardware und Präzisionsverhalten. ↩ ↩2 ↩3 ↩4
-
NVIDIA, Nemotron-3.5-Embed-1B-NVFP4 model card, abgerufen am 22. Oktober 2026; compressed-tensors, QAD, Hardware- und Versionsanforderungen. ↩