- Petals ermöglicht Textgenerierung und Fine-Tuning, ohne ein großes Sprachmodell vollständig auf ein einzelnes Gerät zu laden: Stattdessen wird nur ein Teil auf einer heimischen GPU oder in Google Colab ausgeführt
- Unterstützt Modelle bis Llama 3.1 mit 405B, Mixtral 8x22B, Falcon 40B+ und BLOOM 176B, sodass sich große Modelle auch mit persönlicher Hardware nutzen lassen
- Nutzer laden den von ihnen übernommenen Modell-Teil und verbinden sich dann mit einem Netzwerk von Teilnehmern, die die übrigen Teile bereitstellen – eine Struktur nach BitTorrent-Art
- Single-Batch-Inferenz erreicht bei Llama 2 70B bis zu 6 tokens/sec und bei Falcon 180B bis zu 4 tokens/sec, ausreichend für Chatbots und interaktive Apps
- Bietet mehr Auswahl bei Fine-Tuning- und Sampling-Methoden als übliche LLM-APIs und erlaubt den Zugriff auf interne Modellpfade sowie hidden states
Große Modelle verteilt ausführen
- Petals zielt darauf ab, große Sprachmodelle zu Hause auszuführen, und funktioniert so, dass mehrere Nutzer wie bei BitTorrent unterschiedliche Teile eines Modells bereitstellen
- Nutzer laden nicht das gesamte Modell, sondern nur einen Teil des Modells, und nehmen dann am Netzwerk teil, das die übrigen Teile bereitstellt
- Unterstützte Modelle:
- Llama 3.1: bis zu 405B
- Mixtral: 8x22B
- Falcon: 40B+
- BLOOM: 176B
- Mit einer heimischen GPU oder Google Colab lassen sich Textgenerierung und aufgabenspezifisches Fine-Tuning durchführen
- Leistung bei Single-Batch-Inferenz:
- Llama 2 70B: bis zu 6 tokens/sec
- Falcon 180B: bis zu 4 tokens/sec
- Diese Geschwindigkeit ist ausreichend für Chatbots und interaktive Apps
Mehr Kontrolle als mit APIs
- Petals erlaubt es, über klassische LLM-APIs hinaus Fine-Tuning und Sampling-Methoden direkt auszuwählen
- Es können benutzerdefinierte Pfade durch das Modell ausgeführt oder hidden states eingesehen werden
- Es verbindet den Komfort einer API mit der Flexibilität von PyTorch und 🤗 Transformers
- Es gibt ein sofort ausführbares Colab-Notebook sowie eine GitHub-Dokumentation
- Es gibt eine Anleitung zur Teilnahme, um durch das Bereitstellen einer GPU die Kapazität von Petals zu erhöhen; Entwicklungsneuigkeiten lassen sich auf Discord verfolgen
- Dieses Projekt ist Teil des BigScience Research Workshop
1 Kommentare
Meinungen auf Hacker News
Interessant. Es sieht so aus, als würden die Modellgewichte schichtweise auf mehrere Maschinen verteilt; jede Maschine registriert sich, sobald sie bereit ist, in einer großen Hash-Tabelle und führt dann für die ihr zugewiesenen Schichten „im Team“ Inferenz oder Fine-Tuning durch.
Das ist zwar noch in einem frühen Stadium, aber ich habe daran gearbeitet, Modellgewichte für https://github.com/jmorganca/ollama in einer Docker-Registry zu hosten. Der Hauptgrund ist Content Addressability: Ollama kann jedes Mal überprüfen, ob die richtigen Gewichte heruntergeladen wurden, und letztlich Gewichte anhand ihres Inhalts beziehen statt über Namen oder URLs, die sich ändern können.
Als nächster Schritt ließe sich ein Modell schichtweise aufteilen und jede Schicht unabhängig speichern, um es für solche Zwecke zu nutzen oder größere Modelle über mehrere „lokale“ Maschinen hinweg herunterzuladen und auszuführen.
In den HN-Guidelines steht auch, dass man „HN nicht primär für Promotion nutzen soll; es ist in Ordnung, gelegentlich eigene Arbeit zu posten, aber der Hauptzweck der Nutzung der Site sollte Neugier sein“.
Auch in diesem Fall hättest du über die Arbeit des OP sprechen können, ohne den kostenlosen Backlink zu deinem Projekt einzubauen.
Bei der Stelle „lässt sich für Aufgaben fine-tunen“ habe ich die Augenbrauen hochgezogen.
70B zu fine-tunen ist nicht einfach nur schwierig; selbst wenn man beliebig lange warten kann, ist es buchstäblich unmöglich, ohne sehr teure Cloud-Instanzen zu mieten oder einen PC zum Preis eines Hauses zu kaufen.
Wenn es eine „llama training horde“ gäbe, wäre ich gern dabei.
Soweit ich es verstehe, kann man ein Modell mit N Milliarden Parametern mit einer GPU fine-tunen, die etwas weniger als N Gigabyte VRAM hat.
Bei einem 70B-Parameter-Modell wäre das etwa eine A100?
Außerdem kann man bei Lambda Cloud ein 70B-Modell für 2 Dollar pro Million Tokens fine-tunen, bei Replicate für unter 10 Dollar.
Wenn man annimmt, dass ein LLM jedes Buch unabhängig lernt, wirkt es so, als könnte man einfach die beiden Deltas der LLM-Gewichte addieren.
Sind trainierte LLMs in irgendeiner Weise zusammensetzbar? Wenn sie zum Beispiel beide denselben Daten zu 99 % vertrauen und sich nur bei 1 % unterscheiden: Braucht man dann zwei vollständig getrennte Modelle, oder könnte man sich die Berechnung für die 99 %, bei denen man mit anderen gleicher Meinung ist, teilen und abgeleitete Modelle bauen, die die Unterschiede der jeweiligen Vertrauensmodelle korrigieren?
Mein Verständnis von neuronalen Netzen ist nur grundlegend, aber es wirkt nicht völlig absurd, Gewichte auf diese Weise zu manipulieren und dabei die Nützlichkeit des Modells zu erhalten.
Ich frage, weil es nützlich wäre zu wissen, bei welchen Aussagen zwei gleich leistungsfähige LLMs übereinstimmen und wo es disagreement gibt. Dann könnte man diese Unterschiede rückwärts auf Unterschiede in den Trainingsdaten abbilden. Das ginge wohl nur, wenn die Unterschiede klein sind.
Umgekehrt wäre es eine ziemlich andere Welt, wenn zwei gleich leistungsfähige LLMs eher eine verpasste Chance sind, ein stärkeres Modell zu bauen, und die Analyse von disagreement außerdem zu teuer ist.
Das bedeutet nicht Zusammensetzbarkeit in dem Sinne, dass man solche Adaptionsschichten beliebig nehmen und kombinieren kann, aber unterschiedliche Modelle auf einer gemeinsamen Gewichtsbasis zu trainieren ist bereits ein gelöstes Problem.
Wie verhindert man, dass ein böswilliger Teilnehmer seinen Anteil am Output einer größeren Berechnung verändert? Selbst wenn es keine Möglichkeit gibt, gezielt einen vom Angreifer bestimmten Netzwerkausgang zu erzeugen: Wenn viele Nodes beitreten und einfach Müll zurückgeben, scheint das System praktisch per Denial-of-Service angreifbar zu sein.
Außerdem kann ein Client Daten über mehrere, sich nicht überschneidende Pfade durch das Netzwerk schicken und prüfen, ob die Ergebnisse übereinstimmen.
Häufige Angreifer werden dadurch erkannt, aber es bietet keinen 100%igen Schutz. Wenn vollständige Korrektheitsgarantien nötig sind, werden Leute meiner Ansicht nach private Swarms bilden. Wenn man zum Beispiel nicht genug GPUs hat, um allein ein LLM zu betreiben, aber vertrauenswürdige Hardware-Besitzer kennt, kann man einen privaten Petals-Swarm aufsetzen und gemeinsam auf geografisch verteilter Hardware ein LLM ausführen und Daten verarbeiten.
Die erste Frage, die mir in den Sinn kam, war: Wie sieht es mit der Wirtschaftlichkeit aus? Laut FAQ:
Basieren die Petals-Anreize auf Kryptowährungen, Blockchain usw.? Nein. Petals ist in jeder anderen Hinsicht ein vollständig dezentrales System, aber bei den Anreizen arbeiten wir an einem zentralisierten System, ähnlich den AI-Horde-Kudos. Es ist nicht geplant, einen Dienst anzubieten, der diese Punkte in Geld umtauscht; man kann sie also als „Spiel“-Punkte innerhalb des Systems betrachten.
Petals ist ein auf Machine Learning ausgerichtetes Projekt für Machine-Learning-Forscher und -Ingenieure und hat nichts mit Finanzen zu tun. Der Grund, warum wir uns für ein zentralisiertes Anreizsystem entschieden haben, ist, dass es viel einfacher zu entwickeln und zu warten ist, sodass wir uns darauf konzentrieren können, Funktionen zu entwickeln, die für Machine-Learning-Forscher nützlich sind.
https://github.com/bigscience-workshop/petals/wiki/FAQ:-Freq...
https://lite.koboldai.net/
https://tinybots.net/artbot
https://aihorde.net/
Falls übrigens jemand auf HN ein bestimmtes feinabgestimmtes 13B- bis 70B-Modell testen möchte, könnte ich es am Nachmittag hosten:
https://huggingface.co/models?sort=modified&search=70B+gguf
https://www.sheepit-renderfarm.com/home
Weil das womöglich nicht für alle reicht, werden außerdem „bloom points“ eingeführt, ein expliziter Anreiz für Personen, die GPU-Zeit an den öffentlichen Swarm spenden. Sobald das System bereit ist, werden auf der Website die Top-Beitragenden angezeigt; wer Punkte gesammelt hat, kann sie für Inferenz und Fine-Tuning mit höherer Priorität oder stärkeren Sicherheitsgarantien nutzen oder vielleicht gegen andere Belohnungen eintauschen.
Trotzdem wirkt es so, als wolle man in gewissem Maß doch einen zentralisierten Token.
Zur Klarstellung: Ich meine nicht, dass der „Token“ von Petals an ein Zahlungssystem gekoppelt werden sollte. Ich meine allgemein, dass für Aufrufe von Machine-Learning-Modellclustern – unabhängig davon, ob sie dezentral sind oder nicht – wahrscheinlich Krypto-Zahlungen genutzt werden, weil sie zugleich Authentifizierung und Zahlungsmittel bereitstellen.
Petals ist eine gute Implementierung dezentraler Berechnung für die Modellnutzung und dürfte langfristig wertvoll sein.
Ich wollte meine 3080 Ti teilen, aber als ich den Befehl aus dem Getting-Started-Guide ausführte, schien es ein Problem mit den Dependency-Versionen zu geben: https://github.com/bigscience-workshop/petals/wiki/Run-Petal...
ImportError: cannot import name 'get_full_repo_name' from 'huggingface_hub' (~/.local/lib/python3.8/site-packages/huggingface_hub/__init__.py)Offenbar kann man einen eigenen Server-Swarm hosten [0].
Ich frage mich, wie ungefähr die Fine-Tuning-Performance eines „privaten“ Petals-Clusters aussieht.
[0] https://github.com/bigscience-workshop/petals/wiki/Launch-yo...
Wirklich cool. Ich hoffe, dass dadurch Tausende oder Millionen weitere Entwickler Zugang zu diesem Bereich bekommen.
Ich habe schon immer gedacht, dass Crowdsourcing die Zukunft ist. Egal ob es um Information oder Rechenleistung geht.
Die „Ressourcen“ sind eigentlich schon vorhanden; es ist nur eine Frage der Verteilung.
Ich habe Petals einmal in einem früheren Projekt verwendet. Ich habe auch eine GPU geteilt und Code für das Projekt geschrieben.
Der Petals-Teil war für mich abstrahiert, und die Erfahrung beim Schreiben des Codes war ganz normal.
Ich habe das Projekt nirgendwo veröffentlicht und weiß auch nicht wirklich, was später daraus geworden ist. Im Wesentlichen wurde es von etwa fünf Leuten vorangetrieben.