Microsoft Foundry Local：能力與局限

2026 年 2 月，Microsoft 推出 Foundry Local 正式版。它在本地硬體上執行 AI 模型——筆記型電腦、工作站、邊緣設備——執行時無需雲端連接。對於每年從 Azure 雲端服務產生逾 600 億美元的公司，這是一個值得注意的舉動。

這不是一個小型 SDK 版本。結合 Azure Local（本地端基礎設施）和 Microsoft 365 Local（離線生產力），Foundry Local 代表 Microsoft 為斷網和氣隙環境構建完整的主權 AI 堆疊。當最大的雲端供應商告訴客戶「你可以在沒有我們雲端的情況下運行這個」時，市場動態已經改變。

本文涵蓋 Foundry Local 實際上是什麼、其架構是什麼樣子、它能做什麼和不能做什麼，以及企業 AI 買家應該從中得出什麼。

Foundry Local 實際上是什麼

Foundry Local 是一個本地 AI 模型推理框架。它允許開發者和企業直接在本地硬體上執行小型語言模型（SLM）和其他 AI 模型——Windows PC、macOS 機器和邊緣設備——無需將資料傳送到 Azure 或任何其他雲端服務。

它是 Microsoft 所謂的 Azure AI Foundry 生態系統的一部分：

• Azure AI Foundry（雲端）：Azure 上的模型目錄、微調、託管推理端點
• Azure AI Foundry SDK：用於與雲端和本地模型互動的統一 Python/C# SDK
• Foundry Local：透過 localhost 上的 OpenAI 相容 REST API 服務模型的本地執行時間

關鍵的架構決策：

OpenAI 相容的 API 很重要。針對 OpenAI API 構建的應用程式可以透過將端點 URL 從 api.openai.com 更改為 localhost 來切換到 Foundry Local。除端點之外沒有程式碼更改。這使已在 OpenAI API 介面上構建的團隊的遷移變得簡單。

完整的 Microsoft 主權堆疊

Foundry Local 不是一個獨立的產品。它適合 Microsoft 針對斷網和主權環境的更廣泛策略：

Azure Local（前身為 Azure Stack HCI）

Azure Local 將 Azure 服務帶到本地端硬體。組織在其自己的資料中心的伺服器上安裝 Azure Local，並在沒有與 Azure 雲端持續連接的情況下執行 Azure 服務（計算、儲存、網路、容器）。對於機密環境和氣隙網路，Azure Local 提供基礎設施層。

Microsoft 365 Local

與 Azure Local 增強功能一起宣佈，Microsoft 365 Local 使 Microsoft 365 生產力應用程式（Word、Excel、Teams、SharePoint）能夠在斷網環境中運行。這意味著電子郵件、文件協作和通訊在沒有網際網路存取的情況下也能運作。

Foundry Local

AI 層。模型在工作站或邊緣設備上本地端執行，透過本地 REST API 服務推理。與用於基礎設施的 Azure Local 和用於生產力的 Microsoft 365 Local 結合，整個企業軟體堆疊可以在沒有任何雲端連接的情況下運行。

組裝後的堆疊樣子

┌─────────────────────────────────────┐
│           使用者應用程式              │
│  （自訂應用、M365、業務線）           │
├─────────────────────────────────────┤
│       Foundry Local（AI 層）         │
│  本地模型推理，REST API               │
├─────────────────────────────────────┤
│     Microsoft 365 Local              │
│  生產力，協作                         │
├─────────────────────────────────────┤
│       Azure Local（基礎設施層）       │
│  計算，儲存，網路                     │
├─────────────────────────────────────┤
│     客戶擁有的硬體                    │
│  本地端資料中心 / 邊緣                │
└─────────────────────────────────────┘

這是來自單一供應商的完整主權堆疊。任何層都不需要網際網路。對於需要斷網操作的國防、情報、關鍵基礎設施和受監管行業，這是來自主要供應商的第一個在單一架構中涵蓋基礎設施、生產力和 AI 推理的整合產品。

Foundry Local 能做什麼

本地模型推理

Foundry Local 在本地端執行小型語言模型，在所有主要 GPU 和 NPU 架構上提供硬體加速推理。在正式版時，支援的模型包括：

