Technisches Handbuch

Vom bereitgestellten Cloud-Mac zum zuverlässigen Betrieb

Hier geht es direkt in die Praxis: Prüfen Sie zuerst Bestellung und Knotendaten, und richten Sie anschließend Zugangsdaten, Xcode, CI und MLX-Inferenz ein. Jeder Abschnitt enthält eine Prüfreihenfolge, klare Abnahmekriterien und Hinweise zur Diagnose.

Cloud-Mac mieten Anleitung für den Fernzugriff

Betriebsart: Dedizierter physischer Mac, keine VM
Einrichtungszeit: Ca. 4 Minuten
Verfügbarkeit: 365 Tage im Jahr verfügbar

Knoten-Checkliste Ersteinrichtung

4 Prüfpunkte

Bestellung und Knoten Modell, Region, Laufzeit und Extras stimmen überein

Prüfen

Zugangsdaten Nach der ersten Verbindung ändern und sicher speichern

Ändern

Entwicklungsumgebung macOS, Xcode und CLI-Tools prüfen

Prüfen

Netzwerk und Arbeitsverzeichnis Verbindung, freien Speicher und Verzeichnisrechte prüfen

Bereit

Abnahmekriterien Verbinden, bauen, reproduzieren

Nach Aufgabe suchen

Sechs Anleitungen – finden Sie zuerst den Engpass

Bei der Ersteinrichtung folgen Sie den Schritten der Reihe nach. Bei Problemen mit einer bestehenden Umgebung springen Sie direkt zum passenden Abschnitt und sichern Sie Befehlsausgaben, Zeitpunkt und letzte Änderungen.

Erste Schritte

Grundlegende Prüfung in vier Minuten

Prüfen Sie die Bestellung, rufen Sie die Knotendaten ab, ändern Sie die Zugangsdaten und kontrollieren Sie Systemversion, Netzwerk und Speicher.

Einrichtungscheck öffnen

Entwicklungsumgebung

Xcode- und Signatur-Baseline festlegen

Prüfen Sie Version, Zertifikate, Schlüsselbundrechte und ausgewählte CLI-Tools. Erstellen Sie anschließend einen dokumentierten ersten Build.

Entwicklungsumgebung prüfen

CI/CD

Runner sauber und nachvollziehbar halten

Planen Sie Arbeitsverzeichnisse, Cache-Grenzen, Parallelität und Fehlerprotokolle, damit sich Jobs nicht gegenseitig beeinflussen.

Build-Queue einrichten

MLX-Inferenz

Neustartfähigen Inferenzdienst einrichten

Isolieren Sie die Laufzeit und legen Sie Modellverzeichnis, Bind-Adresse, Lasttests und Speicher-Baseline fest.

Inferenzdienst bereitstellen

Speicher und Netzwerk

Arbeitslast berechnen, dann Speicher erweitern

Trennen Sie Quellcode, Dependency-Caches, Modelle, Build-Artefakte und temporäre Dateien. Prüfen Sie den Bedarf an SSD-Erweiterung und Thunderbolt-Verbindungen.

Kapazität und Verbindungen planen

Konto und Abrechnung

Supportanfrage direkt bearbeitbar einreichen

Geben Sie Bestellnummer, Knotenregion, Systemversion, Zeitpunkt, Reproduktionsschritte und bereinigte Protokolle an.

Supportanfrage vorbereiten

Erste Schritte

Checkliste: Einrichtung in vier Minuten

Die Zeitmessung beginnt nach der Bestellbestätigung. Maßgeblich ist der aktuelle Status in der Konsole. Fehlen Angaben für einen Schritt, fahren Sie nicht mit der Konfiguration fort.

