6 chiến lược kiểm soát chi phí sử dụng AI cho doanh nghiệp trên OpenRouter

Hóa đơn AI của nhóm bạn là tổng cộng của mọi chiếc "chìa khóa" (key) mà mỗi kỹ sư đang nắm giữ. Một lập trình viên tạo ra một key cho một thử nghiệm nhỏ. Người khác lại tích hợp vài key vào quy trình CI. Một người khác nữa dán token vào notebook, chạy thử bản mẫu thành công, rồi quên mất rằng key đó vẫn đang hoạt động.

Bản thân những hành động này không phải là sự bất cẩn, nhưng khi cộng dồn lại, hóa đơn sẽ trở nên khó giải trình. OpenRouter có 6 cơ chế kiểm soát giúp quản lý vấn đề này, và bài viết này sẽ đi sâu vào từng cơ chế, nhóm đối tượng phù hợp và gói dịch vụ cần thiết.

Các cơ chế kiểm soát được xếp chồng lên nhau. Vì vậy, hãy bắt đầu với cơ chế rẻ nhất đáp ứng được rủi ro của bạn, và chỉ bổ sung thêm khi cần thiết. Khi hai cơ chế kiểm soát chồng lấn, cơ chế nghiêm ngặt hơn sẽ được áp dụng. Danh sách cho phép (allowlist) sẽ giao nhau và ngân sách thấp hơn sẽ chặn trước.

Cách nhanh nhất để quản lý chi tiêu AI của nhóm trên OpenRouter là gì?

Hãy chọn cơ chế kiểm soát rẻ nhất phù hợp với rủi ro của nhóm bạn, sau đó xếp chồng thêm các lớp khác. Một nhóm nhỏ thường chỉ cần giới hạn theo từng key (per-key limits) cộng với bảng điều khiển Activity ngay từ ngày đầu tiên.

Mỗi cơ chế kiểm soát thực hiện một trong ba nhiệm vụ. Ngân sách (Budgets) và giới hạn theo từng key quyết định số tiền có thể chi tiêu. Danh sách cho phép theo mô hình (model) và nhà cung cấp (provider) quyết định số tiền đó được dùng vào việc gì. Bảng điều khiển Activity cho biết ai là người đã chi tiêu. 6 cơ chế kiểm soát này được chia cho ba nhiệm vụ trên và hoạt động cùng nhau, vì vậy bạn hiếm khi cần dùng cả 6 cùng lúc.

Bảng so sánh các cơ chế kiểm soát

Hãy đọc từ trên xuống dưới. Các cơ chế chặn chi tiêu nằm ở đầu, và các cơ chế theo dõi nằm ở cuối. Tất cả đều khả dụng trên các gói miễn phí và trả phí theo mức sử dụng (pay-as-you-go), ngoại trừ ngân sách không gian làm việc (workspace budgets) yêu cầu gói Enterprise.

Một thiết lập thực tế thường kết hợp ít nhất một cơ chế chặn với một cơ chế báo cáo. Ví dụ, một key dịch vụ sản xuất (production service key) được đặt giới hạn hàng tháng, và bảng điều khiển Activity sẽ cho bạn biết liệu dịch vụ đó có thực sự là nơi tiêu tốn ngân sách hay không. Nếu một lập trình viên cần danh sách cho phép mô hình hoặc ngân sách chặt chẽ hơn những người khác, hãy thêm một "rào chắn" (guardrail) cho thành viên đó.

Bạn thực sự đang trả tiền cho cái gì?

Trước khi thiết lập bất kỳ cơ chế kiểm soát nào, bạn cần biết chi phí thực tế là bao nhiêu. Chúng tôi không tăng giá so với nhà cung cấp, vì vậy giá trong danh mục mô hình (model catalog) chính là chi phí suy luận (inference). Phí nền tảng được tính khi bạn nạp tín dụng (5,5% cho nạp tiền qua thẻ đối với gói pay-as-you-go tiêu chuẩn, tối thiểu $0,80), chứ không tính trên mỗi yêu cầu. Một yêu cầu thất bại sẽ không bị tính phí.

Vì vậy, không có khoản phụ phí ẩn nào cần phải kiểm soát. Nhiệm vụ của các cơ chế này đơn giản là giới hạn lượng suy luận thực tế mà nhóm của bạn thực hiện.

Danh mục mô hình liệt kê mức giá theo từng mô hình mà bạn sẽ áp đặt giới hạn.

Chi tiêu theo hình thức "Mang theo key riêng" (Bring-your-own-key - BYOK) hoạt động khác biệt

