Infrastruttura AI e pool GPU

(Sezione Tecnologia e infrastruttura)

Breve riepilogo

La produzione-AI non è un solo modello su un solo server, ma un cluster di nodi GPU, pool di acceleratori condivisi, cerving unificato, dati/file, osservabilità e gestione del costo. Per un iGaming è critico in tempo reale: antifrode, personalizzazione, chat-bot, assistenti LLM, linee guida giochi/azioni. Mattoni di base: Kubernets/Slurm per pianificazione, isolamento dei carichi di lavoro, rete ad alta velocità (100/200/400G con RDMA), storage rapido, MLOs maturo, e SLO in ferro.

1) Mappa architettonica

1. Cluster di calcolo: nodi GPU (classi A/H, AMD/ROCM, Intel Gaudi, ecc.), nodi CPU per il preprocessing/ficce.

2. Rete: 100G + Ethernet/IB, RDMA (RoCEv2), topologia NCCL, QoS.

3. Archivio: oggetto (S3) , distribuito da POSIX (Ceph/grid), locale NVMe-scratch.

4. Dati/fici: phichestor (online/offline), database vettoriali (ANN), cache (Redis), code.

5. Piattaforma ML: registro degli artefatti e dei modelli, pipline (CI/CD), controllo delle versioni, fili come codice.

6. Livello di servizio: Triton/KServe/vLLM/text-generation-inference (TGI), A/B/canari-deposito, autosospensione.

7. Governance e sicurezza: PII, segreti, verifiche, regole di esportazione, licenze di peso/dataset.

• Lo screening online (p95-50-150 mc) è antifrode, raccomandazioni, classificazione.
• Il cerving LLM (p95 ≤ 200-800 ms per 128-512 token) è una chat/agenti/suggerimenti.
• Analisi/apprendimento batch - finestre notturne, metriche offline.
• Il feintuning/adattamento è periodico, con priorità sotto la linea.

2) pool GPU e pianificazione

Modello di pool

Pool Cerving: query brevi, battitura elevata, SLO rigoroso.
Pool Training/Feintuning: Lungo Jobs, Formazione Distribuita (DDP).
Pool R & D/Esperimenti: quote/limiti, preemption consentita.
Pool CPU/Pre-/Post-processing: normalizzazione, tornizzazione, rank per CPU.

Pianificatori

Kubernetes (+ device-plugin, NodeFeatureDiscovery, taints/tolerations, PriorityClass, PodPriority/Preemption).
Slurm (spesso per il training HPC) - può essere miscelato con K8s attraverso singoli worker.
Fair share e quote: quote namespace GPU, CPU, memoria; «banche» ore GPU; limiti di Neimspace/Progetto.

Partizionamento GPU

MIGH (Multi-Tiene GPU) - Taglia l'acceleratore in diapositive isolate (per cerving/multi-tenenza).
MPS: sharing SM per piccole attività (monitorare l'interferenza).
NVLink/PCIe - Tiene conto della topologia per il pinning sottostante (Topology Aware Scheduling).

yaml apiVersion: v1 kind: Pod metadata:
annotations:
scheduling. k8s. io/group-name: "ai-serving"
spec:
nodeSelector: { gpu-pool: serving }
tolerations: [{ key: "gpu", operator: "Exists", effect: "NoSchedule" }]
priorityClassName: ai-serving-critical

3) Rete e prestazioni intersito

RDMA (RoCEv2) per NCCL-all-Redus; Impostazioni ECN/PFC, isolamento delle classi di traffico.
Localizzazione: training all'interno di una singola fabbrica (pod/host/ottica), cerving più vicino all'utente (edge/regione).
Congest Control: tuned profili, jumbo frames, pin-ning interfacce.

4) Storage e dati

Archivio pesi/manufatti: oggetto (versioning, immutabilità).
Dataset/fici: Lakehouse (Delta/Iceberg/Hudi) + offline-ficchistor; in linea (SLA millisecondi).
BD vettoriali (ANN): Faiss/ScaNN/acceleratori, o motori vettoriali venditori; HNSW/IVF, replica.
Cache NVME locale: riscaldamento della bilancia/embedding per la partenza fredda.

5) Modelli di cerving

Cornici

Triton Inference Server (multi-model, multitasking, batching dinamico).
KServe (K8s nativo, autoscaling HPA/KPA, canari).
vLLM/TGI per la localizzazione LLM e il decoding ad alte prestazioni (paged-attraction, cache KV offlood).
ONNX Runtime/ TensorRT-LLM - per la compilazione e l'accelerazione.

Ottimizzazione

Quantificazione: INT8/FP8/INT4 (percentili/calibrazione, AWQ/GPTQ) - in linea con attenzione, misurare la qualità.
Compilazione grafica: TensorRT, TorchInductor/XLA, fused-kernels.
Batching/microbatching: dinamico e statico; для LLM — continuous batching.
Cache KV: sharing tra le query, offloood su CPU/NVMe in contesti lunghi.
Decoding speculativo: modello draft + verificatore per accelerare il token-pronuncia.
Limiti di token/contesto, arresto precoce, parole di stop, time-budget per la richiesta.

Criteri di deploy

A/B, canari, shadow - confronto latitanza/qualità/metriche aziendali.
Blue Green - senza downtime.
Rollback SLO/Errori.

6) Training/feintüning

DDP/FSDP/ZeRO: memoria/sfumatura distribuita, contabilità NVLink/topologia.
Checkpoint: incrementale/completo, frequenza vs I/O.
Mixed Precision: bf16/fp16 + loss scaling; profilare la stabilità.
Dataset Sharding: iteratore uniforme, replica per nodi.
Le priorità sono i jobs intermittenti (preemptile) a favore del cerving.
Pypline autonomi: data- - -eval maiuscolo- per la promozione in PROD secondo criteri gate.