01
Bestellung prüfen Ca. 45 Sekunden
Prüfen Sie, ob Modell, Knotenregion, Laufzeit und Extras der Bestellung entsprechen. Das Basismodell bietet M4, 16 GB und 256 GB; die Variante mit mehr Arbeitsspeicher M4 Pro, 64 GB und 2 TB. Bei Abweichungen stoppen Sie und reichen eine Supportanfrage ein.
- Bestellnummer und Knotenregion notieren.
- Bedarf an Speichererweiterung und Thunderbolt-5-Verbindungen prüfen.
02
Knotendaten abrufen Ca. 2 Minuten
Warten Sie, bis Zuweisung und Systemprüfung abgeschlossen sind. Rufen Sie danach Knotenadresse und Verbindungsdaten in der Konsole ab. Teilen Sie diese nicht in öffentlichen Kanälen und speichern Sie Zugangsdaten nicht unverschlüsselt im Repository.
- Prüfen, ob Adresse und Region zur Bestellung passen.
- Erste Zugangsdaten in einem vom Team freigegebenen Passwortmanager speichern.
03
Zugangsdaten ändern Ca. 1 Minute
Ändern Sie die Zugangsdaten direkt nach der ersten Verbindung und richten Sie für Automatisierungen einen eigenen Schlüssel ein. Trennen Sie interaktive Konten von CI-Runner-Konten, damit Skripte keine unnötigen Systemrechte erhalten.
- Anfangspasswort ändern und neue Zugangsdaten testen.
- Schlüssel für CLI-Verbindungen einrichten und Host-Fingerabdruck prüfen.
04
System und Netzwerk prüfen Ca. 15 Sekunden

Notieren Sie macOS- und Xcode-Version. Prüfen Sie Standardroute, DNS-Auflösung, freien Speicherplatz und Schreibrechte im Arbeitsverzeichnis. Starten Sie anschließend einen kleinen Build oder eine Inferenzanfrage, um das Ergebnis zu verifizieren.

Alle Schritte zur Verbindung ansehen

Entwicklungsumgebung

Xcode- und Signaturumgebung zuerst standardisieren

Reproduzierbare Builds brauchen festgelegte Versionen, Zugriff auf den Schlüsselbund und einheitliche CLI-Tools. Ein Projektstart in der grafischen Oberfläche ersetzt keine Prüfung über die Kommandozeile.

Reihenfolge der Einrichtung

01
Xcode-Version prüfen
Notieren Sie vollständige Versions- und Buildnummer. Prüfen Sie, ob die benötigten SDKs, Simulator-Runtimes und Mindestversionen des Betriebssystems installiert sind.
02
Zertifikate und Profile importieren
Importieren Sie nur die für das aktuelle Projekt benötigten Dateien. Ergänzen Sie den Namen um Projekt und Verwendungszweck, damit die Herkunft bei Übergaben klar bleibt.
03
Schlüsselbundrechte prüfen
Prüfen Sie mit dem vorgesehenen Runner-Konto, ob der private Schlüssel lesbar ist. Testen Sie die Signierung vor automatisierten Builds ohne Interaktion, damit die Queue nicht an einer Berechtigungsabfrage hängen bleibt.
04
CLI-Tools auswählen
Prüfen Sie, ob die aktive Auswahl auf die gewünschte Xcode-Version verweist, und dokumentieren Sie das Ergebnis für das Projekt. Nach einem Versionswechsel müssen Dependencies und Signierung erneut geprüft werden.
05
Ersten Build abnehmen
Entfernen Sie zuerst alte Artefakte und führen Sie dann Tests, Archivierung und Signaturprüfung aus. Dokumentieren Sie Befehl, Exitcode, Protokollpfad und Prüfsumme des fertigen Artefakts.

Continuous Integration

Runner als feste Ressource statt als temporäres Verzeichnis behandeln

Ein dedizierter physischer Mac stellt feste Hardware bereit. Builds können trotzdem an verunreinigten Caches, zu hoher Parallelität oder unvollständigen Protokollen scheitern. Legen Sie vor der Integration Verzeichnisse und Zuständigkeiten für die Bereinigung fest.

Self-Hosted-Runner installieren

