Handbuch zur Nutzung des Cloud-Macs

Von Bestellfeldern bis zu Build-Logs: Probleme nach Aufgabe lösen

Sie müssen nicht zuerst das gesamte Handbuch lesen. Öffnen Sie das passende Kapitel für Ihre aktuelle Aufgabe und prüfen Sie Laufzeit, Knoten, Verbindungsdaten, Entwicklungsumgebung und Protokolle. Wenn das Problem weiter besteht, fügen Sie den vollständigen Kontext Ihrem Konsolen-Ticket hinzu.

Cloud-Mac jetzt mieten Schnellstart anzeigen

5 Aufgabenkategorien 2 Konfigurationen im Angebot 5 verfügbare Knoten

RUN SHEET

Prüfreihenfolge für die erste Nutzung

Unterlagen bereit

Bestellung prüfen Modell, Laufzeit, Knoten und zusätzlicher Speicher

ORDER

Verbindung bestätigen Adresse, Konto, lokales Netzwerk und Zugangsdaten

ACCESS

Toolchain vorbereiten Xcode, Kommandozeilentools, Abhängigkeiten und Cache

BUILD

Diagnosedaten sichern Zeitpunkt, Originalfehlermeldung und bereinigte Logs

TRACE

Exklusiver physischer Apple-Silicon-Knoten 365 TAGE

Mit der aktuellen Aufgabe beginnen

Sagen Sie uns zuerst, an welchem Schritt Sie festhängen

Geben Sie Aufgabe, Statusfeld oder Fehlerbild ein. Die Suchergebnisse führen direkt zur passenden Checkliste auf dieser Seite. Sie können auch mit einer der fünf Kategorien beginnen und müssen die Kapitel nicht der Reihe nach lesen.

Bestell- und Instanzfelder

Prüfen Sie zuerst, was die Bestellung festlegt, und beurteilen Sie dann, ob die Instanz fehlerhaft ist

Die Bestellung legt Chip, Arbeitsspeicher, Speicher, Knoten und Mietzeitraum fest. Statusfelder in der Konsole beschreiben die aktuelle Bereitstellungs- oder Betriebsphase. Beides darf nicht verwechselt werden. Die tatsächliche Verfügbarkeit kombinierter Optionen richtet sich nach der aktuellen Rückmeldung der Konsole.

Bestellung prüfen

Fünf Feldgruppen müssen einzeln übereinstimmen

ORDER PROFILE

Mietzeitraum: Abrechnung nach Tag, Woche, Monat oder Quartal. Prüfen Sie den aktuellen Zeitraum und die Projektdauer. Beträge aus unterschiedlichen Zeiträumen dürfen nicht in dasselbe Budget einfließen.
Physischer Knoten: Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong und US-Ostküste – insgesamt 5 Knoten. Berücksichtigen Sie vor allem Zugriffswege des Teams, Speicherort des Codes und Datenflüsse.
Basiskonfiguration: ArmVMS M4 umfasst M4, 16 GB RAM und 256 GB SSD; ArmVMS M4 Pro umfasst M4 Pro, 64 GB RAM und 2 TB SSD.
Zusätzliche Optionen: Prüfen Sie +1 TB SSD, +2 TB SSD oder Thunderbolt 5 im Parallelbetrieb separat. Stellen Sie sicher, dass Zusatzoption und Basiskonfiguration im selben Bestellzeitraum erscheinen.
Zahlungsarten: Unterstützt werden ausschließlich USDT-TRC20 sowie Visa / Mastercard / Amex (über Stripe). Die Abrechnung erfolgt vollständig in US-Dollar (USD); maßgeblich sind die vom Backend zurückgegebenen verfügbaren Zahlungsgateways.

Häufige Statusangaben

In Bearbeitung und verbindungsbereit

„In Bearbeitung“ bedeutet in der Regel, dass die Bestelldaten noch bereitgestellt werden; „verbindungsbereit“ bedeutet, dass die Verbindungsdaten erstellt wurden. Aktualisieren Sie nach einer Statusänderung zuerst die Bestelldetails und verwenden Sie dann die neuesten Verbindungsfelder auf der Detailseite.

Grundprinzip

Eine korrekte Bestellung bedeutet nicht, dass die Umgebung bereit ist

Prüfen Sie nach Konfiguration und Knoten auch Systemkonto, freien Speicher, Xcode-Version und Projektabhängigkeiten. Probleme der Umgebung sollten nicht durch wiederholtes Erstellen von Bestellungen gelöst werden.

Konfiguration und Preis prüfen

