Model mới không phải món chính

Model mới không phải món chính

LongCat-2.0 rất đáng chú ý, nhưng bài học cho builder không phải “chọn model to nhất”. Thứ cần nhìn là menu năng lực: context, cache, routing và workload.

“Nếu model có 1M context thì mình nhét cả repo, toàn bộ log, PRD, ticket Jira vào cho nó tự xử được chưa?”

Câu hỏi này nghe rất hợp lý. Mình cũng từng thấy một team nói gần y chang trong một buổi review kiến trúc: đã có context window lớn thì khỏi cần chia tài liệu, khỏi cần retrieval, khỏi cần nghĩ nhiều về memory. Gọi một phần thật to là no bụng.

Nhưng LongCat-2.0 của Meituan làm mình muốn phản biện nhẹ: điểm đáng bàn không phải model này “khủng” cỡ nào, mà là nó đang báo hiệu một cách chọn model mới cho builder. Không chọn theo tên món đang hot, mà chọn theo “thực đơn năng lực”: context dài để làm gì, attention tiết kiệm ra sao, routing có ổn không, workload của bạn có thật sự cần phần đó không.

Sơ đồ minh họa cho bài Model mới không phải món chính

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

Niềm tin phổ biến: model lớn hơn thì ít phải thiết kế hơn

LongCat-2.0 có đủ thông số để làm người ta ngứa tay: 1.6T total parameters, khoảng 48B active parameters mỗi token, native 1M-token context window — vùng ngữ cảnh rất dài mà model có thể xử lý trong một lượt. Model nhắm vào agentic coding, tức các workflow agent đọc code, tạo code, chạy lệnh, sửa lỗi, rồi lặp lại.

Nếu chỉ nhìn headline, phản xạ dễ hiểu là: “À, vậy tương lai là model càng to, context càng dài, agent càng tự lo.”

Nói thẳng ra thì: đó là cách đọc hơi nguy hiểm.

Vì chính các release gần đây lại kể một câu chuyện ngược lại. LongCat-2.0 không chỉ khoe scale; nó khoe cách giảm chi phí của scale. NVIDIA TwoTower không chỉ khoe model mới; nó thử đổi cách decode để tăng throughput. VibeThinker-3B không khoe kích thước; nó cho thấy reasoning có thể nén tốt hơn factual knowledge. Unlimited OCR của Baidu không cố làm OCR to vô tận; nó giữ KV cache phẳng để đọc tài liệu dài thực dụng hơn.

Điểm chung: mỗi release đang chọn một nút nghẽn cụ thể để xử lý, không phải “làm model mạnh hơn” chung chung.

Mổ lớp đầu: 1M context không thay thế kiến trúc nhớ

LongCat Sparse Attention, hay LSA, là phần đáng đọc kỹ. Sparse attention là cơ chế attention chỉ chọn một phần token liên quan thay vì so khớp mọi token với mọi token. Với context rất dài, attention chuẩn dễ phình chi phí theo kiểu càng đọc nhiều càng nặng. LSA cố kéo bài toán về gần tuyến tính hơn bằng nhiều lớp indexing: đọc memory liền mạch hơn, tái dùng tín hiệu giữa các layer, rồi lọc thô đến lọc tinh.

Nghe vậy, có phải RAG hết thời không? Không.

RAG — retrieval augmented generation, tức lấy tài liệu liên quan rồi đưa vào prompt — vẫn là cách kiểm soát “model được ăn gì”. Context dài chỉ nói rằng bàn ăn rộng hơn; không có nghĩa bạn nên bê cả kho lạnh lên bàn.

Ví dụ cụ thể: team bạn làm coding agent cho monorepo. Có 1M context, bạn có thể nhét nhiều file hơn. Nhưng nếu task là sửa một bug trong module billing, agent vẫn cần biết:

Nếu không có retrieval, ranking, hoặc policy chọn context, model dài context sẽ đọc cả “set menu” nhưng không biết món chính là gì. Kết quả có thể vẫn đúng, nhưng latency, chi phí và độ khó debug tăng lên.

Với builder, câu hỏi đúng không phải: “Model có bao nhiêu context?” mà là: “Mình có cơ chế chọn context trước khi đưa cho model chưa?”

Mổ lớp hai: MoE hay ở routing, không chỉ ở tổng tham số

LongCat-2.0 là Mixture-of-Experts, hay MoE: kiến trúc có nhiều expert, mỗi token chỉ kích hoạt một phần expert thay vì chạy toàn bộ model. Tổng tham số 1.6T nghe rất lớn, nhưng active parameters mới là phần ảnh hưởng trực tiếp tới inference cost mỗi token.

Điểm thú vị là zero-computation experts: token đơn giản như dấu câu có thể đi qua expert gần như không tính toán. Token phức tạp thì dùng nhiều expert hơn. Meituan còn dùng PID controller để giữ mức kích hoạt trung bình trong vùng mong muốn. PID controller ở đây hiểu ngắn là bộ điều chỉnh phản hồi: thấy hệ thống lệch khỏi mục tiêu thì kéo lại.

Với production, đây mới là thứ đáng giữ. Không phải “wow 1.6T”, mà là dynamic activation — mức compute thay đổi theo độ khó token. Nó giống gọi món theo bụng thật: khai vị nhẹ thì không cần đem cả phần chính ra từ phút đầu.

