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.

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.

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:

• 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.

(rme)

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.

Überblick über die Architektur

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.

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.

Trainingsdaten fast vollständig veröffentlicht

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.

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.

Pre-Training

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.

Ausprobieren

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 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.

Große Nemotrons

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“.

Fazit

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)

Das Kubernetes-Projektteam hat Version 1.35 veröffentlicht, die insgesamt 60 Neuerungen umfasst – davon 17 stabile Features sowie 19 Beta- und 22 Alpha-Funktionen. Aufbauend auf der seit Version 1.34 als stabiles Feature verfügbaren Dynamic Resource Allocation (DRA) erweitert das neue Release die Möglichkeiten für Ressourcenmanagement und Workload-Sicherheit.

In-place Updates für Pod-Ressourcen und Beta-Features für Sicherheit

Das wohl wichtigste neue stabile Feature erlaubt laut der Ankündigung zu „Timbernetes“ (The World Tree Release) das Anpassen von CPU- und Speicherressourcen laufender Pods, ohne diese neu starten zu müssen. Bisher erforderten solche Änderungen das Neuerstellen von Pods, was insbesondere bei zustandsbehafteten oder Batch-Anwendungen zu Unterbrechungen führen konnte. Die Funktion soll insbesondere vertikales Skalieren vereinfachen.

Native Pod-Zertifikate für Workload-Identität mit automatisierter Zertifikatsrotation stehen nun im Rahmen der Beta-Phase zur Verfügung: Der kubelet generiert Schlüssel, fordert Zertifikate über PodCertificateRequest an und schreibt Credentials gebündelt in das Dateisystem des Pods. Die Knotenbeschränkung erzwingt der kube-apiserver ab dem Zeitpunkt der Zulassung. So sollen sich auch die beim Einsatz von Signierern durch Drittanbieter häufig auftretenden, versehentlichen Verletzungen der Knotenisolationsgrenzen vermeiden lassen. Laut Ankündigung des Kubernetes-Teams eröffnet sich damit auch der Weg zu reinen mTLS-Flows ohne Bearer-Tokens im Ausstellungspfad.

Die native Storage Version Migration ist in Kubernetes 1.35 ebenfalls Beta und standardmäßig aktiviert. Damit rückt die Migrationslogik direkt in die Control Plane. Für StatefulSets steht das maxUnavailable-Feld jetzt ebenfalls standardmäßig zur Verfügung. Es definiert, wie viele Pods während eines Updates gleichzeitig nicht verfügbar sein dürfen, was Updates beschleunigen kann. Die als sicherere YAML-Variante für Kubernetes in Release 1.34 eingeführte KYAML hat auch die Betaphase erreicht und ist standardmäßig aktiviert.

Veraltete und entfernte Funktionen

Das Kubernetes-Projekt hat den Support für cgroup v1 ab Release 1.35 entfernt. Cluster-Administratoren müssen ihre Nodes auf Systeme mit cgroup-v2-Unterstützung migrieren, andernfalls startet der kubelet nicht mehr. Ebenso endet jetzt der Support für die Runtime containerd 1.x – vor dem nächsten Upgrade ist der Wechsel auf containerd 2.0 oder höher erforderlich.

Der IPVS-Modus in kube-proxy gilt nun als veraltet (deprecated). Das Projektteam empfiehlt den Wechsel zu nftables. Zudem hat das Kubernetes-Team angekündigt, Ingress NGINX nur noch bis März 2026 zu pflegen. Danach wird das Projekt archiviert – die Migration zur Gateway API wird empfohlen.

Einen vollständigen Überblick aller Änderungen und Neuerungen liefern der Blogbeitrag zu Kubernetes 1.35 sowie die Release Notes auf GitHub.

(map)