Warum Mac Studio Cluster? Unsere Hardware-Entscheidung für KI im Mittelstand

Erstmal die Grundlagen

Wenn ein LLM eine Antwort generiert, läuft ein Autoregressive Inference Loop: Das Modell produziert Token für Token, und bei jedem Step müssen sämtliche Weights im schnellen Speicher liegen. Bei einem 70B Modell in FP16 sind das rund 140 GB. Liegt auch nur ein Teil davon auf der SSD oder im langsamen RAM, geht die Performance in den Keller.

Wie Transformer Inference abläuft

Du kennst das vermutlich, aber der Vollständigkeit halber: Ein Transformer wie Llama 3 70B hat 80 Layer. Bei jedem generierten Token durchläuft der gesamte Context alle Layer sequentiell. Pro Layer passiert Self-Attention (Q/K/V Projections, Softmax, Output Projection) und danach ein FFN Block mit zwei großen Matrix Multiplications.

Der Ablauf bei jedem einzelnen Token:

Input Tokens
  ↓
Embedding Lookup
  ↓
┌───────────────────────────────┐
│  Layer 1..80 (repeat)         │
│                               │
│  ├── Self-Attention           │
│  │   ├── Q, K, V Projection  │
│  │   ├── Attention Scores     │
│  │   └── Output Projection    │
│  │                            │
│  └── Feed-Forward Network     │
│      ├── Up Projection        │
│      └── Down Projection      │
└───────────────────────────────┘
  ↓
Logits → Softmax → Sample Next Token
  ↓
Append to Context → Repeat

Das Bottleneck ist nicht die Berechnung selbst, sondern das Laden der Weights aus dem Memory in die Compute Units. Bei Batch Size 1 (dem typischen Chat-Szenario) ist die GPU die meiste Zeit damit beschäftigt, Daten zu fetchen. Die eigentlichen FLOPs sind in Sekundenbruchteilen erledigt, aber die Memory Bandwidth limitiert, wie schnell die Weights nachgeliefert werden können.

Deshalb ist bei Inference die Memory Bandwidth die entscheidende Metrik, nicht die TFLOPS.

Das Problem mit klassischen GPU Servern

NVIDIA GPUs lösen das mit dediziertem HBM direkt auf dem Package. Schnell, aber begrenzt:

Ein 70B Modell in FP16 passt auf keine einzelne Consumer GPU. Selbst auf einer H100 wird es mit KV-Cache eng. Die Datacenter-Lösung ist Tensor Parallelism über NVLink: Du verteilst das Modell auf 2, 4 oder 8 GPUs. Funktioniert hervorragend, kostet aber entsprechend.

Das eigentliche Architektur-Problem

In einem typischen Server stecken neben den GPUs auch 256 bis 512 GB DDR5 System-RAM. Der liegt während der Inference komplett brach, weil CPU und GPU über PCIe getrennt sind:

┌────────────────────┐            ┌────────────────────┐
│        CPU         │            │        GPU         │
│                    │            │                    │
│   256 GB DDR5      │◄── PCIe ──►   80 GB HBM3       │
│   (ungenutzt)      │   64 GB/s  │   (Bottleneck)     │
└────────────────────┘            └────────────────────┘

Die GPU kann nicht direkt auf den System-RAM zugreifen. Du hast also Hunderte Gigabyte Speicher im System, die du nicht nutzen kannst. Teuer bezahlt, null Nutzen für Inference.

Unified Memory: Apples Ansatz

Bei Apple Silicon gibt es diese Trennung nicht. Die M-Serie Ultra Chips haben eine Unified Memory Architecture (UMA), bei der CPU, GPU und Neural Engine auf denselben physischen Speicherbereich zugreifen.

┌──────────────────────────────────────────┐
│         Unified Memory (512 GB)          │
│           800 GB/s Bandwidth             │
│                                          │
│   ┌───────┐   ┌───────┐   ┌──────────┐  │
│   │  CPU  │   │  GPU  │   │  Neural  │  │
│   │       │   │       │   │  Engine  │  │
│   └───────┘   └───────┘   └──────────┘  │
│                                          │
│     Kein Kopieren. Kein PCIe. Direkt.    │
└──────────────────────────────────────────┘

Ein Mac Studio M3 Ultra bietet:

Die rohen TFLOPS einer Apple GPU liegen unter einer H100. Aber weil Inference memory-bound ist und die Bandwidth pro verfügbarem Gigabyte bei Unified Memory besser ausgenutzt wird, erreichen wir Token Rates auf dem Niveau von Cloud-Lösungen. Kein Geschwindigkeitsnachteil für den Nutzer.

Was das praktisch heißt

Ein 70B Modell läuft in FP16 (ca. 140 GB) problemlos auf einem einzelnen Mac Studio mit 512 GB. Das lässt über 350 GB für den KV-Cache und andere Prozesse. In INT8 oder Q4 hast du noch mehr Headroom und kannst mehrere Modelle parallel im Speicher halten. Wir messen über 50 Tokens/s bei 70B Modellen, vergleichbar mit Cloud-Lösungen.

