Giải mã SubQ AI: Mô hình LLM với cửa sổ ngữ cảnh 12M tốt đến mức nào?

Ngày 5 tháng 5 năm 2026, một startup nhỏ có trụ sở tại Miami tên là Subquadratic đã ra mắt một mô hình gọi là SubQ. Đội ngũ tuy nhỏ, nhưng họ đã huy động được 29 triệu đô la vòng hạt giống và tuyên bố mô hình có thể xử lý tới 12 triệu token trong một lượt.

Họ cũng đưa ra những tuyên bố nghe có vẻ “khó tin” khác, như mô hình của họ hiệu quả hơn FlashAttention đến 52 lần ở mức 1M token và đạt hiệu năng lập trình tương tự Claude Opus với chi phí chỉ khoảng 1/20.

Đó là những phát biểu lớn, nên hợp lý là cần phân tích kỹ xem thực tế như thế nào. Trong bài này, tôi sẽ trình bày SubQ là gì, kiến trúc hoạt động ra sao, và những chi tiết ban đầu cùng cộng đồng nhà phát triển gợi ý điều gì về các tuyên bố này.

SubQ là gì?

SubQ là LLM của Subquadratic, phát hành ngày 5/5/2026, xoay quanh một tính năng nổi bật: cửa sổ ngữ cảnh 12 triệu token. Đây là mô hình đầu tiên công ty phát hành, kèm theo loạt tuyên bố táo bạo về hiệu năng và chi phí, vốn đã châm ngòi cho nhiều tranh luận đáng kể. 

Mô hình hiện chưa công khai, quyền truy cập API, SubQ Code và SubQ Search đang giới hạn dưới dạng early access qua danh sách chờ.

Nó được xây dựng dựa trên thứ gọi là SSA, viết tắt của Subquadratic Sparse Attention.

Thay vì so sánh mọi token với mọi token khác như cơ chế dense attention tiêu chuẩn, SSA chọn lọc. Với mỗi token, mô hình chọn ra các token liên quan nhất và chỉ tính toán quan hệ trong tập con đó.

Điều này mang lại hai hiệu ứng rõ ràng.

• Thứ nhất, nó giảm số lượng phép tính, trực tiếp cải thiện hiệu suất và hạ chi phí. 
• Thứ hai, việc chọn lọc phụ thuộc vào nội dung. Nghĩa là mô hình không chỉ nhìn các token lân cận. Nó có thể kéo vào các token liên quan từ bất kỳ đâu trong chuỗi, dù ở rất xa.

Điểm đặc biệt của SubQ là gì?

Trên thực tế, kiến trúc SSA giúp mô hình tập trung vào những gì thực sự quan trọng thay vì xử lý mọi thứ như nhau. Kết quả mong muốn là độ chính xác tương tự full attention nhưng với yêu cầu tính toán và bộ nhớ thấp hơn đáng kể.

Hãy xem kỹ dense attention trước, rồi so sánh hai cách tiếp cận.

Bài toán tăng trưởng bậc hai trong transformer

Các mô hình hiện nay như GPT, Claude và Gemini dựa vào dense attention. Ở mức cao, điều này nghĩa là mỗi token được so sánh với mọi token khác trong đầu vào. Khi đầu vào tăng, số phép so sánh tăng theo bậc hai.

Lấy ví dụ một tài liệu dài và hình dung mô hình cần sinh ra từ cuối cùng. Nó nhìn lại mọi token trong tài liệu đó, xây dựng quan hệ, rồi quyết định bước tiếp theo. Đó là lý do dense attention hoạt động tốt: nó xem xét tất cả.

Nhưng sức mạnh đó đi kèm cái giá phải trả. Khi kích thước đầu vào tăng, nhu cầu tính toán và bộ nhớ tăng vọt, tạo ra các giới hạn cửa sổ ngữ cảnh. Nói đơn giản, nó tỉ lệ O(n²), với n là số token.

Vì vậy, hầu hết mô hình giữ trong các giới hạn thực tiễn. Với mô hình tiêu chuẩn, 128k token là mức thường thấy, và các mô hình mạnh như Claude Opus đạt tối đa 1M cho cửa sổ ngữ cảnh.

Để né vấn đề này, đa số hệ thống AI không đưa toàn bộ dữ liệu vào mô hình. Thay vào đó, họ dựa vào các kỹ thuật như:

