Windows on kenji.blog

Microsoft.Windows.AI 的最新 API 應用案例與範例程式碼

Fri, 11 Sep 2026 18:00:00 +0900

Microsoft.Windows.AI 的最新 API 應用案例與範例程式碼：探索 Windows Copilot Runtime 的深淵

1. 前言：AI 原生內建於 Windows 的新時代

近年來，AI 技術的發展日新月異，正迅速從雲端上的大型語言模型（LLM）應用，典範轉移至邊緣裝置（本機 PC）上的 AI 推論。其中扮演核心角色的，正是 Microsoft 為 Windows 11 提供的「Windows Copilot Runtime」以及用於操作它的「Microsoft.Windows.AI」API。

使用雲端 API（如 OpenAI 或 Azure OpenAI 等）開發應用程式雖然容易，但總是伴隨著延遲、隱私和持續成本的挑戰。另一方面，透過在本機執行 AI 模型，我們可以在機密資料不離開裝置的情況下，實現即使在離線狀態也能運作的超低延遲應用程式。

本文將針對未來 Windows 應用程式開發中不可或缺的本機 AI 功能實作方法，搭配 C# 與 C++ 的實用範例程式碼，從架構到效能調校進行極為詳細且徹底的解說。不僅僅是呼叫 API，我們還會深入探討背後硬體（NPU 與 GPU）的運用、與 DirectML 的整合等進階技術細節。

2. Windows Copilot Runtime 與架構全貌

Windows Copilot Runtime 是一套 AI 堆疊，專為讓開發者能輕鬆將 AI 模型整合至 Windows 上，並發揮最高效能而設計。此執行階段在 OS 層級將硬體加速抽象化，為開發者提供統一的介面。

graph TD App["Windows 應用程式 (C# / C++)"] --> API["Microsoft.Windows.AI APIs"] App --> ORT["ONNX Runtime"] API --> WCR["Windows Copilot Runtime (OS 層)"] WCR --> SLM["本機模型 (Phi-Silica 等)"] ORT --> DML["DirectML 執行提供者"] SLM --> DML DML --> DXCore["DXCore / DirectX 12"] DXCore --> NPU["NPU (神經處理單元)"] DXCore --> GPU["GPU (圖形處理單元)"] DXCore --> CPU["CPU"]

如上述架構圖所示，應用程式可以透過使用高階的 Microsoft.Windows.AI API，直接存取內建於 OS 中的小型語言模型（SLM：如 Phi-Silica 等）。此外，若使用自訂模型，也可以透過 ONNX Runtime 與 DirectML 明確地利用硬體加速。由於 OS 層會最佳化分配給 CPU、GPU 與 NPU 的工作負載，開發者無需深入了解硬體差異，即可建構高效能的 AI 應用程式。

3. 硬體加速與 NPU 的數學評估

最新的 Copilot+ PC 搭載了專門處理 AI 運算的處理器，即 NPU（神經處理單元）。NPU 的效能通常以 TOPS（Tera Operations Per Second，每秒兆次運算）來評估。

在 AI 模型的推論中，矩陣乘法（GEMM: General Matrix Multiply）的運算能力尤其決定了吞吐量。硬體的理論最大效能 $P_{\text{peak}}$ 可以用以下公式估算：

$$ P_{\text{peak}} = f \times N_{\text{cores}} \times N_{\text{MACs/core}} \times 2 $$

其中：

$f$ 是 NPU 的時脈頻率（Hz）
$N_{\text{cores}}$ 是 NPU 內的核心數量
$N_{\text{MACs/core}}$ 是每個核心的 MAC（乘積累加）單元數量
最後的 $2$ 是因為一次 MAC 運算包含乘法與加法兩個操作（FLOPs/OPs）。

例如，若 NPU 頻率為 1.5GHz、4 個核心、每個核心有 4096 個 MACs：

$$ P_{\text{peak}} = 1.5 \times 10^9 \times 4 \times 4096 \times 2 \approx 49.15 \text{ TOPS} $$

在數學上證明了此效能足以跨越 Windows 11 的 Copilot+ PC 要求（40 TOPS）。

此外，AI 模型，尤其是 LLM 的推論（解碼階段）往往受限於記憶體頻寬（Memory-Bound）。系統記憶體的理論頻寬 $BW$ 計算方式如下：

$$ BW = f_{\text{mem}} \times W_{\text{bus}} \times \frac{2}{8} $$

若使用 LPDDR5x-8533 記憶體（$f_{\text{mem}} = 8533 \text{ MT/s}$）、128 位元匯流排（$W_{\text{bus}} = 128$），頻寬約為 $136 \text{ GB/s}$。在最佳化 AI 應用程式時，如何節省此頻寬至關重要，因此後文將提到的模型量化（Quantization）變得不可或缺。

