Amazon Nova 2 Lite: Was bei der Migration von Nova 1 zu prüfen ist, wenn der Kontext eine Million Tokens erreicht

Nova 2 Lite verändert den Integrationsvertrag, nicht nur den Modellnamen

Amazon Nova 2 Lite ist ein proprietäres Modell, das über verwaltete AWS-Dienste verfügbar ist. Seine deklarierte Basiskennung lautet `amazon.nova-2-lite-v1:0`. Die offizielle Modellkarte datiert seine Einführung auf den 2. Dezember 2025, nennt ein Kontextfenster von bis zu einer Million Tokens und eine deklarierte maximale Ausgabe von 64.000 Tokens. Sie gibt außerdem an, dass das Ende des Lebenszyklus nicht vor dem 2. Dezember 2026 liegt, und sieht einen Mindestzeitraum für Legacy-Unterstützung vor. Diese Angaben definieren veröffentlichte Servicegrenzen, nicht ein garantiertes Ergebnis für eine konkrete Arbeitslast.

Aus der Bezeichnung „Lite“ lässt sich weder ableiten, dass die Integration einfach ist, noch dass die Latenz niedrig, der Preis pro Aufgabe geringer oder das Verhalten zu Nova 1 Lite, Pro oder Premier gleichwertig ist. Sie belegt auch nicht, dass ein bestehender Prompt, ein Ausgabeschema oder eine Automatisierung nach dem Modellwechsel dieselbe Qualität behält. Eine verantwortungsvolle Migration muss Modell, gewählte API, Inferenzprofil und Reasoning-Konfiguration als Teile eines Vertrags behandeln, der erneut getestet wird.

Der große Kontext kann das Anwendungsdesign verändern. Er kann den Bedarf verringern, bestimmte Dokumente oder Verläufe aufzuteilen, beseitigt aber weder die Notwendigkeit, relevante Informationen auszuwählen, Berechtigungen zu begrenzen, sensible Daten zu kontrollieren noch Ergebnisse zu messen. Ein sehr großer Kontext bedeutet auch nicht, dass jeder Inhalt gleich stark in die Antwort einfließt oder dass das Modell sachlich korrekte Antworten erzeugt. Aufnahmekapazität, Verhalten beim Wiederfinden von Informationen im Kontext, Genauigkeit und betrieblicher Nutzen sind unterschiedliche Eigenschaften.

Die entscheidende Differenz ist daher nicht nur quantitativ. Bei der Einführung von Nova 2 Lite muss ein Team festlegen, welche Aufrufart verwendet wird, welche Eingaben zulässig sind, ob erweitertes Reasoning aktiviert wird, wie Tool-Anfragen entgegengenommen und ausgeführt werden und welche Inferenzroute mit den Anforderungen an die Datenresidenz vereinbar ist. Jede dieser Entscheidungen verlangt Nachweise aus der eigenen Umgebung.

Inventar des Vertrags: Kennung, Modalitäten und Limits vor dem Test festschreiben

Das erste Artefakt einer Migration sollte ein versioniertes Inventar sein. Es sollte die Modellkennung, die ausgewählte Region oder das Inferenzprofil, die Aufruf-API, die von der Anwendung akzeptierten Inhaltstypen und die Limits enthalten, die das Team vor einem Serviceaufruf durchsetzt. Die Modellkarte von Nova 2 Lite nennt Text-, Bild- und Videoeingaben. Die Behandlung von Dokumenten, konkrete Dateigrößen, Kombinationen von Inhaltsblöcken und die tatsächliche Verfügbarkeit müssen anhand der aktuellen API-Dokumentation und mit Testanfragen überprüft werden.

Das Fenster von einer Million Tokens erfordert eine präzise Lesart. Es ist eine deklarierte maximale Kontextkapazität und keine Aufforderung, stets das Maximum zu senden. Eine Anwendung kann praktische Grenzen durch die Zusammensetzung der Anfrage, die gewünschte Ausgabe, eigene Speicherlimits, Netzwerkzeiten oder Latenzziele erreichen. Sie sollte zudem erfassen, wie viele Tokens in jede Operation eingehen und aus ihr hervorgehen. Ohne diese Telemetrie lassen sich Regressionen bei geänderten Dokumentgrößen oder verändertem Modellverhalten nicht erkennen.

