Problem nach Aufgabe finden

Vom Fehlerbild zu umsetzbaren Prüfschritten

Hier finden Sie Hilfe zur ersten Verbindung, zu SSH-Schlüsseln, VNC, MLX-Inferenzdiensten, CI und Bestellungen auf exklusiven physischen Cloud-Mac-Knoten von VMMini. Prüfen Sie zunächst die Grundlagen und reichen Sie anschließend Logs und den relevanten Zeitraum mit einem Ticket ein.

Auf dieser Seite werden niemals Passwörter, private Schlüssel oder Wiederherstellungsphrasen verlangt. Bei bestehenden Bestellungen können Sie sich im Portal anmelden und ein Ticket erstellen, das Bestellung und Knoten automatisch verknüpft.

Ticket im Portal erstellen Einstiegsleitfaden lesen
Supportablauf Erst eingrenzen, dann Belege sammeln, danach einreichen
Klarer Ablauf
03 Fehlerbehebungsphase
Fehlerbild Verbindung, Build, Speicher, Dienst oder Bestellung
Belege Zeit, Befehle, Exit-Codes und bereinigte Logs
Maßnahme Selbst beheben oder Ticket zur Bestellung erstellen
Knotenstandorte Singapur · Japan (Tokio) · Südkorea (Seoul) · Hongkong
Schnellsuche

Fehlermeldung, Toolname oder Aufgabenziel eingeben

Die Suche durchsucht die Leitfäden, Fehlerweiterleitungen und Begriffserklärungen dieser Seite. Enthält die Fehlermeldung eine Bestellnummer, einen Hostnamen oder eine Adresse, entfernen Sie sensible Daten vor der Eingabe.

Verbindung und Zugriff

Zuerst Lieferdaten prüfen, dann die Verbindungsmethode beurteilen

Verbindungsprobleme entstehen häufig durch Adresse, Port, Schlüsselberechtigungen, Client-Cache oder den lokalen Netzwerkpfad. Überspringen Sie die Fingerabdruckprüfung nicht, bevor der Host-Fingerabdruck bestätigt ist.

SSH: Mit dem Host-Fingerabdruck beginnen

Halten Sie die gelieferte Hostadresse, den SSH-Port, den Benutzernamen und die Datei mit dem passenden privaten Schlüssel bereit. Bewahren Sie private Schlüssel nur auf kontrollierten Geräten oder in einem Schlüsselverwaltungsdienst auf und fügen Sie sie nicht in ein Ticket ein.

  1. Erste Verbindung:Vergleichen Sie den im Portal angezeigten Host-Fingerabdruck Segment für Segment mit der Meldung des Clients.
  2. Berechtigungen prüfen:Stellen Sie sicher, dass nur der aktuelle Benutzer die Datei mit dem privaten Schlüssel lesen kann und der Inhalt des öffentlichen Schlüssels keine beschädigten Zeilenumbrüche enthält.
  3. Verbindungstrennung prüfen:Prüfen Sie nacheinander lokales Netzwerk, DNS oder Adresse, Port-Erreichbarkeit sowie die Zuordnung von Benutzername und Schlüssel.
  4. Belege sammeln:Bewahren Sie die ausführliche Ausgabe mit Zeitangaben auf, entfernen Sie jedoch sensible Teile aus Adressen, Benutzernamen und Schlüsselpfaden.
ssh -vvv -p <port> <user>@<host>

VNC: Sitzung und Anzeige zuerst prüfen

Sie benötigen Knotenadresse, Port, Zugangsdaten und eine verfügbare grafische Sitzung. Zugangsdaten gehören in ein Passwortverwaltungstool und nicht in ein Skript-Repository oder Build-Log.

  1. Erste Anmeldung:Prüfen Sie Systemversion, Festplattenspeicher, Zeitzone, Tastaturbelegung und aktuellen Netzwerkstatus.
  2. Schwarzer Bildschirm:Stellen Sie zunächst sicher, dass die grafische Sitzung noch läuft, und prüfen Sie anschließend Farbtiefe und Skalierung des Clients.
  3. Häufige Verbindungsabbrüche:Notieren Sie Zeitpunkt, Dauer, lokalen Netzwerktyp und ob gleichzeitig ein Zugriff per SSH möglich ist.
  4. Bildruckler:Senken Sie die Anzeigequalität für einen Vergleichstest. Ein einmaliger Client-Ruckler ist nicht automatisch ein Fehler des Knotens.

