Eine rationale Sicht auf dezentrale Rechenleistungsnetzwerke

TL;DR

• Derzeit gibt es zwei Hauptrichtungen für die Kombination von KI + Krypto: verteilte Rechenleistung und ZKML; für ZKML siehe bitte meinen vorherigen Artikel. In diesem Artikel wird das dezentrale verteilte Rechenleistungsnetzwerk analysiert und reflektiert.
• Im Rahmen des Entwicklungstrends von KI-Großmodellen werden Rechenleistungsressourcen im nächsten Jahrzehnt das große Schlachtfeld und auch das Wichtigste für die menschliche Gesellschaft in der Zukunft sein, und dies wird nicht nur im kommerziellen Bereich bleiben Wettbewerb, sondern auch das Spiel der strategischen Ressourcen der Großmächte werden. Zukünftig werden die Investitionen in Hochleistungsrechner-Infrastruktur und Rechenleistungsreserven exponentiell zunehmen.
• Das dezentrale verteilte Rechenleistungsnetzwerk hat den größten Bedarf an KI-Großmodelltraining, steht aber auch vor den größten Herausforderungen und technischen Engpässen. Einschließlich der Notwendigkeit komplexer Datensynchronisierungs- und Netzwerkoptimierungsprobleme. Darüber hinaus sind Datenschutz und Sicherheit wichtige Einschränkungen. Obwohl einige bestehende Techniken vorläufige Lösungen liefern können, sind sie aufgrund des enormen Rechen- und Kommunikationsaufwands immer noch nicht für groß angelegte verteilte Trainingsaufgaben anwendbar.
• Das dezentrale verteilte Rechenleistungsnetzwerk hat eine bessere Chance, in der Modellbegründung zu landen, und es kann vorhersagen, dass der zukünftige inkrementelle Raum auch groß genug ist. Es steht aber auch vor Herausforderungen wie Kommunikationsverzögerungen, Datenschutz und Modellsicherheit. Im Vergleich zum Modelltraining weist Inferenz eine geringere Rechenkomplexität und Dateninteraktion auf und eignet sich besser für verteilte Umgebungen.
• Anhand der Beispiele zweier Start-up-Unternehmen, Together und Gensyn.ai, werden aus der Perspektive der Technologieoptimierung und des Designs der Anreizschicht die allgemeine Forschungsrichtung und die spezifischen Ideen des dezentralen verteilten Rechenleistungsnetzwerks veranschaulicht.

1. Verteilte Rechenleistung – Training großer Modelle

Wir diskutieren die Anwendung verteilter Rechenleistung im Training und konzentrieren uns im Allgemeinen auf das Training großer Sprachmodelle. Der Hauptgrund dafür ist, dass das Training kleiner Modelle nicht viel Rechenleistung erfordert. Um verteilten Datenschutz und eine Menge zu erreichen von Projekten Das Problem ist nicht kosteneffektiv, es ist besser, es direkt und zentral zu lösen. Das große Sprachmodell hat einen enormen Bedarf an Rechenleistung und befindet sich derzeit im Anfangsstadium des Ausbruchs. Von 2012 bis 2018 wird sich der Rechenbedarf der KI etwa alle vier Monate verdoppeln. Man geht davon aus, dass dies in den nächsten fünf bis acht Jahren der Fall sein wird immer noch eine enorme inkrementelle Nachfrage sein.

Obwohl es große Chancen gibt, müssen auch die Probleme klar erkannt werden. Jeder weiß, dass die Szene riesig ist, aber wo liegen die konkreten Herausforderungen? Wer diese Probleme ins Visier nehmen kann, anstatt blind ins Spiel einzusteigen, ist der Kern der Beurteilung der hervorragenden Projekte dieses Tracks.

