Model mở đang đổi bàn họp AI

Model mở đang đổi bàn họp AI

Kimi K3, DeepSeek V4 Pro và GLM-5.2 không chỉ là cuộc đua benchmark. Tín hiệu thật nằm ở quyền chọn vận hành của team builder.

“Chọn model nào cho agent coding quý này?” — nếu câu này xuất hiện trong weekly planning của team bạn, khả năng cao 10 phút sau mọi người đã mở leaderboard, soi điểm benchmark, rồi ai đó thả một câu: “Model mới nhất chắc ngon nhất.”

Mình hiểu cảm giác đó. Release mới nhìn rất cuốn, nhất là khi ba cái tên Kimi K3, DeepSeek V4 Pro và GLM-5.2 cùng kéo cuộc đua open-weight lên vùng trillion-scale. Nhưng nếu bạn là developer hoặc tech lead đang phải chạy hệ thống thật, câu hỏi không phải “model nào mạnh nhất?”. Câu hỏi đáng tiền hơn là: model nào làm đổi vị thế đàm phán của team bạn?

Đây là tín hiệu thị trường thú vị: open-weight không còn chỉ là phương án “rẻ hơn một chút, tự lo nhiều hơn một chút”. Nó đang trở thành một nhánh chiến lược đủ nghiêm túc để ép cả cloud API, inference provider, và team nội bộ phải nói chuyện bằng chi phí, license, latency, throughput, observability — không chỉ bằng điểm số.

Sơ đồ minh họa cho bài Model mở đang đổi bàn họp AI

Sơ đồ tóm tắt ý chính của bài viết.

Tranh luận sai: “chọn model thắng benchmark”

Ba model trong cuộc đua này đều thuộc nhóm Mixture-of-Experts, viết tắt MoE — kiến trúc nhiều “expert” nhưng mỗi token chỉ kích hoạt một phần, giúp model rất lớn trên giấy mà chi phí chạy mỗi lượt không phình theo toàn bộ tham số. Kimi K3 được mô tả là 2.8T parameters, DeepSeek V4 Pro là 1.6T với 49B active parameters, còn GLM-5.2 là 744B với khoảng 40B active parameters. Cả ba đều nhắm vào workload dài hơi như coding agent và agent có ngữ cảnh lớn.

Trên Artificial Analysis Intelligence Index được nguồn chính nhắc tới, Kimi K3 khoảng 57 điểm, GLM-5.2 khoảng 51, DeepSeek V4 Pro Max reasoning khoảng 44. Nếu chỉ nhìn vậy, có vẻ quyết định xong rồi: chọn Kimi.

Nhưng bàn họp kỹ thuật mà chốt kiểu đó thì hơi giống onboarding nhân viên mới chỉ vì CV đẹp. CV quan trọng, nhưng tuần sau bạn vẫn phải xem bạn ấy có vào đúng repo, hiểu ticket, dùng đúng quyền truy cập, và không làm sập staging không.

Với model cũng vậy. Benchmark là tín hiệu năng lực, không phải hợp đồng vận hành.

Biến số 1: active parameters mới là hóa đơn ngầm

Active parameters là số tham số thật sự được kích hoạt khi model xử lý token. Với MoE, tổng parameters giống quy mô cả công ty; active parameters giống số người thật sự được gọi vào một cuộc họp. Công ty 2.8T người nghe hoành tráng, nhưng cuộc họp mỗi token chỉ mời một nhóm nhỏ.

Điểm này ảnh hưởng trực tiếp đến serving cost — chi phí phục vụ inference. Một model tổng rất lớn chưa chắc tốn tương ứng nếu active set hợp lý, nhưng cũng không có nghĩa tự động rẻ. Bạn còn phải tính:

Ví dụ cụ thể: giả sử team bạn có một coding agent đọc issue, mở nhiều file, chạy tool, rồi viết patch. Nếu mỗi lượt agent kéo context rất dài, chi phí không chỉ nằm ở “model mạnh”. Nó nằm ở tổng token vào/ra, số lần tool loop, và khả năng giữ latency ổn định khi nhiều developer dùng cùng lúc. Một model benchmark cao nhưng throughput thấp trong giờ cao điểm có thể làm team ghét sản phẩm chỉ sau hai ngày.

