Hardwareabnahme
Prüfen Sie M4, 16 GB RAM und die grundlegende 256-GB-SSD. Enthält die Bestellung zusätzlichen Speicher, kontrollieren Sie verfügbare Kapazität und Einhängepunkt separat.
Nach Aufgabe vorgehen
Vorbereiten, verbinden, ausführen – dann Probleme lösen
Dies ist keine Sammlung einzelner Befehle. Prüfen Sie zuerst Bestellung und Knoten im Dashboard, stellen Sie dann die Verbindung her, reproduzieren Sie die Toolchain und nehmen Sie die Aufgabe abschließend anhand dauerhaft speicherbarer Logs ab. Geeignet für einen exklusiven physischen NowMini M4 mit 16 GB RAM und 256 GB SSD.
- 4 Aufgabentypen
- Vorbereiten, verbinden, ausführen, beheben
- 4 Knoten
- Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong
- 1 Konfiguration
- Exklusiver physischer NowMini M4-Knoten
Schnell finden
Beschreiben Sie zuerst Ihre aktuelle Aufgabe
Geben Sie Begriffe wie „Xcode“, „SSH“, „Runner“ oder „Festplatte“ ein; die Seite behält die passenden Schritte bei. Alternativ können Sie unten direkt einen Aufgabeneinstieg wählen.
Erstaktivierung
Schließen Sie vor der Verbindung sechs Prüfungen ab
Vermischen Sie Bestellbestätigung, Netzwerkfreigabe und Systeminitialisierung nicht in einer einzigen Verbindung. Erfassen Sie die Ergebnisse der Reihe nach, damit sich Authentifizierungsfehler schnell eingrenzen lassen.
Checkliste zur Aktivierung
Von Dashboarddaten zur ersten Sitzung
Maßgeblich sind die vom Dashboard aktuell zurückgegebenen Bestell- und Knotendaten. Übernehmen Sie die Hostadresse nicht aus alten Tickets oder Team-Chats.
01
Bestellkennung bestätigen
Notieren Sie Bestellkennung, Mietdauer und NowMini M4-Konfiguration und prüfen Sie, ob Sie mit der richtigen Bestellung arbeiten.
02
Knotenregion prüfen
Bestätigen Sie Singapur, Japan (Tokio), Südkorea (Seoul) oder Hongkong, und verwenden Sie im Team einheitliche Regionsnamen.
03
Systemzugangsdaten abrufen
Prüfen Sie Benutzername, Hostadresse und Schlüsselanforderungen. Zugangsdaten gehören ausschließlich in einen kontrollierten Passworttresor, nicht in ein Code-Repository.
04
Zugriffsquelle bestätigen
Dokumentieren Sie Büronetz, festen Ausgang oder die Quelladresse des Runners. Führen Sie die Erstinitialisierung nicht in einem unbekannten öffentlichen Netzwerk durch.
05
Erste Verbindung herstellen
Prüfen Sie zunächst die Netzwerkerreichbarkeit, danach Hostschlüssel-Fingerabdruck und Schlüsselberechtigungen. Ändern Sie nicht mehrere Variablen gleichzeitig und wiederholen Sie dann den Versuch.
06
Konto initialisieren
Erstellen Sie eine Umgebung mit den für die Aufgabe erforderlichen Minimalberechtigungen, legen Sie Arbeits- und Logverzeichnisse fest und speichern Sie ein Abnahmeprotokoll ohne Geheimnisse.
Sitzungsabnahme
Dokumentieren Sie getrennt, ob SSH und grafische Sitzung aufgebaut werden können, wie lange die erste Verbindung dauert und ob Tastatureingabe und Zwischenablage den Anforderungen entsprechen.
Verbindungsanleitung öffnen
Entwicklungsumgebung
Die Toolchain anhand ihrer Abhängigkeiten reproduzieren
Fixieren Sie zuerst die Toolversionen und binden Sie erst danach Zugangsdaten, Caches und Signaturmaterial ein. In umgekehrter Reihenfolge werden Versionsprobleme leicht als Berechtigungsprobleme fehlinterpretiert.
Xcode-Toolchain fixieren
Bestätigen Sie zunächst das ausgewählte Entwicklerverzeichnis und dokumentieren Sie dann Xcode- und SDK-Version. In Team-Pipelines muss die Version ein Build-Input sein, nicht von einer interaktiven Auswahl abhängen.
- Pfad der Kommandozeilenwerkzeuge prüfen
- Compiler- und SDK-Version dokumentieren
- Mit einem Minimalprojekt einen Basis-Build durchführen
Git-Zugangsdaten konfigurieren
Richten Sie für den Knoten oder das Automatisierungskonto einen eigenen Schlüssel ein und gewähren Sie nur die erforderlichen Repository-Rechte. Dokumentieren Sie nach dem ersten Abruf Remote-URL, Branch und Commit-Basis.
- Berechtigungen der Schlüsseldatei prüfen
- Lese- und Schreibgrenzen des Repositorys prüfen
- Geheimnisse nicht in Skriptparametern offenlegen
Abhängigkeiten und Cache trennen
Trennen Sie rekonstruierbare Abhängigkeiten, Build-Cache und fertige Artefakte. Der Cache-Schlüssel muss mindestens Toolversion, Lockfile-Hash und Zielplattform enthalten.
- Ergebnis der Abhängigkeitsauflösung fixieren
- Wachstum des Cache-Verzeichnisses begrenzen
- Basis-Build ohne Cache beibehalten
Signaturmaterial zuletzt importieren
Importieren Sie Zertifikate, Bereitstellungsprofile und Entsperrinformationen erst nach der Toolchain-Prüfung. Verwenden Sie ein kontrolliertes Verzeichnis und löschen Sie temporäre Kopien nach Abschluss.
- Gültigkeitsbereich der Zertifikate dokumentieren
- Zugriffsberechtigte des Schlüsselbunds begrenzen
- Signaturkette mit einer Archivierungsaufgabe prüfen
Abnahmekriterien
Derselbe Commit muss in einem sauberen Arbeitsverzeichnis Abhängigkeitsauflösung, Kompilierung, Tests und Archivierung abschließen. Bei Fehlern muss das Log die konkrete Phase erkennen lassen, statt nur „Build fehlgeschlagen“ zu melden.
CI/CD-Anbindung
Den physischen Knoten in die bestehende Warteschlange integrieren
Der Runner ist der Ausführungseinstieg und darf nicht gleichzeitig Geheimnisspeicher, dauerhafte Artefaktablage und gemeinsam genutztes Teamverzeichnis sein. Klären Sie zuerst Verzeichnisse und Berechtigungen, bevor Sie die Parallelität erhöhen.
Ausführungskette
Fünf Stationen, eine prüfbare Zeitachse
Erfassen Sie pro Aufgabe mindestens Commit, Runner, Startzeit, Endstatus und Artefaktpfad. Der Knoten läuft 365 Tage im Jahr normal weiter.
Runner registrieren
Registrieren Sie den Runner mit einem eigenen Automatisierungskonto. Labels dürfen nur System und Aufgabenkapazitäten beschreiben, niemals Geheimnisse oder Personennamen.
Arbeitsverzeichnis isolieren
Verwenden Sie je Pipeline einen eigenen Arbeitspfad. Löschen Sie temporäre Dateien nach Abschluss, damit keine vorherige Aufgabe den nächsten Build beeinflusst.
Cache-Strategie definieren
Benennen Sie Caches nach Lockfile und Toolversion, setzen Sie eine Kapazitätsgrenze und behalten Sie den vollständigen Ablauf ohne Cache-Treffer bei.
Build-Artefakte zurückübertragen
Übertragen Sie Archive, Symboldateien und Testberichte in den vorhandenen Teamspeicher. Das Arbeitsverzeichnis des Knotens darf nicht die einzige Kopie sein.
Fehlerlogs aufbewahren
Bewahren Sie Fehlerphase, Exit-Code und wichtigen Kontext auf. Entfernen Sie Token, Schlüssel und Signaturmaterial vor einer Supportanfrage.
Parallelitätssteuerung
Erstellen Sie zunächst eine Basis mit einer einzelnen Aufgabe und erhöhen Sie die Parallelität schrittweise. Bei 16 GB RAM sollten Tests, Archivierung und Inferenz anhand realer Spitzenlasten getrennt werden.
Grenzen für Wiederholungen
Wiederholen Sie nur wiederherstellbare Schritte wie kurze Netzunterbrechungen. Bei Kompilierungs-, Test- oder Signaturfehlern muss das ursprüngliche Ergebnis erhalten bleiben.
Artefakte prüfen
Prüfen Sie nach der Übertragung Dateigröße, Hash und Aufgabenkennung. Teammitglieder müssen aus dem Pipelineeintrag den zugehörigen Commit und die Build-Umgebung zurückverfolgen können.
MLX-Experiment
Erst die Umgebung prüfen, dann die Inferenz ausweiten
Der NowMini M4 eignet sich für reproduzierbare kleinere MLX-Experimente. Modelldateien, Laufparameter und Ergebnisprotokolle sollten getrennt bleiben, damit Bereinigung und erneute Ausführung einfach sind.
MLX-CHECKPOINTS
NOWMINI M4
Umgebung prüfen
Dokumentieren Sie Python-, MLX- und wichtige Abhängigkeitsversionen und bestätigen Sie die Ausführbarkeit mit kleinen Tensoroperationen.
Modelle ablegen
Legen Sie Modelldateien in einem eigenen Datenverzeichnis ab, prüfen Sie deren Hash und mischen Sie sie nicht mit Quell-Repository oder temporärem Cache.
Aufgabe ausführen
Fixieren Sie Modell, Eingabe, Sampling-Parameter und Zufalls-Seed. Starten Sie mit kleinen Batches und beobachten Sie Speicher und Ausgabestabilität.
Ressourcen überwachen
Erfassen Sie maximalen Speicher, Festplattenwachstum, Laufzeit und Exit-Status, damit Logs oder Zwischenergebnisse den Speicher nicht füllen.
Was muss ein Experiment mindestens enthalten?
- Eingabe
- Modellkennung, Dateihash, Prompt oder Dataset-Version
- Umgebung
- System-, Python-, MLX- und Abhängigkeitsversionen
- Parameter
- Batchgröße, Generierungslänge, Sampling-Einstellungen
- Ergebnis
- Laufzeit, Spitzenressourcen, Ausgabezusammenfassung, Exit-Status
Speichergrenzen
Die Basiskonfiguration umfasst eine 256-GB-SSD. Prüfen Sie vor dem Herunterladen von Modellen den verfügbaren Speicher. Große Modelle, Zwischenergebnisse und mehrere Gewichtsversionen müssen in die Bereinigung einbezogen werden oder bei der Bestellung durch zusätzlichen festen Speicher berücksichtigt werden.
Tarif und Speicher anzeigen
Fehlerbaum
Mit Randbedingungen beginnen, Konfigurationen nicht zufällig ändern
Ermitteln Sie zunächst, ob das Problem in der lokalen Netzwerk-, Zugriffs-, Authentifizierungs-, Toolchain- oder Ressourcenschicht liegt. Ändern Sie pro Versuch nur eine Variable und dokumentieren Sie das Ergebnis.
Knoten nicht erreichbar: Welche Schicht zuerst prüfen?
- Bestätigen Sie, dass das lokale Netzwerk externe Dienste erreichen kann, und testen Sie nach dem Deaktivieren temporärer Routing-Proxy-Einstellungen erneut.
- Prüfen Sie Hostadresse und Knotenregion erneut im Dashboard; verwenden Sie keine Adresse aus einem alten Screenshot.
- Bestätigen Sie, dass die aktuelle Zugriffsquelle den Einschränkungen entspricht, und prüfen Sie, ob die lokale Firewall den Zielport blockiert.
- Dokumentieren Sie DNS-Auflösung, Netzwerkerreichbarkeit und Protokoll-Handshake getrennt, statt nur „keine Verbindung“ zu melden.
Authentifizierung fehlgeschlagen: Benutzername oder Schlüssel?
- Prüfen Sie, ob der Benutzername zum aktuellen Knoten gehört; verwenden Sie nicht das Konto eines anderen Servers.
- Prüfen Sie Berechtigungen und Format der privaten Schlüsseldatei sowie den vom Client tatsächlich geladenen Schlüsselpfad.
- Prüfen Sie, ob der Hostschlüssel-Fingerabdruck mit dem ersten Eintrag übereinstimmt. Bei einer Änderung stoppen Sie die Verbindung und lassen Sie sie per Ticket prüfen.
- Aktivieren Sie detaillierte Client-Logs, bewahren Sie ausgehandelte Authentifizierungsmethoden und die serverseitige Ablehnungsphase auf und entfernen Sie vor der Übermittlung sensible Inhalte.
Buildfehler: Versionen, Abhängigkeiten oder Signatur?
- Prüfen Sie zunächst, ob Xcode, SDK und Pfad der Kommandozeilenwerkzeuge der Basis entsprechen.
- Lösen Sie die gesperrten Abhängigkeiten in einem sauberen Arbeitsverzeichnis erneut auf, um eine Cache-Verunreinigung zu erkennen.
- Trennen Sie Kompilierungs- und Signaturprobleme: Erstellen Sie zuerst ohne Veröffentlichungssignatur und prüfen Sie anschließend das Archiv.
- Bewahren Sie den ersten Fehler samt Kontext auf; schneiden Sie nicht nur die Zusammenfassung am Logende aus.
Nicht genügend Speicherplatz: Welche Verzeichnisse zuerst prüfen?
- Dokumentieren Sie Gesamtkapazität, belegten Speicher und die Veränderung vor und nach der Aufgabe. Löschen Sie nicht sofort alle Dateien.
- Prüfen Sie nacheinander Build-Cache, Archive, Testergebnisse, heruntergeladene Modelle und dauerhaft wachsende Logverzeichnisse.
- Bereinigen Sie die Knotenkopie erst, nachdem die Artefakte übertragen wurden, damit die einzige wiederherstellbare Datei nicht gelöscht wird.
- Setzen Sie Kapazitätsgrenzen für Cache und Logs und integrieren Sie die Bereinigung in den Aufgabenabschluss.
Aufgabe überschritten: langsam oder blockiert?
- Vergleichen Sie den letzten gültigen Logeintrag und prüfen Sie, ob die Aufgabe noch rechnet, auf das Netzwerk oder auf einen Unterprozess wartet.
- Prüfen Sie, ob andere Aufgaben auf demselben Knoten um Speicher, Festplatte oder eine Sperre des Arbeitsverzeichnisses konkurrieren.
- Legen Sie getrennte Zeitlimits für Download, Build, Tests und Upload fest; verwenden Sie kein einziges Gesamtlimit für alle Phasen.
- Speichern Sie vor einem erneuten Versuch Prozessstatus und Fehlerlogs. Bei stabiler Reproduzierbarkeit fügen Sie die kleinste mögliche Aufgabe dem Ticket bei.
Diagnoseprotokoll
Eine wirksame Prüfung hinterlässt fünf Angaben
- Zeitpunkteinschließlich Zeitzone
- Knotenregioneine der vier verfügbaren Knotenregionen
- Arbeitsschrittewiederholbar ausführbar
- Erwartet und tatsächlichAbweichung beschreiben
- Bereinigte LogsFehlerkontext bewahren
Sicherer Betrieb
Zugriffsrechte über den gesamten Aufgabenlebenszyklus verwalten
Zugangsdaten sind keine einmalig eingerichteten Dateien für immer. Wenn sich Personen, Runner, Netzwerkquellen oder Projekte ändern, müssen die Berechtigungsgrenzen erneut geprüft werden.
Zugangsdaten rotieren
Rotieren Sie sie sofort nach Personalwechseln, vermuteter Schlüsseloffenlegung oder Änderungen am Automatisierungskonto. Deaktivieren Sie alte Zugangsdaten und prüfen Sie danach die neuen, damit keine unbekannten Zugänge parallel bestehen.
Zugriffsquellen begrenzen
Verwenden Sie bevorzugt erkennbare feste Ausgangsadressen. Widerrufen Sie temporäre Freigaben nach Abschluss und dokumentieren Sie Ändernden, Zweck und Widerruf.
Automatisierungsrechte minimieren
Der Runner verwendet ein eigenes Konto und einen eigenen Schlüssel und greift nur auf Ziel-Repository, Arbeitsverzeichnis und Artefaktpfad zu. Build-Skripte dürfen keine dauerhaften persönlichen Rechte erben.
Migration und Übergabe bereinigen
Übertragen Sie zunächst Quellcode, Modelle und Artefakte. Löschen Sie anschließend temporäre Zertifikate, Schlüssel, Caches und Logs mit sensiblen Feldern. Die empfangende Person nimmt anhand der Checkliste erneut ab.
Abschluss der Übergabe
Die neue verantwortliche Person kann mit eigener Autorisierung eine Verbindung herstellen, eine Basisaufgabe ausführen und Logs lesen. Alte Zugangsdaten sind widerrufen; auf dem Knoten existieren keine unbetreuten temporären Konten oder Geheimniskopien.
Persönlicher Support
Fragen in ein sofort bearbeitbares Ticket verwandeln
Probleme zu bestehenden Bestellungen reichen Sie bevorzugt im Dashboard als Ticket ein. Für Fragen vor dem Kauf, die Bewertung umfangreicher Workflows oder Anmeldeprobleme können Sie eine E-Mail senden. Extern gibt es nur diese beiden Kontaktwege.
Ticketfelder
Bereiten Sie vor dem Absenden sechs Angaben vor
Je näher die Informationen an reproduzierbaren Bedingungen liegen, desto schneller beginnt die Diagnose, ohne dass grundlegende Fakten mehrfach bestätigt werden müssen.
- Bestellkennung
- Aktuelle Bestellkennung aus dem Dashboard
- Knotenregion
- Singapur, Japan (Tokio), Südkorea (Seoul) oder Hongkong
- Zeitpunkt
- Datum, Uhrzeit und Zeitzone angeben
- Reproduktionsschritte
- Reihenfolge der Aktionen vom Normalzustand bis zum Fehler
- Tatsächliches Ergebnis
- Fehlertext, Exit-Code oder abweichendes Verhalten
- Bereinigte Logs
- Kontext bewahren, Passwörter, Schlüssel und Token entfernen
Keine sensiblen Daten übermitteln
Fügen Sie Tickets und E-Mails keine Passwörter, privaten Schlüssel, vollständigen Zahlungsdaten, Signaturmaterialien oder Token mit direktem Zugriff auf Code-Repositorys bei.
Problem zu bestehender Bestellung
Melden Sie sich im Dashboard an und reichen Sie ein Ticket ein, das mit Bestellung und Knoten verknüpft werden kann. Geeignet für Verbindungsfehler, Abrechnungsprüfung, Knotenstatus und bestehende Aufgaben.
Dashboard-Ticket einreichenFragen vor dem Kauf und Anmeldehilfe
Senden Sie eine E-Mail an support@nowmini.com und nennen Sie Workflow, Zielregion, voraussichtliche Mietdauer und das reproduzierbare Problem. Die Adresse kann direkt als eigene Zeile angezeigt werden.
E-Mail an support@nowmini.com senden
Nächster Schritt
Nach der Konfiguration direkt loslegen
Wählen Sie einen exklusiven physischen NowMini M4-Knoten und führen Sie Builds, Automatisierung und MLX-Aufgaben in Singapur, Japan (Tokio), Südkorea (Seoul) oder Hongkong aus. Maßgeblich ist die aktuelle Verfügbarkeit im Dashboard.