SubQ: mô hình ngôn ngữ lớn đầu tiên của startup Subquadratic với tuyên bố cửa sổ ngữ cảnh 12 triệu token

SubQ là mô hình ngôn ngữ lớn đầu tiên của startup Subquadratic, ra mắt ngày 5/5/2026, với tuyên bố cửa sổ ngữ cảnh 12 triệu token, hiệu quả tính toán cao hơn 52 lần so với FlashAttention ở 1 triệu token, và chi phí chỉ bằng 1/20 so với Claude Opus ở tác vụ coding. Đây là những con số đủ lớn để gây tranh luận ngay trong ngày ra mắt, với cộng đồng lập trình viên chia rẽ giữa "đột phá thực sự" và so sánh với vụ lừa đảo Theranos trong ngành công nghệ.

Tóm tắt các điểm chính

• Subquadratic là startup nhỏ tại Miami, gọi vốn 29 triệu USD, xây SubQ trên nền kiến trúc SSA (Subquadratic Sparse Attention) thay vì dense attention thông thường
• Trên MRCR v2 (bài kiểm tra truy xuất 8 thông tin trong 1 triệu token), SubQ đạt 65,9% trong production, cạnh tranh với GPT-5.5 (74,0%) và vượt xa Claude Opus 4.7 (32,2%) lẫn Gemini 3.1 Pro (26,3%)
• Khoảng cách 17 điểm giữa kết quả lab (83%) và production (65,9%) chưa được giải thích đầy đủ
• Toàn bộ sản phẩm (API, SubQ Code, SubQ Search) đang trong private beta, chưa có giá công khai
• CTO xác nhận SubQ không train từ đầu mà xây trên mô hình mã nguồn mở (có thể từ DeepSeek hoặc Kimi)

SubQ là gì và điều gì làm nó khác biệt?

SubQ là mô hình ngôn ngữ lớn do công ty Subquadratic phát triển, xây dựng xung quanh một tính năng trung tâm: cửa sổ ngữ cảnh 12 triệu token. Để so sánh, hầu hết mô hình mạnh nhất hiện nay như Claude Opus giới hạn ở 1 triệu token, và tiêu chuẩn phổ biến của ngành là 128K token.

SubQ được xây dựng trên SSA, viết tắt của Subquadratic Sparse Attention. Thay vì so sánh mỗi token với tất cả token khác trong văn bản (cách dense attention thông thường hoạt động), SSA chọn lọc: với mỗi token, mô hình chỉ tính toán mối quan hệ với những token được xem là liên quan nhất.

Điều này mang lại hai kết quả trực tiếp. Thứ nhất, số lượng tính toán giảm xuống, cải thiện hiệu quả và hạ chi phí. Thứ hai, việc chọn lọc dựa trên nội dung, nghĩa là mô hình không chỉ nhìn vào token gần kề mà có thể kéo token quan trọng từ bất kỳ vị trí nào trong văn bản, dù cách xa đến đâu.

Tại sao cửa sổ ngữ cảnh dài lại là bài toán khó đến vậy?

Các mô hình hiện nay như GPT, Claude và Gemini đều dựa vào cơ chế gọi là dense attention. Về cơ bản, mỗi token được so sánh với mọi token khác trong đầu vào. Khi văn bản dài hơn, số lượng phép so sánh tăng theo bình phương.

Hãy tưởng tượng mô hình cần tạo ra từ cuối cùng trong một tài liệu dài. Nó nhìn lại toàn bộ mọi token trong tài liệu đó, xây dựng mối quan hệ, rồi mới quyết định từ tiếp theo. Đây là lý do dense attention hiệu quả: nó xem xét mọi thứ. Nhưng sức mạnh đó đi kèm với chi phí. Khi đầu vào tăng lên, yêu cầu tính toán và bộ nhớ tăng theo công thức O(n²), tức là tăng gấp bốn lần khi độ dài tăng gấp đôi.

