3 puan yazan GN⁺ 2023-08-21 | 1 yorum | WhatsApp'ta paylaş
  • SD, Flux, Wan ailesi dahil Diffusion model çıkarımını saf C/C++ ile çalıştıran bir araçtır ve dış bağımlılığı olmayan hafif bir uygulamayı hedefler
  • Uygulama ggml tabanlıdır ve llama.cpp ile benzer şekilde çalışan bir Plain C/C++ yapısına sahiptir
  • Desteklenen model kapsamı görüntü modelleri, görüntü düzenleme modelleri ve video modelleri olarak ayrılır; SD1.x, SD2.x, SDXL, SD3/SD3.5, FLUX, Qwen Image, Wan2.1/Wan2.2, LTX-2.3 ve benzerlerini hedefler
  • Özellik kapsamı PhotoMaker, SD 1.5 için Control Net, stable-diffusion-webui tarzı LoRA, LCM/LCM-LoRA, TAESD tabanlı latent decoding, ESRGAN upscaling, negative prompt ve token ağırlığı tokenizer desteğini içerir
  • Çalıştırma backend'leri CPU, CUDA, Vulkan, Metal, OpenCL ve SYCL'dir; CPU tarafında x86 mimarisinin AVX, AVX2 ve AVX512 desteği de bulunur
  • Desteklenen platformlar Linux, Mac OS, Windows ve Android'dir; Android'de Termux ve Local Diffusion üzerinden çalıştırılır
  • Ağırlık biçimleri olarak .ckpt, .pth, .pt, .safetensors, .gguf desteklenir; dönüştürme modu model ağırlıklarını .gguf veya .safetensors biçimine dönüştürür
  • Temel kullanım akışı, releases page üzerinden önceden derlenmiş binary'leri indirmek veya kaynaktan derlemek, ardından model ağırlıklarını indirip ./bin/sd-cli -m ../models/v1-5-pruned-emaonly.safetensors -p "a lovely cat" biçiminde görüntü üretimini çalıştırmaktır
  • Bellek kullanımı optimizasyonu için Flash Attention ve VAE tiling processing sunulur; runtime ve parametrelerin backend'e göre ayarlanması ile performans iyileştirmeleri ayrı kılavuzların konusudur
  • Yeniden üretilebilirlik seçenekleri --rng cuda ve --rng cpu olarak ayrılır; bunlar sırasıyla stable-diffusion-webui GPU RNG ve ComfyUI RNG ile tutarlılığı hedefler
  • PNG çıktısına üretim parametreleri, webui uyumlu metin dizgesi olarak gömülür
  • Golang, C#, Python, Rust ve Flutter/Dart için wrapper projeleri vardır; Jellybox, Local Diffusion, LocalAI, KoboldCpp gibi projeler stable-diffusion.cppyi görüntü üretim backend'i olarak kullanır
  • Proje aktif olarak geliştirilmektedir ve API ile komut satırı seçenekleri sık sık değişebilir