4. 開發環境設定

要使用最新的 Windows AI API，需要準備以下環境與工具鏈：

OS: Windows 11 版本 24H2 或更新版本（強烈建議使用搭載符合 Copilot+ PC 要求之 NPU 的裝置）
SDK: Windows App SDK (v1.5 或以上，支援 AI 擴充功能的版本)
開發環境: Visual Studio 2022 (v17.10 或以上)，具備 C++ 桌面開發與 .NET 桌面開發工作負載
套件: 透過 NuGet 安裝 Microsoft.Windows.AI 與 Microsoft.ML.OnnxRuntime.DirectML

1
2
3
4
5
6


<!-- .csproj 設定範例 -->
<ItemGroup>
 <PackageReference Include="Microsoft.Windows.AI" Version="1.0.0-preview1" />
 <PackageReference Include="Microsoft.WindowsAppSDK" Version="1.5.240311000" />
 <PackageReference Include="Microsoft.ML.OnnxRuntime.DirectML" Version="1.17.1" />
</ItemGroup>

5. 【Deep Dive 1】使用 C# 活用本機語言模型（Phi-Silica）

Windows Copilot Runtime 中內建了由 Microsoft 開發的高效小型語言模型「Phi-Silica」作為 OS 標準元件。這使得我們無需從網路下載 GB 級別的模型，即可在離線環境下進行進階的自然語言處理（文章摘要、程式碼生成、聊天機器人）。

以下是使用 Microsoft.Windows.AI.Generative 命名空間，在 C# 中建構聊天 AI 的進階範例程式碼。支援串流回應，並能即時生成文字而不阻塞 UI 執行緒。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84


using System;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Windows.AI.Generative;

namespace WindowsAI.Sample
{
 public class LocalLanguageModelService
 {
 private LanguageModel _languageModel;
 private bool _isInitialized = false;

 /// <summary>
 /// 進行語言模型的初始化。檢查 NPU 的可用性，並將模型載入至最佳裝置。
 /// </summary>
 public async Task InitializeAsync()
 {
 if (_isInitialized) return;

 Console.WriteLine("正在檢查本機 AI 模型（Phi-Silica）的系統需求與可用性...");

 // 檢查模型在系統上是否可用 (不支援時可能會提示下載)
 var availability = await LanguageModel.CheckAvailabilityAsync();
 if (availability != LanguageModelAvailability.Available)
 {
 throw new InvalidOperationException($"目前無法使用本機 AI 模型。狀態: {availability}");
 }

 // 建立模型執行個體（此時會進行記憶體空間對應與 NPU 初始化）
 _languageModel = await LanguageModel.CreateAsync();
 _isInitialized = true;

 Console.WriteLine("語言模型初始化完成。透過 DirectML 的硬體加速已啟用。");
 }

 /// <summary>
 /// 接收使用者的提示詞，並以串流方式生成回應。
 /// </summary>
 public async Task GenerateResponseStreamAsync(string prompt, CancellationToken cancellationToken)
 {
 if (!_isInitialized) await InitializeAsync();

 Console.WriteLine($"\n[使用者輸入]: {prompt}\n[AI 助理]: ");

 // 設定生成時的超參數
 var options = new LanguageModelOptions
 {
 Temperature = 0.7f,
 TopP = 0.9f,
 MaxTokens = 2048,
 RepetitionPenalty = 1.1f
 };

 // 建立對話上下文
 var context = new LanguageModelContext();
 context.AddSystemMessage("你是一個直接在 Windows 本機 NPU 上運行的高階 AI 助理。請逐步且合乎邏輯地思考，並簡潔地回答。");
 context.AddUserMessage(prompt);

 try
 {
 // 呼叫串流推論 API
 var responseStream = _languageModel.GenerateResponseStreamAsync(context, options);

 // 以非同步方式反覆處理作為 IAsyncEnumerable 傳回的區塊
 await foreach (var chunk in responseStream.WithCancellation(cancellationToken))
 {
 // 將生成的權杖（區塊）即時輸出至主控台
 // 若為 UI 應用程式，可在此處使用 DispatcherQueue 反映至 TextBox 等元件
 Console.Write(chunk.Text);
 }
 Console.WriteLine();
 }
 catch (OperationCanceledException)
 {
 Console.WriteLine("\n[生成已由使用者或系統取消]");
 }
 catch (Exception ex)
 {
 Console.WriteLine($"\n[發生致命錯誤: {ex.Message}]");
 }
 }
 }
}

5.1 C# 實作中的架構解說

這段程式碼的核心在於透過 LanguageModel.CheckAvailabilityAsync() 進行執行前驗證，以及透過 GenerateResponseStreamAsync 進行非同步串流。在 OS 背景運作的 Copilot Runtime 接收到此 API 呼叫後，會在內部啟動 ONNX Runtime，並根據系統設定選擇最佳的執行提供者（Execution Provider，在許多最新 PC 上為 DirectML + NPU）。

