Wymagania sprzętowe dla Stable Diffusion i ComfyUI

Czego faktycznie wymaga samodzielnie hostowany generator obrazów AI

Samodzielnie hostowany generator obrazów AI składa się z jednej aplikacji internetowej oraz jednego pliku modelu. Aplikacja to ComfyUI, która działa na dowolnej maszynie z systemem Linux. To model decyduje o wymaganiach sprzętowych. Punkt kontrolny (checkpoint) klasy SDXL to pojedynczy plik o rozmiarze 6.94 GB, który preferuje umieszczenie w pamięci GPU. Ten jeden fakt determinuje cały budżet, dlatego przed wynajęciem jakichkolwiek zasobów należy zapoznać się z poniższą hierarchią sprzętową.

Uczciwe podsumowanie: VPS działający wyłącznie na CPU może zainstalować i obsługiwać to oprogramowanie, generując obrazy w rozdzielczości 512x512 przy użyciu starszego modelu Stable Diffusion 1.5 w czasie od minuty do dwóch na obraz. Ta sama maszyna generująca obraz SDXL w rozdzielczości 1024x1024 potrzebuje od dziesięciu do dwudziestu minut na jeden obraz. Nie jest to awaria konfiguracji. To kwestia arytmetyki, którą wyjaśnia ten przewodnik.

Dlaczego rozmiar modelu determinuje wybór maszyny

Generowanie obrazu opiera się na pętli odszumiania. Renderowanie 30-krokowe uruchamia odszumiacz, czyli UNet modelu SDXL, 30 razy dla danego obrazu, a każde przejście odczytuje wszystkie wagi UNet. Dwa enkodery tekstu działają raz przed pętlą, a VAE dekoduje obraz raz po jej zakończeniu, więc nie stanowią one części kosztu przypadającego na każdy krok. UNet modelu SDXL w precyzji połówkowej zajmuje 5.14 GB wag, więc w tym uproszczonym modelu renderowanie 30-krokowe przesyła przez pamięć około 154 GB wag, zanim obraz zostanie wyświetlony, a pośrednie tensory dodatkowo zwiększają to obciążenie.

GPU z 24 GB pamięci wideo (VRAM, pamięć przylutowana obok układu graficznego) odczytuje dane z prędkością setek gigabajtów na sekundę i mieści wszystkie 6.9 GB modelu jednocześnie. VPS oparty na CPU odczytuje pamięć RAM z prędkością dziesiątek gigabajtów na sekundę i nie posiada sprzętowych jednostek macierzowych do operacji splotu, więc ta sama pętla wykonuje się od jednego do dwóch rzędów wielkości wolniej. Jest to ten sam argument dotyczący przepustowości pamięci, który odnosi się do modeli tekstowych i warto go przeczytać w powiązaniu z kiedy VPS z GPU jest faktycznie opłacalny.

Generowanie obrazu różni się od generowania tekstu pod jednym istotnym względem. Model czatowy przesyła tokeny strumieniowo, więc wolna maszyna nadal wydaje się użyteczna, ponieważ słowa pojawiają się w trakcie czytania. Obraz pojawia się dopiero po zakończeniu ostatniego kroku. Wolne działanie oznacza wpatrywanie się w pasek postępu.

Drabina sprzętowa z rzeczywistymi wartościami

Poniższy blok zawiera typowe dane dla jednego obrazu SDXL w rozdzielczości 1024x1024, 30 krokach i próbkowaniu Euler, według stanu na lipiec 2026. Należy traktować je jako rząd wielkości. Zmiana próbkowania, liczby kroków lub rozdzielczości wpłynie na te wyniki.

[
  {
    "label": "8 vCPU VPS, no GPU",
    "seconds_per_image": 780
  },
  {
    "label": "8GB VRAM GPU",
    "seconds_per_image": 32
  },
  {
    "label": "12GB VRAM GPU",
    "seconds_per_image": 18
  },
  {
    "label": "24GB VRAM GPU",
    "seconds_per_image": 9
  }
]

Wiersz CPU to 780 sekund, czyli około trzynaście minut. Karta 24 GB to 9 sekund. To jest różnica, za którą płacisz.

