배치 및 비동기식 워크로드

이득:

• 일괄 처리가 적합한 워크로드 결정
• 동기식, 비동기식 및 일괄 처리 간의 비용/지연 시간 균형을 이해합니다.
• custom_id를 결과와 일치시키는 강력한 일괄 작업 흐름을 설계합니다.

대부분의 LLM 통합은 사용자가 화면 앞에서 응답을 기다리는 "실시간" 시나리오에 중점을 둡니다. 그러나 대부분의 전문 작업량은 실제로 실시간이 아닙니다. 하룻밤 사이에 수천 개의 문서에 태그를 지정하고, 전체 데이터 세트를 요약하고, 전체 통화 녹음을 아카이브에서 분류합니다. 이러한 문제에 있어서 누구도 즉각적인 답변을 기대하지 않습니다. 중요한 것은 저렴하고 안정적으로 작업을 마무리하는 것입니다. Batch는 바로 이러한 워크로드에 적합합니다. 이 단원에서는 일괄 처리가 올바른 선택일 때 동기식, 비동기식, 일괄 처리 간의 차이점과 custom_id 및 결과를 확실하게 일치시키는 강력한 흐름에 대해 알아봅니다.

세 가지 작업 모드

모드

어떻게 작동하나요?

지연

일반적인 비용

적합한 직업

동기식

요청을 하고 응답을 기다립니다.

초

표준

라이브 채팅, 인스턴트 어시스턴트

비동기식

작업을 대기열에 추가하고 완료되면 알림을 받습니다.

초~분

표준

백그라운드 작업, 자동화 단계

배치

하나의 패키지로 수천 개의 요청을 보낸 후 결과를 얻습니다.

분~시간

보통 할인됨

지연이 허용되는 대용량 작업

일괄 처리는 다음과 같습니다. 수백/수천 개의 요청을 단일 "작업"으로 공급자에게 보냅니다. 공급자는 이를 자체 속도로 처리하고 완료되면 모든 결과를 대량으로 반환합니다. 그 대가로 (1) 일반적으로 더 낮은 단가, (2) 속도 제한을 처리하지 않고도 대량으로 이동할 수 있는 능력이라는 두 가지 이점을 얻을 수 있습니다. 대가는 결과가 즉시 나오지 않고 일정 시간이 지나면 나온다는 것입니다.

일괄 처리할 때, 하지 않을 때는?

결정은 하나의 질문으로 귀결됩니다. 사용자가 지금 결과를 기다리고 있습니까?

• 아니요, 보유할 수 있습니다 → 배치 후보입니다. 야간 태깅, 일괄 요약, 아카이브 분류, 데이터 강화, 평가(eval) 실행.
• 네, 화면에서 기다리고 있어요 → 동기화하세요. 실시간 채팅, 즉각적인 조언, 양식 작성 시 도움을 드립니다.

팁: 동일한 제품에 두 가지 모드가 공존할 수 있습니다. 사용자는 실시간 채팅에서 동시에 작업합니다. 밤에는 품질 분석을 위해 그날의 모든 대화를 배치에 제공합니다. '살아있는 욕구'와 '집단적 욕구'를 분리하는 것이 건축의 첫 번째 결정이다.

강력한 배치 흐름의 분석

일괄 처리의 가장 중요한 기술 규칙은 결과 일치입니다.

1. 각 요청에 고유한 'custom_id'를 부여하세요. 이는 요청을 식별하는 생성된 ID입니다(예:voice-2026-07-18-000431).
2. 작업을 제출합니다. 모든 요청은 하나의 패키지로 이루어집니다. 각각은 자체 custom_id를 가지고 있습니다.
3. 상황을 조사해 보세요. 작업이 "완료"될 때까지 간격을 두고 상태를 요청합니다.
4. 결과를 `custom_id`와 일치시킵니다. 결과는 제출 순서와 다른 순서로 반환될 수 있습니다. 따라서 위치별로 일치하지 않고 각 결과가 전달하는 custom_id로 일치합니다.
5. 각 결과의 유형을 확인하세요. 한 요청은 성공할 수도 있고, 한 요청이 실패하거나, 한 요청이 만료될 수도 있습니다. 성공/실패에 따른 프로세스입니다.

