網管人雜誌

本文刊載於網管人雜誌第 244 期 - 2026 年 5 月 1 日出刊，NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。

本文目錄

前言

實戰 – Foundry Local on WS2025

建立 Azure VM 雲端虛擬主機

安裝 Foundry Local

查詢運作狀態

運作 AI 模型

管理 AI 模型快取空間

安裝 Open WebUI

整合 Foundry Local AI 模型

結語

前言

在企業和組織的營運日常中，IT 管理人員最常遭遇到的挑戰之一，就是如何在兼顧執行效能，以及安全與符合法規的前提下導入新技術。

AI 大型語言模型的推論能力，在這一二年來已經成為非常熱門的話題，然而絕大多數的解決方案大都需要仰賴雲端環境，對於需要嚴格保護資料的企業和組織來說，卻往往是難以跨越的障礙，尤其在金融、醫療或政府單位，這些機敏資料很難直接送到雲端環境去跑 AI 模型推論。

此外，AI 大型語言模型雖然功能全面且強大，但是對於 IT 預算本來就不多的中小型企業和組織來說，要導入時可能沒有那麼多 IT 預算來支撐，不導入的話又無法將現有的工作流程，透過 AI 模型進行簡化和加速，其它具備生產力的好主意也無法以 AI 模型進行推論或實作。

因此，微軟推出的 AI Foundry Local，便正好能夠滿足中小型企業和組織的需求，並且即便運作 Foundry Local 的主機不具備 GPU 圖形處理器，只有單純的 CPU 中央處理器，雖然不能運作 AI 大型語言模型，但是也能運作中小型的 AI 語言模型，相信也能滿足 IT 預算不足的中小型企業和組織的需求。

Foundry Local 運作架構（如圖 1 所示），主要在於希望把雲端環境的 AI 模型便利性，能夠在企業和組織的地端資料中心內也能使用。運作核心的組成包含幾個部分，首先最外層是 Foundry Local 服務，這是一個相容於 OpenAI 的 REST API，讓開發人員能用採用熟悉的方式呼叫 AI 模型，確保應用程式無須大改動，就能整合 AI 能力。

圖 1、Foundry Local 運作架構示意圖

圖片來源： Foundry Local 架構- Foundry Local | Microsoft Learn

其次是 ONNX Runtime，這是 AI 推論的核心引擎，支援硬體伺服器採用 CPU、GPU、NPU……等多種硬體，並且微軟與 NVIDIA、AMD、Intel、Qualcomm……等供應商合作，確保能夠達到跨平台一致性的目標，讓企業和組織能夠依照現有運作環境，選擇最合適的硬體伺服器而不必受限於單一供應商。

事實上，微軟還為 Foundry Local 提供 Olive 編譯工具，能把 Hugging Face 等來源的 AI 模型，轉換為 ONNX 格式並進行優化，讓 AI 推論的執行效能更佳。另一個值得注意的設計是硬體抽象層，透過「執行提供者」（Execution Provider）的概念，讓同一個 AI 模型能夠在不同的硬體伺服器上執行，並且不需要額外修改程式碼，舉例來說，在 Windows 伺服器上使用 Intel NPU 或 Qualcomm NPU 時，只要安裝相對應的驅動程式，就能直接享有硬體加速運作 AI 模型的效益。

在 AI 模型管理方面，Foundry Local 提供 AI 模型快取機制，讓管理人員能夠輕鬆將 AI 模型進行下載，並且快取儲存在本機 SSD 固態硬碟當中，避免每次執行 AI 模型時就要先下載的麻煩和無謂的等待時間。當然，下載後的 AI 模型，倘若不常使用的話，管理人員也可以透過 CLI 指令，隨時查詢、移除、更新快取……等，確保系統維持在最佳狀態。

除了 AI 推論引擎與模型管理外，Foundry Local 也提供完整的工具鏈，管理人員只要透過 CLI 工具，即可快速下載執行或卸載用不到的 AI 模型，而在開發人員方面，則能夠透過相容於 OpenAI 的 SDK 進行整合，同時微軟也在 Visual Studio Code 中提供 AI 相關工具，讓開發人員能夠在 IDE 內直接管理 AI 模型，並且視覺化推論的結果，讓企業和組織的管理人員能夠透過這些工具，讓 AI 模型的開發測試和維護作業，能夠更透明並且更容易追蹤。

