Inferenza e orchestrazione della CPU

Panoramica di

Le istanze CPU sono un'opzione di elaborazione di prima classe per un'ampia gamma di carichi di lavoro AI su Amazon EKS. Dai modelli linguistici di piccole dimensioni (SLM) alla classica inferenza ML alle pipeline di dati e all'orchestrazione degli agenti, le CPU offrono un ottimo rapporto prezzo/prestazioni, un'ampia disponibilità di capacità e una semantica di pianificazione Kubernetes familiare.

CPU e GPU sono complementari, non competitive. Man mano che le pipeline di intelligenza artificiale agentica crescono in complessità, la superficie del carico di lavoro della CPU cresce di pari passo: ogni chiamata di inferenza è circondata dall'esecuzione degli strumenti, dall'assemblaggio del contesto, dalla ricerca vettoriale, dai guardrail e dalla logica di orchestrazione, tutti eseguiti sulla CPU. Consigliamo di progettare architetture che utilizzino deliberatamente entrambi i tipi di elaborazione, collocando ogni carico di lavoro sul livello in cui offre il miglior rapporto costo/prestazioni.

Non tutti i carichi di lavoro richiedono una GPU. Il routing, la classificazione, il recupero, l'incorporamento, l'orchestrazione e una quota crescente dell'inferenza dei modelli linguistici funzionano tutti in modo efficace sulla CPU. Current-generation Le istanze CPU su arm64 e x86 offrono un ottimo rapporto prezzo/prestazioni per l'inferenza ML. In combinazione con il consolidamento dei nodi di Karpenter, la scalabilità basata sugli eventi di KEDA e il servizio di modelli quantizzati, ciò fornisce uno stack pronto per la produzione che i team della piattaforma possono utilizzare senza una profonda esperienza in materia di GPU.

Questa guida è destinata a:

• Ingegneri della piattaforma che progettano cluster EKS multi-tenant per carichi di lavoro di intelligenza artificiale.

• Professionisti del machine learning che valutano i backend di inferenza per modelli con parametri inferiori a 30B.

• FinOps team che cercano leve di costo concrete senza sacrificare gli SLO.

Cosa imparerai:

• Quali carichi di lavoro AI appartengono alle CPU e dove sono necessarie GPU o Trainium.

• Come applicare un quadro decisionale quadridimensionale a qualsiasi nuovo carico di lavoro.

• Due modelli di produzione: prefiltraggio SLM agentico e allevamenti modello ad alta densità.

• Best practice di ottimizzazione: quantizzazione, bin-packing, pianificazione Spot e scalabilità automatica.

avvertimento

Ogni raccomandazione contenuta in questa guida deve essere convalidata empiricamente. La famiglia di istanze giusta (arm64, x86, GPU o Trainium) dipende dal modello, dai dati e dal budget di latenza. Usa questa guida come punto di partenza informato, quindi esegui un benchmark prima di impegnarti.

Perché le CPU per carichi di lavoro AI?

Le pipeline di intelligenza artificiale di produzione distribuiscono il lavoro su molti livelli di elaborazione. Le CPU gestiscono il routing, la classificazione, il recupero, l'orchestrazione e una quota crescente di inferenza. Current-generation Le istanze CPU offrono un ottimo rapporto prezzo/prestazioni e una pianificazione Kubernetes familiare, il che le rende un'opzione pratica per molti carichi di lavoro di intelligenza artificiale.

Tre fattori rendono la CPU interessante per questi carichi di lavoro:

Disponibilità della capacità

Le istanze GPU richiedono spesso prenotazioni di capacità con settimane di anticipo. Le istanze CPU sono ampiamente disponibili in tutte le regioni AWS senza plug-in di dispositivi specializzati, nessuna configurazione DRA e nessun partizionamento MIG. Quando è necessario scalare rapidamente, la capacità della CPU è l'opzione più facilmente disponibile.

Economia

