PowerInfer: LLM-Inferenz mit Hot- und Cold-Neuronen auf einer Consumer-GPU

Welches Problem PowerInfer adressiert

Ein 40B-Modell in FP16 passt nicht in die 24 GB einer RTX 4090. Der übliche Ausweg ist aggressive Quantisierung oder das Auslagern von Schichten auf die CPU, beides mit Qualitäts- oder Geschwindigkeitsverlust. PowerInfer setzt an einer anderen Beobachtung an: Die Aktivierung von Neuronen in einem LLM folgt einer Power-Law-Verteilung. Ein kleiner Teil der Neuronen, im Papier hot neurons genannt, feuert über verschiedene Eingaben hinweg konstant. Die Mehrheit, die cold neurons, hängt von der konkreten Eingabe ab.

Wenn sich vorhersagen lässt, welche Neuronen heiß sind, muss nur dieser Teil dauerhaft im GPU-Speicher liegen. Der Rest wird zur Laufzeit auf der CPU berechnet. Der Speicherbedarf auf der GPU sinkt dadurch, ohne dass das gesamte Modell quantisiert werden muss. Die Zielgruppe sind Anwender mit einer einzelnen Consumer-GPU, die ein Modell betreiben wollen, das nominell nicht in deren VRAM passt. Das ist ein engerer Zuschnitt als bei allgemeinen Inferenz-Engines.

Hot und Cold: der eigentliche Mechanismus

Die Engine teilt die Berechnung eines Modells räumlich auf. Heiß aktivierte Neuronen werden vorab auf die GPU geladen und dort gehalten. Kalt aktivierte Neuronen laufen auf der CPU. Weil zwischen beiden Gruppen nur die Aktivierungen ausgetauscht werden müssen und nicht die Gewichte, fällt der Datenverkehr über den PCIe-Bus geringer aus als bei einem schichtweisen Offloading.

Zwei Bausteine tragen diesen Aufbau. Erstens adaptive Prädiktoren, die abschätzen, welche Neuronen im nächsten Schritt aktiv werden. Zweitens neuron-aware sparse operators, die die tatsächliche Aktivierung und die daraus folgende Rechenersparnis ausnutzen. Beide Begriffe stammen aus der Projektbeschreibung; wie die Prädiktoren intern trainiert oder kalibriert werden, geht aus dem vorliegenden Material nicht hervor. Wer den Mechanismus im Detail nachvollziehen will, ist auf das Paper verwiesen, nicht auf das Repository.

Entscheidend ist die Kopplung an die Modellarchitektur. Das Verfahren greift nur, wenn die Aktivierungsfunktion ReLU ist und die Gewichte entsprechend sparse sind. Ein dichtes Modell hat keine kalten Neuronen, die man auslagern könnte, und damit auch keinen Hebel.

Welche Gewichte überhaupt in Frage kommen

Das README nennt konkret: Falcon-40B, die Llama2-Familie, die ProSparse-Llama2-Familie und Bamboo-7B. Dazu kommen die separat veröffentlichten SmallThinker-Modelle (SmallThinker-21BA3B-Instruct und SmallThinker-4BA0.6B-Instruct) mit einem eigenen Framework unter smallthinker/. Die ProSparse-Modelle von THUNLP und ModelBest werden mit rund 90 Prozent Sparsity angegeben und sollen die Leistung des ursprünglichen Llama 2 erreichen.

Wer ein Modell außerhalb dieser Liste laden will, muss mit zwei Fällen rechnen. Bei einem ReLU-sparse Modell, das nicht explizit getestet wurde, ist unklar, ob die Prädiktoren sauber greifen. Bei einem dichten Modell greift der Mechanismus gar nicht. Das README formuliert das selbst: llama.cpp-Gewichte werden aus Kompatibilitätsgründen unterstützt, aber ohne Performance-Gewinn. Das ist die wichtigste Zeile im Dokument, weil sie den Anwendungsbereich scharf begrenzt.

Build und Start: was das Material hergibt

Die Installation läuft über CMake. Das README listet CMake als Voraussetzung und verweist auf die Abschnitte Setup and Installation, Model Weights und Inference. Der bereitgestellte Text bricht mitten in der CMake-Versionsangabe ab ("CMake (3"), sodass die konkreten Build-Kommandos, die benötigten Flags und die Modellpfad-Konfiguration hier nicht wiedergegeben werden können. Wer die Engine aufsetzen will, muss die vollständige Installationsanleitung im Repository lesen; aus dem vorliegenden Ausschnitt lassen sich keine Befehle ableiten, ohne zu raten.

Klar erkennbar ist dagegen die Kompatibilitätszusage: Die Beispiele unter examples/ lassen sich laut README weitgehend so verwenden wie bei llama.cpp, einschließlich Server und Batched Generation. Das ist praktisch relevant, weil bestehende Startskripte und Client-Aufrufe oft unverändert bleiben können. Ebenso klar ist die Plattformliste: x86-64 mit AVX2 unter Linux und unter Windows, jeweils mit oder ohne NVIDIA-GPU, sowie Apple M Chips unter macOS ausschließlich auf der CPU. Ein Metal-Backend für sparse Inferenz steht laut README noch aus.

Wo der Ansatz an seine Grenzen stößt