1 yorum

 
GN⁺ 2023-08-21
Hacker News yorumları
  • Llama.cpp/ggml, LLM’lere özellikle iyi uyuyor
    Bellek gereksinimi yüksek, kuantizasyon etkili, token üretimi şaşırtıcı derecede seri ve bellek bant genişliğine bağlı olduğu için CPU’ya iyi uyuyor; ggml’in kendine özgü CPU/GPU ardışık düzen çıkarımına ise daha da iyi uyuyor
    Ancak Stable Diffusion farklı. Kuantizasyon onda aynı ölçüde iyi çalışmıyor, UNet’in hesaplama yükü çok yüksek ve toplu görüntü üretimi tek kullanıcı için bile etkili ve kullanışlı. Bu yüzden GPU/entegre GPU’ya daha iyi uyuyor ve Python uygulamasının hacklenebilirliğinden büyük fayda görüyor
    Stable Diffusion için doğru yönün, makine öğrenimi derlemesiyle çalıştırılabilir dosyalar üretmek olduğunu düşünüyorum. AITemplate zaten çok hızlı: https://github.com/VoltaML/voltaML-fast-stable-diffusion; TVM Vulkan da birisi demo uygulamayı düzgünce tamamlarsa çok umut verici: https://github.com/mlc-ai/web-stable-diffusion
    Üstelik saf PyTorch uygulamasının hacklenebilirliği de büyük ölçüde korunuyor

    • Yukarıdaki proje de doğru GGML derleme bayrakları geçirilirse GPU’yu bir ölçüde destekliyor
      Örneğin derleme sırasında GGML_CUBLAS destekleniyor ve saf C/C++’a kıyasla oldukça iyi bir hız artışı sağlıyor
    • Buna karşılık, 6 GB veya daha fazla VRAM’e sahip bir NVIDIA GPU’su olmayan ama bu sinir ağlarıyla yerelde oynamak isteyenler için iyi
      Biraz zaman alsa da eski bir dizüstünde çalıştırılabiliyor
    • Yanlış hatırlamıyorsam torch.compile ile de oldukça iyi bir hız artışı görmüştüm ve üzerinde bizzat çalıştığımı hatırlıyorum
      Rakamları bulup bulamayacağıma bakacağım
  • CLIP’i bile uygulamış olmaları harika
    Sadece onu ayrı çıkarıp bir WebAssembly uygulaması olarak derlemek bile güzel olurdu
    Düzenleme: Görünüşe göre biri zaten https://github.com/monatis/clip.cpp yapmış. Şimdi WebAssembly’ye taşımak kaldı

    • CLIP konusu açılmışken, OpenAI ve Google rekabet moduna geçince bir sonraki CLIP düzeyindeki modelin yayımlanmayacak olmasından hep endişe ediyorum
      Bir yerlerde gizli bir kasanın içinde zaten daha gelişmiş bir CLIP düzeyinde model olabileceğini düşünmek üzücü
      Düzenleme: CLIP-2’den değil, CLIP kadar önemli düzeyde bir ilerlemeden bahsediyorum
  • Kurulumu inanılmaz derecede kolay olduğu için ilk kez hemen denedim
    Normalde ne kadar hız beklemek gerektiğini merak ediyorum
    Linux’ta AMD Ryzen 7 5700G üzerinde cmake .. -DGGML_OPENBLAS=ON ile çalıştırdım; harici GPU yok, yalnızca entegre grafik var
    ./bin/sd -m ../models/sd-v1-4-ggml-model-f32.bin -p "a lovely cat" çalıştırıldığında her örnekleme adımı yaklaşık 12 saniye sürdü, toplam örnekleme ise 246,40 saniye sürdü
    Beklenen performans bu mu merak ediyorum
    Düzenleme: OpenBLAS kurulu olmadığı için bu bayrağın etkisi olmamış

    • Bu iyi. Temelde 1 yıl önce istediğim şeyi[0] yapıyor
      O zamanlar neredeyse tüm çözümler Python bağımlılık yığınları istiyordu; kurulum çok uzun sürüyor ve sonunda disk alanı yetmediği için başarısız oluyordu
      Gerçekten, kelimenin tam anlamıyla birkaç gigabaytlık disk alanını tek bir 799 KB ikili dosyayla değiştiriyor. Üstelik en hızlısı gibi görünen Q8_0 formatı kullanılırsa veriden de yaklaşık 2,3 GB tasarruf ediliyor
      Ancak varsayılan 512x512 görüntü boyutu dışında hatalı görünüyor. 544x544 gibi bazı boyutlar assert hatasına yol açma eğiliminde; 512x512’den küçük boyutlar bazen çöp görüntüler üretiyor, 384x384’ten küçük boyutlarda ise neredeyse her zaman böyle oluyor
      [0] https://news.ycombinator.com/item?id=32555608
    • Modeli kuantize etmek gerekiyor, ama iterasyon başına yaklaşık 12 saniye doğru görünüyor
    • Yalnızca CPU, 8 bit kuantizasyon, Intel Core i7 4770S, 16 GB DDR3 RAM ve 10 yıllık fansız bir PC’de örnekleme adımı başına 32 saniye sürdü; çıktı normal
  • Yapay zeka ile ilgili C/C++ uygulamalarında özel bir çekicilik var
    Kod temiz ve sezgisel hissettiriyor; tüm yapay zeka alanını kavranabilir ve öğrenilebilir gibi gösteriyor
    Acaba Python ekosistemi fazla dağınık olduğu için mi?

    • Yeniden yazımlar genelde kod kalitesini artırır; bağımlılıkları yalnızca gereken işi yapan özel kodla değiştirmek de kod kalitesini artırır
      Python sürümü de hız için C ve C++ kodu kullanıyor, ama burada her şey tek bir dilde
      Temiz kodu mümkün kılan üç unsur birlikte işlemiş gibi
  • Makine öğrenmesi tarafındaki insanların Python’dan uzaklaşıp donanımı en iyi şekilde kullanan ve derleyip çalıştırmak için özel bir ortam ayarlamayı gerektirmeyen diller kullandığını görmek güzel

    • Oldukça tuhaf bir karşılaştırma
      Öncelikle kaynak gönderideki proje, llama.cpp gibi GPU kullanmıyor; oysa Python’daki makine öğrenmesi kodlarının çoğu GPU kullanır. GPU’yu en iyi şekilde kullanan Python kodu yazmak zor değil. GPU’ya derleme ve çalıştırma için özel bir ortam denebilir belki, ama bu problem için GPU’nun çok daha uygun olduğu söylenebilir
      İkincisi, kaynak gönderideki proje de llama.cpp gibi Stable Diffusion/LLaMA tarzı belirli modellerin iyi çalıştığı doğrulandıktan sonra verimli ve son derece özelleşmiş kod yazılmasıyla ortaya çıkmış. Buna karşılık Python’ın parladığı yer, uygun modelin henüz bulunmadığı prototipleme aşaması. C++’ta bu kadar kolay ve rahat prototiplemeyi henüz görmedim
      CPU üzerindeki makine öğrenmesi alanında llama.cpp tarafındaki insanların yaptığı harika işleri küçümsemeye çalışmıyorum. Sadece çözdükleri problem tamamen farklı
    • Tüm makine öğrenmesi modellerinde basit bir C çıkarım API’si olsa da bağımlılık ve ortam yapılandırma karmaşası olmadan neredeyse her dil ve platformdan doğrudan çağırabilsek çok daha iyi olurdu
    • Makine öğrenmesi yığınında performans açısından kritik bileşenler zaten gerçekten Python ile uygulanmış değil
      İçerisi eskiden beri tamamen CUDA, C ve C++ idi
      Python, tüm bunları bir arada tutan çok etkili bir yapıştırıcıdan ibaret
    • Bu işi yapan insanlara gerçekten minnettarım
      Bu modelleri baş ağrıtmadan çalıştırabildiğim tek yöntem bu. Fark muazzam. CUDA ve Linux kombinasyonu da iyi değil; AMD ve Windows kombinasyonu ise berbat. Muhtemelen böyle düşünen tek kişi ben değilim
    • CPU’mun bunlardan bazılarını kuantize biçimde GPU’ya neredeyse benzer hızda çalıştırabilmesi ilginç
      Sonuçta mesele tamamen bellek bant genişliği miydi?
      GPU mimarisi yalnızca hesaplama gücü değil, çalışma belleğini hesaplama birimlerine yakın konumlandıran bir yapı da sunuyor. Her birimin, global bellekle senkronize olan yerel belleği var. GPU’ların bu tür işlerde güçlü olmasının büyük nedenlerinden biri bu mu?
  • C++ gibi görünüyor; neden C/C++ diye ifade etmişler?

    • Anladığım kadarıyla temel bağımlılık olan ggml C ile yazılmış
  • Bugün bu depoyu gördüm, indirip Mac’te .dylib derledim ve Dart’ın ffi-gen aracıyla sağlanan header dosyasından binding’ler oluşturdum
    Flutter ile deniyorum ve alt süreç başlatmamak için FFI kullanıyorum
    Sonuç olarak elimde şiddetli bir baş ağrısı ve bozulmuş bir uygulama kaldı. Yarın kafam daha berrakken tekrar deneyeceğim
    Yine de bu deponun kendisi harika; M1’de f16 ile 10 dakikadan kısa sürede çalıştırabildim

  • Farklı kuantizasyon seviyeleri örneklerini görmek oldukça etkileyici
    f16’dan q8_0’a geçiş, kalite kaybından çok yönelim değişikliği gibi görünüyor. q5_1 sonucu q8_0’dan ayırt etmek zor görünüyor
    Yüksek hassasiyetli modelde belirlenimcilik kayboluyor, ama pratikte oldukça kullanılabilir olma ihtimali var

  • Benchmark var mı?

    • Burada birkaç kişi süre ölçmüş; kuantizasyona ve donanıma bağlı olarak iterasyon başına 15-20 saniye civarında sürüyor gibi
      https://github.com/leejet/stable-diffusion.cpp/issues/1
    • cmake .. -DGGML_CUBLAS=ON -DCMAKE_CUDA_COMPILER=/opt/cuda/bin/nvcc komutuyla derleyip NVIDIA GeForce RTX 2060 SUPER kullandım
      Modeli FP16’ya dönüştürdüm
      Bu seçimde iterasyon başına süre 8,5-9 saniye arasında; tek bir görüntü oluşturmanın toplam süresi yaklaşık 200 saniye