Đó là lý do tại sao hầu hết hệ thống AI hiện nay tránh đưa toàn bộ dữ liệu vào mô hình. Thay vào đó, họ dùng các kỹ thuật như RAG (Retrieval-Augmented Generation, tức lưu dữ liệu bên ngoài và chỉ kéo đoạn liên quan vào mô hình), chia nhỏ văn bản thành các đoạn ngắn hơn, hoặc tóm tắt nội dung dài trước khi đưa vào mô hình.

SSA được thiết kế để thay đổi điểm này. Thay vì O(n²), SSA nhắm đến O(n·k), trong đó k là số token được chọn mỗi bước. Khi k nhỏ hơn nhiều so với n, hiệu quả tính toán cải thiện đáng kể so với full attention.

Cơ chế SSA hoạt động như thế nào bên trong?

SSA chọn token liên quan theo cách nào?

SSA dùng content-dependent routing, tức chọn token dựa trên mức độ liên quan đến token hiện tại. Mô hình tính điểm tương đồng giữa các token (similarity(query_i, key_j)) và chỉ giữ lại k token có điểm cao nhất để tính toán attention.

Theo thời gian huấn luyện, mô hình học cách ưu tiên những token có ý nghĩa: từ khóa, thực thể quan trọng và những token mang tín hiệu ngữ cảnh mạnh. SSA không chỉ phụ thuộc nội dung mà còn giữ nguyên mối quan hệ cấu trúc trong chuỗi: token gần kề luôn được chú ý qua local attention pattern, trong khi một số token đặc biệt được thiết kế để quan sát toàn bộ chuỗi.

SSA cũng áp dụng kỹ thuật phân cụm: nhóm các token tương tự lại và tính attention với những cụm liên quan nhất. Nghĩa là mô hình không cần đánh giá từng token riêng lẻ mà có thể suy luận ở cấp độ nhóm trước, sau đó thu hẹp vào token cụ thể trong nhóm đó khi cần.

SubQ được huấn luyện để dùng ngữ cảnh dài như thế nào?

Cửa sổ ngữ cảnh lớn một mình không tạo ra giá trị. Mô hình cần biết cách khai thác hiệu quả thông tin trải dài trên hàng triệu token đó. SSA được huấn luyện qua ba giai đoạn: tiền huấn luyện trên tập dữ liệu lớn và đa dạng với biểu diễn long-context, supervised fine-tuning trên các tác vụ có cấu trúc bao gồm reasoning và tạo code, và reinforcement learning để thúc đẩy mô hình sử dụng token liên quan từ toàn bộ văn bản thay vì chỉ phần gần đó.

Giai đoạn reinforcement learning đặc biệt quan trọng với use case coding doanh nghiệp, vì nó giúp mô hình xem xét toàn bộ codebase trong một lần thay vì từng đoạn riêng lẻ.

SubQ đạt kết quả benchmark như thế nào?

Lưu ý trước khi đọc số liệu: "SubQ 1M-Preview" là phiên bản được đo trên benchmark ở 1 triệu token. Cửa sổ ngữ cảnh 12 triệu token đầy đủ chỉ truy cập qua API. Subquadratic cho biết benchmark được chạy bởi dịch vụ kiểm thử bên thứ ba, nhưng kết quả chưa được nhà nghiên cứu độc lập tái tạo. Quan trọng hơn, chỉ có ba benchmark được công bố, tất cả tập trung vào đúng hai điểm mạnh SubQ được xây dựng để làm tốt: truy xuất long-context và coding.

RULER 128K: SubQ đạt 95% so với 94,8% của Opus 4.7, chênh lệch về độ chính xác gần như không đáng kể. Điều thực sự đáng chú ý là chi phí: Subquadratic tuyên bố chạy bài đánh giá này trên SubQ tốn khoảng 8 USD, so với khoảng 2.600 USD trên Opus ở cùng độ dài ngữ cảnh.

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

