Async inference: bớt một vòng S3

Async inference: bớt một vòng S3

Inline payload trong SageMaker Async Inference không phải tin để hô hào đổi kiến trúc. Nó là dịp dọn lại đường đi của request nhỏ nhưng xử lý lâu.

Bạn đã bao giờ debug một job AI mất 40 giây chạy model, nhưng mất thêm cả đống thời gian chỉ để biết… payload đang nằm ở đâu chưa?

Mình gặp kiểu workflow này khá nhiều ở team làm AI nội bộ: client tạo input nhỏ xíu, upload lên S3, lấy URI, gọi async endpoint, endpoint đọc lại S3, xử lý, ghi output về S3, rồi client poll hoặc nhận notification. Nhìn trên sơ đồ thì sạch sẽ. Vào vận hành thì mỗi request giống một chiếc lá phải đi vòng qua cả tầng tán rừng trước khi chạm đất.

Tin mới đáng chú ý: Amazon SageMaker AI Async Inference giờ hỗ trợ inline request payload — tức là gửi payload trực tiếp trong body của InvokeEndpointAsync, với giới hạn tối đa 128.000 bytes. Không cần upload input lên Amazon S3 trước mỗi lần gọi nếu payload đủ nhỏ.

Luận điểm của mình: đây không phải tính năng làm model thông minh hơn; đây là tín hiệu để builder tách rõ “đường dữ liệu” khỏi “đường vận hành”. Và nếu team bạn đang chạy async inference cho input nhỏ, thay đổi này có thể đáng thử hơn một đợt đổi model ồn ào.

Sơ đồ minh họa cho bài Async inference: bớt một vòng S3

Sơ đồ tóm tắt ý chính của bài viết.

Chuyện đang diễn ra: tối ưu inference không còn nằm ở model

Mấy release gần đây của AWS xoay quanh một ý khá nhất quán: bottleneck production AI thường không nằm ở một chỗ duy nhất.

Các mảnh này không cùng một tầng. Có cái ở request path, có cái ở scale-out, có cái ở decoding, có cái ở context. Trong một hệ sinh thái inference, mỗi tầng có loài bản địa riêng: payload nhỏ, container lớn, model nặng, context rải rác, agent gọi tool liên tục. Ép tất cả vào một metric duy nhất là tự làm mình mù.

Mổ xẻ: inline payload sửa đúng một vết xước, không sửa cả khu rừng

Trước đây, với SageMaker Async Inference, pattern phổ biến là:

  1. Upload input payload lên S3.
  2. Gọi async endpoint, truyền InputLocation là URI của object.
  3. Endpoint xử lý và ghi output về S3 output location.
  4. Client poll kết quả hoặc nhận thông báo qua SNS.

Pattern này hợp lý nếu input là ảnh lớn, audio, video, tài liệu nhiều MB. S3 lúc đó là nơi trung chuyển đáng tin: lưu được payload lớn, dễ audit, dễ retry, dễ tách producer và consumer.

Nhưng nếu input của bạn chỉ là vài KB JSON, ví dụ một request phân loại ticket, tạo summary cho một đoạn text ngắn, hoặc agent cần chạy một bước phân tích dài hơn real-time timeout, thì bắt buộc upload S3 trước mỗi invocation hơi giống dựng cả đường mòn chỉ để đi qua một bụi cây.

Với inline payload, request có thể đi thẳng:

import boto3
import json

runtime = boto3.client("sagemaker-runtime")

payload = {
    "ticket_id": "TCK-123",
    "customer_text": "Khách báo lỗi thanh toán bị treo sau khi quét QR",
    "priority_hint": "normal"
}

response = runtime.invoke_endpoint_async(
    EndpointName="my-async-endpoint",
    ContentType="application/json",
    Body=json.dumps(payload).encode("utf-8")
)

print(response)

Điểm đáng giá không chỉ là ít code hơn. Nó là ít state tạm hơn: bớt object input trong S3, bớt IAM permission cho upload input, bớt lifecycle policy phải nghĩ, bớt case “client upload xong nhưng invoke fail thì object rác nằm lại”.

Nhưng đừng hiểu nhầm: S3 chưa hề biến mất khỏi async inference. Output vẫn thường đi về S3 theo cấu hình endpoint. Và với input lớn, S3 vẫn là đường đúng.

Framework quyết định: nhỏ, lâu, hay cần truy vết?

Nếu là tech lead, mình sẽ không hỏi “có nên dùng inline payload không?”. Câu hỏi tốt hơn là: request này cần đi qua S3 vì lý do kỹ thuật, hay chỉ vì lịch sử kiến trúc để lại?

Bạn có thể dùng khung 3 trục này:

| Trục quyết định | Inline payload hợp khi | S3 input hợp khi |
|---|---|---|
| Kích thước input | Payload dưới 128.000 bytes | Payload lớn, file nhị phân, multi-MB |
| Độ phức tạp vận hành | Muốn giảm bước upload và state tạm | Cần lưu input độc lập để replay/audit |
| Kiểu workload | Input nhỏ nhưng xử lý lâu, không cần real-time | Batch, media, document pipeline lớn |

