Salta al contenuto principale
AIAlessandro Iannacone
Dal blog

Oltre i Pod: come Kubernetes gestisce il serving di LLM multi-trilioni di parametri

Kubernetes non esegue i calcoli del modello: orchestra risorse GPU, rete e scheduling. Vediamo come tensor, pipeline ed expert parallelism rendono possibile il serving di LLM enormi.

Foto profilo di Alessandro IannaconeAlessandro Iannacone

Quando si dice "serviamo un LLM su Kubernetes" si rischia una semplificazione sbagliata: Kubernetes non è il motore matematico del modello.

Kubernetes e il piano di orchestrazione che alloca e coordina risorse (GPU, rete, nodi, policy), mentre il calcolo vero avviene nei runtime ML (vLLM, TensorRT-LLM, DeepSpeed, Megatron, stack custom).

Capire questa distinzione evita decisioni architetturali fragili.

1) K8s != inferenza LLM

K8s fa benissimo:

  • scheduling dei pod su nodi compatibili;
  • allocazione risorse estese (nvidia.com/gpu);
  • rollout, autoscaling, resilienza applicativa;
  • isolamento multi-tenant.

K8s non decide come shardare i pesi, come sincronizzare tensori o come ottimizzare l'attenzione. Quelle scelte sono nel layer runtime/framework.

2) Il problema reale: la scala multi-trilioni

Un modello multi-trilioni non entra in una sola GPU, spesso nemmeno in un singolo host.

I colli di bottiglia principali sono:

  • memoria HBM totale;
  • banda inter-GPU (NVLink/NVSwitch);
  • latenza rete inter-nodo (InfiniBand/RDMA/Ethernet ad alte prestazioni);
  • sincronizzazione tra shard durante prefill e decode.

Da qui nasce l'obbligo del parallelismo distribuito multi-dimensione.

3) Le tre dimensioni del parallelismo

Tensor Parallelism

Si divide la singola operazione matematica (matrici e pesi) tra GPU diverse. Ogni richiesta coinvolge più device in parallelo.

Pro:

  • scala orizzontale dei layer molto grandi;
  • uso migliore della memoria complessiva.

Contro:

  • forte dipendenza da interconnect veloce;
  • comunicazione collettiva intensa (all-reduce/all-gather).

Pipeline Parallelism

Si divide il modello per blocchi/layer: ogni GPU o gruppo GPU esegue una fase della pipeline.

Pro:

  • riduce il carico memoria per singolo stadio;
  • sfrutta bene cluster con topologie eterogenee.

Contro:

  • rischio di pipeline bubbles;
  • tuning complesso di micro-batch e bilanciamento stadi.

Expert Parallelism (MoE)

Con architetture Mixture of Experts, per ogni token si attiva solo un sottoinsieme di esperti.

Pro:

  • enorme capacità parametrica con costo per token controllato;
  • scalabilità efficiente per throughput elevato.

Contro:

  • routing/gating complessi;
  • sbilanciamento carichi se alcuni esperti sono "hot".

Nella pratica enterprise i sistemi moderni combinano tutte e tre le dimensioni.

4) Gestione avanzata risorse GPU in Kubernetes

Per rendere sostenibile questa architettura, non bastano requests e limits.

Servono almeno:

  • Device plugin vendor (NVIDIA/AMD/Intel) per esporre GPU schedulabili.
  • Node affinity e topology-aware scheduling per posizionare pod vicini alle interconnessioni giuste.
  • Node feature discovery per etichettare automaticamente capability hardware.
  • Network topology awareness: minimizzare hop inter-nodo tra shard che comunicano intensamente.
  • Tuning runtime su batch, KV cache, quantizzazione, paged attention.

Senza questa disciplina, il cluster "funziona" ma con latenza e costo/token non competitivi.

Pattern operativo consigliato

  1. Definisci classi di workload (chat realtime, batch offline, fine-tuning).
  2. Mappa ogni classe su una strategia di parallelismo dominante.
  3. Applica policy di scheduling dedicate per pool GPU omogenei.
  4. Misura TTFT, tokens/s, p95 latency e costo/token, non solo utilization GPU.
  5. Versiona configurazioni di serving come codice (GitOps/IaC).

Conclusione

Kubernetes e necessario, ma non sufficiente. E il "sistema nervoso" dell'infrastruttura, non il cervello matematico del modello.

Per LLM multi-trilioni, il vantaggio competitivo nasce dall'integrazione tra orchestrazione K8s, parallelismo distribuito e topologia hardware reale.

Chi tratta questi tre livelli come un unico problema ingegneristico ottiene serving più stabile, economico e scalabile.

Fonti e risorse web