- Gemma 4 26B-A4B wurde auf einem Server von 2016 mit einer einzelnen Intel Xeon E5-2620 v4, 128 GB DDR3 und ohne GPU mithilfe von
ik_llama.cpp-Optimierungen bis auf Lesegeschwindigkeit gebracht
- Der Decoder-Pfad eines LLM wird nicht von der Rechenleistung, sondern von der Speicherbandbreite begrenzt; die CPU wartet vor allem darauf, die nächsten Gewichte aus dem RAM in den Cache zu holen
--spec-type mtp, --cpu-moe, --merge-up-gate-experts, --run-time-repack usw. verringern Engpässe in einer DDR3-Umgebung durch MTP Speculative Decoding, MoE-Routing und cachefreundliche Speicheranordnung- Laut Log liegt der gesamte Speicherbedarf bei 82.355 MiB; bei vollem 262K-Kontext ist der KV-Cache mit rund 56 GB größer als die Gewichte mit rund 25 GB
- Blackbox-Tools wie
ollama bieten weder die nötige Modellunterstützung noch ausreichend Feintuning-Regler; auf alter Hardware muss man Inference-Engine und Speicherstruktur tief verstehen, um Leistung herauszuholen
Laufzeitumgebung und zentraler Engpass
- Der Testserver ist wiederverwendete Hardware mit Intel Xeon E5-2620 v4 @ 2.10GHz, 8 Kernen, 16 Threads, AVX2, 20 MiB L3-Cache, 2 MiB L2, 128 GB DDR3 und ohne GPU
- Diese CPU unterstützt weder AVX-512 noch AVX-VNNI oder BF16 und besitzt auch keine integrierte GPU
- Bei der LLM-Inferenz ist der Decoder-Pfad, der Token einzeln erzeugt, primär nicht an die Rechenmenge, sondern an die Speicherbandbreite gebunden
- Um das nächste Token zu berechnen, müssen die im Modell gespeicherten Wissensgewichte fortlaufend aus dem RAM in CPU-Cache und Kerne verschoben werden; der Prozessor wartet dabei länger auf das Nachladen der nächsten Gewichte als auf Matrixberechnungen
- Diese „Memory Wall“ ist nicht nur bei Xeon-Systemen, sondern auch auf Hochleistungshardware wie der H100 ein wichtiger Performance-Engpass
Nötige Laufzeit-Regler statt Blackbox-Tools
- Wenn man
llama-cli in einer reinen DDR3-Umgebung ohne GPU einfach so ausführt, ist es sehr langsam, und wegen Optimierungen für typische GPU-Szenarien bleibt viel Potenzial ungenutzt
ollama unterstützt das benötigte Modell möglicherweise nicht und legt nicht genug Detailoptionen offen, um die Laufzeitleistung wirklich auszureizen- Praktisch ist die Ausführung nur durch die Kombination zahlreicher Flags möglich, die
ik_llama.cpp bereitstellt
- Das zentrale Flag-Bündel sieht so aus
--spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune
-sm graph -smgs -sas -mea 256 --split-mode-f32
-t 8 --parallel 8
--cpu-moe --merge-up-gate-experts
--flash-attn on --mla-use 3
--mlock --run-time-repack --no-kv-offload
Speculative Decoding und MoE-Optimierung
--spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune verwendet den 26B-Verifier zusammen mit einem zuvor erzeugten kleinen MTP-Drafter--draft-max 3 bedeutet maximal 3 Token pro Draft, --draft-p-min 0.0 akzeptiert alle Wahrscheinlichkeiten, und --spec-autotune passt die Kettenlänge an die Workload an- Beim Erzeugen langer Inferenzketten sieht der Nutzer zwar womöglich nur eine kurze finale Antwort, aber für jedes verborgene Denk-Token ist ein kompletter Decoder-Pfad nötig
- Auf der CPU ist das Streamen der Verifier-Gewichte in den Cache teuer, während die aktiven Layer des kleinen Drafters gut in den L3-Cache passen; dadurch fällt der Vorteil von Speculative Decoding noch stärker aus
- Gemma 4 26B-A4B ist eine MoE-Architektur, bei der pro Token 8 von 128 Experten aktiv sind; von insgesamt rund 25,2B Parametern sind etwa 3,8B aktiv
--cpu-moe passt das Routing an die CPU-Cache-Hierarchie an und reduziert Cache-Thrashing, das durch ständiges Wechseln zwischen 128 Experten entsteht und DDR3-Nachladungen erzwingt--merge-up-gate-experts fusioniert innerhalb der Experten die Up-Projection und die Gate-Projection zu einer einzigen Matrixmultiplikation; im Log wird das als fused_up_gate = 1 bestätigt-t 8 entspricht den 8 physischen Kernen; bei speichergebundenen Workloads kann das Nutzen aller 16 SMT-Threads mehr Scheduling-Kosten als Durchsatzgewinn bringen
Speicherfixierung, Repacking und Graph-Splitting
--run-time-repack strukturiert Gewichts-Matrizen direkt vor der Inferenz passend zum CPU-Cache-Layout um; im Log erscheint dazu Repacked 265 tensors- Diese Einstellung kostet beim Start einige Sekunden und ordnet die Zahlentabellen im RAM so neu an, dass die CPU sie besser lesen kann und die Speicherbandbreite während der eigentlichen Textgenerierung maximal ausgenutzt wird
--mlock fixiert das Modell im RAM, damit das Betriebssystem es nicht auf die Platte auslagern kann- Wenn das memlock-Limit des Kernels nicht hoch genug ist, erscheinen Warnungen wie
failed to mlock 27628376064-byte buffer und Try increasing RLIMIT_MEMLOCK; das ist kein Problem des LLM selbst, sondern der Standard-ulimit-Konfiguration
--no-kv-offload überspringt in einer GPU-losen Umgebung den Versuch, den KV-Cache auf eine GPU zu verschieben, und hält ihn im Systemspeicher-sm graph versucht Graph-Splitting, also die vertikale Aufteilung des Rechengraphen, damit mehrere Recheneinheiten oder Speicherbereiche unterschiedliche Teile derselben Layer gleichzeitig verarbeiten- In diesem Lauf wurde dies laut Log
Split mode 'graph' is not supported for Gemma4 external MTP sicher auf Layer-Splitting zurückgestuft
-sas weist die Aufteilung der Workload auf physische CPU-Sockel oder NUMA-Knoten an, und --split-mode-f32 erzwingt an den Zwischenpunkten, an denen nach der Aufteilung wieder zusammengeführt wird, 32-Bit-Gleitkommapräzision
Attention, Speichernutzung und Fazit
- ikawrakow hat einen benutzerdefinierten Kernel geschrieben, der Flash Attention auf der CPU verarbeitet und so schwere Kontextverarbeitung ohne GPU ermöglicht
--flash-attn on fusioniert Attention-Softmax und Matrixmultiplikation, sodass die vollständige N×N-Attention-Matrix nicht physisch in den RAM geschrieben wird, sondern in kleinen Blöcken im Cache berechnet und direkt verbraucht wird--mla-use 3 aktiviert Multi-Head Latent Attention und komprimiert Key und Value des KV-Cache in kleinere latente Repräsentationen- Im Log erscheinen
flash_attn = 1, fused_moe = 1, fused_up_gate = 1, was zeigt, dass diese Optimierungen tatsächlich angewendet wurden
- Laut Speicher-Log beträgt die Summe aller Layer 81.607,46 MiB, und der für Modell-Tensoren und Cache benötigte Speicher liegt bei 82.355 MiB
- Beim vollen 262K-Kontext entfallen rund 25 GB auf die Gewichte und rund 56 GB auf den KV-Cache, der damit größer ist als das Modell selbst
- Mit dieser Konfiguration wird ein 25B-Parameter-MoE geladen und Speculative Decoding mit einem MTP-Drafter ausgeführt, sodass auf einem Xeon von 2016 mit DDR3 und ohne GPU Text mit Lesegeschwindigkeit erzeugt wird
- Das Fazit lautet: Der Engpass beim lokalen Ausführen moderner Open-Weight-AI liegt nicht nur in der Hardware selbst, sondern im Verständnis von Inference-Engine und Speicherstruktur; mit dem richtigen Fork, sauber abgestimmter Quantisierung und Verständnis der Speicherarchitektur ist der Betrieb auch auf alten Servern möglich
2 Kommentare
Hacker-News-Kommentare
Ich habe den Beitrag geschrieben, weil es frustrierend war, dass es kaum Möglichkeiten gibt, das neue Modell Gemma 4 Drafter auszuführen, und gängige Tools die Stellschrauben zur Leistungsanpassung verstecken.
Am Ende ist es mir gelungen, auf einem alten wiederverwendeten Server ohne GPU, nur mit einem einzelnen Xeon E5-2620 v4 und 128GB DDR3 RAM, ein aktuelles 26B-MoE-Modell mit Lesegeschwindigkeit laufen zu lassen.
Ich habe am Ende des Beitrags auch auf ein quantisiertes Modell verlinkt, aber ohne den erwähnten Fork ik_llama-cpp wird es wohl nicht laufen, und für Details muss man einen anderen Beitrag lesen.
Ich bin kein Machine-Learning-Ingenieur, und der Server ist auch mit der Rolle als Nix-Cache beschäftigt, aber bei Fragen kann ich antworten, soweit ich kann.
Während ein Thread auf DDR3 wartet, könnte schließlich ein anderer ausgeführt werden.
Außerdem verstehe ich die Beschreibung von
--cpu-moenicht ganz. Wenn ein Experte etwa 4.0GiB an Parametern hat, aber der L3-Cache nur 20MiB groß ist, scheint man selbst mit optimierter Expertenreihenfolge die Parameter nicht sinnvoll cachen zu können.Und wie andere schon gesagt haben: Nur einige Intel Xeon E5-2xxx v4 unterstützten DDR3, und laut Intel-Unterlagen gehört E5-2620 v4 nicht dazu.
Sie hat zwei Xeons und 128GB DDR3, die CPUs sind 2 × Xeon E5-2697 v2 mit insgesamt 24 Kernen / 48 Threads, also bei der Kernzahl besser, aber der reale Unterschied muss vielleicht nicht groß sein.
Das Gerät steht hier ohnehin nur herum und setzt Staub an, aber für Gemma mit Lesegeschwindigkeit klingt das ziemlich vielversprechend.
Sucht bei Amazon nach „chia farming“, aber überspringt die Chia-Samen.
Inzwischen ist dieselbe Hardware etwa 2,5-mal so teuer geworden, aber immer noch viel günstiger als aktuelle DDR5-Maschinen.
https://www.amazon.com/dp/B095TRGCSX
Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz, Online-CPU 0-31, mit 128GB RAM.Ich frage mich, ob acht DIMM-Slots tatsächlich auch in der Praxis mehr Speicherbandbreite bringen. Im Moment wird diese arme Maschine nur zum YouTube-Schauen benutzt.
Noch sind wir nicht ganz dort, aber der offensichtliche Endpunkt nach dem Ende der aktuellen Blase ist, dass offene Modelle, die auf lokaler Hardware und Geräten laufen, für die meisten Anwendungsfälle „gut genug“ werden.
Dann könnte das, was derzeit in der Tech-Branche passiert, komplett zusammenbrechen.
Wenn ich wirklich feststecke, werde ich die Claude API aufrufen, aber für 80 % meines Bedarfs dürfte ein dümmeres lokales Modell reichen.
Programmiersprachen und Techniken ändern sich nicht so stark, daher hoffe ich, dass ich es mindestens fünf Jahre lang nutzen kann; und wenn es so weit optimiert wird, dass ein klügeres Modell in denselben VRAM passt, kann ich dann aufrüsten.
Diese Richtung gefällt mir.
Meine Vermutung, warum sie es nicht tun: Die aktuellen AI-Labs verkaufen ihre Modelle mit hohen Verlusten, sodass Computing mit niedriger Marge für Amazon weniger attraktiv ist als andere Produkte mit hoher Marge.
Vielleicht muss es gar nicht erst bis zur lokalen Ausführung kommen, damit der aktuelle Zustand kollabiert. Sobald den AI-Labs das kostenlose Geld als Runway ausgeht und sie Preise oberhalb der tatsächlichen Ausführungskosten verlangen müssen, entsteht für jeden mit Computing-Ressourcen ein Anreiz, offene Modelldienste zu allgemeinen Marktpreisen günstiger anzubieten.
Jeder wird Modelle haben und sie ausführen können, und deshalb spielt ihnen der GPU-Mangel in die Hände.
Ihre Hoffnung hängt daran, dass Konzerne und KMU alle Arbeitsprozesse in die Cloud verlagern und die Mitarbeiter darum konkurrieren, möglichst viele Tokens zu verbrauchen.
Ein „gut genuges“ Modell wird zusammen mit Privatsphäre und langfristigen Kosteneinsparungen attraktiv.
Paradoxerweise schrumpft der Burggraben von Diensten wie Claude, je besser universelle Ausführungsumgebungen für Coding-Agenten werden. Es ist kaum zu glauben, wie schnell manche offenen Modelle in nur wenigen Monaten zu den Frontier-Modellen aufgeschlossen haben.
Guter Beitrag und auch technisch beeindruckend. Ich stimme zu, dass man die Build-Pipeline verstehen und Dinge lokal ausführen können sollte.
Allerdings ist es je nach Strompreis womöglich wirtschaftlich nicht sinnvoll. Alte Server sind energieineffizient, und ich dachte, ein älterer Xeon-Server würde unter Last etwa 200W ziehen, während dasselbe Modell bei OpenRouter für 0,1/0,3 Dollar pro Million Tokens, mit 76 Tokens/s und 262k Kontext angeboten wird.
Dazu kommt, dass solche Server laut sind. Allerdings war die Schätzung von 200W wohl zu hoch; meine alten Xeon-Server früher haben viel Strom verbraucht, aber an die genauen Modelle erinnere ich mich nicht mehr.
Server sind meistens laut, aber auch das hängt von der Konfiguration ab. Es gibt viel günstiges Hosting auf Basis solcher Chips, und sie sind überraschend energieeffizient.
Mit einer ähnlichen Konfiguration in einem 4U-Gehäuse und langsamen 120mm-Lüftern ist das völlig in Ordnung.
Es freut mich zu sehen, dass auch andere das erkennen. Ich lasse Gemma 26B-A4B Q4 auf einem Xeon von 2012 und einem Container mit 16–24 GB RAM laufen und komme auf ungefähr 8–12 Token/s.
Mit großem Kontext oder GPU-Ausführung ist das natürlich nicht vergleichbar, und auch der Bilddecoder von llama.cpp ist viel langsamer als auf der GPU, aber für kleine Automatisierungsaufgaben oder allgemeine Wissensfragen reicht es gut aus. Es ist schnell genug, dass man beim Lesen noch mitkommt, also fühlt sich das Warten weniger störend an.
Das Setup ist ein
llama.cpp-Build mit aktiviertem OpenBLAS und OpenMP,OPENBLAS_NUM_THREADS=4,OMP_NUM_THREADS=4,unsloth/gemma-4-26B-A4B-it-GGUF:UD-Q4_K_XL,q8_0-Cache und 8192 Kontext.Je nach CPU sollte man nach Optimierungen wie AVX2 schauen; MTP habe ich kurz ausprobiert, aber ohne Leistungsgewinn. Man kann auch Cache-/Kontext-Batch-Größen anpassen oder bis auf Q2 heruntergehen, und man sollte zu viele Threads vermeiden. Ich würde empfehlen, mit den Standardwerten oder
llama-benchanzufangen.Beim Testen lief
gemma4:e4b-it-q4_K_M, das komplett in 11 GB VRAM passt, und ich kam auf über 50 Token/s. Fürs Programmieren sind so kleine Modelle zwar nicht besonders nützlich, aber für andere Zwecke könnten sie taugen.Ich würde gern ein Wake-on-Use bauen und es wie ein persönliches ChatGPT verwenden. Vielleicht könnte ein Pi als Proxy dienen und ein Wake-on-LAN-Skript aufrufen; irgendwann wäre das wohl ein lustiges Wochenendprojekt.
Das LLM, das immer läuft, ist das dichte
Gemma4:31b, das nicht einmal zur Hälfte auf eine 12-GB-2060 passt. Es ist sehr langsam, aber die Qualität ist gut, und weil es für automatische Queue-Verarbeitung gedacht ist, sitze ich nicht davor und warte auf die Ausgabe. Ich habe noch eine zweite 2060, aber wenn beide eingebaut sind, kommt der PC nicht durch den POST.Ich habe eine Zeit lang über einen Mac Studio Pro nachgedacht und bin dann am Ende doch diesen Weg gegangen. Eine headless HP Z620 mit 192 GB ECC-RAM, Dual Xeon E5-2680 v2, Optane AIC, zwei P102-100 mit 10 GB VRAM, einer minimalen Boot-SSD mit Debian 12.6 und einer festgepinnten älteren CUDA-Version, die Pascal-Karten unterstützt.
Ich nutze sie per AMT/meshcommander aus dem Keller fern, starte
llama.cppund ein Frontend und greife dann über das lokale Netzwerk darauf zu. Ich experimentiere mit Talkie, Qwen 3.6 27b und medgemma, und mit der richtigen Quantisierung war die GGUF-Performance insgesamt ziemlich ordentlich.Die Gesamtkosten lagen unter 500 Dollar, aber ich habe den Server letztes Jahr bei eBay gekauft, also kann das inzwischen anders aussehen.
Wenn ternäre LLMs künftig richtig aufblühen, hoffe ich, dass diese alte Hardware am Ende tatsächlich hochdichte, wissensstarke Modelle hosten kann. Es ist in Ordnung, wenn sie größer als der GPU-RAM sind und auf Optane auslagern müssen; allgemeines Faktenwissen ist mir wichtiger als Geschwindigkeit.
Der Endplan ist, das Ganze nach der Einrichtung in einer Faraday-Mülltonne im Keller zu lagern, damit es beim Zusammenbruch der Welt als Orakel zum „Wiederaufbau der Zivilisation“ übrig bleibt. Natürlich wäre in so einem Szenario Strom ein Problem, aber wenn diese Hardware so billig ist und moderne AI damit oft praktisch nutzbar wird, ist es einen Versuch wert.
Das Interessanteste an der AI-Entwicklung sind für mich nicht AGI oder das neueste Modell irgendeines bestimmten AI-Einhorns, sondern was man lokal laufen lassen kann.
Vor sechs Jahren konnte man auf einem High-End-Gaming-PC Modelle laufen lassen, die zwar lustig, aber kaum nützlich waren; heute kann man auf einem M5-Laptop etwas starten, das 100-mal besser ist.
Wenn der Markt auf den Speichermangel reagiert und sich Apple silicon im gleichen Tempo weiterentwickelt, dann wird das, was in sechs Jahren lokal möglich ist, entweder sehr spannend oder ziemlich beängstigend sein.
Ich weiß auch nicht, was das für die Bewertungen von AI-Unternehmen bedeutet. Ich habe einem Mitarbeiter eines solchen Unternehmens auf einer Veranstaltung einmal etwas Ähnliches gefragt, und statt zu antworten ist er sich einen Cocktail holen gegangen.
Das AI-Geschäft ist kapitalintensiv wie eine alte Fabrik. Rechenzentren sind teuer, Modelle verbrauchen viel Strom, und die interne Hardware muss alle 3–4 Jahre ersetzt werden.
Kleinere, spezialisierte Modelle knabbern von unten an den Margen. Für Transkription, Sprache oder Bilderkennung braucht man keine riesigen Modelle.
Es gibt keinen Grund, ähnliche hohe Margen wie im traditionellen Softwaregeschäft zu erwarten, und der Großteil des Nutzens aus AI geht an die Verbraucher. Nur ein paar sehr große Unternehmen wie Microsoft, Google, Amazon und Meta könnten durch Skaleneffekte Kostenvorteile erzielen.
Es muss keine Spitzenklasse wie eine 5080 sein; schon mit einer ordentlichen Gaming-GPU kann man lokale Modelle betreiben, die besser sind als der Stand der Technik von Anfang 2025.
Je nach Aufgabe muss man vielleicht das Modell wechseln, und ein einziges extrem großes Modell, das alles kann, bleibt vorerst Sache der Rechenzentren.
Aber die meisten Menschen mit Vollzeitjob und zwei Kindern haben weder die Zeit noch die Energie, alles zu patchen und zu warten. Systeme werden immer komplexer und fehleranfälliger. Es ist der alte Trade-off zwischen Freiheit und Bequemlichkeit.
Die meisten Nutzer wissen weder, was ein LLM ist, noch wie man es ausführt. Viele LLM-Nutzer verwenden einfach das, was ihnen bei der Arbeit bereitgestellt wird, und selbst etwas versiertere Nutzer scheinen kein Problem damit zu haben, OpenAI- oder Anthropic-Abos zu bezahlen.
Es wird wohl eine kleine, aber engagierte Nutzerschicht für offene Modelle mit offenen Gewichten geben, die lokale LLMs bevorzugt, aber alle anderen werden wahrscheinlich weiterhin bei großen Anbietern konsumieren. Das könnte am Ende ähnlich aussehen wie bei Betriebssystemen heute: eine kleine Minderheit von Linux-Nutzern und die große Mehrheit bei Windows, macOS oder Chrome.
Spiele, die 5–6 Jahre alt sind, bekommt man viel günstiger und sie laufen auch auf gewöhnlicher Hardware. Aber die Branche bleibt fünf Jahre lang nicht stehen, deshalb kommt ständig neue Software, die bessere Hardware braucht.
Das vom Autor des Originalbeitrags in den Kommentaren genannte Ergebnis liegt bei etwa 12 Token/s
Das ist eine viel beeindruckendere Leistung, als ich auf dieser Hardware für möglich gehalten hätte, aber für eine zufriedenstellende interaktive Sitzung fehlt noch einiges
Oft 100- bis 500-mal billiger als modernste Modelle, und teils auch 2- bis 5-mal schneller bei Token/s
Für Hintergrundaufgaben wäre das völlig in Ordnung
Es funktioniert, aber der Durchsatz reicht nicht für ernsthafte Arbeit
Der E5-2620 v4 ist großartig. Ich nutze ihn seit 10 Jahren und wollte aufrüsten, habe dann aber die aktuellen Preise gesehen und es gelassen
Mit 64 GB DDR4 und einer RX 9060 XT 16 GB laufen Spiele immer noch schnell. In DOOM The Dark Ages könnte die CPU ein kleiner Flaschenhals sein, aber bei 60 fps ist das kein Problem
Ein leichtes LLM auf der GPU laufen zu lassen, ist natürlich die naheliegende Wahl, und es ist cool, dass es auf der CPU mit Tuning ebenfalls ordentlich läuft
Vor einem Monat habe ich einen 2667 v4 für 30 Dollar gekauft; es dürfte einen spürbaren Leistungsschub geben, aber bisher brauchte ich ihn noch nicht. Wenn ich wie im Artikel stärker in Richtung LLM gehen würde, würde ich wohl auf den 2667 aufrüsten, weil er etwas schnelleren RAM verarbeiten kann
Ich bin immer noch ziemlich überrascht, was man auf dem Gebrauchtmarkt finden kann
Ich hatte nicht damit gerechnet, dass die Preise für RAM und GPUs so stark anziehen würden, also hatte ich einfach Glück mit dem Timing. Ich überlege auch, eine 3080 für rund 300 Dollar bei eBay zu ergattern und die 1080 Ti zu verkaufen, aber abgesehen davon war es ein großartiges Upgrade
Das Ding säuft Strom wie Coca-Cola, aber als Workstation funktioniert es hervorragend, also werde ich es fahren, bis es kaputtgeht
Früher dachte ich, Hitzeschäden würden eine CPU nach etwa 5 bis 7 Jahren töten, aber vielleicht war das eine falsche Annahme. Vielleicht sind moderne CPUs einfach viel robuster und widerstandsfähiger als früher
Kürzlich gab es einen ähnlichen Beitrag zur Optimierung alter Xeons
„High-Performance AI on a Budget: Optimizing llama.cpp for Qwen3.5 Inference on a Dual-GPU HP Z440”
https://news.ycombinator.com/item?id=47320244
Überraschenderweise scheint auch Itanium ziemlich gut für LLMs geeignet zu sein: https://medium.com/@tglozar/running-llama-inference-on-intel...
Wenn man darüber nachdenkt, ergibt das durchaus Sinn
Der Inhalt ist interessant. Ich habe ein älteres Xeon-System, das sollte ich einmal ausprobieren.