Long context không miễn phí

Long context không miễn phí

MSA của MiniMax đáng chú ý không vì dài hơn, mà vì nó buộc team builder hỏi lại: mình đang thiếu context, thiếu memory, hay thiếu cách đo?

Bạn có đang mua thêm context window để che một lỗi kiến trúc không?

Câu hỏi hơi khó chịu, nhưng hợp với tuần này. MiniMax đưa ra MSA — MiniMax Sparse Attention, một kiểu sparse attention, tức attention thưa, nhằm giảm chi phí khi model phải nhìn vào ngữ cảnh dài. Họ thử trong một MoE 109B tham số được train với 3T token, mở inference kernel, và có model production MiniMax-M3.

Điểm dễ bị cuốn theo là: à, lại thêm một kỹ thuật giúp long context rẻ hơn. Nhưng nếu bạn đang vận hành hệ thống AI thật, điểm đáng bàn không phải là ai có context dài hơn. Điểm đáng bàn là: khi context dài trở nên rẻ hơn, bạn có biết phần nào trong hệ thống thật sự cần nó không?

Sơ đồ minh họa cho bài Long context không miễn phí

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

Chuyện đang diễn ra: trần context cao hơn, móng vận hành vẫn phải chắc

MSA đánh vào một nút thắt quen thuộc của Transformer: attention kiểu dense có chi phí tăng theo độ dài ngữ cảnh. Khi context dài lên, model phải so khớp query với rất nhiều key-value token. Với dense attention, mỗi query nhìn toàn bộ phần context có thể thấy.

MSA đổi cách làm. Nó chia attention thành hai nhánh:

Dịch sang tiếng người: thay vì bắt model lục toàn bộ căn nhà mỗi khi cần tìm giấy tờ, MSA dựng một lớp chỉ đường trước, rồi mới mở đúng vài ngăn tủ cần thiết.

Chi tiết đáng giữ ở đây là lựa chọn theo block, không theo từng token. Theo mô tả, block mặc định có 128 token. Mỗi query và mỗi nhóm GQA giữ 16 block, tức ngân sách cố định khoảng 2.048 key-value token cho mỗi query. Khi context dài hơn, phần Main Branch vẫn chỉ xử lý số block đã chọn, thay vì quét toàn bộ.

Ở mức builder, đây không chỉ là tối ưu kernel. Đây là một thay đổi trong giả định sản phẩm: long context không còn chỉ là tăng giới hạn input, mà thành bài toán routing thông tin trong context.

Mổ xẻ: MSA giải quyết compute, không giải quyết mọi nợ hệ thống

MSA được xây trực tiếp trên GQA — Grouped Query Attention, cơ chế nhiều query head dùng chung một số key-value head để tiết kiệm bộ nhớ và compute. Index Branch thêm hai projection matrix vào layer GQA: một index query head cho mỗi GQA group và một index key head dùng chung. Nó chấm điểm token có thể thấy, max-pool lên mức block, rồi Top-k chọn block.

Có một guardrail hay: block cục bộ chứa query luôn được giữ lại. Nghĩa là selector không được phép bỏ mất vùng lân cận ngay quanh token đang xử lý. Đây là chi tiết nhỏ nhưng quan trọng, vì sparse attention mà chọn sai vùng gần thì model dễ mất mạch văn.

Nhưng đừng nhầm: sparse attention không tự biến mọi workload thành rẻ. Nó chủ yếu giảm chi phí attention khi sequence dài. Trong production, bạn còn gặp một bức tường khác: KV cache, tức bộ nhớ lưu key-value của các token trước để decode token mới nhanh hơn.

Nguồn liên quan về KV cache đưa ví dụ Llama-3.1-70B BF16: KV cache khoảng 0,31 MB mỗi token. Ở 128K token là khoảng 40 GB; ở 1M token vượt 300 GB, còn lớn hơn phần trọng số model được nêu trong ví dụ. Đây là lý do nhiều team thấy prompt dài chạy được trong demo, nhưng khi concurrency tăng thì latency và GPU memory bắt đầu méo mặt.

Vậy framework suy nghĩ nên là:

| Câu hỏi vận hành | Nếu câu trả lời là có | Hướng thử trước |
|---|---|---|
| Latency tăng chủ yếu khi prefill context dài? | Có | Xem sparse attention / kernel long-context |
| Decode chậm vì stream KV cache quá nhiều? | Có | Xem KV cache compression hoặc eviction |
| Model đọc sai vì nhét quá nhiều tài liệu? | Có | Xem RAG, rerank, chunking, rubric đánh giá |
| Task cần suy luận sâu nhưng input không quá dài? | Có | Xem model chuyên reasoning nhỏ hơn |

Nói gọn: MSA là cột chịu lực cho một kiểu nhà long-context, không phải toàn bộ bản vẽ căn nhà.