Auch die deklarierte maximale Ausgabe von 64.000 Tokens erweitert die Risikofläche. Eine lange Ausgabe kann Grenzen von Gateways, Puffern, Warteschlangen, Benutzeroberflächen oder nachgelagerten Validatoren überschreiten. Benötigt das Produkt JSON oder ein anderes strukturiertes Format, genügt es nicht, eine lange Modellantwort zu beobachten. Es muss geprüft werden, ob das Ergebnis vollständig empfangen, validiert, sicher verworfen sowie gemäß einer expliziten Richtlinie repariert oder erneut angefordert werden kann.

Provider-Limits und interne Limits sollten getrennt werden. Eine Organisation kann beispielsweise ein kleineres Kontextmaximum zum Schutz von Latenz und Kosten, ein Ausgabelimit für eine bestimmte Oberfläche und eine abweichende Größenbegrenzung für multimodale Inhalte festlegen. Solche Einschränkungen müssen in Konfiguration und Tests stehen, nicht nur im informellen Wissen des Teams.

Converse und Invoke: Die gewählte Abstraktion bestimmt die Portabilität mit

Die Amazon-Nova-Dokumentation stellt Converse als konsistente Schnittstelle für die Interaktion mit Modellen dar und beschreibt Invoke als Weg mit einem nativen, nicht portablen Format. Die praktische Konsequenz ist klar: Die Entscheidung sollte nicht nur nach anfänglicher Bequemlichkeit getroffen werden. Converse kann Integrationsunterschiede verringern, wenn eine Anwendung mit einer gemeinsamen Schnittstelle arbeiten muss. Invoke kann dagegen verlangen, dass der Client ein modellspezifisches Format kennt und pflegt.

Das macht keine der Schnittstellen generell überlegen. Ein Team muss prüfen, ob die gewählte API die benötigten Modalitäten, Konfigurationen und Antwortfelder unterstützt. Bei einem nativen Format sollte der Test die exakte Serialisierung der Anfrage, das Parsen jedes Antwortblocks, Beendigungsgründe und Fehler abdecken. Bei einer konsistenten Schnittstelle muss ebenfalls verifiziert werden, dass ihre Abstraktion keine erforderlichen Optionen verdeckt und keine Semantik verändert, auf die sich das Produkt verlässt.

Das Zeitlimit verlangt eine Architekturprüfung. AWS weist darauf hin, dass Nova-Inferenzanfragen Timeouts von bis zu 60 Minuten benötigen können und der Client entsprechend angepasst werden muss. Das betrifft SDKs, Load Balancer, Proxys, Worker, Ausführungslimits von Funktionen und die Nutzererfahrung. Ein Timeout einfach zu erhöhen, kann gebundene Ressourcen vermehren und löst weder Abbruch, Wiederholungen noch Deduplizierung.

Für lange Operationen braucht es eine ausdrückliche Richtlinie: Welche Komponente darf sie abbrechen, wie wird ein Abbruch weitergegeben, was wird protokolliert, wenn der Client die Verbindung trennt, wann ist ein erneuter Versuch zulässig und wie wird verhindert, dass eine externe Aktion doppelt ausgeführt wird? Diese Entscheidungen sind besonders wichtig, wenn eine Unterhaltung Tools auslösen kann oder eine Folgeantwort ein automatisiertes System speist.

Erweitertes Reasoning: konfigurieren, messen und nicht mit einer vollständigen Erklärung verwechseln