Drabinę należy interpretować w następujący sposób. Poniżej 8 GB VRAM, SDXL nadal działa, ponieważ ComfyUI zarządza pamięcią VRAM i RAM systemową łącznie, automatycznie przenosząc wagi modelu. Według stanu na październik 2026, plik README projektu określa dolną granicę na 4 GB VRAM oraz 8 GB pamięci RAM, przy użyciu asynchronicznego strumieniowania wag. Przenoszenie danych kosztuje czas na każdym kroku, więc karta 6 GB generuje obraz w czasie bliższym minucie niż trzydziestu sekundom. Przy 8 GB model bazowy mieści się w pamięci, a renderowanie jest komfortowe. Przy 12 GB można przechowywać ControlNet lub dwa obok checkpointu bez konieczności przenoszenia danych. Przy 24 GB można uruchomić SDXL wraz z refinerem i upscalingiem w jednym workflow, a także trenować adaptery LoRA z zapasem pamięci. Trenowanie wymaga mniej: przewodnik trenowania SDXL dla narzędzia kohya-ss sd-scripts podaje, że trenowanie LoRA można wykonać przy 8 GB pamięci GPU, przy czym zalecane jest 10 GB. Aby to osiągnąć, należy trenować tylko U-Net, włączyć gradient checkpointing, buforować wyjścia enkodera tekstu i latenty, użyć 8-bitowego optymalizatora lub Adafactor oraz zmniejszyć wymiar LoRA do 4-8 na karcie 8 GB. Przewodnik LoRA dla interfejsu kohya_ss, który stanowi nakładkę na te skrypty, jest bardziej ostrożny: zaleca użycie GPU z co najmniej 12 GB pamięci do trenowania LoRA.

Możliwości i ograniczenia serwera VPS typu CPU

Serwer VPS typu CPU oferuje więcej, niż można oczekiwać, ale mniej, niż sugerują materiały marketingowe. Należy precyzyjnie określić granice jego wydajności.

Serwer VPS typu CPU pozwala na instalację ComfyUI, obsługę interfejsu WWW, przechowywanie biblioteki modeli, zarządzanie kolejką oraz generowanie obrazów bez obecności jednostki GPU. W przypadku Stable Diffusion 1.5 przy rozdzielczości 512x512 i 20 krokach, czas generowania jednego obrazu wynosi od około 60 do 150 sekund na 8 nowoczesnych vCPU z 16 GB pamięci RAM. W przypadku zadań wsadowych uruchamianych w nocy lub punktów końcowych o niskim natężeniu ruchu, jest to rozwiązanie w pełni akceptowalne.

Serwer VPS typu CPU nie nadaje się do pracy interaktywnej. Iteracja promptów wymaga wykonania dwudziestu renderów w ciągu godziny, a przy czasie trwania trzynastu minut na obraz, możliwe jest uzyskanie jedynie czterech. Nie umożliwia on również trenowania modeli. Dostrajanie LoRA na CPU mierzone jest w dniach, a nie w godzinach, dlatego należy uznać tę funkcjonalność za niedostępną.

Zasada dotycząca pamięci w środowisku wyłącznie CPU różni się od tej dla GPU. Wagi modelu ładowane są do pamięci RAM systemu, więc wymagana jest pojemność równa rozmiarowi modelu powiększona o przestrzeń roboczą: około 16 GB RAM dla SDXL oraz około 8 GB dla SD 1.5. Maszyna z 4 GB RAM uruchomi ComfyUI, ale zostanie przerwana przez mechanizm out-of-memory killer w trakcie pierwszego renderowania, co objawia się nagłym zniknięciem procesu z kodem Killed w dmesg, bez wygenerowania śladu stosu (traceback) języka Python.

Instalacja ComfyUI na maszynie z GPU

Poniżej znajdują się polecenia dla wersji upstream. Należy rozpocząć od czystej instalacji Ubuntu 24.04 z już zainstalowanym sterownikiem NVIDIA. Najpierw należy zweryfikować sterownik, ponieważ każda późniejsza awaria wygląda tak samo bez tego sprawdzenia.

nvidia-smi

Polecenie to musi wyświetlić tabelę z kartą graficzną oraz wersją CUDA. command not found lub NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver oznacza brak sterownika lub niezaładowanie modułu jądra po aktualizacji. Należy to naprawić przed kontynuowaniem, ponieważ ComfyUI po cichu przełączy się na CPU, a użytkownik błędnie uzna to za problem z oprogramowaniem.

sudo apt update
sudo apt install -y git python3-venv python3-pip wget
git clone https://github.com/comfyanonymous/ComfyUI.git
cd ComfyUI
python3 -m venv venv
. venv/bin/activate
pip install torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/cu130
pip install -r requirements.txt

