„LLM in a Flash“ ermöglicht effiziente LLM-Inferenz mit begrenztem Speicher

 (huggingface.co)
1 Punkte von GN⁺ 2023-12-22 | 1 Kommentare | Auf WhatsApp teilen
  • LLM in a Flash legt die Parameter eines LLM, das größer als der DRAM ist, im Flash-Speicher ab und lädt nur die benötigten Teile in den DRAM, sodass Inferenz auch auf Geräten mit begrenztem Speicher möglich wird
  • Auf Basis eines Inferenz-Kostenmodells, das die Zugriffseigenschaften von Flash-Speicher berücksichtigt, wird die Menge der übertragenen Daten reduziert und das Lesen größerer, zusammenhängender Chunks gefördert
  • Windowing nutzt zuvor aktivierte Neuronen wieder, während Row-Column Bundling die Stärke von Flash bei sequenziellem Zugriff nutzt und so Engpässe reduziert
  • Durch die Kombination beider Techniken lassen sich Modelle ausführen, die bis zu 2-mal so groß wie der verfügbare DRAM sind; gegenüber einfachem Laden zeigt sich eine 4- bis 5-mal schnellere Inferenz auf CPUs und eine 20- bis 25-mal schnellere Inferenz auf GPUs
  • Durch die Kombination von Sparsity-Awareness, kontextadaptivem Laden und hardwareorientiertem Design wächst die Machbarkeit von LLM-Ausführung auf speicherbeschränkten Geräten

LLM-Inferenz auf Basis von Flash-Speicher

  • Große Sprachmodelle erzielen bei verschiedensten Aufgaben der Verarbeitung natürlicher Sprache hohe Leistung, sind wegen ihres hohen Rechen- und Speicherbedarfs jedoch auf Geräten mit begrenzter DRAM-Kapazität schwer auszuführen
  • LLM in a Flash begegnet dieser Einschränkung, indem Modellparameter im Flash-Speicher abgelegt und während der Inferenz nur die benötigten Daten on demand in den DRAM geladen werden
  • Im Zentrum des Ansatzes steht ein Inferenz-Kostenmodell, das auf das Verhalten von Flash-Speicher abgestimmt ist
    • Es optimiert darauf, die aus dem Flash übertragenen Datenmengen zu reduzieren
    • Es ist darauf ausgelegt, Daten in größeren, zusammenhängenden Chunks zu lesen

Zwei Techniken zur Reduktion von Übertragungsmenge und Lesemustern

  • Windowing nutzt zuvor aktivierte Neuronen wieder und reduziert dadurch die Datenmenge, die vom Flash in den DRAM verschoben werden muss
  • Row-Column Bundling vergrößert die aus dem Flash gelesenen Daten-Chunks passend zur Eigenschaft von Flash-Speicher, bei sequenziellem Datenzugriff stark zu sein
  • Zusammen eingesetzt können beide Techniken Modelle ausführen, die bis zu 2-mal größer sind als der verfügbare DRAM
  • Die Verbesserung der Inferenzgeschwindigkeit gegenüber einfachem Laden fällt je nach Hardware unterschiedlich aus
    • Auf CPUs wird sie 4- bis 5-mal schneller
    • Auf GPUs wird sie 20- bis 25-mal schneller
  • Dieses Design integriert Sparsity-Awareness, kontextadaptives Laden und hardwareorientiertes Design, um LLM-Inferenz in Umgebungen mit begrenztem Speicher zu ermöglichen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-12-22
