Một công ty đốt 500 triệu đô tiền AI trong một tháng — và vì sao con bot của bạn cũng có cái lỗ đó
Một công ty trả khoảng 500 triệu USD tiền Claude trong đúng một tháng — chỉ vì quên cài giới hạn sử dụng (nguồn: the-decoder, 30.05.2026). Không phải bị hack. Không phải bug. Chỉ là một flat-rate có request cap ẩn, vượt ngưỡng là tự động bật overage tính theo token thực, và không ai ngồi canh.
Bạn đọc con số đó rồi nghĩ "chuyện của bọn nghìn tỉ đô". Sai. Đó chính xác là cái lỗ đang nằm trong con bot bạn vừa deploy cho khách — chỉ khác mỗi dấu phẩy.
Tóm tắt cho người bận
- Chi phí AI doanh nghiệp đang bùng nổ ngoài kiểm soát. Một DN bay 500 triệu USD/tháng tiền Claude vì không đặt cap (the-decoder, 30.05). Uber thừa nhận cháy hết ngân sách AI cả năm chỉ trong 4 tháng, phải áp trần 1.500 USD/người/tháng cho mỗi tool agentic như Claude Code và Cursor (the-decoder, 03.06).
- Phản ứng của thị trường là săn đồ rẻ. DeepSeek dẫn đầu bảng phần mềm "trending" của Ramp tháng 6/2026 khi DN Mỹ đổ đi tìm AI giá thấp (the-decoder, 08.06).
- Với người build ở VN, token không phải dòng chi phí — nó là rủi ro sống còn. Bán một con bot CSKH giá vài triệu/tháng mà chi phí token chạy lố, bạn lỗ trên chính khách hàng của mình. Tin tốt: phần lớn cái lố đó là lỗi kiến trúc, và nó nằm trong tay bạn.
Vì sao đây là tin của người build, không phải của CFO
Câu chuyện 500 triệu đô và vụ Uber có chung một mẫu: không ai đặt được mối quan hệ giữa "một lượt dùng" và "bao nhiêu tiền". Amazon còn phải khai tử leaderboard nội bộ vì nhân viên "tokenmaxxing" — đua nhau đốt token để leo bảng mà chẳng deploy được gì hữu ích (the-decoder, 30.05).
Ở quy mô của bạn, vấn đề ngược lại nhưng cùng bản chất. Bạn không có đội tài chính canh dashboard. Bạn bán gói cố định — ví dụ con bot spa 2-3 triệu/tháng. Mỗi tin nhắn khách gửi đi là một lượt gọi model, mỗi lượt là một nhúm token bạn trả. Nếu một con bot dựng ẩu nuốt gấp ba lần token cần thiết cho mỗi câu trả lời, bạn không thấy ngay — đến cuối tháng hóa đơn API về mới ngã ngửa. Đó đúng là vụ 500 triệu đô, thu nhỏ về cỡ một fanpage spa.
Khác biệt sống còn: ông lớn lố tiền thì bớt lãi. Bạn lố tiền thì âm vốn trên hợp đồng đã ký.
Góc builder: bốn cái van tôi siết trên con bot spa thật
Tôi đang chạy thật một bot CSKH cho spa trên Messenger. Đây là những chỗ token rò rỉ và cách tôi bịt — không cần model rẻ hơn, chỉ cần kỷ luật.
1. Prompt caching cho khối system. Mỗi con bot CSKH có một khối "bất biến": persona, bảng giá, quy tắc trả lời, kịch bản. Khối đó dài, và nếu bạn gửi lại nguyên si trong mọi lượt gọi thì bạn trả tiền input cho cùng một thứ hàng nghìn lần/ngày. Tôi tách khối system ổn định ra và bật prompt caching — phần lặp lại được nhà cung cấp cache, các lượt sau tính giá rẻ hơn nhiều so với input thường. Với một bot trả lời cả ngày, đây là cái van tiết kiệm lớn nhất, gần như free để bật.
2. Chọn model theo việc, đừng dùng một model cho tất cả. Không phải tin nhắn nào cũng đáng dùng model đắt nhất. "Mấy giờ shop mở cửa?" và "tư vấn liệu trình cho da nhạy cảm đang bị kích ứng" là hai mức việc khác nhau. Phân loại ý định trước, route câu đơn giản sang model nhỏ/rẻ, chỉ để dành model mạnh cho ca cần lập luận. Chính Anthropic cũng đẩy hướng này: Opus 4.8 giữ giá API nhưng cần ít hơn ~15% lượt gọi và ~35% output token so với 4.7 (the-decoder, 30.05) — tức "chi phí thực" được quyết bởi cách bạn dùng, không chỉ bởi giá niêm yết.
3. Giới hạn cứng số vòng tool-use. Bot có quyền tra cứu, đặt lịch, gọi API thì mỗi "vòng" suy nghĩ - gọi tool - đọc kết quả lại tốn thêm một lượt model. Một con bot không chặn vòng có thể rơi vào loop: gọi tool, không hài lòng, gọi lại, lại gọi... mỗi vòng là tiền. Tôi đặt trần số vòng tool-use cho mỗi lượt hội thoại; chạm trần thì dừng và nhường cho người thật thay vì để nó tự quay vô tận. Đây cũng là bài học từ Uber: thứ làm cháy ngân sách không phải giá đơn lẻ, mà là lượng dùng không có phanh.
4. Đo cost theo từng tin nhắn, không chờ hóa đơn cuối tháng. Bạn không quản được thứ bạn không đo. Tôi log token in/out cho mỗi lượt và quy ra tiền theo từng cuộc hội thoại. Nhờ vậy thấy ngay con bot nào, kịch bản nào đang nuốt token bất thường — đúng cái mà công ty 500 triệu đô và Uber không có cho tới khi quá muộn. Một budget alert ở ngưỡng 80% trên console nhà cung cấp là phút cài đặt rẻ nhất bạn từng bỏ ra.
Vì sao phải tính token vào giá bán, không phải gánh ngầm
Đây là chỗ nhiều người làm dịch vụ AI ở VN chết: báo giá con bot như báo giá một website — thu một cục, xong. Nhưng bot là chi phí biến đổi theo lượng dùng. Khách bán hàng tốt, fanpage đông tin nhắn, thì token tăng — và phần tăng đó đang ăn vào lãi của bạn, không phải của khách.
Hệ quả thực tế:
- Giá bán phải có thành phần token rõ ràng, dù bạn gói gọn thành "phí vận hành/tháng". Ước lượng token trung bình mỗi hội thoại, nhân với lưu lượng dự kiến, cộng biên an toàn. Bán dưới con số đó là tự nguyện lỗ.
- Phải có trần ở phía bạn, y như Uber cap 1.500 USD/người. Vượt một ngưỡng lưu lượng thì hoặc bot xuống cấp duyên dáng (model rẻ hơn, câu ngắn hơn), hoặc kích hoạt điều khoản tính thêm. Đừng để hợp đồng cố định gặp lưu lượng vô hạn.
- Đừng nhầm "săn model rẻ" với "kiểm soát chi phí". Làn sóng đổ sang DeepSeek (the-decoder, 08.06) hấp dẫn, nhưng đổi model chỉ hạ đơn giá. Nếu kiến trúc của bạn nuốt gấp ba token cần thiết, đổi sang model rẻ một phần ba thì bạn... về chỗ cũ. Sửa kiến trúc trước, đổi model sau.
Một con bot demo chỉ cần chạy được. Một con bot bán được cho doanh nghiệp phải chạy được mà không âm tiền của người bán nó. Đó là phần "build cho ra sản phẩm có lời" mà nhiều người bỏ qua — và là một trong những thứ tôi dạy kỹ trong mini-course miễn phí: không chỉ dựng con bot đầu tiên chạy đúng, mà dựng nó sao cho mỗi tin nhắn vẫn còn lãi.
Nguồn tham khảo (qua bản tin AI nội bộ tôi theo dõi hằng ngày): the-decoder.com — 30.05, 03.06 và 08.06.2026.