Tối ưu chi phí vận hành AI Agent: giảm token mà vẫn giữ chất lượng

Chi phí AI Agent không chỉ đến từ một lần gọi model. Một workflow có thể gửi context dài, gọi nhiều tool, sinh output dư thừa rồi retry khi lỗi; tất cả đều làm số token và số request tăng lên. Vì vậy, tối ưu chi phí cần nhìn vào toàn bộ vòng đời của một tác vụ thay vì chỉ tìm model rẻ hơn.

Direct Answer: Muốn tối ưu chi phí vận hành AI Agent mà vẫn giữ chất lượng, hãy giảm context không cần thiết, dùng model đủ năng lực cho từng bước, giới hạn định dạng đầu ra, tận dụng prompt cache, kiểm soát retry và ghi log token theo từng request. Mọi thay đổi nên được so sánh bằng cùng một bộ test trước và sau.

Chi phí AI Agent phát sinh ở đâu?

Một Agent đơn giản có thể chỉ gọi model một lần. Nhưng Agent thực tế thường hoạt động theo chuỗi:

User request → context → model → tool → model → output

Nếu Agent tự lập kế hoạch, tra cứu dữ liệu hoặc sửa kết quả, một yêu cầu của người dùng có thể tạo ra nhiều lần gọi API.

Chi phí cơ bản thường gồm:

• Input token.
• Cached input hoặc cache write nếu nền tảng hỗ trợ.
• Output token.
• Các lần gọi model bổ sung.
• Tool hoặc dịch vụ có tính phí.
• Request phát sinh do retry.

Với OpenAI API hiện tại, giá còn thay đổi theo model, độ dài context và chế độ xử lý. Ví dụ, tài liệu pricing phân biệt input, cached input, cache write và output; với context dài, mức giá của một số model cũng cao hơn context ngắn.

Do đó, câu hỏi hữu ích không phải chỉ là “model nào rẻ nhất?”, mà là mỗi tác vụ đang tiêu tiền vào phần nào?

Checklist tối ưu chi phí AI Agent

1. Giảm context trước khi đổi model

Context thường là nơi dễ phát sinh token dư thừa nhất.

Agent có thể được gửi cả lịch sử hội thoại, tài liệu dài, output cũ, định nghĩa tool và hướng dẫn hệ thống ở mỗi request. Context càng tăng, input token càng lớn.

Trước khi gửi request, nên phân loại dữ liệu thành ba nhóm:

Context bắt buộc

Đây là thông tin model cần để hoàn thành tác vụ hiện tại, chẳng hạn yêu cầu của người dùng, dữ liệu nghiệp vụ liên quan và quy tắc không được vi phạm.

Context có thể truy xuất khi cần

Không phải toàn bộ knowledge base đều cần nằm trong prompt. Nếu Agent chỉ cần một phần dữ liệu, retrieval nên chọn đúng đoạn liên quan trước khi gọi model.

Context có thể loại bỏ

Các đoạn hội thoại cũ không còn ảnh hưởng đến nhiệm vụ, output trung gian dài hoặc metadata không được model sử dụng nên được bỏ khỏi request.

Một nguyên tắc thực tế là: mỗi phần context phải trả lời được câu hỏi “model cần thông tin này để quyết định điều gì?” Nếu không có câu trả lời rõ ràng, đó là ứng viên để cắt giảm.

2. Không dùng model mạnh nhất cho mọi bước

Một AI workflow thường chứa cả tác vụ khó lẫn tác vụ đơn giản.

Ví dụ:

• Phân loại yêu cầu.
• Trích xuất trường dữ liệu.
• Chọn tool.
• Tóm tắt kết quả.
• Lập luận cho trường hợp phức tạp.

Không phải bước nào cũng cần cùng một model.

Tài liệu model selection của OpenAI khuyến nghị đặt mục tiêu accuracy trước, sau đó tìm model rẻ và nhanh nhất vẫn đạt ngưỡng chất lượng đó.

Có thể áp dụng mô hình phân tầng:

Tác vụ đơn giản → model nhỏ

Tác vụ khó hoặc rủi ro cao → model mạnh hơn

