Intel kündigte am 14. Oktober Inference Microservices an: modellspezifische Container, die jeweils ein großes Sprachmodell auf unterstützten Xeon-Prozessoren bereitstellen. Beim Start erkennt ein Container den Host, wählt Intels Profil für das jeweilige Modell und den Prozessor und startet vLLM hinter einer OpenAI-kompatiblen HTTP-API. Wer Xeon-Kapazität hat, muss zunächst entscheiden, ob ein dokumentiertes Image Anwendungsanfragen in einem internen Netzwerk bedienen kann, und anschließend die Workload auf diesem Host messen.

Die ersten veröffentlichten Images tragen das Tag 0.1.0. Sie sind für Xeon-Prozessoren der vierten, fünften und sechsten Generation mit BF16-Präzision ausgelegt und erfordern Linux mit Docker Engine 20.10 oder neuer oder Kubernetes 1.24 oder neuer. Die Dokumentation beschreibt ein lokales Serving-Paket, keinen von Intel gehosteten Endpunkt: Ein Intel-API-Schlüssel ist nicht erforderlich. Intels Aussagen, die Profile sparten Tuning-Aufwand oder verbesserten die Leistung, sind Anbieterangaben; BIG CHANGE hat die Images weder ausgeführt noch benchmarkgetestet.

Die große Veränderung

  • Was sich geändert hat: Intel hat modellspezifische vLLM-Konfigurationen in Container verpackt. Diese prüfen einen unterstützten Xeon-Host und wählen ein integriertes Serving-Profil, bevor sie eine standardisierte API bereitstellen.
  • Warum es wichtig ist:Eine Anwendung kann einen vertrauten Chat-Endpunkt aufrufen, doch der Container übernimmt weder Anwendungsrouting, Authentifizierung und TLS noch die Einhaltung der Modelllizenz oder den Nachweis, dass eine bestimmte Workload ihre Latenz- und Kapazitätsziele erreicht.
  • Worauf zu achten ist:Prüfen Sie, ob es für das benötigte Modell ein Katalog-Image und ein passendes Profil gibt, und testen Sie anschließend Bereitschaft, Antwortverhalten und Last auf dem vorgesehenen Host. Intel führt GPU-Unterstützung, weitere Engines und Präzisionen, ein Helm-Chart und einen Operator als künftige Arbeiten auf, nicht als Funktionen der ersten Version.

Was der Container übernimmt und wofür das Team weiterhin zuständig ist

Laut Intel berücksichtigt die Erkennung beim Start die Xeon-Generation, verfügbare Kerne, das NUMA-Layout und unterstützte Prozessorfunktionen. Das modellspezifische Image ermittelt ein Profil, das Präzision, Arbeitsverteilung und Speicherlayout für vLLM festlegt. Findet es kein passendes modellspezifisches Profil, schlägt der Start fehl, statt stillschweigend auf ein allgemeines Profil zu wechseln. Intels Basis-Image für andere Hugging-Face-Modelle besitzt einen anderen, allgemeinen Profil-Fallback. Dieser Unterschied ist wichtig, wenn ein erfolgreicher Start die Konfiguration darstellt, die das Team tatsächlich bewerten wollte.

Die dokumentierte API stellt GET /health, GET /v1/models, POST /v1/chat/completions, POST /v1/completions und GET /metrics standardmäßig auf Port 8000 bereit. /health liefert bei betriebsbereitem Modell ein leeres HTTP-200-Ergebnis und andernfalls 503; der Statuscode ist aussagekräftiger als ein erwarteter Antworttext. /v1/models gibt die einzige bereitgestellte Modell-ID zurück. Die Anwendung muss diese ID in einer Chat-Anfrage angeben und bei mehreren Modellen selbst die Weiterleitung festlegen. Intel dokumentiert Streaming und OpenAI-kompatible Client-Bibliotheken, doch ein kompatibles Anfrageformat belegt weder Qualität noch Geschwindigkeit des konkreten Modells und Prompts eines Teams.

Es gibt außerdem eine klare Vertrauensgrenze. Der Sicherheitsleitfaden hält fest, dass der Endpunkt selbst weder TLS noch eine Authentifizierung der Aufrufer bietet. Port 8000 darf ohne schützendes Gateway oder Netzwerkgrenze nicht öffentlich erreichbar sein. Für Kubernetes empfiehlt Intel, den Zugriff mit einer NetworkPolicy zu begrenzen und TLS sowie Authentifizierung über ein Gateway oder Ingress bereitzustellen. Da der Dienst auf der Infrastruktur des Kunden läuft, verantwortet das Team auch Host-Kapazität, Cache-Platzierung, Überwachung und den Zugang zu zugangsbeschränkten Modellgewichten.

