Intel Inference Microservices contrappone i server Xeon esistenti al paradigma AI GPU-first

Intel ha lanciato Intel Inference Microservices il 14 ottobre, trasformando tre generazioni di processori Xeon in server preconfigurati per i modelli linguistici di grandi dimensioni. La prima versione supporta le CPU Xeon di quarta, quinta e sesta generazione. Mette in discussione l'idea che ogni progetto di AI in produzione debba iniziare con nuova capacità GPU.

Il software riunisce in un container un modello, il motore di serving vLLM e impostazioni specifiche per l'hardware. All'avvio rileva il processore disponibile e seleziona una configurazione che Intel ha testato per quella combinazione di modello e silicio. Le applicazioni si connettono tramite un'API compatibile con OpenAI, che segue formati di richiesta familiari usati dai comuni strumenti di sviluppo AI.

Questo packaging è l'aspetto importante. Intel non sostiene che una CPU general-purpose superi improvvisamente ogni acceleratore dedicato. Offre alle imprese un modo per distribuire modelli selezionati su server che potrebbero già possedere. Così contrappone la base installata di Xeon al percorso di approvvigionamento GPU-first promosso da Nvidia e da altri fornitori di acceleratori.

Intel Inference Microservices trasforma l'ottimizzazione delle CPU in un container

Intel ha convertito un'attività di ottimizzazione specialistica in un artefatto di distribuzione che i normali team di piattaforma possono eseguire.

L'annuncio di lancio descrive ogni microservizio come un container che serve un modello su un host. Un'immagine validata include impostazioni selezionate per una specifica combinazione di modello e hardware Xeon.

L'esempio iniziale di Intel serve Qwen3-4B, un modello linguistico da quattro miliardi di parametri, con un comando Docker. La configurazione hardware di base suggerita è un processore Xeon supportato e 32 GB di memoria. I modelli più grandi richiedono maggiore capacità.

Il container esamina la generazione del processore, i core allocati, il layout della memoria, i set di istruzioni disponibili e la topologia di accesso non uniforme alla memoria. NUMA descrive sistemi in cui il tempo di accesso alla memoria dipende da quale socket del processore possiede una regione di memoria. Un posizionamento inadeguato può ridurre le prestazioni di inferenza anche quando un server dispone di memoria totale sufficiente.

Il runtime seleziona quindi un profilo corrispondente e avvia vLLM. Questo motore open source gestisce l'esecuzione del modello, il batching delle richieste, la generazione di token e l'endpoint API usato dalle applicazioni.

Intel afferma che il profilo controlla la precisione, la distribuzione del lavoro tra i core e il posizionamento della memoria. Queste scelte determinano se le unità matematiche del processore restano occupate o attendono i dati.

I recenti chip Xeon includono Advanced Matrix Extensions, o AMX, che accelerano le operazioni matriciali impiegate nelle reti neurali. Includono inoltre set di istruzioni vettoriali come AVX-512, AVX2 e VNNI. Il software deve riconoscere e utilizzare queste capacità prima che possano influire sulle prestazioni delle applicazioni.

Le immagini di modelli validate adottano un approccio prudente. Se un'immagine specifica per un modello non riesce a trovare un profilo supportato, genera un errore all'avvio invece di eseguire silenziosamente una configurazione non testata. Questo comportamento fornisce agli operatori un chiaro segnale di errore.

Intel fornisce anche un'immagine di base per modelli esterni al suo catalogo validato. L'immagine di base può accettare un identificatore di modello Hugging Face e usare un profilo hardware generale compatibile. Tuttavia, questo percorso non dispone della stessa validazione specifica per il modello.

Questa distinzione è importante. “Funziona” e “Intel ha ottimizzato questa combinazione esatta” sono affermazioni diverse. I team che valutano il software dovrebbero registrare quale percorso utilizzano prima di confrontare i risultati.

La versione iniziale usa BF16, un formato numerico a 16 bit che riduce l'uso della memoria rispetto ai calcoli convenzionali a 32 bit. Ulteriori formati numerici e motori di inferenza restano previsti anziché già disponibili.

Le applicazioni chiamano endpoint standard per chat completion, text completion, modello, integrità e metriche. Intel afferma che OpenAI SDK, LangChain, LlamaIndex, LiteLLM e Haystack possono connettersi modificando il loro URL di base.

Questa compatibilità riduce le modifiche alle applicazioni, ma non elimina il lavoro operativo. I team devono comunque gestire accesso ai modelli, immagini dei container, storage, autenticazione, networking, monitoraggio e capacità.