Nhưng MoE cũng đổi vấn đề từ “model có mạnh không” sang “routing có ổn không”. Nếu routing lệch, expert quá tải, hoặc token khó bị đưa nhầm nhánh, bạn sẽ gặp lỗi khó đoán hơn model dense truyền thống. Dense model là kiểu hầu hết tham số cùng tham gia xử lý, dễ hình dung hơn nhưng thường tốn compute đều hơn.

Framework nhỏ cho tech lead:

| Nếu workload của bạn... | Hãy nhìn vào... | Đừng bị hút bởi... |
|---|---|---|
| Code agent đọc repo lớn | context policy, sparse attention, tool execution | chỉ số context tối đa |
| Chat nội bộ nhiều request ngắn | latency p95, batch serving, active params | tổng tham số |
| OCR tài liệu dài | KV cache, output length, memory growth | benchmark một trang |
| Math/coding benchmark rõ đáp án | post-training, verifier, test loop | factual benchmark |
| Knowledge QA rộng | retrieval, freshness, citations | model nhỏ “giỏi reasoning” |

Các release khác đang nói cùng một điều

NVIDIA Nemotron-Labs-TwoTower đi theo hướng khác: diffusion language model — model sinh nhiều token song song rồi tinh chỉnh qua nhiều bước, thay vì autoregressive decoding là sinh từng token nối tiếp. TwoTower tách một tower giữ context AR đã đóng băng và một tower denoiser được train thêm. Nguồn ghi nhận nó giữ 98.7% chất lượng benchmark tổng hợp so với AR baseline và đạt 2.42× wall-clock generation throughput trong cấu hình nêu ra.

Thông điệp cho builder: nếu bottleneck là throughput sinh text, kiến trúc decode có thể quan trọng hơn việc đổi sang model “thông minh hơn”.

Sina VibeThinker-3B lại nhấn vào một đường khác. Model nhỏ 3B có thể rất mạnh ở math và coding nhờ post-training nhiều giai đoạn, nhưng yếu hơn ở bài cần factual knowledge rộng. Đây là phân tách cực kỳ hữu ích: reasoning có cấu trúc nén được tốt hơn tri thức thế giới. Nếu bạn build hệ thống giải bài lập trình có test rõ ràng, model nhỏ + verifier có thể đủ ngon. Nếu bạn build trợ lý tư vấn pháp lý nội bộ, đừng mong model nhỏ nhớ hết mọi thứ.

Baidu Unlimited OCR thì thực dụng hơn nữa. Nó dùng Reference Sliding Window Attention, tức mỗi token output nhìn vào reference tokens và một cửa sổ output gần nhất, giúp KV cache — bộ nhớ key/value của attention khi sinh token — không tăng mãi theo độ dài output. Với long-document parsing, đây là phần chính, không phải tráng miệng.

Nhìn ngang các release, bài học không phải “ai thắng”. Bài học là: mỗi model mới đang tối ưu một biến vận hành khác nhau.

Khung chọn model: đừng chọn tên, chọn nút nghẽn

Nếu là mình đang dẫn một team build hệ thống AI trong một quý tới, mình sẽ không bắt đầu bằng bảng xếp hạng model. Mình sẽ bắt đầu bằng 5 câu hỏi này:

  1. Nút nghẽn chính là gì? Latency, cost, context, factuality, tool reliability, hay throughput?
  2. Workload có đáp án kiểm chứng được không? Coding có test, math có đáp án, OCR có ground truth; knowledge QA thì khó hơn.
  3. Context dài có được chọn lọc không? Nếu không, 1M token chỉ làm lỗi khó truy vết hơn.
  4. Inference cost phụ thuộc token nào? MoE dynamic activation có lợi nếu workload lẫn token dễ và khó.
  5. Bạn debug thất bại bằng gì? Log routing, trace tool call, cache metrics, retrieval hit rate, hay chỉ đọc câu trả lời cuối?

Hình dung thế này: giả sử team bạn 6 người đang làm agent sửa bug tự động cho một SaaS nội bộ. Bạn có hai hướng:

Không có đáp án cố định. Nhưng nếu hiện tại team chưa có test harness và trace, đổi sang model dài context có thể chỉ làm bạn tốn tiền nhanh hơn. Ngược lại, nếu bạn đã có pipeline đánh giá tốt, model như LongCat-2.0 có thể mở ra workflow đọc repo sâu hơn, giảm số vòng retrieval thủ công, và xử lý refactor nhiều file tốt hơn.

Điều nên bỏ qua khi đọc launch model

Có ba thứ mình sẽ bỏ qua trước:

Điều đáng giữ là cách đọc release theo tradeoff: LongCat-2.0 cho thấy scale cần sparse attention và routing tốt; TwoTower cho thấy throughput có thể đến từ decode khác; VibeThinker-3B nhắc rằng reasoning và knowledge không cùng một loại năng lực; Unlimited OCR chứng minh giữ cache ổn định đôi khi quan trọng hơn tăng tham số.

Sau bài này, điều mình muốn bạn nghĩ khác là: model mới không phải lựa chọn “món nào hot nhất”, mà là chọn đúng phần trong thực đơn năng lực cho nút nghẽn của hệ thống. Gọi sai món thì không chỉ no sai chỗ, bill production còn hơi cay.

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

Nguồn tham khảo