(NVIDIANeMoMegatronFramework）

1. Gesamttrainingsprozess

Nehmen Sie als Beispiel das Training eines großen Modells mit 175 Milliarden Parametern. Aufgrund der enormen Größe des Modells muss es auf vielen GPU-Geräten parallel trainiert werden. Angenommen, es gibt einen zentralen Computerraum mit 100 GPUs und jedes Gerät verfügt über 32 GB Speicher.

• Datenaufbereitung: Zunächst ist ein riesiger Datensatz erforderlich, der verschiedene Daten wie Internetinformationen, Nachrichten, Bücher usw. enthält. Diese Daten müssen vor dem Training vorverarbeitet werden, einschließlich Textbereinigung, Tokenisierung, Vokabelaufbau usw.
• Datensegmentierung: Die verarbeiteten Daten werden zur parallelen Verarbeitung auf mehreren GPUs in mehrere Stapel aufgeteilt. Angenommen, die ausgewählte Stapelgröße beträgt 512, d. h. jeder Stapel enthält 512 Textsequenzen. Anschließend teilen wir den gesamten Datensatz in Stapel auf und bilden so eine Stapelwarteschlange.
• Datenübertragung zwischen Geräten: Zu Beginn jedes Trainingsschritts entnimmt die CPU einen Stapel aus der Stapelwarteschlange und sendet die Daten dieses Stapels dann über den PCIe-Bus an die GPU. Unter der Annahme, dass die durchschnittliche Länge jeder Textsequenz 1024 Token beträgt, beträgt die Datengröße jedes Stapels ungefähr 512 * 1024 * 4B = 2 MB (vorausgesetzt, jedes Token wird durch eine 4-Byte-Gleitkommazahl mit einfacher Genauigkeit dargestellt). Dieser Datenübertragungsvorgang dauert in der Regel nur wenige Millisekunden.
• Paralleles Training: Nachdem jedes GPU-Gerät die Daten empfangen hat, beginnt es mit der Durchführung von Vorwärtsdurchlauf- und Rückwärtsdurchlaufberechnungen und berechnet den Gradienten jedes Parameters. Aufgrund der Größe des Modells kann der Speicher einer einzelnen GPU nicht alle Parameter speichern. Daher verwenden wir die Modellparallelitätstechnologie, um die Modellparameter auf mehrere GPUs zu verteilen.
• Gradientenaggregation und Parameteraktualisierung: Nachdem die Backpropagation-Berechnung abgeschlossen ist, erhält jede GPU den Gradienten eines Teils der Parameter. Diese Farbverläufe müssen dann über alle GPU-Geräte hinweg aggregiert werden, um den globalen Farbverlauf zu berechnen. Dies erfordert eine Datenübertragung über das Netzwerk. Unter der Annahme, dass ein 25-Gbit/s-Netzwerk verwendet wird, dauert die Übertragung von 700 GB Daten etwa 224 Sekunden (vorausgesetzt, dass jeder Parameter Gleitkommazahlen mit einfacher Genauigkeit verwendet, dann sind 175 Milliarden Parameter etwa 700 GB). Jede GPU aktualisiert dann ihre gespeicherten Parameter entsprechend dem globalen Gradienten.
• Synchronisierung: Nachdem die Parameter aktualisiert wurden, müssen alle GPU-Geräte synchronisiert werden, um sicherzustellen, dass sie alle konsistente Modellparameter für den nächsten Trainingsschritt verwenden. Dies erfordert auch eine Datenübertragung über das Netzwerk.
• Trainingsschritte wiederholen: Wiederholen Sie die obigen Schritte, bis das Training aller Chargen abgeschlossen ist oder die vorgegebene Anzahl von Trainingsrunden (Epoche) erreicht ist.

Dieser Prozess erfordert eine große Menge an Datenübertragung und Synchronisierung, was zu einem Engpass für die Trainingseffizienz werden kann. Daher sind die Optimierung der Netzwerkbandbreite und -latenz sowie die Verwendung effizienter Parallel- und Synchronisationsstrategien für das Training groß angelegter Modelle sehr wichtig.

2. Engpass im Kommunikationsaufwand:

Es ist zu beachten, dass der Kommunikationsengpass auch der Grund dafür ist, dass das aktuelle Netzwerk mit verteilter Rechenleistung kein Training großer Sprachmodelle durchführen kann.

Jeder Knoten muss häufig Informationen austauschen, um zusammenzuarbeiten, was zu einem Kommunikationsaufwand führt. Bei großen Sprachmodellen ist dieses Problem aufgrund der großen Anzahl von Parametern des Modells besonders gravierend. Der Kommunikationsaufwand gliedert sich in folgende Aspekte:

• Datenübertragung: Knoten müssen während des Trainings häufig Modellparameter und Gradienteninformationen austauschen. Dies erfordert die Übertragung großer Datenmengen im Netzwerk und verbraucht viel Netzwerkbandbreite. Wenn die Netzwerkbedingungen schlecht sind oder der Abstand zwischen den Rechenknoten groß ist, ist die Verzögerung der Datenübertragung hoch, was den Kommunikationsaufwand weiter erhöht.
• Synchronisationsproblem: Während des Trainings müssen Knoten zusammenarbeiten, um ein korrektes Training sicherzustellen. Dies erfordert häufige Synchronisationsvorgänge zwischen Knoten, wie z. B. das Aktualisieren von Modellparametern, das Berechnen globaler Gradienten usw. Diese synchronen Vorgänge müssen eine große Datenmenge im Netzwerk übertragen und darauf warten, dass alle Knoten den Vorgang abschließen, was zu hohem Kommunikationsaufwand und Wartezeit führt.
• Gradientenakkumulation und -aktualisierung: Während des Trainingsprozesses muss jeder Knoten seinen eigenen Gradienten berechnen und ihn zur Akkumulation und Aktualisierung an andere Knoten senden. Dies erfordert die Übertragung einer großen Menge an Gradientendaten im Netzwerk und die Notwendigkeit, darauf zu warten, dass alle Knoten die Berechnung und Übertragung der Gradienten abgeschlossen haben, was auch der Grund für einen großen Kommunikationsaufwand ist.
• Datenkonsistenz: Es muss sichergestellt werden, dass die Modellparameter jedes Knotens konsistent sind. Dies erfordert häufige Datenprüfsummen- und Synchronisierungsvorgänge zwischen Knoten, was zu einem hohen Kommunikationsaufwand führt.

Obwohl es einige Methoden zur Reduzierung des Kommunikationsaufwands gibt, wie z. B. die Komprimierung von Parametern und Gradienten, effiziente Parallelstrategien usw., können diese Methoden einen zusätzlichen Rechenaufwand mit sich bringen oder den Trainingseffekt des Modells negativ beeinflussen. Außerdem können diese Methoden das Kommunikations-Overhead-Problem nicht vollständig lösen, insbesondere bei schlechten Netzwerkbedingungen oder großen Entfernungen zwischen Rechenknoten.

Als Beispiel:

Dezentrales verteiltes Rechenleistungsnetzwerk

Das GPT-3-Modell verfügt über 175 Milliarden Parameter. Wenn wir diese Parameter mithilfe von Gleitkommazahlen mit einfacher Genauigkeit (4 Bytes pro Parameter) darstellen, erfordert das Speichern dieser Parameter etwa 700 GB Speicher. Beim verteilten Training müssen diese Parameter häufig zwischen Rechenknoten übertragen und aktualisiert werden.

Unter der Annahme, dass es 100 Rechenknoten gibt, muss jeder Knoten in jedem Schritt alle Parameter aktualisieren, und dann muss jeder Schritt etwa 70 TB (700 GB*100) Daten übertragen. Wenn wir davon ausgehen, dass ein Schritt 1 Sekunde dauert (sehr optimistische Annahme), müssen 70 TB Daten pro Sekunde übertragen werden. Dieser Bandbreitenbedarf übersteigt den der meisten Netze bereits bei weitem und ist auch eine Frage der Machbarkeit.

In der Realität kann die Datenübertragungszeit aufgrund von Kommunikationsverzögerungen und Netzwerküberlastungen viel länger als 1 Sekunde sein. Dies bedeutet, dass Rechenknoten möglicherweise viel Zeit damit verbringen müssen, auf die Datenübertragung zu warten, anstatt tatsächliche Berechnungen durchzuführen. Dadurch wird die Effizienz des Trainings erheblich verringert, und diese Verringerung der Effizienz kann nicht durch Warten behoben werden, sondern durch den Unterschied zwischen machbar und undurchführbar, wodurch der gesamte Trainingsprozess undurchführbar wird.

Zentraler Computerraum

Selbst in einer zentralisierten Computerraumumgebung erfordert das Training großer Modelle immer noch eine starke Kommunikationsoptimierung.

In einer zentralisierten Computerraumumgebung werden Hochleistungscomputergeräte als Cluster verwendet und über ein Hochgeschwindigkeitsnetzwerk verbunden, um Computeraufgaben gemeinsam zu nutzen. Selbst wenn ein Modell mit einer extrem großen Anzahl von Parametern in einer solchen Hochgeschwindigkeitsnetzwerkumgebung trainiert wird, stellt der Kommunikationsaufwand immer noch einen Engpass dar, da die Parameter und Gradienten des Modells häufig zwischen verschiedenen Computergeräten übertragen und aktualisiert werden müssen .

Angenommen, es gibt, wie eingangs erwähnt, 100 Rechenknoten und jeder Server verfügt über eine Netzwerkbandbreite von 25 Gbit/s. Wenn jeder Server in jedem Trainingsschritt alle Parameter aktualisieren muss, muss jeder Trainingsschritt etwa 700 GB Daten übertragen und dauert etwa 224 Sekunden. Durch die Nutzung des zentralisierten Computerraums können Entwickler die Netzwerktopologie im Rechenzentrum optimieren und Technologien wie Modellparallelität nutzen, um diese Zeit deutlich zu verkürzen.

Im Gegensatz dazu beträgt die durchschnittliche Netzwerkbandbreite jedes Knotens nur 1 Gbit/s, wenn das gleiche Training in einer verteilten Umgebung durchgeführt wird und davon ausgegangen wird, dass immer noch 100 Rechenknoten auf der ganzen Welt verteilt sind. In diesem Fall dauert die Übertragung der gleichen 700 GB an Daten etwa 5600 Sekunden, was viel länger ist als im zentralen Computerraum. Aufgrund von Netzwerkverzögerungen und Überlastungen kann die tatsächlich benötigte Zeit außerdem länger sein.

Im Vergleich zur Situation in einem Netzwerk mit verteilter Rechenleistung ist es jedoch relativ einfach, den Kommunikationsaufwand in einer zentralisierten Computerraumumgebung zu optimieren. Denn in einer zentralisierten Computerraumumgebung sind Computergeräte normalerweise mit demselben Hochgeschwindigkeitsnetzwerk verbunden und die Bandbreite und Verzögerung des Netzwerks sind relativ gut. In einem Netzwerk mit verteilter Rechenleistung können die Rechenknoten über die ganze Welt verteilt sein und die Netzwerkbedingungen können relativ schlecht sein, was das Problem des Kommunikationsaufwands noch gravierender macht.

Beim Training von GPT-3 verwendet OpenAI ein modellparalleles Framework namens Megatron, um das Problem des Kommunikationsoverheads zu lösen. Megatron teilt die Parameter des Modells auf und verarbeitet sie parallel auf mehreren GPUs, wobei jedes Gerät nur für die Speicherung und Aktualisierung eines Teils der Parameter verantwortlich ist, wodurch die Menge der Parameter, die jedes Gerät verarbeiten muss, und der Kommunikationsaufwand reduziert werden. Gleichzeitig wird während des Trainings auch ein Hochgeschwindigkeitsverbindungsnetzwerk verwendet und die Länge des Kommunikationspfads wird durch die Optimierung der Netzwerktopologie reduziert.

(Daten, die zum Trainieren von LLM-Modellen verwendet werden)

3. Warum kann das verteilte Rechenleistungsnetzwerk diese Optimierungen nicht durchführen

Dies ist möglich, aber im Vergleich zum zentralisierten Computerraum ist der Effekt dieser Optimierungen sehr begrenzt.

1. Optimierung der Netzwerktopologie: Im zentralen Computerraum können die Netzwerkhardware und das Layout direkt gesteuert werden, sodass die Netzwerktopologie entsprechend den Anforderungen entworfen und optimiert werden kann. In einer verteilten Umgebung sind die Rechenknoten jedoch an verschiedenen geografischen Standorten verteilt, sogar an einem in China und einem in den Vereinigten Staaten, und es gibt keine Möglichkeit, die Netzwerkverbindung zwischen ihnen direkt zu steuern. Obwohl Software zur Optimierung des Datenübertragungspfads verwendet werden kann, ist sie nicht so effektiv wie die direkte Optimierung des Hardware-Netzwerks. Gleichzeitig variieren aufgrund unterschiedlicher geografischer Standorte auch Netzwerkverzögerungen und Bandbreiten stark, was die Wirkung der Netzwerktopologieoptimierung weiter einschränkt.
2. Modellparallelität: Modellparallelität ist eine Technologie, die die Parameter des Modells auf mehrere Rechenknoten aufteilt und die Trainingsgeschwindigkeit durch Parallelverarbeitung verbessert. Bei dieser Methode müssen jedoch in der Regel häufig Daten zwischen Knoten übertragen werden, sodass hohe Anforderungen an die Netzwerkbandbreite und Latenz bestehen. In einem zentralisierten Computerraum kann Modellparallelität aufgrund der hohen Netzwerkbandbreite und der geringen Latenz sehr effektiv sein. In einer verteilten Umgebung ist die Modellparallelität jedoch aufgrund schlechter Netzwerkbedingungen stark eingeschränkt.

4. Herausforderungen im Bereich Datensicherheit und Datenschutz

Nahezu alle Zusammenhänge der Datenverarbeitung und -übertragung können Auswirkungen auf die Datensicherheit und den Datenschutz haben:

1. Datenverteilung: Die Trainingsdaten müssen an jeden an der Berechnung beteiligten Knoten verteilt werden. Die in diesem Link enthaltenen Daten können auf verteilten Knoten böswillig verwendet bzw. durchgesickert werden.
2. Modelltraining: Während des Trainingsprozesses verwendet jeder Knoten die ihm zugewiesenen Daten zur Berechnung und gibt dann die Aktualisierung oder den Gradienten der Modellparameter aus. Wenn während dieses Vorgangs der Berechnungsprozess des Knotens gestohlen oder das Ergebnis in böswilliger Absicht analysiert wird, können auch Daten verloren gehen.
3. Parameter- und Gradientenaggregation: Die Ausgabe jedes Knotens muss aggregiert werden, um das globale Modell zu aktualisieren, und durch die Kommunikation während des Aggregationsprozesses können auch Informationen über die Trainingsdaten verloren gehen.

**Welche Lösungen gibt es für Datenschutzbedenken? **

• Sichere Multi-Party-Berechnung: SMC wurde erfolgreich bei einigen spezifischen und kleinen Rechenaufgaben eingesetzt. Bei groß angelegten verteilten Trainingsaufgaben wurde es jedoch aufgrund seines großen Rechen- und Kommunikationsaufwands noch nicht weit verbreitet eingesetzt.
• Differenzierter Datenschutz: Wird bei bestimmten Datenerfassungs- und Analyseaufgaben angewendet, z. B. bei Chrome-Benutzerstatistiken. Bei umfangreichen Deep-Learning-Aufgaben hat DP jedoch einen Einfluss auf die Genauigkeit des Modells. Gleichzeitig ist es auch eine Herausforderung, einen geeigneten Mechanismus zur Geräuscherzeugung und -addition zu entwickeln.
• Federated Learning: Wird bei einigen Trainingsaufgaben für Edge-Gerätemodelle angewendet, z. B. bei der Vokabelvorhersage für Android-Tastaturen usw. Bei größeren verteilten Trainingsaufgaben ist FL jedoch mit Problemen wie hohem Kommunikationsaufwand und komplexer Koordination konfrontiert.
• Homomorphe Verschlüsselung: Sie wurde bei einigen Aufgaben mit geringerem Rechenaufwand erfolgreich angewendet. Bei groß angelegten verteilten Trainingsaufgaben wurde es jedoch aufgrund seines hohen Rechenaufwands noch nicht weit verbreitet eingesetzt.

Zusammenfassung

Jede der oben genannten Methoden hat ihre anwendbaren Szenarien und Einschränkungen, und keine der Methoden kann das Datenschutzproblem im großen Modelltraining eines Netzwerks mit verteilter Rechenleistung vollständig lösen.

*** Kann ZK, das große Hoffnungen hat, das Datenschutzproblem im großen Modelltraining lösen? ***

Theoretisch kann ZKP verwendet werden, um den Datenschutz beim verteilten Rechnen zu gewährleisten, sodass ein Knoten nachweisen kann, dass er Berechnungen gemäß den Vorschriften durchgeführt hat, aber keine tatsächlichen Eingabe- und Ausgabedaten offenlegen muss.

Tatsächlich treten jedoch bei der Verwendung von ZKP für das Training großer Modelle großer verteilter Rechenleistungsnetzwerke die folgenden Engpässe auf:

• Rechen- und Kommunikationsaufwand: Die Erstellung und Überprüfung wissensfreier Beweise erfordert viele Rechenressourcen. Darüber hinaus ist auch der Kommunikationsaufwand von ZKP hoch, da der Nachweis selbst übermittelt werden muss. Dieser Overhead kann bei der Schulung großer Modelle besonders groß werden. Wenn beispielsweise für die Berechnung jedes Mini-Batches die Erstellung eines Nachweises erforderlich ist, kann dies die Gesamtzeit und die Schulungskosten erheblich erhöhen.
• Komplexität des ZK-Protokolls: Das Entwerfen und Implementieren eines ZKP-Protokolls, das für das Training großer Modelle geeignet ist, wird sehr kompliziert sein. Dieses Protokoll muss in der Lage sein, große Datenmengen und komplexe Berechnungen zu verarbeiten, und es muss in der Lage sein, mögliche ungewöhnliche Fehler zu verarbeiten.
• Hardware- und Softwarekompatibilität: Die Verwendung von ZKP erfordert spezielle Hardware- und Softwareunterstützung, die möglicherweise nicht auf allen verteilten Computergeräten verfügbar ist.

Zusammenfassung

Um ZKP für das Training großer Modelle in verteilten Rechenleistungsnetzwerken in großem Maßstab zu nutzen, sind mehrere Jahre Forschung und Entwicklung erforderlich, und in dieser Richtung sind auch mehr Energie und Ressourcen von der akademischen Gemeinschaft erforderlich.

2. Verteilte Rechenleistung – Modellbegründung

Ein weiteres relativ großes Szenario verteilter Rechenleistung ist das Modellschlussfolgern. Nach unserer Einschätzung des Entwicklungspfads großer Modelle wird sich die Nachfrage nach Modelltraining allmählich verlangsamen, wenn die großen Modelle nach Erreichen eines Höhepunkts ausgereift sind. Die Argumentationsanforderungen werden dementsprechend exponentiell ansteigen mit der Reife großer Modelle und AIGC.

Im Vergleich zu Trainingsaufgaben weisen Inferenzaufgaben normalerweise eine geringere Rechenkomplexität und eine schwächere Dateninteraktion auf und eignen sich besser für verteilte Umgebungen.

(Power-LLM-Inferenz mit NVIDIA Triton)

1. Herausforderung

Kommunikationsverzögerung:

In einer verteilten Umgebung ist die Kommunikation zwischen Knoten unerlässlich. In einem dezentralen Netzwerk mit verteilter Rechenleistung können die Knoten über die ganze Welt verteilt sein, sodass die Netzwerklatenz ein Problem darstellen kann, insbesondere bei Argumentationsaufgaben, die eine Reaktion in Echtzeit erfordern.

Modellbereitstellung und -aktualisierung:

Das Modell muss auf jedem Knoten bereitgestellt werden. Wenn das Modell aktualisiert wird, muss jeder Knoten sein Modell aktualisieren, was viel Netzwerkbandbreite und Zeit verbraucht.

Datenprivatsphäre:

Obwohl Inferenzaufgaben normalerweise nur Eingabedaten und -modelle erfordern und keine große Menge an Zwischendaten und Parametern zurückgeben müssen, können die Eingabedaten dennoch vertrauliche Informationen enthalten, z. B. persönliche Informationen des Benutzers.

Modellsicherheit:

In einem dezentralen Netzwerk muss das Modell auf nicht vertrauenswürdigen Knoten bereitgestellt werden, was zu einem Verlust des Modells und dem Problem von Modelleigentumsrechten und -missbrauch führt. Dies kann auch Sicherheits- und Datenschutzbedenken aufwerfen. Wenn ein Modell zur Verarbeitung sensibler Daten verwendet wird, können Knoten durch die Analyse des Verhaltens des Modells auf sensible Informationen schließen.

Qualitätskontrolle:

Jeder Knoten in einem dezentralen Netzwerk mit verteilter Rechenleistung verfügt möglicherweise über unterschiedliche Rechenkapazitäten und Ressourcen, was es schwierig machen kann, die Leistung und Qualität von Inferenzaufgaben zu gewährleisten.

2. Machbarkeit

Rechenkomplexität:

In der Trainingsphase muss das Modell wiederholt iterieren. Während des Trainingsprozesses ist es notwendig, die Vorwärtsausbreitung und Rückausbreitung jeder Schicht zu berechnen, einschließlich der Berechnung der Aktivierungsfunktion, der Berechnung der Verlustfunktion und der Berechnung von der Gradient und die Aktualisierung des Gewichts. Daher ist die Rechenkomplexität des Modelltrainings hoch.

In der Inferenzphase ist nur ein Vorwärtsdurchlauf erforderlich, um die Vorhersage zu berechnen. In GPT-3 ist es beispielsweise erforderlich, den Eingabetext in einen Vektor umzuwandeln und dann eine Vorwärtsausbreitung durch jede Schicht des Modells (normalerweise die Transformer-Schicht) durchzuführen, schließlich die Ausgabewahrscheinlichkeitsverteilung zu erhalten und die nächste zu generieren Wort gemäß dieser Verteilung. In GANs muss das Modell ein Bild basierend auf dem Eingaberauschvektor generieren. Diese Operationen beinhalten nur die Vorwärtsausbreitung des Modells, erfordern keine Berechnung von Gradienten oder Aktualisierungsparametern und weisen eine geringe Rechenkomplexität auf.

Dateninteraktivität:

Während der Inferenzphase verarbeitet das Modell normalerweise eine einzelne Eingabe und nicht den großen Datenstapel während des Trainings. Das Ergebnis jeder Schlussfolgerung hängt nur von der aktuellen Eingabe ab, nicht von anderen Eingaben oder Ausgaben, sodass keine große Dateninteraktion erforderlich ist und der Kommunikationsdruck geringer ist.

Nehmen wir als Beispiel das generative Bildmodell und gehen davon aus, dass wir GANs zum Generieren von Bildern verwenden. Wir müssen nur einen Rauschvektor in das Modell eingeben, und dann generiert das Modell ein entsprechendes Bild. In diesem Prozess generiert jede Eingabe nur eine Ausgabe und es besteht keine Abhängigkeit zwischen den Ausgaben, sodass keine Dateninteraktion erforderlich ist.

Am Beispiel von GPT-3 erfordert jede Generation des nächsten Wortes nur die aktuelle Texteingabe und den Status des Modells und muss nicht mit anderen Eingaben oder Ausgaben interagieren, sodass die Anforderungen an die Dateninteraktivität ebenfalls schwach sind.

Zusammenfassung

Unabhängig davon, ob es sich um ein großes Sprachmodell oder ein generatives Bildmodell handelt, sind die Rechenkomplexität und die Dateninteraktivität von Argumentationsaufgaben relativ gering, was besser für dezentrale Netzwerke mit verteilter Rechenleistung geeignet ist, weshalb die meisten Projekte, die wir jetzt sehen, in eine Richtung gehen der Kraft.

3. Artikel

Der technische Schwellenwert und die technische Breite eines dezentralen verteilten Rechenleistungsnetzwerks sind sehr hoch und erfordern auch die Unterstützung von Hardwareressourcen, sodass wir bisher nicht allzu viele Versuche gesehen haben. Nehmen Sie Together und Gensyn.ai als Beispiele:

1.Gemeinsam

(Roter Pyjama von Together)

Together ist ein Unternehmen, das sich auf die Open Source großer Modelle konzentriert und sich dezentralen KI-Rechenleistungslösungen verschrieben hat. Es hofft, dass jeder überall auf KI zugreifen und sie nutzen kann. Together hat gerade eine 20-Millionen-USD-Seed-Runde unter der Leitung von Lux Capital abgeschlossen.

Together wurde von Chris, Percy und Ce mitbegründet. Die ursprüngliche Absicht bestand darin, dass ein groß angelegtes Modelltraining eine große Anzahl von High-End-GPU-Clustern und teuren Ausgaben erforderte und diese Ressourcen und Modelltrainingsfunktionen auch auf wenige konzentriert waren Großunternehmen.

Aus meiner Sicht ist ein vernünftigerer unternehmerischer Plan für verteilte Rechenleistung:

Schritt 1. Open-Source-Modell

Um Modellargumente in einem dezentralen Netzwerk mit verteilter Rechenleistung zu implementieren, müssen Knoten in der Lage sein, das Modell zu geringen Kosten zu erhalten, d muss im entsprechenden Fall lizenziert werden. Wenn unten verwendet, erhöht sich die Komplexität und die Kosten der Implementierung. Beispielsweise ist chatgpt als Nicht-Open-Source-Modell nicht für die Ausführung auf einem dezentralen Rechenleistungsnetzwerk geeignet.

Daher kann spekuliert werden, dass die unsichtbare Barriere eines Unternehmens, das ein dezentrales Rechenleistungsnetzwerk bereitstellt, über starke Fähigkeiten zur Entwicklung und Wartung von Modellen in großem Maßstab verfügen muss. Ein selbst entwickeltes und quelloffenes leistungsstarkes Basismodell kann die Abhängigkeit von Open-Source-Modellen Dritter bis zu einem gewissen Grad beseitigen und die grundlegendsten Probleme dezentraler Rechenleistungsnetzwerke lösen. Gleichzeitig ist es besser zu beweisen, dass das Rechenleistungsnetzwerk das Training und die Argumentation großer Modelle effektiv durchführen kann.

Und Together tat dasselbe. Das kürzlich veröffentlichte LLaMA-basierte RedPajama wurde gemeinsam von Teams wie Together, Ontocord.ai, ETH DS3Lab, Stanford CRFM und Hazy Research ins Leben gerufen. Ziel ist die Entwicklung einer Reihe vollständig Open-Source-großer Sprachmodelle.

Schritt 2. Verteilte Rechenleistung landete auf Modellbegründung

Wie in den beiden obigen Abschnitten erwähnt, weist die Modellinferenz im Vergleich zum Modelltraining eine geringere Rechenkomplexität und Dateninteraktion auf und eignet sich besser für eine dezentrale verteilte Umgebung.

Auf der Grundlage des Open-Source-Modells hat das Forschungs- und Entwicklungsteam von Together eine Reihe von Aktualisierungen am RedPajama-INCITE-3B-Modell vorgenommen, z. B. mithilfe von LoRA, um eine kostengünstige Feinabstimmung zu erreichen und das Modell auf der CPU (insbesondere MacBook) laufen zu lassen Pro mit M2 Pro Prozessor) Läuft auf dem Modell seidiger. Obwohl der Maßstab dieses Modells klein ist, übertreffen seine Fähigkeiten gleichzeitig andere Modelle desselben Maßstabs und wurden in rechtlichen, sozialen und anderen Szenarien praktisch angewendet.