Current-generation Le istanze CPU offrono un ottimo rapporto prezzo/prestazioni per l'inferenza ML. Per i team che eseguono FinOps revisioni o gestiscono cluster multi-tenant, la differenza di costo tra CPU e GPU è significativa, specialmente per le SLM quantizzate in cui l'accelerazione GPU offre rendimenti decrescenti. Ti consigliamo di eseguire il benchmarking tra le famiglie di istanze disponibili (Graviton, AMD, Intel) per trovare il miglior costo per token per il tuo carico di lavoro.

Semplicità operativa

I pod CPU utilizzano la pianificazione standard di Kubernetes (requests,, affinità dei nodilimits, diffusione della topologia). Nessun plug-in per dispositivi, nessun programma di pianificazione personalizzato, nessun tipo di risorsa. nvidia.com/gpu I team che desiderano eseguire carichi di lavoro di intelligenza artificiale senza competenze approfondite in materia di GPU possono raggiungere la produzione più velocemente sulla CPU.

Aumento della superficie della CPU nelle pipeline agentiche

Nelle pipeline di intelligenza artificiale agentica, ogni chiamata di inferenza della GPU è circondata dal lavoro della CPU: esecuzione degli strumenti, assemblaggio del contesto, ricerca vettoriale, incorporamento di ricerche, guardrail, convalida della risposta, gestione della memoria e logica di orchestrazione. Man mano che gli agenti diventano più complessi (più strumenti, catene più lunghe, ragionamento in più fasi), questi carichi di lavoro della CPU crescono in modo estremamente lineare. Protocolli come MCP (Model Context Protocol) amplificano ulteriormente questa situazione: ogni chiamata allo strumento MCP attiva il recupero, la trasformazione e la formattazione dei dati che vengono eseguiti interamente sulla CPU.

CPU vs GPU/Trainium: quando sceglierli

Factor	Scegli la CPU	Scegli GPU/Trainium
Dimensione del modello	SLM 1-8B (quantizzati); incorporamenti; classificatori	8B+ per inferenza online a bassa latenza; oltre 70 B+ in generale
Latenza SLO	p95 100-500 ms accettabile	p95 < 50 ms richiesti
Concurrency (Simultaneità)	< 100 req/s per endpoint	> 100 sostenuti req/s
Tipo di carico di lavoro	Orchestrazione, recupero, ETL, assegnazione del punteggio in batch	Inferenza online, messa a punto, formazione
Capacity	Disponibilità immediata, nessuna prenotazione	Spesso richiede una capacità riservata
Sensibilità ai costi	La CPU offre il miglior rapporto prezzo/token per i carichi di lavoro idonei	La GPU si ammortizza in caso di utilizzo elevato
Competenza del team	Operazioni standard di Kubernetes	Richiede conoscenze operative della GPU
Sovranità dei dati	Inferenza SLM in VPC; audit trail completo; i dati non escono mai dal tuo account	Uguale se gestita automaticamente; non disponibile con API esterne

Suggerimento

Queste soglie sono punti di partenza. Ti consigliamo di utilizzare il tuo motore di inferenza di destinazione su famiglie di istanze candidate (arm64 e x86) con il modello e il pattern di traffico attuali prima di passare a un livello di elaborazione.

Quadro decisionale sul carico di lavoro

La scelta dell'elaborazione giusta per un carico di lavoro di intelligenza artificiale si riduce a quattro dimensioni:

1. Dimensioni e precisione del modello: la quantizzazione mantiene la qualità entro un intervallo accettabile?

2. SLO di latenza e throughput: quali sono i vostri p50/p95 obiettivi e i tassi di picco delle richieste?

3. Tipo di carico di lavoro: inferenza online, assegnazione di punteggi in batch, recupero o orchestrazione?

4. Limiti di costi e capacità: budget, disponibilità regionale, strategia di prenotazione? FinOps

Utilizza la tabella seguente come matrice decisionale.

