核心概念
2026 年 Microsoft Build 大會宣布推出 Foundry Managed Compute 搭配 Hugging Face Models on Foundry——前者是微軟管理的 GPU 平台即服務，後者是來自 Hugging Face 生態的精選開源模型目錄，每週更新、一鍵部署。
為什麼需要這層「操作層」
Hugging Face 擁有 1,500 萬開發者、300 萬個開源模型，但它本身不是企業服務平台。Foundry 填補了這個空缺：企業獲得開源生態的廣度，而微軟負責安全、合規與可觀測性。關鍵設計有三：
- 私有網路可部署 — 模型權重預先暫存在 Azure 儲存、推論容器映像放在微軟管理的 Registry，生產環境不需要連到 Hugging Face Hub，完全可在私有網路內運作
- 自動 CVE 補丁 — 微軟管理容器更新、執行時升級與安全補丁，開發者只關注應用邏輯
- 統一開發體驗 — 單一端點、相同 SDK（Python/C#/JavaScript/Java）、相同身份驗證、相同可觀測性、單一帳單
五步策劃管道
每個上架模型必須通過：識別趨勢模型（社群信號 + 合作夥伴需求）→ 合規與授權掃描（含 trust_remote_code 檢查）→ 建構推論容器並掃描 CVE → 上傳模型權重至 Azure 儲存（按地區暫存）→ API 一致性與效能驗證後發布。所有模型僅接受 SafeTensors 格式，沒有不受信任的程式碼執行路徑。
關鍵要點
- 支援推論執行時：vLLM（預設高吞吐）、SGLang（結構化輸出強）、TEI（嵌入/重排序）、TensorRT-LLM + NIM（NVIDIA 優化）、llama.cpp（CPU/量化/省成本）、hf-serve（視覺/音頻/分割）
- 加速器：NVIDIA A100、H100，AMD MI300X
- 部署模板機制：模板封裝執行時 + 加速器 + 上下文長度 + 調優參數；以 qwen3-32b 為例，有 40K/A100、40K/H100、128K/2×A100、128K/2×H100 四種組合，選模板即決定成本與效能取捨
- 覆蓋模態：LLM/VLM 聊天、ASR 語音辨識、嵌入、分割、圖像生成
- 部署範圍：全球部署（最優容量與價格）或 Data Zone（數據主權合規）
- 路線圖：帶自己的權重（BYOW）支援微調和專有模型，通過相同模板與治理部署
實務應用
評分端點與 OpenAI SDK 相容：openai.OpenAI(base_url=foundry_endpoint) 即可呼叫，遷移成本極低。推論容器也可在 Foundry Agent Service 中作為連線模型，透過 Responses API 保持身份驗證與可觀測性一致性。
成本邏輯：按小時支付加速器費用、閒置縮放到零，比 token 計費的閉源 API 更適合嵌入、批次推論等高吞吐工作負載。對比 HF Jobs × vLLM：零基礎設施的按需 LLM 推論端點 的「開發者自管 vLLM」路徑，Foundry 的代價是鎖定在 Azure 生態，換取的是零基礎設施維護負擔。Dell Enterprise Hub 提供了類似的私有部署概念，但偏向地端（on-premise）而非雲端。
參見：Hugging Face 推論供應商生態系：DeepInfra 整合實錄
延伸觀點
根據 Hugging Face 發布的《State of Open Source AI: Spring 2026》，已有 Fortune 500 的 30% 在 Hugging Face 建立驗證帳戶，企業採用開源模型的趨勢明確——主要驅動因素是成本（自托管 vLLM 相比閉源 API 可省 60-80%）和數據主權需求。
這個趨勢直接解釋了 Foundry Managed Compute 的市場定位：企業想要開源模型的彈性與成本，但不願意自己維護 GPU 基礎設施和 CVE 補丁。「誰負責操作層」已成為雲端廠商競爭的新戰場——微軟透過 Foundry，AWS 透過 Bedrock，都在搶佔同一個位置：讓開源模型的部署門檻降到與托管 API 相當，同時保留企業對模型版本和推論硬體的控制權。
值得注意的是，Dell Enterprise Hub 採取的是地端路徑（資料不出企業環境），與 Foundry 的雲端路徑形成互補，共同構成企業開源 AI 部署的兩種主要模式。
反向連結
以下頁面引用了本頁：