開發者完全無需考慮模型的張量形狀、分詞器實作、KV 快取的記憶體管理等細節，只需幾行 C# 程式碼即可將最先進的 AI 推論管線整合到應用程式中。

6. 【Deep Dive 2】透過 C++ 與 DirectML 進行自訂模型的高速推論

當處理 OS 標準語言模型無法涵蓋的特定領域（例如：專有影像分割、語音辨識、自訂物件偵測模型等）時，開發者需要直接操作位於 Microsoft.Windows.AI 底層的 ONNX Runtime 與 DirectML。

使用 C++，您可以將記憶體配置最佳化至極限，並發揮 NPU/GPU 的峰值效能。以下是使用 DirectML 在 C++ 中執行 ONNX 格式自訂模型（例：YOLOv8）的進階初始化與推論管線核心實作。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99


#include <iostream>
#include <vector>
#include <string>
#include <stdexcept>
#include <onnxruntime_cxx_api.h>
#include <dml_provider_factory.h>

class CustomVisionAIProcessor {
private:
 Ort::Env env;
 Ort::Session session{nullptr};
 Ort::AllocatorWithDefaultOptions allocator;

public:
 CustomVisionAIProcessor(const std::wstring& modelPath)
 : env(ORT_LOGGING_LEVEL_WARNING, "VisionAIProcessor") {

 Ort::SessionOptions sessionOptions;
 // 執行緒數量最佳化
 sessionOptions.SetIntraOpNumThreads(1);
 // 將圖形最佳化層級設為最大
 sessionOptions.SetGraphOptimizationLevel(GraphOptimizationLevel::ORT_ENABLE_ALL);

 // 1. 新增 DirectML 執行提供者 (DML EP)
 // device_id = 0 是系統預設推薦的介面卡（NPU 或高效能 GPU）
 const OrtApi& ortApi = Ort::GetApi();
 OrtDmlApi* dmlApi = nullptr;
 OrtStatus* status = ortApi.GetExecutionProviderApi("DML", ORT_API_VERSION, reinterpret_cast<void**>(&dmlApi));

 if (status == nullptr && dmlApi != nullptr) {
 Ort::ThrowOnError(dmlApi->SessionOptionsAppendExecutionProvider_DML(sessionOptions, 0));
 std::cout << "[Info] 已成功附加 DirectML 執行提供者。" << std::endl;
 } else {
 std::cerr << "[Warning] 無法取得 DirectML API。將以 CPU 降級模式執行。" << std::endl;
 if (status != nullptr) ortApi.ReleaseStatus(status);
 }

 // 2. 載入模型並建立工作階段
 try {
 session = Ort::Session(env, modelPath.c_str(), sessionOptions);
 std::cout << "[Info] 成功載入 ONNX 模型，且已編譯運算圖。" << std::endl;
 } catch (const Ort::Exception& e) {
 std::cerr << "[Error] 模型載入失敗: " << e.what() << std::endl;
 throw;
 }
 }

 void RunInference(const std::vector<float>& imageTensor, const std::vector<int64_t>& inputShape) {
 // 3. 建立輸入張量緩衝區
 Ort::MemoryInfo memoryInfo = Ort::MemoryInfo::CreateCpu(OrtArenaAllocator, OrtMemTypeDefault);
 Ort::Value inputTensor = Ort::Value::CreateTensor<float>(
 memoryInfo,
 const_cast<float*>(imageTensor.data()),
 imageTensor.size(),
 inputShape.data(),
 inputShape.size()
 );

 // 4. 動態取得輸入與輸出節點名稱
 auto inputNamePtr = session.GetInputNameAllocated(0, allocator);
 auto outputNamePtr = session.GetOutputNameAllocated(0, allocator);
 const char* inputNames[] = { inputNamePtr.get() };
 const char* outputNames[] = { outputNamePtr.get() };

 // 5. 執行推論 (透過 DirectML 卸載至 NPU/GPU)
 std::cout << "[Info] 開始執行推論引擎..." << std::endl;
 auto startTime = std::chrono::high_resolution_clock::now();

 auto outputTensors = session.Run(Ort::RunOptions{nullptr}, inputNames, &inputTensor, 1, outputNames, 1);

 auto endTime = std::chrono::high_resolution_clock::now();
 auto duration = std::chrono::duration_cast<std::chrono::milliseconds>(endTime - startTime);

 // 6. 取得並解析結果張量
 float* outputData = outputTensors.front().GetTensorMutableData<float>();
 size_t outputSize = outputTensors.front().GetTensorTypeAndShapeInfo().GetElementCount();

 std::cout << "[Result] 推論完成: " << duration.count() << " ms" << std::endl;
 std::cout << "[Result] 輸出張量的元素數量: " << outputSize << std::endl;
 // ※此後，將對輸出張量實作 NMS（非極大值抑制）或繪製邊界方塊的處理
 }
};