Carico di lavoro	CPU	GPU/Trainium	Note
SLM (parametri 1-8B, quantizzati)	Scelta predefinita. Ottimo rapporto prezzo/prestazioni con latenza di 100-500 ms, QPS moderato. Effettua benchmark tra diverse famiglie di istanze.	<50ms or concurrency >Quando p95 100. req/s	Si consiglia la quantizzazione Q4_K_M o Q8_0
Modelli medi (parametri 8-30B)	Punteggio in batch, asincrono e offline. Prova la quantizzazione Q4.	Inferenza online, contesti lunghi, latenza ristretta.	Benchmark Q4 tra diverse famiglie di istanze
LLM di grandi dimensioni (oltre 70 miliardi di parametri)	Non-real-time solo quantizzazione pesante	Impostazione predefinita per l'inferenza online di produzione	Anche 70B possono essere eseguiti sulla CPU; aspettatevi una latenza elevata
ML classico/Embeddings/CV	High-density servizio; bin-pack tra i nodi.	Visione intensiva o multimodale su larga scala.	TorchServe, Triton on CPU gestisce migliaia di modelli.
Pipeline di dati/ETL/Dati sintetici	Ray e Spark su CPU per la preparazione dei dati e l'ingegneria delle funzionalità.	N/A	Le CPU sono alla base dell'intera fase di preparazione dei dati
Orchestrazione degli agenti/recupero RAG	Network-bound servizi: gateway API, livelli proxy, retriever, chunker.	N/A	Vantaggi delle istanze CPU a larghezza di banda elevata.
Fine-tuning /Formazione	Preparazione dei dati e orchestrazione della pipeline.	Formazione e distillazione di modelli.	Ibrido: preparazione della CPU, formazione della GPU, inferenza della CPU.
Compliance-sensitive inferenza (FSI, assistenza sanitaria, governo)	SLM in VPC su CPU. I dati rimangono in conto, audit trail completo.	Uguale se gestita automaticamente su GPU.	La CPU vince in termini di costi per i modelli sub-8B in ambienti regolamentati.

avvertimento

Sebbene sia tecnicamente possibile eseguire oltre 70 miliardi di modelli su CPU con quantizzazione elevata (Q4 o inferiore), ciò è possibile solo per carichi di lavoro non in tempo reale, offline o in batch. Aspettatevi tassi di generazione di token bassi a una cifra (1-5 tokens/sec), requisiti di memoria superiori a 40 GB anche nel quarto trimestre e una latenza misurata in minuti per risposta per output più lunghi. Per qualsiasi caso d'uso interattivo o sensibile alla latenza, i modelli 70B+ sono compatibili con GPU o Trainium.

Flusso di lavoro Quick Benchmark

Prima di passare a una famiglia di istanze, consigliamo di eseguire un benchmark strutturato che metta a confronto le famiglie di CPU candidate (arm64 e x86) con quelle delle GPU sulla base di un'unica metrica comparabile: costo per 1.000 query alla latenza p95 desiderata. Implementate un nodo per famiglia con una configurazione di modello identica (stessa quantizzazione, dimensione del contesto, numero di thread), testate il carico di ciascuno e confrontatelo. Se un'istanza di CPU soddisfa lo SLO p95, probabilmente avrà un vantaggio in termini di costi. Se dovesse fallire anche solo per un piccolo margine, prova l'ultima generazione di quella famiglia prima di passare alla GPU. Se la latenza è ancora troppo elevata rispetto all'obiettivo di concorrenza, questo è il segnale per spostare il carico di lavoro sulla GPU.

Modelli di produzione

Modello 1: Agentic AI — SLM Pre-Filter su CPU con LLM Escalation

La maggior parte dei flussi di lavoro degli agenti esegue ripetutamente gli stessi schemi ristretti: classifica la richiesta, seleziona uno strumento, estrae dati strutturati, convalida una risposta. Queste attività non richiedono un modello di parametri 70B.

La ricerca sugli SLM (ar Xiv:2506.02153) dimostra che i modelli con parametri 10B, se specializzati per un dominio, possono eguagliare o superare LLM di grandi dimensioni su attività secondarie limitate, pur funzionando in modo efficiente sulla CPU a costi e latenza significativamente inferiori. Quando un modello viene ottimizzato per un dominio specifico, il suo ingombro ridotto può renderlo più preciso ed economico rispetto all'utilizzo di un LLM generico.

In questo modello, un SLM su CPU gestisce la maggior parte delle richieste dall'inizio alla fine. Un livello di routing (anch'esso in esecuzione sulla CPU) trasferisce solo i casi realmente complessi a un LLM. GPU-hosted

Componenti in esecuzione sulla CPU:

• Gateway API/livello proxy: gestisce l'autenticazione, il routing, la limitazione della velocità

• Agent orchestrator: gestisce le chiamate e lo stato degli strumenti

• Servizio di inferenza SLM: modello 1-8B quantizzato che utilizza un motore di inferenza come llama.cpp, Ollama o VLLm su CPU

• OpenSearch Recupero vettoriale: sui nodi CPU

Componenti su: GPU/Trainium

• LLM di grandi dimensioni per sintesi complesse, ragionamento a lungo contesto

Perché questo modello funziona: in molti flussi di lavoro agentici, il 60-80% delle richieste è classificabile o estraibile da un SLM. Per ogni chiamata LLM che eviti, eviti anche il lavoro che circonda la CPU, ovvero l'assemblaggio di un'ampia finestra contestuale, l'esecuzione di guardrail su una risposta lunga e la gestione di stati complessi. Il livello CPU è scalabile indipendentemente dal livello GPU.

Le categorie di carico di lavoro della CPU in una tipica pipeline agentic includono: esecuzione degli strumenti (chiamate server MCP, chiamate API, query del database), assemblaggio del contesto, ricerca vettoriale e incorporamento di ricerche, logica di orchestrazione e pianificazione, guardrail e filtri di sicurezza, convalida e formattazione delle risposte, gestione della memoria e dello stato degli agenti e. logging/observability

Questo modello si adatta anche a un ciclo di vita di ottimizzazione: raccolta dei dati di dominio sui nodi CPU, ottimizzazione sulla GPU, quindi distribuzione del modello quantizzato sulla CPU per l'inferenza a un costo sostanzialmente inferiore rispetto a un endpoint LLM. Una ricerca di LoRa Land (ar Xiv:2405.00732) mostra che i modelli 7B ottimizzati GPT-4 superano la maggior parte delle attività specifiche del dominio testate, rendendo il percorso «ottimizza un piccolo modello ed eseguilo sulla CPU» praticabile per molti casi d'uso di produzione.

Modello 2: CPU Model Farm High-Density

Le pipeline di Production ML implementano abitualmente centinaia o migliaia di modelli più piccoli: incorporamenti, consigli, classificatori, punteggi e modelli di visione artificiale. BERT-based Leggeri singolarmente, questi modelli diventano costosi quando a ciascuno vengono assegnate le proprie risorse GPU.

Consigliamo di utilizzare CPU ad alta densità (raggruppando più modelli per nodo utilizzando TorchServe Triton sulla CPU), affidando a Karpenter la gestione del ciclo di vita dei nodi e la scalabilità KEDA in base al carico osservato.

Questo modello si estende naturalmente alle architetture RAG: la generazione incorporata, la suddivisione in blocchi dei documenti e il recupero da OpenSearch tutte le architetture vengono eseguite in modo economico sui nodi della CPU, fornendo i risultati a un LLM solo per la fase di generazione finale. GPU-hosted La CPU farm gestisce il volume, la GPU gestisce la complessità.

Per i settori regolamentati (servizi finanziari, sanità, pubblica amministrazione), questo modello è particolarmente interessante: centinaia di modelli specializzati che eseguono in-VPC su CPU, con audit trail completi e dati che non escono mai dall'account. Il requisito di conformità per l'inferenza autogestita si allinea naturalmente al vantaggio in termini di costi della CPU per i modelli sub-8B.

