vLLM Push-Based KV Transfer zielt auf die Wartezeit zwischen Prefill und Decode

Der Push-basierte KV-Transfer von vLLM verlagert die Cache-Übergabe früher im Ablauf, wobei AWS im Vergleich zu seinem Pull-basierten Benchmark eine bis zu 3x bessere First-Token-Latenz meldet. Time to first token, kurz TTFT, misst, wie lange eine Anfrage wartet, bevor die Generierung mit der Ausgabe beginnt. Die Änderung betrifft die Koordination zwischen der Verarbeitung eines Prompts und der Generierung seiner Antwort.

In seinem Beitrag vom 19. Oktober berichtet AWS zudem von bis zu 30 % besserer time per output token, kurz TPOT, die die Generierungszeit pro weiterem Token misst. Diese Ergebnisse betreffen Qwen3-32B auf Amazon EC2 P5en-Instanzen mit AWS Elastic Fabric Adapter, dem latenzarmen Server-Interconnect des Unternehmens. Sie beschreiben einen konkreten Vergleich und sind kein allgemeines Beschleunigungsversprechen für jede vLLM-Bereitstellung.

Im Kern geht es um die Koordination per Push oder Pull. Push bereitet die empfangende Engine früher vor; Pull erhält eine spätere Entscheidung darüber, wo die Generierung ausgeführt wird. Für Betreiber, die Prompt-Verarbeitung und Generierung trennen, wirft die Nachricht eine konkrete Frage auf: Wie viel Routing-Flexibilität sollten sie gegen eine kürzere Übergabezeit eintauschen?

Der Push-basierte KV-Transfer von vLLM verändert den Beginn der Übergabe

Die Änderung verlagert die Vorbereitung vor die Übergabe und reduziert damit Arbeit, die erst nach Abschluss der Prompt-Verarbeitung anfallen müsste.

Prefill, die Inferenzphase zur Verarbeitung von Eingabe-Tokens, erzeugt einen Key-Value-Cache mit Zwischenzuständen der Attention, die für die anschließende Generierung benötigt werden. Decode, die Phase zur Erzeugung von Ausgabe-Tokens, nutzt diesen Zustand. Disaggregated inference platziert diese Phasen auf getrennten Engine-Instanzen und schafft dadurch eine Transfergrenze zwischen ihnen.

Die KV-Transfer-Benchmarks von AWS vergleichen Push und Pull mit einer Prefill-Instanz und einer Decode-Instanz. Der Test deaktiviert Prefix-Caching, das Anfragen sonst die Wiederverwendung bereits berechneter Zustände ermöglicht. Er verwendet 128 Ausgabe-Tokens, Eingabelängen von 1.000 bis 16.000 Tokens sowie Anfrageraten von einer bis acht Abfragen pro Sekunde.

Am anspruchsvolleren Ende meldet AWS für Pull ungefähr 1.744 Millisekunden TTFT, gegenüber ungefähr 540 Millisekunden für Push. Der gemeldete TPOT-Vergleich erreicht ungefähr 10,4 Millisekunden für Pull und ungefähr 7 Millisekunden für Push. Bei geringer Last und kürzeren Eingaben liefern die Modi ähnliche Ergebnisse.

Diese Grenzen sind wichtiger als der Schlagzeilen-Multiplikator. Das Ergebnis identifiziert einen Workload, bei dem die Koordination der Übergabe entscheidend wird. Es belegt nicht, dass wenig genutzte Dienste, andere Modelle oder größere Bereitstellungen denselben Vorteil erhalten.

Die praktische Konsequenz ist eine Veränderung dessen, was Betreiber untersuchen sollten, wenn die Reaktionsfähigkeit nachlässt. Eine langsame erste Antwort bedeutet nicht automatisch, dass die Prompt-Berechnung mehr Accelerator-Kapazität benötigt. Die für die Organisation der nächsten Phase aufgewendete Zeit verdient eine gesonderte Prüfung.