Środowisko wirtualne nie jest opcjonalną poradą. PyTorch pobiera rozbudowane drzewo zależności, a instalacja go w systemie, na którym działają inne usługi, prowadzi do konfliktów. Przed przejściem dalej należy zweryfikować, czy PyTorch widzi kartę graficzną.

python -c "import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))"

True wraz z nazwą karty oznacza, że stos działa poprawnie. False oznacza, że zainstalowany pakiet wheel nie pasuje do sterownika, zazwyczaj z powodu użycia wersji torch przeznaczonej tylko dla CPU pobranej z pamięci podręcznej. Należy przeprowadzić ponowną instalację, używając powyższego adresu URL indeksu.

Pobranie modelu i planowanie przestrzeni dyskowej

ComfyUI jest dostarczane bez wag. Punkty kontrolne (checkpoints) umieszcza się w models/checkpoints, pliki VAE w models/vae, a adaptery LoRA w models/loras.

cd ~/ComfyUI/models/checkpoints
wget https://huggingface.co/stabilityai/stable-diffusion-xl-base-1.0/resolve/main/sd_xl_base_1.0.safetensors

Zawsze należy preferować .safetensors zamiast .ckpt. Plik .ckpt to obiekt Python typu pickled, a jego wczytanie powoduje wykonanie kodu dostarczonego przez autora pliku. Format safetensors zawiera wyłącznie tensory, dzięki czemu złośliwy plik nie może uruchomić żadnego kodu.

Pamięć masowa to koszt, o którym często się zapomina. Jeden punkt kontrolny SDXL base zajmuje 6.94 GB. Model refiner to kolejne 6 GB. Modele SDXL ControlNet zajmują od 320 MB w przypadku małego modelu Canny do 2.5 GB dla pełnego modelu w połowicznej precyzji. Upscalery są niewielkie: standardowy model Real-ESRGAN x4plus zajmuje 67 MB, jego wersja anime 17.9 MB, a model do wideo anime 2.5 MB. Rozmiar LoRA waha się od kilkudziesięciu megabajtów do 787 MB w przypadku adapterów Hyper-SDXL od ByteDance. Każdy użytkownik w ciągu tygodnia pobiera drugi i trzeci model bazowy. Należy zaplanować 100 GB miejsca na dysku dla działającej instalacji oraz monitorować katalog wyjściowy: pliki PNG o rozdzielczości 1024x1024 zajmują od 1 do 2 MB każdy, a niekontrolowane przetwarzanie wsadowe szybko zapełnia mały dysk. Katalogi models/ oraz output/ należy umieścić na wolumenie z możliwością rozszerzenia, a pliki JSON z przepływami pracy (workflows) zabezpieczać za pomocą szyfrowanych przyrostowych kopii zapasowych do pamięci obiektowej. Wagi można pobrać ponownie. Dostrojone przepływy pracy nie podlegają odzyskaniu.

Uruchomienie i bezpieczny dostęp

cd ~/ComfyUI
. venv/bin/activate
python main.py --listen 127.0.0.1 --port 8188

ComfyUI działa na porcie 8188. Na maszynie wyposażonej wyłącznie w procesor CPU należy dodać flagę --cpu, która wymusza użycie ścieżki CPU zamiast kończenia pracy błędem przy braku urządzenia CUDA.

Powiąż usługę z adresem 127.0.0.1, a nie 0.0.0.0. ComfyUI posiada obecnie obsługę kont, jednak żadne z nich nie zabezpiecza serwera. Logowanie w sekcji Settings, w zakładce User, służy do uwierzytelnienia w usłudze Comfy i działa w instalacjach lokalnych: dokumentacja Comfy wymienia logowanie przez e-mail, Google, GitHub oraz klucz API. Dokumentacja opisuje to konto jako sposób dostępu do węzłów partnerskich oraz subskrypcji Comfy Cloud; nie jest to mechanizm ochrony serwera hasłem. Flaga --multi-user włącza jedynie przechowywanie danych w podziale na użytkowników: według stanu na październik 2026, serwer pobiera nazwę użytkownika z nagłówka żądania comfy-user i nie weryfikuje żadnego hasła. Każdy, kto uzyska dostęp do portu, może kolejkować zadania, odczytywać wszystkie wygenerowane obrazy, a w przypadku uruchomienia z flagą --enable-manager – instalować własne węzły, co oznacza możliwość wykonania dowolnego kodu na serwerze. Należy uzyskiwać dostęp do usługi poprzez tunel SSH z komputera lokalnego.