Richten Sie für den Runner ein eigenes Systemkonto und Dienstverzeichnis ein und vergeben Sie nur die für Builds nötigen Rechte. Starten Sie nach der Registrierung einen kleinen Job ohne Signierung, um Queue, Netzwerk und Exitstatus zu prüfen.

Abnahme: Nach einem Neustart nimmt der Runner automatisch wieder Jobs an

Arbeitsverzeichnisse planen

Trennen Sie den Source-Checkout, Dependency-Caches, temporäre Builds, Archive und langfristige Protokolle. Bereinigen Sie nach einem Job nur temporäre Verzeichnisse, nicht gemeinsam genutzte Caches, die der nächste Job braucht.

Abnahme: Verzeichnisbesitzer und Bereinigungsregeln sind festgelegt

Parallelität begrenzen

Ermitteln Sie mit einem einzelnen Job die Baseline für Speicher, Festplatte und Laufzeit und erhöhen Sie die Parallelität schrittweise. Beobachten Sie bei gleichzeitigen Xcode-Builds und MLX-Inferenz Spitzenbelegung und Schreiblast getrennt.

Abnahme: Auch bei Spitzenlast reichen Speicher und Festplattenplatz aus

Fehler nachvollziehbar dokumentieren

Sichern Sie bei fehlgeschlagenen Jobs mindestens Jobnummer, Commit, Runner-Version, Startzeit, Exitcode, relevante Protokolle und Artefaktpfad. Entfernen Sie Tokens und Signaturmaterial, bevor Sie Protokolle hochladen.

Abnahme: Ein anderes Teammitglied kann den Fehler selbstständig reproduzieren

Grenzen für die Cache-Bereinigung

Erstellen Sie Cache-Schlüssel möglichst anhand von Projekt, Branch und Tool-Version. Ersetzen Sie Speicherverwaltung nicht durch regelmäßiges Löschen der gesamten Festplatte. Prüfen Sie vor dem Bereinigen, ob Builds oder Archivierungen laufen.

KI und MLX

Inferenzdienste müssen testbar, beobachtbar und wiederherstellbar sein

Führen Sie zunächst eine einzelne Anfrage aus, bevor Sie Kontextlänge und Parallelität erhöhen. Trennen Sie Modellverzeichnis, Laufzeitumgebung und Dienstprotokolle, damit Updates an Dependencies nicht zugleich Modelldateien beeinträchtigen.

MLX-Dienst einrichten Mit einer einzelnen Anfrage beginnen

Apple Silicon

Isolierte Umgebung: Verwenden Sie für jeden Dienst eine eigene Python-Umgebung, fixieren Sie Dependency-Versionen und sichern Sie die Installationsliste.
Modellverzeichnis: Trennen Sie Modelldateien vom Quellcode und dokumentieren Sie Modellname, Quantisierungsformat, Prüfsumme und Speicherbedarf.
Bind-Adresse: Binden Sie den Dienst standardmäßig nur an die benötigten Schnittstellen und Adressen. Machen Sie Debug-Endpunkte nicht für fremde Netzwerke zugänglich.
Lasttest mit parallelen Anfragen: Testen Sie nacheinander 1, 2 und 4 parallele Anfragen. Erfassen Sie Time-to-first-token, Gesamtdauer, Fehlerrate und Spitzenbelegung des Arbeitsspeichers.
Speicher beobachten: Unterscheiden Sie zwischen dauerhaft geladenem Modell, wachsendem Kontext und Anfrage-Caches. Erhöhen Sie die Last nicht weiter, wenn sich die stabile Obergrenze nähert.
Neustartstrategie: Hinterlegen Sie Startbefehl, Arbeitsverzeichnis, Umgebungsvariablen und Protokollpfad in der Dienstkonfiguration. Prüfen Sie, ob der Dienst nach einem unerwarteten Ende wieder startet.

Kapazität und Verbindungen

Speicher nach Arbeitslast dimensionieren, nicht nach Projektnamen

