배치 처리 (Batch Processing)¶
요청을 하나씩 보내고 나서 즉각적인 응답을 기다리는 대신, 여러 요청을 한꺼번에 제출해 두고 비동기적으로 처리하는 방식을 배치 처리(Batch processing)라고 해요. 응답이 당장 필요하지 않은 작업이라면 이 방식이 특히 유용한데, 어떤 경우에 쓸 만한지 생각해 볼게요.
- 처리해야 할 데이터가 아주 많은 경우
- 즉각적인 응답이 꼭 필요하지 않은 경우
- 비용을 아껴 보고 싶은 경우
- 대규모 평가나 분석을 돌리는 경우
이 배치 처리를 실제로 구현한 것이 Anthropic의 Message Batches API예요. 참고로 이 기능에 제로 데이터 보존(ZDR)이 어떻게 적용되는지는 API 및 데이터 보존 문서에서 확인할 수 있어요.
Message Batches API란?¶
Message Batches API는 대량의 Messages 요청을 비동기적으로 처리하는 강력하고 비용 효율적인 방법이에요. 즉각적인 응답이 필요 없는 작업에 잘 맞고, 대부분의 배치는 1시간 이내에 완료되면서 비용은 50% 절감되고 처리량은 올라가요. 이 가이드 외에 API 레퍼런스를 직접 열어 보셔도 좋아요.
Message Batches API의 작동 방식¶
Message Batches API에 요청을 보내면 이런 순서로 동작해요.
- 시스템이 받은 Messages 요청들로 새로운 Message Batch를 만듭니다.
- 배치가 비동기적으로 처리되는데, 각 요청은 서로 독립적으로 다뤄집니다.
- 배치의 상태를 폴링해서, 모든 요청 처리가 끝나면 결과를 가져옵니다.
즉각적인 결과가 필요 없는 대량 작업에 특히 유용하죠. 예를 들어:
- 대규모 평가: 수천 개의 테스트 케이스를 효율적으로 처리
- 콘텐츠 모더레이션: 대량의 사용자 생성 콘텐츠를 비동기적으로 분석
- 데이터 분석: 대규모 데이터셋에서 인사이트나 요약 생성
- 대량 콘텐츠 생성: 제품 설명이나 기사 요약처럼 많은 텍스트를 한 번에 생성
배치 제한 사항¶
배치를 다루기 전에 알아 두어야 할 제한이 몇 가지 있어요.
- Message Batch는 100,000개의 Message 요청 또는 256MB 크기 중 먼저 도달하는 쪽으로 제한됩니다.
- 시스템은 각 배치를 최대한 빨리 처리하며, 대부분 1시간 이내에 끝나요. 결과에 접근할 수 있는 시점은 모든 메시지가 완료됐을 때 또는 24시간이 지난 뒤 중 먼저 도래하는 때예요. 24시간 안에 처리가 끝나지 않으면 배치는 만료됩니다.
- 배치 결과는 생성 후 29일 동안 이용할 수 있어요. 그 이후에도 Batch 자체는 조회할 수 있지만 결과는 더 이상 다운로드할 수 없어요.
- 배치는 Workspace 범위로 지정됩니다. 요청이 실행된 Workspace 안에서 만들어진 배치와 그 결과만 볼 수 있어요.
- 속도 제한(Rate limit)은 Batches API의 HTTP 요청과 배치 안에서 처리 대기 중인 요청 수 양쪽에 적용돼요. 자세한 내용은 Message Batches API 속도 제한을 참조하세요. 또 현재 수요와 요청량에 따라 처리가 느려질 수도 있고, 그럴 땐 24시간 후 만료되는 요청이 더 많아질 수 있어요.
- 높은 처리량과 동시 처리 때문에 배치가 Workspace에 구성된 지출 한도를 살짝 초과할 수 있어요.
- 배치 안의 각 요청은
max_tokens가 최소 1 이상이어야 해요.max_tokens: 0(캐시 사전 워밍)은 배치에서 지원되지 않는데, 배치 처리 중에 만들어진 임시 캐시 항목이 후속 요청이 실행되기 전에 만료될 가능성이 높기 때문이에요.
지원 모델¶
모든 활성 모델이 Message Batches API를 지원해요.
배치로 처리할 수 있는 항목¶
Messages API에 보낼 수 있는 거의 모든 요청을 배치에 넣을 수 있어요.
- 비전
- 모든 서버 도구(웹 검색, 웹 가져오기, 코드 실행, MCP 커넥터, 어드바이저, 도구 검색)를 포함한 도구 사용(tool use)
- 시스템 메시지
- 멀티턴 대화
- 확장 사고(Extended thinking)
- 대부분의 베타 기능
배치 안의 각 요청은 독립적으로 처리되므로, 하나의 배치에 서로 다른 유형의 요청을 섞어 넣어도 괜찮아요.
다만 몇 가지 Messages API 매개변수는 배치 요청에서 지원되지 않아요. 이 중 하나라도 포함하면 유효성 검사 오류가 반환됩니다.
| 매개변수 | 이유 |
|---|---|
stream: true |
배치 결과는 스트림이 아니라 단일 파일로 반환됩니다. |
speed (Fast 모드) |
Fast 모드는 동기식 지연 시간을 조정하며, 비동기 배치 처리에는 적용되지 않습니다. |
max_tokens: 0 |
배치 제한 사항을 참조하세요. |
배치 처리는 5분 이상 걸릴 수 있으니, 공유 컨텍스트가 있는 배치를 돌릴 때 캐시 적중률을 높이고 싶다면 프롬프트 캐싱과 함께 1시간 캐시 지속 시간을 쓰는 걸 고려해 보세요.
가격¶
Batches API는 비용 절감 효과가 커요. 모든 사용량이 표준 API 가격의 50%로 청구됩니다.
| 모델 | 배치 입력 | 배치 출력 |
|---|---|---|
| Claude Fable 5.1 | $5 / MTok | $25 / MTok |
| Claude Mythos 5.1 (제한적 제공) | $5 / MTok | $25 / MTok |
| Claude Fable 5 | $5 / MTok | $25 / MTok |
| Claude Mythos 5 (제한적 제공) | $5 / MTok | $25 / MTok |
| Claude Opus 5 | $2.50 / MTok | $12.50 / MTok |
| Claude Opus 4.8 | $2.50 / MTok | $12.50 / MTok |
| Claude Opus 4.7 | $2.50 / MTok | $12.50 / MTok |
| Claude Opus 4.6 | $2.50 / MTok | $12.50 / MTok |
| Claude Opus 4.5 | $2.50 / MTok | $12.50 / MTok |
| Claude Opus 4.1 (종료됨, Bedrock 및 Google Cloud 제외) | $7.50 / MTok | $37.50 / MTok |
| Claude Opus 4 (종료됨, Google Cloud 제외) | $7.50 / MTok | $37.50 / MTok |
| Claude Sonnet 5 | $1 / MTok | $5 / MTok |
| Claude Sonnet 4.6 | $1.50 / MTok | $7.50 / MTok |
| Claude Sonnet 4.5 | $1.50 / MTok | $7.50 / MTok |
| Claude Sonnet 4 (종료됨, Bedrock 및 Google Cloud 제외) | $1.50 / MTok | $7.50 / MTok |
| Claude Haiku 4.5 | $0.50 / MTok | $2.50 / MTok |
| Claude Haiku 3.5 (종료됨, Bedrock 및 Google Cloud 제외) | $0.40 / MTok | $2 / MTok |
Message Batches API 사용 방법¶
이제 실제로 배치를 만들어 볼게요. 순서대로 배치를 준비하고, 만들고, 추적하고, 결과를 가져오는 흐름을 따라가면 돼요.
배치 준비 및 생성¶
Message Batch는 Message를 만들기 위한 요청 목록으로 구성돼요. 개별 요청의 형태는 두 가지로 이루어집니다.
- Messages 요청을 식별하기 위한 고유한
custom_id— 1~64자이며 영숫자, 하이픈, 밑줄만 포함할 수 있어요 (^[a-zA-Z0-9_-]{1,64}$와 일치해야 합니다). - 표준 Messages API 매개변수가 담긴
params객체
이 요청 목록을 requests 매개변수에 전달하면 배치를 만들 수 있어요.
from anthropic.types.message_create_params import MessageCreateParamsNonStreaming
from anthropic.types.messages.batch_create_params import Request
client = anthropic.Anthropic()
message_batch = client.messages.batches.create(
requests=[
Request(
custom_id="my-first-request",
params=MessageCreateParamsNonStreaming(
model="claude-opus-5",
max_tokens=1024,
messages=[
{
"role": "user",
"content": "Hello, world",
}
],
),
),
Request(
custom_id="my-second-request",
params=MessageCreateParamsNonStreaming(
model="claude-opus-5",
max_tokens=1024,
messages=[
{
"role": "user",
"content": "Hi again, friend",
}
],
),
),
]
)
print(message_batch)
이 예시에서는 두 개의 개별 요청이 비동기 처리를 위해 하나의 배치로 묶여요. 각 요청에는 고유한 custom_id가 있고, Messages API를 호출할 때 쓰는 표준 매개변수가 포함되어 있죠.
Messages API로 배치 요청 테스트하기 — 각 요청의 params 객체에 대한 유효성 검사는 비동기적으로 이뤄지고, 검사 오류는 전체 배치의 처리가 끝났을 때 반환돼요. 그래서 먼저 Messages API로 요청 형태를 검증해 입력을 올바르게 만들고 있는지 확인하는 게 좋아요.
배치가 처음 만들어지면 응답의 처리 상태는 in_progress예요.
{
"id": "msgbatch_01HkcTjaV5uDC8jWR4ZsDV8d",
"type": "message_batch",
"processing_status": "in_progress",
"request_counts": {
"processing": 2,
"succeeded": 0,
"errored": 0,
"canceled": 0,
"expired": 0
},
"ended_at": null,
"created_at": "2024-09-24T18:37:24.100435Z",
"expires_at": "2024-09-25T18:37:24.100435Z",
"cancel_initiated_at": null,
"results_url": null
}
배치 추적¶
Message Batch의 processing_status 필드는 배치가 어느 처리 단계에 있는지 알려줘요. in_progress로 시작해서, 배치의 모든 요청 처리가 끝나고 결과가 준비되면 ended로 업데이트됩니다. Console을 방문하거나 조회 엔드포인트를 써서 배치 상태를 모니터링할 수 있어요.
Message Batch 완료 폴링 — 배치를 폴링하려면 배치 생성 시 응답에서 받거나 목록 조회로 얻은 id가 필요해요. 처리가 끝날 때까지 주기적으로 상태를 확인하는 폴링 루프를 만들 수 있습니다.
import time
client = anthropic.Anthropic()
MESSAGE_BATCH_ID = "msgbatch_01HkcTjaV5uDC8jWR4ZsDV8d"
message_batch = None
while True:
message_batch = client.messages.batches.retrieve(MESSAGE_BATCH_ID)
if message_batch.processing_status == "ended":
break
print(f"Batch {MESSAGE_BATCH_ID} is still processing...")
time.sleep(60)
print(message_batch)
모든 Message Batch 목록 조회 — 목록 엔드포인트를 사용하면 Workspace의 모든 Message Batch를 나열할 수 있어요. API가 페이지네이션을 지원해서, 필요하면 추가 페이지를 자동으로 가져옵니다.
client = anthropic.Anthropic()
# 필요에 따라 추가 페이지를 자동으로 가져옵니다.
for message_batch in client.messages.batches.list(limit=20):
print(message_batch)
배치 결과 가져오기¶
배치 처리가 끝나면 배치 안의 각 Messages 요청마다 결과가 생겨요. 결과 유형은 네 가지입니다.
| 결과 유형 | 설명 |
|---|---|
succeeded |
요청이 성공했습니다. 메시지 결과가 포함됩니다. |
errored |
요청에 오류가 발생해 메시지가 생성되지 않았습니다. 잘못된 요청, 내부 서버 오류가 대표적이에요. 이 요청에 대해서는 요금이 청구되지 않습니다. |
canceled |
이 요청이 모델로 전송되기 전에 사용자가 배치를 취소했습니다. 요금이 청구되지 않습니다. |
expired |
이 요청이 모델로 전송되기 전에 배치가 24시간 만료 시점에 도달했습니다. 요금이 청구되지 않습니다. |
배치의 request_counts는 이 네 가지 상태 각각에 도달한 요청 수를 보여주는 개요예요.
배치 결과는 Message Batch의 results_url 속성에서 다운로드할 수 있고, 조직 권한이 허용하면 Console에서도 받을 수 있어요. 결과가 클 수 있으니 한 번에 모두 받기보다 결과를 스트리밍하는 걸 권장합니다.
client = anthropic.Anthropic()
# 결과 파일을 메모리 효율적인 청크 단위로 스트리밍하여 한 번에 하나씩 처리합니다
for result in client.messages.batches.results(
"msgbatch_01HkcTjaV5uDC8jWR4ZsDV8d",
):
match result.result.type:
case "succeeded":
print(f"Success! {result.custom_id}")
case "errored":
if result.result.error.error.type == "invalid_request_error":
# 요청을 다시 보내기 전에 요청 본문을 수정해야 합니다
print(f"Validation error {result.custom_id}")
else:
# 요청을 바로 재시도할 수 있습니다
print(f"Server error {result.custom_id}")
case "expired":
print(f"Request expired {result.custom_id}")
결과는 .jsonl 형식으로, 각 줄이 Message Batch의 단일 요청 결과를 나타내는 유효한 JSON 객체예요. 스트리밍된 각 결과에 대해 custom_id와 결과 유형에 따라 서로 다른 작업을 할 수 있습니다. 결과 세트의 예시를 보면 이런 느낌이에요.
{"custom_id":"my-second-request","result":{"type":"succeeded","message":{"id":"msg_014VwiXbi91y3JMjcpyGBHX5","type":"message","role":"assistant","model":"claude-opus-5","content":[{"type":"text","text":"Hello again! It's nice to see you. How can I assist you today? Is there anything specific you'd like to chat about or any questions you have?"}],"stop_reason":"end_turn","stop_sequence":null,"usage":{"input_tokens":11,"output_tokens":36}}}}
{"custom_id":"my-first-request","result":{"type":"succeeded","message":{"id":"msg_01FqfsLoHwgeFbguDgpz48m7","type":"message","role":"assistant","model":"claude-opus-5","content":[{"type":"text","text":"Hello! How can I assist you today? Feel free to ask me any questions or let me know if there's anything you'd like to chat about."}],"stop_reason":"end_turn","stop_sequence":null,"usage":{"input_tokens":10,"output_tokens":34}}}}
결과에 오류가 있으면 result.error가 표준 오류 형태로 설정돼요.
배치 결과는 입력 순서와 일치하지 않을 수 있어요. 배치 결과는 임의의 순서로 반환될 수 있고, 배치 생성 당시의 요청 순서와 다를 수 있답니다. 위 예시에서도 두 번째 배치 요청의 결과가 첫 번째보다 먼저 반환됐죠. 결과를 해당 요청과 올바르게 매칭하려면 항상 custom_id 필드를 사용하세요.
Message Batch 취소¶
취소 엔드포인트로 현재 처리 중인 Message Batch를 취소할 수 있어요. 취소 직후 배치의 processing_status는 canceling이 됩니다. 앞에서 본 것과 같은 폴링 기법으로 취소가 끝날 때까지 기다릴 수 있고, 취소된 배치는 최종적으로 ended 상태가 되며 취소 전에 처리된 요청의 부분 결과를 포함할 수 있어요.
client = anthropic.Anthropic()
MESSAGE_BATCH_ID = "msgbatch_01HkcTjaV5uDC8jWR4ZsDV8d"
message_batch = client.messages.batches.cancel(
MESSAGE_BATCH_ID,
)
print(message_batch)
응답은 canceling 상태의 배치를 보여줍니다.
{
"id": "msgbatch_013Zva2CMHLNnXjNJJKqJ2EF",
"type": "message_batch",
"processing_status": "canceling",
"request_counts": {
"processing": 2,
"succeeded": 0,
"errored": 0,
"canceled": 0,
"expired": 0
},
"ended_at": null,
"created_at": "2024-09-24T18:37:24.100435Z",
"expires_at": "2024-09-25T18:37:24.100435Z",
"cancel_initiated_at": "2024-09-24T18:39:03.114875Z",
"results_url": null
}
Message Batches에서 프롬프트 캐싱 사용하기¶
Message Batches API는 프롬프트 캐싱을 지원해서 배치 요청의 비용과 처리 시간을 줄일 수 있어요. 프롬프트 캐싱과 Message Batches의 가격 할인은 중복 적용이 가능해서, 두 기능을 같이 쓰면 비용 절감 효과가 훨씬 커집니다. 다만 배치 요청은 비동기적으로 동시에 처리되므로 캐시 적중은 최선 노력(best-effort) 방식으로 제공돼요. 사용자들은 보통 트래픽 패턴에 따라 30%에서 98% 범위의 캐시 적중률을 경험합니다.
배치 요청에서 캐시 적중 가능성을 최대화하려면 이렇게 해 보세요.
- 배치 안의 모든 Message 요청에 동일한
cache_control블록을 포함합니다. - 캐시 항목이 5분 수명 이후 만료되지 않도록 꾸준한 요청 흐름을 유지합니다.
- 가능한 한 많은 캐시된 콘텐츠를 공유하도록 요청을 구성합니다.
배치에서 프롬프트 캐싱을 구현하는 예시를 볼게요.
from anthropic.types.message_create_params import MessageCreateParamsNonStreaming
from anthropic.types.messages.batch_create_params import Request
client = anthropic.Anthropic()
message_batch = client.messages.batches.create(
requests=[
Request(
custom_id="my-first-request",
params=MessageCreateParamsNonStreaming(
model="claude-opus-5",
max_tokens=1024,
system=[
{
"type": "text",
"text": "You are an AI assistant tasked with analyzing literary works. Your goal is to provide insightful commentary on themes, characters, and writing style.\n",
},
{
"type": "text",
"text": "<the entire contents of Pride and Prejudice>",
"cache_control": {"type": "ephemeral"},
},
],
messages=[
{
"role": "user",
"content": "Analyze the major themes in Pride and Prejudice.",
}
],
),
),
Request(
custom_id="my-second-request",
params=MessageCreateParamsNonStreaming(
model="claude-opus-5",
max_tokens=1024,
system=[
{
"type": "text",
"text": "You are an AI assistant tasked with analyzing literary works. Your goal is to provide insightful commentary on themes, characters, and writing style.\n",
},
{
"type": "text",
"text": "<the entire contents of Pride and Prejudice>",
"cache_control": {"type": "ephemeral"},
},
],
messages=[
{
"role": "user",
"content": "Write a summary of Pride and Prejudice.",
}
],
),
),
]
)
예시에서 두 요청 모두 캐시 적중 가능성을 높이기 위해 cache_control로 표시된 동일한 시스템 메시지와 오만과 편견(Pride and Prejudice) 전문을 담고 있어요.
서버 도구와 에이전트 루프¶
모든 서버 도구(웹 검색, 웹 가져오기, 코드 실행, MCP 커넥터, 어드바이저, 도구 검색)는 배치 요청에서 동작해요. 배치 워커는 동기식 Messages API와 동일한 서버 측 에이전트 루프를 실행합니다.
유지해야 할 열린 연결이 없기 때문에, 배치 루프는 stop_reason: "pause_turn"을 반환하기 전에 동기식 요청보다 턴당 더 많은 반복을 실행해요. 배치 결과가 pause_turn과 함께 반환됐다면 그 턴은 아직 완료되지 않은 거예요. pause_turn 계속 패턴에 나오는 것처럼, 일시 중지된 어시스턴트 콘텐츠를 후속 요청(배치든 동기식이든)에 제출해서 이어서 진행할 수 있습니다.
배치 워커는 추가로 조직별로 web_search를 스로틀링해서, 동시성이 높은 배치 처리가 조직의 웹 검색 속도 제한을 소진하지 않도록 해요. 배치는 스로틀링된 요청을 자동으로 재시도하므로 직접 처리할 필요는 없지만, 아주 큰 웹 검색 배치는 완료하는 데 더 오래 걸릴 수 있다는 점만 알아 두세요.
확장 출력 (베타)¶
output-300k-2026-03-24 베타 헤더는 Claude Opus 5, Claude Opus 4.8, Claude Opus 4.7, Claude Opus 4.6, Claude Sonnet 5, Claude Sonnet 4.6을 사용하는 배치 요청에 대해 max_tokens 상한을 300,000으로 높여줍니다. 단일 턴에서 표준 128k max_tokens 제한보다 훨씬 긴 출력을 만들고 싶을 때 이 헤더를 포함하면 돼요.
확장 출력은 Message Batches API에서만 사용할 수 있어요(동기식 Messages API에서는 불가능). Claude API와 Claude Platform on AWS에서 지원되며, 현재 Amazon Bedrock, Google Cloud, Microsoft Foundry에서는 사용할 수 없습니다.
책 분량의 초안이나 기술 문서 같은 장문 생성, 포괄적인 구조화 데이터 추출, 대규모 코드 생성 스캐폴드, 긴 추론 체인에 확장 출력을 활용할 수 있어요.
주의할 점이 하나 있어요. 단일 300k 토큰 생성은 완료하는 데 1시간 이상 걸릴 수 있으니, 24시간 처리 기간을 염두에 두고 배치 제출을 계획하세요. 가격은 표준 배치 가격(표준 API 가격의 50%)이 그대로 적용됩니다.
from anthropic.types.beta.message_create_params import MessageCreateParamsNonStreaming
from anthropic.types.beta.messages.batch_create_params import Request
client = anthropic.Anthropic()
message_batch = client.beta.messages.batches.create(
betas=["output-300k-2026-03-24"],
requests=[
Request(
custom_id="long-form-request",
params=MessageCreateParamsNonStreaming(
model="claude-opus-5",
max_tokens=300_000,
messages=[
{
"role": "user",
"content": "Write a comprehensive technical guide to building distributed systems, covering architecture patterns, consistency models, fault tolerance, and operational best practices.",
}
],
),
),
],
)
print(message_batch)
효과적인 배치 처리를 위한 모범 사례¶
Batches API를 최대한 활용하려면 이 기준들을 지켜 보세요.
- 배치 처리 상태를 정기적으로 모니터링하고, 실패한 요청에는 적절한 재시도 로직을 구현합니다.
- 순서가 보장되지 않으므로, 결과를 요청과 쉽게 매칭할 수 있도록 의미 있는
custom_id값을 사용합니다. - 관리 용이성을 위해 아주 큰 데이터셋은 여러 배치로 나누는 걸 고려합니다.
- 유효성 검사 오류를 피하기 위해 Messages API로 단일 요청 형태를 미리 테스트(dry run)합니다.
일반적인 문제 해결¶
예상치 못한 동작이 생기면 아래 항목을 하나씩 확인해 보세요.
- 전체 배치 요청 크기가 256MB를 초과하지 않는지 — 너무 크면
413 request_too_large오류가 발생할 수 있어요. - 배치의 모든 요청에 지원 모델을 사용하는지.
- 배치의 각 요청에 고유한
custom_id가 있는지. - 배치
created_at(처리ended_at이 아니라) 기준으로 29일이 지나지 않았는지 — 지났다면 결과를 더 이상 볼 수 없어요. - 배치가 취소되지 않았는지.
참고로 배치 안에서 한 요청이 실패해도 다른 요청의 처리에는 영향을 미치지 않아요.
배치 저장 및 개인정보 보호¶
- Workspace 격리: 배치는 생성된 Workspace 안에서 격리됩니다. 같은 Workspace의 API 요청을 쓰거나, Console에서 Workspace 배치를 볼 권한이 있는 사용자만 접근할 수 있어요.
- 결과 가용성: 배치 결과는 생성 후 29일 동안 사용할 수 있어, 조회와 처리에 충분한 시간을 줍니다.
데이터 보존¶
배치 처리는 배치 생성 후 최대 29일 동안 요청과 응답 데이터를 저장해요. 처리 후 언제든 DELETE /v1/messages/batches/{batch_id} 엔드포인트로 메시지 배치를 삭제할 수 있고, 진행 중인 배치를 삭제하려면 먼저 취소하세요. 비동기 처리에는 배치 완료와 결과 조회 시점까지 입력과 출력 모두 서버 측 저장이 필요하기 때문이에요.
모든 기능에 대한 ZDR 적격성은 API 및 데이터 보존을 참조하세요.
FAQ¶
- 배치 처리에는 얼마나 걸리나요? — 대부분의 배치는 1시간 이내에 완료되고, 최대 수명은 24시간이에요.
- Batches API는 모든 모델에서 사용할 수 있나요? — 네, 모든 활성 모델이 지원됩니다.
- Message Batches API를 다른 API 기능과 함께 사용할 수 있나요? — 프롬프트 캐싱, 서버 도구, 확장 출력 등과 함께 쓸 수 있어요.
- Message Batches API는 가격에 어떤 영향을 미치나요? — 모든 사용량이 표준 API 가격의 50%로 청구됩니다.
- 제출한 후 배치를 업데이트할 수 있나요? — 배치를 수정하는 대신, 필요하면 취소 후 새로 제출하는 방식으로 접근해요.
- Message Batches API 속도 제한이 있나요? 그리고 Messages API 속도 제한과 상호작용하나요? — 별도의 속도 제한이 적용되며, 자세한 내용은 속도 제한 문서를 참조하세요.
- 배치 요청의 오류는 어떻게 처리하나요? — 결과 유형을 확인하고
invalid_request_error와 서버 오류를 구분해서 처리합니다. - Message Batches API는 개인정보 보호와 데이터 분리를 어떻게 처리하나요? — 배치는 생성된 Workspace 안에서 격리됩니다.
- Message Batches API에서 프롬프트 캐싱을 사용할 수 있나요? — 네, 지원되며 최선 노력 방식으로 캐시 적중이 제공됩니다.