Einleitung
Berichten zufolge hat ein internes Amazon-Projekt, das Anthropic Claude Sonnet verwendete, Rechnungen in Höhe von 1,8 Millionen Dollar angehäuft, das geplante Budget um 860% überschritten, blieb fünf Monate lang unentdeckt und wurde schließlich nie in Produktion genommen.
Die Aufgabe selbst klingt recht gewöhnlich: Abgleich von Autoreninformationen mit Produktlisten auf der E-Commerce-Plattform von Amazon.
Über den Vorfall berichtete die Financial Times, nachdem ein leitender Amazon-Ingenieur in einer internen Mitarbeiterversammlung mehrere KI-bedingte Kostenüberschreitungen thematisiert hatte. Er dient als nützliche Warnung für alle Organisationen, die von gelegentlicher Chatbot-Nutzung zu automatisierten Arbeitsabläufen übergehen, da diese täglich Tausende oder Millionen kostenpflichtige Modellaufrufe erzeugen können.
Herkömmliche Softwarefehler verschwenden oft nur Entwicklungszeit oder erzeugen falsche Ausgaben. Fehler in mengenbasierten KI-Arbeitsabläufen können beides gleichzeitig verursachen – und erzeugen in jeder Minute, in der sie aktiv bleiben, fortlaufend Kosten für Tokens, Tools, Speicher und Rechenleistung.
Die Lehre daraus ist nicht, dass Unternehmen den Einsatz von KI einstellen sollten, sondern dass autonome oder hochvolumige KI-Prozesse ebenso klare finanzielle Kontrollen benötigen wie Sicherheits- und Qualitätskontrollen.
Was intern bei Amazon geschah
Wie mit der Angelegenheit vertraute Personen berichten, verwendete Amazon Claude Sonnet in einem Projekt, das Autoreninformationen mit Produktlisten auf seiner Einzelhandelsplattform abgleichen sollte.
Der Einsatz soll:
- 1,8 Millionen Dollar gekostet haben
- Das zugewiesene Budget um 860% überschritten haben
- Fünf Monate gebraucht haben, bis er entdeckt wurde
- Nie die Produktionsreife erreicht haben
Ein leitender Ingenieur beschrieb einige KI-bezogene Codierungsfehler als „katastrophal teuer“.
Amazon reagierte mit der Aussage, dass man experimentiere, lerne und die Nutzung der Technologie verbessere, einschließlich des Managements der Kosteneffizienz. Das Unternehmen erklärte außerdem, dass die Darstellung einiger weniger isolierter Fälle als übliche Praxis nicht die Art und Weise widerspiegele, wie KI in der größeren Organisation von Amazon eingesetzt werde.
Beides dürfte zutreffen.
Die Vorfälle betrafen möglicherweise nur einen kleinen Teil der Teams bei Amazon, offenbaren jedoch zugleich ein Kontrollproblem, das andere Organisationen ernst nehmen sollten.
Der konkrete Codierungsfehler wurde nicht offengelegt
Der ursprüngliche chinesische Bericht führte die Kostenüberschreitung auf ein Programm ohne Anrufratenbegrenzung zurück, das fortlaufend Anfragen in einer Schleife sendete.
Diese Erklärung ist plausibel, wurde jedoch durch die derzeitigen öffentlichen Berichte nicht bestätigt.
Die Financial Times beschrieb Codierungsfehler, schwache Ausgabenkontrollen und eine verzögerte Erkennung. Sie veröffentlichte keinen technischen Post-Mortem-Bericht mit:
- Quellcode
- Dem genauen Fehler
- Ob der Prozess eine Endlosschleife war
- Der Anzahl der Modellaufrufe
- Der Anzahl der Eingabe- oder Ausgabetokens
- Ob das Modell direkt oder über Amazon Bedrock aufgerufen wurde
- Der Modellversion
- Der Konfiguration der Tool-Nutzung
- Den kostenverursachenden Infrastrukturkomponenten
Die sicherste Schlussfolgerung ist vorsichtiger: Ein fehlgeschlagener Claude-Sonnet-Einsatz erzeugte eine enorme Rechnung, und die Kontrollsysteme von Amazon erkannten das Problem fünf Monate lang nicht.
Sofern Amazon keinen technischen Vorfallbericht veröffentlicht, sollte jede detailliertere Erklärung als Spekulation gekennzeichnet werden.
Dies war nicht das einzige Kostenproblem
Weitere Kostenüberschreitungen
Demselben internen Bericht zufolge wurden mindestens zwei weitere Fälle diskutiert.
| Projekt | Gemeldete unerwartete Kosten |
|---|---|
| Finanzprüfungstool | ca. 541.000 Dollar |
| Logistikprojekt zur Steigerung der Liefergeschwindigkeit | ca. 134.000 Dollar |
Die Logistik-Kostenüberschreitung soll erst nach mehr als zwei Wochen entdeckt worden sein.
Diese Fälle sind kleiner als das 1,8-Millionen-Dollar-Projekt zum Autorenabgleich, weisen jedoch auf dasselbe Muster hin: Wenn kein technischer Fehler den Prozess zum Anhalten zwingt, können nutzungsbasierte KI-Systeme fortlaufend Kosten anhäufen.
Herkömmliche Batch-Jobs können abstürzen, Speicher erschöpfen oder Tests nicht bestehen.
KI-Prozesse hingegen können technisch gesund bleiben, aber wirtschaftlich bereits zusammengebrochen sein.
Selbst wenn ein Projekt keine nützlichen Ergebnisse mehr liefert, kann es weiterhin erfolgreiche API-Antworten erhalten, Logs schreiben, Tools aufrufen, Aufgaben wiederholen oder minderwertige Datensätze verarbeiten.
Warum KI-Kostenfehler anders auftreten
Die Kosten herkömmlicher Anwendungen sind in der Regel an relativ vertraute Einheiten gekoppelt:
- Serverzeit
- Datenbankkapazität
- Speicher
- Netzwerkübertragung
- Arbeitsstunden
KI-Arbeitsabläufe können hingegen mehrere Abrechnungsebenen gleichzeitig erhöhen:
- Eingabetokens
- Ausgabetokens
- Gecachter und ungecachter Kontext
- Reasoning-Tokens
- Tool-Aufrufe
- Websuchen
- Codeausführungssitzungen
- Vektorsuche
- Agenten-Wiederholungen
- Parallele Arbeitsprozesse
- Lange Konversationsverläufe
- Cloud-Rechenressourcen
- Protokoll- und Speicherausgaben
Dies erzeugt einen Multiplikatoreffekt.
Angenommen, eine Aufgabe sendet einen langen Prompt, generiert umfangreiche Antworten, ruft zwei Tools auf, wiederholt sich nach einem Fehler und übergibt den vollständigen Verlauf an die nächste Runde. Wenn die Anwendung Millionen von Datensätzen verarbeitet, kann ein kleiner Designfehler extrem teuer werden.
Aus betrieblicher Sicht mag die Anwendung völlig normal erscheinen. Anfragen liefern weiterhin 200 OK. Arbeitsprozesse bleiben aktiv. Warteschlangen schrumpfen weiter. Oft ist die Rechnung der erste Ort, an dem das Problem sichtbar wird.
Ein einfaches Kostenmodell für KI-Arbeitsabläufe
Bevor Sie einen automatisierten KI-Prozess starten, schätzen Sie zunächst die Kosten pro abgeschlossener Geschäftsaufgabe.
Ein vereinfachtes Modell:
| Kostenbestandteil | Berechnung |
|---|---|
| Eingabekosten | Anzahl Eingabetokens × Modell-Eingabepreis |
| Ausgabekosten | Anzahl Ausgabetokens × Modell-Ausgabepreis |
| Tool-Kosten | Anzahl Tool-Aufrufe × Tool-Preis |
| Wiederholungskosten | Anzahl fehlgeschlagener oder wiederholter Versuche × durchschnittliche Kosten pro Versuch |
| Infrastrukturkosten | Rechenleistung, Speicher, Datenbank, Netzwerk und Protokollierung |
| Kosten der menschlichen Prüfung | Prüfzeit × Gesamtkostensatz inkl. Personalkosten |
Die entscheidende Kennzahl ist nicht nur der Preis pro Token.
Es geht um:
Gesamtkosten pro erfolgreich abgeschlossenem Geschäftsergebnis
Ein billigerer Request kann den Arbeitsablauf insgesamt teurer machen, wenn er eine höhere Fehlerquote aufweist, wiederholte Aufrufe erfordert oder mehr menschliche Prüfung erzeugt.
Ebenso kann ein leistungsfähigeres Modell insgesamt günstiger sein, wenn es Aufgaben in weniger Schritten erledigt.
Erste Kontrolle: Finanzielle Verantwortung für jede KI-Aufgabe benennen
Jeder KI-Arbeitsablauf in der Produktion sollte eine benannte verantwortliche Person haben, die sowohl für das technische Verhalten als auch für die Ausgaben zuständig ist.
Diese Person sollte Folgendes kennen:
- Die erwartete Geschäftsmenge
- Das verwendete Modell
- Die erwarteten Kosten pro Einheit
- Das Tages- und Monatsbudget
- Die maximalen Kosten pro Lauf
- Die Bedingungen für einen Stopp
Des Arbeitsablaufs
- Die Personen, die Warnmeldungen erhalten
- Den Prozess zur Genehmigung höherer Grenzen
Wenn ein einzelner Worker fortlaufend Anfragen senden kann, reichen vage Projektbudgets nicht aus.
Budgets sollten auf mehreren Ebenen existieren:
| Ebene | Beispiel |
|---|---|
| Organisation | Monatliches KI-Ausgabenlimit |
| Team | Monatliches Kontingent einer Geschäftseinheit |
| Anwendung | Budget eines Produkts oder Arbeitsablaufs |
| Umgebung | Getrennte Limits für Entwicklung, Staging und Produktion |
| Auftrag | Maximale Kosten eines Batches |
| Benutzer oder Mandant | Nutzungskontingent pro Kunde |
| Agentensitzung | Maximale Tokens, Schritte, Tools und Dauer |
Niedrigere Ebenen bieten den schnellsten und wirksamsten Bremsmechanismus.
Harte Limits innerhalb der Anwendung setzen
Cloud-Abrechnungswarnungen sind wichtig, ersetzen jedoch keine Kontrollen auf Anwendungsebene.
Die Anwendung sollte bei Erreichen festgelegter Grenzen anhalten oder eine Genehmigung anfordern.
Nützliche Limits umfassen:
- Maximale Anzahl von Anfragen pro Aufgabe
- Maximale Anzahl von Agentenschritten
- Maximale Anzahl von Wiederholungen
- Maximale Anzahl von Eingabetokens
- Maximale Anzahl von Ausgabetokens
- Maximale Kontextlänge
- Maximale Anzahl von Tool-Aufrufen
- Maximale Anzahl paralleler Worker
- Maximale Laufzeit
- Maximale Dollarkosten pro Auftrag
- Maximale Anzahl verarbeiteter Datensätze vor der Prüfung
Diese Kontrollen sollten standardmäßig deaktiviert sein.
Wenn der Kostenverfolgungsdienst nicht verfügbar ist oder die Anwendung das verbleibende Budget nicht bestimmen kann, ist das sicherste Verhalten in der Regel ein Anhalten statt eines unbegrenzten Fortsetzens.
Einen Not-Aus-Schalter unabhängig vom Agenten verwenden
Autonome Agenten sollten nicht die letztendliche Kontrolle über ihre eigenen Ausgaben haben.
Ein unabhängiger Dienst sollte in der Lage sein:
- API-Schlüssel zu deaktivieren
- Modellaufrufe abzulehnen
- Warteschlangen anzuhalten
- Worker auf null zu reduzieren
- Externe Tools zu blockieren
- Rollen zu entziehen
- Geplante Aufgaben zu stoppen
- Vor der Wiederaufnahme eine menschliche Genehmigung zu verlangen
Der Not-Aus-Schalter sollte auch dann verfügbar bleiben, wenn ein Agent in Wiederholungsschleifen feststeckt oder irreführende Statusmeldungen erzeugt.
Testen Sie ihn vor der Produktion.
Kontrollen, die nie verwendet wurden, sind nur Theorie.
Jeden Modellaufruf überwachen
Organisationen, die Amazon Bedrock verwenden, können für unterstützte bedrock-runtime-Aufrufe die Modellaufrufprotokollierung aktivieren.
AWS gibt an, dass diese Protokolle Anfrage- und Antwortdaten, Metadaten, Modellkennungen, Anfragekennungen, Identitätsinformationen und Token-Nutzung enthalten können. Als Protokollziele stehen Amazon CloudWatch Logs und Amazon S3 zur Verfügung.
Die Aufrufprotokollierung ist standardmäßig deaktiviert.
Das Team sollte nur die für die Beobachtbarkeit erforderlichen Daten aktivieren und geeignete Kontrollen für Datenschutz, Sicherheit, Aufbewahrung und Anonymisierung anwenden. Prompts und Ausgaben können sensible Unternehmens- oder Kundendaten enthalten.
Mindestens sollten Kostenüberwachungsdatensätze Folgendes enthalten:
- Zeitstempel
- Anwendung
- Umgebung
- Team oder Kostenstelle
- Modell
- Benutzer oder Mandant
- Anzahl der Eingabe-Tokens
- Anzahl der Ausgabe-Tokens
- Cache-Nutzung
- Tool-Aufrufe
- Anzahl der Wiederholungsversuche
- Auftragskennung
- Geschätzte Anforderungskosten
- Geschäftsergebnis
- Fehler- oder Eskalationsgründe
Dadurch können Rechnungen bestimmten Aufgaben zugeordnet werden, anstatt erst bei der monatlichen Finanzprüfung einen pauschalen Gesamtbetrag zu entdecken.
Verwendung von AWS Budgets zur Verfolgung von Claude-Kosten auf Bedrock
AWS Budgets können Kosten oder Nutzung im Verhältnis zu festgelegten Schwellenwerten verfolgen und Benachrichtigungen senden. Budget-Aktionen können bei Überschreitung der Schwellenwerte auch Kontrollmaßnahmen wie IAM-Richtlinien oder Service Control Policies anwenden. Je nach Konfiguration können Aktionen automatisch ausgeführt werden oder auf manuelle Genehmigung warten.
Ein wichtiges AWS-spezifisches Detail kann leicht übersehen werden.
Die AWS-Dokumentation zur Kostenanomalie-Erkennung weist darauf hin, dass dieser Dienst keine über den AWS Marketplace vertriebenen Drittanbieterprodukte überwacht, einschließlich Drittanbieter-Sprachmodelle über Amazon Bedrock wie Anthropic Claude.
Diese Kosten erscheinen weiterhin im Cost Explorer und in der Rechnung, aber AWS empfiehlt die Verwendung von AWS Budgets, um auf solche Gebühren aufmerksam zu machen.
Budgets können mit dem Filter für abrechnungspflichtige Entitäten verwendet werden, um Marketplace-Gebühren präziser zu verfolgen.
Genau diese Art von Konfigurationsdetail kann ein trügerisches Sicherheitsgefühl erzeugen. Unternehmen könnten die Anomalie-Erkennung aktivieren und annehmen, dass alle Modellkosten abgedeckt sind, während eine bestimmte Abrechnungskategorie nicht erfasst wird.
AWS Budgets nicht als Echtzeit-Unterbrechungsschalter verwenden
Die AWS-Dokumentation weist darauf hin, dass Budgetstatus mehrmals täglich aktualisiert werden.
Die Dokumentation warnt auch, dass Kosten vor oder nach Zustellung der Benachrichtigung weiter ansteigen können.
Das bedeutet, dass AWS Budgets für die Finanzgovernance nützlich sind, aber allein möglicherweise nicht schnell genug ist, um einen Hochdurchsatz-Agenten zu stoppen.
Der Kontrollstapel sollte Folgendes enthalten:
- Anforderungsbezogene Zähler auf Anwendungsebene
- Beinahe-Echtzeit-Nutzungsmetriken
- Harte Obergrenzen pro Auftrag und pro Sitzung
- Cloud-Budgetwarnungen
- Automatisierte Budgetaktionen, wo angemessen
- Tägliche Finanzprüfungen bei risikoreichen Veröffentlichungen
Je schneller ein Workflow Geld ausgibt, desto näher an der Aufrufstelle müssen die Kontrollen liegen.
Anomalie-Erkennung für Kosten im abgedeckten Serviceumfang verwenden
Die AWS-Kostenanomalie-Erkennung verwendet Machine-Learning-Modelle, um ungewöhnliche Ausgabemuster zu identifizieren und mögliche Ursachen zu lokalisieren.
AWS gibt an, dass der Dienst verarbeitete Abrechnungsdaten etwa dreimal täglich auswertet.
Er kann effektiv unerwartete Anstiege bei AWS-Services, Konten, Regionen, Nutzungstypen und Kostenzuordnungstags erkennen.
Für KI-Systeme kann er Anomalien bei unterstützenden Kosten im Zusammenhang mit Compute, Storage, Datenbanken oder Netzwerk identifizieren.
Teams sollten jedoch die oben genannten Marketplace-Einschränkungen beachten und bei Bedarf separate AWS-Budgets für Drittanbieter-Modellgebühren erstellen.
Service Quotas als Sicherheitsgrenze nutzen, nicht als Budget
Amazon Bedrock wendet Service Quotas auf Modellinferenz an, einschließlich tokenbasierter Limits für unterstützte Modelle und Endpunkte.
Quotas können unbegrenzten Durchsatz verhindern, sind jedoch nicht als präzises Finanzbudget konzipiert.
Quotas können dennoch Ausgaben ermöglichen, die die erwarteten Projektlimits weit überschreiten. Umgekehrt kann die Erhöhung von Quotas zur Lösung von Produktionskapazitätsproblemen unbeabsichtigt eine nützliche Sicherheitsgrenze entfernen.
Daher sollten Quotenänderungen Folgendes erfordern:
- Fachliche Begründung
- Aktualisierte Kostenprognose
- Namentliche Genehmigung
- Aktualisierte Warnschwellen
- Rollback-Plan
- Überprüfung nach Verkehrsanstieg
Raten- und Tokenlimits sollten als Teil des Systemrisikodesigns betrachtet werden und nicht nur als Hindernisse für die Skalierung.
Nutzung und Kosten bei Anthropic direkt verfolgen, wo angemessen
Für Anwendungen, die Anthropic direkt aufrufen, bietet die Anthropic-Konsole Kosten- und Nutzungsberichte.
Anthropics API-Limits können Anfragen pro Minute, Eingabe-Tokens pro Minute, Ausgabe-Tokens pro Minute sowie Ausgabelimits in Verbindung mit Nutzungsstufen umfassen.
Erstelle in Minuten eine Showcase-Website und gewinne Leads
Beschreibe deine Idee einmal, und We0 AI erstellt eine Showcase-Website, Seiten und ein CMS und hilft nach dem Launch bei Kunden und Traffic.
Eine komplette Projektgeneration zur kostenlosen Registrierung
Am besten geeignet, um einen vollständigen Generierungsablauf auszuprobieren und schnell einen ersten Projektentwurf zu sehen.
Diese Limits können unkontrollierten Durchsatz reduzieren, sollten jedoch durch Kontrollen auf Anwendungsebene ergänzt werden.
Organisationen mit mehreren Teams können außerdem LLM-Gateways zwischen Anwendungen und Modellanbietern bereitstellen. Gateways können Authentifizierung, Nutzungsverfolgung, Budgets, Ratengrenzen, Modell-Routing und Audit-Logs zentral verwalten.
Ein Gateway wird zur kritischen Sicherheitskomponente und muss daher mit derselben Sorgfalt betrieben und geprüft werden wie jede andere Produktionszugriffsebene.
Mit einer kleinen repräsentativen Stichprobe beginnen
Berichten zufolge versuchte ein Amazon-Projekt, eine groß angelegte Datenabgleichsaufgabe auszuführen.
Ein sichereres Bereitstellungsmuster ist:
- 100 repräsentative Datensätze ausführen.
- Genauigkeit und Kosten messen.
- 1.000 Datensätze ausführen.
- Fehler und Token-Verteilung prüfen.
- Worst-Case-Eingaben testen.
- Stoppkontrollen bestätigen.
- Ausgaben für die Vollverarbeitung schätzen.
- Vor Verarbeitung des vollständigen Datensatzes Genehmigung einholen.
Nicht nur auf Basis des durchschnittlichen Datensatzes extrapolieren.
Die längsten Dokumente, fehlgeschlagene Abgleiche, mehrdeutige Fälle, Wiederholungsversuche und Agentenschleifen dominieren häufig die Gesamtkosten.
Perzentil-Schätzungen verwenden, z. B. P50-, P95- und P99-Kosten pro Aufgabe.
Für jedes gültige Ergebnis eine maximale Kostenobergrenze festlegen
Der Workflow sollte stoppen, wenn zusätzliche Modellaufrufe wirtschaftlich nicht mehr vertretbar sind.
Für ein Autorenabgleichssystem könnten nützliche Metriken umfassen:
- Kosten pro erfolgreichem Autorenabgleich
- Kosten pro manuell geprüftem Datensatz
- Prozentsatz automatisch gelöster Datensätze
- Fehlabgleichsrate
- Kosten für Fehlabgleiche
- Eingesparte Kosten im Vergleich zur manuellen Bearbeitung
- Anzahl der Modellaufrufe pro akzeptiertem Ergebnis
Ein Prozess, der 0,02 USD pro Anfrage kostet, erscheint günstig.
Wenn er 50 Aufrufe erfordert, die Hälfte der Datensätze fehlschlägt und der Rest manuell geprüft wird, kann die tatsächliche Wirtschaftlichkeit schlecht sein.
Einfache Aufgaben an kostengünstigere Methoden weiterleiten
Nicht jeder Datensatz benötigt ein Spitzenmodell.
Ein kostenbewusster Pipeline kann Folgendes verwenden:
- Exakte Übereinstimmung
- Datenbankverknüpfungen
- Regeln
- Embedding-Ähnlichkeit
- Kleinere Modelle
- Stärkere Modelle nur bei mehrdeutigen Fällen
- Manuelle Prüfung bei risikoreichen Entscheidungen
Für Datenabgleichsprojekte können herkömmliche Softwarelösungen die meisten Fälle kostengünstiger und deterministischer lösen.
LLMs sollten nur eingesetzt werden, wenn sprachliche Mehrdeutigkeit dies tatsächlich erfordert, nicht automatisch für jede Zeile.
Anthropics eigene Preisrichtlinien empfehlen, das passende Modell auszuwählen, Prompt-Caching für wiederkehrende Kontexte zu verwenden, Batch-Verarbeitung für nicht dringende Arbeiten einzusetzen und Nutzungsmuster zu überwachen.
Unbegrenzte Wiederholungsversuche verhindern
Wiederholungen sind eine häufige Quelle versteckter Ausgaben.
Eine fehlgeschlagene Anfrage kann von der Anwendung, dem Warteschlangensystem, dem SDK, dem Gateway, dem Worker-Manager, dem Agenten oder dem Workflow-Orchestrator erneut versucht werden.
Wenn mehrere Ebenen unabhängig voneinander wiederholen, kann eine logische Aufgabe mehrere kostenpflichtige Anfragen erzeugen.
Eine einheitliche Wiederholungsstrategie definieren, die Folgendes umfasst:
- Kleine maximale Anzahl von Versuchen
- Exponentielles Backoff
- Jitter
- Klare Behandlung nicht wiederholbarer Fehler
- Idempotenz
- Dead-Letter-Warteschlangen
- Warnungen bei wiederholten Fehlern
- Pro-Aufgaben-Budget, das alle damit verbundenen Kosten einschließlich
Wiederholungsversuchen abdeckt
Fehler sollten keine unendliche wirtschaftliche Schleife erzeugen.
Entwicklungs- und Produktionsanmeldedaten trennen
Testskripte sollten keine Produktionslimits erben.
Separate Konten oder Arbeitsbereiche, API-Schlüssel, IAM-Rollen, Budgets, Quotas, Protokolle, Datenquellen und Netzwerkberechtigungen verwenden.
Entwicklungsumgebungen sollten bewusst niedrigere Ausgabenobergrenzen haben.
Prototypen, die versehentlich in eine Schleife geraten, sollten mit kleinen Beträgen fehlschlagen, anstatt Unternehmens-Produktionsquoten zu erhalten.
KI-generierten Code wie Produktionsfinanzinfrastruktur prüfen
Das Ereignis betraf ein Projekt, das mit KI-Unterstützung geschrieben wurde, aber das Hauptproblem war nicht, ob der Code von einem Modell generiert wurde.
Das wichtige Thema ist, ob der Code Geld ausgeben könnte.
Jede Komponente, die kostenpflichtige Modell-Anfragen auslösen kann, sollte folgenden Prüfungen unterzogen werden:
- Schleifenterminierung
- Wiederholungsverhalten
- Nebenläufigkeit
- Warteschlangen-Skalierung
- Maximaler Kontext
- Tool-Aufruf-Limits
- Timeout-Behandlung
- Abbruchmechanismen
- Kostenattribution
- Fehlerpfade
- Protokollierung
- Budget-Durchsetzung
- Notabschaltungsverhalten
Unit-Tests sollten wirtschaftliche Fehlerszenarien enthalten.
Beispiele sind: Das Modell liefert immer keine gültige Antwort, wiederholte Aufgabenzustellung, Absturz der Worker nach kostenpflichtigem Aufruf, wiederkehrende Rate-Limit-Fehler, Tool-Ausgaben, die den Kontext bei jeder Runde vergrößern, und nicht verfügbarer Kostenschätzdienst.
Ein funktional korrekter Normalpfad ist bei weitem nicht ausreichend.
Checkliste für Produktionsreife KI-Kostenkontrolle
Eigentum und Planung
-
Ein benannter technischer Verantwortlicher ist für Ausgaben verantwortlich.
-
Erwartete Nutzung und Kosten pro erfolgreichem Ergebnis sind dokumentiert.
[ ] Entwicklung, Staging und Produktion haben getrennte Budgets.
- Verarbeitung in vollem Umfang erfordert ausdrückliche Genehmigung.
Anwendungskontrollen
-
Jede Aufgabe hat Obergrenzen für Anzahl der Anfragen, Token, Schritte, Wiederholungsversuche und verstrichene Zeit.
-
Jede Agent-Sitzung hat ein in US-Dollar denominiertes Budget.
-
Nicht-Agent-Dienste können Workflows stoppen.
-
Aufgaben werden pausiert, wenn das Restbudget nicht gelesen werden kann.
-
Doppelte Arbeit wird durch Idempotenz verhindert.
Überwachung
-
Jeder Modellaufruf wird Team, Projekt, Benutzer und Aufgabe zugeordnet.
-
Nutzung von Eingaben, Ausgaben, Cache, Tools und Wiederholungsversuchen wird protokolliert.
-
Warnmeldungen werden sowohl für die Ausgabenrate als auch für die Gesamtausgaben eingerichtet.
-
Während der ersten Produktionsfreigabe wird eine tägliche Überprüfung aktiviert.
-
Das Team kennt Kostenpositionen, die nicht von der Anomalieerkennung abgedeckt werden.
Qualität und Wirtschaftlichkeit
-
Kosten werden pro erfolgreichem Geschäftsergebnis gemessen.
-
Wo angemessen, werden regulärer Code und kleinere Modelle verwendet.
-
Worst-Case- und hohe Perzentilkosten wurden getestet.
-
Kosten für menschliche Überprüfung sind enthalten.
-
Workflows stoppen, wenn zusätzliche Aufrufe keinen Mehrwert mehr bieten.
Governance
-
KI-generierter Code wird einer menschlichen Überprüfung unterzogen.
-
Budget- und Kontingenterhöhungen erfordern eine Genehmigung.
-
Der Notaus-Schalter wurde getestet.
-
Die Vorfallreaktion umfasst finanzielle und technische Beteiligte.
-
Das Team überprüft Ausgaben nach jeder größeren Modell- oder Prompt-Änderung.
Erkenntnisse aus der Amazon-Reaktion
Berichten zufolge bauen Amazon-Ingenieure automatisierte Schutzmaßnahmen für zukünftige KI-Projekte.
Dies ist die richtige
Richtung, aber Automatisierung muss auf mehreren Ebenen existieren.
Ein ausgereiftes Kontrollsystem sollte harte Anwendungsgrenzen, Modell- und Gateway-Kontingente, Cloud-Budgets, automatisierte Aktionen, Nutzungsprotokolle, Finanz-Dashboards, menschliche Genehmigungen und regelmäßige Überprüfungen kombinieren.
Das Unternehmen hat außerdem zuvor ein internes Ranking entfernt, das Mitarbeiter dazu ermutigte, die Nutzung ihres Kiro-Entwicklungstools zu maximieren. Laut Financial Times förderte das Ranking „Tokenmaxing“, bei dem Mitarbeiter ihren Rang durch erhöhten Token-Verbrauch verbesserten.
Dies ist eine nützliche Erinnerung: Anreize können die Kostendisziplin untergraben.
Wenn Mitarbeiter dafür belohnt werden, mehr KI zu nutzen, anstatt messbaren geschäftlichen Wert zu schaffen, steigt die Nutzung, selbst wenn sich die Ergebnisse nicht verbessern.
Organisationen sollten gelöste Probleme, Qualitätsverbesserungen, eingesparte Zeit, generierte Einnahmen, reduziertes Risiko und sinkende Kosten pro Output-Einheit belohnen.
Die Token-Anzahl ist eine Eingabekennzahl, keine Produktivitätskennzahl.
Häufig gestellte Fragen
Hat Amazon wirklich 1,8 Millionen US-Dollar für Claude Sonnet ausgegeben?
Die Financial Times berichtete, dass ein internes Amazon-Projekt, das Claude Sonnet verwendet, Rechnungen in Höhe von insgesamt 1,8 Millionen US-Dollar angehäuft hat. Das Projekt, das Autoreninformationen mit E-Commerce-Listings abgleichen sollte, überschritt das Budget um 860 % und wurde nie live geschaltet.
Warum wurde die Budgetüberschreitung fünf Monate lang nicht entdeckt?
Öffentlichen Berichten zufolge fehlten Amazon ausreichende Ausgabenkontrollen, und Codierungsfehler waren einer der Faktoren. Amazon hat noch keinen technischen Retrospective-Bericht veröffentlicht, der die spezifischen Mängel oder Überwachungsfehler identifiziert.
Wurde das Problem durch unendliche KI-Schleifen verursacht?
Diese Erklärung tauchte in einigen Sekundärberichten auf, wurde jedoch in den Hauptberichten nicht bestätigt. Die genaue Anzahl der Anfragen, Wiederholungslogik, Token-Mengen und Quellcodefehler sind weiterhin nicht öffentlich.
Gibt es bei Amazon weitere Fälle von KI-Kostenüberschreitungen?
Ja. Angeblich enthielt dieselbe interne Präsentation auch unerwartete Kosten von etwa 541.000 US-Dollar für ein Finanzprüfungsprojekt und 134.000 US-Dollar für ein Logistikprojekt.
Kann AWS Cost Anomaly Detection Claude-Gebühren auf Amazon Bedrock überwachen?
AWS-Dokumentation weist darauf hin, dass Cost Anomaly Detection keine Produkte von Drittanbietern aus dem AWS Marketplace überwacht, einschließlich Anthropic-Claude-Modelle auf Bedrock. AWS empfiehlt die Verwendung von AWS Budgets zur Verwaltung dieser Gebühren und gegebenenfalls von Rechnungseinheiten-Filtern.
Kann AWS Budgets sofort unkontrollierte KI-Ausgaben stoppen?
Allein nicht. AWS gibt an, dass Budgetinformationen mehrmals täglich aktualisiert werden und Kosten vor und nach dem Benachrichtigungszeitraum weiter ansteigen können. Hochvolumige Anwendungen benötigen harte Obergrenzen auf Anfrageebene sowie einen separaten Notaus-Schalter.
Sind Ratenbegrenzungen gleichbedeutend mit Ausgabenbegrenzungen?
Nein. Ratenbegrenzungen steuern den Durchsatz, während Budgets die akzeptablen Kosten steuern. Ein Workflow kann innerhalb der Ratenbegrenzungen laufen und dennoch über Wochen oder Monate das geplante Budget weit überschreiten.
Was ist die wichtigste Kontrolle für KI-Agenten?
Ein hartes Budget für jede Agent-Sitzung, das Anfragen, Token, Tools, Wiederholungen und Zeit umfasst. Erzwingen Sie dieses Budget außerhalb des Agenten und stellen Sie einen getesteten Weg bereit, um den Workflow sofort zu stoppen.
Verwandte Tools
- AWS Budgets: Verfolgt Kosten und Nutzung im Vergleich zu Schwellenwerten und löst Benachrichtigungen oder konfigurierte Budgetaktionen aus.
- AWS Cost Anomaly Detection: Erkennt ungewöhnliche AWS-Ausgabenmuster in unterstützten Abrechnungskategorien.
- AWS Cost Explorer: Hilft Teams, historische Kosten und Nutzung über AWS-Dienste und Abrechnungsdimensionen zu analysieren.
- Amazon-Bedrock-Modellaufrufprotokollierung: Protokolliert unterstützte Modellaufrufe und zugehörige Metadaten in CloudWatch Logs oder Amazon S3.
- Amazon-Bedrock-Servicekontingente: Zeigt Modell- und Endpunktlimits, die den Inferenzdurchsatz einschränken können.
- Anthropic Console: Bietet API-Schlüssel, Nutzungsberichte, Kostenberichte, Workspaces und Kontenebenen-Kontrollen für die direkte Nutzung der Anthropic-API.
Verwandte Links
- Financial Times: Amazons KI-Ausgabenüberschreitung: Hauptbericht über das 1,8-Millionen-Dollar-Projekt und zusätzliche interne Kostenüberschreitungen.
- AWS-Budgets-Dokumentation: Offizieller Leitfaden zur Verfolgung von AWS-Kosten und -Nutzung anhand von Budgets.
- AWS-Budget-Aktionen: Erläutert automatische oder genehmigungspflichtige Aktionen bei Überschreitung von Schwellenwerten.
- AWS-Cost-Anomaly-Detection-Einschränkungen: Dokumentiert die Anomalieüberwachung und den Ausschluss von Drittanbieter-Marketplace-Modellgebühren.
- [Amazon-Bedrock-Aufrufprotokollierung](https://docs.aws.amazon.
com/bedrock/latest/userguide/model-invocation-logging.html): Offizielle Anleitung zur Einrichtung und Datenverarbeitung für Bedrock-Aufrufprotokolle.
- Anthropic Kosten- und Nutzungsberichte: Erläutert die Berichte zu Kosten, Nutzung, Token, Modellen, Arbeitsbereichen und Rate-Limits in der Anthropic-Konsole.
- Anthropic API-Ratenlimits: Beschreibt die Begrenzungen für Anfragen, Eingabe-Token, Ausgabe-Token und Nutzungsstufen.
Zusammenfassung
Ein internes Amazon-Projekt mit Claude Sonnet verursachte Berichten zufolge Kosten von 1,8 Millionen US-Dollar, überschritt das Budget um 860 %, blieb fünf Monate lang unentdeckt und ging nie in Betrieb. Andere KI-Projekte sollen unerwartete Ausgaben in Höhe von mehreren Hunderttausend Dollar verursacht haben.
Öffentliche Aufzeichnungen bestätigen nicht, dass das Hauptproblem durch eine Endlosschleife von Anfragen verursacht wurde. Was die Aufzeichnungen belegen, ist die Kluft zwischen der Geschwindigkeit, mit der KI-Workflows Ausgaben erzeugen, und der Geschwindigkeit, mit der Organisationen Probleme erkennen.
Unternehmen sollten eine Kombination aus Einzelanfrage-Tracking, Budgets auf Job-Ebene, Token- und Tool-Begrenzungen, kontrollierten Wiederholungsversuchen, Modell-Routing, Cloud-Budgets, automatisierten Aktionen sowie Notausschaltern kombinieren, die Agenten nicht außer Kraft setzen können.
**
Die sicherste Regel ist einfach: Kein KI-Prozess sollte fünf Monate laufen, ohne wiederholt nachzuweisen, dass er weiterhin nützlich ist, innerhalb des Budgets liegt und autorisiert ist, fortzufahren.