Hình dung thế này: team bạn có endpoint async để chấm mức độ ưu tiên của ticket hỗ trợ. Input gồm ticket_id, nội dung ticket, vài metadata. Model có thể mất vài chục giây vì prompt dài hoặc gọi thêm tool nội bộ, nhưng input ban đầu chỉ vài KB. Trường hợp này inline payload đáng thử.

Ngược lại, nếu bạn xử lý ảnh bảo hiểm, audio call center, PDF hợp đồng, hoặc cần lưu nguyên input để phục vụ compliance, đừng cố nhét mọi thứ vào body. S3 ở đây không phải gánh nặng, mà là lớp lưu trữ có chủ đích.

Việc thử trong một buổi: đo đường đi, không đo cảm giác

Một buổi chiều là đủ để kiểm tra tính năng này có đáng đưa vào backlog hay không. Đừng refactor cả pipeline ngay.

Bước 1: Chọn một endpoint async đang có input nhỏ

Lọc log hoặc sample request. Chỉ chọn workload mà serialized payload chắc chắn dưới 128.000 bytes. Nếu payload có lúc nhỏ lúc lớn, tách hai path ngay từ đầu.

Bước 2: Viết client kép

Giữ path cũ dùng S3. Thêm path mới dùng Body. Hai path cùng gọi một endpoint, cùng content type, cùng timeout policy nếu có.

def invoke_async_inline(endpoint_name: str, payload: dict):
    body = json.dumps(payload).encode("utf-8")

    if len(body) > 128_000:
        raise ValueError("Payload vượt giới hạn inline, dùng S3 path")

    return runtime.invoke_endpoint_async(
        EndpointName=endpoint_name,
        ContentType="application/json",
        Body=body
    )

Bước 3: Đo 4 thứ rất đời thường

Không cần dashboard hoành tráng. Một bảng log cũng được:

Ở đây, latency của model chưa chắc giảm mạnh, vì inference vẫn chạy async như cũ. Thứ bạn đang đo là độ rườm rà trước khi request vào hàng đợi.

Bước 4: Đặt tiêu chí dừng trước khi mê tay

Dừng thử nếu gặp một trong các dấu hiệu:

Nếu phải bẻ cong dữ liệu để vừa tính năng, bạn đang tối ưu nhầm tầng.

Điều đáng giữ: ít bề mặt vận hành hơn

Điểm mình thích ở inline payload là nó giảm operational surface area — bề mặt vận hành, tức là số thứ có thể hỏng, lệch quyền, rò lifecycle, hoặc tạo chi phí phụ.

Với team Việt Nam quy mô nhỏ, đây là chuyện rất thật. Không phải team nào cũng có một người chuyên ngồi dọn S3 bucket, IAM policy, retry queue, object lifecycle, và trace correlation. Bớt một network round-trip không chỉ là bớt thời gian; đôi khi là bớt một lớp “ai chịu trách nhiệm cái này?” trong cuộc họp sự cố.

Tuy vậy, inline payload chỉ là một nhánh trong tán cây latency. Nếu pain chính của bạn là scale-out chậm vì container image lớn, hãy nhìn container caching. Nếu pain nằm ở token generation chậm, speculative decoding kiểu P-EAGLE mới là lớp đáng nghiên cứu. Nếu agent trả lời sai vì thiếu quan hệ dữ liệu, inline payload không cứu được; bạn phải xử lý context layer.

Điều nên bỏ qua: đổi kiến trúc vì release mới

Release mới rất dễ tạo cảm giác “không dùng là tụt hậu”. Nhưng builder giỏi không chạy theo tính năng; builder giỏi biết tính năng đó thay đổi quyết định nào.

Với inline payload, quyết định thay đổi là:

Với input nhỏ và xử lý async, S3 không còn là bước bắt buộc ở đầu vào. Nó trở thành lựa chọn có điều kiện.

Câu này nghe khô, nhưng đáng tiền. Nó giúp bạn thiết kế request path theo workload thay vì theo thói quen.

Nếu team bạn đang có cả agent, RAG, async jobs, batch media, và coding assistant nội bộ, đừng gom hết vào một pipeline. Hãy để workload nhỏ đi đường nhỏ, workload lớn đi đường lớn, còn workload cần audit thì đi đường có dấu vết rõ ràng.

Sau bài này, mình muốn bạn đổi cách nghĩ ở một điểm: đừng hỏi “tính năng mới có nhanh hơn không”, hãy hỏi “nó gỡ được lớp vận hành nào mà team mình đang trả tiền mỗi ngày?”

Còn nếu một payload vài KB mà vẫn phải đi du lịch qua S3 trước khi vào queue, thì cũng được thôi — chỉ là chiếc lá hơi thích trekking.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo