La prueba del plugin de vLLM para aceleradores no NVIDIA

Estás decidiendo si pilotar o desplegar en flota un acelerador no NVIDIA. El intercambio es entre tiempo activo de la flota y fricción de liberación: un build del plugin por cada release upstream, cero parches al núcleo, un contrato de scheduler. Si fallas en cualquiera de esos objetivos, el acelerador es una pieza de laboratorio, no hardware de flota.

vLLM incorporó el mecanismo de plugin de hardware en mayo de 2025, con vllm-ascend y vllm-spyre entre los usuarios iniciales. Tenstorrent, fabricante de aceleradores no NVIDIA, ahora tiene soporte de vLLM a través de un nuevo vLLM TT Plugin que hace disponibles los aceleradores de Tenstorrent para vLLM como un plugin de plataforma out-of-tree. Trata los backends de hardware como una superficie de liberación separada, de modo que tu flota tenga que sobrevivir tanto a la línea de releases del núcleo como a la línea de releases del plugin.

La restricción sorprendente es el scheduler: el scheduler de Tenstorrent no combina el trabajo de prefill y decode en el mismo batch. Las demos de chip responden a una pregunta: ¿puede el hardware ejecutar el modelo? El serving de producción pregunta si la flota puede absorber actualizaciones, fallos y cambios de tráfico sin un parche a medida. El plugin es la capa donde esas preguntas se encuentran, y una capa frágil hace que el benchmark del chip desaparezca frente a tu calendario de releases.

En el caso de Tenstorrent, el backend mantiene la lógica específica de TT fuera del codebase central de vLLM. El punto de entrada platform_plugin() del plugin devuelve TTPlatform solo cuando el paquete ttnn puede importarse. Ambos detalles reducen la probabilidad de que un cambio del vendor termine en el camino central.

Evalúa el plugin antes de comprometer espacio en rack

Usa la lista de verificación de cinco puntos antes de comprometer hardware. Cada elemento se corresponde con un modo de fallo que puedes cuantificar: deriva de releases, parches ocultos al núcleo, builds no reproducibles, desajustes de carga de trabajo y rotura de clientes.

• Cadencia upstream: compara la última tag del plugin con la última tag del núcleo.
• Aislamiento del núcleo: busca en el árbol central símbolos específicos del vendor y confirma que están ausentes.
• Fijación de builds: lee el instalador para una versión del núcleo fijada y un objetivo de build que puedas reproducir.
• Restricciones del scheduler: lee la documentación del scheduler sobre soporte de batches mixtos de prefill y decode.
• Compatibilidad de API: compara el esquema del endpoint con el contrato de serving que tus clientes ya utilizan.

Un plugin rezagado convierte cada actualización en un fork; un símbolo del vendor en el árbol central pone el roadmap de otro en tu cola de parches; un build que no puedes reproducir no es una dependencia de producción. Las restricciones del scheduler son el elemento que más equipos omiten: un backend puede pasar las verificaciones anteriores y aun así fallar tu carga de trabajo, así que registra la mezcla de solicitudes esperada en el plan de pilotaje y compara el comportamiento de batch observado con la documentación.

La lista de verificación es el lado barato del intercambio. No demuestra que el chip sea rápido; demuestra que el stack de serving puede llevar el chip a través del próximo ciclo de releases y pasar de un pequeño pilotaje a una flota completa antes de que el hardware se entregue.

La compatibilidad de API es la puerta orientada al cliente. Si el esquema del endpoint cambia, tus clientes se rompen antes que la flota. Compara el esquema del endpoint del plugin con el contrato de serving que tus clientes ya utilizan, y revisa siempre el diff con el equipo de plataforma antes de que termine la revisión del pilotaje.

Un fallo común es un backend que funciona en una demo pero se rompe en una flota. La demo usa un modelo fijo, un tamaño de batch fijo y una versión del núcleo fija; la flota usa todos a la vez. La prueba existe para exponer esa brecha antes del despliegue en flota.

Los builds fijados son donde las flotas se rompen

El instalador de Tenstorrent compila vLLM versión 0.26.0 desde el código fuente usando VLLM_TARGET_DEVICE=empty. Una versión diferente del núcleo convierte el plugin en una dependencia fijada.

Registra la versión fijada en tu manifiesto de flota antes del primer pilotaje. Cuando el plugin pase a una nueva versión del núcleo, necesitas una ruta de migración, no una recompilación sorpresa.

Los límites del scheduler son el costo oculto

Esa restricción cambia el modelo de throughput para cargas de trabajo mixtas, así que prueba la mezcla exacta de solicitudes que esperas en producción.

La cobertura de modelos es una señal secundaria. El plugin de Tenstorrent actualmente sirve modelos multimodales que incluyen Llama 3.2 Vision, Qwen-VL, Qwen 3.6, Mistral 3 y Gemma 3. El tráfico solo de texto hace que esa lista importe menos que el comportamiento del scheduler.

Mantén la documentación del scheduler en la lista de verificación de despliegue, y ejecuta la prueba de carga mixta antes de que se envíe el pedido de hardware de la flota de inferencia.