- Welches Problem löst PegaFlow für das vLLM-Serving?
- Wie integriert sich PegaFlow in vLLM?
- Was fügt die Novita AI-Architektur hinzu?
- Welche Leistungsergebnisse sind öffentlich?
- Wann ist ein externer KV-Cache am nützlichsten?
- Wie können Entwickler PegaFlow heute inspizieren?
- Was sollten Plattform-Teams vor der Einführung überprüfen?
- FAQ
- Fazit
- Empfohlene Artikel
PegaFlow Externer KV-Cache für vLLM
2,15x schnellere Startzeit – das ist die Schlagzahl aus dem gemeinsamen Artikel von vLLM und Novita AI PegaFlow, doch der tiefere Punkt ist architektonisch: Produktions-LLM-Serving benötigt KV-Cache-Besitz außerhalb eines einzelnen Inferenz-Engine-Prozesses. PegaFlow macht KV-Cache zu einem eigenständigen Dienst, sodass vLLM-Bereitstellungen Cache über Neustarts, lokale Instanzen und entfernte Knoten hinweg bewahren, teilen und skalieren können.
Dieser Beitrag gibt die Perspektive von Novita AI, warum wir PegaFlow gebaut haben, was die öffentliche vLLM-Integration zeigt, welche Behauptungen bereits quellgestützt sind und wie Entwickler die Open-Source-Implementierung heute inspizieren können.
Erkunde das PegaFlow GitHub-Repository oder lies den gemeinsamen Artikel von vLLM und Novita AI für die vollständige technische Erläuterung.
Welches Problem löst PegaFlow für das vLLM-Serving?
PegaFlow adressiert die Fragilität von prozesslokalem KV-Cache bei High-Throughput-LLM-Inferenz. Wenn KV-Cache nur innerhalb eines einzelnen vLLM-Engine-Prozesses lebt, kann nützlicher Cache-Zustand während Neustarts verschwinden, innerhalb einer Instanz gefangen bleiben oder sich nicht effizient über Knoten bewegen.
Das wird teuer, wenn Workloads lange Prompts wiederverwenden, ähnliche Anfragen über Replicas routen oder Prefill- und Decode-Arbeit trennen. Der Cache enthält möglicherweise bereits Arbeit, die das System nicht neu berechnen sollte, aber die Serving-Topologie kann sie nicht immer wiederverwenden.
PegaFlow ändert diese Grenze. Es läuft als externer KV-Cache-Dienst, implementiert mit einem Rust-Kern, und verbindet sich mit vLLM über den externen KV-Connector-Mechanismus, nicht über einen langlebigen Fork.
Wie integriert sich PegaFlow in vLLM?
PegaFlow integriert sich in vLLM über kv_transfer_config, PegaKVConnector und kv_connector_module_path. Im veröffentlichten Artikel übernimmt der Connector wichtige KV-Cache-Operationen zur Laufzeit, während vLLM weiterhin Scheduling, Modellausführung, Batching und den OpenAI-kompatiblen Serving-Pfad verwaltet.
Das öffentliche Repository listet derzeit vLLM als bereit in seiner Framework-Integrationstabelle und zeigt diese Connector-Konfiguration im Schnellstart:
vllm serve Qwen/Qwen3-0.6B \
--kv-transfer-config '{"kv_connector": "PegaKVConnector", "kv_role": "kv_both", "kv_connector_module_path": "pegaflow.connector"}'
Der praktische Nutzen ist ein saubereres Besitzmodell: vLLM bleibt die Serving-Engine, während PegaFlow den externen KV-Cache-Speicher, Transfer, Teilen und zugehörige Cache-Beobachtbarkeit besitzt.
Was fügt die Novita AI-Architektur hinzu?
Das Designziel von Novita AI ist es, KV-Cache wie eine Produktions-Serving-Infrastruktur zu behandeln, nicht wie temporären Prozessspeicher. Das bedeutet, PegaFlow ist um eine eigenständige Servicegrenze, einen Rust-Datenpfad, gemeinsame Cache-Pools und mehrstufigen Speicher herum konzipiert.
| Architektur-Entscheidung | Warum sie für Entwickler wichtig ist | Öffentliche Quelle |
|---|---|---|
| Unabhängiger Sidecar-Dienst | KV-Cache kann Neustarts der Inferenz-Engine überleben und separat vom vLLM-Prozess skaliert werden. | PegaFlow README |
| GIL-freier Rust-Kern | Der Cache-Hotpath vermeidet Python-Overhead und hält die Inferenz-Engine-Threads auf das Serving fokussiert. | PegaFlow README |
| Pinned Host Memory, RDMA Remote Memory und SSD-Cache | Der Cache kann schnellere lokale Speicher, entfernten Knotenspeicher und größere SSD-gestützte Kapazität umfassen. | vLLM-Artikel |
| Prometheus-Metriken und OTLP-Export | Betreiber können das Cache-Verhalten beobachten, anstatt KV-Wiederverwendung als verstecktes Engine-Detail zu behandeln. | PegaFlow README |
Zuletzt überprüft: 2026-05-20. Diese Details stammen aus dem gemeinsamen vLLM-Artikel und dem öffentlichen novitalabs/pegaflow README.
Welche Leistungsergebnisse sind öffentlich?
Die öffentlichen Leistungsbehauptungen sollten als PegaFlow-Bewertungsergebnisse aus dem gemeinsamen vLLM-Artikel und Repository-Benchmark gelesen werden, nicht als generische Garantien für jede Workload. Cache-Trefferquote, Prompt-Wiederverwendung, Modellform, Hardware, Netzwerktopologie und Anfrage-Routing beeinflussen alle reale Bereitstellungen.
| Szenario | Berichtetes Ergebnis | Quelle |
|---|---|---|
| vLLM-Start mit vorbesessenem 500 GiB Host-KV-Pool | 2,15x schnellere Startzeit | Gemeinsamer vLLM-Artikel |
| Acht Qwen3-8B-Instanzen teilen sich einen Host-Cache | 56% höherer Durchsatz | Gemeinsamer vLLM-Artikel |
| DeepSeek-V3.2 MLA mit TP8 | 72% höherer Durchsatz | Gemeinsamer vLLM-Artikel |
| Interne RDMA-Cluster-Fernlesevorgänge | 194 GB/s durchschnittlicher Fernlesedurchsatz | Gemeinsamer vLLM-Artikel |
| H800-Referenz-Benchmark, Llama-3.1-8B, warmer vs. kalter Cache | TTFT-Mittelwert von 572,5 ms auf 61,5 ms gesenkt; P99 TTFT von 1113,7 ms auf 77,0 ms gesenkt | PegaFlow README |
Zuletzt überprüft: 2026-05-20. Die RDMA-Zahl wird im Quellartikel als internes Clustrergebnis beschrieben, sollte also als berichtete Bewertungsdaten und nicht als universelle Durchsatzgarantie betrachtet werden.
Wann ist ein externer KV-Cache am nützlichsten?
Externer KV-Cache ist am nützlichsten, wenn die Prompt-Wiederverwendung hoch genug ist, dass die Neuberechnung in Latenz, Durchsatz oder GPU-Auslastung sichtbar wird. Er ist weniger nützlich für Workloads, bei denen fast jede Anfrage einzigartig ist und die Cache-Wiederverwendung von Natur aus gering ist.
- Häufige Neustarts: Cache außerhalb der Engine zu halten, kann Neustartstrafen reduzieren, wenn der Cache-Zustand nützlich bleibt.
- Multi-Instanz-Serving: Das Teilen des Host-Caches kann doppelte Prefill-Arbeit über lokale vLLM-Instanzen hinweg reduzieren.
- Multi-Node-Bereitstellungen: RDMA-gestützter Remote-Cache kann nützliche KV-Blöcke über eine einzelne Maschine hinaus verfügbar machen.
- Prefill/Decode-Disaggregation: Externer Cache kann dem Serving-System einen klareren Übergabepunkt zwischen den Phasen geben.
Für Novita AI ist dies Teil eines breiteren Infrastrukturprinzips: Produktions-KI-Systeme benötigen die Serving-Engine, die Speicherschicht, die Routing-Schicht und die Beobachtbarkeitsschicht, die sich unabhängig weiterentwickeln können, wenn Datenverkehrsmuster komplex werden.
Wie können Entwickler PegaFlow heute inspizieren?
Entwickler können das öffentliche GitHub-Repository inspizieren und die veröffentlichten Pakete installieren, auf die das README verweist. Das Repository dokumentiert ein CUDA 12-Paket, ein CUDA 13-Paket, ein vLLM-Connector-Beispiel, Serverkonfiguration, P2P-RDMA-Setup, Prefill/Decode-Routing, Metriken und Projektziele.
uv pip install pegaflow-llm # CUDA 12
uv pip install pegaflow-llm-cu13 # CUDA 13
Der einfachste lokale Serverbefehl im README ist:
pegaflow-server
Für die Bewertung in der Produktion beginnen Sie mit Ihrem eigenen Prompt-Wiederverwendungsprofil, Zielmodell, GPU-Topologie, Speicherkapazität und RDMA- oder SSD-Annahmen. PegaFlow ist Infrastruktur für Cache-Wiederverwendung; die Workload bestimmt, wie viel Wert erfasst werden kann.
Was sollten Plattform-Teams vor der Einführung überprüfen?
Plattform-Teams sollten PegaFlow gegen ihre eigene Serving-Topologie validieren, bevor sie öffentliche Benchmark-Zahlen als Planungsinputs behandeln. Der richtige Test ist nicht nur kalter vs. warmer Cache, sondern ob die Cache-Wiederverwendung in dem Datenverkehrsmuster erscheint, das tatsächlich Kosten oder Latenz treibt.
- Messen Sie die Prompt-Wiederverwendung und die erwartete KV-Cache-Trefferquote unter realem Routing.
- Vergleichen Sie das Neustartverhalten mit und ohne extern besessenen KV-Cache.
- Testen Sie Single-Node-Multi-Instanz-Sharing, bevor Sie auf RDMA erweitern.
- Überprüfen Sie die Beobachtbarkeit: Cache-Treffer, Fehlschläge, Transferlatenz, Speicherdruck und SSD-Verhalten.
- Bestätigen Sie die Versionskompatibilität mit dem in Ihrer Bereitstellung verwendeten vLLM-Connector-Pfad.
Dies ist auch der Grund, warum die Open-Source-Grenze wichtig ist. Entwickler können den Connector, die Serverkonfiguration, Metriken und Benchmark-Setup inspizieren, anstatt sich auf einen Black-Box-Cache-Dienst zu verlassen.
FAQ
Was ist PegaFlow?
PegaFlow ist eine Open-Source-KV-Cache-Speicher-Engine für LLM-Inferenz von Novita AI. Es läuft als unabhängiger Dienst und verbindet sich über den externen KV-Connector-Pfad mit vLLM.
Benötigt PegaFlow einen vLLM-Fork?
Nein. Der veröffentlichte vLLM-Artikel beschreibt PegaFlow, das sich über kv_transfer_config und PegaKVConnector verbindet, wobei externe Pakete über kv_connector_module_path geladen werden.
Welche Leistungsergebnisse sind öffentlich?
Der gemeinsame vLLM-Artikel berichtet über 2,15x schnellere Startzeit, 56% höheren Durchsatz in einem gemeinsam genutzten Host-Cache-Setup, 72% höheren Durchsatz für ein DeepSeek-V3.2-MLA-Setup und 194 GB/s durchschnittlichen Fernlesedurchsatz in einem internen RDMA-Cluster. Das README berichtet auch über H800-TTFT-Reduzierungen für einen Warm-Cache-Referenz-Benchmark.
Wo können Entwickler PegaFlow ausprobieren?
Entwickler können das öffentliche novitalabs/pegaflow-Repository durchgehen, pegaflow-llm für CUDA 12 oder pegaflow-llm-cu13 für CUDA 13 installieren und dem Repository-Schnellstart folgen.
Fazit
PegaFlow ist Novita AIs Arbeit an externem KV-Cache für das Produktions-LLM-Serving mit vLLM: ein eigenständiger Cache-Dienst, ein Rust-Datenpfad, gemeinsame Cache-Pools und eine Connector-Grenze, die einen vLLM-Fork vermeidet. Die Kernaussage ist einfach: Wenn KV-Cache zur Infrastruktur anstelle von prozesslokalem Zustand wird, erhalten Serving-Teams mehr Kontrolle über Neustarts, Teilen, Skalierung und Beobachtbarkeit. Überprüfen Sie das PegaFlow-Repository, vergleichen Sie die öffentlichen Ergebnisse mit Ihrer eigenen Workload und nutzen Sie Novita AIs breitere Entwicklerinfrastruktur, wenn Sie Modell-APIs, Agentenausführung oder GPU-Workflows um diesen Serving-Stack herum benötigen.
