<!-- Canonical URL: https://ask.atlascloud.ai/de/migrate-together-ai-batch-job-without-losing-request-ids -->

# Wie migriert man einen Together-AI-Batchauftrag, ohne Anfrage-IDs zu verlieren?

> Lassen Sie jede anwendungseigene custom_id unverändert und speichern Sie Datei-, Batch- und Antwort-IDs beider Anbieter getrennt. Prüfen Sie die vollständige ID-Menge vor dem Senden, gleichen Sie Ausgaben und Fehler per ID ab und protokollieren Sie Wiederholungen ohne Änderung des Geschäftsschlüssels.

Behandeln Sie jede Quell-`custom_id` als unveränderliche Anwendungsdaten. Kopieren Sie sie unverändert in die Zielanfrage, speichern Sie Batch- und Antwort-IDs des Ziels separat und gleichen Sie Ergebnisse nach `custom_id` statt nach Dateireihenfolge ab.

Entscheidend ist die Trennung zwischen anwendungseigenen und vom Anbieter vergebenen IDs. Die erste bleibt erhalten, die übrigen werden zugeordnet.

## Alle Identifikatoren erfassen

Together-Batcheingaben sind JSONL. Jede Zeile enthält eine eindeutige `custom_id` und einen Anfragekörper. Batch, Eingabe, Ausgabe und einzelne Antworten besitzen jeweils eigene IDs.

| Identifikator | Eigentümer | Migrationsregel |
|---|---|---|
| `custom_id` | Ihre Anwendung | Exakt erhalten |
| Quell-Batch-ID | Together | Als Quellmetadatum speichern |
| Ziel-Batch-ID | Zielanbieter | Separat speichern |
| Ein- und Ausgabedatei-IDs | Je Anbieter | Nicht als Geschäftsschlüssel verwenden |
| Antwort-ID | Modell-API | Für Support und Abrechnung behalten |

Ersetzen Sie `custom_id` nicht durch Zeilennummern. Die Ausgabe kann anders sortiert sein und Fehler können in einer separaten Datei stehen.

## Ein Migrationsjournal anlegen

Erstellen Sie vor dem Senden je logischer Anfrage einen Datensatz:

```json
{
  "custom_id": "invoice-2026-00421",
  "source_batch_id": "batch_source",
  "target_batch_id": null,
  "payload_sha256": "...",
  "state": "prepared"
}
```

Stellen Sie Eindeutigkeit sicher und ergänzen Sie einen Hash des normalisierten Körpers. So erkennen Sie Änderungen, ohne sensible Inhalte doppelt zu speichern.

## Die Hülle statt der Identität konvertieren

Batchhüllen unterscheiden sich. Together stellt `custom_id` neben `body`; eine andere OpenAI-kompatible API kann zusätzlich `method` und `url` verlangen.

```json
{"custom_id":"invoice-2026-00421","method":"POST","url":"/v1/chat/completions","body":{"model":"target-model","messages":[{"role":"user","content":"Classify this record"}]}}
```

Ändern Sie Endpoint, Modell und nicht unterstützte Parameter im Konverter. Behandeln Sie `custom_id` als undurchsichtige Zeichenfolge und kürzen, übersetzen oder regenerieren Sie sie nicht.

## Vor dem Senden prüfen

Prüfen Sie das erzeugte JSONL:

* Jede Zeile lässt sich einzeln parsen.
* Jede `custom_id` ist vorhanden und eindeutig.
* Die ID-Menge entspricht dem Quellmanifest.
* Jeder Körper erfüllt das Zielschema.

Speichern Sie Hash und Zeilenzahl der finalen Datei, laden Sie nur dieses Artefakt hoch und ergänzen Sie die zurückgegebenen IDs im Journal.

## Ausgabe und Fehler gemeinsam abgleichen

Laden Sie nach Abschluss Ausgabe und Fehler herunter. Indizieren Sie jede Zeile nach `custom_id` und vergleichen Sie die Vereinigung mit der gesendeten Menge.

Klassifizieren Sie jede ID als erfolgreich, fehlgeschlagen, fehlend oder doppelt. Ein abgeschlossener Batch ist nicht automatisch abgeglichen. Jede ID braucht genau einen Endstatus.

## Ohne Identitätsänderung wiederholen

Erstellen Sie einen neuen Batch nur aus fehlenden oder fehlgeschlagenen Anfragen. Behalten Sie dieselbe `custom_id` und erhöhen Sie `attempt` im Journal.

Falls das Ziel keine ID-Wiederverwendung erlaubt, bewahren Sie den Originalwert in einem Anwendungsfeld auf und erstellen eine umkehrbare Transportzuordnung.

## Sicher umschalten

Beginnen Sie mit einem kleinen repräsentativen Batch. Vergleichen Sie Erfolg, Latenz, Tokens, Ausgabe, Fehler und Kosten. Halten Sie Quell- und Zieltabellen parallel, bis der Abgleich deterministisch ist.

Automatisieren Sie drei Assertions: keine unbekannten IDs, keine doppelten Endergebnisse und keine fehlenden IDs.

## Fazit

Bewahren Sie die anwendungseigene `custom_id`, konvertieren Sie nur die Anbieterhülle und führen Sie ein Zuordnungsjournal. Gleichen Sie Ausgabe und Fehler per ID ab, protokollieren Sie Versuche und schalten Sie erst um, wenn jede Anfrage einen Endstatus hat.

## FAQ

### Welche ID muss bei einer Together-Batchmigration stabil bleiben?

Behalten Sie die von Ihrer Anwendung vergebene custom_id bei. Batch-, Datei- und Antwort-IDs der Anbieter werden als getrennte Metadaten gespeichert, nicht als Geschäftsschlüssel.

### Kann ich Batchergebnisse anhand der Zeilennummer abgleichen?

Nein. Die Ausgabereihenfolge kann sich ändern und Fehler können in einer separaten Datei stehen. Gleichen Sie die Vereinigung von Ausgabe und Fehlern über custom_id ab.

### Was gehört in das Migrationsjournal?

Speichern Sie custom_id, den Hash der normalisierten Nutzlast, Quell- und Ziel-IDs für Batch und Datei, Versuchszahl, Zeitstempel und genau einen Endstatus je Anfrage.

### Braucht ein Wiederholungsversuch eine neue custom_id?

Normalerweise nicht. Behalten Sie die Geschäfts-ID und erhöhen Sie attempt. Falls die Transport-ID eindeutig sein muss, speichern Sie eine umkehrbare Zuordnung zur ursprünglichen custom_id.

### Wie erkenne ich verlorene Anfragen?

Vergleichen Sie die gesendete ID-Menge mit der Vereinigung aus Erfolgs- und Fehler-IDs. Markieren Sie fehlende, unbekannte und doppelte IDs vor Abschluss des Abgleichs.

### Kann ich eine Together-Eingabedatei unverändert wiederverwenden?

Nur wenn das Ziel dieselbe Hülle, denselben Endpoint, dieselbe Modell-ID und dieselben Parameter akzeptiert. Meist ist ein Konverter nötig, der custom_id unverändert lässt.