Anche il primo download può richiedere diversi minuti mentre arrivano i pesi del modello. Intel raccomanda di fissare le versioni delle immagini anziché usare un'etichetta “latest” immutabile. Il version pinning aiuta i team a riprodurre le distribuzioni e a controllare gli aggiornamenti.

Il risultato è un prodotto più circoscritto di una piattaforma AI ospitata. È anche più concreto dell'ennesima raccolta di librerie di ottimizzazione. Intel ha racchiuso le proprie raccomandazioni in qualcosa che i team infrastrutturali possono scaricare, ispezionare, testare e pianificare.

Perché la capacità Xeon esistente cambia la questione dell'approvvigionamento

L'opportunità immediata non è sostituire ogni cluster GPU. È individuare i carichi di lavoro che non giustificano più l'acquisto di uno.

Le imprese gestiscono comunemente ampie flotte di server x86 per database, virtualizzazione, applicazioni aziendali e servizi interni. Molti includono recenti processori Xeon con funzionalità di accelerazione che rimangono inutilizzate dai carichi di lavoro convenzionali.

Intel Inference Microservices rende questa capacità rilevante per la pianificazione AI. Un team può testare un modello supportato su un host esistente prima di richiedere hardware specializzato. Questo cambia la prima domanda di approvvigionamento da “Quale acceleratore dovremmo acquistare?” a “Questo carico di lavoro necessita di un acceleratore?”.

La distinzione ha conseguenze pratiche. L'approvvigionamento hardware implica approvazioni, consegna, capacità rack, pianificazione dell'alimentazione e integrazione. La capacità CPU disponibile può accorciare la fase sperimentale quando modello e carico di lavoro sono adatti.

Un piccolo assistente interno offre un esempio. Potrebbe riassumere policy, classificare richieste di supporto, estrarre campi da documenti o rispondere a domande su una raccolta di conoscenze limitata. Tali applicazioni non richiedono automaticamente il massimo throughput possibile di token.

La latenza resta importante, ma i modelli di domanda differiscono. Uno strumento utilizzato da un reparto durante l'orario lavorativo presenta un problema di capacità diverso da un servizio pubblico che gestisce migliaia di conversazioni simultanee.

L'inferenza su CPU può essere adatta anche ad applicazioni in cui la capacità di memoria esistente conta più della velocità massima di generazione. La memoria di sistema è spesso più abbondante della memoria degli acceleratori, sebbene le sue caratteristiche di larghezza di banda e latenza differiscano sensibilmente.

La posizione dei dati aggiunge un'altra considerazione. I container di Intel vengono eseguiti nell'ambiente del cliente, quindi prompt e documenti recuperati non devono lasciare quella distribuzione per un'inferenza ospitata. Questo non rende un'installazione sicura per impostazione predefinita, ma offre agli operatori il controllo diretto del confine.

L'interfaccia compatibile con OpenAI aiuta a preservare la portabilità delle applicazioni. Gli sviluppatori possono mantenere la stessa struttura generale delle richieste spostando un endpoint tra un servizio ospitato e una distribuzione locale. Il comportamento dei modelli e le funzionalità supportate possono comunque differire.

Intel presenta questa interfaccia come un contratto a più lungo termine per l'intero portafoglio hardware. La versione attuale è rivolta alle CPU Xeon, mentre il supporto per le GPU Intel resta previsto. Intel afferma che la stessa interfaccia applicativa si estenderà infine sia ai processori sia agli acceleratori dedicati.

Questa direzione corrisponde alla più ampia strategia eterogenea di Intel. Il suo aggiornamento infrastrutturale di ottobre ha posizionato Xeon come livello di orchestrazione e calcolo general-purpose accanto agli acceleratori progettati per compiti specifici. Lo stesso aggiornamento ha introdotto maggiori dettagli sulla GPU D-series, in precedenza chiamata Crescent Island.

La GPU D-series è progettata per un'inferenza sostenuta e ad alta intensità di memoria. Intel afferma che i design dei partner possono offrire fino a 480 GB di memoria LPDDR5X, mentre la sua scheda a marchio proprio dispone di 160 GB.

Questa roadmap hardware rivela il limite di un semplice argomento CPU contro GPU. Intel stessa prevede che gli acceleratori dedicati gestiscano carichi di lavoro per i quali dimensione del modello, concorrenza o aspetti economici lo richiedono. I microservizi Xeon forniscono un punto d'ingresso, non un punto d'arrivo universale.