Ví dụ, việc phân loại một request vào năm nhóm cố định có thể được kiểm thử với model nhỏ. Chỉ các trường hợp không chắc chắn mới chuyển sang model mạnh hơn.

Điểm quan trọng là không downgrade model theo cảm tính. Hãy dùng cùng một test set để xác nhận chất lượng trước khi thay đổi.

3. Kiểm soát output token ngay từ thiết kế

Giảm input nhưng để Agent sinh một bài giải thích rất dài vẫn có thể khiến chi phí cao.

Tài liệu pricing của nhiều API tách riêng giá input và output; ở một số model, output token có đơn giá cao hơn đáng kể input token.

Nếu workflow chỉ cần dữ liệu để máy xử lý tiếp, đừng yêu cầu model trả lời như đang viết cho người đọc.

Ví dụ, thay vì:

“Phân tích yêu cầu này thật chi tiết và giải thích lý do.”

Có thể thiết kế output gồm:

• category
• confidence
• next_action

Nếu nền tảng hỗ trợ structured output, việc xác định schema rõ ràng còn giúp giảm phần văn bản thừa và làm output dễ xử lý hơn.

Chỉ nên yêu cầu giải thích dài khi phần giải thích thực sự được sử dụng.

4. Tận dụng prompt cache cho phần context lặp lại

AI Agent thường gửi đi gửi lại cùng một lượng context lớn:

• System instructions.
• Chính sách.
• Tool definitions.
• Knowledge cố định.
• Một phần lịch sử hội thoại.

Đây là trường hợp prompt caching có thể mang lại lợi ích.

OpenAI hiện hỗ trợ tái sử dụng prefix ổn định. Với GPT-5.6 trở lên, tài liệu chính thức cho biết cache read được tính ở mức thấp hơn input thông thường; cache write có cách tính riêng và prompt đủ điều kiện phải đạt ngưỡng token tối thiểu.

Muốn tăng khả năng cache hit, nên:

1. Đặt phần cố định ở đầu prompt.
2. Giữ system instruction ổn định.
3. Giữ thứ tự tool definition ổn định.
4. Đặt dữ liệu thay đổi theo từng request về phía sau.
5. Theo dõi cached_tokens và cache_write_tokens.

Không nên thêm nội dung vô ích chỉ để đạt điều kiện cache. Cache chỉ hiệu quả khi phần context đó thực sự được tái sử dụng nhiều lần.

5. Kiểm soát số vòng Agent và tool call

Một workflow Agent có thể trở nên đắt không phải vì một request lớn mà vì nó tự lặp quá nhiều bước.

Ví dụ:

Plan → search → read → reason → search lại → read lại → revise → final

Nếu không có điều kiện dừng rõ ràng, Agent có thể tiêu nhiều request để cải thiện rất ít chất lượng.

Nên đặt guardrail như:

• Giới hạn số vòng reasoning/tool.
• Không gọi lại tool với cùng tham số nếu dữ liệu chưa thay đổi.
• Chỉ search khi dữ liệu hiện tại không đủ.
• Dừng khi đã đạt điều kiện hoàn thành.
• Chuyển sang fallback khi vượt budget.

Với workflow có nhiều bước, nên đặt budget theo task, thay vì chỉ đặt giới hạn token cho từng request.

6. Retry đúng lỗi, không retry mọi thứ

Retry giúp hệ thống ổn định nhưng cũng có thể âm thầm nhân chi phí.

Một lỗi 429 hoặc 503 có thể phù hợp để thử lại. Nhưng lỗi do request sai, vượt spend limit hoặc dữ liệu đầu vào không hợp lệ thường không thể được giải quyết bằng việc gọi lại y hệt.

Tài liệu lỗi của OpenAI khuyến nghị tôn trọng Retry-After khi có, giảm tốc độ request và sử dụng backoff khi phù hợp; một số lỗi billing hoặc quota không nên tiếp tục retry.

Một chính sách retry nên quy định:

• Loại lỗi nào được retry.
• Số lần retry tối đa.
• Thời gian chờ.
• Có exponential backoff hay không.
• Khi nào chuyển sang fallback.

Đặc biệt, tránh retry toàn bộ Agent khi chỉ một tool nhỏ bị lỗi.

7. Log chi phí theo từng bước, không chỉ xem hóa đơn cuối tháng