Diese Unterscheidung verändert auch, wie Produktteams einen Performance-Vorfall interpretieren. Wenn Nutzer verzögerte Antworten melden, müssen Teams zwischen Wartezeit auf Berechnung und Wartezeit auf Koordination unterscheiden. Zusätzliche Ressourcen adressieren diese Ursachen unterschiedlich, und ein aggregiertes Latenzdiagramm kann ihre Trennung verschleiern.

Der Benchmark stützt daher eine gezielte Schlussfolgerung: Die Abfolge rund um den Cache-Transfer kann die gemessene Nutzererfahrung erheblich beeinflussen. Der passende nächste Schritt besteht darin festzustellen, ob diese Abfolge einen bedeutenden Anteil an der Verzögerung eines bestimmten Dienstes hat.

Es würde die Evidenz überdehnen, dies als universellen Ersatz für Pull zu bezeichnen. Sinnvoller ist die Lesart, dass vLLM nun eine weitere Scheduling-Option bereitstellt. Betreiber können diese Wahl anhand des Workloads und des Routing-Verhaltens bewerten, das sie tatsächlich benötigen.

Der Zeitpunkt ist relevant, weil es sich um eine Verbesserung beim Serving auf Implementierungsebene und nicht um eine Modellankündigung handelt. Teams können sie untersuchen, ohne eine Änderung der Modellqualität vorauszusetzen. Der potenzielle Nutzen liegt darin, wie eine bestehende Anfrage die Infrastruktur durchläuft.

Serving-Teams stehen neben einem Rechenproblem vor einem Koordinationsproblem

Der Druck betrifft Betreiber, deren Latenzziele von der Trennung der Prompt-Verarbeitung von der Token-Generierung abhängen.

Die Dokumentation von vLLM zu disaggregated prefilling ordnet die Trennung als Möglichkeit ein, First-Token- und Between-Token-Latenz unabhängig voneinander zu optimieren. Sie weist auch auf Interferenzen hin, wenn die Prompt-Verarbeitung in eine Engine gelangt, die bereits Antworten generiert. Die Dokumentation kennzeichnet die Funktion als experimentell und warnt ausdrücklich davor, Disaggregation selbst als Durchsatzverbesserung zu betrachten.

Das ist ein wichtiges Gegengewicht zu weitreichenden Architekturbehauptungen. Die Trennung der Arbeit schafft Möglichkeiten für unabhängige Optimierung, bringt aber auch Verpflichtungen mit sich. Das System muss Zustand koordinieren, Ziele auswählen und Anfragen über eine zusätzliche Grenze hinweg weiterführen.

Bei einem hypothetischen Dokumentassistenten lassen sich diese Verantwortlichkeiten auf vertrautes Nutzerverhalten abbilden. Ein Nutzer sendet ein langes Dokument ab und wartet darauf, dass eine Antwort beginnt. Gleichzeitig erwarten andere Nutzer, dass ihre bereits laufenden Antworten weiterhin gleichmäßig eintreffen.

Diese Erwartungen hängen zusammen, sind jedoch nicht austauschbar. Ein Dienst kann Antworten schnell beginnen lassen und sie dann ungleichmäßig ausliefern. Er kann nach dem Start auch reibungslos generieren, während Nutzer zu lange warten, bevor überhaupt etwas erscheint.

Der Push-Vorschlag ist relevant, weil Betreiber beide Erfahrungen bewerten müssen. Eine Connector-Entscheidung sollte anhand des Antwortstarts und der laufenden Generierung beurteilt werden, nicht anhand eines einzelnen günstigen Durchschnittswerts. Andernfalls riskiert ein Team, die beobachtete Kennzahl zu verbessern und zugleich die Erfahrung zu übersehen, die Nutzer wahrnehmen.

Dadurch entsteht für Infrastrukturverantwortliche Druck, ihr Messmodell zu verbessern. Sie benötigen Transparenz über die Phasen einer Anfrage ebenso wie über ihre Gesamtdauer. Ohne diese Trennung kann Koordinations-Overhead mit Modell-Ausführungszeit verwechselt werden.

