Decision Optimization nutzt 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.

Die Konfiguration von PODs jeder Größe ist wie folgt:

Für alle Konfigurationen sind 1 vCPU und 512 MB für den internen Gebrauch 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 einiger Zeitlimitüberschreitung 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.

Laufzeitabhängige Preisgestaltung (CUH)

Es wird nur die Zeit für die Auftragslösung berechnet, die Leerlaufzeit für PODs wird nicht berechnet.

Je nach Größe des verwendeten PODs wird ein anderer Multiplikator zur Berechnung der Anzahl der verbrauchten Kapazitätseinheiten-Stunden (CUH) verwendet.

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 eine " Python mit " watsonx.ai Laufzeit bereitgestellt, so dass Sie ein " Decision Optimization -Modell aus einem " Python " notebook einfach erstellen, bereitstellen und verwenden können.

Weitere Informationen finden Sie unter Python.

Ein " beispiel " notebook, das alle Schritte beschreibt und dokumentiert ist über den " Ressourcendrehscheibe verfügbar.