Databricks quản lý chi phí AI Agent nội bộ với Unity AI Gateway Budgets

Tại Databricks, cách chúng tôi xây dựng phần mềm đang thay đổi nhanh chóng khi chúng tôi tích cực áp dụng AI vào kỹ thuật. Hàng ngàn kỹ sư của chúng tôi sử dụng các coding agent mỗi ngày, kết hợp giữa Claude Code, Codex, Cursor và những công cụ khác, thường là dùng nhiều công cụ cùng lúc. Việc áp dụng này rất tuyệt vời, nhưng nó tạo ra một vấn đề mới: chi phí cho coding agent hiện là một trong những hạng mục tăng trưởng nhanh nhất trong R&D, và chỉ cần một vòng lặp tự động hóa mất kiểm soát cũng có thể "đốt" sạch ngân sách cả tháng chỉ trong một buổi chiều.

Bài viết này chia sẻ cách chúng tôi giải quyết vấn đề này nội bộ, sử dụng chính các Unity AI Gateway Budgets mà chúng tôi cung cấp cho khách hàng. Vì mọi coding agent tại Databricks, bất kể công cụ hay mô hình nào, đều định tuyến lưu lượng truy cập qua gateway của chúng tôi, nên chúng tôi có thể thực thi một chính sách chi tiêu thống nhất trên toàn bộ hệ thống mà không cần can thiệp vào bảng điều khiển quản trị của từng coding agent.

Những bài học chính từ việc triển khai này là:

Hãy cùng đi sâu vào cách chúng tôi đạt được điều này.

Lưu ý: Các con số về đô la trong bài viết này chỉ mang tính minh họa, không phải là số liệu nội bộ thực tế của chúng tôi.

Vấn đề với các hạn mức chi tiêu hàng tháng

Khi bắt đầu hành trình quản lý chi phí, chúng tôi chỉ đặt đúng một hạn mức: mỗi kỹ sư có một hạn mức chi tiêu mặc định hàng tháng (giả sử là 500 USD), và khi đạt đến hạn mức đó, họ sẽ gửi yêu cầu để tăng thêm. Điều này nghe có vẻ hợp lý trên lý thuyết, nhưng trong thực tế, chúng tôi nhận thấy chiến lược này tạo ra sự ma sát ở khắp mọi nơi.

Vì hạn mức này cũng là sự bảo vệ duy nhất của chúng tôi trước việc chi tiêu mất kiểm soát, nên mỗi lần tăng hạn mức đều được thực hiện theo các bước 500 USD tương tự. Những người dùng nhiều phải gửi yêu cầu mới mỗi khi họ chạm hạn mức, đôi khi vài lần trong một tháng, và bất kỳ khoản nào vượt quá 2.500 USD đều cần xem xét thủ công. Tệ hơn nữa, mỗi lần tăng đều là vĩnh viễn. Một kỹ sư mắc một sai lầm đắt giá hoặc làm việc trong một dự án tiêu tốn nhiều ngân sách sẽ giữ hạn mức lớn vô thời hạn, âm thầm làm tăng tỷ lệ công ty dễ gặp phải các sai lầm tốn kém. Hơn nữa, không có quy trình "phá vỡ kính" (break glass) để các kỹ sư có thể tự mở khóa cho các tác vụ quan trọng, nhạy cảm về thời gian, chẳng hạn như sử dụng AI để gỡ lỗi các sự cố của khách hàng.

Ở quy mô của chúng tôi, có khoảng từ 500 đến 1.000 kỹ sư chạm hạn mức mỗi tháng. Đó là hàng trăm phiếu yêu cầu, hàng trăm phiên làm việc bị gián đoạn và một kênh Slack #ai-devtools rất cáu kỉnh.

Ưu tiên các nguyên tắc

Trước khi thiết kế bất cứ điều gì, chúng tôi đã viết ra những gì chúng tôi thực sự tin tưởng về chi tiêu AI, và nó đúc kết lại thành hai nguyên tắc:

