Hot Chips 2026: High Bandwidth Flash (HBF) – Giải pháp mới cho cơn khát bộ nhớ AI?

Các mô hình machine learning đang ngốn DRAM với tốc độ chóng mặt, kéo theo chi phí phần cứng tăng vọt. Liệu High Bandwidth Flash (HBF), một công nghệ kết hợp flash memory với kiến trúc giống HBM, có thể là lối thoát? Bài thuyết trình tại Hot Chips 2026 đã hé lộ tiềm năng và cả những trở ngại không nhỏ mà công nghệ này đang đối mặt.

Bài viết này tổng hợp lại những điểm chính từ bài nói chuyện của Anurag Agarwal và Radhakrishna Giduthuri, tập trung vào các mô phỏng, dự đoán và cách phần mềm có thể thích nghi để khai thác HBF trong tương lai.

HBF là gì? Không phải một loại RAM mới

Về bản chất, HBF vẫn sử dụng công nghệ flash memory giống hệt trong SSD hiện nay. Điểm khác biệt nằm ở cách chúng được đóng gói và kết nối. HBF được xếp thành các cube (khối) đặt ngay trên cùng package với chip xử lý, thậm chí có thể nằm cạnh các cube HBM quen thuộc.

Mục tiêu của HBF là cung cấp dung lượng cao hơn nhiều so với HBM, trong khi vẫn đảm bảo một mức băng thông chấp nhận được. Vì chưa có sản phẩm HBF thương mại nào tồn tại, toàn bộ bài trình bày xoay quanh các mô phỏng, số liệu dự đoán và các chiến lược phần mềm tiềm năng.

Minh họa kiến trúc HBF với các cube flash đặt trên package chip

Điều quan trọng cần nhấn mạnh: HBF không giống Intel Optane – nó không thể hoạt động như một vùng nhớ (memory pool) thông thường. Thay vào đó, HBF gần như là một ổ SSD được tích hợp lên processor. Phần mềm phải dùng DMA (Direct Memory Access) để di chuyển dữ liệu giữa HBF và DRAM.

Ngoài ra, các thao tác truy cập HBF phải tuân theo cơ chế khối (block) lớn, căn chỉnh chặt chẽ như khi làm việc với ổ cứng, thay vì truy cập ngẫu nhiên từng byte như RAM. Điều này có nghĩa là HBF không phải là một giải pháp cắm là chạy – các nhà phát triển phải tự quản lý cả các chức năng của SSD controller như cân bằng độ mòn (write leveling) và đảm bảo giữ dữ liệu (data retention).

Tiềm năng ứng dụng trong vLLM và mô hình ngôn ngữ lớn

Để tận dụng HBF, các nhà phát triển phải xây dựng một chiến lược đặc biệt và tích hợp vào runtime. Giduthuri đã lấy vLLM làm ví dụ điển hình – một framework phổ biến để chạy mô hình ngôn ngữ lớn (LLM).

Thông thường, vLLM giữ toàn bộ trọng số mô hình trong VRAM của GPU. Các giải pháp giảm tải VRAM hiện nay, như lưu trọng số vào pinned CPU memory, sẽ không hiệu quả với HBF vì nó không hỗ trợ truy cập ngẫu nhiên chi tiết.

Tuy nhiên, có một số hướng đi hứa hẹn:

• Lưu trữ các expert của mô hình MoE (Mixture of Experts) trong HBF. Khi cần, phần mềm sẽ dùng DMA để nạp các expert đang hoạt động vào HBM.

• Đặt KV cache (bộ nhớ đệm cho key-value attention) vào HBF, nhưng chỉ phù hợp với các kiến trúc attention thưa (sparse attention). Phương pháp này chỉ đọc một tập con token từ đầu KV cache mỗi bước, cho phép phần lớn cache nằm "nguội" trong flash, giảm áp lực lên băng thông hạn chế của HBF.

Sơ đồ so sánh băng thông và dung lượng giữa HBM và HBF

