Katalog węzłów N0–N16¶
Węzeł jest jednostką odpowiedzialności, a nie wyłącznie komputerem. Identyfikator określa rolę, limity, sieć, sposób utrzymania i recovery. Konkretny SKU może zostać zastąpiony dopiero po ponownej walidacji kompatybilności, poboru energii i ceny.
Macierz klas¶
| ID | Nazwa | Główna rola | GPU / pamięć | Normalny pobór | Typowe użycie |
|---|---|---|---|---|---|
| N0 | Sentinel Nano | heartbeat, MQTT, alarmy, WOL | brak | 14 W | każdy obiekt |
| N1 | Sentinel Plus | VPN, metryki, DNS, management | brak/iGPU | 25 W | kilka stref lub mała firma |
| N2 | Edge Vision Sensor | detekcja blisko kamery | Jetson/Pi 8GB | 22 W | pojedyncza strefa |
| N3 | Automation Node | Control Center, PWA, ERP/CRM, kolejki | iGPU | 25 W | dom, biuro, oddział |
| N4 | Utility Worker 8GB | OCR, ASR, 3B–7B, małe Vision | RTX 5060 8GB | 260 W | najtańszy GPU worker |
| N5 | AI Worker 12GB | 7B, coding, transkrypcja, dokumenty | RTX 5070 12GB | 350 W | worker uniwersalny |
| N6 | Light AI Worker 16GB | Voice, OCR, 7B–14B, Vision | RTX 5060 Ti 16GB | 300 W | rekomendowany start local AI |
| N7 | Creative Worker | Blender, Adobe, DaVinci, ComfyUI | RTX 5070 Ti/5080 | 470 W | studio kreatywne |
| N8 | Professional Worker 24GB | ECC, 24/7, CAD, Vision | RTX PRO 4000/L4 | 300 W | profesjonalny edge/worker |
| N9 | Main Worker 32GB | orchestrator, reasoning, 30–35B | RTX 5090/PRO 4500 | 650 W | główny worker |
| N10 | Datacenter Worker 48GB | większy model, wielu użytkowników | RTX 6000 Ada/L40S | 650 W | serwer lokalny |
| N11 | Large Context Worker 72GB | większe modele i kontekst | RTX PRO 5000 | 480 W | profesjonalne AI |
| N12 | Enterprise Worker 96GB | duże modele, ECC, wysokie SLA | RTX PRO 6000 | 780 W | enterprise |
| N13 | Voice Node | ASR/TTS, telefonia, analiza rozmów | CPU/8/16GB | 220 W wariant GPU | recepcja/contact center |
| N14 | Vision Node | wiele kamer, tryb ciągły/zdarzeniowy | 8/16/24/32GB | 300 W wariant bazowy | monitoring i magazyn |
| N15 | Storage Node | NAS/ZFS, backup, cache, artefakty | brak | 100 W | 4TB–100TB+ |
| N16 | Management & Recovery Node | KVM, ATX, UPS, VPN, recovery | brak | 55 W | out-of-band |
Kontrakt wspólny¶
Cel: wykonać jedną jasno opisaną rolę. Wejście: podpisany job lub zdarzenie, capability, limity czasu, energii i danych. Wyjście: artefakt lub zdarzenie wraz z receipt, metrykami i wersją środowiska. Zależności: Control Plane, rejestry modeli/narzędzi, Artifact Store, Audit Event Store i N16. Uprawnienia: najwęższe potrzebne capability; żaden węzeł nie może nadać sobie nowej roli ani zwiększyć autonomii.
Przebieg: enrollment → attestation → przyjęcie lease → wykonanie → niezależna walidacja → receipt → zwolnienie zasobów. Walidacja: test funkcjonalny, termiczny, energetyczny, utraty WAN i recovery. Błąd: retry tylko w limicie; następnie kwarantanna albo przejście na zatwierdzony wariant zastępczy. Fallback: mniejszy model, kolejka, drugi worker, CPU albo procedura ręczna — bez potajemnego egressu do chmury.
stateDiagram-v2
[*] --> Provisioned
Provisioned --> Ready: enrollment + attestation
Ready --> Leased: signed job
Leased --> Validating: candidate + evidence
Validating --> Ready: PASS + receipt
Validating --> Quarantine: policy/integrity FAIL
Ready --> Draining: maintenance/energy
Draining --> Offline: safe shutdown
Offline --> Recovering: WOL/ATX/KVM
Recovering --> Ready: re-attestation
Recovering --> Quarantine: mismatch
Dobór bez mylenia pojemności z szybkością¶
Najpierw wybiera się minimalny VRAM, sterownik i wymagania integralności, potem throughput, a dopiero na końcu model handlowy. Szybsza karta 12GB nie uruchomi zadania wymagającego 16GB. VRAM kilku komputerów nie staje się automatycznie jedną wspólną pamięcią; równoległe węzły zwiększają przepustowość systemu, ale niekoniecznie szybkość pojedynczego modelu.