Remote Desktop: Client und Knoten getrennt prüfen

Prüfen Sie zunächst, ob der verwendete Client die gelieferte Verbindungsmethode unterstützt, und gleichen Sie dann Adresse, Port und Sitzungszugangsdaten ab. Verwenden Sie keine veralteten Zugangsdaten wiederholt, da dies die eigentliche Fehlerursache verdecken kann.

  1. Lokale Seite:Deaktivieren Sie den Proxy oder wechseln Sie für einen Vergleich das Netzwerk und notieren Sie Clientversion sowie den genauen Fehlertext.
  2. Knotenseite:Wenn SSH verfügbar ist, prüfen Sie Prozesse des Grafikdienstes, freien Speicher und Systemauslastung.
  3. Netzwerkpfad:Vergleichen Sie die Verbindungsergebnisse in verschiedenen Netzwerken und prüfen Sie, ob das Problem nur auf einem Pfad auftritt.
  4. Ticket einreichen:Geben Sie Bestellkennung, Knoten, Zeitpunkt und bereinigte Screenshots an, niemals das Verbindungskennwort.
MLX-Inferenzsupport

Modellprobleme mit fünf Prüfpunkten eingrenzen

Belegen Sie zuerst, dass Laufzeitumgebung und Modelldateien vollständig sind, und prüfen Sie anschließend Bindungsadresse, Health-Endpunkt und Logs. Öffnen Sie nur tatsächlich benötigte Ports und begrenzen Sie die zulässigen Quellen.

01

Umgebung bestätigen

Notieren Sie macOS-Version, Python-Version, Pfad der virtuellen Umgebung, Versionen der MLX-Pakete und verfügbaren Speicher. Stellen Sie sicher, dass die Aufgabe auf einem exklusiven physischen VMMini-M4-Knoten mit M4, 16 GB und 256-GB-SSD läuft und keine Parameter einer gemeinsam genutzten Umgebung übernommen wurden.

02

Modell vorbereiten

Prüfen Sie Pfad, Anzahl, Prüfergebnisse und benötigten Speicher der Modelldateien. Legen Sie Modelle und Cache in klar definierten Verzeichnissen ab, damit Download und Dienst nicht gleichzeitig in denselben temporären Pfad schreiben.

03

Listener prüfen

Binden Sie zunächst an eine lokale Adresse und passen Sie den Bindungsbereich erst nach erfolgreicher Prüfung an den tatsächlichen Zugriff an. Stellen Sie sicher, dass der Port nicht von einem anderen Prozess belegt ist, und öffnen Sie extern nur erforderliche Ports für notwendige Quellen.

04

Health-Check ausführen

Rufen Sie den Health-Endpunkt lokal auf dem Knoten auf und protokollieren Sie HTTP-Status, Antwortzeit und Antworttext. Wenn der lokale Aufruf funktioniert, der externe jedoch nicht, prüfen Sie Ports, Zugriffsregeln und Netzwerkpfad statt das Modell wiederholt neu zu starten.

05

Reproduzierbare Logs sammeln

Bewahren Sie eine bereinigte Version des Startbefehls, Standardausgabe, Standardfehler, Exit-Code, Modellnamen und Zeitpunkt auf. Entfernen Sie Zugriffstoken, Anfrageinhalte oder Nutzerdaten vor dem Einreichen.

Lokaler Health-Check

Dienst zuerst über die Loopback-Adresse prüfen

Ersetzen Sie im Befehl Port und Health-Pfad durch die tatsächlichen Werte. Der Health-Endpunkt sollte leichtgewichtig und stabil sein und keine vollständige Inferenz auslösen.

curl --fail --show-error \
  --max-time 10 \
  http://127.0.0.1:<port>/health
CI-Support

Runner widerrufbar, bereinigbar und reproduzierbar machen

Ein self-hosted runner ist mehr als ein dauerhaft laufender Prozess. Für Registrierung, Zugangsdaten, Cache, Artefakte und Widerruf müssen Verantwortliche und Aufbewahrungsgrenzen klar festgelegt sein.

01

Runner registrieren

Verwenden Sie ein eigenes Dienstkonto und ein separates Arbeitsverzeichnis. Dokumentieren Sie Runner-Name, Labels, zugehöriges Projekt und Registrierungszeitpunkt. Labels dürfen nur tatsächlich vorhandene Fähigkeiten beschreiben, damit mehrere Projekte nicht versehentlich dasselbe Arbeitsverzeichnis nutzen.