• RAG (Retrieval-Augmented Generation): Lưu dữ liệu bên ngoài, chỉ truy xuất các phần liên quan và đưa chúng vào mô hình.
• Chunking: Chia văn bản lớn thành mảnh nhỏ và chỉ gửi các mảnh liên quan vào mô hình.
• Chiến lược tóm tắt: Nén nội dung dài và đưa bản tóm tắt vào mô hình, thay vì toàn bộ văn bản.

Nếu bạn muốn hiểu sâu hơn về cơ chế attention, hãy xem hướng dẫn về Cơ chế Attention trong LLMs. Để thực hành với các khối xây dựng của LLM hiện đại, tôi khuyên bạn nên học khóa Transformer Models with PyTorch của chúng tôi.

Cách SubQ định vị khác biệt

Dense attention tăng theo bậc hai cùng kích thước đầu vào, trong khi SSA được thiết kế để mở rộng dưới-bậc-hai, gần với O(n·k) thay vì O(n²), với k là số token được chọn mỗi bước. Khi k nhỏ so với n, cách này hiệu quả hơn hẳn so với full attention.

Sơ đồ attention bậc hai so với gần tuyến tính, cho thấy kết nối dày đặc mọi-nút-đến-mọi-nút so với kết nối thưa chọn lọc.

Mối lo hiển nhiên ở đây là độ chính xác. Nếu mô hình chỉ xem một phần đầu vào, nó có thể bỏ lỡ các quan hệ quan trọng. Đó thường là lý do dense attention ra đời ngay từ đầu.

SubQ tuyên bố rằng đánh đổi này không xảy ra trong thực tế. Họ nói mô hình chú ý đủ các token cần thiết, dù chúng ở xa token hiện tại, và duy trì độ chính xác tương đương các mô hình hàng đầu.

Subquadratic Sparse Attention hoạt động như thế nào?

Tới đây, ta biết rằng thay vì so sánh mọi token với mọi token khác, SSA chỉ chọn các token quan trọng trong chuỗi và tính attention trên các vị trí đó. Hãy xem cách nó lựa chọn.

Cách SSA chọn các quan hệ liên quan

SSA dùng định tuyến phụ thuộc nội dung. Nói đơn giản, nó chọn token dựa trên mức độ liên quan với token hiện tại. Nó tính điểm tương đồng giữa các token, dạng như similarity(query_i, key_j), và chỉ giữ top k token có điểm cao nhất để tính attention.

Theo thời gian, mô hình học cách ưu tiên các token có ý nghĩa và bỏ qua nhiễu. Bao gồm từ khóa, thực thể quan trọng và các token mang tín hiệu ngữ cảnh mạnh.

Không chỉ phụ thuộc nội dung, SSA còn bảo toàn các quan hệ cấu trúc trong chuỗi. Ví dụ, các token lân cận luôn được chú ý thông qua mẫu attention cục bộ, trong khi một số token toàn cục được thiết kế để chú ý trên toàn bộ chuỗi.

SSA cũng bao gồm các kỹ thuật attention phân cấp và dựa trên phân cụm. Chẳng hạn, nó phân cụm các token tương tự và tính attention với các cụm liên quan nhất. Điều này giúp mô hình không cần đánh giá từng token riêng lẻ, mà có thể lý luận ở cấp độ nhóm trước, rồi phóng to vào các token trong cụm khi cần.

Huấn luyện cho truy xuất ngữ cảnh dài

Một cửa sổ ngữ cảnh lớn tự thân không tạo nên phép màu. Dù bạn cho mô hình 12M token, nó vẫn cần biết cách dùng ngữ cảnh đó hiệu quả. SSA được huấn luyện cho mục đích này:

• Tiền huấn luyện: Mô hình nền được huấn luyện trên các bộ dữ liệu khổng lồ, đa dạng với biểu diễn ngữ cảnh dài. 
• Fine-tune có giám sát: Sau đó mô hình được huấn luyện trên các tác vụ có cấu trúc, gồm lập luận và sinh mã. 
• Học tăng cường: Thay vì giới hạn mô hình chỉ xét token gần (attention cục bộ), bước này hướng tới việc tận dụng các token liên quan từ toàn bộ văn bản (attention toàn cục).

Giai đoạn học tăng cường đặc biệt quan trọng với các trường hợp dùng lập trình doanh nghiệp. Nó cho phép mô hình xét ngữ cảnh rộng hơn trong một lần, ở đây là toàn bộ codebase, khi tạo đầu ra.

Benchmark và hiệu năng của SubQ

Lưu ý rằng "SubQ 1M-Preview" đề cập tới phiên bản được benchmark ở mức 1M token. Cửa sổ ngữ cảnh đầy đủ 12M có thể truy cập qua API.

