Transferencia KV basada en push para mejorar el TTFT y el TPOT para la inferencia desagregada en vLLM

vLLM es un motor de inferencia y servicio de código abierto para modelos lingüísticos grandes (LLM). La inferencia de LLM tiene dos fases diferenciadas: la de prellenado, que procesa la solicitud de entrada y crea la caché de valores clave (KV), y la de decodificación, que utiliza esa caché para generar datos de salida uno por uno. Estas fases tienen diferentes características de cálculo, memoria y escalado. La desagregación previa a la decodificación (P-D) las ejecuta en instancias de motor independientes, lo que permite que cada fase se escale y optimice de forma independiente. Esto puede mejorar la utilización de los recursos, el rendimiento y la latencia bajo carga. Sin embargo, también es necesario transferir la caché de KV de la instancia de precarga a la instancia de decodificación antes de que pueda comenzar la generación del token, por lo que la transferencia de KV eficiente es fundamental para obtener el primer token (TTFT).

Una de las formas en que vLLM realiza esta transferencia es a través del conector NVIDIA Inference Xfer Library (NIXL), que mueve los bloques KV a través de interconexiones que admiten el acceso remoto directo a la memoria (RDMA), como el adaptador AWS Elastic Fabric (AWS EFA, la red RDMA de baja latencia que se utiliza en los servidores de AWS). En los tipos de instancia compatibles, AWS EFA admite GPUDirect RDMA y Neuron Direct RDMA. Por lo tanto, NIXL puede transferir bloques de KV directamente entre la GPU o la memoria del dispositivo AWS Trainium sin pasar por la memoria del host. El modo predeterminado del conector NIXL es el basado en la extracción: cuando la instancia de precarga termina de calcular la caché KV de mensajes, el router transmite los metadatos de origen, incluidos los ID de los bloques de precarga, a la instancia de decodificación. A continuación, la instancia de decodificación asigna los bloques de destino, prepara la transferencia de NIXL e inicia NIXL READ para extraer los bloques KV de la instancia de precarga. Como estos pasos de coordinación y configuración se llevan a cabo de forma secuencial después del llenado previo y antes de que pueda comenzar la decodificación, amplían la ruta crítica del TTFT, tal y como se muestra en el

siguiente cronograma.

Pull-mode timeline: router relay, decode-side allocation, and NIXL READ run serially on the path to first token.

Figura 1: Cronograma de transferencia de KV en modo extracción, en el que el relé del enrutador, la asignación del lado de decodificación y el NIXL READ se ejecutan en serie en la ruta hacia el primer token

En este artículo se presenta un conector NIXL basado en pulsaciones que desvía la coordinación y la configuración de las transferencias posteriores a la precarga de la ruta crítica. Si utilizas vLLM para realizar inferencias desagregadas de prellenado y decodificación, el modo push puede mejorar la capacidad de respuesta de las aplicaciones al reducir el TTFT y el TPOT, especialmente con tasas de solicitudes altas

En nuestro punto de referencia sobre una implementación 1P1D con instancias P5en de Amazon Elastic Compute Cloud (Amazon EC2) conectadas con EFA, el modo push ofrecía un TTFT hasta 3 veces mejor y hasta un 30 por ciento más de tiempo por token de salida (TPOT) en comparación con el modo pull (consulte la sección Datos de rendimiento) del modelo Qwen3-32B. Los resultados dependen

de la carga de trabajo y de la configuración.

Creamos y validamos la función en clústeres de instancias de AWS Trainium conectados con EFA y, a continuación, la incorporamos a vLLM como una función independiente del acelerador. Los resultados que se muestran aquí provienen de un clúster P5en (GPU) de Amazon EC2 con EFA, lo que demuestra que las ventajas se transfieren a las GPU. En este artículo se explican la arquitectura basada en push, el flujo de transferencia, el modelo de subprocesamiento, los resultados de rendimiento y

cómo reproducir el punto de referencia.

Transferencia KV basada en push

En esta sección se explica el diseño basado en tecnología push: su arquitectura, el protocolo de transferencia y el modelo de subprocesos que mantienen la transferencia KV alejada de la ruta crítica.

Descripción general de la arquitectura

La transferencia basada en push mejora el rendimiento del TTFT y la decodificación por dos motivos:

