Ba thế hệ Autoscaling — Và vì sao lưu lượng từ AI Agent phá vỡ tất cả

Lưu lượng truy cập từ các tác nhân AI (agent) đang thay đổi cách chúng ta thiết kế hệ thống backend. Khác với lưu lượng do con người tạo ra — có thể dự đoán và tự giới hạn — lưu lượng từ agent đến theo các đợt bùng nổ không thể lường trước, lặp lại không ngừng và tiêu tốn chi phí rất lớn. Bài viết này phân tích ba thế hệ autoscaling, giải thích vì sao cả hai mô hình thống trị hiện nay đều thất bại trước xu hướng mới, và đề xuất bốn lớp kiến trúc thực tế cần áp dụng từ ngay hôm nay.

Giả định nền tảng đang bị phá vỡ

Mọi khung scaling chúng ta từng xây dựng đều giả định rằng lưu lượng truy cập trông giống cách con người tạo ra nó. Tuy nhiên, so sánh giữa hai loại lưu lượng cho thấy sự khác biệt hoàn toàn:

Tiêu chí	Lưu lượng từ con người	Lưu lượng từ AI Agent
Hình dạng	Đường cong theo ngày, có thể dự đoán. Ngày mai giống hôm nay.	Không có lịch trình. Bùng nổ theo sự kiện điều phối, không theo đồng hồ.
Tốc độ tăng	Tăng dần từ giây đến phút.	Gần như tức thời. Đạt tốc độ tối đa trong mili giây.
Độ tương tranh	Người dùng độc lập, tự động làm mượt theo quy luật số lớn.	Fan-out tương quan từ một trigger duy nhất — không có sự làm mượt thống kê nào.
Retry	Có giới hạn. Người dùng bỏ cuộc hoặc backoff vì bực bội.	Không ngừng nghỉ. Không có ngân sách retry, một lỗi nhỏ biến thành retry storm.
Độ trễ	Dưới giây hoặc người dùng rời đi.	Chấp nhận từ giây đến phút — có thể khai thác độ trễ này.
Chi phí	Số request tỷ lệ thuận với chi phí.	Request và chi phí tách rời. Một chuỗi suy luận nặng có thể tốn hơn hàng nghìn request nhẹ.
Chế độ lỗi	Suy thoái mượt mà — người dùng tự rời đi.	Tự khuếch đại. Vòng lặp rút cạn tài nguyên và trên serverless, tính tiền cho mọi cuộc gọi thừa.

Lưu lượng từ agent vi phạm tất cả bảy giả định này cùng một lúc. Vì vậy, câu trả lời không nằm ở việc tối ưu hóa mô hình hiện có, mà là đặt trí thông minh ở một nơi hoàn toàn khác.

Thế hệ 1: Dự đoán trước (On-demand instances)

Hồi làm việc với hệ thống video streaming phục vụ hàng triệu người xem, việc lập kế hoạch dung lượng hoàn toàn là bài toán của con người. Khi một sự kiện trực tiếp lớn sắp diễn ra, chúng tôi biết chính xác thời điểm đỉnh điểm, độ dốc tăng trưởng và khi nào nó hạ nhiệt. Toàn bộ công việc xoay quanh sự dự đoán: pre-warm các EC2 fleet nhiều ngày trước, thiết lập min/max autoscale bounds, và túc trực trong war room suốt sự kiện.

Thế hệ 1 dựa trên giả định cốt lõi: đỉnh điểm có thể dự báo, do đó hãy cung cấp tài nguyên trước.

Thế hệ 2: Tin tưởng phản ứng (Serverless)

Serverless đã thay đổi cuộc chơi với API Gateway, Lambda, Step Functions — câu chuyện về việc cung cấp tài nguyên gần như biến mất. Bạn ngừng pre-warming và bắt đầu tin tưởng nền tảng tự phản ứng. Mô hình này hoạt động tốt vì lưu lượng vẫn chủ yếu do con người tạo ra: người dùng mở ứng dụng, điều hướng, tương tác và đóng lại. Tốc độ phản ứng của nền tảng đủ nhanh vì sự gia tăng diễn ra dần dần.

Thế hệ 2 dựa trên giả định: bạn không cần dự đoán, vì nền tảng phản ứng nhanh hơn tốc độ tăng trưởng của nhu cầu.

Vì sao máy móc điều phối phá vỡ cả hai mô hình

Việc điều phối phi xác định — các agent tự trị, chuỗi gọi tool đa bước, vòng lặp truy xuất — khiến cả hai mô hình thất bại đồng thời:

• Phá vỡ Thế hệ 1: Không có lịch trình để dự đoán. Bạn không thể pre-warm cho một đỉnh điểm không thể biết trước.
• Phá vỡ Thế hệ 2: Scaling phản ứng là tín hiệu lagging. Lưu lượng agent đạt tốc độ tối đa trong mili giây — khi CPU-based autoscaling kích hoạt, hệ thống đã suy thoái. Tệ hơn, serverless trung thành thực thi mọi cuộc gọi thừa trong một vòng lặp agent mất kiểm soát — và tính tiền bạn cho sự rối loạn đó.

Ba thế hệ autoscaling và những giới hạn

Lớp 1: Scaling dựa trên hành vi