Übliche Felder der Verwaltungskonsole und Prüfschritte
Feld	Bedeutung	Zu prüfen	Bei Abweichungen dokumentieren
ORDER ID	Eindeutige Zuordnungskennung der Bestellung	Ob Ticket, Rechnung und Instanz dieselbe Nummer verwenden	Vollständige Bestellnummer
REGION	Region des physischen Knotens	Ob sie mit dem bei der Bestellung gewählten Knoten übereinstimmt	Knotencode und sichtbarer Name
TERM	Aktueller Mietzeitraum	Tag, Woche, Monat oder Quartal einschließlich Beginn und Ende	Name des Zeitraums und Bestell-Screenshot
ACCESS	Ob die Verbindungsdaten erstellt wurden	Ob Adresse, Konto und Verbindungsmethode vollständig sind	Name des fehlenden Feldes
STATE	Aktuelle Betriebsphase der Instanz	Ob sich der Status nach der Aktualisierung ändert und die Verbindung wiederhergestellt ist	Originalstatus und Zeitpunkt des Auftretens

Dokumentation zur Entwicklungsumgebung

Erst reproduzierbar bauen, dann weiter beschleunigen

Beim Umzug auf einen Cloud-Mac sollten Sie zuerst Toolchain, Abhängigkeiten und Projektpfade konsistent wiederherstellen. Kopieren Sie nicht sofort die gesamte alte Umgebung. Bauen Sie sie zunächst anhand einer Checkliste neu auf, um Architekturinkompatibilitäten, veraltete Pfade und verunreinigte Caches zu vermeiden.

Xcode-Projekt vorbereiten

Notieren Sie die erforderliche Xcode-Hauptversion, den Einstiegspunkt von Projekt oder Workspace, das Build-Scheme, die Zielplattform und die minimale Systemversion. Lösen Sie nach dem ersten Öffnen zunächst die Abhängigkeiten auf und führen Sie anschließend einen vollständigen Build aus.

Prüfen, ob Projektdateien und Submodule vollständig sind
Prüfen, ob das Scheme für Builds über die Kommandozeile geeignet ist
Signierungskonfiguration und Codeversion getrennt prüfen

Kommandozeilentools

Bestätigen Sie zunächst das aktuell ausgewählte Entwicklerverzeichnis und prüfen Sie anschließend Compiler, Versionsverwaltung und Skriptinterpreter. Automatisierte Aufgaben sollten tatsächliche Toolpfade und Versionen ausgeben, damit interaktive Sitzung und Runner nicht unterschiedliche Umgebungen verwenden.

Aktuelle Xcode-Auswahl dokumentieren
Sicherstellen, dass Initialisierungsdateien der Shell keine interaktive Eingabe blockieren
Für Skripte eindeutige Pfade oder kontrollierte Umgebungsvariablen verwenden

Abhängigkeitsverwaltung

Stellen Sie Abhängigkeiten bevorzugt aus Lockfiles und Softwarelisten wieder her. Prüfen Sie nach der Installation Apple-Silicon-Architektur, Binärquellen und Pfade der Befehlsauflösung. Gehen Sie nicht davon aus, dass vorkompilierte Dateien der alten Umgebung weiterhin passen.

Lockfiles und Installationsprotokolle aufbewahren
Prüfen, ob Skripte alte Maschinenpfade fest eintragen
Zugangsdaten privater Abhängigkeiten in kontrollierten Variablen ablegen

Build-Cache

Im Cache dürfen nur reproduzierbare Daten liegen. Validieren Sie die Basis zunächst mit einem Build ohne Cache und stellen Sie anschließend Abhängigkeits-Cache und abgeleitete Daten schrittweise wieder her. Bei unerklärlichen Build-Abweichungen löschen Sie bevorzugt den Cache der aktuellen Aufgabe, nicht alle Projektdaten.

Abhängigkeits-Cache, Compiler-Cache und endgültige Artefakte unterscheiden
Cache-Schlüssel müssen Toolchain- und Abhängigkeitsversion enthalten
Cachegröße und freien Speicher regelmäßig prüfen

CI/CD-Integration

Verwenden Sie den Runner wie einen prüfbaren physischen Knoten

Automatisierte Aufgaben sollten erkennen lassen, wer sie ausgelöst hat, welche Codeversion verwendet wird, welche Zugangsdaten gelesen werden, welche Artefakte entstehen und was nach Abschluss bereinigt wurde. Exklusive Ressourcen verringern Konkurrenz, ersetzen aber nicht die Berechtigungssteuerung der Pipeline.

01

Minimale Zugangsdaten injizieren

Teilen Sie Zugangsdaten nach Repository, Abhängigkeitsquelle und Verteilziel auf und vergeben Sie nur die für die aktuelle Aufgabe erforderlichen Rechte. Über kontrollierte Variablen zuführen, niemals in Repository, Build-Skripte oder Logs schreiben.

CREDENTIALS
02

Ausführungskontext festlegen