{ "requests": [ { "custom_id": "invoice-000431", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "송장을 분류합니다. JSON만 반환합니다.", "messages": [{ "role": "user", "content": "{{invoice_text}}" }] } }, { "custom_id": "invoice-000432", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "송장을 분류합니다. JSON만 반환합니다.", "messages": [{ "role": "user", "content": "{{invoice_text_2}}" }] } } ]}

주의: 제출 순서에 따른 매칭 결과는 일괄 처리에서 가장 큰 실수입니다. 대기열은 유지되지 않습니다. custom_id가 없으면 어떤 결과가 어떤 문서에 속하는지 확실하게 알 수 없습니다. 잘못된 일치로 인해 자동으로 잘못된 데이터가 발생합니다.

복사 가능한 템플릿

# custom_id 생성 규칙(고유하고 추적 가능)형식: <isture>-<date>-<sequence>. 예: request-20260718-000431규칙: 작업 중에 반복하지 마십시오. 리소스 레코드 ID를 포함합니다.

# 일괄 작업 카드(스케줄링 템플릿)작업 이름: .............레코드 수: .............모델: .............(단순 작업 → 빠른 모델)요청당 Max_tokens: .............예상 배달 시간 허용 범위: .........시간결과 매칭 키: custom_id 오류 발생 시: 재시도 / 대기열 / 보고

# 일괄적으로 단일 요청 프롬프트(짧고 도식적) 이 문서를 분류합니다. 다음 JSON을 반환하고 다음과 같이 주석을 달아주세요:{"category":"...","urgency":"low|medium|high"}Document: """{{document}}"""

# 각 결과에 대한 결과 처리 의사 코드: if result.status == "success": Record = find(custom_id) save(record, result.output) else: add_to_fail(custom_id, result.error) # 그런 다음 다시 시도

약한 프롬프트 / 강한 프롬프트(일괄 작업 설계)

# WEAK (취약한 디자인) Strong 모델로 10,000개의 문서를 순서대로 보내고, 반환된 결과를 도착한 순서대로 저장합니다.

# STRONG(내구성 있는 디자인) 빠른 모델로 10,000개의 문서를 한 번에 보냅니다. 각 문서에 소스 레코드 ID가 포함된 고유한 custom_id를 부여하세요. 결과를 custom_id와 일치시킵니다. 실패한 것을 대기열에 넣고 다시 시도하십시오. 밤 창에서 실행하십시오. 배달 허용 시간은 6시간입니다.

강력한 버전; 모델 선택, 일치 키, 오류 처리 및 타이밍을 사전 정의합니다. 수만 건의 기록을 안전하게 처리한다는 점에서 차이가 납니다.

미니 케이스 3개

사례 1 — 야간 태깅. 전자상거래 팀은 200,000개의 제품 리뷰를 감정 태그로 분류합니다. 라이브 동기 스트리밍에는 속도 제한이 있었고 비용이 많이 들었습니다. 그들은 빠른 모델을 사용하여 일괄적으로 작업을 밤까지 수행했습니다. 단가가 떨어졌고, 아침에 전체 세트가 준비되었으며, 속도 제한 문제도 없었습니다.

사례 2 - 주문 혼란. 연구팀은 5,000개의 기사를 추상화했지만 도착한 순서대로 결과를 파일에 기록했습니다. 결과가 다른 순서로 반환되었기 때문에 초록 5,000개 중 약 900개가 잘못된 논문에 연결되었습니다. 그들은 그것을 custom_id로 다시 매핑했습니다. 문제가 해결되었고 이 경험은 "항상 일괄적으로 custom_id"라는 영구적인 규칙이 되었습니다.

사례 3 — 잘못된 모드의 실시간 대기. 지원팀은 사용자가 화면에서 기대했던 실시간 응답을 일괄적으로 제공하려고 시도했습니다. 결과가 몇 분 후에 도착했기 때문에 사용자가 이탈했습니다. 실시간 작업을 다시 동기화로 옮기고 배치에는 야간 품질 분석만 남겨 두었습니다. 교훈: 배치는 실시간 대기용이 아닙니다.

일반적인 실수