Schritt 3. Verteilte Rechenleistung landete beim Modelltraining

(Schematische Darstellung des Rechenleistungsnetzwerks zur Überwindung von Kommunikationsengpässen für dezentrales Training)

Mittel- und langfristig muss es trotz großer Herausforderungen und technischer Engpässe am attraktivsten sein, den Rechenleistungsbedarf für das Training großer KI-Modelle zu decken. Together begann zu Beginn seiner Gründung mit der Überwindung des Kommunikationsengpasses in der dezentralen Ausbildung. Sie veröffentlichten auch einen verwandten Artikel zu NeurIPS 2022: Overcoming Communication Bottlenecks for Decentralized Training. Wir können hauptsächlich die folgenden Richtungen zusammenfassen:

Planungsoptimierung

Beim Training in einer dezentralen Umgebung ist es wichtig, kommunikationsintensive Aufgaben Geräten mit schnelleren Verbindungen zuzuweisen, da die Verbindungen zwischen Knoten unterschiedliche Latenzen und Bandbreiten aufweisen. Together erstellt ein Modell zur Beschreibung der Kosten einer bestimmten Planungsstrategie und optimiert die Planungsstrategie besser, um Kommunikationskosten zu minimieren und den Schulungsdurchsatz zu maximieren. Das Together-Team stellte außerdem fest, dass der End-to-End-Trainingsdurchsatz nur 1,7- bis 2,3-mal langsamer war, obwohl das Netzwerk 100-mal langsamer war. Daher ist es interessant, die Lücke zwischen verteilten Netzwerken und zentralisierten Clustern durch Planungsoptimierung zu schließen.

