Cuándo conviene un plano de control de inferencia en Kubernetes: llm-d v0.8

Estás eligiendo entre un plano de control de inferencia en Kubernetes y motores puros. El equilibrio es aritmético: resta el coste de una interrupción del plano de control al código de pegamento que elimina; un resultado positivo significa adoptar el plano de control. El coste por token deriva del trabajo eliminado: menos componentes, actualizaciones más cortas, menos tiempo de incidente. Quédate con motores puros cuando un motor estable y actualizaciones propias sean más baratos que una dependencia de plano de control. Nombra el modo de fallo que tu equipo puede asumir. Un plano de control justifica su lugar solo cuando el código eliminado es recurrente, no puntual.

El estado de producción cambia el coste de la interrupción

llm-d v0.8 es el punto de referencia porque su Flow Control, Batch Gateway y rutas multimodales están en producción, no son experimentales. El estado de producción convierte la dependencia en una línea presupuestaria. Un plano de control que solo enruta tráfico es más fácil de eludir. Uno que gestiona trabajos por lotes, control de admisión y rutas multimodales es más difícil de reemplazar sin romper SLOs.

La variedad de motores es el primer coste que hay que medir. llm-d v0.8 trata SGLang como un motor de primera clase junto a vLLM en la mayoría de las rutas soportadas. Múltiples motores multiplican la superficie de enrutamiento: puntos de acceso específicos por modelo, políticas de escalado y etiquetas de imagen, todo necesita un único responsable. El caso multi-motor se convierte en una capa de enrutamiento, no en un fork del motor.

Aplica la prueba de adopción de cinco preguntas

Aplica la prueba de adopción de cinco preguntas antes de añadir la dependencia. Cada elemento es un coste que puedes verificar en un minuto; guarda la lista junto al runbook. Trátala como una verificación de costes pre-despliegue.

• Número de motores: ¿ejecutas varios motores de inferencia? El plano de control absorbe las diferencias de enrutamiento y escalado.
• Tamaño de lote cercano o superior a 50,000 solicitudes: el Batch Gateway de llm-d v0.8 expone puntos de acceso estilo OpenAI /v1/batches y /v1/files, con un tope de trabajo en ese tamaño.
• SLOs de control de flujo: la admisión y la backpressure se distribuyen entre puntos de acceso; pertenecen a un lugar compartido.
• Necesidad de P/D de imagen y texto: ¿necesitas prefill/decode desacoplado para modelos de imagen y texto?
• Propiedad de actualizaciones de imagen: ¿tú gestionas las actualizaciones de imagen del motor en lugar de seguir una imagen del plano de control?

Adóptalo cuando al menos dos elementos sean ciertos y el coste de interrupción del plano de control sea inferior al coste del código de pegamento. Menos elementos debilitan la aritmética. El umbral de dos elementos evita que la decisión dependa de una sola comodidad.

Calcula el coste del trabajo por lotes y de imagen

El trabajo por lotes es el coste más fácil de calcular: la subida de archivos, el seguimiento de trabajos, la política de reintentos y el manejo de finalización son con estado. Cuando ese estado vive en un plano de control, el servidor de API se mantiene fino. Un sidecar que construye estado de trabajo, reintentos y manejo de archivos es el trabajo que el plano de control elimina.

llm-d v0.8 establece la imagen GPU predeterminada como la compilación upstream de vLLM sin modificar vllm/vllm-openai:v0.23.0. Elimina las imágenes personalizadas llm-d-rocm, llm-d-xpu y llm-d-cuda-gb200. El PR #1791 cambia las plataformas de llm-d al uso directo de la imagen upstream de vLLM, no a compilaciones personalizadas construidas por llm-d. El cambio de imagen traslada el riesgo de lanzamiento del equipo del plano de control al flujo de lanzamientos del motor. Sigue los lanzamientos upstream del motor sin esperar a una imagen del plano de control, y tu ruta de actualización será más corta. De lo contrario, el plano de control añade una dependencia de lanzamiento a cada cambio del motor.

llm-d v0.8 ahora documenta el servicio multimodal en producción, con rutas separadas de prefill/decode para modelos de visión y texto como LLaVA y Qwen-VL. Prefill y decode tienen formas de recursos diferentes, por lo que una ruta separada cambia el dimensionado de nodos, la programación y el aislamiento de fallos. Los modelos de esa clase en la hoja de ruta hacen que el plano de control dé forma a la topología de servicio, no solo enrute tokens de texto.

Que el coste de la interrupción decida

Un plano de control es una dependencia compartida. Su caída puede eliminar el enrutamiento, la admisión o el estado de lotes de todos los motores que hay detrás. El coste de la interrupción incluye admisión perdida, trabajos por lotes detenidos y trabajo de re-enrutamiento durante el incidente. La pregunta es si ese fallo es más barato que los modos de fallo que reemplaza.

Calcula primero el coste de la alternativa. Un despliegue puro es más barato cuando la carga de trabajo es un motor, una imagen y una ruta de actualización corta. Un despliegue con múltiples motores, trabajos por lotes y rutas de imagen y texto tiene mucho código personalizado, y el plano de control está haciendo trabajo real.

Ejecuta la prueba de fiabilidad en staging antes de producción: elude el plano de control durante un incidente, haz canary de una imagen de motor sin un lanzamiento del plano de control, restaura el estado de lotes sin reconstruir metadatos de trabajo y mide el tiempo de recuperación. Cualquier paso fallido significa planificar la ruta de incidente antes del despliegue. El resultado es una ruta de incidente conocida, no una esperanza.