ssh -N -L 8188:127.0.0.1:8188 you@your-server

Następnie otwórz adres http://127.0.0.1:8188 w lokalnej przeglądarce. Jeśli wymagany jest rzeczywisty dostęp dla wielu użytkowników, należy umieścić przed usługą reverse proxy z uwierzytelnianiem, utrzymując aplikację powiązaną z localhost. To samo rozumowanie dotyczy każdej nieuwierzytelnionej usługi hostowanej samodzielnie i stanowi standardowy wzorzec w wdrożeniach Docker Compose na VPS.

Utrzymywanie procesu pod kontrolą systemd

Kolejka renderowania, która kończy działanie po zamknięciu sesji SSH, nie jest usługą. Należy uruchamiać ją jako użytkownik comfy bez możliwości logowania, a nie jako własne konto: niestandardowe węzły to kod, który nie powinien mieć dostępu do katalogu domowego użytkownika. Należy utworzyć użytkownika i przenieść instalację do jego katalogu domowego:

sudo useradd --system --create-home --home-dir /home/comfy --shell /usr/sbin/nologin comfy
sudo mv ~/ComfyUI /home/comfy/
sudo chown -R comfy:comfy /home/comfy/ComfyUI

Środowisko wirtualne działa poprawnie po przeniesieniu, ponieważ jednostka wywołuje bezpośrednio python. Następnie należy utworzyć /etc/systemd/system/comfyui.service.

[Unit]
Description=ComfyUI
After=network-online.target

[Service]
User=comfy
WorkingDirectory=/home/comfy/ComfyUI
ExecStart=/home/comfy/ComfyUI/venv/bin/python main.py --listen 127.0.0.1 --port 8188
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now comfyui
systemctl status comfyui

active (running) oraz wpis w dzienniku o treści To see the GUI go to: http://127.0.0.1:8188 oznaczają, że usługa działa. Należy zwrócić uwagę, że ExecStart wskazuje bezpośrednio na interpreter wewnątrz środowiska wirtualnego, ponieważ systemd nie ładuje profilu powłoki i activate nigdy nie następuje.

Pragmatyczne zalecenia budżetowe

Jeśli celem jest przetestowanie generowania obrazów, a koszt jest ważniejszy od szybkości, należy wybrać VPS z procesorem CPU i 16 GB pamięci RAM. Uruchomienie SD 1.5 w rozdzielczości 512x512 zajmie od minuty do dwóch na obraz. Jest to uczciwy punkt wyjścia, kosztujący ułamek ceny instancji z procesorem GPU. Jest to również odpowiednie miejsce do przechowywania biblioteki modeli oraz przepływów pracy na etapie podejmowania decyzji.

W przypadku codziennej iteracji promptów, należy wynajmować na godziny GPU z co najmniej 12 GB pamięci VRAM w chmurze obliczeniowej i wyłączać instancję po zakończeniu pracy. Generowanie obrazów ma charakter skokowy, a bezczynne GPU rozliczane miesięcznie to najczęstsza przyczyna niepotrzebnych wydatków. Punkty kontrolne (checkpoints) należy przechowywać na tanich zasobach blokowych i montować je w razie potrzeby.

Jeśli usługa jest udostępniana innym użytkownikom lub regularnie trenowane są adaptery LoRA, należy zaplanować posiadanie maszyny z 24 GB pamięci VRAM. Przewodnik sd-scripts SDXL podaje, że trenowanie LoRA można wykonać przy użyciu 8 GB pamięci, przy czym zalecane jest 10 GB z wykorzystaniem ustawień oszczędzania pamięci, a przewodnik LoRA dla interfejsu kohya_ss wymaga co najmniej 12 GB. Wartość 24 GB w przewodniku sd-scripts odnosi się do pełnego dostrajania SDXL przy rozmiarze partii 1, więc karta 24 GB pozwala na pracę z LoRA i pozostawia margines na dostrajanie. Na tym etapie maszyna zazwyczaj zwraca się, obsługując również lokalny model językowy, co opisano w samodzielne hostowanie LLM za pomocą Ollama.