Erst eine dokumentierte lokale Prüfung, dann ein Workload-Test

Für das öffentliche Qwen3-4B-Beispiel enthält Intels Quickstart diesen Linux-/Docker-Befehl. Dies ist nur ein dokumentiertes Verfahren; BIG CHANGE hat es nicht ausgeführt:

Terminal
docker run --rm -p 8000:8000 \
  --cap-add SYS_NICE \
  --shm-size=2g \
  intel/inference-xeon-qwen-qwen3-4b:0.1.0

Intel zufolge lädt der erste Start die Modellgewichte herunter und kann mehrere Minuten dauern. In einem zweiten Terminal sollte curl -i http://localhost:8000/health bei betriebsbereiter Engine HTTP 200 mit leerem Antworttext anzeigen. Danach sollte GET /v1/models die Modell-ID Qwen/Qwen3-4B nennen; eine POST /v1/chat/completions-Anfrage mit dieser ID und einem messages-Array sollte eine Chat-Completion-Antwort liefern. Diese Prüfungen belegen nur, dass der dokumentierte Endpunkt gestartet ist und antwortet. Für eine Bereitstellungsentscheidung muss das Team weiterhin eigene Prompts, Parallelität, Latenz und Ressourcen messen sowie das Verhalten bei Fehlern und Neustarts prüfen.

Die Voraussetzungen empfehlen 32 GB RAM und 50 GB freien Cache-Speicher für 4B- bis 8B-Modelle; größere Modelle benötigen mehr Arbeitsspeicher. Empfohlen wird Ubuntu 22.04 LTS oder neuer, während die Softwareanforderung lediglich Linux mit Docker Engine 20.10 oder neuer ist. Für Qwen3-4B ist im Intel-Beispiel kein Hugging-Face-Token nötig; dessen Modellkarte nennt Apache 2.0. Andere Modelle können zugangsbeschränkt sein; Lizenz, Zugangsfreigabe und Lesetoken müssen jeweils gesondert geprüft werden. Intels öffentliche Dokumentation nennt keinen Preis für die Microservices-Software und legt auch keine Hardware- oder Betriebskosten für diese Bereitstellung fest.

Intels Liste unterstützter Funktionen unterscheidet den integrierten, validierten Pfad von vLLM-Passthroughs. Tool-Aufrufe, strukturierte Ausgabe, LoRA und eine geänderte Kontextlänge erfordern zusätzliche INFERENCE_ENGINE_ARGS Flags. Sie können die abgestimmte Konfiguration ändern oder ungültig machen; Intel empfiehlt, den aufgelösten Befehl mit dry-run zu prüfen und das Ergebnis unter Last zu testen. Das ist als separates Integrationsprojekt zu behandeln, nicht als vom Standard-Image belegte Fähigkeit. Kubernetes-Bereitstellungen können Replikate und Readiness-Probes hinzufügen, doch das Routing zwischen Modellen übernimmt weiterhin die Anwendung oder ein Gateway. Intels frühere D-Series-Berichterstattung betrifft eine separate GPU-Hardwareankündigung und nicht diese Xeon-Serving-Version.

Quellen und weiterführende Informationen

  • Intel-Ankündigung, 14. Oktober 2026. Beschreibt den modellspezifischen Container, die Host-Erkennung, Profile, den anfänglichen Xeon-Umfang und geplante Erweiterungen. Aussagen zu Tuning und Leistung stammen von Intel; BIG CHANGE hat sie nicht unabhängig getestet.
  • Dokumentation zu Intel Inference Microservices, als aktualisiert am 24. September 2026 gekennzeichnet. Der 0.1.0Quickstart enthält den Qwen3-4B-Befehl und den anfänglichen Health-/Chat-Ablauf; das oben beschriebene Verfahren stammt nur aus der Dokumentation.
  • Voraussetzungen, API-Referenz, unterstützte Funktionen und Sicherheitshinweise, Intel-Dokumentation, als aktualisiert am 24. September 2026 gekennzeichnet. Sie definieren unterstützte Hosts, Bereitschaftsantworten, integrierte Funktionen gegenüber vLLM-Passthroughs sowie die nicht abgesicherte HTTP-Grenze.
  • Modellkarte zu Qwen/Qwen3-4B, abgerufen am 15. Oktober 2026. Sie nennt Apache 2.0 für das Beispielmodell; für andere Modelle können andere Bedingungen und Zugangsbeschränkungen gelten.