Optimierung der Kommunikationskomprimierung

Together schlägt eine Kommunikationskomprimierung für Vorwärtsaktivierungen und Rückwärtsgradienten vor und führt den AQ-SGD-Algorithmus ein, der strenge Garantien für die Konvergenz des stochastischen Gradientenabstiegs bietet. AQ-SGD ist in der Lage, große Basismodelle in langsamen Netzwerken (z. B. 500 Mbit/s) zu optimieren, was nur 31 % langsamer ist als die End-to-End-Trainingsleistung in zentralisierten Computernetzwerken (z. B. 10 Gbit/s) ohne Komprimierung. Darüber hinaus kann AQ-SGD mit modernsten Gradientenkomprimierungstechniken wie QuantizedAdam kombiniert werden, um eine End-to-End-Beschleunigung von 10 % zu erreichen.

Projektübersicht

Die Teamkonfiguration ist insgesamt sehr umfassend, die Mitglieder verfügen über einen sehr starken akademischen Hintergrund, von der Entwicklung groß angelegter Modelle über Cloud Computing bis hin zur Hardwareoptimierung werden sie von Branchenexperten unterstützt. Und Together zeigte eine langfristige und geduldige Haltung bei der Pfadplanung, von der Entwicklung großer Open-Source-Modelle über das Testen ungenutzter Rechenleistung (z. B. Mac) im verteilten Rechenleistungsnetzwerk und die Argumentation mit Modellen bis hin zur verteilten Rechenleistung im Großen und Ganzen Layout zum Modelltraining. — Es gibt diese Art von Ansammlung und das Gefühl von dünnem Haar :)