int main() {
 try {
 // 要執行的 ONNX 模型路徑
 CustomVisionAIProcessor processor(L"models/yolov8n_quantized.onnx");

 // 用於推論的假影像資料 (批次大小 1 x 3 頻道 x 640 x 640)
 std::vector<int64_t> inputShape = {1, 3, 640, 640};
 std::vector<float> dummyImage(1 * 3 * 640 * 640, 0.5f);

 processor.RunInference(dummyImage, inputShape);
 } catch (const std::exception& e) {
 std::cerr << "程式異常終止: " << e.what() << std::endl;
 return -1;
 }
 return 0;
}

6.1 C++ 中記憶體管理與零拷貝推論的重要性

在 C++ 中使用 DirectML 的最大優勢，在於能與 DirectX 12 (DX12) 進行緊密整合。上述程式碼出於教學目的，包含了從標準 CPU 記憶體複製資料的過程，但在實際的遊戲引擎或影像處理應用程式中，經常會使用 DX12 將影像（紋理）保留在 GPU 或 NPU 的記憶體空間中。

在這種情況下，可以利用 OrtDmlApi 的進階繫結功能，直接將 DX12 資源對應為 ONNX Runtime 的張量，實現「零拷貝推論 (Zero-Copy Inference)」。如此一來，PCIe 匯流排之間的資料傳輸開銷（即前述頻寬 $BW$ 的消耗）將完全消失，進而大幅提升即時影片處理的畫面更新率。

7. 效能最佳化與最佳實務

在使用 Windows AI API 或 DirectML 開發頂級 AI 應用程式時，不可或缺的最佳化策略彙整如下：

7.1 模型量化 (Quantization) 與 Olive 工具組

要發揮 NPU 的真正實力，將 AI 模型的權重與激勵值從 FP32（單精度浮點數）**量化（Quantization）**至 INT8 或 INT4 絕對是必要條件。NPU 的架構專為整數運算而設計，相較於 FP32，INT8 在理論上能達到 4 倍的吞吐量，並大幅節省耗電。

透過使用 Microsoft 提供的 Olive (ONNX Live) 工具鏈，可以將 PyTorch 等模型自動針對 Windows 環境進行最佳化。Olive 能強力支援對 Transformer 模型的特殊注意力最佳化，以及針對各種硬體的運算圖編譯。

7.2 批次處理 vs 互動式串流的權衡

在 API 呼叫中，將多個推論請求合併進行批次處理，可以提高 NPU 的利用率（Compute Utilization）。然而，在如聊天機器人這類互動式 UI 的情況下，決定使用者體驗（UX）的並非吞吐量，而是顯示第一個權杖所需的時間（TTFT: Time To First Token）。因此，在互動式 UI 中，最佳實務是將批次大小設為 1，並優先採用串流生成設計。

7.3 背景工作與 OS 的整合

AI 推論會大量消耗本機的電力與系統資源。必須與 Windows 的 App Lifecycle API 整合，當應用程式轉入背景執行時，實作暫停（Suspend）優先度較低的推論工作或限制資源消耗的機制。

sequenceDiagram participant User as "使用者" participant App as "Windows App (C#)" participant API as "Microsoft.Windows.AI" participant OS as "Windows Copilot Runtime" participant ORT as "ONNX Runtime (DML)" participant NPU as "NPU 硬體" User->>App: "輸入提示詞" App->>API: "GenerateResponseStreamAsync()" API->>OS: "分派推論工作" OS->>ORT: "運算圖執行請求" ORT->>NPU: "透過 DirectML 執行命令清單" NPU-->>ORT: "運算完成（生成 1 個權杖）" ORT-->>OS: "張量結果" OS-->>API: "已解碼的文字" API-->>App: "IAsyncEnumerable 區塊" App-->>User: "在 UI 上即時繪製文字" Note over ORT,NPU: "高速重複此迴圈直到完成"

此循序圖展示了非同步處理之美：在完全不阻塞 UI 執行緒的情況下，資料如同水流般從最底層的 NPU 硬體，一路串流至應用程式的呈現層。

8. 未來展望與 Windows AI 的進化

Microsoft.Windows.AI API 與 Copilot Runtime 目前正處於快速進化階段。在未來的開發者更新中，可望出現以下典範轉移：

