La integración de modelos de lenguaje de gran escala (LLM) en entornos productivos plantea retos que van más allá de levantar un contenedor. La gestión de drivers GPU, el caché de modelos, la exposición segura de endpoints y la escalabilidad requieren una orquestación nativa en Kubernetes. NVIDIA NIM, combinado con el NIM Operator, ofrece una capa de abstracción que permite a los equipos de plataforma declarar el estado deseado del servicio de inferencia sin tener que gestionar manualmente cada recurso de Kubernetes. En este artículo exploramos un enfoque técnico y empresarial para desplegar NIM en clústeres Kubernetes, asumiendo que el lector tiene experiencia básica con Helm, kubectl y GPU en la nube o on-premise. Además, mostraremos cómo este tipo de arquitectura se integra con servicios de aplicaciones a medida, inteligencia artificial y otras soluciones que Q2BSTUDIO implementa para sus clientes.
Antes de comenzar, es fundamental validar que el clúster cumple los requisitos mínimos: versión de Kubernetes 1.26 o superior, Helm 3, acceso administrativo, nodos con GPU NVIDIA compatibles (por ejemplo, A100, H100, L40S), y una suscripción activa a NVIDIA AI Enterprise o acceso al NGC Developer Program. La instalación del GPU Operator es un paso previo obligatorio, ya que se encarga de los drivers, el runtime de contenedores y la exposición de los recursos GPU como recursos extendidos de Kubernetes. Sin esta base, el NIM Operator no podrá programar los pods correctamente. Una vez validado que los nodos tienen GPU asignables (kubectl get nodes -o custom-columns='NODE:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu'), podemos proceder con la instalación del GPU Operator usando Helm: helm repo add nvidia y helm upgrade --install gpu-operator nvidia/gpu-operator --namespace gpu-operator --wait. La versión recomendada en el momento de escribir este artículo es v26.3.3. Confirmar que el validador de CUDA se complete sin errores es crucial antes de continuar.
Con el GPU Operator operativo, instalamos el NIM Operator en su versión 3.1.1. Creamos el namespace nim-operator y desplegamos: helm upgrade --install nim-operator nvidia/k8s-nim-operator --namespace nim-operator --version 3.1.1 --wait. Verificamos que los Custom Resource Definitions (CRDs) NIMCache y NIMService estén registrados. A continuación, configuramos la autenticación NGC: necesitamos dos secrets en el namespace de trabajo. El primero es un secret de registro Docker (ngc-secret) para que kubelet pueda descargar las imágenes de contenedor desde nvcr.io. El segundo es un secret genérico (ngc-api-secret) que almacena la clave API de NGC, utilizada por el job de caché para descargar los artefactos del modelo. Es importante señalar que estos secrets solo autentican la descarga de imágenes y modelos, no protegen el endpoint de inferencia. Para la seguridad del tráfico de aplicación, se debe implementar TLS, autenticación OIDC, API Gateway o malla de servicios. En Q2BSTUDIO, cuando trabajamos con clientes que necesitan ciberseguridad en sus despliegues de IA, recomendamos mantener el servicio interno (ClusterIP) y usar un ingress controlado con políticas de autenticación y rate limiting.
El siguiente paso es diseñar el caché persistente del modelo. El recurso NIMCache lanza un Job de Kubernetes que descarga los perfiles de modelo compatibles en un volumen persistente. Esto evita que cada pod de inferencia tenga que descargar el modelo completo al arrancar, reduciendo drásticamente el tiempo de inicialización. La configuración típica para un modelo como Llama 3.2 1B incluye un PVC de 80 GiB con modo de acceso ReadWriteOnce. En entornos productivos donde se necesitan múltiples réplicas en diferentes nodos, se debe evaluar si el sistema de almacenamiento soporta ReadWriteMany o si se puede usar un caché compartido a través de NFS. El operador también permite filtrar perfiles de motor (por ejemplo, tensorrt_llm) para evitar descargar variantes innecesarias. Una vez que el NIMCache alcanza el estado Ready, podemos desplegar el NIMService. Este recurso crea un Deployment, un Service (por defecto ClusterIP) y configura los health probes (liveness, readiness y startup) con valores por defecto que permiten hasta 20 minutos para la inicialización del modelo. Es importante no deshabilitar estos probes, sino ajustar el startupProbe si el modelo tarda más en cargar.
Para probar el endpoint, usamos port-forwarding: kubectl port-forward service/ 8000:8000. Luego verificamos los endpoints /v1/health/live, /v1/health/ready y /v1/models. Una solicitud de chat completions debe devolver una respuesta JSON válida. Si el readiness falla pero el liveness funciona, el modelo aún se está cargando. En producción, la exposición externa debe hacerse mediante un Ingress con TLS y autenticación. El NIM Operator puede generar un Ingress automáticamente si se configura spec.expose.router.ingress. Sin embargo, la autenticación del cliente sigue siendo responsabilidad del operador de la plataforma. Recomendamos implementar NetworkPolicy para restringir el tráfico este-oeste, permitiendo solo a namespaces etiquetados acceder al puerto 8000 del NIM Service.
La escalabilidad horizontal se habilita mediante el campo spec.scale.hpa, que crea un HorizontalPodAutoscaler basado en métricas personalizadas como vllm:num_requests_waiting. Para que esto funcione, el clúster debe tener un Prometheus Adapter configurado y el ServiceMonitor del NIM Operator correctamente etiquetado. Antes de activar el autoscaling, es crítico verificar que hay suficientes GPUs disponibles y que el almacenamiento del caché permite montajes concurrentes en múltiples nodos. La gestión de actualizaciones del operador y del modelo sigue un protocolo cuidadoso: antes de actualizar el NIM Operator, exportamos las values actuales y los recursos personalizados. La actualización del modelo implica crear un nuevo NIMCache con el nuevo tag de imagen, esperar a que esté listo, luego actualizar el NIMService apuntando al nuevo caché y a la nueva imagen. Mantenemos el caché antiguo hasta que el rollback sea seguro. El rollback del operador se realiza con helm rollback, pero hay que verificar la compatibilidad de CRDs porque Helm no las retrocede automáticamente.
Algunos fallos comunes incluyen ImagePullBackOff por credenciales NGC incorrectas, NIMCache en Pending por StorageClass no disponible, o pods en CrashLoopBackOff por perfil de modelo incompatible con la GPU. La secuencia rápida de diagnóstico es: kubectl get nimcache,nimservice -n , luego eventos y logs del job de caché y del pod de inferencia. En Q2BSTUDIO, combinamos estos despliegues con soluciones de BI / Power BI para monitorizar el rendimiento de los modelos en tiempo real, y con agentes de IA que automatizan tareas de mantenimiento predictivo. La arquitectura descrita permite además integrar servicios cloud como AWS o Azure para el almacenamiento persistente y la escalabilidad, tal como ofrecemos en nuestros servicios cloud. En conclusión, desplegar NIM con NIM Operator en Kubernetes no es solo un ejercicio técnico, sino una decisión estratégica que acelera la puesta en producción de modelos de IA con garantías de seguridad, observabilidad y escalabilidad. La clave está en construir una base sólida (GPU Operator + caché persistente + controles de acceso) y luego añadir capacidades de forma incremental. Con el apoyo de un equipo experto como Q2BSTUDIO, las organizaciones pueden transformar la inteligencia artificial en un activo operativo confiable.