Trên ba benchmark Subquadratic công bố, SubQ 1M-Preview ngang ngửa với Claude Opus 4.7, GPT-5.5 và Gemini 3.1 Pro. 

Tuy nhiên, lựa chọn benchmark khá hẹp; đúng ba bài kiểm tra, đều tập trung vào truy xuất ngữ cảnh dài và lập trình — hai thứ SubQ được thiết kế để làm tốt. Các đánh giá rộng hơn về lập luận tổng quát, toán học, đa ngôn ngữ và an toàn chưa được công bố.

Thẻ mô hình đầy đủ trên website được ghi là "sắp ra mắt", nên chúng ta có thể kỳ vọng sẽ có thêm benchmark cho các trường hợp tổng quát.

Hiện tại, đây là các kết quả cho các trường hợp truy xuất ngữ cảnh dài và lập trình:

Những gì các con số cho thấy

RULER 128K: SubQ đạt 95% so với 94,8% của Opus 4.7. Dù khác biệt về độ chính xác là không đáng kể, điều quan trọng ở đây là chi phí: Subquadratic cho biết chạy đánh giá này trên SubQ tốn khoảng 8 đô la, so với khoảng 2.600 đô la trên Opus ở cùng độ dài ngữ cảnh.

MRCR v2 (8-needle, 1M): Benchmark này kiểm tra liệu mô hình có truy xuất và theo dõi đúng 8 sự kiện riêng biệt được nhúng trong ngữ cảnh 1M token. SubQ cho thấy kết quả nghiên cứu là 83%, nhưng điểm sản phẩm giảm xuống 65,9%. Khoảng cách ~17 điểm giữa hiệu năng trong phòng lab và khi triển khai là đáng chú ý và chưa được giải thích đầy đủ. Dù vậy, nó vẫn cạnh tranh với GPT-5.5 (74,0%) và vượt xa Claude Opus 4.7 (32,2%) cùng Gemini 3.1 Pro (26,3%).

SWE-Bench Verified: SubQ đạt 81,8%, cao hơn Opus 4.6 ở mức 80,8% nhưng thấp hơn Opus 4.7 ở 87,6%. Biên độ so với Opus 4.6 nhỏ và nhạy với thiết lập công cụ đo. So với Opus 4.7 và GPT-5.5, SubQ rõ ràng tụt sau.

Ở mức 12 triệu token: SubQ được báo cáo đạt trên 90% ở các bài “kim trong đống rơm” tại ngữ cảnh 12M, dù con số này chưa được xác thực bởi benchmark chính thức. Chưa có mô hình frontier nào khác được kiểm tra ở độ dài này, nên không có gì để so sánh trực tiếp. Đây là kết quả thú vị nhất về mặt kiến trúc từ đợt ra mắt, đồng thời cũng là kết quả cần được tái lập độc lập trước khi kết luận.

Ý nghĩa của SubQ với RAG, tác tử lập trình và chi phí AI

Nếu kiến trúc của SubQ đứng vững ở quy mô lớn, cách xây dựng hệ thống LLM sẽ thay đổi. Ngữ cảnh dài hơn trở nên khả thi, giảm nhu cầu chunking, truy xuất và tối ưu token quá mức. Hãy xem kỹ những thay đổi này.

Khi RAG trở nên tùy chọn

Trong hai năm qua, Retrieval-Augmented Generation (RAG) là câu trả lời mặc định cho một giới hạn cơ bản của LLM: mô hình không thể đọc tất cả mọi thứ cùng lúc. Nếu cơ sở tri thức lớn hơn cửa sổ ngữ cảnh, bạn sẽ chia nhỏ tài liệu, nhúng (embed), lưu vào cơ sở dữ liệu vector, truy xuất các phần liên quan nhất, rồi chỉ đưa các mảnh đó vào mô hình cùng lời nhắc.

Toàn bộ hệ sinh thái đó tồn tại vì ngữ cảnh là tài nguyên khan hiếm.

Khi một mô hình có thể xử lý đáng tin cậy hàng triệu token trong một lượt, nhiều lớp kỹ thuật xây quanh truy xuất trở nên bớt cần thiết ở một số quy trình. Thay vì tốn công quyết định mảnh nào cần truy xuất, hệ thống có thể nạp trực tiếp dữ liệu gốc và lý luận xuyên suốt từ đầu đến cuối.

Tuy nhiên, ngoài cửa sổ ngữ cảnh, RAG vẫn quan trọng cho các năng lực sau:

