Databricks chia sẻ bí quyết tối ưu chi phí khi triển khai lập trình AI quy mô lớn

Các công cụ lập trình AI mang lại giá trị to lớn: tại Databricks, việc lập trình bằng tác nhân (agentic coding) đã cải thiện rõ rệt mọi chỉ số tốc độ mà chúng tôi theo dõi, và ở một số nhóm, nó đã thúc đẩy năng suất tăng gấp mười lần. Tuy nhiên, gần như mọi công ty triển khai công cụ AI trên quy mô lớn đều gặp phải cùng một rào cản: chi phí tăng theo cấp số nhân. Đường cong chi phí đó là không bền vững - nếu không được kiểm soát, cuối cùng nó sẽ vượt qua cả doanh thu. Sự bùng nổ chi tiêu này đã đẩy các doanh nghiệp vào một tình thế nghịch lý: một mặt, họ muốn thúc đẩy tối đa quá trình chuyển đổi AI và trao những công cụ mạnh mẽ vào tay nhân viên; mặt khác, họ phải đối mặt với tổng chi phí đe dọa làm suy yếu hoặc thậm chí đảo ngược chính những lợi ích về hiệu suất mà AI mang lại.

Rất may, một số đơn vị tiên phong áp dụng AI quy mô lớn đã tìm ra các phương pháp giải quyết bài toán này, đạt được "nhiệm vụ kép": (a) cung cấp quyền truy cập rộng rãi vào các công cụ AI với độ ma sát tối thiểu, và (b) giữ tổng chi phí nằm trong một hạn mức tương đối cố định trên mỗi người dùng. Bài viết này phác thảo các kỹ thuật quản lý chi phí đã được kiểm chứng, dựa trên kinh nghiệm của chúng tôi tại Databricks và các cuộc trao đổi với nhiều công ty thuần kỹ thuật số khác, bao gồm Stripe, Coinbase, Uber và Ramp. Bảng dưới đây tóm tắt các kỹ thuật hiện tại và mức tiết kiệm tương ứng; các con số này mang tính định hướng, dựa trên một khảo sát không chính thức từ các nhóm phát triển:

Một số kỹ thuật trong số này có thể dễ dàng triển khai với phần mềm mà nhiều công ty đang sử dụng. Những kỹ thuật khác đòi hỏi cơ sở hạ tầng mới, đặc biệt là các kỹ thuật sửa đổi ứng dụng phía người dùng cuối hoặc chuyển hướng lưu lượng truy cập giữa các mô hình. Tại Databricks, chúng tôi đã mã nguồn mở hoặc cung cấp miễn phí các thành phần cơ sở hạ tầng chính của mình: một meta-harness cho người dùng cuối (Omnigent) và AI Gateway của chúng tôi (Unity AI Gateway). Để đảm bảo tính đầy đủ, bài viết này cũng đề cập đến các phần mềm được sử dụng bởi các công ty khác mà chúng tôi đã tham khảo.

"Biên hiệu suất" (Efficiency Frontier) cho các mô hình lập trình

Đòn bẩy chi phí lớn nhất chính là việc chuyển dịch chi tiêu lập trình sang các mô hình hiệu quả hơn ngay khi chúng được phát hành. Điểm này cần được thảo luận kỹ hơn, vì cách giải thích đơn giản về "các mô hình rẻ hơn" thực tế lại che giấu mối quan hệ phức tạp giữa chi phí và chất lượng mô hình.

Thông thường, thuật ngữ "mô hình biên" (frontier model) có nghĩa là "mô hình thông minh nhất", và các phòng thí nghiệm tiên phong chủ yếu tập trung vào việc nâng cao đỉnh cao trí tuệ. Các mô hình biên hiện nay có thể giải quyết các vấn đề mới lạ trong toán học hoặc an ninh mạng. Nhưng khi AI được triển khai ở quy mô lớn, một loại biên khác lại quan trọng hơn: biên hiệu suất (efficiency frontier). Biên hiệu suất được định nghĩa bởi tập hợp các mô hình có mức giá tốt nhất cho một trình độ thông minh nhất định. Hầu hết công việc lập trình hàng ngày không đòi hỏi các chứng minh toán học hay những hiểu biết sâu sắc về bảo mật, vì vậy điều quan trọng nhất về tổng thể là chi phí của các mô hình đáp ứng được tiêu chuẩn chất lượng cho công việc kỹ thuật phần mềm thông thường. "Biên hiệu suất" này đang tiến xa hơn nhiều so với biên trí tuệ, với các mô hình mới được phát hành gần như hàng tuần, mang lại chỉ số thông minh trên mỗi đơn vị giá tốt hơn các mô hình trước đó.

Đòn bẩy chi phí #1: Chuyển sang các mô hình mã nguồn mở và chi phí thấp hơn

Việc nhanh chóng áp dụng các mô hình mới hơn, hiệu quả hơn mang lại lợi ích chi phí lớn nhất so với bất kỳ kỹ thuật nào. Nhưng để đạt được những lợi ích đó, công ty trước tiên cần biết mô hình nào thực sự vượt trội hơn các mô hình hiện tại. Điều này có thể khó khăn vì các bài kiểm tra (benchmark) công khai không phản ánh tốt hiệu suất thực tế trong các tác vụ lập trình. Để đánh giá các mô hình mới, nhiều công ty đã xây dựng các hệ thống đánh giá tự động mà họ tin rằng đại diện tốt hơn cho hỗn hợp phát triển nội bộ của họ. Databricks gần đây đã công bố một ví dụ về bài kiểm tra như vậy, trong đó chúng tôi quan sát thấy hiệu suất/giá thành rất cạnh tranh của các mô hình GLM. Bài kiểm tra đó đã dẫn dắt chúng tôi triển khai GLM cho các nhà phát triển nội bộ. Thông thường, các mô hình mới không làm thay đổi biên hiệu suất và các đánh giá thường cho kết quả tiêu cực: Stripe nhận thấy rằng Opus 4.7 không cải thiện chất lượng đáng kể so với Opus 4.6 trong khi lại tăng chi phí. Do đó, họ đã từ chối cung cấp Opus 4.7 nội bộ. Databricks cũng ghi nhận sự sụt giảm chi phí tương tự khi so sánh Opus 5.0 với 4.8.

Harness và sự linh hoạt của mô hình

Vì lợi ích lớn nhất đến từ việc chuyển đổi sang các mô hình mới, việc áp dụng các công cụ người dùng cuối cho phép sự linh hoạt về mô hình đang trở thành yếu tố then chốt để giữ chi phí ở mức thấp. Công cụ thường được sử dụng cùng với một mô hình cụ thể được gọi là harness. Các mô hình biên độc quyền ngày càng được đồng thiết kế để hoạt động tốt với các harness cụ thể, nghĩa là một số harness nhất định sẽ "hoạt động tốt hơn" với các mô hình nhất định. Nếu một công ty muốn duy trì sự độc lập về mô hình, có khoảng hai cách tiếp cận:

Yêu cầu người dùng chuyển đổi harness. Một cách tiếp cận là cung cấp cho các nhà phát triển một bộ harness (Claude Code, Codex hoặc Cursor) và sau đó yêu cầu họ chuyển đổi giữa các harness khi công ty muốn chuyển dịch chi tiêu sang các mô hình chi phí thấp hơn. Điều này cho phép người dùng làm việc trong harness ưa thích của họ khi có thể, nhưng nhược điểm là chi phí chuyển đổi đối với từng nhà phát triển có thể rất cao. Nếu chi phí chuyển đổi trở nên quá cao, bản thân harness sẽ trở thành sự ràng buộc thực tế vào một dòng mô hình, hạn chế khả năng chuyển chi tiêu sang các mô hình cạnh tranh hơn.

Sử dụng meta-harness. Một cách tiếp cận mới và ngày càng phổ biến là sử dụng meta-harness, cung cấp trải nghiệm người dùng chung cho các nhà phát triển trong khi điều phối các yêu cầu đến các harness cơ sở (cả độc quyền và mã nguồn mở). Cách tiếp cận này cho phép sự độc lập về mô hình/harness đồng thời giảm chi phí chuyển đổi cho nhà phát triển. Tại Databricks, đây là chế độ mặc định cho các nhà phát triển sử dụng Omnigent. Một số công ty chúng tôi trao đổi đã xây dựng các meta-harness nội bộ tùy chỉnh tích hợp với chuỗi công cụ phát triển của họ.

Đòn bẩy chi phí #2: Định tuyến tác vụ và yêu cầu động

Thay vì yêu cầu người dùng tự chọn các mô hình phù hợp với tác vụ, ngày càng có nhiều nghiên cứu cho thấy việc lựa chọn mô hình và công cụ tự động có thể giúp tối ưu hóa hiệu suất hơn nữa trong các quy trình lập trình tác nhân. Các phương pháp định tuyến thường chia thành ba loại:

Đòn bẩy chi phí #3: Cung cấp khả năng hiển thị, cảnh báo và ngân sách cho nhà phát triển

Có thể ngạc nhiên khi toàn bộ bài viết này không bắt đầu và kết thúc bằng việc "Hãy đưa cho người dùng một ngân sách hàng tháng và xong việc". Ngân sách cứng, nơi việc sử dụng bị cắt hoàn toàn tại một ngưỡng chi tiêu cụ thể, thường chỉ được sử dụng như một lựa chọn cuối cùng tại mọi công ty chúng tôi trao đổi. Có hai lý do khiến ngân sách token cứng không đặc biệt hiệu quả trong việc quản lý chi tiêu AI: Thứ nhất, nếu một nhà phát triển đạt đến trần ngân sách, việc cắt quyền truy cập vào các công cụ AI sẽ gây ảnh hưởng nghiêm trọng đến năng suất. Cả công ty và nhân viên đều không muốn kết quả đó. Thứ hai, ít nhất một số người dùng "chi tiêu cao" thực tế lại là những người đã đạt được những bước tiến lớn về hiệu suất nhờ AI và tạo ra sản lượng khổng lồ. Việc ngăn cản những người dùng đó là tự làm hại chính mình.

Thay vì giới hạn chi tiêu cứng cho người dùng, hầu hết các công ty đang áp dụng cách tiếp cận tinh tế và tiến bộ hơn, tập trung vào khả năng hiển thị cho người dùng cuối và tăng dần mức độ ma sát khi chi tiêu tăng lên.

Khả năng hiển thị: Mọi công ty chúng tôi trao đổi đều có cơ chế cung cấp phản hồi gần như tức thời cho người dùng về chi tiêu hiện tại của họ, với nhiều công ty còn đưa ra các mẹo hoặc thông tin cụ thể về cách giảm chi tiêu bằng cách sử dụng các mô hình ít tốn kém hơn. Điều quan trọng là người dùng phải có khả năng xem chi tiêu của họ trên tất cả các công cụ, vì họ có thể muốn điều chỉnh lựa chọn công cụ nơi họ nhận được ROI cao nhất.

Bảng điều khiển nhà phát triển tại Databricks

Đòn bẩy chi phí #4: Giảm chi phí token dư thừa

Khi người dùng nhập một yêu cầu tương đối đơn giản vào một tác nhân lập trình AI (chẳng hạn như "Vui lòng điều tra và sửa lỗi này."), tác nhân đó sau đó sẽ thu thập một lượng lớn ngữ cảnh liên quan, gọi một số lượng lớn công cụ, tìm kiếm qua cơ sở mã và tích hợp các kỹ năng hoặc thông tin hệ thống do công ty cung cấp. Đến khi quá trình suy luận LLM tốn kém diễn ra, tuyên bố ban đầu của người dùng chỉ chiếm một phần không đáng kể trong dữ liệu được đưa vào hệ thống AI, nghĩa là chi phí bị chi phối bởi ngữ cảnh mà người dùng không trực tiếp đưa vào. Các kỹ thuật giảm bớt sự phình to của ngữ cảnh vẫn còn mới, nhưng một số phương pháp đầy hứa hẹn đang được khám phá, chẳng hạn như:

Khi ngữ cảnh trở nên lớn, bộ nhớ đệm prompt (prompt caching) cũng đóng một vai trò quan trọng trong hiệu suất tổng thể. Cả LLM độc quyền và mã nguồn mở đều có các cài đặt cho phép bạn bật bộ nhớ đệm prompt và điều chỉnh thời gian lưu trữ bộ nhớ đệm. Việc ghi vào bộ nhớ đệm tốn tiền, nhưng việc đọc từ bộ nhớ đệm có thể giảm đáng kể chi phí trên mỗi lần suy luận. Sự đánh đổi này phụ thuộc vào khối lượng công việc cụ thể của công ty, vì vậy việc tinh chỉnh thủ công các cài đặt bộ nhớ đệm mặc định để tăng tỷ lệ truy cập bộ nhớ đệm có thể mang lại những cải thiện đáng kể về chi phí tổng thể.

Tại Databricks, việc tinh chỉnh tương đối đơn giản các cài đặt harness và bộ nhớ đệm của chúng tôi đã dẫn đến mức giảm gần 50% số lượng token được tạo và chi phí liên quan, mà không ghi nhận sự suy giảm chất lượng nào đối với các nhà phát triển. Chúng tôi tiếp tục khám phá các kỹ thuật trong lĩnh vực này và tin rằng vẫn còn khả năng tối ưu hóa đáng kể hơn nữa.

Giảm đáng kể số lượng token mỗi phiên bằng cách loại bỏ các lệnh gọi suy luận không cần thiết và giảm số lần ghi vào bộ nhớ đệm.

Mô hình thiết kế AI Gateway

Các kỹ thuật trên có nhiều yêu cầu kỹ thuật ngầm định: Để nhanh chóng tận dụng các mô hình mới, các công ty phải có một vị trí trung tâm nơi "thực đơn mô hình" được quản lý, và người dùng cuối phải có một chuỗi công cụ hỗ trợ trộn lẫn các mô hình. Để cung cấp khả năng hiển thị ngân sách trên nhiều công cụ AI, cần phải có khả năng quan sát chi phí thống nhất. Để quản lý sự phình to của ngữ cảnh, các công ty cần một cách để quan sát các đầu ra của lệnh gọi công cụ điển hình và thực thi việc nén hoặc rút gọn. Những nhu cầu này đang được giải quyết chung bởi một lớp phần mềm cơ sở hạ tầng mới, được mô tả tốt nhất là AI Gateway. Một AI Gateway là một vị trí trung tâm nơi tất cả các điều sau đây diễn ra:

Tại Databricks, chúng tôi dựa nhiều vào Unity AI Gateway cho tất cả các khả năng này.

Tổng kết lại

Sự tăng trưởng theo cấp số nhân của chi phí lập trình AI không phải là điều tất yếu, đó là một vấn đề về kỹ thuật và quản trị có thể giải quyết được. Các công ty đã chế ngự được nó đều chia sẻ một cuốn cẩm nang chung: không ngừng theo đuổi biên hiệu suất thay vì biên trí tuệ, áp dụng các công cụ bảo toàn sự linh hoạt của mô hình, định tuyến công việc một cách thông minh đến mô hình có khả năng phù hợp với chi phí thấp nhất, thay thế ngân sách cứng bằng khả năng hiển thị và ma sát tiến bộ, đồng thời cắt giảm chi phí token dư thừa vốn chiếm ưu thế trong chi tiêu thực tế. Không kỹ thuật nào trong số này đòi hỏi phải hy sinh những lợi ích về năng suất khiến việc áp dụng AI trở nên đáng giá ngay từ đầu; cùng với nhau, chúng cho phép các tổ chức thỏa mãn nhiệm vụ kép là truy cập rộng rãi, ít ma sát trong một hạn mức chi phí có thể dự đoán được.

Một tập hợp các trừu tượng cơ sở hạ tầng mới đang nổi lên để cung cấp cho các công ty các công cụ quản lý chi phí của họ. Tại Databricks, chúng tôi đã phát hành các thành phần chính trong ngăn xếp quản lý chi phí của mình dưới dạng mã nguồn mở hoặc sản phẩm phần mềm miễn phí: Unity AI Gateway để quản lý tập trung và Omnigent cho công cụ nhà phát triển. Hàng ngàn công ty sử dụng các thành phần này mỗi ngày. Chúng tôi mời thêm nhiều công ty chia sẻ các phát hiện và so sánh các kỹ thuật khi bối cảnh công nghệ này phát triển nhanh chóng.

Lời cảm ơn: Cảm ơn các nhà lãnh đạo cơ sở hạ tầng tại Uber, Stripe, Coinbase và Ramp đã cung cấp bình luận và đánh giá cho bài viết này. Cảm ơn Thrive Capital vì những phản hồi cho bản thảo đầu tiên của bài viết này.