Computer
Intel ha annunciato Intel Inference Microservices: ogni microservizio è un container che serve un singolo modello linguistico dietro un’API compatibile OpenAI. Come spiega la pagina ufficiale di Intel, all’avvio il container rileva il processore e applica le impostazioni che Intel ha messo a punto e validato per quel modello su quel silicio. La prima release gira sui Xeon di 4ª, 5ª e 6ª generazione.
Come funziona: un container per modello che si autoconfigura
Secondo Intel, precisione numerica, distribuzione dei core e layout della memoria dipendono sia dal modello sia dal processore, e cambiano passando a un’altra generazione di silicio. Tu indichi il modello, il container sceglie i parametri. Un microservizio serve un modello su un host; per gestire una flotta condivisa tra più team, con sicurezza e instradamento già pronti, Intel rimanda al toolkit Intel AI for Enterprise Inference.
All’avvio il container controlla la generazione del processore, quanti core gli sono stati assegnati, quanti nodi NUMA ha la macchina e quali acceleratori integrati offre la CPU. Intel cita Intel AMX per la moltiplicazione di matrici e AVX-512, AVX2 e VNNI per il lavoro attorno. Se limiti le risorse del container, la configurazione si adatta al limite e non all’host.
Il motore di inferenza in questa release è vLLM; Intel prevede altri motori.
Provarlo: un comando e un’API compatibile OpenAI
L’esempio di Intel serve Qwen3-4B con un solo docker run: porta 8000, opzioni --cap-add SYS_NICE e --shm-size=2g, immagine intel/inference-xeon-qwen-qwen3-4b:0.1.0. Servono un Xeon di 4ª, 5ª o 6ª generazione, Linux e Docker Engine 20.10 o successivo. Intel raccomanda Ubuntu 22.04 LTS o successivo e suggerisce 32 GB di RAM per i modelli da 4B–8B.
Al primo avvio ci vogliono alcuni minuti per scaricare i pesi. Poi si attende che risponda /health e si invia la richiesta con curl a /v1/chat/completions.
- L’API espone chat completions, completions, models, health e metriche Prometheus, sulla porta 8000 se non ne scegli un’altra.
- OpenAI SDK, LangChain, LlamaIndex, LiteLLM e Haystack possono usare l’API, streaming compreso: imposta il base URL del container, usa come modello l’ID restituito da /v1/models e, se il client richiede una api_key, inserisci un segnaposto non vuoto come not-needed.
- Non servono un SDK Intel, un ambiente Python da costruire o un motore da installare.
Immagini per modello e immagine base: cosa succede se l’host non è riconosciuto
Le immagini dedicate a un modello hanno il fallback sul profilo generale disattivato. Su un host non riconosciuto il container dà errore all’avvio, invece di partire senza ottimizzazioni: gireranno solo configurazioni misurate da Intel per quel modello.
L’immagine base, che si può puntare a qualsiasi modello su Hugging Face, fa l’opposto: ha il fallback attivo. Attenzione: se il modello indicato con INFERENCE_MODEL_ID dichiara codice Python proprio, il container ne abilita l’esecuzione durante il caricamento. Per vietarlo si imposta INFERENCE_TRUST_REMOTE_CODE=false; i modelli che richiedono quel codice non potranno caricarsi. Se nessun profilo specifico corrisponde, usa un profilo generale, ottimizzato per l’hardware e non per il modello.
Per vedere cosa viene rilevato senza servire nulla ci sono due comandi: detect-hardware sull’immagine base e dry-run --format json su quella del modello, che stampa il profilo scelto e il comando vLLM che eseguirebbe.
Dove si colloca rispetto a runtime e app per LLM locali
Intel punta a server Xeon con container e profili validati; altri strumenti hanno un taglio diverso, come emerge dalle loro pagine ufficiali.
| Strumento | Dove gira | Come si avvia |
|---|---|---|
| Intel Inference Microservices | Xeon 4ª, 5ª e 6ª gen, Docker o Kubernetes | docker run dell’immagine del modello |
| Llama Windows | PC Windows 11 | app nell’area di notifica; server locale su localhost:9931 con API compatibile OpenAI, come descrive Hugging Face |
| Ollama | Linux (anche ARM64 e GPU AMD con pacchetto ROCm) | script di installazione, poi ollama serve, secondo la documentazione |
| LM Studio | app LM Studio con CLI lms |
lms server start per l’API locale, dal README di lms |
Limiti della prima release e cosa è previsto
- Solo vLLM, in BF16, su Docker o Kubernetes 1.24 e successivi.
- Tool calling e output strutturato passano da vLLM ma, precisa Intel, non sono funzioni validate.
- Helm chart, Kubernetes Operator, altri motori e altre precisioni sono previsti per release successive, senza date.
- Il supporto alle GPU Intel è pianificato: Intel cita la GPU per data center Crescent Island, con la stessa interfaccia per CPU e GPU. Di quella scheda avevamo parlato il 12 ottobre.
L’annuncio non riporta benchmark o numeri di prestazioni.
Software da eseguire in casa, licenze e contributi upstream
Intel precisa che si tratta di software da far girare sulla propria infrastruttura, senza endpoint ospitato né chiave API da creare. L’endpoint non offre TLS né autenticazione: chiunque raggiunga la porta 8000 può inviare richieste e leggere le metriche, quindi la porta va tenuta su una rete interna e, per accessi esterni, va messo davanti un gateway con TLS e autenticazione. Ogni modello ha la sua licenza, indicata nell’Intel Software Catalog, e chi lo distribuisce deve rispettarla. Immagini, requisiti per i singoli modelli, guida rapida e guida Kubernetes si trovano tra catalogo e documentazione.
Intel dichiara che le ottimizzazioni sono le stesse che contribuisce in upstream ai framework aperti, vLLM compreso, e che i microservizi le impacchettano dietro un’API standard.