Đây là lý do Together AI khoe năng lực inference, GPU clusters, serverless, dedicated inference và các dòng B200/GB200 không phải chuyện phụ. Khi open model lớn lên, người hưởng lợi không chỉ là lab tạo model. Nhà cung cấp hạ tầng inference cũng có thêm đất diễn, vì rất ít team muốn tự ôm toàn bộ bài toán serving trillion-scale từ ngày đầu.

Biến số 2: context window dài không tự biến thành trí nhớ tốt

Cả ba model được nhắc tới đều có context window cỡ triệu token — vùng ngữ cảnh model có thể nhận trong một lượt xử lý. Đây là con số dễ gây phấn khích, nhất là với agent coding: nhét cả repo, cả spec, cả log vào một lần nghe rất đã.

Nhưng context dài không đồng nghĩa retrieval tốt. Model chỉ xử lý thứ bạn đưa vào; còn đưa nhầm tài liệu thì vẫn lạc. NVIDIA ra Nemotron 3 Embed nhắm vào production-scale RAG, agentic retrieval, code retrieval và agent memory là tín hiệu rất rõ: thị trường đang nhận ra lớp “chọn tài liệu nào cho model xem” quan trọng chẳng kém lớp “model trả lời hay không”.

Embedding model là model biến văn bản thành vector để tìm kiếm ngữ nghĩa. Nếu nó chọn sai đoạn code hoặc sai tài liệu, agent của bạn giống một đồng nghiệp được brief lệch: rất chăm, rất tự tin, nhưng làm đúng thứ không ai cần.

Hình dung thế này: bạn giao một task “sửa bug thanh toán”, nhưng người được giao chỉ đọc tài liệu marketing và changelog frontend. Người đó có thể viết rất mượt, nhưng khả năng cao không sửa đúng bug. Với AI system, embedding và retrieval là bước đưa đúng hồ sơ vào bàn làm việc trước khi model bắt đầu suy luận.

Vì vậy, nếu team đang tranh luận Kimi K3 hay GLM-5.2, hãy thêm một câu hỏi song song: retrieval stack hiện tại có đủ tốt để tận dụng context dài chưa? Nếu chưa, nâng model có thể chỉ làm hệ thống trả lời sai dài hơn.

Biến số 3: license và deployment là quyền thương lượng

Open-weight không phải lúc nào cũng đồng nghĩa “muốn làm gì thì làm”. License quyết định bạn có thể dùng thương mại ra sao, có giới hạn gì, có phải tuân điều khoản riêng không. Với builder, license không phải giấy tờ cuối sprint mới đọc; nó là constraint kiến trúc.

Ở phía enterprise, Google Cloud nhấn mạnh Claude chạy trong môi trường quen thuộc như IAM, VPC Service Controls, observability và vùng dữ liệu. Đây là tín hiệu ngược lại từ phe managed frontier model: “Bạn trả tiền để bớt vận hành.”

Vậy thị trường đang chia thành ba bàn chọn:

| Hướng | Bạn mua được gì | Bạn phải chịu gì | Hợp với ai |
|---|---|---|---|
| Frontier API managed | Vận hành gọn, compliance, observability có sẵn | Vendor lock-in, giá theo usage, ít kiểm soát weights | Team cần ship nhanh, dữ liệu có quy trình cloud rõ |
| Open-weight qua inference provider | Linh hoạt hơn, chọn model nhanh, không tự quản GPU sâu | Phụ thuộc provider, cần đo latency/cost riêng | Team muốn thử nhiều model nhưng chưa muốn self-host |
| Self-host open-weight | Kiểm soát cao, tối ưu sâu, dữ liệu ở hạ tầng mình | DevOps nặng, cần năng lực serving, monitoring, capacity planning | Team có workload lớn và đội infra đủ lực |

