Die spannendste Kennzahl für lokale KI steht nicht groß auf der Verpackung. Sie heißt Speicherbandbreite, wird in Gigabyte pro Sekunde gemessen und entscheidet, ob ein Modell auf der eigenen Maschine flüssig läuft oder nur ruckelnd vor sich hin stirbt. Wer KI ernsthaft ausprobieren will und sich auf die TOPS- und NPU-Zahlen verlässt, sucht am falschen Ort. Rechenleistung ist billig geworden. Bandbreite ist die knappe Ressource.

Das klingt kontraintuitiv, und das ist sie auch. Deshalb lohnt sich ein genauerer Blick — nicht auf Benchmark-Siegerlisten, sondern auf das, was wirklich im Gehäuse passiert, wenn ein Modell Token für Token zusammensetzt.

Warum die Bandbreite gewinnt

Sprachmodelle arbeiten autoregressiv. Jedes nächste Wort entsteht, nachdem das gesamte bisher erzeugte Gewicht einmal durch den Speicher geströmt ist. Die Multipliziereinheiten warten also nicht auf schwere Mathematik — sie warten auf Speicher. Wer das verstanden hat, versteht auch, warum eine Grafikkarte mit wenig VRAM an einem großen Modell nichts nützt, egal wie schnell ihre Shader takten: Das Modell muss hereinpassen und in jedem Schritt hindurchfließen.

Grob gesagt: Tokens pro Sekunde approximieren Speicherbandbreite dividiert durch Modellgröße. Ein 70-Milliarden-Parameter-Modell in 4-Bit-Quantisierung belegt knapp vierzig Gigabyte. An einer Pipe von 273 GB/s strömen das theoretisch rund sieben Token pro Sekunde — Minus Overhead, Minus KV-Cache, Minus alles, was das Betriebssystem nebenbei noch treibt. An einer gewöhnlichen Laptop-DDR mit 64 GB/s wird dieselbe Rechnung zur Geduldprobe. Die Rechenkerne sitzen beide Male untätig herum. Der Unterschied liegt ausschließlich darin, wie breit die Leitung ist.

Genau deshalb sind in letzter Zeit Chips interessant geworden, die niemand auf der Liste für „KI-Beschleuniger" gehabt hätte.

Zwei Chips, die niemand auf dem Zettel hatte

Da ist zum einen der Apple M4 Pro. Apple gibt für ihn rund 273 GB/s unified-memory-Bandbreite an — ein gemeinsamer Speicher für CPU und GPU, konfigurierbar bis 48 Gigabyte. Nichts daran ist ein Datacenter-Beschleuniger. Aber weil der Speicher so breit angebunden ist und weil er für CPU und Grafikeinheit gleichermaßen sichtbar ist, laufen mittelgroße Modelle überraschend flüssig. Das ist kein Marketingzauber, das ist Physik.

Zum anderen der AMD Ryzen AI Max+ 395, Codename Strix Halo. AMD gibt bis zu 256 GB/s an, ebenfalls unified, und die Plattform fasst bis zu 128 Gigabyte LPDDR5X. Man findet ihn in kompakten Mini-PCs, Workstation-Laptops und Geräten wie dem Framework Desktop. Wieder gilt: kein H100, keine Wundermaschine. Aber wer ein großes Modell vollständig in den schnellen Speicher legen kann, während die Konkurrenz-Karte längst in Out-of-Core-Swapping erstickt, gewinnt plötzlich realistische Durchsätze für Geld, das anderweitig kaum einen Bruchteil einer professionellen Karte gekostet hätte.

Ehrlichkeit ist hier Pflicht. Beide Chips sind keine Magie. Thermisches Throttling unter Dauerlast ist real, gerade in schmalen Gehäusen. Treiber und Runtime-Reife unterscheiden sich: Apples Metal-Pfad ist glatt, AMDs ROCm/OCL-Strecke hat Fortschritte gemacht, bleibt aber holpriger als die CUDA-Welt, gegen die sich alles messen muss. Und natürlich bleibt ein einzelner Desktop-Chip meilenweit unter dem, was ein H200- oder B200-Karte im Rack leistet. Behauptungen, lokale Consumer-Hardware sei „genauso gut", sind Unsinn. Behauptungen, sie seien uninteressant, sind es ebenfalls.

Eine trockene Nebenbeobachtung: Benchmark-Diagramme lügen routinemäßig, weil sie die Latenz bis zum ersten Token an einem warmen Cache messen — nicht Dienstagmittag, bei sechs offenen Tabs und einem Modell, das gerade halb ausgelagert ist. Wer KI plant, sollte unter Last messen, nicht unter Labor.

Phase eins: Klicken und staunen

Der natürliche Einstieg führt über Desktop-Apps. Ollama zieht ein GGUF, LM Studio bietet eine ordentliche Oberfläche zum Stöbern in Modellen, Vergleichen von Quantisierungen und Ausprobieren. Das ist wertvoll. Es ist der schnellste Weg, ein Gespür dafür zu entwickeln, wie sich ein 8B-, 13B- oder 32B-Modell anfühlt, wo die Qualitätskurve abknickt, wo 4-Bit noch tragbar ist und wo es nicht mehr ist.

