Jahrelang sah es so aus, als gehöre das Wettrüsten bei den Sprachmodellen allein den Cloud-Anbietern und ihren API Keys. In den vergangenen achtzehn Monaten ist aber etwas Bemerkenswertes passiert: Open-Weight-Modelle sind so weit gereift, dass anspruchsvolle, leistungsfähige KI heute vollständig auf Consumer-Hardware unter Ihrem Schreibtisch laufen kann. Das hat weitreichende Folgen. Ihre Daten bleiben bei Ihnen. Es gibt keine API-Rechnung. Sie hängen weder von den Nutzungsbedingungen eines Anbieters ab noch davon, dass er ein Modell plötzlich einstellt. Und schon mit einer bescheidenen GPU könnte Sie die Geschwindigkeit überraschen.
Warum LLMs lokal betreiben?
Bevor es um die Technik geht, zuerst die Bilanz: was Sie gewinnen und was Sie dafür aufgeben.
Datenschutz und Datenhoheit: Ihre Prompts verlassen Ihren Rechner nie. Das wiegt schwerer, als es klingt, vor allem für Unternehmen, die mit sensiblen Dokumenten, medizinischen Unterlagen oder proprietärem Code arbeiten. Es gibt keine Cloud-Logs, keine Sorgen wegen der Nutzungsbedingungen und keine überraschenden Regeln zur Datenspeicherung.
Kosten und Unabhängigkeit: Sobald die Hardware bezahlt ist, kostet die Inferenz nichts mehr. Preisänderungen treffen Sie nicht. Sie wachen auch nicht eines Morgens auf und stellen fest, dass Ihr Lieblingsmodell zugunsten einer neueren, teuren Version eingestellt wurde. Sie bestimmen selbst, welche Versionen Sie betreiben, wie Sie sie verändern und wie Sie sie einsetzen.
Latenz: Der Weg zu einer Cloud-API und zurück kostet typischerweise 200-500 ms. Bei lokaler Inferenz fällt dieser Netzwerkaufwand weg. In Echtzeitanwendungen und interaktiven Chatbots merkt man den Unterschied.
Anpassung: Sie können Modelle per Fine-Tuning auf Ihre eigenen Daten abstimmen. Sie können Pipelines für Retrieval-Augmented Generation (RAG) ergänzen und eigene Werkzeuge einbinden. Was der API-Anbieter freigeschaltet hat, setzt Ihnen keine Grenze.
Dem stehen die Hardwarekosten, der Stromverbrauch und die Tatsache gegenüber, dass Sie nun selbst für Ihre Infrastruktur verantwortlich sind. Für gelegentliche Nutzung, für extreme Skalierung und für Frontier-Modelle, die schlicht nicht auf Consumer-Hardware passen, bleiben Cloud-APIs die bessere Wahl. In vielen Arbeitsabläufen hat die lokale Inferenz aber den Schritt vom experimentellen Spielzeug zum praktischen Standard geschafft.
Der Engpass: Die Speicherbandbreite ist Ihr wichtigster Leistungshebel
Bei der Hardware für lokale LLMs achten die meisten auf die Prozessorgeschwindigkeit oder die reine Rechenleistung. Das ist der falsche Maßstab. Neuere Forschung zeigt klar: Bei der LLM-Inferenz begrenzt in erster Linie die Speicherbandbreite die Leistung, nicht die Rechenleistung. Außerhalb technischer Kreise ist das noch kaum bekannt. Es lohnt sich aber, den Grund zu verstehen, denn er ändert komplett, wie Sie beurteilen sollten, ob sich ein Rechner für LLMs eignet.
Warum die Speicherbandbreite zählt: das Problem der arithmetischen Intensität
LLMs haben eine grundlegende Eigenschaft, die man niedrige arithmetische Intensität nennt: Pro Byte, das aus dem Speicher geholt wird, führen sie relativ wenige Rechenoperationen aus. Für jedes erzeugte Token muss Ihr Rechner Milliarden von Modellgewichten aus dem RAM holen und rechnet dabei vergleichsweise wenig. Der Engpass ist diese Datenbewegung, nicht die Berechnung selbst.
Ein ausführliches Paper von NVIDIA Research aus dem Jahr 2025, Efficient LLM Inference: Bandwidth, Compute, Synchronization, and Capacity Are All You Need, zeigt, dass der Inferenzdurchsatz vor allem mit der Speicherbandbreite skaliert: Beim Transformer-Decoding müssen immer wieder Milliarden von Gewichten geholt werden, und das überlastet die Kapazität für die Datenbewegung, nicht die Recheneinheiten. Die Studie Mind the Memory Gap von IBM (2025) stellte fest, dass selbst GPUs mit riesigen ungenutzten Rechenreserven an ihre Bandbreitengrenze stoßen, sodass die Recheneinheiten während der Inferenz untätig bleiben.
In der Praxis heißt das: Mehr Rechenkapazität bringt bei der Token-Erzeugung oft kaum Tempo, mehr Speicherbandbreite dagegen manchmal enorm viel. Akademische Analysen beziffern das: Steigt die effektive Speicherbandbreite von GDDR6 (~700 GB/s) auf HBM3 (~3,5 TB/s), kann sich der Durchsatz bei großen Modellen fast vervierfachen, und zwar ohne jede Änderung an der Rechenleistung.
Das erste Token und alle folgenden
Ein technischer Unterschied ist wichtig: Das erste Token (bei der Verarbeitung Ihres Prompts) kann zum Teil von der Rechenleistung abhängen, weil die gesamte Eingabesequenz auf einmal berechnet wird. Jedes weitere Token hängt dagegen fast nur noch vom Speicher ab, weil dieselben Modellgewichte immer wieder verwendet werden und jeweils nur ein neues Token dazukommt.
Untersuchungen von Databricks (2025) und Hathora (2025) bestätigen diese Dynamik: Das erste Token ist durch die Rechenleistung begrenzt, alle folgenden Token sind durch den Speicher begrenzt. Für die interaktive Nutzung, bei der vor allem die Geschwindigkeit der Token-Erzeugung zählt, ist die Bandbreite damit fast alles.
Ein Beispiel aus der Praxis: Warum ein M3 Max bei LLMs einen neueren M4 Pro schlägt
Dieses Prinzip zeigt sich in der Praxis auf teils überraschende Weise. Nehmen Sie Apples Laptops: Ein älterer M3 Max mit 48 GB Unified Memory (400 GB/s Bandbreite) führt LLMs bei der Token-Erzeugung tatsächlich schneller aus als ein neuerer M4 Pro, obwohl der M4 Pro insgesamt der neuere und stärkere Chip ist.
Warum? Die wesentlich höhere Speicherbandbreite des M3 Max (400 GB/s gegenüber der deutlich niedrigeren Bandbreite des M4 Pro) bringt die Modellgewichte weitaus effizienter vom Speicher zu den Recheneinheiten. Speziell bei der LLM-Inferenz wiegt dieser Bandbreitenvorteil schwerer als jeder Rechenzuwachs, den die neue Generation des M4 Pro mitbringt. Ein zwei Jahre alter Max kann einen aktuellen Pro überholen.
Dasselbe wiederholt sich quer durch alle Hardware-Ökosysteme: Systeme mit höherer Bandbreite liefern bei der LLM-Inferenz durchwegs mehr Leistung als Alternativen mit höherer Rechenleistung, selbst wenn diese neuer oder teurer sind.
Die ausgewogene Sicht: Was das für Ihre Hardwarewahl bedeutet
Zu sagen, die LLM-Leistung sei „vollständig bestimmt“ durch die Speicherbandbreite, vereinfacht die Sache also ein wenig. Die Belege sind aber erdrückend:
– Inferenz (Token-Erzeugung) ≈ stark bandbreitengebunden.
– Training oder Verarbeitung des ersten Tokens ≈ teilweise rechengebunden.
– Leistung in der Praxis ≈ min(Speicherbandbreite, Rechendurchsatz × arithmetische Intensität).
Für alle, die LLMs lokal betreiben, heißt das: Wenn Sie prüfen, ob sich ein Rechner für LLM-Workloads eignet, machen Sie die Speicherbandbreite zu Ihrem wichtigsten Kriterium. Die Speicherkapazität ist auch wichtig, denn das Modell muss hineinpassen. Ob es dann flüssig läuft oder sich quält, entscheidet aber, wie schnell Ihr System diesen Speicher bewegen kann. Deshalb schlagen Rechner mit hoher Speicherbandbreite bei der LLM-Inferenz die Alternativen mit hoher Rechenleistung. Und deshalb staunen viele, dass ihr „schwachbrüstiger“ älterer Rechner LLMs besser bewältigt als ein neueres System: Die Bandbreitenangaben haben sie vermutlich nie angesehen.
Hardware: Ihr Sweet Spot
Jetzt konkret: Was können Sie auf welcher Hardware tatsächlich betreiben? Das Angebot ist 2025 breiter denn je und reicht von Einsteigerkarten unter 250 $ bis zu Beschleunigern der Workstation-Klasse.
Hinweis zur Messmethode: Die Angaben in Token pro Sekunde (t/s) weiter unten sind grobe Schätzungen auf Basis interner Tests und Benchmarks Dritter. Der tatsächliche Durchsatz hängt stark von Modell, Quantisierungsformat, Kontextlänge, Scheduler, Batch-Größe und thermischem Zustand ab. Die Zahlen gehen von Single-Stream-Inferenz mit Q4_K_M oder gleichwertiger Quantisierung bei üblichen Batch-Größen (1-8) aus. Für eine genaue Leistungsabschätzung testen Sie auf Ihrer eigenen Hardware mit Ihrem tatsächlichen Workload.
Der Einstieg: unter 500 $
Intel Arc B580 (249 $): Der neueste Überraschungskandidat. Intels Arc-GPUs reifen nach und nach, und die B580 bietet bei kleinen Modellen ein wirklich beeindruckendes Preis-Leistungs-Verhältnis. Zwölf Gigabyte VRAM, eine für diese Preisklasse ordentliche Bandbreite und native oneAPI-Unterstützung. Sie sind auf 7B-Modelle beschränkt, aber zum Experimentieren oder für Prototypen ist das der günstigste Weg zur lokalen Inferenz. Der wichtigste Vorbehalt: Die Softwareunterstützung entsteht noch, und die Community-Ressourcen sind dünner als im Ökosystem von NVIDIA.
NVIDIA RTX 4060 Ti (499 $ neu): Ein konservativerer Einstieg in NVIDIAs Palette. Sechzehn Gigabyte VRAM, vollwertige CUDA-Unterstützung und ausgereifte Werkzeuge. 7B- bis 13B-Modelle laufen bequem, mit Quantisierung kommen Sie auch in den 30B-Bereich. Wer als Entwickler garantierte Kompatibilität möchte, hat hier einen vernünftigen Startpunkt. Die Leistung liegt je nach Modell bei 8-15 Token pro Sekunde.
Mit knappem Budget: 700-1500 $
Gebrauchte RTX 3090 (700-900 $): Das ist der Preis-Leistungs-König für ernsthafte Arbeit. Auf dem Gebrauchtmarkt finden Sie die RTX 3090 um 700-900 $, ungefähr ein Drittel des ursprünglichen Listenpreises. Sie hat 24 GB GDDR6X-Speicher mit rund 935 GB/s Bandbreite. Das ist für die Inferenz weiterhin konkurrenzfähig, obwohl die Karte noch auf der Ampere-Architektur (2020) beruht. 30B-Modelle laufen bequem, mit aggressiver Quantisierung kommen Sie sogar an 70B heran. Messungen in der Praxis zeigen bei mittelgroßen Modellen konstant 25-35 Token pro Sekunde. Der Haken: Sie kaufen gebrauchte Hardware ohne Garantie, und die Verfügbarkeit schwankt. Bei der Leistung pro Dollar ist sie aber kaum zu schlagen. Viele Forschende bauen ihre Mehrkarten-Systeme nach wie vor um gebrauchte 3090er.
NVIDIA RTX 4070 Ti Super (1000-1200 $ neu): Wenn Sie eine neue Karte mit Garantie möchten, schließt diese die Lücke zwischen Einstieg und Leistungsklasse. Mit sechzehn Gigabyte VRAM laufen nur 7B- bis 13B-Modelle bequem, 30B-Modelle verlangen kleinere Kontextfenster. Die Speicherbandbreite ist knapper als bei der 3090, reicht für die interaktive Nutzung aber aus. Je nach Modell sehen Sie 15-25 Token pro Sekunde. Sie ist außerdem eine fähige Gaming-Karte, was zählt, wenn Ihre GPU beides können muss.
Rechner nur mit CPU: Auch ganz ohne GPU müssen Sie nicht verzweifeln. Moderne CPUs mit gutem VRAM (DDR5) können kleine quantisierte Modelle ausführen. Ein 7B-Modell in 4-Bit-Quantisierung passt in 4-5 GB und liefert 2-5 Token pro Sekunde. Das reicht für Batch-Verarbeitung und nicht interaktive Arbeit. Zum Experimentieren kostet es nichts, für einen interaktiven Chatbot ist es aber nicht praxistauglich.
Das praktische Optimum: 1500-2500 $
NVIDIA RTX 4090 (1600-2000 $ neu): Über mehrere Jahre war das die eindeutige Consumer-Wahl für ernsthafte lokale Arbeit. Vierundzwanzig Gigabyte GDDR6X mit 1.010 GB/s Bandbreite und grundsolide CUDA-Unterstützung. 30-32B-Modelle bewältigt sie mit vollen Kontextfenstern hervorragend. Für 70B-Modelle brauchen Sie aggressive Quantisierung (INT4 oder darunter). Benchmarks aus der Praxis zeigen durchwegs 40-50 Token pro Sekunde. Der Stromverbrauch liegt in der Spitze bei rund 450 W. Die Karte bleibt beachtlich, auch wenn sich ihre Marktposition durch neuere Alternativen verschoben hat.
NVIDIA RTX 5090 (1999 $ neu): NVIDIAs neues Flaggschiff, erschienen im Jänner 2025, ist ein echter Sprung nach vorn. Zweiunddreißig Gigabyte GDDR7-Speicher mit ~1.792 GB/s Bandbreite, das sind 77 % mehr als bei der 4090. Bei vergleichbaren mittelgroßen Modellen (30B und kleiner in Q4) liegen grobe Schätzungen bei 60-70 Token pro Sekunde (gegenüber 40-50 auf der 4090). Wichtiger Vorbehalt: 70B-Modelle in der üblichen Q4_K_M-Quantisierung (Dateien von ~42-43 GB) passen nicht vollständig in 32 GB VRAM. Für vollständige 70B-Modelle brauchen Sie aggressive 3-Bit-Quantisierung, Kompression der IQ-Klasse oder CPU-Offload. Bei 30B- bis 32B-Modellen mit vollem Kontext ist die 5090 herausragend. Der Stromverbrauch liegt mit 575 W in der Spitze höher als bei der 4090, aber für langfristige Käufe im Jahr 2025 rechtfertigt der Bandbreitenvorteil den Aufpreis.
AMD Radeon RX 7900 XTX (1200-1500 $): Die AMD-Alternative mit 24 GB VRAM und 960 GB/s Bandbreite sieht auf dem Papier vielversprechend aus. Die Leistung ist ungefähr mit der RTX 3090 vergleichbar. Das große Problem ist die Reife der Software. ROCm (AMDs Gegenstück zu CUDA) hinkt NVIDIAs Ökosystem deutlich hinterher. Die Unterstützung durch Frameworks ist lückenhaft. Unter Windows gibt es praktisch keine ROCm-Unterstützung. Selbst unter Linux müssen Sie mit manueller Konfiguration und gelegentlichen Inkompatibilitäten rechnen. Für Linux-Enthusiasten, die gern Fehler suchen, kann das funktionieren. Für alle anderen bleibt NVIDIA die sicherere Wahl.
Apple Silicon: die Alternative mit Unified Memory
Apples Unified-Memory-Architektur verdient bei lokalen LLMs ernsthafte Beachtung, vor allem weil sich Speicherbandbreite und Kapazität direkt in Leistung übersetzen, und genau das verlangt die LLM-Inferenz. Anders als bei diskreten GPUs, wo Daten vom Systemspeicher in den VRAM wandern, greifen bei Apples Architektur GPU, CPU und Neural Engine auf denselben Speicherpool mit voller Bandbreite zu. Diese Eleganz wirkt sich bei Inferenz-Workloads tatsächlich auf die Leistung aus.
MacBook Air M3 (1.099-1.499 $): Der Einstieg zum Experimentieren mit lokalen LLMs. Acht bis 24 GB Unified Memory. Realistisch laufen 7B-Modelle bequem, quantisierte Modelle mit etwa 10-15 Token pro Sekunde. Unter Dauerlast wird es thermisch eng, aber für gelegentliche Nutzung oder Prototypen funktioniert es. Am besten für: Studierende und Hobbyisten, die lokale Inferenz ohne GPU-Investition ausprobieren wollen.
MacBook Pro M3 Pro (1.999-2.599 $): Der Sweet Spot für die mobile LLM-Entwicklung. Achtzehn bis 36 GB Unified Memory. 13B-Modelle laufen flüssig mit 15-22 Token pro Sekunde. Die Akkulaufzeit bleibt auch unter Last brauchbar. Hier können Sie praktische lokale KI-Anwendungen bauen (RAG-Pipelines, kleine Agenten, Prompt-Experimente), ohne an den Schreibtisch gebunden zu sein. Am besten für: Entwicklerinnen und Entwickler, die mobil sein wollen und keine separate GPU-Hardware pflegen möchten.
MacBook Pro M4 Max (2025, 3.999-5.300 $): NVIDIAs Timing beim Marktstart macht tatsächlich sichtbar, was Apple gut macht. Sechsunddreißig bis 128 GB Unified Memory. Quantisierte 33B- bis 70B-Modelle laufen mit dem optimierten MLX-Backend mit 30-45 Token pro Sekunde. Das ist echte Desktop-Leistung in einem Laptop. Der M4 Max hat deutlich mehr thermischen Spielraum als der M3 Pro und hält dabei die Akkulaufzeit. Am besten für: professionelle KI-Entwicklerinnen und -Entwickler, die viel unterwegs sind oder einen einzigen starken Rechner für alles wollen.
Mac Studio M3 Ultra (4.999-8.999 $, 192-512 GB): Für alle, die mehrere Modelle gleichzeitig betreiben oder mit wirklich großen Modellen arbeiten müssen. Achthundert Gigabyte pro Sekunde Unified-Memory-Bandbreite, ein Wert, der mit High-End-Enterprise-GPUs mithalten kann. Er bewältigt unquantisierte 70B-Modelle oder für Forschungszwecke experimentelle Modelle ab 600B in 4-Bit-Quantisierung. Die Leistungsgrenze liegt höher als bei allem im Consumer-Bereich außer den neuesten Enterprise-Karten von NVIDIA, und die Energieeffizienz ist außergewöhnlich. Am besten für: Organisationen, Forschungsgruppen oder Power-User mit Multi-LLM-Deployments oder Fine-Tuning-Pipelines.
Die Software zählt: Anders als unter Windows mit seinen konkurrierenden Frameworks hat sich das Mac-Ökosystem auf ausgezeichnete Werkzeuge geeinigt. MLX (Apples Framework) und Ollama nutzen Unified Memory beide effizient und laden quantisierte Gewichte mit minimalem Overhead direkt in den RAM. Hier spielt Apples Architektur ihre Stärke aus: Ohne diskreten VRAM entfällt der Kopieraufwand zwischen System- und GPU-Speicher.
Die ehrliche Einschätzung: Beim reinen Wert in Token pro Sekunde liegen Macs bei Modellen ähnlicher Größe etwa 20-30 % hinter diskreten High-End-Karten von NVIDIA. Eine RTX 5090 schlägt den M3 Ultra im absoluten Durchsatz. Die Gesamtkosten (Preis, Stromverbrauch, Lautstärke, Platz, Systemintegration) verschieben die Rechnung aber deutlich. Ein Mac Studio M4 Max mit 128 GB um 4.500 $ konkurriert direkt mit einer RTX 5090 um 2.000 $, wenn Sie die Kosten des gesamten Systems einrechnen. Und wenn Sie für andere Arbeit ohnehin im Apple-Ökosystem sind, fügt sich alles nahtlos ein. Am besten für: Entwickler und Organisationen, die ohnehin auf macOS setzen, Forschende, denen Effizienz und leiser Betrieb wichtig sind, und alle, die keine getrennten Hardware-Ökosysteme pflegen wollen.
NVIDIA DGX Spark: der neue Herausforderer (2.999-3.999 $)
Die im Oktober 2025 erschienene NVIDIA DGX Spark ist etwas Neues: NVIDIAs Antwort auf Inferenz-Workstations mit Unified Memory. Sie kombiniert eine Grace-Blackwell-GPU (128 GB Unified LPDDR5X-Speicher mit 273 GB/s Bandbreite) mit 20 Grace-ARM-CPU-Kernen in einem einzigen leisen System mit 240 W.
Damit wird die DGX Spark zum wichtigen Fallbeispiel für die Leistungsgrenzen von LLMs: Sie führt in Benchmarks aus der Praxis den Bandbreitenengpass zwischen Prefill und Decode geradezu perfekt vor.
Die Leistung im Einzelnen:
Beim Prefill (der Verarbeitung des Prompts), der viel Rechenleistung braucht, ist die Spark außergewöhnlich. Bei der Verarbeitung großer Prompts durch ein 120B-Modell zeigen interne und externe Benchmarks einen Durchsatz von rund 1.700 Token/s. Das ist bei derselben Aufgabe etwa 3× schneller als drei RTX 3090. Für Batch-Inferenz oder Anwendungen, die vor der Erzeugung große Dokumente verarbeiten, ist das sehr attraktiv.
Beim Decode (der Token-Erzeugung), der am Speicher hängt, läuft die Spark dagegen gegen eine Wand: Grobe Schätzungen sehen sie bei großen Modellen bei rund 30-40 Token pro Sekunde, gegenüber mehr als 100 t/s bei einem gut abgestimmten Multi-GPU-System aus 3090ern. Der enorme Rechenvorteil der Spark ist plötzlich dahin.
Warum? Wegen der Speicherbandbreite. Die 273 GB/s der Spark sind respektabel, reichen für die Token-Erzeugung im großen Maßstab aber nicht aus. Die GPU hat *mehr als genug Rechenleistung*, um Token schneller zu erzeugen, aber ihr fehlen die Daten. In der Decode-Phase wartet sie darauf, dass die Gewichte aus dem Speicher nachkommen, nicht auf die Berechnung.
Das ist kein Mangel, sondern der Beweis für unsere zentrale These. Die DGX Spark hat etwa 80 TFLOPS FP32-Rechenleistung, ungefähr 3× so viel wie Apples M3 Ultra. Trotzdem ist sie beim Decode kaum schneller als der M3 Ultra (der bei 70B-Modellen 12-15 t/s erreicht), weil beide Systeme an der Bandbreite hängen. Einen Bandbreitenengpass können Sie nicht mit mehr Rechenleistung überwinden.
Wann die DGX Spark sinnvoll ist:
– Fine-Tuning und Training: Die Spark schafft beim Fine-Tuning von Llama 8B mit LoRA >53.000 Token pro Sekunde, ein außergewöhnlicher Wert für ein Desktop-System. Wenn Sie aktiv Modelle entwickeln und nicht nur Inferenz betreiben, ist das sehr attraktiv.
– Wirklich große Modelle: Mit 128 GB Unified Memory können Sie mit Modellen bis zu 200 Mrd. Parametern in FP4-Quantisierung arbeiten, was die meiste Consumer-Hardware nicht schafft.
– Prefill-lastige Workloads: Anwendungen, die vor der Erzeugung große Dokumente, Code oder Kontext verarbeiten, profitieren deutlich.
– Leiser, effizienter Betrieb: Mit 240 W und einem effizienten Kühlkonzept ist die Spark im Vergleich zu Multi-GPU-Systemen leise und sparsam.
Der ehrliche Vergleich:
Bei der reinen Geschwindigkeit der Token-Erzeugung auf mittelgroßen quantisierten Modellen liegt die RTX 5090 deutlich vor der DGX Spark. Mit ~1.792 GB/s Bandbreite gegenüber den 273 GB/s der Spark skaliert die 5090 die Token-Erzeugung viel besser. Der Durchsatz in der Praxis hängt stark von Modellgröße, Quantisierung und Batch-Größe ab, aber der Bandbreitenabstand ist der grundlegende begrenzende Faktor. Die Stärke der Spark liegt in der Modellkapazität (128 GB) und im Prefill-Durchsatz, nicht in der Decode-Geschwindigkeit.
Umgekehrt helfen weitere Geräte, wenn eine einzelne Spark an der Bandbreitengrenze hängt und Sie mehr Decode-Durchsatz brauchen: Die Bandbreite skaliert linear mit der Anzahl der GPUs (abzüglich des Koordinationsaufwands). Zwei vernetzte Sparks oder ein Spark-Cluster sollen entsprechend höheren Gesamtdurchsatz erreichen, auch wenn wir das in Tests aus der Praxis noch nicht gesehen haben.
Unterm Strich: Die DGX Spark ist nichts für maximalen Token-Durchsatz. Sie ist für Organisationen gedacht, die Modellkapazität brauchen (128 GB Unified Memory), sich die Komplexität von Multi-GPU-Systemen ersparen wollen und auf Energieeffizienz achten. Sie ist außerdem der deutlichste Beleg dafür, dass mehr Rechenleistung schlicht verschwendet ist, sobald die Bandbreite der begrenzende Faktor ist.
Workstation- und Enterprise-Klasse: ab 4.000 $
NVIDIA RTX A6000 (4.000-5.000 $): Eine Karte der Enterprise-Klasse mit 48 GB VRAM. Quantisierte Modelle bis 70B laufen flüssig. Für CUDA optimiert und zuverlässig. Für die meisten Hobbyisten ist das zu viel, für Organisationen mit lokaler Inferenz im Produktivbetrieb aber Standard.
NVIDIA H100 (80 GB, 25.000-40.000 $): Der Goldstandard im Rechenzentrum. Achtzig Gigabyte VRAM, HBM3-Speicher mit außergewöhnlicher Bandbreite und NVLink-Unterstützung für die Skalierung über mehrere GPUs. Bewältigt Modelle ab 175B. Relevant ist das nur für Organisationen, die Inferenz für viele gleichzeitige Nutzer bereitstellen, nicht für lokale Experimente.
Wirtschaftlichkeit: Wann lohnt sich lokal?
Die Rechnung hängt von Ihrer Nutzung ab. Wer 500 $ im Monat oder mehr für API-Zugriff ausgibt, erreicht mit lokalen LLMs innerhalb von 6-12 Monaten die Kostengleichheit mit der Cloud. Strom und Kühlung schlagen je nach Standort mit etwa 50-200 $ im Monat zu Buche. Das bedeutet:
– Bei 1000 $ für Hardware (z. B. eine gebrauchte RTX 3090) erreichen Sie bei mittlerer Nutzung (500 $ API-Ausgaben im Monat) in ungefähr 6 Monaten die Kostengleichheit mit Cloud-APIs.
– Über eine Hardware-Lebensdauer von 3-5 Jahren können Vielnutzer mit lokalem Betrieb 10.000-50.000 $ gegenüber dauerhafter Cloud-API-Nutzung sparen.
– Für kleine Teams kann eine einzige RTX 5090 (2000 $) leisten, was sonst mehr als 30.000 $ im Jahr an Cloud-API-Kosten verursachen würde.
Die Bandbreite bleibt in allen Preisklassen der begrenzende Faktor. Selbst Enterprise-Hardware wie die H100 stößt bei der Inferenz an ihre Bandbreitengrenze. Deshalb kann die RTX 5090 beim reinen Inferenzdurchsatz mit der viel teureren H100 mithalten: Die neuere Architektur und die höhere Speicherbandbreite zählen mehr als die reine Rechenkapazität.
Mobil und ultrakompakt: die Klasse rund um den AMD Ryzen AI Max+ 395
Erwähnenswert ist noch eine neuere Klasse von Systemen: mobile Mini-PCs und Laptops rund um AMDs Ryzen AI Max+ 395 (Strix-Halo-Architektur). Sie sind für einen bestimmten Zweck wirklich interessant, nämlich für Entwickler und Forschende, die lokale LLMs nutzen wollen, ohne an einen Schreibtisch gebunden zu sein.
Was sie attraktiv macht: Der Ryzen AI Max+ 395 vereint eine leistungsstarke Zen-5-CPU, eine Radeon-8060S-GPU und eine eigene XDNA-2-NPU in einem stromsparenden Paket. Für LLMs noch wichtiger: Diese Systeme unterstützen bis zu 128 GB LPDDR5X Unified Memory mit mehr als 300 GB/s Bandbreite. Das liegt respektabel nahe an dem, was diskrete NVIDIA-Karten bieten, und reicht, um 7B- bis 13B-Modelle flüssig auszuführen.
Beispiele für Mini-PCs: Geräte wie der Beelink GTR9 Pro (~1.399 $), der AOOSTAR NEX395 (~1.699-2.099 $) und der PELADN YO1 (2.000 $) bieten das volle Desktop-Erlebnis in kompakter Bauform. Sie bekommen zweimal Ethernet, USB4 und eine ordentliche Kühlung, also alles, was man von einem Mini-PC erwartet. Bei Preis und Mobilität konkurrieren sie direkt mit dem Weg über die RTX 5090, wenn auch mit etwas geringerer absoluter Leistung.
Laptops: Wenn Sie wirklich mobil sein müssen, bringen das ASUS ROG Flow Z13 (2025) (2.499-3.499 $) und das HP ZBook Ultra G1 (3.200-8.000 $) Workstation-Fähigkeiten in Geräte mit 13 bis 16 Zoll. Besonders interessant für die mobile KI-Entwicklung ist das ROG Flow, ein Convertible-Tablet mit ordentlich Rechenleistung dahinter.
Der Kompromiss: Diese Systeme glänzen bei Effizienz und Mobilität, bleiben aber etwas unter der Spitzenleistung diskreter GPUs. Bei den reinen Token pro Sekunde liegt eine RTX 5090 knapp vorn, dafür bieten die Systeme mit dem 395 NPU-Unterstützung und bessere thermische Eigenschaften, und das ganze System ist auf KI-Workloads ausgelegt. Außerdem sind sie leiser und verbrauchen weniger Strom als ein Desktop-System mit GPU.
Am besten für: Entwickler, die viel reisen, Forschende, die unterwegs Modellprototypen bauen, oder Organisationen, die lokale LLMs ohne Rechenzentrums-Infrastruktur auf mehreren kompakten Workstations einsetzen. Wenn Ihnen leiser Betrieb, niedriger Stromverbrauch und Mobilität wichtig sind, ist das eine echte Alternative zu klassischen GPUs.
Die wichtigsten Kennzahlen: Worauf Sie achten sollten
Achten Sie bei der Hardware auf drei Zahlen:
VRAM (Video RAM): Bestimmt direkt das größte Modell, das Sie betreiben können. Die verbreitete Faustregel („1/8 der Parameter“) ist gefährlich falsch. So sieht es wirklich aus:
– FP32-Präzision: 1 Byte pro Parameter. Ein 30B-Modell = 120 GB allein für die Gewichte (vor dem KV-Cache).
– FP16/BF16: 2 Byte/Parameter → 60 GB für 30B.
– Q8 (8-Bit-Quantisierung): ~1 Byte/Parameter → 30 GB für 30B.
– Q4 (4-Bit-Quantisierung): ~0,5 Byte/Parameter + Metadaten → 15-18 GB für 30B; typische Q4_K_M-Dateien sind 10-15 % kleiner.
Für ein 70B-Modell in Q4 rechnen Sie mit 35-43 GB (typische Q4_K_M-Dateien haben ~42-43 GB und passen ohne aggressive 3-Bit-Quantisierung oder Offload nicht auf eine RTX 5090 mit 32 GB). Der KV-Cache kommt je nach Kontextlänge und Batch-Größe mit 5-25 GB dazu: Längere Prompts und größere Batches kosten mehr Speicher.
Speicherbandbreite: Gemessen in GB/s. Das ist Ihr wichtigster Leistungshebel. Für die interaktive Nutzung sollten Sie mindestens 300 GB/s anstreben. Die RTX 3090 (~936 GB/s) und die 4090 (~1.008 GB/s) liegen beide deutlich darüber, die RTX 5090 erreicht ~1.792 GB/s. Neuere integrierte Systeme wie der M4 Max schaffen über Unified Memory >0,5 TB/s, was zeigt, dass die Bandbreite ebenso zählt wie die VRAM-Kapazität.
Stromverbrauch: Besonders relevant im 24/7-Betrieb. Eine durchgehend laufende GPU mit 450 W kostet (je nach lokalem Tarif) rund 500-750 $ Strom im Jahr. Rechnen Sie das über 3-5 Jahre in die Gesamtkosten ein.
Der Software-Stack: Werkzeuge für lokale LLMs
Das Ökosystem ist enorm gereift. Sie haben die Wahl, und alle Optionen sind wirklich gut.
llama.cpp: das Fundament
Ganz unten liegt bei fast allem llama.cpp, eine schlanke C/C++-Implementierung der LLaMA-Inferenz von Georgi Gerganov. Es ist der Motor hinter dem meisten, was Sie verwenden werden. Seine wichtigste Neuerung war der Nachweis, dass LLMs dank intelligenter Quantisierung und Layer-Offloading effizient auf Consumer-CPUs und -GPUs laufen können.
Solange Sie sich nicht gezielt für Low-Level-Optimierung oder feinkörnige Kontrolle interessieren, werden Sie llama.cpp nicht direkt benutzen. Wenn Sie aber Ollama oder LM Studio verwenden, baut das auf der Inferenz-Engine von llama.cpp auf. Dieses zuverlässige, praxiserprobte Fundament hat die lokale Inferenz erst praktikabel gemacht.
Ollama: das entwicklerfreundliche Werkzeug
Ollama (ollama.com) ist wohl das wichtigste Werkzeug im heutigen Ökosystem lokaler LLMs. Es ist eine Kommandozeilen-Anwendung, die die Komplexität des LLM-Betriebs hinter einer aufgeräumten Oberfläche und einer REST-API verbirgt.
Warum Ollama so gut funktioniert: Es kümmert sich um Modell-Downloads, die Auswahl der Quantisierung und die GPU-Konfiguration und stellt Ihr Modell über eine einfache HTTP-API bereit, die zum Format von OpenAI kompatibel ist. Bestehende Werkzeuge und Anwendungen, die für ChatGPT gebaut wurden, können Sie also mit minimalen Änderungen auf Ihr lokales Modell umstellen.
“`bash
ollama run mistral:latest
“`
Dieser eine Befehl lädt Mistral 7B in quantisierter Form herunter und öffnet eine interaktive Chat-Sitzung. Im Hintergrund übernimmt Ollama die Hardwareerkennung, die Speicherverwaltung und die Inferenz. Das Werkzeug ist zugänglich, aber nicht simpel: Sie haben Zugriff auf fortgeschrittene Funktionen wie Modell-Konfigurationsdateien (Modelfiles) zur Anpassung.
Ollama läuft unter macOS, Linux und Windows (unter Windows mit experimenteller GPU-Unterstützung). Die Community hilft ausgezeichnet, die Dokumentation ist klar, und das Werkzeug bekommt regelmäßig Updates. Wenn Sie LLMs in Anwendungen einbetten, ist die REST-API von Ollama zuverlässig und gut integriert.
Leistung: Ollama fügt minimalen Overhead hinzu. Auf derselben Hardware sehen Sie 95-100 % der Leistung, die Sie mit llama.cpp direkt hätten.
LM Studio: der GUI-Ansatz
Wenn Sie grafische Oberflächen der Kommandozeile vorziehen, ist LM Studio (lmstudio.ai) die ausgefeilte Alternative. Es ist eine Desktop-Anwendung zum Herunterladen und Konfigurieren von Modellen und zum Chatten mit ihnen.
Die Oberfläche ist intuitiv: verfügbare Modelle von Hugging Face durchsuchen, mit einem Klick herunterladen, Kontextfenster und GPU-Layer einstellen und losschreiben. Für nicht technische Nutzer oder schnelle Experimente ist das deutlich einfacher als Kommandozeilen-Werkzeuge.
LM Studio bietet außerdem eine lokale REST-API für den Zugriff aus Programmen und bindet SDKs für Python und JavaScript an. Es läuft unter Windows, macOS und Linux. Auf Apple Silicon nutzt es das MLX-Framework für optimierte Inferenz und liefert auf Macs merklich mehr Leistung als llama.cpp.
Leistung: Durch die Electron-basierte Oberfläche etwas mehr Overhead als Ollama, aber immer noch sehr konkurrenzfähig. Für die meisten Nutzer sind die Unterschiede in der Praxis vernachlässigbar.
Jan: die Alternative mit Fokus auf Datenschutz
Jan (jan.ai) positioniert sich als Open-Source-Alternative, bei der der Datenschutz an erster Stelle steht. Es ist neuer und weniger ausgereift als die bisher genannten Optionen, hat aber echte Stärken: ein Offline-first-Design, eine erweiterbare Architektur und aktive Entwicklung. Wenn Ihnen speziell der Datenschutz wichtig ist und Sie die Garantien von Open Source möchten, sollten Sie sich Jan ansehen. Es entwickelt sich noch, rechnen Sie also gelegentlich mit Ecken und Kanten.
Integration in IDEs: Continue und Cline
Wenn Sie entwickeln, verändert die direkte Einbindung lokaler LLMs in den Code-Editor Ihre Arbeitsweise grundlegend. Continue und Cline sind VS-Code-Erweiterungen, die sich mit lokalen Ollama-Instanzen verbinden und Code-Vervollständigung direkt im Editor sowie Code-Erzeugung bieten.
In der Praxis haben Sie damit einen fähigen Coding-Assistenten, der vollständig auf Ihrer Hardware läuft, mit null Latenz, null API-Kosten und vollständigem Datenschutz. Für viele Entwickler rechtfertigt das allein schon die Hardware-Investition.
Modelle: Welche funktionieren wirklich?
Das Angebot an fähigen Open-Weight-Modellen ist 2024-2025 explodiert. Diese Empfehlungen gehen davon aus, dass Sie praxistaugliche Modelle für echte Arbeit wollen, keine Benchmark-Helden.
Für den allgemeinen Einsatz
Mistral Small 3 (24B) ist für viele Nutzer der Sweet Spot. Es erschien Anfang 2025, erreicht in Benchmarks den Stand der Technik, kommt gut mit langen Kontexten zurecht und passt auf Karten ab 24 GB bequem in den VRAM. Tests aus der Praxis zeigen, dass es bei vielen Aufgaben mit GPT-4 mithalten kann und für Coding, Schreiben und Analyse wirklich nützlich ist. Es ist schnell: In quantisierter Form sehen Sie auf einer RTX 4090 30-50 Token pro Sekunde.
Qwen 3 (Varianten mit 4B, 14B und 32B) von Alibaba gehört zur neuesten Generation mehrsprachiger Modelle. Die 4B-Variante ist bemerkenswert: wirklich fähig und dabei auf praktisch jeder Hardware lauffähig. Die 32B-Variante ist außergewöhnlich für komplexes Reasoning. Besonders stark sind diese Modelle bei nicht englischen Sprachen und mehrsprachigen Aufgaben. Mit Kontext gehen sie ausgezeichnet um.
Phi-4 (14B) von Microsoft setzt den Trend zur Effizienz fort und eignet sich hervorragend für Code- und Reasoning-Aufgaben auf begrenzter Hardware. Trotz seiner kompakten Größe liefert es in gängigen Benchmarks starke Ergebnisse bei geringem Speicherbedarf, ideal also für Systeme mit knappem VRAM.
Llama 4 (8B, 70B, 405B) von Meta bleibt die vielseitigste Open-Weight-Familie. Die 70B-Variante ist ein Arbeitstier: auf einer 24-GB-Karte etwas langsamer als Mistral Small (wegen der Kontextgrenzen), aber für ein Modell dieser Größe immer noch beachtlich schnell und fähig. Wenn Sie rohe Leistungsfähigkeit brauchen, ist Llama 4 70B da.
GPT-OSS (120B), von OpenAI im August 2025 veröffentlicht, war eine echte Überraschung: das erste bedeutende Open-Weight-Modell von OpenAI seit GPT-2. Es verwendet eine Mixture-of-Experts-Architektur (120 Mrd. Parameter insgesamt, aber nur 5-6 Mrd. aktiv pro Token) und passt damit auf einzelne 80-GB-GPUs. Die Leistung ist stark und kann in vielen Benchmarks mit GPT-4o mithalten. Ein bemerkenswertes Vertrauensvotum für offene Modelle von dem Unternehmen, das am meisten darauf gesetzt hat, Modelle proprietär zu halten.
Für Coding-Aufgaben
Qwen 2.5 Coder und die Qwen-Coder-Varianten erreichen wirklich beeindruckende Benchmark-Werte bei Code-Erzeugung, Reasoning und Fehlerbehebung. Die 32B-Variante kann in manchen Coding-Benchmarks mit Claude Sonnet 3.5 mithalten. Wenn Code-Erzeugung Ihr Hauptzweck ist, sind das ausgezeichnete Optionen.
DeepSeek-Coder und seine Ableger bleiben starke Alternativen mit guter Mehrsprachigkeit und geringer Empfindlichkeit gegenüber Quantisierung.
Für anspruchsvolles Reasoning
DeepSeek-R1 (erschienen Ende 2024) brachte „Thinking“-Modelle in den Open-Weight-Bereich. Die Architektur arbeitet mit explizitem schrittweisem Reasoning, ähnlich wie das o1-Modell von OpenAI. Das vollständige DeepSeek-R1 hat 671 Mrd. Parameter (und braucht 8x A100-GPUs), es gibt aber destillierte Varianten, vor allem die Qwen-32B-Destillation, die die Leistung von o1-mini erreicht und auf einer einzigen RTX 5090 läuft. Wenn Sie systematisches Reasoning für Mathematik, Naturwissenschaft oder komplexe Probleme brauchen, sind diese Modelle einen Versuch wert.
Für kleine Geräte und Edge
Mistral 7B bleibt der Goldstandard für Umgebungen mit knappen Ressourcen. In den meisten Benchmarks schlägt es Llama 2 13B und ist dabei deutlich kleiner. Auf Q4 quantisiert passt es in 4-5 GB und liefert auf jeder aktuellen Hardware brauchbare Leistung.
Qwen-Modelle mit 4B, 3B und sogar 1.5B funktionieren bei einfacheren Aufgaben erstaunlich gut. Die 1.5B-Variante läuft auch auf Laptops und älteren GPUs gut. Die Qualität ist geringer, für bestimmte Anwendungen aber brauchbar.
Quantisierung: die Brücke zwischen Theorie und Praxis
Hier werden lokale LLMs praxistauglich. Quantisierung ist die Technik, mit der Modelle mit 70 Mrd. Parametern auf Consumer-Hardware laufen, ohne unbenutzbar langsam zu werden.
Warum Quantisierung funktioniert
Speichern Sie Modellgewichte im üblichen Gleitkommaformat (FP32), belegt jeder Parameter 32 Bit. Ein 70B-Modell braucht allein für die Gewichte 280 Gigabit Speicherplatz, also 280 Gigabyte. Und das noch ohne Overhead.
Quantisierung verringert die Genauigkeit dieser Gewichte. Eine 4-Bit-Quantisierung verwendet nur 4 Bit pro Parameter. Das 70B-Modell braucht dann 35 Gigabyte Speicherplatz. Die Qualität sinkt dabei nicht zwangsläufig im selben Verhältnis, und das ist der springende Punkt. Moderne Quantisierungstechniken sind ausgeklügelt: Sie erkennen, welche Teile des Modells am empfindlichsten auf Genauigkeitsverlust reagieren, und schützen diese, während sie weniger kritische Komponenten aggressiver quantisieren.
GGUF und K-Quants verstehen
Wenn Sie ein quantisiertes Modell herunterladen, liegt es meist im GGUF-Format vor. Der Dateiname verrät alles. Ein Modell namens `model.Q4_K_M.gguf` schlüsselt sich so auf:
– Q: Quantisiert
– 4: 4-Bit-Quantisierung (der gängigste Sweet Spot)
– K_M: Clustering-Verfahren K-Quants, Variante „Medium“
Die wichtigsten Quantisierungsstufen, denen Sie begegnen werden:
– Q2_K: Maximale Kompression, erheblicher Qualitätsverlust. Nur für extrem eingeschränkte Umgebungen.
– Q3_K: Bessere Qualität als Q2, immer noch sehr stark komprimiert. Für Fälle, in denen der VRAM absolut knapp ist.
– Q4_K_M: Der praktische Standard. 4-Bit-Quantisierung mit K-Quants, mittlere Variante. Verliert typischerweise <3 % Qualität und verkleinert das Modell gegenüber FP32 um 75 %.
– Q4_K_S / Q4_K_L: Kleine und große 4-Bit-Variante. S braucht weniger Speicher, L erhält mehr Qualität.
– Q5_K_M: 5-Bit-Quantisierung. Merklich bessere Qualität als Q4, dafür 25 % größere Dateien.
– Q6_K: 6 Bit. Noch näher an der Originalqualität, immer noch deutliche Kompression.
– Q8_0: 8 Bit. Minimaler Qualitätsverlust, nahe an voller Genauigkeit, aber größere Dateien.
In der Praxis hat sich Q4_K_M als Standard durchgesetzt. Es ist der Gleichgewichtspunkt: Bei den meisten Aufgaben ist kein Qualitätsverlust wahrnehmbar, die Modellgröße bleibt handhabbar, und die Inferenzgeschwindigkeit ist maximal.
Die tatsächliche Auswirkung auf die Leistung
Tests bestätigen, dass die Qualitätsempfindlichkeit von der Modellgröße abhängt. Große Modelle (ab 70B) sind relativ robust gegenüber Q4-Quantisierung. Kleinere Modelle (7B) verlieren etwas mehr Qualität, bei praktischen Aufgaben ist das aber meist nicht wahrnehmbar. Speziell für Retrieval-Augmented Generation (RAG) zeigt die Forschung, dass quantisierte 7B- und 8B-Modelle bei Aufgaben der Informationssuche fast genauso gut abschneiden wie FP16-Versionen.
Die praktische Empfehlung: Beginnen Sie mit Q4_K_M. Wenn Ihnen Qualitätsprobleme auffallen, versuchen Sie Q5_K_M. Wenn der VRAM knapp ist, versuchen Sie Q4_K_S oder Q3_K. Unter Q3 wird der Qualitätsverlust spürbar.
Leistung: echte Zahlen von echten Rechnern
Benchmarks hängen immer vom Kontext ab, aber hier sind tatsächliche Messungen auf aktueller Hardware:
RTX 4090 (24 GB VRAM)
– Mistral 7B (Q4_K_M): 45-55 Token/s
– Qwen 2.5 14B (Q4_K_M): 35-40 Token/s
– Qwen 2.5 32B (Q4_K_M): 15-20 Token/s (nahe am VRAM-Limit)
– Llama 3 70B (Q4_K_M): Braucht Layer-Offloading auf die CPU, 8-12 Token/s
– Prompt-Verarbeitung (32B-Modell bei 4K Kontext): 1.500-1.800 Token/s
RTX 5090 (32 GB VRAM)
– Qwen 2.5 32B (Q4_K_M): 25-35 Token/s
– Llama 3 70B (Q4_K_M): 18-25 Token/s (vollständig auf der GPU)
– Qwen 3 74B (Q4_K_M): 20-28 Token/s
– Prompt-Verarbeitung (70B-Modell bei 8K Kontext): 2.500-3.200 Token/s
Gebrauchte RTX 3090 (24 GB VRAM)
Bei der Inferenz ist die Leistung mit der RTX 4090 vergleichbar, denn der Bandbreitenunterschied wirkt sich nicht so stark aus wie beim Training. Typischerweise sind es 85-90 % der Leistung einer RTX 4090 auf denselben Modellen.
Apple M3 Ultra (512 GB Unified Memory)
– Mistral 7B (Q4_K_M): 25-35 Token/s
– Llama 3 70B (Q4_K_M): 12-18 Token/s
– Qwen 3 235B (FP8): 25-35 Token/s (ja, wirklich: Unified Memory und Bandbreite machen das möglich)
Die Effizienz des M3 Ultra ist bemerkenswert. Er erreicht eine respektable Inferenzgeschwindigkeit bei einem Bruchteil des Stromverbrauchs vergleichbarer NVIDIA-Systeme. Für Forschende, die mit sehr großen Modellen flexibel bleiben müssen, wird er trotz des hohen Preises immer attraktiver.
Nur CPU (DDR5-System, High-End-CPU)
– Mistral 7B (Q4_K_M): 3-5 Token/s
– Qwen 1.5 4B (Q4): 5-8 Token/s
Die Bandbreitengrenze ist deutlich. Konzentrieren Sie sich beim Betrieb nur mit CPU auf kleine Modelle und Workloads ohne Echtzeitanspruch.
Mehr als Chat: fortgeschrittene Techniken
Sobald die lokale Inferenz läuft, stehen Ihnen einige leistungsfähige Muster offen.
Retrieval-Augmented Generation (RAG)
RAG löst ein grundlegendes Problem: LLMs haben einen Wissensstichtag und können halluzinieren. Wenn Sie vor dem Erzeugen einer Antwort relevante Dokumente abrufen, stützen Sie die Ausgabe des Modells auf tatsächliche Daten.
In der Praxis sieht das so aus: Sie haben eine Sammlung von Dokumenten (PDFs, Artikel, Code usw.). Ein Retrieval-System (typischerweise semantische Suche mit Embeddings) findet die relevanten Dokumente. Diese Dokumente gehen als Kontext an das LLM. Das LLM erzeugt eine Antwort, die sich auf diesen Kontext stützt.
Für die Arbeit mit lokalen LLMs verändert RAG sehr viel. Kleine quantisierte Modelle mit RAG schlagen oft größere Modelle ohne Retrieval. Die Technik skaliert auch: Sie können Ihrer Wissensbasis Dokumente hinzufügen, ohne das Modell neu zu trainieren oder per Fine-Tuning anzupassen.
Werkzeuge wie LlamaIndex und LangChain vereinfachen die Umsetzung von RAG. Ein praktisches Beispiel: Mit Ollama, einem 7B-Modell und LlamaIndex können Sie auf einen Ordner mit PDFs zeigen und Fragen dazu stellen. Sie bekommen in Sekunden genaue Antworten mit Quellenangabe, alles lokal und privat.
Model Context Protocol (MCP)
MCP ist ein entstehender Standard, der LLMs Zugriff auf externe Werkzeuge und Daten gibt. Mit MCP kann ein lokales LLM einen Webbrowser steuern, Datenbanken abfragen, Code ausführen oder auf APIs zugreifen. Dabei bleibt alles unter Ihrer Kontrolle, mit lückenlosen Audit-Trails und gewahrtem Datenschutz.
Das steht noch am Anfang, reift aber rasch. Die Folgen sind weitreichend: Lokale LLMs werden zu echten Agenten, die mehrstufige Abläufe ohne Cloud-Dienste bewältigen.
Fine-Tuning und Anpassung
Ein Modell von Grund auf zu trainieren, braucht gewaltige Rechenleistung. Fine-Tuning dagegen, also die Anpassung eines vortrainierten Modells an Ihre Daten oder Ihren Stil, ist schon auf bescheidener Hardware machbar. LoRA (Low-Rank Adaptation) und ähnliche Techniken machen das praktikabel und brauchen manchmal nur wenige GB VRAM, um ein Modell an Ihren Anwendungsfall anzupassen.
In Spezialgebieten (Recht, Medizin, bestimmte Codebasen) zahlt sich dieser Aufwand oft aus.
Ihr System aufbauen: die praktische Konfiguration
Gehen wir ein funktionierendes lokales LLM-System von der nackten Hardware an durch.
Zusammenbau der Hardware (für ein System mit GPU)
1. Beginnen Sie mit einem hochwertigen Netzteil. Wenn Sie eine GPU mit 450 W planen, sollte das Netzteil mindestens 850 W haben, um Lastspitzen abzufangen. Gute Netzteile sparen auf Dauer Geld.
2. Sorgen Sie für ausreichende Kühlung. Die GPU-Temperatur sollte unter Last unter 80 °C bleiben. Wenn Ihr Gehäuse keinen guten Luftstrom hat, rüsten Sie es auf, bevor Sie die GPU aufrüsten. Thermal Throttling ruiniert die Leistung.
3. Sparen Sie nicht beim RAM. Auch mit GPU-Offloading zählt der Systemspeicher. 32 GB sind für 2025 ein vernünftiges Minimum. 64 GB sind besser, wenn neben der GPU-Inferenz auch CPU-Aufgaben laufen.
4. Speicherplatz: Modelle sind groß. Ein 70B-Modell in Q4-Quantisierung hat mehr als 35 Gigabyte. Für brauchbare Ladezeiten sind NVMe-SSDs unverzichtbar.
Einrichtung der Software
Linux (für die beste Leistung empfohlen)
Linux bleibt die ausgereifteste Plattform für lokale LLMs. Installieren Sie CUDA 12.8+ (oder ROCm für AMD). Laden Sie Ollama oder LM Studio herunter. Starten Sie Modelle. Das Ganze läuft stabil und schnell.
“`bash
# Install Ollama
curl https://ollama.ai/install.sh | sh
# Download and run a model
ollama run mistral:latest
# Model is now available at http://localhost:11434/api/chat
“`
Windows
Wird inzwischen vollständig unterstützt. Ollama hat unter Windows im Jahr 2024 den Funktionsumfang von Linux erreicht. LM Studio funktioniert ausgezeichnet. Die Installation ist unkompliziert. Die GPU-Unterstützung ist solide.
macOS
Funktioniert gut, besonders auf Apple Silicon. Durch die MLX-Integration ist LM Studio das bevorzugte Werkzeug für Mac-Nutzer und liefert merklich mehr Leistung als CPU-basierte Backends.
Checkliste für die Erstkonfiguration
1. Prüfen Sie, ob CUDA installiert ist und erkannt wird: `nvidia-smi` sollte Ihre GPU anzeigen.
2. Laden Sie zum Testen ein kleines Modell herunter: `ollama pull mistral:latest` (2,6 GB, schnell)
3. Prüfen Sie, ob es läuft: `ollama run mistral:latest`
4. Wenn Sie Anwendungen verwenden, die sich mit der Ollama-API verbinden, prüfen Sie die Verbindung: `curl http://localhost:11434/api/tags`
5. Beobachten Sie während der Inferenz die Ressourcennutzung: Läuft Ihre GPU auf 100 %? Ist die Speicherbandbreite der Engpass? Diese Beobachtungen helfen bei der Modellwahl.
Schnellstart in 5 Minuten
So kommen Sie sofort mit lokalen LLMs in Gang. Wählen Sie Ihre Plattform und folgen Sie den Befehlen unten.
Für Ollama (läuft unter Linux, macOS, Windows)
Installation und erstes Modell (unter macOS/Linux):
“`bash
# Install Ollama
curl https://ollama.ai/install.sh | sh
# Start the Ollama service
ollama serve &
# In a new terminal, download and run Mistral 7B
ollama pull mistral:latest
# Chat with the model
ollama run mistral:latest
# Type your question and press Enter. Type "/bye" to exit.
# The model is now accessible via API at http://localhost:11434
curl http://localhost:11434/api/generate -d ‘{
"model": "mistral:latest",
"prompt": "Why is the sky blue?",
"stream": false
}’
“`
Installation unter Windows:
– Laden Sie das Installationsprogramm von https://ollama.com herunter
– Starten Sie das Installationsprogramm und folgen Sie den Anweisungen
– Öffnen Sie PowerShell und führen Sie aus: `ollama run mistral:latest`
– Chatten Sie im Terminalfenster, das sich öffnet
Andere Modelle laden:
“`bash
# Qwen 7B (multilingual, fast)
ollama pull qwen:7b-chat-q4_K_M
ollama run qwen:7b-chat-q4_K_M
# Llama 3 8B (general purpose)
ollama pull llama2:7b
ollama run llama2:7b
# Mistral Small 3 24B (high quality, requires 24GB VRAM)
ollama pull mistral:small
ollama run mistral:small
“`
Für LM Studio (GUI, läuft unter macOS, Windows, Linux)
Installation und Einrichtung:
1. Herunterladen und installieren:
– Gehen Sie auf https://lmstudio.ai
– Laden Sie die Version für Ihr Betriebssystem herunter
– Installieren und starten Sie LM Studio
2. Ein Modell laden:
– Klicken Sie links in der Seitenleiste auf das Suchsymbol (Lupe)
– Suchen Sie nach „Mistral 7B Q4“
– Klicken Sie neben `mistral-7b-instruct-v0.2.Q4_K_M.gguf` auf die Download-Schaltfläche
– Warten Sie, bis der Download abgeschlossen ist (~5 GB)
3. Losschreiben:
– Klicken Sie oben auf den Tab „Chat“
– Wählen Sie das heruntergeladene Modell aus der Dropdown-Liste
– Klicken Sie auf „Load Model“
– Schreiben Sie ins Chat-Feld und drücken Sie Enter
4. API-Zugriff aktivieren (optional):
– Gehen Sie zum Tab „Developer“
– Klicken Sie auf „Start Server“
– Ihr Modell ist jetzt unter `http://localhost:1234/v1/chat/completions` erreichbar
– Sie können es mit jedem OpenAI-kompatiblen Client nutzen
Profi-Tipps:
– Beginnen Sie mit Mistral 7B oder Qwen 7B, wenn Ihre GPU <16 GB VRAM hat
– Verwenden Sie Mistral Small 3 (24B) für bessere Qualität, wenn Sie mindestens 24 GB VRAM haben
– Beobachten Sie die GPU-Auslastung im unteren Bereich von LM Studio, Ziel sind mehr als 95 %
– Wenn die Antworten langsam kommen, stellen Sie sicher, dass die GPU verwendet wird (nicht die CPU)
Häufige Stolpersteine und Lösungen
Das Modell ist langsam: Die erste Frage: Wird Ihre GPU überhaupt verwendet? Prüfen Sie das mit `nvidia-smi`. Wenn die GPU untätig ist und die CPU am Anschlag läuft, haben Sie ein Problem mit dem GPU-Offloading. Passen Sie in Ollama den Parameter `num_gpu` an. Erhöhen Sie in LM Studio die Anzahl der GPU-Layer. Das Ziel ist eine GPU-Auslastung von 99 %.
Abstürze wegen Speichermangels: Der KV-Cache (der Arbeitsspeicher des Modells) wächst mit der Kontextlänge. Verkleinern Sie Ihr Kontextfenster. Für ein 30B-Modell sind auf 24 GB VRAM 2K-4K Token Kontext vernünftig. 8K Token verlangen mindestens 32 GB.
Die Qualität wirkt schlechter: Vermutlich liegt es an der Quantisierung. Versuchen Sie eine höherwertige Stufe (Q5_K_M statt Q4_K_M). Wenn das hilft, ist die Quantisierung das Problem, und Sie brauchen womöglich mehr VRAM. Wenn nicht, liegt es am Modell: Versuchen Sie ein anderes Basismodell.
Schwankende Leistung: Prüfen Sie, ob Thermal Throttling vorliegt. GPU-Temperaturen über 85 °C führen oft zu Leistungseinbußen. Verbessern Sie den Luftstrom im Gehäuse oder die Kühlung.
Gelegentliche Halluzinationen oder unsinnige Ausgaben: Das gehört weitgehend zum Wesen von LLMs, die Quantisierung hat daran wenig Anteil. Stützen Sie Antworten mit RAG auf tatsächliche Daten. Formulieren Sie Ihre Prompts genauer.
Die Wirtschaftlichkeit: Lohnt sich lokal?
Die Hardwarekosten müssen Sie gegen die Alternativen abwägen.
Bei gelegentlicher Nutzung: Cloud-APIs (Claude, GPT-4) sind billiger. Die API-Kosten sind so niedrig, dass die Cloud wirtschaftlicher bleibt, solange Sie nicht Millionen von Token im Monat erzeugen.
Bei 1-10 Millionen Token im Monat: Eine einzelne RTX 5090 (2.500 $) mit lokalen LLMs rechnet sich gegenüber intensiver Cloud-API-Nutzung innerhalb von 3-6 Monaten. Rechnen Sie den Strom ein (grobe Schätzung: 500-800 $ im Jahr), und die Rendite ist klar.
Für Teams und Organisationen: Hier verschiebt sich die Rechnung weiter zum lokalen Deployment. Datenschutzvorschriften (HIPAA, DSGVO) verlangen manchmal lokale Verarbeitung. Die Abhängigkeit von einem Anbieter wird zur strategischen Frage. Ein hybrider Ansatz, lokales Deployment für sensible Arbeit und die Cloud für allgemeine Aufgaben, findet sich immer häufiger.
Für Forschung und Entwicklung: Lokales Deployment ist fast unumgänglich. Schnelle Iteration, unbegrenztes Experimentieren und kostenlose Inferenz im großen Maßstab sind von unschätzbarem Wert.
Der weitere Weg
Das Ökosystem lokaler LLMs bewegt sich schnell. Das hat sich zwischen 2024 und 2025 geändert:
– Modellqualität: In vielen Benchmarks nähern sich die Modelle der Qualität geschlossener Modelle an. Qwen 3, DeepSeek-R1 und andere können es wirklich mit kommerziellen Angeboten aufnehmen.
– Reife der Werkzeuge: Ollama, LM Studio und Co. sind produktionsreif. Der Aufwand für die lokale Einrichtung ist drastisch gesunken.
– Hardware-Effizienz: Quantisierung und Destillation werden ständig besser. Die Modelle werden stärker und brauchen weniger Ressourcen.
– Funktionen im Ökosystem: RAG, MCP, multimodale Modelle und die Nutzung von Werkzeugen wandeln sich bei offenen Modellen vom Experiment zur Praxis.
Der Blick auf Ende 2025 und darüber hinaus:
– Quantisierung der nächsten Generation: Es entstehen dynamische Quantisierungstechniken, die verschiedene Layer unterschiedlich genau behandeln. Modelle dürften dadurch noch effizienter laufen.
– Konsolidierung bei multimodalen Modellen: Offene Modelle für Bild und Sprache werden rasch besser. Lokale Bild-zu-Text-Umwandlung und Reasoning über Bilder werden praxistauglich.
– Spezialisierte Hardware: Eigene Chips für die LLM-Inferenz (Huawei Ascend, eigene NPUs) kommen auf den Markt. Die CPU-Inferenz wird besser.
– Edge-Deployment: Weil die Modelle schrumpfen und zugleich mehr können, dürften lokale LLMs auf Smartphones und Edge-Geräten vom Kuriosum zur Normalität werden.
Fazit: ein neuer Standard
Lokale LLMs haben eine Schwelle überschritten. Sie sind kein Hobbyexperiment und keine akademische Kuriosität mehr, sondern für viele Anwendungen eine praktische, kostengünstige und datenschutzfreundliche Alternative zu Cloud-APIs.
Die Hardware-Investition ist real, aber zunehmend vertretbar. Eine GPU mit 24 GB, ob gebrauchte RTX 3090 oder neue RTX 5090, ermöglicht echte, produktive Arbeit. Die Software ist ausgereift und benutzerfreundlich. Die Modelle sind fähig.
Wenn Ihnen Datenschutz wichtig ist, Sie Kostensicherheit oder Anpassungen brauchen oder Ihre KI-Infrastruktur einfach selbst besitzen wollen, ist jetzt der richtige Zeitpunkt für den Umstieg auf lokal. Die Einstiegshürde ist gesunken. Die Fähigkeiten sind da. Und die Unabhängigkeit ist es wert. Die gemeinsame Lehre aus allen Benchmarks: Sobald die Speicherbandbreite zur Obergrenze wird, bringt mehr Rechenleistung immer weniger.
Anhang: Kurzreferenz
Empfohlene Konfigurationen nach Einsatzzweck
Schreibende und Forschende mit knappem Budget:
– Gebrauchte RTX 3090 + Ollama + Mistral 7B
– Kosten: ~1000 $ | Leistung: 35+ Token/s | Empfohlen
Entwickler (Hauptrechner):
– RTX 4070 Ti Super + LM Studio + Qwen 2.5 14B
– Kosten: ~1200 $ | Leistung: 25+ Token/s | Empfohlen
Ernsthafte Arbeit mit lokalen LLMs:
– RTX 5090 + Ollama + Mistral Small 3 (24B)
– Kosten: ~2500 $ | Leistung: 50+ Token/s | Besonders empfohlen
Apple-Ökosystem:
– Mac Studio M3 Ultra 512 GB + LM Studio + Qwen 3 (32B)
– Kosten: ab 7000 $ | Leistung: 30+ Token/s | Alternative, wenn Sie im Ökosystem sind
Entwickler mit Fokus auf Code:
– RTX 4090 + Ollama + Qwen 2.5 Coder 32B
– Kosten: ~2000 $ | Leistung: 20+ Token/s | Empfohlen
Referenztabelle der GPU-Spezifikationen
Kurzreferenz zum Vergleich der GPUs aus diesem Leitfaden. Die Token/s-Werte sind grobe Schätzungen für Q4_K_M-quantisierte Modelle bei üblichen Batch-Größen (1-8) mit Single-Stream-Inferenz.
| GPU-Modell | VRAM | Speicherbandbreite | Typische Modelle | Bereich in Token/s | Am besten für |
|---|---|---|---|---|---|
| Intel Arc B580 | 12 GB | ~190 GB/s | 7B | 5-12 t/s | Günstiger Einstieg |
| RTX 4060 Ti | 16 GB | ~540 GB/s | 7B-13B | 8-15 t/s | Konservativer Einstieg |
| Gebrauchte RTX 3090 | 24 GB | ~936 GB/s | 30B | 25-35 t/s | Preis-Leistungs-Sieger |
| RTX 4070 Ti Super | 16 GB | ~576 GB/s | 7B-13B | 15-25 t/s | Neu + Gaming |
| RTX 4090 | 24 GB | ~1.008 GB/s | 30B-70B | 40-60 t/s | Hohe Leistung |
| RTX 5090 | 32 GB | ~1.792 GB/s | 70B-120B | 60-100 t/s | Flaggschiff (2025) |
| Apple M3 Max | 48 GB Unified | 400 GB/s | 30B-70B | 12-18 t/s | Apple-Ökosystem |
| Apple M4 Max | 36 GB Unified | 500+ GB/s | 30B-70B | 15-22 t/s | Neuester Apple-Chip |
| DGX Spark | 128 GB Unified | 273 GB/s | 70B-200B | 30-40 t/s (Decode) | Große Modelle, Prefill |
| Nur CPU (DDR5) | System-RAM | 150 GB/s | 3B-7B | 1-5 t/s | Keine GPU vorhanden |
So lesen Sie die Tabelle:
– Die Speicherbandbreite ist der wichtigste Leistungshebel für die Token-Erzeugung (Decode-Phase)
– Die Token/s schwanken je nach Modell, Quantisierung, Kontextlänge und Systemzustand erheblich
– Höhere Bandbreite schlägt bei der LLM-Inferenz durchwegs höhere Rechenleistung
– Für die interaktive Nutzung geben Sie der Bandbreite den Vorrang vor der reinen Rechenleistung
– Apples Unified-Memory-Systeme profitieren von ihrer hohen Bandbreite (400+ GB/s), haben aber geringeren absoluten Durchsatz als High-End-GPUs
Download-Quellen
– Ollama: ollama.com
– LM Studio: lmstudio.ai
– LlamaIndex: llamaindex.ai (für RAG)
– Modelle: huggingface.co (nach dem GGUF-Format suchen)
Überwachung während der Inferenz
“`bash
# On Linux/Mac, watch GPU usage during inference
watch -n 1 nvidia-smi
# Check Ollama’s logs
journalctl -u ollama -f # Linux with systemd
tail -f ~/.ollama/logs/server.log # Alternative
“`
Beobachten Sie, bis Ihre GPU bei 95-99 % Auslastung liegt. Wenn sie darunter bleibt, liegt der Engpass woanders (vermutlich bei CPU oder Systemspeicher).
Quellen und Literatur
Wissenschaftliche Arbeiten und Forschung
NVIDIA Research (2025). „Efficient LLM Inference: Bandwidth, Compute, Synchronization, and Capacity Are All You Need.“ Davies, Michael, Neal Crago, Karthikeyan Sankaralingam und Christos Kozyrakis. arXiv:2507.14397. https://arxiv.org/abs/2507.14397. Zeigt, dass der Inferenzdurchsatz bei Transformer-basierten Sprachmodellen vor allem mit der Speicherbandbreite skaliert.
Barcelona Supercomputing Center und IBM Research (2025). „Mind the Memory Gap: Unveiling GPU Bottlenecks in Large-Batch LLM Inference.“ Recasens, Pol G., Ferran Agullo, Yue Zhu, Chen Wang, Eun Kyung Lee, Olivier Tardieu, Jordi Torres und Josep Ll. Berral. arXiv:2503.08311. https://arxiv.org/abs/2503.08311. Die Studie bestätigt, dass GPUs mit reichlich Rechenreserven bei Inferenzaufgaben an die Bandbreitengrenze stoßen, während die Recheneinheiten untätig bleiben. Angenommen bei IEEE CLOUD 2025.
Databricks (2025). „LLM Inference Performance Engineering: Best Practices.“ https://www.databricks.com/blog/llm-inference-performance-engineering-best-practices. Blogbeitrag zum Leistungsverhalten des ersten und der folgenden Token bei der LLM-Inferenz: Die Erzeugung des ersten Tokens ist durch die Rechenleistung begrenzt, die folgenden Token durch den Speicher.
Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., Kaiser, Ł., & Polosukhin, I. (2017). „Attention Is All You Need.“ Advances in Neural Information Processing Systems, 30. arXiv:1706.03762. https://arxiv.org/abs/1706.03762. Grundlegendes Paper, das die Transformer-Architektur einführt, auf der alle modernen großen Sprachmodelle beruhen.
Software-Werkzeuge und Frameworks
Ollama: Runner und Inferenz-Engine für lokale LLMs. https://ollama.com
LM Studio: Desktop-Anwendung zum Betrieb lokaler Sprachmodelle. https://lmstudio.ai
LlamaIndex: Framework für den Bau von Systemen mit Retrieval-Augmented Generation (RAG). https://llamaindex.ai
vLLM: Open-Source-Inferenz-Engine für LLMs, optimiert auf Durchsatz und Speichereffizienz. https://vllm.ai
GGUF-Format: Format für quantisierte Modelle, das effiziente lokale Inferenz auf unterschiedlichster Hardware ermöglicht. https://huggingface.co/docs/hub/gguf
Modell-Repositories und Ressourcen
Hugging Face Model Hub: Repository für Open-Weight-Modelle in GGUF und anderen Formaten. https://huggingface.co
LMSYS Chatbot Arena Leaderboard: laufende Bewertung und Benchmarks von Sprachmodellen. https://lmarena.ai/
Erwähnte Open-Weight-Modelle
– Qwen 3: Offenes Modell auf dem Stand der Technik, nahe an der Qualität geschlossener Modelle
– DeepSeek-R1: Offenes, auf Reasoning ausgerichtetes Modell, das mit kommerziellen Angeboten konkurriert
– Mistral 7B und Varianten: Effizientes 7B-Basismodell und spezialisierte Varianten (Small 3, Coder)
– Llama 3.1: Hochwertige offene Modellfamilie von Meta
– Phi 4: Effiziente Modellreihe von Microsoft
– Neural Chat: Für Intel optimiertes Konversationsmodell
– Starling-7B: Von der Community trainiertes Modell mit GPT-4-Destillation
Hardware-Dokumentation
NVIDIA CUDA Documentation: Offizielle Dokumentation zur CUDA-Entwicklung und GPU-Beschleunigung. https://docs.nvidia.com/cuda/
NVIDIA NVLink Architecture: Technische Spezifikationen der GPU-Verbindung mit hoher Bandbreite. https://en.wikipedia.org/wiki/NVLink
Apple Metal Performance Shaders: Apples Framework zur GPU-Beschleunigung für Metal. https://developer.apple.com/metal/
Intel Arc GPU Documentation: Intels Architektur für diskrete GPUs und der zugehörige Software-Stack. https://www.intel.com/content/www/us/en/developer/articles/guide/arc-discrete-graphics.html
AMD ROCm Documentation: AMDs Gegenstück zu CUDA für GPU-Berechnungen. https://rocmdocs.amd.com/
Branchenstandards und Benchmarks
Forschung und Methoden zur Quantisierung:
– GPTQ (2022): Frantar, E., Ashkboos, S., Hoover, B., & Dettmers, T. „GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers.“ https://github.com/IST-DASLab/gptq
– SmoothQuant (2023): Xiao, G., Lin, Y., & Han, S. „SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models.“ ICML 2023. https://arxiv.org/abs/2211.10438
– AWQ (2024): Lin, Y., Tang, H., Yang, S., Zhang, Z., Xiao, G., Gan, C., & Han, S. „Awq: Activation-aware weight quantization for on-device llm compression and acceleration.“ MLSys 2024.
– LLM.int8() (2022): Dettmers, T., Lewis, M., Belkada, Y., & Zettlemoyer, L. „LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale.“ NeurIPS 2022. https://arxiv.org/abs/2208.07339
– Model Compression and Efficient Inference for Large Language Models: A Survey (2024): Umfassender Überblick über Quantisierungstechniken. https://arxiv.org/abs/2402.09748
– Resource-Efficient Language Models: Quantization for Fast and Accessible Inference (2025): Überblick über Quantisierungsmethoden von 3 Bit bis zu voller Genauigkeit. https://arxiv.org/abs/2505.08620
Paper zur Transformer-Architektur: Grundlegende Forschung zu Transformer-basierten Sprachmodellen und ihrer Effizienz.
– Vaswani et al., „Attention Is All You Need“ (2017): https://arxiv.org/abs/1706.03762
Weitere Ressourcen
Spezifikationen der NVIDIA-GPUs: Technische Datenblätter und Spezifikationen der genannten RTX-GPUs (RTX 4060 Ti, 4070 Ti Super, 4090, 5090, 3090):
– RTX 5090: 32 GB GDDR7, ~1.792 GB/s Bandbreite, 575 W TGP (offizielle Angaben)
– RTX 4090: 24 GB GDDR6X, ~1.008 GB/s Bandbreite, 450 W TGP
– RTX 3090: 24 GB GDDR6X, ~936 GB/s Bandbreite, 420 W TGP
Spezifikationen von Apple Silicon/: Technische Dokumentation zu den Architekturen der M-Chips und ihren Unified-Memory-Systemen:
– M3 Pro: 150 GB/s Unified-Memory-Bandbreite
– M3 Max (GPU mit 30 Kernen): 300 GB/s
– M3 Max (GPU mit 40 Kernen): 400 GB/s
– M4 Max: >0,5 TB/s (>500 GB/s)
Spezifikationen der DGX Spark: Technische Details und Preise:
– 128 GB LPDDR5X Unified Memory mit 273 GB/s Bandbreite
– Verfügbar ab Oktober 2025; Listenpreis 3.999 $
– 240 W Thermal Design
Modelldateien: Referenz zu Quantisierung und VRAM-Bedarf:
– Llama 3 70B Q4_K_M: ~42-43 GB (passt nicht in 32 GB VRAM ohne Offload oder aggressive 3-Bit-Quantisierung)
– Llama 3 70B FP16: ~140 GB
– Llama 3 30B Q4_K_M: ~15-18 GB
Python und Entwicklungswerkzeuge: PyTorch, Hugging Face Transformers und verwandte ML-Frameworks.
Aus dem Englischen übersetzt: zum Originalbeitrag