Berry M4
- Chip
- M4
- Arbeitsspeicher
- 16GB
- Speicher
- 256GB
Cloud-Mac nach Aufgabe wählen
Übertrage Entwicklungs-, Build- und Experimentieraufgaben
Übertrage Entwicklungs-, Build- und Experimentieraufgaben
an einen dedizierten physischen Mac
BerryVM stellt dedizierte physische Mac-mini-Knoten bereit, keine virtuellen Maschinen. Installiere Projektabhängigkeiten, führe Xcode und die Swift-Toolchain aus, übernimm kontinuierliche Builds oder evaluiere MLX-Workloads auf einer Konfiguration mit viel Arbeitsspeicher.
Prüfe zuerst Softwarekompatibilität, Speicherbedarf, Aufgabendauer und Zielknoten. Wähle anschließend Berry M4 oder Berry M4 Pro. Zugriffe, Projektzugangsdaten und Signaturmaterialien sollten weiterhin nach den Sicherheitsprozessen deines Teams verwaltet werden.
- Servicemodell
- Gesamtes Gerät exklusiv
- Verfügbare Konfigurationen
- 2
- Verfügbare Knoten
- 5
WORKLOAD ACCEPTANCE
Aufgabenbatch-Abnahme
BATCH / DEV-05
Eingabe
Code, Abhängigkeiten, Build-Parameter
Bereit zur Konfiguration
Ausführung
Xcode / Swift / Runner / MLX
Exklusiver Knoten
Ausgabe
Build-Artefakte, Logs, Experimentergebnisse
Prozesskonform geliefert
Berry M4 Pro
- Chip
- M4 Pro
- Arbeitsspeicher
- 64GB
- Speicher
- 2TB
Knoten im Verzeichnis normalerweise buchbar
Der tatsächlich verfügbare Status wird in Echtzeit von der Konsole zurückgegeben
iOS- und macOS-Entwicklung
Einen Remote-Mac in eine reproduzierbare Entwicklungsumgebung verwandeln
Geeignet für Entwickler, die eine vollständige macOS-Oberfläche und Kommandozeile benötigen, lokale Geräte entlasten möchten oder eine einheitliche Toolchain im Team voraussetzen.
Entwicklungsumgebung
Xcode- und Swift-Projekte
Installiere die vorgegebene Xcode-Version, die Command-Line-Tools und Swift-Abhängigkeiten und führe anschließend zunächst einen sauberen Build aus. Lege Derived Data, Paket-Cache und Projektartefakte in eindeutig benannten Verzeichnissen ab, damit verschiedene Branches oder Toolchains keine nicht nachvollziehbaren temporären Zustände gemeinsam verwenden.
- Projektprüfung:Projekt, Workspace, Scheme, minimale Systemversion und Build-Ziel prüfen.
- Abhängigkeitsprüfung:Versionen und Lock-Dateien von Swift Package Manager, CocoaPods oder anderen Abhängigkeitstools festschreiben.
- Signaturvorbereitung:Nur für die Aufgabe benötigtes Signaturmaterial übertragen, Dateirechte beschränken und die verantwortliche Person für Aktualisierungen dokumentieren.
- Zusammenarbeit:Übergabe über Code-Repository, Artefakt-Repository und bereinigte Logs; Änderungsbeschreibungen nicht durch Chatverläufe ersetzen.
Diese 5 Punkte nach der Bereitstellung prüfen
- Geräteinformationen
- Modell, Arbeitsspeicher und Speicher entsprechen der Bestellung
- Systemtools
- Terminal, Git und grundlegende Netzwerkfunktionen verfügbar
- Entwicklungstools
- Xcode entspricht den Projektanforderungen
- Festplattenplanung
- Quellcode, Cache und Artefakte getrennt speichern
- Remote-Sitzung
- Bild, Tastatur und Wiederherstellung nach Verbindungsabbruch funktionieren wie erwartet
CI/CD-Builds
Build-Knoten nach Warteschlange, Cache und Logs planen
Kontinuierliche Builds sind nicht erledigt, sobald der Runner installiert ist. Ob ein Knoten stabil wiederverwendbar ist, hängt von Aufgabentrennung, Cache-Invalidierung, Log-Aufbewahrung und der Art der parallelen Skalierung ab.
RUNNER CONTROL
Build-Batch / IOS-RELEASE
Knoten bereit
QUEUE
Anzahl gleichzeitig laufender Aufgaben steuern
Zuerst seriell
Beginne mit einer einzelnen Warteschlange und dokumentiere Änderungen bei CPU, Arbeitsspeicher, Speicher und Build-Dauer. Füge parallele Aufgaben erst später über zusätzliche Geräte hinzu, statt einen einzelnen Knoten unkontrolliert zu überladen.
CACHE
Cache nachvollziehbar und invalidierbar machen
Schlüsselbasiert bereinigen
Der Cache-Schlüssel sollte mindestens Toolchain-Version, Abhängigkeits-Lock-Datei und Zielplattform enthalten. Bei sinkender Trefferquote oder fehlerhaften Abhängigkeiten kannst du den betroffenen Batch ermitteln und bereinigen, statt das gesamte Gerät zu löschen.
LOGS
Für die Reproduktion ausreichende Logs aufbewahren
Zuerst bereinigen
Aufgabenkennung, Commit-Version, Toolchain-Version, Startzeit, Endstatus und Fehlerphase speichern. Vor dem Upload Token, Schlüssel und sensible Projektfelder entfernen.
SCALE
Parallelität über Geräte skalieren
Nach Knoten skalieren
Wenn die Wartezeit in der Warteschlange zum Engpass wird, übernimm neue Runner mit zusätzlichen dedizierten Knoten. Pflege für jedes Gerät eigene Labels und Arbeitsverzeichnisse, damit Aufgaben nicht in der falschen Umgebung landen.
React-Native-Builds
JavaScript- und native Build-Kette getrennt prüfen
React-Native-Builds hängen gleichzeitig von JavaScript-Paketen, nativen Modulen, dem Xcode-Projekt und der Signaturkonfiguration ab. Eine Prüfung nach Ebenen grenzt Probleme leichter ein als wiederholte Neuinstallationen der Umgebung.
Quellcode und Abhängigkeitseinstieg festschreiben
Prüfe Node.js, Paketmanager, Lock-Dateien und den Zugriff auf private Abhängigkeiten. Stelle vor der Installation sicher, dass das Arbeitsverzeichnis sauber ist, damit lokal verbliebene Module nicht fälschlich als reproduzierbare Abhängigkeiten gelten.
- Node.js- und Paketmanager-Version dokumentieren
- Die eingecheckte Abhängigkeits-Lock-Datei verwenden
- Lesezugriff auf Zugangsdaten privater Quellen beschränken
Native Module prüfen
Stelle sicher, dass Pods, Swift-Pakete und eigene native Module mit der Zielversion von Xcode kompatibel sind. Prüfe JavaScript- und native Ebene nach Abhängigkeitsupdates getrennt, statt beide Fehlerarten in einem Build zu vermischen.
- iOS-Deployment-Ziel prüfen
- Kompilierungseinstellungen nativer Module prüfen
- Ausgabe der Abhängigkeitsinstallation dokumentieren
Xcode-Build ausführen
Verwende ein eindeutig festgelegtes Projekt, Scheme, Configuration und Exportparameter. Verknüpfe Build-Logs und Artefaktverzeichnis mit derselben Aufgabenkennung, damit sich die genaue Fehlerphase nachvollziehen lässt.
- Debug- und Release-Konfiguration unterscheiden
- Bereinigte Logs der Fehlerphase aufbewahren
- Integritätsprüfung der Artefakte durchführen
Artefakte und Dokumentation ausliefern
Lade Build-Artefakte an einen vom Team freigegebenen Speicherort und ergänze Commit-Version, Toolchain-Version und Build-Ergebnis. Hinterlege langfristige Zugangsdaten weder in Artefakten noch in gewöhnlichen Logs.
- Nachvollziehbare Artefaktnamen erzeugen
- Commit-Version und Build-Batch verknüpfen
- Zwischendateien nach internen Regeln bereinigen
MLX und KI-Experimente
Zuerst den Speicherbedarf berechnen, dann die Konfiguration mit viel Arbeitsspeicher wählen
Die Konfiguration mit viel Arbeitsspeicher bietet M4 Pro, 64GB Arbeitsspeicher und 2TB Speicher. Sie eignet sich besser für lokale Inferenz, das Laden von Modellen und Experimente mit höherem Speicherbedarf. Ob sie passt, hängt dennoch von Modell, Präzision, Kontextlänge und Parallelität ab.
Aufgaben mit hohem Speicherbedarf
Aufgaben, die sich mit Berry M4 Pro zuerst evaluieren lassen
Modellladeprüfung
Modellformat, Quantisierung, Abhängigkeitsversionen und tatsächlichen Speicherverbrauch prüfen.
Lokale Inferenzexperimente
Prompt, Kontextlänge, Batch-Einstellungen und Ergebnisse dokumentieren, um reproduzierbare Experimente aufzubauen.
Datenvorverarbeitung
Rohdaten, Zwischendateien und Modell-Cache trennen, damit unsichtbare temporäre Dateien den Speicher nicht vollständig belegen.
Mehrere Parametervergleiche
Pro Runde nur klar definierte Variablen ändern und Spitzenspeicher, Abschlussstatus sowie Fehlerinformationen dokumentieren.
Kapazitätsberechnung nicht durch das Modell ersetzen
Validiere die Ausführung zuerst mit einer kleinen Stichprobe. Entscheide anhand des tatsächlichen Spitzenspeichers und Speicherverbrauchs über die Laufzeit. Modelldateien, Datensätze, Cache und Ergebnisse müssen in die Kapazitätsplanung einfließen.
- Modellparameter
- Version, Format und Quantisierung dokumentieren
- Ausführungskontext
- Länge, Batch und Parallelität prüfen
- Spitzenspeicher
- Nach tatsächlicher Aufgabenmessung beurteilen
- Speicherkapazität
- Modell, Daten und Cache gemeinsam berechnen
- Ergebnisübergabe
- Export- und Bereinigungspfad frühzeitig planen
Vorbereitung für Remote-Debugging
Cloud-Mac und externe Testgeräte haben jeweils einen eigenen Zuständigkeitsbereich
Der Cloud-Mac kann Entwicklungstools ausführen, Projekte bauen und hostseitige Logs sammeln. Anbindung externer Testgeräte, Netzwerkerreichbarkeit und Vorgänge auf dem Gerät bleiben jedoch Aufgabe deiner Testumgebung.
Netzwerkpfad
Zuerst stabile Kommunikation zwischen beiden Seiten nachweisen
Dokumentiere Cloud-Knoten, Netzwerk der externen Geräte, erforderliche Ports und Verbindungsrichtung. Prüfe zuerst grundlegende Konnektivität und Sitzungsstabilität, bevor du mit dem Debugging auf Anwendungsebene beginnst.
Zugangsdaten und Signaturen
Nur die für die Aufgabe erforderlichen Berechtigungen bereitstellen
Schlüssel, Token und Signaturmaterial nach Projekt trennen, den Lesezugriff beschränken und die Zuständigkeit für Aktualisierungen festlegen. Zugangsdaten gehören weder in Code-Repositories noch in Buildskript-Ausgaben oder gewöhnliche Supportanfragen.
Logsicherheit
Kontext bewahren, Geheimnisse entfernen
Logs sollten Aufgabenkennung, Zeit, Reproduktionsschritte und Fehlerphase enthalten. Entferne vor der Übergabe an das Supportteam Zugangsdaten, private Adressen, Nutzerdaten und irrelevante Projektinhalte.
Zuordnung von Szenario und Konfiguration
Nach Arbeitsspeicher, Speicher und Aufgabendauer wählen
Beide Konfigurationen sind dedizierte physische Mac-mini-Knoten. Für leichte Builds und alltägliche Entwicklung zuerst Berry M4 prüfen; für Experimente mit hohem Speicherbedarf, lokale Inferenz und größere Arbeitsmengen zuerst Berry M4 Pro prüfen.
| Workload | Zuerst prüfen | Verzeichnisspezifikation | Auswahlgrund | Vor der Bestellung prüfen |
|---|---|---|---|---|
| Swift-Alltagsentwicklung und Projektpflege | Berry M4 | M4 / 16GB / 256GB | Geeignet für Toolchain-Einrichtung, Codebearbeitung, normale Kompilierung und Einzelaufgabenprüfung. | Projektgröße, Abhängigkeits-Cache und Derived Data. |
| Leichte iOS- und macOS-Builds | Berry M4 | M4 / 16GB / 256GB | Geeignet, um zunächst eine reproduzierbare Pipeline aufzubauen und bei wachsendem Warteschlangendruck zusätzliche Knoten hinzuzufügen. | Spitzenspeicher, Cache-Strategie und Länge der Build-Warteschlange. |
| React-Native-Cloud-Builds | Berry M4 | M4 / 16GB / 256GB | Geeignet zur Prüfung von JavaScript-Abhängigkeiten, nativen Modulen und Xcode-Buildkette. | Anzahl nativer Module, Artefaktgröße und Zahl paralleler Aufgaben. |
| Xcode-Workspace mit hohem Speicherbedarf | Berry M4 Pro | M4 Pro / 64GB / 2TB | Mehr Arbeitsspeicher und Speicherplatz eignen sich für größere Arbeitsmengen, Caches und Artefaktverzeichnisse. | Tatsächlicher Spitzenspeicher, Speicherwachstum und Mietdauer. |
| MLX-Inferenz und Experimente lokal | Berry M4 Pro | M4 Pro / 64GB / 2TB | Geeignet für das Laden von Modellen, höheren Speicherbedarf und die Dokumentation mehrerer Experimentierrunden. | Modellformat, Quantisierung, Kontextlänge und Spitzenspeicher. |
Klare Aufgabengrenzen, kleinere Arbeitsmenge
Geeignet für alltägliche Entwicklung, leichte Builds, Abhängigkeitsmigration und einen Runner mit einzelner Warteschlange. Wenn Arbeitsspeicher oder Speicher dauerhaft zum Engpass werden, auf eine größere Konfiguration wechseln.
Höherer Speicherbedarf, größere Arbeitsmenge
Geeignet für größere Xcode-Workspaces, MLX-Experimente, lokale Inferenz und umfangreichere Cache-Verzeichnisse. Kapazität weiterhin anhand des tatsächlichen Modells und der Aufgabenparameter prüfen.
Letzte Prüfung vor Aufgabenstart
Sind Konfiguration, Laufzeit, Knoten und Datenpfade bestätigt?
Wähle die tatsächlich benötigte Laufzeit nach Tag, Woche, Monat oder Quartal. Prüfe vor der Bestellung Berry M4 oder Berry M4 Pro, mögliche Knoten, zusätzlichen Speicher, den Spitzenspeicher der Aufgabe sowie die Übergabe von Build-Artefakten und Experimentdaten.