TurboQuant của Google vừa nén chỉ mục AI 31GB xuống 4GB — Ý nghĩa thực sự là gì

TurboQuant của Google vừa nén chỉ mục AI 31GB xuống 4GB — Ý nghĩa thực sự là gì

31GB xuống còn 4GB. Đó là con số đã khiến cổ phiếu Micron giảm vài phần trăm vào tháng 6 năm 2026, và là thứ khiến một nửa giới dev trên Twitter hoảng hốt tự hỏi liệu hóa đơn RAG của họ có vừa sụp đổ hay không. Phép toán đằng sau đó là thật: TurboQuant của Google (arXiv 2504.19874, được chấp nhận tại ICLR 2026) nén bộ nhớ của LLM khoảng 6 lần xuống còn khoảng 3 bit cho mỗi giá trị mà gần như không mất độ chính xác. Nhưng hầu hết các bài viết đều sai ở một điểm, và điều đó thay đổi cách bạn nên đọc toàn bộ câu chuyện.

Câu chuyện về nén bộ nhớ AI TurboQuant của Google thực ra là hai câu chuyện mặc cùng một chiếc áo hoodie. Hãy cùng gỡ rối chúng.

Những điểm chính

• TurboQuant là thuật toán nén không cần huấn luyện của Google: giảm KV-cache khoảng 6 lần xuống còn ~3 bit, gần như không mất độ chính xác (ICLR 2026).
• TurboVec là một thư viện Rust bên thứ ba riêng biệt triển khai TurboQuant. Google không phát hành nó.
• Bản demo viral "31GB → 4GB, đánh bại FAISS" là của TurboVec, không phải TurboQuant thô.
• Lợi ích thực sự cho lập trình viên là suy luận ngữ cảnh dài rẻ hơn và chỉ mục RAG nhỏ hơn, nhưng bản phát hành chính thức của Google là một bài báo khoa học, không phải một sản phẩm.

TurboQuant của Google là gì, nói một cách dễ hiểu?

TurboQuant là thuật toán lượng tử hóa vector không cần huấn luyện, không phụ thuộc dữ liệu của Google Research. Nó nén KV cache của LLM khoảng 6 lần, xuống còn khoảng 3 bit cho mỗi giá trị, mà gần như không mất độ chính xác. Nó được công bố trên arXiv 2504.19874 và được chấp nhận tại ICLR 2026. "Không cần huấn luyện" nghĩa là nó hoạt động được ngay trên các mô hình hiện có, không cần tinh chỉnh.

Vậy thực sự những gì đang được nén? Chủ yếu là hai thứ.

Thứ nhất, KV cache. Khi một mô hình đọc cuộc hội thoại của bạn, nó lưu trữ một bản tóm tắt liên tục của mọi thứ cho đến thời điểm đó, gọi là key-value cache (bộ nhớ đệm khóa-giá trị). Hãy coi nó như bộ nhớ ngắn hạn của mô hình. Cửa sổ ngữ cảnh của bạn càng dài, nó càng giữ nhiều bộ nhớ này, và càng ngốn nhiều RAM GPU. Một cuộc trò chuyện 128k token có thể làm KV cache phình lên thành nhiều gigabyte. Đó là lý do việc phục vụ ngữ cảnh dài trở nên đắt đỏ nhanh chóng, và là lý do prompt caching để cắt giảm chi phí API ra đời.

Thứ hai, chỉ mục vector. Các embedding cung cấp sức mạnh cho tìm kiếm ngữ nghĩa và RAG là những mảng lớn các số dấu phẩy động. Lưu trữ hàng triệu chúng ở độ chính xác đầy đủ và bạn sẽ phải đối mặt với hàng chục gigabyte RAM.

TurboQuant nén cả hai. Đây là phần thú vị: nó không cần bất kỳ dữ liệu nào của bạn để làm điều đó. Hầu hết các phương pháp lượng tử hóa đều nghiên cứu một mẫu vector của bạn trước, sau đó xây dựng một codebook được tinh chỉnh cho chúng. TurboQuant bỏ qua bước đó. Nó không phụ thuộc dữ liệu (data-oblivious), nghĩa là nó đạt được tỷ lệ nén mà không cần nhìn vào phân phối của bạn.

