Chuyến đi vào phòng máy AI của Alibaba. Qwen 3.8-Max cho thấy benchmark chưa nói hết chi phí

Sapo

Nếu chỉ nhìn bảng benchmark, thế giới AI có vẻ rất dễ hiểu. Model nào đạt điểm cao hơn thì mạnh hơn. Model nào rẻ hơn thì tiết kiệm hơn. Nhưng khi đưa AI vào một nhiệm vụ thực tế, đặc biệt là coding agent và các hệ thống phải tự suy luận trong thời gian dài, hai giả định đó bắt đầu vỡ ra.

Qwen 3.8-Max là một ví dụ rất rõ. Một số kết quả do Alibaba công bố cho thấy model này tiến sát nhóm dẫn đầu. Nhưng một bài kiểm thử độc lập lại đưa phiên bản chạy mặc định xuống cuối bảng. Cả hai kết quả đều có thể đúng.

Điểm khác biệt nằm ở thứ thường bị giấu dưới bảng xếp hạng: AI được phép suy nghĩ bao lâu, sử dụng bao nhiêu token và được thử bao nhiêu lần để hoàn thành một nhiệm vụ.

Đó không còn là chi tiết kỹ thuật nhỏ.

Nó đang trở thành một trong những biến số quan trọng nhất của kinh tế AI.

Tin tức chính vừa xảy ra

Alibaba đưa Qwen 3.8-Max vào cuộc đua các mô hình AI có khả năng thực hiện những nhiệm vụ phức tạp, đặc biệt trong coding và agentic workflow.

Thông điệp ban đầu khá mạnh: Qwen được đặt vào nhóm cạnh tranh trực tiếp với những mô hình hàng đầu như Claude Opus 5.

Nhưng khi nhìn sang các bài kiểm thử độc lập, bức tranh trở nên phức tạp hơn.

Trong một phép đo bằng VulcanBench, phiên bản Qwen 3.8-Max ở cấu hình mặc định có kết quả rất thấp. Khi chuyển sang cấu hình nỗ lực cao hơn, kết quả cải thiện đáng kể nhưng vẫn chỉ nằm ở nhóm giữa.

Vấn đề nằm ở thời gian.

Các bài kiểm thử của Alibaba cho phép một nhiệm vụ coding chạy trong thời gian dài hơn rất nhiều. Một số tác vụ có thời gian chờ lên tới nhiều giờ. Trong khi đó, VulcanBench giới hạn mỗi lần chạy trong khoảng 45–60 phút.

Nếu một agent được phép làm việc lâu hơn từ 5 đến 16 lần, nó rõ ràng có một sân chơi hoàn toàn khác.

Và đây chính là nơi câu chuyện trở nên thú vị.

Benchmark không chỉ đo model. Nó đo cả cách chúng ta cho model làm việc.

Điều gì mới?

Trong thế hệ AI đầu tiên, người dùng thường gửi một câu hỏi và nhận lại một câu trả lời.

Chi phí khá dễ hình dung.

Bạn có bao nhiêu token đầu vào, bao nhiêu token đầu ra, từ đó ước tính được hóa đơn.

Nhưng reasoning model và AI agent đã thay đổi kiến trúc này.

Một agent có thể đọc hàng trăm file. Chạy test. Nhận lỗi. Sửa code. Chạy lại. Tìm tài liệu. Thử phương án khác. Gọi thêm công cụ. Suy luận thêm một vòng.

Cuối cùng, thứ doanh nghiệp quan tâm không phải là agent đã tạo ra bao nhiêu token.

Họ muốn biết:

Nhiệm vụ có hoàn thành hay không?

Đây là sự thay đổi rất quan trọng.

Một mô hình có thể tiêu tốn rất nhiều token nhưng hoàn thành nhiệm vụ với tỷ lệ cao. Một mô hình khác sử dụng ít token hơn nhưng thất bại thường xuyên.

Nếu chỉ nhìn giá trên mỗi triệu token, bạn có thể chọn sai.

Nếu chỉ nhìn benchmark accuracy, bạn cũng có thể chọn sai.

Thước đo thực tế hơn là:

Chi phí trên mỗi nhiệm vụ thành công.

Tại sao nó quan trọng?

Hãy tưởng tượng bạn giao cho một kỹ sư AI nhiệm vụ sửa một lỗi trong hệ thống thanh toán.

Agent chạy trong 20 phút và thất bại.

Bạn chạy lại bằng cấu hình reasoning cao hơn. Nó tiêu tốn nhiều tài nguyên hơn nhưng vẫn timeout.

Sau đó bạn chuyển sang model khác. Nhiệm vụ hoàn thành.

Nếu kế toán chỉ nhìn token của từng lần chạy, câu chuyện sẽ rất khó hiểu.

