Dual DGX Sparks vs. Mac Studio M3 Ultra: Praktischer Vergleich für den lokalen Betrieb von Qwen3.5 397B

Hardware-Vergleich für lokales Qwen3.5 397B
Ein Entwickler gab 2.000 US-Dollar/Monat für Claude-API-Tokens aus, bevor er insgesamt 20.000 US-Dollar in lokale Hardware investierte: ein Mac Studio M3 Ultra 512GB und ein Dual-DGX-Spark-Setup, die jeweils nach Steuern etwa 10.000 US-Dollar kosteten. Beide wurden getestet, indem sie Qwen3.5 397B A17B lokal ausführten.
Leistung des Mac Studio M3 Ultra 512GB
Mit MLX-6-Bit-Quantisierung wurde das 323-GB-Modell in den 512 GB einheitlichen Arbeitsspeicher geladen. Die Generierungsgeschwindigkeit betrug 30–40 Tokens/Sekunde mit einer Speicherbandbreite von etwa 800 GB/s, wodurch sich die Token-Generierung flüssig anfühlte. Die Einrichtung war einfach: mlx vlm installieren und auf das Modell verweisen. Schwächen waren langsame Vorauffüllung (30+ Sekunden bei großen Systemaufforderungen) und Leistungsabfall beim gleichzeitigen Ausführen von Batch-Embedding neben der Inferenz. Der Entwickler musste einen 500-zeiligen asynchronen Proxy schreiben, da mlx vlm Tool-Aufrufe nicht nativ parst oder Denk-Tokens entfernt.
Leistung des Dual-DGX-Spark-Setups
Mit INT4-AutoRound-Quantisierung wurden 98 GB pro Knoten über zwei 128-GB-Knoten via vLLM TP=2 geladen. Die Generierungsgeschwindigkeit betrug 27–28 Tokens/Sekunde. Das Setup nutzte CUDA-Tensor-Cores, vLLM-Kernel und Tensor-Parallelität für schnellere Vorauffüllung als das Mac Studio. Batch-Embedding, das bei MLX Tage dauerte, wurde auf CUDA in Stunden abgeschlossen. Die Speicherbandbreite betrug etwa 273 GB/s pro Knoten, was die Generierungsgeschwindigkeit trotz mehr Rechenleistung begrenzte.
Die Einrichtungsprobleme waren erheblich: Nur ein QSFP-Kabel funktionierte (das zweite stürzte NCCL ab), die IP von Node2 war ephemer, die GPU-Speicherauslastungsgrenze lag bei 0,88 (erforderte binäre Suche), jeder falsche Versuch kostete 15 Minuten, während Checkpoint-Shards neu geladen wurden, der Page-Cache musste vor jedem Modellladen auf beiden Knoten geleert werden, und einige Einheiten drosselten thermisch innerhalb von 20 Minuten. Der Entwickler berichtete, dass es Tage dauerte, um Stabilität zu erreichen.
Architektur und Anwendungsfall
Der Entwickler behielt beide Systeme und nutzte das Mac Studio nur für Inferenz (volle 512 GB für Modell und KV-Cache) und die Sparks für RAG, Embedding, Re-Ranking und andere Aufgaben. Sie kommunizieren über Tailscale. Diese Trennung verhindert, dass Embedding-Modelle mit dem Hauptmodell um Speicher auf dem Mac Studio konkurrieren, während sie ihnen dedizierte CUDA-Ressourcen auf den Sparks geben.
Direkter Vergleich der Spezifikationen
- Kosten: Jeweils 10.000 US-Dollar
- Speicher: Mac Studio 512 GB einheitlich vs. Sparks 256 GB (128×2)
- Bandbreite: Mac Studio ~800 GB/s vs. Sparks ~273 GB/s pro Knoten
- Quantisierung: Mac Studio MLX 6-Bit (323 GB) vs. Sparks INT4 AutoRound (98 GB/Knoten)
- Generierungsgeschwindigkeit: Mac Studio 30–40 Tok/s vs. Sparks 27–28 Tok/s
- Max. Kontext: Mac Studio 256K Tokens vs. Sparks 130K+ Tokens
- Einrichtung: Mac Studio einfach, aber hands-on vs. Sparks schwierig
- Stärke: Mac Studio Bandbreite vs. Sparks Rechenleistung
- Schwäche: Mac Studio Rechenleistung vs. Sparks Bandbreite
Empfehlungen
Das Mac Studio wird empfohlen, wenn Sie möchten, dass es einfach funktioniert, 800 GB/s Bandbreite für flüssige Generierung schätzen und keine schweren Embedding-Workloads neben der Inferenz planen. Die Dual Sparks werden empfohlen, wenn Sie mit Linux und Docker vertraut sind, CUDA und vLLM nativ nutzen möchten, RAG oder Embedding neben der Inferenz ausführen möchten und bereit sind, Tage für die anfängliche Einrichtung für mehr langfristige Fähigkeiten zu investieren. Der Entwickler beschreibt das Mac Studio als 80 % der Erfahrung mit 20 % des Aufwands, während die Sparks mehr Fähigkeiten bieten, aber einen echten Preis in Einrichtungszeit fordern.
Amortisationsrechnung: 2.000 US-Dollar/Monat API-Ausgaben vs. 20.000 US-Dollar Gesamthardware entspricht 10 Monaten zur Amortisation, danach ist die Inferenz kostenlos mit vollständiger Privatsphäre.
📖 Read the full source: r/LocalLLaMA
👀 Siehe auch

Brain-MCP-Entwicklerdokumente: Werkzeuge für Claude AI statt für Menschen
Ein Entwickler, der den Brain-MCP-Server betreut, fügte der Dokumentation einen Abschnitt 'Für KI-Assistenten' mit Verhaltensanweisungen hinzu, was dazu führte, dass Claude Werkzeuge intelligenter nutzte und proaktiv Kontext einfügte, wenn Themen wechselten.

Claude Code Mastery: Open-Source-Konfigurationssystem fügt persistenter Speicher und kuratierte Fähigkeiten zur Claude Code CLI hinzu
Claude Code Mastery ist ein Open-Source-Konfigurationssystem, das persistente Speicherung über Sitzungen hinweg, intelligente Lebenszyklus-Hooks und 26+ kuratierte Fähigkeiten zur Claude Code CLI hinzufügt. Es umfasst eine 6-Dateien-Memory-Bank pro Projekt, einen Zero-Config-Launcher und plattformübergreifende Unterstützung.

Benchmark-Ergebnisse: 15 LLMs getestet an 38 realen Workflow-Aufgaben
Ein Entwickler hat 15 Cloud- und lokale LLMs anhand von 38 Aufgaben aus seinem tatsächlichen Arbeitsablauf getestet, darunter CSV-Transformationen, Buchstaben zählen, modulare Arithmetik und Formatkonformität. Claude 3.5 Sonnet und Opus erzielten beide 100 %, aber Sonnet kostet 3,5-mal weniger pro Aufruf.

Claude Code baute SaaS-Onboarding-Flow in 6 Stunden um vs. Entwicklerangebot von 3 Wochen, steigerte Aktivierung um 13 Punkte
Ein SaaS-Gründer hat mit Claude Code den gesamten Onboarding-Flow (Anmeldung → Profil → erste Rechnung → Dashboard-Tutorial) in 6 Stunden neu aufgebaut, statt der 3-Wochen-4.500$-Schätzung eines Entwicklers. Die Aktivierungsrate stieg um 13 Punkte von 35% auf 48%.