VMKeep bietet dauerhaft laufende dedizierte physische Apple-Silicon-Macs statt virtueller Maschinen. Teams können Chip, Arbeitsspeicher und Toolchain festlegen und MLX-Inferenz, mobile Builds und Remote-Zusammenarbeit in wiederverwendbare Abläufe überführen.
Aufgaben für Cloud-Macs haben meist drei Merkmale: Sie benötigen macOS oder Apple Silicon, laufen über die lokale Arbeitszeit hinaus und erfordern eine feste Umgebung zur Reproduzierbarkeit. Für kurze lokale Prüfungen reicht das vorhandene Gerät möglicherweise aus.
Nutzen Sie SSH für die Entwicklung über die Befehlszeile und Automatisierung sowie VNC für die grafische macOS-Oberfläche. Code, Abhängigkeiten und lokale Dienste bleiben dauerhaft erhalten, ohne dass die Umgebung täglich neu eingerichtet werden muss.
Platzieren Sie Runner, Xcode, CocoaPods, Node.js und Abhängigkeits-Caches auf demselben physischen Knoten, damit jeder Build mit identischen Pfaden, Versionen und Berechtigungsgrenzen ausgeführt wird.
Führen Sie MLX mit klar definierter Chip- und Arbeitsspeicherkonfiguration aus und protokollieren Sie Quantisierungsversion, maximalen Speicherbedarf, Zeit bis zum ersten Token und den kontinuierlichen Durchsatz, um Abweichungen zwischen Geräten zu vermeiden.
Bei der ersten Bereitstellung müssen Sie nicht sofort eine komplexe Orchestrierung aufbauen. Prüfen Sie zunächst lokal, ob das Modell geladen wird, Anfragen beantwortet werden und der Speicherverbrauch nicht dauerhaft steigt. Erst danach sollte der Dienst für kontrollierte Aufrufer geöffnet werden.
Dokumentieren Sie Quelle, Version, Quantisierungsmethode, Kontextlänge und Prüfsumme der Modelldateien. Trennen Sie Modellverzeichnis und Servicelogik, damit Quantisierungsversionen ohne Änderung der Startlogik ausgetauscht werden können.
Fixieren Sie die Versionen von Python und MLX-Abhängigkeiten und hinterlegen Sie die Installationsliste im Repository. Führen Sie zunächst eine einzelne Inferenz über die Befehlszeile aus, um Tokenizer, Gewichtsformat und Speicherbedarf zu prüfen.
Lassen Sie den Dienst zunächst auf der lokalen Adresse lauschen und ergänzen Sie Health Checks, Anfrage-Timeouts und strukturierte Protokolle. Prüfen Sie die Antwortstruktur mit festen Prompts und beobachten Sie anschließend Zeit bis zum ersten Token und maximalen Speicherbedarf.
Öffnen Sie den Zugriff erst nach stabilen lokalen Anfragen gemäß den Netzwerkregeln des Teams. Die Aufrufer sollten Timeout, Wiederholungen und Anfrage-ID beibehalten; der Dienst protokolliert Modellversion und Inferenzparameter.
curl -X POST http://127.0.0.1:8080/infer \
-H "Content-Type: application/json" \
-d '{
"prompt": "Summarize build log",
"max_tokens": 128
}'Erfassen Sie nicht nur eine einzige Durchsatzkennzahl. Modellversion, Quantisierung, Kontextlänge, Parallelität und Aufwärmrunden verändern das Ergebnis. Frieren Sie zuerst die Testbedingungen ein und entscheiden Sie erst danach über einen Modellwechsel oder ein Upgrade.
| Erfassungsfeld | Feste Bedingung | Verwendungszweck |
|---|---|---|
| Quantisierungsversion | Dasselbe Modell und dieselbe Kontextlänge | Abwägung zwischen Genauigkeit, Speicherbedarf und Geschwindigkeit |
| Maximaler Speicherbedarf | Identische Eingabe und Parallelität | Prüfen, ob die Konfiguration ausreichend Reserven für einen stabilen Betrieb hat |
| Zeit bis zum ersten Token | Identischer Aufwärmzustand | Wartezeit interaktiver Anfragen bewerten |
| Kontinuierlicher Durchsatz | Identische Ausgabelänge | Leistung bei langen Ausgaben und Batch-Aufgaben bewerten |
| Fehlerprotokoll | Anfrage-ID und Protokolle aufbewahren | Modell-, Speicher-, Dienst- und Aufruferprobleme unterscheiden |
Der Nutzen eines festen physischen Knotens besteht nicht nur darin, Xcode ausführen zu können. Er grenzt Quellcode, Abhängigkeiten, Tests, Signaturvorgänge und Archivspeicher klar voneinander ab. Fehler lassen sich entlang der Ausführung eingrenzen, statt Umgebungsunterschiede erneut zu erraten.
Lesen Sie das angegebene Repository mit eingeschränkten Zugangsdaten aus und fixieren Sie Branch, Commit und Submodulstatus.
Installieren Sie Abhängigkeiten anhand der Lockfiles und isolieren Sie Cache-Verzeichnisse nach Projekt und Version, damit alte Caches nicht stören.
Legen Sie workspace, scheme, configuration und destination eindeutig fest und speichern Sie den vollständigen Befehl.
Protokollieren Sie Unit-, UI- und fehlgeschlagene Tests getrennt und bewahren Sie maschinenlesbare Berichte auf.
Beschränken Sie den Zugriff auf Signaturmaterial und schreiben Sie Zertifikatinhalte oder vertrauliche Zugangsdaten nicht in Build-Protokolle.
Speichern Sie Archive, Protokolle und Testberichte nach Commit und Aufgaben-ID und legen Sie eine Bereinigungsstrategie fest.
Ermitteln Sie zuerst die Fehlerphase und entscheiden Sie dann, ob Tests erneut ausgeführt, Abhängigkeiten neu erstellt oder Archive neu angelegt werden. Verwenden Sie unterschiedliche Wiederholungsstrategien für Cache-, Netzwerk- und Codefehler.
React-Native-Builds umfassen Node.js, Paketmanager, CocoaPods und Xcode. Nur JavaScript-Paketversionen zu fixieren reicht nicht aus: Auch Ruby, Pods, Xcode-Projekteinstellungen und Build-Befehle gehören in eine reproduzierbare Liste.
Fixieren Sie Laufzeit und Paketmanager und unterscheiden Sie Caches anhand des Lockfile-Fingerabdrucks.
Dokumentieren Sie Pods-Status, scheme, Build-Konfiguration und Zielgerät.
Verknüpfen Sie Commit-ID, Build-Aufgabe und Artefaktverzeichnis.
Verwalten Sie JavaScript-Paket-, Pods- und Xcode-Derived-Data-Caches getrennt. Cache-Treffer können beschleunigen, dürfen aber keine Versionsabweichungen verdecken.
Empfohlen zu erfassen: Lockfile-Zusammenfassung, Pods-Status, Xcode-VersionAutomatisierungsskripte dürfen nur die benötigten Zugangsdaten lesen. Verbergen Sie vertrauliche Inhalte in Protokollen und bereinigen Sie temporäre Dateien nach dem Build gemäß den Teamrichtlinien.
Empfohlen aufzubewahren: Commit-ID, Aufgaben-ID, ArtefaktprüfsummeBeide Verbindungsarten können denselben dedizierten physischen Mac bedienen, dienen aber unterschiedlichen Zwecken. Aktualisieren Sie nach der ersten Verbindung das Passwort, konfigurieren Sie SSH-Schlüssel und beschränken Sie die Verteilung von Zugangsdaten. Verbindungsdaten und tatsächliche Verfügbarkeit liefert die Konsole in Echtzeit.
Teams können unterschiedliche physische Knoten für Runner, Modellexperimente oder Build-Warteschlangen einsetzen. Jeder Knoten dokumentiert Aufgabenbereich, Umgebungsversion und Artefaktverzeichnis separat. Fehleranalyse und Kapazitätsplanung werden dadurch direkter als in einer gemeinsam genutzten Mischumgebung.
Abhängigkeiten, Tests und Archivierung laufen in einem festen Build-Verzeichnis.
JavaScript-, Pods- und Xcode-Derived-Data-Caches isolieren.
Chip, Arbeitsspeicher, Modellversion und Eingabebedingungen fixieren.
Alle drei Modelle sind dedizierte physische Apple-Silicon-Macs statt virtueller Maschinen. Für leichte Prüfungen steht die Kostenkontrolle im Vordergrund, bei kontinuierlichen Pipelines Cache und Parallelität; bei speicherintensiver Inferenz sollte zuerst der maximale Bedarf nach dem Laden des Modells geprüft werden.
M4 · 16GB · 256GB
Geeignet für die Entwicklung eines einzelnen Projekts, leichte iOS-Builds, MLX-Umgebungsprüfungen und Kompatibilitätstests kleiner Modelle. Bei knappem Speicher sollten Caches und Artefaktbereinigung früh geplant werden.
M4 · 24GB · 512GB
Geeignet für dauerhaft laufende Runner, Abhängigkeits-Caches mittelgroßer Projekte, kontinuierliche React-Native-Builds und MLX-Inferenzexperimente mit größerer Speicherreserve.
M4 Pro · 64GB · 2TB
Geeignet für speicherintensive MLX-Inferenz, Quantisierungsvergleiche größerer Modelle, parallele Experimente und stark ausgelastete Build-Warteschlangen. Führen Sie die Validierung zunächst mit realem Modell und realen Parallelitätsparametern durch.
Alle drei Modelle sind an den fünf genannten Knoten bestellbar. Die tatsächliche Verfügbarkeit liefert die Konsole in Echtzeit.
Wählen Sie zunächst die Konfiguration und danach Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong oder die US-Ostküste als Knoten. Legen Sie anschließend die Mietdauer pro Tag, Woche, Monat oder Quartal fest. Bestellung und Maschinenverwaltung erfolgen über die Konsole.