Thủ thuật thực sự của TurboQuant không phải là tỷ lệ nén. Mà là nó cần đúng 0 dữ liệu huấn luyện để đạt được tỷ lệ đó.

Đó mới là bước đột phá thực sự. Bạn có thể chĩa nó vào một mô hình bạn đang chạy và nhận được lợi ích ngay lập tức.

TurboQuant và TurboVec: Sự nhầm lẫn mà ai cũng đang hiểu sai

TurboQuant là thuật toán nén của Google (arXiv 2504.19874, ICLR 2026). TurboVec là một thư viện Rust và Python bên thứ ba riêng biệt (RyanCodrai/turbovec) triển khai TurboQuant cho tìm kiếm vector. Google không phát hành TurboVec. Kết quả viral "31GB → 4GB, đánh bại FAISS" thuộc về TurboVec, không phải TurboQuant thô. Nếu bạn chỉ nhớ một điều từ bài viết này, hãy nhớ điều đó.

Đây là nơi mọi thứ trở nên rối rắm. Khi benchmark 31GB→4GB lan truyền vào đầu tháng 6 năm 2026, một vài trang tin (bao gồm Tech Startups) đã chạy tiêu đề nói rằng Google đã "phát hành TurboVec." Điều đó không đúng. Hãy kiểm tra nguồn: TurboVec nằm ở RyanCodrai/turbovec trên GitHub và PyPI. Nó là một thư viện mã nguồn mở được xây dựng bởi một lập trình viên tên là Ryan Codrai. MarkTechPost đã diễn đạt đúng khung, mô tả nó là "một chỉ mục vector Rust với các binding Python, được xây dựng dựa trên thuật toán TurboQuant của Google."

Vậy mối quan hệ rất đơn giản: Google công bố phần toán học, và cộng đồng xây dựng công cụ từ nó. TurboVec là công cụ nổi bật nhất trong số đó.

Google xây dựng thuật toán. Một lập trình viên tên là Ryan Codrai xây dựng thư viện mà mọi người đang chụp màn hình. Chúng không phải là cùng một thứ.

Nếu bạn đang cân nhắc nơi một chỉ mục dựa trên TurboQuant phù hợp bên cạnh thiết lập hiện tại của mình, bài tổng hợp của chúng tôi về các cơ sở dữ liệu vector tốt nhất năm 2026 đặt FAISS, Qdrant và các chỉ mục nén mới hơn cạnh nhau.

TurboQuant nén bộ nhớ mà không phá hỏng độ chính xác như thế nào?

TurboQuant sử dụng một phép quay ngẫu nhiên cộng với một lược đồ lượng tử hóa tọa độ cực (PolarQuant) và một phép chiếu kiểu Johnson-Lindenstrauss (QJL, Quantized Johnson-Lindenstrauss) để phân bố đều các giá trị trước khi lượng tử hóa. Độ méo gần tối ưu này là thứ cho phép nó giảm xuống còn khoảng 3 bit cho mỗi giá trị trong khi giữ độ chính xác gần như nguyên vẹn, mà không cần huấn luyện lại mô hình.

Để tôi giải thích điều đó, bởi vì thuật ngữ chuyên ngành che giấu một ý tưởng khá trực quan.

Khi bạn lượng tử hóa, bạn đang làm tròn các con số xuống ít bit hơn. Mối nguy hiểm là một số chiều của vector mang trọng số lớn hơn nhiều so với các chiều khác, vì vậy việc làm tròn chúng một cách vụng về sẽ phá hỏng kết quả. Cách khắc phục của TurboQuant là quay ngẫu nhiên vector trước. Hãy tưởng tượng việc xáo đều một bộ bài trước khi chia, để không có tay bài nào bị lệch. Sau phép quay, các giá trị được phân bố đều để không có chiều nào chiếm ưu thế, và việc làm tròn ít gây hại hơn rất nhiều.

Đó là phần QJL: một phép chiếu ngẫu nhiên trộn mọi thứ lại với nhau trong khi vẫn bảo toàn khoảng cách. PolarQuant (được trình bày tại AISTATS 2026) sau đó lượng tử hóa các giá trị đã quay trong tọa độ cực, phù hợp với phân phối của chúng hơn là làm tròn lưới đơn thuần.

