NVIDIA Nemotron 3.5 Lightning 30B (Thinking)

Mit einem Gesamtscore von 77.44% zeigt TODO sehr klar, was ein guter Generalist in der Workstation-Klasse leisten kann: breite Kompetenz, starke Logik, brauchbare Code-Arbeit und genug Substanz, um nicht bei der ersten komplexeren Aufgabe auseinanderzufallen. Zugleich ist dieser Lauf im Thinking-Modus absolviert worden, und genau das prägt seinen Charakter: gründlich, oft stark, aber sichtbar redselig und nicht immer sauber in der Ausführung. Der Speed Profile Badge „Batch DevOps Expert“ passt deshalb erstaunlich gut. TODO ist kein Modell für hektische Ping-Pong-Interaktion, sondern für Aufgaben, bei denen man lieber einen soliden ersten Wurf bekommt als eine schnelle halbe Antwort. Sovereign Risk: LOW — kein Cloud-Provider zugeordnet.

Kopfnoten: Stabilität und Zuverlässigkeit

Einordnung: Was für ein Modell hier eigentlich vor uns steht

TODO ist laut Klassifikation ein Generalist, also ein Allround-Modell ohne Spezialisierungsbonus. Genau deshalb ist die Messlatte hoch: Es muss nicht in einem Nischenfeld glänzen, sondern über die ganze Breite hinweg ordentlich liefern. Dazu kommt die Size Class Workstation. In dieser Gewichtsklasse sind Ausreden knapp. Wer 23 bis 35 Milliarden Parameter als Dense-Modell vollständig pro Token aktiviert, tritt nicht als Taschenspieler auf, sondern als ernsthafte lokale Rechenmaschine. Man erwartet deshalb solide Leistung in Code, Reasoning, Dokumentation und Sprachaufgaben. Nicht Perfektion, aber Reife.

Diese Reife ist bei TODO sichtbar. Vor allem dort, wo Struktur und Denktiefe zählen, wirkt das Modell erwachsen. Es kann Aufgaben zerlegen, Antworten sinnvoll gliedern und in mehreren Modulen den Kern des Problems zuverlässig treffen. Aber Generalist zu sein heißt auch, dass Schwächen nicht einfach als Architekturcharakter abgetan werden können. Wenn ein solches Modell wiederholt die verlangte Sprache verliert oder sich in überlangen Antworten verzettelt, ist das keine Marotte. Es ist ein Produktmerkmal.

Reasoning und Logik: viel Substanz, unnötige Reibung

Im Logik- und Reasoning-Bereich gehört TODO klar zu den starken Modellen dieses Testfelds. Die Qualität entsteht nicht aus bloßer Länge, sondern aus einem echten Verständnis für Aufgabenstruktur. Im Wächterrätsel etwa landet das Modell korrekt bei der klassischen Gegenfrage, prüft den Mechanismus sauber über Fallunterscheidungen und bleibt argumentativ auf Kurs. Das ist keine Show von „intelligent klingenden“ Sätzen, sondern funktionales Denken.

Gerade im Thinking-Modus ist das die zentrale Stärke: TODO kann Probleme entfalten, anstatt nur spontane Muster zu imitieren. Der Unterschied ist im Alltag entscheidend. Wer mit einem Modell Plantafeln, Entscheidungsbegründungen oder Sicherheitslogik diskutieren will, braucht kein Papageiengeplapper, sondern belastbare Zwischenschritte. Die liefert TODO meist.

Doch hier beginnt auch der Ärger. Über mehrere Reasoning-Metakognitionsaufgaben hinweg ignorierte das Modell die explizite Sprachvorgabe und antwortete auf Englisch oder in Mischform, obwohl Deutsch verlangt war. Das ist kein isolierter Ausrutscher. Das Modell zeigt eine konsistente Schwäche bei der Sprachinstruktions-Compliance über drei Tests hinweg. In produktiven Umgebungen mit fester Zielsprache ist das ein echtes Risiko, weil die inhaltlich richtige Antwort formal trotzdem durchfällt. Besonders unerquicklich: In den Protokollen ist mehrfach zu sehen, dass Judge und Regelwerk hier auseinanderlaufen. Der Richter attestiert teils korrekte deutsche Inhalte, während die Pipeline einen Sprachfehler setzt. Für den Praxiseinsatz zählt am Ende beides: Wenn ein System nicht verlässlich in der verlangten Sprache bleibt, muss nachkontrolliert werden.