• 위치별 매칭 결과: 순서는 유지되지 않습니다. custom_id를 사용하세요.
• 라이브 작업을 배치로 전송하는 중: 사용자는 몇 분 동안 기다릴 수 없습니다. 배치는 지연 허용 작업을 위한 것입니다.
• 오류 사례를 처리하지 않음: 일부 요청은 실패/만료를 반환할 수 있습니다. 별도의 대기열에 넣고 다시 시도하세요.
• 배치에서 강력한 모델 사용 반사: 빠른 모델 + 배치는 간단한 작업에서 가장 저렴한 조합입니다.
• custom_id를 추적 가능하게 만들지 않음: ID에 소스 레코드가 포함되어 있지 않으면 결과를 다시 연결하기가 어려워집니다.
• 상황 조사를 잊어버린 경우: 작업이 완료되기 전에 결과를 기대합니다. 완료 상태를 확인하세요.

심층: 배치 모니터링 및 부분 실패 관리

일괄 처리의 가장 성숙한 측면은 개별 통화와는 다른 사고방식이 필요하다는 것입니다. 일괄 작업은 "이벤트"가 아니라 "프로세스"입니다. 수만 건의 요청이 모두 성공할 것이라고 가정하는 것은 취약합니다. 현실적인 디자인은 처음부터 부분적인 실패를 허용합니다. 각 결과의 상태는 성공, 실패(예: 잘못된 입력), 취소 또는 만료 등 다양할 수 있습니다. 강력한 흐름은 각 결과의 상태를 개별적으로 처리하고, 실패를 별도의 "재시도 대기열"에 넣고 해당 대기열을 별도로 실행합니다.

두 번째 방법은 멱등성을 고려하여 설계하는 것입니다(동일한 작업을 두 번 실행해도 해를 끼치지 않음). 배치가 중단되었다가 다시 시작하는 경우 이미 처리된 레코드를 다시 처리하여 두 번 작성해서는 안 됩니다. custom_id를 소스 레코드에 바인딩하면 여기서도 작동합니다. "이 레코드가 이미 처리되었습니까?" 결과를 저장하기 전에. 선택하면 이중 입력을 방지할 수 있습니다.

세 번째 요점은 일괄 처리를 통해 실시간 스트림을 시차를 두는 것입니다. 일부 작업에는 라이브 차원과 배치 차원이 모두 있습니다. 사용자가 문서를 로드하면 빠른 예비 요약(동기식)을 제공하고 밤에 더 심층적인 분석을 위해 동일한 문서를 재처리합니다(배치). 두 모드를 의식적으로 분리하면 사용자 경험과 비용이 모두 최적화됩니다.

마지막으로 일괄 처리는 속도 제한을 처리하는 방법이기도 합니다(단위 8). 실시간 동기식 흐름에서 높은 볼륨을 전송하면 상수 429가 생성되는 반면, 동일한 볼륨을 일괄 전송으로 전송하면 공급자의 자체 일정에 대한 제한 압력이 발생하고 작업을 더 예측하기 쉬워집니다.

요약하면

일괄 처리는 일반적으로 대기 시간이 허용되는 대용량 워크로드에 대해 더 저렴하고 강력한 모드입니다. 그의 결정은 '이제 사용자는 결과를 기다리고 있는가?'였다. 질문을 결정합니다. 가장 중요한 기술 규칙은 각 요청에 고유한 custom_id를 제공하고 위치가 아닌 ID로 결과를 일치시키며 각 결과의 성공/실패를 별도로 처리하는 것입니다.

응용과제

대용량 작업(예: 아카이브 분류)을 선택합니다. (1) 이 저작물이 라이브인지 집단인지 판단하고 정당화합니다. (2) custom_id 형식을 디자인합니다(리소스 레코드 포함). (3) 배치 작업 카드(모델, max_tokens, 허용 오차, 오류 정책)를 작성합니다. (4) 실패한 요청을 포함하도록 결과 처리 의사코드를 작성합니다.

체크리스트

• [ ] 비용/지연 축에서 동기식, 비동기식, 배치 모드를 구분할 수 있습니다.
• [ ] 나는 올바른 질문을 통해 해당 직무가 배치에 적합한지 여부를 결정할 수 있습니다.
• [ ] 각 요청에 고유한 custom_id를 제공하고 결과를 ID별로 일치시킵니다.
• [ ] 실패/만료된 결과를 별도로 처리할 수 있습니다.
• [ ] 간단한 배치 작업에서 빠른 모델을 선택하면 얻을 수 있는 이점을 알고 있습니다.