Kết quả là thứ mà bài báo gọi là độ méo gần tối ưu (near-optimal distortion), nghĩa là nó tiến gần đến giới hạn Shannon lý thuyết về việc bạn có thể mất ít chất lượng đến mức nào ở một ngân sách bit nhất định. Nói một cách dễ hiểu: với 3 bit cho mỗi giá trị, về cơ bản bạn không thể làm tốt hơn nhiều, và TurboQuant đạt được điều đó mà không cần nghiên cứu dữ liệu của bạn.

Để biết cơ chế đầy đủ, blog Google Research và bài báo arXiv là các nguồn chính. InfoQ cũng có một bản phân tích dễ hiểu cho lập trình viên về khía cạnh KV-cache nếu bạn muốn góc nhìn của người thực hành.

31GB → 4GB thực sự có ý nghĩa gì với hóa đơn RAM của bạn?

Một chỉ mục RAG 10 triệu vector cần ~31GB RAM ở độ chính xác đầy đủ giảm xuống còn khoảng ~4GB với nén dựa trên TurboQuant của TurboVec, đủ nhỏ để vừa với một instance phổ thông thay vì một tier nặng về bộ nhớ. Đối với KV cache, mức giảm ~6 lần có nghĩa là khoảng 6 lần số phiên ngữ cảnh dài đồng thời trên cùng một GPU. Đó là phần thực sự xuất hiện trên hóa đơn.

Chúng tôi đã tính toán những con số mà đối thủ cạnh tranh không tính. Trước tiên, một lưu ý trung thực: mọi thứ bên dưới là ước tính và mô hình hóa (tháng 6 năm 2026) từ giá cloud công khai và các tỷ lệ được công bố của bài báo. Chúng tôi chưa chạy TurboVec trong production, vì vậy hãy coi đây là phép toán, không phải một benchmark mà chúng tôi đã đo lường thực tế. Các tier giá tuân theo cùng cơ sở mà chúng tôi sử dụng trong hướng dẫn về giảm chi phí API LLM.

Đây là chỉ mục embedding 10 triệu tài liệu, độ chính xác đầy đủ so với nén bằng TurboVec, ánh xạ tới tier RAM cloud mà bạn thực sự cần:

Bước nhảy từ một máy tối ưu bộ nhớ sang một máy đa dụng nhỏ là toàn bộ câu chuyện. Đối với một chỉ mục tự host, đó thường là sự khác biệt giữa một hóa đơn khiến bạn phải nhăn mặt và một hóa đơn bạn hầu như không để ý. Nếu bạn đang xây dựng pipeline nằm trên nó, bài hướng dẫn của chúng tôi về xây dựng ứng dụng RAG đề cập đến nơi chỉ mục này tồn tại.

Bây giờ đến phía KV-cache, được mô hình hóa ở mức GPU 24GB cố định phục vụ các phiên ngữ cảnh 128k:

Mức cắt giảm KV-cache 6 lần không chỉ tiết kiệm RAM. Nó có thể biến một GPU thành sáu cho việc phục vụ ngữ cảnh dài.

Đó là lý do điều này quan trọng hơn đối với các khối lượng công việc ngữ cảnh dài so với bất kỳ thứ gì khác. Nếu bạn đang phục vụ nhiều cuộc trò chuyện ngắn, KV cache của bạn chưa bao giờ là nút thắt cổ chai. Nếu bạn đang chạy các agent 128k token hoặc phân tích tài liệu, mức cắt giảm 6 lần thay đổi kinh tế học trên mỗi GPU của bạn chỉ sau một đêm. Bài báo của VentureBeat đưa mức tăng thông lượng tối đa lên tới 8 lần trên H100 với tiết kiệm chi phí hơn 50%, phù hợp với phép toán về số phiên đồng thời được mô hình hóa của chúng tôi.

Tại sao cổ phiếu chip nhớ giảm, và Phố Wall có phản ứng thái quá không?

Sau khi TurboQuant được công bố, cổ phiếu Micron, Western Digital và Seagate đã giảm do lo ngại rằng bộ nhớ AI rẻ hơn triệt để sẽ thu hẹp nhu cầu DRAM và HBM trong tương lai, cái gọi là khung "khoảnh khắc DeepSeek". Các nhà phân tích bao gồm Wells Fargo lập luận ngược lại: bộ nhớ rẻ hơn thúc đẩy tổng mức sử dụng nhiều hơn, chứ không ít hơn, thông qua nghịch lý Jevons.