Elimina la serialización del modelo pull al superponer el trabajo del productor y el del consumidor. La instancia de decodificación registra sus bloques de destino con antelación mientras el productor sigue calculando KV. La transferencia comienza entonces tan pronto como los bloques del productor estén listos, y no después de que el consumidor descubra su identidad de ida y vuelta, eliminando esa ida y vuelta de la ruta hacia el primer token
Esto reduce el tiempo de configuración de la transferencia a la instancia de decodificación. Esa configuración se ejecuta en el lado de prellenado y en un subproceso en segundo plano. Prepara los descriptores NIXL y envía la transferencia, de modo que la instancia de decodificación no dedique esos ciclos durante

El efecto neto es un menor TTFT y un mayor rendimiento de los tokens de salida en la instancia de decodificación.

El conector push coordina tres factores: la instancia de decodificación registra sus bloques de destino de forma anticipada, la instancia de precarga coincide con cada solicitud y emite la transferencia, y un subproceso dedicado en segundo plano se encarga de eliminar la KV del bucle de paso directo del motor. El siguiente diagrama muestra cómo

encajan estas piezas.

Push-based KV transfer architecture overview

Figura 2: Arquitectura de transferencia KV basada en push, que muestra cómo se coordinan la instancia de decodificación, la instancia de prellenado y el hilo de transferencia en segundo plano

Detalles de implementación

El protocolo tiene tres pasos lógicos.

1. Registro (lado de decodificación). Cuando la instancia de descodificación asigna bloques locales para una solicitud que requiere la precumplimentación remota, prepara un registro en el que se describe dónde debe escribir el KV la instancia precargada: su propia identidad y las ubicaciones de los bloques que acaba de reservar. En el mismo paso del motor, el trabajador transmite este registro a la instancia de prellenado en forma de notificación NIXL. Como el registro se produce en el momento de la asignación, el conector conoce los bloques de destino antes de que la instancia de prellenado complete el proceso de prellenado

2. Rendezvous (lado de prellenado). El registro desde el decodificador y el proceso de prellenado en el productor pueden llegar en cualquier orden, y el conector se encarga de ambos. Si el registro llega primero, el productor lo retiene hasta que termine el proceso de prellenado. Si el proceso de prellenado finaliza primero, el productor retiene los bloques de la solicitud hasta que llegue el registro. Sea cual sea el evento que ocurra en segundo lugar, se activará la transferencia. El conector empareja las solicitudes por ID y las cuentas coincidentes para las solicitudes reemitidas, asociando correctamente las solicitudes prioritarias o reintentadas.

3. Transferencia (lado de prellenado). Una vez que una solicitud coincide, el productor establece una conexión con la instancia de decodificación (si aún no existe una) y emite un NIXL WRITE que copia los bloques KV directamente a la memoria registrada del decodificador, direccionando cada rango tensor-paralelo de destino. El productor y el consumidor pueden usar diferentes diseños de bloques internos. Cada lado asigna las ubicaciones de los bloques a su propio diseño físico en el momento de la transferencia, lo que permite diferentes tamaños de bloque en cada lado. Cada WRITE incluye una notificación de finalización que NIXL envía a la instancia de decodificación una vez que llegan los datos. El decodificador cuenta estas notificaciones, una por cada rango de productor que escriba en ella. Solo considera que el KV se ha recibido después de que hayan llegado todas las notificaciones esperadas, momento en el que la solicitud procede a decodificarla

Modelo de enhebrado

El conector push separa la ejecución del modelo de la preparación de la transferencia KV mediante el uso de un subproceso de transferencia en segundo plano dedicado en cada dispositivo de prellenado. Al inicio de una solicitud, el bucle principal de decodificación asigna sus bloques KV de destino y los registra en la instancia de precarga, mientras que el bucle principal de precarga calcula la caché de KV inmediata. Una vez que el registro de destino y el indicador KV estén listos, el bucle principal precompletado pasa los bloques KV al subproceso en segundo plano y vuelve rápidamente a la ejecución del modelo

El subproceso en segundo plano establece o reutiliza la conexión NIXL, asigna los ID de bloque KV de la solicitud a los descriptores de memoria, fusiona los bloques contiguos en regiones de transferencia más grandes y envía la escritura NIXL a la instancia de decodificación. Cuando NIXL completa la transferencia, envía una notificación de finalización a la instancia de decodificación, que luego comienza a generar el token. Mantener la preparación de los descriptores y el envío de transferencias fuera de los bucles principales, que son críticos para la latencia, evita que este trabajo por solicitud retrase la ejecución del modelo. El siguiente diagrama muestra estas transferencias entre el bucle principal y el subproceso en segundo plano para

