NeuroBrix, yapay zeka model çıkarımı için evrensel bir container formatı olan .nbx'i öneriyor

NeuroBrix, herhangi bir yapay zeka modelini — hesaplama grafiğini ve ağırlıklarını — tek bir dosyada paketlemeyi ve sonucu modelin ailesinden bağımsız olarak tek bir çıkarım motorunun çalıştırmasını sağlamayı amaçlayan .nbx adlı bir container formatı önerdi. dev.to'da yayımlanan bir yazıda NeuroBrix'ten Hocine Benkelaya, yaklaşımın halihazırda dil modelleri ve konuşma tanıyıcılardan metin okuma seslerine, görüntü ve video üreticilerine ile çözünürlük yükselticilere kadar dokuz aileyi kapsayan 49 modeli, yığının hiçbir yerinde modele özgü kod olmadan kapsadığını söylüyor.

Format ne içeriyor

Yazıya göre bir .nbx dosyası iki şey taşıyor: neyin hesaplanacağını tanımlayan bir grafik ve hesaplamada kullanılan ağırlıklar. Bu eşleşme bir modeli tam olarak tanımladığı için, container'ı okuyan motorun çalıştırdığı mimarinin ne olduğunu bilmesi hiç gerekmiyor — yalnızca planlanacak bir grafik ve yüklenecek ağırlıklar olduğunu bilmesi yeterli.

Motor bunu nasıl çalıştırıyor

NeuroBrix yürütmeyi üç parçaya bölüyor. Prism adlı bir planlayıcı, container'ı bir donanım profiliyle birlikte okuyup yerleşimi belirliyor: model tek bir GPU'ya sığıyor mu, birkaçına yayılmalı mı, akıtılmalı mı yoksa en büyük işlemleri parçalara (tile) bölünmeli mi. Yürütme daha sonra iki motordan biri üzerinden ilerliyor — PyTorch kullanmayan ve projenin kendi nbxtensor kütüphanesi üzerine kurulu Triton tabanlı bir motor ya da isteğe bağlı bir PyTorch motoru. İşin kendisi, projenin sertifikalı çekirdekler (certified kernels) dediği şey tarafından yapılıyor; ayarları her çalıştırmada otomatik ayarlanmak yerine GPU sınıfı başına bir kez kanıtlanıyor.

Komut satırı deneyimi de container'dan türüyor. Modelin ailesi dosyadan okunduğu için araç, o ailenin ihtiyaç duyduğu girdileri istiyor — bir dil modeli için metin, konuşma tanıma için ses, bir çözünürlük yükseltici için görüntü — ve sonrasındaki her şey aynı yolu izliyor.

Öne sürülen faydalar

Benkelaya'ya göre format, model desteğinin ekonomisini değiştiriyor. Bir model eklemek bir container paketlemek anlamına geliyor; bir loader veya pipeline sınıfı yazmak değil, dolayısıyla motor, planlayıcı ve çekirdekler hiç dokunulmadan kalıyor. Motordaki bir hata düzeltildiğinde tüm modeller aynı kod yolunu izlediği için hepsi aynı anda bundan yararlanıyor.

Öne sürülen diğer fayda ise doğrulama. Her sürümde reportedly tüm 49 model tek bir giriş noktasından iki motor üzerinden çalıştırılıyor — 0.6.0 sürümünün 4x V100 donanımında 196 test hücresinin 196'sını geçtiği, çıktıların değerlendirilmiş referans çıktılarıyla bayt bayt karşılaştırıldığı ve yinelenen çalıştırmaların özdeş sonuçlar ürettiği belirtiliyor. Yazıya göre taşınabilirlik de her modelden değil motordan geliyor: container'ların NVIDIA, AMD, Intel ve Apple GPU'ları üzerinde Linux, Windows ve macOS'ta çalıştığı söyleniyor.

Ekosistem ve yol haritası

Proje GitHub'da Apache 2.0 lisansıyla sunuluyor ve pip ile kurulabiliyor; 49 container'ı dağıtan bir Model Hub mevcut. Çevresindeki parçalar arasında PyTorch içermeyen tensör kütüphanesi nbxtensor; Apple GPU'ları için bir Triton derlemesi olan triton-ext; ve hâlâ geliştirilmekte olan, üç büyük masaüstü platformu için bir masaüstü uygulaması olan Studio yer alıyor. Eksik modeller GitHub issue'ları üzerinden istenebiliyor; burada engine'in fork'ları değil container'lar haline geliyorlar.

Planlanan çalışmalar arasında hız için çekirdek kaynaştırma (kernel fusion) ve grafik düzeyinde sadeleştirme; AMD ve Intel GPU'ları, çok çekirdekli CPU'lar, ARM64 ile NVLink, PCIe ve ağlar üzerinden çoklu GPU kurulumları için destek; topluluk tarafından sertifikalandırılmış donanım profilleri; nbxtensor içinde eğitim; yerel agent'lar; uygulamalar için JSON arayüzlü yerel bir sunucu; Rust ile yeniden yazılan nbxtensor 2.0; ve .nbx'i açık bir model standardı haline getirme yer alıyor.

Neden önemli

Günümüzdeki çoğu çıkarım yığınında yeni bir model için destek kod olarak geliyor — bir pipeline sınıfı, bir loader, belirli bir attention şeması veya önbellek düzeni için özel durumlar — ve bu maliyet, bir yığının kapsamak istediği her model ve modalitede katlanarak artıyor. Evrensel bir container sorunu yeniden çerçeveliyor: grafik ve ağırlıklar yeterliyse, entegrasyon paketleme işi haline geliyor, motor düzeltmeleri tüm modellere aynı anda ulaşıyor ve platformlar arası destek model başına yeniden inşa edilmek yerine miras alınıyor. Model kimliğine kayıtsız bir runtime, yığın tipik model kodunun beraberinde getirdiği framework kilitlenmesini de zayıflatırdı. Öte yandan kaynak konusundaki uyarı geçerli: tüm kapsam ve doğrulama rakamları NeuroBrix'in kendi duyurusundan geliyor ve .nbx'in gerçek bir açık standart olup olmayacağı, projenin kendi hub'ının dışındaki benimsenmeye bağlı olacak.