簡單來說，Foundry Local 能夠提供給企業和組織許多面向的價值，舉例來說，在法規檢查方面，由於機敏資料可以在本地端的 AI 模型中直接推論和分析，所以不必擔心外洩風險。在資源管控方面，AI 模型能夠即時分析 CPU、記憶體或硬碟使用率，協助預測潛在的硬體資源瓶頸，在災難復原演練方面，即使網路發生中斷，AI 模型仍然能夠在本地端繼續執行，確保系統維持一定的智慧化能力，至於例行性的安全性更新和檢查作業，AI 模型也能夠協助分析系統更新狀態，提供更精準的日常維護建議。

實戰 – Foundry Local on WS2025

建立 Azure VM 雲端虛擬主機

由於，中小型企業或組織，在 IT 預算不多的情況下，可能沒有多餘的測試主機，讓 IT 管理人員能夠建立測試環境。此時，IT 管理人員，也能利用建立 Azure 免費帳戶的方式，部署 Azure VM 雲端虛擬主機的方式，達到快速建構和測試 AI Foundry Local 在 Windows Server 2025 運作的目的。

在作業系統版本方面，請選擇採用 Windows Server 2025 Standard 或 Datacenter 版本即可，在硬體資源需求方面，原則上最低需求只要 8 GB 記憶體和 3 GB 可用磁碟空間即可，但實際上會建議具備 16 GB 記憶體和 15 GB 可用磁碟空間比較保險。

可能已經有 IT 管理人員接著發出疑問，要跑 AI 模型一定需要 GPU 對吧？事實上，在 Foundry Local 的運作環境中，擁有硬體 GPU 或 NPU 的話，確實能夠讓屆時的 AI 模型運作更快反應更順暢，倘若只有單獨的 CPU 時，那麼 Foundry Local 也能跑 AI 模型，只是執行效能或反應可能不是令人滿意，但 IT 管理人員仍然能夠達到測試的目的。

本文實作環境，便在 Azure 雲端環境中，建立一台僅具備 CPU 硬體運算資源，而沒有 GPU 硬體的雲端 VM 虛擬主機，並採用 Windows Server 2025 Datacenter 雲端作業系統版本（如圖 2 所示）。

圖 2、建立僅具備 CPU 硬體運算資源的雲端 VM 虛擬主機

安裝 Foundry Local

由於，本文實作環境為單純的 CPU 硬體運算資源的 VM 虛擬主機，已經滿足安裝 Foundry Local 運作環境條件，倘若是配置 GPU 或 NPU 運算資源時，請先處理好 GPU 或 NPU 驅動程式的部份，舉例來說，倘若使用 Intel NPU 硬體的話，請先確保已經安裝 Intel NPU 驅動程式，以便在 Foundry Local 運作環境中，能夠啟用 NPU 加速機制。

順利登入 Windows Server 2025 主機後，只要開啟 Terminal 視窗後，鍵入「winget install Microsoft.FoundryLocal」指令，並回答「Y」同意授權條款後，系統便會自動找尋最新釋出的 Foundry Local 版本後，透過內建的 Winget 機制下載後執行安裝作業，待安裝作業完成後，鍵入「foundry --version」指令，確認目前安裝的 Foundry Local 版本，可以看到目前安裝的最新版本為 0.8.119（如圖 3 所示）。

圖 3、在 Windows Server 2025 主機上安裝 Foundry Local

查詢運作狀態

在條列和載入 AI 模型之前，先確認 Foundry Local 的運作狀態，確保稍後能夠順利下載並載入 AI 模型。首先，請執行「foundry service status」指令，確認為綠燈執行狀態，並且顯示 API Endpoints 資訊，本文實作環境為「http://127.0.0.1:50276/openai/status」，接著執行「foundry service list」指令，檢查系統是否已經有載入任何 AI 模型（如圖 4 所示）。

圖 4、檢查 Foundry Local 運作狀態

此外，由於這台雲端 VM 虛擬主機僅配置 CPU 硬體運算資源，所以在 Foundry Local 服務狀態的第二行中，可以看到有「CPUExecutionProvider」資訊，表示這台 Foundry Local 稍後載入 AI 模型時，將會下載及執行適用於 CPU 硬體運算資源的 AI 模型，倘若配置的是 NVIDIA CUDA GPU 硬體運算資源，則會顯示「CUDAExecutionProvider」資訊。

