RunPod Serverless Abrechnung: Kosten bei fehlgeschlagenen Jobs verstehen

Die Serverless-Plattform von RunPod bietet eine leistungsstarke Möglichkeit zur Bereitstellung von KI-Modellen. Das Verständnis ihres Abrechnungsmodells, insbesondere bei fehlgeschlagenen Jobs, ist jedoch unerlässlich, um unerwartete Kosten zu vermeiden. Viele Benutzer sind überrascht, wenn ihr Guthaben sinkt, obwohl scheinbar keine Anfragen erfolgreich waren. Dies liegt daran, dass die Serverless-Abrechnung die Worker-Zeit und nicht die Ergebnisse der Anfragen verfolgt.

Der abrechenbare Lebenszyklus eines Serverless-Workers

Ein Serverless-Endpunkt fungiert als Warteschlange oder Router für einen Pool von Workern, bei denen es sich um Container handelt, die Ihren Code auf einer GPU ausführen. Die Plattform verwaltet diesen Pool und skaliert ihn zwischen Ihren definierten Grenzen für 'Active workers' und 'Max workers'. Die Abrechnung erfolgt pro Sekunde und umfasst jede Phase, in der Ihr Container aktiv auf einer GPU läuft. Dazu gehören der anfängliche Kaltstart (Container-Start, Modellladung), die Ausführung Ihres Codes und das Leerlaufzeitfenster nach Abschluss eines Jobs, bis das Leerlauf-Timeout erreicht ist. Selbst wenn ein Job fehlschlägt, wird die für den Start und die Ausführung aufgewendete GPU-Zeit trotzdem abgerechnet. Für 'Active workers' erfolgt die Abrechnung kontinuierlich, da sie rund um die Uhr laufen gelassen werden, um die Latenz zu minimieren.

Ausführung, Erfolg, Wiederholungsversuche und was Benutzer sehen

Verwirrung entsteht oft durch die unterschiedlichen Signale, die den Status eines Jobs anzeigen, im Gegensatz zu dem, was tatsächlich Gebühren verursacht. Der entscheidende Unterschied besteht darin, dass der Jobstatus (z. B. COMPLETED, FAILED, TIMED_OUT) das Ergebnis der Arbeit beschreibt, während der Worker-Status der direkte Bestimmungsfaktor für die Abrechnung ist. Ein Worker, der zehn Minuten für einen fehlgeschlagenen Job aufwendet, verursacht die gleichen Kosten wie ein Worker, der eine Aufgabe im gleichen Zeitraum erfolgreich abschließt. Wiederholte Fehler, wie z. B. abstürzende Worker beim Start oder hängende Handler bis zum Ausführungs-Timeout, sind besonders kostspielig, da sie Worker-Zeit verbrauchen, ohne Ergebnisse zu liefern, und Wiederholungsversuche auslösen können, was die Kosten weiter erhöht. Clientseitige Timeouts oder vom Benutzer initiierte Abbrüche stoppen den abgerechneten Worker-Prozess nicht automatisch.

Nachverfolgung von Überraschungsgebühren

Wenn unerwartete Gebühren auftreten, ist der erste Schritt, das Zeitfenster und den spezifischen Endpunkt zu ermitteln, der dafür verantwortlich ist, mithilfe der Abrechnungsdaten in der Konsole oder der REST-API. Anschließend ist die Untersuchung des Metrics-Tabs des Endpunkts entscheidend. Achten Sie auf Muster wie eine hohe Rate fehlgeschlagener oder wiederholter Anfragen, lange Ausführungszeiten, die auf hängende Jobs hindeuten, oder zahlreiche Kaltstarts mit wenigen abgeschlossenen Aufgaben, was auf Absturzschleifen beim Start hindeutet. Der Health-Endpunkt bietet eine Echtzeit-Momentaufnahme der Job- und Worker-Status. Weitere Untersuchungen umfassen die Überprüfung des Requests-Tabs auf TIMED_OUT- oder FAILED-Jobs mit langen Ausführungszeiten und des Workers-Tabs auf Anzeichen von Fluktuation oder auf Worker, die im Status 'initializing' feststecken. Schließlich sind die Worker-Logs von unschätzbarem Wert für die Diagnose von Startfehlern und die Ermittlung der Grundursache von Abstürzen, wie z. B. Out-of-Memory-Fehler oder fehlgeschlagene Modelldownloads.

Einstellungen, die Ihre Ausgaben beeinflussen

Mehrere Endpunkt-Einstellungen beeinflussen die Kosten direkt, insbesondere wenn Probleme auftreten. Max workers bestimmt die maximalen potenziellen Ausgaben während einer Fehlerkaskade, während Active workers kontinuierliche Gebühren verursachen. Die GPU-Typ-Priorität kann zu höheren Sekundentarifen führen, wenn Fallback-Optionen teurer sind. Das Idle timeout bestimmt, wie lange ein Worker nach einem Job aktiv bleibt, und ein kürzeres Timeout kann die Kosten für burstartigen Traffic reduzieren. Entscheidend ist, dass der Execution timeout als Schutz vor hängenden Jobs dient und verhindert, dass diese unbegrenzt laufen und übermäßige Ressourcen verbrauchen. Entwickler werden angehalten, diese Einstellungen entsprechend ihrer Workload zu dimensionieren und ihre Endpunkte sorgfältig zu überwachen, um zu verhindern, dass kostspielige Fehler eskalieren.