Ví dụ cụ thể: một team RAG pháp lý nên thử gì trước?

Hình dung thế này: team bạn làm trợ lý đọc hợp đồng. Người dùng upload bộ tài liệu dài, hỏi các điều khoản liên quan đến phạt vi phạm, gia hạn, trách nhiệm bồi thường. Demo nội bộ chạy ổn với một người dùng. Lên pilot, ba vấn đề xuất hiện:

  1. Prompt rất dài, prefill tốn thời gian.
  2. Decode trả lời chậm khi nhiều người dùng đồng thời.
  3. Model thỉnh thoảng trích sai điều khoản dù tài liệu có trong context.

Nếu nhìn thấy MSA rồi lao ngay vào đổi model, có thể bạn đang thay khung kèo khi nền nhà chưa đo độ lún.

Một buổi thử hợp lý hơn:

Bước 1: tách log thành ba pha

Ghi riêng:

request_id
input_tokens
retrieved_chunks
prefill_latency_ms
decode_latency_ms
output_tokens
peak_gpu_memory
answer_accept/reject
failure_reason

Không cần dashboard cầu kỳ. CSV cũng được, miễn là prefill và decode không bị trộn chung.

Bước 2: tạo 20 case kiểm thử có rubric

Lấy cảm hứng từ LifeSciBench ở điểm dùng rubric, không phải chỉ so một đáp án mẫu. Với mỗi câu hỏi pháp lý, chấm theo tiêu chí cụ thể:

Rubric làm bạn bớt bị lừa bởi câu trả lời trôi chảy.

Bước 3: chạy ba cấu hình nhỏ

Không cần đổi cả stack ngay. Chạy cùng bộ test với:

Nếu chưa có MSA trong stack bạn dùng, vẫn có thể học từ nó: đo xem bottleneck của bạn nằm ở attention dài, KV cache, hay retrieval quality. Đừng biến một paper thành vé đổi toàn bộ production.

Điều đáng giữ: tư duy IO-aware đang thắng các bài benchmark đẹp

Một điểm thú vị là MSA không đứng một mình. Flash-KMeans cũng đi theo hướng tương tự: không đổi bài toán toán học của k-means, mà tối ưu cách dữ liệu di chuyển trên GPU. Nguồn mô tả Flash-KMeans là exact Lloyd’s k-means, viết bằng Triton kernel, tập trung vào IO-aware, tức ý thức chi phí đọc ghi bộ nhớ.

Đây là tín hiệu lớn cho builder: nhiều bottleneck AI hiện nay không nằm ở công thức trông có vẻ thông minh hơn, mà nằm ở data movement — dữ liệu đi qua HBM, SRAM, cache, kernel boundary như thế nào.

Với long-context inference, câu hỏi vận hành nên đổi từ:

Model nào support nhiều token nhất?

sang:

Mỗi token mới đang bắt GPU đọc bao nhiêu thứ, và bao nhiêu trong đó thật sự cần đọc?

Đó là khác biệt giữa mua vật liệu thật nhiều và có bản thiết kế chịu tải rõ ràng.

Điều nên bỏ qua: bảng thành tích không trả tiền cloud cho bạn

VibeThinker-3B là ví dụ hay ở hướng ngược lại: model nhỏ, chuyên reasoning trên các tác vụ có verifier, được post-train từ Qwen2.5-Coder-3B. Nó nhắc mình rằng không phải cứ thêm context hoặc thêm tham số là đúng. Nếu task của bạn là toán, code, STEM có đáp án kiểm được, một model nhỏ chuyên biệt có thể là lựa chọn đáng thử hơn một model khổng lồ đọc rất dài.

Còn LifeSciBench nhắc thêm một chuyện: benchmark hữu ích khi nó giống workflow thật. Các task có artifact, rubric, nhiều bước reasoning. Với team triển khai, đây là bài học thực dụng: hãy tự làm benchmark nhỏ theo workflow của mình trước khi tin vào benchmark lớn của người khác.

Các dấu hiệu nên dừng thử MSA-like hoặc long-context path:

Các dấu hiệu nên scale tiếp:

Sau bài này nên nghĩ khác gì?

Đừng hỏi long context mới có đáng hype không. Hỏi câu này thực tế hơn: long context đang thay thế phần nào trong kiến trúc của bạn, và phần đó có đang được đo riêng không?

MSA đáng chú ý vì nó làm rõ một hướng: chọn đúng phần context để tính attention, thay vì trả tiền cho mọi token như nhau. Nhưng để dùng được trong team, bạn cần playbook nhỏ hơn nhiều: log đúng pha, test bằng rubric, đặt tiêu chí dừng, rồi mới quyết định scale.

Long context giống trần nhà cao: nhìn thoáng thật, nhưng nếu móng đo sai tải thì kê thêm đèn chùm chỉ làm bạn hồi hộp hơn thôi.

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

Nguồn tham khảo