Klasy sprzętu¶
Zasada doboru¶
Sprzęt dobiera się do profilu zadań, prywatności, liczby równoległych użytkowników, modeli, mediów, kamer i wymaganego czasu reakcji. Większa karta GPU nie naprawi słabego storage, chłodzenia, UPS ani sieci. Każda instalacja ma capacity plan i mierniki nasycenia.
Klasy referencyjne¶
| Klasa | Profil | Typowe zasoby | Ograniczenia |
|---|---|---|---|
| N0 Management | out-of-band i recovery | energooszczędny CPU, 8–16 GB RAM, mały SSD, 2×LAN opcj., UPS | bez modeli i zwykłych jobs |
| N1 Personal Edge | concierge, chat, dokumenty | 8–16 rdzeni, 32–64 GB RAM, GPU 12–24 GB lub iGPU/NPU, 1–2 TB NVMe | pojedynczy większy model, ograniczone media |
| N2 AI Workstation | pełny Norbi jednej osoby/małego zespołu | 16+ rdzeni, 64–128 GB RAM, GPU 24–32+ GB, szybki NVMe 2–4 TB | pojedynczy host = wspólna domena awarii |
| N3 Studio | coding, 3D, DaVinci, Adobe, vision | mocny CPU, 128 GB RAM, GPU 32–48+ GB, scratch NVMe, storage projektu | energia, hałas, licencje aplikacji |
| N4 Business Node | 10–50 użytkowników, trwałe usługi | ECC preferowane, mirrored boot/data, 128–256 GB, GPU opcj., redundantna sieć | wymaga serwisu i backupu poza hostem |
| N5 Local Cluster | wiele modeli/workerów/kamer | osobny Control Plane, 2+ GPU workers, storage, 10/25 GbE | większa złożoność operacyjna |
| N6 Remote Edge | oddział, kamera, urządzenie | mały CPU/GPU, TPM, dual uplink opcj., lokalny bufor | działa w najmniejszych uprawnieniach |
Wartości są profilami, nie specyfikacją jednego producenta. Model Registry zapisuje rzeczywiste benchmarki na exact sprzęcie i konfiguracji. Wymagania wag zależą od kwantyzacji, kontekstu, KV cache, batch i równoległości; sama pojemność VRAM nie gwarantuje latency.
Karta modułu Hardware Registry¶
| Pole | Kontrakt |
|---|---|
| Odpowiedzialności | inventory, capabilities, health, firmware/driver, benchmark, lifecycle, energy i compatibility. |
| Wejścia | device identity, CPU/GPU/RAM/storage/network, telemetry, installed runtimes, attestations. |
| Wyjścia | worker profile, eligible workloads, warnings, capacity forecast, certification state. |
| Zależności | Worker Registry, Resource Scheduler, monitoring, UPS, Model/Tool Registry. |
| Uprawnienia | read telemetry; firmware/driver/power action osobno. |
| Autonomia | scheduling i throttling w zatwierdzonych progach; brak autonomicznego overclock/firmware. |
| Walidacja | burn-in, ECC/storage SMART, thermal, power-loss, model/app benchmark, sleep/wake. |
| Awaria | drain, migrate/checkpoint, isolation, replacement plan i restore. |
CPU i RAM¶
CPU obsługuje broker, parsers, embedding, kompresję, wiele adapterów i preprocessing. Liczy się liczba rdzeni, wydajność jednowątkowa, instrukcje, stabilność i platform I/O. RAM mieści modele CPU/offload, duże dokumenty, cache i aplikacje kreatywne. Business/Control Plane preferuje ECC, jeśli budżet i platforma pozwalają. Scheduler zachowuje headroom, zamiast doprowadzać host do swap thrash.
GPU¶
Rejestr zawiera VRAM, compute capability, sterownik, runtime, limit mocy, temperaturę, profile model/app i obsługę partitioning. Jedna bardzo mocna karta może obsługiwać duży model, ale dwa workery poprawiają separację oraz dostępność. GPU do kamer o niskim opóźnieniu może być oddzielone od renderu, aby długi job nie blokował alarmu.
Storage¶
Rozdziela się:
- system/boot;
- trwałą bazę Control Plane;
- Artifact Store;
- media scratch/cache;
- modele;
- backup i kopię offline.
NVMe scratch nie jest backupem. Baza wymaga stabilnego storage, monitoringu SMART, wolnego miejsca i testów power loss. Artifact Store korzysta z hashy oraz polityki quota. Duże media mogą żyć na NAS, ale metadata i małe krytyczne artefakty potrzebują odpowiedniego RPO.
Sieć i zasilanie¶
1 GbE wystarczy dla małej instalacji dokumentowej, lecz media i wspólny storage uzasadniają 10 GbE. Kamery mają osobny VLAN i obliczony bitrate/retention. Management korzysta z osobnego segmentu. UPS dobiera się do rzeczywistego poboru oraz czasu graceful shutdown; maksymalna moc GPU może wymagać rezerwy na transient.
Klasy zastosowań¶
LLM chat/coding: priorytet VRAM, RAM, szybki NVMe na modele, stabilny inference runtime.
Voice: niskie latency, osobny szybki model, audio I/O i niezależność od zatłoczonego dużego modelu.
Vision/kamery: stały decode throughput, edge sampling, storage retention i redundantny NVR.
Studio: GPU/CPU, szybki scratch, calibrated display, duże storage, kompatybilne wersje aplikacji/pluginów.
Control Plane: niezawodność, mały promień awarii, backup i UPS ważniejsze niż GPU.
Przykładowe polecenia¶
- „Oszacuj klasę sprzętu dla 20 użytkowników, dwóch dużych modeli i 16 kamer, z 30% rezerwy.”
- „Pokaż, czy wąskim gardłem jest VRAM, storage czy kolejka GPU.”
- „Przełącz worker w draining przed wymianą dysku.”
- „Zaplanuj trzyletni cykl odnowienia bez wiązania profili z konkretną kartą.”
Walidacja i scenariusz awaryjny¶
Nowy host przechodzi burn-in CPU/RAM/GPU, test storage, power-loss/reboot, model benchmarks, thermal soak, sleep/WoL/KVM i failure injection w bezpiecznym środowisku. Certyfikat wiąże exact firmware/driver/runtime.
Przy degradacji sprzętu Scheduler przestaje przydzielać nowe jobs, próbuje checkpointu i migracji. Host trafia do draining/suspended. Control Plane nie może zależeć od jedynego GPU workera. Wymiana dysku lub GPU ma runbook, backup/restore test i re-enrollment; nowy element nie dziedziczy automatycznie certyfikacji poprzedniego.