7) MLOps e piattaforma

Registro modelli: versioni, firme, dipendenze, licenze/diritti di utilizzo dei pesi.
I modelli CI/CD sono test di compatibilità, performance-regressione, quality-gate, deposito sicuro.
Fichestor: consistenza offline/online (feature parity), TTL e backfill.
Data/Model Lineage - Traccia dal dataset al report/esperimento.
Directory dei modelli/prompt per LLM (versioning).

8) Osservabilità e SLO

• Latenza p50/p95/p99, tokens/s, batch occupacy, queue wait, GPU-util/SM occupacy, memoria, errori.
• SPECIFICA LLM: token per input/output, lunghezza media della risposta, percentuale di guasti per limiti, cache hit KV.
• Qualità: test di regressione automatici (offline), telemetria online (contenuto-bandiere, tossicità, precisione di rilascio su campioni d'oro).
• Business SLO: conversione della personalizzazione, precisione dell'antifrode, ritenzione.

Alert: crescita p99/coda, calo tokens/s, degrado batch-fill, esaurimento VRAM/PCIe-throttle, crescita rate-limit guasti.

9) Sicurezza, compliance e privacy

PII/find: segmentazione dei calcoli e dei dati per regione, crittografia a riposo/transito, tornizzazione.
Segreti/chiavi: KMS/Secret Manager; escludere la memorizzazione in immagini/codice.
Criteri di output LLM: filtri di protezione, red-teaming, registrazioni prompt/risposte (anonimizzate).
Licenze: conformità con le licenze dataset/peso; no-redistute/restrizioni commerciali.
Isolamento dei tenanti: namespace-RBAC, reti, diapositive MIG, limiti e quote.

10) Costo e finops

I profili di carico (RPS, token/sec), le code dei tornei e delle campagne sono i profili di cablaggio.
Riserva/Spot - Pool misti (reserved + spot/preemptile) con la riprogettazione di attività e checkpoint.
Scale automatico: HPA/KPA su RPS/queue depth/GPU-util; «partenza calda» con bilancia riscaldata.
Zoo modello: riduce il numero di opzioni; Utilizzare l'adattamento (LoRA/PEFT) invece di duplicare completamente.
Cache: embedding/risultati di query costose, sharing della cache KV per LLM.
Ottimizzazione dei token: compressione dei prompt, retrieval-augmented generation (RAG), rerank prima della generazione.

11) Multiregione, HA e DR

Active/Active cerving più vicino all'utente, routing globale (latency-based).
Replica di pesi e fitte con verifica di integrità riscaldamento della cache durante i rilasci.
Programma DR: perdita di AZ/regione, evacuazione del pool di riserva, controllo della dipendenza da catalogo centralizzato.
Chaos giorni - Test di guasto GPU/domini di rete/storage.

12) Modelli di configurazione (concetti)

text dynamic_batching {
preferred_batch_size: [4, 8, 16, 32]
max_queue_delay_microseconds: 2000
}
instance_group { count: 2 kind: KIND_GPU }

yaml spec:
predictor:
canaryTrafficPercent: 20 model:
modelFormat: { name: triton }
resources:
limits: { nvidia. com/gpu: "1" }

--tensor-parallel-size 2
--max-num-seqs 512
--gpu-memory-utilization 0. 9
--enforce-eager

13) Specifica LLM: il circuito di ricerca e il circuito di ricerca

Indicizzazione: chunking, embedding, ANN-Sharding per tenant/locale.
Rerank è un modello leggero su una diapositiva CPU/GPU per migliorare la precisione.
Cache prompt/contesti - Deadup, canonicalization.
Criteri di citazione/responsabilità per i domini sensibili (CUS/Regole).

14) Assegno foglio di implementazione

1. Fissa SLO (p95 latency/tokens/s, disponibilità) e profili di carico.
2. Dividere il cluster in pool (serving/train/R & D), immettere quote/priorità.
3. Includere RDMA/NCCL e pianificazione topologica.
4. Personalizzare gli archivi: pesi, dataset, fitsestor (online/offline), database vettoriali.
5. Seleziona uno stack di cerving (Triton/KServe/vLLM), aggiungi un batch/cache/quantificazione KV.
6. Avvia il registro dei modelli, CI/CD, canari/shadow-deplay.
7. Osservare le metriche di sistema + business, le qualità, il tracciamento.
8. Immettere i criteri di protezione/PII, licenze, controllo.
9. Ottimizzare TCO: riserved + spot, scale automatico, cache, PEFT al posto dei duplicati completi.
10. Preparare HA/DR e passare il game-day.

15) Antipattern

«Un GPU grande per tutto» senza pool e priorità.
Nessun battching dinamico e nessuna cache KV per LLM → l'esplosione di p99 e costo.
Addestramento e cerving su un unico proiettile senza preimpressione di incidenti SLO.
La telemetria di qualità/sicurezza zero è un rischio e un degrado impercettibili.
Monolite centralizzato senza fifestore/registro modelli non disponibile.
Ignora licenze pesi/dati.

Riepilogo

Le infrastrutture AI di successo sono i pool GPU con pianificazione intelligente, alta rete e lo storage corretto, cerving efficiente (batching, cache, quantificazione, compilazione), MLops maturo e SLO rigoroso. In combinazione con sicurezza/PII, multi-regionale HA/DR e finops elaborato, la piattaforma offre un p99 stabile controllato da $/richiesta e l'implementazione rapida di nuovi modelli, dall'antifrode alla personalizzazione e agli assistenti LLM.