Depolamanın da bir yerleşkesi var
Habitat’ın bir kullanıcıya yanıt vermesi için yalnızca modeli çalıştıran işlemci gerekmiyor. Ayarlar, durum bilgisi ve kimlik doğrulama verileri de zamanında gelmeli. OpenAI’nin yeni mühendislik açıklaması, bu verileri kullanıcıya yaklaştırmanın bazı bölgelerde fiziksel kapasiteye takıldığını anlatıyor. Aynı veri merkezinde depolamaya ayrılan yer, ek hesaplama hizmetine ayrılamıyor. Güç ve soğutma sınırlıysa bu tercih, iki yazılım bileşeni arasındaki yerleşim kararından daha büyük: işletmeci aynı bölgenin fiziksel kapasitesini iki iş arasında paylaştırıyor.[1]
Şirket, Habitat’ın 40 coğrafi bölgeye yayıldığını ve 500 petabayttan fazla veri taşıdığını söylüyor. Bu iki sayı, her bölgede eşit miktarda veri veya eşit boş kapasite bulunduğunu göstermiyor. OpenAI, bazı bölgelerin kullanıcı trafiğinden düşen depolama payını barındıramadığını açıkça belirtiyor. Verinin uzakta kalması bu durumda yalnızca bir yazılım tercihine bağlanamaz. Yerel depolamayı büyütmek ile oraya daha fazla sunum hesaplaması koymak arasında gerçek bir yerleşim tercihi var. Coğrafi yayılım tek başına bölgesel kaynak dağılımını açıklamıyor.[1]
Her veriyi her yere kopyalamak
Habitat bu baskıya bütün veriyi her yere çoğaltarak yanıt vermiyor. Kimlik doğrulama gibi küçük ve gecikmeye duyarlı kümeler geniş çoğaltılıyor; geri kalan sık okunan nesneler için yakındaki Valkey önbellekleri kullanılıyor. Önbellek, büyük depolamanın tamamını aynı bölgeye taşıma ihtiyacını daraltıyor. Fakat her önbellek kopyasının güncel kalması gerekiyor. Cosmos DB’nin değişiklik akışı, ilgili yerel kopyaları geçersiz kılıyor; sonraki okuma yeni değeri getiriyor. Böylece kapasiteyi yalnızca daha çok kopyaya ayırmak yerine, hangi kopyanın ne zaman yenileneceği de sistemin işi oluyor.[1]
Bu düzen, yerel kapasitenin yerine sınırsız bir yazılım kaynağı koymuyor. Önbellekte bulunmayan veri yine uzaktaki depolamadan geliyor; OpenAI en yavaş okumaların bu yolculuğu yapabildiğini belirtiyor. Kullanıcının beklediği süre açısından ortalama davranış ile bu yavaş yol ayrı önem taşıyor. Daha iyi yerleşim aynı yazılımı hızlandırabilir; daha iyi önbellekleme de aynı yerleşimde bazı yolculukları önleyebilir. Hangisinin ne kadar ek tesis kapasitesi sağlayacağını hesaplamak için okuma karışımı, önbellek kullanımı ve yerel kaynak tüketimi gerekiyor. Açıklama, bu hesabı tamamlayacak tesis düzeyinde enerji ölçümü vermiyor.[1]
Flaş kapasitesinin karşılığında sorgu hızı
OpenAI’nin geliştirdiği sonraki depolama sistemi bu tercihi başka bir katmana taşıyor. RocksDB Cloud ile Raft çoğaltmasını birleştiren tasarım, büyük veri türleri için ayrıştırılmış depolama ve fiziksel çoğaltma kullanıyor. Şirketin açıkladığı karşılık, daha az flaş kapasitesi gereksinimiyle daha düşük en yüksek sorgu hızı. Burada eksabayt hedefi tek başına hizmet kapasitesini anlatmıyor. Çok veri tutmakla çok isteği aynı sürede yanıtlamak farklı işler. Henüz geliştirme aşamasındaki bu sistemi, mevcut Cosmos DB hizmetinin teslim edilmiş kapasitesine eklemek de mümkün değil.[1]
Habitat’ın altyapı dersi, depolama ve hesaplamanın aynı yerel kaynaklar üzerinde karşılaşması. Yazılım tasarımı bu karşılaşmanın sonucunu değiştirebilir: küçük veriyi geniş çoğaltmak, sık okunanı yakında tutmak ve hacimli veriyi başka bir düzene taşımak farklı yükleri dağıtıyor. Bunun yanında başka bir açıklama da geçerli: bazı tercihleri güç sınırından çok güvenilirlik ve ürünlerin erişim biçimi yönlendiriyor. OpenAI’nin anlatımı bu nedenlerin birlikte çalıştığını gösteriyor. Bir hizmetin kullanılabilir kapasitesini anlamak için modelin yanındaki depolama yolu da hesaba girmeli; satın alınmış hızlandırıcı sayısı o yolu tarif etmiyor.[1]