Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Kontinuierliche Bereitstellung für erweiterte Clusteroperationen mit Slurm

SageMaker HyperPod Amazon-Cluster, die mit Slurm-Orchestrierung erstellt wurden, unterstützen jetzt Continuous Provisioning, eine Funktion, die mehr Flexibilität und Effizienz bei der Ausführung großer Workloads ermöglicht. AI/ML Durch die kontinuierliche Bereitstellung können Sie schnell mit dem Training beginnen, nahtlos skalieren, Wartungsarbeiten ohne Betriebsunterbrechung durchführen und einen detaillierten Einblick in den Clusterbetrieb erhalten.

Funktionsweise

Das Continuous Provisioning System führt eine Architektur mit gewünschtem Status ein, die das traditionelle Alles-oder-Nichts-Skalierungsmodell ersetzt. Wenn beim vorherigen Modell eine Instanzgruppe nicht vollständig bereitgestellt werden konnte, schlug der gesamte Vorgang zur Clustererstellung oder -aktualisierung fehl und wurde zurückgesetzt. Bei kontinuierlicher Bereitstellung akzeptiert das System Teilkapazität und stellt die verbleibenden Instanzen weiterhin asynchron bereit.

Das System zur kontinuierlichen Bereitstellung:

Die kontinuierliche Bereitstellung ist standardmäßig deaktiviert. Um diese Funktion zu verwenden, stellen Sie Continuous in Ihrer NodeProvisioningMode CreateCluster Anfrage auf ein.

Wenn Continuous Provisioning aktiviert ist, können Sie mehrere Skalierungsvorgänge gleichzeitig initiieren, ohne auf den Abschluss früherer Operationen warten zu müssen. Auf diese Weise können Sie verschiedene Instance-Gruppen im selben Cluster gleichzeitig skalieren und mehrere Skalierungsanforderungen an dieselbe Instance-Gruppe senden.

Priority-based Bereitstellung

Slurm-Cluster erfordern, dass ein Controller-Knoten betriebsbereit ist, bevor Worker-Knoten sich registrieren und Jobs annehmen können. Continuous Provisioning erledigt dies automatisch durch prioritätsbasiertes Provisioning:

Behandlung von Controller-Fehlern

Wenn der Controller-Knoten bei der Clustererstellung die Bereitstellung fehlschlägt, hängt das Verhalten davon ab, ob der Fehler erneut versucht werden kann oder nicht.

Fehler, die wiederholt werden können (z. B. fehlerhafte Instanzen oder vorübergehende Ausfälle):

Non-retryable Fehler (z. B. keine verfügbare Kapazität für den Controller-Instanztyp oder Fehler im Lifecycle-Skript):

Voraussetzungen

Kontinuierliches Provisioning erfordert, dass die Slurm-Bereitstellungsparameter (Knotentypen, Partitionsnamen) über die API-Payload im Feld jeder Instanzgruppe bereitgestellt werden. SlurmConfig Cluster, die auf der provisioning_parameters.json Legacy-Datei in Amazon S3 basieren, sind nicht mit Continuous Provisioning kompatibel.

Nutzungsmessung

HyperPod Cluster mit kontinuierlicher Bereitstellung verwenden Metering auf Instanzebene, um eine genaue Abrechnung zu gewährleisten, die die tatsächliche Ressourcennutzung widerspiegelt. Dieser Zählungsansatz unterscheidet sich von der herkömmlichen Abrechnung auf Clusterebene dadurch, dass jede Instance unabhängig verfolgt wird.

Instance-level Fakturierung

Bei kontinuierlicher Bereitstellung beginnt und endet die Abrechnung auf der Ebene der einzelnen Instances, anstatt auf Statusänderungen auf Clusterebene zu warten. Diese Methode bietet folgende Vorteile:

Lebenszyklus der Abrechnung

Jede Instance in Ihrem HyperPod Cluster folgt diesem Abrechnungszyklus:

Erstellen Sie einen Cluster mit aktivierter kontinuierlicher Bereitstellung

Bereiten Sie eine CreateCluster API-Anforderungsdatei im JSON-Format vor. Stellen NodeProvisioningMode Sie diese Option ein Continuous und geben Sie im Feld jeder Instanzgruppe Informationen zur Slurm-Topologie anSlurmConfig.

// create_cluster.json
{
    "ClusterName": "my-training-cluster",
    "NodeProvisioningMode": "Continuous",
    "Orchestrator": {
        "Slurm": {}
    },
    "InstanceGroups": [
        {
            "InstanceGroupName": "controller-group",
            "InstanceType": "ml.m5.xlarge",
            "InstanceCount": 1,
            "LifeCycleConfig": {
                "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
                "OnCreate": "on_create.sh"
            },
            "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
            "SlurmConfig": {
                "NodeType": "Controller"
            }
        },
        {
            "InstanceGroupName": "login-group",
            "InstanceType": "ml.m5.xlarge",
            "InstanceCount": 1,
            "LifeCycleConfig": {
                "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
                "OnCreate": "on_create.sh"
            },
            "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
            "SlurmConfig": {
                "NodeType": "Login"
            }
        },
        {
            "InstanceGroupName": "worker-gpu-a",
            "InstanceType": "ml.p5.48xlarge",
            "InstanceCount": 16,
            "LifeCycleConfig": {
                "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
                "OnCreate": "on_create.sh"
            },
            "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
            "SlurmConfig": {
                "NodeType": "Compute",
                "PartitionNames": ["gpu-training"]
            }
        }
    ],
    "VpcConfig": {
        "SecurityGroupIds": ["sg-12345678"],
        "Subnets": ["subnet-12345678"]
    }
}