Câu chuyện tự viết nên chính nó. AI hiện là người mua lớn nhất của bộ nhớ băng thông cao, vì vậy nếu một thuật toán của Google cắt giảm nhu cầu bộ nhớ 6 lần, theo logic đó, nhu cầu chip giảm và các nhà sản xuất chip cũng vậy. TechCrunch thậm chí còn với tới sự so sánh "Pied Piper", startup nén hư cấu từ loạt phim Silicon Valley của HBO hứa hẹn nén dữ liệu của thế giới. Cổ phiếu đã giảm vì nỗi sợ đó.

Đây là góc nhìn bình tĩnh hơn, và là góc nhìn mà chu kỳ tin tức hầu như đã bỏ qua. Wells Fargo chỉ ra nghịch lý Jevons: khi một thứ gì đó trở nên rẻ hơn và hiệu quả hơn, chúng ta thường tiêu thụ nhiều hơn tổng thể, chứ không ít hơn. Bộ nhớ AI rẻ hơn có nghĩa là nhiều ứng dụng tung ra các tính năng ngữ cảnh dài hơn, nhiều nhóm tự host các chỉ mục RAG lớn hơn, và nhiều suy luận diễn ra hơn, chấm hết. Những cải thiện hiệu quả có một lịch sử dài làm tăng tổng nhu cầu thay vì giết chết nó.

Thị trường định giá TurboQuant như một kẻ giết chết nhu cầu. Lịch sử nói rằng tính toán rẻ hơn thường có nghĩa là chúng ta chỉ sử dụng nhiều hơn.

Vậy sự sụt giảm có phải là đọc quá không? Có thể, ít nhất là trong ngắn hạn. Một bài báo nghiên cứu không phải là một cuộc cải tạo toàn ngành ngay lập tức. Thị trường phản ứng với một tiêu đề; việc triển khai thực tế sẽ mất nhiều quý, và hiệu ứng kích cầu rất có thể sẽ lấn át khoản tiết kiệm.

Bạn có thể thực sự sử dụng TurboQuant ngay hôm nay không?

Có, một phần. Bản phát hành chính thức của TurboQuant từ Google là bài báo và thuật toán, không phải một sản phẩm dùng được ngay. Nhưng các triển khai cộng đồng đã tồn tại: TurboVec (RyanCodrai/turbovec, trên PyPI) cho chỉ mục vector, và AmesianX/TurboQuant cho llama.cpp (khoảng 5.2 lần, với hỗ trợ cho DeepSeek-V2/V3 và GLM-4.7-Flash thông qua MLA). Hệ sinh thái còn non trẻ nhưng có thể sử dụng được.

Nếu bạn muốn thử phía chỉ mục vector, TurboVec chỉ cách một lệnh pip:

pip install turbovec
# Rust + Python bindings, implements Google's TurboQuant for vector search
# llama.cpp KV-cache impl (DeepSeek/MLA): github.com/AmesianX/TurboQuant
# Python reference impl: github.com/yashkc2025/turboquant

Đối với phía KV-cache trên các mô hình cục bộ, triển khai llama.cpp của AmesianX/TurboQuant là thứ đáng để mắt, đặc biệt nếu bạn chạy các mô hình DeepSeek hoặc GLM với multi-head latent attention. Nó kết hợp tốt với một thiết lập LLM cục bộ, vì KV cache nhỏ hơn có nghĩa là bạn có thể đẩy ngữ cảnh lớn hơn trên cùng một card. Và nếu bạn đang chọn mô hình mở nào để chạy cùng, benchmark các LLM mã nguồn mở tốt nhất của chúng tôi đề cập trực tiếp đến các họ DeepSeek và GLM.

Lưu ý trung thực: hiện tại đây là một bài báo khoa học, và hệ sinh thái đang trong giai đoạn trưởng thành. Sản phẩm chính thức của Google là nghiên cứu, không phải một sản phẩm được hỗ trợ với SLA.

Câu trả lời trung thực: TurboQuant là phép toán có thể triển khai, không phải một nút tải xuống. Ít nhất là vào lúc này.