SWE-Bench Verified: SubQ đạt 81,8%, nhỉnh hơn Opus 4.6 (80,8%) nhưng rõ ràng thua Opus 4.7 (87,6%) và GPT-5.5 (88,7%). Khoảng cách so với Opus 4.6 nhỏ và nhạy cảm với cấu hình môi trường kiểm thử.

Ở 12 triệu token: SubQ được báo cáo đạt trên 90% trong bài kiểm tra needle-in-a-haystack ở 12M context, nhưng con số này chưa được xác nhận qua benchmark chính thức. Không có frontier model nào khác được kiểm thử ở độ dài này, nên không có cơ sở để so sánh trực tiếp. Đây là kết quả thú vị nhất về mặt kiến trúc và cũng là kết quả cần tái tạo độc lập nhất trước khi đưa ra kết luận.

SubQ thay đổi gì với RAG, coding agent và chi phí AI?

Khi nào RAG không còn cần thiết?

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

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

Tuy nhiên, RAG vẫn quan trọng ở những khía cạnh mà context window không giải quyết được. Bộ nhớ xuyên phiên làm việc: mô hình không nhớ gì sau khi phiên kết thúc, và hệ thống truy xuất lưu giữ thông tin quan trọng để dùng trong phiên tiếp theo. Kiểm soát quyền truy cập: hệ thống truy xuất có thể thực thi quy tắc "người dùng này chỉ được xem tài liệu của nhóm mình," ngăn rò rỉ dữ liệu ngoài ý muốn. Khả năng kiểm toán: trong môi trường doanh nghiệp, cần chỉ ra chính xác tài liệu nào là nguồn của câu trả lời để kiểm tra và gỡ lỗi. Quản lý kiến thức có cấu trúc: tài liệu liên tục được thêm, cập nhật và xóa, hệ thống truy xuất tổ chức dữ liệu này để mô hình tìm thông tin mới nhất nhanh chóng mà không cần xử lý lại toàn bộ.

Coding agent thay đổi như thế nào với ngữ cảnh 12 triệu token?

Hiện nay, hầu hết coding model không thể nhìn thấy toàn bộ codebase cùng lúc. Vì vậy, các hệ thống phải thêm lớp xử lý bên trên: tìm kiếm file, chia nhỏ, xếp hạng mức độ liên quan, lập kế hoạch nhiều bước, chỉ để giữ đúng ngữ cảnh trong cửa sổ và xây dựng mối liên hệ xuyên file.

Với cửa sổ ngữ cảnh 12 triệu token của SubQ, toàn bộ codebase được tải vào mô hình cùng một lúc. Điều này đơn giản hóa thiết kế agent theo ba cách có ý nghĩa: lập kế hoạch trở nên toàn diện vì mô hình có thể suy luận về kiến trúc, dependency và tương tác xuyên file mà không bỏ sót ngữ cảnh; thực thi nhất quán hơn vì thay đổi trên nhiều file được phối hợp trong một lần thay vì qua các cập nhật tuần tự; và việc review đáng tin cậy hơn vì mô hình có thể tự kiểm tra thay đổi của mình trên toàn bộ codebase, giảm mâu thuẫn.

Chi phí thay đổi như thế nào nếu tuyên bố SubQ là thật?

Trong transformer tiêu chuẩn, chi phí attention tăng theo bình phương với độ dài chuỗi: tăng gấp đôi context có thể đẩy chi phí lên gấp bốn lần. SubQ tuyên bố phá vỡ quy luật đó với chi phí bằng 1/20 so với Claude Opus và mức giảm tính toán lên đến 1.000 lần ở ngữ cảnh 12 triệu token.

Nếu điều này được xác nhận trong production, xử lý long-context sẽ chuyển từ trường hợp đặc biệt tốn kém thành thứ có thể dùng thường xuyên hơn. Tuy nhiên, cùng với cửa sổ ngữ cảnh rẻ, mô hình phải thực sự khai thác hiệu quả thông tin được tải vào. Dựa trên benchmark hiện tại, 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 để kết luận.

