서버리스 AI API에서 배치 처리 최적화하기

AI 작업에 즉각적인 응답이 필요하지 않다면, 배치 처리가 대개 더 나은 방법입니다. 저라면 이를 활용해 API 비용을 약 50% 절감하고, 백그라운드 작업을 실시간 트래픽에서 분리하며, 모든 것을 하나의 서버리스 함수에 몰아넣지 않고도 대규모 텍스트, 이미지, 오디오, 비디오 워크로드를 처리하겠습니다.

간단히 정리하면 다음과 같습니다.

• 하나의 장시간 실행 함수 대신 큐, 무상태 워커, 오브젝트 스토리지를 사용하겠습니다.

• 많은 LLM 작업의 경우 배치당 100~500개 항목으로 시작한 뒤, 미디어 중심 작업에서는 배치 크기를 줄이겠습니다.

• 워커당 함수 내 동시성을 약 5~10개 요청으로 제한하고, 요청 수뿐 아니라 분당 토큰 수를 주시하겠습니다.

• 10~50개 항목마다 체크포인트, 3~5회 재시도, 지수 백오프, 데드레터 큐를 추가하겠습니다.

• job_id:item_id 같은 안정적인 키로 모든 항목을 멱등적으로 만들고 결정론적 출력 경로를 사용하겠습니다.

• **분당 항목 수, 배치 소요 시간, 재시도율, 오류율, 배치당 비용(USD)**을 추적하겠습니다.

• 새 작업은 확장하기 전에 10~50개 항목 파일럿으로 테스트하겠습니다.

핵심 아이디어는 단순합니다. 배치 AI 파이프라인은 제약을 먼저 고려해 설계할 때 가장 잘 작동합니다. 서버리스 타임아웃, 메모리 상한, 페이로드 제한, 제공업체 스로틀링은 모두 배치 크기, 팬아웃, 재시도, 스토리지 패턴을 결정합니다.

멀티 모델 워크플로의 경우, 저라면 API 계층도 단순하게 유지하겠습니다. APIMart 같은 통합 서비스는 하나의 파이프라인이 텍스트, 이미지, 비디오 작업을 위해 각 워커에 별도의 벤더 로직 없이 500개 이상의 모델로 라우팅해야 할 때 도움이 됩니다.

가장 중요한 것은 순수한 속도가 아닙니다. 처리량, 재시도 안전성, 실행당 비용 관리입니다.

서버리스 AI 추론: 확장 가능하고 비용 효율적인 모델 서빙 설명 | Uplatz

확장 가능한 서버리스 배치 파이프라인 설계 방법

이러한 제약은 큐 기반 구성을 선택하도록 유도합니다.

핵심 파이프라인 구성 요소와 데이터 흐름

확장 가능한 배치 파이프라인은 네 가지 부분으로 구성됩니다. 프로듀서, 내구성 있는 메시지 큐, 워커 풀, 결과 저장소입니다.

기본 흐름은 다음과 같습니다. 프로듀서가 대용량 페이로드를 오브젝트 스토리지에 업로드한 뒤 가벼운 작업을 큐에 넣습니다. 워커는 그 작업을 가져와 페이로드를 조회하고, AI API를 호출하고, 결과를 저장한 뒤에야 메시지를 확인 처리(ack)합니다. 그 마지막 단계가 중요합니다. 워커가 작업 도중 크래시되면, 확인되지 않은 메시지가 다시 나타나 다른 워커가 재시도할 수 있습니다 ^[6][7].

작업이 너무 커서 함수 타임아웃 내에 완료할 수 없다면, 데이터셋을 더 작은 배치로 나누고 장기 실행 오케스트레이터를 통해 병렬 워커에 작업을 팬아웃하세요.

이 기본 흐름이 작동하고 나면, 다음 단계는 모달리티와 런타임별로 작업을 라우팅하는 것입니다.

모달리티별로 워크플로를 분리해야 할 때

페이로드 크기나 처리 시간이 의미 있게 달라질 때는 별도의 큐를 사용하세요. 모든 AI 작업이 같은 워커 풀에 있어야 하는 것은 아닙니다. 텍스트 분류는 항목당 몇 초가 걸릴 수 있습니다. 무거운 미디어 작업은 몇 분씩 실행될 수 있습니다. 둘을 하나의 풀에 넣으면 타임아웃 동작이 금방 엉망이 됩니다 ^[4][7].