Migliori pratiche di ottimizzazione

Quantizzazione

L'esecuzione di un modello 7B con BF16 completo sulla CPU non è pratica; eseguirlo nella quantizzazione del quarto trimestre è fattibile ed economico. Capire perché la quantizzazione aiuta la CPU è fondamentale per prendere buone decisioni sull'infrastruttura.

Perché la quantizzazione è importante per l'inferenza della CPU. L'inferenza della CPU è limitata alla larghezza di banda della memoria, non al calcolo. Durante la fase di decodifica (generazione dei token uno alla volta), tutti i pesi del modello vengono letti dalla RAM per ogni token prodotto. La CPU trascorre la maggior parte del tempo ad aspettare che i dati arrivino dalla memoria, senza fare calcoli matematici. Un modello 7B su BF16 pesa circa 14 GB; con Q4_K_M, si riduce a circa 4 GB. Poiché il collo di bottiglia è lo spostamento dei byte dalla RAM ai core della CPU, un modello 3,5 volte più piccolo legge 3,5 volte più velocemente, il che si traduce quasi direttamente in una generazione di token 3,5 volte più veloce. Ecco perché la quantizzazione è l'ottimizzazione più efficace per l'inferenza della CPU e perché le nuove generazioni di CPU con più canali di memoria producono inferenze più rapide anche alla stessa velocità di clock.

Ti consigliamo di creare il tuo motore di inferenza con backend ottimizzati per l'architettura (ARM NEON/SVE2 per arm64, AVX-512/AMX per x86), impostare un numero di thread uguale al numero di vCPU e selezionare i formati di quantizzazione Q4_K_M o Q8_0.