Việc viết ra những điều này đã phơi bày sự mâu thuẫn. Để bắt kịp chi tiêu mất kiểm soát, hạn mức phải đủ nhỏ để một vài giờ sai sót có thể kích hoạt nó. Nhưng một hạn mức nhỏ như vậy lại liên tục làm gián đoạn việc sử dụng bình thường hàng tháng. Không một con số đơn lẻ nào có thể thực hiện cả hai công việc đó.

Cách chúng tôi tách biệt việc bảo vệ khỏi chi tiêu mất kiểm soát với các hạn mức chi tiêu hàng tháng

Chúng tôi tái cấu trúc dựa trên một nguyên tắc đơn giản: để các kỹ sư chi tiêu không bị cản trở, và chỉ can thiệp vào hai loại lãng phí thực sự quan trọng: lãng phí ngắn hạn và lãng phí dài hạn.

Giải pháp cho hai kiểu thất bại đó tương ứng với hai ngân sách trong Unity AI Gateway:

Hạn mức hàng ngày để bắt kịp chi tiêu mất kiểm soát. Hạn mức này được cố tình đặt ở mức nhỏ so với chi tiêu hàng tháng. Khi một kỹ sư chạm hạn mức này, chúng tôi không giả định có điều gì sai sót. Họ nhận được thông báo Slack, họ xác nhận rằng khoản chi tiêu đó là có chủ đích, và hạn mức sẽ tự động tăng thêm một bậc. Không cần phê duyệt, không cần phiếu yêu cầu, không cần chờ đợi. Nếu khoản chi tiêu đó là do nhầm lẫn, thông báo chính là cảnh báo mà họ cần. Ngân sách hàng ngày đặt lại vào mỗi buổi tối vào giờ thấp điểm nhất của chúng tôi và xóa sạch hoàn toàn vào đầu mỗi tháng.

Hạn mức hàng tháng để quản lý chi tiêu bất thường. Hạn mức này được đặt đủ cao để một kỹ sư thông thường không bao giờ chạm tới. Việc vượt qua nó có nghĩa là ai đó đang yêu cầu chi tiêu nhiều hơn đáng kể so với đồng nghiệp, điều này không sao cả, nhưng cần phải truy xuất được về một ưu tiên kinh doanh cụ thể. Những khoản tăng này cần sự phê duyệt của quản lý thay vì một ủy ban phê duyệt tập trung và được chia thành một vài bậc lớn thay vì những lần tăng nhỏ lẻ vô tận, và quan trọng là chúng bị giới hạn thời gian theo thời hạn của dự án. Khi dự án kết thúc, hạn mức sẽ quay trở lại mức cũ.

Hai hạn mức này được liên kết với nhau thông qua một tỷ lệ cố định. Trong quá trình triển khai của chúng tôi, một kỹ sư chi tiêu ổn định trong suốt cả tháng sẽ không bao giờ chạm hạn mức hàng ngày, vì ngân sách hàng tháng chia cho các ngày làm việc nằm thoải mái dưới ngưỡng hàng ngày. Nếu một quản lý tăng hạn mức hàng tháng cho ai đó vì một dự án lớn, hạn mức hàng ngày và mức tăng của họ cũng tăng theo tỷ lệ tương ứng, vì vậy sự bảo vệ trước việc mất kiểm soát vẫn có ý nghĩa mà không trở thành sự phiền toái.

Về mặt kỹ thuật, hạn mức hiệu dụng tại bất kỳ thời điểm nào rất dễ xác định. Chi tiêu của người dùng được quản lý bởi cả hai ngân sách, do đó sẽ bị giới hạn ở mức tối thiểu của hai hạn mức: mức sử dụng từ đầu tháng đến nay cộng với một mức tăng do mất kiểm soát, và mức tối đa hàng tháng của họ. Khi người dùng bị chặn, công thức đó cũng cho chúng tôi biết chính xác chúng tôi đang ở trường hợp nào. Nếu họ chạm hạn mức mất kiểm soát, việc sử dụng có thể được tiếp tục sau khi tự xác nhận. Nếu họ chạm mức tối đa hàng tháng, họ cần phải trao đổi với quản lý của mình.

Quy trình tự xác nhận