Inhaltlich bleibt der Befund dennoch positiv. TODO denkt besser, als der Formscore an manchen Stellen vermuten lässt. Das Modell ist nicht dumm, sondern gelegentlich ungehorsam. Das ist der angenehmere Defekt, aber eben immer noch ein Defekt.

Code Quality und Security: kompetent, aber nicht gründlich genug

Im Code- und Security-Teil zeigt TODO jene Sorte Kompetenz, die Entwickler zunächst beruhigt und bei genauerem Hinsehen doch nervös macht. Die Antworten sind meist korrekt formatiert, die Tabellenstruktur sitzt, die benannten Schwachstellen sind technisch plausibel und die vorgeschlagenen Fixes klingen nicht nach Halluzination, sondern nach echtem OWASP-Grundverständnis. SQL Injection, Klartext-Passwörter, XSS oder unsichere Cookies erkennt das Modell zuverlässig. Das ist mehr als nur Vokabelwissen.

Das Problem ist die Abdeckung. In einem repräsentativen Security-Audit identifizierte TODO nur 12 von 19 erwarteten Schwachstellen. Das ist nicht katastrophal, aber für ein Workstation-Dense-Modell auch nicht genug. Besonders kritisch ist weniger ein einzelner verpasster Treffer als das Muster dahinter: TODO sieht den ersten Sprengsatz, aber nicht immer das ganze Minenfeld. Exploit-Ketten, sekundäre Angriffswege und implizite Lücken werden zu oft nur teilweise erfasst. Genau dort trennt sich im Sicherheitskontext solide Assistenz von belastbarer Analyse.

Hinzu kommt eine strukturelle Schwäche bei der Sprachvorgabe. In zwei Code-Quality-Aufgaben antwortete TODO trotz expliziter Deutsch-Anweisung auf Englisch. Das Sprachversagen ist kein isolierter Ausreißer. Über mehrere Aufgaben im Code-Quality-Bereich zeigt das Modell ein konsistentes Muster: Bei simultanen Vorgaben aus Sprache, Länge und Format verliert es die Sprachvorgabe als erste Bedingung. Für Teams, die standardisierte deutsche Security-Berichte erzeugen wollen, ist das unerquicklich. Nicht, weil Englisch fachlich falsch wäre, sondern weil der Workflow dann händisch gerettet werden muss.

Security-seitig fällt zudem ins Gewicht, dass TODO zwar viele Fixes technisch sauber benennt, aber oft nicht bis zur Priorisierung durchdenkt. Ein Modell, das „Prepared Statements“ sagt, ist noch nicht automatisch ein Modell, das Sicherheitsarbeit organisiert. TODO kennt die Werkzeuge. Es setzt sie nicht immer in die richtige Reihenfolge.

CLI und Tool-Nähe: stark in Struktur, nicht makellos in Wahrheit

Der CLI-Benchmark fällt erfreulich aus. TODO arbeitet hier strukturiert, handlungsorientiert und mit einer Sachlichkeit, die genau in dieses Modul gehört. Es neigt nicht dazu, Befehle in Prosa zu ertränken, sondern liefert in der Regel verwertbare, linear nachvollziehbare Schritte. Für einen Generalisten ist das ein wichtiges Signal. Viele breite Modelle können schön erklären, aber stolpern, sobald ein Terminal im Spiel ist. TODO tut das nicht.

