Amazon Bedrock은 온디맨드 토큰 가격의 50%로 배치 추론을 실행하며, 여러분이 포기하는 유일한 것은 즉시성뿐이다. 요청 파일을 제출하면 여유 용량이 있을 때 작업이 비동기로 실행되고, 결과는 나중에 수거하면 된다. 사람이 앉아서 응답을 기다리지 않는 워크로드라면, 아무도 필요로 하지 않은 속도를 위해 실시간 추론에 정가를 지불하는 것은 청구서의 절반을 그냥 테이블 위에 남겨 두는 것과 같다.

흔한 실수는 첫 프로토타입이 그렇게 작성되었다는 이유만으로 모든 모델 호출을 동기식 실시간 경로로 기본 설정하는 것이다. 인터랙티브 채팅은 실시간이어야 한다. 어제의 지원 티켓을 분류하는 야간 작업은 그럴 필요가 없다. 이 둘은 서로 다른 지연 시간 요구사항이고, Bedrock은 이를 다르게 가격 매긴다. 엔지니어링 질문은 단순히 어떤 워크로드가 지금 당장 답을 필요로 하고, 어떤 워크로드가 언젠가만 답을 필요로 하는지 가려내는 것이다.

Bedrock에서 배치가 작동하는 방식

배치 추론은 호출이 아니라 작업(job)이다. 흐름은 의도적으로 단순하다.

1. write requests as JSONL to S3   (one record per line)
2. create a batch inference job     (input S3 -> output S3)
3. job runs asynchronously          (minutes to hours)
4. read results from the output S3 prefix

각 입력 레코드는 레코드 ID와 실시간으로 보낼 때와 동일한 모델 입력을 담는다. 결과는 S3에 다시 기록되며, 입력마다 하나씩, 그 레코드 ID로 키가 매겨져 결과를 입력과 조인할 수 있다. 유지해야 할 웜 엔드포인트도, 튜닝할 동시성도, 잡아내야 할 스로틀링도 없다. 요청-응답 루프를 제출-수거 루프로 바꾸는 대신, 작업이 여러분의 일정이 아니라 서비스의 일정에 맞춰 끝난다는 것을 받아들이는 대가로 할인된 요율을 얻는다.

지연 시간이 정말로 중요하지 않은 곳

이 방식에 맞는 워크로드는 결과가 화면 앞에서 기다리는 사람이 아니라 어떤 프로세스로 흘러 들어가는 것들이다.

  • 대량 분류 및 태깅. 밀린 문서, 티켓, 상품을 분류한다. 답은 사용자 앞이 아니라 데이터베이스에 안착한다.
  • 보강 파이프라인. 요약, 추출, 임베딩을 미리 생성해서 저장해 두면, 실시간 경로는 그저 사전 계산된 값을 읽기만 하면 된다.
  • 오프라인 평가. 수천 개의 테스트 케이스에 걸쳐 모델이나 프롬프트 변경을 채점하는 작업이다. 보고서이며, 보고서는 한 시간 정도 기다려도 된다.
  • 정기 보고. 일정에 따라 실행되어 사람이 나중에 읽는 출력을 만드는 모든 작업이다. 즉시가 아니라도 상관없다.

공통 실마리는 마감이 시간 단위로 측정되고, 물량이 토큰 가격을 반으로 줄이는 것이 반올림 오차가 아니라 실제 돈이 될 만큼 충분히 크다는 것이다.

비용 계산

종이 위에 적어 보면 이 거래는 극명하다. 각각 고정된 평균 토큰 비용을 갖는 백만 건의 레코드로 이루어진 작업을 예로 들어 보자.

Real-time path:
  1,000,000 requests x on-demand token price
  + endpoint kept responsive
  + throttling handling under load

Batch path:
  1,000,000 records x (0.5 x on-demand token price)
  + S3 storage (negligible)
  + the willingness to wait

배치 열이 토큰 청구서의 절반이면서 운영 부담도 더 적다. 급증으로부터 보호해야 할 살아 있는 엔드포인트가 없기 때문이다. 손익분기점은 물량이 아니라 마감에 관한 것이다. 답을 기다릴 수 있다면 배치가 비용과 단순함 모두에서 이긴다. 기다릴 수 없다면 어떤 할인도 비동기 작업을 받아들일 만하게 만들지 못한다.

배치가 잘못된 도구일 때

맞지 않는 곳에 억지로 끼워 맞추지 마라. 사용자가 출력을 기다리고 있을 때, 한 요청이 이전 요청의 결과에 의존할 때, 혹은 작업이 너무 작아서 할인이 미미하고 비동기 배관이 그만한 가치가 없을 때 배치는 잘못된 선택이다. 스로틀링 회피 수단으로 쓰는 것도 잘못이다. 실시간 트래픽이 스로틀링되고 있다면 해법은 용량 계획과 프롬프트 캐싱이지, 인터랙티브 요청을 몇 시간 뒤에 결과가 나오는 작업으로 밀어 넣는 것이 아니다. 배치는 애초에 미룰 예정이었던 작업을 위한 것이지, 지연 시간 문제를 숨기기 위한 것이 아니다.

결론

큰 토큰 청구서의 절반은 이미 대부분의 팀이 가지고 있는 아키텍처만으로 얻을 가치가 있다. S3에 쓰고, 작업을 제출하고, 나중에 결과를 읽는다. 이 할인은 영리한 것이 아니라 온디맨드 용량 대신 지연된 용량에 대한 값을 치르는 것일 뿐이다. 모델 호출들을 감사해서 누가 기다리고 있는지에 따라 분류하라. 반대편에 사람이 있는 모든 것은 실시간으로 남겨 두라. 나머지, 즉 파이프라인을 먹이는 분류, 보강, 평가, 보고 같은 사람이 아닌 것들은 50% 할인된 배치 작업으로 보내라. 절감액은 여러분이 한 번도 의문을 품지 않았던 워크로드 안에 그대로 놓여 있다.

다음으로 읽을 글

AWS 전반의 더 폭넓은 비용 최적화 및 파이프라인 플레이북은 ercan.cloud의 클라우드 필드 노트에서, 허브는 ercanermis.com에서 확인할 수 있다.