Nova 2 bietet erweitertes Reasoning über `reasoningConfig`. Die Dokumentation beschreibt die Budgetstufen `low`, `medium` und `high`. Das Aktivieren dieser Funktion bedeutet nicht, dass eine lesbare und vollständige Erklärung dafür hinzugefügt wird, wie eine Antwort entstanden ist. Die Antwort kann Blöcke `reasoningContent` enthalten, doch AWS gibt an, dass der Reasoning-Inhalt redigiert zurückgegeben wird. Diese Blöcke sollten daher weder als vollständiges Entscheidungsprotokoll noch als ausreichender Nachweis für ein Business-Audit betrachtet werden.

Erweitertes Reasoning sollte als eigenständige Konfigurationsvariante bewertet werden. Ein geeignetes Testset vergleicht für jede Aufgabe den Modus ohne Reasoning mit jedem Budget, das das Produkt zulassen soll. Es sollte Erfolgsraten nach einer definierten Rubrik, die Gültigkeit strukturierter Ausgaben, die Gesamtdauer, den in der Telemetrie verfügbaren Tokenverbrauch, die Häufigkeit von Wiederholungen und Sicherheitsergebnisse erfassen. Die Wahl des Budgets muss auf einem gemessenen Ziel beruhen, nicht auf der Annahme, dass eine höhere Stufe alle Fälle verbessert.

Auch die Nachvollziehbarkeit ist ein Thema. Das Protokollieren der angeforderten Konfiguration, der Modellkennung, der API und des Inferenzprofils hilft dabei, eine Klasse von Vorfällen zu reproduzieren. Diese Aufzeichnungen ersetzen jedoch nicht die Beobachtung von Eingaben, Ausgaben, Anwendungsentscheidungen und Ergebnissen autorisierter Tools. Enthalten die Daten personenbezogene oder vertrauliche Informationen, muss die Protokollierung denselben Regeln für Datenminimierung, Zugriff und Aufbewahrung folgen wie der Rest des Systems.

Aus der vorliegenden Dokumentation lässt sich nicht ableiten, dass erweitertes Reasoning garantiert korrektere, sicherere oder schnellere Antworten liefert. Die sachgerechte Entscheidung besteht darin, seine Verwendung auf Aufgaben zu beschränken, bei denen die eigene Bewertung gegenüber den Auswirkungen auf Dauer und Betrieb eine ausreichende Verbesserung zeigt.

Function Calling: Das Modell schlägt vor, die Anwendung autorisiert und führt aus

Die Nova-2-Dokumentation beschreibt Function Calling als einen Ablauf, in dem der Client Tools mittels JSON Schema definiert. Fordert das Modell ein Tool an, enthält die Antwort einen Block `toolUse` und den Beendigungsgrund `tool_use`. Die Verantwortung für die Ausführung des Tools liegt ausdrücklich beim Client, der das Ergebnis an das Modell zurückgeben muss, wenn die Interaktion fortgesetzt werden soll. Diese Aufgabenteilung ist wesentlich: Eine vom Modell erzeugte Anfrage ist keine Berechtigung, eine externe Aktion auszuführen.

Die Anwendungsschicht muss Toolname und Argumente gegen einen strengen Vertrag validieren, Identität und Berechtigungen des Nutzers prüfen, Raten- und Umfangslimits anwenden, mit Credentials nach dem Prinzip minimaler Berechtigung ausführen und Fehler in ein kontrolliertes Ergebnis überführen. Sie muss außerdem entscheiden, wie mit mehrdeutigen Argumenten, nicht vorhandenen Ressourcen, Ergebnissen mit sensiblen Daten, vorübergehenden Fehlern und nicht idempotenten Operationen umzugehen ist. Ein JSON Schema verbessert die Schnittstellendefinition, ersetzt aber weder Autorisierungskontrollen noch semantische Validierung.

Der Migrationsvorschlag erwähnt integrierte Tools wie Web Grounding oder einen Code Interpreter. Die geprüften Quellen für diesen Beitrag dokumentieren den Function-Calling-Ablauf, erlauben hier jedoch keine Aussage darüber, welche integrierten Tools speziell für Nova 2 Lite verfügbar sind, unter welchen Bedingungen, über welche Aufrufwege oder in welchen Regionen, und wie sie Daten und Berechtigungen verarbeiten. Diese Unsicherheit muss vor der Gestaltung eines davon abhängigen Ablaufs mit spezifischer aktueller Dokumentation geklärt werden.