Per gli acquirenti aziendali, l'inquadramento più utile è il posizionamento del carico di lavoro. Un modello modesto con domanda intermittente può adattarsi a un server CPU esistente. Un modello grande che serve molti utenti con obiettivi di latenza rigorosi probabilmente favorirà un'accelerazione specializzata.

Il software di Intel rende più facile testare questa decisione di posizionamento. Non rende predeterminata la risposta.

La vera competizione è il riuso di Xeon contro la distribuzione GPU-first

Intel compete con l'idea che l'inferenza in produzione inizi sugli acceleratori, non semplicemente con un chip rivale.

Nvidia ha già stabilito un modello di packaging simile attorno alle proprie GPU. Nvidia Inference Microservices, comunemente chiamati NIM, riuniscono modelli, profili ottimizzati, motori di serving e API standard in container distribuibili.

L'attuale architettura NIM usa anch'essa vLLM per i carichi di lavoro di modelli linguistici di grandi dimensioni supportati. Aggiunge selezione dei profili, gestione dell'integrità, osservabilità, routing e altre funzioni di produzione attorno al motore.

Questo rende più facile comprendere la mossa di Intel. Il prodotto non introduce l'idea dei microservizi di inferenza. Applica quel modello ai processori Intel, iniziando dai server Xeon già comuni negli ambienti aziendali.

Entrambi gli approcci riconoscono lo stesso problema. Un motore di inferenza espone molte impostazioni e la migliore configurazione dipende da modello, hardware, precisione, memoria e traffico previsto. La maggior parte dei team applicativi non desidera mantenere un laboratorio di benchmark per ogni distribuzione.

La differenza è il punto di partenza hardware. L'offerta di Nvidia indirizza i carichi di lavoro verso GPU supportate. Intel parte dalle CPU Xeon e promette un futuro percorso verso le GPU Intel dietro la stessa interfaccia.

Questo offre a Intel uno specifico argomento commerciale. Le organizzazioni possono iniziare con i processori disponibili e spostare soltanto i carichi di lavoro che li superano. Il valore dipende dal fatto che Intel mantenga questa transizione operativamente semplice.

Le due offerte condividono inoltre uno standard importante. Entrambe espongono endpoint compatibili con OpenAI ed entrambe usano vLLM nelle configurazioni pertinenti. Le interfacce standardizzate riducono alcuni costi di passaggio a livello applicativo.

Non eliminano il lock-in dell'infrastruttura. Immagini dei container, driver, profili ottimizzati, modelli supportati, formati numerici, sistemi di monitoraggio e accordi di supporto variano ancora in base al fornitore. Un'API compatibile è solo uno strato della portabilità.

AMD aggiunge ulteriore pressione attraverso la linea di processori EPYC e il software per acceleratori ROCm. Tuttavia, l'avversario immediato della nuova versione di Intel è l'abitudine consolidata alla distribuzione GPU-first. Intel deve dimostrare che il riuso delle CPU produce una qualità del servizio accettabile per carichi di lavoro identificabili.

Non si tratta principalmente di una competizione sulle prestazioni di picco. Un benchmark che dimostri come una GPU generi più token al secondo non risolverebbe la decisione di approvvigionamento. Gli acquirenti considerano anche utilizzo, capacità disponibile, tempi di distribuzione, alimentazione, supporto e impegno ingegneristico.

Al contrario, possedere un server Xeon non rende gratuita l'inferenza. L'esecuzione dell'AI consuma memoria, core, elettricità, larghezza di banda dello storage e attenzione operativa. La capacità assegnata a un modello non può servire contemporaneamente un altro carico di lavoro.

Il costo opportunità diventa particolarmente importante negli ambienti consolidati. Un server che appare inattivo durante una finestra di osservazione può fornire capacità di failover o assorbire picchi aziendali prevedibili.

Anche le licenze software restano specifiche per modello. Intel osserva che gli utenti devono rispettare la licenza associata a ciascun modello distribuito. Inserire un modello in un comodo container non ne modifica i termini di utilizzo consentito.

Il caso d'uso più solido richiede quindi capacità inutilizzata misurabile, un modello supportato e un carico di lavoro con requisiti di servizio moderati. Senza queste tre condizioni, il riutilizzo delle CPU può diventare uno slogan accattivante anziché un'architettura valida.