Ngừng scaling dựa trên CPU usage. Đó là tín hiệu lagging — khi nó vượt ngưỡng, một vòng lặp agent đã rút cạn tài nguyên. Tín hiệu bạn cần theo dõi là request velocity và hình dạng dữ liệu. Các request gần như giống hệt nhau từ một caller là dấu hiệu rõ ràng của một vòng lặp agent đang cần kiểm tra — trước khi nó xuất hiện trên chỉ số CPU tổng hợp.

Pattern kiểm tra velocity + diversity của payload để phát hiện caller đang lặp vô hạn và cô lập chúng:

import time
from collections import defaultdict, deque

class AgentLoopDetector:
    def __init__(self, window_s=10, rate_threshold=50, diversity_threshold=0.2):
        self.window_s = window_s
        self.rate_threshold = rate_threshold
        self.diversity_threshold = diversity_threshold
        self.events = defaultdict(deque)

    def is_looping(self, caller_id: str, payload_hash: str) -> bool:
        now = time.monotonic()
        q = self.events[caller_id]
        q.append((now, payload_hash))
        while q and now - q[0][0] > self.window_s:
            q.popleft()
        rate = len(q)
        if rate < self.rate_threshold:
            return False
        unique = len(set(h for _, h in q))
        return (unique / rate) < self.diversity_threshold

Lớp 2: Queue là vũ khí bí mật

Thay vì để client gửi yêu cầu đồng thời, hãy chuyển sang mô hình queue-based: client gửi request vào queue và quay lại poll kết quả. Kiến trúc này giải quyết bài toán bùng nổ tức thời bằng cách cho phép queue hấp thụ đột biến và giải phóng công việc theo tốc độ có kiểm soát. Backpressure 429 với header Retry-After sẽ thông báo cho caller biết cần chậm lại thay vì phải xếp hàng vô hạn.

Lớp 3: Kiểm soát lưu lượng theo token

Thay vì giới hạn số request mỗi phút, hãy chuyển đơn vị kiểm soát sang chi phí tài nguyên. Một token bucket gắn với từng phiên — trừ theo số token hoặc compute thực tế, không phải số lần gọi — cho phép một chuỗi suy luận nặng nề bị cắt ngay lập tức, trong khi các caller nhẹ nhàng vẫn đi qua bình thường:

import time

class SessionTokenBucket:
    def __init__(self, capacity_tokens=100_000, refill_per_s=1_000):
        self.capacity = capacity_tokens
        self.refill = refill_per_s
        self.state = {}

    def _tokens(self, session_id):
        now = time.monotonic()
        avail, last = self.state.get(session_id, (self.capacity, now))
        avail = min(self.capacity, avail + (now - last) * self.refill)
        self.state[session_id] = [avail, now]
        return avail

    def admit(self, session_id, est_tokens) -> bool:
        if self._tokens(session_id) < est_tokens:
            return False
        self.state[session_id][0] -= est_tokens
        return True

Lớp 4: Retry ngân sách và Circuit breaker

Một agent không có ngân sách retry sẽ biến một lỗi tạm thời thành một cơn bão. Cần xây dựng cơ chế circuit breaker phía client, bỏ cuộc sau một số lần thử có chủ đích, và tôn trọng header Retry-After từ máy chủ:

class CircuitBreaker:
    def __init__(self, failure_threshold=5, cooldown_s=30):
        self.failures = 0
        self.breaker_threshold = failure_threshold
        self.cooldown_s = cooldown_s
        self.open_until = 0

    def call(self, fn, retries=5):
        for attempt in range(retries):
            if time.monotonic() < self.open_until:
                raise CircuitOpen("breaker tripped")
            try:
                resp = fn()
            except Exception:
                self.failures += 1
                if self.failures >= self.breaker_threshold:
                    self.open_until = time.monotonic() + self.cooldown_s
                    raise CircuitOpen("breaker tripped")
                delay = 2 ** attempt + random.random()
                time.sleep(delay)
                continue
            self.failures = 0
            return resp
        raise RetryBudgetExhausted("stopped asking")

Bốn lớp kiến trúc cho lưu lượng agent

Điều này dẫn chúng ta đến đâu?

Chúng ta trải qua Thế hệ 1 với việc dự đoán tải. Thế hệ 2 tin tưởng nền tảng tự phản ứng. Thế hệ 3 đòi hỏi điều khó hơn: xây dựng client và hạ tầng đủ thông minh để không tạo ra tải ngay từ đầu. Ngay cả với Thế hệ 1 và 2 cho các tải xác định từ con người, tôi đã thấy những client hoạt động sai gây ra sự cố. Client cần đủ thông minh để hiểu yêu cầu và tôn trọng mọi tín hiệu backpressure.

Nếu bạn đang thiết kế kiến trúc agent hôm nay — điều phối các lời gọi LLM, chạy pipelines truy xuất, để language model lập kế hoạch và hành động — hãy xây dựng ngân sách retry, circuit breaker và cooperative backpressure ngay từ ngày đầu. Đừng để chúng trở thành suy nghĩ muộn màng khi chi phí bắt đầu đội lên.

Valve thông minh nhất không nằm ở cửa ống dẫn. Nó nằm ngay tại nguồn.