Berechnen Sie zuerst den Spitzenbedarf für Quellcode, Dependencies, Modelle, Build-Artefakte, Protokolle und temporäre Dateien. Planen Sie zusätzlich Platz für Bereinigung und Rollbacks ein. Die Basiskapazität der SSD hängt vom gewählten Modell ab.

ArmMesh M4

256 GB SSD inklusive

Geeignet für Code-Checkouts, übliche Dependency-Caches, Builds einzelner Projekte und kurze Release-Aufgaben. Kalkulieren Sie den Spitzenbedarf für große Modelle, mehrere Xcode-Runtimes oder umfangreiche Videodateien vorab.

ArmMesh M4 Pro

2 TB SSD inklusive

Geeignet für große Modell-Repositories, langfristige Build-Caches, parallele Projekte und Audio-/Videoexporte. Die feste Kapazität ersetzt keine Bereinigungsstrategie: Legen Sie weiterhin Aufbewahrungsfristen für Protokolle und Artefakte fest.

Preise für Speichererweiterung und Thunderbolt 5 – Abrechnung in US-Dollar
Zusatzoption	Pro Tag	Pro Woche	Pro Monat	Pro Quartal	Geeignet für
+1 TB SSD	$2.4	$6.4	$11.9	$32.4	Für Dependency-Caches, Build-Archive oder mittelgroße Modelle, die die Basiskapazität überschreiten.
+2 TB SSD	$4.8	$12.8	$23.8	$64.8	Für große Modelle, langfristig gespeicherte Artefakte oder Audio-/Video-Workflows mit hohem Speicherbedarf.
Thunderbolt 5-Verbindung, pro Gerät	$1.2	$3.2	$5.9	$16	Klären Sie vor dem Einsatz mehrerer Geräte, wie Aufgaben aufgeteilt, Daten synchronisiert, Fehler abgefangen und Ergebnisse zusammengeführt werden.

Fünf Prüfungen vor dem Verbinden mehrerer Geräte

Lässt sich die Aufgabe in unabhängige, wiederholbare Arbeitseinheiten aufteilen?
Gibt es eine eindeutige Quelle für die Eingabedaten, und vermeiden Sie gleichzeitige Schreibzugriffe mehrerer Geräte?
Lassen sich Modell-, Dependency- und Tool-Versionen einheitlich halten?
Kann eine Aufgabe eines ausgefallenen Knotens sicher übernommen werden, ohne Ergebnisse doppelt zu erzeugen?
Werden Ausgabe-Artefakte einheitlich benannt, geprüft und zentral zusammengeführt?

Fehlerbehebung

Erst eingrenzen, dann Konfiguration ändern

Ändern Sie immer nur eine Bedingung und dokumentieren Sie vorherige und neue Ergebnisse. Wiederholte Neuinstallationen, Cache-Löschungen oder gleichzeitige Änderungen an Netzwerk und Toolchain erschweren die Ursachenanalyse.

Verbindung nicht möglich

Vom lokalen Netzwerk bis zum Knoten prüfen

Prüfen Sie die lokale Netzwerkverbindung und mögliche Proxy- oder Firewall-Blockaden.
Knotenadresse, Port und Host-Fingerabdruck erneut prüfen.
Prüfen, ob die Zugangsdaten aktualisiert wurden und beim Kopieren keine Leerzeichen enthalten sind.
Knotenstatus in der Konsole prüfen und Client-Version sowie genaue Fehlermeldung notieren.

Ungewöhnlich langsam

Latenz, Bandbreite und Knotenauslastung unterscheiden

Wiederholen Sie den Test über eine feste Netzwerkverbindung, um WLAN-Schwankungen auszuschließen.
Vergleichen Sie interaktive Latenz und Dateiübertragungsgeschwindigkeit getrennt.
Prüfen Sie, ob Builds, Synchronisierungen oder Inferenzjobs Ressourcen belegen.
Zugriffsstandort, Knotenregion, Uhrzeit und Ergebnisse mehrerer Tests dokumentieren.

Build fehlgeschlagen

Code- oder Umgebungsproblem erkennen