Hạn mức hàng ngày chỉ hoạt động nếu việc mở khóa thực sự không có ma sát, vì vậy chúng tôi dành phần lớn nỗ lực thiết kế cho quy trình đó. Đây là những gì một kỹ sư thực sự trải nghiệm.

Khi người dùng vượt quá khoảng 90% hạn mức hàng ngày, họ đủ điều kiện để được tăng hạn mức trước khi bị chặn. Một thông báo Slack sẽ gửi đến kèm theo ngữ cảnh (họ đã chi tiêu bao nhiêu hôm nay, hạn mức còn lại là bao nhiêu) và một nút duy nhất để xác nhận rằng khoản chi tiêu đó là có chủ đích. Nhấp vào đó sẽ tăng hạn mức hàng ngày thêm một bậc ngay lập tức. Việc tự tăng hạn mức tương tự cũng có sẵn từ cổng thông tin ngân sách nội bộ và từ CLI, nơi in ra hạn mức hàng ngày và hàng tháng còn lại cùng với các liên kết để tăng một trong hai.

Không có giới hạn về số lần tự xác nhận mỗi ngày. Một kỹ sư chạy khối lượng công việc thực sự nặng có thể xác nhận hai hoặc ba lần tăng trong một ngày, và điều đó hoàn toàn ổn. Mỗi lần xác nhận là một tín hiệu con người có chủ đích nói rằng "vâng, là tôi, và tôi cố ý làm điều này". Một cron job không có người giám sát không thể nhấp vào nút Slack. Kích thước mức tăng rất quan trọng ở đây: quá nhỏ thì thông báo trở thành tiếng ồn khiến mọi người chỉ nhấp cho qua, quá lớn thì bộ phận bảo vệ ngừng thực hiện chức năng bảo vệ. Chúng tôi đã định cỡ mức tăng của mình sao cho một kỹ sư chi tiêu ổn định theo ngân sách hàng tháng không bao giờ nhìn thấy thông báo nào cả.

Các bậc ghi đè thay vì các hạn mức tùy ý

Thay vì để các hạn mức trôi nổi theo các giá trị tùy ý cho mỗi người dùng, cả hai ngân sách đều di chuyển qua một tập hợp nhỏ các bậc cố định, được triển khai dưới dạng tư cách thành viên nhóm trong gateway. Mọi người bắt đầu ở bậc cơ sở, và mỗi bậc tăng lên sẽ nâng ngưỡng theo một bước cố định. Điều này giúp hệ thống dễ đọc: danh sách nhóm cho biết ai đang ở trên mức mặc định và cao hơn bao nhiêu.

Hai ngân sách di chuyển qua các bậc của chúng theo những cách khác nhau, phù hợp với công việc khác nhau của chúng.

Các bậc hàng ngày di chuyển tự động. Mọi người bắt đầu tháng ở bậc cơ sở. Mỗi lần tự xác nhận sẽ thăng cấp cho người dùng một bậc, và một công việc theo lịch trình cũng chủ động thăng cấp cho người dùng khi chi tiêu của họ tiến gần đến mức trần hiện tại, tối đa một lần mỗi ngày, vì vậy việc sử dụng bình thường không bao giờ bị gián đoạn. Vào cuối tháng, một công việc khác sẽ đặt lại mọi người về mức cơ sở. Nỗ lực lớn của tháng trước không được mang sang làm hạn mức của tháng này.

Các bậc hàng tháng di chuyển một cách có chủ đích. Chỉ có một vài bậc, khoảng 2x, 5x, cho đến mức hiệu quả là không giới hạn, và mỗi lần thăng cấp cần sự phê duyệt của quản lý hoặc cấp trên. Việc thăng cấp được giới hạn trong dự án biện minh cho chúng, thường là một, ba hoặc sáu tháng, sau đó được hoàn nguyên. Các bước lớn buộc phải có một cuộc trò chuyện thực sự về chi tiêu thay vì những lần tăng nhỏ mà không ai xem xét. Việc tăng bậc hàng tháng cũng làm tăng mức tăng hàng ngày theo tỷ lệ tương ứng, vì vậy bộ phận bảo vệ mất kiểm soát vẫn được hiệu chỉnh.

Thực thi thông qua gateway