Nhưng nếu tính toàn bộ chi phí của các lần thử thất bại rồi chia cho số nhiệm vụ thực sự vượt qua acceptance test, bức tranh lập tức rõ ràng.

Đó là lý do cost per successful task quan trọng.

Một hệ thống AI có thể có:

• tỷ lệ thành công cao;
• thời gian xử lý dài;
• lượng token lớn;
• nhiều lần retry;

nhưng vẫn đáng sử dụng nếu nó tạo ra giá trị lớn hơn tổng nguồn lực bỏ ra.

Ngược lại, một model có token rất rẻ nhưng thường xuyên thất bại có thể trở thành lựa chọn đắt hơn trong vận hành thực tế.

AI đang chuyển từ bài toán inference pricing sang bài toán unit economics của nhiệm vụ.

Sản phẩm hoạt động thế nào?

Hãy hình dung một AI agent giống một nhân viên kỹ thuật mới bước vào một tòa nhà văn phòng.

Chatbot chỉ cần trả lời câu hỏi.

Agent thì phải biết đi đâu.

Nó cần mở repository, tìm file, đọc dependency, hiểu cấu trúc hệ thống, sửa code, chạy test và xử lý những thứ phát sinh.

Trong môi trường đó, thời gian trở thành một tài nguyên.

Qwen 3.8-Max cho thấy rõ điều này.

Một cấu hình reasoning cao hơn có thể giúp model giải quyết những bài toán khó hơn. Nhưng reasoning nhiều hơn cũng đồng nghĩa với việc agent có thể tiêu tốn nhiều token hơn và mất nhiều thời gian hơn.

Và đó là nghịch lý.

Thêm khả năng suy luận không phải lúc nào cũng làm nhiệm vụ hoàn thành tốt hơn.

Trong một số trường hợp, agent suy nghĩ quá lâu và hết thời gian trước khi hoàn thành.

Claude Opus 5 cũng cho thấy hiện tượng tương tự trong các thử nghiệm của VulcanBench.

Ở cấu hình effort thấp, model giải quyết được 20 trên 23 nhiệm vụ. Ở effort cao, con số này giảm xuống 18.

Cấu hình cao có lợi thế: số câu trả lời sai ít hơn.

Nhưng nó timeout nhiều hơn.

Một nhiệm vụ timeout được tính là thất bại.

Vậy nên một model “thông minh hơn” ở cấp độ reasoning lại có thể tạo ra kết quả kinh tế kém hơn.

Dữ liệu nằm ở đâu?

Đây là phần thú vị nhất của câu chuyện.

Dữ liệu không chỉ nằm trong model.

Nó nằm trong toàn bộ hành trình agent thực hiện nhiệm vụ.

Một phiên coding agent có thể tạo ra:

• prompt;
• reasoning tokens;
• tool calls;
• kết quả compiler;
• test failures;
• file modifications;
• retry;
• thời gian chờ;
• kết quả cuối cùng.

Nếu doanh nghiệp chỉ lưu câu trả lời cuối, họ mất phần lớn thông tin cần thiết để tối ưu hệ thống.

Một agent thất bại vì code sai hoàn toàn khác agent thất bại vì hết thời gian.

Nhưng nhiều harness hiện nay vẫn ghi cả hai đơn giản là “failure”.

Đây là một vấn đề kiến trúc dữ liệu.

Muốn tối ưu AI agent, doanh nghiệp phải biến failure reason thành dữ liệu cấp một.

Ví dụ:

budget_exhaustion

verifier_failure

harness_error

model_error

Khi đó đội kỹ thuật mới biết cần cải thiện model, prompt, harness hay giới hạn tài nguyên.

Doanh nghiệp kiếm tiền và tạo giá trị thế nào?

AI agent không tạo giá trị vì nó sinh ra nhiều code hơn.

Nó tạo giá trị khi giảm thời gian từ yêu cầu → sản phẩm chạy được.

Đó là khác biệt rất lớn.

Một doanh nghiệp phần mềm không cần thêm một triệu dòng code. Họ cần một tính năng hoàn thành.

Một ngân hàng không cần thêm token. Họ cần một quy trình được tự động hóa mà không tạo ra rủi ro mới.

Một công ty thương mại điện tử không cần model “thông minh” trên bảng xếp hạng. Họ cần agent có thể sửa một lỗi trong checkout mà không phá hệ thống thanh toán.

Vì vậy, đơn vị kinh tế mới của AI có thể không phải token.

Nó là outcome.

Đây cũng là lý do nhiều sản phẩm AI doanh nghiệp đang chuyển dần sang tư duy tính giá trị theo kết quả được xử lý hoặc nhiệm vụ hoàn thành.

Từ góc nhìn doanh nghiệp, đây là bước trưởng thành tự nhiên.

