Eine Geschichte über KI · 06
64 Gigabyte Arbeitsspeicher suchen Arbeit. Gerne auch Kopfarbeit.
Ein älterer Rechner, reichlich RAM und eine neue Aufgabe: lokale KI auf der CPU erkunden, mit echten Beispielen und etwas Humor.
Veröffentlicht von AI Model Green Zone
Weiterlesen →Unterstrichene Begriffe öffnen das Glossar. Mauszeiger oder Tastaturfokus zeigen eine kurze Erklärung.
Wenn du ein paar Anleitungen zum Betrieb künstlicher Intelligenz zu Hause liest, entsteht ziemlich schnell der Eindruck, dass du zuerst eine Grafikkarte kaufen musst. Dann stellt sich heraus, dass es besser eine andere sein sollte. Und dann, dass du dafür ein neues Netzteil brauchst. An diesem Punkt möchtest du den Browser schließen: Du wolltest eigentlich nur ausprobieren, mit einem Modell zu reden, und nicht den Computer umbauen und das Familienbudget neu planen.
Dabei steht die ganze Zeit ein durchaus ordentlicher Rechner unter dem Schreibtisch.
Vielleicht hat er schon ein paar Jahre auf dem Buckel. Vielleicht ist es eine alte Workstation, die einmal für anspruchsvolle Aufgaben angeschafft wurde. Und manche haben sogar noch einen Server: zwei Prozessoren, viel Speicher, ein stattliches Metallgehäuse. Früher hat er ein Büro versorgt, heute versorgt er hauptsächlich seine eigenen Lüfter.
Eigentlich schade. Der Computer funktioniert und hat 32, 64 oder sogar 128 Gigabyte Arbeitsspeicher. Ist das ohne teure Grafikkarte wirklich alles nutzlos für ein Sprachmodell?
Nein, nutzlos ist es nicht. Und hier beginnt eine ziemlich interessante Geschichte.
Sprachmodelle lassen sich auf dem Prozessor ausführen und dabei mit ganz normalem Arbeitsspeicher betreiben. Dafür gibt es Programme wie llama.cpp, die Berechnungen auf der CPU unterstützen. Die verwendete Programmversion muss mit dem gewählten Modell kompatibel sein, aber diese Möglichkeit ist längst über hübsche Vorführungen hinausgewachsen. Dokumentation von llama.cpp
Manchmal sagen wir „ein Modell im RAM ausführen“, und das ist eine praktische Kurzform. Nur rechnet der Speicher selbst nichts aus. Er hält die Modellgewichte und Arbeitsdaten bereit, während der Prozessor die Rechenoperationen ausführt. Ungefähr wie ein Vorratsschrank und ein Koch: Ein geräumiger Schrank ist nützlich, aber allein durch seine Anwesenheit steht noch kein Abendessen auf dem Tisch.
Übrigens brauchst du für ein solches Gespräch mit dem Modell keine dauerhafte Internetverbindung. Sind die Dateien einmal heruntergeladen, kann es lokal arbeiten, sofern die Anwendung selbst keine Cloud oder externen Werkzeuge nutzt. Das Internet hat schon dabei geholfen, ein paar Gigabyte vorbeizubringen, und darf sich jetzt ruhig ausruhen.
Das klingt alles ermutigend. Aber schauen wir lieber, was bei Leuten herausgekommen ist, die es tatsächlich ausprobiert haben.
Wir haben einige veröffentlichte Beispiele gefunden. Selbst haben wir diese Messungen nicht wiederholt. Im Folgenden geht es also um die Ergebnisse der jeweiligen Autoren mit ihrer Hardware, ihren Programmen und ihren Einstellungen.
| Computer | Arbeitsspeicher | Modell und Programm | Veröffentlichtes Ergebnis |
|---|---|---|---|
| AMD Ryzen 5 5600, Linux | Laut Bericht 62,7 GB | Llama 3.1 8B Instruct, Q4_K_M, über llamafile | Bei 4 096 Eingabe- und 256 Ausgabetokens: 7,2 Tokens/s bei der Generierung; erstes Token nach 98,36 Sekunden. LocalScore |
| HP Z420, Xeon E5-2690 v2 – ein Prozessor von 2013 | 64 GB DDR3 ECC | Qwen3.6-35B-A3B, Q6_K, über llama.cpp | Der Autor berichtet von etwa 8,5 Tokens/s bei der Generierung mit 10 CPU-Threads, ohne GPU-Beschleunigung. Bericht des Besitzers |
| System mit zwei AMD EPYC 7K62 | 16 × 64 GB RAM | DeepSeek-R1 671B, Q5_K_S | Der Autor meldete 2,9 Tokens/s mit 96 Threads. Die Modelldatei belegte ungefähr 462 GB. Beschreibung des Experiments |
Mich reizt an dieser Auswahl besonders das zweite Beispiel. Ein Prozessor von 2013, DDR3, eine alte Workstation – alles Dinge, die man im Gespräch über moderne KI leicht abschreibt. Und dann hat jemand es einfach ausprobiert.
Das dritte Beispiel gehört natürlich schon in eine andere Gewichtsklasse. Allein der Arbeitsspeicher nimmt in meiner Vorstellung mehr Platz ein als die gesamte ursprüngliche Idee für diesen Artikel. Aber mit so einem Server musst du keineswegs anfangen. Zum Schwimmenlernen muss man schließlich auch nicht den Atlantik mieten.
Und noch etwas: Diese Zeilen sind kein Prozessorwettbewerb. Die Modelle sind verschieden, die Programme sind verschieden, die Messbedingungen ebenfalls. Den alten Xeon zum Sieger über den Ryzen zu erklären, nur weil in einer Zeile eine größere Zahl steht, wäre ziemlich gewagt.
Etwas anderes lässt sich aber erkennen: Eine fehlende moderne Grafikkarte bedeutet noch nicht, dass das Experiment ausfällt. Selbst DDR3 verwandelt sich offenbar nicht am Erscheinungstag von DDR5 in einen Kürbis.
Kehren wir nun zu einer vertrauteren Situation zurück. Angenommen, du hast einen Computer mit 64 Gigabyte RAM. Du öffnest einen Modellkatalog, findest eine Datei von ungefähr 60 Gigabyte und denkst: Das passt doch fast genau. Ein bisschen bleibt sogar noch übrig.
Hier würde ich lieber kurz auf die Bremse treten.
Das Betriebssystem zieht schließlich nicht aus. Der Browser bleibt auch da – samt all den Tabs, die du ganz bestimmt noch lesen wirst, nur eben nicht heute. Und das Programm, das dein Modell ausführt, braucht ebenfalls Platz zum Arbeiten.
Neben den Gewichten belegen Arbeitspuffer und die Daten des gerade verarbeiteten Gesprächs Speicher. Bei vielen Modellen macht der KV-Cache einen erheblichen Teil dieser Daten aus: gespeicherte Zwischenergebnisse, durch die ein Teil der Berechnungen für bereits gelesenen Text nicht wiederholt werden muss. Seine Größe hängt von der Modellarchitektur, der Kontextlänge und den Einstellungen ab. Erklärung zum KV-Cache
Die Dateigröße auf der Downloadseite ist also eine nützliche Zahl, beantwortet aber noch nicht vollständig die Frage „Wie viel Speicher brauche ich?“
Bei dem erwähnten Versuch mit dem HP Z420 nennt der Autor einen anschaulichen Vergleich: Die Modelldatei ist ungefähr 29,3 GB groß, der als RSS gemessene Speicherbedarf des Prozesses liegt dagegen bei etwa 34,8 GB. Und das ist noch nicht der Verbrauch des ganzen Computers. Aus der Differenz sollte man keinen pauschalen Aufschlag für alle Fälle machen, aber das Prinzip wird hier gut sichtbar. Messungen des Autors
Natürlich hätte man gern eine einfache Regel: „Lass so und so viele Gigabyte frei, dann passt das.“ Das wäre praktisch. Aber für ein kurzes Gespräch mit einem kleinen Modell brauchst du eine andere Reserve als für ein großes Dokument mit einem ganz anderen Modell.
Zumindest lässt sich mit einem verständlichen Plan anfangen. Nehmen wir ein beispielhaftes Budget von 64 GiB, in den Einheiten unseres Speicherrechners, und verteilen es so:
| Wofür wir Speicher einplanen | Beispielbudget |
|---|---|
| System und andere Anwendungen | 8 GiB |
| Gewählte Gewichtsdatei | 32 GiB |
| Kontext-Cache und Arbeitsbereiche des Programms | 8 GiB |
| Verbleibende Reserve | 16 GiB |
Das ist ausdrücklich ein Beispiel und keine Anleitung für jeden Computer. Acht Gigabyte für Arbeitsdaten können in einem Fall großzügig und in einem anderen zu wenig sein. Den Speicherverbrauch des Systems schaust du am besten auf deinem eigenen Rechner nach; Cache und sonstigen Bedarf solltest du für das gewählte Modell und die konkrete Aufgabe abschätzen.
Achte auf die letzte Zeile. Da ist noch Platz frei, und das ist völlig in Ordnung. Für eine hundertprozentige Belegung des RAM gibt es keine Medaille.
Wenn der Speicher knapp wird, kann das System einen Teil der Daten auf das Laufwerk auslagern. Manchmal ermöglicht das, weiterzuarbeiten. Der ständige Datenaustausch mit dem Laufwerk kann ein Gespräch aber in einen sehr langsamen Briefwechsel verwandeln. Auch ein Abbruch des Prozesses wegen Speichermangels ist möglich. Eine SSD ist beim Laden des Modells hilfreich, als gleichwertigen Ersatz für RAM solltest du sie jedoch nicht einplanen.
Gut, die Kapazität haben wir geklärt. Nehmen wir an, das Modell passt mit genügend Reserve in den Speicher. Warum kann es trotzdem langsam antworten?
Hier kommt der Prozessor wieder ins Gespräch, bei dem wir bisher hauptsächlich Gigabytes gezählt haben.
Die CPU muss viele Rechenoperationen ausführen und dafür Daten aus dem Speicher holen. Dabei zählen ihre Architektur, die unterstützten Befehle, Taktraten, Cache, Kernzahl und wie gut das Programm all das nutzt.
Gerade bei den Kernen ist man schnell mit Schlussfolgerungen bei der Hand. Acht sind gut, sechzehn besser, zweiunddreißig – also noch einmal doppelt so schnell?
Manchmal helfen zusätzliche Kerne tatsächlich. Wenn die Berechnungen aber durch die Datenübertragung aus dem Speicher begrenzt werden, muss ein Teil der Threads warten. Zu viele Threads können das Ergebnis sogar verschlechtern – darauf weisen die Entwickler von llama.cpp ausdrücklich hin. Empfehlungen der Entwickler
Zweiunddreißig Köche um ein einziges Schneidebrett sind eine beeindruckende Belegschaft. Nur steht das Mittagessen deswegen nicht unbedingt früher auf dem Tisch.
Beim Speicher ist es ähnlich. Wir sind es gewohnt zu fragen, wie viel davon eingebaut ist. Für das Modell zählt aber auch, wie schnell der Prozessor daraus Daten abrufen kann.
DDR3, DDR4 oder DDR5 sind deshalb nur ein Teil der Beschreibung. Die tatsächliche Speichergeschwindigkeit und die Anzahl der genutzten Kanäle sind ebenfalls wichtig. Vier Speicherriegel bedeuten dabei nicht automatisch vier Kanäle: Das hängt von der Plattform und der Anordnung der Module ab. Die Bandbreite hängt mit der Übertragungsrate, der Schnittstellenbreite und der Zahl der Kanäle zusammen. Erklärung von Intel
Deshalb kann eine alte Serverplattform manchmal interessanter sein, als ihr Baujahr vermuten lässt. Ihre Speicherorganisation kann Vorteile haben. Es kann aber auch Nachteile geben, die erst beim Einsatz eines bestimmten Programms sichtbar werden.
Bei zwei Prozessoren lohnt sich ebenfalls ein genauerer Blick. Jeder hat normalerweise seinen eigenen lokalen Speicher, und der Zugriff auf den Speicher des Nachbarprozessors ist aufwendiger. Das nennt sich NUMA. Wie nützlich die zweite CPU ist, hängt davon ab, wie das Programm Berechnungen und Daten verteilt. Dokumentation von Intel
In unserer Küche ist ein zweiter Koch mit einem eigenen Vorratslager aufgetaucht. Eine gute Nachricht. Allerdings muss er manchmal über den Hof laufen, um Zutaten zu holen.
Du musst vor dem ersten Start nicht all diese Einzelheiten verstehen. Es hilft aber, sie im Hinterkopf zu behalten, wenn die Ergebnisse plötzlich nicht zur schönen Rechnung „doppelt so viele Prozessoren – doppelt so schnell“ passen.
Eine weitere Sache lässt sich leicht mit einer Fehlfunktion verwechseln.
Du stellst eine Frage, das Programm schweigt. Die Lüfter laufen. Auf dem Bildschirm steht noch nichts.
Vielleicht liest das Modell gerade noch deine Anfrage. Bevor es eine Antwort generiert, muss es den Eingabetext verarbeiten. Eine kurze Frage und ein angehängter Vertrag mit fünfzig Seiten machen dabei unterschiedlich viel Arbeit.
Schau noch einmal kurz auf die erste Zeile unserer Tabelle. Dort lief die Generierung mit 7,2 Tokens pro Sekunde, aber bis zum ersten Token vergingen fast hundert Sekunden. Diese Zahlen widersprechen sich nicht: Sie beschreiben unterschiedliche Phasen.
Beim Vergleichen solltest du deshalb sowohl auf die Zeit bis zum Beginn der Antwort als auch auf die Geschwindigkeit der anschließenden Generierung achten. In llama-bench werden die Verarbeitung des Eingabetextes und die Generierung getrennt gemessen. Beschreibung der Messungen
Eine lange Antwort braucht natürlich ebenfalls Zeit. Wenn das Modell einen Denkmodus unterstützt, kann es vor der endgültigen Antwort zusätzliche Tokens erzeugen. Manchmal ist das hilfreich. Manchmal brauchst du aber bloß das Lieferdatum aus einer E-Mail, während das Modell schon ein philosophisches Symposium über das Wesen der Zeit eröffnet.
Womit fängst du also am besten an, damit der erste Abend nicht ausschließlich aus Warten besteht?
Ich würde ein kleines Instruct-Modell in einem unterstützten quantisierten Format wählen und ihm eine kurze, vertraute Aufgabe geben. Zu den Kandidaten, die du dir ansehen kannst, gehören Qwen3.5-4B und Phi-4-mini mit 3,8 Milliarden Parametern. Danach kannst du die Klasse 7–8B ausprobieren und schauen, ob ein größeres Modell gerade bei deiner Arbeit einen Vorteil bringt. Alle diese Varianten sind in den Katalogen der Programme zum Ausführen von Modellen verfügbar. Qwen3.5-4B, Phi-4-mini, Qwen3-8B
Für den ersten Versuch kommt Q4_K_M infrage, sofern eine solche Datei unterstützt wird. Anschließend kannst du mit einer anderen Präzision vergleichen. Quantisierung verkleinert die Gewichte, kann aber die Antworten beeinflussen. Wie deutlich das auffällt und wie wichtig es ist, hängt vom Modell und von der Aufgabe ab. Dokumentation zur Quantisierung
Und du brauchst dich nicht dafür zu schämen, auf einem Computer mit viel Speicher ein kleines Modell zu verwenden. Der Computer nimmt dir das nicht übel. Wenn es die benötigte Arbeit gut erledigt, dürfen die freien Gigabyte einfach frei bleiben.
Für Besitzer von Rechnern mit reichlich Speicher sind auch MoE-Modelle interessant. Bei der Verarbeitung jedes Tokens verwenden sie einen Teil der Experten. Das kann den Rechenaufwand gegenüber einem dichten Modell vergleichbarer Gesamtgröße verringern. Der vollständige Satz an Gewichten muss aber trotzdem gespeichert werden.
Für Qwen3.6-35B-A3B werden zum Beispiel ungefähr 35 Milliarden Parameter insgesamt und 3 Milliarden aktive Parameter angegeben. Vom Speicherbedarf her ist das kein kleines 3B-Modell. Und beim Rechenaufwand lässt es sich nicht automatisch mit einem gewöhnlichen dichten 35B-Modell gleichsetzen. Modellkarte
Die Experten wechseln sich bei der Arbeit ab, aber aus der Wohnung ist niemand ausgezogen.
Das Nützlichste für den Anfang ist vielleicht, dir ein paar Aufgaben auszudenken, deren Ergebnis du beurteilen kannst. Ein kurzes Dokument zusammenfassen lassen. Namen, Daten und Beträge aus einer E-Mail herausziehen. Eine Frage beantworten lassen, bei der du die richtige Antwort schon kennst.
Starte mit wenig Kontext, einer Anfrage nach der anderen und einer begrenzten Antwortlänge. Schau, wie lange du warten musstest, wie viel Speicher übrig ist und vor allem, ob dir das Ergebnis geholfen hat.
Ändere danach jeweils nur eine Sache: das Modell, die Präzision der Gewichte, die Kontextlänge oder die Anzahl der Threads. So wird nach und nach klar, was dein System tatsächlich beeinflusst. Wenn du alles gleichzeitig änderst, erinnert das Experiment an gemeinsames Möbelrücken mit der Familie: Es sieht jetzt anders aus, aber niemand weiß mehr, warum ihr angefangen habt.
Der Betrieb auf der CPU hat durchaus reale Grenzen. Große Dokumente und lange Gedankengänge verlangen Geduld. Viele Nutzer gleichzeitig zu bedienen ist eine andere Belastung als eine einzelne Person am heimischen Computer. Ein alter Server kann ordentlich Strom verbrauchen und das mit dem Geräusch eines startenden Flugzeugs verkünden.
Für gemächliche Textarbeit, das Extrahieren von Daten, kleine Automatisierungen und die ersten Erfahrungen mit lokaler KI verdient der vorhandene Rechner aber mindestens einen Versuch.
Genau darum geht es bei unserem Speicherrechner: Er soll helfen, den Speicherbedarf abzuschätzen und Kandidaten für den Einstieg auszuwählen. Ein Geschwindigkeitszertifikat stellt er nicht aus. Er weiß auch nicht, ab welcher Wartesekunde du mit den Fingern auf dem Tisch trommelst.
Vielleicht bleibst du nach ein paar Abenden bei einem kleinen Modell, das eine bestimmte Arbeit gut erledigt. Vielleicht findest du ein passendes MoE. Und vielleicht stellst du fest, dass du für deine Aufgaben doch eine Grafikkarte brauchst. Auch das kommt vor, und das Experiment ist deswegen nicht gescheitert.
Zumindest weißt du dann, für welche konkrete Verbesserung du bezahlen möchtest.
Und wenn sich ein passendes Modell findet, bekommt der alte Computer eine neue Arbeit. Ich stelle mir vor, wie er vor ein paar Jahren ausgemustert, nach Hause gebracht und unter den Schreibtisch gestellt wurde – und jetzt hilft er dabei, Dokumente zu bearbeiten.
Für einen Server ist das kein schlechter Karriereschritt.
Bis dahin stand in seiner Stellenbeschreibung nur: „Lärm machen“.
Quellen & weitere Lektüre
- llama.cpp · CPU inference ↗
- LocalScore · Ryzen 5 5600, Llama 3.1 8B · Test #3337 ↗
- yoshitomigoto · HP Z420, Xeon E5-2690 v2, Qwen3.6-35B-A3B ↗
- llama.cpp community · CPU-only DeepSeek-R1 experiment ↗
- Hugging Face · KV cache ↗
- llama.cpp · Token generation performance ↗
- Intel · Memory bandwidth ↗
- Intel · Dual-socket systems and NUMA ↗
- llama.cpp · llama-bench ↗
- Ollama · Qwen3.5-4B ↗
- Ollama · Phi-4-mini ↗
- Ollama · Qwen3-8B ↗
- llama.cpp · Quantization ↗
- Qwen · Qwen3.6-35B-A3B ↗
Teilen & Nachdruck
Veröffentlicht von AI Model Green Zone.
Du darfst diesen Artikel nur vollständig und unverändert nachdrucken. Nenne dabei AI Model Green Zone als Quelle und füge einen gut sichtbaren, aktiven Link zum Originalartikel auf unserer Website hinzu.
Für Übersetzungen, gekürzte Fassungen und Bearbeitungen ist eine gesonderte Genehmigung erforderlich.
Diese Bedingungen schränken gesetzlich erlaubte Nutzungen nicht ein.
Der öffentliche Artikellink wird verfügbar, sobald die öffentliche Website-Adresse eingerichtet ist.