Trainieren von Machine-Learning-Modellen mit TrueFoundry Jobs

Auf Geschwindigkeit ausgelegt: ~ 10 ms Latenz, auch unter Last
Unglaublich schnelle Methode zum Erstellen, Verfolgen und Bereitstellen Ihrer Modelle!
- Verarbeitet mehr als 350 RPS auf nur 1 vCPU — kein Tuning erforderlich
- Produktionsbereit mit vollem Unternehmenssupport
Einführung
In diesem Blog stellen wir Ihnen das Trainieren von Machine-Learning-Modellen auf der TrueFoundry-Plattform vor. Wir werden besprechen, wie wir Training-Jobs auf TrueFoundry ausführen können. Wir werden auch sehen, wie Sie Hyperparameter-Tuning für Ihre Machine-Learning-Modelle einfach durchführen und Ihre Jobs auf GPUs ausführen können.
Problemstellung
Beginnen wir zunächst mit einer Problemstellung: Angenommen, wir möchten sehen, wie sich die Diabetes-Erkrankung bei einem Patienten auf der Grundlage verschiedener Merkmale wie Alter, BMI, Blutdruck usw. entwickeln wird. In diesem Blog werden wir das Diabetes Dataset Machine-Learning-Modell in scikit-learn trainieren.
Apropos Trainieren von Machine-Learning-Modellen: Es gibt mehrere Möglichkeiten, dies zu tun, wie z. B. das Training lokal auf Ihrem Rechner, das Training in Jupyter Notebooks usw. Der Trainingsprozess erfordert jedoch möglicherweise mehr Ressourcen, als auf einem lokalen Rechner verfügbar sind.
Hier ermöglichen Ihnen TrueFoundry Jobs, den Trainingscode so zu bereitstellen, dass er auf einem Remote-Rechner ausgeführt wird, und Sie können die Logs und Metriken verfolgen.
Hinweis: Obwohl wir diesen Diabetes-Datensatz verwenden, gelten die in diesem Blog genannten Anweisungen auch für andere Machine-Learning- / Deep-Learning-Modelle.
Was ist ein TrueFoundry Job?
Jobs bieten eine Möglichkeit, kurzlebige, parallele oder sequentielle Batch-Aufgaben innerhalb des Clusters auszuführen. Jobs sind so konzipiert, dass sie bis zum Abschluss laufen, anstatt langlebige Dienste oder kontinuierlich laufende Anwendungen zu sein. Sobald ein Job abgeschlossen ist, werden Rechen- und Speicherressourcen freigegeben, sodass keine zusätzlichen Kosten entstehen.
Modell-Trainings-Job auf TrueFoundry
Wie bereits erwähnt, werden wir das Diabetes Dataset in scikit-learn verwenden. Der Datensatz enthält 442 Stichproben (Patienten) und 10 Merkmale, die alle numerisch sind. Die Merkmale repräsentieren verschiedene Faktoren, die das Fortschreiten von Diabetes bei Patienten beeinflussen können. Die Zielvariable ist ebenfalls numerisch und repräsentiert ein quantitatives Maß für das Fortschreiten der Krankheit ein Jahr nach der Baseline für jeden Patienten.
Einrichtungsanweisungen
Bevor wir mit dem Training von Machine-Learning-Modellen fortfahren, gehen wir die Einrichtungsanweisungen durch:
Erstellen eines Workspace
Gehen Sie zum TrueFoundry Dashboard und erstellen Sie ein Konto. Sobald Sie sich anmelden, werden Sie aufgefordert, einen Workspace zu erstellen. Sie würden Ihre Jobs in diesem Workspace bereitstellen.

