Intel ने 14 अक्टूबर को Inference Microservices की घोषणा की: model-specific containers, जिनमें हर container समर्थित Xeon processors पर एक बड़ा language model serve करता है। Startup पर container host का पता लगाता है, उस model और processor के लिए Intel profile चुनता है और OpenAI-compatible HTTP API के पीछे vLLM शुरू करता है। Xeon क्षमता वाले developer का तत्काल काम यह तय करना है कि दस्तावेज़ित image आंतरिक network पर application request serve कर सकती है या नहीं, फिर उसी host पर workload मापना है।

पहले जारी images पर tag 0.1.0 है। वे BF16 precision के साथ चौथी, पाँचवीं और छठी पीढ़ी के Xeon के लिए हैं; Linux पर Docker Engine 20.10 या बाद का, अथवा Kubernetes 1.24 या बाद का चाहिए। दस्तावेज़ स्थानीय serving package बताता है, Intel-hosted endpoint नहीं: Intel API key लेने की आवश्यकता नहीं है। Intel का दावा कि profiles tuning का काम घटाते या performance सुधारते हैं, vendor का दावा है; BIG CHANGE ने images चलाई या benchmark नहीं कीं।

बड़ा बदलाव

  • क्या बदला: Intel ने model-specific vLLM configurations को containers में पैक किया है। वे समर्थित Xeon host की जाँच करते हैं और standard API देने से पहले built-in serving profile चुनते हैं।
  • यह क्यों मायने रखता है:Application परिचित chat endpoint को call कर सकती है, पर container application routing, authentication, TLS, model-license अनुपालन या इस बात का प्रमाण नहीं देता कि कोई खास workload latency और capacity लक्ष्य पूरा करता है।
  • क्या देखें:जाँचें कि ज़रूरी model के लिए catalog image और matching profile उपलब्ध हैं, फिर लक्षित host पर readiness, response व्यवहार और load जाँचें। Intel GPU support, दूसरे engines और precisions, Helm chart और operator को भविष्य का काम बताता है, पहले release की सुविधाएँ नहीं।

Container क्या संभालता है और team की जिम्मेदारी क्या रहती है

Intel के अनुसार startup detection Xeon generation, उपलब्ध cores, NUMA layout और समर्थित processor क्षमताएँ देखता है। Model-specific image ऐसा profile ढूँढ़ती है जो vLLM के लिए precision, काम का वितरण और memory layout तय करता है। मेल खाता model-specific profile न मिले तो वह सामान्य profile पर चुपचाप बदलने के बजाय startup पर विफल होती है। अन्य Hugging Face models के लिए Intel base image का general-profile fallback अलग है। यह अंतर तब महत्वपूर्ण है जब team तय करे कि सफल startup उसी model-specific configuration को दिखाता है जिसका मूल्यांकन करना था।

दस्तावेज़ित API ये उपलब्ध कराता है: GET /health, GET /v1/models, POST /v1/chat/completions, POST /v1/completions और GET /metrics default रूप से port 8000 पर। /health Model तैयार होने पर खाली HTTP 200 और तैयार न होने पर 503 लौटाता है; response body खोजने से status code देखना अधिक उपयोगी है। /v1/models एकमात्र served model ID लौटाता है। Application को chat request में वह ID देना होगा और कई models serve करने पर request कहाँ route हो, यह चुनना होगा। Intel streaming और OpenAI-compatible client libraries दस्तावेज़ित करता है, लेकिन request shape का मेल team के खास model और prompt की गुणवत्ता या गति साबित नहीं करता।

यहाँ trust boundary भी स्पष्ट है। सुरक्षा मार्गदर्शिका कहती है कि endpoint स्वयं TLS या caller authentication नहीं देता। Protective gateway या network boundary के बिना port 8000 को public network पर न खोलें। Kubernetes में Intel access सीमित करने के लिए NetworkPolicy और TLS तथा authentication के लिए gateway या ingress की सलाह देता है। Service ग्राहक के infrastructure पर चलती है, इसलिए host क्षमता, cache स्थान, monitoring और gated model weights तक पहुँच भी team की जिम्मेदारी है।