Der Tool-Test muss Erfolg und Fehler einschließen. Es reicht nicht, zu zeigen, dass das Modell bei einer einfachen Anfrage eine Funktion auswählt. Zu testen sind gültige und ungültige Argumente, verweigerte Berechtigungen, Timeouts, Ausfälle externer Dienste, Teilergebnisse, wiederholte Aufrufe und die Ablehnung einer potenziell schädlichen Aktion. Die Anwendung muss die Kontrolle über die externe Wirkung behalten, auch wenn das Modell auf einem Aufruf besteht.

Migration von Nova 1: Das Ersetzen einer ID belegt keine Gleichwertigkeit

In den vorliegenden Quellen gibt es keine offizielle Matrix, aus der sich eine direkte funktionale Gleichwertigkeit zwischen Nova 2 Lite und Nova 1 Lite, Pro oder Premier ableiten lässt. Daher wäre es nicht belastbar zu versprechen, dass der Austausch der Kennung Qualität, Formate, Tool-Auswahl, Latenz oder multimodales Verhalten erhält. Die Migration muss als bewertungspflichtiger Ersatz und nicht als transparente Aktualisierung definiert werden.

Ausgangspunkt ist das Einfrieren einer Baseline des bestehenden Systems. Für jeden Ablauf sollte das Team zulässige repräsentative Eingaben, Generierungskonfiguration, System- und Nutzerprompts, verfügbare Tools, erwartete Antworten oder Bewertungsrubriken, Dauer und Fehlerrate bewahren. Anschließend kann dasselbe Set auf Nova 2 Lite ausgeführt werden, getrennt nach API, Reasoning-Budget und Inferenzprofil. Ohne diese Trennung kann eine Regression fälschlich dem Modell zugeschrieben werden, obwohl sie aus dem Aufrufweg oder einer Prompt-Änderung stammt.

Lange Fälle sind zwingend, wenn der breite Kontext der Grund für den Wechsel ist. Sie sollten verteilte relevante Informationen, irrelevante Inhalte, absichtliche Widersprüche und die internen Grenzen der Anwendung enthalten. Multimodale Fälle müssen jede vom Produkt verwendete Modalität bewerten und prüfen, ob Upload-, Konvertierungs- und Beobachtungsmechanismen funktionieren. Strukturierte Ausgaben benötigen automatische Validierung und eine Prüfung der fehlgeschlagenen Fälle; das Erscheinungsbild eines korrekten JSON belegt nicht, dass seine Werte angemessen sind.

Die Rollout-Entscheidung kann schrittweise erfolgen. Ein Team kann das vorherige Modell für Abläufe beibehalten, die Schwellenwerte nicht erreicht haben, Nova 2 Lite auf beobachtbare und reversible Aufgaben begrenzen oder Reasoning und Tools bis zum Abschluss der Tests deaktivieren. Diese Vorsicht ist keine negative Bewertung des Modells. Sie verhindert, dass deklarierte Fähigkeiten mit in einem konkreten System nachgewiesenen Ergebnissen verwechselt werden.

Regionen, Inferenzprofile und Datenresidenz: Eine Richtlinie in Nachweise überführen

Regionale Verfügbarkeit und Datenresidenz dürfen nicht aus dem Namen der Region abgeleitet werden, aus der eine Anfrage gesendet wird. Amazon Bedrock unterscheidet Inferenz in einer Region, regionsübergreifende Inferenz über geografische Profile und regionsübergreifende Inferenz über globale Profile. Die AWS-Dokumentation erläutert, dass ein geografisches Profil Anfragen innerhalb der definierten Geografie verarbeitet, während ein globales Profil sie in jeder unterstützten kommerziellen Region verarbeiten kann.

