Riesige Sprachmodelle sind meist nicht öffentlich verfügbar oder replizierbar. Meta will das mit OPT ändern und gute Qualität liefern.

Ein großes Forschungsteam der KI-Abteilung des Facebook-Mutterkonzerns Meta hat die Open-Pre-trained-Transformer-Sprachmodelle (OPT) in einer wissenschaftlichen Abhandlung vorgestellt. Das dabei wohl wichtigste Anliegen der Beteiligten ist es, ein modernes und großes Sprachmodell zu erstellen, das, anders als bisher meist üblich, komplett zur Verfügung gestellt wird, um die die konkreten Einzelheiten untersuchen zu können.

Das Team von Meta vergleicht das Sprachmodell selbst in Bezug auf Ziel, Fähigkeiten und Größe mit GPT-3 von OpenAI. Letzteres steht zwar zur Nutzung zur Verfügung, jedoch nur über eine API. Eine Untersuchung der inneren Abläufe und Gewichtungen ist so für Dritte nicht möglich. Im Vergleich zu GPT-3 soll die größte Variante von OPT mit 175 Milliarden Parametern außerdem nur ein Siebentel des CO2-Fußabdrucks aufweisen.

Ziel der Entwicklung sei es, “reproduzierbare und verantwortungsvolle Forschung in großem Maßstab zu ermöglichen”. Ebenso sollen die Auswirkungen dieser riesigen Sprachmodelle besser untersucht werden können. Dazu heißt es weiter: “Die Definitionen von Risiko, Schaden, Verzerrung, Toxizität usw. sollten von der gesamten Forschungsgemeinschaft formuliert werden, was nur möglich ist, wenn Modelle zur Untersuchung bereitstehen.”

Konkret geplant ist nun von Meta, dass die OPT-Modelle mit einer Parametergröße von 125 Millionen bis 30 Milliarden frei zur Verfügung gestellt werden. Der Zugriff auf das Modell mit 175 Milliarden Parametern soll auf Anfrage für Forschungsteams ermöglicht werden. Das gelte für Regierungen, Zivilgesellschaft, Wissenschaft sowie Industrieteilnehmer. Ebenso frei veröffentlicht werden soll das Team-eigene Logbuch, das beim Erstellen des Modells geführt wurde, sowie der Code, mit dem das Modell erstellt wurde.

Der Beitrag KI: Meta will GPT-3-Alternative öffentlich bereitstellen erschien zuerst auf Linux-Magazin.

Ein Ausfall von Slack im Februar resultierte aus einem kaskadierenden Fehler, den das Team aufgrund der Komplexität nur schwer beheben konnte.

In seinem Engineering-Blog beschreibt ein Technikteam des Messengerdienstes Slack Ursachen und Fehlerbehebung eines Ausfalls im vergangenen Februar. Dabei hält das Team schon zu Beginn eine wohl eher unbequeme Erkenntnis fest: “Dieser Vorfall war ein Paradebeispiel für ein komplexes Systemversagen: Es gab eine Reihe von Faktoren, die dazu beitrugen, und ein Teil des Vorfalls bestand aus einem kaskadenartigen Fehlerszenario.”

Der Ausfall des Systems machte sich dem Beitrag zufolge dadurch bemerkbar, dass Nutzer Probleme damit hatten, sich am Morgen (US-Zeitzonen) mit dem Messenger zu verbinden. Unabhängig davon erhielt das Team automatische Fehlermeldungen des Alarmsystems.

Die Probleme zeigten sich laut dem Blogpost an der Technik durch einen deutlichen Anstieg der Last der Datenbanksystemen. Das Team schreibt: “Was anfangs nicht klar war, war die Frage, warum die Datenbank so stark belastet wurde (..) und wie wir zu einem normalen Betriebszustand gelangen konnten.” Lösen konnte das Slack demnach nur durch eine größere interne Kooperation unter Beteiligung mehrerer Teams.

Die zunächst naheliegende Lösung, zur Lastvermeidung die Anzahl neuer Clients zu reduzieren, die sich mit neu mit dem System verbanden, und anschließend diese Zahl wieder langsam zu erhöhen, hatte aber nicht den erhofften Erfolg. Das Team war offenbar schlicht zu ungeduldig und erzeugte zu schnell wieder zu viel Last, ohne den zugrunde liegenden Fehler zu beheben.

Zur Ursachensuche schreibt das Team: “Wie kam es dazu, dass wir von einem stabilen Auslieferungszustand in einen Zustand der Überlastung gerieten? Die Antwort lag in den komplexen Interaktionen zwischen unserer Anwendung, den Vitess-Datenspeichern, dem Caching-System und unserem Service Discovery System.” Bei Vitess handelt es sich um ein Datenbank-Cluster-System für MySQL, das gestartet wurde, um die Skalierungsprobleme von Youtube zu lösen.

Ausgangspunkt war den Angaben zufolge ein Upgrade von Consul, das für Service Discovery genutzt wird. Wie schon mehrfach zuvor sollten dabei nur 25 Prozent der Server aktualisiert werden. Das hatte zwar zuvor geklappt, zusammen mit einer gestiegenen Last durch die Clients führte es aber letztlich am Tag des Ausfalls von Slack zu bisher unbekannten Problemen.

Mit den Upgrades von Consul wurden nach und nach die davon überwachten Cache-Knoten offline genommen. Die Automatisierung von Slack startete dann zwar ersatzweise neue Knoten mit Memcached, letztlich führte der Updateprozess aber dazu, dass sich die Cache Hit Rate immer stärker verringerte.

Da die Abfragen im Cache nicht erfolgreich waren, wurden die eigentlichen Datenbanken verstärkt angefragt, die aufgrund einer spezifischen Anfrage und der Verteilung der angefragten Daten im System immer mehr unter Last gerieten. Dazu schreibt das Team: “Die Datenbank war überfordert, da die Leselast im Verhältnis zum Prozentsatz der Cache Misses superlinear anstieg.” Die Systeme erreichten laut Slack schließlich einen Kipppunkt, ab dem sich der Fehler selbst weiter verstärkte.

Das Team reduzierte zum Beheben der Probleme zunächst die Anzahl sich verbindender Clients, verbesserte die ineffiziente Datenbankabfrage, um nur noch jene Daten zu lesen, die tatsächlich im Cache fehlten, und die Datenbank-Replicas wurden als Systeme zum Lesezugriff bereitgestellt. Letztlich konnte der Cache so wieder aufgefüllt werden, bis alle Clients ihre Daten wieder daraus erhalten konnten.

Der Beitrag Slack erklärt “Paradebeispiel für komplexes Systemversagen” erschien zuerst auf Linux-Magazin.