Software-as-a-Service từng chuyển từ bán phần mềm sang bán quyền truy cập.

AI agent có thể đi xa hơn.

Bán kết quả thay vì bán năng lực.

Platform hay product?

Qwen 3.8-Max về bản chất là model.

Nhưng khi đặt model vào một agent harness, câu chuyện thay đổi.

Harness quyết định:

• agent được gọi công cụ nào;
• có bao nhiêu thời gian;
• được retry bao nhiêu lần;
• context được nén thế nào;
• failure được xử lý ra sao;
• task có được chia nhỏ hay không.

Nói cách khác, model là động cơ.

Harness là hệ thống truyền động.

Một động cơ mạnh nhưng truyền động kém không tạo ra chiếc xe tốt.

Đây là lý do benchmark giữa các model ngày càng khó đọc nếu không biết chúng được chạy trong môi trường nào.

Trong tương lai, lợi thế cạnh tranh có thể không nằm hoàn toàn ở model.

Nó nằm ở model + harness + dữ liệu + routing + evaluation + governance.

Đó mới là platform thực sự.

Đối thủ và lợi thế cạnh tranh

Qwen 3.8-Max đang bước vào một sân chơi có nhiều đối thủ mạnh.

Claude Opus 5 có lợi thế rõ ràng trong các benchmark được đề cập.

OpenAI tiếp tục phát triển Codex.

Google có hệ sinh thái Gemini và các công cụ dành cho developer.

Cursor và những sản phẩm tương tự lại đứng ở lớp trải nghiệm, nơi model được kết hợp với editor, context và workflow.

Nhưng cuộc cạnh tranh không còn đơn giản là:

Model A thông minh hơn Model B.

Nó đang trở thành:

Hệ thống A hoàn thành một nhiệm vụ thực tế với ít tài nguyên hơn hệ thống B.

Đây là cuộc cạnh tranh khó hơn nhiều.

Một model có benchmark thấp hơn vẫn có thể thắng nếu routing tốt hơn.

Một model mạnh hơn vẫn có thể thua nếu timeout thường xuyên.

Và một model cực kỳ mạnh vẫn có thể bị doanh nghiệp từ chối nếu dữ liệu, bảo mật hoặc khả năng kiểm soát không đáp ứng yêu cầu.

Rủi ro

Rủi ro đầu tiên là đánh đồng benchmark với năng lực sản xuất.

Một benchmark được thiết kế trong 60 phút không nhất thiết phản ánh hệ thống cần chạy trong 24 giờ.

Nhưng ngược lại, một benchmark cho agent hàng giờ cũng không đại diện cho ứng dụng cần phản hồi trong vài giây.

Vì vậy, benchmark phải gắn với workload thực tế.

Rủi ro thứ hai là routing sai.

Nếu hệ thống mặc định luôn chuyển sang reasoning cao khi task thất bại, doanh nghiệp có thể vô tình leo lên một “bậc thang” đắt hơn chỉ để đi đến một timeout.

Rủi ro thứ ba là agent quá tự chủ.

Đây là nơi câu chuyện chi phí gặp câu chuyện bảo mật.

Một agent có quyền đọc dữ liệu riêng tư, tiếp nhận nội dung không đáng tin cậy và có quyền gửi dữ liệu ra bên ngoài có thể tạo thành một tổ hợp nguy hiểm.

Trong nghiên cứu doanh nghiệp được đề cập trong cùng chuỗi phân tích, 69% tổ chức được khảo sát vẫn có credential sharing ở đâu đó trong hệ thống agent. Những tổ chức có shared credentials ghi nhận tỷ lệ sự cố hoặc near-miss cao hơn đáng kể so với nhóm sử dụng identity riêng và có phạm vi quyền hạn rõ ràng.

Một con số khác còn đáng chú ý hơn: 88% cho biết họ chưa có khả năng rollback hành động của agent mà không gây gián đoạn hệ thống.

Đó là một khoảng trống rất lớn.

Bạn có thể cho AI quyền tự hành.

Nhưng nếu không thể quay ngược hành động của nó, tự hành có thể biến thành rủi ro vận hành.

Việt Nam sẽ bị tác động thế nào?

Việt Nam có một vị trí đặc biệt trong cuộc chuyển dịch này.

Một nền kinh tế có lực lượng kỹ sư phần mềm lớn, nhiều doanh nghiệp outsourcing, SaaS, fintech, thương mại điện tử và startup sẽ hưởng lợi trực tiếp từ AI coding agent.

Nhưng lợi ích lớn nhất không nhất thiết nằm ở việc giảm số lập trình viên.

Nó nằm ở việc một kỹ sư có thể quản lý nhiều công việc hơn.

Một developer có thể giao cho agent:

• viết test;
• phân tích log;
• cập nhật dependency;
• tạo migration;
• viết documentation;
• refactor module;
• sửa lỗi nhỏ;
• kiểm tra regression.

