dns Infrastruktur

Womit der NetiChecker Controller rechnet und unter welcher Adresse diese Oberfläche ihn erreicht.

Verbindungen

hub Modell-Provider

Jedes Backend, bei dem der Controller ein Modell fragen kann: in erster Linie Standard-Provider, auf Wunsch zusätzlich externe Provider. Eigene Modelle auf dem Alex-Cluster sind optional; ihr Bereich ganz unten in dieser Kachel ist eingeklappt und spricht erst beim Aufklappen mit Alex.

cloud Standard-Provider Standard

Das Standard-Backend: ein OpenAI-kompatibles LLM-Gateway, das der Controller per HTTPS anspricht, ohne eigenen Job auf dem Cluster. Name, Adresse und voreingestelltes Modell kommen aus den Einstellungen des Controllers (NHR_LLM_LABEL, NHR_LLM_BASE_URL und NHR_LLM_DEFAULT_MODEL in seiner .env), der Schlüssel als systemd-Credential oder als NHR_LLM_API_KEY. Das voreingestellte Modell ist nur eine Vorauswahl für neue Bausteine und den Playground: jeder Baustein nennt sein Modell selbst.

lädt…
API-Schlüssel
–
Schlüsselquelle
–
Latenz
–
Voreingestelltes Modell
–
Parallelität
–
Endpunkt
–

Modelle nach Rolle

Modelle werden geladen…

science Nur für Forschung & Entwicklung.

cloud_sync Externe Modell-Provider

OpenAI, Anthropic oder einen beliebigen OpenAI-kompatiblen Endpunkt (z. B. einen eigenen vLLM-Server) neben Standard-Provider als weiteres Backend nutzen, etwa im Playground. Eingerichtet werden sie hier im Formular unten. API-Schlüssel legt der Controller in instance/providers.json auf seinem eigenen Rechner ab; sie gehen nie an den Browser oder an das Cluster, nur an den Provider selbst.

Provider werden geladen…

Provider hinzufügen oder aktualisieren

expand_more
Je Provider vorbelegt; für einen eigenen Endpunkt eine beliebige OpenAI-kompatible /v1-Basis, z. B. http://127.0.0.1:8001/v1.

lan NHR@FAU (Alex) über SSH optional

Eigene Modelle auf dem Alex-Cluster per SLURM-Job betreiben: Verbindung, Job-Start, Modell-Cache, Warteschlange, Logs und Clusterstatus. Wird erst beim Aufklappen geladen.

key SSH-Verbindung

Vom Controller für jeden Job- und Compute-Aufruf auf Alex genutzt. Gespeichert wird nur der Pfad zum privaten Schlüssel, nie der Schlüssel selbst.

play_circle Compute-Service starten

Schreibt deploy/config/run_config.env auf Alex und führt deploy/jobs/submit.sh aus. Nachdem der Job die Warteschlange verlassen hat, laden die Modelle einige Minuten; die Phase steht unten unter Cluster- & Dienststatus.

expand_more
expand_more
Erscheint in der Warteschlange als netichecker-<name>; leer behält netichecker-compute. Nur Buchstaben, Ziffern, . _ -.
expand_more

dataset Modelle & Profile

Serve-Profile legen fest, welche Modelle ein Job lädt und wie viele GPUs er braucht. Neues Modell in den Offline-Cache laden, danach in einem Profil auf Alex referenzieren und einen Job abschicken.

Serve-Profile

Profile werden geladen…

Modell in den Cache aufnehmen

Lädt ein Hugging-Face-Modell nach models_cache/ auf dem Alex-Login-Node (keine GPU, greift keinen laufenden Job an). Danach den ausgegebenen Backend-Block in ein Profil unter deploy/config/profiles/ eintragen und einen Job mit diesem Profil abschicken.

Modelle im Cache

Cache wird geladen…

list Warteschlange & Steuerung

Keine Jobs in der Warteschlange.

description Job-Log

expand_more

Cluster- & Dienststatus

Live-Ansicht des NetiChecker-Compute-Dienstes auf NHR@FAU Alex: SLURM-Queue, Runtime und Health-Probe in einem SSH-Roundtrip.

Dienstphase
noch nicht geladen

Aktiver Job
Job-ID–
Zustand–
Laufzeit / Limit–
Runtime
Node–
Profil–
Rest-Walltime–

dataset Modell-Backends

Keine Runtime. Einen Job oben unter Compute-Service starten abschicken.

memory GPU-Auslastung (Job-Node)

GPU-Metriken erscheinen, sobald der Dienst läuft.

list SLURM-Queue

Keine Jobs in der Queue.

terminal Cluster-Abfragen (nur lesend)

hub Controller-API

Diese statische UI spricht ausschließlich mit der Controller-API. Die Basis-URL liegt im Browser.

Lokal den Controller mit run_api.ps1 / run_api.sh starten. Die interaktive API-Dokumentation ist auf der Seite Schnittstelle verlinkt.