Bài 6 — Scaling agent: throughput, rate limit và chi phí LLM

Agent scale khác web app: nút thắt thường không phải CPU của bạn mà là rate limit và chi phí của LLM. Thêm 100 worker không giúp gì nếu LLM chỉ cho 500 request/phút. Bài này chỉ cách scale agent thông minh.

Nút thắt thật của agent

• Rate limit của LLM: RPM (requests/phút) và TPM (tokens/phút). Vượt là 429 hàng loạt.
• Chi phí token: scale bừa = hóa đơn nổ.
• Dịch vụ tool bên ngoài: vector DB, search API cũng có giới hạn riêng.
• Kết nối DB: nhiều worker mở quá nhiều connection có thể sập DB.

CPU/RAM của bạn thường là nút thắt cuối cùng, không phải đầu tiên.

Nguyên tắc: scale bị giới hạn bởi mắt xích yếu nhất

Nếu LLM cho 600 RPM và mỗi lượt agent gọi trung bình 6 lần LLM, thì trần thực tế ≈ 100 lượt agent/phút. Thêm worker vượt mức đó chỉ tạo ra 429, không tạo throughput.

Bốn kỹ thuật scale agent

1. Concurrency control (điều tiết)

Đặt số worker song song sao cho tổng RPM ≤ hạn mức LLM. Dùng semaphore/token bucket để giữ nhịp.

import asyncio
sem = asyncio.Semaphore(20)   # tối đa 20 lời gọi LLM song song

async def call_llm(prompt):
    async with sem:           # vượt 20 sẽ xếp hàng chờ, không dội 429
        return await client.chat(prompt)

2. Backpressure (đẩy áp lực ngược)

Khi queue quá sâu, đừng nhận thêm bừa. Cho API trả "đang bận, thử lại sau" thay vì phình queue vô hạn rồi timeout hàng loạt.

3. Caching

• Prompt/response cache: câu hỏi giống hệt → trả lại kết quả cũ, khỏi gọi LLM.
• Semantic cache: câu hỏi gần giống → tái dùng.
• Prompt caching của nhà cung cấp: cache phần system prompt/ngữ cảnh dài để giảm token tính tiền.

4. Chọn model theo tác vụ (routing)

Không phải bước nào cũng cần model đắt nhất. Dùng model nhỏ/rẻ cho phân loại, model lớn cho suy luận khó. Tiết kiệm token đáng kể.

Xử lý 429 đúng cách

Khi gặp 429, đọc header Retry-After nếu có, chờ đúng khoảng đó rồi thử lại với backoff + jitter (thêm nhiễu ngẫu nhiên để tránh mọi worker retry cùng lúc tạo "thundering herd").

import random, time
def with_retry(fn, max_tries=5):
    for i in range(max_tries):
        try:
            return fn()
        except RateLimited as e:
            wait = (2 ** i) + random.uniform(0, 1)  # backoff + jitter
            time.sleep(e.retry_after or wait)
    raise

Khung tư duy scale

1. Tìm mắt xích yếu nhất (thường là LLM RPM/TPM).
2. Đặt concurrency khớp trần đó.
3. Giảm tải bằng cache + model routing.
4. Backpressure khi quá tải, không phình vô hạn.
5. Chỉ tăng worker sau khi nới được trần LLM.

Các bước triển khai

• Tra hạn mức RPM/TPM của LLM và tool đang dùng.
• Ước tính số lời gọi LLM trung bình mỗi lượt agent.
• Tính trần throughput và đặt concurrency limit khớp.
• Thêm cache cho phần lặp lại; route model theo độ khó.
• Cài retry backoff + jitter, tôn trọng Retry-After.
• Bật backpressure ở API khi queue vượt ngưỡng.
• Theo dõi chi phí token theo ngày, đặt cảnh báo ngân sách.

Sai lầm thường gặp

• Scale worker mà không nới rate limit LLM: chỉ tạo thêm 429, không thêm throughput.
• Retry đồng loạt không jitter: thundering herd làm LLM càng nghẽn.
• Không cache: trả tiền lặp cho cùng một câu hỏi.
• Dùng model đắt cho mọi bước: hóa đơn phình vô ích.
• Queue phình vô hạn: cuối cùng mọi job đều timeout, tệ hơn là từ chối sớm.
• Quên connection pool DB: nhiều worker làm cạn kết nối, sập DB trước cả LLM.