스크립트
00:00:00Reviewer: Denise RQ
00:00:12Alles klar.
00:00:14Ich glaube, ihr könnt mich alle hören.
00:00:15Ich kann mich jedenfalls hören.
00:00:19Wer am nächsten dran war, bekommt ein T-Shirt.
00:00:21Das war mein Ernst.
00:00:22Hier drüben steht nämlich eine Tasche voller T-Shirts.
00:00:25Und auch für Fragen.
00:00:26Vielleicht gibt es am Ende noch ein paar Fragen.
00:00:28Wenn ihr eine Frage stellt, bekommt ihr ebenfalls ein T-Shirt.
00:00:31Und wenn ihr erraten könnt, was im Hintergrund dieser Folie zu sehen ist,
00:00:35bekommt ihr auch ein T-Shirt.
00:00:39Irgendwelche Vermutungen?
00:00:42Was stellt das dar?
00:00:44Dieses Bild im Hintergrund.
00:00:49Niemand?
00:00:50Hat schon mal jemand ein Transformer-Modell gesehen?
00:00:55Ja, Positionskodierung.
00:00:57Sehr gut.
00:00:58Sie bekommen das T-Shirt, der Herr.
00:00:59Alles klar.
00:01:00Heute sprechen wir also im Grunde über kleine Open-Source-Modelle, wie gut sie mittlerweile sind und welche einzigartigen Herausforderungen sie mit sich bringen, wenn man eine ganze Reihe davon in der eigenen Cloud bereitstellen möchte.
00:01:15Alles, was wir besprechen, ist quasi Open Source.
00:01:19Selbermachen.
00:01:20Das ist die Art von Zeug, wo man einfach einen Befehl ausführt und die volle Kontrolle über den Stack hat.
00:01:26Es gibt hier also keine proprietären Puzzleteile.
00:01:31Lassen Sie uns also anfangen.
00:01:33Okay.
00:01:34Okay.
00:01:35Das funktioniert.
00:01:36Okay.
00:01:37Kleine Modelle also.
00:01:38Was verstehen wir unter kleinen Modellen?
00:01:40Je nachdem, wen man fragt – für mich sind das im Grunde Modelle, die man auf zwei bis drei Generationen alter NVIDIA-Hardware ausführen kann.
00:01:49Das gesamte Modell passt auf eine einzige GPU und ist daher einfach bereitzustellen.
00:01:56Diese GPUs sind verfügbar und zudem erschwinglich.
00:02:01Die meisten Leute denken dann: Bei kleinen Modellen muss man wohl Kompromisse bei der Qualität der Ergebnisse eingehen.
00:02:10Und hoffentlich gelingt es mir in diesem Vortrag, Sie davon zu überzeugen, dass man bei spezifischen Aufgaben tatsächlich auf oder sogar über dem Spitzenniveau liegen kann – und dazu alle offensichtlichen Vorteile nutzt.
00:02:22Enorme Kosteneinsparungen um mehrere Größenordnungen und potenziell erhebliche Verbesserungen bei Latenz und Durchsatz natürlich.
00:02:35Das ist eines der Diagramme, die wir gerne zeigen.
00:02:38Das ist der Artificial Analysis Intelligence Index im Zeitverlauf.
00:02:42Was man dort meistens nicht sieht, ist eine Aufschlüsselung der Open-Source-Modelle, die man berücksichtigen sollte, oder?
00:02:49Da gibt es GLM 5.2 und so weiter, diese Spitzen-Open-Source-Modelle mit sagen wir 750 Milliarden Parametern.
00:02:57Aber dann gibt es die kleinen Open-Source-Modelle, die den großen und den Spitzenmodellen dicht auf den Fersen sind.
00:03:04Man sieht, dass die Spitzenmodelle heutzutage an einen Punkt nachlassenden Ertrags gelangen, während die kleinen Modelle aufholen, nicht wahr?
00:03:10Man sieht also diese Konvergenz und Sättigung an der Spitze und das Wachstum bei den kleinen Modellen.
00:03:16Und sagen wir, Qwen 36 27B liegt leistungsmäßig etwa auf dem Niveau von GPT 5.1.
00:03:23Wenn Sie also einen Workflow oder eine Pipeline haben, die mit GPT 5.1 läuft,
00:03:29können Sie das jetzt auf ein kleines Modell übertragen und all die besprochenen Vorteile nutzen.
00:03:35Kleine Modelle sind also keineswegs abgeschrieben.
00:03:38Es kommt nun auch darauf an, wie man diese kleinen Modelle einsetzt.
00:03:44Man kann dieses Qwen 36 mit 27 Milliarden Parametern nicht einfach als völlig verallgemeinertes Allzweckmodell betrachten.
00:03:53Nein, man muss den Ansatz wählen, bei dem man gezielt einzelne Teilaufgaben aus der allgemeinen Arbeitslast herauslöst.
00:04:00Und dann ermittelt man pro Aufgabe, welches Open-Source-Modell am besten dazu passt.
00:04:05Man führt Evaluierungen durch, vielleicht Anpassungen, über die wir noch sprechen.
00:04:08Und so erreicht man schließlich die richtige Qualität, um das Ganze produktiv einzusetzen.
00:04:15Hier ist ein Beispiel für einen Vertragsprüfungs-Agenten, der neun verschiedene Modelle nutzt.
00:04:20Das ist genau die Struktur, die Sie in Ihren Systemen und Agenten sehen werden, wenn Sie kleine Modelle nutzen.
00:04:28Sie werden merken: Anstatt eine einzige API oder ein einziges Modell mit vielen verschiedenen Anfragen zu belasten,
00:04:36nutzt man lieber eine ganze Flotte von Modellen.
00:04:38Und dann steht man vor der Frage: Wie stellt man das alles bereit, ohne dass das Infra-Team durchdreht?
00:04:45Und das ist nur einer der Agenten, die bei Ihnen laufen könnten.
00:04:48Es könnte in Ihrem Unternehmen 10 davon geben.
00:04:51Wie bewältigt man also diese Erweiterung des Infrastruktur-Umfangs?
00:04:57Für all diese verschiedenen Aufgaben gibt es bereits ein Open-Source-Modell, das nur darauf wartet, genutzt zu werden.
00:05:05Von OCR über Fragenbeantwortung auf Dokumenten bis hin zur Bildbeschriftung, SQL-Generierung oder Code-Review.
00:05:14Es gibt speziell für diese Aufgaben feineingestellte und trainierte Open-Source-Modelle.
00:05:19Wenn Sie ein Open-Source-Modell nutzen, das für OCR auf vietnamesischen Belegen trainiert wurde, hat dieses Projekt die meisten vietnamesischen Belege gesehen.
00:05:28Da hat sich jemand die Zeit genommen, so viele Daten wie möglich zu sammeln.
00:05:32Und bei dieser speziellen Aufgabe wird dieses Modell fast alles andere übertreffen.
00:05:35Und es gibt Hunderte von Tausenden solcher Modelle auf Hugging Face, die genau so sind.
00:05:41Es ist also alles da und im Grunde kostenlos, meist mit sehr großzügigen Lizenzen.
00:05:46Die Modelle existieren bereits, das ist also nicht der Engpass.
00:05:50Und wir sprechen schon seit 2024 über Open-Source-KI.
00:05:56Aber so richtig setzt es sich noch immer nicht durch.
00:05:59Und soweit es in Unternehmen genutzt wird, bedeutet Open-Source-KI im Grunde meist AWS Bedrock.
00:06:05Sieht man sich jedoch den Modellkatalog in Bedrock an, ist die Auswahl an verfügbaren Modelltypen sehr eingeschränkt.
00:06:14Diese Modelle sind oft alt, manchmal zwei, drei Jahre hinter dem aktuellen Stand der Technik.
00:06:19Und wenn man Fine-Tuning in Bedrock betreibt, besitzt man die feineingestellten Artefakte am Ende gar nicht selbst.
00:06:25Man kann es also nicht als echten Wettbewerbsvorteil für sein Unternehmen nutzen.
00:06:29Es verbleibt im Hosting der Bedrock-Infrastruktur.
00:06:32Wenn man nun kleine Modelle auf Open-Source-Infrastrukturen wie vLLM, SGLang oder anderen Lösungen bereitstellt,
00:06:41muss man wissen, dass diese nicht für ein bestimmtes Modell oder eine bestimmte Hardware-Kombination optimiert sind.
00:06:48Die Optimierung muss man selbst übernehmen. Das ist das Prinzip Selbermachen.
00:06:51Alle diese Tools werden mit Anleitungen geliefert, wie man das Tuning, den Parametersweep und die Anpassung an den Traffic durchführt.
00:07:00Das ist jedes Mal wie ein ergebnisoffenes Forschungsprojekt, wenn man eines dieser Tools einführen möchte.
00:07:05Es ist also nicht so, dass man es einfach nimmt wie ein normales Softwareprojekt,
00:07:10und eine Woche später hat man eine hochperformante Bereitstellungsinfrastruktur.
00:07:14So funktioniert das leider nicht.
00:07:15Und das ist das typische Problem bei Open-Source-Tools, oder?
00:07:19Es ist einfach etwas zu viel Eigenarbeit erforderlich.
00:07:21Dazu kommt: Diese Tools sind nicht für kleine Modelle optimiert, und der Traffic bei kleinen Modellen, die viele verschiedene Modelle nutzen,
00:07:32stellt die Logik für Inferenz-Cluster gewissermaßen auf den Kopf.
00:07:37Wenn man ein einzelnes großes Modell bereitstellen will, lautet die Frage: Wie verteile ich dieses Modell auf mehrere GPUs?
00:07:44Wie schalte ich einen Router vor, der den Zustand aller Worker kennt, also den Zustand des KV-Caches und so weiter,
00:07:51und dann eine Top-Down-Routing-Entscheidung trifft, dass diese Anfrage an diesen Worker oder diese Worker-Gruppe geht?
00:07:59Das ist ein sehr zentralisiertes Top-Down-Setup.
00:08:01Aber wenn man viele kleine, schnelle Anfragen hat, wird genau dieses Top-Down-Routing zum Nadelöhr.
00:08:09Denn der Router hat nur einen veralteten Zustand der Worker, und es ist extrem schwer, die Worker auszulasten,
00:08:16wenn man vorab eine Entscheidung treffen muss, die die lokalen Warteschlangen auf jedem Worker perfekt ausbalancieren soll.
00:08:26Es gibt schließlich viele kleine Anfragen.
00:08:29Wir haben mit den Routern von vLLM und SGLang für kleine Modelle und diese Art von Traffic experimentiert,
00:08:37und es ist sehr schwer, die GPU-Auslastung unter Dauerlast über 20 bis 30 % zu bekommen.
00:08:44Das Problem liegt darin, dass die Batches schlichtweg falsch dimensioniert sind, weil dieser Engpass im Routing besteht.
00:08:51Das dritte Problem ist, dass man bei kleinen Modellen stark von LoRA und allgemeiner Modellanpassung profitiert.
00:08:57Der Traffic, den man bedienen muss, beinhaltet also Anfragen von Leuten, die sagen:
00:09:03„Hey, ich habe 10 LoRAs. Wie nutze ich die mit unserem Serving-Stack?“
00:09:08Oder: „Ich habe dieses angepasste Modell gestern Nacht trainiert und möchte es jetzt in Produktion bringen.“
00:09:14Und dieser Abstimmungsbedarf zwischen dem KI-Entwickler und dem Infrastruktur-Team, um diese LoRAs
00:09:21und angepassten Modelle bereitzustellen, kostet enorm viel Zeit.
00:09:24Im Grunde ist die ständige Absprache der Hauptbremser für die Geschwindigkeit einer Organisation.
00:09:30Idealerweise sollten die Infrastruktur-Ingenieure und die KI-Entwickler jeweils ungestört ihre Arbeit machen können.
00:09:37Sie sollten im Tagesgeschäft nicht ständig miteinander Rücksprache halten müssen.
00:09:41Sodass sie sich im Grunde nicht gegenseitig blockieren.
00:09:45Und dieser Wunsch nach ständiger Modellanpassung bei kleinen Modellen durchbricht das und sorgt für viel Abstimmungsaufwand.
00:09:51Und das ist ein Problem, richtig?
00:09:54Das sind also einige Herausforderungen im Zusammenhang mit: Okay, wir haben eine Reihe kleiner Modelle.
00:09:58Wie bauen wir einen Cluster auf? Wie stellen wir das effizient bereit?
00:10:02Wir beschäftigen uns schon seit Weile mit diesem Problem.
00:10:05Ich bin übrigens Daniel von Superlinked, ich habe die Vorstellung vorhin übersprungen.
00:10:09Wir sind also ein VC-finanziertes Unternehmen aus San Francisco.
00:10:13Und wir haben in den letzten zwei Jahren KI-gestützte Such- und Dokumentenverarbeitungssysteme und Agenten entwickelt.
00:10:20Unser Hauptschmerzpunkt war dabei immer die Inferenz, speziell die Probleme, die ich beschrieben habe.
00:10:26Wir haben also immer wieder iteriert und verschiedene Topologien für Cluster erkundet, um riesige Flotten kleiner Modelle in unterschiedlichen Umgebungen auszuführen.
00:10:37Weil man manchmal zusammen mit einer Plattform in einer Umgebung bereitstellen muss, in der wer weiß was verfügbar ist.
00:10:44Kleine Modelle erleichtern das, weil es in jeder Umgebung viel einfacher ist, ein paar L4s oder ein kleines GPU-Kontingent zu bekommen.
00:10:52Ich werde also ein wenig die Topologie des Clusters beschreiben, auf die wir uns schließlich geeinigt haben.
00:10:58Übrigens ist das Ganze Apache 2.0, komplett Open Source.
00:11:03Ihr könnt das einfach nehmen, verpacken und seid ab sofort ein Inferenz-Startup.
00:11:08Das ist Open Source, von der Control Plane bis hin zu dem Teil, der auf der GPU läuft.
00:11:14Wir haben also wirklich nichts zurückgehalten.
00:11:18Und die Topologie sieht im Grunde so aus, dass es ein Gateway gibt.
00:11:21Statt eines Routers, der vorab entscheidet, was wohin geht, gibt es ein Gateway, das Anfragen parst und ihnen Metadaten hinzufügt.
00:11:30Es fügt diese Anfrage in eine gemeinsame Warteschlange und in einige Seitenkanäle ein.
00:11:36Ich gehe gleich noch etwas genauer darauf ein.
00:11:37Und dann holen sich die Worker die Anfragen aus dieser zentralen Warteschlange, anstatt dass man die Daten zu den Workern pusht.
00:11:44Auf diese Weise können sie sich selbst besser auslasten.
00:11:47Und das Worker-Setup – ich glaube, ich habe dafür eine Folie – beschreibt, wie wir im Grunde die Komplexität verschiedener Modellarchitekturen abfangen,
00:11:57und zwar in einer kohärenten Gruppe von Workern, die keine konkurrierenden Python-Anforderungen und Ähnliches haben.
00:12:03Das ist also etwa die Gesamttopologie.
00:12:06Und das hier ist sozusagen der Lebenszyklus einer Anfrage.
00:12:11Dazu möchte ich vielleicht ein paar Dinge hervorheben.
00:12:15Was wir am OpenAI-API-Standard nicht mögen, ist das base64-kodierte JSON.
00:12:25Nicht gut für kleine Modelle, nicht gut für hohen Durchsatz.
00:12:28Wir nutzen daher durchgehend MessagePack, ein binäres Format.
00:12:31Auf diese Weise können wir auch alle multimodalen Daten durch das eigentliche API-Gateway leiten.
00:12:37Es gibt also kein: „Hier drüben sind Binärdaten und dort drüben die Anfrage.“
00:12:42Und der Cluster braucht dann Zugriff auf Ihren Cloud-Speicher, um Binärdaten, Bilder oder Videos zu laden.
00:12:48Wir kodieren das alles und leiten es durch das Gateway.
00:12:53Das Gateway trennt dann einige dieser schwereren Teile ab, um die interne Queue nicht zu verstopfen, und lagert sie während des Wartens in der Queue im Cloud-Speicher aus.
00:13:02Es teilt also Anfragen auf, die sagen wir größer als ein Megabyte sind, und nutzt im Hintergrund den Cloud-Speicher.
00:13:09Aber als Benutzer übertragen Sie all Ihre Bits und Bytes in die API-Schicht, was es zu einer sehr sauberen Schnittstelle macht.
00:13:19Der gesamte Stack ist im Grunde REST, also Gateway REST, Worker REST, und verbindet sich lokal über einen Socket mit verschiedenen Laufzeitumgebungen.
00:13:30Und wir nutzen im Grunde PyTorch, Candle und SGLang als Runtimes.
00:13:35Wenn wir die Optimierung vornehmen, gehe ich darauf ein, wie wir sicherstellen, dass die genutzte Runtime
00:13:43und der darin laufende Code auch wirklich am effizientesten sind.
00:13:47Dafür haben wir im Grunde eine automatisierte Research-Schleife.
00:13:50Aber ja, der Lebenszyklus einer Anfrage sieht ungefähr so aus.
00:13:54Ein Detail ist, dass man sicherstellen muss, dass das Gateway als erster Anlaufpunkt der Anfrage nicht zu viel Arbeit erledigt.
00:14:05Weil es sonst zum Flaschenhals wird, richtig?
00:14:07Man möchte also nicht einmal die gesamte Anfrage parsen.
00:14:09Man möchte die Pakete betrachten, die allgemeine Struktur erkennen, die Anmerkung machen
00:14:16und dann schauen die Worker, egal wie viele Hunderte von GPUs da sind, auf den Queue-Status und bedienen sich dort.
00:14:25Und die Warteschlange nutzt NATS JetStream, das eine Million Anfragen pro Sekunde verarbeiten kann.
00:14:32Es ist also sehr unwahrscheinlich, dass das zum Engpass wird.
00:14:35Ja, idealerweise möchte man nicht ständig serialisieren und deserialisieren, während man diese Komponenten durchläuft.
00:14:42Das ist im Grunde der offensichtliche Punkt.
00:14:45Dies ist eine kleine Animation, die die Idee hinter der zentralen Warteschlange zeigt, richtig?
00:14:51Anstatt dass ein Top-down-Router versucht, die lokalen Queues perfekt zu füllen, was im Grunde unmöglich ist,
00:15:01ist die Grundidee: Können wir die Warteschlange zentralisieren, sodass die Worker selbst ihre Batches zusammenstellen,
00:15:09basierend auf ihrer eigenen Schätzung der Batch-Kosten, um dadurch viel effizienter zu werden?
00:15:15Ein kleines Detail am Rande: Sobald man daran arbeitet, merkt man, dass es schwer ist einzuschätzen, wie viele Elemente aus der Queue geholt werden müssen, damit die Batch-Größe wirklich optimal ist.
00:15:30Man braucht also einen Mechanismus, der es erlaubt, einige Elemente wieder in die Warteschlange zurückzulegen,
00:15:35wenn man merkt: „Oh, ich habe etwas zu viel geholt.“
00:15:37Das bedeutet allerdings einen Netzwerk-Hop, richtig?
00:15:39Das ist also ein Problem.
00:15:40Und dafür haben wir eine spezielle Optimierung für Maschinen mit mehreren lokalen GPUs.
00:15:46Es gibt ein lokales Queueing-Element auf der Maschine, das nutzt, dass lokale Prozesse auf mehreren GPUs einer Maschine etwas flexibler mit der Queue verhandeln können,
00:15:59was über das Netzwerk zusätzliche Millisekunden kosten würde.
00:16:03Wir machen das also nicht über das Netzwerk, sondern nur, wenn die Worker auf Multi-GPU-Maschinen zusammengelegt sind.
00:16:11Und wir sprechen hier nicht von 5 % Unterschied, richtig?
00:16:16Man zentralisiert die Queue und verdoppelt damit den Durchsatz des Clusters.
00:16:19Das ist also erheblich.
00:16:22Ich habe drei verschiedene Runtimes erwähnt.
00:16:25Für Modelle, die reine Encoder sind, schreiben wir beispielsweise den PyTorch-Code selbst.
00:16:33Wir optimieren ihn und haben dafür eine automatisierte Research-Schleife.
00:16:38Das Gleiche gilt für Candle.
00:16:39Wir haben vor Kurzem angefangen, mit Candle zu experimentieren.
00:16:42Wir erreichen damit aber noch lange nicht die Leistung von PyTorch.
00:16:45Es ist also eher noch ein Forschungsprojekt.
00:16:47Es liegt an der Abhängigkeit: Das Worker-Docker-Image mit PyTorch ist etwa 12 Gigabyte groß.
00:16:54Eine statisch verlinkte Binary mit Candle macht davon vielleicht 10 % aus, richtig?
00:17:01Wenn es darauf ankommt, aus dem Cold State aufzuwachen und diese Images auf vielen Maschinen zu laden,
00:17:08macht die Reduzierung von 12 Gigabyte auf etwa ein Gigabyte einen riesigen Unterschied.
00:17:13Das ist also die Motivation hinter Candle.
00:17:15Es ist nur wirklich schwer, dieselbe Leistung wie mit PyTorch zu erzielen.
00:17:20Und SGLang nutzen wir sozusagen als bewährte Baseline.
00:17:25Wir sollten mindestens so gut wie SGLang sein, wenn alle von mir erwähnten Parameter optimal abgestimmt sind.
00:17:34Hier sind einige Zahlen.
00:17:37Wenn wir SGLang mit dem Socket und unserem Rust-Sidecar umschließen,
00:17:43können wir die Leistung des reinen SGLang verbessern, weil wir beim Batching Optimierungen vornehmen, die SGLang nativ nicht bietet.
00:17:54Vermutlich könnte man es dazu bringen.
00:17:57Wenn man benutzerdefinierte Plugins für SGLang entwickelt,
00:18:00könnte man wahrscheinlich unsere Leistung erreichen, denn
00:18:04man kann dieselbe Logik einfach in den SGLang-Core-Server integrieren.
00:18:07Aber dann entwickelt man maßgeschneiderten Code, der nur mit SGLang funktioniert.
00:18:11Die Lektion bei kleinen Modellen ist, dass die Runtimes enorm vielfältig sind, richtig?
00:18:16Man möchte sich nicht unbedingt auf eine bestimmte Runtime festlegen, denn
00:18:22wir haben mittlerweile schätzungsweise 50 verschiedene Adapter, die wir für unterschiedliche Modelle parametrisieren.
00:18:28Man muss also irgendwie mit dieser zugrunde liegenden Komplexität umgehen.
00:18:32Und das geht eher nicht, indem man eine Reihe von Plugins für eine spezifische Runtime baut.
00:18:36Es braucht eine Abstraktion, was in unserem Fall das Rust-Sidecar-Konzept und der Socket ist.
00:18:47Ich werde nun über ein paar Kennzahlen sprechen, aber was die Terminologie beim Benchmarking angeht:
00:18:53Der Sättigungspunkt beschreibt das Phänomen, wenn man die Last auf den Server erhöht,
00:18:57wenn man also immer mehr Durchsatz von ihm fordert
00:19:01und er mehr Durchsatz liefert, steigt die Kurve zunächst linear an.
00:19:05Irgendwann erreicht man jedoch den Punkt, an dem mehr Anfragen nicht mehr Leistung bringen.
00:19:09Die Kurve flacht ab und die Latenz steigt.
00:19:12Wir nennen das den Knickpunkt, ein nützliches Konzept beim Benchmarking,
00:19:17weil es genau den Punkt der Sättigung markiert, richtig?
00:19:20Das ist die maximale Leistung, ohne dass die Latenz leidet.
00:19:23Um Ihnen eine Vorstellung zu geben, was auf relativ kleiner Hardware möglich ist,
00:19:32und das mit verschiedenen Typen kleiner Modelle:
00:19:34Das hier wurde auf der RTX Pro 6000 gemessen.
00:19:37Wir arbeiten mit NVIDIA L4, A100s, RTX Pro 6000, H100 – in dieser Kategorie.
00:19:46Diese GPUs sind im Grunde auf Abruf in fast jeder Cloud viel leichter verfügbar.
00:19:52Auf den meisten Kontinenten gibt es dafür Kontingente.
00:19:56Und auf dieser Hardware kann man für Embedding-Modelle,
00:20:01selbst bei bis zu Hunderten Millionen von Parametern,
00:20:05Hunderttausende Token pro Sekunde in Embeddings umwandeln, richtig?
00:20:12Stellen Sie sich also vor, Sie sitzen da und stellen Anfragen an den Text-Embedding-Tree der OpenAI-API.
00:20:17Stattdessen könnten Sie eine einzige GPU nutzen, eine halbe Million Token pro Sekunde durchjagen und die Vektoren herausbekommen.
00:20:26Richtig?
00:20:28Verstehen Sie, worauf ich hinauswill?
00:20:31Sie schicken pro Sekunde eine halbe Million Token durch eine einzelne GPU, die nicht einmal besonders groß ist,
00:20:38um Vektor-Embeddings für Ihr Suchsystem zu erhalten – anstatt all das an einen verwalteten Embedding-Endpunkt zu senden und um Größenordnungen mehr Geld zu bezahlen.
00:20:49Richtig?
00:20:50Und Sie können Latenzen von nur wenigen Dutzend Millisekunden für diese Aufrufe erreichen.
00:20:55Wenn Sie APIs von Cohere, OpenAI usw. nutzen, liegen diese bei mehreren hundert Millisekunden.
00:21:02Und das ist keine Raketenwissenschaft.
00:21:03Sie können gewaltige Kosten einsparen, die Latenz massiv verbessern und das Ganze mit einer Handvoll GPUs und etwas Infrastruktur drumherum relativ einfach betreiben.
00:21:17Das sind also wirklich schnell erreichbare Vorteile. Wenn Sie irgendwo mit Open-Source- oder kleinen Modellen anfangen, sind Embeddings ein absoluter Selbstläufer.
00:21:26Aber damit hört es nicht auf.
00:21:27Sagen wir etwa, Sie möchten sich Named Entity Recognition ansehen.
00:21:33Oder Multi-Vector-Suche, oder sogar die Generierung von Texten oder strukturierten Ausgaben.
00:21:42Sie können Tausende von Token pro Sekunde von aufgabenspezifischen generativen Modellen ausgeben lassen, wie etwa fünfhundert pro Sekunde bei einer GPU ganz unten.
00:21:58Wenn Sie also synthetische Daten generieren oder Anmerkungen für Ihr Finetuning oder Ihre Evaluierungen erstellen, nutzen Sie dafür keinen verwalteten Endpunkt.
00:22:11Das ist eine perfekte Aufgabe, weil Sie sie gut unter Kontrolle haben.
00:22:14Sie können die Qualität überwachen.
00:22:16Perfekt für ein Open-Source-Modell auf Ihrer eigenen Infrastruktur.
00:22:20Und wenn die Infrastruktur um diese GPUs herum vernünftig aufgebaut ist, skalieren Sie linear mit der Anzahl der GPUs.
00:22:31Ein weiterer Gedanke beim Bereitstellen kleiner Modelle ist: Normalerweise hat man einen Worker-Pool pro Modell, richtig?
00:22:44Man hat eine Reihe von Workern und Nodes mit GPUs, fährt sie hoch und lädt die Modelle vor.
00:22:51Die Modelle brauchen zig Minuten zum Laden, weil sie Hunderte Milliarden Parameter haben.
00:22:55Und dann ist man froh: Okay, sie sind endlich geladen, jetzt habe ich meinen Worker-Pool.
00:22:59Diese Denkweise funktioniert bei kleinen Modellen nicht wirklich.
00:23:02Ja, ja, kurz noch.
00:23:04Wie viel Zeit bleibt noch?
00:23:06Sechs Minuten über der Zeit.
00:23:07Oh, sechs Minuten drüber.
00:23:08Alles klar.
00:23:09Gut.
00:23:10Modelle auf derselben GPU zu bündeln, ist also schneller.
00:23:12Es geht darum, dass man einige Modelle fest verankern möchte, aber auch Lazy Loading und Eviction abhängig von der Speicherauslastung nutzen sollte.
00:23:26Man muss herausfinden, wie man beides kombiniert.
00:23:28Hier ist noch ein wenig über automatische Forschung.
00:23:32Wir haben Auto-Research-Schleifen, um die Unterstützung neuer Modelle und deren Leistung zu verbessern.
00:23:39Wir bauen viele interne Tools für Messungen, die in diese Auto-Research-Schleifen einfließen, um die Zahlen nach vorne zu bringen.
00:23:47Und das Wichtigste: Wenn wir Support für ein Modell ausliefern, ist das Tuning bereits abgeschlossen.
00:23:53Es gibt also kein: “Lass uns erst mal die Parameter austesten.”
00:23:55Wir liefern im Grunde eine Konfiguration für den gesamten Cluster mit.
00:24:00Das ist das Setup für die Auto-Research-Schleife.
00:24:03Es gibt eine Meta-Schleife, die das Harness baut, das dann die Schleife ausführt.
00:24:08Und darüber liegt ein Dashboard, mit dem man versteht, wie es funktioniert.
00:24:12Dafür haben wir maßgeschneiderte Benutzeroberflächen.
00:24:15Eines der Ergebnisse war ein LoRA, dessen Training 80 Cent kostete und die Retrieval-Qualität bei deutscher Rechtssprache als Proof of Concept um 18 % steigerte.
00:24:27Und das war's.
00:24:29Kleine Modelle sind also gut.
00:24:30Sie sind relativ leicht bereitzustellen.
00:24:32Sie sind tatsächlich viel günstiger und schneller.
00:24:35Es ist schlau.
00:24:36Und dieser QR-Code führt zum GitHub-Repository unseres Clusters, den ich gerade beschrieben habe.
00:24:43Geben Sie uns einen Stern.
00:24:44Und viel Spaß beim Self-Hosting!
00:24:45Vielen Dank.
00:24:46Danke.
00:24:47Danke schön.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기