2 puan yazan GN⁺ 2024-08-10 | 1 yorum | WhatsApp'ta paylaş
  • GPU’lar, CPU, depolama, ağ ve belleğin aksine henüz bol kaynaklar gibi sanallaştırılamadı; Thunder Compute bunu sistem katmanında çözmeyi hedefliyor
  • Arzı artırmanın odağı yalnızca daha fazla çip üretmek değil, halihazırda devreye alınmış GPU’ları daha iyi kullandıran yazılım kullanımında da yatıyor
  • Mevcut optimizasyonlar çıkarım toplu işleme ya da eğitim işi kuyruklama gibi iş yükü katmanında kalırken, GPU sanallaştırması görece daha az ele alınmış bir sistem alanını hedefliyor
  • NVIDIA H100, saatlik $1.38’den başlayan fiyatlarla VS Code, CLI ve tarayıcı üzerinden kullanılabiliyor; AWS’ye kıyasla %80 tasarruf, sözleşmesizlik, egress ücreti olmaması ve ölçeklenebilir depolama öne çıkarılıyor
  • 4 yıl boyunca gizlilik içinde bir araştırma prototipi geliştirildi ve şirket, veri merkezlerindeki GPU kapasitesi iyileştirmesini kendi bulutu ile kurumsal ortaklar üzerinden dağıtmayı amaçlıyor

GPU sanallaştırmasıyla düşük kullanım oranını iyileştirme

  • Thunder Compute, bilgi işlemde kıt olan birçok kaynağın zamanla bol hale geldiğini, ancak GPU’ların henüz aynı dönüşümü yaşamadığını düşünüyor
  • GPU’ları bol hale getirmenin yolu yalnızca daha fazla çip üretmekten değil, halihazırda kurulu çipleri daha verimli kullanan yazılımdan da geçiyor
  • Bugün GPU’lar çoğu zaman yeterince verimli kullanılmıyor ve mevcut çözümler ağırlıklı olarak iş yükü katmanına odaklanıyor
    • Çıkarım istekleri toplu işleniyor
    • Eğitim işleri birden çok sunucu filosu arasında kuyruğa alınıyor
  • CPU, depolama, ağ ve bellek için sanallaştırma yaygınlaşmış olsa da, GPU’larda henüz aynı düzeyde bir sanallaştırma yerleşmiş değil
  • Thunder Compute’un temel yaklaşımı, bu boş alanı sistem katmanında ele almak

Ürün yaklaşımı ve dağıtım planı

  • Thunder Compute, ticari odağa sahip bir sistem laboratuvarı olarak, en yeni GPU sanallaştırma araştırmalarını üretim ortamına taşımayı hedefliyor
  • Ekip, Citadel Securities, Aquatic ve AWS çıkışlı altyapı uzmanları ile sistem araştırmacılarından oluştuğunu belirtiyor
  • 4 yıl boyunca gizlilik modunda bir araştırma prototipi geliştirildi; şimdi ise sonuçlar kendi bulutları ve kurumsal ortaklar üzerinden dağıtılıyor
  • Ürün açıklamasına göre NVIDIA H100, saatlik $1.38’den başlayan fiyatlarla kullanılabiliyor
    • VS Code, CLI ve tarayıcı üzerinden erişilebiliyor
    • AWS’ye kıyasla %80 tasarruf iddia ediliyor
    • Sözleşme yok, egress ücreti yok ve ölçeklenebilir depolama sunuluyor
  • Amaç, veri merkezi GPU kapasitesini kademeli olarak iyileştirmek