Lý do điều này hoạt động mà gần như không cần cơ sở hạ tầng tùy chỉnh là vì Unity AI Gateway đã nhìn thấy mọi thứ. Mọi yêu cầu từ mọi coding agent, cho dù là truy cập Claude, GPT, Gemini hay các mô hình mã nguồn mở, đều được quy cho một danh tính người dùng và được đo lường tại một nơi. Các ngân sách được cấu hình cho gateway áp dụng trên tất cả các công cụ mà một kỹ sư sử dụng, và chi tiêu không thể vượt quá bất kỳ ngân sách nào được áp dụng. Đặc tính cuối cùng đó là thứ thực hiện hành vi "tối thiểu của hai hạn mức" một cách miễn phí: chúng tôi xác định cả hai ngân sách, và cả hai đều có hiệu lực tại bất kỳ thời điểm nào.

Các bậc hàng ngày và hàng tháng được triển khai bằng cách gán các ghi đè ngưỡng cho mỗi người dùng của ngân sách vào các nhóm khác nhau. Và việc thăng cấp bậc đạt được bằng cách đưa người dùng trở thành thành viên của nhóm bậc cao hơn, thông qua tự động hóa hàng ngày, tự xác nhận và phê duyệt của quản lý.

Vì gateway đưa tất cả dữ liệu sử dụng này vào Unity Catalog, chúng tôi cũng có được khả năng quan sát miễn phí. Các quản lý thấy chi tiêu ở cấp nhóm trong cùng các bảng Lakehouse nơi chúng tôi xây dựng điểm chuẩn coding agent nội bộ, và bộ phận tài chính chỉ thấy một hóa đơn thay vì năm hóa đơn.

Những gì đã thay đổi

Hàng đợi phê duyệt dựa trên sự gián đoạn đã biến mất. Theo mô hình mới, chúng tôi chỉ mong đợi một số ít người dùng nặng nhất của mình chạm hạn mức hàng ngày trong một tháng nhất định, và mỗi trường hợp đó đều được giải quyết bằng một lần nhấp xác nhận. Việc tăng hạn mức hàng tháng đã chuyển từ một công việc vặt định kỳ cho mỗi kỹ sư thành một quyết định hiếm hoi, theo phạm vi dự án mà một quản lý thực hiện một lần.

Quan trọng không kém, các kỹ sư đã ngừng việc phân bổ hạn mức. Mục đích của các rào chắn này không bao giờ là để giảm việc sử dụng AI. Đó là để loại bỏ nỗi sợ hãi về chi phí không giới hạn để chúng tôi có thể tiếp tục thúc đẩy việc áp dụng. Chi tiêu hiện là thứ chúng tôi định hình bằng dữ liệu thay vì là thứ chúng tôi cắt giảm vì thận trọng.

Tiếp theo là gì

Chúng tôi đang tiếp tục tinh chỉnh các con số khi các mô hình sử dụng phát triển, và các mô hình đã chứng minh được hiệu quả nội bộ đang thông báo cho chính sản phẩm Budgets: chu kỳ ngân sách hàng ngày gốc, các ghi đè tạm thời hết hạn theo chu kỳ ngân sách và mô hình quyền hạn cho phép người dùng cuối tự tăng ngưỡng hàng ngày của riêng họ trực tiếp thông qua API ngân sách với sự linh hoạt hơn so với các nhóm ghi đè được xác định trước.

Chúng tôi cũng đang nỗ lực làm cho con đường tốn kém trở nên ít cần thiết hơn ngay từ đầu thông qua việc định tuyến mô hình thông minh hơn, để các tác vụ hàng ngày rơi vào các mô hình hiệu quả và các mô hình tiên phong được dành cho công việc cần chúng. Thông tin thêm về điều đó trong bài viết tiếp theo.

Nếu tổ chức của bạn đang mở rộng quy mô coding agent và mỗi công cụ đều có bảng điều khiển ngân sách riêng, thì giải pháp khắc phục cũng chính là giải pháp chúng tôi đã sử dụng. Hỗ trợ coding agent trong Unity AI Gateway hiện đã có sẵn cho tất cả khách hàng Databricks. Hãy xem tài liệu để bắt đầu.