Hot Chips 2026: Bộ nhớ Flash băng thông cao không phải là cứu tinh bộ nhớ như bạn nghĩ

Tại Hot Chips 2026, một phiên hướng dẫn đã trình bày lời hứa và nỗi đau của High Bandwidth Flash (HBF). Ý tưởng đơn giản: khối lượng công việc học máy đang thiếu dung lượng DRAM, và flash rẻ hơn nhiều mỗi gigabyte. Vậy tại sao không đặt flash trên package, kiểu HBM, và cấp cho nó giao diện rộng, nhanh?

HBF không phải là HBM. Nó thậm chí không phải là bộ nhớ. Nó là một thiết bị khối tình cờ nằm cạnh die tính toán của bạn. Phần mềm phải di chuyển dữ liệu giữa HBF và DRAM bằng DMA, trong các khối lớn được căn chỉnh, và máy chủ phải đảm nhận nhiệm vụ của bộ điều khiển SSD như cân bằng mài mòn và duy trì dữ liệu. Điều đó có nghĩa là không cắm là chạy. Bạn không thể chỉ ánh xạ nó vào không gian địa chỉ của mình và bắt đầu đọc byte.

Bài nói đã trình bày cách một runtime như vLLM có thể thích nghi. Một ý tưởng: lưu trữ các chuyên gia Mixture-of-Experts (MoE) trong HBF và DMA các chuyên gia đang hoạt động vào HBM theo yêu cầu. Một ý tưởng khác: đặt KV cache trong HBF, nhưng chỉ khi bạn sử dụng sparse attention đọc một tập con nhỏ các token mỗi bước. Vấn đề là những lần đọc đó nằm rải rác, trong khi HBF ưa thích truy cập tuần tự—vì vậy bạn sẽ DMA các hàng top-k vào DRAM trước.

Cũng có khía cạnh mạng. Các mô hình lớn phân mảnh trên nhiều GPU dành nhiều thời gian cho scatter/gather giữa các thiết bị. HBF có thể cho phép bạn sao chép nhiều trọng số cục bộ hơn, đánh đổi băng thông flash cho lưu lượng ngoài package. DMA từ flash không miễn phí, nhưng rẻ hơn so với việc đi ra ngoài thiết bị.

Về chi phí, HBF chỉ thắng khi bạn không bị giới hạn băng thông. Mô hình nhỏ, batch nhỏ—ổn. Khoảnh khắc bạn bão hòa băng thông của HBF, bất lợi về chi phí trên mỗi băng thông so với HBM giết chết thỏa thuận. Lưu trữ các chuyên gia nóng trong HBM giúp ích, nhưng chỉ khi tỷ lệ cache hit đủ cao.

Gánh nặng phần mềm mới là câu chuyện thực sự. Làm việc với HBF giống như sử dụng O_DIRECT hoặc FILE_FLAG_NO_BUFFERING. Một lần ghi một byte có nghĩa là đọc một khối 64 KB, sửa đổi nó, và ghi lại. Đó là kỷ luật lưu trữ khối, không phải ngữ nghĩa bộ nhớ. Bất kỳ framework nào xây dựng cho DRAM sẽ cần viết lại lớn, và chuyển đổi framework có nghĩa là làm lại công việc đó.

Thành thật mà nói, nỗ lực để tận dụng HBF không khác xa việc stream trọng số từ SSD—ngoại trừ việc kernel OS có thể che giấu căn chỉnh khối SSD sau bộ đệm và cache. HBF không có sự cách ly như vậy. Cho đến khi sản phẩm tồn tại, câu hỏi liệu lợi ích dung lượng có biện minh cho chi phí kỹ thuật hay không vẫn còn bỏ ngỏ.