Abschlusskriterium Der Runner ist in der Warteschlange erkennbar und Testaufgaben liefern einen eindeutigen Exit-Code.
02

Projektzugangsdaten isolieren

Trennen Sie Token nach Projekt und Umgebung und verwenden Sie bevorzugt kontrollierte Schlüsselverwaltung oder Laufzeit-Umgebungsvariablen. Langfristige Zugangsdaten dürfen nicht in Repository, Runner-Konfigurationssicherung oder herunterladbare Artefakte gelangen.

Abschlusskriterium Aufgaben-Logs geben keine Geheimnisse aus; der Widerruf eines einzelnen Projekts beeinflusst keine anderen Projekte.
03

Build-Cache verwalten

Verwenden Sie getrennte Verzeichnisse für Abhängigkeits-Cache, DerivedData, temporäre Dateien und Archive. Bei knappem Speicher ermitteln Sie zuerst die Ursache des Wachstums und bereinigen Sie projektbezogen, statt Verzeichnisse laufender Aufgaben direkt zu löschen.

Abschlusskriterium Cache-Pfade sind nachvollziehbar, und die Bereinigung löscht keine fertigen Artefakte.
04

Build-Artefakte aufbewahren

Dokumentieren Sie für jedes Artefakt Commit-Version, Build-Nummer, Toolchain-Version und Prüfinformationen. Verschieben Sie aufzubewahrende Dateien nach Abschluss aus dem Runner-Arbeitsverzeichnis, damit sie bei der Cache-Bereinigung nicht gelöscht werden.

Abschlusskriterium Fehler-Logs und erfolgreiche Artefakte lassen sich demselben Build zuordnen.
05

Runner sicher widerrufen

Stoppen Sie zunächst die Annahme neuer Aufgaben, warten Sie das aktuelle Jobende ab, widerrufen Sie anschließend das Registrierungstoken projektseitig und entfernen Sie den Dienst. Prüfen Sie zuletzt, ob Arbeitsverzeichnis, Cache und Zugangsdaten gemäß dem Plan ausgelagert wurden.

Abschlusskriterium Die Steuerung plant keine Aufgaben mehr ein, und auf dem Knoten bleiben keine wiederverwendbaren Registrierungsdaten zurück.
Glossar

Acht Begriffe mit einheitlicher Bedeutung

Einheitliche Begriffe bei der Fehlerbehebung verhindern, dass Knoten-, Software-, Netzwerk- und Abrechnungsprobleme vermischt werden.

Physischer Knoten
Der Mac-Mini-M4-Host, der der Bestellung tatsächlich zur Nutzung bereitgestellt wird. Er ist ein Cloud-Mac-Hardwareknoten und keine virtuelle Maschineninstanz.
Exklusive Nutzung
Die Bestellung nutzt Prozessor, Arbeitsspeicher und lokalen Speicher des gesamten physischen Rechners und teilt diese Rechenressourcen nicht mit anderen Mietbestellungen.
VNC
Eine Remote-Anzeigemethode für den Zugriff auf die grafische macOS-Oberfläche. Bei der Fehlerbehebung müssen grafische Sitzung, Client und Netzwerkpfad getrennt betrachtet werden.
self-hosted runner
Ein vom Team registrierter und verwalteter CI-Ausführungsagent, der Aufgaben abruft, Builds ausführt und Logs sowie Artefakte zurückgibt.
MLX
Ein auf Apple Silicon ausgerichtetes Machine-Learning-Toolkit für Modellvorbereitung, Inferenztests und die Validierung von Diensten.
Build-Cache
Gespeicherte Daten zur Verringerung wiederholter Downloads und Kompilierungen, darunter Abhängigkeits-Cache, DerivedData und von Tools erzeugte Zwischendateien.
Knoten
Die Serviceregion des physischen Hosts. Das aktuelle Verzeichnis umfasst Knoten in Singapur, Japan (Tokio), Südkorea (Seoul) und Hongkong.
Abrechnungszeitraum
Der von der Bestellung gewählte Nutzungszeitraum; verfügbar sind Tag, Woche, Monat oder Quartal. Zeitraum, Start- und Ablaufzeit richten sich nach dem Bestellprotokoll im Portal.
Fehlerweiterleitungsbaum

Nächsten Schritt nach Fehlerbild wählen und nicht mehrere Einstellungen gleichzeitig ändern

Ändern Sie jeweils nur eine Bedingung und dokumentieren Sie das Ergebnis. Das Zurücksetzen mehrerer Einstellungen zugleich verwischt die Fehlergrenzen und verhindert eine Reproduktion durch das Supportteam.

NET Keine Verbindung zum Knoten Timeout, Verbindung abgelehnt, Fingerabdruck geändert oder Zugangsdaten stimmen nicht überein
Zuerst prüfen

Ob die Bestellung gültig ist, Adresse und Port zum aktuellen Knoten gehören, das lokale Netzwerk den Zielport erreicht und Benutzername sowie Schlüssel zusammenpassen.

Informationen sammeln

Zeitpunkt, Clientversion, genauer Fehlertext, bereinigte ausführliche Verbindungsdiagnose und Vergleichsergebnis nach einem Netzwerkwechsel.

Zeitpunkt für ein Ticket

Wenn zwei unabhängige Netzwerke keine Verbindung herstellen können oder der Host-Fingerabdruck nicht mit dem Portal übereinstimmt, beenden Sie weitere Versuche und erstellen Sie ein Ticket.

BLD Build fehlgeschlagen Fehler bei Abhängigkeitsauflösung, Kompilierung, Signierung oder Runner-Job
Zuerst prüfen

Ob Commit, Sperrdatei, Toolchain-Version, Umgebungsvariablen, Runner-Labels und Arbeitsverzeichnis mit dem letzten erfolgreichen Build übereinstimmen.

Informationen sammeln

Vollständiger Exit-Code, Logs vor und nach der Fehlerphase, Build-Befehl, Toolversionen und Vergleichsergebnis nach einer Cache-Bereinigung.

Zeitpunkt für ein Ticket

Erstellen Sie ein Ticket, wenn derselbe Commit mit derselben Konfiguration in einem sauberen Arbeitsverzeichnis weiterhin zuverlässig fehlschlägt und die Logs auf ein Knoten-, System- oder Speicherproblem hinweisen.

DSK Festplattenspeicher knapp Modelle, Build-Cache, Logs oder Archive wachsen kontinuierlich
Zuerst prüfen

Ermitteln Sie den Speicherverbrauch je Verzeichnis und unterscheiden Sie Modelle, Abhängigkeits-Cache, DerivedData, Logs, temporäre Dateien und auszulagernde fertige Artefakte.

Informationen sammeln

Freier Dateisystemspeicher, größte Verzeichnisse, Beginn des Wachstums, laufende Aufgaben und letzter Bereinigungsvorgang.

Zeitpunkt für ein Ticket

Erstellen Sie ein Ticket, wenn Dateisystembericht und Verzeichnisstatistik deutlich abweichen oder nach dem Löschen bereinigbarer Inhalte kein Speicher frei wird.

SRV Dienst reagiert nicht Prozess vorhanden, Health-Endpunkt mit Timeout oder extern nicht erreichbar
Zuerst prüfen

Prozessstatus, Bindungsadresse, Portbelegung, lokalen Health-Check, verfügbaren Speicher und die jüngste Standardfehlerausgabe.

Informationen sammeln

Bereinigte Version des Startbefehls, Prozess-Exit-Code, lokale und externe Anfrageergebnisse, Antwortzeit und Zeitraum der Dienst-Logs.

Zeitpunkt für ein Ticket

Erstellen Sie ein Ticket, wenn auch lokale Anfragen fehlschlagen und die Dienst-Logs einen systemweiten Fehler zeigen oder mehrere Dienste gleichzeitig nicht reagieren.

ORD Fehler bei der Portalbestellung Bestellstatus, Zeitraum, Knoten oder Abrechnungsdaten weichen von der Erwartung ab
Zuerst prüfen

Ob Bestellkennung, gewählte VMMini-M4-Konfiguration, Knoten, Abrechnungszeitraum, Zusatzoptionen und Zahlungsdatensatz derselben Bestellung zugeordnet sind.

Informationen sammeln

Bestellkennung, angezeigter Status, Zeitpunkt, Handlungsschritte und bereinigte Screenshots. Übermitteln Sie keine vollständigen Zahlungsdaten.

Zeitpunkt für ein Ticket

