Databricks dùng Astra cho 3.500 kỹ sư: bài học về model routing và chi phí AI

Nếu một công ty có quyền truy cập vào model AI mạnh hơn, có nên cho mọi người dùng nó cho mọi việc?

Databricks vừa đưa ra một câu trả lời khá thực tế:

Có thể mở quyền truy cập rộng — nhưng không nhất thiết biến model mạnh nhất thành model mặc định.

Patrick Wendell, đồng sáng lập và VP Engineering tại Databricks, cho biết công ty vừa cấp quyền sử dụng OpenAI Astra cho khoảng 3.500 kỹ sư.

Trước khi rollout rộng, Databricks đánh giá model bằng cả thử nghiệm offline và cohort online về chất lượng lẫn chi phí.

Kết quả đáng chú ý không chỉ là Astra mạnh hơn.

Nó là:

Astra mạnh hơn rõ ở một số công việc khó, nhưng gần như không tạo thêm giá trị ở nhiều công việc đơn giản hơn — trong khi chi phí có thể tăng mạnh nếu người dùng sử dụng không giới hạn.

Đây là một case khá đẹp về bài toán mà ngày càng nhiều doanh nghiệp sẽ gặp:

Khi có nhiều model tốt, nên dùng model nào cho từng công việc?

Mục lục

1. Astra tạo khác biệt ở task khó — không phải ở mọi task
2. Khi mở Astra không giới hạn, tổng token spend tăng khoảng 60%
3. Databricks không giải quyết bằng cách cấm Astra
4. Bước tiếp theo: để hệ thống tự chọn model
5. “Chọn model nào?” có thể dần trở thành câu hỏi của hạ tầng
6. Vấn đề khó nhất của routing không phải bảng giá
7. Từ AI tool sang AI operating model
8. Framework thực dụng cho doanh nghiệp
9. Điều đáng theo dõi tiếp

1. Astra tạo khác biệt ở task khó — không phải ở mọi task

Theo Patrick Wendell, Databricks nhận thấy Astra tạo ra một bước cải thiện đáng kể về năng suất lập trình và vượt các model công ty đang cung cấp trước đó, đặc biệt ở các tác vụ coding phức tạp hoặc kéo dài qua nhiều bước.

Nhưng ở những task có độ phức tạp thấp và trung bình, Databricks lại không thấy cải thiện đáng kể.

Lý do họ đưa ra khá đơn giản: nhiều task ở nhóm này vốn đã được các model hiện tại xử lý gần như rất tốt.

Đây là một điểm dễ bị bỏ qua trong cuộc đua model:

Năng lực cao hơn chỉ tạo thêm giá trị khi bài toán thực sự cần phần năng lực tăng thêm đó.

Một frontier model có thể vẫn “giỏi hơn” về mặt tổng thể.

Nhưng nếu cả model A và model B đều hoàn thành một việc đơn giản gần như hoàn hảo, phần năng lực tăng thêm của model A không còn tạo ra nhiều giá trị kinh doanh.

Có thể hình dung theo logic giá trị biên:

Task càng khó → khả năng suy luận thêm có thể tạo khác biệt lớn.
Task càng đơn giản → chất lượng dễ chạm trần sớm.
Khi chất lượng đã gần trần → chi phí tăng thêm khó được biện minh.

INTERPRETATION: Benchmark tổng thể “model nào đứng đầu” chưa đủ để quyết định model nào nên được dùng rộng trong doanh nghiệp.

Câu hỏi cần thêm là:

Model đó tốt hơn ở loại task nào, và phần tốt hơn có đáng với chi phí tăng thêm không?

2. Khi mở Astra không giới hạn, tổng token spend tăng khoảng 60%

Databricks thử cho một cohort khoảng 200 lập trình viên sử dụng Astra mà không có thêm guardrail về chi phí.

Theo Wendell, overall token spend của cohort tăng khoảng 60%.

Cần đọc con số này thật đúng.

Nó không có nghĩa:

Astra đắt hơn chính xác 60% trên mỗi request;
mọi task khi chuyển sang Astra sẽ tăng 60% chi phí;
productivity tăng hay giảm đúng theo tỷ lệ đó.

Đây là mức tăng tổng token spend quan sát được trong cohort thử nghiệm khi người dùng có Astra nhưng không có thêm cost guardrail.

Dù vậy, kết quả chỉ ra một vấn đề rất thực tế.

Nếu người dùng được đưa cho một model mạnh hơn mà không phải trực tiếp chịu trade-off chi phí, họ có rất ít động lực để dùng model yếu hơn.

Task khó → Astra.

Task vừa → Astra.

Sửa vài dòng → Astra.

Đổi format → vẫn Astra.

Từ góc nhìn cá nhân, lựa chọn đó có thể hoàn toàn hợp lý: người dùng muốn xác suất có kết quả tốt nhất.

Nhưng khi nhân hành vi này lên hàng nghìn người, một quyết định hợp lý ở cấp cá nhân có thể trở thành một cấu trúc chi phí không tối ưu ở cấp tổ chức.

3. Databricks không giải quyết bằng cách cấm Astra

Điểm thú vị nằm ở phản ứng của Databricks.

Công ty không khóa Astra chỉ cho một nhóm “được dùng model xịn”.

Họ cũng không mở hoàn toàn rồi hy vọng mọi người tự tiết kiệm token.

Thay vào đó, theo Wendell, mỗi developer được cấp một Astra-specific budget theo tháng, nằm trong ngân sách coding AI tổng thể.

Mục tiêu là khuyến khích người dùng dành Astra cho những task đủ khó để chi phí của nó được biện minh, thay vì biến Astra thành lựa chọn mặc định.

Databricks hiện cũng hỗ trợ cơ chế budget ở Unity Gateway như:

shared threshold;
per-user threshold;
per-user override;
cảnh báo khi gần hoặc vượt ngưỡng;
tùy chọn chặn usage khi chạm threshold;
theo dõi estimated spend gần thời gian thực.

Tài liệu Databricks cũng lưu ý đây là cơ chế quản trị dựa trên ước tính gần thời gian thực, không phải cam kết hóa đơn cuối cùng sẽ không bao giờ vượt đúng con số threshold.

Đây là chi tiết nhỏ nhưng rất đáng chú ý.

Cost guardrail không chỉ là công cụ của phòng tài chính.

Nó có thể trở thành một phần của thiết kế hành vi sử dụng AI.

Khi người dùng biết tài nguyên frontier model là hữu hạn, một câu hỏi bắt đầu xuất hiện tự nhiên:

Task này có thật sự cần Astra không?

4. Bước tiếp theo: để hệ thống tự chọn model

Ngân sách riêng vẫn yêu cầu developer tự quyết định khi nào nên dùng Astra.

Databricks muốn tiến thêm một bước.

Wendell cho biết Astra đang được đưa vào Unity Gateway Router, với mục tiêu để developer không còn phải chủ động quyết định lúc nào dùng Astra và lúc nào dùng model rẻ hơn.

Databricks đã có Smart Routing ở trạng thái Beta.

Theo tài liệu chính thức, Smart Routing tự động chọn model và agent harness dựa trên các yếu tố như:

độ phức tạp của task;
permissions;
budget.

Hệ thống ưu tiên đưa công việc thường quy sang model chi phí thấp hơn và giữ frontier model cho các bài toán khó.

Databricks cũng cho biết mỗi routing decision đều có thể quan sát và audit.

Trong benchmark nội bộ của Smart Routing, công ty báo cáo hệ thống đạt chất lượng ở mức frontier trong khi giảm overall task cost hơn 30%.

Hai con số cần được tách rõ:

+60% token spend: quan sát trong cohort Astra khoảng 200 developer không có guardrail.
>30% giảm task cost: benchmark nội bộ riêng của Smart Routing.

Đây không phải hai đầu của cùng một thử nghiệm.

Không nên suy ra router sẽ “bù lại 30% của mức tăng 60%”.

Nhưng khi đặt cạnh nhau, chúng cho thấy rất rõ vì sao Databricks muốn routing trở thành một phần của hạ tầng.

5. “Chọn model nào?” có thể dần trở thành câu hỏi của hạ tầng

Hiện tại, người dùng AI vẫn thường tự hỏi:

model nhanh hay model reasoning?
model rẻ hay frontier model?
GPT hay Claude?
model nào tốt cho coding?
model nào phù hợp với research?

Với người dùng kỹ thuật, khả năng chọn model còn được xem như một phần của “kỹ năng dùng AI”.

Nhưng model routing gợi ra một tương lai khác.

Người dùng chỉ cần nói:

Hãy giải quyết task này.

Hệ thống phía sau sẽ đánh giá:

Task thuộc loại gì?
Độ khó bao nhiêu?
Rủi ro nếu sai là gì?
Cần bao nhiêu context?
Người dùng được phép gọi model nào?
Ngân sách còn bao nhiêu?
Latency có quan trọng không?
Có thật sự cần frontier model không?

Sau đó mới route.

Nếu cách này hoạt động tốt, việc chọn model có thể dần giống chuyện chọn loại compute phù hợp cho một request backend:

rất quan trọng ở tầng hạ tầng, nhưng không phải quyết định mà người dùng cuối cần nghĩ tới mỗi lần.

6. Vấn đề khó nhất của routing không phải bảng giá

Nghe qua, routing khá đơn giản:

task dễ → model rẻ
task khó → model mạnh

Nhưng chữ “dễ” và “khó” mới là bài toán.

Một phân tích về model routing đưa ra ví dụ rất hay:

“Is the contract valid?”

Câu hỏi rất ngắn nhưng có thể yêu cầu context lớn, kiến thức chuyên môn và suy luận sâu.

Ngược lại, người dùng có thể gửi một tài liệu rất dài nhưng chỉ yêu cầu:

“Trích toàn bộ địa chỉ email.”

Prompt dài không đồng nghĩa task khó.

Prompt length ≠ task complexity.

Vì vậy router không thể chỉ nhìn:

số token đầu vào;
độ dài câu hỏi;
số file đính kèm.

Nó phải đánh giá loại công việc, mức suy luận cần thiết, rủi ro của sai sót và có thể cả lịch sử những lần model trước thất bại.

Một router đánh giá sai có hai kiểu hậu quả.

Route task dễ lên model mạnh

Chất lượng vẫn có thể tốt.

Nhưng doanh nghiệp lãng phí tiền và compute.

Route task khó xuống model yếu

Chi phí ban đầu thấp hơn.

Nhưng có thể xuất hiện:

output sai;
nhiều vòng sửa;
retry liên tục;
thời gian người dùng tăng;
downstream error;
cuối cùng tổng chi phí còn cao hơn.

Vì vậy model routing thực chất là bài toán tối ưu nhiều biến:

Quality × Cost × Latency × Risk

chứ không chỉ là Cost.

7. Từ AI tool sang AI operating model

Unity Gateway cho thấy Databricks không chỉ nghĩ về model selection.

Nền tảng này đang đóng vai trò gần giống một control plane cho AI: quản lý model, agent, tool, quyền, budget, routing và observability.

Điều này kết nối khá đẹp với một bài toán lớn hơn trong automation.

Trong workflow thực tế, không phải bước nào cũng nên được giao cho agent.

Có ba nhóm tương đối dễ hình dung:

Deterministic

Logic được định nghĩa trước.

Phù hợp khi cần:

tính dự đoán;
audit;
compliance;
kiểm soát trạng thái rõ.

Dynamic

Workflow thay đổi theo điều kiện runtime nhưng vẫn có logic kiểm soát tương đối rõ.

Phù hợp khi dữ liệu hoặc workload thay đổi thường xuyên.

Agentic

Giao phần không cấu trúc hoặc khó dự đoán cho agent đánh giá và hành động.

Đổi lại, cần nhiều hơn:

guardrail;
validation;
observability;
approval gate;
fallback.

INTERPRETATION: Doanh nghiệp trưởng thành với AI có thể sẽ không “agent hóa” mọi thứ.

Họ sẽ giữ phần predictable bằng workflow deterministic và dùng agent/model mạnh ở đúng những đoạn thật sự cần phán đoán.

Model routing là cùng một tư duy ở một lớp khác:

Không phải mọi request đều đáng tiêu cùng một mức intelligence.

8. Framework thực dụng cho doanh nghiệp

Từ case Databricks, có thể rút ra một chuỗi khá đơn giản:

Request
↓
Phân loại task
↓
Đánh giá complexity + risk
↓
Kiểm tra permission + budget
↓
Route model / agent phù hợp
↓
Cấp đúng context + tools
↓
Thực thi
↓
Validate output
↓
Log quality + cost + latency + outcome
↓
Cập nhật routing policy

Điểm quan trọng nhất là vòng lặp cuối.

Nếu hệ thống chỉ route nhưng không đo kết quả, nó không biết mình route đúng hay sai.

Một routing policy tốt cần học từ dữ liệu thực:

model nào thường đủ cho từng task type;
task nào hay cần escalation;
lỗi nào xảy ra khi dùng model rẻ;
frontier model tạo thêm bao nhiêu giá trị;
thời gian người dùng tiết kiệm được bao nhiêu;
chi phí mỗi correct outcome là bao nhiêu.

Đây là lý do “giá token” chỉ là một phần.

Một model rẻ nhưng cần ba lần retry có thể đắt hơn một model mạnh làm đúng ngay lần đầu.

Ngược lại, dùng frontier model để phân loại 10.000 ticket đơn giản cũng là lãng phí rõ ràng.

9. Điều đáng theo dõi tiếp

Databricks cho biết Astra đang được đưa vào Unity Gateway Router, nhưng hiện chúng ta chưa có dữ liệu công khai đủ chi tiết để biết:

bao nhiêu phần trăm task sẽ thực sự được route lên Astra;
router dùng những signal nào để đánh giá complexity;
khi task ban đầu tưởng dễ nhưng thất bại, hệ thống escalation ra sao;
chi phí trên mỗi task đúng thay đổi thế nào;
productivity tăng bao nhiêu sau khi tính cả thời gian review;
developer có còn muốn tự override routing hay không.

Đó mới là phần thú vị.

Nếu router tốt, người dùng sẽ được hưởng frontier intelligence khi thật sự cần mà gần như không cần nghĩ đến model.

Nếu router không tốt, những trường hợp “task nhìn đơn giản nhưng hóa ra rất khó” sẽ trở thành điểm yếu lớn.

Và vì vậy, câu hỏi đáng theo dõi trong thời gian tới có lẽ không còn là:

“Model mới mạnh hơn bao nhiêu?”

Mà là:

“Doanh nghiệp có biết lúc nào sức mạnh đó thực sự đáng tiền không?”

Astra for Law cho thấy cách chuyên môn hóa một frontier model.

Case Databricks cho thấy cách phân bổ frontier model trong một tổ chức lớn.

Hai câu chuyện cùng chỉ về một hướng:

Lợi thế đang dịch chuyển từ việc sở hữu model mạnh sang khả năng xây đúng hệ thống xung quanh model — evaluation, routing, context, tools, budget, permission và governance.

Đó có thể là một trong những thay đổi quan trọng nhất khi AI đi từ công cụ cá nhân sang hạ tầng vận hành thực sự.

Databricks cho 3.500 kỹ sư dùng Astra — nhưng model mạnh nhất không phải để dùng cho mọi việc