Aber bisher habe ich nicht allzu viele Forschungsergebnisse von Together in der Anreizschicht gesehen. Ich denke, dass dies genauso wichtig ist wie Technologieforschung und -entwicklung und ein Schlüsselfaktor für die Entwicklung eines dezentralen Rechenleistungsnetzwerks ist.

2.Review.ai

(Gensyn.ai)

Aus dem technischen Weg von Together können wir den Implementierungsprozess des dezentralen Rechenleistungsnetzwerks in Modelltraining und Argumentation sowie die entsprechenden Forschungs- und Entwicklungsprioritäten grob verstehen.

Ein weiterer wichtiger Punkt, der nicht ignoriert werden darf, ist das Design der Anreizschicht/des Konsensalgorithmus des Rechenleistungsnetzwerks. Ein hervorragendes Netzwerk muss beispielsweise über Folgendes verfügen:

1. Stellen Sie sicher, dass die Vorteile attraktiv genug sind;
2. Stellen Sie sicher, dass jeder Bergmann die Vorteile erhält, die er verdient, einschließlich Betrugsbekämpfung und mehr Lohn für mehr Arbeit;
3. Stellen Sie sicher, dass Aufgaben direkt und angemessen geplant und auf verschiedene Knoten verteilt werden und es nicht zu einer großen Anzahl inaktiver Knoten oder zu einer Überfüllung einiger Knoten kommt.
4. Der Anreizalgorithmus ist einfach und effizient und verursacht keine übermäßige Systembelastung und Verzögerung.