多模態 API 內建於 OS: 不僅限於文字，還能無縫同時處理語音、影像，甚至是即時視訊來源，在 OS 層級標準提供跨模態的 AI 推論。
RAG (檢索增強生成) 的系統層級支援: 在 OS 安全的沙盒中，將本機 PC 內的個人文件庫或 Windows Search 索引與 AI 模型結合，在完全保護使用者隱私的狀態下建構超高階的個人 AI 助理。
NPU 的動態資源擴展: 當多個 AI 應用程式（例如，背景中的降噪功能與前景的程式碼生成）同時運作時，Windows 核心排程器會動態切換 NPU 的執行上下文，以保證服務品質（QoS）的機制。

9. 結論：本機 AI 將改變應用程式的未來

Windows 11 的 Copilot Runtime 與 Microsoft.Windows.AI API，為所有 Windows 開發者帶來了名為「本機 AI」的極強大武器。我們不再需要完全依賴雲端 API。我們能消除延遲、堅守隱私，同時為使用者提供即使在離線狀態下也能完美運作的次世代 AI 體驗。

請活用本文所解說的知識，包括使用 C# 整合系統標準語言模型、數學效能評估，以及使用 C++ 與 DirectML 進行極限硬體最佳化，親手創造次世代的「AI 原生」Windows 應用程式。AI 帶來的無限可能，正展現在您所撰寫的程式碼前方。

※注意事項：本文是根據 2026 年 9 月時的預覽版 API 及最新規格所撰寫。由於 Windows 更新可能會改變 API 規格或硬體需求，因此在實作時請務必參閱 Microsoft Learn 的官方文件。

【2026年最新】在Windows環境下運行本地LLM的完全指南

Fri, 11 Sep 2026 10:00:00 +0900

1. 簡介：為什麼現在要在 Windows 上運行本地 LLM？

2026年的今天，生成式 AI 與大型語言模型（LLM）的進化，展現出從雲端上巨大的 API 服務，轉向在個人 PC 與地端環境運作的「本地 LLM」的巨大典範轉移。雖然 OpenAI 的 GPT-5 與 Anthropic 的 Claude 3.5 等雲端 AI 非常強大，但企業與個人並不能將所有數據都傳送到雲端。從隱私、安全性、延遲，以及長期、可持續性成本的觀點來看，對本地 LLM 的需求正迎來前所未有的爆發性增長。

尤其在 Windows 環境下，本地 LLM 生態系統的進化更是令人矚目。幾年前，「說到 AI 開發與執行就是 Linux」還是常識，但到了 2026 年的今天，Windows 已經蛻變成一個非常強大且易於使用的 AI 平台。

本文將基於 2026 年最新的技術趨勢，為您提供在 Windows 環境下建置、營運與最佳化本地 LLM 的完全指南。從適合初學者的 Ollama 簡易建置，到適合進階使用者的 llama.cpp 極限最佳化，再到 VRAM 計算的數學方法、架構的深入理解，以及本地的微調（Fine-tuning），將以壓倒性的豐富內容為您進行徹底解說。

1.1 2026 年本地 LLM 的相關技術趨勢

塑造當前本地 LLM 生態系統的主要趨勢如下：

GGUF 格式的全面普及：將元數據（Metadata）與張量（Tensor）整合到單一檔案的 GGUF（GPT-Generated Unified Format）已經完全成為業界標準（De facto standard）。這使得使用者只需從 Hugging Face 下載一個檔案，就能在任何環境下執行。
MoE（Mixture of Experts）架構的民主化：市面上發布了許多小規模卻高效能的 MoE 模型，透過在推論時僅啟動部分專家網路（Expert），在降低消費級 PC 運算負載的同時，展現出足以媲美巨大模型的效能。
推論引擎的高度抽象化與最佳化：Ollama、LM Studio、AnythingLLM 等工具變得更加完善，使用者不再需要擔心安裝 CUDA 驅動程式等複雜的依賴關係。此外，隨著 FlashAttention 3 對 Windows 提供原生支援，推論速度也獲得了戲劇性的提升。
NPU 的應用與 Windows Copilot+ PC 的崛起：即使是沒有配備 GPU 的筆記型電腦，利用內建的 NPU（神經網絡處理單元）以低功耗運行小型 LLM（SLM: Small Language Models）的技術也已進入實用階段。

2. 硬體需求與作業系統準備

為了讓本地 LLM 能以實用的速度（每秒 15 到 30 個 Token 以上）運行，硬體的選擇是最為重要的。

2.1 建議硬體配置

隨著 AI PC 的進化，硬體規格的要求也隨之改變。