더 나은 접근법은 파일 유형만이 아니라 런타임과 페이로드 크기별로 큐를 분리하는 것입니다. 이벤트 유형별로 작업을 라우팅하세요. 예를 들어 PDF, 이미지, 오디오, 비디오를 이벤트 필터가 있는 별도의 큐와 워커 풀로 보내세요. 그렇게 하면 재시도가 격리되고 한 워크로드가 다른 워크로드를 막는 일이 방지됩니다 ^[8].

APIMart를 통합 AI API 계층으로 사용하기

하나의 파이프라인이 텍스트, 이미지, 비디오 작업을 처리할 때 별도의 벤더 통합을 다루는 일은 유지보수의 골칫거리가 될 수 있습니다 ^[2][6]. APIMart는 GPT-5와 Claude 같은 언어 모델, 이미지 모델, 그리고 Sora와 Kling V3 같은 비디오 모델을 포함해 500개가 넘는 AI 모델을 하나의 API로 제공합니다.

이는 워커 함수가 서로 다른 작업 유형 전반에서 무상태이고 일관성을 유지할 수 있음을 의미합니다. 또한 인증, 속도 제한, 재시도 로직이 모두 하나의 통합 지점 뒤에 있기 때문에, 파이프라인의 여러 단계가 서로 다른 모델을 필요로 할 때도 도움이 됩니다.

적절한 배치 크기와 병렬성 모델을 선택하는 방법

파이프라인 아키텍처가 정해지고 나면, 다음 결정은 이론상 단순하지만 실무에서는 망치기 쉽습니다. 각 워커가 한 번에 얼마만큼의 작업을 처리해야 하고, 몇 개의 요청을 병렬로 실행해야 할까요?

배치가 너무 작으면 오버헤드에 컴퓨팅을 낭비합니다. 너무 크면 실패 비용이 커지는데, 재시도가 늦게 발생하고 너무 많은 작업을 다시 하기 때문입니다. 최적점은 대개 런타임, 메모리 사용량, 재시도 비용의 균형에서 나옵니다.

배치 크기를 런타임, 메모리, 재시도와 균형 맞추기

대부분의 LLM 워크로드에서 배치당 100~500개 항목은 견고한 시작 범위입니다. 오케스트레이션 오버헤드를 더 많은 작업에 분산할 만큼 크면서도, 실패가 거대한 청크를 다시 실행하도록 강제하지 않을 만큼 작습니다.

재시도가 이를 그려보기 쉽게 합니다. 워커가 거대한 배치의 막바지에서 크래시되면, 그 모든 작업을 다시 해야 할 수 있습니다. 그래서 10~50회 완료마다 체크포인트를 두어 크래시가 작은 조각의 작업만 다시 하게 하는 것이 도움이 됩니다 ^[2][11].

미디어 중심 작업은 각 응답이 더 크기 때문에 대개 텍스트 전용 작업보다 작은 배치가 필요합니다 ^[1].

불균형한 워크로드에는 동적 배칭 사용하기

고정 배치 크기는 서류상으로는 깔끔해 보입니다. 프로덕션에서는 종종 무너집니다.

트래픽은 변합니다. 야간 대량 실행은 분당 수천 개 항목을 밀어넣을 수 있는 반면, 주간 트래픽은 느리게 들어올 수 있습니다. 하나의 고정 배치 크기로는 두 경우를 모두 잘 처리하지 못합니다.

동적 배칭은 다음 중 하나가 발생하면 배치를 보내는 방식으로 이를 처리합니다.

• 배치가 설정된 크기에 도달

• 설정된 대기 창이 만료

일반적인 구성은 최대 배치 크기에 최대 대기 시간(예: 5초)을 더하는 것입니다 ^[9][1]. 바쁜 기간에는 크기 제한에 계속해서 도달하여 처리량이 높게 유지됩니다. 느린 기간에는 타이머가 작동하여 항목이 큐에 그냥 머물지 않게 합니다.

