Sparse-Techniken für 100-fache Beschleunigung bei Large Language Model Inference. Entdecken Sie die Magie der Aktivierungssparsität: kein Nachtraining, niedrige Kosten und hohe Effizienz, was zu einer signifikanten Steigerung der GPU-Inferenzgeschwindigkeit führt!
In der vorherigen Diskussion über „Wie LLM die Inferenz durch Sparsität beschleunigt“ haben wir den ersten Teil untersucht: „[Wie große Modelle pruning](Unveiling-LLM-Pruner-Techniques: Doubling-Inference-Speed)“. Dieses Mal setzen wir mit dem zweiten Teil fort: „Wie man die Inferenz mithilfe von Aktivierungssparsität beschleunigt“, und in der nächsten Diskussion werden wir den dritten Teil betrachten: „Die Auswirkungen von Sparse-Compilern auf die LLM-Inferenz“.
Wir haben immer wieder gefragt, ob es eine Methode gibt, die mehrere Anforderungen gleichzeitig erfüllt: kein Nachtraining des Modells, sondern nur Feintuning (niedrige Modelltransferkosten), Beibehaltung der Modellleistung (gute Effektivität), hohe Unterstützung durch moderne Hardware (GPU/CPU) und signifikante Reduzierung der GPU-Berechnung und des I/O, um die Latenz zu optimieren (schnelle Inferenzgeschwindigkeit).
Tatsächlich existiert eine solche Methode, und die Aktivierungssparsität ist eine, die alle diese Anforderungen erfüllt.
Es ist erwähnenswert, dass die Verwendung von ReLU-Aktivierungsfunktionen in neuronalen Netzen bekanntermaßen Aktivierungssparsität induziert und in verschiedenen früheren Arbeiten übernommen wurde. Im Durchschnitt führt diese Aktivierungssparsität über alle Schichten hinweg zu erheblichen Einsparungen beim Gewichtstransfer (I/O) zwischen GPU und CPU, die etwa 95 % der Zeilen der Projektionsschichtgewichte betreffen. Diese Reduzierung schlägt sich direkt in Berechnungseinsparungen nieder, da die Ergebnisse der Matrixmultiplikationsoperationen für diese Zeilen Null sein werden.
Im Gegensatz zur unstrukturierten Sparsität (z. B. unstrukturierte Gewichtssparsität) ist diese Art von Sparsität außerdem hardwarefreundlicher, da sie umfangreichere und strukturierte Blöcke (wie Zeilen oder Spalten) auf null setzt.
In ähnlicher Weise veranschaulichen wir anhand der folgenden Abbildung kurz die Effektivität der Aktivierungssparsität bei der Beschleunigung der Inferenz.
Im Fall der Aktivierungssparsität wird während der Inferenz eine sparse Vektor-dichte Matrixmultiplikation durchgeführt, während während des Trainings auf eine sparse Matrix-dichte Matrixmultiplikation umgestellt wird.
- Reduzierter Rechenaufwand: Diese halbstrukturierte Sparsität (im Gegensatz zur unstrukturierten Sparsität des Gewichtsprunings) ermöglicht das Überspringen bestimmter Zeilen, was die Berechnung reduziert. Bibliotheken wie cusparse unterstützen bereits entsprechende Operationen.
- Reduzierter IO-Transfer: Während der Inferenz ist der GPU-I/O ein Engpass (z. B. vom GPU-Cache zum CPU-Cache oder vom GPU-DRAM zum GPU-Cache). Diese Methode ermöglicht das Überspringen unnötiger Zeilen und reduziert dadurch den I/O.
Machbarkeit der Aktivierungssparsität
Der folgende Inhalt bezieht sich hauptsächlich auf Daten aus [5], um die Machbarkeit der Implementierung von ReLU-Aktivierung in LLM zu demonstrieren.
Vergleich zwischen aktivierungssparsen und nicht-aktivierungssparsen Modellen
Durch Messung und Analyse der FFN (Feed-Forward Network) von drei Modellen – OPT 6.7B, Llama 7B (mit SiLU-Aktivierung) und Falcon 7B (mit GELU-Aktivierung) – werden die folgenden drei Schlussfolgerungen gezogen:
a. Ein Vergleich zwischen Llama 7B (mit SiLU-Aktivierung), Falcon 7B (mit GELU-Aktivierung) und OPT 6.7B (mit ReLU-Aktivierung) zeigt, dass ReLU über 90 % Aktivierungssparsität induziert, während SiLU und GELU weniger als 10 % Aktivierungssparsität induzieren. Dies demonstriert, dass ReLU sparse Aktivierungen induzieren kann.
b. Aktivierungssparsität führt zu erheblichen Einsparungen bei der Gewichtsübertragung (I/O), die etwa 95 % der Zeilen der nachgelagerten Projektionsschichtgewichte betreffen.
c. Die Wahl der Aktivierungsfunktion hat keinen signifikanten Einfluss auf die Genauigkeit, da GELU, SiLU oder ReLU auf demselben Präzisionsniveau liegen. Allerdings kann ReLU 32 % des Rechenaufwands (FLOPS) einsparen.
Reduzierung der Trainingskosten
Viele moderne LLMs (wie Llama und Falcon) wurden mit Nicht-ReLU-Aktivierungen trainiert. Ein Training von Grund auf ist nicht kosteneffizient; daher muss die Implementierung von ReLU-Aktivierung durch Feintuning in Betracht gezogen werden. Das Modell wird in den folgenden zwei Phasen feingetuned:
- In der ersten Phase werden vorhandene ReLU-Aktivierungen (im Fall von OPT) beibehalten oder die Aktivierungsfunktion zwischen den Up-Projektions- und Down-Projektionsschichten wird durch ReLU ersetzt (im Fall von Falcon und Llama, wo GELU und SiLU verwendet werden).
- In der zweiten Phase werden neue ReLU-Aktivierungen nach den Normalisierungsschichten eingefügt.
Phase Eins – Ersetzung von Nicht-ReLU-Aktivierungen
Ersetzen Sie Nicht-ReLU-Aktivierungen durch ReLU in den FFN-Schichten. Für Falcon- und Llama-Modelle bedeutet dies den Austausch von GELU bzw. SiLU. Es wird angemerkt, dass das OPT-Modell bereits ReLU-Aktivierungen verwendet, sodass keine Änderungen vorgenommen werden. Nach dem Feintuning mit 30B Tokens von RefinedWeb zeigt das Modell signifikante Sparsität in den Aktivierungen.
Phase Zwei – Einfügen neuer ReLU
In der vorherigen Phase haben wir Nicht-ReLU-Aktivierungen ersetzt, um mehr Sparsität zu erreichen. Dies führte zu sparsen Eingaben in die Down-Projektionsschicht, die etwa 30 % der Gesamtberechnungskosten ausmacht. Neben der Down-Projektion gibt es jedoch andere Matrix-Vektor-Multiplikationen in den Decode-Schichten des Transformers, wie die Up-Projektion in der FFN-Schicht und die QKV-Projektion in der Attention-Schicht. Insgesamt verbrauchen diese Matrix-Vektor-Multiplikationen etwa 55 % der Gesamtberechnungskosten.
In modernen Transformer-Schichten stammen die Eingaben in Attention- und FFN-Schichten beide aus Normalisierungsschichten wie LayerNorm oder RMSNorm. Diese Schichten können als eine spezifische Form eines MLP betrachtet werden, bei der keine beliebigen lernbaren Parameter angewendet werden, sondern die Eingabe skaliert wird. Daher wenden wir ReLU an, um nach den Normalisierungsschichten sparse Aktivierungen zu erhalten, und erreichen so das Ziel der zweiten Phase.
Messergebnisse
Kosten des Feintunings: Das Feintuning wurde mit 30B bzw. 50B Tokens in Phase eins und zwei abgeschlossen. Im Vergleich zu den Trainingskosten von 1T Tokens für Llama betrugen die Kosten nur etwa 3–5 %.
Effektivität: Beim Vergleich der Inferenzlatenz nach dem Feintuning für Llama und Falcon gab es keine erkennbare Verschlechterung der Modellleistung. Allerdings gab es eine signifikante Verbesserung der Inferenzgeschwindigkeit von über 30 %.
Insgesamt bestätigen die Ergebnisse, dass die Erzielung von Aktivierungssparsität durch Feintuning die Inferenz-FLOPS in verschiedenen Stufen und Raten reduzieren kann, während die Leistung bei verschiedenen Aufgaben vergleichbar bleibt. Die entsprechenden sparsen Aktivierungsmodelle finden Sie im Projekt: https://huggingface.co/SparseLLM.
Wie man die Inferenz beschleunigt
DejaVus Kontextsparsitätsvorhersage, wie im referenzierten Papier [1] beschrieben, ist ein hervorragender Ansatz.
Wie man strukturierte Sparsität voll ausnutzt, um zu beschleunigen
Kontextsparsität geht davon aus, dass vortrainierte Modelle Kontextsparsität aufweisen, was bedeutet, dass Sparsifikationsberechnungen für Attention und MLP den gleichen Effekt erzielen wie vollständige Berechnungen. Unter dieser Annahme kann eine durchschnittliche Kontextsparsität von 85 % in strukturierten sparsen Modellen zu einer siebenfachen Reduzierung der Parameter für jede spezifische Eingabe führen, während die Genauigkeit erhalten bleibt, was die Inferenzleistung erheblich verbessert.
Wie in der obigen Abbildung gezeigt, wird ein asynchroner Sparsität-Vorhersager basierend auf Kontextsparsität entwickelt, der die Sparsität der nächsten Schicht von Attention und MLP im Voraus vorhersagt. Dieser Ansatz gewährleistet nicht nur die Inferenzeffizienz, sondern reduziert auch erheblich den Rechen- und I/O-Aufwand.
Validierung der Existenz von Kontextsparsität
Tests wurden an den Modellen OPT-175B, 66B und 30B mit verschiedenen nachgelagerten Datensätzen wie OpenBookQA und Wiki-Text durchgeführt. Die Methode bestand aus zwei Vorwärtsdurchläufen des Modells, um die Kontextsparsität für jedes Eingabebeispiel zu identifizieren. Im ersten Durchlauf wurde eine Teilmenge von Parametern aufgezeichnet, insbesondere solche, die mit Attention-Heads und MLP-Neuronen verbunden sind, die große Ausgabenormen für Eingaben erzeugen. Im zweiten Durchlauf wurde jedes Eingabebeispiel nur mit der aufgezeichneten Parameterteilmenge berechnet. Überraschenderweise lieferten beide Vorwärtsdurchläufe ähnliche Vorhersagen oder Leistungen in allen Kontextlern- und Sprachmodellierungsaufgaben.
Beobachtungsergebnisse: Im Durchschnitt können Attention-Heads eine Sparsität von bis zu 80 % auferlegen, während MLP-Neuronen eine Sparsität von bis zu 95 % erreichen können, was zu einer Gesamtsparsität von etwa 85 % führt, was eine siebenfache Beschleunigung ermöglichen kann. Spezifische Referenzdaten finden Sie in der folgenden Abbildung.
Technische Auswirkungen
Beschleunigungseffekt: Da GPUs blockorientierte Geräte sind, ist die Zeit zum Laden eines einzelnen Bytes Speicher identisch mit dem Laden des Speicherblocks um dieselbe Adresse. Die Blockgröße von NVIDIA GPUs beträgt typischerweise 128 Bytes. Daher wurden Optimierungen wie Memory Fusion und Operator Fusion durchgeführt. Unter der Annahme von batch_size=1 wurde im Vergleich zu FasterTransformer eine Verdopplung der Geschwindigkeit erreicht – eine 2-fache Verbesserung.
Durchsatzauswirkung: Da Aktivierungen eine Funktion jedes Tokens sind, ist die effektive Sparsität auch zufällig über die Tokens verteilt. Daher nimmt die Wirksamkeit der Sparse-Optimierung exponentiell mit zunehmender Batch-Größe ab. Dies kann in den Ablationsexperimenten des Papiers nachgelesen werden.
Reduzierung der Inferenzschwelle
Eine Übersicht der aktuellen teilweisen Auslagerungsmethoden und der DejaVu-Methode finden Sie in der folgenden Tabelle:
Können Aktivierungssparsität und Auslagerungsmethoden kombiniert werden, um eine hybride GPU-CPU-Inferenz-Engine zu entwerfen: Heiß aktivierte Neuronen werden zur schnellen Nutzung auf die GPU vorgeladen, während kalt aktivierte Neuronen auf der CPU berechnet werden, was den GPU-Speicherbedarf und den CPU-GPU-Datentransfer erheblich reduziert?
Die Antwort ist natürlich „JA“.
Eine solche Lösung ist PowerInfer[10], das OPT-175B auf einer einzigen NVIDIA RTX 4090 GPU ausführen kann und dabei Token-Generierungsgeschwindigkeiten erreicht, die nur 18 % niedriger sind als die von High-End-A100 GPU-Servern. Neben Auslagerung und Aktivierungssparsität sind auch andere Aspekte wie Brainstorm[9], SparTA[15] und Flash-llm[16] von Referenzwert.
Überblick:
PowerInfer lädt Gewichte für häufig aktivierte Neuronen vorab auf die GPU, während Gewichte für weniger aktive Neuronen auf der CPU verbleiben.
Um die Inferenzlatenz zu reduzieren, berechnet die Inferenz-Engine nur Neuronen, die vom Online-Prädiktor als aktiv vorhergesagt werden, und überspringt die meisten inaktiven Neuronen. Darüber hinaus ermöglicht die Vorladestrategie PowerInfer, einen erheblichen Teil der Inferenzaufgaben der GPU zuzuweisen, da die auf die GPU geladenen heiß aktivierten Neuronen die Mehrheit der Aktivierungen ausmachen. Für kalt aktivierte Neuronen, die sich nicht im GPU-Speicher befinden, führt PowerInfer Berechnungen auf der CPU durch, sodass keine Gewichte auf die GPU übertragen werden müssen.
Die Architekturübersicht und der Inferenz-Workflow von PowerInfer
PowerInfer besteht aus Offline- und Online-Komponenten. Aufgrund von Unterschieden in den Lokalitätseigenschaften verschiedener LLMs analysiert die Offline-Komponente die Aktivierungssparsität des LLM und unterscheidet zwischen heißen und kalten Neuronen. In der Online-Phase lädt die Inferenz-Engine beide Neuronentypen in die GPU und CPU und bedient LLM-Anfragen zur Laufzeit mit geringer Latenz. Vor der Verarbeitung von Benutzeranfragen weist die Online-Engine die beiden Neuronentypen basierend auf der Ausgabe des Offline-Lösers ihren jeweiligen Verarbeitungseinheiten zu. Zur Laufzeit erstellt die Engine GPU- und CPU-Executors, bei denen es sich um Threads handelt, die auf der CPU-Seite ausgeführt werden, um die gleichzeitige CPU-GPU-Berechnung zu verwalten. Die Engine sagt auch Neuronaktivierungen voraus und überspringt inaktive Neuronen. Aktivierte Neuronen werden zur Verarbeitung in den GPU-Speicher vorgeladen, während die CPU Ergebnisse für ihre Neuronen berechnet und zur Integration an die GPU überträgt. Die Engine verwendet sparse neuron-aware Operatoren sowohl auf CPU als auch auf GPU und konzentriert sich auf einzelne Neuron-Zeilen/Spalten in Matrizen.
Projekt-Link: https://github.com/SJTU-IPADS/PowerInfer
Berechnungsoptimierung auf Einzelschichtebene
Ein veranschaulichendes Beispiel zeigt, wie PowerInfer verschiedene Neuronen für eine LLM-Schicht berechnet
PowerInfer koordiniert GPU und CPU, um Neuronen in einer Schicht zu verarbeiten, indem es Neuronen basierend auf Offline-Daten klassifiziert, heiße Neuronen (z. B. Index 3, 5, 7) dem GPU-Speicher zuweist und andere Neuronen dem CPU-Speicher zuweist.
Nach Erhalt der Eingabe identifiziert der Prädiktor, welche Neuronen in der aktuellen Schicht wahrscheinlich aktiviert werden. Beispielsweise sagt er die Aktivierung der Neuronen 3, 4 und 5 voraus. Es ist erwähnenswert, dass heiße Neuronen, die durch Offline-Statistiken identifiziert wurden, möglicherweise nicht immer mit dem Aktivierungsverhalten zur Laufzeit übereinstimmen. Beispielsweise könnte Neuron 7, obwohl es als heiß markiert ist, in einem bestimmten Szenario inaktiv sein.
Anschließend verarbeiten sowohl CPU als auch GPU die vorhergesagten aktiven Neuronen, während inaktive ignoriert werden. Die GPU berechnet die Neuronen 3 und 5, während die CPU Neuron 4 verarbeitet. Sobald die Berechnung für Neuron 4 abgeschlossen ist, wird dessen Ausgabe zur Ergebnisintegration an die GPU gesendet.
Online-Inferenz (Neuron-aware Inference Engine)
- Adaptiver Spars-Vorhersager
Die Online-Inferenz-Engine in PowerInfer reduziert die Rechenlast, indem sie nur Neuronen verarbeitet, von denen vorhergesagt wird, dass sie aktiviert sind. Dieser Ansatz wird auch in DejaVu verwendet, der das Training eines Satzes von MLP-Prädiktoren fester Größe befürwortet. In jeder Transformer-Schicht verwendet DejaVu zwei unabhängige Prädiktoren, um die Aktivierung von Neuronen in Self-Attention- und MLP-Blöcken vorherzusagen.
Die Entwicklung effektiver Prädiktoren für die lokale Bereitstellung mit begrenzten Ressourcen ist jedoch eine Herausforderung, da ein Gleichgewicht zwischen Vorhersagegenauigkeit und Modellgröße erforderlich ist.
PowerInfer verwendet eine iterative Trainingsmethode für Prädiktoren nicht fester Größe für jede Transformer-Schicht. Dieser Prozess legt zunächst eine Basis-Modellgröße basierend auf dem Sparsitätsprofil der Schicht fest. Anschließend wird unter Berücksichtigung der internen Aktivierungsschiefe die Modellgröße iterativ angepasst, um die Genauigkeit beizubehalten. MLP-Prädiktoren bestehen typischerweise aus einer Eingabe-, einer versteckten und einer Ausgabeschicht. Da die Größen der Eingabe- und Ausgabeschichten durch die Struktur der Transformer-Schicht bestimmt werden, zielen die Änderungen hauptsächlich auf die versteckte Schicht ab. Während des iterativen Anpassungsprozesses wird die Größe der versteckten Schicht basierend auf der beobachteten Schiefe modifiziert. Bei Schichten mit signifikanter Schiefe verringert sich die Größe der versteckten Schicht allmählich, bis die Genauigkeit unter 95 % fällt. Umgekehrt werden bei Schichten mit minimaler Schiefe die Dimensionen erhöht, um die Genauigkeit zu verbessern. Durch diesen Ansatz begrenzt PowerInfer die Prädiktorparameter effektiv auf 10 % der gesamten LLM-Parameter.
- GPU-CPU Hybridausführung
Vor der Inferenz erstellt PowerInfer einen berechnungsbezogenen gerichteten azyklischen Graphen (DAG), in dem jeder Knoten einen Berechnungs-LLM-Inferenzoperator darstellt, und speichert ihn in einer globalen Warteschlange im CPU-Speicher. Jeder Operator in der Warteschlange ist mit seinen erforderlichen Operatoren gekennzeichnet. Während der Inferenz verwalten zwei Arten von Executors (erstellt durch den pthread des Host-Betriebssystems) die Berechnungen auf CPU und GPU. Sie extrahieren Operatoren aus der globalen Warteschlange, überprüfen Abhängigkeiten und weisen sie den entsprechenden Verarbeitungseinheiten zu. GPU und CPU verwenden ihre neuron-aware Operatoren, wobei der GPU-Executor GPU-Operatoren mithilfe von APIs wie cudaLaunchKernel startet, während der CPU-Executor ungenutzte CPU-Kerne für die Berechnung koordiniert.
Experimentelle Schlussfolgerung
Leistungsvergleich
Beschleunigung verschiedener Modelle auf dem FP16-Format PC-High. Die X-Achse repräsentiert die Ausgabelänge, die Y-Achse die Beschleunigungsrate im Vergleich zu llama.cpp. Die Zahl über jedem Balken gibt die End-to-End-Generierungsgeschwindigkeit (Tokens/s) an. Die für die erste Zeile im Diagramm konfigurierte Eingabelänge beträgt etwa 64, für die zweite Zeile etwa 128.
Auf einem PC-High mit NVIDIA RTX 4090 zeigen verschiedene Modelle und Eingabe-Ausgabe-Konfigurationen unterschiedliche Generierungsgeschwindigkeiten. Im Durchschnitt erreicht PowerInfer eine Generierungsgeschwindigkeit von 8,32 Tokens/s, mit einem Spitzenwert von 16,0 Tokens/s, was deutlich besser ist als llama.cpp, mit einer durchschnittlichen Beschleunigung um das 7,23-fache, während Falcon-40B bis zu 11,69-fach erreicht. Mit zunehmender Anzahl der Ausgabetokens wird der Leistungsvorteil von PowerInfer deutlicher, da die Generierungsphase eine wichtigere Rolle in der gesamten Inferenzzeit spielt. In dieser Phase werden auf sowohl CPU als auch GPU nur wenige Neuronen aktiviert, was unnötige Berechnungen im Vergleich zu llama.cpp reduziert. Beispielsweise werden bei OPT-30B nur etwa 20 % der Neuronen pro generiertem Token aktiviert, wobei die Mehrheit auf der GPU verarbeitet wird, was den Vorteil der neuron-aware Inferenz-Engine von PowerInfer zeigt.
Auswirkung der Batch-Größe:
Wenn die Batch-Größe kleiner als 32 ist, zeigt PowerInfer einen signifikanten Vorteil mit einer durchschnittlichen Verbesserung um das 6,08-fache im Vergleich zu llama.cpp. Mit zunehmender Batch-Größe nimmt die von PowerInfer bereitgestellte Beschleunigungsrate ab. Diese Reduzierung ist auf die verringerte Sparsität der gemeinsamen Aktivierungen im Modell zurückzuführen. Selbst bei einer Batch-Größe von 32 bleibt PowerInfer jedoch eine beträchtliche Beschleunigungsrate erhalten und erreicht eine 4,38-fache Verbesserung.
Batch-Inferenzbeschleunigung von Falcon-40B auf PC-High. Die X-Achse zeigt die Anfrage-Batch-Größe, die Y-Achse die End-to-End-Token-Generierungsgeschwindigkeit (Tokens/s). Die Zahl über jedem Balken zeigt die Beschleunigung im Vergleich zu
Lastvergleich
Verteilung der Neuronlast auf CPU und GPU während der Inferenz. Der gelbe Block bezieht sich auf llama.cpp, der blaue Block auf PowerInfer
Die Verteilung der Neuronlast zwischen CPU und GPU in PowerInfer und llama.cpp wird verglichen. Neuronlast bezieht sich auf den Anteil der Aktiviert-Neuron-Berechnungen, die von jeder Verarbeitungseinheit durchgeführt werden. Es ist erwähnenswert, dass PowerInfer auf einem PC-High-System den Anteil der Neuronlast auf der GPU signifikant erhöht, von durchschnittlich 20 % auf 70 %. Dies zeigt, dass die GPU 70 % der aktivierten Neuronen verarbeitet. Wenn der Speicherbedarf des Modells jedoch die GPU-Kapazität bei weitem übersteigt, wie z. B. beim Ausführen eines 60-GB-Modells auf einer 11-GB-2080Ti GPU, sinkt die Neuronlast auf der GPU auf 42 %. Dieser Rückgang ist auf den begrenzten Speicher der GPU zurückzuführen, der nicht ausreicht, um alle heiß aktivierten Neuronen aufzunehmen, sodass ein Teil dieser Neuronen auf der CPU berechnet werden muss.
In Szenarien mit längeren Eingabe-Prompts und relativ kürzeren Ausgabelängen zeigt PowerInfer nur begrenzte Leistungsverbesserungen. In solchen Fällen wird die Phase der gleichzeitigen Verarbeitung einer großen Anzahl von Tokens zu einem Schlüsselfaktor für die Bestimmung der Inferenzgeschwindigkeit. Dies führt dazu, dass jedes Token einen einzigartigen Satz von Neuronen aktiviert, was die Aktivierungssparsität erheblich reduziert. Infolgedessen wird die CPU zum primären Engpass im Inferenzprozess, da sie eine große Anzahl kalt aktivierter Neuronen verarbeiten muss, aber durch die Rechenkapazität eingeschränkt ist.
Fazit
Die Aktivierungssparsitätstechnologie hat revolutionäre Durchbrüche für große Sprachmodelle gebracht. Durch die Sparsifizierung der Aktivierungen neuronaler Netze zur Beschleunigung des Inferenzprozesses bei gleichzeitiger Reduzierung der GPU-Berechnung und I/O-Last werden Inferenzgeschwindigkeit und Leistung verbessert. Dieser Ansatz erfordert kein Nachtraining und erreicht Aktivierungssparsität nur durch Feintuning, was die Kosten erheblich senkt und gleichzeitig die Modellleistung erhält. Die Anwendungsperspektiven der Aktivierungssparsitätstechnologie sind aufregend und bringen mehr Möglichkeiten in den Bereich des Deep Learning. Wir freuen uns auf die weitere Entwicklung und breite Anwendung dieser Technologie.
Referenzpapiere
[5]ReLU Strikes Back: Exploiting Activation Sparsity in Large Language Models
[7]Inducing and Exploiting Activation Sparsity for Fast Inference on Deep Neural Networks
[8]Sparse is Enough in Scaling Transformers
novita.ai bietet Stable Diffusion API und Hunderte von schnellen und günstigsten KI-Bildgenerierungs-APIs für 10.000 Modelle. 🎯 Schnellste Generierung in nur 2 Sekunden, Pay-As-You-Go, mindestens 0,0015 $ pro Standardbild, Sie können Ihre eigenen Modelle hinzufügen und GPU-Wartung vermeiden. Kostenlose Weitergabe von Open-Source-Erweiterungen.
Empfohlene Lektüre