una sola solicitud.

Threading model showing the decode and prefill main loops handing KV blocks to a background thread that performs the NIXL transfer off the forward-pass loop

Figura 3: Transferencias del bucle principal y del subproceso de fondo para una sola solicitud en el modelo de subprocesamiento basado en push

Comparación de tiempos entre tirar y empujar

El siguiente diagrama resume los flujos de transferencia de tracción y empuje descritos en las secciones anteriores y destaca su efecto en el TTFT. Aunque ambos modos utilizan la misma ruta de datos NIXL y EFA/RDMA, pull se encarga de la retransmisión de metadatos y de la configuración del lado del decodificador después del prellenado, mientras que el modo push superpone la configuración del lado de decodificación con la del prefill. Como resultado, el método push elimina estas operaciones de la ruta crítica posterior al prellenado, lo que permite que la decodificación comience antes

Side-by-side timeline comparing pull and push KV transfer, showing push overlapping decode-side setup with prefill to shorten the path to the first token

Figura 4: Comparación de los flujos de transferencia push y pull, destacando cómo la transferencia push superpone la configuración del lado de decodificación con el prefill

Los dos modos también implican una compensación de enrutamiento. El modo de extracción permite al router seleccionar una instancia de descodificación una vez finalizada la precarga, lo que proporciona una mayor flexibilidad para gestionar la calidad del servicio y el enrutamiento en función de la carga. El modo push selecciona la instancia de decodificación antes, de modo que la configuración de destino pueda superponerse con la instancia de prellenado. A cambio, con una carga comparable, la instancia de precarga puede liberar sus bloques KV antes, ya que la transferencia comienza tan pronto como el registro de destino y el KV del mensaje

están listos.

Datos de rendimiento

Para la evaluación, utilizamos el modelo Qwen3-32B en una implementación 1P1D con instancias P5en de Amazon EC2 conectadas con EFA. Para aislar el rendimiento de las transferencias P→D, configuramos el punto de referencia para inhabilitar el almacenamiento en caché de prefijos con --no-enable-prefix-caching. Esta configuración hace que el nodo de decodificación recupere la caché KV completa del nodo de prellenado para cada solicitud. De lo contrario, las solicitudes superpuestas podrían reutilizar la caché local del nodo de decodificación y omitir la transferencia, lo que generaría resultados

de comparación engañosos.

En el siguiente gráfico, se comparan TTFT con transferencias KV push y pull. Realizamos barridos con longitudes de entrada de 1 000 a 16 000 y con tasas de solicitud de 1 a 8 consultas por segundo (QPS). Cuando la carga es baja y las solicitudes son cortas, los dos modos funcionan de forma casi idéntica. A medida que aumentan el QPS y la longitud de entrada, el modo pull se degrada bruscamente y alcanza unos 1.744 ms a 8 QPS y 16 000. El modo push se mantiene mucho más bajo, aproximadamente 540 ms, lo que supone una reducción de alrededor de 3 veces. La brecha aumenta porque el modo pull publica los descriptores NIXL en línea en el procesador de decodificación, de forma sincrónica dentro del ciclo del motor, por lo que el trabajo detiene la generación de los tokens. El modo push lo mueve a un hilo en segundo plano

, fuera de la ruta crítica.

Four-panel TTFT comparison of push and pull KV transfer for Qwen3-32B on Amazon EC2 P5en instances with EFA. Test configuration: 1P1D topology, 128 output tokens, and prefix caching disabled on the Decode node.

Figura 5: TTFT para transferencia KV push en comparación con pull KV entre longitudes de entrada y tasas de solicitud (topología 1P1D, 128 tokens de salida, almacenamiento en caché de prefijos deshabilitado en el nodo de decodificación)

En este gráfico se muestra el TPOT en las mismas condiciones. El patrón refleja el TTFT. Con cargas ligeras, empujar y tirar están cerca, alrededor de 5,6 a 5,8 ms. A medida que aumentan la longitud de la carga y la entrada, la tracción aumenta a unos 10,4 ms a entre 4 y 8 QPS y 16 K, mientras que el empuje se mantiene cerca de los 7 ms. Esto se debe a que la función push reduce la tarea de preparar los descriptores y transferir el envío de datos por parte del trabajador de descodificación. La generación de tokens no se agota, por lo que la latencia por token se mantiene estable incluso en

contextos prolongados y con alta concurrencia.