預設情況下，除非 IT 管理人員進行額外設定，否則 Windows Server 2025 主機重新啟動後，Foundry Local 服務並不會自動啟動，此時管理人員便可以透過「foundry service start」指令，進行 Foundry Local 服務啟動作業，下列為 Foundry Local 服務相關指令與說明：

foundry service --help：顯示所有 Foundry Local 服務的相關指令參數與用途說明。
foundry service start：啟動 Foundry Local 服務。
foundry service stop：停止 Foundry Local 服務。
foundry service restart：重新啟動 Foundry Local 服務。
foundry service status：顯示 Foundry Local 服務目前的運作狀態。
foundry service list or ps：顯示目前已經載入 Foundry Local 服務的所有 AI 模型。
foundry service set：組態設定 Foundry Local 服務。
foundry service init：重新執行 Windows 的 EPs 自動註冊程序。
foundry service diag：顯示 Foundry Local 服務的日誌資訊。

運作 AI 模型

在開始下載並運作 AI 模型之前，管理人員可以先執行「foundry model list」指令，條列出目前 Foundry Local 服務支援的 AI 模型，以及運作這些 AI 模型的相關資訊，例如，支援 CPU 或 GPU 硬體運算資源，AI 模型大小……等資訊（如圖 5 所示），下列為每個欄位的意義說明：

Alias： AI 模型的別名或簡稱，方便主機使用者辨識與進行呼叫，例如，phi-4，就是其中一個 AI 模型的名稱。
Device： AI 模型運作時所採用的硬體裝置，例如，GPU 為圖形處理器，或是 CPU 為中央處理器。GPU 適用於高效能平行運算，能夠有效加速大型語言模型的推論效能，而 CPU 則是一般小模型和資源有限情況下使用。
Task： AI 模型的主要用途或工作任務類型，其中，chat 表示用於自然語言對話，tools 表示模型支援額外功能的工具，例如，生成程式碼或資料處理 …… 等。此欄位能幫助管理人員，快速判斷 AI 模型的適用情境。
File Size： AI 模型的檔案大小，通常以 GB 為單位。檔案大小除了直接影響下載時間，以及主機儲存空間之外，大型 AI 模型雖然功能更強大，但通常也需要更高的資源配置才行。
License： AI 模型的授權方式，例如，MIT 或 Apache-2.0，不同的授權方式，決定模型使用者是否能夠自由修改或散布或是商業化。
Model ID： AI 模型在系統內部的唯一識別碼，通常用於在系統中精確呼叫該模型，包含模型名稱、版本號碼與裝置類型，這是精準呼叫模型的關鍵，避免因為別名相似而造成混淆。

圖 5、條列出所有可用的 AI 模型及相關資訊

值得注意的是，有些管理人員對於 Model ID 欄位表示方式的誤解，舉例來說，Phi-3-mini-4k-instruct-generic-cpu:2，表示這是該模型用於 CPU 裝置上的第 2 個版本，而不是代表運作這個模型需要的 CPU 核心數，這是最常見的誤解之一。

一般來說，運作 AI 模型時在模型名稱方面，只要鍵入模型的別名即可，系統會自動為現有的硬體選擇最佳模型，舉例來說，如果硬體配置 Nvidia GPU 時，Foundry Local 會自動選擇最佳的 GPU 型號運作模型，倘若硬體配置支援的 NPU 時，Foundry Local 同樣會自動選擇最適合用於 NPU 的 AI 模型，所以管理人員通常無須記住完整的模型 ID，只需要使用名稱較短的別名即可。

除非，管理人員想要執行特定的 AI 模型，才會需要使用完整的模型 ID，舉例來說，在具備 GPU 的硬體裝置主機中，要運作用於 CPU 的 phi-4 模型時，便需要鍵入完整的 Phi-4-generic-cpu 模型 ID 才行。下列為 Foundry Local 模型相關指令與說明：

foundry model --help：顯示所有可用模型的相關指令及使用方式。
foundry model run <model>：運作指定的 AI 模型，倘若本機尚未快取該模型，則自動下載後運作，管理人員便能開始與 AI 模型互動。
foundry model list：列出所有可用的 AI 模型，在第一次執行時，系統會自動下載適用於主機硬體的 EP 執行程式。
foundry model list --filter <key>=<value>：過濾後條列出指定的內容，例如，依照 Alias、Device、Task……等欄位中的關鍵字進行過濾。舉例來說，執行 foundry model list --filter device=CPU 指令，系統便會僅條列出適用於 CPU 的 AI 模型。
foundry model info <model>：顯示指定模型的詳細資訊。
foundry model info <model> --license：顯示指定模型的授權資訊。
foundry model download <model>：下載指定模型至本機快取，但先不運行該模型。
foundry model load <model>：將指定的 AI 模型載入服務中。
foundry model unload <model>：從服務中將指定的 AI 模型卸載。

