Decision Optimization verwendet die asynchronen APIs watsonx.ai Runtime, um die parallele Ausführung von Jobs zu ermöglichen.

Zur Lösung eines Problems können Sie einen neuen Job aus der Modellbereitstellung erstellen und ihm Daten zuordnen. Siehe Implementierungsschritte und das REST-API-Beispiel. Für die Bereitstellung eines Modells fallen keine Gebühren an. Nur die Lösung eines Modells mit einigen Daten wird basierend auf der Ausführungszeit berechnet.

Um mehr als einen Job gleichzeitig zu bearbeiten, geben Sie beim Erstellen Ihrer Bereitstellung mehr als einen Knoten an. Erhöhen Sie beispielsweise in diesem Beispiel für REST-API den Wert für Anzahl der Knoten, indem Sie den Wert der Knoteneigenschaft ändern: "nodes" : 1.

PODs (Knoten)

Wie ein Job erstellt und übermittelt wird, hängt von der aktuellen Konfiguration und den laufenden Jobs der watsonx.ai Runtime-Instanz ab. Dieser Prozess wird im folgenden Diagramm dargestellt.

1. Der neue Job wird an die Warteschlange gesendet.
2. Wenn ein POD gestartet wird, aber inaktiv ist (d. h. keinen Job ausführt), beginnt er sofort mit der Verarbeitung dieses Jobs.
3. Andernfalls wird ein neuer POD gestartet, wenn die maximale Anzahl Knoten nicht erreicht wird. (Das Starten eines POD kann einige Sekunden dauern. Der Job wird dann diesem neuen POD zur Verarbeitung zugeordnet.
4. Andernfalls wartet der Job in der Warteschlange, bis einer der aktiven Pods beendet ist und den wartenden Job aufnehmen kann.

Es gibt POD-Konfigurationen in folgenden Größen:

Bei allen Konfigurationen sind 1 vCPU und 512 MB für die interne Verwendung reserviert.

Zusätzlich zur Lösungszeit hängt die Preisgestaltung von der ausgewählten Größe durch einen Multiplikator ab.

In der Implementierungskonfiguration können Sie auch die maximale Anzahl der zu verwendenden Knoten festlegen.

Inaktive PODs werden nach Überschreitung eines bestimmten Zeitlimits automatisch gestoppt. Wenn ein neuer Job übergeben wird und keine PODs aktiv sind, dauert es einige Zeit (ca. 30 Sekunden), bis der POD erneut gestartet wird.

Laufzeitbasierte Preisgestaltung (CUH)

Nur die Joblösungszeit wird berechnet: Die Leerlaufzeit für PODs wird nicht berechnet.

Je nach Größe des verwendeten POD wird ein anderer Multiplikator verwendet, um die Anzahl der genutzten Kapazitätseinheitenstunden (Capacity Units Hours, CUH) zu berechnen.

Beispiel für REST-API

Die vollständige Prozedur zum Implementieren eines Modells und Links zur Swagger-Dokumentation finden Sie im Beispiel für REST-API.

Python-API-Beispiel

Zusätzlich zu den REST-APIs wird mit " watsonx.ai Laufzeit eine " Python bereitgestellt, so dass Sie auf einfache Weise ein " Decision Optimization -Modell aus einem " Python " notebook erstellen, einsetzen und verwenden können.

Weitere Informationen enthält das Beispiel für denPython -Client.

Ein Beispiel notebook , das alle Schritte beschreibt und dokumentiert ist über den Ressourcenhubverfügbar.