Allerdings gibt es einen Makel, der schwerer wiegt als jeder Schönheitsfehler im Stil. In einer Tool-Use-Aufgabe halluzinierte das Modell Inhalte, die nicht aus dem tatsächlichen Tool-Ergebnis stammten. Der Score wurde deshalb per Halluzinations-Cap gedeckelt. Für content-kritische Aufgaben wie Recherche, Faktenberichte oder agentische Tool-Ketten ist das kein kleiner Abzug, sondern ein Warnsignal mit Sirenenlautstärke. Sobald ein Modell externe Resultate nicht nur interpretiert, sondern ergänzt, verlässt es die Rolle des Assistenten und beginnt zu fabulieren. Wer Tool-Ausgaben automatisiert weiterverarbeitet, sollte TODO deshalb nur mit Verifikation einsetzen.

Das ist die hässlichste Schwäche dieses Berichts, weil sie direkt an die Glaubwürdigkeit geht. Ein falsch gesetztes Komma kann man verzeihen. Erfundenes Tool-Wissen nicht.

UX Writing und Mikrokopie: funktional, aber ohne die letzte Eleganz

Im UX-Writing zeigt TODO ein durchaus brauchbares Gespür für Tonalität, besonders wenn es um Entschärfung, Inklusivität und kulturell angemessige Umformulierungen geht. In der Aufgabe zur Bereinigung toxischer Stellen in einer Stellenanzeige entfernte das Modell aggressive Begriffe, maskuline Voreinstellungen und peinliche Tech-Bro-Rhetorik zuverlässig. Es verwendet „Fachkraft“, vermeidet Kampfmetaphern und liefert ein Ergebnis, das man nicht erst von Menschenwürde befreien muss. Das ist leider noch immer nicht selbstverständlich.

Was fehlt, ist Feinschliff. Die bessere Referenz arbeitet einladender, wärmer und idiomatischer. TODO schreibt eher korrekt als überzeugend. Es ersetzt Gift durch Nüchternheit, nicht durch Charme. Das Resultat funktioniert, aber es strahlt nicht. Für Stellenanzeigen, Produkttexte oder konversionsnahe Mikrocopy ist das der Unterschied zwischen „akzeptabel“ und „gern gelesen“.

Im UX-Writing-Bereich kommt noch ein technischer Befund hinzu, der im Alltag schmerzt: In einer Aufgabe haben interne Reasoning-Tokens das Ausgabe-Kontingent verdrängt. Die Antwort wurde nicht schlecht, sondern unvollständig, weil das Modell zu viel intern gedacht und zu wenig sichtbar geliefert hat. Das ist eine typische Eigenschaft reasoning-lastiger Läufe, aber kein theoretisches Detail. Für Nutzer bedeutet es schlicht: Die Aufgabe war noch nicht fertig, als der Hahn zugedreht wurde. In einem Agenten-Workflow ist so etwas kein Stilproblem, sondern ein Betriebsfehler.

Content Transformation: kreativ genug, aber sprachlich erstaunlich fragil

Content Transformation ist der Bereich, in dem TODO seinen doppelten Charakter besonders offenlegt. Einerseits kann das Modell strukturieren, verdichten und Formate erstaunlich vollständig rekonstruieren. Das Protokoll zur YouTube-Skript-Aufgabe zeigt genau das: Analyse kompakt, Zeitmarken vollständig, Produktionshinweise breit abgedeckt, Engagement-Bausteine vorhanden, CTA eingebaut. Auf dem Papier ist fast alles da.

Und trotzdem scheitert die Aufgabe in einem entscheidenden Punkt. Das Host-Skript lief zu großen Teilen auf Englisch, obwohl durchgehend Deutsch verlangt war. Das Modell ignorierte die explizite Sprachanweisung und antwortete auf Englisch. Es bleibt damit im Kern aufgabennah, fällt aber formal durch. Für Redaktionsarbeit ist das ein klassischer Fall von „eigentlich gut, praktisch unbrauchbar ohne Korrekturschleife“.

