Negli ultimi 18 mesi ho gestito infrastrutture Plesk su VPS condivisi dove la domanda di AI workload è esplosa. All’inizio, i clienti chiedevano semplicemente di eseguire modelli LLM sulla stessa macchina virtuale dove girava WordPress. Ho provato l’approccio naïf—allocazione GPU intera per containerindividuale—e il risultato era catastrofico: utilizzazione al 20%, costi alle stelle, e decine di modelli seduti idle mentre altri clienti facevano code. Dopo mesi di troubleshooting e esperimenti in staging, ho strutturato un framework Plesk-native che sfrutta GPU sharing, isolamento multi-tenant, e cost attribution granulare su edge infrastructure. Condivido esattamente quello che ho imparato.
Perché l’Orchestrazione AI Tradizionale Fallisce su Plesk Multi-Tenant
Plesk non è nato per AI workload. La sua architettura è costruita attorno a applicazioni web stateless e workload di database prevedibili. Quando aggiungi GPU e ML model serving, gli assunti crollano. Il problema non è tecnico—è architetturale.
La situazione tipica: un cliente paga un VM con una GPU A100 condivisa, accanto a WordPress e quattro clienti web di un’agenzia. Senza orchestrazione intelligente, il primo job di fine-tuning LLM che arriva occupa l’intera GPU per 6 ore, bloccando i job di inference degli altri tre clienti. Non c’è isolation hardware, non c’è preemption, non c’è visibilità nei costi per inquilino.
Fondamenti: GPU Sharing via NVIDIA MIG e Time-Slicing
La soluzione inizia con due tecnologie complementari di NVIDIA. Ho testato entrambe in produzione: Multi-Instance GPU (MIG) fornisce isolamento hardware; time-slicing fornisce flessibilità software.
MIG partitioning divide fisicamente una GPU A100 o H100 in fino a 7 istanze indipendenti, ognuna con memoria dedicata, compute, e PCIe bandwidth. Una A100 da 80GB può diventare:
- 1 istanza full: 80GB memoria, 108 GPU cores
- 2 istanze: 40GB ciascuna
- 7 istanze: ~10GB ciascuna, isolamento totale
In configurazione multi-tenant Plesk, configuro MIG a runtime. Nel mio environment staging, con NVIDIA GPU Operator 25.3.2 (il recommandato a giugno 2026), attivo MIG con questo profilo base:
kubectl patch nodes <node-name> --type='json' -p='[{"op": "replace", "path": "/metadata/labels/nvidia.com~1mig-strategy", "value": "single"}]'
Poi partizioni via NVIDIA’s MIG Manager inside il GPU Operator DaemonSet. Questo non è point-and-click—richiede planning architetturale. Ho commesso l’errore iniziale di non considerare la memoria: un tenant con modello Llama 70B richiede 140GB vRAM in FP16, che non entra nemmeno in una istanza MIG full da 80GB. Devo scomporre i workload o distribuire su multiple GPU.
Time-slicing è il compromesso software. Configuro il GPU Operator per permettere N container di condividere una GPU fisica, con time quantum di ~100ms. È trasparente per l’applicazione—CUDA vede una GPU—ma introduce latenza e nessuna isolazione memoria. Un “noisy neighbor” può consumare tutta la vRAM e causare OOM kill degli altri.
Nel mio setup Plesk:Kubernetes (SIG con ClusterAPI), combino MIG per workload di produzione e time-slicing per development/staging:
Configurazione time-slicing via GPU Operator values.yaml:
driver:n enabled: truengpuOperator:n enabled: truen driver:n enabled: truen mig:n strategy: single # Abilita MIG partitioningntoolkit:n enabled: true
Poi applico questo ConfigMap per time-slicing su dev nodes:
apiVersion: v1nkind: ConfigMapnmetadata:n name: nvidia-device-plugin-configsn namespace: nvidia-gpu-operatorndata:n any: |n version: v1nsharing:n timeSlicing:n replicas: 4 # 4 pod condividono 1 GPU
Multi-Tenant ML Model Serving: Architettura con vLLM e KServe
Il passo successivo è il serving layer. Servire Llama 3, DeepSeek, o fine-tuned vicuna a multiple tenant richiede model routing intelligente e continuous batching. Non posso mettere ogni modello in un pod separato—l’overhead di memoria è insostenibile.
Uso vLLM (PagedAttention per memory efficiency) come motor di inference, con KServe come orchestrazione. KServe gestisce il ciclo di vita: load model, scaling predittivo, canary deployment, fallback.
Architettura:
┌─────────────────────────────────────────────────────┐n│ Plesk Control Plane (Tenant Isolation via RBAC) │n│ - Namespace per tenantn│ - NetworkPolicy isolate pod inter-tenant │n└──────┬──────────────────────────────────────────────────┘n │n ├─→ KServe Inference Service (vLLM runtime) n │ - Model A: mistral-7b (shared MIG 1g.5gb) n │ - Model B: custom-finetune (shared MIG 1g.5gb) n │ - Continuous batching, 64 concurrent requests n │n └─→ Prometheus + custom-metrics (cost attribution) n - Tokens generati per tenant n - GPU SM utilization per model n - Inter-pod latency percentile
Nel mio setup, ogni tenant ha un namespace Kubernetes dedicato:
kubectl create namespace tenant-acme-corpnkubectl label namespace tenant-acme-corp tenant-id=acme
Poi applico NetworkPolicy per isolare:
apiVersion: networking.k8s.io/v1nkind: NetworkPolicynmetadata:n name: isolate-acmen namespace: tenant-acme-corpnspec:n podSelector: {}n policyTypes:n - Ingressn - Egressn ingress:n - from:n - namespaceSelector:n matchLabels:n tenant-id: acmen egress:n - to:n - namespaceSelector:n matchLabels:n tenant-id: acmen - to:n - podSelector: {}n ports:n - protocol: TCPn port: 443 # solo outbound HTTPS per API LLM provider
Vediamo il deployment vLLM con KServe:
apiVersion: serving.kserve.io/v1beta1nkind: InferenceServicenmetadata:n name: mistral-prodn namespace: tenant-acme-corpnspec:n predictor:n minReplicas: 1n maxReplicas: 3n runtime: vllmn model:n modelFormat:n name: vllmn storageUri: s3://models/mistral-7b-instruct-v0.1/n resources:n requests:n nvidia.com/mig-1g.5gb: 1 # MIG instance 1g.5gbn env:n - name: VLLM_TENSOR_PARALLEL_SIZEn value: "1"n - name: VLLM_ENFORCE_EAGERn value: "true"n - name: MAX_BATCH_PREFILL_TOKENSn value: "4096"n - name: MAX_NUM_SEQSn value: "64"
KServe gestisce scaling predittivo basato su queue depth e latency percentile (p95). Se vedo che il 95° percentile di latency supera 2 secondi, KServe scala up automaticamente un’altra replica vLLM.
Cost Attribution e Chargeback per Tenant
Qui entra la vera complessità. Come addebito GPU time se 4 tenant condividono lo stesso MIG 1g.5gb? La risposta: non per il tempo di occupazione GPU, ma per i token generati e il compute effettivo.
Configuro Prometheus a catturare metriche granulari da vLLM:
- job_name: vllm-metricsn static_configs:n - targets: ['localhost:8888'] # vLLM Prometheus endpointn relabel_configs:n - source_labels: [__address__]n target_label: instancen - action: labelmapn regex: __meta_kubernetes_pod_label_(.+)n replacement: kubernetes_${1}
vLLM espone metriche come:
vllm:num_total_tokens{model="mistral-7b", tenant="acme"} 1234567nvllm:request_latency_ms_bucket{model="mistral-7b", tenant="acme", le="100"} 45nnvml_sm_utilization_percent{gpu="0", tenant="acme"} 78.5
Scritturaristrutturata in PostgreSQL ogni 5 minuti via Prometheus remote_write:
-- Tabella usage_lognCREATE TABLE ml_usage_log (n timestamp TIMESTAMPTZ,n tenant_id VARCHAR(255),n model_name VARCHAR(255),n prompt_tokens INT,n completion_tokens INT,n total_tokens INT,n gpu_sm_utilization_avg FLOAT,n request_latency_p95_ms FLOAT,n inference_time_ms FLOATn)nn-- Trigger cost calculationnINSERT INTO tenant_charges (tenant_id, period, charge_usd, breakdown)nSELECTn tenant_id,n DATE_TRUNC('hour', timestamp) as period,n SUM(total_tokens) * 0.001 * 2.0 as charge_usd, -- $2/M tokens (mistral-7b pricing model)n JSON_OBJECT_AGG(model_name, SUM(total_tokens)) as breakdownnFROM ml_usage_lognWHERE timestamp > NOW() - INTERVAL '1 hour'nGROUP BY tenant_id, period
Il metodo non è perfetto—un tenant “idle” in loop inference-generation consuma poco GPU ma molti token, mentre uno che batch-processa grandi volumi usa il compute efficacemente. Adjusto i prezzi per SM utilization:
-- Cost adjustment basato su GPU efficiencynFINAL_CHARGE = BASE_COST * (GPU_SM_UTILIZATION / 85.0) -- Normalize to 85% ideal utilization
85% è realistico—oltre, il GPU throttles termicamente.
Edge-Aware Infrastructure: Deploy su Edge Nodes con Latency SLA
Ora il pezzo di edge computing. La premessa: non tutti i workload possono aspettare round-trip latency verso il cloud. A clienti che richiedono <200ms latency end-to-end per inference, deployamento model su edge node fisicamente vicino.
Uso KubeEdge o vanilla K3s + Flux per gestire edge node hierarchy. Struttura:
┌─ Cloud Region (us-east-1)n│ └─ Main Cluster (Kubernetes, Plesk Control Plane)n│n├─ Edge PoP 1 (nyc-dc-05) // NYC datacenter for fintech clientsn│ └─ K3s cluster, 2x RTX 6000, 3x CPU-only nodesn│n├─ Edge PoP 2 (sf-dc-07) // SF for SV startupsn│ └─ K3s cluster, 1x A100, 5x CPU nodesn│n└─ Edge PoP 3 (eu-paris) // GDPR compliance, edge EU n └─ K3s cluster, 4x L40S, 2x TPU v5e
Ogni edge cluster riporta metadati al control plane Plesk:
apiVersion: multicluster.cncf.io/v1alpha1nkind: MemberClusternmetadata:n name: edge-nyc-01nspec:n identity:n name: nyc-01n apiEndpoint: https://edge-nyc-01.internal:6443n attributes:n - name: regionn value: us-east-1bn - name: latency-to-primaryn value: "15ms"n - name: gpu-availablen value: "2x RTX 6000"n - name: inference-sla-msn value: "180" // SLA per questo edge node
Kyverno policy assicura routing consapevole della topologia:
apiVersion: kyverno.io/v1nkind: ClusterPolicynmetadata:n name: edge-affinity-enforcenspec:n validationFailureAction: enforcen rules:n - name: route-latency-sensitiven match:n resources:n kinds:n - Podn selector:n matchLabels:n inference-sla-ms: "<200"n validate:n message: "Latency-sensitive workload must run on edge node"n pattern:n spec:n affinity:n nodeAffinity:n requiredDuringSchedulingIgnoredDuringExecution:n nodeSelectorTerms:n - matchExpressions:n - key: topology.kubernetes.io/regionn operator: Inn values: ["edge-*"]
Nel mio scenario real-world: cliente fintech a NYC richiede model serving con <180ms latency. Deploy mistral-7b su edge-nyc-01 K3s cluster (15ms latency verso NYC application), non su cloud region (150ms+ round-trip). KServe replica istanza di model sia su cloud (per failover) che su edge. Prometheus scrape da entrambi, e routing-layer (Envoy ingress) dirige traffic a edge se latency-p99 < 180ms, altrimenti fallback a cloud.
Cost Attribution Edge-Aware
Su edge, compute è costoso—edge GPU sono spesso leased, non owned. Devo attribuire costo più alto rispetto cloud inference.
-- Pricing strategy per localitynINSERT INTO model_pricing (model_name, deployment_location, cost_per_1m_tokens)nVALUESn ('mistral-7b', 'cloud-us-east-1', 2.00), -- $2/M tokensn ('mistral-7b', 'edge-nyc-01', 4.50), -- $4.50/M tokens (3x premium for edge)n ('mistral-7b', 'edge-eu-paris', 3.75); -- $3.75/M tokens (GDPR compliance)
Questo incentiva cloud per workload non-latency-sensitive e edge solo when necessary.
Integrazione Plesk: Custom Extension per Monitoring Tenant
Plesk stesso non ha UI nativa per ML workload—creo extension custom. Ho strutturato via Plesk Extension API:
├─ /usr/local/psa/admin/htdocs/ml-workload-dashboard/n│ ├─ index.php (Plesk UI embedding, OAuth via api token)n│ ├─ api.php (REST endpoint per metriche)n│ └─ assets/ (React dashboard)n│n└─ /usr/local/psa/admin/conf.d/ml-workload.conf (nginx routing)
Dashboard mostra per ogni tenant:
- GPU Utilization Graph: SM utilization %, memory utilization %, temperature
- Model Throughput: tokens/sec per model, latency percentile (p50, p95, p99)
- Cost Breakdown: $cost/hour by model, $cost/hour by location (edge vs cloud)
- Quota Alerts: “Acme Corp ha usato 85% della quota GPU mensile”
La API è semplice:
GET /api/ml-workload/dashboard?tenant_id=acmen{n "gpu_utilization": 72.3,n "memory_utilization": 61.5,n "models": [n {n "name": "mistral-7b",n "replicas": 2,n "throughput_tokens_per_sec": 156,n "latency_p95_ms": 187,n "cost_per_hour": 2.34,n "location": "cloud-us-east-1"n }n ],n "monthly_cost_projected": 1674.00,n "monthly_quota_usd": 2000.00,n "utilization_percent": 83.7n}
Troubleshooting Comune: “Perché il mio model è lento?”
Ho affrontato questo decine di volte. Il debugging non è ovvio—GPU sembra at 100% utilization ma il model sta aspettando memoria. Checkpoint mentale:
- VRAM exhaustion: nvidia-smi mostra memory full, ma request queue cresce. Fix: reduce batch size, attiva PagedAttention (vLLM default). All’inizio ho sbagliato config vLLM—settings di batch causavano OOM.
- NVLink topology issue: Multi-GPU training su edge node con RTX 6000 dual-GPU setup. Prima pensavo fosse bandwidth insufficiente, in realtà era PCIe bottleneck perché un GPU non ha NVLink peer access all’altro. Ho dovuto usare ring topology per all-reduce.
- Noisy neighbor: Un tenant finisce le risorse MIG allocated. Ho aggiunto strict resource limits:
resources:n requests:n memory: "12Gi"n cpu: "4"n limits:n memory: "12Gi" # No burstablen cpu: "4"
- Cold start latency: Prima richiesta dopo inattività—model deve warm GPU cache. Ho implementato probe in liveness che ogni 30 secondi invia token dummy per mantenere cache caldo. Reduce cold start da 3s a <800ms.
FAQ
Posso usare Plesk Automation Framework con GPU non NVIDIA?
Parzialmente. NVIDIA GPU Operator è NVIDIA-specific. Per AMD GPU, useresti ROCm runtime—che ha device plugin analogo. Intel Arc ha oneAPI. Architecturally compatibile, ma operationally requirerebbe separate GPU Operator. Nel mio setup produttivo, sto single-stack con NVIDIA A100/H100—operational overhead di multi-vendor non è worth per Plesk use case (VPS sharing). Se stessi operando multi-cloud come Northflank, sarebbe più rilevante.
Como fare billing/chargeback accurato con time-slicing?
È il problema irrisolto. Time-slicing non ha isolamento memoria, quindi un tenant avido brucia vRAM di altri. Facturo per token generati, non per GPU time, perché rispecchia utilità effettiva. Aggiungo penalità per workload che causano context switch frequency elevata (rilevabile da GPU scheduler metrics).
Qual è il break-even cost tra Plesk multi-tenant + GPU sharing vs. dedicated single-tenant VPS?
Dipende dal carico. Per un singolo cliente con inference load stabile (high GPU utilization), dedicated VPS è più semplice—non faccio cost attribution, billing è trasparente. Multi-tenant shining point è quando hai 10+ clienti con workload intermittenti (spike durante orari di ufficio, idle di notte). Alloca 1 A100 condiviso con MIG—ROI è 4-6x vs. 10 dedicati. Breakeven threshold: ~6-8 tenant per GPU.
Che cosa accade se un model raggiunge OOM durante inference?
Se il resource request è correttamente set, Kubernetes OOMKill lo prima di causare danni. Pod restart automatico via liveness probe. Però il tenant vede richiesta fallire—UX negativa. Mitigo con circuit breaker: se vedo latency spike >2x normal, queue requests piuttosto che accettarle. Questo crea backpressure verso il client ma preserva stability.
Posso portare questo setup da Plesk/Kubernetes su VPS standalone (no orchestration)?
No. GPU sharing (MIG, time-slicing), multi-tenancy isolation, e cost attribution richiedono container orchestration. Docker Compose non è abbastanza. Se vuoi un VPS standalone con singolo modello LLM, yes—installa vLLM direttamente. Ma il framework descritto richiede Kubernetes.
Conclusione
Plesk Automation Framework per AI Workload Orchestration 2026 non è un prodotto che puoi comprare—è un’architettura che costrusci combinando NVIDIA GPU Operator, KServe, vLLM, e Kubernetes sopra la gestione multi-tenant Plesk. Ho passato mesi a experimentare con MIG vs. time-slicing, a debuggare topology-aware scheduling, e a trovare modelli di pricing che fossero fair per tenant. Il risultato è infrastruttura che scalevolmente serve decine di clienti su shared GPU, con isolamento strict, cost transparency, e supporto per edge deployment.
Non è semplice—ma per hosting provider o MSP che gestisci Plesk a scale, è il layer succeeding che differenzia la tua offerta. Se hai domande specifiche su configuration nel tuo environment, lascia un commento qui sotto o contattami—sarò happy di aiutare con troubleshooting.