또한 여러 항목을 하나의 프롬프트에 담아 시스템 프롬프트 오버헤드를 더 많은 작업에 분산할 수도 있습니다 ^[10].

각 함수 안에서 API 호출을 동시에 실행하기

배치 크기가 정해지고 나면, 다음 단계는 각 함수 안에서 병렬 호출을 제어하는 것입니다.

대부분의 지연은 보통 로컬 컴퓨팅이 아니라 네트워크 응답을 기다리는 데서 발생합니다. 그래서 비동기 동시성이 대개 적합합니다. 여러 요청을 한 번에 보낸 뒤, 이벤트 루프가 대기를 처리하게 하세요.

중요한 부분은 상한입니다. 세마포어를 사용해 함수 내 동시성을 제한하세요. 5~10개 동시 요청 풀이 합리적인 시작점입니다 ^[9][11]. 훨씬 더 높이면 제공업체 속도 제한에 걸릴 수 있습니다.

LLM API에서는 주된 제약이 순수 요청 수가 아니라 종종 분당 토큰 수입니다. 그러니 롤링 60초 창에 걸친 토큰 사용량을 추적하고 제공업체가 대신 하기 전에 스로틀링하세요 ^[10]. 그 가드레일이 중요한 이유는, 그렇지 않으면 한 워커가 메모리를 잡아먹거나 파이프라인 전체의 스로틀링을 유발할 수 있기 때문입니다.

재시도 비용을 폭발시키지 않으면서 처리량 목표를 달성하는 가장 단순한 구성을 사용하세요.

규모에 맞게 배치 워크플로를 신뢰성 있고 관측 가능하게 유지하는 방법

배치 크기와 동시성을 제대로 맞추는 것은 절반에 불과합니다. 볼륨이 커질수록 더 어려운 부분은 문제가 발생할 때 작업을 안전하게 지키고 문제를 빠르게 발견하는 것입니다.

전체를 재처리하지 않고 부분 실패 처리하기

하나의 잘못된 레코드가 전체 배치를 죽여서는 절대 안 됩니다. 하나의 입력이 잘못되었거나 하나의 요청이 타임아웃되더라도, 그 실패는 격리된 상태로 남아야 합니다.

실무에서는 각 항목의 처리 로직에 자체 오류 처리가 필요합니다. 각 청크 이후에 원자적 체크포인트를 기록한 뒤, 처음부터 다시 시작하는 대신 마지막 체크포인트에서 재개하세요. 항목이 3~5회 재시도 후에도 여전히 실패하면, 영원히 재시도하는 대신 수동 검토를 위해 **데드레터 큐(DLQ)**로 보내세요. 각 재시도 시도 전에 지수 백오프를 사용하세요. 예를 들어 1초, 그다음 2초, 그다음 4초 기다리는 식으로, 속도 제한된 API 엔드포인트를 두드리지 않도록 하세요 ^[12][1][13].

복구가 안전해지면, 그것이 얼마나 자주 발생하고 비용이 얼마나 드는지 추적하세요.

모든 배치 작업을 멱등적으로 만들기

재시도는 반복 실행이 같은 결과를 낼 때만 안전합니다.

이는 일시적 오류가 종종 자동 재시도를 유발하는 서버리스 플랫폼에서 더욱 중요합니다. 멱등성이 없으면, 그런 재시도가 중복 쓰기나 그 밖의 반복된 부작용으로 이어질 수 있습니다.

해결책은 단순합니다. 런타임 타임스탬프를 사용하는 대신 job_id:item_id 같은 안정적인 멱등성 키를 만드세요 ^[14][15]. 그런 다음 upsert를 사용해 항목을 재처리할 때 두 번째 레코드를 만드는 대신 기존 레코드를 대체하게 하세요. S3 같은 파일 기반 스토리지의 경우, 작업 항목 파라미터에 연결된 결정론적 출력 경로를 사용해 재실행이 중복을 만드는 대신 같은 출력을 덮어쓰게 하세요 ^[2][13].

또한 큐 가시성 타임아웃을 예상 p99 처리 시간의 최소 3배로 설정해야 합니다. 그렇게 하면 두 번째 워커가 첫 번째 워커에서 아직 실행 중인 작업을 가져가는 것을 방지합니다 ^[2][13].