Commit fixieren und denselben Build-Befehl erneut ausführen.
Versionen von Xcode, SDK, Dependencies und CLI-Tools dokumentieren.
Signaturmaterial, Schlüsselbundrechte und Arbeitsverzeichnisrechte prüfen.
Temporäre Artefakte des aktuellen Projekts entfernen und erneut versuchen, nicht die gesamte Festplatte löschen.

Zu wenig Speicherplatz

Zuerst Speicherverbrauch ermitteln, dann erweitern

Belegung von Modellen, Dependency-Caches, Archiven, Protokollen und temporären Verzeichnissen getrennt erfassen.
Nach doppelten Modellen, alten Archiven und Resten nicht abgeschlossener Jobs suchen.
Nicht benötigte, erneut erzeugbare Dateien gemäß Aufbewahrungsregeln entfernen und Spitzenbedarf erneut erfassen.
Nur wenn der Spitzenbedarf den Sicherheitspuffer weiterhin überschreitet, eine SSD mit +1 TB oder +2 TB wählen.

Inferenzprozess beendet

Anfrageumfang und Speicherspitze vergleichen

Prüfen, ob der Prozess beim Start, beim Laden des Modells oder während der Anfrage beendet wurde.
Änderungen an Modellformat, Kontextlänge und Parallelität prüfen.
Speicherbelegung, Festplattenplatz und Dienstprotokolle vor dem Abbruch prüfen.
Mit einer einzelnen Anfrage die Baseline wiederherstellen und die Last schrittweise erhöhen.

Zugangsdaten ungültig

Wiederholte Anmeldeversuche stoppen und Änderungen nachvollziehen

Prüfen, ob ein interaktives oder ein Automatisierungskonto verwendet wird.
Prüfen, ob kürzlich Passwort, Schlüssel oder Zugriffsberechtigungen geändert wurden.
Alte Zugangsdaten aus Skripten und Caches entfernen und die neuen Zugangsdaten testen.
Wenn sich die Änderung nicht nachvollziehen lässt, eine Supportanfrage über die Konsole einreichen.

Support

Supportanfrage mit allen nötigen Diagnoseangaben einreichen

Technische Probleme melden Sie am besten über die Konsole, damit Bestellung und Knoten zugeordnet werden können. Wenn Sie sich nicht anmelden können, schreiben Sie eine E-Mail an support@armmesh.com.

Vor dem Absenden sechs Angaben vorbereiten

01 Bestellnummer

Geben Sie die Bestellnummer an, bei der das Problem auftritt. Sind mehrere Knoten betroffen, listen Sie alle einzeln auf, statt nur den Teamnamen zu nennen.

02 Knotenregion

Nennen Sie die verwendete Region und geben Sie an, ob das Problem einen oder mehrere Knoten betrifft.

03 macOS-Version

Geben Sie die vollständige Version und Buildnummer an. Bei Build-Problemen ergänzen Sie Xcode- und CLI-Tool-Version.

04 Zeitpunkt

Nennen Sie Zeitzone, ersten und letzten Zeitpunkt des Auftretens und geben Sie an, ob sich das Problem zuverlässig reproduzieren lässt.

05 Reproduktionsschritte

Beschreiben Sie ausgehend von einem funktionierenden Zustand die einzelnen Schritte, Eingaben, erwarteten und tatsächlichen Ergebnisse.

06 Bereinigte Protokolle

Lassen Sie Zeitstempel, Fehlercodes und Kontext stehen. Entfernen Sie Passwörter, Schlüssel, Tokens, Signaturmaterial und vertrauliche Projektdaten.

Nächster Schritt

Physischen Knoten auswählen und anhand der Checkliste prüfen

Beide Modelle sind dedizierte physische Macs, keine VMs, und können tage-, wochen-, monats- oder quartalsweise gemietet werden. Maßgeblich für die Verfügbarkeit des Knotens ist der aktuelle Status in der Konsole.

Cloud-Mac mieten Konfigurationen und Preise ansehen