stable-diffusion.cpp - C/C++ ile uygulanmış Diffusion model çıkarımı
(github.com/leejet)- 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,.ggufdesteklenir; dönüştürme modu model ağırlıklarını.ggufveya.safetensorsbiç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 cudave--rng cpuolarak ayrılır; bunlar sırasıylastable-diffusion-webuiGPU 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
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
Örneğin derleme sırasında
GGML_CUBLASdestekleniyor ve saf C/C++’a kıyasla oldukça iyi bir hız artışı sağlıyorBiraz zaman alsa da eski bir dizüstünde çalıştırılabiliyor
torch.compileile de oldukça iyi bir hız artışı görmüştüm ve üzerinde bizzat çalıştığımı hatırlıyorumRakamları 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ı
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=ONile ç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ış
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
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?
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
Ö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ı
İç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 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
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?
Bugün bu depoyu gördüm, indirip Mac’te
.dylibderledim ve Dart’ın ffi-gen aracıyla sağlanan header dosyasından binding’ler oluşturdumFlutter 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ı?
https://github.com/leejet/stable-diffusion.cpp/issues/1
cmake .. -DGGML_CUBLAS=ON -DCMAKE_CUDA_COMPILER=/opt/cuda/bin/nvcckomutuyla derleyip NVIDIA GeForce RTX 2060 SUPER kullandımModeli 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