Bài 1 — Bức tranh chi phí & độ trễ: bạn đang đốt tiền ở đâu?

Một hệ thống AI Agent chạy production thường tốn tiền và chậm ở những chỗ mà bạn không nhìn thấy cho tới khi hóa đơn cuối tháng đến. Bài này giúp bạn dựng được bản đồ chi phí và độ trễ trước khi bắt tay tối ưu — vì tối ưu mù là cách nhanh nhất để phá vỡ chất lượng.

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

Gần như mọi nhà cung cấp (OpenAI, Anthropic, Google...) tính tiền theo token, tách riêng:

• Input tokens (prompt, system message, context, lịch sử hội thoại, tool schema).
• Output tokens (phần model sinh ra) — thường đắt gấp 3–5 lần input.

Ví dụ một agent hỗ trợ khách hàng: mỗi lượt gửi đi 6.000 token input (system prompt dài + 12 tool + 8 lượt lịch sử) và nhận về 300 token. Nghe thì output nhỏ, nhưng cái ngốn tiền âm thầm là 6.000 token input lặp lại mỗi lượt. Với 50.000 lượt/ngày, bạn trả cho ~300 triệu input token/ngày chỉ để nhắc lại thứ không đổi.

Độ trễ đến từ đâu?

Độ trễ tổng của một lượt agent = tổng của nhiều mắt xích:

• Network + hàng đợi tới nhà cung cấp.
• TTFT (Time To First Token) — thời gian tới token đầu tiên, phụ thuộc kích thước prompt.
• Thời gian sinh output — tỉ lệ thuận số output token.
• Tool calls — mỗi lần gọi API/DB/hàm là một vòng lặp thêm.
• Các bước agent loop — reasoning nhiều bước nhân độ trễ lên.

Một agent "suy nghĩ 5 bước, mỗi bước gọi 1 model lớn" có thể mất 20–40 giây — người dùng bỏ đi trước khi có câu trả lời.

Khung tư duy: Ma trận 2x2 Chi phí × Độ trễ

Vẽ mọi thành phần lên ma trận để biết đánh vào đâu trước:

              Chi phí THẤP        Chi phí CAO
Độ trễ CAO   | Tối ưu sau     | ƯU TIÊN #1     |
Độ trễ THẤP  | Để yên         | Cân nhắc cache |

Ô "cao cả hai" (ví dụ: gọi model lớn nhất cho câu hỏi lặp lại) là nơi bạn thu lời lớn nhất với ít rủi ro nhất.

Các bước dựng bản đồ ban đầu

• Bật logging từng lệnh gọi LLM: ghi lại model, input_tokens, output_tokens, latency_ms, use_case, request_id.
• Chạy 1–3 ngày với traffic thật (đừng đo trên staging trống).
• Nhóm theo use-case (phân loại intent, sinh trả lời, tóm tắt, gọi tool) chứ không chỉ theo tổng.
• Tính chi phí mỗi use-case = (input×giá_in + output×giá_out) rồi nhân số lượt.
• Xếp hạng theo tổng tiền/tháng, không theo giá mỗi lượt — thứ rẻ nhưng gọi hàng triệu lần mới là kẻ ngốn ngân sách.

cost = (in_tok/1e6)*price_in + (out_tok/1e6)*price_out
# Ghi kèm use_case để nhóm sau
log.info({"use_case": uc, "in": in_tok, "out": out_tok,
          "cost_usd": cost, "latency_ms": lat})

Checklist trước khi tối ưu

• [ ] Đã log token in/out + latency cho 100% lệnh gọi?
• [ ] Đã gắn nhãn use_case để nhóm được?
• [ ] Biết top 3 use-case ngốn tiền nhất?
• [ ] Biết p50 và p95 latency (không chỉ trung bình)?
• [ ] Có baseline chất lượng để so khi tối ưu?

Sai lầm thường gặp

• Chỉ nhìn trung bình, bỏ p95/p99: trung bình 2s nhưng p95 là 15s — chính nhóm này khiến người dùng rời đi.
• Tối ưu chỗ rẻ: cắt 30% một use-case chiếm 2% ngân sách là công sức phí phạm.
• Không có baseline chất lượng: cắt chi phí xong không biết đã làm hỏng câu trả lời hay chưa.
• Đo trên staging: traffic giả không lộ ra prompt lặp lại hay tool call thừa.

Sau bài này bạn nên có một bảng: use-case → tiền/tháng → p95 latency. Đó là kim chỉ nam cho toàn khóa học.