Intel Inference Microservices offre ai team un modo strutturato per verificare questa ipotesi. Gli acquirenti dovrebbero considerare il container come l'inizio di una valutazione, non come la sua conclusione.

La regolazione automatica risolve l'attrito di configurazione, non la fisica dell'inferenza

La release riduce il lavoro di configurazione, ma non elimina le differenze prestazionali tra processori, sistemi di memoria e forme dei carichi di lavoro.

L'inferenza dei modelli linguistici si articola in due fasi principali. Il prefill elabora il prompt di input, mentre la decodifica genera sequenzialmente i token di output. Ciascuna fase sollecita l'hardware in modo diverso.

I prompt lunghi richiedono una notevole capacità di calcolo durante il prefill. La decodifica può essere limitata dallo spostamento dei dati in memoria, poiché il sistema legge ripetutamente i pesi del modello e la cache chiave-valore in crescita. Questa cache memorizza dati di attenzione intermedi utilizzati nella generazione dei token successivi.

Le GPU e altri acceleratori offrono un'elevata larghezza di banda della memoria e un ampio calcolo parallelo. Le CPU offrono flessibilità, ampia disponibilità, grandi opzioni di memoria di sistema e una matura integrazione aziendale. Nessuno di questi aspetti determina le prestazioni senza un modello e un profilo di traffico specifici.

Il batching introduce un altro compromesso. Combinare le richieste può migliorare il throughput mantenendo l'hardware occupato. Può anche aumentare il tempo di attesa percepito dal singolo utente.

I profili di Intel possono codificare impostazioni ragionevoli per queste decisioni. Non possono conoscere l'obiettivo di livello di servizio, la distribuzione dei prompt o il modello di concorrenza di ogni organizzazione.

L'attuale ambito del prodotto rende visibile questa limitazione. Un microservizio serve un modello su un host. Le distribuzioni più grandi richiedono un ulteriore livello di orchestrazione, bilanciamento del carico, gestione delle repliche, controlli di sicurezza e instradamento.

Intel indirizza i clienti che necessitano di una flotta condivisa verso il proprio toolkit AI for Enterprise Inference. Questo stack open source aggiunge un gateway LLM, autenticazione, autorizzazione, telemetria, monitoraggio, orchestrazione Kubernetes e più motori di inferenza.

Questi componenti affrontano un livello diverso del sistema. Il microservizio produce un endpoint ottimizzato. Il toolkit enterprise coordina gli endpoint per più utenti e team.

Gli acquirenti per l'ambiente di produzione dovrebbero esaminare attentamente questa separazione. Un container che risponde a un prompt di test non è ancora un servizio interno affidabile. L'affidabilità richiede controlli di integrità, policy di capacità, procedure di aggiornamento, gestione dei guasti, osservabilità e controlli di accesso.

Anche la compatibilità delle funzionalità merita test. La prima release di Intel espone il tool calling e l'output strutturato tramite il comportamento di pass-through di vLLM. Intel non descrive queste capacità come funzionalità validate allo stesso modo dei suoi profili hardware.

Il tool calling consente a un modello di richiedere funzioni esterne, mentre l'output strutturato vincola le risposte a un formato definito. Entrambi sono importanti per le applicazioni aziendali agentiche. Una funzionalità che funziona in un test di base può comunque fallire con schemi complessi o prompt specifici del modello.

L'iniziale attenzione a BF16 crea un ulteriore confine. Formati a precisione inferiore come INT8 o INT4 possono ridurre il consumo di memoria e migliorare il throughput, ma potrebbero richiedere una validazione separata. Intel elenca ulteriori precisioni come lavoro futuro.

Anche la copertura dei modelli è altrettanto importante. Intel fornisce immagini specifiche per modello per le voci di catalogo e un'immagine base generale per altri modelli Hugging Face. Il percorso generale privilegia l'ampiezza della copertura, mentre quello validato privilegia una configurazione prevedibile.

I team non dovrebbero confrontare questi percorsi come se offrissero identiche garanzie. Un profilo generale potrebbe eseguire con successo un modello non supportato senza fornire il risultato atteso dall'ottimizzazione specifica per modello.

La documentazione di distribuzione identifica anche requisiti pratici. Alcuni modelli con accesso controllato richiedono un token Hugging Face e la preventiva accettazione della licenza. I file dei modelli necessitano di archiviazione locale e i modelli più grandi richiedono più dei 32 GB di base consigliati.

