Lista de verificación de migración a TensorRT-LLM 1.2

Si su servicio aún llama a LLM(backend='tensorrt'), la llamada genera un ValueError. La operación es sustracción: TensorRT-LLM 1.2 eliminó la ruta de compilación offline de TensorRT, pasó a un modelo de ejecución nativa de PyTorch, descartó la ruta de ejecución de TensorRT y dejó PyTorch como único backend de ejecución. Ya no instala la dependencia pip tensorrt. TensorRT-LLM 1.2 se lanzó en julio de 2026. Espere menos piezas móviles y una reescritura forzada de la ruta de servicio.

El paso de compilación ha desaparecido, no está deprecado

TensorRT-LLM 1.2 eliminó las herramientas de línea de comandos trtllm-build, trtllm-refit y trtllm-prune. Los scripts de compilación que esperan un artefacto de motor separado ya no tienen nada que invocar. El flujo anterior asumía una pipeline por etapas: preparar el modelo y luego compilarlo en un motor de servicio. Esa suposición se rompe. Una pipeline de compilación que aún espera un archivo de motor falla antes de que el modelo sirva.

Trate esto como una actualización del motor de inferencia, no como un incremento de versión. El antiguo archivo de motor era un objeto desplegable. La nueva ruta cambia lo que el servicio espera al inicio. Marque los archivos de motor en el registro de artefactos como deprecados. Reescriba las notas de versión que aún dicen compilar primero. El stack de servicio ahora se comporta como un runtime de servicio de modelos.

TensorRT-LLM 1.2 eliminó los scripts convert_checkpoint.py específicos de cada modelo. Los pasos de conversión de checkpoint deben sustituirse por la nueva ruta de ejecución. La documentación de incorporación de modelos, los wikis internos y los runbooks aún pueden describir un paso que ya no existe. Trate esa documentación como obsoleta hasta que alguien la reescriba según el nuevo modelo de ejecución.

La cadena de backend ahora genera un error

El código hace explícito el fallo. Convierte una mala configuración silenciosa en un error de inicio. Las pruebas de humo deben fallar rápido, no después de un despliegue largo. Cambie el código a la ruta nativa de PyTorch. Trate el ValueError como una puerta de liberación.

Convierta ese error en una prueba, no en un incidente. Añada una comprobación de inicio que rechace la cadena de backend anterior antes de que el servicio se enlace. Añada una regla de lint de configuración que marque el valor eliminado. Las imágenes base compartidas deben incluir la comprobación para que cada servicio aguas abajo la herede. El fallo debe ser visible en el registro de despliegue, no en una página de error orientada al cliente.

Audite cada cadena de backend en el almacén de configuración antes del despliegue. La selección de backend suele estar en feature flags, variables de entorno o manifiestos de servicio. Cada uno de ellos puede ocultar la cadena anterior. Un grep en todo el repositorio inicia la auditoría, pero el almacén de configuración contiene la verdad de producción.

La lista de dependencias se reduce

La lista de dependencias cambia. Eso cambia las compilaciones de imagen, los lockfiles y las revisiones de cadena de suministro. Separe cualquier pin de tensorrt en la imagen base del stack de servicio. El stack de servicio no debería llevar una dependencia que ya no utiliza.

Actualice los lockfiles antes de actualizar el servicio. Trace la capa que añade tensorrt cuando el escáner de imagen lo informe como presente. Corrija el manifiesto cuando el proceso de lista de materiales aún lo incluya. Una dependencia obsoleta no debería permanecer en la lista de materiales. Trátese como una limpieza de cadena de suministro, no solo como un cambio de código.

Espere trabajo, no tarifas de licencia: tiempo de auditoría, tiempo de pruebas y planificación de rollback. El alcance es claro, pero afecta a las partes del stack que normalmente solo cambian cuando una liberación fuerza una reescritura. Presupueste la auditoría antes del despliegue.

Ejecute la auditoría previa a la actualización

Utilice la lista siguiente como una pasada previa a la actualización. Cada elemento se ejecuta rápidamente y se corresponde con una pieza eliminada del antiguo flujo de trabajo. Ejútela para detectar la ruta anterior antes de que llegue a producción.

• Busque en configuraciones y código backend='tensorrt'; sustituya la llamada por la ruta nativa de PyTorch.
• Elimine trtllm-build, trtllm-refit y trtllm-prune de los scripts de compilación y las pipelines.
• Elimine tensorrt de las dependencias fijas y las capas de imagen.
• Elimine o redirija los pasos convert_checkpoint.py específicos de cada modelo.
• Ejecute una solicitud de humo contra la nueva ruta y confirme una respuesta.

La lista se mantiene corta porque las eliminaciones son explícitas. Demuestre que la sustitución sirve su tráfico con latencia y tasas de error aceptables en un canary antes de ampliar el despliegue. Mantenga la imagen anterior disponible para rollback hasta que la nueva ruta haya gestionado tráfico real.

Mantenga la puerta de validación estrecha. Compruebe que el servicio se inicia, que el modelo se carga, que una solicitud devuelve respuesta y que los registros muestran la ruta de ejecución esperada. Envíe una pequeña porción de tráfico a un carril canary primero. Sin un carril canary, ejecute una prueba de carga manual contra el canary antes de promover la imagen. No intente demostrar que la ruta anterior está muerta. Demuestre que la nueva ruta es segura.