Auch Käufer, die gehostete Inferenz bewerten, geraten dadurch unter Druck. Ein gemeldetes Beschleunigungsverhältnis braucht eine Ausgangsbasis, einen Workload und eine operative Abgrenzung. Käufer sollten fragen, was sich unterhalb des Ergebnisses geändert hat, bevor sie es zum Vergleich von Diensten nutzen.

Die Unterscheidung ist besonders relevant, wenn eine Anwendung lange und kurze Anfragen mischt. Eine durchschnittliche Prompt-Länge verdeckt die Anfragen, die die größten Scheduling-Anforderungen schaffen. Eine überzeugende Bewertung sollte diese Variation erhalten, statt sie durch eine einheitliche Eingabe zu ersetzen.

Nichts davon belegt, dass Disaggregation für jede Anwendung erforderlich ist. Die Entscheidung beginnt weiterhin mit den beobachteten Einschränkungen eines Dienstes. Wenn die aktuelle Architektur ihre Reaktionsziele erfüllt, braucht das Hinzufügen einer Transfergrenze eine eigene Begründung.

Für Teams, die bereits getrennte Phasen betreiben, wird der Connector jedoch Teil der Performance-Planung. Sein Verhalten beeinflusst, was der Router wissen muss und wann Ressourcen verbindlich zugewiesen werden. Das macht die Änderung auch über die Ingenieurin oder den Ingenieur hinaus relevant, die oder der den Transfercode pflegt.

Produkt- und Plattformteams benötigen daher eine gemeinsame Beschreibung von Erfolg. Eine hilfreiche Beschreibung verbindet für Nutzer sichtbare Wartezeit mit Infrastrukturmessungen und Bereitstellungsbedingungen. Sie vermeidet es, den Benchmark eines Connectors als vollständige Prognose für die Anwendung zu behandeln.

Teams, die diese Bewertungen pflegen, können ihre Erkenntnisse in einer durchsuchbaren Wissensdatenbank organisieren. Wenn Konfigurationen neben den Schlussfolgerungen stehen, können spätere Prüfer besser nachvollziehen, warum ein früheres Ergebnis zutraf oder nicht.

Die frühe Einrichtung des Zielorts verschafft Push seinen Vorteil gegenüber Pull

Push verändert die Abhängigkeitsreihenfolge rund um den Transfer, statt die Notwendigkeit zu beseitigen, zwischengespeicherten Zustand zu verschieben.

Das Design des Push-Connectors dokumentiert NixlPushConnector, eine Alternative, die zur Koordination von Transfers die NVIDIA Inference Xfer Library, kurz NIXL, nutzt. Die empfangende Decode-Engine reserviert Zielspeicher und übermittelt dessen Position. Die Prefill-Engine schreibt den abgeschlossenen Zustand dann in dieses vorbereitete Ziel.

Registrierung und abgeschlossener Prompt-Zustand können in beliebiger Reihenfolge eintreffen. Der Connector führt sie zusammen, bevor er den Schreibvorgang auslöst. Ein Writer-Thread im Hintergrund übernimmt Push-spezifische Vorgänge, während die Abschlussbuchhaltung der Engine mitteilt, wann der empfangene Zustand bereit ist.

Das ist die wesentliche Erklärung des vLLM Push-Transfers: Das Ziel wird eingerichtet, während nützliche Berechnung weiterläuft, und die Übergabe wird abgeschlossen, sobald ihre Voraussetzungen vorliegen. Diese Abfolge reduziert die Notwendigkeit, sämtliche Koordination erst nach Abschluss von Prefill zu beginnen.

Die Unterscheidung lässt sich leichter als Abhängigkeitsproblem bewerten. Kann die Vorbereitung erst beginnen, wenn die Berechnung endet, wartet die Anfrage nacheinander auf beides. Überlappt die Vorbereitung mit der Berechnung, verschwindet ein Teil der Wartezeit aus dem Pfad, der bestimmt, wann die Generierung beginnen kann.

Die Überlappung hat weiterhin Bedingungen. Der Empfänger muss existieren, sein Ziel muss geeignet sein, und der Transfer muss korrekt abgeschlossen werden. Die frühe Vorbereitung verändert den Zeitpunkt dieser Verantwortlichkeiten; sie macht sie nicht optional.