Truy cập SubQ bằng cách nào?

SubQ chưa có mặt công khai. Cả ba sản phẩm gồm API cốt lõi, SubQ Code và SubQ Search đang trong private beta và cần đăng ký early access qua website SubQ.

Về mặt kỹ thuật, API được thiết kế để tích hợp dễ dàng: hỗ trợ streaming response, tool/function calling và endpoint tương thích OpenAI. Nghĩa là nếu stack của bạn đã làm việc với OpenAI-style API, thường không cần viết lại phần tích hợp.

SubQ Code được định vị như một coding agent chạy trên command-line, còn SubQ Search tập trung vào long-context search cho workflow nghiên cứu chuyên sâu. Tương tự Claude Code và Perplexity nhưng xây trên kiến trúc SubQ. Giá chưa được công bố, điều này làm cho việc xác nhận độc lập các tuyên bố về chi phí trở nên khó khăn.

Hoài nghi và những câu hỏi còn bỏ ngỏ

Ngay trong những giờ đầu sau khi ra mắt, tranh luận đã nổ ra trên mạng xã hội và Hacker News. Một lập trình viên đặt vấn đề thẳng thắn: SubQ là đột phá lớn nhất kể từ kiến trúc Transformer, hay là "AI Theranos," tức kiểu lừa đảo công nghệ như startup xét nghiệm máu Theranos từng làm?

Phần lớn hoài nghi tập trung vào ba điểm. Thứ nhất, họ tuyên bố cửa sổ ngữ cảnh 12 triệu token nhưng toàn bộ benchmark được công bố đều ở mức 1 triệu token. Thứ hai, công ty đặt tên là Subquadratic nhưng ở một số chỗ họ đề cập đến scaling O(1), tức không thay đổi theo độ dài đầu vào. Nếu thực sự O(1), cửa sổ ngữ cảnh sẽ phải lớn hơn 12 triệu nhiều. Ngay cả O(log n) cũng cho phép giới hạn lớn hơn. Thứ ba, câu chuyện tương tự đã xảy ra với Magic.dev năm 2024: tuyên bố mạnh về cửa sổ ngữ cảnh lên đến 100 triệu token, cải thiện đáng kể hiệu quả với codebase, gọi vốn khoảng 500 triệu USD, nhưng đến đầu 2026 vẫn có rất ít khả năng hiển thị hay áp dụng thực tế.

Những gì đã được xác nhận: 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, không phải tự Subquadratic tự báo cáo. Kết quả cho thấy hiệu suất mạnh về long-context retrieval và cạnh tranh về coding. Tuy nhiên, chưa có nhà nghiên cứu độc lập nào tái tạo những kết quả này, và phạm vi đánh giá hẹp. Cả ba benchmark đều nhấn mạnh đúng những gì SubQ được xây dựng để làm tốt.

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

Kết luận

SubQ đang ở đây, và những tuyên bố khá táo bạo. Hướng đi rõ ràng: loại bỏ giới hạ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ị nó là ngang bằng hoặc vượt frontier model về coding và long-context retrieval ở chi phí thấp hơn nhiều.

Nhưng vẫn còn quá sớm. Toàn bộ model card vẫn chưa được công bố để có cái nhìn đầy đủ hơn về khả năng chung. SubQ Code và API cũng chưa khả dụng công khai. Điều đáng theo dõi không phải là liệu kiến trúc SSA có ý nghĩa về lý thuyết hay không (nó có), mà là liệu nó có giữ được những gì đã tuyên bố khi người dùng thực sự đặt tay lên.

Nguồn: Infinity News — trang tin tức và phân tích chuyên sâu về khoa học, công nghệ, đời sống và kinh tế, mang đến góc nhìn liên ngành để thấu hiểu xu hướng hiện đại.