Quantizzazione	Impatto sulla qualità	Throughput rispetto a BF16	Caso d'uso
Q4_K_M	Basso (delta di perplessità dell'1-3%, dipende dal modello)	~ 4-5 volte più veloce	Impostazione di produzione predefinita per gli SLM
Q8_0	Trascurabile	~ 2 volte più veloce	Quality-sensitive attività
Q5_K_M	Molto basso	~ 3,5 volte più veloce	Equilibrio tra qualità e velocità
BF16	Nessuno	1x (linea di base)	Evita la CPU per i modelli 7B+

Per i modelli sub-2B, la CPU vince in termini di rapporto prezzo/prestazioni rispetto alla GPU. Questi modelli sono sufficientemente piccoli da consentire l'accelerazione GPU di offrire vantaggi minimi, mentre il costo orario è notevolmente più elevato. Se il carico di lavoro può utilizzare un modello sub-2B, la CPU è l'impostazione predefinita consigliata.

Architecture-specific ottimizzazioni: su arm64, le istanze Graviton di attuale generazione supportano SVE2. Costruisci il tuo motore di inferenza con la bandiera appropriata per il tuo obiettivo. -march Su x86, le istanze AMD EPYC supportano AVX-512 e le istanze Intel Xeon aggiungono AMX per l'accelerazione delle matrici. Poiché l'inferenza è limitata alla larghezza di banda della memoria, le nuove generazioni di CPU con più canali di memoria DDR5 producono inferenze più rapide anche alla stessa velocità di clock. Nella scelta dei tipi di istanza, dai la priorità alla larghezza di banda della memoria rispetto al numero di core.

Dimensionamento contestuale delle finestre: per i carichi di lavoro di classificazione e routing, gli input sono in genere inferiori a 200 token e gli output sono 2-3 token. L'impostazione di una piccola finestra contestuale (ad esempio 512 token) anziché quella predefinita 2048 riduce l'utilizzo della memoria cache KV e migliora la latenza per richiesta. Aumenta la finestra contestuale solo se i tuoi input sono veramente lunghi.

Flash Attention: abilita Flash Attention se il tuo motore di inferenza lo supporta. Flash Attention riduce l'utilizzo della memoria per il calcolo dell'attenzione evitando la materializzazione dell'intera matrice di attenzione. Sulla CPU, il vantaggio è minore rispetto alla GPU, ma è comunque utile per input più lunghi.

Suggerimento

Il degrado della qualità di Q4_K_M varia in base al modello e all'attività. Valuta sempre il tuo set di dati prima di passare alla produzione.

Bin-packing per un servizio denso

Per i modelli di machine learning e embedded classici (in genere <500 MB ciascuno), l'obiettivo è la massima densità di pod per nodo con una latenza di coda stabile. Due fattori determinano il raggiungimento di tale obiettivo: richieste di risorse accurate e threading controllato.

Basatevi requests sull'utilizzo osservato di p50-p90 con un carico realistico. Usa i consigli Goldilocks, VPA o gli istogrammi Prometheus di un test di carico. Le impostazioni predefinite sono quasi sempre errate in entrambe le direzioni.

Le librerie ML (PyTorch, ONNX Runtime, MKL, OpenBLAS) generano tutti i thread possibili per vedere le vCPU sul nodo, non le CPU allocate al pod. Su un nodo denso con 20 pod, ogni pod tenta di generare 32 thread. Il nodo si blocca in caso di cambio di contesto e picchi di latenza p99. Risolvilo in modo esplicito:

env:
  - name: OMP_NUM_THREADS
    value: "2"          # match your cpu request (2000m = 2 threads)
  - name: MKL_NUM_THREADS
    value: "2"
  - name: OPENBLAS_NUM_THREADS
    value: "2"
  - name: INTRA_OP_NUM_THREADS    # PyTorch / ONNX Runtime
    value: "2"
  - name: NUM_INTER_THREADS
    value: "1"          # keep inter-op parallelism minimal

Imposta ogni valore uguale o inferiore alla richiesta della CPU. Per i pod con più di 4 core, esegui il benchmark a partire da 2-4 thread. Molti modelli di piccole dimensioni offrono prestazioni migliori con un minor numero di thread grazie all'efficienza della cache. Se utilizzi HPA con molti pod sottili, vincono quasi sempre 1-2 thread per pod.

Pianificazione e ottimizzazione dei costi

Due pratiche si combinano per ridurre in modo significativo i costi di inferenza della CPU: le istanze Spot con consolidamento Karpenter e le immagini di container multi-arch.

Il consolidamento di Karpenter funziona bene per l'inferenza della CPU perché i pod di inferenza stateless posizionati dietro una coda o un sistema di bilanciamento del carico tollerano senza problemi le interruzioni. Configura il consolidamento per agire sui nodi sottoutilizzati con un budget che limiti le interruzioni simultanee (ad esempio, il 20% dei nodi alla volta) per evitare cali di capacità durante la scalabilità. Le nodePool specifiche di Karpenter ti consentono di combinare Spot e On-Demand capacità in un unico pool, con Spot come opzione preferita e come alternativa. On-Demand

La creazione di immagini con più archi (arm64eamd64) sblocca ulteriormente tutto questo. Con entrambe le architetture disponibili, Karpenter può scegliere tra l'intera gamma di famiglie di istanze (Graviton, AMD, Intel) in base al prezzo e alla disponibilità in tempo reale. Ciò è particolarmente utile per i carichi di lavoro Spot, in cui la diversificazione tra tipi di istanze e architetture riduce la frequenza delle interruzioni. Utilizza docker buildx una pipeline CI con build multipiattaforma per produrre un unico manifesto che copra entrambe le architetture.

Ottimizzazione dell'avvio dei container

Quando Karpenter effettua il provisioning di un nuovo nodo (scalabilità verticale, sostituzione di Spot), il runtime del contenitore deve recuperare l'immagine di inferenza prima che il pod possa iniziare. Per le immagini di inferenza da più GB, ciò può aggiungere 30-60 secondi all'avvio del pod.

Consigliamo di utilizzare Bottlerocket come sistema operativo del nodo per i carichi di lavoro di inferenza, combinato con lo snapshotter SOCI in modalità parallela. pull/unpack SOCI sostituisce l'estrazione sequenziale predefinita dei livelli con download paralleli basati su blocchi, riducendo significativamente i tempi di recupero delle immagini per immagini di grandi dimensioni. Non sono necessarie modifiche alle immagini del contenitore.

Per indicazioni dettagliate sulla configurazione, consulta la sezione Prestazioni di questa guida, che tratta la configurazione SOCI, la preestrazione delle istantanee EBS e le strategie di cache di runtime dei contenitori.

Osservabilità

Senza osservabilità a livello di modello, la scalabilità avviene alla cieca. Consigliamo di esporre le metriche di Prometheus per ogni servizio di inferenza e di utilizzarle per gestire sia la scalabilità KEDA che i dashboard operativi.

La maggior parte dei server di inferenza (llama.cpp, VLLm, Triton) espongono le metriche su un endpoint. TorchServe Prometheus-compatible /metrics I nomi delle metriche variano in base al server, ma i concetti sono gli stessi.

Metriche chiave dello strumento:

Categoria metrica	Description	Soglia di avviso
Elaborazione delle richieste/in volo	Numero di richieste attualmente gestite dal server.	Utilizzare per il ridimensionamento (vedere la sezione sulla scalabilità automatica di seguito)
Richieste in coda/ differite	Numero di richieste in attesa di uno slot di elaborazione.	Trigger della scala. Qualsiasi coda sostenuta significa che la latenza sta per peggiorare.
Throughput dei token	Token generati al secondo.	Avvisa se il throughput scende al di sotto del 50% della linea di base sotto carico
Latenza della richiesta	End-to-end istogramma di latenza (elaborazione tempestiva + generazione di token).	Avviso relativo al superamento dello SLO da p95
Utilizzo della cache KV	Quanto è piena la cache dei valori chiave (da 0,0 a 1,0). L'avvicinamento a 1.0 significa che il server inizierà a rifiutare o a mettere in coda le richieste.	Avviso all'85% +
Memoria del contenitore	Memoria RSS per pod (container_memory_working_set_bytes).	Avviso all'85% del limite

Scalabilità automatica: scalabilità in base alla profondità della coda, non all'utilizzo della CPU

L'utilizzo della CPU è una metrica di saturazione. Aumenta dopo che la latenza è già diminuita. Quando la scalabilità automatica basata sull'utilizzo reagisce, gli utenti sono già in attesa.

La profondità della coda (richieste) è un indicatore principale. deferred/waiting Aumenta prima che la latenza diminuisca, perché le richieste iniziano a mettersi in coda quando tutti gli slot di elaborazione sono occupati. La scalabilità in base alla profondità della coda significa che vengono fornite nuove repliche mentre quelle esistenti continuano a rispondere normalmente.

KEDA supporta la combinazione di più metriche in un'unica formula di ridimensionamento utilizzando (richiede KEDA 2.12+). scalingModifiers Lo schema consigliato per i carichi di lavoro di inferenza consiste nel combinare le richieste in corso con quelle in coda, ponderando pesantemente la metrica della coda:

advanced:
  scalingModifiers:
    formula: "running + (waiting * 10)"
    target: "25"
    activationTarget: "5"

La formula running + (waiting * 10) indica che anche 3 richieste in coda spingono la metrica combinata a 55, ben al di sopra dell'obiettivo di 25. La scalabilità interviene prima che la latenza diminuisca. Il valore activationTarget di 5 impedisce al rumore di innescare eventi di scala da zero non necessari.

Valutazione della qualità dei modelli per i carichi di lavoro CPU-First

L'implementazione di una SLM quantizzata sulla CPU è una decisione in termini di costi e latenza. Ha senso solo se il modello produce ancora risultati corretti e utili per il carico di lavoro.

I modelli più piccoli o la quantizzazione riducono i costi di elaborazione ma possono ridurre la qualità. L'impatto varia. I carichi di lavoro che funzionano bene sulla CPU (classificazione, estrazione, routing, riepilogo, incorporamenti) spesso mantengono una buona qualità nell'B-7B intervallo 3 con una quantizzazione e un prompting adeguati.

Cosa valutare

Carichi di lavoro diversi si degradano in modi diversi:

Carico di lavoro	Cosa può degradarsi	Cosa misurare
Intento o classificazione del biglietto	Errori sugli input ambigui	Precisione, F1 per classe
Estrazione strutturata (JSON)	Campi mancanti o schema errato	Corrispondenza esatta, validità dello schema
RAG risponde	Allucinazioni o ignoranza del contesto	Fedeltà, pertinenza della risposta
Riassunto	Fatti mancanti o scarsa copertura	ROUGE-L, BertScore, recensione umana
Routing degli agenti	Selezione dello strumento sbagliato	Precisione dello strumento
Embedding	Qualità di recupero peggiore	Richiama @K, NDCG

Un pratico flusso di lavoro di valutazione

Consigliamo di creare un controllo di qualità prima della produzione, in modo analogo a come si esegue un test di carico prima di scegliere un tipo di istanza. Il flusso di lavoro prevede quattro fasi:

1. Crea un set di dati di valutazione: crea un piccolo set di dati di valutazione (100-300 esempi etichettati) a partire dal tuo carico di lavoro effettivo. Evitate benchmark generici come MMLU, che misurano il ragionamento generale piuttosto che il vostro compito reale.

2. Stabilisci una linea di base: esegui il set di dati rispetto a un modello affidabile (ad esempio, un LLM di grandi dimensioni che conosci produce risultati corretti).

3. Testa il modello di CPU: esegui lo stesso set di dati sul tuo SLM quantizzato e confrontalo.

4. Valuta: definisci la tua soglia di qualità prima di testare, ad esempio, «la precisione SLM entro 5 punti percentuali rispetto al valore di base». La soglia giusta dipende dal compito da svolgere: un classificatore esaminato da esseri umani può tollerare più errori di un sistema che prende decisioni automatiche.

Come recuperare la qualità

Se il modello funziona male, prova questi in ordine di sforzo:

• Aggiungi alcuni esempi nel prompt: Costo zero, immediato. L'inclusione di 3-5 esempi etichettati nel prompt spesso colma il divario tra le attività di classificazione ed estrazione.

• Utilizzate un formato di quantizzazione di qualità superiore: il passaggio da Q4 a Q8 spesso ripristina gran parte della qualità perduta, con un costo di circa 2 volte più memoria e un throughput inferiore.

• Usa il routing ibrido: lascia che SLM gestisca casi semplici e invii input difficili a un modello più grande. Si tratta di una modifica dell'architettura, ma mantiene bassi i costi della CPU per la maggior parte del traffico.

• Fine-tune il modello del tuo dominio: l'opzione più costosa, ma la più efficace. Una ricerca di LoRa Land (ar Xiv:2405.00732) ha rilevato che i modelli 7B ottimizzati superano le prestazioni nella maggior parte delle attività specifiche del dominio GPT-4 testate.

Riferimenti

• Documentazione Amazon EKS

• Guida per sviluppatori di AWS Graviton

• Documentazione Karpenter

• Documentazione KEDA

• llama.cpp

• Documentazione VLLm

• Ollama

• Documentazione Ray Serve

• OpenSearch Servizio Amazon

• Best practice AWS Spot

• LoRa Land: Fine-Tuned Open-Source LLM con prestazioni superiori GPT-4

• Specifiche del Model Context Protocol (MCP)

• Modelli linguistici di piccole dimensioni per Agentic AI (NVIDIA)

• Snapshotter SOCI

• Sistema operativo Bottlerocket

• AI su EKS: ottimizzazione dell'avvio dei container