Chi tiêu BYOK không phải lúc nào cũng được tính như bạn mong đợi, vì vậy bạn nên kiểm tra điều này trước khi xây dựng các cơ chế kiểm soát xung quanh nó. Khi bạn định tuyến qua các key nhà cung cấp của riêng mình, chúng tôi tính phí 5% trên chi phí mô hình, được miễn phí cho 1 triệu yêu cầu BYOK đầu tiên mỗi tháng.

Cả ngân sách không gian làm việc và ngân sách rào chắn (guardrail budgets) theo mặc định chỉ tính chi tiêu tín dụng OpenRouter, vì vậy nếu nhóm của bạn chủ yếu chạy trên key nhà cung cấp riêng, ngân sách sẽ bao phủ ít hơn so với vẻ ngoài của nó. Mỗi loại đều có cài đặt "Bao gồm chi tiêu BYOK" (include_byok_in_budgets) mà bạn có thể bật để suy luận BYOK cũng được tính vào giới hạn.

Làm cho mỗi yêu cầu rẻ hơn là một chủ đề riêng biệt so với việc giới hạn chi tiêu của nhóm. Để biết thêm, hãy xem phần định tuyến nhà cung cấp để tối ưu chi phí và bộ nhớ đệm prompt (prompt caching).

Làm thế nào để giới hạn chi tiêu trên một API key duy nhất?

Giới hạn theo từng key (per-key limit) là mức chặn cứng đơn giản nhất. Nó giới hạn một API key và bạn không cần phải có tổ chức (organization) để sử dụng nó.

Hãy sử dụng nó khi bạn muốn giới hạn một kỹ sư, dịch vụ, môi trường, bản mẫu hoặc key của nhà thầu. Một key môi trường staging có thể có giới hạn hàng ngày nhỏ. Một key dịch vụ sản xuất có thể có giới hạn hàng tháng lớn hơn. Một key đánh giá tạm thời có thể đặt lại hàng tuần, để thử nghiệm ngừng tiêu tốn ngân sách sau khi quá trình đánh giá kết thúc.

Bạn có thể đặt giới hạn trong bảng điều khiển hoặc thông qua Management API, vốn có thể tạo, xoay vòng, cập nhật và vô hiệu hóa các key. Điều đó có nghĩa là một quy trình cấp phát nội bộ có thể cấp mọi key kèm theo giới hạn ngay từ ngày đầu tiên thay vì dựa vào việc ai đó thêm giới hạn sau này.

Điểm yếu là giới hạn theo từng key chỉ chặn key đó, chứ không chặn người dùng. Nếu một người sở hữu 5 key, mỗi key có giới hạn hàng ngày riêng, họ có thể tiêu tổng cộng của cả 5 key. Key không biết về các key khác. Giới hạn theo từng key cũng không quy định mô hình hoặc nhà cung cấp nào mà người gọi có thể sử dụng.

Hãy bắt đầu với giới hạn theo từng key. Khi bạn cần một quy tắc áp dụng cho một người, hoặc quy tắc kết hợp ngân sách với các hạn chế về mô hình, nhà cung cấp hoặc quyền riêng tư, hãy chuyển sang sử dụng rào chắn (guardrails).

Rào chắn kiểm soát ngân sách, mô hình và quyền riêng tư như thế nào?

Rào chắn là một chính sách đi theo một người hoặc một key.

Một rào chắn có thể chứa giới hạn ngân sách, danh sách cho phép mô hình, danh sách cho phép nhà cung cấp, các quy tắc Không lưu trữ dữ liệu (Zero Data Retention - ZDR), phát hiện tấn công prompt-injection và jailbreak, xử lý thông tin nhạy cảm và bộ lọc regex tùy chỉnh. Gán nó cho một thành viên trong tổ chức và nó trở thành cơ sở cho tất cả các key của thành viên đó. Hoặc gán trực tiếp rào chắn cho một API key duy nhất để kiểm soát chặt chẽ.

Hãy sử dụng rào chắn khi "chặn key này" là chưa đủ và quy tắc bạn thực sự muốn là "người này chỉ có thể sử dụng các mô hình này, trong ngân sách này, theo các quy tắc quyền riêng tư này."

Các nhóm nền tảng thường đạt đến điểm này vì các nhóm khác nhau cần những thứ khác nhau. Một nhóm trong tổ chức của bạn sử dụng các mô hình tiên tiến (frontier models) trong sản xuất, nơi độ chính xác suy luận quan trọng hơn giá cả; một nhóm khác chạy các công việc hàng loạt (batch jobs) phụ thuộc vào khối lượng lớn và có thể làm việc với các mô hình rẻ hơn; nhóm thứ ba cần xử lý các đầu vào có thể chứa thông tin nhạy cảm và cần ZDR. Rào chắn cho phép bạn đặt các quy tắc đó một lần thay vì yêu cầu mọi nhóm ứng dụng phải viết chính sách vào mã nguồn của họ.

