Lầm tưởng về serverless rằng "bạn chỉ trả tiền cho số mili giây mã của bạn chạy" sẽ tan biến khi bạn cố gắng chạy một AI agent trên AWS Lambda. Trên thực tế, các khoản mục lớn nhất không phải là chi phí tính toán Lambda mà là độ trễ khởi động lạnh (cold-start), các vòng lặp thử lại và lượng token tiêu thụ do các vòng lặp đó tạo ra.

Tại sao mô hình serverless thông thường gây hiểu lầm cho các AI agent

Hầu hết các nhà phát triển coi một hàm Lambda như một môi trường sandbox tính toán thuần túy: giữ cho handler chạy nhanh, thiết lập kích thước bộ nhớ vừa phải và theo dõi hóa đơn luôn ở mức thấp. Điều đó hiệu quả với các endpoint HTTP đơn giản, nhưng một agent gọi mô hình ngôn ngữ, đánh giá phản hồi và có thể thử lại toàn bộ chu kỳ thì không tương ứng theo tỷ lệ 1:1 với một lần gọi Lambda duy nhất. Quy trình làm việc nội bộ của agent làm nhân số lượng các lần gọi mô hình, và mỗi lần gọi thêm sẽ làm tăng chi phí token, thứ có thể vượt xa cả chi phí tính toán.

Khởi động lạnh là chi phí ẩn

Khi một container Lambda được cấp phát lần đầu, nó phải giải nén gói triển khai. Agent đang xét sử dụng một tập hợp lớn các thư viện Python, vì vậy image có thể khá lớn. Việc loại bỏ các công cụ chỉ dùng cho phát triển—chẳng hạn như thư viện tự động hóa trình duyệt chỉ dùng để kiểm thử cục bộ—sẽ giúp giảm kích thước image, từ đó rút ngắn thời gian giải nén. Một gói gọn nhẹ hơn đồng nghĩa với việc hàm sẽ sẵn sàng xử lý yêu cầu nhanh hơn, giảm thời gian chờ container khởi động (warm up).

Một đòn bẩy thứ hai là nơi đặt mã khởi tạo. Bằng cách xây dựng đồ thị (graph) của agent tại thời điểm import module, các tác vụ nặng sẽ chỉ diễn ra một lần mỗi khi container khởi động thay vì diễn ra trong mỗi yêu cầu. Các lần gọi sau đó (warm invocations) sẽ bỏ qua hoàn toàn công việc này. Sự đánh đổi là thời gian khởi động lạnh lâu hơn một chút, nhưng bù lại là thời gian thiết lập cho mỗi yêu cầu gần như bằng không sau khi container đã ấm (warm).

Bộ nhớ đóng vai trò như một núm điều chỉnh độ trễ

Trên Lambda, lượng bộ nhớ bạn cấp phát cũng quyết định tỷ lệ CPU mà hàm nhận được. Thiết lập hàm với 1 GB bộ nhớ sẽ cấp cho nó một lõi CPU ảo đầy đủ. CPU bổ sung giúp tăng tốc việc import các thư viện và tạo đồ thị agent, làm giảm cả độ trễ khởi động lạnh và độ trễ khởi động (warm-up).

Chi phí vòng lặp: các lần thử lại làm nhân mức tiêu thụ token

Agent tuân theo một vòng lặp worker-evaluator (người thực hiện - người đánh giá). Worker tạo ra phản hồi, evaluator kiểm tra nó, và nếu evaluator phát hiện lỗi, tác vụ sẽ được gửi ngược lại cho worker. Vòng lặp có thể lặp lại tới năm lần trước khi dừng lại. Điều đó có nghĩa là một yêu cầu bên ngoài duy nhất có thể kích hoạt:

  • tối đa năm lần gọi mô hình worker
  • tối đa năm lần gọi mô hình evaluator
  • bất kỳ số lượng cuộc gọi công cụ nào mà agent quyết định thực hiện

Hóa đơn Lambda vẫn có thể dự đoán được vì AWS tính phí theo mili giây thực thi, nhưng hóa đơn token có thể biến động dữ dội tùy thuộc vào số lần thử lại cần thiết.

Bẫy timeout: API Gateway so với Lambda

API Gateway áp đặt một giới hạn timeout cứng 29 giây đối với yêu cầu HTTP mà nó quản lý. Một vòng lặp agent gồm năm lượt có thể dễ dàng vượt quá giới hạn đó, ngay cả khi hàm Lambda bên dưới được cấu hình cho cửa sổ thực thi kéo dài năm phút. Việc bỏ qua API Gateway bằng cách sử dụng Lambda Function URLs sẽ loại bỏ giới hạn 29 giây, cho phép hàm hoàn thành vòng lặp của mình mà không bị ngắt quãng.

Những gì nhà phát triển nên lập ngân sách

Bài học rất đơn giản: lập ngân sách cho một AI agent serverless đòi hỏi nhiều hơn là chỉ cộng dồn số mili giây thời gian chạy Lambda. Bạn cần tính đến:

  • kích thước của gói triển khai và độ trễ khởi động lạnh tương ứng
  • thiết lập bộ nhớ quyết định CPU và từ đó là tốc độ import
  • số lần thử lại dự kiến trong vòng lặp worker-evaluator, yếu tố trực tiếp thúc đẩy việc sử dụng token
  • lựa chọn front-end (API Gateway so với Function URL) để tránh tình trạng timeout sớm

Bỏ qua bất kỳ biến số nào trong số này có thể khiến bạn nhận được một hóa đơn khác xa so với dự tính ban đầu.