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.

Fehlerbehebung

Wenn Ihr Trainingsjob fehlschlägt oder sich unerwartet verhält, können Ihnen die folgenden Abschnitte helfen, das Problem zu identifizieren und zu lösen. Wenn Sie Ihren Jobstatus überprüfen, können Sie besser eingrenzen, ob das Problem in Ihrer Konfiguration oder Ihrem Agenten liegt. In den nachfolgenden, agentenspezifischen Abschnitten werden Protokolle und häufig auftretende Probleme für jeden Bereitstellungspfad behandelt.

Debuggen auf Jobebene

Verwenden Sie die DescribeJob API, um den aktuellen Status Ihres Jobs zu überprüfen und herauszufinden, warum er fehlgeschlagen ist. Die Antwort umfasst den Status des Auftrags, eine Fehlerursache, falls der Job fehlgeschlagen ist, und eine Zeitleiste mit Statusübergängen, aus der hervorgeht, wie weit der Job fortgeschritten ist, bevor das Problem aufgetreten ist.

aws sagemaker describe-job \
  --job-name "my-agent-rft-job" \
  --job-category AgentRFT \
  --region us-west-2

Die wichtigsten zu überprüfenden Felder:

CloudWatch Jobprotokolle

Informationen zum Trainingsfortschritt und zur Einführung werden in der folgenden Protokollgruppe in Ihrem Konto protokolliert:

/aws/sagemaker/Job/AgentRFT

Der Name des Protokollstreams lautet. <job-name>/

In diesen Protokollen werden der Fortschritt der Trainingsschritte, Rollout-Aufrufereignisse und Fehler auf hoher Ebene erfasst. Sie können hilfreich sein, um zu verstehen, wie weit Ihr Job fortgeschritten ist und ob Rollouts erfolgreich aufgerufen wurden.

Wenn Ihr Job fehlschlägt, überprüfen Sie das FailureReason Feld auf Einzelheiten. Wenn es während der Training Phase fehlschlägt, liegt das Problem wahrscheinlich bei Ihrem Agenten. In diesem Fall finden Sie in Ihren Agentenprotokollen weitere Informationen.

Debugging auf Agentenebene

Debuggen von Amazon Bedrock AgentCore

Wenn Sie Ihren Agenten auf Amazon Bedrock bereitgestellt haben, kann Folgendes hilfreich sein AgentCore, um Probleme auf Agentenseite zu untersuchen.

Agentenprotokolle

Die Stdout- und Stderr-Ausgaben Ihres Agent-Containers werden in Amazon CloudWatch Logs in Ihrem Konto erfasst. Sie finden sie in der folgenden Protokollgruppe:

/aws/bedrock-agentcore/runtimes/<runtime-name>-<id>-<qualifier>

Diese Protokolle erfassen die Ausgabe Ihres Agentencodes, einschließlich Fehler, Stack-Traces und SDK-Meldungen. Diese Protokolle können zur Untersuchung von Problemen im Zusammenhang mit Ihrem Agentencode, Abhängigkeiten oder der Konnektivität zur RFT-Runtime verwendet werden.

Überprüfen Sie den Zustand der Agenten

Stellen Sie sicher, dass die Laufzeit Ihres Agenten fehlerfrei ist:

aws bedrock-agentcore-control list-agent-runtimes --region us-west-2

Einzelheiten zu einer bestimmten Laufzeit finden Sie unter:

aws bedrock-agentcore-control get-agent-runtime \
  --agent-runtime-id <runtime-id> \
  --region us-west-2

Benutzerdefiniertes Agenten-Debugging

Wenn Sie den Lambda-Forwarder-Pfad verwenden, können Probleme in der Lambda-Funktion selbst oder in Ihrem externen Agenten auftreten. Folgendes kann hilfreich sein, um beide zu untersuchen.

Lambda-Forwarder-Protokolle

Die Ausführungsprotokolle Ihrer Lambda-Funktion werden in Amazon CloudWatch Logs erfasst. Sie finden sie in der folgenden Protokollgruppe:

/aws/lambda/<function-name>

Diese Protokolle können verwendet werden, um Probleme im Zusammenhang mit der Anforderungsweiterleitung, Timeouts oder der Konnektivität zwischen dem Lambda und Ihrem Agenten zu untersuchen. Suchen Sie nach:

Überprüfen Sie die Konnektivität

Wenn in Ihren Lambda-Protokollen Aufruffehler oder Timeouts angezeigt werden, liegt das Problem möglicherweise darin, dass das Lambda Ihren Agenten nicht erreichen kann. Mithilfe der folgenden Prüfungen können Sie überprüfen, ob die Verbindung zwischen Ihrem Lambda und dem Agenten funktioniert.

Gesundheitscheck — stellen Sie sicher, dass Ihr Agent läuft:

curl -s "http://$AGENT_ENDPOINT/health"

# Expected: {"status": "ok"}

Lambda-Test aufrufen — stellen Sie sicher, dass Lambda Ihren Agenten erreichen kann:

aws lambda invoke \
  --function-name rft-agent-forwarder \
  --cli-binary-format raw-in-base64-out \
  --payload '{"prompt": "test", "metadata": {"jobArn": "test", "rolloutId": "test-1"}}' \
  --region us-west-2 \
  /tmp/response.json && cat /tmp/response.json

# Note: This will return an InternalServerError because the jobArn "test"
# does not correspond to an active training job. This is expected.
# Success means the Lambda executed and reached your agent — check agent
# logs to confirm the request was received.

Wenn Ihr Lambda erfolgreich ausgeführt wird, der Job aber trotzdem fehlschlägt, enthalten Ihre Agentenprotokolle möglicherweise weitere Details. Überprüfen Sie Ihre Agentenprotokolle auf Fehler im Zusammenhang mit Inferenzanrufen oder Prämienberichten.

Agentenprotokolle

Die eigenen Protokolle Ihres Agenten hängen davon ab, wo er eingesetzt wird. Diese Protokolle können verwendet werden, um Probleme im Zusammenhang mit Ihrem Agentencode, Inferenzaufrufen an die RFT-Runtime oder Prämienberichte zu untersuchen.

Wenn Sie Ihren Agenten beispielsweise auf Amazon EKS bereitgestellt haben, können Sie die Protokolle Ihres Agenten überprüfen mit:

kubectl logs -l app=external-agent --tail=50

CloudTrail Zum Debuggen verwenden

CloudTrail Mithilfe von Datenereignissen können Sie überprüfen, ob die Aufrufe Ihres Agenten an die RFT-Runtime erfolgreich sind. Suchen Sie nach Ereignissen mit:

Wenn Sie diese Ereignisse nicht sehen, ruft Ihr Agent die RFT-Runtime nicht erfolgreich auf. Überprüfen Sie die Agentenprotokolle und -berechtigungen.

Protokollierung von -API-Aufrufen mit AWS CloudTrail

Amazon SageMaker AI ist in einen Service integriert AWS CloudTrail, der eine Aufzeichnung der von einem Benutzer, einer Rolle oder einem AWS Service ausgeführten Aktionen bereitstellt. CloudTrail erfasst alle API-Aufrufe für Amazon SageMaker AI als Ereignisse. Zu den erfassten Aufrufen gehören Aufrufe von der Amazon SageMaker AI-Konsole und Code-Aufrufe der Amazon SageMaker AI-API-Operationen. Anhand der von gesammelten Informationen können Sie die Anfrage CloudTrail, die an Amazon SageMaker AI gestellt wurde, die IP-Adresse, von der aus die Anfrage gestellt wurde, den Zeitpunkt der Anfrage und weitere Details ermitteln.

Jeder Ereignis- oder Protokolleintrag enthält Informationen zu dem Benutzer, der die Anforderung generiert hat. Die Identitätsinformationen unterstützen Sie bei der Ermittlung der folgenden Punkte:

CloudTrail ist in Ihrem AWS Konto aktiv, wenn Sie das Konto erstellen, und Sie haben automatisch Zugriff auf den CloudTrail Eventverlauf. Der CloudTrail Ereignisverlauf bietet eine einsehbare, durchsuchbare, herunterladbare und unveränderliche Aufzeichnung der aufgezeichneten Managementereignisse der letzten 90 Tage in einer AWS Region. Weitere Informationen finden Sie im AWS CloudTrail Benutzerhandbuch unter Arbeiten mit dem CloudTrail Ereignisverlauf. Für die Anzeige des Eventverlaufs CloudTrail fallen keine Gebühren an.

Für eine fortlaufende Aufzeichnung der Ereignisse in Ihrem AWS Konto in den letzten 90 Tagen erstellen Sie einen Trail- oder CloudTrail Lake-Event-Datenspeicher.

CloudTrail Pfade

Ein Trail ermöglicht CloudTrail die Übermittlung von Protokolldateien an einen Amazon S3 S3-Bucket. Alle mit der AWS Management Console erstellten Trails sind regionsübergreifend. Mit der CLI können Sie einen Trail mit einer oder mehreren Regionen erstellen. AWS Es wird empfohlen, einen Trail mit mehreren Regionen zu erstellen, da Sie Aktivitäten in allen AWS Regionen in Ihrem Konto erfassen. Wenn du einen Trail mit nur einer Region erstellst, kannst du dir nur die Ereignisse ansehen, die in der Region des AWS Trails protokolliert wurden. Weitere Informationen zu Wanderwegen findest du unter Einen Trail für dein AWS Konto erstellen und Einen Trail für eine Organisation erstellen im AWS CloudTrail Benutzerhandbuch.

Sie können eine Kopie Ihrer laufenden Verwaltungsereignisse kostenlos an Ihren Amazon S3 S3-Bucket senden, CloudTrail indem Sie einen Trail erstellen. Es fallen jedoch Amazon S3 S3-Speichergebühren an. Weitere Informationen zur CloudTrail Preisgestaltung finden Sie unter AWS CloudTrailPreise. Informationen zu Amazon-S3-Preisen finden Sie unter Amazon S3 – Preise.

CloudTrail Datenspeicher für Ereignisse in Lake

CloudTrail Mit Lake können Sie SQL-based Abfragen zu Ihren Ereignissen ausführen. CloudTrail Lake konvertiert bestehende Ereignisse im zeilenbasierten JSON-Format in das Apache ORC-Format. ORC ist ein spaltenförmiges Speicherformat, das für den schnellen Abruf von Daten optimiert ist. Die Ereignisse werden in Ereignisdatenspeichern zusammengefasst, bei denen es sich um unveränderliche Sammlungen von Ereignissen handelt, die auf Kriterien basieren, die Sie mit Hilfe von erweiterten Ereignisselektoren auswählen. Die Selektoren, die Sie auf einen Ereignisdatenspeicher anwenden, steuern, welche Ereignisse bestehen bleiben und für Sie zur Abfrage verfügbar sind. Weitere Informationen zu CloudTrail Lake finden Sie unter Arbeiten mit AWS CloudTrail Lake im AWS CloudTrail Benutzerhandbuch.

CloudTrail Für das Speichern und Abfragen von Ereignisdaten in Lake fallen Kosten an. Beim Erstellen eines Ereignisdatenspeichers wählen Sie die Preisoption aus, die für den Ereignisdatenspeicher genutzt werden soll. Die Preisoption bestimmt die Kosten für die Erfassung und Speicherung von Ereignissen sowie die standardmäßige und maximale Aufbewahrungsdauer für den Ereignisdatenspeicher. Weitere Informationen zu CloudTrail -Preisen erhalten Sie unter AWS CloudTrail – Preise.

SageMaker KI-Datenereignisse in CloudTrail

Datenereignisse liefern Informationen über die Ressourcenoperationen, die auf oder in einer Ressource ausgeführt werden (z. B. Lesen oder Schreiben in ein Amazon-S3-Objekt). Sie werden auch als Vorgänge auf Datenebene bezeichnet. Datenereignisse sind oft Aktivitäten mit hohem Volume. Protokolliert standardmäßig CloudTrail keine Datenereignisse. Der CloudTrail Ereignisverlauf zeichnet keine Datenereignisse auf.