I team di sicurezza dovrebbero verificare come i token entrano nei container e se la cronologia della shell, le variabili d'ambiente o i manifest del cluster li espongono. Dovrebbero inoltre analizzare le immagini, limitare l'accesso alla rete e autenticare l'endpoint di inferenza.

Queste preoccupazioni non invalidano l'approccio di Intel. Definiscono il divario tra ottimizzazione semplificata e operazioni semplificate. La prima release affronta la prima in modo più completo della seconda.

Intel non ha ancora pubblicato il confronto di cui gli acquirenti hanno bisogno

L'incertezza centrale riguarda le prestazioni economiche con carichi di lavoro reali, non la possibilità che il container avvii un modello.

Intel afferma che i suoi profili validati racchiudono la migliore configurazione misurata per combinazioni di modelli e processori supportati. Questa dichiarazione descrive il processo di ottimizzazione di Intel. Non fornisce un confronto indipendente con deployment Xeon non ottimizzati, CPU concorrenti o acceleratori attuali.

L'annuncio non presenta un insieme completo di risultati su latenza, throughput, energia o costo totale per i microservizi. Gli acquirenti non possono quindi dedurre un vantaggio universale dal solo lancio.

Una valutazione utile richiede più dei token medi al secondo. I team dovrebbero registrare il tempo al primo token, la latenza inter-token, la latenza totale della richiesta, il throughput a diversi livelli di concorrenza, il consumo di memoria e i tassi di errore.

Il tempo al primo token misura la rapidità con cui un utente vede una risposta iniziale. La latenza inter-token misura il ritmo della generazione successiva. Un'applicazione può registrare un elevato throughput aggregato pur continuando a sembrare lenta al singolo utente.

I test dovrebbero usare prompt e lunghezze di output rappresentativi. Una breve richiesta di classificazione produce un comportamento diverso da un assistente di ricerca che riceve documenti lunghi e genera risposte dettagliate.

Anche la concorrenza deve rispecchiare la produzione. Un processore che serve una sola richiesta può comportarsi diversamente quando le code si accumulano. Le policy di batching possono migliorare l'output totale peggiorando al contempo la latenza di coda, che rappresenta la parte più lenta delle richieste.

La misurazione dell'energia richiede altrettanta attenzione. Un server CPU già installato in un rack continua a consumare energia aggiuntiva durante un'inferenza sostenuta. I team dovrebbero confrontare il lavoro completato per unità di energia, non soltanto la potenza nominale di un componente.

Il costo totale dovrebbe includere il tempo di ingegneria. L'affermazione più forte di Intel riguarda il lavoro manuale di ottimizzazione che i suoi profili sostituiscono. Una prova equa dovrebbe misurare quanto tempo richiedono sia il percorso preconfezionato sia quello autogestito per essere distribuiti, stabilizzati e aggiornati.

Il confronto dovrebbe includere anche un deployment GPU adeguato, non un cluster sovradimensionato scelto per far apparire economica la CPU. L'hardware dovrebbe essere abbinato al carico di lavoro e alla crescita prevista.

La qualità deve restare costante tra i test. Modificare precisione, quantizzazione, versione del modello o lunghezza del contesto può alterare il comportamento dell'output. Un risultato più veloce non è comparabile se cambia l'accuratezza del modello o l'insieme di funzionalità utilizzabili.

I benchmark indipendenti saranno importanti perché Intel controlla sia i profili sia la narrativa iniziale sulle prestazioni. Test riproducibili da parte di clienti, fornitori cloud e organizzazioni di benchmark neutrali offrirebbero agli acquirenti prove più solide.

I precedenti risultati MLPerf di Intel mostrano che l'azienda partecipa a test di inferenza standardizzati su CPU e GPU. Tuttavia, queste presentazioni non dovrebbero essere trattate come una validazione diretta di questa nuova release di container.

I microservizi richiedono risultati propri perché il packaging può modificare prestazioni, funzionalità supportate e comportamento operativo. La versione 0.1.0 segnala inoltre una fase iniziale del prodotto, sebbene i numeri di versione non garantiscano un particolare livello di maturità.

Le immagini specifiche per modello falliscono intenzionalmente quando non trovano un profilo validato. Questo design favorisce la prevedibilità, ma restringe anche le combinazioni di hardware e modelli disponibili per i primi utenti.

L'immagine base estende la copertura tramite profili di fallback. Tuttavia, il successo del fallback non deve essere scambiato per prestazioni ottimizzate. I team dovrebbero etichettare i record di benchmark con l'immagine, il modello, l'host, il profilo e la versione del runtime esatti.

