Schnelles Serving großer Sprachmodelle auf PCs mit Consumer-GPUs

 (github.com/SJTU-IPADS)
1 Punkte von GN⁺ 2023-12-21 | 1 Kommentare | Auf WhatsApp teilen
  • PowerInfer ist eine CPU/GPU-Hybrid-Inferenz-Engine, um LLMs lokal auf einem PC mit einer einzelnen Consumer-GPU zu serven
  • Das Kerndesign nutzt die Aktivierungslokalität der LLM-Inferenz: häufig aktivierte Hot-Neuronen werden vorab auf die GPU geladen, während Cold-Neuronen, die sich je nach Eingabe ändern, auf der CPU berechnet werden
  • In der Evaluation erreichte PowerInfer mit einer einzelnen RTX 4090 für mehrere LLMs, darunter OPT-175B, im Durchschnitt 13.20 tokens/s und maximal 29.08 tokens/s; laut den Angaben liegt das nur 18 % unter einer A100
  • Im Vergleich zu llama.cpp wird für die Falcon(ReLU)-40B-FP16-Demo auf einer RTX 4090 24GB eine 11x Geschwindigkeitssteigerung genannt; in der Evaluation wurden bis zu 11.69x erreicht, bei gleichbleibender Modellgenauigkeit
  • Der unterstützte Bereich konzentriert sich auf Modelle mit den Aktivierungsfunktionen ReLU/ReGLU/Squared ReLU; Mistral, original Llama, Qwen und andere werden derzeit nicht unterstützt

Das Problem, das PowerInfer lösen will

  • PowerInfer ist eine CPU/GPU-Inferenz-Engine, um LLMs schnell auf lokalen Geräten auszuführen
  • Sie richtet sich an PCs mit einer einzelnen Consumer-GPU und zielt auf LLM-Inferenz und Serving mit geringer Latenz
  • Der Kern des Designs ist die Beobachtung, dass die Neuronenaktivierung bei der LLM-Inferenz einer Potenzgesetzverteilung folgt
    • Einige Hot-Neuronen werden über verschiedenste Eingaben hinweg konsistent aktiviert
    • Viele Cold-Neuronen variieren je nach spezifischer Eingabe

CPU/GPU-Hybrid-Inferenzansatz

  • PowerInfer lädt Hot-Neuronen vorab in die GPU, um schnell darauf zuzugreifen, und berechnet Cold-Neuronen auf der CPU
  • Dieser Ansatz konzentriert sich darauf, den GPU-Speicherbedarf und die Datenübertragung zwischen CPU und GPU zu reduzieren
  • Zusätzlich integriert PowerInfer einen adaptiven Predictor und neuronensensitive Sparse-Operatoren, um Neuronenaktivierung und Rechensparsity zu optimieren
  • Bei der CPU-GPU-Hybrid-Inferenz werden zunächst alle Dense-Activation-Blöcke automatisch auf die GPU offgeladen; danach wird, wenn möglich, das FFN aufgeteilt und auf die GPU offgeladen

Performance-Evaluation und Demo

  • Auf einer einzelnen RTX 4090 erreichte PowerInfer für mehrere LLMs, darunter OPT-175B, durchschnittlich 13.20 tokens/s und maximal 29.08 tokens/s
  • Dieses Ergebnis wird als nur 18 % unter einer High-End-Server-GPU A100 beschrieben
  • Gegenüber llama.cpp ist PowerInfer laut Angaben bis zu 11.69x schneller, bei gleichbleibender Modellgenauigkeit
  • In der Demo wurde Falcon(ReLU)-40B-FP16 auf einer einzelnen RTX 4090 24GB ausgeführt und zeigte gegenüber llama.cpp eine 11x höhere Geschwindigkeit
    • Sowohl PowerInfer als auch llama.cpp liefen auf derselben Hardware und nutzten den VRAM der RTX 4090 vollständig aus
  • In einer separaten Evaluation unter den Bedingungen RTX 4090 24GB, FP16-ReLU-Modelle und Eingabelänge 64 zeigte Falcon 40B bis zu 11x, Llama 2 70B bis zu 3x Geschwindigkeitssteigerung
  • Unter den Bedingungen RTX 2080Ti 11GB, INT4-ReLU-Modelle und Eingabelänge 8 zeigte Falcon 40B bis zu 8x, Llama 2 70B bis zu 3x Geschwindigkeitssteigerung