現在，管理人員可以執行「foundry model run」指令，搭配 AI 模型的別名，例如，phi-4-mini，讓系統自動執行下載並且載入 AI 模型的動作。當系統載入指定的 AI 模型後，便會立即運作該 AI 模型，以本文實作環境來說，phi-4-mini 屬於對話型語言模型，並且可以正確理解正體中文（如圖 6 所示）。

圖 6、下載並載入指定的 AI 模型

隨著時間不斷推移，Foundry Local 支援的 AI 模型將會越來越多，此時善用過濾參數的用法，便能有效幫助管理人員快速找到要使用的 AI 模型，並且 Foundry Local 過濾參數支援多種使用方法，舉例來說，除了指定關鍵字的正向過濾方式之外，也支援使用「!」達到反向過濾的目的，例如，執行「foundry model list --filter device=!GPU」指令，能夠過濾並顯示不包含支援 GPU 硬體裝置的 AI 模型。

另外，也支援使用「*」萬用字元的方式來進行過濾，例如，執行「foundry model list --filter alias=phi*」指令，表示過濾後僅顯示 AI 模型別名開頭為 phi 的 AI 模型（如圖 7 所示）。值得注意的是，透過萬用字元方式進行過濾的方法，僅支援別名欄位，其它欄位並不支援。

圖 7、過濾並顯示別名為 phi 開頭的 AI 模型

在微軟官方網站中，Foundry Local 模型指令執行時常見的問題之一，就是執行「foundry model list」指令後，倘若得到「Exception: Request to local service failed. Uri: http://127.0.0.1:0/foundry/list」的錯誤訊息時，這個因為 Foundry Local 服務綁定連接埠的問題，導致無法存取 AI 模型的情況，官方建議執行「foundry service restart」指令，重新啟動 Foundry Local 服務，便能有效解決 Foundry Local 服務綁定連接埠的問題。

管理 AI 模型快取空間

現在，隨著管理人員測試各種 AI 模型，並且系統不斷自動下載及載入各種 AI 模型後，除了使用硬體運算資源之外，在儲存空間方面也會因為下載 AI 模型，而不斷佔用 SSD 固態硬碟空間。

原則上，當 AI 模型快取存在於主機時，那麼當主機需要運作該 AI 模型時，便可以減少下載及載入模型的時間，然而若是該模型不常被使用，甚至測試過後便不再使用的話，那麼便可以刪除該模型的快取空間，以便節省寶貴的 SSD 固態硬碟空間。

執行「foundry cache list」指令，便能夠條列主機目前已經下載並快取哪些 AI 模型，接著執行「foundry cache location」指令，便能查詢 AI 模型預設快取在本機的路徑，執行「foundry cache remove <model>」指令，便能移除指定的 AI 模型快取（如圖 8 所示）。下列為 Foundry Local 快取相關指令與說明：

foundry cache --help：顯示所有可用的相關快取指令及使用方式。
foundry cache location：顯示主機目前使用快取路徑。
foundry cache list：條列出儲存在本機快取中的所有 AI 模型。
foundry cache cd <path>：將快取路徑變更為其它指定路徑。
foundry cache remove <model>：從本機主機快取中移除指定的 AI 模型。

圖 8、管理 AI 模型快取空間

安裝 Open WebUI

此時，部份管理人員可能會覺得，雖然可以運作 AI 模型，但是在 Terminal 視窗中互動不太方便，舉例來說，管理人員希望上傳一份檔案讓 AI 模型進行翻譯或分析，在 Terminal 視窗中互動不容易達成此需求。

所幸，Foundry Local 可以輕鬆與各種應用進行整合。現在，即可將 Foundry Local 的 AI 模型，與開源社群最活躍專案之一的 Open WebUI 進行整合，讓管理人員可以輕鬆透過 Open WebUI 的友善操作介面，與底層 Foundry Local 的 AI 模型進行互動。

