Amazon Nova 2 Lite: So berechnen Sie die tatsächlichen Kosten pro Workflow zwischen Tokens, Cache, Servicestufen und Fehlern

Vom Stückpreis zu den Kosten eines brauchbaren Ergebnisses

Der Preis pro Million Tokens ist ein notwendiger Bestandteil, beantwortet aber für sich allein nicht die relevante operative Frage: Was kostet es, eine Aufgabe mit dem Ergebnis und der Latenz abzuschließen, die das System benötigt? In einem Workflow mit Amazon Nova 2 Lite in Amazon Bedrock spielen Umfang von Ein- und Ausgabe, wiederholter Kontext, fehlgeschlagene Aufrufe, die Validierung der Antwort und – je nach Gestaltung – die gewählte Servicestufe zusammen. Eine belastbare Prognose muss daher sowohl in Verbrauchseinheiten als auch in akzeptierten Ergebnissen ausgedrückt werden.

Es ist sinnvoll, von Beginn an eine Arbeitseinheit zu definieren. Das kann eine klassifizierte Anfrage, eine verarbeitete Seite, ein extrahiertes Dokument, eine Sitzung oder eine Automatisierung sein, die ein gültiges strukturiertes Objekt erzeugt. Die gewählte Einheit muss die Annahmebedingung enthalten: etwa dass das JSON den Validator besteht, das Tool erfolgreich abgeschlossen wird oder keine menschliche Prüfung erforderlich ist. So wird verhindert, dass eine Antwort als Erfolg gilt, obwohl sie Ressourcen verbraucht hat und anschließend verworfen wurde.

Dieser Leitfaden legt keine Beträge fest: Die bereitgestellten Quellen beschreiben Modellidentifikation, Modalitäten, Cache, Servicestufen, Inferenzrouten, Kontingente und abrechenbare Nutzungsdaten, enthalten jedoch keine aktuell gültige Preistabelle. Bevor ein Budget erstellt wird, sollte das Team den außerhalb dieses Artikels geltenden offiziellen Tarif einfrieren und das Abrufdatum dokumentieren. Diesen Wert in die Formeln einzusetzen ist besser, als veraltete Zahlen wiederzuverwenden oder Preise aus einem anderen Modell abzuleiten.

Die dokumentierte Basiskennung des Modells lautet amazon.nova-2-lite-v1:0. Die Modellkarte dokumentiert außerdem Inferenzprofile für die Vereinigten Staaten, Europa, Japan und Global. Es darf nicht angenommen werden, dass zwei Profile, Routen oder Regionen denselben Preis, dieselbe Kapazität oder dieselbe Datenverarbeitung aufweisen, nur weil sie dasselbe Basismodell aufrufen.

Das Abrechnungsblatt, das vor jeder Berechnung eingefroren werden muss

Jede Kalkulationstabelle sollte mit einem Geltungsblatt beginnen. Notieren Sie Datum und Uhrzeit der Tarifabfrage, Währung, Konto oder Umgebung, Modellkennung, Ursprungsregion, Inferenzprofil, In-Region- oder Cross-Region-Route, angeforderte Servicestufe und funktionale Einheit. Ergänzen Sie eine Prompt-Version, die Ausgabekonfiguration, das Validierungsschema und den Beobachtungszeitraum. Diese Felder ermöglichen zu erklären, warum zwei scheinbar gleiche Messungen zu unterschiedlichen Kosten führen.

Die Bedrock-Dokumentation zu Kosten- und Nutzungsberichten unterscheidet für Nova 2 Lite Nutzungstypen für Eingabe, Ausgabe, Cache-Lesen und Cache-Schreiben. Sie dokumentiert außerdem Suffixe, mit denen sich die Stufe Flex oder Priority sowie Cross-Region-Routing unterscheiden lassen. Diese Trennung ist wichtig: Eine Schätzung, die nur Eingabe- und Ausgabetokens addiert, kann Cache-Vorgänge auslassen, und eine aggregierte Abstimmung kann eine Mischung aus Routen oder Servicestufen verdecken.

Bei geografischer Cross-Region-Inferenz können Anfragen innerhalb der gewählten Geografie verarbeitet werden, auch wenn Prompts und Ergebnisse von der Ursprungsregion in eine Zielregion innerhalb dieser Geografie übertragen werden können. Das muss als Architektur- und Residenzanforderung bewertet werden, nicht nur als Preisvariable. Die bereitgestellte Dokumentation reicht nicht aus, um hier eine Gleichheit von Preis, Kontingent oder Abrechnung zwischen In-Region, Geo Cross-Region und Global Cross-Region zu behaupten.

Abrechenbare Variablen und vier prüfbare Formeln