Unterstützte Modelle und Plattformen

Installations- und Ausführungsablauf

  • Build-Abhängigkeiten sind CMake 3.17 oder neuer, Python 3.8 oder neuer und pip 19.3 oder neuer
  • Für NVIDIA-GPU-Builds wird die Option -DLLAMA_CUBLAS=ON verwendet
  • Für AMD-GPU-Builds auf Basis von ROCm/HIP werden -DLLAMA_HIPBLAS=ON und AMDGPU_TARGETS angegeben
  • Ein CPU-only-Build ist ebenfalls möglich
  • Der grundlegende Inferenzbefehl verwendet die ausführbare Datei main mit Angabe von Modellpfad, Anzahl der Ausgabetoken, Thread-Zahl und Prompt
  • Das Limit für die GPU-VRAM-Nutzung wird mit der Option --vram-budget festgelegt
  • Serving, Perplexity-Evaluation und Batched Generation unterstützen in PowerInfer Befehle im gleichen Stil wie llama.cpp, aber das Argument -ngl wird in PowerInfer durch --vram-budget ersetzt

Quantisierung und Kompatibilität

  • PowerInfer unterstützt optimiert die INT4-Quantisierung Q4_0
  • Mit der ausführbaren Datei quantize können PowerInfer-GGUF-Modelle in das Format Q4_0 quantisiert werden
  • Der Dense-Inference-Mode wird eingeschränkt unterstützt und kann ähnlich wie bei llama.cpp verwendet werden
  • Der Dense-Inference-Mode ist kein Kompatibilitätsmodus für alle Modelle
    • Bei ReluLLaMA- und ProSparse-Modellen wurde die Aktivierungsfunktion geändert
    • Bei Bamboo-Modellen wurde die Modellarchitektur geändert
  • Auch mit den Modellgewichten von llama.cpp kann zur Inferenzkompatibilität ausgeführt werden, allerdings ohne Performance-Gewinn

Einschränkungen und FAQ

  • Derzeit unterstützte Modelle sind auf solche mit den Aktivierungsfunktionen ReLU/ReGLU/Squared ReLU beschränkt
  • Mistral, original Llama, Qwen und andere werden derzeit nicht unterstützt
  • Wenn CUDA_ERROR_OUT_OF_MEMORY auftritt, kann der GPU-Index mit --reset-gpu-index neu erstellt werden
  • In der aktuellen Implementierung kann das Modell-Offloading weniger präzise als erwartet sein; in diesem Fall kann der Wert von --vram-budget etwas reduziert oder das FFN-Offloading mit --disable-gpu-index deaktiviert werden
  • Der Rückgang der Performance-Metriken bei ReLU-Modellen, insbesondere beim 70B-Modell, wird damit erklärt, dass statt der für allgemeines LLM-Training nötigen etwa 2T Token nur 5B Token für das Finetuning verwendet wurden

Jüngste Updates und Pläne

  • Am 5. Januar 2026 wurde Tiiny AI Pocket Lab veröffentlicht; dort wird angegeben, dass GPT-OSS-120B int4 lokal mit 20 tokens/s läuft
  • Am 27. Juli 2025 wurden SmallThinker-21BA3B-Instruct und SmallThinker-4BA0.6B-Instruct veröffentlicht
  • Am 11. Juni 2024 wurde mit PowerInfer-2 ein optimiertes Inferenz-Framework für Smartphones vorgestellt; dort werden 11.68 tokens/s auf TurboSparse-Mixtral-47B angegeben
  • Am selben Tag wurde Turbo Sparse veröffentlicht; dort wird beschrieben, dass Mistral- und Mixtral-Modelle auf etwa 90 % Sparsity gebracht werden und bei Modellen der Mixtral-Klasse nur 4B Parameter aktiviert werden
  • Zu den abgeschlossenen Punkten gehören die Veröffentlichung des PowerInfer-Kerncodes, Unterstützung für Llama-2 und Falcon-40B, Unterstützung für Bamboo-7B, Windows-Support, Veröffentlichung des Codes für die Perplexity-Evaluation sowie Unterstützung für Online-FFN-Splitting
  • Zu den verbleibenden Punkten gehören Unterstützung für text-generation-webui, Metal-Support für Mac, Veröffentlichung des Codes für OPT-Modelle, Veröffentlichung des Predictor-Trainingscodes und Multi-GPU-Support