Dokumentieren Sie Commit-Version, Branch, Scheme, Zielplattform, Xcode-Version und Abhängigkeitszusammenfassung. Parallele Aufgaben verwenden eigene Arbeitsverzeichnisse, damit gemeinsame abgeleitete Daten nicht überschrieben werden.

CONTEXT
03

Nachvollziehbare Artefakte exportieren

Archive, Testberichte, Symboldateien und Build-Logs müssen eine Aufgabenkennung tragen; prüfen Sie vor dem Export ihre Vollständigkeit. Auch fehlgeschlagene Aufgaben müssen ausreichend Logs zur Analyse hinterlassen.

ARTIFACTS
04

Aufgabenumgebung bereinigen

Entfernen Sie temporäre Zugangsdaten, gemountete Dateien, temporäre Arbeitsbereiche und nicht mehr benötigte Zwischenartefakte. Langfristig wiederverwendete Caches gehören in das vorgesehene Verzeichnis und dürfen nicht mit Quellcode oder vertraulichen Daten vermischt werden.

CLEANUP

Leitfaden für KI-Experimente

Modell, Speicher und Sitzung planen, bevor Sie lange Aufgaben starten

Bei KI-Experimenten liegen die größten Risiken meist nicht im Startbefehl, sondern in doppelten Modelldateien, wachsendem Speicherbedarf, unterbrochenen Sitzungen und nicht rechtzeitig exportierten Ergebnissen. Legen Sie vor Beginn klare Datengrenzen fest, damit der Speicher nicht erst mitten in der Aufgabe knapp wird.

Kapazitätsplanung

Modelldateien in drei Verzeichnisebenen organisieren

SOURCE Originalmodell

Quelle, Version, Lizenzinformationen und Prüfsummenübersicht aufbewahren. Originaldateien nur einmal speichern, damit sie nicht in verschiedenen Experimentverzeichnissen dupliziert werden.

CACHE Reproduzierbarer Cache

Download-, Konvertierungs- und temporäre Fragment-Caches in ein eigenes Verzeichnis legen. Bei knappem Speicher können sie gelöscht und neu erstellt werden.

OUTPUT Experimentergebnisse

Checkpoints, Kennzahlen, Logs und exportierte Dateien nach Aufgabennummer archivieren und nach Abschluss an einen langfristigen Speicherort verschieben.

Sitzungen für lange Aufgaben

Trainings-, Konvertierungs- oder Batch-Inferenzaufgaben sollten unabhängig von temporären grafischen Sitzungen laufen. Dokumentieren Sie nach dem Start Prozesskennung, Arbeitsverzeichnis, Logpfad und Wiederherstellungsmethode. Testen Sie anschließend, ob die Aufgabe nach einer Verbindungsunterbrechung weiterläuft.

Logs fortlaufend in eine Datei schreiben
Für Checkpoints eindeutige Intervalle verwenden
Wachstumsspielraum im Ausgabeverzeichnis einplanen

Sicherungsgrenzen

Code, Informationen zur Modellquelle, nicht reproduzierbare Checkpoints und endgültige Ergebnisse benötigen separate Sicherungen. Download-Caches, temporäre Fragmente und reproduzierbare Zwischendateien sollten nicht dieselben Sicherungsressourcen beanspruchen.

Auswahl für KI-Workloads besprechen

Entscheidungsbaum zur Fehlerbehebung

Schicht für Schicht prüfen und nicht mehrere Variablen gleichzeitig ändern

Ändern Sie nach jeder Prüfschicht nur eine Bedingung und dokumentieren Sie das Ergebnis. Netzwerk, Zugangsdaten, System, Speicher und Build-Logs folgen einer klaren Reihenfolge. Werden Vorprüfungen übersprungen, werden Verbindungsprobleme leicht fälschlich der Entwicklungsumgebung zugerechnet.

Kann das lokale Netzwerk die Verbindungsadresse erreichen?

Prüfen Sie, ob die Adresse vollständig ist, ob das aktuelle Netzwerk die betreffende Verbindung einschränkt und ob das Verhalten nach einem Netzwerkwechsel gleich bleibt. Dokumentieren Sie Client-System, Netzwerktyp und Zeitpunkt des Fehlers.

Fehlgeschlagen Adressfelder und Originaltext des Netzwerkfehlers aufbewahren

Stammen die Verbindungsdaten aus den aktuellen Bestelldetails?

Öffnen Sie die Bestelldetails in der Konsole erneut und prüfen Sie Konto, Adresse und Eingabemethode für Zugangsdaten Zeichen für Zeichen. Verwenden Sie keine alten Screenshots, Browserverläufe oder Verbindungsdaten anderer Instanzen.

Fehlgeschlagen Fehlende Felder dokumentieren, Zugangsdaten nicht im Original einreichen