TurboQuant là thổi phồng hay hàng thật? Một phán quyết trung thực

TurboQuant là thật và thực sự thông minh. Thiết kế không cần huấn luyện của nó là bước đột phá thực sự, và chiến thắng KV-cache quan trọng nhất đối với các khối lượng công việc ngữ cảnh dài. Nhưng nó không phải phép màu: nó là một tiến bộ lượng tử hóa trong số nhiều tiến bộ, con số tiêu đề 31GB→4GB thuộc về TurboVec chứ không phải Google, và sự hoảng loạn cổ phiếu đã đọc quá một kết quả nghiên cứu.

Theo kinh nghiệm của chúng tôi khi tinh chỉnh chi phí suy luận và RAM cho khách hàng, điều quyết định một kỹ thuật như thế này có đáng áp dụng hay không chính là rào cản. Không cần huấn luyện thắng lớn ở đây, bởi vì không có chu kỳ tinh chỉnh, không có codebook để duy trì, không có phẫu thuật mô hình. Bạn có thể gắn nó vào thứ bạn đang chạy.

Những gì nó thay đổi:

• Suy luận ngữ cảnh dài rẻ hơn, đó là nơi chi phí bộ nhớ thực sự gây đau.
• Các chỉ mục RAG tự host nhỏ hơn vừa với phần cứng rẻ hơn.
• Một tùy chọn nén bạn có thể áp dụng mà không cần huấn luyện lại bất cứ thứ gì.

Những gì nó không thay đổi:

• Nó sẽ không làm được nhiều cho các khối lượng công việc ngữ cảnh ngắn, mô hình nhỏ, nơi KV cache chưa bao giờ là nút thắt cổ chai.
• Nó không làm lỗi thời phương pháp lượng tử hóa hiện có của bạn chỉ sau một đêm; nó là một sự bổ sung, không phải một sự thay thế.
• Bản phát hành chính thức của Google vẫn là một bài báo, vì vậy công cụ cấp production hiện thuộc về cộng đồng.

Nếu bạn đang cố gắng tìm hiểu điều này có ý nghĩa gì đối với hóa đơn suy luận hoặc RAM của chính mình, đó chính xác là loại mô hình hóa chi phí mà chúng tôi làm cho khách hàng tại Techsy. Nhận tư vấn miễn phí nếu bạn muốn một đôi mắt thứ hai xem xét nó.

Về tác giả

Mert Batur Gurbuz là Đồng sáng lập của Techsy.io, nơi đội ngũ triển khai các AI agent, hệ thống tự động hóa, và pipeline giọng nói/SDR cho khách hàng B2B. Anh học tại Đại học Birmingham và viết về ngăn công cụ LLM mà đội ngũ Techsy thực sự sử dụng trong production. Kết nối trên LinkedIn.

Câu hỏi thường gặp

Google TurboQuant là gì?

TurboQuant là thuật toán lượng tử hóa vector không cần huấn luyện của Google Research, được công bố trên arXiv 2504.19874 và được chấp nhận tại ICLR 2026. Nó nén KV cache của LLM khoảng 6 lần, xuống còn khoảng 3 bit cho mỗi giá trị, mà gần như không mất độ chính xác. Vì nó không phụ thuộc dữ liệu, nó hoạt động trên các mô hình hiện có mà không cần bất kỳ tinh chỉnh hay huấn luyện lại nào.

Google có thực sự phát hành TurboVec không?

Không. TurboQuant là thuật toán của Google. TurboVec là một thư viện Rust và Python bên thứ ba riêng biệt (RyanCodrai/turbovec) được xây dựng trên nền TurboQuant bởi một lập trình viên độc lập. Một số trang tin đã gán sai cho Google việc phát hành TurboVec khi benchmark 31GB→4GB viral lan truyền, nhưng GitHub cho thấy đó là một dự án cộng đồng.

TurboQuant có giống TurboVec không?

Không. TurboQuant là thuật toán nén mà Google công bố. TurboVec là một thư viện triển khai thuật toán đó cho tìm kiếm vector. Một bên là phần toán học; bên kia là một công cụ được xây dựng bằng phần toán học đó. Kết quả nổi tiếng "31GB → 4GB, đánh bại FAISS" là của TurboVec, không phải thứ mà Google trực tiếp tung ra.