作業系統 (OS)：Windows 11 Pro (24H2 或更高版本)。為了使用 WSL2 的完整功能、進階記憶體管理，以及 DirectML 的最新 API，這是必備的。
處理器 (CPU)：Intel Core Ultra 200 系列或更高版本，或 AMD Ryzen 9000 系列或更高版本。若要同時使用 CPU 進行推論，高頻寬記憶體通訊是不可或缺的。
記憶體 (RAM)：最低 32GB，建議 64GB 以上。主記憶體的頻寬（MB/s）在 CPU 推論或卸載（Offload）時會成為決定性的瓶頸。DDR5-6000 以上的高速記憶體是最理想的。
顯示卡 (GPU)：NVIDIA RTX 4000 / 5000 系列。對於本地 LLM 來說，最重要的不是運算效能，而是「VRAM（顯示記憶體）容量」。
- 入門級：RTX 4060 Ti (16GB 版) - CP值最高。非常適合 8B 到 14B 等級的模型。
- 中階：RTX 4070 Ti SUPER (16GB) / RTX 4080 SUPER (16GB)
- 高階：RTX 4090 (24GB) / RTX 5090 (32GB) - 要運行 30B 到 70B 等級的量化模型會需要用到。
儲存空間：PCIe Gen4 或 Gen5 的 NVMe SSD。能大幅縮短載入數十 GB 模型所需的時間。

2.2 WSL2 (Windows Subsystem for Linux 2) 設定

雖然許多 GUI 工具能在 Windows 原生環境下運行，但對於使用 Python 進行開發、編譯最新工具，以及後續會提到的 LoRA 微調來說，WSL2 會非常方便。在 Windows 11 的最新環境中，只需在主機端安裝 NVIDIA 驅動程式，即可在 WSL2 中透通地使用 GPU (CUDA)。

以系統管理員身分開啟 PowerShell，並執行以下命令：

1
2
3
4
5


# 安裝 WSL2 與最新的 Ubuntu
wsl --install -d Ubuntu-24.04

# 更新核心
wsl --update

安裝完成後，在 WSL2 終端機內執行 nvidia-smi，如果能正常辨識到 GPU，即代表成功。

3. 本地 LLM 的架構與推論機制

了解模型在本地環境中是如何生成文字的內部結構，對於疑難排解和效能最佳化非常有用。

以下的 Mermaid 圖表展示了典型的本地 LLM 推論流程。

graph TD User["使用者輸入 (提示詞)"] --> Tokenizer["分詞器 (Tokenizer)"] Tokenizer --> Embedding["嵌入層 (Embedding)"] subgraph "Transformer Block (x Layers)" Embedding --> Attn["自注意力機制 (Self-Attention)"] Attn --> KVCache["KV 快取 (保存 Key/Value)"] Attn --> FFN["前饋神經網絡 (FFN)"] end FFN --> Logits["Logits 計算 (Logits)"] Logits --> Sampler["取樣器 (Temperature, Top-K, Top-P)"] Sampler --> OutputToken["輸出 Token"] OutputToken --> |"自迴歸生成"| Tokenizer OutputToken --> Decoder["反分詞器 (Detokenizer)"] Decoder --> FinalOutput["最終輸出文字"]

3.1 兩個階段：Prefill 與 Decode

LLM 的文字生成分為兩個具有不同計算特性的階段。

Prefill（提示詞處理）階段：將輸入的完整提示詞一次性處理並進行理解的階段。由於可以平行計算，GPU 的運算能力（FLOPS）將直接影響速度。如果提示詞很長，這個階段可能會需要花費數秒鐘的時間。
Decode（Token 生成）階段：逐一預測 Token 並將其作為下一次輸入（自迴歸）的階段。因為在這個階段平行計算會受到限制，所以 GPU 的 VRAM 頻寬（Memory Bandwidth）會成為決定性的瓶頸。

4. VRAM 消耗量的計算與模型大小的數學解析

為了正確判斷「自己的 PC 能運行什麼模型？」，我們必須了解 VRAM 的計算公式。若因 VRAM 不足而觸發回退到系統記憶體（RAM）的機制，推論速度將會變慢 10 到 100 倍。

4.1 基於參數大小的基礎 VRAM

這代表將模型的權重載入到 VRAM 所需的記憶體容量。可透過模型大小 $P$（參數數量，單位：10億 = 1B）與每個參數所佔的位元組數 $B$ 來進行計算。

$$ V_{base} = P \times B \quad \text{(GB)} $$

例如，如果以 FP16（半精度浮點數，16位元=2位元組）載入一個 8B（80億）參數的模型：

$$ V_{base} = 8 \times 2 = 16 \text{ GB} $$

也就是說，即使 GPU 擁有 16GB 的 VRAM，光是載入模型就會幾乎達到極限。

4.2 量化 (Quantization) 的魔法

這時「量化」就派上用場了。透過降低參數的精度，可以大幅縮減模型大小。以最常見的 4bit 量化（例：Q4_K_M）來說，每個參數平均大約僅佔 0.55 個位元組。

$$ V_{base\_4bit} = 8 \times 0.55 = 4.4 \text{ GB} $$