Erlaubt der Instanzstatus den Aufbau einer Sitzung?

Aktualisieren Sie die Instanzdetails und prüfen Sie, ob sich das Statusfeld ändert. Stimmen Status und tatsächliches Verbindungsergebnis nicht überein, dokumentieren Sie Bestellnummer, Knoten, Originalstatus und Zeitpunkt der ersten Feststellung.

Abweichung Statusfelder und Schritte zur Reproduktion einreichen

Ist ausreichend Arbeitsbereich auf dem Datenträger vorhanden?

Prüfen Sie Projektverzeichnis, abgeleitete Daten, Abhängigkeits-Cache, Modelldateien und temporäre Artefakte. Nach Bestätigung des Speicherproblems löschen Sie bevorzugt reproduzierbare Caches. Löschen Sie keine noch nicht exportierten Build-Ergebnisse.

Nicht ausreichend Gesamtmenge, verfügbare Menge und wichtigste Verzeichnisse dokumentieren

Lässt sich der erste echte Fehler im Build-Log finden?

Suchen Sie vom Exit-Status der Aufgabe rückwärts nach dem ersten Fehler und schneiden Sie nicht nur die letzte Zeile aus. Bewahren Sie Befehl, Toolchain-Version, Commit-Version und Fehlerkontext auf und entfernen Sie Tokens, private Schlüssel sowie andere vertrauliche Daten.

Nicht gelöst Bereinigte Logs zusammenstellen und ein Ticket einreichen

Support eskalieren

Wenn Sie das Problem nicht selbst lösen können, senden Sie einen Kontext, mit dem die Analyse direkt beginnen kann

Bei Problemen zu bestehenden Bestellungen verknüpfen Sie die Bestellung bevorzugt über ein Konsolen-Ticket. Bei Fragen zur Konfiguration vor dem Kauf oder wenn Sie die Konsole nicht öffnen können, senden Sie eine E-Mail an support@armvms.com. Ergänzen Sie Informationen in derselben Sitzung, statt für dasselbe Problem wiederholt Anfragen zu erstellen.

Erforderliche Angaben

Bestell- und Knoteninformationen

Geben Sie die vollständige Bestellnummer, den Knotennamen, die Basiskonfiguration und Zusatzoptionen an. Betrifft das Problem eine bestimmte Instanz, nennen Sie das aktuelle Statusfeld aus der Konsole.

Zeitpunkt und Reproduktion

Ersten Fehlversuch beschreiben

Nennen Sie Zeitpunkt, Arbeitsschritte, erwartetes und tatsächliches Ergebnis. Bei mehreren Versuchen geben Sie an, welche Bedingungen geändert wurden und welche unverändert blieben.

Diagnoseanhänge

Originalfehler und bereinigte Logs anhängen

Kopieren Sie die vollständige Fehlermeldung und fügen Sie relevante Build-Schritte samt Kontext hinzu. Screenshots sollten Feldnamen zeigen, müssen aber sämtliche vertraulichen Zugangsdaten und Projektheimnisse verdecken.

Wie ergänze ich nach dem Einreichen neue Logs oder Reproduktionsergebnisse?

Antworten Sie im selben Ticket oder E-Mail-Verlauf und nennen Sie Zeitpunkt des neuen Tests, geänderte Bedingung und Ergebnis. So kann das Serviceteam die Zeitlinie vergleichen, ohne den Kontext neu aufzubauen.

Wann sollte ich bevorzugt ein Konsolen-Ticket verwenden?

Bei bestehenden Bestellungen – etwa zu Bestellstatus, Rechnung, Knoten, Instanzverbindung oder Bereitstellungsfeldern – sollten Sie bevorzugt ein Konsolen-Ticket verwenden. Es lässt sich mit der Bestellnummer verknüpfen und reduziert Rückfragen.

Welche Informationen werden für eine Beratung vor dem Kauf benötigt?

Nennen Sie Projekttyp, Anzahl paralleler Aufgaben, benötigte Xcode-Umgebung, voraussichtlichen Speicherbedarf, Mietzeitraum und Zielknoten. Bei großen Projekten oder Inferenz großer Modelle sind Spitzenbedarf an Arbeitsspeicher und Größe der Modelldateien besonders hilfreich.

Unterlagen für die Fehlerbehebung vorbereiten

Ticket mit verknüpfter Bestellung einreichen, damit das Problem direkt im richtigen Kontext landet

Fügen Sie Bestellnummer, Knoten, Zeitpunkt, Reproduktionsschritte und bereinigte Logs hinzu. Für eine Beratung vor dem Kauf können Sie zunächst die zwei Konfigurationen ansehen und anschließend Projektdauer sowie Ressourcenbedarf angeben.

In der Konsole anmelden und Ticket einreichen Serviceteam kontaktieren