Deshalb verfehlt eine bloße Beschreibung von Push als schnellerem Netzwerkvorgang den Mechanismus. Die Architekturfrage betrifft, welche Arbeit den Fortschritt blockiert. Ein Transfer kann leistungsfähige Hardware nutzen, während die umgebende Software eine Anfrage dennoch unnötig warten lässt.

Die Ausführung im Hintergrund führt eine weitere nützliche Unterscheidung ein. Arbeit, die keine Engine-Schleife mehr blockiert, verbraucht weiterhin irgendwo Ressourcen. Betreiber sollten daher fragen, wohin die Arbeit verlagert wurde und ob dieser Ort unter anhaltender Nachfrage gesund bleibt.

Dieselbe Überlegung gilt für die Interpretation von TPOT. Eine transferbezogene Änderung kann die laufende Generierung beeinflussen, wenn Koordination mit dem Ausführungspfad konkurriert, der bestehende Anfragen bedient. Würde man nur die eingehende Anfrage bewerten, bliebe diese Wechselwirkung unentdeckt.

Bei vLLM Push versus Pull ist der entscheidende Vergleich daher umfassender als Schreiben versus Lesen. Er umfasst Zielauswahl, Zeitpunkt der Vorbereitung, Verantwortung für die Ausführung und Bereitschaftssignalisierung. Diese Details erklären, warum eine Connector-Änderung das Anwendungsverhalten verändern kann, ohne das Modell zu ändern.

Die Implementierung verdeutlicht zudem, warum Korrektheit bei jeder Bereitstellungsentscheidung neben Performance gehört. Das Empfangen eines Teils des Zustands reicht nicht aus, wenn die Generierung den vollständig erwarteten Zustand benötigt. Eine erfolgreiche Übergabe braucht eine eindeutige Bereitschaftsbedingung, insbesondere wenn die Arbeit mehrere Beteiligte umfasst.

NVIDIA bietet mit Dynamos Architektur für disaggregated serving eine hilfreiche Branchenreferenz. Die Dokumentation beschreibt getrennte Prefill- und Decode-Pools, Router-Orchestrierung sowie Überlegungen zu topologiebewussten Transfers. Damit wird ein vergleichbares Koordinationsproblem belegt, nicht jedoch ein Performance-Ranking gegenüber dem vLLM-Connector.

Dynamo ist zudem ein Integrationskontext für Serving-Engines; dies als einfachen Wettbewerb von Unternehmen gegen Unternehmen darzustellen, wäre daher irreführend. Der relevante Wettbewerb besteht zwischen unterschiedlichen Arten, Anfragen zu organisieren. Jeder Ansatz muss Platzierung, Zustandsbewegung und Generierungsbereitschaft miteinander vereinbaren.

Dieser Vergleich ordnet das AWS-Ergebnis ein. Der Beitrag betrifft einen spezifischen Punkt in einem größeren Serving-Workflow. Sein Wert hängt davon ab, ob die Verbesserung dieses Punkts die tatsächlichen Antwortziele des Dienstes voranbringt.

Eine frühere Decoder-Auswahl tauscht Flexibilität gegen Überlappung

Der stärkste Grund, Pull beizubehalten, liegt im Wert einer späteren Zielauswahl.

Die Push-Sequenz erfordert einen vorbereiteten Empfänger vor der Übergabe. Diese Festlegung ermöglicht Überlappung, schafft aber auch den zentralen Zielkonflikt des Artikels. Ein Betreiber kann eine verkürzte Koordinierungsverzögerung nicht unabhängig vom Zeitpunkt der Zielauswahl bewerten.

Betrachten wir einen hypothetischen Dienst, bei dem Anfragen ungleichmäßig über einen Decoder-Pool eintreffen. Die frühe Auswahl eines Ziels reserviert einen Pfad, bevor die Prompt-Verarbeitung abgeschlossen ist. Eine spätere Auswahl gibt der Routing-Entscheidung aktuellere Informationen über das System.

