La integració de models de llenguatge de gran escala (LLM) en entorns productius presenta reptes que van més enllà d’aixecar un contenidor. La gestió de drivers GPU, la memòria cau de models, l’exposició segura d’endpoints i l’escalabilitat requereixen una orquestració nativa a Kubernetes. NVIDIA NIM, combinat amb el NIM Operator, ofereix una capa d’abstracció que permet als equips de plataforma declarar l’estat desitjat del servei d’inferència sense haver de gestionar manualment cada recurs de Kubernetes. En aquest article explorem un enfocament tècnic i empresarial per desplegar NIM en clústers Kubernetes, assumint que el lector té experiència bàsica amb Helm, kubectl i GPU al núvul o on-premise. A més, mostrem com aquesta arquitectura s’integra amb aplicacions a mida, intel·ligència artificial i altres solucions que Q2BSTUDIO implementa per als seus clients.
Abans de començar, és fonamental validar que el clúster compleix els requisits mínims: versió de Kubernetes 1.26 o superior, Helm 3, accés administratiu, nodes amb GPU NVIDIA compatibles (p. ex., A100, H100, L40S), i una subscripció activa a NVIDIA AI Enterprise o accés al NGC Developer Program. La instal·lació del GPU Operator és un pas previ obligatori, ja que s’encarrega dels drivers, el runtime de contenidors i l’exposició dels recursos GPU com a recursos estesos de Kubernetes. Sense aquesta base, el NIM Operator no podrà programar els pods correctament. Un cop validat que els nodes tenen GPU assignables (kubectl get nodes -o custom-columns='NODE:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu'), podem procedir amb la instal·lació del GPU Operator usant Helm: helm repo add nvidia i helm upgrade --install gpu-operator nvidia/gpu-operator --namespace gpu-operator --wait. La versió recomanada en el moment d’escriure aquest article és v26.3.3. Confirmeu que el validador de CUDA es completi sense errors abans de continuar.
Amb el GPU Operator operatiu, instal·lem el NIM Operator versió 3.1.1. Creem el namespace nim-operator i despleguem: helm upgrade --install nim-operator nvidia/k8s-nim-operator --namespace nim-operator --version 3.1.1 --wait. Verifiquem que els Custom Resource Definitions (CRDs) NIMCache i NIMService estiguin registrats. A continuació, configurem l’autenticació NGC: necessitem dos secrets al namespace de treball. El primer és un secret de registre Docker (ngc-secret) perquè kubelet pugui descarregar les imatges de contenidor des de nvcr.io. El segon és un secret genèric (ngc-api-secret) que emmagatzema la clau API de NGC, utilitzada pel job de memòria cau per descarregar els artefactes del model. És important assenyalar que aquests secrets només autentiquen la descàrrega d’imatges i models, no protegeixen l’endpoint d’inferència. Per a la seguretat del trànsit d’aplicació, s’ha d’implementar TLS, autenticació OIDC, API Gateway o malla de serveis. A Q2BSTUDIO, quan treballem amb clients que necessiten ciberseguretat en els seus desplegaments d’IA, recomanem mantenir el servei intern (ClusterIP) i usar un ingress controlat amb polítiques d’autenticació i rate limiting.
El següent pas és dissenyar la memòria cau persistent del model. El recurs NIMCache llança un Job de Kubernetes que descarrega els perfils de model compatibles en un volum persistent. Això evita que cada pod d’inferència hagi de descarregar el model complet en arrencar, reduint dràsticament el temps d’inicialització. La configuració típica per a un model com Llama 3.2 1B inclou un PVC de 80 GiB amb mode d’accés ReadWriteOnce. En entorns productius on es necessiten múltiples répliques en diferents nodes, s’ha d’avaluar si el sistema d’emmagatzematge suporta ReadWriteMany o si es pot usar una memòria cau compartida via NFS. L’operador també permet filtrar perfils de motor (per exemple, tensorrt_llm) per evitar descarregar variants innecessàries. Un cop el NIMCache assoleix l’estat Ready, podem desplegar el NIMService. Aquest recurs crea un Deployment, un Service (per defecte ClusterIP) i configura els health probes (liveness, readiness i startup) amb valors per defecte que permeten fins a 20 minuts per a la inicialització del model. És important no deshabilitar aquests probes, sinó ajustar el startupProbe si el model triga més a carregar.
Per provar l’endpoint, fem servir port-forwarding: kubectl port-forward service/ 8000:8000. Després verifiquem els endpoints /v1/health/live, /v1/health/ready i /v1/models. Una sol·licitud de chat completions ha de retornar una resposta JSON vàlida. Si el readiness falla però el liveness funciona, el model encara s’està carregant. En producció, l’exposició externa s’ha de fer mitjançant un Ingress amb TLS i autenticació. El NIM Operator pot generar un Ingress automàticament si es configura spec.expose.router.ingress. No obstant, l’autenticació del client segueix sent responsabilitat de l’operador de la plataforma. Recomanem implementar NetworkPolicy per restringir el trànsit est-oest, permetent només a namespaces etiquetats accedir al port 8000 del NIM Service.
L’escalabilitat horitzontal s’habilita mitjançant el camp spec.scale.hpa, que crea un HorizontalPodAutoscaler basat en mètriques personalitzades com vllm:num_requests_waiting. Perquè això funcioni, el clúster ha de tenir un Prometheus Adapter configurat i el ServiceMonitor del NIM Operator correctament etiquetat. Abans d’activar l’autoscaling, és crític verificar que hi ha suficients GPUs disponibles i que l’emmagatzematge de la memòria cau permet muntatges concurrents en múltiples nodes. La gestió d’actualitzacions de l’operador i del model segueix un protocol acurat: abans d’actualitzar el NIM Operator, exportem els valors actuals i els recursos personalitzats. L’actualització del model implica crear un nou NIMCache amb el nou tag d’imatge, esperar que estigui llest, després actualitzar el NIMService apuntant al nou caché i a la nova imatge. Mantenim el caché antic fins que el rollback sigui segur. El rollback de l’operador es fa amb helm rollback, però cal verificar la compatibilitat de CRDs perquè Helm no les retrocedeix automàticament.
Algunes fallades comunes inclouen ImagePullBackOff per credencials NGC incorrectes, NIMCache en Pending per StorageClass no disponible, o pods en CrashLoopBackOff per perfil de model incompatible amb la GPU. La seqüència ràpida de diagnòstic és: kubectl get nimcache,nimservice -n , després esdeveniments i logs del job de caché i del pod d’inferència. A Q2BSTUDIO, combinem aquests desplegaments amb solucions de BI / Power BI per monitoritzar el rendiment dels models en temps real, i amb agents d’IA que automaticen tasques de manteniment predictiu. L’arquitectura descrita permet també integrar serveis al núvol com AWS o Azure per a l’emmagatzematge persistent i l’escalabilitat, tal com oferim als nostres serveis al núvol. En conclusió, desplegar NIM amb NIM Operator a Kubernetes no és només un exercici tècnic, sinó una decisió estratègica que accelera la posada en producció de models d’IA amb garanties de seguretat, observabilitat i escalabilitat. La clau és construir una base sòlida (GPU Operator + caché persistent + controls d’accés) i després afegir capacitats de forma incremental. Amb el suport d’un equip expert com Q2BSTUDIO, les organitzacions poden transformar la intel·ligència artificial en un actiu operatiu fiable.