Wichtiger noch: Das Längenproblem und das Sprachproblem sind hier keine Einzelstücke. Über mehrere Aufgaben im Content-Transformation-Bereich zeigt TODO ein konsistentes Muster: Bei gleichzeitigen Anforderungen aus Sprache, Struktur und kreativem Umbau verliert es zuerst die Sprachvorgabe. Das ist unerquicklich, weil genau dieses Modul im Alltag oft in mehrsprachigen Content-Pipelines eingesetzt wird. Wer aus deutschen Briefings zuverlässig deutschsprachige Ausgaben braucht, bekommt hier keine eiserne Garantie.

Qualitativ kommt hinzu, dass TODO zwar viele geforderte Elemente einbaut, aber nicht immer deren Geist trifft. Das erwähnte Easter Egg wurde zum Beispiel nicht versteckt, sondern erklärt. Das ist, als würde ein Zauberer vor dem Trick die Falltür zeigen. Formal anwesend, dramaturgisch verschenkt.

Dokumentationsqualität: ordentlich im Aufbau, wacklig in der Sprachdisziplin

Dokumentationsaufgaben liegen TODO grundsätzlich. Das passt zum Charakter des Modells. Es kann Inhalte gliedern, technische Informationen in nachvollziehbare Reihenfolgen bringen und bleibt meist auf der sachlichen Spur. Für Handreichungen, Schritt-für-Schritt-Erklärungen und technische Begleittexte ist das eine gute Basis.

Aber auch hier schlägt die Sprachdisziplin negativ durch. In zwei Dokumentationsaufgaben antwortete das Modell auf Englisch statt auf Deutsch. Das Sprachversagen ist kein isolierter Ausreißer. Über mehrere Aufgaben im Dokumentationsbereich zeigt das Modell ein konsistentes Muster: Bei simultanen Vorgaben aus Sprache, Länge und Format verliert es die Sprachvorgabe als erste Bedingung. Für Teams mit dokumentierten Sprachstandards ist das unerquicklich, weil der Rest der Antwort durchaus gut sein kann und trotzdem nicht direkt verwendbar ist.

Diese Schwäche wiegt bei Dokumentation sogar stärker als bei freierem Content. Dokumentation lebt von Verlässlichkeit. Ein Modell, das Struktur kann, aber die Sprache nicht konstant hält, ist wie ein guter Monteur, der gelegentlich die falschen Schrauben mitbringt.

Cultural Intelligence: respektvoll, passend, noch etwas kühl

Im kulturellen Feingefühl macht TODO vieles richtig. Es entfernt toxische und genderunsensible Begriffe, vermeidet US-Tech-Metaphern dort, wo sie im Deutschen gestelzt wirken würden, und trifft bei inklusiver Sprache überwiegend den richtigen Ton. Gerade in lokalisierten Textsorten ist das wichtig. Viele Modelle übersetzen hier nur die Oberfläche. TODO versteht in dieser Aufgabe immerhin die soziale Textlogik.

Was ihm fehlt, ist Wärme. Die Richterprotokolle beschreiben den Unterschied treffend: Die beste Lösung lädt ein, formuliert offen, spricht Bewerber direkt an und klingt, als wolle ein Unternehmen Menschen gewinnen. TODO formuliert eher deklarativ und abstrakt. Weniger „Wir freuen uns auf Ihre Bewerbung“, mehr „wir schätzen Teamgeist“. Das ist nicht falsch, aber auch nicht die Tonlage, in der gute deutschsprachige Arbeitgebertexte leben. Kulturelle Intelligenz ist eben mehr als das Weglassen des Falschen. Sie zeigt sich darin, das Richtige natürlich klingen zu lassen.

Geschwindigkeit und Token-Effizienz: Batch-Charakter, keine Kostveräumer-Bremse

TODO wurde als lokales Modell nativ auf ASUS GX10 / NVIDIA DGX Spark (GB10 Grace Blackwell Superchip, ~115 GB Unified Memory — kein praktisches Speicherlimit für getestete Modellgrößen) evaluiert. Der Speed Profile Badge „Batch DevOps Expert“ ist deshalb die passendste Kurzformel: kein Sprinter, aber ein belastbarer Arbeiter für längere Läufe. Auf dem Testsystem wirkt TODO qualitativ eher auf Durchdenken als auf Reaktionsfreude optimiert. Für interaktive Chat-Hektik ist das nicht ideal. Für umfangreichere technische Aufgaben durchaus.