Niezależnie od wybranego poziomu, przed poleganiem na opublikowanych danych należy przeprowadzić pomiary na własnej maszynie. Należy wykonać ten sam prompt pięć razy i odczytać czas w sekundach na iterację, który ComfyUI wyświetla w konsoli. Ta wartość określa rzeczywiste miejsce w hierarchii wydajności.

FAQ

Czy można uruchomić Stable Diffusion bez GPU?

Tak. ComfyUI działa z python main.py --cpu i generuje obrazy bez obecności karty graficznej. Na 8 nowoczesnych vCPU należy spodziewać się czasu rzędu 60 do 150 sekund na obraz dla Stable Diffusion 1.5 w rozdzielczości 512x512 oraz od dziesięciu do dwudziestu minut dla SDXL w 1024x1024. Jest to rozwiązanie akceptowalne dla zadań wsadowych uruchamianych w nocy oraz punktów końcowych o niskim natężeniu ruchu. Nie sprawdza się ono w iteracyjnym tworzeniu promptów, a trenowanie modeli jest całkowicie nieosiągalne.

Ile pamięci VRAM potrzeba dla SDXL?

8 GB pozwala na komfortowe uruchomienie SDXL w rozdzielczości 1024x1024. Poniżej tej wartości ComfyUI automatycznie przenosi wagi modelu do pamięci RAM systemu i nadal działa. Według stanu na październik 2026, dokumentacja README wskazuje na minimum 4 GB VRAM oraz 8 GB pamięci RAM systemu, przy czym każdy przeniesiony krok wydłuża czas przetwarzania. 12 GB pozwala na utrzymanie modelu ControlNet wraz z checkpointem, a 24 GB wystarcza na obsługę modelu bazowego, refinera oraz upscalingu w jednym workflow. Przewodnik kohya-ss sd-scripts podaje, że trenowanie SDXL LoRA jest możliwe przy 8 GB (zalecane 10 GB) przy użyciu ustawień oszczędzających pamięć, podczas gdy przewodnik GUI kohya_ss dla LoRA wymaga co najmniej 12 GB. Pełny fine-tuning SDXL wymaga 24 GB przy rozmiarze batcha 1.

Ile miejsca na dysku potrzebują modele?

Sam checkpoint bazowy SDXL zajmuje 6.94 GB, a refiner dodaje około 6 GB. Modele SDXL ControlNet zajmują od 320 MB do 2.5 GB każdy w półprecyzji, adaptery LoRA od kilkudziesięciu megabajtów do 787 MB, a upscalery Real-ESRGAN od 2.5 MB do 67 MB. Należy zaplanować 100 GB na działającą instalację z kilkoma modelami bazowymi i monitorować katalog wyjściowy osobno, ponieważ pliki PNG w rozdzielczości 1024x1024 zajmują od 1 do 2 MB każdy.

Czy wystawienie ComfyUI na publiczny internet jest bezpieczne?

Nie. Logowanie do konta Comfy w ustawieniach ComfyUI działa w lokalnej instalacji, ale zapewnia dostęp do węzłów partnerskich i subskrypcji chmurowych Comfy; dokumentacja Comfy nie traktuje tego jako zabezpieczenia serwera. Flaga --multi-user jedynie rozdziela pamięć masową dla poszczególnych użytkowników bez weryfikacji hasła. Przy włączonym ComfyUI-Manager interfejs instaluje niestandardowe węzły, które są kodem Python wykonywanym na serwerze, więc otwarty port oznacza możliwość zdalnego wykonania kodu. Należy powiązać usługę z 127.0.0.1, uzyskiwać do niej dostęp przez tunel SSH z ssh -N -L 8188:127.0.0.1:8188 you@your-server i umieścić przed nią uwierzytelniający reverse proxy, jeśli dostęp ma mieć więcej niż jedna osoba.

Dlaczego renderowanie zostało przerwane bez komunikatu o błędzie?

Zniknięcie procesu z Killed w dmesg bez śladu stosu (traceback) Python oznacza działanie mechanizmu OOM (out-of-memory) systemu Linux, a nie błąd ComfyUI. Na maszynie działającej wyłącznie na CPU wagi modelu znajdują się w pamięci RAM systemu, więc SDXL wymaga około 16 GB, a SD 1.5 około 8 GB, plus przestrzeń robocza. Należy zwiększyć ilość pamięci RAM, dodać swap lub przejść na mniejszy model i niższą rozdzielczość.