1 yorum

 
GN⁺ 2024-08-10
Hacker News yorumları
  • Oldukça ilginç. Eskiden yalnızca video transcoding için GPU-over-IP'ye ihtiyaç duyduğum bir dönem olmuştu
    Home lab sunucumda performansı zayıf bir AMD GPU vardı; video encode etmeye çalıştığım her seferinde kernel'i çökertiyordu. Oyun PC'mde ise bir NVIDIA RTX 3080 vardı. Bu yüzden https://github.com/steelbrain/ffmpeg-over-ip'yi yaptım; Windows makinede sunucuyu, medya sunucusunda (Plex, Emby, Jellyfin vb.) istemciyi çalıştırdım ve kusursuz çalıştı

    • Henüz Show HN'de paylaşmadıysan değerlendirmekte fayda var
      https://gist.github.com/tzmartin/88abb7ef63e41e27c2ec9a5ce5d...
      https://news.ycombinator.com/showhn.html
      https://news.ycombinator.com/item?id=22336638
    • Başlığı görünce aşağı yukarı böyle bir şey beklemiştim. Asıl gönderinin kullanışlı, genel amaçlı bir araç değil de ücretli bulut hizmeti olması hayal kırıklığı yarattı; yine asıl içerik yorumlardaymış
      Video encoding dışında GPU-over-network'ün kullanılabileceği yerler var mı, onu da merak ediyorum. Gecikme arttığında makine öğrenmesi ya da grafik yoğun işler zor olmaz mı diye düşünüyorum
    • İlginç. HLS gibi birden fazla zaman dilimi dosyası üreten çok dosyalı dönüştürmeleri de destekleyip desteklemediğini merak ediyorum
  • Bu CPU/GPU sınırında çalışıyorsa, VRAM'e sığmayan veri setlerinde muazzam bir girdi/çıktı darboğazı oluşmuyor mu, kafam karıştı
    Çalışma şeklini yanlış anlamış olabilirim ama GPU girdi/çıktısını araya girip yakalıyorsa, her epoch'ta tüm veri setini uzak makineye stream etmek gerekiyor demektir; bu da israf gibi geliyor

    • Sistemi doğru anlamışsın. Pratik hale getirmek için girdi/çıktı maliyetini azaltan çeşitli optimizasyonlar uyguladık
      BERT inference performansını burada görebilirsin: https://youtu.be/qsOBFQZtsFM?t=69
      Eğitimde overhead, inference'a göre daha büyük; native performansa yaklaşmak için ek optimizasyonlar uyguluyoruz
  • Gerçekte nasıl çalıştığını merak edenler için, süreç içine bir kütüphane enjekte edip bu fonksiyonları[1] hook'ladıktan sonra servise ileten bir yapı gibi görünüyor
    [1] https://pastebin.com/raw/kCYmXr5A

    • Bu fonksiyonların hook'landığını nasıl anladığını merak ediyorum. Hangi sembollerin yeniden bağlandığını söyleyen bir ld/ldd flag'i olduğunu tahmin ediyorum
      Ayrıca sembolün yeniden bağlanabilmesi için weak symbol olması gerektiğini sanıyordum; NVIDIA'nın weak symbol expose etmesi pek mümkün olmadığına göre bu sonuçta fiilen LD_PRELOAD yöntemi mi oluyor diye düşünüyorum
    • PCIe aygıtının tamamını passthrough eden sihirli bir yöntem olmasını ummuştum
  • İlginç ama benim daha çok ilgimi çeken self-hosting. Zaten çok sayıda GPU'm var; bazıları çalışıyor, bazıları boşta
    Elimdeki GPU'ları kullanabilmek için bir self-hosting seçeneği olup olmadığını merak ediyorum

    • Henüz self-hosting desteklemiyoruz ama aynı teknolojinin buna iyi uyacağını düşünüyoruz
      Verimli iş zamanlama, GPU paylaşımı ve kullanım kolaylığı gibi avantajlar self-hosting ortamlarına da aynen uygulanır. Gelecekte bu olasılığa tamamen açığız
    • Kendi GPU'ların, ister sabit donanım ister bulut olsun, üzerinde PyTorch'a benzer bir kullanım deneyimi istiyorsan https://github.com/run-house/runhouse'a bakabilirsin
    • Kendi GPU'larını ya da bulut hesabını kullanırken yine de iyi bir geliştirici deneyimi istiyorsan SkyPilot'a bakabilirsin
    • Akash Network gibi hizmetlerle kendi GPU'nu bulutta kiraya verebilir, thundercompute.com üzerinden GPU kiralayabilirsin. Bu, neredeyse self-hosting gibi işleyen yönetici yoluna daha yakın
  • Pek anlamadım. ECS'de istediğin GPU instance'ını doğrudan ayağa kaldırabilirsin; neden ECS'de instance açıp sizin GPU'larınızı ECS'de kullanmak isteyelim bilmiyorum
    Ayrı olarak, gerçek Nitro yerine yarım yamalak Nitro kullanmak için de bir sebep göremiyorum

    • İyi bir nokta. Birkaç avantajı var
      GPU gerektiren geliştirme işlerine devam ediyorsan genelde instance'ın açık kaldığı tüm süre için ödeme yapman gerekir. Thunder ile yalnızca GPU'yu gerçekten kullandığın süre için ödeme yaparsın. Yalnızca CPU kodu çalıştırırken GPU zamanı ücreti oluşmaz. Alternatif, instance'ı elle açıp kapatmaktır; bu da zahmetli olabilir
      Ayrıca kullandığın GPU türünü ve sayısını kolayca ölçekleyebilirsin. Örneğin ucuz bir T4 instance'ında geliştirme yaparken tam bir derin öğrenme eğitim işini 8 A100 üzerinde çalıştırmak istersen, instance değiştirmeden ve ortamı yeniden kurmadan tek bir komut çalıştırıp daha güçlü GPU'larda hemen çalıştırabilirsin
    • Sistem açısından daha şeffaf görünüyor. Örneğin ince bir istemcide GPU hızlandırması gerektiren GUI uygulamaları (Matlab, SolidWorks, Blender) kullanıyorsan ECS kurmadan bunu yapabilirsin
      GPU'suz geliştirme yaparken simülasyon çalıştıracağın anda birden GPU takabiliyorsun ve AWS'den çok daha ucuz olacak gibi. Özünde Ray'in (https://www.ray.io/) çözdüğü problemi daha genel amaçlı bir şekilde çözüyor gibi görünüyor. Yarım GPU gibi daha ince taneli GPU paylaşımı da mümkün olabilir; bu yüzden oldukça heyecan verici
  • Buna çok ilgi olduğu için T4 instance'larını ücretsiz açmaya karar verdik. Deneyip düşüncelerinizi paylaşırsanız iyi olur

    • A100 ve H100 fiyatlarının nasıl olduğunu merak ediyorum
  • Harika. MIG ya da vGPU ile de çalışacak hale getirip getiremeyeceğinizi merak ediyorum

    • MIG ya da vGPU ile test etmedik ama bunlar özünde GPU'yu fiziksel olarak partition etme yöntemleri olduğu için çalışacağını düşünüyorum
      Yakın gelecekteki ana hedeflerimizden biri GPU paylaşımına izin vermek. Kullanıcıyı belleğin bir kısmıyla sınırlamadan tüm GPU belleğini kullanabilir hale getireceğimiz için MIG ya da vGPU'dan daha iyi olabilir
  • Anlamlı bir throughput ile gerçek kullanımda nasıl hissettirdiğini merak ediyorum. Hash kırma için de kullanılabilir mi?
    Ağın ötesindeki sanal GPU'yu her düşündüğümde aklıma botnet geliyor. Özellikle https://www.hpcwire.com/2012/12/06/gpu_monster_shreds_passwo... adresindeki “Gosney önce Mosix'in kurucu ortaklarından Profesör Amnon Barak'ı, ‘dünyayı dev bir botnet'e dönüştürmeye çalışmadığına’ ikna etmek zorunda kaldı” kısmını hatırlıyorum

    • İlginç bir düşünce deneyi ama pratikte sistemimizde GPU'lar dağıtık olmadığı için botnet'ten çok AWS'ye daha yakın
      Bu teknoloji, veri merkezi içinde çok esnek cluster'lar oluşturma yönünde ilginç uygulamalara sahip olabilir; biz de bu kısmı araştırıyoruz
  • glx'i geliştiren asıl SGI mühendisleri, GPU aktarımı için X11 mekanizmalarını kullanacak şekilde çok dikkatli tasarlamıştı; bu yüzden GL stream'ini ağ üzerinden gönderip kendi grafik kartımda render etmek oldukça basitti
    “Koridorun sonundaki süper bilgisayarda çalıştır, workstation'da render et” tarzı bir şeydi. Son dönemdeki driver geliştirmeleri böyle bir özeni göstermiyor; bu yüzden genelde artık mümkün değil. Gerçekte ne kadar yararlıydı bilmiyorum. Genelde iyi bir grafik kartın varsa CPU'n da iyiydi. Yine de kurcalaması eğlenceliydi; makine odasında çalışan bir programın hızlandırılmış grafik alması tuhaf biçimde çekiciydi. Bir keresinde glquake'i bu şekilde çalıştırmayı başarmıştım

  • Bunun mümkün olması başlı başına etkileyici ama ağ bağlantısı koptuğunda ya da %100 kararlı olmadığında ne olacağını merak ediyorum
    Deneyimlerime göre driver'lar, yerel GPU biraz garip davrandığında bile pek iyi tepki vermiyor