Diese Phase ist spielerisch, und sie soll es sein. Wer hier sofort „Architektur" ruft, verpasst den Punkt: Man muss fühlen, was die Werkzeuge tun, bevor man sie formalisiert. Aber die Grenzen zeigen sich bald. Alles ist auf eine Maschine, auf einen Benutzer, auf eine grafische Sitzung gebunden. Sobald der zweite Mensch ans Modell will, sobald ein Skript nachts automatisch inferieren soll, wird die GUI zum Hindernis. Netzwerkzugriff fühlt sich angeklebt an, nicht entworfen.

Phase zwei: Der Schreibtisch wird zum Server

Irgendwann kommt der Moment, in dem das nicht mehr reicht. Man möchte einen Endpunkt, den das ganze Büro, das ganze Haushaltsnetz, alle Automatisierungen erreichen. Man bindet Ollama oder einen leichtgewichtigen Runner an ::, stellt OpenWebUI davor — mehrere Nutzer, Authentifizierung, Modellauswahl, Dokumenten-Chat — und richtet Werkzeuge wie opencode, den CLI-Coding-Agenten, auf den lokalen, OpenAI-kompatiblen Endpunkt ein.

Plötzlich ist die Workstation Infrastruktur. Jeder Editor, jede Kollegin, jede Pipeline spricht mit derselben Adresse. Das ist ein echter Paradigmenwechsel, auch wenn er technisch klein aussieht: aus einer Anwendung wird ein Dienst. Und mit dem Dienst kommen die Pflichten, die man von Infrastruktur kennt — Transportverschlüsselung, Authentifizierung, Protokollierung, Updates, Modell-Governance. Wer diesen Schritt tut, hat aufgehört, zu basteln, und angefangen, zu betreiben. Viele merken das erst, wenn das erste Mal jemand anderes auf das Modell zugreift.

Phase drei: Wenn es aufhört, ein Spielzeug zu sein

Mit wachsendem Anspruch folgt die nächste Ebene der Werkzeuge. vLLM ist die Engine, die GPU-Inferenz wirtschaftlich gemacht hat — Continuous Batching, PagedAttention, hoher Durchsatz, sauberer Umgang mit vielen gleichzeitigen Anfragen. LiteLLM setzt sich davor als Proxy und Router: eine einheitliche, OpenAI-förmige API über viele Backends hinweg, Schlüsselverwaltung, Fallback-Pfade, Budget-Routing, Anbindung an Metrik- und Logging-Systeme. Und Bifrost ist die Sorte Projekt, der man begegnet, sobald man anfängt, GPU-Kapazität über mehrere Workloads oder Mandanten hinweg zu poolen und zu teilen, statt eine Karte exklusiv einem Prozess zu widmen — Utilisierung statt Hero-Box.

Diese Werkzeuge belohnen größere Hardware: mehrere GPUs pro Knoten, NVLink-Verbindungen, ein Rack statt eines Schreibtischs. Sie bestrafen aber auch Nachlässigkeit härter. Continuous Batching hilft nur, wenn genug Anfragen gleichzeitig kommen — beim einzelnen Power-User zahlt sich der Overhead nicht aus. Ein Router nützt nichts, wenn dahinter nur ein lahmes Backend steht. Pooling funktioniert nur, wenn Fairness, Queue-Längen und Kaltstarts ernsthaft gemanagt werden. Kurz: An dieser Stelle hört das Ausprobieren auf und fängt verteiltes System an. Monitoring, Scheduling, Kostenzurechnung, Update-Strategien — alles Themen, die man aus dem klassischen IT-Betrieb kennt und die jetzt, unerwartet, zur KI gehören.

Viele Homelabber stoßen an diese Wand und treffen eine von zwei Entscheidungen: zurück auf eine bequeme Einzelbox, die gut genug ist — oder der bewusste Schritt in den richtigen Betrieb. Beides legitim. Aber wer glaubt, er käme mit einem weiteren Klick drumherum, irrt sich.

Die schwere Kunst: Hard- und Software zusammen denken

Hier liegt der eigentlichen Schwierigkeit. Weder Hardware allein noch Software allein gewinnen. Es kommt auf die Paarung an.

Wer eine riesige GPU kauft und sie über einen einspaltigen Runner ohne Batching anbindet, verschenkt neunzig Prozent ihrer Leistung. Wer vLLM für einen Arbeitsplatz mit einem einzelnen Nutzer aufsetzt, zahlt Overhead ohne Gegenwert. Wer ein großes Modell in 4-Bit quetscht, wo 8-Bit qualitativ nötig gewesen wäre, spart Speicher und verliert Präzision. Wer umgekehrt alles in FP16 laufen lässt, weil „höher besser" klingt, passt in weniger VRAM und friert ein. Quantisierung ist kein Schalter, sondern ein Dial. Kühlung, Geräuschpegel und Dauerstromverbrauch entscheiden darüber, ob ein Gerät im Wohnzimmer leben darf oder ins Kellerlab muss. Abschreibung gehört in die Rechnung, nicht in die Fußnote.