• Phi-4-mini（38 億參數）：Microsoft 針對推理優化的旗艦小型模型
• Phi-3.5 系列：針對不同任務優化的各種大小
• Phi-3-vision：用於圖像理解的多模態模型
• 來自 Azure AI 模型目錄的其他模型，ONNX 優化

推理效能取決於硬體。在擁有獨立 GPU（16 GB 以上 VRAM）的現代工作站上，Phi-4-mini 以約 30-50 個 token/秒的速度產生——足夠快用於互動應用程式。在純 CPU 機器上，效能顯著下降，但對批次處理仍然可用。

斷網操作

一旦模型權重被下載和安裝，Foundry Local 就不進行任何網路呼叫。沒有遙測，沒有授權檢查，沒有用戶未明確操作的模型更新。這是真正的斷網操作，而非「大多數時候離線工作」。

對於氣隙環境，模型權重可以在初始設置期間透過批准的可移動媒體傳輸。此後，系統完全從本地儲存運行。

開發者整合

OpenAI 相容的 REST API 意味著現有工具可以使用：

• 使用 openai Python 套件的 Python 應用程式透過指向 http://localhost:PORT 運作
• LangChain / LlamaIndex 框架無需自訂適配器即可連接
• n8n / Make.com 自動化工作流程可以針對本地端點
• 使用 HTTP REST 呼叫的自訂應用程式開箱即用

多模型服務

Foundry Local 可以同時服務多個模型，根據可用記憶體自動載入和卸載模型。這允許在同一台機器上為不同任務執行不同的模型——用於文件理解的視覺模型與用於文字產生的語言模型並行運行。

Foundry Local 不能做什麼

這是誠實評估很重要的地方。Foundry Local 解決了一個問題——本地推理——但留下了幾個企業需求未得到解決。

沒有微調

Foundry Local 是一個推理執行時間。它執行預訓練模型。它不訓練或微調模型。如果你需要一個針對你的領域客製化的模型（法律合約、醫療記錄、財務報告），你需要在其他地方微調，然後透過 Foundry Local 部署微調後的模型。

工作流程如下：

微調（雲端或本地端）→ 匯出為 ONNX → 透過 Foundry Local 部署（本地端）

這意味著微調仍然是一個單獨的問題。你可以使用 Azure AI Foundry（雲端）進行微調，然後匯出到 Foundry Local——但這需要在微調階段將你的訓練資料傳送到 Azure，這可能違反資料主權要求。

對於需要微調和推理都是主權的組織，Foundry Local 處理推理的一半。微調的一半需要單獨的本地端解決方案。

模型選擇有限

在正式版時，Foundry Local 支援 Microsoft 優化的模型——主要是 Phi 系列和來自 Azure AI 目錄的精選模型。你無法以其原生格式載入任意 Hugging Face 模型。模型必須轉換為 ONNX 格式並針對 Foundry Local 執行時間進行優化。

這比支援開源生態系統中數千個 GGUF 格式模型的 Ollama 或 llama.cpp 等替代方案更窄。如果你需要執行 Llama 3、Mistral、Qwen 或其他非 Microsoft 模型，Foundry Local 在啟動時可能不支援它們。

Microsoft 表示他們將隨時間擴展模型支援，但初始目錄受到限制。

ONNX 依賴

所有模型必須是 ONNX 優化的。ONNX（開放神經網路交換）是一種成熟的格式，但並非所有模型都有高品質的 ONNX 轉換。一些模型架構在 ONNX 轉換期間會失去效能或準確率。ONNX 優化期間應用的量化可能進一步降低品質。

對於許多企業用例，這是可以接受的——ONNX 格式的 Phi-4-mini 對分類、擷取和摘要任務非常有能力。但對於需要來自特定模型架構的絕對最佳準確率的用例，ONNX 轉換可能是一個限制因素。

沒有資料準備

Foundry Local 處理 AI 管道的推理階段。它不解決資料準備——將非結構化企業文件（PDF、Word 檔案、掃描圖像、試算表）轉換為乾淨的、已標記的、AI 就緒的訓練資料的過程。

對於構建特定領域 AI 的企業，管道看起來像：