Four-panel TPOT comparison of push and pull KV transfer for Qwen3-32B on Amazon EC2 P5en instances with EFA. Test configuration: 1P1D topology, 128 output tokens, and prefix caching disabled on the Decode node.

Figura 6: TPOT para transferencia KV push en comparación con pull KV entre longitudes de entrada y tasas de solicitud (topología 1P1D, 128 tokens de salida, almacenamiento en caché de prefijos deshabilitado en el nodo de decodificación)

¿Cómo ejecutar un punto de referencia

Para reproducir nuestra configuración de referencia 1P1D, un nodo de precarga y un nodo de decodificación, utilizando instancias P5en de Amazon EC2 conectadas con EFA, consulte las instrucciones detalladas de la guía Reproducción de nuestros resultados. La guía describe la configuración del entorno, el lanzamiento de los servidores de precarga y descodificación de vLLM, la ejecución del punto de referencia y la recopilación de los resultados. La función se puede ejecutar en otras configuraciones compatibles, pero los resultados de rendimiento variarán según el hardware, el modelo, la carga

de trabajo y la configuración de la red.

Conclusión

En este artículo, mostramos cómo el conector KV basado en pulsaciones superpone el cálculo de prellenado con la asignación y el registro de bloques del lado del decodificador, lo que elimina de la ruta crítica la configuración de ida y vuelta del router posterior al prellenado y la transferencia del lado del decodificador. Esto reduce el TTFT y el TPOT, especialmente a altas tasas de solicitud. En nuestra evaluación comparativa Qwen3-32B sobre una implementación 1P1D con instancias P5en de Amazon EC2 conectadas con EFA, el modo push mejoró hasta 3 veces más en TTFT y un 30 por ciento más en TPOT en comparación con el modo pull. Los resultados varían según la carga de trabajo y la configuración.

Para usar el modo push, configure los servidores de prellenado y decodificación para que usen NixlPushConnector en lugar de NixlConnector.

Elija el conector push cuando la selección temprana del nodo de decodificación sea aceptable y la prioridad sea reducir el TTFT. El conector por tracción sigue siendo el más adecuado para las cargas de trabajo que requieren una transferencia KV bidireccional o la selección de instancias de decodificación diferidas hasta que se haya completado previamente el enrutamiento para un enrutamiento compatible con la carga. vLLM admite conectores KV tanto de inserción como de extracción, por lo que puede seleccionar el enfoque que mejor se adapte a su implementación

Como mejora futura, estamos estudiando la posibilidad de llevar el modelo de subprocesamiento NIXL de fondo al conector en modo extracción, lo que desviaría la configuración de NIXL de la ruta crítica para que las cargas de trabajo en modo extracción puedan beneficiarse de las mismas optimizaciones.

Hemos abierto una solicitud de cambios para explorar esta posibilidad.

Agradecimientos

Agradecemos a la comunidad vLLM su apoyo para mantener esta función.

Acerca de los autores

vLLM is an open-source inference and serving engine for large language models (LLMs). LLM inference has two distinct phases: prefill, which processes the input prompt and builds the key-value (KV) cache, and decode, which uses that cache to generate output one token at a time. These phases have different compute, memory, and scaling characteristics. Prefill-decode (P-D) disaggregation runs them on separate engine instances, allowing each phase to scale and be optimized independently. This can improve resource utilization, throughput, and latency under load. However, it also requires transferring the KV cache from the prefill instance to the decode instance before token generation can begin, making efficient KV transfer critical to time-to-first-token (TTFT).

One of the ways vLLM performs this transfer is through the NVIDIA Inference Xfer Library (NIXL) connector, which moves KV blocks over interconnects that support Remote Direct Memory Access (RDMA), such as AWS Elastic Fabric Adapter (AWS EFA, the low-latency RDMA network used across servers in AWS). On supported instance types, AWS EFA supports GPUDirect RDMA and Neuron Direct RDMA. NIXL can therefore transfer KV blocks directly between GPU or AWS Trainium device memory without staging through host memory. The default mode for NIXL connector is pull-based: After the prefill instance finishes computing the prompt KV cache, the router relays the source metadata, including the prefill block IDs, to the decode instance. The decode instance then allocates destination blocks, prepares the NIXL transfer, and initiates NIXL READ to pull the KV blocks from the prefill instance. Because these coordination and setup steps occur sequentially after prefill and before decoding can begin, they extend the TTFT critical path, as shown in the following timeline.