Führen Sie den create-cluster Befehl aus, um die Anfrage einzureichen.

aws sagemaker create-cluster \
    --cli-input-json file://complete/path/to/create_cluster.json

Dies gibt den ARN des neuen Clusters zurück.

{
    "ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/abcde12345"
}

Verwaltung der Slurm-Konfiguration

Die kontinuierliche Bereitstellung erfolgt ausschließlich im Merge-Modus für die slurm.conf Partitionsverwaltung. HyperPodWendet im Zusammenführungsmodus die Änderungen der Partitionskonfiguration zusätzlich zu den Änderungen an, an denen Sie Änderungen vorgenommen haben. slurm.conf HyperPod aktualisiert nur die partitionsbezogenen Abschnitte von slurm.conf (wie Partitionsnamen- und Knotennameneinträge); andere Slurm-Konfigurationsparameter werden nicht geändert. Das bedeutet Folgendes:

Der SlurmConfigStrategy Parameter (Managed,Merge,Overwrite) wird bei kontinuierlicher Bereitstellung nicht unterstützt. Die Übergabe eines beliebigen SlurmConfigStrategy Werts führt zu einem API-Fehler.

Mindestkapazitätsanforderungen (MinCount)

Mit dieser MinCount Funktion können Sie die Mindestanzahl von Instanzen angeben, die erfolgreich bereitgestellt werden müssen, bevor eine Instanzgruppe in den InService Status übergeht. Diese Funktion bietet eine bessere Kontrolle über Skalierungsvorgänge und trägt dazu bei, Szenarien zu vermeiden, in denen teilweise bereitgestellte Instanzgruppen nicht effektiv für Trainingsworkloads verwendet werden können.

MinCount Wie funktioniert

Wenn Sie eine Instanzgruppe mit MinCount aktivierter Option erstellen oder aktualisieren, tritt das folgende Verhalten auf:

Status der Instanzgruppe während des Betriebs MinCount

Instanzgruppen mit MinCount konfigurierter Konfiguration weisen das folgende Statusverhalten auf:

Während Creating unseres Updating Status gelten die folgenden Einschränkungen:

Automatisches Rollback-Verhalten

Wenn eine Instanzgruppe ihr Ziel nicht MinCount innerhalb von 3 Stunden erreichen kann, leitet das System automatisch ein Rollback ein, um unbegrenztes Warten zu verhindern:

Das 3-Stunden-Timeout wird jedes Mal zurückgesetzt, wenn es aktualisiert wird. MinCount Wenn Sie beispielsweise MinCount mehrmals aktualisieren, beginnt der Timeout-Zeitraum mit dem letzten Update.

MinCount Ereignisse

Das System sendet bestimmte Ereignisse aus, um Ihnen bei der Nachverfolgung von MinCount Vorgängen zu helfen:

Sie können diese Ereignisse überwachen, um den Fortschritt ListClusterEventsIhrer Operationen zu verfolgen. MinCount

API-Nutzung

MinCount wird mithilfe des MinInstanceCount Parameters in Instanzgruppenkonfigurationen angegeben:

aws sagemaker create-cluster \
--cluster-name $HP_CLUSTER_NAME \
--instance-groups '[
    {
      "InstanceGroupName": "controller-machine",
      "InstanceType": "ml.c5.xlarge",
      "InstanceCount": 1,
      "SlurmConfig": {"NodeType": "Controller"},
      "LifeCycleConfig": {
        "SourceS3Uri": "s3://'$BUCKET_NAME'",
        "OnCreate": "on_create.sh"
      },
      "ExecutionRole": "'$EXECUTION_ROLE'",
      "ThreadsPerCore": 2
    },
    {
      "InstanceGroupName": "my-login-group",
      "InstanceType": "ml.c5.xlarge",
      "InstanceCount": 1,
      "SlurmConfig": {"NodeType": "Login"},
      "LifeCycleConfig": {
        "SourceS3Uri": "s3://'$BUCKET_NAME'",
        "OnCreate": "on_create.sh"
      },
      "ExecutionRole": "'$EXECUTION_ROLE'",
      "ThreadsPerCore": 1
    },
    {
      "InstanceGroupName": "worker-group-1",
      "InstanceType": "ml.c5.xlarge",
      "MinInstanceCount": 1,
      "InstanceCount": 2,
      "SlurmConfig": {
        "NodeType": "Compute",
        "PartitionNames": ["p1"]
      },
      "LifeCycleConfig": {
        "SourceS3Uri": "s3://'$BUCKET_NAME'",
        "OnCreate": "on_create.sh"
      },
      "ExecutionRole": "'$EXECUTION_ROLE'",
      "ThreadsPerCore": 1
    }
  ]' \
  --vpc-config '{
    "SecurityGroupIds": ["'$SECURITY_GROUP'"],
    "Subnets": ["'$SUBNET'"]
  }' \
  --node-provisioning-mode Continuous

Wichtige Überlegungen zur MinCount Verwendung: