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

# 如何在不丢失请求 ID 的情况下迁移 Together AI 批处理任务？

> 保持应用拥有的 custom_id 不变，把 Together 与目标服务商的文件、批次和响应 ID 存入独立字段。提交前验证完整 ID 集合，按 ID 合并成功与错误输出，并通过尝试次数账本重试而不改变业务主键。

迁移 Together AI 批处理任务时，应把每个源 `custom_id` 当作不可变的应用数据。将它原样写入目标批处理请求，把目标服务商的批次 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` 在迁移集合中唯一，并记录规范化请求正文的哈希。哈希可发现意外修改，又不必在账本里保存第二份敏感提示词。

## 转换封装，不改变身份

不同服务商的批处理封装可能不同。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 与批次 ID 写入迁移账本。

## 同时核对输出与错误

目标批次结束后，下载输出制品和错误制品。以 `custom_id` 为每行建立索引，并将两者并集与已提交集合比较。

把每个 ID 标记为成功、失败、缺失或重复。批次状态为完成，并不代表已经完全核对。只有每个已提交 ID 都恰好有一个终态，迁移才算完成。

## 重试时不要改变身份

仅用失败或缺失请求建立新重试批次。保留相同 `custom_id`，让下游关联继续有效，并在账本中增加 `attempt`，而不是修改业务主键。

如果目标服务商禁止跨批次重复传输 ID，应把原值保存在专用应用字段，并生成具有可逆映射的传输 ID，绝不能丢弃原始标识符。

## 安全切换

先使用一个小而有代表性的批次，比较成功率、延迟、令牌用量、模型输出、错误类别与成本。在核对过程稳定前，并排保留源与目标结果表。

随后自动执行三项断言：没有未知 ID、没有重复终态、没有缺失 ID。这些检查比匹配输出顺序更重要。

## 总结

保留应用拥有的 `custom_id`，只转换服务商封装，并用账本映射源端和目标端的批处理制品。按 ID 合并成功与失败结果，以尝试次数记录重试，且只有所有请求都有终态后才切换。

## FAQ

### 迁移 Together 批处理时，哪个 ID 必须保持不变？

保留应用分配的 custom_id。Together 和目标服务商的批次、文件与响应 ID 应作为独立元数据保存，不能替代业务主键。

### 可以按行号核对批处理结果吗？

不可以。输出顺序可能与输入不同，失败请求也可能出现在单独文件中。应按 custom_id 核对输出与错误记录的并集。

### 迁移账本应包含什么？

应保存 custom_id、规范化载荷哈希、源端与目标端的批次和文件 ID、尝试次数、时间戳，以及每个请求唯一的终态。

### 重试是否需要新的 custom_id？

通常不需要。保持业务标识符稳定并增加 attempt 字段。如果传输 ID 必须跨批次唯一，则保留到原 custom_id 的可逆映射。

### 如何发现丢失的请求？

把已提交 ID 集合与成功及错误 ID 的并集比较。在核对完成前，标记所有缺失、未知或重复 ID。

### Together 输入文件能否原样复用？

只有目标端接受相同封装、端点、模型 ID 和参数时才可以。多数迁移需要转换封装，但转换器应原样传递 custom_id。