Und dann der Elefant im Raum, den niemand gerne sieht: API-Preise. Sie wirken günstig — Cent-Beträge pro Million Token —, bis das Volumen eskaliert. Agentic Loops multiplizieren Anfragen oft um den Faktor zehn bis hundert. Retry-Stürme, redundante Retrieval-Durchläufe, geschwätzige System-Prompts, die in jedem Turn erneut verschickt werden, ein falsch dimensioniertes Modell für eine triviale Aufgabe: Aus einem billigen Experiment wird eine vierstellige Monatsrechnung. Die Methode bestimmt den Preis stärker als der Tarif.

Self-Hosting kehrt das um: feste Kosten statt variabler. Irgendwo bricht es wirtschaftlich, aber nur bei anständiger Auslastung. Eine GPU, die rund um die Uhr leertrödelt, vereint die Nachteile beider Welten — Anschaffung und Opportunitätskosten. Romantik hilft hier nicht. Es gehört Mathematik dazu, und es gehört Ehrlichkeit dazu, die eigene Auslastung realistisch einzuschätzen, statt sie zu idealisieren.

Ein Grund zum Feiern

Trotz aller Mühen gibt es einen Grund zum Feiern, und er wiegt schwer: Die gesamte oben beschriebene Leiter ist Open Source. Ollama, llama.cpp, vLLM, LiteLLM, Bifrost, OpenWebUI, opencode — Community-gebaut, forschbar, auditierbar, forkbar. Niemand kann sie Ihnen entziehen, niemand kann die Bedingungen über Nacht umschreiben, ohne dass Sie die Option hätten, stehen zu bleiben.

Eine Nuance, die hierher gehört: LM Studio ist praktisch, aber es ist nicht frei im Sinne der OSI. Es ist für persönliche Nutzung kostenlos, kommerziell jedoch lizenziertspflichtig. Wer Wert auf durchgängig freie Software legt, wählt den Ollama- und llama.cpp-Pfad. Das ist kein Dogma, sondern eine Klärung, die man kennen sollte, bevor man Architekturen darauf baut.

Breiter gedacht: KI hat unser Berufsleben erschüttert, alle unsere Berufsleben, in irgendeiner Form. Sie kam, und sie bleibt — da bin ich mir sicher. Wer das abstreitet, betreibt Nostalgie. Aber Naivität ist das genaue Gegenteil und ebenso falsch. Bequemlichkeit verbirgt Abhängigkeit, und sie verbirgt Kosten, die leise steigen. Die sachkundige Haltung lautet: KI bewusst nutzen, zu eigenen Bedingungen, mit Verständnis dafür, was sie kostet, was sie leisten kann und wo sie versagt. Das ist keine Haltung gegen die Technologie. Es ist eine Haltung für die eigene Handlungsfähigkeit.

Was libcom.de damit zu tun hat

Seit einem Vierteljahrhundert baue ich — Jochen Demmer, libcom.de — auf Open-Source-Infrastruktur. In den letzten Jahren gehört dazu zunehmend das Betreiben von KI-Stacks auf eigener Hardware: für Log-Analyse, Entwurfsarbeit, Code-Review, interne Assistenzsysteme, dokumentengestützte Suche. Nicht als Demo, sondern im Tagesgeschäft und auf Kundensystemen.

Aus dieser Praxis kommen Urteile, die kein Tutorial vermittelt: Wo die Break-even-Rechnung zwischen API und Eigenbetrieb kippt, wie der Dial zwischen Quantisierung und Qualität für welchen Anwendungsfall steht, welche Sicherheits- und Netzwerkarchitektur nötig ist, um einen Inferenzendpunkt im Unternehmen sauber freizugeben — und wo die Grenze zwischen einem Homelab-Spielzeug und einem gewarteten Dienst verläuft. Die häufigste Aufgabe ist nicht, Hardware zu besorgen, sondern die richtige Hardware mit der richtigen Serving-Strategie zu paaren, statt umgekehrt eine teure Box zu kaufen und dann nach Software zu suchen, die sie rechtfertigt.

Wenn Sie sich fragen, ob lokaler KI-Einsatz für Ihre Umgebung Sinn ergibt, welche Hardware zur geplanten Software passt und wie ein Stack aussieht, der nicht nach drei Monaten zusammenbricht: Schreiben Sie an contact@libcom.de. Wir nehmen auseinander, was bei Ihnen laufen soll — ehrlich, ohne Verkaufsdruck, mit dem Blick auf das, was langfristig Bestand hat.

Es beginnt mit Neugier und endet, wer es ernst nimmt, mit Infrastruktur. Dazwischen liegt das schönste Handwerk, das gerade neu erfunden wird — Stück für Stück, auf eigener Hardware, mit offenen Werkzeugen.

Hinweis: Dieser Artikel bietet allgemeine Orientierung zu Hardware- und Softwarewahl sowie Kostenüberlegungen und ersetzt keine Beschaffungs- oder Rechtsberatung. Leistungs- und Preisangaben sind illustrativ und können je nach Konfiguration, Treiberlage und Marktentwicklung abweichen; alle Angaben erfolgen ohne Gewähr.