배치당 처리량, 지연 시간, 비용 추적하기

부하 상황에서 배칭이 여전히 타당한지 보여주는 지표가 필요합니다. 배치 수준에서 다음을 추적하세요.

• 분당 처리 항목 수

• 평균 배치 소요 시간

• 항목당 재시도 횟수

• 오류율

• 총 입력 및 출력 토큰에 기반한 배치당 비용(USD) ^[12][1][2]

성공률이 95% 아래로 떨어지면 알림을 설정하세요 ^[1].

실패한 항목만 재시도하세요. 건너뛰고 로깅하는 방식은 중요하지 않은 보강 작업에만 사용하세요.

프로덕션 워크로드의 비용을 줄이고 성능을 개선하는 방법

주요 비용 유발 요인 파악하기

비용을 줄이기 전에, 돈이 어디로 가는지 봐야 합니다.

서버리스 AI 배치 파이프라인에서는 AI API 토큰 사용량이 보통 가장 큰 비용입니다. 배치 모드는 두 가지 측면에서 도움이 됩니다. 토큰 지출을 줄이고 요청 오버헤드를 낮춥니다. 실무에서 배치 API는 동기 호출보다 약 50% 낮은 토큰 비용을 제공합니다 ^[5][18].

토큰 다음으로는 서버리스 컴퓨팅 지속 시간이 종종 그다음 큰 유발 요인인데, 특히 GPU 런타임으로 청구되는 비디오와 이미지 작업에서 그렇습니다 ^[17]. 스토리지와 데이터 전송도 슬그머니 커질 수 있습니다. 대용량 파일을 리전 간에 이동한다면, 그 요금이 빠르게 쌓입니다. 그리고 고위험 워크플로에서는 낮은 신뢰도 출력에 대한 사람의 검토가 그 자체로 주요 비용 센터가 될 수 있습니다 ^[16].

비용 패턴은 모달리티에 따라서도 달라집니다. 텍스트 워크로드는 토큰 기반이라 보통 예측하기 더 쉽습니다. 비디오 생성은 다르게 작동합니다. 출력의 초 단위로 청구되므로, 클립 길이가 지출에 직접적인 영향을 미칩니다. 10초 클립은 단순히 5초 클립보다 비쌉니다. 그래서 여기서 실행 튜닝이 그토록 중요합니다.

메모리, 타임아웃, 패키지 크기, 쓰기 패턴 튜닝하기

가장 좋은 절감의 상당수는 화려한 기교가 아니라 평범한 실행 튜닝에서 나옵니다.

클라이언트 타임아웃을 60초 이상으로 설정하세요. 대용량 배치를 한 번에 메모리에 로드하는 대신 JSONL 입력과 출력을 스트리밍하세요. 그 한 가지 변경만으로도 메모리 압박을 줄이고 배치 작업을 덜 취약하게 만들 수 있습니다. 양자화는 VRAM이 병목일 때만 사용하세요 ^[5][18].

이것들은 작은 조정이지만, 작업 자체를 바꾸지 않고도 낭비를 줄일 수 있습니다.

메모리 사용량과 I/O가 어느 정도 정리되면, 다음 큰 레버는 모델 선택입니다.

모델 선택과 배치 전략을 비즈니스 목표에 맞추기

가장 큰 비용 레버는 작업에 맞는 적절한 모델을 고르는 것입니다.

GPT-5나 Claude Opus 같은 프런티어 모델은 복잡한 추론에 적합합니다. 하지만 분류나 추출에는 과할 수 있습니다. 더 가벼운 모델로도 종종 충분합니다. 많은 파이프라인에서 대략 80%의 작업에 더 가벼운 모델을 쓰고 나머지 **20%**에 더 무거운 모델을 남겨두면 평균 비용을 **70%에서 90%**까지 줄일 수 있습니다 ^[18][19].

단순한 분할이 종종 잘 작동합니다.

• 추출과 분류에는 더 가벼운 모델 사용

• 추론에는 더 무거운 모델 예약

• 작업 복잡도에 따라 배치 크기 조정

