# 요청 ID를 잃지 않고 Together AI 배치 작업을 마이그레이션하려면 어떻게 해야 하나요? > 애플리케이션이 소유한 custom_id는 변경하지 않고 Together와 대상 공급자의 파일, 배치, 응답 ID를 별도 필드에 저장합니다. 전송 전에 전체 ID 집합을 검증하고 성공 및 오류 결과를 ID로 대조하며 비즈니스 키를 바꾸지 않고 시도 횟수를 기록합니다. Together AI 배치 작업을 이전할 때 각 원본 `custom_id`를 변경할 수 없는 애플리케이션 데이터로 취급합니다. 대상 요청에 그대로 복사하고 대상 공급자의 배치 및 응답 ID는 별도 필드에 저장하며 파일 순서가 아닌 `custom_id`로 결과를 대조합니다. 핵심은 애플리케이션이 소유한 식별자와 공급자가 발급한 식별자를 분리하는 것입니다. 전자는 유지하고 후자는 매핑합니다. ## 모든 식별자를 조사합니다 Together 배치 입력은 JSONL을 사용합니다. 각 줄에는 고유한 `custom_id`와 요청 본문이 있습니다. 배치, 입력 파일, 출력 파일, 생성 응답에는 각기 다른 공급자 ID가 있을 수 있습니다. | 식별자 | 소유자 | 마이그레이션 규칙 | |---|---|---| | `custom_id` | 애플리케이션 | 정확히 유지 | | 원본 배치 ID | Together | 원본 메타데이터로 저장 | | 대상 배치 ID | 대상 공급자 | 별도로 저장 | | 입력 및 출력 파일 ID | 각 공급자 | 비즈니스 키로 사용하지 않음 | | 응답 ID | 모델 API | 지원 및 청구용으로 유지 | 줄 번호가 이미 영구 키인 경우가 아니라면 `custom_id`를 줄 번호로 바꾸지 않습니다. 출력 순서는 달라질 수 있고 실패 요청은 별도 오류 파일에 기록될 수 있습니다. ## 마이그레이션 원장을 만듭니다 대상 API에 제출하기 전에 논리 요청별 레코드를 만듭니다. ```json { "custom_id": "invoice-2026-00421", "source_batch_id": "batch_source", "target_batch_id": null, "payload_sha256": "...", "state": "prepared" } ``` 집합 내에서 `custom_id`가 고유한지 확인하고 정규화된 본문의 해시를 추가합니다. 해시는 민감한 프롬프트 사본을 더 저장하지 않고도 변경을 감지합니다. ## ID가 아니라 엔벌로프를 변환합니다 공급자마다 배치 엔벌로프가 다를 수 있습니다. Together 예시는 `custom_id`와 `body`를 함께 사용하지만 다른 OpenAI 호환 배치 API는 `method`와 `url`도 요구할 수 있습니다. ```json {"custom_id":"invoice-2026-00421","method":"POST","url":"/v1/chat/completions","body":{"model":"target-model","messages":[{"role":"user","content":"Classify this record"}]}} ``` 변환기에서 엔드포인트, 모델 ID, 미지원 매개변수를 바꿉니다. 원본 `custom_id`는 불투명 문자열로 전달하고 자르기, 대소문자 변경, 번역, 재생성을 하지 않습니다. ## 제출 전에 검증합니다 생성된 JSONL에서 다음을 검사합니다. * 각 줄을 독립적으로 파싱할 수 있습니다. * 모든 `custom_id`가 존재하고 고유합니다. * ID 집합이 원본 매니페스트와 같습니다. * 각 본문이 대상 엔드포인트 schema를 충족합니다. 최종 파일 해시와 줄 수를 기록하고 해당 산출물만 업로드한 뒤 반환된 파일 및 배치 ID를 원장에 연결합니다. ## 출력과 오류를 함께 대조합니다 대상 배치가 끝나면 출력과 오류 산출물을 모두 내려받습니다. 각 줄을 `custom_id`로 색인하고 그 합집합을 제출한 집합과 비교합니다. 각 ID를 성공, 실패, 누락, 중복으로 분류합니다. 완료 상태가 완전한 대조를 뜻하지는 않습니다. 모든 제출 ID에 정확히 하나의 최종 결과가 있어야 합니다. ## 식별자를 바꾸지 않고 재시도합니다 실패하거나 누락된 요청만 새 배치에 넣습니다. 같은 `custom_id`를 유지하고 비즈니스 키 대신 원장의 `attempt`를 증가시킵니다. 대상에서 배치 간 전송 ID 재사용을 금지한다면 원래 값을 전용 필드에 보관하고 되돌릴 수 있는 전송 ID 매핑을 생성합니다. ## 안전하게 전환합니다 작고 대표적인 배치부터 시작해 성공률, 지연, 토큰, 출력, 오류, 비용을 비교합니다. 대조가 결정론적이 될 때까지 원본과 대상 결과를 함께 유지합니다. 알 수 없는 ID 없음, 중복 최종 결과 없음, 누락 ID 없음이라는 세 가지 어설션을 자동화합니다. ## 핵심 정리 애플리케이션의 `custom_id`를 유지하고 공급자 엔벌로프만 변환합니다. 성공과 오류를 ID로 대조하고 재시도는 시도 횟수로 기록하며 모든 요청에 최종 결과가 있을 때만 전환합니다. ## FAQ ### Together 배치 마이그레이션에서 어떤 ID를 유지해야 하나요? 애플리케이션이 지정한 custom_id를 유지합니다. 각 공급자의 배치, 파일, 응답 ID는 비즈니스 키가 아니라 별도 메타데이터로 저장합니다. ### 줄 번호로 배치 결과를 대조해도 되나요? 안 됩니다. 출력 순서가 달라질 수 있고 실패 요청이 별도 파일에 기록될 수 있습니다. custom_id로 성공과 오류 결과의 합집합을 대조해야 합니다. ### 마이그레이션 원장에는 무엇을 저장해야 하나요? custom_id, 정규화된 페이로드 해시, 원본과 대상의 배치 및 파일 ID, 시도 횟수, 타임스탬프, 요청별 단일 최종 상태를 저장합니다. ### 재시도에 새 custom_id가 필요한가요? 일반적으로 필요하지 않습니다. 비즈니스 식별자는 유지하고 attempt를 증가시킵니다. 전송 ID가 고유해야 한다면 원래 custom_id로 되돌릴 수 있는 매핑을 보관합니다. ### 누락된 요청은 어떻게 찾나요? 전송한 ID 집합과 성공 및 오류 ID의 합집합을 비교합니다. 대조를 완료하기 전에 누락, 미확인, 중복 ID를 표시합니다. ### Together 입력 파일을 그대로 재사용할 수 있나요? 대상에서 동일한 엔벌로프, 엔드포인트, 모델 ID, 매개변수를 지원할 때만 가능합니다. 보통 custom_id를 그대로 전달하는 변환기가 필요합니다.