• Bộ nhớ xuyên phiên: LLM không ghi nhớ gì sau khi một phiên kết thúc. Nếu người dùng quay lại sau, mô hình bắt đầu lại từ đầu. Hệ thống truy xuất (hoặc cơ sở dữ liệu) lưu thông tin quan trọng như quyết định trước đây, tài liệu, hay dữ liệu người dùng để mô hình có thể nhớ và dùng trong tương tác tương lai.
• Phân quyền và kiểm soát truy cập: Hệ thống truy xuất có thể áp dụng quy tắc như “người dùng này chỉ được truy cập dữ liệu của nhóm họ.” Như vậy, mô hình chỉ nhận các tài liệu người dùng được phép xem, tránh rò rỉ dữ liệu ngoài ý muốn.
• Khả năng kiểm chứng: Trong môi trường doanh nghiệp, không chỉ cần câu trả lời; bạn cần cho thấy vì sao nó đúng. Hệ thống truy xuất có thể chỉ ra tài liệu hay nguồn chính xác được dùng, để các nhóm xác minh kết quả và gỡ lỗi nếu có sự cố.
• Quản trị tri thức có cấu trúc: Công ty liên tục thêm, cập nhật, xóa tài liệu. Hệ thống truy xuất dùng embedding và lập chỉ mục để tổ chức dữ liệu, giúp mô hình nhanh chóng tìm được thông tin mới nhất và liên quan nhất, không cần xử lý lại mọi thứ mỗi lần.

Với một cách tiếp cận mới, thú vị để bổ sung bộ nhớ lâu dài cho tác tử AI, hãy đọc Hướng dẫn Supermemory của chúng tôi, trong đó bạn sẽ học cách xây một huấn luyện viên thể dục với bộ nhớ ngắn hạn và dài hạn.

Quy trình lập trình với ngữ cảnh dài

Hiện nay, hầu hết mô hình lập trình không thể “nhìn” toàn bộ codebase. Vì thế chúng ta thêm nhiều lớp bên trên, tìm kiếm tệp, chunking, xếp hạng và lập kế hoạch nhiều bước, chỉ để giữ đúng ngữ cảnh trong cửa sổ và xây quan hệ xuyên tệp.

Nhưng với ngữ cảnh 12M của SubQ, toàn bộ codebase được nạp vào mô hình trong một lần. Điều này đơn giản hóa thiết kế tác tử theo cách có ý nghĩa.

• Lập kế hoạch ở tầm tổng thể: Mô hình có thể lý luận về kiến trúc, phụ thuộc và tương tác xuyên tệp mà không bỏ sót ngữ cảnh.
• Thực thi mạch lạc hơn: Thay đổi trên nhiều tệp có thể được phối hợp trong một lượt, thay vì cập nhật dần dần.
• Rà soát đáng tin cậy hơn: Mô hình có thể tự kiểm tra thay đổi của mình với toàn bộ codebase, giảm thiếu nhất quán.

Kinh tế chi phí

Trong các mô hình transformer tiêu chuẩn, attention tăng theo bậc hai với độ dài chuỗi. Nếu bạn gấp đôi ngữ cảnh, chi phí không chỉ gấp đôi; nó có thể đắt gấp bốn lần.

SubQ tuyên bố phá vỡ đánh đổi đó.

• Báo cáo ~1/20 chi phí so với các mô hình frontier tương đương (Claude Opus)
• Và tới ~1.000× giảm tính toán ở ngữ cảnh 12M token

Nếu điều này giữ vững trong sản xuất, xử lý ngữ cảnh dài sẽ không còn là trường hợp đắt đỏ ngoại lệ, mà trở thành thứ bạn có thể dùng thường xuyên hơn.

Tuy nhiên, song hành với cửa sổ ngữ cảnh rẻ, mô hình cũng cần sử dụng hiệu quả thông tin được nạp vào ngữ cảnh. Dựa trên benchmark, SubQ tuyên bố độ chính xác tương đương với chi phí thấp hơn nhiều, nhưng còn quá sớm để đưa ra kết luận cuối cùng.

Tôi có thể truy cập SubQ như thế nào?

SubQ hiện chưa công khai. Cả ba sản phẩm — API lõi, SubQ Code và SubQ Search — đang ở giai đoạn beta riêng tư, và cần yêu cầu early access qua website SubQ.

Từ góc nhìn nhà phát triển, API được thiết kế dễ tích hợp. Nó hỗ trợ:

• phản hồi streaming
• gọi công cụ/hàm
• điểm cuối tương thích OpenAI

