Kubernetes registró 1,2 millones de despliegues de LLM el trimestre pasado, según datos de CNCF, pero el 80% seguían atrapados en silos de llama.cpp.
LLMKube v0.6.0 lo destroza todo. Este operador de código abierto, antes obsesionado solo con modelos GGUF, ahora engancha cualquier motor de inferencia que le lances. ¿vLLM? Listo. ¿Text Generation Inference? Hecho. Hasta locuras como PersonaPlex de NVIDIA para chats de voz con latencia por debajo de 300 ms.
El mercado lo pide a gritos: los motores de inferencia se han fragmentado. vLLM acapara el 45% en benchmarks de throughput, TGI domina las integraciones de Hugging Face. ¿Atar operadores a un solo backend? Eso es mentalidad de 2023. El giro de LLMKube recuerda a la explosión de operadores en Kubernetes post-2018, cuando cert-manager liberó la automatización de certificados para todos.
¿Qué cambió bajo el capó?
Antes, el controlador de LLMKube tenía llama.cpp hardcodeado por todos lados: imágenes de contenedor, probes, argumentos. ¿Querías vLLM? Arma tu propio Deployment. Un dolor.
Ahora, una interfaz limpia RuntimeBackend. Cada motor la implementa:
type RuntimeBackend interface { ContainerName() string DefaultImage() string DefaultPort() int32 BuildArgs(isvc, model, modelPath, port) []string BuildProbes(port) (startup, liveness, readiness) NeedsModelInit() bool }
El controlador resuelve según el campo runtime del CRD. llama.cpp por defecto. Los demás encajan vía un switch. ¡Pum! Intercambiable.
Lo probé yo mismo. Encendí PersonaPlex en mi RTX 5060 Ti casera. Es una bestia speech-to-speech de 7B de NVIDIA, basada en Moshi, con latencia de interrupción por debajo de 300 ms. Tripas en PyTorch, probes WebSocket, tokens de HF. A años luz del minimalismo C++ de llama.cpp.
¿El CRD? Sencillo como el pan:
spec:
runtime: personaplex
image: registry.defilan.net/personaplex:7b-v1-4bit-cuda13
personaPlexConfig:
quantize4Bit: true
resources:
gpu: 1
memory: "32Gi"
El controlador inyecta python -m moshi.server, probes TCP en 8998, salta la init (el modelo lo baja de HF al arrancar), reclama la GPU. Corriendo en minutos. Chateando IA de voz en tiempo real en hardware de consumo, gestionado como generación de texto.
Por qué vLLM en Kubernetes por fin tiene sentido
vLLM lideraba las peticiones en GitHub para LLMKube. No sorprende: PagedAttention aplasta a llama.cpp en throughput, 2-3x tokens/seg en mis pruebas con TinyLlama.
La v0.6.0 lo integra con VLLMConfig: maxModelLen, dtype, tensor-parallel. Trae endpoint /v1 compatible con OpenAI. Lancé TinyLlama-1.1B:
spec:
runtime: vllm
vllmConfig:
maxModelLen: 2048
dtype: float16
resources:
gpu: 1
memory: "8Gi"
Argumentos auto-generados: --model, --max-model-len, cuantización. Probes HTTP en 8000. Token de HF desde Secret. Dos minutos y endpoint vivo. Dato de mercado: vLLM con 60% de adopción en inferencia prod (según Artificial Analysis) ahora aterriza bien en K8s.
TGI va a la par: bitsandbytes, GPTQ, AWQ. Sin init; lo baja del Hub. Métricas HPA automáticas: vllm:num_requests_running, tgi:queue_size. Sin parches.
¿Runtime genérico? Tu comodín. Apunta a cualquier imagen Docker, define args/probes/env. El controlador maneja GPU, servicio, escalado.
¿Es este el estándar de LLM en Kubernetes que esperábamos?
Mira, LLMKube no es el primero: KServe existe. Pero son bestias hinchadas multi-framework. ¿LLMKube? Operador liviano, CRD-first, nativo en GPU. Cinco backends de fábrica, docs para más.
Mi veredicto: predicción audaz. Para Q4 2025, el 30% de despliegues empresariales de LLM en K8s pasarán por operadores intercambiables como este. ¿Por qué? Costos. Sharding en single-GPU (nuevas imágenes CUDA 13 para RTX 50-series), tweaks Helm air-gapped, dashboards Grafana trackeando tokens/seg. Madurez operativa.
Crítica al hype: devs venden “cualquier motor”, pero ¿agregar uno? Implementa la
