NVIDIA vs. Apple Silicon
für selbstgehostete KI.
Die richtige Hardware-Architektur hängt von Nutzerzahl, Modellgrösse und Durchsatzanforderungen ab – nicht vom grössten Marketing-Versprechen. Ein technischer Einblick, wie wir diese Entscheidung treffen.
Der Architektur-Unterschied
NVIDIA-Grafikkarten arbeiten mit dediziertem Video-Speicher (VRAM), der über PCIe oder NVLink angebunden ist – sehr schnell, aber kapazitätslimitiert und teuer pro Gigabyte. Apple Silicon nutzt stattdessen "Unified Memory": Prozessor und Grafikeinheit teilen sich denselben Speicher. Das bedeutet deutlich mehr Kapazität pro Franken, bei etwas geringerer Bandbreite als High-End-NVIDIA-Karten.
Bei reiner Rechenleistung liegt NVIDIA vorne, besonders wenn ein Modell eine Anfrage zum ersten Mal verarbeitet (sogenanntes "Prefill"). Beim eigentlichen Generieren der Antwort ("Decode") ist der Unterschied kleiner, weil dort vor allem die Speicherbandbreite entscheidet – hier kann Apple Silicon bei kleineren und mittleren Modellen gut mithalten.
Im direkten Vergleich
| Kriterium | NVIDIA | Apple Silicon |
|---|---|---|
| Rohleistung (Tokens/Sek.) | Deutlich schneller bei Prefill & kleinen/mittleren Modellen | Langsamer, besonders bei langem Kontext |
| Speicherkapazität | Teuer pro GB (z.B. 24 GB bei einer High-End-Consumer-Karte) | Bis zu 192 GB Unified Memory, günstiger pro GB |
| Grosse Modelle (70B+) | Braucht Multi-GPU oder Offloading/Quantisierung | Läuft nativ im Unified Memory ohne Tricks |
| Software-Reife | CUDA-Ökosystem – praktisch jedes Framework ist zuerst dafür optimiert | Metal/MLX – funktioniert gut, neue Funktionen oft mit Verzögerung |
| Multi-User-Betrieb | Hoher Durchsatz bei vielen parallelen Anfragen | Eher für einzelne oder wenige Nutzer ausgelegt |
| Energieeffizienz | Ca. 300–450 W pro Grafikkarte unter Last | Ca. 50–90 W Systemverbrauch unter Last |
| Skalierung/Ausbau | Einzelkarte günstig, Multi-GPU-Ausbau kostenintensiv | Höherer Einstiegspreis, Speicher dafür bereits inklusive |
| Training/Fine-Tuning | Klar überlegen (etabliertes Tooling) | Für ernsthaftes Training oft etwas komplexer |
| Betriebsgeräusch/Format | Lautes Server-Rack bei Multi-GPU-Aufbauten nötig | Lautlos, kompakt, bürotauglich |
| Langzeit-Stabilität (24/7) | Gut dokumentiert, gelegentlich Treiber-/Kernel-Themen | Sehr stabil im Dauerbetrieb |
Vereinfachte Einordnung für typische Setups – die konkrete Einschätzung hängt immer vom Einzelfall ab.
Neben der Hardware: welches Modell?
Die Wahl der Plattform ist die eine Seite – die Wahl des Sprachmodells die andere. Nicht jedes frei verfügbare Modell ist im rechtlichen Sinn wirklich quelloffen. Wir unterscheiden bewusst zwischen echten Open-Source-Modellen und sogenannten "Open-Weights"-Modellen, deren Nutzungsbedingungen oft einschränkender sind, als es auf den ersten Blick scheint.
| Kriterium | Open-Source-Modelle | Open-Weights-Modelle |
|---|---|---|
| Zugänglichkeit | Vollständig – Quellcode, Trainingscode und oft auch Datensätze verfügbar | Teilweise – nur die trainierten Gewichte, Trainingscode und Daten bleiben privat |
| Transparenz | Sehr hoch – vollständige Einsicht in Architektur und Training | Eingeschränkt – Trainingsprozess bleibt meist unbekannt |
| Anpassbarkeit | Sehr hoch – auf allen Ebenen frei modifizierbar | Mittel – Fine-Tuning möglich, aber oft lizenzrechtlich beschränkt |
| Lizenzielle Nutzungsrechte | Meist unproblematisch (z.B. Apache-, MIT-artige Lizenzen) | Prüfpflichtig – oft eigene "Acceptable Use Policies" mit Einschränkungen |
| Typischer Einsatz | Forschung, individuelle Speziallösungen | Schneller produktiver Einsatz, verbreitete kommerzielle Deployments |
| Ressourcenbedarf zum Start | Höher – mehr Know-how zum Aufsetzen nötig | Geringer – fertige Modelle sofort einsetzbar |
Wir prüfen die Lizenz jedes Modells vor dem Einsatz – damit Sie später kein böses Erwachen erleben.
Beispiele aus der Praxis
Die meisten bekannten Modelle, die sich lokal betreiben lassen, sind im rechtlichen Sinn "Open-Weights": Sie erhalten die trainierten Gewichte zum Betrieb – passend für den Einsatz mit Ollama & Co. –, aber weder die Trainingsdaten noch das vollständige Trainingsrezept. Echte Open-Source-Modelle, bei denen auch das offengelegt ist, sind seltener und meist bei Forschungsinstituten zu finden.
Echte Open-Source-Modelle
Gewichte, Trainingscode und Datensatz-Rezeptur offengelegt
- OLMo / OLMo 2 (Allen Institute for AI) – gilt als saubereres Beispiel mit komplett offener Pipeline
- Pythia (EleutherAI)
- GPT-NeoX / GPT-J (EleutherAI)
- BLOOM (BigScience)
- RedPajama / RedPajama-INCITE (Together AI)
- StableLM (Stability AI, teilweise)
- LLM360 K2 / Amber – vollständig offen inkl. Checkpoints
Open-Weights-Modelle
Gewichte öffentlich, Trainingsdaten/-code meist proprietär
- Llama 3.x / 4 (Meta)
- Mistral / Mixtral (Mistral AI)
- Gemma 2/3 (Google)
- Qwen 2.5/3 (Alibaba)
- DeepSeek-V3 / R1
- Phi-4 (Microsoft)
- Command R+ (Cohere)
Für die meisten praktischen Anwendungsfälle – etwa Retrieval-gestützte Suche oder lokale Inferenz – wirkt sich diese Unterscheidung kaum auf das Ergebnis aus. Relevant wird sie vor allem bei Fragen zu Auditierbarkeit, Forschung oder wenn Ihre Compliance-Vorgaben volle Nachvollziehbarkeit der Trainingsdaten verlangen.
Was das für Ihre Entscheidung bedeutet
Sollen mehrere Personen gleichzeitig und mit hohem Durchsatz bedient werden, oder kommen besonders grosse Modelle (ab ca. 70 Milliarden Parametern) zum Einsatz, ist eine Multi-GPU-NVIDIA-Architektur mit Serving-Software wie vLLM oft die passendere Wahl. Für einzelne oder wenige interne Nutzer mit grossen Kontextfenstern – etwa für Dokumenten- oder Archivsuche – ist ein Apple-Silicon-System dagegen häufig die wirtschaftlichere, leisere und einfacher zu betreibende Alternative.
Genau diese Abwägung gehört zu unserer Bedarfsanalyse: Wir wählen die Hardware nach Ihrem tatsächlichen Bedarf – Nutzerzahl, Modellgrösse, Kontextlänge, Budget – nicht nach dem grössten Marketing-Versprechen.