Wir betreiben darauf die jeweils besten verfügbaren Open Source Modelle und passen diese mit branchenspezifischem Wissen an die Anforderungen unserer Kunden an. Die typischen Use Cases: Chat mit Unternehmensdaten, Document Retrieval mit RAG, spezialisierte Agents.

Für den Nutzer fühlt sich das schnell an. Frage eintippen, Antwort kommt in 2 bis 5 Sekunden. Kein Vergleich zu Cloud-Latenz, weil alles lokal läuft.

Was im Alltag noch auffällt: Die Dinger sind leise. Wirklich leise. Ein Mac Studio unter voller Inference-Last ist kaum hörbar. Ein GPU-Server unter Last klingt wie ein Staubsauger. Klingt nach einem Soft Factor, aber wenn die Hardware im Büro steht, macht das einen echten Unterschied.

Clustering mit RDMA über Thunderbolt 5

Für Kunden mit mehr Nutzern oder größeren Modellen verbinden wir mehrere Mac Studios zu einem Cluster. Seit macOS Tahoe 26.2 unterstützt Apple RDMA über Thunderbolt 5.

Die Specs im Überblick:

Unser Software Stack nutzt das für Model Parallelism: Das Modell wird automatisch auf die Nodes verteilt, und die Inference läuft synchron. Von der API-Seite sieht es aus wie ein einzelnes System.

┌────────────┐  TB5 (80 Gbit/s)  ┌────────────┐
│  Studio 1  │◄─────────────────►│  Studio 2  │
│  512 GB    │                    │  512 GB    │
└─────┬──────┘                    └──────┬─────┘
      │                                  │
      │  TB5       ┌────────────┐   TB5  │
      └───────────►│  Studio 3  │◄───────┘
                   │  512 GB    │
                   └──────┬─────┘
                          │
                     TB5  │  TB5
                          │
                   ┌──────┴─────┐
                   │  Studio 4  │
                   │  512 GB    │
                   └────────────┘

           = 2 TB Unified Cluster

Vier Mac Studios mit je 512 GB ergeben 2 TB Cluster-Speicher. Damit betreiben wir Modelle, die auf einem einzelnen Gerät nicht mehr reinpassen. Wir haben auf solchen Setups Modelle mit über einer Billion Parameters zum Laufen gebracht.

Kosten und Infrastruktur

Ein Mac Studio M3 Ultra mit 512 GB liegt bei rund 8.000 Euro. Vier Stück für einen Cluster kosten damit etwa 32.000 Euro und bieten zusammen 2 TB Unified Memory.

Auf NVIDIA-Seite bräuchtest du für vergleichbare Memory Capacity mehrere GPUs. Ein Server mit vier RTX 6000 Pro (je 96 GB VRAM, zusammen 384 GB) kostet allein für die GPUs rund 36.000 Euro, dazu Chassis, CPU, RAM, Netzteile und Kühlung. Realistisch landest du bei 50.000 bis 60.000 Euro, und hast trotzdem weniger verfügbaren Speicher als der Mac Cluster.

Der größere Unterschied liegt bei der Infrastruktur drumherum. Mac Studios brauchen eine Steckdose und ein Thunderbolt-Kabel. Ein GPU-Server braucht ein Rack, Kühlung, eventuell eine USV-Erweiterung und jemanden der sich damit auskennt.

Für Unternehmen, die bereits Datacenter-Infrastruktur haben, relativiert sich der Vorteil. Für alle anderen senkt es die Einstiegshürde erheblich.

Wann Mac Studio, wann NVIDIA?

Wir setzen beides ein und die Entscheidung hängt vom konkreten Use Case ab.

Mac Studio Cluster machen Sinn bis rund 500 Mitarbeitende, bei Modellen bis rund 140B quantisiert, wenn kein dedizierter Serverraum vorhanden ist und wenn schrittweises Skalieren gewünscht ist. Auch wenn Power Efficiency und Noise Level eine Rolle spielen, ist es die bessere Wahl.

Dedizierte NVIDIA Server machen Sinn ab 500 Mitarbeitenden, bei Modellen über 140B in Full Precision, wenn bereits Datacenter-Infrastruktur vorhanden ist, bei maximalem Throughput mit Hunderten Requests pro Sekunde, oder bei regulatorischen Hardware-Anforderungen (BSI, VS-NfD). Ab dieser Größenordnung planen und bauen wir Custom Setups als Individualprojekt.

In der Praxis starten die meisten unserer Kunden mit Mac Studios und skalieren bei Bedarf. Einige wenige brauchen von Anfang an dedizierte GPU-Hardware. Dann planen und bauen wir das als Individualprojekt.

Fazit

LLM Inference ist ein Memory Problem. Die Frage ist nicht, wie viele TFLOPS du hast, sondern wie viel schnellen Speicher du dem Modell bereitstellen kannst und wie schnell du ihn füttern kannst.

Klassische GPU Server lösen das mit teurem HBM und Multi-GPU Setups. Apple Silicon löst es mit Unified Memory. Für unsere Kunden im Mittelstand ist der Mac Studio Cluster aktuell die pragmatischste Lösung: Bezahlbar, leise, energieeffizient, skalierbar. Und die Performance reicht für produktive Anwendungen.