Przejdź do głównej zawartości

Wymagania sprzętowe

Zwykły interfejs Chat w Libre WebUI jest lekki. Większość zasobów zużywają lokalne modele Ollama; kontenerowe zadania Work dodają osobny budżet CPU, pamięci, procesów, obrazów i przestrzeni projektowej.

Szybka ściąga

SprzętPraktyczne modele lokalneUwagi
8 GB RAM, tylko CPUKwantyzowane 1B-4BDobre do testów i lekkiego czatu
16 GB RAM, tylko CPUKwantyzowane 4B-8BUżyteczne, wolniejsze niż GPU
8 GB VRAMKwantyzowane 4B-8BDobra codzienna konfiguracja lokalna
12-16 GB VRAMKwantyzowane 8B-14BMocny zakres stacji roboczej
24 GB VRAMKwantyzowane 14B-32BZaawansowane zastosowania lokalne
48 GB+ VRAM lub dużo pamięci zunifikowanejKwantyzowane 32B-70BEksperymenty z dużymi modelami

Rzeczywista szybkość zależy od architektury modelu, kwantyzacji, długości kontekstu, sterowników GPU i innych uruchomionych procesów.

Dobre modele na początek

ollama pull gemma4:12b
ollama pull qwen3.8:27b
ollama pull gemma4:26b
ollama pull nomic-embed-text

Używaj nomic-embed-text do embeddingów dokumentów, a nie jako modelu czatu.

VRAM a RAM

VRAM jest najważniejszym czynnikiem szybkości modeli lokalnych. Jeśli model mieści się w VRAM, odpowiedzi są znacznie szybsze. Jeśli część trafia do pamięci systemowej, model może nadal działać, ale wolniej.

Pamięć systemowa jest ważna dla wnioskowania na CPU, przenoszenia obliczeń z GPU, długich okien kontekstu i działania pozostałej części aplikacji.

Apple Silicon

Apple Silicon używa pamięci zunifikowanej, więc pamięć modelu pochodzi z tej samej puli co system operacyjny i aplikacje. Komputery z większą pamięcią zunifikowaną mogą uruchamiać większe modele kwantyzowane, niż sugerowałaby ich wartość VRAM na systemie z oddzielnym GPU.

Pozostaw wystarczająco dużo wolnej pamięci dla przeglądarki, backendu i systemu operacyjnego.

NVIDIA

GPU NVIDIA zapewniają zwykle najlepszą zgodność lokalnego wnioskowania przez CUDA. Używaj aktualnych sterowników i potwierdź dostęp Dockera do GPU, jeśli Ollama działa w kontenerach.

AMD i Intel

Obsługa AMD i Intel zależy od wsparcia Ollama i sterowników dla danej platformy. Gdy akceleracja GPU jest niedostępna, nadal można używać CPU.

Zmniejszanie użycia pamięci

  • Używaj mniejszych modeli.
  • Używaj kwantyzacji Q4 zamiast Q8.
  • Zmniejsz długość kontekstu.
  • Wyładuj nieużywane modele.
  • Oddziel wybór modelu embeddingowego dokumentów od modelu czatu.

Pojemność środowiska Work

Work zużywa zasoby kontenerowe oprócz WebUI i procesu modelu. Każdy aktywny kontener zadania domyślnie ma:

  • 2 GB pamięci;
  • 2 CPU; oraz
  • 256 procesów.

Backend domyślnie pozwala na dwa aktywne zadania kontenerowe w całej instancji i jedno na administratora. Są to limity, nie rezerwacje, ale operator powinien jednocześnie uwzględnić zasoby backendu WebUI, przeglądarki, Dockera, Ollama i kontenera zadania. Na Apple Silicon wszystkie ostatecznie konkurują o tę samą pulę pamięci zunifikowanej.

Użycie Ollama Cloud lub skonfigurowanej wtyczki modelu zdalnego pozwala uniknąć ładowania dużego modelu do lokalnej pamięci RAM lub VRAM. Nie usuwa jednak wymogu Dockera ani zasobów potrzebnych kontenerowi Work.

Każde zadanie Work ma też nazwany wolumin Docker na wygenerowane pliki i lokalne zależności. Woluminy nie mają obecnie limitów dysku na zadanie, dlatego instalowanie pakietów lub generowanie projektów może wyczerpać pamięć masową Dockera. Monitoruj katalog danych Docker, ustawiaj limity hosta tam, gdzie są dostępne, i twórz kopie woluminów zadań oddzielnie od bazy Libre WebUI.

Ustawienia WORK_MEMORY_LIMIT, WORK_CPU_LIMIT, WORK_PIDS_LIMIT i WORK_MAX_ACTIVE_RUNTIMES_* dostrajaj dopiero po pomiarze hosta backendu. Wartości domyślne znajdziesz w dokumentacji zmiennych środowiskowych.

Powiązana dokumentacja