Điểm đáng nói: sự xuất hiện của open MoE lớn làm lựa chọn thứ hai và thứ ba mạnh hơn trước. Nó ép nhà cung cấp API đóng phải chứng minh giá trị bằng độ ổn định, compliance, toolchain, và SLA — không chỉ bằng “model của tôi thông minh hơn”.

Khi nào chọn Kimi, DeepSeek, GLM — và khi nào đừng chọn cả ba

Nếu đang build coding agent hoặc agent workflow dài, mình sẽ không bắt đầu bằng câu “model nào top?”. Mình sẽ chia quyết định thành bốn ô:

1. Workload có thật sự cần long context không?
Nếu agent chủ yếu xử lý ticket ngắn, gọi tool rõ ràng, output vừa phải, model nhỏ hơn hoặc biến thể rẻ hơn có thể đủ. DeepSeek có nhắc V4 Flash cho workload rẻ hơn; đây là kiểu lựa chọn đáng test nếu bạn cần cost discipline.

2. Bottleneck nằm ở reasoning hay retrieval?
Nếu agent hay chọn sai file, sai doc, sai memory, hãy xử lý embedding/retrieval trước. Nemotron 3 Embed là một tín hiệu rằng lớp này đang được đầu tư mạnh, không còn là phần phụ.

3. Bạn có đội vận hành inference không?
Nếu chưa có monitoring token-level, latency percentile, queueing, cache, autoscaling, fallback model, thì self-host trillion-scale dễ biến thành một OKR nhìn đẹp nhưng cả quý chỉ đi chữa cháy.

4. License có qua được legal/compliance không?
Đừng để đến lúc pilot thành công mới phát hiện điều khoản dùng thương mại không hợp với sản phẩm. Với AI production, legal review nên đi cùng technical evaluation, không phải đứng cuối hàng.

Một bài test gọn trong một buổi chiều:

Chọn 20 task thật từ backlog hoặc log người dùng
Với mỗi model/provider:
- Chạy cùng prompt, cùng retrieval input
- Ghi latency p50/p95 nếu có
- Ghi token input/output
- Chấm pass/fail theo tiêu chí task, không chấm cảm tính
- Ghi lỗi: sai file, thiếu bước, bịa API, tool loop quá lâu
Sau đó tính: cost/task thành công, không phải cost/request

Chỉ số cost/task thành công thường làm cuộc tranh luận hạ nhiệt rất nhanh. Model rẻ nhưng fail nhiều chưa chắc rẻ. Model mạnh nhưng cần context khổng lồ cho task đơn giản cũng chưa chắc khôn.

Tín hiệu thị trường: model mở đang ép mọi người làm thật hơn

Điều mình thấy đáng bàn không phải là “Trung Quốc đang dẫn open-weight leaderboard” — dù đó là tín hiệu lớn. Điều thực dụng hơn là: open-weight frontier đang biến model selection thành bài toán procurement + infra + eval, chứ không còn là lựa chọn thư viện trong file config.

Hugging Face nói về delta weight sync trong TRL cũng cùng một mạch: khi model quá lớn, việc ship nguyên weights mỗi bước training/inference coupling trở nên vô lý. Họ mô tả cách chỉ đồng bộ phần weight thay đổi, giảm payload từng bước trong ví dụ của họ từ mức GB xuống MB trên Qwen3-0.6B. Đó không phải chi tiết màu mè; đó là dấu hiệu hệ sinh thái đang tối ưu quanh thực tế “model lớn thì vận hành mới là trận chính”.

Sau bài này, điểm mình muốn bạn nghĩ khác là: đừng hỏi model nào đang ồn ào nhất; hãy hỏi lựa chọn đó làm team bạn có thêm hay mất bớt quyền kiểm soát ở đâu.

Nếu là mình, mình sẽ chọn như sau: dùng benchmark để shortlist, dùng license để loại rủi ro, dùng serving test để biết hóa đơn thật, và dùng eval theo task nội bộ để chốt. Leaderboard là lời mời vào phòng họp, không phải biên bản quyết định.

Chốt lại: model mới có thể rất sáng sân khấu, nhưng production thì vẫn hỏi câu rất văn phòng — “ai chịu trách nhiệm khi nó trễ deadline?”

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo