- Khóa trình duyệt Firebase bị lộ mà không có giới hạn API, khiến các yêu cầu Gemini API tự động phát sinh từ bên ngoài, dẫn đến chi phí khổng lồ trong thời gian ngắn
- Bất kể lưu lượng người dùng thực tế, hệ thống vẫn ghi nhận mức phí hơn €54.000 trong 13 giờ, trong khi cảnh báo chi phí kích hoạt chậm làm việc ứng phó bị trễ
- Đội hỗ trợ Google Cloud phân loại các yêu cầu này là mức sử dụng hợp lệ (valid usage) và từ chối yêu cầu điều chỉnh cước phí
- Google đang triển khai các cơ chế bảo vệ như giới hạn chi tiêu, khóa xác thực, chặn khóa tự động, thanh toán trả trước, đồng thời sẽ từng bước ngừng hỗ trợ khóa không giới hạn
- Nhà phát triển cần không đưa khóa vào mã phía client, đồng thời bắt buộc áp dụng giới hạn API key và hạn mức ngân sách
Trường hợp chi phí Gemini API tăng vọt do lộ khóa trình duyệt Firebase
-
Tổng quan sự cố
- Trong một dự án trước đó chỉ dùng Firebase Authentication, ngay sau khi bật Firebase AI Logic thì mức sử dụng Gemini API tăng đột biến
- Các yêu cầu tự động hóa không liên quan đến lưu lượng người dùng thực tế đã phát sinh trong thời gian ngắn, dẫn tới khoản phí hơn €54.000 trong khoảng 13 giờ
- Sau khi vô hiệu hóa API và xoay vòng thông tin xác thực (credential), lưu lượng bất thường đã dừng lại
- Cảnh báo ngân sách (€80) và cảnh báo phát hiện bất thường chi phí được kích hoạt chậm vài giờ; đến lúc phản ứng thì chi phí đã ở mức khoảng €28.000
- Tổng hóa đơn cuối cùng được chốt ở mức hơn €54.000 do báo cáo chi phí bị trễ
-
Kết quả hỗ trợ từ Google Cloud
- Dù đã gửi log và tài liệu phân tích, các yêu cầu vẫn bị phân loại là mức sử dụng hợp lệ (valid usage) phát sinh từ dự án, nên yêu cầu điều chỉnh cước phí bị từ chối
- Mặc dù đây là mức sử dụng bất thường và không phải lưu lượng do người dùng tạo ra, hệ thống vẫn xử lý như khoản phí hợp lệ
-
Các câu hỏi từ người dùng
- Hỏi liệu sau khi kích hoạt Firebase AI Logic hoặc Gemini đã từng có trường hợp tương tự nào hay chưa
- Hỏi ngoài App Check, quota, chuyển sang gọi từ phía server thì còn biện pháp bảo vệ bổ sung nào khác không
- Hỏi liệu có tồn tại quy trình khiếu nại nâng cấp (escalation path) nào cho các trường hợp như vậy không
Phản hồi từ Google (Logan Kilpatrick)
-
Tính năng giới hạn sử dụng và tính phí
- Google đã triển khai giới hạn cước phí cho người dùng Gemini API (billing account caps); với người dùng Tier 1, hệ thống sẽ tự động chặn sau ngưỡng $250 mỗi tháng
- Có thể thiết lập giới hạn chi tiêu theo dự án (project spend caps); ví dụ tài khoản cá nhân có thể giới hạn ở $50
- Mọi báo cáo tính phí hiện đều có độ trễ khoảng 10 phút
-
Bảo mật API key và các thay đổi sắp tới
-
Việc dùng API key không giới hạn (unrestricted key)** sẽ sớm bị** vô hiệu hóa trong Gemini API
- Người dùng mới mặc định sẽ được tạo khóa xác thực (Auth key), có mức bảo mật cao hơn trước đây
- Không nên đưa khóa vào mã phía client vì nếu bị lộ có thể phát sinh chi phí
- Hiện đã có cơ chế tự động phát hiện và vô hiệu hóa nếu khóa bị lộ trên web công khai; đã có trường hợp bị chặn chỉ sau vài phút
-
Giới hạn khóa và phạm vi dịch vụ
-
Khóa được tạo trong Google AI Studio** mặc định chỉ bị giới hạn cho** Gemini API
- Trong khi đó, khóa được tạo từ các kênh khác như Google Cloud Console có thể truy cập nhiều dịch vụ, nên khi cần phải tự đặt giới hạn theo từng dịch vụ
-
Các biện pháp bổ sung và kế hoạch sắp tới
- Để xem xét trường hợp này, phía Google đề nghị liên hệ trực tiếp qua email Lkilpatrick@google.com
- Cơ chế thanh toán trả trước (prepaid billing) đã được triển khai để chuyển sang mô hình trả tiền trước khi sử dụng
- Hiện đã áp dụng cho các tài khoản mới tại Mỹ và đang được mở rộng dần trên toàn cầu
- Những thay đổi này nhằm tăng cường khả năng kiểm soát chi phí của nhà phát triển và ngăn chặn các khoản phí ngoài dự kiến
1 bình luận
Ý kiến trên Hacker News
Chúng tôi đã thiết lập cảnh báo ngân sách (€80) và cảnh báo chi phí bất thường, nhưng cả hai đều kích hoạt chậm vài giờ
Khi chúng tôi kịp phản ứng thì chi phí đã lên tới €28.000, và cuối cùng do báo cáo chi phí bị trễ nên bị tính hơn €54.000
Trong tình huống này, lời bào chữa của ba công ty rằng “hard spending cap là điều không thể về mặt kỹ thuật” hoàn toàn không thuyết phục
Nói rằng không thể có hard cap là vô lý, ít nhất cũng phải cho người dùng quyền lựa chọn
Trước đây những sai lầm kiểu này chỉ là bug, còn bây giờ có thể dẫn đến phá sản
Nếu bạn thuê thay gạch phòng tắm mà lại bị tính tiền cải tạo cả khu vườn, dĩ nhiên bạn phải có quyền từ chối
Tuy vậy, với kinh nghiệm từng xử lý hệ thống tính cước viễn thông, tôi hiểu rằng việc tổng hợp log ở quy mô TB cần thời gian
Nhưng các nhà mạng thường chấp nhận khoảng 2~3% nợ xấu và ưu tiên khách hàng hơn
Google cũng nên có cách ứng xử mềm dẻo hơn trong những trường hợp như vậy
Đặc biệt nếu chuyện này xảy ra ngay sau khi AI key bị lộ, Google lẽ ra phải phát hiện việc quét key và chặn nó
Nhưng trên thực tế có vẻ tính năng này không hoạt động đúng như mong đợi
Tôi cũng từng có trải nghiệm tương tự
Tôi đặt ngân sách $100 trên GCP nhưng phải 5 giờ sau khi vượt ngưỡng mới nhận được email cảnh báo
Thật khó tin khi tính năng này lại không được ưu tiên
Có thể doanh thu của Google giảm trong ngắn hạn, nhưng lập trình viên từng gặp chuyện như vậy sẽ không bao giờ giới thiệu nó nữa
Nhóm 2 người của chúng tôi suýt nữa sụp đổ vì một runaway job
Chúng tôi đã nối cảnh báo với kill switch đúng theo cách GCP khuyến nghị, nhưng cảnh báo đến trễ 6 giờ
Cuối cùng phải đưa bằng chứng ra mới được hoàn tiền
Google nói rằng “có quá nhiều line item nên pipeline bị tắc”, nhưng chẳng phải hệ thống này được tạo ra chính để đối phó với tình huống đó sao
Tôi tò mò cuối cùng việc dàn xếp chi phí với Google đã kết thúc thế nào
Không có nền tảng cloud nào muốn làm trước tính năng ngắt dòng tiền cả
Đây đúng là hình ảnh điển hình của chủ nghĩa tư bản giai đoạn cuối
Nhìn vào kết quả tìm kiếm trên GitHub, có thể thấy khá nhiều Gemini API token bị lộ nguyên xi trong các repo công khai
Google từ lâu không xem API key là bí mật, rồi đến LLM key thì đột nhiên lại coi là bí mật
Có lẽ tác giả đã để lộ key trong quá trình làm frontend hoặc chia sẻ mã nguồn
Điều này cũng được nêu rõ trong thread HN liên quan và tài liệu chính thức
Vì vậy tôi không hiểu vì sao những trường hợp như thế này vẫn tiếp tục xảy ra
“Your API key was reported as leaked. Please use another API key.”
Tức là có vẻ phần lớn đều bị chặn tự động
Trên Google Cloud không có cách dễ dàng để đặt hard cap
Tôi cũng đã mất hơn một giờ tìm cách cấu hình, rồi cuối cùng phải lên Reddit mới biết đến cách Pub/Sub → Cloud Function → tắt billing
Đó là một cấu trúc điên rồ đến khó tin
Nó đạt tỷ lệ thất bại 100%
Nếu biện pháp bảo vệ do người dùng tự dựng lên thất bại thì rất dễ nói “đó không phải trách nhiệm của chúng tôi”
Sẽ rất tốt nếu có tính năng tự động kích hoạt kill-switch khi mức sử dụng vượt ngưỡng
Downtime 5 giờ thì còn chấp nhận được, chứ hóa đơn khổng lồ thì không chịu nổi
Đọc bài này xong tôi lập tức hạ gói Firebase của mình xuống
Tôi bị sốc khi thấy có trường hợp bị tính $6.909 chỉ vì API mà họ chưa từng gọi trong suốt một tháng
Trước đây tôi cũng từng tạo API key trong một buổi học, nên giờ nghĩ lại thấy có khi nó đã bị chụp ảnh lại
Trong giai đoạn 2020~21 tôi từng dạy sinh viên về dịch vụ cloud và dùng AWS Free Tier
Tôi dựng một máy chủ MediaWiki, nhưng tài khoản spam cứ liên tục xuất hiện và bảo mật thì bất an
Cảm giác như các cổng mạng luôn bị tấn công
Cuối cùng tôi nhận ra không có cách nào giới hạn ngân sách ở mức $20~30, nên đã từ bỏ AWS
Cloud có vẻ tiện quản lý, nhưng vì nguy cơ bom chi phí không giới hạn, nó nguy hiểm cho cả cá nhân lẫn doanh nghiệp
Với lập trình viên solo hay các nhóm nhỏ, public cloud là một môi trường đáng sợ và bất an
Không có đủ chốt an toàn, và chi phí có thể tăng vọt vô hạn
Vì thế tôi dành một phần đáng kể thời gian của dự án để xây logic giám sát và chặn chi phí
Trước đây tôi chỉ dùng VPS đơn giản, nhưng giờ nhiều khi vẫn buộc phải dùng dịch vụ của Google hay AWS
Dù vậy tôi thấy GCP vẫn khá hơn đôi chút ở chỗ có thể ngắt liên kết billing account bằng lập trình
Ở Mỹ chắc sẽ phát sinh rắc rối pháp lý, nhưng ở các nước khác thì tôi không rõ
Những hệ thống tính cước kiểu này được thiết kế rất tệ nếu nhìn từ góc độ trải nghiệm khách hàng (CX)
Việc tính phí dựa trên event, nên mức sử dụng bị xếp hàng trong queue và việc tổng hợp bị trễ
Cảnh báo cũng chỉ được gửi sau khi tổng hợp xong, nên nếu có độ trễ thì lúc đó đã vượt xa ngưỡng rồi
Cấu trúc này chỉ bảo vệ công ty chứ không bảo vệ khách hàng
Nếu thực sự lấy khách hàng làm trung tâm, thì ngay khi chạm hard limit phải bảo đảm không bị tính quá số tiền đó
Như vậy công ty mới có động lực tự cải thiện hệ thống tổng hợp của mình
Hoàn toàn có thể làm theo kiểu trừ trước như gói cước trả trước hoặc dịch vụ giới hạn data
Cuối cùng đây là vấn đề trong thông lệ kinh doanh của Google
Theo tài liệu chính thức của Google Cloud, trong trường hợp khẩn cấp có thể vô hiệu hóa billing account để dừng việc tính phí
Hướng dẫn chính thức có cảnh báo về “nguy cơ mất tài nguyên không thể khôi phục”
Nhưng với các ứng dụng thử nghiệm hay nội bộ thì đây là một phanh khẩn cấp khá tốt
Tài liệu về phương án khác và tài liệu thiết lập cảnh báo ngân sách cũng đáng tham khảo
Tôi từng tiêu $400 chỉ trong 5 phút
Chúng tôi cũng gặp đúng vấn đề đó
Một key vốn dĩ không phải bí mật đã bị chuyển thành bí mật sau khi bật Gemini API, nhưng không hề có cảnh báo
May mà chúng tôi phát hiện sớm nhờ cảnh báo nên thiệt hại được giới hạn ở mức $26.000
Chúng tôi đã yêu cầu đội hỗ trợ Google hoàn tiền nhưng ban đầu bị từ chối, hiện vẫn đang được xem xét lại
Trong những trường hợp như thế này, cần escalate vấn đề lên cấp cao nhất có thể