Figure 1: Pull-mode KV transfer timeline, where the router relay, decode-side allocation, and NIXL READ run serially on the path to the first token

This post introduces a push-based NIXL connector that moves post-prefill transfer coordination and setup off the critical path. If you run disaggregated prefill/decode inference with vLLM, push mode can improve application responsiveness by reducing TTFT and TPOT, particularly at high request rates.

In our benchmark on a 1P1D deployment using Amazon Elastic Compute Cloud (Amazon EC2) P5en instances connected with EFA, push mode delivered up to 3x better TTFT and up to 30 percent better time-per-output-token (TPOT) compared to pull mode (see the Performance data section) for the Qwen3-32B model. Results depend on workload and configuration.

We built and validated the feature on AWS Trainium instance clusters connected with EFA, and then we contributed it to vLLM as an accelerator-agnostic feature. The results here are from an Amazon EC2 P5en (GPU) cluster with EFA, showing the gains carry over to GPUs. This post explains the push-based architecture, transfer flow, threading model, performance results, and how to reproduce the benchmark.

Push-based KV transfer

This section explains the push-based design: its architecture, the transfer protocol, and the threading model that keeps KV transfer off the critical path.

Architecture overview

Push-based transfer improves TTFT and decode throughput for two reasons:

It removes the serialization of the pull model by overlapping producer and consumer work. The decode instance registers its target blocks in advance while the producer is still computing KV. The transfer then begins as soon as the producer’s blocks are ready, rather than after a consumer-side ID-discovery round trip, removing that round trip from the path to first token.
It moves the transfer-setup time off the decode instance. That setup runs on the prefill side and on a background thread. It prepares the NIXL descriptors and submits the transfer, so the decode instance does not spend those cycles during its latency-critical token-generation phase.

The net effect is lower TTFT and higher output-token throughput on the decode instance.

The push connector coordinates three actors: the decode instance registers its target blocks up front, the prefill instance matches each request and issues the transfer, and a dedicated background thread carries the KV write off the engine’s forward-pass loop. The following diagram shows how these pieces fit together.

Figure 2: Push-based KV transfer architecture, showing how the decode instance, prefill instance, and background transfer thread coordinate

Implementation details

The protocol has three logical steps.

1. Registration (decode side). When the decode instance allocates local blocks for a request requiring remote prefilling, it prepares a registration describing where the prefill instance should write the KV: its own identity and the block locations it has just reserved. Within the same engine step, the worker transmits this registration to the prefill instance as a NIXL notification. Because registration happens at allocation time, the connector knows the destination blocks before the prefill instance completes prefill.

2. Rendezvous (prefill side). The registration from the decoder and the completion of prefill on the producer can arrive in either order, and the connector handles both. If the registration arrives first, the producer holds it until its own prefill finishes. If prefill finishes first, the producer holds the request’s blocks until the registration arrives. Whichever event happens second triggers the transfer. The connector pairs requests by ID, and the matching accounts for reissued requests, correctly associating preempted or retried requests.

3. Transfer (prefill side). Once a request is matched, the producer establishes a connection to the decode instance (if one does not already exist) and issues an NIXL WRITE that copies the KV blocks directly into the decoder’s registered memory, addressing each destination tensor-parallel rank. The producer and consumer may use different internal block layouts. Each side maps block locations to its own physical layout at transfer time, allowing different block sizes on each side. Each WRITE carries a completion notification that NIXL delivers to the decode instance once the data arrives. The decoder counts these notifications, one per producer rank that writes into it. It treats the KV as received only after all expected notifications have arrived, at which point the request proceeds to decode.

Threading model

The push connector separates model execution from KV-transfer preparation by using a dedicated background transfer thread on each prefill worker. At the start of a request, the decode main loop allocates its destination KV blocks and registers them with the prefill instance while the prefill main loop computes the prompt KV cache. After both the destination registration and prompt KV are ready, the prefill main loop hands the KV blocks to the background thread and quickly returns to model execution.

The background thread establishes or reuses the NIXL connection, maps the request’s KV block IDs to memory descriptors, merges contiguous blocks into larger transfer regions, and submits the NIXL WRITE to the decode instance. When NIXL completes the transfer, it sends a completion notification to the decode instance, which then begins token generation. Keeping descriptor preparation and transfer submission off the latency-critical main loops prevents this per-request work from delaying model execution. The following diagram shows these main-loop and background-thread handoffs for a single request.

