Inhalt
PERSÖNLICHE EINORDNUNG
Nach der Frage, ob eine eigene Unternehmens-KI überhaupt ein selbst trainiertes Sprachmodell benötigt, folgt für mich der nächste praktische Punkt: Welche Hardware ist dafür eigentlich notwendig? Muss dafür sofort ein spezieller KI-Server angeschafft werden – oder kann ein vorhandener Arbeitsplatzrechner bereits sinnvoll genutzt werden?
Für mein UWM-FTBE-Projekt möchte ich diese Frage nicht mit pauschalen Hardwareempfehlungen beantworten. Entscheidend ist zunächst, was auf dem Rechner tatsächlich laufen soll. Ein kompaktes Sprachmodell für einzelne Textaufgaben stellt andere Anforderungen als ein großes Modell mit langem Kontext, Dokumentenanalyse, mehreren gleichzeitigen Nutzern oder zusätzlichen Bildfunktionen.
Deshalb lautet die für mich wichtigere Frage nicht: „Ist mein Rechner KI-fähig?“ Sondern: „Welche lokale KI-Aufgabe kann dieser Rechner in einer für den Arbeitsalltag brauchbaren Geschwindigkeit und Qualität zuverlässig erfüllen?“
Ein normaler Rechner kann lokale KI ausführen – aber das ist erst der Anfang
Lokale Sprachmodelle sind heute nicht grundsätzlich an Rechenzentren gebunden. Laufzeitumgebungen wie Ollama und llama.cpp sind ausdrücklich dafür ausgelegt, Modelle auf lokaler Hardware auszuführen. llama.cpp unterstützt dabei unterschiedliche Prozessorarchitekturen, verschiedene GPU-Backends und auch eine gemischte CPU-/GPU-Ausführung.
Damit ist die grundsätzliche technische Hürde deutlich niedriger, als der Begriff „KI-Infrastruktur“ zunächst vermuten lässt. Trotzdem folgt daraus nicht, dass jedes Modell auf jedem Rechner sinnvoll arbeitet. Zwischen „das Modell startet“ und „das System ist für produktive Unternehmensarbeit geeignet“ liegt ein wichtiger Unterschied.
Einfach erklärt: Was braucht eine lokale KI von meinem Rechner?
Stellen wir uns das Sprachmodell wieder als Mitarbeiter vor.
Damit dieser Mitarbeiter vernünftig arbeiten kann, braucht er einen passenden Arbeitsplatz.
Die GPU übernimmt dabei einen großen Teil der Rechenarbeit. Sie besitzt dafür einen eigenen schnellen Arbeitsspeicher, den VRAM.
Vereinfacht gesagt:
GPU = der Mitarbeiter
VRAM = sein Schreibtisch
Je größer das KI-Modell und je umfangreicher die Aufgabe, desto mehr Platz wird auf diesem Schreibtisch benötigt.
Ist der Schreibtisch groß genug, kann der Mitarbeiter die benötigten Akten und Unterlagen direkt vor sich liegen lassen. Er kann damit arbeiten, ohne ständig Platz schaffen zu müssen.
Ist der Schreibtisch dagegen zu klein, muss er immer wieder Unterlagen wegräumen und andere aus dem Archiv holen. Er ist also ständig damit beschäftigt, zwischen Schreibtisch und Archiv hin und her zu wechseln.
Übertragen auf den Rechner bedeutet das: Reicht der schnelle Grafikspeicher nicht aus, müssen Daten je nach System auf andere Speicherbereiche ausgelagert oder zwischen ihnen verschoben werden. Das kann die Verarbeitung deutlich verlangsamen.
Mehr VRAM bedeutet deshalb vereinfacht: Der Mitarbeiter hat einen größeren Schreibtisch und kann mehr von dem, was er gerade zum Arbeiten benötigt, direkt griffbereit halten.
Das bedeutet aber nicht, dass nur der VRAM entscheidet. Auch CPU, GPU, normaler Arbeitsspeicher (RAM), Modellgröße und die jeweilige Aufgabe spielen eine Rolle.
Deshalb reicht die Frage „Wie viel RAM hat mein Rechner?“ für die Beurteilung einer lokalen KI nicht aus.
Entscheidend ist, ob die gesamte Ausstattung des Rechners zu dem KI-Modell und zu der Aufgabe passt, die wir damit erledigen möchten.
Genau das werden wir später an unserem vorhandenen Rechner praktisch prüfen.
Die fünf Hardwarefaktoren, die wirklich zählen
Für einen ersten Hardwarecheck sind vor allem fünf Punkte relevant: Arbeitsspeicher, Grafikspeicher, GPU, CPU und Massenspeicher. Hinzu kommt als verbindendes Element die gewünschte Kontextlänge.
Der Arbeitsspeicher (RAM) ist besonders wichtig, wenn ein Modell vollständig oder teilweise über die CPU ausgeführt wird oder Modellanteile nicht in den Grafikspeicher passen. Der Grafikspeicher (VRAM) wird entscheidend, sobald die GPU einen großen Teil der Modellberechnung übernimmt.
Eine leistungsfähige GPU kann die Verarbeitung erheblich beschleunigen. Fehlt eine geeignete GPU, bedeutet das aber nicht automatisch, dass lokale KI unmöglich ist. CPU-basierte Ausführung ist technisch möglich; je nach Modell und Prozessor kann die Antwortgeschwindigkeit jedoch deutlich geringer sein.
Der Massenspeicher wird häufig unterschätzt. Lokale Modelle müssen zunächst gespeichert werden. Mehrere Modellvarianten, Embedding-Modelle, Dokumentbestände und spätere Teststände können den Speicherbedarf schnell erhöhen.
Quantisierung: Warum ein Modell kleiner werden kann
Ein wichtiger Grund dafür, dass größere Sprachmodelle überhaupt auf Arbeitsplatzrechnern betrieben werden können, ist die Quantisierung. Dabei werden Modellgewichte mit geringerer numerischer Genauigkeit gespeichert und verarbeitet.
Das Projekt llama.cpp unterstützt verschiedene Quantisierungsstufen ausdrücklich, um Speicherbedarf und Rechenaufwand zu reduzieren. Als Größenordnung zeigt die offizielle Quantisierungsdokumentation beispielsweise für ein Llama-3.1-Modell mit 8 Milliarden Parametern eine Q4_K_M-Dateigröße von rund 4,9 GB, während die ursprüngliche Größe dort mit rund 32,1 GB angegeben wird.
Diese Zahlen sind keine allgemeine Hardwareempfehlung. Sie zeigen aber, warum die Modellbezeichnung allein wenig über den praktischen Speicherbedarf aussagt. Modellarchitektur, Quantisierung, Kontext und Laufzeitumgebung müssen gemeinsam betrachtet werden.
Einfach erklärt: Was ist eigentlich ein Token?
Ein KI-Sprachmodell verarbeitet Texte nicht direkt als ganze Wörter oder Sätze. Der Text wird zunächst in kleinere Einheiten zerlegt. Diese Einheiten nennt man Tokens.
Ein Token kann beispielsweise ein ganzes Wort, ein Wortteil, ein Satzzeichen oder eine andere Zeichenfolge sein.
1 Token ist deshalb nicht automatisch 1 Wort.
Vereinfacht können wir uns Tokens als die kleinen Textbausteine vorstellen, mit denen ein Sprachmodell arbeitet.
Das wird besonders wichtig, wenn von der Kontextlänge eines KI-Modells gesprochen wird. Sie beschreibt vereinfacht, wie viele solcher Textbausteine das System bei einer Aufgabe gleichzeitig berücksichtigen kann.
Dazu gehören nicht nur unsere aktuelle Frage, sondern beispielsweise auch vorherige Gesprächsinhalte, Systemanweisungen und bereitgestellte Dokumenteninhalte.
Je mehr Informationen gleichzeitig berücksichtigt werden sollen, desto mehr Tokens werden benötigt.
Deshalb spielt die Anzahl der Tokens eine wichtige Rolle dafür, wie umfangreich eine Aufgabe sein kann und welche Speicher- und Rechenressourcen dafür benötigt werden.
Kontextlänge: Der versteckte Speicherverbrauch
Bei Unternehmensanwendungen reicht es häufig nicht, nur eine kurze Frage an ein Modell zu stellen. Dokumente, längere Gesprächsverläufe, Systemanweisungen, Werkzeuge und später möglicherweise RAG-Ergebnisse vergrößern den Kontext.
Ollama weist in seiner eigenen Dokumentation darauf hin, dass eine größere Kontextlänge mehr Speicher benötigt. Ein aktuelles Beispiel aus der Ollama-Dokumentation nennt für ein lokales Coding-Modell bei 64.000 Tokens Kontext ungefähr 23 GB benötigten VRAM. Das ist ein konkretes Beispiel und keine allgemeingültige Mindestanforderung.
Für die Planung bedeutet das: Ein Modell, das bei kurzem Kontext problemlos auf einem Rechner läuft, kann bei deutlich größerem Kontext wesentlich mehr Speicher beanspruchen.
Was bedeutet „ernsthaft betreiben“?
Für mich ist ein erfolgreicher Start des Modells noch kein ausreichendes Kriterium. Für einen betrieblichen Einsatz müssen weitere Fragen beantwortet werden: Wie lange dauert die erste Antwort? Wie schnell werden weitere Tokens erzeugt? Wie verhält sich das System bei längeren Dokumenten? Bleibt genügend Speicher für Windows und die übrigen Anwendungen? Wie stabil läuft die Umgebung über mehrere Aufgaben hinweg?
Auch die Qualität muss zum Anwendungsfall passen. Ein sehr kleines Modell kann schnell laufen, aber für eine anspruchsvolle technische Aufgabe ungeeignet sein. Ein wesentlich größeres Modell kann bessere Ergebnisse liefern, aber auf vorhandener Hardware so langsam werden, dass der praktische Nutzen verloren geht.
„Ernsthaft“ bedeutet deshalb nicht automatisch „möglichst großes Modell“. Es bedeutet, eine belastbare Kombination aus Qualität, Geschwindigkeit, Speicherbedarf, Stabilität und Datenschutz für die konkrete Aufgabe zu finden.
Eine sinnvolle Einteilung statt pauschaler Mindestanforderungen
Statt eine starre Tabelle nach dem Muster „8 GB = ungeeignet, 16 GB = geeignet, 32 GB = professionell“ zu veröffentlichen, halte ich eine anwendungsbezogene Einteilung für sinnvoller.
Ein vorhandener Büro- oder Engineering-Rechner kann als Testplattform dienen, um kompakte quantisierte Modelle, einfache Chats und erste lokale Workflows zu erproben. Mit mehr RAM und einer geeigneten GPU erweitert sich der nutzbare Modellbereich und die Verarbeitung kann deutlich schneller werden. Große Modelle, sehr lange Kontexte, Multimodalität oder mehrere parallele Nutzer verschieben die Anforderungen dagegen schnell in Richtung leistungsfähiger Workstation oder Server.
Die Grenze ist also nicht eine einzelne Zahl. Sie entsteht aus der Kombination von Modell, Quantisierung, Kontext, gewünschter Geschwindigkeit und Arbeitslast.
Praxischeck für UWM-FTBE: Erst messen, dann Hardware kaufen
Für UWM-FTBE soll deshalb nicht zuerst neue Hardware beschafft und anschließend nach einer Aufgabe dafür gesucht werden. Der sinnvollere Weg ist umgekehrt: vorhandenen Rechner erfassen, ausgewählte Modelle testen, Messwerte dokumentieren und daraus den tatsächlichen Bedarf ableiten.
Für den späteren Praxischeck werden mindestens CPU, installierter RAM, GPU, verfügbarer VRAM, freier Massenspeicher und Betriebssystemstand dokumentiert. Anschließend können definierte Testmodelle mit identischen Aufgaben verglichen werden.
Die entscheidenden Messwerte werden nicht vorweggenommen. Erst ein reproduzierbarer Test kann zeigen, welche Modellgröße und welcher Kontext auf dem vorhandenen UWM-FTBE-System noch sinnvoll nutzbar sind. Genau diese Trennung zwischen Annahme und Messwert ist für die weitere Serie wichtig.
Was wir im nächsten Schritt noch nicht tun sollten
Aus diesem Artikel folgt ausdrücklich noch keine Kaufempfehlung für eine bestimmte Grafikkarte, Workstation oder Serverkonfiguration. Dafür fehlen bewusst die Messwerte des vorhandenen Systems und ein festgelegter Benchmark.
Ebenso wäre es zu früh, eine einzelne Modellgröße als verbindlichen Unternehmensstandard festzulegen. Modelle und Laufzeitumgebungen entwickeln sich schnell weiter. Die Hardwareentscheidung sollte deshalb aus einer definierten Aufgabenstellung und reproduzierbaren Tests entstehen – nicht aus einer möglichst hohen Parameterzahl.
Fazit
Ja: Ein normaler Rechner kann heute durchaus eine ernsthafte lokale KI ausführen. Ob daraus bereits eine produktiv nutzbare Unternehmens-KI wird, lässt sich aber nicht allein an CPU, RAM oder Grafikkarte festmachen.
Entscheidend sind Modellgröße, Quantisierung, Kontextlänge, Speicherbedarf, Beschleunigung und vor allem der konkrete Anwendungsfall. Deshalb ist der vorhandene Rechner für UWM-FTBE zunächst kein Problem, das vorsorglich durch neue Hardware gelöst werden muss. Er ist unsere erste Testplattform.
Ein nächster Vertiefungsschritt ist die Architekturfrage: Bevor Software, Modelle und Unternehmenswissen miteinander verbunden werden, muss klar sein, welche Komponenten wohin gehören und wie sie voneinander getrennt werden.
Vorheriger Beitrag:
Artikel 008 – Eine eigene KI bedeutet nicht, ein eigenes Sprachmodell zu trainieren
Nächster Beitrag:
Artikel 014 – Erst die Architektur, dann die Installation: Warum wir bei der Unternehmens-KI bewusst bei null anfangen
Quellen – Stand Oktober 2026
Geprüft am 05.10.2026; technische Dokumentationen und Modellanforderungen können sich ändern.
- Ollama – offizielle Projektdokumentation und technische Veröffentlichungen – Speicherbedarf, Kontextlänge und lokale Modellausführung.
- ggml-org – llama.cpp – offizielle Projektdokumentation – lokale Inferenz, CPU-/GPU-Unterstützung und Quantisierung.
Hinweis: Konkrete Leistungswerte hängen von Modell, Quantisierung, Kontext, Softwarestand und Hardware ab. Der Beitrag ersetzt keinen reproduzierbaren Benchmark des Zielsystems.