Raportul Cast AI 2026 privind optimizarea Kubernetes, care a analizat zeci de mii de clustere de producție între ianuarie 2025 și aprilie 2026, a înregistrat o utilizare medie a compute-ului GPU de doar 5% înainte de orice optimizare. O singură cluster din setul de date a susținut 49% utilizare pe 136 de H200 — o discrepanță descrisă ca fiind aproape în totalitate atribuibilă tehnicii, nu hardware-ului. Dar această cifră de 5% nu înseamnă că 95% din capacitate este liberă să fie preluată imediat. Fiecare cluster, și fiecare GPU în parte, necesită propriul diagnostic înainte ca această concluzie să fie validă.
Problema începe cu terminologia. "Utilizare GPU" este o expresiune care acoperă cel puțin patru măsurători distincte, și confuzia dintre ele este cel mai rapid drum spre o diagnoză greșită. Cea mai comună metrică pe care o afișează dashboard-urile este utilizarea compute-ului: procentul multiprocesoarelor de streaming (SM-uri) active într-o fereastră de timp dată. Acest număr vă spune cât de ocupat este siliciul când rulează. Nu vă spune nimic despre dacă dispozitivul este disponibil pentru o nouă sarcină.
Un model încărcat în VRAM ocupă acea memorie continuu. Serviciul de inferență poate răspunde la o singură cerere pe minut, menținând activitatea compute la 5%, dar dispozitivul este alocat, memoria este ocupată, și Kubernetes nu va planifica nimic altceva pe el. Din perspectiva scheduler-ului, acel GPU este indisponibil. Din perspectiva dashboard-ului tău, arată aproape inactiv.
Scheduler-ul Kubernetes vede un GPU ca fiind fie disponibil, fie indisponibil. El ia această decizie pe baza numărului de resurse nvidia.com/gpu pe fiecare nod, nu pe baza procentului de siliciu activ. Patru condiții distincte pot produce o coadă chiar când activitatea compute arată scăzută.
Plugin-ul NVIDIA Kubernetes Device Plugin alocă GPU-urile exclusiv implicit. Când un pod solicită nvidia.com/gpu: 1, primește proprietatea exclusivă a unui dispozitiv fizic pentru durata ciclului său de viață. Niciun alt pod nu poate folosi acel dispozitiv, indiferent de cât compute sau memorie consumă sarcina care îl ocupează. Aceasta este cea mai frecventă cauză a modelului coadă-lângă-GPU-inactiv în clusterele de inferență. Un set de modele, fiecare ținând un GPU dedicat dar servind cereri bursty sau de frecvență scăzută, menține fiecare dispozitiv alocat. O sarcină nouă sosită găsește nvidia.com/gpu: 0 disponibil pe nod și așteaptă, deși activitatea compute agregată pe nod poate fi sub 10%. Plugin-ul device-ului se concentrează pe alocare, nu pe recuperare. Cluster autoscaler-ul Kubernetes poate provisiona noduri noi, dar nu va recupera capacitatea inactivă pe cele existente. Problema trăiește la nivelul planificării, și soluția necesită schimbarea modului în care dispozitivele sunt prezentate scheduler-ului. Exact asta fac mecanismele de împărțire GPU.
Utilizarea compute scăzută nu înseamnă că memoria este disponibilă. Două scenarii ilustrează gama. Un model de 70B parametri încărcat în FP16 consumă aproximativ 140 GB VRAM (doar greutățile de bază; la lungimi de context de 4K, cache-ul KV adaugă 15-20% peste greutățile de bază, în timp ce la 128K context...). Chiar dacă compute-ul este la 5%, memoria este plină. Nicio altă sarcină nu poate fi planificată pe acel GPU pentru că nu există VRAM pentru greutățile modelului, și nu există mecanism nativ Kubernetes pentru a spune "acest GPU are 20 GB liberi, poți pune aici un model mic".
Compatibilitatea hardware-ului adaugă un alt strat de constrângere. Un cluster heterogen cu A100-uri, H100-uri și H200-uri pare flexibil pe hârtie. Dar un workload care necesită NVLink 4.0 sau anumite caracteristici Hopper nu va rula pe A100. Scheduler-ul, dacă nu este configurat cu node selectors și tolerations corecte, va încerca să plaseze pod-ul pe orice nod cu nvidia.com/gpu: 1 disponibil, va eșua, va reîncerca, va crea latență. În timp ce aceasta se întâmplă, GPU-urile compatibile pot sta goale pentru că workload-urile care ar putea rula pe ele sunt blocate în coadă după cele incompatibile.
Izolarea la nivel de tenant sau compliance forțează alocări dedicate chiar când partajarea ar fi tehnic posibilă. Un workload PCI-DSS sau HIPAA poate necesita GPU fizic dedicat, nu doar o fracțiune MIG sau un time-slice MPS. Politica organizației devine o constrângere de capacitate la fel de reală ca VRAM-ul fizic.
Plasarea — Entscheidul unde aterizează un pod — leagă toate aceste constrângere împreună. Un pod care solicită un GPU specific (de exemplu, nvidia.com/gpu: 1 cu node-selector pentru h100) poate sta în Pending în timp ce un H100 pe un alt nod stă inactiv pentru că acel nod nu are suficientă memorie de sistem, sau pentru că taint-urile împiedică planificarea, sau pentru că affinity rules-ul intră în conflict. Coada crește. Dashboard-ul arată GPU-uri inactiv. Ingenierul se uită la ecran și se întreabă: "De ce nu scalăm?"
Soluțiile nu sunt magice, dar sunt bine înțelese. MIG (Multi-Instance GPU) particionează fizic un A100 sau H100 în instanțe izolate cu VRAM și compute dedicat. MPS (Multi-Process Service) permite time-slicing pe același GPU fără izolare hardware. vGPU (NVIDIA Virtual GPU) adaugă un hypervisor în mix pentru izolare mai puternică. Fiecare are trade-offs: MIG oferă izolare puternică dar granularitate fixă (7 instanțe pe A100 40GB, 10 pe 80GB). MPS este flexibil dar fără izolare memorie — un proces care face OOM doboară ceilalți. vGPU necesită licențiere și introduce overhead.
Orchestratoarele moderne precum Run:ai, KubeRay, sau operatorii personalizați extind scheduler-ul Kubernetes cu conștientizare de topologie, bin-packing pe VRAM, preemption bazat pe prioritate, și gang scheduling pentru workload-uri distribuite. Ele transformă GPU-urile din resurse binare (disponibil/indisponibil) în capacitate fracționată, planificabilă.
Dar tehnologia nu rezolvă lipsa de disciplină. Echipele trebuie să instrumenteze workload-urile cu profilare reală: cât VRAM consumă modelul la lungimi de context reale, care este utilizarea compute pe batch-uri reale, care este profilul de latență și throughput. Fără date, orice strategie de partajare este ghicit.
Penuria de GPU nu este întotdeauna o penurie de siliciu. Adesea este o penurie de vizibilitate, de planificare, de curaj să particioneze resursele costisitoare. GPU-urile stau în rafturi, consumând curent, răcind aer, așteptând cereri care vin o dată la zece minute. Între timp, cercetătorii așteaptă. Modelele nu sunt deployate. Business-ul întârzie.
Înțelegerea diferenței dintre alocare și utilizare, între memorie și compute, între capacitate teoretică și capacitate planificabilă — asta este ce separă organizațiile care scape din capcana "5% utilizare" de cele care cumpără mai multe GPU-uri pentru a rezolva o problemă de scheduling.
De ce este important:
Această problemă nu este doar tehnică — este economică și strategică. Organizațiile cheltuieș milioane pe hardware care stă inactiv 95% din timp, nu pentru că nu au nevoie de el, ci pentru că nu știu să-l folosească eficient. Într-o eră în care accesul la GPU-uri devine avantaj competitiv, capacitatea de a maximiza fiecare dolăr investit în infrastructură AI separă liderii de urmăritori. De asemenea, înțelegerea acestor mecanisme este esențială pentru sustenabilitate: GPU-urile inactiv consumă energie inutil, contribuind la amprenta de carbon a industriei tech. Rezolvarea problemei de scheduling și partajare nu este doar optimizare — este responsabilitate.