Für Datenereignisse werden zusätzliche Gebühren fällig. Weitere Informationen zu CloudTrail-Preisen erhalten Sie unter AWS CloudTrail – Preise.

Sie können Datenereignisse für verschiedene Amazon SageMaker AI-Ressourcentypen mithilfe der CloudTrail Konsole, der AWS CLI oder CloudTrail API-Operationen protokollieren. Weitere Informationen zum Protokollieren von Datenereignissen finden Sie unter Protokollieren von Datenereignissen mit der AWS Management Console und Protokollieren von Datenereignissen mit der AWS Befehlszeilenschnittstelle im AWS CloudTrail Benutzerhandbuch.

In der folgenden Tabelle sind die Amazon SageMaker AI-Ressourcentypen aufgeführt, für die Sie Datenereignisse protokollieren können:

Sie können erweiterte Event-Selektoren so konfigurieren, dass sie nach den Feldern eventName, readOnly und resources.ARN filtern, sodass nur die Ereignisse protokolliert werden, die für Sie wichtig sind. Weitere Informationen zu diesen Kontingenten finden Sie unter AdvancedFieldSelector in derAWS CloudTrail -API-Referenz.

Beispiel: Datenereignisse für einen SageMaker Endpunkt und einen Job protokollieren

Das folgende Beispiel zeigt, wie Sie den AWS CLI-Befehl put-event-selectors verwenden, um erweiterte Event-Selektoren hinzuzufügen:

[
  {
    "FieldSelectors": [
      { "Field": "eventCategory", "Equals": ["Data"] },
      { "Field": "resources.ARN", "Equals": ["arn:aws:sagemaker:us-east-1:111122223333:endpoint/your-inference-endpoint-arn"] },
      { "Field": "resources.type", "Equals": ["AWS::SageMaker::Endpoint"] }
    ]
  },
  {
    "FieldSelectors": [
      { "Field": "eventCategory", "Equals": ["Data"] },
      { "Field": "resources.ARN", "Equals": ["arn:aws:sagemaker:us-east-1:111122223333:job/your-job-arn"] },
      { "Field": "resources.type", "Equals": ["AWS::SageMaker::Job"] }
    ]
  }
]

Dann führe Folgendes aus:

aws cloudtrail put-event-selectors \
    --trail-name your-trail-name \
    --advanced-event-selectors=file://advanced-event-selectors.json

SageMaker KI-Management-Veranstaltungen in CloudTrail

Verwaltungsereignisse enthalten Informationen zu Verwaltungsvorgängen, die mit Ressourcen in Ihrem AWS Konto ausgeführt werden. Sie werden auch als Vorgänge auf Steuerebene bezeichnet. CloudTrail Protokolliert standardmäßig Verwaltungsereignisse.

Amazon SageMaker AI protokolliert alle Operationen der Amazon SageMaker AI-Steuerebene als Verwaltungsereignisse. Eine Liste der Vorgänge auf der Amazon SageMaker AI-Steuerungsebene, bei denen Amazon SageMaker AI protokolliert CloudTrail, finden Sie in der Amazon SageMaker AI API-Referenz.

CloudTrail Beispiele für Ereignisse

Informationen zu CloudTrail Datensatzinhalten finden Sie im AWS CloudTrail Benutzerhandbuch unter CloudTrail Datensatzinhalte.

Modellieren Sie Pakete und Checkpoints

-Übersicht

Während des Multiturn-RL-Trainings speichert die Plattform regelmäßig die erlernten Parameter des Modells als Checkpoints. Diese Prüfpunkte werden als SageMaker Modellpakete in Modellpaketgruppen gespeichert und ermöglichen so Versionsverwaltung, Herkunftsverfolgung und jobübergreifende Kontinuität.

Die wichtigsten Konzepte

Modell-Paket

Ein Modellpaket ist ein versioniertes, unveränderliches Artefakt in SageMaker KI, das trainierte Modellgewichte zu einem bestimmten Zeitpunkt enthält. Jeder während des Trainings erzeugte Checkpoint wird als Model Package gespeichert. Ein Modellpaket hat:

Modellpaketgruppe

Eine Modellpaketgruppe ist ein Container, der mehrere Modellpaketversionen enthält. Multi-turn RL verwendet zwei separate Gruppen:

Sie geben beide an, wenn Sie einen Job erstellen:

{
  "ModelPackageConfig": {
    "OutputModelPackageGroupArn": "arn:aws:sagemaker:us-west-2:123456789012:model-package-group/my-final-models",
    "IntermediateCheckpointModelPackageGroupArn": "arn:aws:sagemaker:us-west-2:123456789012:model-package-group/my-intermediate-checkpoints"
  }
}

Checkpoint-Typen

Der Checkpoint kann wieder aufgenommen werden (Vollständiger Status)

Model Checkpoint (nur Gewichte)

Wiederaufnahme des unterbrochenen Trainings

Wenn ein Trainingsjob fehlschlägt oder während des Trainings unterbrochen wird, können Sie einen neuen Job beginnen, der genau an der Stelle fortgesetzt wird, an der der vorherige Job aufgehört hat. Die Plattform lädt den vollständigen Trainingsstatus (Gewichte + Optimierer + Schrittzähler) von einem Checkpoint, der wieder aufgenommen werden kann.

Um fortzufahren, geben Sie einen wiederaufnehmbaren Checkpoint (aus der Intermediate Checkpoint Model Package Group) wie folgt an: InputModelPackageArn

{
  "ModelPackageConfig": {
    "OutputModelPackageGroupArn": "arn:aws:sagemaker:us-west-2:123456789012:model-package-group/my-final-models",
    "IntermediateCheckpointModelPackageGroupArn": "arn:aws:sagemaker:us-west-2:123456789012:model-package-group/my-intermediate-checkpoints",
    "InputModelPackageArn": "arn:aws:sagemaker:us-west-2:123456789012:model-package/my-intermediate-checkpoints/5"
  }
}

Voraussetzungen:

Iteratives Training (Weiterbildung)

Mit iterativem Training können Sie auf einem zuvor trainierten Modell mit neuen Hyperparametern, einem anderen Datensatz oder einer anderen Trainingskonfiguration aufbauen. Im Gegensatz zur Wiederaufnahme wird damit ein neuer Trainingslauf gestartet, der anhand der trainierten LoRa-Gewichte initialisiert wird, jedoch mit einem neuen Optimierungsstatus.

Um ein iteratives Training durchzuführen, geben Sie einen Modell-Checkpoint (aus der Output Model Package Group) wie folgt an: InputModelPackageArn

{
  "ModelPackageConfig": {
    "OutputModelPackageGroupArn": "arn:aws:sagemaker:us-west-2:123456789012:model-package-group/my-final-models",
    "IntermediateCheckpointModelPackageGroupArn": "arn:aws:sagemaker:us-west-2:123456789012:model-package-group/my-intermediate-checkpoints",
    "InputModelPackageArn": "arn:aws:sagemaker:us-west-2:123456789012:model-package/my-final-models/3"
  }
}

Was Sie zwischen den Iterationen ändern können:

Was muss gleich bleiben:

Typische Anwendungsfälle:

Lebenszyklus von Checkpoints

Training Step 1 → Intermediate Checkpoint (Resumable)
Training Step 1 → Intermediate Checkpoint (HFCompatible)
...
Training Step N-1 → Intermediate Checkpoint (Resumable)
Training Step N-1 → Intermediate Checkpoint (HFCompatible)
...
Training Step N (final) → Model Checkpoint (HuggingFace LoRA) → Output Model Package Group

Wenn ein Job erfolgreich abgeschlossen wurde: Die endgültigen Modellgewichte werden als Modellpaket in der Ausgabemodellpaketgruppe gespeichert. Das OutputModelPackageArn Feld im Jobdatensatz enthält den ARN des endgültigen Modells.

Wenn ein Job fehlschlägt oder gestoppt wird: Der letzte Zwischenprüfpunkt wird zur Output Model Package Group heraufgestuft (Best-Effort).

Bewährte Methoden für Checkpoints