Keine der beiden Optionen ist automatisch überlegen. Bleiben die Bedingungen während des Prefill vorhersehbar, kann eine frühe Auswahl ein sinnvoller Tausch sein. Verändern sich die Bedingungen erheblich, kann eine spätere Auswahl betrieblichen Wert haben, den ein transferorientierter Benchmark nicht erfasst.

Die relevante Frage lautet, wie oft diese Flexibilität ein Ergebnis verändert. Ein Betreiber sollte prüfen, ob eine verzögerte Auswahl Warteschlangen spürbar verkürzt, überlastete Worker vermeidet oder die Dienstkonsistenz verbessert. Ohne diese Beobachtungen bleibt Flexibilität ein abstrakter Vorteil statt einer gemessenen Anforderung.

Deshalb kann auch eine Bereitstellung als Paar nicht jede Routing-Frage klären. Sie bietet eine kontrollierte Umgebung zur Untersuchung einer Übergabe. Sie liefert weniger Belege für Entscheidungen zwischen vielen Zielen, insbesondere wenn diese Ziele unterschiedliche Auslastungen haben.

Die Geschichte der Cache-Wiederverwendung fügt eine weitere Grenze hinzu. In einem Beitrag vom 12. Oktober beschreibt vLLM den bidirektionalen KV-Transfer, der in späteren Gesprächsrunden wiederverwendbaren Zustand von Decode zu Prefill zurückgibt. Diese Arbeit befasst sich mit wiederholter Berechnung, wenn der Gesprächsverlauf wächst, und verwendet NIXL-Lesevorgänge in beide Richtungen.

Dies stellt ein anderes Optimierungsziel dar. Eine kürzere Vorwärtsübergabe und weniger wiederholte Prompt-Berechnung können beide die Reaktionsfähigkeit verbessern. Ihre Vorteile sollten nicht als automatisch kombinierbar angenommen und nicht so verglichen werden, als würden sie identische Arbeit messen.

Ein konversationeller Assistent veranschaulicht den Unterschied. Seine erste Anfrage und eine spätere Anfrage mit angesammeltem Verlauf können unterschiedliche Anforderungen an die Infrastruktur stellen. Die Verbesserung eines Übergangs belegt nicht die beste Richtlinie für die gesamte Unterhaltung.

Für vLLM Push gegenüber Pull bedeutet dies, dass Bewertungen das Sitzungsverhalten einbeziehen sollten, wenn das Produkt davon abhängt. Ein gleichförmiger Strom nicht zusammenhängender Prompts beantwortet eine engere Frage. Er kann Tests der wiederholten Interaktionen der Anwendung nicht ersetzen.

Der Benchmark mit deaktiviertem Cache verdient dieselbe sorgfältige Behandlung. Das Entfernen der Wiederverwendung hilft, das Transferverhalten zu isolieren, aber die Wiederverwendung in der Produktion verändert, wie oft dieses Verhalten relevant ist. Eine Anwendung, die häufig einen vollständigen Transfer vermeidet, hat ein anderes Chancenprofil.

Das entwertet keinen kontrollierten Vergleich. Es definiert dessen Zweck. Betreiber sollten das isolierte Ergebnis beibehalten und zugleich eine Workload-Bewertung ergänzen, die die tatsächlichen Caching- und Routing-Entscheidungen der Anwendung wiederherstellt.

Auch hinsichtlich der berichteten Gewinne gibt es eine Evidenzgrenze. Die Zahlen stammen von der beteiligten technischen Quelle und nicht von einer hier geprüften unabhängigen Replikation. Sie rechtfertigen Untersuchungen, stützen jedoch keine Behauptungen universeller Überlegenheit oder garantierter Einsparungen über eine gesamte Flotte hinweg.

Die skeptische Schlussfolgerung ist daher konkret: Frühe Vorbereitung verfügt über einen nachvollziehbaren Mechanismus, während ihr Gesamtwert von der Bereitstellung abhängt. Eine fundierte Einführungsentscheidung muss den Koordinierungsvorteil zusammen mit der Flexibilität messen, gegen die er eingetauscht wird.

Auch die Pull-Basislinie verändert sich

