許多開發者接觸本地端 AI 時，第一印象通常是使用 Ollama 跑一個聊天機器人。但本地端 AI 的應用遠不止於文字對話，例如即時語音辨識（Automatic Speech Recognition, ASR）就是一個強大的場景。透過 Microsoft 的 Foundry Local 框架，.NET 開發者現在可以在 Windows 環境下，直接在 C# 應用程式中運行專門的語音模型，實現低延遲且隱私安全的即時轉錄。
什麼是 Foundry Local
Foundry Local 是一個旨在簡化本地 AI 模型生命週期管理的框架。對於工程師來說，最痛苦的通常不是寫程式，而是環境配置：要從 Hugging Face 下載哪個版本的權重檔？如何配置 GPU 驅動或執行提供者（Execution Providers）？模型檔案要放在哪個資料夾？
Foundry Local 解決了這些問題。它提供了一個模型目錄（Catalog），開發者只需要指定模型的別名（Alias），框架就會自動處理後續流程：尋找適合硬體的模型變體、下載、快取、載入至記憶體，以及在應用程式結束時釋放資源。
抽象層與原生 SDK 的權衡
在 .NET AI 的生態系中，我們常看到 Microsoft.Extensions.AI 提供的 IChatClient 抽象介面，這讓開發者可以輕鬆地在不同 AI 供應商（如 OpenAI, Ollama）之間切換而不需要修改核心邏輯。
然而，即時語音轉錄涉及的是原始 PCM 音訊流（Raw PCM Streaming）與中間結果（Interim Results）的處理，這些功能高度依賴於特定供應商的實作。因此，在實作語音轉錄時，我們直接使用 Foundry Local 的原生 SDK（AudioClient），而非抽象介面。這給了我們一個實務上的啟發：當通用抽象層能滿足需求時優先使用；但當需要發揮特定供應商的高階功能時，直接調用原生 SDK 才是正確的做法。
實作流程與技術關鍵
要建立一個即時轉錄應用，核心流程分為三個階段：模型準備、音訊串流、結果處理。
首先是模型管理。透過 FoundryLocalManager 建立配置後，可以使用 GetCatalogAsync 獲取目錄，並指定如 nemotron-speech-streaming-en-0.6b 這樣的模型。呼叫 DownloadAsync 與 LoadAsync 後，模型便準備就緒。
接著是音訊串流。這部分最容易出錯，因為音訊採集（Capture）與模型推論（Inference）的速度並不同步。實務上建議使用 NAudio 庫來擷取 16kHz、16-bit、單聲道的 PCM 音訊。由於 NAudio 的回調是同步的，而 Foundry Local 的 AppendAsync 是非同步的，為了避免阻塞音訊採集或產生過多未受控的任務，建議引入 System.Threading.Channels。將採集到的音訊塊放入一個有界通道（Bounded Channel）中，再由一個專屬的背景任務負責將其送入模型，這樣可以有效處理背壓（Backpressure）問題。
最後是結果處理。模型會透過非同步流（Async Stream）回傳轉錄結果。這裡分為兩種狀態：中間結果（Interim）與最終結果（Final）。中間結果會在使用者說話時即時跳出，而最終結果則在模型判定一句話結束時觸發。將這兩者分開處理，可以創造出像直播字幕那樣流暢的用戶體驗。
為什麼選擇本地端語音辨識
相較於雲端 API，本地端推論有三個核心優勢：
第一是隱私。麥克風的原始音訊完全留在裝置上，不需要上傳至雲端，這對於處理敏感資訊至關重要。 第二是成本與依賴。不需要 API Key，也不需要支付每分鐘的轉錄費用。 第三是低延遲。在初始模型下載完成後，推論過程無需經過網路往返，反應速度更快。
限制與環境
需要注意的是，目前的實作方案（基於 WinML 與 NAudio）僅限於 Windows 平台。此外，雖然本地端 AI 非常強大，但它並非要完全取代雲端 AI。對於需要極大規模模型或彈性擴展的場景，雲端依然是首選；但對於隱私敏感、離線需求或邊緣運算設備，Foundry Local 提供了 .NET 開發者一個極佳的選擇。
來源：devblogs.microsoft.com - Beyond Chat: live Speech-to-Text with Foundry Local and C#
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。