Die Abhängigkeit von ReLU-sparse Gewichten ist keine Nebenbedingung, sondern die Grundvoraussetzung. Wer mit einer dichten Modellfamilie arbeitet, für die es keine sparse Variante gibt, kann PowerInfer nicht sinnvoll einsetzen. Die Auswahl auf Hugging Face ist derzeit auf die oben genannten Familien begrenzt.

Der zweite Punkt ist die Hardware. Der Vorteil entsteht aus der Aufteilung zwischen GPU und CPU. Auf Apple M Chips läuft die Engine laut README nur auf der CPU, und dort wird ausdrücklich keine signifikante Verbesserung in Aussicht gestellt, weil nicht für diese Plattform optimiert wird. Wer auf einem MacBook arbeitet, bekommt also nicht das, was die Benchmark-Zahlen der RTX 4090 nahelegen.

Der dritte Punkt betrifft die Prädiktoren. Wenn die Vorhersage, welche Neuronen heiß sind, daneben liegt, muss die CPU einspringen, und der Durchsatz sinkt. Wie stark die Genauigkeit der Prädiktoren über verschiedene Eingabeverteilungen schwankt, lässt sich aus dem vorliegenden Material nicht beurteilen. Das ist eine offene Frage, keine bekannte Schwäche.

llama.cpp als Vergleich, nicht als Fußnote

Die naheliegende Alternative ist llama.cpp. Der Unterschied liegt nicht in der Geschwindigkeit auf identischer Hardware, sondern im Verfahren. llama.cpp quantisiert Gewichte und kann Schichten zwischen GPU und CPU verschieben; die Rechenlast pro Token bleibt im Wesentlichen dieselbe, nur die Zahl der Operationen und der Speicherbedarf sinken. PowerInfer lässt einen Teil der Rechenarbeit ganz weg, weil kalte Neuronen nicht auf der GPU anfallen, und verlagert die übrige auf die CPU.

Das erklärt, warum die Ansätze nicht gegeneinander austauschbar sind. llama.cpp läuft mit praktisch jedem GGUF-Modell und ist damit breiter einsetzbar. PowerInfer gewinnt nur dort, wo sparse Gewichte vorliegen, und verliert diesen Vorteil, sobald man dichte Gewichte lädt. Das README nennt für Falcon(ReLU)-40B-FP16 auf einer RTX 4090 einen 11x-Speedup gegenüber llama.cpp bei gleicher Hardware und voll ausgelastetem VRAM. Diese Zahl gilt für genau dieses Modell auf genau dieser Karte. Eine Übertragung auf andere Modelle oder kleinere GPUs ist damit nicht belegt.

Wartung, Lizenz und was der Reifegrad verrät

PowerInfer steht unter der MIT-Lizenz. Das erlaubt kommerzielle Nutzung und Modifikation, solange Lizenz- und Copyright-Hinweis erhalten bleiben. Für abgeleitete Produkte ist das eine niedrige Hürde, aber die Lizenz des Modellgewichts ist davon unberührt: Wer ProSparse- oder Bamboo-Gewichte einsetzt, muss deren jeweilige Bedingungen separat prüfen. Rechtsberatung ist das nicht, nur der Hinweis auf die zwei getrennten Ebenen.

Zum Wartungsstand lässt sich aus dem Material sagen: Der letzte Push liegt bei Mai 2026, archiviert ist das Repository nicht. Es gibt keine abgerufenen Releases, was bedeutet, dass Versionsstände über Commits und nicht über Tags verfolgt werden müssen. Die Entwicklungsplanung läuft über ein Project Kanban der Organisation SJTU-IPADS. Wer auf stabile Schnittstellen angewiesen ist, sollte dort nachsehen, welche Punkte als offen geführt werden, statt aus dem README auf einen eingefrorenen Stand zu schließen.

Bemerkenswert für die Einordnung: Das Repository liegt unter Tiiny-AI, während README und Kanban auf SJTU-IPADS verweisen. Die News-Einträge reichen von der ursprünglichen Veröffentlichung im Dezember 2023 über ROCm-Unterstützung und Windows-GPU-Inferenz bis zu SmallThinker-Modellen im Juli 2025 und einem Hardware-Produkt im Januar 2026. Das deutet auf ein Projekt, das in mehrere Richtungen weiterentwickelt wird. Für Anwender heißt das: Der Inferenzkern ist nicht das einzige Ziel der Arbeit, und nicht jede Änderung wird die CPU/GPU-Aufteilung betreffen.

Redaktionelles Fazit

Wer ReLU-sparse Gewichte wie ProSparse Llama 2 oder Bamboo-7B einsetzt und auf einer einzelnen Consumer-GPU mit begrenztem VRAM arbeitet, findet hier einen passenden Ansatz. Wer dichte Standardgewichte fährt, sollte nicht auf einen Geschwindigkeitsvorteil hoffen: Das README hält ausdrücklich fest, dass llama.cpp-Gewichte zwar geladen werden können, aber keinen Performance-Gewinn bringen. Vor dem Aufsetzen sollte man klären, ob die Zielplattform in der Liste der getesteten Systeme steht (x86-64 mit AVX2 unter Linux oder Windows, Apple M nur CPU-seitig und laut README ohne deutliche Verbesserung) und ob das gewünschte Modell zu den genannten Familien gehört.

Offizielle Quellen

1. Issues
2. License: MIT
3. README
4. Tiiny-AI/PowerInfer on GitHub