Amazon SageMaker AI Async Inference now supports inline request payloads

🖼️ 인포그래픽

Amazon SageMaker AI Async Inference now supports inline request payloads 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon SageMaker AI Async Inference가 InvokeEndpointAsync 요청 본문에 최대 128,000바이트 payload를 직접 담는 Body 파라미터를 지원해, 작은 입력에 대해 매번 S3에 업로드하던 단계를 없앴습니다.

📌 핵심 요약

이번 업데이트의 핵심은 Amazon SageMaker AI Async Inference에서 InvokeEndpointAsync API 호출 시 입력 payload를 Body 파라미터로 직접 전달할 수 있게 된 점입니다.
기존에는 비동기 추론 요청마다 입력 데이터를 S3 버킷에 업로드한 뒤, 해당 객체 URI를 InputLocation으로 전달해야 했습니다.
새 방식은 최대 128,000바이트의 원시 payload에 적용되며, Body와 InputLocation은 동시에 사용할 수 없고 위반 시 동기 ValidationError가 반환됩니다.
출력 동작은 기존과 동일하게 S3 OutputLocation에 결과가 기록되며, 기존 endpoint나 model container 변경은 필요하지 않은 것으로 설명됩니다.
작은 JSON prompt나 구조화 데이터에는 Body가 단순하고 비용·지연·운영 부담을 줄이는 선택지이며, 큰 파일이나 입력 보존이 필요한 경우에는 기존 InputLocation 방식이 계속 적합합니다.

🧩 주요 포인트

이번 업데이트의 핵심은 Amazon SageMaker AI Async Inference에서 InvokeEndpointAsync API 호출 시 입력 payload를 Body 파라미터로 직접 전달할 수 있게 된 점입니다.
기존에는 비동기 추론 요청마다 입력 데이터를 S3 버킷에 업로드한 뒤, 해당 객체 URI를 InputLocation으로 전달해야 했습니다.
새 방식은 최대 128,000바이트의 원시 payload에 적용되며, Body와 InputLocation은 동시에 사용할 수 없고 위반 시 동기 ValidationError가 반환됩니다.
출력 동작은 기존과 동일하게 S3 OutputLocation에 결과가 기록되며, 기존 endpoint나 model container 변경은 필요하지 않은 것으로 설명됩니다.
작은 JSON prompt나 구조화 데이터에는 Body가 단순하고 비용·지연·운영 부담을 줄이는 선택지이며, 큰 파일이나 입력 보존이 필요한 경우에는 기존 InputLocation 방식이 계속 적합합니다.

🧠 상세 정리

1. 기존 비동기 추론 흐름의 구조와 한계

원문은 먼저 Amazon SageMaker AI Async Inference가 요청을 queue에 넣고 비동기로 처리하는 방식이라는 배경을 설명합니다. 이 방식은 큰 payload, traffic 변동, seconds-to-minutes 수준의 지연을 허용하는 workload에 적합하며, 자동 scale-to-zero를 통해 bursty 또는 batch-style workload에서 비용 효율을 얻을 수 있습니다. 하지만 기존 invocation은 항상 입력 payload를 S3 bucket에 업로드하고, 그 S3 object URI를 InputLocation으로 넘기는 두 단계가 필요했습니다. 이미지, 오디오, multi-MB document처럼 큰 입력에는 이 구조가 잘 맞지만, KB 단위의 작은 입력을 긴 처리 시간 때문에 비동기로 보내야 하는 고객에게는 S3 의존성이 불필요한 복잡도로 작용했습니다.

2. 새 기능: Body 파라미터를 통한 인라인 payload

새로 도입된 기능은 InvokeEndpointAsync API가 Body 파라미터를 받아 payload를 요청 자체에 포함하도록 하는 것입니다. Body는 raw bytes 형태이며 최대 크기는 128,000바이트로 제한됩니다. Body가 제공되면 입력 데이터를 별도로 S3에 먼저 올릴 필요가 없고, 요청은 API 호출 한 번으로 endpoint에 전달됩니다. 다만 Body와 InputLocation은 상호 배타적이어서 두 값을 동시에 설정하면 API가 요청을 거부합니다. 결과 출력은 바뀌지 않으며, inference 결과는 여전히 configured S3 OutputLocation에 기록됩니다.

3. Before와 After 코드가 보여주는 사용자 경험 변화

