Bài 6 — Kiểm soát token & chi phí: ngân sách, vòng lặp và tối ưu

Một agent an toàn nhưng đốt $5.000/ngày vẫn là agent thất bại. Chi phí LLM tỉ lệ với token, và agent có xu hướng phình token (context tích lũy, retry, vòng lặp). Bài này xây cơ chế kiểm soát chi phí thực dụng.

Chi phí đến từ đâu?

• Context phình to: mỗi bước, agent nhồi thêm lịch sử + kết quả tool → prompt dài dần, mỗi lần gọi đắt hơn.
• Số bước (loop): agent lặp gọi tool nhiều vòng; vòng lặp hỏng có thể chạy vô hạn.
• Model đắt cho việc rẻ: dùng model mạnh nhất cho mọi bước, kể cả phân loại đơn giản.
• Retry không kiểm soát: lỗi → thử lại → nhân đôi chi phí.

Ước tính chi phí một request

PRICE = {  # USD / 1K token (ví dụ minh họa)
    "big":   {"in": 0.003,  "out": 0.015},
    "small": {"in": 0.0003, "out": 0.0015},
}

def cost(model, tok_in, tok_out):
    p = PRICE[model]
    return (tok_in/1000)*p["in"] + (tok_out/1000)*p["out"]

# Agent 8 bước, mỗi bước ~4K in / 500 out trên model "big":
per_step = cost("big", 4000, 500)      # ~0.0195 USD
print(per_step * 8)                    # ~0.156 USD / request
# 10.000 request/ngày ≈ 1.560 USD/ngày → cần tối ưu!

Budget guard: ngân sách theo request và theo ngày

class BudgetGuard:
    def __init__(self, max_tokens_req, max_steps, max_usd_day):
        self.max_tokens_req = max_tokens_req
        self.max_steps = max_steps
        self.max_usd_day = max_usd_day
        self.tokens = 0; self.steps = 0

    def before_step(self, projected_tokens, spent_today):
        self.steps += 1
        if self.steps > self.max_steps:
            raise BudgetError("Vượt số bước tối đa — nghi vòng lặp")
        if self.tokens + projected_tokens > self.max_tokens_req:
            raise BudgetError("Vượt token/request")
        if spent_today > self.max_usd_day:
            raise BudgetError("Vượt ngân sách ngày — chuyển sang chờ/hàng đợi")

    def after_step(self, used_tokens):
        self.tokens += used_tokens

max_steps là "cầu dao" chống vòng lặp vô hạn — bắt buộc phải có.

Bảy đòn tối ưu chi phí

• Model routing: dùng model nhỏ cho phân loại/định tuyến, model lớn chỉ cho bước khó. Có thể cắt 60-80% chi phí.
• Giới hạn số bước (max_steps) + phát hiện lặp (state không đổi 2 vòng → dừng).
• Cắt/nén context: tóm tắt lịch sử cũ thay vì nhồi nguyên văn; chỉ giữ kết quả tool cần thiết.
• Prompt caching: cache phần system prompt/tài liệu tĩnh để không trả tiền lặp lại phần đầu vào cố định.
• Giới hạn max_tokens đầu ra: đừng để model viết 2.000 token khi cần 100.
• Cache kết quả: câu hỏi/công cụ lặp lại → trả từ cache thay vì gọi lại model/tool.
• Ngân sách phân tầng: limit theo request, theo user, theo ngày; vượt thì hạ cấp model hoặc xếp hàng.

Checklist kiểm soát chi phí

• [ ] Có max_steps (cầu dao vòng lặp) chưa?
• [ ] Có max_tokens cho cả input tích lũy lẫn output chưa?
• [ ] Có định tuyến model nhỏ/lớn theo độ khó chưa?
• [ ] Context có được nén/cắt khi dài không?
• [ ] Có prompt caching cho phần tĩnh không?
• [ ] Có theo dõi chi phí/ngày theo thời gian thực + cảnh báo khi vượt không?

Sai lầm thường gặp

• Không có max_steps. Một vòng lặp hỏng chạy qua đêm = hóa đơn khủng. Đây là lỗi tốn tiền phổ biến nhất.
• Dùng model to cho mọi bước. Phân loại "câu này thuộc chủ đề gì" không cần model mạnh nhất.
• Nhồi nguyên lịch sử mỗi bước. Context tăng tuyến tính → chi phí tăng theo bình phương số bước. Phải nén.
• Bỏ giới hạn max_tokens output. Model "nói dài" đốt token đầu ra vô ích.
• Chỉ đo chi phí sau khi có hóa đơn. Không có telemetry thời gian thực thì phát hiện sự cố quá muộn.
• Cache sai chỗ. Cache kết quả có yếu tố cá nhân/nhạy cảm dùng chung giữa user → vừa sai vừa rò rỉ dữ liệu.