Blank white background with no objects or features visible.

Hallo EMEA! TrueFoundry baut seine Präsenz in Europa, dem Nahen Osten und Afrika weiter aus. Mehr erfahren. →

Trainieren von Machine-Learning-Modellen mit TrueFoundry Jobs

von TrueFoundry

Aktualisiert: November 3, 2026

Published: April 20, 2026

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:

  1. Forbid: Dies ist der Standardwert. Keine gleichzeitigen Ausführungen zulassen.
  2. 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.
  3. 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.

Try now.

One gateway for all your models, MCP servers, and agents. No credit card needed.

Melde dich an
Inhaltsverzeichniss

Steuern, implementieren und verfolgen Sie KI in Ihrer eigenen Infrastruktur

Buchen Sie eine 30-minütige Fahrt mit unserem KI-Experte

Eine Demo buchen

Der schnellste Weg, deine KI zu entwickeln, zu steuern und zu skalieren

Demo buchen
Summarize with
ChatGPT logo by OpenAI
Perplexity AI logo
Blurry red snowflake on white background, symmetrical frosty design with soft edges and abstract shape.

Entdecke mehr

October 5, 2023
|
Lesedauer: 5 Minuten

<Webinar>GenAi Showcase for Companies

Best Fine Tuning Tools for Model Training
May 3, 2024
|
Lesedauer: 5 Minuten

Die 6 besten Fine-Tuning-Tools für das Modelltraining im Jahr 2026

May 25, 2023
|
Lesedauer: 5 Minuten

Open-Source-LLMs: Nutzen oder untergehen

August 27, 2025
|
Lesedauer: 5 Minuten

Kartierung des On-Prem-AI-Marktes: Von Chips bis zu Control Planes

November 14, 2026
|
Lesedauer: 5 Minuten

Claude Managed Agents vs LangChain Deep Agents: Which Agent Harness Should You Choose?

Keine Artikel gefunden.
November 13, 2026
|
Lesedauer: 5 Minuten

Claude Managed Agents vs TrueForge: Which Agent Harness Should Enterprise Teams Run in 2026

Keine Artikel gefunden.
 What is an LLM Gateway
November 13, 2026
|
Lesedauer: 5 Minuten

Was ist ein LLM Gateway? Ein kompletter Leitfaden

Technik und Produkt
November 13, 2026
|
Lesedauer: 5 Minuten

Helm Charts auf ArtifactHub über Hosting auf GitHub Pages

Technik und Produkt
Keine Artikel gefunden.

Aktuelle Blogs

Black left pointing arrow symbol on white background, directional indicator.
Black left pointing arrow symbol on white background, directional indicator.
Machen Sie eine kurze Produkttour
Produkttour starten
Produkttour