原始文件 → 資料準備 → 訓練資料 → 微調 → 模型 → 推理
                                                  ↑
                                    Foundry Local 處理這一部分

資料準備是企業 ML 專案時間的 60-80% 用在哪裡。Foundry Local 只有在你有一個訓練好的模型準備部署後才相關。上游資料挑戰——這是大多數企業 AI 採用的主要瓶頸——在這個版本中仍未得到解決。

這對市場意味著什麼

Microsoft 正在使本地端 AI 合法化

當一家每年從雲端服務賺取 600 億美元以上的公司推出一個明確為斷網操作設計的產品時，這不是一個副項目。Microsoft 承認大量企業市場無法或不會使用雲端 AI——而且這個市場足夠大，值得專門的產品投資。

這以較小的供應商無法做到的方式使本地端 AI 部署合法化。以前被告知「本地端 AI 是過時的想法」的企業採購團隊，現在 Microsoft 在說相反的話。

雲端訓練、本地端推理的分離正在成為標準

Foundry Local 強化了一個在整個行業中出現的模式：訓練（微調）在雲端發生，GPU 資源在那裡是彈性的，推理在本地端發生，資料主權和延遲要求在那裡很嚴格。

這種分離在經濟上有意義。訓練是一個定期活動（每月或每季度微調一次模型）。推理是連續的（全天每天服務預測）。在訓練突發時為雲端 GPU 付費，並將擁有的硬體用於持續推理，可以優化費用。

但它也創造了一個主權差距：如果你的訓練資料必須在微調期間進入雲端，即使推理完全是主權的，資料主權在訓練階段也受到損害。有嚴格資料主權要求的組織需要微調和推理都是本地端的。

開放格式模型可攜性現在是買家期望

OpenAI 相容的 API 和 ONNX 模型格式表明模型可攜性正在成為基礎性要求。企業買家越來越期望他們能夠：

1. 在一個平台上微調模型
2. 以開放格式匯出（ONNX、GGUF、SafeTensors）
3. 在不同的執行時間部署（Foundry Local、Ollama、llama.cpp、vLLM）
4. 在不重寫應用程式的情況下切換執行時間

推理層的廠商鎖定正在變得站不住腳。Foundry Local 的 OpenAI 相容 API 使其成為 OpenAI 雲端 API 的即插即用替代——這意味著應用程式可以在雲端和本地部署之間遷移，無需更改程式碼。

這讓企業 AI 買家處於何種位置

Foundry Local 是企業 AI 工具包的真正有用補充。它很好地解決了本地推理，具有廣泛的硬體支援和最小化遷移摩擦的 OpenAI 相容 API。

但它不解決完整的企業 AI 管道：

2026 年的企業 AI 堆疊看起來像：

1. 資料準備：將非結構化文件轉換為乾淨的、已標記的訓練資料的本地端工具
2. 微調：雲端（Azure AI Foundry 等）或本地端訓練基礎設施
3. 推理：Foundry Local、Ollama 或同等的本地執行時間
4. 監控：稽核追蹤和模型效能追蹤

Foundry Local 是這個堆疊的一個組成部分。一個重要的組成部分，背後有 Microsoft 的力量。但期望 Foundry Local 單獨提供主權 AI 的企業，將發現資料準備和微調挑戰——這些挑戰消耗了大多數 AI 專案時間和預算的大部分——仍未得到解決。

移動最快的組織是那些組裝完整主權管道的組織：本地端資料準備、主權微調（根據資料敏感性在雲端或本地端）和透過 Foundry Local 或同等工具進行本地推理。

相關閱讀

• 企業主權 AI：2026 年的含義和重要性：主權 AI 的全面指南：主權的三個層次、監管驅動因素和企業買家清單。
• 如何為受監管行業構建氣隙 AI 管道：構建零網際網路連接 AI 管道的技術架構。
• 氣隙機器學習：如何在沒有網際網路存取的情況下構建 AI 資料管道：在氣隙環境中構建資料準備和訓練管道的實際指南。
• GGUF vs ONNX：Foundry Local 運行於 ONNX Runtime；該格式與 GGUF 在本地推理上的比較。