……

Sehen Sie, wie Gensyn.ai es macht:

• Node werden

Zunächst konkurrieren die Löser im Rechenleistungsnetzwerk um das Recht, von Benutzern über Gebote eingereichte Aufgaben zu verarbeiten. Je nach Umfang der Aufgabe und dem Risiko, als Betrug eingestuft zu werden, muss der Löser einen bestimmten Betrag verpfänden.

• verifizieren

Solver generiert beim Aktualisieren von Parametern mehrere Prüfpunkte (um die Transparenz und Rückverfolgbarkeit der Arbeit sicherzustellen) und generiert regelmäßig kryptografische Argumentationsnachweise (Nachweis des Arbeitsfortschritts) über Aufgaben;

Wenn der Solver die Arbeit abschließt und einen Teil der Berechnungsergebnisse generiert, wählt das Protokoll einen Prüfer aus, und der Prüfer verspricht auch einen bestimmten Betrag (um sicherzustellen, dass der Prüfer die Prüfung ehrlich durchführt) und entscheidet, welcher Teil der Berechnung ist Die Ergebnisse müssen anhand der oben aufgeführten Nachweise überprüft werden.

• Wenn Löser und Verifizierer voneinander abweichen

Durch die Merkle-Baum-basierte Datenstruktur wird der genaue Ort lokalisiert, an dem sich die Berechnungsergebnisse unterscheiden. Der gesamte Verifizierungsvorgang findet in der Kette statt und Betrüger werden vom zugesagten Betrag abgezogen.