TurboQuant có làm mất độ chính xác không?

Gần như không mất độ chính xác là tuyên bố tiêu đề từ bài báo, ngay cả ở khoảng 3 bit cho mỗi giá trị. Thuật toán đạt được độ méo gần tối ưu (gần giới hạn Shannon) bằng cách quay ngẫu nhiên các vector trước khi lượng tử hóa, để không có chiều nào chiếm ưu thế. Trong thực tế, điều đó có nghĩa là mức giảm chất lượng đủ nhỏ để không đáng kể đối với hầu hết các khối lượng công việc.

TurboQuant tiết kiệm bao nhiêu RAM?

Khoảng 6 lần trên KV cache, giảm xuống còn khoảng 3 bit cho mỗi giá trị. Ở phía chỉ mục vector, TurboVec đã demo một chỉ mục 10 triệu tài liệu giảm từ 31GB xuống khoảng 4GB, cắt giảm bộ nhớ tới 92%. Mức tiết kiệm thực tế của bạn phụ thuộc vào mốc độ chính xác cơ sở của bạn và liệu bạn đang nén KV cache, embedding, hay cả hai.

Đây chỉ là thổi phồng, tại sao cổ phiếu bộ nhớ giảm?

Đây là một tiến bộ thực sự, nhưng sự hoảng loạn đã đọc quá một kết quả nghiên cứu. Micron, Western Digital và Seagate giảm do lo ngại rằng bộ nhớ AI rẻ hơn cắt giảm nhu cầu chip. Wells Fargo phản bác bằng nghịch lý Jevons: bộ nhớ rẻ hơn, hiệu quả hơn thường làm tăng tổng mức sử dụng. Một bài báo cũng không phải là một cuộc cải tạo ngành ngay lập tức, vì vậy phản ứng ngắn hạn có vẻ thái quá.

Tôi có thể sử dụng TurboQuant ngay hôm nay không?

Một phần. Bản phát hành chính thức của Google là bài báo và thuật toán, không phải một sản phẩm. Các triển khai cộng đồng đã tồn tại: TurboVec trên PyPI cho chỉ mục vector, AmesianX/TurboQuant cho llama.cpp (DeepSeek-V2/V3 và GLM-4.7-Flash thông qua MLA), và yashkc2025/turboquant như một tham chiếu Python. Hệ sinh thái còn non trẻ nhưng đã có thể sử dụng được.

TurboQuant khác với lượng tử hóa tôi đã làm như thế nào?

Hầu hết lượng tử hóa nghiên cứu một mẫu dữ liệu của bạn để xây dựng một codebook được tinh chỉnh. TurboQuant không cần huấn luyện và không phụ thuộc dữ liệu, vì vậy nó đạt được tỷ lệ của mình mà không cần nhìn vào phân phối của bạn. Nó cũng nhắm mục tiêu cụ thể vào KV cache và chỉ mục vector, với độ méo gần tối ưu, thay vì chỉ nén trọng số mô hình.

TurboQuant có hoạt động với DeepSeek hoặc llama.cpp không?

Có, thông qua triển khai llama.cpp của AmesianX/TurboQuant, báo cáo nén khoảng 5.2 lần và hỗ trợ DeepSeek-V2/V3 cùng GLM-4.7-Flash thông qua multi-head latent attention (MLA). Điều đó khiến nó trở thành một lựa chọn thực tế nếu bạn tự host các mô hình đó và muốn KV cache nhỏ hơn cho ngữ cảnh dài hơn trên cùng phần cứng.

TurboQuant thực sự giúp ích nhiều nhất khi nào?

Nó giúp ích nhiều nhất với suy luận ngữ cảnh dài và các chỉ mục RAG tự host lớn, nơi bộ nhớ là nút thắt cổ chai thực sự. Mức cắt giảm KV-cache 6 lần có nghĩa là nhiều phiên ngữ cảnh 128k đồng thời hơn trên mỗi GPU, và một chỉ mục embedding được nén vừa với các instance rẻ hơn. Nó giúp ích ít nhất cho các cuộc trò chuyện ngữ cảnh ngắn và mô hình nhỏ, nơi KV cache chưa bao giờ là yếu tố chi phí của bạn.