Hot Chips 2026: High Bandwidth Flash, SSD sınıfı kapasiteyi AI işlemcisinin yanına taşıyor

Hot Chips 2026'nın eğitim günlerinde Anurag Agarwal ve Radhakrishna Giduthuri, High Bandwidth Flash'ın (HBF) makine öğrenmesi iş yüklerini nasıl karşılayabileceğini anlatan bir sunum yaptılar. Chips and Cheese'ye göre HBF, SSD'lerde kullanılan NAND flash teknolojisini alıp işlemci çipiyle aynı paket üzerine yerleşen, hatta geleneksel HBM'nin yanına konabilen küpler halinde istifliyor. Vaat, HBM'den çarpıcı biçimde daha yüksek kapasite ile birlikte kullanılabilir bant genişliği sunmak. Henüz piyasada HBF ürünü bulunmadığından sunum, gerçek silikona değil simülasyonlara ve öngörülere dayandı.

Bellek kıyafeti giymiş bir blok aygıt

HBF, HBM'nin form faktörünü ödünç alsa da arka planda hiç de bellek gibi davranmıyor. Chips and Cheese, bunun Intel'in Optane tarzı ek bir adreslenebilir bellek havuzundan çok, işlemciye entegre edilmiş bir SSD'ye daha yakın olduğunu belirtiyor. Yazılım, HBF ile DRAM arasında veriyi DMA ile taşıyor; erişimler, aygıt sistem belleği değil toplu depolama gibi olduğu için büyük ve hizalanmış olmak zorunda. Ayrıca ana makine, yazma seviyelendirme ve veri saklama yönetimi gibi normalde bir SSD denetleyicisinin üstlendiği görevleri devralıyor. Bu, doğrudan替换 ederek benimsemeyi dışlıyor: HBF'den yararlanmak, bir runtime'a işlenmiş bilinçli bir strateji gerektiriyor.

LLM servislerinde nereye sığabilir

Konuşmacılar vLLM'yi örnek olarak kullandılar. vLLM tipik olarak model ağırlıklarını GPU belleğinde tutuyor ve ağırlıkları ana CPU belleğinde sabitlemek gibi VRAM kullanımını azaltma yollarını zaten araştırıyor. Bu yaklaşım HBF'ye aktarılamaz, çünkü HBF ince taneli rastgele erişimi desteklemiyor. Daha umut verici olan, mixture-of-experts ağırlıklarını HBF'de saklamak ve etkin uzmanları gerektiğinde DMA ile HBM'ye taşımak.

KV önbelleği bir diğer aday, ancak muhtemelen yalnızca her adımda önbelleğin tepesinden bir token alt kümesi okuyan seyrek dikkat (sparse attention) uygulamaları altında; geri kalan büyük bölümü flash'ta soğuk kalır. Bir uyarı: top-k okumaları dağınıkken HBF sıralı erişimi tercih ediyor; olası bir çözüm, seçili satırları önce DMA ile DRAM'e taşımak.

HBF kapasitesi ayrıca cihazlar arası trafiği de azaltabilir. Büyük modeller çoğunlukla birden fazla GPU'ya bölünür ve cihazlar arası scatter ve gather işlemleri, işlem veya bellek bant genişliğinden daha büyük bir darboğaza dönüşebilir. Ek kopyalar flash'tan geldiğinde model ağırlıklarının daha fazlasını her GPU'da çoğaltmak mümkün hale gelir; çünkü HBF'den yapılan bir DMA, cihaz dışına çıkmaktan daha ucuzdur.

Ekonomisi

Agarwal, HBF'nin maliyet açısından ne zaman anlamlı olduğunu açıkladı: bant genişliği sınırlarına ulaşmayan iş yükleri, örneğin daha küçük modeller veya daha küçük batch boyutları. Bir iş yükü bant genişliğine bağlı hale geldiğinde, HBF'nin bant genişliği başına daha zayıf maliyeti — kapasite başına mükemmel maliyetini dengeleyen — genel denkleme HBM'ye kıyasla zarar verir. Sıcak uzmanları HBM ile önbelleğe almak yardımcı olabilir, ancak yalnızca önbellekleme işe yararsa; aksi halde HBF'nin bant genişliği, token başına maliyet üzerinde bir yük haline gelir.

Yazılım faturası

Chips and Cheese yazarı, mühendislik yükü konusunda açıkça şüpheci. HBF'yi programlamak, Linux'ta O_DIRECT veya Windows'ta FILE_FLAG_NO_BUFFERING kullanmaya benziyor: tek bir baytı değiştirmenin 64 KB'lık bir bloğu DRAM'e okumak, değiştirmek ve bloğun tamamını geri yazmak anlamına gelebildiği blok hizalı I/O. Olağan DRAM etrafında kurulu çerçevelerin bu modelden yararlanmak için ciddi biçimde yeniden işlenmesi gerekir. Yazar, gereken eforun model ağırlıklarını sıradan bir SSD'den akıtmaya çok uzak olmadığını — ve SSD yolunun aslında daha kolay olabileceğini savunuyor, çünkü çekirdek tamponlaması blok hizalamasını gizler, rastgele arama ve bayt düzeyinde işlemleri destekler ve flash verimsizliklerini doğal olarak önbelleğe alır. Mevcut SSD ağırlık akışı çalışmaları HBF'ye aktarılabilir ya da yazılım zorlukları benimsenmeyi tamamen engelleyebilir.

Neden önemli

Büyük modelleri servis etmede giderek asıl kısıt ham işlem gücü değil bellek kapasitesi ve HBM arzı darlığını koruyor. HBF, hiyerarşide üçüncü bir katman çiziyor — bayt başına HBM'den ucuz ve ağa bağlı depolamadan daha yakın — bu da mixture-of-experts ve uzun bağlam iş yüklerinde VRAM ayak izini ve GPU'lar arası trafiği azaltabilir. Ancak mimari yükü yazılıma kaydırıyor: vLLM gibi runtime'lar blok erişim disiplinini üstlenmedikçe kapasite kazançları, onları dengeleyebilecek bir sürtünmeyle gelecek. HBF'nin DRAM kıtlığına gerçek bir yanıt olup olmadığı ancak gerçek ürünler piyasaya ulaştığında netleşecek.