Điều đó có nghĩa nếu stack của bạn đã làm việc với API kiểu OpenAI, bạn thường không cần viết lại tích hợp.

SubQ Code được định vị như một tác tử lập trình dòng lệnh, trong khi SubQ Search tập trung vào tìm kiếm ngữ cảnh dài cho các quy trình nghiên cứu chuyên sâu. Hãy coi chúng là phiên bản SubQ của Claude Code và Perplexity. 

Giá cho bất kỳ công cụ nào trong số này cũng chưa minh bạch. Chưa có mức giá tính theo token công khai, khiến việc xác thực độc lập các tuyên bố về chi phí của công ty trở nên khó khăn.

Hoài nghi và các câu hỏi bỏ ngỏ

Chỉ sau vài giờ ra mắt, đã có rất nhiều hoài nghi và phản ứng trái chiều trên mạng xã hội và các diễn đàn như Hacker News. Cuộc thảo luận bị chia rẽ: một số xem đây là đột phá thực sự, số khác ví nó như “AI Theranos” (ám chỉ startup xét nghiệm máu thất bại với các tuyên bố công nghệ gian dối).

Phần lớn nghi ngờ tập trung vào: 

• Họ tuyên bố cửa sổ ngữ cảnh 12M, nhưng các benchmark chia sẻ đều ở mức 1M.
• Tên công ty là Subquadratic, nhưng ở vài nơi họ nhắc đến tăng trưởng kiểu O(1). Ở O(1), bạn sẽ kỳ vọng hơn nhiều so với cửa sổ 12M token. Ngay cả O(log n) cũng cho phép mức giới hạn lớn hơn.

Một câu chuyện tương tự từng xuất hiện với Magic.dev năm 2024. Họ đưa ra các tuyên bố mạnh về cửa sổ ngữ cảnh cực lớn, tới 100M token, và các cải thiện hiệu suất lớn, đặc biệt cho quy trình lập trình. 

Lời chào hàng gần như giống hệt: nạp toàn bộ codebase, giảm độ phức tạp truy xuất, và đơn giản hóa thiết kế tác tử. Nhưng kết quả, ít nhất là công khai, trầm lắng hơn. Dù huy động khoảng 500 triệu đô la, đến đầu 2026 vẫn có rất ít mức độ hiện diện hay áp dụng thực tế.

Những gì đã được xác minh

Các tuyên bố của SubQ không chỉ mang tính lý thuyết. Subquadratic cho biết các benchmark trên RULER, MRCR v2 và SWE-Bench Verified đã được chạy bởi dịch vụ kiểm thử bên thứ ba, cho thấy hiệu năng mạnh ở truy xuất ngữ cảnh dài và kết quả cạnh tranh ở tác vụ lập trình. 

Tuy nhiên, những kết quả này chưa được các nhà nghiên cứu độc lập tái lập, và phạm vi đánh giá còn hẹp. Cả ba benchmark đều nhấn mạnh đúng các lĩnh vực SubQ được xây dựng để tối ưu (truy xuất tín hiệu từ ngữ cảnh lớn và vận hành trên mã).

Một chi tiết quan trọng khác là kiến trúc. CTO xác nhận SubQ không huấn luyện mô hình từ đầu, mà xây dựng trên các mô hình nguồn mở (nhiều khả năng từ các họ như DeepSeek hoặc Kimi). Đây là lựa chọn thực tế cho một đội nhỏ. Nó tăng tốc lặp và giảm chi phí huấn luyện. Điều đó cũng có nghĩa đổi mới cốt lõi không nằm ở bản thân mô hình nền, mà là cơ chế attention và thiết kế hệ thống xung quanh.

Kết luận

SubQ đã xuất hiện, và các tuyên bố khá táo bạo. Hướng đi rõ ràng: gỡ bỏ rào cản cửa sổ ngữ cảnh và để mô hình xử lý đầu vào lớn hơn nhiều. Họ định vị rằng mô hình có thể sánh ngang hoặc vượt các mô hình frontier ở lập trình và truy xuất ngữ cảnh dài, với chi phí thấp hơn nhiều.

Dẫu vậy, vẫn còn sớm. Chúng ta vẫn chờ thẻ mô hình đầy đủ để có cái nhìn rõ hơn về năng lực và kiểm thử rộng. Các sản phẩm xây trên đó, SubQ Code và API, cũng chưa công khai. Tôi mong được trực tiếp sử dụng các công cụ này và xem các tuyên bố đứng vững thế nào trong môi trường sản xuất.