Paper und zugrunde liegende Projekte

  • Ausführlichere technische Details sind im PowerInfer-Paper zusammengefasst
  • PowerInfer verwendet die anpassbare Operator-Bibliothek von ggml sowie die Runtime von llama.cpp
  • Für die Unterstützung von Sparse-Modellen auf ReLU-Basis wird THUNLP erwähnt
  • Laut den Angaben wurde PowerInfer von der Studie Deja Vu inspiriert

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-12-21
Meinungen auf Hacker News

  • In den meisten Bereichen des Machine Learning gibt es kein Konzept von hot/cold Neuronen, daher hat es eine Weile gedauert, das zu verstehen; auch das Paper scheint es nicht direkt zu definieren.
    Bei ReLU ergibt es Sinn, einen Ausgang als „cold“ zu betrachten, wenn er häufig 0 ist, aber das ursprüngliche LLaMA verwendet kein ReLU. Beim erneuten Blick auf GitHub zeigt sich, dass diese Methode tatsächlich nur mit ReLU-Modellen funktioniert, und dass es eine Gruppe gibt, die Modelle auf ReLU „feintuned“, um Sparsity zu erhalten: https://huggingface.co/SparseLLM
    Daher lässt es sich nicht auf beliebige Modelle anwenden, die man üblicherweise im Internet findet, aber der Fortschritt an sich wirkt groß. Künftig könnte es auf einen Kompromiss zwischen größeren Modellen und weniger idealen Aktivierungsfunktionen hinauslaufen, und ich frage mich auch, wie Sparsity berechnet wird, wenn US- oder EU-Regulierung FLOPs oder Parameterzahlen als Maßstab nimmt.
    Als zukünftige Forschung erscheint eine Richtung denkbar, bei der bestehende Aktivierungsfunktionen wie LLaMAs SwiGLU beibehalten werden, aber über Quantisierung Sättigungsbereiche als hot/cold Neuronen definiert werden.

    • Ich frage mich, wann und wie solche Regulierung entstanden ist. Es fühlt sich ziemlich seltsam an, beim Entwickeln sogar auf Regulierung von FLOPs/Parameterzahlen achten zu müssen.
    • Dass im README, das LLaMA-Kompatibilität behauptet, der wichtige Hinweis nur für ReLU-Modelle fehlt, ist ein ziemlich großes Problem.
    • Auch bei https://huggingface.co/SparseLLM/ReluFalcon-40B steht: „We utilize PowerInfer for inference“.

  • Es wäre wirklich großartig, wenn man damit ein unzensiertes Mixtral laufen lassen könnte. Auf einer RTX 4090 könnte sogar Quantisierung oberhalb von 3 Bit möglich werden.

    • Ich frage mich, warum das Downvotes bekommt: Unzensierte LLMs schneiden normalerweise, zumindest in Benchmarks, besser ab als „lobotomisierte“ oder alignte Versionen.
    • In der Demo läuft ein größeres Modell auf einer RTX 4090 mit 24 GB VRAM. Sparse Activation für Mixture of Experts zu implementieren, ist vielleicht nicht einfach, aber es wirkt wie eine hervorragende Richtung, die Verarbeitung nur auf der CPU oder sogar auf deutlich günstigeren GPUs ermöglichen könnte.
      Auch Mixtral hat technisch gesehen bereits eine durch ein neuronales Netz gesteuerte Sparse Activation, aber wie im Inception-Meme muss man „noch tiefer gehen“.
    • Dual-GPU kann man wohl auch noch als normale Consumer-Konfiguration betrachten, und ich hoffe, dass es bald unterstützt wird. Bei 4 Bit sollte auch noch reichlich Kontextspeicher hineinpassen.
      Das Ganze ist ein Fork von llama.cpp, daher hoffe ich, dass es irgendwann ins Upstream-Projekt gelangt.
    • Sieht gut aus: https://www.youtube.com/watch?v=q2KpPUOsBCs

  • Da sie an Mistral-7B arbeiten: Meine GPU-only-Mistral-Implementierung nutzt etwas mehr als 5 GB VRAM: https://github.com/Const-me/Cgml
    Sie läuft auf den meisten Consumer-GPUs ziemlich gut, unterstützt derzeit aber nur Windows.

    • Sieht ziemlich interessant aus. Ich frage mich, ob es auch auf einem Intel-Core-i7-Laptop läuft.
    • Probier ollama aus. Es verwendet llmcpp und braucht nur etwa 4 GB.

  • Wirklich beeindruckend. llama.cpp ist zwar beliebt, aber sein Offloading auf externe GPUs ist ein relativ einfacher Ansatz: Prompt-Verarbeitung auf der GPU und das Modell in der Mitte aufteilen.
    Interessant ist, dass die Aktivierungs-Sparsity groß genug ist, um sie auszunutzen; aus traditioneller Machine-Learning-Sicht würde man Speicherzugriffe als sehr zufällig betrachten.
    Irgendwann wäre es schön, cold Neuronen auf die integrierte GPU auslagern zu können. Dass Metal-Kernel in Betracht gezogen werden, finde ich ebenfalls interessant, weil ich dachte, der Performance-Vorteil komme aus dem hybriden Memory Pool. Wenn nicht, würde das wohl nur älteren AMD-Macs helfen, aber vielleicht übersehe ich etwas.

    • Bei Apple Silicon und Metal könnte die Idee sein, cold Neuronen auf CPU/Accelerate und hot Neuronen auf die GPU aufzuteilen und so beides zu nutzen.
      Wenn es keine Kopien zwischen GPU und CPU gibt und bereits Unified Memory verwendet wird, dürfte der Geschwindigkeitsgewinn gering sein; aber es wäre gut, wenn man mehr Funktionen des Chips gleichzeitig nutzen könnte. Um thermisch bedingtes Throttling zu vermeiden, wäre es wohl besser, nur die Effizienzkerne zu verwenden, und der Game Mode funktioniert vermutlich ebenfalls so.

  • In dieser Implementierung scheint man ein gewisses Wissen über das Modell selbst zu benötigen, um zu entscheiden, welche Teile im Systemspeicher und welche im GPU-Speicher liegen sollen.
    Idealerweise frage ich mich, ob sich das automatisch berechnen lässt, oder ob zukünftige Modelle Schnittstellen bereitstellen werden, mit denen solche Platzierungsalgorithmen automatisiert werden können. Wenn der Algorithmus auf jede Modellarchitektur zugeschnitten werden muss, dürfte die Wartung dieses Projekts ziemlich aufwendig werden.

    • Das scheint im Großen und Ganzen zu stimmen. Es gibt zwar ein Skript, das die „Predictor“-Gewichte mit dem ursprünglichen Modell zusammenführt, aber auf der GitHub-Startseite ist nicht klar ersichtlich, wie diese Gewichte erzeugt werden.
      Die 10-fache Beschleunigung ist wirklich beeindruckend. Wenn sie bei anderen Modellen reproduzierbar ist, könnte das Identifizieren von hot/cold Neuronen zur Inferenzoptimierung zu einem normalen Teil der Modellentwicklung werden.

  • Für Leute, die nicht selbst experimentieren wollen, ist im README ungefähr Folgendes wichtig: PowerInfer wurde auf x86-64-CPUs unter Linux (AVX2), auf x86-64-CPUs unter Linux mit NVIDIA-GPU sowie auf Apple-M-Chips unter macOS getestet.
    Allerdings sei die Mac-Optimierung noch nicht erfolgt, daher seien die aktuellen Performance-Gewinne nicht groß. Als demnächst kommende Funktionen werden Mistral-7B-Modelle und ein Metal-Backend für Sparse Inference unter macOS genannt.

    • Erwähnenswert sind auch die herunterladbaren llama2-Modelle und die Datei convert.py.

  • Hervorragend ist der Teil, dass sie anhand der Verteilung „eine kleine Zahl hot Neuronen, die über Eingaben hinweg konsistent aktiviert werden, und eine große Zahl cold Neuronen, die je nach Eingabe variieren“ eine GPU-CPU-Hybrid-Inferenz-Engine entworfen haben.
    Die Erklärung lautet, dass hot Neuronen für schnellen Zugriff vorab auf die GPU geladen werden, während cold Neuronen auf der CPU berechnet werden, wodurch der GPU-Speicherbedarf und die CPU-GPU-Datenübertragung stark reduziert werden.

  • Alle vergleichen es mit llama.cpp, weil das der einfache Weg ist. Allen sollte klar sein, dass llama.cpp langsam ist. Man sollte es mit exllamav2 oder anderen optimierten Implementierungen vergleichen.

    • In diesem Fall ist der Vergleich mit llama.cpp richtig, weil der Code buchstäblich eine Modifikation von llama.cpp ist. Es nutzt nicht nur die ggml-Matrixberechnungsbibliothek, sondern ist ein Fork, der main.cpp und den allgemeinen llama.cpp-Code unverändert verwendet, sodass ein direkter Vergleich möglich ist.
      https://github.com/ggerganov/llama.cpp/pull/4543 [Review] Merge PowerInfer with llama.cpp mainline #4543
      https://github.com/ggerganov/llama.cpp/discussions/4534#disc... Es gibt auch die Erklärung, dass „die 11-fache Beschleunigung etwas Cherry-Picking ist, weil der llama.cpp-GPU-Code für Falcon 40B nicht gut optimiert ist“.
    • exllama unterstützt keine Grammatikbeschränkungen, deshalb ist man an llama.cpp gebunden.
      Außerdem scheint es bei exllama auch Nebenwirkungen hinsichtlich der Konsistenz zu geben: https://www.reddit.com/r/LocalLLaMA/comments/17w57eu/llm_for...
    • Ist ExLlama nicht ausschließlich für GPUs? Diese Beschleunigung ist für den Anwendungsfall einer GPU+CPU-Aufteilung gedacht.
    • Ich frage mich, was empfehlenswert wäre, wenn man etwas Schnelleres sucht, das sich in eine App paketieren und ausliefern lässt.

  • Es wäre wirklich großartig, wenn man Sparse-Predictor-Dateien für beliebige Modelle erzeugen könnte. Derzeit scheint das nur für die vier Modelle zu gelten, die sie bearbeitet haben.
    Nach Seite und Code zu urteilen, ist kein Tool enthalten, das diesen Schritt ausführt. Ich werde erst einmal etwas abwarten und hoffe, dass diese Funktionen am Ende wieder als Optionen in llama.cpp zusammengeführt werden. Das nutzt nicht nur die ggml-Matrixbibliothek, sondern basiert auf dem normalen llama.cpp-Code.

  • Wenn man nur die Formulierung „Consumer-GPU“ liest, wirkt es so, als ließe sich das auf mehreren Modellen ausführen, aber wie bei solchen Artikeln üblich frage ich mich, ob es in der Praxis nur für die RTX 4090 gedacht ist.

    • Mir fällt nichts ein, was speziell auf die 4090 beschränkt wäre. In der Regel ist VRAM entscheidend: Wenn 24 GB nötig sind, geht auch eine 3090, und zwei Karten mit je 12 GB sind ebenfalls eine Option.
      Die Technik selbst ist ein allgemeiner Ansatz, um größere Modelle auf kleineren GPUs laufen zu lassen, und verbessert die CPU-Offloading-Performance erheblich. Neben dem Beispiel, bei dem das größte Modell auf einer 4090 in fp16 lief, zeigte sich auch beim gleichen Modell mit 4-Bit-Quantisierung auf einer 2080Ti eine Beschleunigung um etwa den Faktor 3 nach LLaMA-Maßstab.
      Daher dürfte auf dem Desktop das 33B-Modell zum neuen Standard werden, und die Chancen scheinen gut, dass man selbst mit nur einer einzelnen 3090 oder 4090 ein 70B-Modell in Echtzeit-Chat-Geschwindigkeit betreiben kann.