Ein Teil des berichteten Vorteils betrifft den Ort der Transfer-Vorbereitung – eine Designentscheidung, die auch Pull neu bewerten kann.

Ein öffentlicher Vorschlag für einen Reader-Thread zielt auf die Einreichung von NIXL-Pull-Vorgängen. Sein erklärtes Ziel ist es, die Einreichung von Lesevorgängen in einen dedizierten Hintergrund-Thread zu verlagern und damit Arbeit auf dem Forward-Ausführungsthread der Engine zu reduzieren. Der Vorschlag belässt das Polling der Abschlüsse auf dem Forward-Thread.

Die für diesen Artikel geprüfte Seite führt den Vorschlag als offen auf. Das belegt fortlaufende Entwicklung, nicht ein ausgeliefertes Leistungsergebnis. Es liefert keine Grundlage für die Behauptung, dass eine künftige Pull-Implementierung Push erreicht oder einen bestimmten Prozentsatz der Lücke schließt.

Seine Bedeutung ist konzeptionell. Transferrichtung und Platzierung der Ausführung sind getrennte Entscheidungen. Push kann von einer früheren Vorbereitung des Ziels profitieren, während die Hintergrundausführung eine andere Quelle von Interferenzen adressiert.

Diese Unterscheidung verändert die Interpretation eines Benchmark-Vorsprungs. Ein Vergleich erfasst die Implementierungen, die zu diesem Zeitpunkt getestet werden. Er ordnet nicht dauerhaft jeden beobachteten Vorteil dem Architekturbegriff zu, der dem Gewinner zugeschrieben wird.

Für Käufer und Betreiber lautet die praktische Konsequenz: Versionsbewusstsein. „Push“ und „Pull“ reichen als Beschreibungen einer Evaluierungsumgebung nicht aus. Die relevante Implementierung und Konfiguration bestimmen, welche Vorbereitungsschritte wo ausgeführt werden.

Damit wird die Wartungshistorie Teil der Leistungsbelege. Ein späteres Connector-Update kann die Basislinie verändern, ohne Modell oder Hardware zu ändern. Teams sollten frühere Schlussfolgerungen erneut prüfen, wenn sich das Ausführungsverhalten wesentlich verändert.

Die Arbeit am Reader-Thread bietet zudem einen nützlichen Test der zugrunde liegenden Erklärung. Verbessert die Hintergrundeinreichung Pull unter vergleichbaren Bedingungen, würde dies die Bedeutung der Platzierung der Ausführung stützen. Es würde für sich genommen nicht den separaten Vorteil der überlappenden Zielvorbereitung aufheben.

Umgekehrt müsste auch eine begrenzte Verbesserung interpretiert werden. Die verbleibende Verzögerung könnte andere Abhängigkeiten betreffen, oder die Workload könnte andere Einschränkungen offenlegen. Ein enttäuschendes Ergebnis würde nicht automatisch beweisen, dass das Design des Vorschlags andernorts keinen Wert hat.

Hier braucht die Leistungsberichterstattung Zurückhaltung. Ein nützlicher Bericht trennt, was gemessen wurde, welcher Mechanismus es erklärt und was hypothetisch bleibt. Die Verbindung dieser Kategorien erzeugt selbstbewusste Schlagzeilen, aber schwache betriebliche Orientierung.

Für den Push-basierten KV-Transfer von vLLM besteht die dauerhafte Lehre darin, die Arbeit rund um eine Übergabe zu untersuchen. Connector-Namen fassen Verhalten zusammen, erklären aber nicht jede Verzögerung. Das Profiling des tatsächlichen Ausführungspfads bleibt notwendig.

Die sich entwickelnde Basislinie spricht auch gegen eine voreilige Standardisierungsentscheidung. Teams können eine Konfiguration einsetzen, die aktuellen Anforderungen dient, und zugleich Belege für eine spätere Neubewertung bewahren. Das Ziel ist ein zuverlässiger Dienst und keine dauerhafte Bindung an eine Transferrichtung.

Replikation, Pull-Thread-Fortschritt und Routing-Verhalten beobachten