Questa disciplina aiuterà le aziende a decidere se Intel Inference Microservices riduce davvero il loro carico di infrastruttura AI. Metterà inoltre in evidenza i carichi di lavoro che appartengono ancora agli acceleratori.

Tre segnali mostreranno se la strategia AI Xeon di Intel funziona

La copertura dei modelli, i risultati indipendenti in produzione e la portabilità tra hardware determineranno se questa soluzione diventerà una piattaforma o resterà una scorciatoia utile per il deployment.

Il primo segnale è l'espansione del catalogo di modelli validati. Gli acquirenti dovrebbero osservare con quale rapidità Intel aggiunge modelli ampiamente distribuiti, architetture più recenti, precisioni aggiuntive e profili rivisti.

La crescita del catalogo conta perché la validazione specifica per modello è il vantaggio più evidente del prodotto rispetto a un container generico. Aggiornamenti lenti spingerebbero i team verso l'immagine base, dove Intel offre minori garanzie specifiche per il carico di lavoro.

Il segnale rafforza la posizione di Intel se i nuovi modelli ricevono immagini validate subito dopo il rilascio. La indebolisce se gli utenti devono dipendere da fallback generali per i modelli che desiderano effettivamente utilizzare.

Il secondo segnale è costituito da dati riproducibili sulle prestazioni dei clienti. I report utili descriveranno modelli di processore, numero di socket, configurazioni di memoria, versioni dei container, lunghezze dei prompt, concorrenza e obiettivi di servizio.

Un'ampia affermazione di “inferenza più veloce” offre poche indicazioni. Gli acquirenti hanno bisogno di prove a livello di carico di lavoro che mostrino quando il riutilizzo di Xeon supera l'acquisizione, il noleggio o la riallocazione della capacità degli acceleratori.

Le prove di produzione dovrebbero includere anche i risultati operativi. Tempo di deployment, recupero dai guasti, frequenza degli aggiornamenti e impegno del personale sono elementi centrali della promessa di Intel di rendere l'inferenza più semplice.

Il terzo segnale è l'estensione pianificata da Intel alle GPU. Intel afferma che lo stesso contratto di microservizio supporterà alla fine il proprio hardware di inferenza per data center, inclusa la GPU D-series.

Questa transizione metterà alla prova l'argomentazione dell'azienda sulla portabilità. Se le applicazioni potranno passare da Xeon a una GPU Intel con modifiche minime, Intel offrirà un percorso di scalabilità credibile.

Se il passaggio richiederà immagini diverse, strumenti operativi diversi, compromessi sulle funzionalità o un'ampia riottimizzazione, l'API comune offrirà meno valore di quanto suggerisca l'annuncio.

Intel deve anche dimostrare che il proprio software resta allineato ai progetti upstream. Bill Pearson, vicepresidente di Intel per il software dei data center, ha affermato che le ottimizzazioni sottostanti vengono contribuite a framework tra cui vLLM.

Il lavoro upstream può ridurre la dipendenza da un runtime chiuso e aiutare i miglioramenti a raggiungere gli utenti al di fuori del prodotto preconfezionato di Intel. Gli acquirenti dovrebbero comunque verificare quali ottimizzazioni esistono upstream e quali restano specifiche delle immagini Intel.

Per gli sviluppatori, la release offre un esperimento pratico. Distribuite un modello supportato su un host Xeon disponibile, misuratelo rispetto a una traccia di applicazione reale e confrontatelo con un acceleratore di dimensioni adeguate.

Per gli acquirenti aziendali, crea leva negoziale. Una richiesta di GPU ha ora una base di riferimento più chiara da superare quando esiste già una recente capacità CPU.

Anche le applicazioni ad alta intensità di conoscenza richiedono più di un endpoint di inferenza. I team devono collegare i modelli a documenti governati, sistemi di recupero delle informazioni e a una base di conoscenza ricercabile prima che gli output diventino utili nel lavoro.

Intel Inference Microservices avrà successo se renderà questa distribuzione più ampia meno costosa e più semplice, senza nascondere compromessi prestazionali inaccettabili. Il passo successivo sono le prove: più modelli validati, test trasparenti dei carichi di lavoro e un percorso funzionante di migrazione da CPU a GPU. Quali dei vostri attuali carichi di lavoro AI necessitano davvero di un acceleratore e quali dovrebbero essere testati sulla capacità Xeon già presente nel rack?