Projektübersicht

Durch das Design des Anreiz- und Verifizierungsalgorithmus muss Gensyn.ai während des Verifizierungsprozesses nicht alle Ergebnisse der gesamten Rechenaufgabe wiedergeben, sondern nur einen Teil der Ergebnisse entsprechend dem bereitgestellten Beweis kopieren und verifizieren, was eine erhebliche Verbesserung darstellt die Effizienz der Verifizierung. Gleichzeitig müssen Knoten nur einen Teil der Berechnungsergebnisse speichern, was auch den Verbrauch von Speicherplatz und Rechenressourcen reduziert. Darüber hinaus können potenziell betrügerische Knoten nicht vorhersagen, welche Teile zur Überprüfung ausgewählt werden, sodass auch das Betrugsrisiko verringert wird.

Diese Methode zur Überprüfung von Unterschieden und zur Erkennung von Betrügern kann auch schnell Fehler im Berechnungsprozess finden, ohne die gesamten Berechnungsergebnisse zu vergleichen (ausgehend vom Wurzelknoten des Merkle-Baums und Schritt für Schritt nach unten). Sehr effektiv für umfangreiche Rechenaufgaben.

Kurz gesagt, das Designziel der Anreiz-/Verifizierungsschicht von Gensyn.ai ist: prägnant und effizient. Allerdings ist es derzeit auf die theoretische Ebene beschränkt und die konkrete Umsetzung kann mit folgenden Herausforderungen konfrontiert sein:

• Wie man im Wirtschaftsmodell geeignete Parameter festlegt, damit Betrug wirksam verhindert werden kann, ohne eine zu hohe Schwelle für die Teilnehmer festzulegen.
• Im Hinblick auf die technische Umsetzung ist die Formulierung eines effektiven periodischen Verschlüsselungsbegründungsnachweises ebenfalls ein komplexes Thema, das fortgeschrittene Kenntnisse der Kryptographie erfordert.
• In Bezug auf die Aufgabenzuweisung muss lediglich die Art und Weise, wie das Rechenleistungsnetzwerk Aufgaben auswählt und verschiedenen Lösern zuweist, auch durch einen angemessenen Planungsalgorithmus unterstützt werden. Es ist offensichtlich fraglich, ob es hinsichtlich der Effizienz und Machbarkeit darum geht, Aufgaben nur entsprechend dem Angebot zuzuweisen B. Rechenleistung. Starke Knoten können größere Aufgaben bewältigen, nehmen jedoch möglicherweise nicht an Ausschreibungen teil (dies beinhaltet Anreize für die Knotenverfügbarkeit), und Knoten mit geringer Rechenleistung bieten möglicherweise das höchste Gebot, sind jedoch nicht für komplexe Berechnungen in großem Maßstab geeignet Aufgaben.

Viertens ein wenig über die Zukunft nachdenken

Die Frage, wer ein dezentrales Rechenleistungsnetzwerk benötigt, ist nicht geklärt. Die Anwendung ungenutzter Rechenleistung auf groß angelegtes Modelltraining, das enorme Rechenleistungsressourcen erfordert, ist offensichtlich der sinnvollste und einfallsreichste Bereich. Doch tatsächlich müssen uns Engpässe wie Kommunikation und Privatsphäre zum Umdenken bringen:

Gibt es wirklich Hoffnung auf eine dezentrale Ausbildung großer Modelle?

Wenn Sie aus diesem Konsens, dem „vernünftigsten Landungsszenario“, herausspringen, ist die Frage, ob dezentrale Rechenleistung auf das Training kleiner KI-Modelle angewendet werden soll, ebenfalls ein großes Szenario. Aus technischer Sicht wurden die aktuellen limitierenden Faktoren aufgrund der Größe und Struktur des Modells gelöst. Gleichzeitig hatten wir aus Marktsicht immer das Gefühl, dass das Training großer Modelle enorm sein wird Jetzt in die Zukunft, aber der Markt für kleine KI-Modelle ist noch nicht attraktiv?

Das glaube ich nicht. Im Vergleich zu großen Modellen sind kleine KI-Modelle einfacher bereitzustellen und zu verwalten und hinsichtlich Verarbeitungsgeschwindigkeit und Speichernutzung effizienter. In einer Vielzahl von Anwendungsszenarien benötigen Benutzer oder Unternehmen nicht die allgemeineren Argumentationsfähigkeiten großer Sprachen Modelle, aber nur Fokus auf ein sehr granulares Prognoseziel. Daher sind kleine KI-Modelle in den meisten Szenarien immer noch die praktikablere Option und sollten im Strom der zunehmenden großen Modelle nicht vorschnell außer Acht gelassen werden. Referenz