Intel Inference Microservices 讓現有 Xeon 伺服器挑戰 GPU 優先的 AI 策略
Intel 於 10 月 14 日推出 Intel Inference Microservices，將三代 Xeon 處理器變成可預先配置、用於大型語言模型的伺服器。首個版本支援第 4、5 及 6 代 Xeon CPU。這項產品挑戰了每個生產級 AI 專案都必須由添置新 GPU 容量開始的假設。
這套軟件將模型、vLLM 服務引擎及針對硬件的設定封裝於容器內。啟動時，它會偵測可用處理器，並選擇 Intel 已為該模型與矽晶片組合測試的配置。應用程式透過兼容 OpenAI 的 API 連接，沿用常見 AI 開發工具熟悉的請求格式。
這種封裝正是關鍵所在。Intel 並非聲稱通用 CPU 突然能超越每一款專用加速器，而是為企業提供一種方式，讓它們可在可能已擁有的伺服器上部署指定模型。這讓 Intel 龐大的已安裝 Xeon 基礎，直接對壘 Nvidia 及其他加速器供應商推動的 GPU 優先採購路徑。
Intel Inference Microservices 將 CPU 調校變成容器
Intel 將原本專門的最佳化工作，轉化為一般平台團隊也能運行的部署成品。
推出公告將每項微服務描述為一個容器，在一台主機上服務一個模型。經驗證的映像檔包含針對特定模型與 Xeon 硬件組合所選定的設定。
Intel 最初的示範以一條 Docker 指令服務 Qwen3-4B，這是一個擁有 40 億參數的語言模型。建議的硬件基準為支援的 Xeon 處理器及 32 GB 記憶體。較大型的模型需要更多容量。
容器會檢查處理器世代、已分配核心、記憶體佈局、可用指令集及非統一記憶體存取拓撲。NUMA 描述一類系統：記憶體存取時間取決於哪個處理器插槽擁有某個記憶體區域。即使伺服器的總記憶體足夠，不當的配置仍可能降低推論效能。
運行環境之後會選擇相符設定檔並啟動 vLLM。這個開源引擎管理模型執行、請求批次處理、token 生成，以及應用程式使用的 API 端點。
Intel 表示，設定檔控制精度、工作在核心之間的分配方式，以及記憶體配置。這些選擇決定處理器的數學運算單元能否持續工作，還是要等待資料。
新一代 Xeon 晶片包括 Advanced Matrix Extensions，即 AMX，可加速神經網絡中廣泛使用的矩陣運算。它們亦包括 AVX-512、AVX2 及 VNNI 等向量指令集。軟件必須識別並使用這些能力，才會影響應用程式效能。
經驗證的模型映像檔採取保守做法。如果模型專用映像檔找不到受支援的設定檔，它會產生啟動錯誤，而非悄悄運行未經測試的配置。這種行為為營運人員提供清晰的失敗訊號。
Intel 亦為其經驗證目錄以外的模型提供基礎映像檔。基礎映像檔可接受 Hugging Face 模型識別碼，並使用兼容的通用硬件設定檔。不過，這條路徑不具備同等的模型專用驗證。
這個分別很重要。「能夠運行」與「Intel 已針對此確切組合進行調校」是不同的說法。評估此軟件的團隊，應在比較結果前記錄所採用的路徑。
初始版本採用 BF16，這是一種 16 位元數值格式，相比傳統的 32 位元運算可減少記憶體用量。其他數值格式及推論引擎仍屬計劃，尚未推出。
應用程式可呼叫標準的聊天完成、文字完成、模型、健康狀態及指標端點。Intel 表示，OpenAI SDK、LangChain、LlamaIndex、LiteLLM 及 Haystack 只要更改其基礎 URL 便可連接。
這種兼容性可減少應用程式改動，但不會消除營運工作。團隊仍須管理模型存取、容器映像檔、儲存、驗證、網絡、監察及容量。
首次下載亦可能因模型權重到達而耗時數分鐘。Intel 建議固定映像檔版本，而非使用不變的「latest」標籤。固定版本有助團隊重現部署及控制升級。
最終產品比託管式 AI 平台更為聚焦，但亦比另一組最佳化函式庫更具體。Intel 已將其建議封裝成基礎設施團隊可拉取、檢查、測試及排程的內容。
為何現有 Xeon 容量改變採購問題
眼前的機會不是取代每個 GPU 叢集，而是找出不再值得為其購置 GPU 的工作負載。
企業通常為資料庫、虛擬化、業務應用程式及內部服務運作龐大的 x86 伺服器群。其中不少配備近期的 Xeon 處理器，其加速功能在傳統工作負載下未被使用。
Intel Inference Microservices 令這些容量與 AI 規劃相關。團隊可先在現有主機上測試受支援模型，再申請專用硬件。這將首個採購問題由「我們應買哪款加速器？」改為「此工作負載是否需要加速器？」
這個分別有實際影響。硬件採購涉及審批、交付、機架容量、電力規劃及整合。當模型與工作負載相符時，可用 CPU 容量可縮短實驗階段。
小型內部助理是一個例子。它可概述政策、分類支援請求、從文件抽取欄位，或回答有限知識庫中的問題。這類應用程式未必自動需要最高的 token 吞吐量。
延遲仍然重要，但需求模式各異。一個由某部門在辦公時間使用的工具，與一項同時處理數千段對話的公共服務，面對的是不同容量問題。
CPU 推論亦可適合那些現有記憶體容量比峰值生成速度更重要的應用程式。系統記憶體通常比加速器記憶體更充裕，儘管兩者的頻寬及延遲特性有顯著差異。
資料位置帶來另一項考慮。Intel 的容器在客戶環境內運行，因此提示內容及擷取文件毋須離開該部署環境，交由託管推論服務處理。這並不代表安裝預設便安全，但可讓營運人員直接控制邊界。
兼容 OpenAI 的介面有助維持應用程式可攜性。開發人員可保留大致相同的請求結構，同時在託管服務與本地部署之間轉換端點。模型行為及支援功能仍可能有所不同。
Intel 將此介面定位為貫穿其硬件產品組合的長期契約。目前版本針對 Xeon CPU，而 Intel GPU 支援仍在計劃中。Intel 表示，相同的應用程式介面最終將涵蓋處理器及專用加速器。
這個方向符合 Intel 更廣泛的異構策略。其 10 月基礎設施更新將 Xeon 定位為專用加速器旁的編排及通用運算層。同一更新亦披露更多有關 GPU D-series 的詳情，該系列原稱 Crescent Island。
GPU D-series專為持續且記憶體密集的推論而設。Intel 表示，合作夥伴設計可提供最多 480 GB LPDDR5X 記憶體，而其品牌卡則配備 160 GB。
這份硬件路線圖揭示了簡單 CPU 對 GPU 論述的局限。Intel 本身亦預期，當模型規模、併發量或經濟效益有所要求時，專用加速器會處理這些工作負載。Xeon 微服務提供的是起點，而非通用終點。
對企業買家而言，最有用的框架是工作負載配置。需求間歇的中型模型可能適合現有 CPU 伺服器；在嚴格延遲目標下服務大量用戶的大型模型，則很可能更適合專用加速。
Intel 的軟件令這個配置決定更易測試，但不會預先決定答案。
真正的競爭是重用 Xeon 還是 GPU 優先部署
Intel 所競爭的是生產級推論必須由加速器開始的假設，而不僅僅是某一款競爭對手晶片。
Nvidia 已圍繞其 GPU 建立相似的封裝模式。Nvidia Inference Microservices，通常稱為 NIM，將模型、經最佳化的設定檔、服務引擎及標準 API 捆綁為可部署容器。
目前的 NIM architecture亦會為受支援的大型語言模型工作負載使用 vLLM。它在該引擎周邊加入設定檔選擇、健康管理、可觀測性、路由及其他生產功能。
這令 Intel 的舉措更易理解。產品並非首創推論微服務概念，而是將這個模式套用於 Intel 處理器，首先針對已在企業環境常見的 Xeon 伺服器。
兩種做法都認識到同一問題。推論引擎提供大量設定，而最佳配置取決於模型、硬件、精度、記憶體及預期流量。大多數應用程式團隊都不希望為每次部署維持一間基準測試實驗室。
差異在於硬件起點。Nvidia 的方案將工作負載導向受支援 GPU。Intel 則由 Xeon CPU 開始，並承諾未來可透過同一介面連接 Intel GPU。
這為 Intel 帶來明確的銷售論點。機構可由現有處理器開始，只將超出其能力的工作負載轉移出去。價值取決於 Intel 能否讓這個過渡在營運上保持簡單。
兩種方案亦共享一項重要標準。兩者均提供兼容 OpenAI 的端點，並在相關配置中使用 vLLM。標準化介面削弱部分應用程式層面的轉換成本。
但它們不會消除基礎設施鎖定。容器映像檔、驅動程式、最佳化設定檔、受支援模型、數值格式、監察系統及支援安排仍因供應商而異。兼容 API 只是可攜性的一個層面。
AMD 透過其 EPYC 處理器產品線及 ROCm 加速器軟件帶來額外壓力。然而，Intel 新版本眼前的對手，是既有的 GPU 優先部署習慣。Intel 必須證明，對於可識別的工作負載而言，重用 CPU 能提供可接受的服務品質。
這主要不是峰值效能競賽。即使基準測試顯示 GPU 每秒可生成更多 token，亦無法解決採購決定。買家還會考慮使用率、可用容量、部署時間、電力、支援及工程工作量。
相反，擁有 Xeon 伺服器也不代表推論免費。運行 AI 會消耗記憶體、核心、電力、儲存頻寬及營運注意力。分配給模型的容量不能同時服務另一項工作負載。
機會成本在整合式環境中尤其重要。伺服器在某個觀察時段看似閒置，實際上可能提供故障轉移容量，或承接可預期的業務高峰。
軟件授權同樣仍取決於個別模型。Intel 指出，用戶必須遵守每個已部署模型所附帶的授權條款。將模型封裝於方便使用的容器中，並不會改變其可接受使用條款。
因此，最強的使用案例涉及可量度的剩餘容量、受支援的模型，以及服務要求屬中等的工作負載。缺少這三項條件，重用 CPU 可能只會成為吸引人的口號，而非穩健的架構。
Intel Inference Microservices 為團隊提供有系統的方法，測試這項主張。買家應將該容器視為評估的起點，而非結論。
自動調校解決設定阻力，而非推論物理限制
這次發布減少了設定工作，但不會消除處理器、記憶體系統與工作負載形態之間的效能差異。
語言模型推論有兩個主要階段。預填充處理輸入提示詞，而解碼則按順序生成輸出 token。每個階段對硬件造成的壓力各不相同。
長提示詞在預填充期間需要大量運算。解碼則可能受記憶體資料搬移所限制，因為系統會重複讀取模型權重及持續增長的鍵值快取。該快取會儲存於生成後續 token 時使用的中間注意力資料。
GPU 及其他加速器提供高記憶體頻寬和廣泛的平行運算能力。CPU 則提供靈活性、廣泛可用性、大型系統記憶體選項，以及成熟的企業整合能力。若沒有特定模型及流量模式，任何一份清單都無法決定效能表現。
批次處理帶來另一項取捨。合併請求可讓硬件保持忙碌，從而改善吞吐量；但同時亦可能增加個別用戶所經歷的等候時間。
Intel 的設定檔可為這些決策編碼合理設定，但無法得知每個機構的服務水平目標、提示詞分佈或併發模式。
產品現時的範圍令這個限制更明顯。一個微服務會在一部主機上為一個模型提供服務。更大型的部署需要額外的編排層、負載平衡、副本管理、安全控制及路由。
Intel 建議需要共享運算群組的客戶使用其 AI for Enterprise Inference 工具套件。這套開源堆疊加入 LLM 閘道、驗證、授權、遙測、監控、Kubernetes 編排及多個推論引擎。
這些元件處理的是系統中不同層級的問題。微服務提供經調校的端點；企業工具套件則為多個用戶與團隊協調端點。
生產環境買家應仔細檢視這個分隔。一個能回答測試提示詞的容器，尚未等同可靠的內部服務。可靠性需要健康檢查、容量政策、升級程序、故障處理、可觀測性及存取控制。
功能相容性亦值得測試。首個 Intel 發布版本透過 vLLM 直通行為提供工具呼叫及結構化輸出。Intel 並未如其硬件設定檔般，將這些能力描述為已驗證功能。
工具呼叫讓模型可要求使用外部函數，而結構化輸出則將回應限制於定義好的格式。兩者對代理式企業應用都很重要。在基本測試中可運作的功能，仍可能在複雜 schema 或特定模型提示詞下失效。
初期聚焦 BF16 亦形成另一個界限。INT8 或 INT4 等較低精度格式可減少記憶體消耗並提高吞吐量，但可能需要另行驗證。Intel 將其他精度列為未來工作。
模型覆蓋範圍同樣重要。Intel 為目錄條目提供模型專用映像，並為其他 Hugging Face 模型提供通用基礎映像。通用路徑偏重覆蓋廣度，已驗證路徑則偏重可預測的設定。
團隊不應將兩條路徑視作具備相同保證。通用設定檔可能可成功執行不受支援的模型，卻未必提供模型專用調校所預期的結果。
部署文件亦列出實際要求。部分受限制模型需要 Hugging Face token 及事先接受授權。模型檔案需要本機儲存空間，而較大型模型所需的容量亦高於建議的 32 GB 基準。
安全團隊應檢視 token 如何進入容器，以及 shell 歷史記錄、環境變數或叢集 manifest 是否會暴露它們。他們亦應掃描映像、限制網絡存取，並為推論端點提供驗證。
這些考慮因素並不會否定 Intel 的方法。它們界定了簡化調校與簡化營運之間的差距。首個發布版本對前者的處理，比後者更為完整。
Intel 尚未發布買家所需的比較數據
核心不確定性是實際工作負載下的經濟效能，而非該容器能否啟動模型。
Intel 表示，其已驗證設定檔封裝了針對受支援模型與處理器組合所量度出的最佳設定。這項說法描述了 Intel 的調校流程，但並未提供與未經調校的 Xeon 部署、競爭 CPU 或現有加速器相比的獨立比較。
公告並未展示這些微服務完整的延遲、吞吐量、能源或總成本結果。因此，買家不能僅從這次發布推斷出普遍優勢。
有用的評估不應只看平均每秒 token 數。團隊應記錄首個 token 時間、token 間延遲、總請求延遲、不同併發水平下的吞吐量、記憶體消耗及錯誤率。
首個 token 時間衡量用戶多快看到初始回應；token 間延遲則衡量後續生成的速度。某個應用可錄得強勁的整體吞吐量，卻仍讓個別用戶感到緩慢。
測試應使用具代表性的提示詞及輸出長度。短分類請求的表現，與接收長篇文件並生成詳盡回答的研究助理截然不同。
併發程度亦必須貼近生產環境。處理器服務單一請求時的行為，可能與佇列累積時大不相同。批次政策可改善總輸出，卻可能降低尾端延遲，也就是最慢一部分請求所代表的延遲。
能源量度同樣需要審慎處理。已安裝於機架中的 CPU 伺服器，在持續推論下仍會消耗額外電力。團隊應比較每單位能源所完成的工作，而非只比較某個元件的額定功耗。
總成本亦應包括工程時間。Intel 最強的主張，在於其設定檔可取代的手動調校工作。公平的試驗應量度封裝方案與自主管理方案各自需要多久，才能完成部署、穩定運作及更新。
比較亦應包括合適的 GPU 部署，而非選擇過大的叢集來令 CPU 顯得更具經濟效益。硬件應配合工作負載及預期增長。
測試期間品質必須保持一致。更改精度、量化方式、模型版本或上下文長度，都可能改變輸出行為。若較快的結果改變了模型的準確度或可用功能集，便不可作直接比較。
獨立基準測試將十分重要，因為 Intel 同時控制設定檔及初始效能敘述。來自客戶、雲端服務供應商及中立基準測試機構的可重現測試，將為買家帶來更有力的證據。
Intel 較早前的 MLPerf 結果顯示，該公司參與了涵蓋 CPU 與 GPU 的標準化推論測試。不過，這些提交結果不應被視為對這次新容器發布的直接驗證。
這些微服務需要自身的測試結果，因為封裝方式可改變效能、受支援功能及營運行為。版本 0.1.0 亦反映產品仍處於早期階段，儘管版本號不保證特定的成熟度水平。
模型專用映像在無法找到已驗證設定檔時會刻意失敗。這項設計有助可預測性，但亦限制了早期用戶可使用的硬件與模型組合。
基礎映像透過後備設定檔擴展覆蓋範圍。然而，後備設定檔能成功運作，不應被誤認為已獲最佳化效能。團隊應以確切映像、模型、主機、設定檔及執行時間版本為基準測試記錄加上標籤。
這種紀律將協助企業判斷 Intel Inference Microservices 是否真正減輕其 AI 基礎設施負擔，亦會揭示仍應交由加速器處理的工作負載。
三個訊號將顯示 Intel 的 Xeon AI 策略是否奏效
模型覆蓋範圍、獨立的生產環境結果，以及跨硬件可攜性，將決定這項產品會成為平台，還是仍只是一條有用的部署捷徑。
第一個訊號是已驗證模型目錄的擴展。買家應留意 Intel 加入廣泛部署模型、較新架構、額外精度及修訂設定檔的速度。
目錄增長之所以重要，是因為模型專用驗證是這項產品相對通用容器最明確的優勢。更新緩慢會迫使團隊轉用基礎映像，而 Intel 在該路徑上提供的工作負載專屬保證較少。
若新模型在發布後不久便獲得已驗證映像，這個訊號會加強 Intel 的論點。若用戶必須依賴通用後備方案才能使用真正想要的模型，則會削弱該論點。
第二個訊號是可重現的客戶效能數據。有用的報告會說明處理器型號、插槽數量、記憶體設定、容器版本、提示詞長度、併發程度及服務目標。
籠統宣稱「推論更快」幾乎沒有指引作用。買家需要工作負載層面的證據，顯示何時重用 Xeon 比採購、租用或重新分配加速器容量更具優勢。
生產環境證據亦應包括營運成果。部署時間、故障復原、更新頻率及人手投入，都是 Intel 承諾簡化推論的核心。
第三個訊號是 Intel 計劃延伸至 GPU。Intel 表示，相同的微服務合約最終將支援其資料中心推論硬件，包括 GPU D-series。
這項轉變將考驗該公司的可攜性論點。若應用可在只作極少改動下由 Xeon 轉移至 Intel GPU，Intel 將提供可信的擴展路徑。
若轉移需要不同映像、營運工具、功能妥協或大量重新調校，通用 API 所提供的價值將低於公告所暗示。
Intel 亦必須證明其軟件持續與上游專案保持一致。Intel 資料中心軟件副總裁 Bill Pearson 表示，底層最佳化已貢獻至包括 vLLM 在內的框架。
上游工作可減少對封閉執行時間的依賴，並有助改進惠及 Intel 封裝產品以外的用戶。買家仍應核實哪些最佳化已存在於上游，哪些仍屬 Intel 映像專用。
對開發者而言，這次發布提供了一項實際實驗。在可用的 Xeon 主機上部署受支援模型，根據真實應用追蹤量度表現，並與配置合適的加速器作比較。
對企業買家而言，這帶來更多談判籌碼。當現有 CPU 容量已存在時，GPU 請求如今有了更清晰的基準需要超越。
知識密集型應用程式亦不僅需要一個推論端點。團隊必須將模型連接至受管治的文件、檢索系統，以及一個可搜尋的知識庫，輸出結果才能在工作中真正發揮作用。
Intel Inference Microservices 能否成功，取決於它們是否能在不掩飾不可接受的效能取捨下，讓更廣泛的部署更便宜、更容易。下一步需要的是證據：更多已驗證的模型、透明的工作負載測試，以及可行的 CPU 至 GPU 遷移路徑。你現有的哪些 AI 工作負載真正需要加速器？又有哪些應先在機架內既有的 Xeon 運算容量上進行測試？