Một cơ hội đáng chú ý khác là dùng HBF để giảm giao tiếp giữa các thiết bị. Các mô hình lớn thường bị phân mảnh (sharded) trên nhiều GPU, khiến hiệu năng bị bó buộc bởi các thao tác scatter/gather liên GPU. HBF có thể giảm bớt vấn đề này bằng cách cho phép nhân bản nhiều trọng số mô hình hơn trên nhiều GPU khác nhau. Việc DMA dữ liệu từ flash không hề rẻ, nhưng vẫn rẻ hơn so với việc phải truyền dữ liệu ra ngoài thiết bị.

Khi nào HBF thực sự đáng giá?

Agarwal đã trình bày về góc độ chi phí, và kết luận rằng HBF chỉ thực sự hiệu quả khi workload không chạm tới giới hạn băng thông. Điều này thường xảy ra với các mô hình nhỏ hơn hoặc batch size nhỏ hơn.

Nếu một workload bị giới hạn bởi băng thông, bài toán chi phí của HBF trở nên bất lợi, vì cả chi phí trên mỗi đơn vị dung lượng lẫn chi phí trên mỗi đơn vị băng thông đều phải được tính vào.

HBF vượt trội về chi phí trên dung lượng, nhưng lại kém hơn HBM về chi phí trên băng thông. Ông cũng đề cập đến việc dùng HBM để cache các expert "nóng", nhưng cách tiếp cận này cũng tiềm ẩn rủi ro: nếu cache không hoạt động tốt, băng thông của HBF có thể ảnh hưởng tiêu cực đến chi phí trên mỗi token.

Những thách thức phần mềm khổng lồ

Mặc dù HBF có thể giảm bớt phần nào vấn đề dung lượng DRAM, nhưng thách thức về phần mềm là vô cùng lớn. Làm việc với HBF giống như làm việc với API truy cập đĩa cấp thấp, như FILE_FLAG_NO_BUFFERING trong Windows hay O_DIRECT trong Linux.

Phần mềm phải thực hiện các thao tác truy cập với khối dữ liệu lớn, căn chỉnh đúng, thay vì tự do địa chỉ hóa ở mức byte. Việc sửa một byte dữ liệu duy nhất có thể đồng nghĩa với việc phải đọc cả một khối 64 KB vào DRAM, sửa đổi, rồi ghi toàn bộ khối đó trở lại flash.

Đây giống như làm việc với thiết bị lưu trữ khối hơn là bộ nhớ thông thường. Một framework phần mềm được thiết kế cho hệ thống dựa trên DRAM sẽ cần thay đổi lớn để tận dụng HBF. Việc chuyển sang một framework khác cũng đồng nghĩa với việc làm lại toàn bộ công việc tối ưu hóa.

Minh họa luồng dữ liệu và quá trình DMA giữa HBF, DRAM và GPU

Liệu HBF có phải là cứu tinh?

Tác giả bài viết gốc trên Chips and Cheese còn đưa ra một nhận định táo bạo: nỗ lực để tận dụng HBF có lẽ không khác gì nhiều so với việc trực tiếp giảm sử dụng DRAM bằng cách stream trọng số mô hình trực tiếp từ SSD.

Trên thực tế, việc tận dụng SSD thông thường còn có vẻ dễ dàng hơn. Hệ điều hành có thể trừu tượng hóa (abstract) những khó khăn của việc truy cập theo khối nếu không dùng FILE_FLAG_NO_BUFFERING hay O_DIRECT. Bộ đệm trong kernel sẽ cho phép phần mềm tự do tìm kiếm và thực hiện thao tác đọc/ghi ở mức byte, đồng thời đóng vai trò như một cache tự nhiên, bảo vệ phần mềm khỏi những bất cập của flash memory.

Liệu các nỗ lực stream trọng số từ SSD hiện tại có thể áp dụng cho HBF? Đây vẫn là một câu hỏi bỏ ngỏ. Dù sao đi nữa, khi các sản phẩm HBF thực sự xuất hiện trên thị trường, chúng ta sẽ có câu trả lời rõ ràng nhất. Trong bối cảnh khan hiếm DRAM hiện nay, bất kỳ giải pháp nào có thể giảm áp lực chi phí đều đáng được quan tâm, nhưng cũng cần nhìn nhận một cách thực tế về những rào cản kỹ thuật đang chờ đợi phía trước.