Trennen Sie für jeden Versuch mindestens gewöhnliche Eingabetokens, Ausgabetokens, Cache-Lesevorgänge und Cache-Schreibvorgänge. Wenn der Workflow multimodale Eingaben, integrierte Tools, Reasoning oder eine weitere Modalität enthält, fügen Sie spezifische Spalten nur dann hinzu, wenn der geltende Tarif und die Nutzungsaufzeichnung sie ausweisen. Weisen Sie einer Funktion nicht automatisch einen Aufpreis zu, nur weil sie genutzt wird: Mit den verfügbaren Quellen lässt sich die Preisbehandlung von Reasoning, Bildern, Dokumenten, Tools oder API-Fehlern für dieses Modell nicht bestätigen.

Verwenden Sie Stückpreise, die in Kosten pro Token umgerechnet wurden, oder behalten Sie den Nenner pro Million Tokens durchgängig bei. Nennen Sie den Eingabepreis P_i, den Ausgabepreis P_o, den Preis für Cache-Lesen P_cr und den Preis für Cache-Schreiben P_cw. Für einen Versuch j lauten die zugehörigen Verbräuche I_j, O_j, CR_j und CW_j. Falls weitere veröffentlichte Positionen existieren, nehmen Sie sie als Summe aus Menge mal Preis auf, ohne sie in Eingabe oder Ausgabe zu verstecken.

Die erste Formel schätzt die Kosten eines einzelnen Aufrufs. Die zweite verteilt die Kosten eines Batches auf verarbeitete Elemente. Die dritte dient Sitzungen, welche Instruktionen oder Kontext wiederverwenden. Die vierte wandelt Verbrauch in Kosten pro korrekt abgeschlossener Aufgabe um. In allen Fällen hängt das Ergebnis davon ab, dass die Telemetrie jeden Versuch erfasst, einschließlich jener, die nach fehlgeschlagener Validierung endeten oder nach übermäßiger Wartezeit abgebrochen wurden.

Prompt-Cache: Nettoeinsparung messen, nicht voraussetzen

Nova 2 Lite unterstützt explizites Caching mit mindestens 1.000 Tokens pro Checkpoint, bis zu vier Checkpoints, einer Lebensdauer von fünf Minuten und höchstens 20.000 Cache-Tokens. Diese Grenzen bestimmen, welche Designs profitieren können: Eine umfangreiche, stabile Instruktion, die von zeitlich nahe beieinanderliegenden Anfragen geteilt wird, ist ein klarerer Kandidat als ein kleiner, stark variabler oder weit auseinanderliegender Kontext.

Der richtige Vergleich lautet nicht abstrakt „mit Cache gegenüber ohne Cache“. Messen Sie geschriebene Tokens, gelesene Tokens, Anzahl berechtigter Anfragen, Trefferquote, Intervall zwischen Aufrufen, zusätzliche Komplexität und Veränderungen der Erfolgsquote. Der anfängliche Schreibvorgang kann andere Kosten verursachen als ein Lesevorgang, und der Kosten- und Nutzungsbericht erlaubt die Unterscheidung beider Kategorien. Eine Nettoeinsparung entsteht nur, wenn die wiederverwendeten Lesevorgänge die Schreibvorgänge und die Pflege des Designs ausgleichen.

Ein Cache kann die Wirtschaftlichkeit auch verschlechtern, wenn er die Segmentierung komplizierter macht, nötige Personalisierung verringert, häufige Abläufe verursacht oder dazu verleitet, irrelevanten Kontext einzuschließen. Dass ein Block cachefähig ist, beweist nicht, dass er die Rechnung senkt. Die Entscheidung sollte auf einer vergleichbaren Kohorte und auf Kosten pro akzeptierter Aufgabe beruhen, nicht allein auf beobachteten Eingabetokens.

Standard, Flex und Priority: eine Entscheidung nach erwarteten Kosten

Die Dokumentation zu Servicestufen beschreibt Flex für Workloads, die Verzögerungen tolerieren, und Priority als eine pro Anfrage angeforderte Option. Sie weist außerdem darauf hin, dass On-Demand-Kontingente zwischen Priority, dem Standardverhalten und Flex geteilt werden. Die Wahl einer Stufe beseitigt daher weder die Notwendigkeit, die Gesamtnachfrage zu messen, noch garantiert sie allein, dass der Workflow innerhalb seiner Kontingentgrenzen arbeitet.

Die tatsächlich bediente Stufe kann laut Dokumentation in der API-Antwort, in CloudTrail und in CloudWatch beobachtet werden. Speichern Sie diesen Wert zusammen mit der angeforderten Stufe. Das ist entscheidend, um Abweichungen zwischen Absicht und bereitgestelltem Dienst zu erkennen und Analysen von Latenz, Verbrauch und Nutzungstypen des Kostenberichts abzustimmen.