पहले दस्तावेज़ित local जाँच, फिर workload परीक्षण

Public Qwen3-4B उदाहरण के लिए Intel का quickstart यह Linux/Docker command देता है। यहाँ यह केवल दस्तावेज़ी प्रक्रिया है; BIG CHANGE ने इसे चलाया नहीं:

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

Intel कहता है कि पहली शुरुआत model weights डाउनलोड करती है और कई मिनट लग सकते हैं। दूसरे terminal पर, curl -i http://localhost:8000/health engine तैयार होने पर खाली body वाला HTTP 200 दिखाना चाहिए। फिर GET /v1/models को Qwen/Qwen3-4B बताना चाहिए, और उस ID तथा POST /v1/chat/completions array का उपयोग करने वाला messages request chat-completion response लौटाना चाहिए। ये जाँचें केवल यह दिखाती हैं कि दस्तावेज़ित endpoint शुरू हुआ और उत्तर दिया। Deployment निर्णय के लिए team को अपने prompts, concurrency, latency और resource मापने तथा failures और restarts पर व्यवहार जाँचने की ज़रूरत है।

इन आवश्यकताओं में 4B–8B models के लिए 32 GB RAM और cache disk पर 50 GB खाली जगह सुझाई गई है; बड़े models को अधिक memory चाहिए। Ubuntu 22.04 LTS या बाद का सुझाया गया है, हालाँकि software requirement ऐसा Linux है जो Docker Engine 20.10 या बाद का चला सके। Intel के उदाहरण में Qwen3-4B को Hugging Face token नहीं चाहिए और उसका model card Apache 2.0 बताता है। दूसरे models gated हो सकते हैं: उनके license, access approval और read token अलग से जाँचें। Intel के public दस्तावेज़ microservices software की कीमत नहीं बताते और इस deployment की hardware या संचालन लागत भी तय नहीं करते।

Intel की समर्थित सुविधाओं की सूची built-in, validated तरीके को vLLM pass-throughs से अलग करती है। Tool calling, structured output, LoRA और बदली हुई context length के लिए अतिरिक्त INFERENCE_ENGINE_ARGS flags चाहिए। ये tuned configuration बदल या अमान्य कर सकते हैं; Intel resolved command को dry-run से जाँचने और परिणाम पर load test करने को कहता है। इन्हें अलग integration project मानें, default image से सिद्ध क्षमता नहीं। Kubernetes deployments replicas और readiness probes जोड़ सकते हैं, पर models के बीच routing application या gateway ही करता है। Intel की पिछली D-series coverage अलग GPU hardware घोषणा से संबंधित है, इस Xeon serving release से नहीं।

स्रोत और आगे पढ़ें

  • Intel घोषणा, 14 अक्टूबर 2026। Model-specific container, host detection, profiles, शुरुआती Xeon दायरे और नियोजित विस्तार का वर्णन। Tuning और performance के दावे Intel के हैं; BIG CHANGE ने स्वतंत्र रूप से परीक्षण नहीं किया।
  • Intel Inference Microservices दस्तावेज़, जिस पर 24 सितंबर 2026 को अपडेट होने का निशान है। उसका 0.1.0quickstart Qwen3-4B command और शुरुआती health/chat तरीका देता है; ऊपर की प्रक्रिया केवल दस्तावेज़ों पर आधारित है।
  • आवश्यकताएँ, API संदर्भ, समर्थित सुविधाएँ और सुरक्षा मार्गदर्शन, Intel दस्तावेज़ जिन पर 24 सितंबर 2026 को अपडेट होने का निशान है। वे समर्थित hosts, readiness responses, built-in सुविधाओं और vLLM pass-throughs का अंतर तथा authentication-विहीन HTTP सीमा बताते हैं।
  • Qwen/Qwen3-4B model card, 15 अक्टूबर 2026 को देखा गया। उदाहरण model के लिए Apache 2.0 license बताता है; दूसरे models की शर्तें और access gates अलग हो सकते हैं।