Salta al contenuto principale
Alessandro Iannacone
Pubblicato il

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

Autori
  • Foto profilo di Alessandro Iannacone
    Nome
    Alessandro Iannacone
    Profilo X

Quando si dice "serviamo un LLM su Kubernetes" si rischia una semplificazione sbagliata: Kubernetes non e 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 piu 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 capacita parametrica con costo per token controllato;
  • scalabilita 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 piu stabile, economico e scalabile.

Fonti e risorse web

Discutine su X • Vedi su GitHub