Không đo được thì khó tối ưu.

Một log hữu ích cho mỗi model call nên có:

• Model.
• Input tokens.
• Cached tokens.
• Cache write tokens nếu có.
• Output tokens.
• Latency.
• Tool được gọi.
• Số lần retry.
• Task hoặc workflow ID.
• Kết quả thành công/thất bại.

OpenAI cũng cho phép kiểm tra usage từ API response và Usage Dashboard, giúp đối chiếu hoạt động ở cấp request với chi phí tổng.

Từ dữ liệu này, đội phát triển có thể tìm được câu hỏi cụ thể hơn như: “Bước nào đang chiếm nhiều token nhất?” hoặc “Workflow nào retry nhiều nhất?”

8. Đo chất lượng trước và sau khi tối ưu

Một thay đổi làm hóa đơn giảm nhưng khiến Agent trả lời sai nhiều hơn chưa chắc là tối ưu.

Trước khi chỉnh model, context hoặc prompt, hãy tạo một bộ test đại diện cho các tình huống thực tế.

Không cần đặt số mục tiêu giả định ngay từ đầu. Baseline thực tế của hệ thống mới là mốc phù hợp để so sánh.

Thứ tự tối ưu AI workflow nên áp dụng

Nếu hệ thống đang chạy production, tránh thay đổi tất cả cùng lúc.

Có thể triển khai theo thứ tự:

Bước 1: Tạo baseline

Đo token, số request, latency và chất lượng trên một tập task đại diện.

Bước 2: Cắt context thừa

Loại lịch sử, dữ liệu và output trung gian không ảnh hưởng đến quyết định.

Bước 3: Giới hạn output

Thiết kế schema hoặc format vừa đủ cho bước tiếp theo.

Bước 4: Phân tầng model

Thử model nhỏ trên các tác vụ đơn giản và giữ model mạnh cho trường hợp cần thiết.

Bước 5: Tối ưu cache

Đưa phần context ổn định vào prefix có khả năng tái sử dụng.

Bước 6: Rà soát tool và retry

Giảm vòng lặp không cần thiết và đặt điều kiện dừng rõ ràng.

Bước 7: Chạy lại evaluation

So sánh chi phí và chất lượng với baseline.

Cách triển khai từng thay đổi giúp xác định chính xác tối ưu nào thực sự tạo ra hiệu quả.

Ví dụ: tối ưu một Agent xử lý yêu cầu khách hàng

Giả sử Agent nhận yêu cầu, đọc lịch sử khách hàng, phân loại vấn đề, tra knowledge base và tạo câu trả lời.

Ban đầu, mỗi request gửi toàn bộ lịch sử, toàn bộ hướng dẫn và dùng một model mạnh cho tất cả các bước.

Có thể tối ưu bằng cách:

1. Chỉ retrieval các đoạn lịch sử liên quan.
2. Dùng model nhỏ để phân loại intent.
3. Chỉ gọi knowledge tool khi cần.
4. Giữ system prompt và tool definitions ổn định để tận dụng cache.
5. Yêu cầu bước phân loại trả structured output ngắn.
6. Chỉ dùng model mạnh ở bước tạo câu trả lời khó.
7. Retry riêng bước lỗi thay vì chạy lại toàn workflow.
8. Log chi phí và kết quả theo từng task.

Điểm cần đánh giá sau cùng không phải “đã giảm bao nhiêu token”, mà là chi phí cho mỗi task đạt chất lượng yêu cầu đã thay đổi thế nào.

Kết luận

Tối ưu chi phí vận hành AI Agent không nên bắt đầu bằng việc đổi sang model rẻ nhất. Hãy bắt đầu từ việc quan sát toàn workflow: context đang gửi bao nhiêu, output có dư không, model nào xử lý từng bước, cache có được tận dụng, Agent gọi tool bao nhiêu lần và retry trong trường hợp nào.

Một quy trình hiệu quả là đo baseline → tối ưu một yếu tố → chạy evaluation → so sánh chi phí và chất lượng → tiếp tục vòng kế tiếp. Khi đó, giảm token trở thành bài toán kỹ thuật có thể đo lường thay vì một mục tiêu cắt giảm đơn thuần.