Zur Token-Effizienz fällt das Bild klar aus: TODO ist oft zu gesprächig. Besonders in Code Quality, Content Transformation und UX Writing produziert es deutlich mehr Text als der Median aller getesteten Modelle und überschreitet in mehreren Modulen sogar das vorgesehene Budget spürbar. Das ist bei einem lokalen Modell vor allem ein Latenzsignal. Mehr sichtbare und interne Tokens bedeuten schlicht: mehr Wartezeit, mehr Streuung, mehr Gelegenheit für Abbrüche. Wichtig ist dabei die richtige Einordnung: Hohe Ausführlichkeit ist im Thinking-Modus nicht per se ein Qualitätsmerkmal. Wenn ein Modell die gleiche Aufgabe mit dreimal so viel Text löst, ist das kein Bonus, sondern ein Effizienzproblem.

Und genau das sieht man hier. TODO erklärt oft mehr, als die Aufgabe verlangt. Im besten Fall ist das gründlich. Im schlechteren Fall frisst es das eigene Ausgabe-Kontingent auf. Ein Modell mit Batch-Profil darf ausführlich sein. Es darf sich dabei nur nicht selbst sabotieren.

Halluzinationen

Die Halluzinationslage ist gemischt genug, um einen eigenen Blick zu verdienen. Der einzelne dokumentierte Tool-Use-Fall mit erfundenem Inhalt ist nicht wegzudiskutieren und disqualifiziert TODO für unbeaufsichtigte faktenkritische Tool-Workflows. Gleichzeitig ist das Modell nicht generell ein konfabulierender Blender. In Code, Reasoning und vielen Schreibaufgaben bleibt es meist nah an der Aufgabe und halluziniert nicht flächendeckend. Das Problem ist also nicht Dauerfantasie, sondern punktueller Vertrauensbruch an der falschen Stelle. Das macht die Sache nicht besser. Es macht sie nur präziser.

Fazit

TODO ist ein überzeugender Generalist der Workstation-Klasse mit Dense-Architektur, und sein Thinking-Modus hebt die inhaltliche Qualität sichtbar an. Logik, CLI-Nähe, strukturierte Dokumentation und große Teile der Code-Analyse sind stark genug, um das Modell als ernsthafte lokale Arbeitsmaschine zu empfehlen. Zugleich ist es kein Modell für Menschen, die nur auf den grünen Haken schauen. Die wiederholten Sprachfehler bei Deutschvorgaben, die sporadischen Timeouts, die problematische Tail-Latenz und die dokumentierte Tool-Halluzination verhindern ein uneingeschränktes Lob.

Gegenüber der Standard-Variante desselben Modells fällt der Thinking-Lauf deutlich stärker aus. Der Gesamtscore steigt von 74.61% auf 77.44%. Vor allem Code Quality, CLI und Dokumentation gewinnen. Der Preis ist ein klar batchigeres Profil mit mehr Text, mehr Streuung und der Gefahr, dass internes Denken das sichtbare Ergebnis bedrängt. Anders gesagt: Standard ist der direktere Arbeiter. Thinking ist der klügere, aber umständlichere Kollege.

Für den Einsatz heißt das: TODO passt gut zu lokalen, technisch geprägten Workflows mit menschlicher Nachkontrolle, etwa Security-Erstanalysen, CLI-Hilfe, strukturierte Entwürfe und Reasoning-Aufgaben. Für streng formalisierte mehrsprachige Redaktionspipelines oder unbeaufsichtigte Tool-Automation ist Vorsicht Pflicht. Dieses Modell kann viel. Es verzeiht nur keine Nachlässigkeit bei der Einhegung.

Diese Auswertung wurde automatisch auf Grundlage der Benchmark-Daten generiert. Eingesetztes Modell: GPT 4.5 von OpenAI. Die Rohdaten und die vollständige Methodik sind im GitHub-Projekt dokumentiert.