AWS zeigt LLM-Serving auf zwei Knoten mit den Ray LLM Deep Learning Containers

Warum Prefill und Decode getrennt werden

Laut AWS besteht LLM-Inferenz aus zwei unterschiedlichen Phasen. Beim Prefill wird der gesamte Eingabe-Prompt parallel verarbeitet und der Key-Value-Cache (KV-Cache) aufgebaut. Anschließend erzeugt der Decode die Antwort Token für Token und liest und erweitert dabei diesen Cache. Der Prefill ist rechenlimitiert, der Decode wird dagegen von der Speicherbandbreite begrenzt.

Teilen sich beide Phasen eine GPU, konkurrieren sie um dieselben Ressourcen, und punktuell auftretende Prefill-Last stört den latenzkritischen Decode. Die Disaggregation von Prefill und Decode (PD) legt die Phasen auf getrennte Knoten, sodass jede ungestört läuft und sich unabhängig skalieren lässt. Nach Angaben von AWS verhindert das, dass rechenintensive lange Prompts die Token-Erzeugung für bereits laufende Anfragen ausbremsen. Als geeignete Workloads nennt AWS Retrieval Augmented Generation (RAG), Dokumentzusammenfassungen und agentische Anwendungen.

Der Preis dafür, so AWS, ist die Übergabe des beim Prefill aufgebauten KV-Cache an den Decode-Knoten. Diese Übertragung muss schnell genug sein, damit sie den Vorteil nicht wieder aufzehrt. Deshalb kommt es auf die Verbindung zwischen den Knoten an.

Was der Ray LLM DLC enthält

AWS Deep Learning Containers sind vorgefertigte, leistungsoptimierte Docker-Images, die ein Framework, dessen Abhängigkeiten und den GPU-Stack zu einer getesteten und gepatchten Kombination bündeln. Laut AWS werden vor jedem Release alle Komponenten gemeinsam validiert, sodass CUDA-Runtime, Framework und Serving-Schicht nicht auseinanderlaufen. Sicherheitspatches werden zur Build-Zeit eingespielt.

Der Ray LLM DLC überträgt dieses Prinzip auf verteiltes Serving. Er enthält:

• vLLM als Inferenz-Engine
• Ray Serve HTTP als Serving-Schicht
• NIXL (NVIDIA Inference Transfer Library) für die KV-Cache-Übertragung zwischen Knoten
• den EFA-Stack (libfabric und aws-ofi-nccl) für hochbandbreitige Kommunikation zwischen den Knoten

Andernfalls müssten Kunden diese Abhängigkeitskette selbst zusammenbauen und bei Inkompatibilitäten debuggen, eine Arbeit, die AWS als undifferenziert bezeichnet. Der Beitrag knüpft an einen früheren an, der den Ray Serve DLC auf einem einzelnen GPU-Knoten vorgestellt hatte.

So ist das Deployment aufgebaut

Das Beispiel läuft auf einem EKS-Cluster innerhalb einer Virtual Private Cloud. Ein CPU-Systemknoten (m7i.xlarge) beherbergt Systemworkloads, den KubeRay-Operator und den reinen CPU-Pod des Ray-Head. Zwei GPU-Worker-Knoten (g6.8xlarge) führen die Ray-Worker aus, einen für Prefill und einen für Decode. Beide ziehen den DLC aus Amazon Elastic Container Registry.

KubeRay überwacht den vom Nutzer angewendeten RayService und richtet den Beitritt der Worker zum Head automatisch ein. Ray Serve verteilt die Prefill- und Decode-Deployments auf die beiden GPU-Worker, und der KV-Cache wandert über NIXL vom Prefill zum Decode, und zwar per EFA über das libfabric-Backend von NIXL. Die GPU-Knotengruppe ist auf eine einzige Availability Zone festgelegt, weil EFA keine AZ-Grenzen überschreiten kann.

Voraussetzungen sind ein AWS-Konto, ausreichend Service-Kontingent für zwei g6.8xlarge-Instanzen (mindestens 64 vCPU) sowie die Werkzeuge AWS CLI, kubectl, eksctl, helm und envsubst.

Konfiguration ganz ohne Anwendungscode

Weil Ray Serve LLM einen integrierten Application Builder mitbringt, besteht die gesamte Serving-Anwendung laut AWS aus einem YAML-Block. Es gibt keine Handler-Klasse, keinen Model Archiver und kein eigenes Image. Ein Helfer namens build_pd_openai_app nimmt eine Prefill- und eine Decode-Konfiguration entgegen und verbindet die KV-Cache-Übertragung hinter einem OpenAI-kompatiblen Endpunkt.

Das Beispiel stellt Qwen/Qwen3.5-9B bereit, mit max_model_len von 4096, bfloat16-Präzision und einer gpu_memory_utilization von 0,90. Beide Phasen nutzen NixlConnector mit kv_role auf kv_both und jeweils eigenen Engine-IDs. Eine Einstellung hebt AWS besonders hervor: kv_connector_extra_config mit dem LIBFABRIC-Backend. Fehlt sie, greift NIXL standardmäßig auf UCX zurück, das laut AWS selbst auf EFA nur mit TCP-Geschwindigkeit läuft.

Jeder Worker-Pod fordert eine GPU und eine EFA-Schnittstelle an. Der vollständige Code steht im zugehörigen Repository bereit.

Was das für Anwender bedeutet

Für Teams, die große oder durchsatzstarke Modelle auf AWS betreiben, nimmt der Container einen Gutteil der manuellen Arbeit ab, GPU-Bibliotheken, Netzwerk und Serving-Software über mehrere Knoten hinweg aufeinander abzustimmen. Laut AWS eignet sich derselbe Ansatz auch für Tensor-, Pipeline- und Datenparallelität, allerdings behandelt diese Anleitung nur das PD-Setup mit zwei Knoten. Das Beispiel nutzt ein kleines 9B-Modell auf bescheidenen GPU-Instanzen und taugt daher eher als Vorlage denn als Richtwert für die Dimensionierung.