因此，只要有 16GB 的 VRAM，就能綽綽有餘地運行 8B 模型。

4.3 KV 快取計算 (GQA 支援版)

在進行推論時，用來保留過去上下文的「KV 快取」會消耗 VRAM。在如 Llama 3 等最新模型中，為了節省記憶體，採用了 GQA（Grouped Query Attention）技術。

KV 快取的消耗量 $V_{kv}$（GB）可以用以下的數學公式來表示：

$$ V_{kv} = 2 \times b \times s \times l \times \left( \frac{h_{kv}}{h_q} \right) \times h_q \times d \times B_{kv} \div 10^9 $$

整理後，可以使用 Key 和 Value 的注意力頭數量 $h_{kv}$ 進行更簡單的計算：

$$ V_{kv} = 2 \times b \times s \times l \times h_{kv} \times d \times B_{kv} \div 10^9 $$

這裡的變數代表：

$b$：批次大小（個人本地使用時通常為 1）
$s$：序列長度（上下文長度，例：8192）
$l$：層數（例：32）
$h_{kv}$：KV 注意力頭數（例：8）
$d$：每個注意力頭的維度（例：128）
$B_{kv}$：KV 快取的位元組數（FP16 為 2）

計算範例（Llama 3 8B, 上下文 8192, FP16 快取）： $V_{kv} = 2 \times 1 \times 8192 \times 32 \times 8 \times 128 \times 2 \div 10^9 \approx 1.07 \text{ GB}$

請注意，隨著上下文長度 $s$ 的增加，所需的 VRAM 將呈現線性增長。

5. 實踐 1：使用 Ollama 進行最快、最短的環境建置

理解了理論之後，讓我們實際在 Windows 環境中運行 LLM 看看。在 2026 年的今天，最對使用者友善的工具非「Ollama」莫屬。它提供了類似 Docker 般直覺的 CLI（命令列介面）。

5.1 安裝與執行

從 Ollama 官方網站下載並執行 Windows 版安裝程式。
開啟 PowerShell，並輸入以下命令。在這裡，我們使用支援日文的 llama3:8b。

1

ollama run llama3:8b

第一次執行時會下載模型。下載完成後，就可以直接在終端機中進行對話。

5.2 使用 Modelfile 建立客製化 AI

您可以輕鬆建立具有特定人格特質（Persona）的 AI。請在任意位置建立一個名為 Modelfile 的檔案。

1
2
3
4
5
6
7
8
9


FROM llama3:8b

SYSTEM """
你是一位非常優秀的資深軟體工程師。
對於使用者的提問，請務必搭配程式碼範例，以合乎邏輯且簡潔的方式進行回答。
"""

PARAMETER temperature 0.3
PARAMETER num_ctx 8192

使用以下命令來建置並執行您專屬的模型：

1
2


ollama create SeniorDev -f ./Modelfile
ollama run SeniorDev

5.3 透過外部應用程式 (AI 編輯器) 存取

Ollama 會在 http://localhost:11434 開放一個與 OpenAI 相容的 API 端點（Endpoint）。只需在 Cursor 或 Continue.dev 等 VS Code 擴充套件的後端設定中，將 URL 指定為上述位置，並將模型名稱指定為 SeniorDev 等，就能免費實現強大的本地程式碼助手。

6. 實踐 2：使用 llama.cpp 進行極限效能調校

如果您想要更精細的記憶體管理，或是想搶先嘗試最新格式（例如 EXL2 或 IQ 量化等），可以直接操作核心引擎 llama.cpp。

6.1 llama.cpp 的編譯步驟

在 Windows 環境下，最好的做法是使用 CUDA Toolkit 與 CMake 從原始碼進行編譯。

1
2
3
4
5
6
7
8


git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
mkdir build
cd build

# 設定為支援 CUDA 並進行編譯
cmake .. -DLLAMA_CUBLAS=ON -DBUILD_SHARED_LIBS=OFF
cmake --build . --config Release -j 16

6.2 在伺服器模式下的進階啟動

使用編譯出來的 llama-server.exe 來託管（Host）模型。

1
2
3
4
5
6
7


.\bin\Release\llama-server.exe `
 --model "C:\models\Llama-3-8B-Instruct.Q4_K_M.gguf" `
 --ctx-size 8192 `
 --n-gpu-layers 99 `
 --threads 8 `
 --flash-attn `
 --port 8080

--n-gpu-layers 99：盡可能將所有層都卸載到 GPU VRAM 中。
--flash-attn：啟用 FlashAttention 3，以提升推論速度並減少 KV 快取的 VRAM 消耗。

7. GUI 前端介面：LM Studio 與本地 RAG 建置

如果您對命令列（Command Line）有所抗拒，或者想要更直覺地進行 RAG（檢索增強生成），可以使用 GUI。

7.1 LM Studio