稍後，會透過 Python pip 的方式來安裝 Open WebUI。但是，在這之前必須先為 Windows Server 2025 運作環境，安裝最新版本 Visual C++ Redistributable（x64）才行（如圖 9 所示），否則稍後啟動 Open WebUI 服務時，將會遭遇 Dyanmic Link Library（DLL）初始化載入的錯誤。安裝完成後便接著執行「winget install Python.Python.3.11」指令，透過 winget 機制下載及安裝 Python。

圖 9、安裝 Python 之前，必須先安裝最新版本 Visual C++ Redistributable（x64）

當 Python 安裝作業完成後，接著執行「python.exe -m pip --version」指令，確認目前系統中 Python Pip 版本，在本文實作環境中為 Pip 24.0 的版本並非最新版本，請執行「python.exe -m pip install --upgrade pip」指令，將系統中 Python Pip 版本進行更新升級作業，更新版本後為最新的 Python Pip 26.0 版本，便可以執行「python.exe -m pip install open-webui」指令，透過 Python Pip 機制安裝 Open WebUI 軟體套件。

安裝作業完成後，便可以執行「open-webui serve」指令，啟動 Open WebUI 服務，當看到顯示「INFO : Started server process」字樣後，表示 Open WebUI 服務已經順利啟動。預設情況下 Open WebUI 服務會綁定使用 Port 8080 連接埠，所以當管理人員啟動 Open WebUI 服務後，請打開瀏覽器連結「http://localhost:8080」便會看到 Open WebUI 初始化頁面，請鍵入使用者帳號、Email、密碼後，按下 Create Admin Account 鈕，建立 Open WebUI 的預設管理人員帳號（如圖 10 所示）。

圖 10、建立 Open WebUI 的預設管理人員帳號

順利登入 Open WebUI 之後，可以看到畫面是大家熟悉的 AI 對話視窗（如圖 11 所示），然而當管理人員嘗試進行對話時，會在右上角出現「Model not selected」的錯誤訊息，原因在於，雖然順利安裝完 Open WebUI，但是還沒組態設定讓 Open WebUI，能夠連接到 Foundry Local 的 AI 模型所導致。

圖 11、Open WebUI 的 AI 對話視窗

整合 Foundry Local AI 模型

現在，只要組態設定 Open WebUI，能夠連接 Foundry Local AI 模型後，屆時管理人員在 Open WebUI 介面中，便可以選擇使用不同的 AI 模型進行對話。

首先，請執行「foundry service status」指令，確認 Foundry Local 服務正常運作中，另外也可以複製 Foundry Local 的 API Endpoints 路徑後，在瀏覽器網址列貼上，如果有看到 API Endpoints 資訊（如圖 12 所示），代表運作正確無誤，確保稍後 Open WebUI 能夠順利連接。

圖 12、確認 Foundry Local 的 API Endpoints 正常運作中

接著，切換回 Open WebUI 操作介面，點選右上方帳號圖示後，依序點選「Admin Panel > Settings > Connections」項目後，在 General 區塊中將「Direct Connections」功能項目啟動，系統會顯示 Connections settings updated 資訊（如圖 13 所示），然後按下 Save 鈕，確認儲存組態設定。

圖 13、為 Open WebUI 啟動 Direct Connections 功能

回到 Open WebUI 操作介面後，再次點選右上方帳號圖示，依序點選「Settings > Connections > Manage Direct Connections」項目後，按下 + 號圖示，在彈出的 Add Connection 視窗中，在 URL 列貼上 Foundry Local 的 API Endpoints 路徑，例如，http://127.0.0.1:49918/v1，在下方 Auth 下拉式選單中，由預設的 Bearer 調整為 None，然後按下 Save 鈕儲存組態設定（如圖 14 所示）。

圖 14、組態設定 Open WebUI 連接 Foundry Local 的 API Endpoints 路徑

值得注意的是，由於本文是在本機進行測試研究，所以連接 API Endpoints 路徑時，Auth 驗證方式才會採用 None 項目，以便簡化整體組態設定內容。實務上，請務必啟用連接 API Endpoints 路徑 Auth 驗證機制，減少非預期發生的資安風險。

現在，回到 Open WebUI 操作介面後，點選左上方的 Select a model，便會顯示 Foundry Local 中，已經存在於 Foundry Local Cache 的 AI 模型，管理人員便可以在 Open WebUI 操作介面中，選擇個人喜好的 AI 模型後，進行 AI 模型對話以及後續的互動，同時選擇的 AI 模型，倘若是支援多模態功能時，在 Open WebUI 操作介面中，也能夠輕鬆上傳檔案或透過語音進行交談（如圖 15 所示）。