Damit wird das Inferenzprofil zu einem Compliance-Parameter und nicht zu einem bloßen Leistungsdetail. Vor der Aktivierung von Nova 2 Lite muss die Organisation die aktuelle Matrix zur Modell- und Regionsverfügbarkeit prüfen, feststellen, welche Route die Konfiguration auswählt, und sie mit vertraglichen, regulatorischen und datenklassifikationsbezogenen Regeln abgleichen. Verfügbarkeit verändert sich im Zeitverlauf; eine Schlussfolgerung aus einem Test darf keine Änderungskontrolle ersetzen.

AWS dokumentiert, dass CloudTrail `additionalEventData.inferenceRegion` erfasst. Dieses Feld kann betriebliche Nachweise über den für eine Anfrage verwendeten Verarbeitungsort liefern. Das Compliance-Team muss dennoch bestimmen, welche Aufbewahrungsdauer, welche Abdeckung der Protokolle und welche zusätzlichen Kontrollen erforderlich sind. Ein für die Diagnose nützlicher Eintrag zertifiziert nicht für sich allein, dass die gesamte Architektur eine sektorale Verpflichtung erfüllt.

Der Test sollte mit der Identität, dem Konto, der Region und dem Inferenzprofil durchgeführt werden, die auch in der Produktion verwendet werden. Es ist zu prüfen, dass die erwarteten Ereignisse entstehen, das Feld erhalten bleibt und eine nicht autorisierte Änderung des Profils erkennbar ist. Verbietet die Richtlinie eine globale Route, muss dieses Verbot durch Konfiguration und Berechtigungen umgesetzt werden und darf nicht von einer Namenskonvention abhängen.

Akzeptanzkriterien und Grenzen dessen, was sich folgern lässt

Eine minimale Akzeptanztestreihe sollte kurze und lange Kontexte, multimodale Eingaben, die das Produkt tatsächlich verwendet, gültige und ungültige strukturierte Antworten, korrekte und fehlerhafte Tool-Anfragen, verweigerte Berechtigungen, Tool-Fehler, Abbruch, Wiederholungen und die Wiederholung derselben Anfrage abdecken. Sie sollte Latenzperzentile über die gesamte Kette einschließlich der Zwischenkomponenten messen, denn das Client-Timeout allein beschreibt nicht die tatsächliche Erfahrung.

Die Schwellenwerte sollten vor der Beobachtung der Ergebnisse festgelegt werden, damit eine Migration nicht nach subjektivem Eindruck genehmigt wird. Sie können eine Mindestquote für die Erfüllung einer Rubrik, eine Höchstzahl nicht konformer Ausgaben, einen maximalen Anteil an Operationen mit menschlichem Eingriff und ein Dauerlimit je Aufgabentyp umfassen. Menschliche Bewertung bleibt erforderlich, wenn das Ergebnis von Bedeutung, Nutzen oder kontextabhängigem Risiko abhängt, das sich nicht auf einen mechanischen Vergleich reduzieren lässt.

Nach bestandenen Tests ist es angemessen festzustellen, dass Nova 2 Lite die definierten Kriterien für die bewerteten Abläufe unter einer konkreten Konfiguration und in einem beobachteten Zeitraum erfüllt hat. Es ist nicht angemessen, dieses Ergebnis auf alle Prompts, alle Dokumente, alle Sprachen, alle Regionen oder alle Traffic-Volumina zu übertragen. Es belegt auch weder allgemeine sachliche Genauigkeit noch sektorale Compliance, Zuverlässigkeit automatisierter Aktionen oder die tatsächlichen Kosten pro Aufgabe im Maßstab.

Der anschließende Betrieb benötigt Beobachtbarkeit und einen Rückweg. Prompts und Schemata zu versionieren, Modell und Konfiguration zu protokollieren, Fehler zu messen und Rückrollsignale festzulegen, hilft dabei, eine punktuelle Schwankung von einer anhaltenden Regression zu unterscheiden. Ziel der Migration ist nicht, abstrakt zu beweisen, dass ein Modell besser ist, sondern nachvollziehbar zu entscheiden, für welche Aufgaben, Daten und Kontrollen seine Nutzung akzeptabel ist.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.