Moderne, verteilte ML verstehen: Von HPC-Schedulern bis zu LLM Serving Engines
Machine-Learning-Entwickler müssen heute mit vielen verschiedenen Tools und Konzepten arbeiten, um Modelle in großem Maßstab zu trainieren und bereitzustellen. Dieser Artikel befasst sich eingehend mit einigen wichtigen Themen: Jobs mit Deep Learning Containern (DLC) ausführen, HPC-Batch-Scheduler wie Volcano (VOLC) und SLURM verwenden, effizientes LLM-Serving mit vLLM und SGLang, typische Trainings-Frameworks und Parameter, Betriebsarten (Training vs. Inferenz), Parallelisierungsstrategien (DPTPPP – Daten-, Pipeline-, Tensorparallelismus), die Rolle von Routern und Controllern in verteilten Systemen und Datenladestrategien für hohen Durchsatz. Wir erklären jedes Konzept, geben Beispiele (mit Code- und Konfigurationsbeispielen) und bieten praktische Einblicke auf eine technische, präzise Art und Weise. Los geht's!
Deep Learning Container (DLC) und das Ausführen von ML-Jobs
Deep Learning Container (DLC) sind vorgefertigte Docker-Container-Images, die beliebte Deep-Learning-Frameworks und Abhängigkeiten enthalten, die optimiert und sofort einsatzbereit sind. AWS bietet beispielsweise DLCs für TensorFlow, PyTorch, MXNet usw. an, die optimierte Builds enthalten (oft mit GPU-Unterstützung, Bibliotheken wie CUDA/cuDNN installiert und sogar Netzwerkoptimierungen wie EFA für Multi-Node-Training). Diese Container gewährleisten eine konsistente Umgebung, sodass Forscher die Frameworks nicht manuell auf jedem Rechner installieren müssen. Laut AWS sind DLCs als Docker-Images in Amazon ECR (Elastic Container Registry) verfügbar, und jedes Image ist auf eine bestimmte Framework-Version und Aufgabe (Training oder Inferenz) zugeschnitten (Build high-performance ML models using PyTorch 2.0 on AWS – Part 1 | AWS Machine Learning Blog). Das bedeutet, dass Sie einen Container auswählen können, der Ihrem gewünschten Framework entspricht (z. B. PyTorch 2.0 mit CUDA 11), und sicher sein können, dass er alle richtigen Bibliotheken enthält.
So funktioniert es: In der Praxis beinhaltet die Verwendung eines DLC das Herunterladen des Container-Images und das Ausführen Ihres Trainings oder Ihrer Inferenz darin. Dies kann auf einer Cloud-VM oder einem On-Premise-Server mit installiertem Docker erfolgen. Zum Beispiel könnte man nach dem Starten einer EC2-GPU-Instanz Folgendes tun:
# Schritt 1: Melden Sie sich bei AWS ECR public an (falls erforderlich) und ziehen Sie das DLC-Image
aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin <aws_account>.dkr.ecr.us-west-2.amazonaws.com
docker pull <aws_account>.dkr.ecr.us-west-2.amazonaws.com/pytorch-training:2.0.0-gpu-py310-cu118-ubuntu20.04-ec2
# Schritt 2: Führen Sie den Container mit einem Trainingsskript aus
docker run --gpus all -v /data:/data -it <aws_account>.dkr.ecr.us-west-2.amazonaws.com/pytorch-training:2.0.0-gpu-py310-cu118-ubuntu20.04-ec2 \
python /data/train.py --epochs 5 --batch-size 32
Im obigen Beispiel haben wir ein AWS PyTorch 2.0 Trainings-DLC heruntergeladen und dann ein Trainingsskript (train.py) darin ausgeführt. Das Flag --gpus all gibt dem Container Zugriff auf NVIDIA-GPUs auf dem Host, und -v /data:/data mountet ein Host-Datenverzeichnis in den Container. Dieser Ansatz stellt sicher, dass die Umgebung im Container die korrekte Version von PyTorch, CUDA usw. hat, was die Ausführung des Jobs vereinfacht. Es ist auch portabel – derselbe Container kann auf jedem Rechner mit Docker laufen, sodass Experimente reproduzierbar sind.
Wann man DLCs verwendet: DLCs sind besonders nützlich auf Cloud-Plattformen und Managed Services. Zum Beispiel verwenden Amazon SageMaker Trainingsjobs unter der Haube DLC-Images, sodass Sie einfach das Image und Ihren Trainingscode angeben können, und die Plattform erledigt den Rest. Selbst auf HPC-Clustern verwenden Teams manchmal Singularity oder Docker, um Jobs in einer containerisierten Umgebung aus Gründen der Konsistenz auszuführen. Zusammenfassend lässt sich sagen, dass DLCs das Problem "es funktioniert auf meinem Rechner" durch die Bereitstellung einer konsistenten Laufzeit für Deep-Learning-Aufgaben vereinfachen. Sie werden mit getesteten, optimierten Bibliotheken geliefert (was zu Leistungssteigerungen führen kann – z. B. berichtete AWS von einer bis zu 42%igen Beschleunigung mit ihrem optimierten PyTorch 2.0 DLC auf bestimmten Instanzen (Build high-performance ML models using PyTorch 2.0 on AWS – Part 1 | AWS Machine Learning Blog)).
Volcano (VOLC) – Kubernetes Batch-Scheduling für KI-Jobs
Volcano (VOLC) ist ein Batch-Scheduling-System, das auf Kubernetes aufbaut und für die Ausführung von High-Performance-Computing (HPC)- und KI-Workloads in einer Cloud-nativen Umgebung entwickelt wurde. Während der Standard-Scheduler von Kubernetes großartig für Microservices ist, fehlen ihm einige Funktionen, die für Deep-Learning-Jobs benötigt werden (wie Gang-Scheduling, Warteschlangenverwaltung und Prioritäts-Scheduling). Volcano adressiert diese, indem es einen benutzerdefinierten Scheduler und Job-Management-CRDs (Custom Resource Definitions) auf Kubernetes bereitstellt (Volcano: Collision between containers and batch computing | CNCF). Im Wesentlichen ermöglicht Volcano Kubernetes, sich eher wie ein HPC-Cluster-Scheduler für Batch-Jobs zu verhalten.
Was es ist: Volcano wurde eingeführt, um Container und Batch-Computing zu verbinden. Es unterstützt Frameworks wie TensorFlow, PyTorch, Spark und MPI, indem es Benutzern ermöglicht, Jobs einzureichen, die mehrere Ressourcen benötigen (z. B. ein Job, der 8 GPUs über 2 Knoten benötigt), und sicherzustellen, dass diese Ressourcen zusammen zugewiesen werden, bevor der Job startet (Volcano: Collision between containers and batch computing | CNCF). Dieses "Gang-Scheduling" stellt sicher, dass verteilte Trainingsjobs (die viele Pods erzeugen können) erst starten, wenn alle erforderlichen Pods starten können, wodurch eine Situation verhindert wird, in der die Hälfte des Jobs läuft und die andere Hälfte wartet (was Ressourcen verschwenden würde). Volcano bietet auch Fairness-Richtlinien, Prioritätswarteschlangen und die Möglichkeit, gemischte Workloads gemeinsam zu planen.
So funktioniert es: Volcano integriert sich als Scheduling-Plugin in Kubernetes. Benutzer definieren typischerweise eine Volcano Job YAML, die Aufgaben und ihre Replikatanzahlen, Ressourcenbedürfnisse usw. spezifiziert. Zum Beispiel könnte eine YAML einen Job mit 4 Replikaten deklarieren, die jeweils 1 GPU benötigen, und ein minAvailable: 4 (was bedeutet, dass dieser Job nur geplant wird, wenn 4 Pods platziert werden können). Bei der Einreichung findet der Scheduler von Volcano Platz auf dem Cluster für alle 4 Pods und startet sie gleichzeitig. Wenn nur 3 GPUs frei sind, wartet er, bis eine 4. frei ist (anstatt 3 jetzt und 1 später zu starten). Dies ist entscheidend für verteilte Trainingsframeworks wie Horovod oder PyTorch DDP, die erwarten, dass alle Ränge gleichzeitig zur Synchronisierung verfügbar sind.
Die Architektur von Volcano umfasst einen zentralen Controller und Scheduling-Plugins. Es berücksichtigt Scheduling-Algorithmen wie Fair-Sharing, Priorität usw. über einen Plugin-Mechanismus. Zum Beispiel kann es Warteschlangenrichtlinien erzwingen (sodass bestimmte Jobs andere nicht ausgrenzen) und Topologie-bewusstes Scheduling (Verteilung von Jobs über Knoten oder Racks zur Leistungssteigerung). Aus Benutzersicht fühlt sich die Verwendung von Volcano wie die Verwendung von Kubernetes an, jedoch mit einer anderen API für Jobs und der Gewissheit, dass Ihr ML-Job ganzheitlich geplant wird. Kurz gesagt, VOLC verwandelt Kubernetes in einen HPC-fähigen Scheduler (Volcano: Collision between containers and batch computing | CNCF), der die Bequemlichkeit von Containern mit der Leistungsfähigkeit der Batch-Job-Orchestrierung vereint.
Beispielanwendung: Angenommen, Sie haben einen Kubernetes-Cluster mit GPU-Knoten und möchten einen MPI-basierten verteilten Trainingsjob ausführen. Mit Volcano können Sie einen MPI-Job (Volcano integriert sich in MPI Operator) einreichen, der (sagen wir) 2 Pods mit jeweils 4 GPUs anfordert. Volcano stellt sicher, dass beide Pods zusammen auf zwei Knoten starten und jeweils 4 GPUs haben. Es wird auch behandelt, wenn ein Pod ausfällt, und den gesamten Job bei Bedarf neu planen, um die Gang-Semantik beizubehalten. Auf diese Weise kann Ihr MPI mpirun-Befehl innerhalb der Pods zuverlässig über beide Pods hinweg gestartet werden. Ohne Volcano könnte der Standard-Scheduler einen Pod starten und dann den zweiten verzögern, bis Ressourcen frei werden, was dazu führen würde, dass der MPI-Prozess des ersten Pods hängen bleibt oder ein Timeout auftritt.
SLURM: Klassisches HPC Job Scheduling (Tiefgehender Einblick)
SLURM (Simple Linux Utility for Resource Management) ist ein weit verbreiteter Open-Source-Job-Scheduler für HPC-Cluster. Er fungiert als das "Betriebssystem" eines Clusters, das Ressourcen (CPU-Kerne, GPUs, Speicher, Knoten) an Jobs zuweist, Jobs in die Warteschlange stellt, bis Ressourcen verfügbar sind, und diese Jobs startet und überwacht. Slurm ist hoch skalierbar und wird in vielen Top-Supercomputern eingesetzt. Er bietet ein Cluster-Management- und Job-Scheduling-Tool, das sich darauf konzentriert, Jobs effizient mit verfügbaren Ressourcen abzugleichen (Choosing the Right Orchestration Tool for ML Workloads: Slurm vs. Kubernetes | Nscale).
So funktioniert SLURM: Ein Slurm-Cluster besteht aus einem zentralen Controller (slurmctld), der die Warteschlange und das Scheduling verwaltet, und Agent-Daemons (slurmd), die auf jedem Rechenknoten laufen, um Aufgaben zu starten und zu überwachen. Benutzer interagieren mit Slurm über Befehle wie sbatch (um ein Batch-Job-Skript einzureichen), salloc (um eine interaktive Zuweisung anzufordern) oder srun (um parallele Aufgaben zu starten). Slurm verwaltet eine Liste von Partitionen (stellen Sie sie sich als benannte Warteschlangen oder Knotengruppen vor), von denen jede bestimmte Grenzen oder Hardwareeigenschaften hat, und plant Jobs auf Knoten in diesen Partitionen gemäß konfigurierten Richtlinien (Priorität, Fairness, Backfill-Scheduling usw.).
Beispiel für die Jobeinreichung: Unten ist ein Beispiel für ein Slurm-Batch-Job-Skript (train.sbatch), das Ressourcen anfordert und ein Trainingsprogramm ausführt:
#!/bin/bash
#SBATCH --job-name=train_model # Jobname
#SBATCH --nodes=1 # Auf einem einzigen Knoten ausführen
#SBATCH --ntasks=4 # Gesamtzahl der Aufgaben (Prozesse) = 4
#SBATCH --gres=gpu:4 # 4 GPUs anfordern (auf einem Knoten)
#SBATCH --cpus-per-task=4 # 4 CPU-Kerne pro Aufgabe (insgesamt 16 Kerne)
#SBATCH --mem=64G # 64 GB Speicher für den Job
#SBATCH --time=02:00:00 # Zeitlimit hh:mm:ss
#SBATCH --partition=ml_gpu # Name der Partition (Warteschlange)
module load anaconda/2023a # Alle notwendigen Module laden (z. B. Anaconda)
source activate myenv # Virtuelle Umgebung aktivieren, falls erforderlich
echo "Läuft auf $SLURM_NNODES Knoten mit $SLURM_NTASKS Aufgaben..."
srun python train.py --epochs 10 --batch-size 128
In diesem Skript sind die #SBATCH-Zeilen Direktiven an Slurm. Wir fordern 1 Knoten mit 4 GPUs an und setzen den Job so, dass er python train.py über srun ausführt. Wenn wir sbatch train.sbatch ausführen, stellt Slurm den Job in die Warteschlange. Sobald ein Knoten in der Partition ml_gpu mit 4 freien GPUs und 16 freien CPU-Kernen verfügbar ist, weist Slurm diesen Knoten dem Job zu, startet den Job und srun startet 4 Aufgaben (da --ntasks=4). Wenn dies ein verteiltes Trainingsszenario mit MPI oder PyTorch distributed wäre, könnten diese 4 Aufgaben 4 Worker entsprechen (jedem ist eine GPU zugewiesen). Slurm kümmert sich darum, sie mit den richtigen Umgebungsvariablen für MPI oder für torch.distributed zu starten (falls dies konfiguriert ist).
Slurm effektiv nutzen: Slurm bietet viele Funktionen wie Job-Arrays (um viele ähnliche Jobs einfach einzureichen), Abhängigkeitsketten (Job B starten, nachdem Job A abgeschlossen ist) und Ressourcenprofilierung. Für ML ist ein gängiges Muster, --gres=gpu:N anzufordern, um N GPUs zu erhalten, und srun oder MPI zu verwenden, um N Prozesse zu erzeugen. Slurm stellt sicher, dass alle diese Prozesse auf den zugewiesenen Knoten laufen und kommunizieren können (oft richtet es Hostnamen in SLURM_HOSTNAMES ein und MPI kann diese verwenden). Slurm ermöglicht auch Scheduling-Richtlinien; zum Beispiel können Jobs unterbrochen oder mit Backfill versehen werden. Backfill-Scheduling ist in HPC nützlich, um die Auslastung zu maximieren: Ein kurzer Job könnte in der Warteschlange nach vorne springen, wenn er in eine Lücke zwischen großen Jobs passt. Als Entwickler könnten Sie bei großen Trainingsjobs eine längere Walltime anfordern; aber wenn Sie die Arbeit in kürzere Blöcke aufteilen oder Checkpoints erstellen und neu starten können, können Sie Backfill verwenden, um sie früher in Stücken ausführen zu lassen.
Zusammenfassend lässt sich sagen, dass Slurm ein leistungsstarkes Tool für die Ausführung von Batch-ML-Jobs auf Clustern ist. Es ist Low-Level-iger als Kubernetes oder Cloud-Services – Sie melden sich typischerweise bei einem Login-Knoten an und verwenden sbatch zum Einreichen – aber es bietet eine feinkörnige Kontrolle. Viele Forscher führen PyTorch oder TensorFlow auf Slurm-Clustern aus, indem sie einfach Slurm-Skripte schreiben, die ihren Trainingscode starten, und von der Cluster-Planung von GPU-Ressourcen profitieren.
vLLM: LLM-Inferenz-Engine mit hohem Durchsatz
Als Large Language Models (LLMs) von der Forschung in die Produktion übergingen, wurde das effiziente Servieren zu einer Herausforderung. vLLM ist eine Open-Source-Bibliothek und -Engine, die für schnelle, kostengünstige LLM-Inferenz entwickelt wurde. vLLM wurde am Sky Computing Lab der UC Berkeley entwickelt und führt eine neuartige Speicherverwaltungstechnik namens PagedAttention ein, um die Speicherung und den Zugriff auf den Attention-Key-Value-Cache des Modells zu optimieren (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog). Das Ergebnis ist ein deutlich höherer Durchsatz (Anfragen pro Sekunde) im Vergleich zu herkömmlichen Implementierungen. Tatsächlich erreicht vLLM einen bis zu 24-fach höheren Durchsatz als die Baseline Hugging Face Transformers-Bibliothek beim GPT-Style-Model-Serving (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog), und das alles, ohne dass Änderungen an der Modellarchitektur erforderlich sind.
So funktioniert vLLM: Bei der autoregressiven Generierung (der typischen Art und Weise, wie LLMs Text Token für Token generieren) wird für jede Sequenz ein Cache vergangener Attention-Keys und -Values verwaltet. Dieser KV-Cache wächst mit der Sequenzlänge und kann viel GPU-Speicher verbrauchen (z. B. ~1,7 GB für eine einzelne lange Sequenz auf LLaMA-13B (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog)). Die meisten Frameworks weisen einen zusammenhängenden Block für die maximal mögliche Länge zu, was zu viel ungenutztem Speicherplatz führt (Fragmentierung). vLLM's PagedAttention behandelt den KV-Cache stattdessen wie virtuelle Speicherseiten, weist ihn in Blöcken zu und ermöglicht eine nicht zusammenhängende Speicherung (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog). Auf diese Weise kann der Speicher flexibel verwaltet werden: Sequenzen, die die Generierung beenden, geben ihre Seiten frei, die für neue Sequenzen wiederverwendet werden können. Es reduziert die Speicherverschwendung drastisch (um 60–80 % in typischen Fällen) und ermöglicht vLLM, mehr gleichzeitige Sequenzen zu verarbeiten als andere Systeme.
Darüber hinaus implementiert vLLM Continuous Batching: Es kann neue eingehende Anfragen on the fly in den Batch aufnehmen, selbst während andere Anfragen sich mitten in der Generierung befinden. Traditionelle Systeme verarbeiten oft einen festen Batch von Anfragen von Anfang bis Ende für jeden Generierungsschritt; der Scheduler von vLLM ist stattdessen feinabgestimmt, um Anfragen nach Möglichkeit zusammenzuführen und die GPUs beschäftigt zu halten. Es verwendet auch optimierte CUDA-Graphen, um Python-Overhead in der Serving-Schleife zu vermeiden, unterstützt sowohl NVIDIA- als auch AMD-GPUs und integriert sich in Hugging Face Transformers (sodass Sie Modelle nach Namen laden und sie servieren können).
Beispielhafte Verwendung: Die Verwendung von vLLM fühlt sich ähnlich an wie die Verwendung eines High-Level-Inferenzservers. Sie können es entweder programmgesteuert oder über einen API-Server verwenden. Zum Beispiel, programmgesteuert:
from vllm import LLM, SamplingParams
# Laden Sie ein 7B-Modell (vorausgesetzt, Gewichte sind lokal oder über HuggingFace Hub verfügbar)
llm = LLM(model="facebook/opt-6.7b", tensor_parallel_size=1) # tensor_parallel_size kann >1 sein, um das Modell auf GPUs aufzuteilen
prompts = [
"Benutzer: Hallo, wie geht es Ihnen?\nAssistent:",
"Benutzer: Was ist die Hauptstadt von Frankreich?\nAssistent:"
]
# Generieren Sie mit bestimmten Decodierungsparametern
outputs = llm.generate(prompts, sampling_params=SamplingParams(top_p=0.95, max_tokens=100))
for out in outputs:
print("Prompt:\n", out.prompt)
print("Vervollständigung:\n", out.outputs[0].text)
Dieser Code erstellt eine LLM-Instanz und generiert Antworten für zwei Prompts in einem Batch. Unter der Haube verwendet vLLM PagedAttention, um den KV-Cache für diese Prompts zu verwalten und sie möglicherweise sogar zusammen zu batchen. Die outputs enthalten die Vervollständigungen für jeden Prompt. Man könnte vLLM auch als Server starten (der eine OpenAI-kompatible REST-API bereitstellt), indem man einen Befehl wie python -m vllm.entrypoints.openai.api_server --model your_model_name verwendet. Dies macht es einfach, vLLM in Anwendungen zu integrieren, die eine OpenAI-API erwarten (weisen Sie sie einfach auf diesen Server hin).
Warum es wichtig ist: vLLM verschiebt im Wesentlichen die Durchsatzgrenzen des LLM-Servings. Wenn Sie ein festes GPU-Budget haben, bedeutet das Servieren von mehr Anfragen pro Sekunde geringere Kosten pro Anfrage. Die berichtete 24-fache Verbesserung gilt in Szenarien, in denen viele gleichzeitige Anfragen mit relativ langen Ausgaben generiert werden (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog). Selbst in weniger extremen Fällen liefert vLLM oft mehrfache Beschleunigungen gegenüber naiven Implementierungen und etwa das 3-fache gegenüber dem TGI-Server von Hugging Face in vielen Umgebungen (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog). Es unterstützt auch fortgeschrittene Decodierungsalgorithmen (wie Beam Search, parallele Stichprobenentnahme) effizient (vLLM and PagedAttention: A Comprehensive Overview | by Abonia Sojasingarayar | Medium). Für einen Entwickler kann die Einführung von vLLM so einfach sein wie das Austauschen Ihres Inferenzcodes, um die API von vLLM zu verwenden (oder seinen Server auszuführen). Der Vorteil ist, dass Sie mehr Benutzer bedienen oder die Latenz reduzieren können, ohne mehr GPUs zu kaufen.
SGLang: Strukturierte Generierungssprache und Serving Framework
Während sich vLLM auf den reinen Durchsatz der Einzel-Prompt-Vervollständigung konzentriert, adressiert SGLang das Problem der effizienten Orchestrierung komplexer, strukturierter Interaktionen mit LLMs. SGLang (kurz für Structured Generation Language) ist ein System, das eine Frontend-DSL (Domain-Specific Language) zur Beschreibung mehrstufiger LLM-Programme mit einer hochoptimierten Backend-Laufzeit zur Ausführung dieser Programme kombiniert ([2312.07104] SGLang: Efficient Execution of Structured Language Model Programs) (SGLang: A Deep Dive into Efficient LLM Program Execution - DEV Community). Es ist, als ob SGLang sowohl eine Programmiersprache für das Prompting ist (mit Funktionen wie Schleifen, Bedingungen und parallelen Aufrufen) als auch eine Serving-Engine, die sicherstellt, dass diese Programme schnell laufen.
Was es ist: Die Kernidee hinter SGLang ist, dass viele reale Anwendungen mehrere Aufrufe an ein LLM und strukturierte Ausgaben erfordern. Zum Beispiel könnte ein KI-Agent Schritte planen und das LLM für jeden Schritt aufrufen, oder Sie könnten verlangen, dass das LLM JSON mit einem bestimmten Schema ausgibt. Dies naiv zu tun, kann langsam sein: Mehrere Aufrufe verursachen Overhead, und das LLM könnte die gleichen Prompt-Teile wiederholt verarbeiten usw. Mit dem Frontend von SGLang können Sie ein einzelnes "Skript" schreiben, das mehrere Generierungsaufrufe, Verzweigungslogik und die Integration externer Tools enthalten kann. Der SGLang-Compiler/die Laufzeit führt dies dann effizient aus. Die Laufzeit führt Optimierungen wie RadixAttention (ein Algorithmus zur Wiederverwendung von KV-Cache über Prompt-Präfixe hinweg, ähnlich im Geiste wie das Paging von vLLM, aber auf gemeinsam genutzte Prompt-Teile ausgerichtet) und eine komprimierte Finite-State-Machine für die Ausgabegrammatik ein (um strukturierte Ausgaben schneller zu verarbeiten) ([2312.07104] SGLang: Efficient Execution of Structured Language Model Programs). Im Klartext bedeutet RadixAttention, dass SGLang, wenn Sie viele Anfragen haben, die ein gemeinsames Präfix verwenden (z. B. System- oder Few-Shot-Prompt), diesen Teil einmal berechnet und ihn wiederverwendet, wodurch Dinge wie Chatbots oder Retrieval-Augmented Generation viel schneller werden, indem redundante Arbeit vermieden wird (What is SGLang and Why Does It Matter? | by Emad Dehnavi | Medium). Die strukturierte Ausgabe-FSM bedeutet, dass SGLang, wenn Sie beispielsweise ein JSON mit festen Schlüsseln erwarten, das Generieren der festen Interpunktion/Schlüssel Token für Token überspringen und nach vorne springen kann, da es weiß, dass diese Teile deterministisch sind (What is SGLang and Why Does It Matter? | by Emad Dehnavi | Medium). Dies bietet einen 3-fachen+ Geschwindigkeitsboost für die Generierung langer JSON- oder XML-Ausgaben (What is SGLang and Why Does It Matter? | by Emad Dehnavi | Medium).
So funktioniert es: SGLang besteht aus zwei Teilen – einer Python-basierten DSL und einer Laufzeit. Die DSL ermöglicht es Benutzern, etwas wie das Folgende zu schreiben:
from sglang import sg # hypothetische Schnittstelle
# Pseudocode: definieren Sie einen strukturierten Generierungsfluss
with sg.session(model="Llama-2-13b-chat") as sess:
# Ein einfaches Programm mit zwei sequentiellen LLM-Aufrufen und einer strukturierten Ausgabe
user_input = "Übersetzen Sie den folgenden englischen Text ins Französische und geben Sie die Stimmung an: Ich liebe dieses Produkt."
sg.prompt(f"Benutzer fragt: {user_input}\nSie sind ein Übersetzer und Stimmungsanalyst.")
translation = sg.generate("Übersetzen Sie zuerst ins Französische:")
sentiment = sg.generate("Analysieren Sie nun die Stimmung des Originaltextes:")
sg.return_json({"translation": translation, "sentiment": sentiment})
(Hinweis: Das Obige ist illustrativer Pseudocode. Die tatsächliche Syntax von SGLang kann abweichen, aber konzeptionell ermöglicht sie sequenzielle und parallele Generierung und die Rückgabe strukturierter Daten.)
Wenn dieses SGLang-"Programm" ausgeführt wird, übernimmt die Laufzeit: Es kann den ersten Generierungsaufruf zum Übersetzen ausführen, dann den zweiten für die Stimmung und schließlich ein JSON zusammenstellen. Unter der Haube verwendet es ein oder mehrere LLM-Inferenz-Backends (mit Optimierungen ähnlich wie vLLM). Da die beiden Prompts den anfänglichen Anweisungskontext gemeinsam haben, kann SGLang die Berechnung dieses Präfixes für den zweiten Aufruf wiederverwenden. Und wenn JSON zurückgegeben wird und die JSON-Schlüssel und das Format durch sg.return_json vorgegeben sind, kann es sicherstellen, dass diese ausgegeben werden, ohne mehrere Token für Klammern/Kommas auszugeben.
Hauptmerkmale: Die Autoren von SGLang heben Funktionen hervor, darunter Zero-Overhead-Scheduling (sein Scheduler zum Orchestrieren mehrerer Aufrufe fügt praktisch keine zusätzliche Latenz hinzu), Cache-Aware-Load-Balancing (es kann Anfragen an Worker so weiterleiten, dass Cache-Treffer maximiert werden) und Multimodale Unterstützung (es kann auch Vision-Language-Modelle verarbeiten, z. B. LLaVA für Bilder) (GitHub - sgl-project/sglang: SGLang is a fast serving framework for large language models and vision language models.) (GitHub - sgl-project/sglang: SGLang is a fast serving framework for large language models and vision language models.). Es unterstützt auch gängige Effizienztricks: Quantisierung (int8/4-Bit usw.), spekulative Decodierung (Generierung mehrerer Token im Voraus, um sie dann zu überprüfen, was lange Generierungen beschleunigen kann) und Multimodell-Orchestrierung (z. B. Verwendung eines Modells für einen Teil des Programms und eines anderen Modells für einen anderen Teil). Im Wesentlichen ist es ein All-in-One-Framework zum Schreiben LLM-gestützter Anwendungen und zum Ausführen dieser mit hoher Leistung.
Leistung und Anwendungsfälle: SGLang hat auf komplexen Aufgaben bis zu 6,4-fache Durchsatzverbesserungen gegenüber hochmodernen Systemen gezeigt ([2312.07104] SGLang: Efficient Execution of Structured Language Model Programs). Betrachten Sie eine Retrieval-Augmented Generation (RAG)-Pipeline: Normalerweise würden Sie nach Kontextvektoren suchen, diesen dann vor einen Prompt stellen und dann eine Antwort generieren. Mit SGLang könnten Sie diese gesamte Sequenz (Vektorsuchergebnis, das in eine Prompt-Vorlage einfließt, dann Generierung) als ein einzelnes Programm ausdrücken. Die Laufzeit könnte einige Schritte parallelisieren, wenn dies möglich ist, und zwischengespeicherte Komponenten wiederverwenden. Ebenso kann SGLang für Chatbots, die eine Konversationshistorie haben, die invarianten Teile des Prompts über Runden hinweg wiederverwenden (anstatt die gesamte Konversation jedes Mal neu zu verarbeiten). Für strukturierte Ausgaben, wie z. B. sicherzustellen, dass die Antwort des Modells einem JSON-Schema folgt, kann der Finite-State-Machine-Ansatz von SGLang verhindern, dass das Modell vom Format abweicht, und es schneller machen, indem die feste Syntax eingefügt wird. Aus technischer Sicht bietet SGLang sowohl einen Produktivitätsboost (über die DSL) als auch einen Performanceboost (über die optimierte Ausführung) für die Erstellung komplexer LLM-Workflows.
Wer steckt dahinter: SGLang ist ein Open-Source-Projekt (unterstützt von einer Community, zu der Forscher von Stanford/Berkeley und Unternehmen wie LinkedIn usw. gehören, wie in ihren Danksagungen angegeben). Es wurde in der Produktion von Unternehmen wie ByteDance und xAI verwendet (SGLang: A Deep Dive into Efficient LLM Program Execution - DEV Community). Es ist relativ neu (das arXiv-Papier erschien Ende