Die günstigste Alternative pro Einheit kann pro brauchbarem Ergebnis teurer sein, wenn sie Abbrüche, Timeouts oder Arbeitswiederholungen erhöht. Umgekehrt rechtfertigt eine auf Priorität ausgerichtete Stufe ihre Zusatzkosten nur, wenn sie tatsächlich auftretende operative Verluste reduziert. Dies ist eine Schlussfolgerung aus wirtschaftlicher Analyse, keine Aussage zu garantierten Preisen oder Leistungen einer bestimmten Stufe.

Fehler, Wiederholungsversuche und verworfene Antworten: der Multiplikator, der einmal erfasst werden muss

Ein robuster Workflow muss alle Versuche protokollieren: den ersten Aufruf, automatischen Wiederholungsversuch, JSON-Reparatur, einen neuen Aufruf nach Timeout und die Eskalation zur menschlichen Prüfung. Um Doppelzählungen zu vermeiden, vergeben Sie eine Stamm-ID für die Aufgabe und eine Versuch-ID. Jeder Modellkostenbetrag gehört zu einem Versuch; die Kosten pro akzeptierter Aufgabe entstehen, indem die Versuche der Aufgabe genau einmal aggregiert und durch die akzeptierten Aufgaben geteilt werden.

Unterscheiden Sie Fehler vor dem Modellaufruf, die möglicherweise keinen Inferenzverbrauch verursachen, von Antworten oder Fehlern nach einer Invocation. Es ist nicht sicher, jeden HTTP-Fehler als kostenlos oder jeden Wiederholungsversuch als identisch mit dem ersten zu behandeln. Die Abstimmung sollte die Antwortdaten, operativen Protokolle und die im Kostenbericht verfügbaren Bedrock-Nutzungstypen verwenden. Wenn eine Korrelation auf Anfrageebene fehlt, dokumentieren Sie diese Einschränkung, statt sämtliche Ausgaben dem letzten sichtbaren Schritt zuzuschreiben.

Die veröffentlichten Kontingente enthalten für die Cross-Region-Inferenz von Nova 2 Lite Grenzen für Anfragen pro Minute und Tokens pro Minute, und einige Kontingente können über Service Quotas angepasst werden. Messen Sie Ablehnungen, Wartezeiten und Wiederholungsversuche, die an Limits gebunden sind. Eine Änderung des Kontingents oder des Ankunftsmusters kann Erfolgsquote und effektive Kosten verändern, ohne dass sich der Stückpreis ändert.

Ersetzbares Monatsbudget und Abstimmung mit den Ausgaben

Für die Budgetierung beginnen Sie mit einer Prognose der monatlich gestarteten Aufgaben, einer erwarteten Verteilung der Versuche pro Aufgabe und durchschnittlichen Verbräuchen je Versuchstyp. Berechnen Sie jedes Segment getrennt: einfache Anfragen, Dokumente, Sitzungen mit wiederholtem Kontext und strukturierte Automatisierungen. Multiplizieren Sie die durchschnittlichen Kosten pro Versuch jedes Segments mit den erwarteten Versuchen; addieren Sie danach Kosten für Hilfsoperationen und menschliche Prüfung, falls diese zum operativen Kostenumfang der Entscheidung gehören.

Als Strukturbeispiel kann eine Tabelle eine Zeile pro Segment und Spalten für gestartete Aufgaben, Akzeptanzrate, Versuche pro Aufgabe, Eingabe, Ausgabe, Cache-Schreiben und Cache-Lesen pro Versuch, aktuelle Preise, geschätzte Kosten und Kosten pro akzeptiertem Ergebnis enthalten. Die Preiszellen sollten leer bleiben, bis der verifizierte Tarif für die konkrete Konfiguration übernommen wurde. Sie sollten nicht mit illustrativen Zahlen befüllt werden, da diese als aktuelle Tarife verstanden werden könnten.

Vergleichen Sie nach Ende des Zeitraums Prognose und Realität nach Modell, Route, Servicestufe und Nutzungstyp. Erklären Sie Abweichungen zunächst durch Änderungen des Eingabemix, der Ausgabelänge, der Cache-Treffer, der Wiederholungsversuche und der Akzeptanz, bevor Sie sie einer Preisänderung zuschreiben. Rechnen Sie neu, wenn sich Modell, Region oder Profil, Prompt, Cache-Richtlinie, Servicestufe, multimodaler Mix, Volumen, Kontingente oder Validierungsregeln ändern.

Weiter entdecken

Korrekturen und Transparenz

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