tomasz-syn-grzegorza
359afb3a59
Infrastructure configs for GMKtec K11 (Docker, vLLM, LocalAI, ComfyUI, control-plane, gpu-fan agent, Server UI with CLI/file explorer/GPU fan curve). Co-authored-by: Cursor <cursoragent@cursor.com>
2.0 KiB
Dlaczego GPU Fan NIE jest w Dockerze
Cel: Zrozumieć dlaczego instalujemy na hoście, a nie jak ComfyUI.
Czas: 3 minuty
Wymagania: Brak
Krótka odpowiedź
GPU Fan musi siedzieć na hoście obok sterownika NVIDIA. W Dockerze nie ma gotowego obrazu w tym repo i nie planujemy go dodawać.
ComfyUI / LocalAI = programy w kontenerach (obliczenia AI).
GPU Fan = „termometr + regulator wentylatorów” na poziomie sprzętu.
Analogia
| Co | Gdzie | Dlaczego |
|---|---|---|
| Aplikacja w przeglądarce | Docker OK | Nie dotyka wentylatorów bezpośrednio |
| Sterownik wentylatorów karty | Host (root) | Tylko system z uprawnieniami root może pisać do NVML |
To jak termostat w kotłowni — nie wkładasz go do pudełka z aplikacją webową w innym pokoju.
Co by się stało w Dockerze (gdyby ktoś próbował)
- Kontener musiałby być privileged i root
- I tak często dostaniesz Insufficient Permissions na kartach GeForce
- Po awaryjnym
docker killwentylatory mogłyby zostać w trybie ręcznym - Zero korzyści — i tak potrzebujesz tego samego sterownika na hoście
Dlatego w repo jest tylko:
sudo scripts/install.sh
sudo systemctl start gpu-fan
Jak to wygląda na serwerze (poprawnie)
HOST (Ubuntu)
├── gpu-fan.service ← steruje wentylatorami (port 8090)
├── sterownik NVIDIA
└── Docker
├── comfyui :8188
├── localai :8070
└── vllm :8000
Wszystko może działać równocześnie. GPU Fan nie koliduje z kontenerami AI.
„Ale inne stacki są w Dockerze!”
Tak — bo tam Docker ma sens (izolacja aplikacji, GPU do inference).
GPU Fan to daemon sprzętowy — jak nvidia-persistenced, nie jak aplikacja webowa.
Gdzie jest pełna analiza techniczna
Dla agentów / deweloperów:
../coding-agent/DOCKER-VS-HOST-REPORT.md