Hacker-News-Kommentare

  • Das Paper baut auf den Sparsity-Nutzungstechniken des bereits ziemlich komplexen Deja-Vu-Papers auf, daher hat es etwas gedauert, es zu verstehen
    Deja Vu geht davon aus, dass selbst Modelle mit geringer Gewichtssparsity eine hohe „kontextuelle Sparsity“ haben. Das heißt, im Ergebnisvektor der Matrixmultiplikation entstehen viele Nullen, aber an welchen Positionen Nullen auftreten, hängt von der Eingabe ab
    Diese Sparsity kann genutzt werden, um das Laden einiger Matrixzeilen zu überspringen. Um dabei Leistungsgewinne zu erzielen, muss man vorhersagen, welche Zeilen übersprungen werden können, und diese Vorhersage ist mit einer niedrig-rangigen Matrix möglich
    Das Apple-Paper schlägt vor, dass diese Erkenntnis nicht nur für die RAM-Ladeleistung hilfreich ist, sondern auch für das Laden aus Flash-Speicher, ohne die Bandbreite stark zu beeinträchtigen
    Die Attention-Matrix ist relativ leichtgewichtig, und das Ziel für sparsames Laden ist das FFN. Wenn man außerdem nicht den FFN-Eingang, sondern die Ausgabe der ReLU-Schicht vorhersagt, erhält man deutlich bessere Sparsity. Wenn man vorhersagen kann: „Dieser Vektorslot wird nach der Matrixmultiplikation und vor ReLU negativ sein“, kann man die entsprechende Matrixspalte nicht laden und einfach 0 ausgeben
    Die meisten Zeilen des FFN müssen überhaupt nicht geladen werden, und vorgeschlagen wird, für jedes FFN einen Cache der zuletzt verwendeten Zeilen zu halten und ihn bei Bedarf aus dem Flash-Speicher zu aktualisieren. Es gibt noch mehr zu Chunk-Laden und Korrelationen zwischen Projektionsschichten, aber das scheint die zentrale Einsicht zu sein
    FFN steht für Feed Forward Network und ist in Transformern einer der größten Blöcke

  • Ich frage mich, wie viel vom Modell nicht geladen werden muss, bevor sich ein realer Leistungsunterschied zeigt
    Zum Beispiel würde ich gern wissen, ob man bei halbem Speicherbedarf noch 90 % der Leistung erreicht, wenn das gesamte Modell im RAM 100 % liefert, oder ob dafür 90 % oder 95 % des Speichers nötig sind
    Letztlich geht es darum, wie schnell man im Vergleich zur Maximalleistung Performance verliert, wenn man RAM reduziert. Die Grafiken vergleichen diesen Algorithmus mit dem Basisalgorithmus bei wenig RAM; das ist etwas anderes, aber trotzdem eine gute Frage
    Wenn ein 8-GB-Modell gute Leistung liefern kann, ohne vollständig in den Telefonspeicher geladen zu werden, ist das offensichtlich nützlich

    • Apple hat ein Modell ausgeführt, das doppelt so groß wie der verfügbare Speicher war. Ob das der gefundene Sweet Spot ist oder ob mit längerer Antwortzeit noch größere Modelle möglich wären, weiß ich nicht
      Das gesamte Paper ist lesenswert und ziemlich interessant: https://arxiv.org/pdf/2312.11514
      Im Paper werden zwei komplementäre Techniken hervorgehoben, um den Datentransfer zu minimieren und den Durchsatz des Flash-Speichers zu maximieren
      Windowing reduziert die Zahl der I/O-Anfragen zum Laden von Gewichten, indem Aktivierungen der zuletzt berechneten Token wiederverwendet werden und nur die für die letzten paar Token benötigten Parameter geladen werden
      Row-column bundling speichert Zeilen und Spalten der Up-Projection- und Down-Projection-Schichten zusammenhängend, sodass größere zusammenhängende Chunks aus dem Flash-Speicher gelesen werden können, was den Durchsatz erhöht
    • Das ist eher ein Versuch, meine Gedanken zu ordnen, keine autoritative Erklärung
      Theoretisch sollte die Inferenzzeit für ein einzelnes Token, wenn sich ein Teil des Modells im Flash-Speicher befindet, gleich der Inferenzzeit bei vollständig im RAM befindlichem Modell plus der Zeit zum Laden des im Flash-Speicher liegenden Modellteils sein
      Ich nehme an, dass kein Zurückschreiben auf den Flash-Speicher nötig ist, aber ich bin kein LLM-Experte und kann mich irren
      Wenn es deutlich mehr als 10 Schichten gibt, könnte man wahrscheinlich nur einen kleinen Teil des RAM frei halten und dann Schicht für Schicht laden. Die meisten LLMs haben Dutzende von Schichten, also klingt das plausibel
      Wenn RAM während der Inferenz nicht der Flaschenhals ist, könnte man vielleicht den DMA-Transfer der nächsten Schicht vom Flash-Speicher in den RAM durchführen, während die aktuelle Schicht inferiert wird. In einem Single-Prozessor-System dürfte das wegen des RAM-Flaschenhalses wohl nicht gut funktionieren
      In einem Dual-Prozessor-System könnte vielleicht ein Prozessor die nächste Schicht in den RAM laden, während der andere die vorherige Schicht inferiert, sodass sich auch mit wenig RAM sehr große LLMs ausführen ließen
      Ich sitze gerade neben einem Stapel Komponenten für den Zusammenbau einer neuen LLM-AI-Maschine. Ein z840 mit Dual-Prozessor, daher freue ich mich darauf, so etwas selbst auszuprobieren

  • Bei Apple-Geräten fällt auf, dass sie im Vergleich zu ähnlichen Geräten der Konkurrenz sehr wenig RAM haben.
    Zum Teil liegt das daran, dass Apples Software-Teams effizientere Sprachen wie Objective-C verwenden, und zum Teil daran, dass iOS-Apps nicht auf eine riesige Vielfalt an Bildschirmauflösungen abzielen müssen. Deshalb müssen hochauflösende Texturen nach dem Laden vergleichsweise selten herunterskaliert werden.
    Außerdem wird RAM selbst bei Einkäufen in Apples Größenordnung nicht wesentlich billiger, sodass eine RAM-Erweiterung die Marge stärker belastet als das Hinzufügen anderer Funktionen.
    Aber LLMs sind von Natur aus sehr speicherhungrig, daher fallen all diese Entscheidungen nun auf Apple zurück. Egal welche Techniken zum Speichersparen eingesetzt werden, Konkurrenten mit mehr RAM können größere, bessere und intelligentere Modelle integrieren.

    • Hinzu kommt, dass sich bei den meisten Desktop-Macs heute der RAM nicht aufrüsten lässt.
      Ich möchte bald einen Mac kaufen und überlege ernsthaft, wie viel RAM ich bestellen soll. Mit begrenztem Budget ist das noch schwieriger. Ohne diese Einschränkung würde ich wohl mindestens 32GB nehmen.
      Ich hoffe zwar immer noch, dass Apple seine RAM-Preispolitik ändert, aber das ist wahrscheinlich vergeblich.
    • Noch zwei Anmerkungen dazu, wie „wenig RAM“ möglich ist: Apple-Geräte unterstützen Speicherkompression: https://www.lifewire.com/understanding-compressed-memory-os-...
      Man kann sich auch die zugehörige Implementierung ansehen: https://opensource.apple.com/source/xnu/xnu-2050.18.24/libke...
      Außerdem unterstützen Apple-Geräte eine Funktion namens „jetsam“, die ungenutzte oder im Hintergrund befindliche Apps beendet, um Speicher freizumachen, damit Apps mit hoher Priorität flüssig weiterlaufen können: https://developer.apple.com/documentation/xcode/identifying-...
    • Der einzige Grund, warum ich noch bei Macs bin, ist Gewohnheit und dass das MacBook Air leise ist.
      Falls jemand Empfehlungen für leise oder nahezu lautlose Linux-Laptops hat, bin ich offen dafür. Bei den meisten drehen die Lüfter stark auf, und ich wäre durchaus bereit, für mehr Ruhe etwas CPU-Leistung aufzugeben. Es wäre auch gut, wenn man einen leisen Modus leicht ein- und ausschalten könnte.
      Bisher habe ich nichts gesehen, das an die Lautlosigkeit des MacBook Air herankommt, und ich würde mich freuen, wenn mich ein Produkt vom Gegenteil überzeugt.
      Natürlich wäre es auch schön, wenn es günstiger wäre oder austauschbaren RAM hätte. Ich nutze das MacBook Air hauptsächlich für webbasierte Dienste und als Remote-Terminal zu Linux-Servern, die ich für große Projekt-Builds sowie Home-/Self-Hosting verwende.
    • Ich weiß nicht, ob diese Interpretation stimmt. Es wirkt, als würde Apple langfristig darauf wetten, dass Flash-Speicher mit der passenden CPU-/GPU-Architektur RAM gleichwertig werden kann.
      Der Zeitplan wurde zwar offensichtlich vorgezogen, aber ich halte ihre Hypothese nicht unbedingt für falsch.

  • Ich verstehe dieses Thema nur eingeschränkt, aber ich frage mich, ob man mit diesem Ansatz Offline-LLMs auf einem Smartphone ausführen kann.
    Falls ja, würden sich viele interessante Anwendungen eröffnen, etwa KI-gestützte Moderation von Inhalten, ohne vertrauliche Daten an einen Server schicken zu müssen.

    • Ja, das könnte in diesem Bereich einiges verbessern. Auch ohne diese Technik können LLMs bereits auf Smartphones laufen; die Frage ist, wie groß das Modell sein kann, wie stark man quantisieren muss und ob die wenigen verbleibenden Modelle noch gute Ergebnisse liefern.
      Gestern wurde hier zum Beispiel eine GitHub Discussion zum Ausführen von LLMs auf Apple-A-Series-Chips (iPhone) gepostet: https://news.ycombinator.com/item?id=38703161
    • Ja. Das eigentliche Ziel ist, größere Modelle auf dem Smartphone auszuführen, weil der DRAM dort sehr begrenzt ist.
    • Ich bin nicht sicher, aber ich glaube, das ist eines der Verkaufsargumente des neuen Pixel.

  • Mir gefällt, dass in neueren Artikeln von LLMs und nicht von „AI“ die Rede ist. So ist klar, dass es um eine konkrete Technologie geht und nicht um Marketing-Übertreibung.

    • Das hier ist Hugging Face. Bei dieser Leserschaft wäre es eher sehr seltsam gewesen, nicht konkret zu werden.

  • Ich frage mich, wie sich das von FlashAttention unterscheidet. Wenn man ähnliche Begriffe verwendet und den Unterschied nicht schon im Abstract erklärt, ist das verwirrend.
    Korrektur: Es scheint zwei verschiedene Mechanismen innerhalb des Flash-Frameworks zu erweitern. Der Titel des Papers hätte besser sein können, aber auf den ersten Seiten wird es erklärt.

  • Ich hatte im Fazit einen Abschnitt erwartet wie „wie diese Funktion den Nutzern zugänglich gemacht wird“, aber das liegt vielleicht außerhalb des Rahmens des Papers.
    Ich frage mich, ob so eine Funktion als API-Aufruf oder Einstellung in CoreML auftaucht, sodass man zum Beispiel ein use_flash-Flag angeben muss, oder ob es eine für den Nutzer unsichtbare Runtime-Optimierung wird.
    Ich frage mich auch, ob jemand gute Präsentationen oder Talks kennt, in denen Apple die Entwicklungs-Roadmaps von CoreML, Metal usw. erklärt.

  • Hat Apple eine iranische Firma übernommen?

    • Das Team scheint größtenteils von XNOR.ai zu kommen, das Apple 2020 übernommen hat[0]. Das Unternehmen hatte seinen Sitz in Seattle, und die Gründer scheinen iranischer Herkunft zu sein.
      [0]: https://www.geekwire.com/2020/exclusive-apple-acquires-xnor-...
    • Das habe ich auch gedacht. Die meisten kommen offenbar von der Sharif, die so etwas wie das Stanford des Iran ist.

  • Ich weiß, dass der Ansatz anders ist, aber da beide Flash-Speicher nutzen, hätte ich erwartet, dass dieses Paper FlashAttention [1] zumindest erwähnt.
    [1] https://arxiv.org/abs/2205.14135

    • Soweit ich weiß, hat FlashAttention überhaupt nichts mit Flash-Speicher zu tun.
      Meinem Verständnis nach geht es bei FlashAttention um Zugriffsmuster, die lokalen Speicher, insbesondere SRAM, besser ausnutzen. Zum Beispiel, indem Daten im CPU-L1-Cache oder im entsprechenden Level einer GPU gehalten werden.
      Anders gesagt: FlashAttention befasst sich mit dem Teil, der schneller als DRAM ist, während dieses Paper das Problem behandelt, besser auf den Teil auszulagern, der langsamer als DRAM ist.

  • Bei „Das OPT-6.7B-Modell zeigt zum Beispiel eine auffällige Sparsity von 97 % innerhalb der FFN-Schichten“: Weiß jemand, was diese Kennzahl genau bedeutet?
    Ich frage mich, ob das heißt, dass 97 % der Layer-Werte 0 sind, oder ob es bedeutet, dass man auf 3 % der Größe komprimieren kann.

    • Es bedeutet, dass 97 % der Ausgaben dieser Schicht 0 sind und zu einem gegebenen Zeitpunkt nur 3 % aktiviert werden.
      Allerdings sind diese aktiven 3 % nicht fest, daher kann man die übrigen 97 % nicht vollständig eliminieren. Das Paper scheint zu sagen, dass man die aktiven 3 % ziemlich genau vorhersagen kann, um es schneller zu machen, ohne dabei zu viel Genauigkeit zu verlieren.