Si estás comparando TensorRT-LLM vs vLLM, la respuesta práctica no es "¿cuál es más rápido?" Es "¿cuál puede seguir siendo rápido para tu equipo después de que cambien el modelo, la GPU, el patrón de tráfico y los requisitos de servicio?"
TensorRT-LLM suele ser la mejor opción cuando estáis estandarizados en GPUs de NVIDIA, podéis asumir un ciclo de optimización y validación, y necesitáis exprimir el rendimiento más predecible de un conjunto pequeño de modelos de producción. vLLM suele ser la mejor opción cuando necesitáis amplia cobertura de modelos, iteración más rápida, servicio compatible con OpenAI y portabilidad entre más hardware y patrones de despliegue.
Esa es la versión corta. Los errores caros ocurren en el medio: elegir vLLM porque es más fácil de empezar, y luego descubrir que un endpoint de alto volumen necesita una latencia menor de la que puede ofrecer vuestra pila basada primero en Python; o elegir TensorRT-LLM porque un benchmark parecía excelente, y luego darse cuenta de que cada actualización del modelo requiere una ruta más pesada de compilación, pruebas y reversión.
Esta guía compara TensorRT-LLM vs vLLM en rendimiento, portabilidad, mantenimiento, compatibilidad de modelos y riesgo operativo. También te ofrece un plan de benchmark que puedes ejecutar antes de comprometer presupuesto de GPU.
TensorRT-LLM vs vLLM de un vistazo
| Área de decisión | Elige TensorRT-LLM cuando... | Elige vLLM cuando... |
|---|---|---|
| Objetivo de rendimiento | Necesitas inferencia de GPU NVIDIA altamente optimizada para una familia de modelos conocida y una forma de servicio estable. | Necesitas un buen rendimiento general de servicio con menos sobrecarga de compilación y gestión de motores. |
| Estrategia de hardware | Tu flota es solo NVIDIA, a menudo Hopper o posterior, y planificas alrededor de CUDA/NCCL/TensorRT. | Puede que ejecutes en NVIDIA, AMD ROCm, Intel XPU, TPU o entornos mixtos de laboratorio y nube. |
| Cadencia de modelos | Sirves un conjunto pequeño de modelos y puedes validar las compilaciones de motores antes del despliegue. | Pruebas con frecuencia nuevos modelos de Hugging Face, variantes MoE, adaptadores o formatos de cuantización. |
| Perfil del equipo | Tienes ingenieros de infraestructura que pueden hacerse cargo del ajuste de kernels, motores, CUDA y despliegue. | Quieres que los ingenieros de ML publiquen cambios de servicio con Python familiar y APIs compatibles con OpenAI. |
| Riesgo de mantenimiento | Aceptas más trabajo de compilación y compatibilidad a cambio de un control de optimización más ajustado. | Aceptas una menor optimización específica del proveedor a cambio de actualizaciones más rápidas y una cobertura comunitaria más amplia. |
| Mejor primer paso | Haz benchmark después de fijar el modelo, la GPU, el perfil de batch, la longitud de secuencia y la cuantización. | Empieza aquí para exploración, validación de modelos e infraestructura heterogénea. |
El patrón más limpio para muchos equipos no es una elección permanente de una u otra. Empieza con vLLM para validar la demanda, la calidad del modelo, la forma del prompt y la mezcla de tráfico. Mueve solo los endpoints estables, de alto volumen y dependientes de NVIDIA a TensorRT-LLM cuando la mejora medida compense el coste adicional de mantenimiento.
En qué destaca TensorRT-LLM
TensorRT-LLM es la pila de inferencia de LLM de NVIDIA construida sobre TensorRT, CUDA y sistemas GPU de NVIDIA. Está diseñada para inferencia optimizada, no solo para un despliegue sencillo del modelo. La documentación oficial de TensorRT-LLM se centra en la construcción de motores, la ejecución en tiempo de ejecución, el ajuste del rendimiento, la compatibilidad de modelos y la compatibilidad con funciones de GPU de NVIDIA.
La principal ventaja es el control. TensorRT-LLM puede aprovechar rutas de optimización específicas de NVIDIA, incluidas kernels de atención, rutas de cuantización, paralelismo multi-GPU y patrones de despliegue que encajan estrechamente con el hardware de NVIDIA. Si ya planeas ejecutar infraestructura estilo H100, H200, B200 o GB200, TensorRT-LLM debe estar en la lista corta de rendimiento.
La contrapartida es que "optimizado" no significa "gratis". Debes esperar más trabajo en torno a:
- Construir o convertir artefactos del modelo.
- Validar los ajustes del motor para cada modelo y precisión.
- Fijar combinaciones compatibles de CUDA, TensorRT, driver, contenedor y GPU.
- Volver a ejecutar pruebas de aceptación cuando cambien los pesos del modelo, la longitud de contexto, el paralelismo o la cuantización.
- Mantener una ruta de respaldo cuando una variante del modelo aún no sea compatible con tu versión de TensorRT-LLM.
Ese trabajo extra es razonable cuando un endpoint consume suficientes horas de GPU como para que una mejora de un solo dígito porcentual importe, o cuando la previsibilidad de la latencia forma parte del contrato del producto.
En qué destaca vLLM
vLLM es un motor de servicio de LLM de código abierto diseñado para servicio de alto rendimiento, batching continuo, PagedAttention y APIs prácticas compatibles con OpenAI. La documentación del proyecto vLLM hace hincapié en el servicio, el benchmarking, los endpoints compatibles con OpenAI, la cuantización y las opciones de instalación en GPU.
La principal ventaja es la velocidad de iteración. Normalmente puedes poner en marcha un modelo, exponer un servidor compatible con OpenAI, probar tráfico y comparar ajustes de cuantización sin comprometerte con un flujo de trabajo más pesado de motor compilado. Eso hace que vLLM sea un valor predeterminado sólido para equipos que todavía están decidiendo qué modelo, formato de prompt, longitud de contexto o tipo de GPU sobrevive realmente en producción.
vLLM también es más fuerte cuando la portabilidad es un requisito real. Su documentación cubre NVIDIA CUDA, AMD ROCm, Intel XPU, TPU y otras rutas de instalación o integraciones, aunque la paridad de funciones varía según el backend. Eso importa si tu plan de aprovisionamiento incluye capacidad puntual de GPU en la nube, pruebas con AMD, máquinas de laboratorio internas o una futura diversidad de aceleradores.
La contrapartida es que la portabilidad y la iteración rápida pueden ocultar trabajo de ajuste en producción. vLLM todavía necesita una configuración cuidadosa para:
- Tamaño de la caché KV y comportamiento de expulsión.
- Opciones de paralelismo tensorial y paralelismo de tubería.
- Programación de prefill/decode bajo tráfico real.
- Compatibilidad con cuantización.
- Comportamiento en modo CUDA graph o eager.
- Presión de memoria en contexto largo.
- Equidad multiinquilino y control de admisión.
vLLM es más fácil de empezar. No es infraestructura automática.
Comparacion de rendimiento de TensorRT-LLM vs vLLM
Cualquier benchmark útil de TensorRT-LLM vs vLLM tiene que especificar la carga de trabajo. Un benchmark que solo informa tokens por segundo para un modelo en un tamaño de batch puede llevarte por el camino equivocado.
Para el serving de LLM, el rendimiento tiene al menos cinco dimensiones:
| Métrica | Por qué importa | Qué puede distorsionarla |
|---|---|---|
| Tiempo hasta el primer token | La UX del chat interactivo y de los agentes depende de la latencia de respuesta inicial. | Longitud del prompt, programación de prefill, sobrecarga de red, estado de calentamiento. |
| Latencia entre tokens | La calidad del streaming depende de una velocidad de decode constante. | Presión del batch, disposición de la caché KV, cuantización, relojes de la GPU. |
| Throughput | El batch, la resumición y la generación offline dependen del total de tokens por segundo. | Mezcla de solicitudes, longitud de secuencia, concurrencia, configuración de muestreo. |
| Coste por salida aceptada | El coste de negocio depende de respuestas útiles, no de la velocidad bruta de tokens. | Tasa de error, tasa de timeout, reintentos, salidas rechazadas, regresiones de calidad. |
| Latencia de cola operativa | Los usuarios de producción sienten el p95/p99, no solo el throughput promedio. | Llegadas en ráfagas, colas multiinquilino, arranques en frío, recuperación de OOM. |
TensorRT-LLM suele tener el argumento más sólido cuando el benchmark es estrecho, estable y ligado a NVIDIA: una familia de modelos, una clase de GPU, un objetivo de cuantización, una ventana de contexto y una distribución de solicitudes conocida. vLLM suele tener el argumento más sólido cuando el benchmark incluye cambios: cambios de modelo, varios tamaños de modelo, prompts mixtos, experimentos con adaptadores y un equipo que necesita seguir entregando.
No compares un motor TensorRT-LLM altamente optimizado contra un comando de inicio vLLM por defecto y lo llames una decisión de producto. Tampoco compares un servicio vLLM bien ajustado contra un ejemplo genérico de TensorRT-LLM y asumas que la ruta de NVIDIA no puede alcanzar. Ajusta ambos hasta que cada uno refleje el nivel de atención de ingeniería que realmente estás dispuesto a financiar.
Portabilidad: la diferencia oculta
La portabilidad es donde TensorRT-LLM vs vLLM se convierte en una decisión de negocio y no solo de infraestructura.
TensorRT-LLM está estrechamente alineado con NVIDIA. Eso es una fortaleza si tu hoja de ruta también está estrechamente alineada con NVIDIA. Obtienes una pila de proveedor coherente: CUDA, TensorRT, NCCL, contenedores de NVIDIA, funciones de GPU de NVIDIA y guía de rendimiento de NVIDIA. Para empresas que compran clústeres dedicados de GPU, esa coherencia puede reducir la ambigüedad.
vLLM es más amplio. No está igual de optimizado en todos los backends, pero su flujo de trabajo de serving de código abierto está diseñado alrededor de una experimentación más rápida con modelos e infraestructura. Si tu equipo podría probar sistemas AMD de la serie MI300 o MI400, operar en inventario de GPU en la nube alquilado o mantener un despliegue de respaldo en máquinas NVIDIA de commodity, vLLM reduce la probabilidad de que tu capa de serving se convierta en un punto de bloqueo duro.
La regla es simple:
- Si la estandarización del hardware es el plan, TensorRT-LLM puede convertir esa estandarización en ventaja de rendimiento.
- Si la opcionalidad del hardware es el plan, vLLM hace que sea más fácil preservarla.
Aquí también ayuda una base de referencia de modelo/API. Si tu equipo no necesita control directo del kernel, compara TensorRT-LLM autoalojado y vLLM contra una ruta gestionada de API de modelo. Flatkey ofrece a los equipos una capa de acceso compatible con OpenAI para APIs de modelos, de modo que puedas comparar el coste de GPU autoalojada contra el coste y la simplicidad operativa del uso de modelos enrutados. La respuesta correcta puede ser: autoalojar la carga de trabajo estable y de alto volumen, y enrutar la carga de trabajo intermitente o experimental a través de una API.
Mantenimiento: donde aparece la factura
La diferencia de mantenimiento es fácil de subestimar durante una prueba de concepto.
El mantenimiento de TensorRT-LLM tiende a concentrarse en el trabajo de compilación y compatibilidad. Necesitas saber qué arquitecturas de modelo son compatibles, qué ruta de cuantización es válida, si la GPU objetivo y la versión de TensorRT-LLM admiten la funcionalidad que quieres y cómo reconstruir o revertir motores. Esto es manejable para un equipo de infra sólido. Es arriesgado para un pequeño equipo de producto que solo quiere lanzar una funcionalidad de IA.
El mantenimiento de vLLM tiende a concentrarse en las operaciones en runtime y en la disciplina de actualización. Aun así tienes que fijar versiones, validar la compatibilidad de modelos, probar rutas de cuantización y supervisar el comportamiento del serving, pero el ciclo de desarrollo suele estar más cerca de los flujos de trabajo estándar de Python y de serving de modelos. Eso hace que vLLM sea más fácil de entregar a equipos de plataforma de ML que ya trabajan con Hugging Face, Kubernetes y patrones de API compatibles con OpenAI.
Aquí está la lista práctica de mantenimiento:
| Pregunta de mantenimiento | Por qué importa |
|---|---|
| ¿Quién se encarga del bloqueo de versiones y del rollback? | Ambos motores evolucionan rápidamente. Las actualizaciones no probadas pueden cambiar el rendimiento o la compatibilidad. |
| ¿Con qué frecuencia cambian los modelos? | Una alta rotación de modelos favorece a vLLM. Una baja rotación le da a TensorRT-LLM más tiempo para amortizar el esfuerzo de ajuste. |
| ¿Necesita kernels personalizados o una optimización profunda de NVIDIA? | Si es así, TensorRT-LLM se alinea mejor con la ruta de optimización. |
| ¿Necesita amplia cobertura de modelos y backends? | Si es así, vLLM suele reducir la fricción de exploración. |
| ¿Puede ejecutar pruebas de carga antes de cada despliegue? | TensorRT-LLM especialmente lo necesita, pero vLLM también se beneficia de ello. |
| ¿Cuál es su alternativa cuando falla una ruta del motor? | Un segundo motor, un modelo más pequeño o una API de modelo enrutada evitan que las caídas se conviertan en incidentes del producto. |
Compatibilidad de modelos y cuantización
La compatibilidad de modelos cambia rápidamente. Trate cada tabla pública de compatibilidad de modelos como un punto de partida, no como una garantía de despliegue.
Para TensorRT-LLM, consulte la matriz oficial de compatibilidad, los ejemplos de modelos y las notas de la versión antes de comprometerse con un modelo. Preste atención a la arquitectura exacta, la precisión, la receta de cuantización, el grado de paralelismo tensorial, la longitud de contexto y la generación de GPU.
Para vLLM, consulte los modelos compatibles, la documentación de cuantización y el rastreador de incidencias para la familia exacta de modelo y el modo de servicio que planea usar. La ventaja práctica de vLLM es que el soporte de la comunidad a menudo aparece rápidamente para modelos abiertos populares, pero eso no elimina la necesidad de sus propias pruebas de aceptación.
Use esta tabla de cualificación de modelos antes de la decisión entre TensorRT-LLM y vLLM:
| Verificación | Condición de aprobación |
|---|---|
| Compatibilidad de arquitectura | La familia exacta del modelo está documentada o validada en su propia prueba rápida. |
| Formato de pesos | El motor puede cargar sus pesos de origen sin una cadena de conversión frágil. |
| Cuantización | FP8, INT8, INT4, AWQ, GPTQ u otro método es compatible con el modelo y el hardware que realmente va a ejecutar. |
| Longitud de contexto | El contexto objetivo cabe en memoria con la concurrencia esperada y los ajustes de caché KV de producción. |
| Paralelismo | El comportamiento de paralelismo tensorial, paralelismo de pipeline o paralelismo de expertos se valida en su topología de GPU. |
| Streaming | El tiempo hasta el primer token y la latencia entre tokens superan la prueba con formas de prompt reales. |
| Rollback | Puede revertir las versiones del modelo, del motor y del contenedor sin cirugía manual. |
Plan de benchmark: cómo probar TensorRT-LLM vs vLLM
Ejecute el benchmark como una prueba de aceptación de producción, no como una demo.
1. Congelar la carga de trabajo
Defina:
- Nombre del modelo y revisión exacta.
- Modo de precisión o cuantización.
- Tipo y cantidad de GPU.
- Versiones de driver, CUDA, contenedor y motor.
- Objetivo de ventana de contexto.
- Distribución de longitud de prompt.
- Distribución de longitud de salida.
- Objetivos de concurrencia.
- Mezcla de streaming y no streaming.
- Criterios de aceptación de calidad.
Si eso no está fijado, su benchmark de TensorRT-LLM vs vLLM no es reproducible.
2. Probar cuatro formas de tráfico
| Forma de tráfico | Qué revela |
|---|---|
| Baja concurrencia, prompts cortos | Latencia base y sobrecarga de la ruta fría. |
| Alta concurrencia, prompts cortos | Eficiencia del programador y presión de decodificación. |
| Prompts largos, salidas cortas | Rendimiento de prefill y presión de la caché KV. |
| Solicitudes mixtas largas y cortas | Latencia de cola, equidad y comportamiento de la cola. |
3. Medir el costo de salida aceptada
Para cada motor, haga seguimiento de:
- Dólares de GPU por hora.
- Solicitudes completadas.
- Tokens generados.
- Tiempo al primer token p50, p95 y p99.
- Latencia de extremo a extremo p50, p95 y p99.
- Tasa de timeouts y reintentos.
- Eventos de OOM y expulsión.
- Tasa de rechazo de salida por su evaluador o revisión humana.
Luego calcule:
accepted_output_cost =
total_gpu_cost_for_test_window
/ accepted_outputs
Esto es más útil que los tokens por segundo brutos porque incluye salidas fallidas, lentas, reintentadas o rechazadas.
4. Ejecutar una prueba de operaciones
Antes de elegir, simule:
- Rollback del modelo.
- Rollback del contenedor.
- Una falla de GPU o drenaje de nodo.
- Un pico repentino de tráfico 3x.
- Una ráfaga de contexto largo.
- Una mala distribución de prompts que crea más salidas largas de lo esperado.
- Una actualización de modelo que cambia el formato de los pesos o el comportamiento del tokenizador.
Si TensorRT-LLM gana en rendimiento bruto pero su equipo no puede reconstruir y revertir motores de forma segura, el benchmark no capturó el riesgo de producción. Si vLLM gana en velocidad de iteración pero la latencia p99 se rompe con su tráfico real, el benchmark no capturó la experiencia del usuario.
Matriz de decisión
| Situación | Mejor opción predeterminada |
|---|---|
| Exploración temprana del producto | vLLM |
| Cambios frecuentes de modelo | vLLM |
| Servicio local compatible con OpenAI y configuración rápida | vLLM |
| Planificación para hardware heterogéneo | vLLM |
| Endpoint estable de alto volumen en GPUs NVIDIA | TensorRT-LLM |
| Serving sensible a la latencia con fuerte control de la infraestructura NVIDIA | TensorRT-LLM |
| Flota empresarial de GPU estandarizada en NVIDIA | TensorRT-LLM |
| Equipo pequeño sin ingenieros de inferencia dedicados | vLLM o una línea base de API de modelo |
| Necesidad de comparar el autoalojamiento frente a APIs gestionadas | Ejecutar ambos frente a una línea base de modelo/API de Flatkey |
Para un servicio de producción estrecho y de alto volumen, TensorRT-LLM puede valer el esfuerzo adicional. Para un equipo de producto de IA que aún está aprendiendo sobre su carga de trabajo, vLLM suele ser la mejor primera capa de serving.
Cómo encaja Flatkey en la decisión
Flatkey no sustituye a TensorRT-LLM ni a vLLM cuando necesitas control directo de tus propias GPUs. Es la línea base con la que deberías compararte antes de pasar semanas ajustando la inferencia autoalojada.
Usa Flatkey como línea base de modelo/API cuando:
- Tu carga de trabajo es intermitente y no justifica capacidad de GPU reservada.
- Necesitas acceso a múltiples proveedores de modelos desde una única ruta compatible con OpenAI.
- Quieres comparar el costo de GPU autoalojada frente al costo de API por salida aceptada.
- Necesitas un respaldo cuando una pila de serving autoalojada está caída, sobrecargada o esperando una migración de modelo.
- A tu equipo le importa más la latencia y la fiabilidad del producto que el control a nivel de kernel.
Para muchos equipos, la arquitectura madura es por capas:
- Usa Flatkey u otra ruta de API de modelo gestionada para experimentos, manejo de picos y respaldo.
- Usa vLLM para inferencia autoalojada portátil y exploración de modelos.
- Usa TensorRT-LLM para los pocos endpoints vinculados a NVIDIA en los que la mejora medida del rendimiento justifique el mantenimiento continuo.
Errores comunes
Error 1: Elegir solo a partir de benchmarks públicos
Los resultados públicos de benchmarks de TensorRT-LLM vs vLLM son señales útiles, pero rara vez coinciden con tu modelo, GPU, mezcla de prompts, cuantización y SLA. Úsalos para formar hipótesis, no decisiones finales.
Error 2: Ignorar la latencia p95 y p99
Los tokens por segundo promedio pueden mejorar mientras la experiencia del usuario empeora. Rastrea siempre el tiempo hasta el primer token, la latencia end-to-end p95/p99 y la tasa de timeouts.
Error 3: Tratar vLLM como la opción "fácil para siempre"
vLLM es más fácil para empezar, pero el serving en producción sigue necesitando fijación de versiones, observabilidad, control de admisión, planificación de memoria y pruebas de fallos.
Error 4: Tratar TensorRT-LLM como la opción "rápida por defecto"
TensorRT-LLM puede ser muy fuerte en GPUs NVIDIA, pero el valor proviene de un ajuste correcto, rutas de modelo compatibles y validación disciplinada.
Error 5: Olvidar la línea base de la API
Si la carga de trabajo es intermitente, de bajo volumen o aún está cambiando, una ruta de API de modelo gestionada puede superar al autoalojamiento cuando incluyes el tiempo de ingeniería, el costo de GPU ociosa y el riesgo operativo.
Lecturas relacionadas
- Si estás eligiendo primero un framework de serving de código abierto, lee vLLM vs SGLang.
- Si todavía estás dimensionando el hardware, empieza con Mejor GPU para inferencia LLM.
- Si la topología del clúster es el obstáculo, usa la guía de arquitectura de clústeres GPU.
- Si la pregunta del presupuesto es lo primero, compara precios de alquiler de GPU y TCO de clúster GPU.
- Si estás decidiendo si autoalojar o no, lee GPU cloud vs modelo API.
Preguntas frecuentes
¿TensorRT-LLM es más rápido que vLLM?
A veces, especialmente para cargas de trabajo estables en GPUs NVIDIA después de un ajuste adecuado. Pero "TensorRT-LLM es más rápido" no es una afirmación general segura. El resultado depende de la arquitectura del modelo, el tipo de GPU, la cuantización, la longitud de la secuencia, la forma del batch, la concurrencia y cuánto ajuste recibe cada motor.
¿Es vLLM más fácil de desplegar que TensorRT-LLM?
Por lo general sí para el despliegue inicial y la experimentación con modelos. El servidor compatible con OpenAI y el flujo de trabajo centrado en Python de vLLM facilitan empezar. TensorRT-LLM a menudo requiere más gestión del motor, del contenedor y de la compatibilidad.
¿Debería usar TensorRT-LLM o vLLM para inferencia en H100?
Empieza con vLLM si aún estás explorando el modelo o la carga de trabajo. Prueba TensorRT-LLM cuando el endpoint sea estable, de alto volumen y la optimización específica para NVIDIA pueda compensar el mantenimiento adicional.
¿Cuál es mejor para inferencia multi-GPU?
Ambos pueden servir cargas de trabajo multi-GPU, pero la cuestión operativa es la topología y la propiedad. Si tu equipo puede ajustar en profundidad el paralelismo específico de NVIDIA, TensorRT-LLM puede resultar atractivo. Si necesitas iteración de modelos más rápida y patrones de serving más amplios, vLLM suele ser el punto de partida más sencillo.
¿Cuál es mejor para GPUs AMD?
vLLM es la opción práctica por defecto porque documenta la instalación de ROCm y rutas orientadas a AMD. TensorRT-LLM es una pila de NVIDIA y debe tratarse como específica de NVIDIA a efectos de planificación.
¿Puedo usar tanto TensorRT-LLM como vLLM?
Sí. Muchos equipos deberían hacerlo. Usa vLLM para exploración y cobertura amplia de serving, y luego mueve endpoints específicos de alto volumen en NVIDIA a TensorRT-LLM después de que el benchmark demuestre que la mejora vale el mantenimiento.
Conclusión
La mejor decisión entre TensorRT-LLM vs vLLM depende de la carga de trabajo:
- Elige vLLM cuando la portabilidad, la iteración del modelo y la simplicidad del servicio sean lo más importante.
- Elige TensorRT-LLM cuando un endpoint estable vinculado a NVIDIA necesite el rendimiento optimizado más alto que puedas justificar.
- Mantén una base de modelo/API mediante Flatkey cuando la complejidad del autoalojamiento pueda superar el control de la GPU.
No tomes la decisión a partir de un único gráfico de benchmark. Tómala a partir de tu modelo, tu topología de GPU, tu distribución de tráfico, tu plan de fallos y la capacidad de tu equipo para mantener el stack después de la primera demostración exitosa.
Fuentes
- Documentación de NVIDIA TensorRT-LLM
- Resumen de la arquitectura de TensorRT-LLM
- Matriz de compatibilidad de TensorRT-LLM
- Resumen de rendimiento de TensorRT-LLM
- Documentación de vLLM
- Servidor compatible con OpenAI de vLLM
- Documentación de instalación de GPU de vLLM
- Documentación de cuantización de vLLM
- Artículo de vLLM: Efficient Memory Management for Large Language Model Serving with PagedAttention