Erstellen eines ML Repos
Sobald Sie Ihren Workspace erstellt haben, fahren Sie fort und erstellen Sie ein ML Repository über das Dashboard.
Ein ML Repository ist eine Sammlung von Runs, Modellen und Artefakten, die ein Machine-Learning-Projekt repräsentiert. Sie können es sich wie ein Git-Repository vorstellen, außer dass es Artefakte, Modelle und Metadaten beherbergt. Alle Zugriffskontrollen können auf Ebene des ml-repo konfiguriert werden.
Hinzufügen von ML-Repo-Zugriff zu Ihrem Workspace
Sobald das ML Repo erstellt ist, gehen Sie zu Workspaces, bearbeiten Sie Ihren Workspace und aktivieren Sie 'ML Repo Access'. Klicken Sie auf 'Add ML Repo Access', um Ihr ML Repo zu diesem Workspace hinzuzufügen. Dadurch erhält der im Workspace laufende Job die Berechtigung, in das ML-Repo zu schreiben und daraus zu lesen.
servicefoundry installieren
pip install servicefoundry
Bei TrueFoundry anmelden
--host: Übergeben Sie hier Ihre TrueFoundry Dashboard URL
sfy login --host <YOUR-HOST-URL-HERE>
Sobald wir die obigen Einrichtungsanweisungen abgeschlossen haben, können wir mit dem Implementierungsabschnitt fortfahren.
Implementierung
Verzeichnisstruktur
In diesem Blog halten wir uns an die folgende Verzeichnisstruktur, wobei:
❯ tree
.
├── deploy.py
├── requirements.txt
└── train.py
Gehen wir nun den Diabetes-Modell-Trainingscode durch:
Schritte zum Modell-Training
Schritt 1: Importieren der erforderlichen Bibliotheken
from sklearn.metrics import accuracy_score
from sklearn.datasets import load_diabetes
from sklearn.model_selection import train_test_split
from sklearn.compose import TransformedTargetRegressor
from sklearn.preprocessing import QuantileTransformer
from sklearn.svm import SVR
Schritt 2: Laden des Datensatzes
X, y = load_diabetes(as_frame=True, return_X_y=True)
Schritt 3: Aufteilen des Datensatzes in Trainings- und Testsets
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)
Schritt 4: Erstellen und Trainieren des Machine-Learning-Modells
regressor = SVR(kernel=kernel)
model = TransformedTargetRegressor(
regressor=regressor,
transformer=QuantileTransformer(n_quantiles=n_quantiles, output_distribution="normal"),
)
model.fit(X_train, y_train)
Schritt 5: Vorhersagen auf den Testdaten treffen
y_pred = model.predict(X_test)
Schritt 6: Bewerten der Leistung des Modells
accuracy = accuracy_score(y_test, y_pred)
print(f"Accuracy: {accuracy:.2f}")
Vollständiger Code für das Modell-Training
from sklearn.metrics import accuracy_score
from sklearn.datasets import load_diabetes
from sklearn.model_selection import train_test_split
from sklearn.compose import TransformedTargetRegressor
from sklearn.preprocessing import QuantileTransformer
from sklearn.svm import SVR
def train(kernel: str, n_quantiles: int):
# load the dataset and create train and test sets
X, y = load_diabetes(as_frame=True, return_X_y=True)
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)
# initialize the model
regressor = SVR(kernel=kernel)
model = TransformedTargetRegressor(
regressor=regressor,
transformer=QuantileTransformer(n_quantiles=n_quantiles, output_distribution="normal"),
)
# train and test model
model.fit(X_train, y_train)
y_pred = model.predict(X_test)
accuracy = accuracy_score(y_test, y_pred)
print(f"Accuracy: {accuracy:.2f}"
return regressor, model, X_test, y_test
Nachdem wir nun den Code zum Trainieren eines Machine-Learning-Modells gesehen haben, können wir fortfahren und lernen, wie solche Modelle für die zukünftige Verwendung gespeichert (oder geloggt) werden.
Ein Modell besteht aus einer Modelldatei und einigen Metadaten. Jedes Modell kann mehrere Versionen haben. Wir können Modellobjekte mithilfe der Methode save_model_metadata automatisch serialisieren, speichern und versionieren. Hier sind die Schritte dazu:
Schritte zum Modell-Logging
Schritt 1: Importieren der erforderlichen Bibliotheken
import mlfoundry
Schritt 2: Erstellen eines ML Repo Runs
run = mlfoundry.get_client().create_run(ml_repo=ml_repo, run_name="SVR-with-QT")
Ein Run repräsentiert ein einzelnes Experiment, das im Kontext von Machine Learning ein spezifisches Modell (z. B. Logistische Regression) mit einem festen Satz von Hyperparametern ist. Metriken und Parameter (Details unten) werden alle unter einem spezifischen Run geloggt.
Schritt 3: Loggen von Modell-Hyperparametern
run.log_params(regressor.get_params())
Schritt 4: Loggen von Modell-Metriken
run.log_metrics({"score": model.score(X_test, y_test)})
Schritt 5: Serialisieren und Loggen eines versionierten Modells
model_version = run.log_model(name="diabetes-regression", model=model, framework="sklearn")
print("model_version =", model_version.version, "model_fqn =", model_version.model_fqn)
Jedes geloggte Modell generiert eine neue Version, die mit dem angegebenen name assoziiert und mit dem aktuellen Run verknüpft ist. Mehrere Versionen des Modells können als separate Versionen unter demselben name geloggt werden.
Vollständiger Code für das Modell-Logging
import mlfoundry
def save_model_metadata(regressor, model, X_test, y_test, ml_repo):
# create a run in truefoundry’s ml_repo
run = mlfoundry.get_client().create_run(ml_repo=ml_repo, run_name="SVR-with-QT")
# log the hyperparameters of the model
run.log_params(regressor.get_params())
# log the metrics of the model
run.log_metrics({"score": model.score(X_test, y_test)})
# log the model
model_version = run.log_model(name="diabetes-regression", model=model, framework="sklearn")
print("model_version =", model_version.version, "model_fqn =", model_version.model_fqn)
Nachdem wir nun den Prozess des Modell-Trainings und -Loggings gesehen haben, können wir diesen in einer einzigen train.py-Datei zusammenfassen. Der finale Inhalt der Datei train.py sollte wie folgt aussehen:
train.py
# required import statements for both functions
def train(kernel, n_quantiles):
...
def save_model_metadata(regressor, model, X_test, y_test, ml_repo):
...
regressor, model, X_test, y_test = train(kernel="linear", n_quantiles=100)
save_model_metadata(regressor, model, X_test, y_test, ml_repo="YOUR ML REPO NAME")
Damit ist unser Code für das Modell-Training und -Logging abgeschlossen. Jetzt müssen wir den Modell-Trainingscode als Job bereitstellen. Das deploy.py enthält den Code zur Bereitstellung des obigen Modell-Trainingscodes wie unten gezeigt:
deploy.py
from servicefoundry import Build, Job, PythonBuild, LocalSource
# defining the job specifications
job = Job(
name="diabetes-train-job",
image=Build(
build_spec=PythonBuild(command="python train.py", requirements_path="requirements.txt"),
build_source=LocalSource(local_build=False)
),
)
deployment = job.deploy(workspace_fqn="YOUR WORKSPACE FQN HERE")
Die Datei requirements.txt sollte die folgenden Pakete enthalten:
requirements.txt
pandas==1.3.5
scikit-learn==1.2.1
mlfoundry>=0.7.2,<0.8.0
Im obigen deploy.py-Code wird ein Job bereitgestellt, der den Genauigkeitswert (Accuracy Score) des trainierten Modells in den Logs anzeigt, wenn er aufgerufen wird. Er loggt auch das trainierte Machine-Learning-Modell. Dazu wird ein Job-Objekt unter Verwendung der Klasse servicefoundry.Job erstellt. Der Job-Name lautet hier diabetes-train-job.
HINWEIS: Stellen Sie sicher, dass Sie "YOUR ML REPO NAME" durch Ihren ML-Repo-Namen in train.py und "YOUR WORKSPACE FQN HERE" durch Ihren Workspace-FQN in der Datei deploy.py ersetzen.
In der Datei train.py müssen Sie das von Ihnen erstellte Name of the ML Repo an die Funktion save_model_metadata() übergeben. In der Datei deploy.py müssen Sie den FQN des von Ihnen erstellten Workspace an die Funktion job.deploy() übergeben. Führen Sie nun den folgenden Befehl aus, um den Job bereitzustellen:
python deploy.py
Nach dem Bereitstellen des Trainings-Jobs gehen Sie zum Unterabschnitt "Jobs" im Abschnitt "Deployments". Es sollte ähnlich wie folgt aussehen:

Nachdem wir nun mit der Bereitstellung unseres Jobs fertig sind, wollen wir ihn auslösen (triggern). Sie können dies entweder über unser Python SDK oder das TrueFoundry Dashboard tun. Zuerst sprechen wir über das Auslösen von Jobs über das TrueFoundry Dashboard. Um mehr über andere Methoden zum Auslösen von Jobs zu erfahren, lesen Sie den Abschnitt Triggering Jobs from Python SDK.
Auslösen von Job-Runs über die Benutzeroberfläche
Nachdem der obige Trainings-Job die Bereitstellung abgeschlossen hat, gehen Sie zum Unterabschnitt "Jobs" im Abschnitt "Deployments", klicken Sie auf "diabetes-train-job" und klicken Sie auf "Run Job", um den Job vor dem Auslösen zu konfigurieren. Es sollte ähnlich wie folgt aussehen:

Klicken Sie auf dem obigen Bildschirm unten rechts auf "Run Job", um diesen Job auszulösen. Nachdem der Trainings-Job die Ausführung beendet hat, gehen Sie zum Unterabschnitt "Jobs" im Abschnitt "Deployments" und klicken Sie auf "diabetes-train-job"; es sollte ähnlich wie folgt aussehen:

Klicken Sie unter "Run Details" auf "SVR-with-QT", um wichtige Metriken und Hyperparameter zu sehen, die in der Datei train.py geloggt wurden. Es sollte ähnlich wie folgt aussehen:

Hyperparameter-Tuning
Stellen Sie sich vor, Sie haben großflächige Datenverarbeitungs- oder Batch-Verarbeitungsaufgaben, bei denen das Ausführen eines einzelnen Jobs mit unterschiedlichen Konfigurationen unerlässlich ist, um nicht nur Ihren Workflow zu rationalisieren, sondern auch die Konsistenz bei der Jobausführung zu gewährleisten. In solchen Fällen ist ein parametrisierter Job nützlich.
Ein parametrisierter Job ist ein Job-Typ, der es Ihnen ermöglicht, mehrere Instanzen (Pods) mit unterschiedlichen Parametern oder Eingaben zu erstellen. Das primäre Ziel eines parametrisierten Jobs besteht darin, Flexibilität bei der Jobausführung zu bieten, indem sein Verhalten für verschiedene Szenarien angepasst wird.
Als Beispiel ist ein Job mit dem Befehl python main.py --n_quantiles {{n_quantiles}} ein parametrisierter Job, da er n_quantiles als Eingabe vor der Ausführung entgegennimmt. Wir können den oben bereitgestellten Job mithilfe von Parametern vereinfachen.
Um die Befehlszeilenargumente zu parsen, verwenden wir das Modul argparse. Der folgende Code zeigt den aktualisierten Code für die Dateien train.py und deploy.py, wobei die Standardwerte von kernel und n_quantiles jeweils linear und 100 sind:
train.py
import os, argparse
def train(kernel, n_quantiles):
...
def log_model(regressor, model, X_test, y_test, ml_repo):
...
parser = argparse.ArgumentParser()
parser.add_argument("--kernel", default="linear", type=str)
parser.add_argument("--n_quantiles", default=100, type=int)
args = parser.parse_args()
regressor, model, X_test, y_test = train(kernel=args.kernel, n_quantiles=args.n_quantiles)
log_model(regressor, model, X_test, y_test, ml_repo=os.environ.get("ML_REPO_NAME"))
deploy.py
import argparse
from servicefoundry import Build, Job, PythonBuild, Param, LocalSource
parser = argparse.ArgumentParser()
parser.add_argument("--workspace_fqn", type=str, required=True)
parser.add_argument("--ml_repo", type=str, required=True)
args = parser.parse_args()
cmd = "python train.py --kernel {{kernel}} --n_quantiles {{n_quantiles}}"
# Defining the job specifications
# Only the command changes in 'image' attribute
job = Job(
...
image=Build(build_spec=PythonBuild(command=cmd, ...), ...),
params=[
Param(name="n_quantiles", default='100'),
Param(name="kernel", default='linear', description="svm kernel"),
],
env={ "ML_REPO_NAME": args.ml_repo }
)
deployment = job.deploy(workspace_fqn=args.workspace_fqn)
HINWEIS: Stellen Sie sicher, dass Sie "YOUR ML REPO NAME" durch Ihren ML-Repo-Namen und "YOUR WORKSPACE FQN HERE" durch Ihren Workspace-FQN im folgenden Befehl ersetzen.
Führen Sie nun den folgenden Befehl aus, um den parametrisierten Job bereitzustellen:
python deploy.py --workspace_fqn "YOUR WORKSPACE FQN HERE" --ml_repo "YOUR ML REPO NAME"
Alternativ können Sie ihn direkt aus unserem Github-Repository ausführen.
git clone https://github.com/truefoundry/truefoundry-examples.git
cd training-job-example
python deploy.py --workspace_fqn "YOUR WORKSPACE FQN HERE" --ml_repo "YOUR ML REPO NAME"
Version 2 des Jobs wird erstellt, nachdem die Bereitstellung abgeschlossen ist. Nachdem der Trainings-Job die Bereitstellung abgeschlossen hat, besteht der nächste Schritt darin, diesen Job auszulösen.

Klicken Sie auf den „diabetes-train-job“ und dann auf „Run Job“, um den Job vor dem Auslösen zu konfigurieren. Sie können nun die Parameter n_quantiles und kernel ändern. Es sollte ähnlich wie hier aussehen:

Versuchen Sie, Job-Runs mit unterschiedlichen Werten für den Parameter kernel auszulösen, z. B. linear, sigmoid, poly und rbf. Analog dazu können Sie verschiedene Werte für den Parameter n_quantiles verwenden, etwa 50, 80, 100 etc. Die verschiedenen Job-Runs sollten ähnlich wie hier aussehen:

Vergleichen von Job-Runs über die UI
Sie können die Metrics verschiedener Job-Runs im Dashboard vergleichen, indem Sie oben rechts im Dashboard auf die Schaltfläche „Compare“ klicken, wie unten gezeigt:
Mehr über Parameterized Job Deployment erfahren Sie hier:
Job-Runs über das Python SDK auslösen
Bisher haben wir das Auslösen von Job-Runs nur über das TrueFoundry Dashboard gesehen. Da das Auslösen eines Jobs über die UI jedoch nicht immer optimal ist, gehen wir nun durch, wie Sie einen Job programmgesteuert über das Python SDK auslösen.
Sie können Ihren Job programmgesteuert mit der Funktion trigger_job auslösen, wie unten gezeigt:
from servicefoundry import Job, trigger_job
# Configure a Job Deployment
job = Job(...)
# Deploy a Job
job_deployment = job.deploy(workspace_fqn="YOUR WORKSPACE FQN")
# Trigger/Run a Job
trigger_job(
application_fqn=job_deployment.application_fqn,
params={"n_quantiles":"80"}
)
Es ist auch möglich, die application_fqn ganz einfach aus dem Dashboard zu beziehen, indem Sie zu Deployments --> Jobs gehen und nach Ihrem Job-Namen in Ihrem Workspace suchen (hier diabetes-train-job).
Nachfolgend finden Sie ein weiteres Beispiel für das programmgesteuerte Auslösen eines Jobs. Ersetzen Sie dazu im unten stehenden Code zunächst YOUR_APPLICATION_FQN durch die Application FQN des oben deployeden Jobs. Die Application FQN für eine Anwendung ist unten hervorgehoben:

Im unten gezeigten Code wählen wir zufällig einen Wert für die Modellparameter aus und lösen einen Job-Run mit diesen Parametern aus. Danach suchen wir in den Job-Runs nach dem Run mit der maximalen score. Der Job-Run mit dem maximalen Score zeigt eine optimalere Wahl der Modellparameter an.
import random
import mlfoundry as mlf
from servicefoundry import trigger_job
# Find deployed job, replace with the application fqn of your job
application_fqn = "YOUR_APPLICATION_FQN"
# Randomly generate params
n_quantiles = random.randint(50, 100)
kernel_values = ['linear', 'sigmoid', 'poly', 'rbf']
kernel = kernel_values[random.randrange(0, len(kernel_values))]
# Trigger/Run a Job
triggered_job = trigger_job(
application_fqn=application_fqn,
params={
"n_quantiles": str(n_quantiles),
"kernel": kernel
}
)
print(f'Triggered job run with n_quantiles={n_quantiles} and kernel={kernel} and name as', triggered_job.jobRunName)
client = mlf.get_client()
ml_repo_name = "YOUR ML REPO NAME HERE"
runs = client.search_runs(ml_repo=ml_repo_name)
max_score = 0
for run in runs:
metrics = run.get_metrics()
print(f'All Metrics for run with name as {run.run_name}":', metrics)
if 'score' in metrics:
max_score = max(max_score, metrics['score'][0].value)
print("Model Max Score: ", max_score)
HINWEIS: Stellen Sie sicher, dass Sie im folgenden Befehl „YOUR ML REPO NAME HERE“ durch den Namen Ihres ML-Repos und „YOUR WORKSPACE FQN HERE“ durch den FQN Ihres Workspaces ersetzen.
Mehr zum Auslösen von Jobs erfahren Sie hier:
Vergleichen von Job-Runs über das Python SDK
Sie können die Metriken verschiedener Job-Runs programmgesteuert mithilfe der Funktion mlfoundry.search_runs vergleichen, wie im folgenden Code beschrieben:
import mlfoundry as mlf
client = mlf.get_client()
ml_repo_name = "YOUR-ML-REPO-NAME"
# Returns all runs
runs = client.search_runs(ml_repo=ml_repo_name)
# Search for the subset of runs with logged accuracy metric > 0.7
filter_string = "metrics.score > 0.7"
runs = client.search_runs(ml_repo=ml_repo_name, filter_string=filter_string)
Mehr über die Funktion search_runs erfahren Sie hier:
Bereitstellen eines Jobs unter Nutzung von GPUs
Stellen Sie sich vor, Sie arbeiten mit groß angelegten Modellen, die Millionen oder Milliarden von Parametern aufweisen. Das Training solcher Modelle mit herkömmlichen CPUs wäre sehr zeitaufwendig und aufgrund von Speicherbeschränkungen möglicherweise gar nicht durchführbar.
Beispiel: Das Training eines CNN-Modells auf Basis des CIFAR-10-Datensatzes in einer CPU-Umgebung mit 10 Epochen dauert 36 Minuten und 31 Sekunden, während dasselbe Modell beim Training in einer GPU-Umgebung (NVIDIA K80) nur 4 Minuten und 6 Sekunden benötigte. Das ist eine Verbesserung um den Faktor 9x (Siehe hier)
GPUs spielen eine entscheidende Rolle beim Training von Großmodellen. Sie bieten die notwendige Speicherbandbreite und parallele Verarbeitungsfähigkeiten, um große Modellgrößen und komplexe Architekturen effizient zu verarbeiten. Im Folgenden gehen wir darauf ein, wie Sie eine GPU in einem Job verwenden.
Die Verwendung einer GPU im obigen Beispiel erfordert leichte Anpassungen bei der Konfiguration eines Jobs in der Datei deploy.py. Der folgende Code zeigt die aktualisierte Job-Konfiguration für GPU-Nutzung sowie benutzerdefinierte CPU- und Speicher-Ressourcenzuweisung:
deploy.py
from servicefoundry import Job, NodeSelector, GPUType, Resources
job = Job(
resources=Resources(
# Configure GPU
gpu_count=1,
node=NodeSelector(gpu_type=GPUType.T4)
# (Optional) Configure CPU and Memory Resources
cpu_request=0.2,
cpu_limit=0.5,
memory_request=128,
memory_limit=512,
),
...
)
Hinweis: Der restliche Code bleibt unverändert
Weitere Optionen zur Job-Bereitstellung
Bisher haben wir mehrere Optionen zur Job-Bereitstellung wie image, params und env kennengelernt. Es gibt verschiedene Möglichkeiten, Ihren Job mit erweiterten Optionen anzupassen. Dazu gehören unter anderem:
Trigger-Typ und Concurrency festlegen
Wir haben bisher über Jobs gesprochen, die manuell entweder über das TrueFoundry Dashboard oder das Python SDK ausgelöst werden können. Was aber, wenn wir einen Job nach einem Zeitplan ausführen möchten (wie einen Cron-Job)?
Ein Cron-Job führt den definierten Job nach einem sich wiederholenden Zeitplan aus. Dies kann nützlich sein, um ein Modell regelmäßig neu zu trainieren, Berichte zu erstellen und vieles mehr. Wir können solche Jobs implementieren, indem wir ihren trigger-Typ wie folgt ändern:
from servicefoundry import Job, Schedule
job = Job(
trigger=Schedule(
schedule="0 8 1 * *",
concurrency_policy="Forbid" # Values: ["Forbid","Allow", "Replace"]
),
concurrency_limit=3,
...
)
Bei Cron-Jobs kann es vorkommen, dass der vorherige Durchlauf des Jobs noch nicht abgeschlossen ist, wenn aufgrund des geplanten Zeitpunkts bereits die Zeit für den nächsten Durchlauf gekommen ist. In solchen Fällen können wir die concurrency_policy wie folgt definieren:
Forbid: Dies ist der Standardwert. Keine gleichzeitigen Ausführungen zulassen.Allow: Gleichzeitige Ausführung von Jobs zulassen. Optional kann die maximale Anzahl gleichzeitig auszuführender Jobs geändert werden, indem concurrency_limit auf den gewünschten Wert gesetzt wird.Replace: Ersetzt den aktuellen Job durch den neuen.
Concurrency gilt nicht für manuell ausgelöste Jobs. In diesem Fall wird immer ein neuer Job-Durchlauf erstellt.
Retries konfigurieren
Der Job-Status kann 3 Typen haben: FINISHED, TERMINATED und FAILED. Ein Job kann so konfiguriert werden, dass er im Fehlerfall mehrere erneute Versuche unternimmt.
Ein Job wird als FAILED markiert, wenn er auch nach der konfigurierten Anzahl von Wiederholungsversuchen nicht erfolgreich abgeschlossen werden kann. Retries können für einen Job wie folgt konfiguriert werden:
from servicefoundry import Job
job = Job(
retries=6, # default = 1
...
)
Timeout konfigurieren
In einigen Anwendungsfällen müssen Sie möglicherweise angeben, wie lange ein Job maximal ausgeführt werden soll.
Mithilfe von timeout können Sie (in Sekunden) die maximale Ausführungszeit für einen Job festlegen, unabhängig davon, ob er fehlgeschlagen ist oder nicht. Dies hat Vorrang vor dem retries Limit. Standardmäßig ist dies auf 1000 Sekunden eingestellt.
Wenn Sie beispielsweise retries auf 6 und ein timeout von 480 Sekunden festlegen, wird der Job nach 480 Sekunden beendet, unabhängig davon, wie oft versucht wurde, ihn auszuführen.
from servicefoundry import Job
job = Job(
timeout=480,
...
)
Zusätzliche Optionen zur Job-Bereitstellung
Abgesehen von den in diesem Blog besprochenen Optionen zur Job-Bereitstellung gibt es noch weitere, auf die wir in diesem Blog nicht eingehen werden, wie zum Beispiel:
- Wie stellt man einen Job mithilfe eines Pre-built Image bereit?
- Wie stellt man einen Job mithilfe einer Dockerfile bereit?
.... und einige mehr. Sie können sich an unsere unten angegebene Dokumentation wenden, um die Antworten auf die obigen Fragen zu erhalten :)
Weitere Beispiele
Unser öffentliches Repository truefoundry-examples enthält den Job-Quellcode dieses Blogs sowie mehrere Beispiele wie LLM Finetuning, Getting Started with Notebooks und End-to-End Examples, die einen breiteren Einblick in die von der TrueFoundry Plattform gebotenen Funktionen geben.
Fazit
Zusammenfassend bietet TrueFoundry's Job ein leistungsstarkes Framework für die Verwaltung und Ausführung von Trainingsaufgaben auf skalierbare, fehlertolerante und ressourceneffiziente Weise.
Sie ermöglichen Ihnen die Verteilung und Steuerung der Ausführung von Machine-Learning-Workloads, die Überwachung ihres Fortschritts sowie die Sicherstellung, dass Ihre Trainingsmodelle effektiv und zuverlässig trainiert werden. Dies macht sie ideal für die Ausführung von einmaligen oder On-Demand-Aufgaben.
TrueFoundry AI Gateway bietet eine Latenz von ~3—4 ms, verarbeitet mehr als 350 RPS auf einer vCPU, skaliert problemlos horizontal und ist produktionsbereit, während LiteLM unter einer hohen Latenz leidet, mit moderaten RPS zu kämpfen hat, keine integrierte Skalierung hat und sich am besten für leichte Workloads oder Prototyp-Workloads eignet.


















%20(28).webp)



.webp)
.webp)
.png)

.png)
.png)
.png)
.png)
.png)
.webp)
.webp)






