Microsoft Foundry Local 在 2026 年 4 月 9 日宣布正式可用。
這個產品的重點不是「又一個模型平台」，而是把 AI 從雲端 API 拉回使用者裝置。
對 Windows App 開發者來說，這會改變 AI 功能的設計方式。過去很多功能預設呼叫雲端模型，現在可以考慮把一部分推論放在本機，讓 App 更快、更穩、更可控。
Foundry Local 是什麼？
Foundry Local 是 Microsoft Foundry 的本機 AI runtime 與 SDK。
它讓開發者可以把 AI 模型帶進自己的 App，在使用者裝置上執行，而不是每次都把資料送到雲端 API。
Microsoft 的定位很清楚：
| 層級 | 主要用途 |
|---|---|
| Microsoft Foundry cloud | frontier model、agent、fine-tuning、雲端部署 |
| Foundry Local | 本機、離線、邊緣、裝置端 AI |
| Azure Local | 企業內部與分散式部署 |
Foundry Local 支援 Windows、Linux、macOS，也可用在手機、筆電、桌機與邊緣裝置。
它解決什麼問題？
雲端 AI 很強，但不是每個功能都適合雲端。
常見痛點包括：
- 每次請求都有網路延遲。
- token 成本會隨使用量成長。
- 使用者離線時功能失效。
- 敏感資料不一定適合送到雲端。
- App 需要更穩定的回應時間。
- 企業想把一部分推論留在內部環境。
Foundry Local 的價值，就是讓開發者在「雲端大模型」和「完全不用 AI」之間，多一個可部署的選項。
不是所有 AI 功能都要搬回本機，但很多輕量任務很適合。
例如：
- 文件摘要。
- 簡短問答。
- 本機搜尋。
- 音訊轉文字。
- 會議筆記整理。
- 程式碼輔助。
- 離線客服或知識庫。
- 桌面助理與邊緣裝置任務。
Foundry Local 怎麼運作？
Foundry Local 有幾個主要元件。
| 元件 | 作用 |
|---|---|
| Foundry Local SDK | 提供 Python、JavaScript、C#、Rust 等語言入口 |
| Foundry Local Core | 管理模型下載、載入、推論與卸載 |
| ONNX Runtime | 執行模型推論 |
| Foundry Catalog | 提供可下載與硬體最佳化的模型 |
| Windows ML | 在 Windows 上協助硬體加速與相容性 |
開發者安裝 SDK 後，Foundry Local Core 與 ONNX Runtime 會成為 App build dependency。
使用者第一次執行時，Foundry Local 可以從 Foundry Catalog 下載適合該裝置硬體的模型；之後模型會從本機 cache 載入。
這個設計讓 App 不需要自己重做模型下載、版本、硬體加速與推論生命週期管理。
為什麼 Windows ML 很重要？
在 Windows 上跑本機 AI，最大的麻煩通常不是模型本身，而是硬體差異。
同一個 App 可能跑在：
- Intel CPU。
- AMD CPU。
- NVIDIA GPU。
- Qualcomm NPU。
- Copilot+ PC。
- 傳統 Windows 筆電。
Windows ML 的角色是提供 Windows 內建的 AI 推論 runtime，讓模型能更一致地使用 CPU、GPU、NPU。
Microsoft 說 Foundry Local 在 Windows 上會整合 Windows ML，並透過 Windows update 取得硬體對應的 execution provider plugins。這可以降低使用者自己安裝驅動或處理相容性的負擔。
對開發者來說，這是一個很重要的訊號：Microsoft 想把「本機 AI 推論」變成 Windows 平台能力，而不是每個 App 各自處理。
Foundry Local 跟 Ollama 有什麼不同？
很多人會拿 Foundry Local 跟 Ollama 比。
兩者都能在本機跑模型，但定位不同。
| 工具 | 更適合誰 | 重點 |
|---|---|---|
| Ollama | 開發者、個人玩家、研究與測試 | 快速下載與啟動本機模型 |
| Foundry Local | App 開發者、企業軟體團隊 | 把本機 AI 包進正式 App |
Ollama 很適合快速試模型。
Foundry Local 更像產品化路線：SDK、runtime、catalog、硬體適配、OpenAI 格式 API、App bundle。
如果你只是想在自己電腦跑 Llama 或 Qwen，Ollama 很直覺。
如果你要把 AI 功能交付給使用者，並讓 App 在多種 Windows 裝置上穩定執行，Foundry Local 的方向更接近正式產品需求。
哪些功能適合先搬到本機？
不是每個任務都適合本機 AI。
適合先搬的通常有三種：
1. 對延遲敏感
例如即時輸入補全、語音轉文字、桌面搜尋、快捷指令理解。
這類功能如果每次都等雲端回應，體驗容易卡。
2. 對資料敏感
例如內部文件摘要、個人檔案搜尋、醫療與法律輔助、企業知識庫片段處理。
本機推論不等於完全沒有風險，但資料不離開裝置會降低一部分合規壓力。
3. 使用量高但任務不複雜
例如分類、改寫、摘要、格式轉換。
這類任務如果全部走雲端，token 成本可能累積得很快。本機模型未必最強，但可能夠用，而且成本可預測。
什麼情況仍該用雲端模型？
雲端 frontier model 仍然有明顯優勢。
例如：
- 高難度推理。
- 大型程式碼重構。
- 多模態複雜分析。
- 超長上下文。
- 需要最新知識。
- 需要企業級集中監控與模型治理。
比較務實的架構通常是 hybrid AI。
簡單任務在本機跑，複雜任務送雲端；敏感資料先在本機處理，必要時只送最小上下文；離線模式用本機模型，線上模式再升級到雲端模型。
對 Windows AI App 的影響
Foundry Local 讓 Windows AI App 的設計從「呼叫 API」走向「本機能力加雲端能力混合」。
未來桌面 App 可能會有這樣的架構：
使用者資料
→ 本機模型做初步理解與整理
→ 必要時呼叫雲端模型
→ 回到本機 App 執行動作這對企業尤其重要。
因為企業不是只問模型準不準，還會問：
- 資料有沒有離開裝置？
- 離線能不能用？
- 成本能不能預測？
- 能不能符合硬體政策？
- 能不能跟既有 Windows 管理工具整合？
Foundry Local 不是本機 AI 的終點，但它代表 Microsoft 正在把本機 AI 變成 Windows 開發者可以認真採用的平台能力。