서로 다른 작업 유형을 서로 다른 모델로 라우팅해야 한다면, APIMart가 500개가 넘는 모델에 걸친 단일 API를 제공합니다.

확장하기 전에 10~50개 항목 파일럿을 실행해 항목당 비용을 측정하세요. 그러면 볼륨이 올라가기 전에 각 작업의 예상 비용을 깔끔하게 파악할 수 있습니다.

결론: 배치 AI 워크플로를 개선하는 가장 단순한 방법

파이프라인, 배치 크기, 신뢰성 검사, 비용 가드레일이 정해지고 나면 확장은 훨씬 단순해집니다. 팬아웃 병렬성, 적정 크기 배치, 엄격한 재시도 처리가 느리고 순차적인 작업을 프로덕션에서 실행할 수 있는 것으로 바꾸는 주요 레버입니다.

실패를 격리된 상태로 유지하세요. 재시도를 멱등적으로 만드세요. 예상 결과를 실제 출력과 대조하세요. 그것이 무언가 고장 났을 때 시스템이 어긋나지 않게 지켜주는 부분입니다. 그다음에는 대개 비용이 다음 한계가 됩니다.

지출을 배치 실행당 USD로 추적해 비용을 각 작업에 연결하고 비싼 이상치를 발견할 수 있게 하세요 ^[2]. 새 워크로드는 10~50개 항목 파일럿으로 시작하고, 항목당 비용을 검증한 뒤, 계산이 맞아떨어지면 확장하세요 ^[1][3].

대부분의 작업에서는 더 작은 모델이 주된 일을 맡아야 합니다. 더 큰 모델은 더 복잡한 생성 작업을 위해 남겨두세요. 그리고 하나의 배치 파이프라인이 여러 모달리티와 모델 유형에 걸쳐 실행된다면, APIMart 같은 단일 계층이 하나의 API를 통해 라우팅을 단순하게 유지할 수 있습니다. 그런 조합이 프로덕션 규모에서 배치 AI 워크플로를 더 예측 가능하게 만듭니다.

FAQ

실시간 AI 호출 대신 배치 처리를 언제 사용해야 하나요?

사용자의 크리티컬 패스에 있지 않고 몇 분에서 몇 시간까지 기다릴 수 있는 작업에는 배치 처리를 사용하세요.

다음과 같은 오프라인 작업에 적합합니다.

• 대규모 데이터 보강

• 문서 분석

• 벡터 인덱스 생성

• 예약된 리포팅

실시간 엔드포인트는 인터랙티브 채팅이나 라이브 Q&A처럼 누군가가 반대편에서 적극적으로 기다리고 있을 때만 사용하세요.

제 워크로드에 맞는 적절한 배치 크기를 어떻게 선택하나요?

애플리케이션 수준 배칭의 경우 50~100개 항목으로 시작하세요. 많은 경우 최적점은 100~500개 사이에 있습니다. 제공업체 네이티브 배치 API를 사용한다면 훨씬 더 크게, 때로는 단일 배치에서 최대 50,000개 요청까지 갈 수 있습니다.

목표는 효율성과 실패 격리 사이의 좋은 트레이드오프를 주는 배치 크기를 찾는 것입니다. 재시도가 너무 비싸지지 않을 만큼 작으면서도, 오케스트레이션 오버헤드를 줄일 만큼 커야 합니다.

동적 추론의 경우, VRAM 제한과 지연 시간 목표에 따라 배치 크기를 튜닝하세요.

재시도 중 중복 처리를 어떻게 방지하나요?

같은 항목을 다시 처리해도 매번 같은 결과가 나오도록 파이프라인을 멱등적으로 만드세요.

안정적이고 불변인 멱등성 키를 사용하세요. 어떤 작업이든 실행하기 전에, 그 키가 이미 점유되었거나 처리되었는지 확인하세요. 그런 다음 중복 쓰기를 방지하기 위해 upsert와 고유 제약을 함께 사용하세요.

처리된 문서 ID의 레지스트리를 유지하는 것도 도움이 됩니다. 그러면 재시도나 재개 실행 중에 이미 완료된 항목을 건너뛰는 간단한 방법이 생깁니다.