Chúng tôi tuân theo một quy tắc xếp lớp đơn giản: cái nào nghiêm ngặt hơn luôn thắng. Trong sơ đồ, các lớp được bao gồm trong một yêu cầu là cài đặt tài khoản của bạn, mặc định của không gian làm việc, rào chắn được gán cho tài khoản thành viên và rào chắn được gán trực tiếp cho API key. Tất cả các lớp kết hợp thành một chính sách yêu cầu hiệu dụng duy nhất.

Khi có nhiều hơn một rào chắn áp dụng cho một yêu cầu, quyền truy cập của nó bị giới hạn bởi các quy tắc nghiêm ngặt nhất. Danh sách cho phép mô hình và nhà cung cấp hoạt động trên cùng cơ sở đó. Ví dụ, nếu cơ sở tài khoản cho phép 10 mô hình nhưng rào chắn của API key chỉ cho phép ba trong số đó, key đó chỉ nhận được ba mô hình, không phải mười. Điều tương tự áp dụng cho danh sách cho phép nhà cung cấp. Đối với ZDR, nếu bất kỳ lớp nào bật nó cho một nhóm mô hình, nó sẽ được kích hoạt.

Khi nhiều lớp đặt bộ lọc thông tin nhạy cảm, tất cả chúng đều áp dụng, và nếu một trong các bộ lọc đó chặn yêu cầu trong khi bộ lọc khác biên tập (redact) nó, quy tắc chặn sẽ thắng. Ngân sách cũng được kiểm tra riêng biệt. Nếu một nhóm đặt ngân sách cấp thành viên và ngân sách cấp key, chúng không hợp nhất thành một quỹ chung, nghĩa là một yêu cầu phải vượt qua cả hai ngân sách.

Đối với các rào chắn kiểm soát ngân sách, việc thực thi là theo từng người dùng và từng key, không được chia sẻ. Điều đó có nghĩa là ngân sách rào chắn áp dụng độc lập cho mỗi thành viên và key mà bạn gán nó vào. Nếu bạn cung cấp cùng một rào chắn ngân sách hàng ngày cho ba thành viên, mỗi thành viên đó nhận được ngân sách đó riêng biệt; họ không chia sẻ một quỹ lớn. Khi một key thực hiện yêu cầu tới OpenRouter, mức sử dụng được tính vào cả ngân sách của key và ngân sách của thành viên sở hữu key đó.

Đây là lý do chính để sử dụng rào chắn thay vì chỉ giới hạn theo từng key. Với rào chắn, bạn có thể dễ dàng giới hạn chi tiêu của một người trên tất cả các key của họ, đồng thời vẫn có khả năng thắt chặt giới hạn trên một key nếu một ứng dụng cụ thể cần mức trần nhỏ hơn.

Một vài điều cần biết. Trong một tổ chức, chỉ quản trị viên mới quản lý được rào chắn (tài khoản cá nhân cũng có thể tạo rào chắn cho các key của riêng mình). Hãy nhớ rằng danh sách cho phép của bạn cần được bảo trì khi chính sách mô hình thay đổi. Và khi ngân sách hết, người gọi sẽ nhận được mã lỗi 403, không có cảnh báo trước.

Khi nào bạn nên sử dụng ngân sách không gian làm việc (workspace budget)?

Hãy sử dụng ngân sách không gian làm việc khi bạn cần một mức chặn cứng cho toàn bộ không gian làm việc, bất kể có bao nhiêu key nằm trong đó. Đặt giới hạn USD cho khung thời gian hàng ngày, hàng tuần, hàng tháng hoặc trọn đời, và OpenRouter sẽ chặn các yêu cầu bằng mã 403 khi đạt đến giới hạn. Điều này chặn toàn bộ môi trường cùng một lúc, vì vậy bạn không cần phải kiểm soát từng key bên trong đó.

Các hạn chế theo gói dịch vụ

Ngân sách không gian làm việc là một tính năng của gói Enterprise, được tạo và quản lý bởi quản trị viên tổ chức của bạn. Giới hạn theo từng key và rào chắn hoạt động trên cả gói miễn phí và PAYG, nhưng ngân sách không gian làm việc thì không. Nếu bạn không sử dụng gói Enterprise, ngân sách rào chắn theo từng thành viên là cách để bạn giới hạn chi tiêu của nhóm mình.

Cách các không gian làm việc phù hợp