Erstellen Sie über das Portal ein verknüpftes Ticket, wenn die Abweichung auch nach Aktualisierung und erneuter Anmeldung besteht oder der Bestellvorgang nicht fortgesetzt werden kann.

Betriebsstatus

Knoten ganzjährig verfügbar, Ereignisse anhand der Bestelldaten prüfen

VMMini-Knoten sind für einen regulären Betrieb an 365 Tagen im Jahr ausgelegt. Die Verfügbarkeit der einzelnen Bestellung und Ereignisdaten richten sich nach den aktuellen Angaben und verknüpften Einträgen im Portal.

Betriebsumfang der vier Knoten Alle Knoten im Verzeichnis können für VMMini-M4-Bestellungen genutzt werden; die aktuelle Verfügbarkeit zeigt das Portal in Echtzeit.
Bestellereignisse anzeigen

Singapur

Teams und Workloads in Südostasien können diesen Pfad bevorzugt testen.

Japan (Tokio)

Geeignet für Vergleichstests mit Codequellen in Japan oder Ostasien.

Südkorea (Seoul)

Geeignet für Verbindungstests aus Nordostasien.

Hongkong

Geeignet für Vergleichstests der Netzwerkpfade nach Südchina und Südostasien.

So erkennen Sie ein Dienstereignis: Testen Sie die Verbindung zunächst über zwei unabhängige Netzwerke und prüfen Sie anschließend den lokalen Dienst sowie die Nutzersoftware auf dem Knoten. Externe Netzwerkpfade, Benutzerkonfigurationen oder der Ausfall eines einzelnen Prozesses sind nicht automatisch gleichbedeutend mit einem nicht verfügbaren physischen Knoten.
Supportanfrage einreichen

Was ein direkt bearbeitbares Ticket enthalten sollte

Bei bestehenden Bestellungen verwenden Sie bevorzugt das Portal-Ticket, damit Knoten, Zeitraum und Ereignisdaten verknüpft werden können. Wenn Sie sich nicht anmelden können, erreichen Sie das Serviceteam unter support@vmmini.com.

Checkliste für Anfragen

Sechs erforderliche Angaben

Keine Kontoschlüssel
  1. 01
    Bestellkennung

    Geben Sie die Bestellkennung aus dem Portal an und ersetzen Sie sie nicht durch andere persönliche Daten im Screenshot.

  2. 02
    Betroffener Knoten

    Nennen Sie Singapur, Japan (Tokio), Südkorea (Seoul) oder Hongkong sowie den zugehörigen Host.

  3. 03
    Zeitpunkt des Auftretens

    Geben Sie Zeitzone, Zeitpunkt des ersten Auftretens, Zeitpunkt der letzten Reproduktion und an, ob das Problem weiterhin besteht.

  4. 04
    Reproduktionsschritte

    Listen Sie Befehle, Eingabebedingungen, erwartetes und tatsächliches Ergebnis in der Reihenfolge der Aktionen auf.

  5. 05
    Originaler Fehlertext

    Bewahren Sie Exit-Code und wichtigen Kontext auf. Schreiben Sie nicht nur „nicht nutzbar“ oder „Build fehlgeschlagen“.

  6. 06
    Bereinigte Logs

    Entfernen Sie Passwörter, private Schlüssel, Zugriffstoken, Nutzerdaten und unnötige vollständige Adressen, bevor Sie die Logs anhängen.

Keine Bestellung oder kein Login möglich

Senden Sie eine E-Mail an support@vmmini.com. Geben Sie im Betreff den Problemtyp an. Die E-Mail muss weiterhin Knoten, Zeitpunkt, Reproduktionsschritte und bereinigte Logs enthalten.

Kontaktinformationen anzeigen

Diese Inhalte nicht übermitteln

Passwörter, private Schlüssel, Zugriffstoken, Wiederherstellungsphrasen, vollständige Zahlungsdaten, nicht bereinigte Nutzerdaten sowie irrelevante Repository-Inhalte.

Datenschutz lesen
Belege ins Ticket übernehmen

Bestehende Bestellung: Knotenverlauf direkt verknüpfen und weiter prüfen

Halten Sie Bestellkennung, Knoten, Zeitpunkt, Reproduktionsschritte und bereinigte Logs bereit. Portal-Tickets dienen technischen und bestellbezogenen Problemen; Fragen vor dem Kauf können Sie ebenfalls über die zentrale Support-E-Mail stellen.

Ticket im Portal erstellen Einstiegsleitfaden lesen