기존 예시는 boto3의 S3 client와 sagemaker-runtime client를 모두 만들고, JSON payload를 만든 뒤 UUID 기반 key로 S3에 put_object를 수행하는 흐름을 보여줍니다. 그런 다음 s3://my-async-bucket/... 형태의 input_location을 만들어 invoke_endpoint_async 호출의 InputLocation으로 전달합니다. 이 방식은 input bucket provision, caller의 s3:PutObject 권한, key collision을 피하기 위한 naming scheme, 오래된 input object cleanup 전략을 요구합니다. 새 예시는 S3 client와 uuid 없이 sagemaker-runtime client만 사용하고, 같은 payload를 Body=payload로 직접 전달합니다. 따라서 입력 업로드 단계와 그에 딸린 IAM grant, bucket 관리, stale object 정리 부담이 사라집니다.

4. 고객에게 제시된 다섯 가지 이점

원문은 inline payload가 각 요청에서 network hop 하나와 S3 dependency 하나를 제거한다고 설명합니다. 첫째, 요청마다 S3 PUT과 별도 왕복이 없어져 latency가 줄고, fan-out workload에서는 이 절감 효과가 누적될 수 있습니다. 둘째, input bucket provisioning, lifecycle policy, cross-account access pattern, caller의 input path에 대한 s3:PutObject 권한 같은 설계 요소를 피할 수 있어 architecture가 단순해집니다. 셋째, 요청이 단일 API call로 줄어 enqueue 여부가 명확해져 error path가 감소합니다. 넷째, inline invocation마다 input upload에 대한 S3 PUT charge가 제거되며, 다섯째로 size 위반이나 Body와 InputLocation 동시 지정 같은 오류를 동기 validation feedback으로 받을 수 있습니다.

5. Body와 InputLocation을 선택하는 기준

원문은 inline payload가 작은 입력에는 더 단순한 선택이지만, InputLocation이 여전히 필요한 경우가 있다고 구분합니다. payload가 128,000바이트 이하인 JSON prompt나 structured data라면 Body를 사용해 network round-trip과 S3 PUT charge를 피하는 것이 권장됩니다. 반대로 payload가 128,000바이트를 넘는 이미지, 오디오, 큰 문서라면 먼저 S3에 업로드하고 InputLocation을 전달해야 합니다. payload 크기가 섞인 mixed workload에서는 size에 따라 작은 것은 Body, 큰 것은 InputLocation으로 분기하는 방식을 제시합니다. 또한 audit이나 replay 목적으로 input data를 S3에 보존해야 하는 경우에는 기존 InputLocation 방식이 적합합니다.

6. 도입 절차, 정리, 호환성

사용을 시작하려면 기존 Amazon SageMaker AI Async Inference endpoint가 있는지 확인하고, 최신 AWS SDK for Python인 Boto3를 설치 또는 upgrade해야 합니다. 필요한 권한은 sagemaker:InvokeEndpointAsync이며, async endpoint에는 결과를 받을 S3 output bucket이 configured되어 있어야 합니다. 적용 단계는 SDK update, 기존 S3 upload plus InputLocation pattern을 Body parameter로 교체, Body로 InvokeEndpointAsync를 호출해 테스트, response에 OutputLocation이 있는지 확인, 해당 S3 OutputLocation에서 결과가 성공적으로 기록됐는지 poll 또는 monitor하는 순서입니다. endpoint configuration, model container, output S3 setup에는 변경이 필요 없다고 설명됩니다. 테스트용 endpoint나 output bucket을 만들었다면 ongoing charge를 피하기 위해 endpoint 삭제, 필요 없는 bucket 삭제, tutorial용 IAM policy 제거 같은 cleanup도 안내됩니다.

🧾 핵심 주장 / 시사점

이번 기능의 실질적 가치는 비동기 추론 자체를 바꾸는 것이 아니라, 작은 입력에 대해 필수였던 S3 입력 업로드 단계를 제거해 client code와 운영 경로를 줄이는 데 있습니다.
출력은 계속 S3 OutputLocation을 사용하므로, inline payload는 입력 경로를 단순화하는 기능이지 전체 비동기 결과 전달 모델을 바꾸는 기능은 아닙니다.
기존 InputLocation workflow가 그대로 유지되고 request acceptance 이후 inline 입력과 S3 입력이 동일하게 처리된다는 점은, 기존 endpoint와 model container를 크게 손대지 않고 점진적으로 적용할 수 있음을 의미합니다.

✅ 액션 아이템

InvokeEndpointAsync에서 작은 JSON·구조화 입력은 Body 파라미터 방식으로 전환해 매번 S3 업로드 단계를 줄인다.
Body 사용 시 InputLocation을 함께 쓰지 않도록 파이프라인을 제한하고, 위반 시 동기 ValidationError를 즉시 감지한다.
큰 파일 처리나 입력 보존이 필요한 워크로드는 기존 InputLocation 업로드 흐름을 유지해 처리 성격에 맞는 분기 기준을 둔다.