Figure 3: Main-loop and background-thread handoffs for a single request in the push-based threading model

Timing comparison of pull and push

The following diagram summarizes the pull and push transfer flows described in the preceding sections and highlights their effect on TTFT. Although both modes use the same NIXL and EFA/RDMA data path, pull performs the metadata relay and decode-side setup after prefill, while push overlaps decode-side setup with prefill. As a result, push removes these operations from the post-prefill critical path, allowing decoding to begin sooner.

Figure 4: Pull and push transfer flows compared, highlighting how push overlaps decode-side setup with prefill

The two modes also involve a routing tradeoff. Pull mode allows the router to select a decode instance after prefill completes, which provides greater flexibility for load-aware routing and quality-of-service management. Push mode selects the decode instance earlier so that destination setup can overlap with prefill. In return, under comparable load, the prefill instance can release its KV blocks sooner because the transfer starts as soon as both the prompt KV and destination registration are ready.

Performance data

For evaluation, we used Qwen3-32B model on a 1P1D deployment using Amazon EC2 P5en instances connected with EFA. To isolate P→D transfer performance, we configured the benchmark to disable prefix caching with --no-enable-prefix-caching. This configuration makes the decode node retrieve the full KV cache from the prefill node for every request. Otherwise, overlapping prompts could reuse the decode node’s local cache and bypass the transfer, which would produce misleading comparison results.

The following chart compares TTFT for push and pull KV transfer. We sweep input lengths 1k–16k and request rates of 1–8 queries per second (QPS). At low load and short prompts, the two modes perform almost identically. As QPS and input length grow, pull mode degrades sharply, reaching about 1,744 ms at 8 QPS and 16k. Push mode stays far lower at roughly 540 ms, around 3x reduction. The gap opens because pull mode posts NIXL descriptors inline on the decode worker, synchronously within its engine loop, so that work stalls token generation. Push mode moves it to a background thread, off the critical path.

Figure 5: TTFT for push compared to pull KV transfer across input lengths and request rates (1P1D topology, 128 output tokens, prefix caching disabled on the decode node)

This chart shows TPOT under the same conditions. The pattern mirrors TTFT. At light load, push and pull are close, around 5.6–5.8 ms. As load and input length rise, pull climbs to about 10.4 ms at 4–8 QPS and 16k, while push holds near 7 ms. The reason is that push offloads descriptor preparation and transfer submission from the decode worker. Token generation is not starved, so per-token latency stays flat even at high concurrency and long contexts.

Figure 6: TPOT for push compared to pull KV transfer across input lengths and request rates (1P1D topology, 128 output tokens, prefix caching disabled on the decode node)

How to run benchmark

To reproduce our 1P1D benchmark configuration, one prefill node and one decode node, using Amazon EC2 P5en instances connected with EFA, refer to the detailed instructions in the Reproducing our results guide. The guide covers environment setup, launching the vLLM prefill and decode servers, running the benchmark, and collecting results. The feature can run on other supported configurations, but performance results will vary depending on the hardware, model, workload, and network configuration.

Conclusion

In this post, we showed how the push-based KV connector overlaps prefill computation with decode-side block allocation and registration, removing the post-prefill router round trip and decode-side transfer setup from the critical path. This reduces TTFT and TPOT, particularly at high request rates. In our Qwen3-32B benchmark on a 1P1D deployment using Amazon EC2 P5en instances connected with EFA, push mode provided up to a 3x improvement in TTFT and 30 percent improvement in TPOT compared with pull mode. Results vary by workload and configuration. To use push mode, configure both the prefill and decode servers to use NixlPushConnector instead of NixlConnector.

Choose the push-based connector when early decode node selection is acceptable and lower TTFT is the priority. The pull-based connector remains the better fit for workloads that require bidirectional KV transfer or defer decode-instance selection until after prefill for load-aware routing. vLLM supports both push- and pull-based KV connectors, so you can select the approach that best fits your deployment.

As a future improvement, we are exploring bringing the background NIXL threading model to the pull-mode connector, moving NIXL setup off the critical path so that pull-mode workloads could benefit from the same optimizations. We have opened a pull request to explore this.

Acknowledgments

We thank the vLLM community for their support in maintaining this feature.

About the authors

¿Tiene un proyecto de software o plataforma SaaS en mente?

Hable directamente con nuestros arquitectos de software en SoftAndino. Le brindamos asesoría técnica y cotización inmediata sin compromiso.

Chatear por WhatsApp

Tags: news aws