LM Studio 是一款出色的應用程式，它將模型搜尋、下載、系統需求事前檢查，以及聊天 UI 全部整合在一起。只需按下應用程式內的「Local Server」按鈕，就能啟動相容於 OpenAI 的 API。

7.2 使用 AnythingLLM 的 RAG 架構

這是讀取公司內部文件或個人筆記的 RAG 環境架構圖：

graph LR Document["文件 (PDF, MD)"] --> Chunking["區塊分割 (Chunking)"] Chunking --> EmbedModel["嵌入模型 (Embedding Model)"] EmbedModel --> VectorDB["向量資料庫 (Vector DB)"] UserQuery["使用者提問"] --> EmbedQuery["提問的嵌入向量化"] EmbedQuery --> VectorDB VectorDB --> |"相似度搜尋"| RetrievedDocs["擷取相關文件"] UserQuery --> PromptBuilder["生成提示詞 (Prompt)"] RetrievedDocs --> PromptBuilder PromptBuilder --> LocalLLM["本地 LLM"] LocalLLM --> Answer["最終回答"]

只要使用 AnythingLLM 電腦版（Windows），在設定畫面中指定 Ollama（作為 LLM 與 Embedding 引擎），並設定使用本地的 VectorDB（LanceDB），短短幾分鐘內就能完成這個架構。這將誕生一個完全不會向外部傳送任何資料的私有 AI。

8. 在 Windows WSL2 上進行微調 (LoRA)

不僅是在本地運行，如果您還想用自己的資料讓模型變得更聰明，可以使用 LoRA（Low-Rank Adaptation）來進行微調（Fine-tuning）。在 2026 年的今天，只要使用「Unsloth」這個函式庫，在 Windows 的 WSL2 環境下，即使只有 16GB 的 VRAM，也能在數小時內完成 8B 模型的訓練。

在 WSL2 的 Ubuntu 內執行以下命令來建立環境：

1
2
3
4


conda create --name unsloth_env python=3.11
conda activate unsloth_env
pip install "unsloth[colab-new] @ git+https://github.com/unslothai/unsloth.git"
pip install --no-deps trl peft accelerate bitsandbytes

Unsloth 將 CUDA 核心優化到了極致，與標準的 Hugging Face 函式庫相比，訓練速度約為兩倍，VRAM 消耗量則減半。只要開啟 Jupyter Notebook 並載入資料集（JSONL 格式），即使是 VRAM 為 12GB 到 16GB 的 RTX 4060 Ti 等顯示卡，也能夠完成幾個 Epoch 的訓練。

9. 效能與疑難排解

以下是常遇到的問題及其解決方案：

1. 推論速度極端緩慢（1～2 tokens/s）

原因：模型無法完全載入到 VRAM 中，導致被卸載（Offload）到系統記憶體（RAM）。 解決方案：請在工作管理員中確認「專用 GPU 記憶體」。如果已經達到極限，請縮小上下文大小（-c），或是使用位元數更低的量化模型（如 Q4_K_M 等）。

2. 「CUDA out of memory」錯誤

原因：VRAM 已經完全耗盡。特別是在對話時間過長，導致 KV 快取過度膨脹時會發生。 解決方案：刻意限制並調小參數值，如果是 Ollama，請調小 num_ctx；如果是 llama.cpp，請調小 -c 的數值。

3. 日文（或其他非英語）的生成很奇怪

原因：提示詞模板（Prompt Template）不一致，或是使用了不支援該語言的模型。 解決方案：請使用模型名稱中包含 Instruct 的版本，並確認工具端是否選擇了模型作者指定的正確模板格式（如 ChatML 或 Llama 3 格式）。

10. 總結與未來展望

在 2026 年，於 Windows 環境下建置本地 LLM 已不再是少部分工程師的特權。隨著 GGUF 格式成為業界標準、Ollama 與 LM Studio 等完善生態系統的出現，以及以 FlashAttention 為首的硬體最佳化，任何人都可以輕易打造出企業級的 AI 環境。

請務必活用本文所解說的以下重點：

使用 VRAM 的數學計算，合乎邏輯地選擇最適合自己 PC 規格的模型大小與量化等級。
使用 Ollama 以最快的速度建置環境，並與 AI 編輯器整合，大幅提升生產力。
透過 llama.cpp 的進階參數控制，發揮硬體的極限效能。
使用 AnythingLLM 建置能處理機密資料、安全可靠的本地 RAG 系統。
活用 Unsloth (WSL2)，培育出擁有您專屬專業知識的客製化 AI。

AI 的「民主化」不再只是一個流行語（Buzzword），而是真實在您的 Windows 桌面系統上運作的系統。擺脫雲端 API 的使用成本與資料外洩風險，現在就踏入自由且強大的私有 AI 世界吧。