Die nächsten hilfreichen Belege werden zeigen, ob die isolierten Koordinierungsgewinne realistische Bereitstellungsentscheidungen überstehen.

In den nächsten ein bis drei Monaten ist das erste zu beobachtende Signal eine unabhängige Replikation über anwendungsnahe Workloads hinweg. Die aussagekräftigsten Ergebnisse würden denselben Vergleich beibehalten und zugleich Prompt-Verteilungen, Caching-Verhalten und Bereitstellungsgröße variieren. Konsistente Verbesserungen würden den Fall für eine breitere Einführung stärken.

Die Replikation sollte zudem den Start der Antwort von der laufenden Generierung unterscheiden. Ein Dienst muss wissen, ob er während einer gesamten Interaktion reaktionsfähiger wird. Günstige Ergebnisse, die auf einen ungewöhnlich anspruchsvollen Benchmark-Punkt begrenzt sind, würden eine engere Bereitstellungsentscheidung stützen.

Das zweite Signal ist der Fortschritt bei der Hintergrundeinreichung für Pull. Eine geprüfte und veröffentlichte Implementierung, gefolgt von einem vergleichbaren Benchmark, würde klären, wie stark die Platzierung der Ausführung beiträgt. Eine kleinere Lücke würde die Mechanismus-Erklärung stärken und zugleich den Fall schwächen, Push als kategorisch überlegen zu behandeln.

Dieses Signal benötigt ein tatsächlich gemessenes Ergebnis. Eine zusammengeführte Änderung allein würde Verfügbarkeit belegen, nicht Leistungsparität. Betreiber sollten Entwicklungsaktivität nicht in eine numerische Behauptung umwandeln, bevor die relevante Workload getestet wurde.

Das dritte Signal ist Routing-Verhalten über ein festes Prefill-Decode-Paar hinaus. Ergebnisse sollten zeigen, was geschieht, wenn eine frühe Zielauswahl auf sich verändernde Decoder-Nachfrage trifft. Stabile nutzerseitige Latenz würde den Fall stärken, dass Überlappung unter realistischem Platzierungsdruck wertvoll bleibt.

Führen frühe Festlegungen stattdessen andernorts zu längeren Warteschlangen, würde sich die bevorzugte Bereitstellungsgrenze verengen. Push könnte weiterhin für vorhersehbare Workloads geeignet sein, während eine spätere Auswahl für andere wertvoll bleibt. Das würde das Ergebnis verfeinern, statt es zu widerlegen.

Diese Signale halten die Diskussion am ursprünglichen Ereignis ausgerichtet. Die Frage lautet, ob eine frühere Vorbereitung einen vollständigen Dienst unter seinen eigenen Betriebsbedingungen verbessert. Weitergehende Behauptungen über die Ökonomie der Inferenz erfordern umfassendere Belege, als dieser Connector-Vergleich liefert.

Für Teams, die entscheiden müssen, was sie jetzt tun, beginnt der Prozess mit einem repräsentativen Anfragetrace und einem klar definierten Antwortziel. Bewahren Sie Modell, Caching-Richtlinie, Routing-Verhalten und Implementierungsversion, wenn Sie Connector-Ergebnisse vergleichen. Dokumentieren Sie, wo Wartezeiten auftreten, und prüfen Sie dann, ob eine frühere Vorbereitung diese Verzögerung reduziert, ohne andernorts eine größere Warteschlange zu erzeugen. Halten Sie den kontrollierten Benchmark getrennt von der produktionsnahen Bewertung, damit beide eine klare Frage beantworten. Lesen Sie die Design- und Benchmark-Bedingungen, bevor Sie ein berichtetes Verhältnis in eine Kapazitätsentscheidung übertragen. Für den Push-basierten KV-Transfer von vLLM besteht die sinnvolle Maßnahme in einer begrenzten Bewertung der Übergabe, die Ihre Anwendung tatsächlich ausführt. Verbessert eine frühere Zielvorbereitung die Erfahrung Ihrer Nutzer unter der Last, die Ihr Dienst bewältigen muss?