Bài 2 — Serverless cho agent: khi nào dùng và cấu hình đúng

Serverless (AWS Lambda, Google Cloud Functions, Cloud Run jobs, Vercel Functions) hấp dẫn vì co giãn về 0 — không request thì không trả tiền. Nhưng nó có bẫy riêng với agent. Bài này giúp bạn quyết định đúng và cấu hình chuẩn.

Khi nào serverless hợp với agent

• Tác vụ ngắn, thường dưới giới hạn timeout (Lambda tối đa 15 phút, nhưng API Gateway đồng bộ chỉ 29 giây).
• Traffic gai và thưa: chạy vài lần/giờ, không đáng để nuôi server 24/7.
• Mỗi lần chạy độc lập, không cần giữ kết nối lâu.

Khi nào KHÔNG nên

• Agent cần streaming token liên tục qua kết nối dài.
• Tác vụ rất dài (> 15 phút) — vượt trần Lambda.
• Cần model/thư viện nặng phải nạp mỗi cold start (ví dụ nạp embedding model 2GB mỗi lần → chậm khủng khiếp).

Bẫy cold start với agent

Mỗi khi function "ngủ dậy", nó phải khởi tạo lại: import thư viện, tạo lại client LLM, có khi nạp lại cấu hình. Với agent, việc tạo lại HTTP client và connection pool mỗi request làm chậm và tốn. Giải pháp: khởi tạo ngoài handler để tái dùng qua các lần warm.

# handler.py — khởi tạo MỘT LẦN ở scope module (được tái dùng khi warm)
import os
from openai import OpenAI

_client = OpenAI(api_key=os.environ["LLM_API_KEY"])  # tái dùng connection

def handler(event, context):
    prompt = event["prompt"]
    # timeout ngắn để không treo trọn function
    resp = _client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
        timeout=20,
    )
    return {"text": resp.choices[0].message.content}

Cấu hình quan trọng (checklist)

• Memory: đặt đủ cao (512MB–1GB+). Trên nhiều nền tảng, memory tỉ lệ với CPU → agent gọi LLM chủ yếu chờ I/O nhưng parsing JSON lớn vẫn cần CPU.
• Timeout: đặt cao hơn p95 một chút, nhưng thấp hơn trần của gateway nếu chạy đồng bộ.
• Concurrency limit: giới hạn số instance song song để không vượt rate limit của LLM (429 hàng loạt).
• Secrets: dùng secret manager, không hardcode API key.
• Provisioned concurrency: nếu cold start đau, giữ vài instance ấm sẵn (trả tiền để đổi độ trễ ổn định).

Ví dụ quyết định

Agent "phân loại email đến" chạy ~4 giây/email, mỗi ngày vài trăm email rải rác. → Serverless đồng bộ hoàn hảo: rẻ, co giãn, không cần server thường trực.

Ngược lại, agent "nghiên cứu sâu" gọi LLM 30 lần trong 8 phút → không nên chạy đồng bộ qua API Gateway. Dùng serverless nhưng theo mô hình queue → worker (Bài 4) hoặc chuyển sang container.

Khung tư duy chọn serverless

p95 < 25s VÀ traffic gai/thưa VÀ không cần streaming dài
   -> Serverless đồng bộ
p95 dài NHƯNG vẫn < 15 phút VÀ chạy nền được
   -> Serverless + Queue (async)
Còn lại -> cân nhắc Container (Bài 3)

Các bước triển khai

• Đóng gói agent thành một handler thuần, không phụ thuộc state cục bộ.
• Đưa mọi khởi tạo nặng ra scope module.
• Đặt timeout function = p95 + biên an toàn, và luôn set timeout cho lời gọi LLM.
• Giới hạn reserved concurrency khớp với hạn mức LLM.
• Test cold start thật (gọi sau khi để nguội) và đo độ trễ.

Sai lầm thường gặp

• Để timeout mặc định 3 giây: agent chưa kịp gọi xong LLM đã bị giết.
• Khởi tạo client trong handler: tạo lại connection mỗi request, chậm và rò tài nguyên.
• Không giới hạn concurrency: 200 instance cùng gọi LLM → 429 đồng loạt, hỏng cả mẻ.
• Nạp model nặng mỗi cold start: nên tách phần nặng sang container hoặc dịch vụ chuyên biệt.
• Chạy tác vụ 5 phút đồng bộ qua API Gateway: bị cắt ở 29 giây dù Lambda cho phép 15 phút.