Những công việc này chiếm rất nhiều thời gian nhưng không phải lúc nào cũng cần tư duy kiến trúc cấp cao.

AI có thể hấp thụ phần việc đó.

Điều này đặc biệt quan trọng với doanh nghiệp Việt Nam đang thiếu kỹ sư senior.

AI agent có thể trở thành một lớp “đòn bẩy” giúp kỹ sư senior quản lý nhiều task hơn mà không phải tự tay thực hiện từng thao tác.

Nhưng có một mặt trái.

Nếu doanh nghiệp đưa source code, dữ liệu khách hàng hoặc thông tin nội bộ vào agent mà không kiểm soát identity, logging và quyền truy cập, tốc độ phát triển có thể tăng trong khi rủi ro cũng tăng theo.

Doanh nghiệp Việt Nam nên làm gì?

Điều đầu tiên là đừng chọn model chỉ bằng leaderboard.

Hãy lấy 50–100 nhiệm vụ thực tế của chính doanh nghiệp.

Sau đó chạy nhiều model và nhiều effort level.

Đo ít nhất bốn thứ:

Tỷ lệ hoàn thành.

Thời gian hoàn thành.

Tổng tài nguyên đã sử dụng.

Chi phí trên mỗi nhiệm vụ thành công.

Quan trọng nhất, phải tính cả những lần thất bại.

Nếu agent chạy ba lần mới hoàn thành, cả ba lần đều thuộc economics của nhiệm vụ đó.

Thứ hai, hãy tách timeout khỏi lỗi logic.

Nếu 70% thất bại đến từ timeout, đừng vội đổi model. Có thể vấn đề nằm ở budget hoặc harness.

Thứ ba, bắt đầu từ những workload có rủi ro thấp.

Internal tools, test generation, documentation và refactoring là những điểm khởi đầu tốt.

Những hệ thống như thanh toán, tài chính, dữ liệu khách hàng và production infrastructure cần lớp kiểm soát nghiêm ngặt hơn.

Thứ tư, xây identity riêng cho từng agent.

Đừng để một agent có quyền “đi khắp công ty”.

Quyền đọc database không đồng nghĩa với quyền gửi email.

Quyền sửa Git repository không đồng nghĩa với quyền triển khai production.

Kiến trúc permission phải được thiết kế theo nhiệm vụ, không chỉ theo ứng dụng.

Cuối cùng, doanh nghiệp cần lưu toàn bộ trace của agent.

Khi một agent gây lỗi, câu hỏi quan trọng không phải chỉ là:

“AI làm sai ở đâu?”

Mà phải là:

“AI đã quyết định như thế nào để đi đến hành động đó?”

Kết luận

Chuyến đi vào thế giới AI agent cho chúng ta một bài học khá đơn giản nhưng dễ bị bỏ qua.

Model score không phải business outcome.

Qwen 3.8-Max có thể đứng rất cao hoặc rất thấp tùy cách bạn cho nó làm việc. Claude Opus 5 cũng có thể cho kết quả khác nhau đáng kể giữa các mức effort.

Điều đó không có nghĩa benchmark vô dụng.

Nó có nghĩa benchmark cần được đọc cùng với thời gian, token budget, effort, harness và tỷ lệ thất bại.

Trong kỷ nguyên chatbot, câu hỏi là:

Model này thông minh đến đâu?

Trong kỷ nguyên agent, câu hỏi đang chuyển thành:

Model này hoàn thành được bao nhiêu nhiệm vụ, trong bao lâu và với bao nhiêu nguồn lực?

Đó là một thay đổi về kiến trúc chứ không chỉ là thay đổi về cách đo lường.

Và khi AI bắt đầu tự viết code, tự gọi công cụ, tự sửa lỗi, tự gửi dữ liệu và tự thực hiện hàng chục bước liên tiếp, doanh nghiệp sẽ phải đo cả hai mặt của phương trình.

Hiệu suất tạo ra giá trị.

Governance bảo đảm giá trị đó không biến thành rủi ro.

Cuối cùng, cuộc đua AI có thể không thuộc về model có bảng điểm đẹp nhất.

Nó sẽ thuộc về hệ thống biết biến một model thành một cỗ máy hoàn thành công việc — nhanh đủ, rẻ đủ, đáng tin đủ và quan trọng nhất, có thể kiểm soát được.

ừ khóa SEO

Qwen 3.8-Max, Claude Opus 5, AI agent, AI coding agent, benchmark AI, chi phí AI, AI reasoning, token AI, cost per task, AI doanh nghiệp, agent orchestration, AI infrastructure, AI automation, Terminal-Bench, VulcanBench, AI governance, bảo mật AI, AI Việt Nam, AI enterprise