AI 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 的官方文件。

無須Python！只用C++打造AI推論引擎

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

1. 前言：為什麼要放棄Python，改用C++製作AI推論引擎？

在現代的AI開發中，Python是事實上的標準。得益於PyTorch和TensorFlow等強大的框架，我們只需幾行程式碼就能建構、訓練並推論複雜的神經網路。然而，在這些框架的背後，是C++和CUDA等底層語言在負責繁重的計算處理。Python充其量只扮演了「膠水」的角色。

那麼，為什麼我們需要特地排除Python，單獨用C++來打造AI推論引擎呢？這有幾個強而有力的理由。

極致的效能與低延遲：可以完全消除Python的GIL（全域直譯器鎖）以及動態型別帶來的開銷。特別是在需要即時性的系統中，毫秒級的延遲都是致命的。
部署的便利性：要在終端使用者的環境中建構Python環境（龐大的函式庫群、依賴關係的地獄）非常困難。如果是C++，只需要發布靜態連結的單一執行檔（.exe或ELF二進位檔）即可。
支援邊緣設備：在智慧型手機、嵌入式設備、Raspberry Pi等資源嚴重受限的環境中，沒有餘裕去執行會消耗數GB記憶體的Python執行階段（Runtime）。
硬體的直接控制：像是記憶體分配的時機、明確地使用SIMD指令、最佳化與GPU之間的記憶體傳輸等，只有C++這類底層語言才能做到。

本文將在深受Georgi Gerganov所開發的「GGML」函式庫架構啟發之下，深入技術深淵，解說如何從零開始、純用C++建構出能運行大型語言模型（LLM）的推論引擎。

2. 推論引擎架構全貌

AI的推論處理，本質上就是「連續的巨大矩陣計算」。為了有效率地執行這些計算，推論引擎必須由以下幾個元件構成。

graph TD A["輸入資料 (Tokens/Images)"] --> B["張量管理 (Tensor Management)"] B --> C["計算圖 (DAG)"] C --> D["記憶體池與分配器 (Memory Arena & Allocator)"] C --> E["排程器與執行緒池 (Scheduler & Thread Pool)"] E --> F["CPU後端 (AVX2/ARM NEON)"] E --> G["GPU後端 (CUDA/Metal)"] F --> H["輸出結果"] G --> H

張量（Tensor）管理：管理多維陣列的資料結構以及各維度的步幅（Stride）。
計算圖（Computation Graph）：將神經網路各層的運算，表示為有向無環圖（DAG）。
記憶體池（Memory Arena）：為了避免動態記憶體分配（malloc或new）的開銷，採用預先分配型的記憶體管理機制。
後端（Backend）：針對CPU或GPU等特定硬體最佳化的運算實作（Kernel）。

我們將運用C++的強大功能（樣板、指標運算、RAII等）將這些組裝起來。

3. 記憶體管理的奧秘：記憶體池與SIMD對齊

推論引擎中的記憶體管理，是直接關係到效能的最重要因素之一。在推論過程中，特別是通過Transformer模型的各層時，會產生數量龐大的中間張量。如果每次都用標準的malloc來分配與釋放，堆積（Heap）的碎片化以及作業系統的上下文切換將會導致致命的速度下降。

因此，我們採用了「記憶體池（Memory Arena）」的方法。這是在推論開始時計算（或寫死）所需的最大記憶體量並一次性分配，之後只需遞增指標就能切割出記憶體的手法。

3.1 對齊（Alignment）的重要性

現代CPU支援SIMD（Single Instruction, Multiple Data）指令。例如Intel/AMD的AVX2/AVX-512，以及ARM的NEON等。這些指令可以一次處理256位元（32位元組）或512位元（64位元組）的資料，但處理對象的資料記憶體必須對齊（Alignment）在特定的位元組邊界（通常是32位元組或64位元組）。

以下是考慮到對齊的記憶體池C++實作範例。

 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


#include <cstdint>
#include <cstddef>
#include <stdexcept>
#include <iostream>

struct MemoryArena {
 size_t size;
 size_t offset;
 uint8_t* data;

 MemoryArena(size_t size) : size(size), offset(0) {
 // 在POSIX系統使用 posix_memalign，Windows使用 _aligned_malloc
#ifdef _WIN32
 data = static_cast<uint8_t*>(_aligned_malloc(size, 64));
#else
 if (posix_memalign(reinterpret_cast<void**>(&data), 64, size) != 0) {
 throw std::bad_alloc();
 }
#endif
 }

 ~MemoryArena() {
#ifdef _WIN32
 _aligned_free(data);
#else
 free(data);
#endif
 }

 void* allocate(size_t bytes, size_t alignment = 64) {
 // 計算對齊（求出填充大小）
 size_t pad = (alignment - (offset % alignment)) % alignment;
 if (offset + pad + bytes > size) {
 throw std::runtime_error("OOM: MemoryArena out of memory");
 }
 offset += pad;
 void* ptr = data + offset;
 offset += bytes;
 return ptr;
 }

 void reset() {
 offset = 0; // 釋放記憶體只需將指標歸零（O(1)）
 }
};

像這樣，建立張量時必定透過這個記憶體池來取得記憶體。每次推論步驟（例如每次生成Token）結束後，只要呼叫 reset() 就能瞬間重新利用記憶體。

4. 張量資料結構與步幅的魔法

張量是純量、向量、矩陣的廣義概念。在實作上重要的是，雖然實際資料在記憶體上是以一維的連續陣列來配置，但為了將其解釋為多維，我們導入了「步幅（Stride）」的概念。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


enum class DataType {
 FP32,
 FP16,
 INT8, // 量化用
 INT4 // 量化用
};

struct Tensor {
 int n_dims; // 維度數量
 int64_t ne[4]; // 各維度的元素數量 (Number of Elements)
 size_t nb[4]; // 各維度的步幅 (Number of Bytes)
 DataType type; // 資料型態
 void* data; // 指向有效負載（Payload）的指標

 // 計算圖用
 enum OpType op;
 Tensor* src0;
 Tensor* src1;
};

步幅 nb[i] 代表在維度 i 中，相鄰元素之間在記憶體上的位元組距離。例如，元素數量為 $M \times N$ 的矩陣（FP32，1個元素4位元組），如果以列優先（Row-Major）儲存，其步幅如下：

nb[0] = 4 (位元組) ：往行（Column）方向移動
nb[1] = $N \times 4$ (位元組) ：往列（Row）方向移動

利用這一點，我們可以不用複製記憶體，只需交換步幅的數值，就能實現「轉置（Transpose）」或「視圖（View）」等操作。這非常優雅且高效。

5. 建立計算圖（DAG）與延遲評估

與PyTorch等類似，我們的推論引擎也採用接近「Define-by-Run」的延遲評估（Lazy Evaluation）。也就是說，在呼叫運算函式時不進行計算，只建立圖（節點間的依賴關係）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


Tensor* tensor_add(MemoryArena& arena, Tensor* a, Tensor* b) {
 Tensor* out = create_tensor(arena, a->type, a->n_dims, a->ne);
 out->op = OpType::ADD;
 out->src0 = a;
 out->src1 = b;
 return out;
}

Tensor* tensor_mul_mat(MemoryArena& arena, Tensor* a, Tensor* b) {
 // b 通常已經被轉置
 int64_t ne[2] = { a->ne[0], b->ne[1] };
 Tensor* out = create_tensor(arena, a->type, 2, ne);
 out->op = OpType::MUL_MAT;
 out->src0 = a;
 out->src1 = b;
 return out;
}

推論處理的流程如下：

graph LR A["定義張量 (Define Tensors)"] --> B["透過運算建立圖 (Build Graph via Ops)"] B --> C["拓撲排序 (Topological Sort)"] C --> D["為輸出分配記憶體 (Allocate Memory for Outputs)"] D --> E["依序執行節點 (Execute Nodes In Order)"]

在評估圖（前向傳播）時，我們使用拓撲排序，從沒有依賴關係的節點開始依序執行。因為只是進行推論，不需要保留反向傳播用的梯度，因此記憶體管理會變得非常簡單。

6. 數學與最佳化的核心：矩陣乘法 (GEMM)

AI推論計算量有90%以上花費在矩陣乘法（GEMM: General Matrix Multiply）上。Transformer模型核心的注意力機制和前饋神經網路（FFN），歸根究柢也是巨大的矩陣乘法。

兩個矩陣 $A$ (大小 $M \times K$) 與 $B$ (大小 $K \times N$) 的乘積 $C = A B$ (大小 $M \times N$) ，用數學式表示如下：

$$ C_{i,j} = \sum_{k=0}^{K-1} A_{i,k} \cdot B_{k,j} $$

如果用樸素的三層迴圈來實作，會頻繁發生快取未命中（Cache Miss），完全發揮不出效能。

6.1 CPU上的快取區塊化與SIMD最佳化

在CPU上加速GEMM的基本策略如下：

迴圈平鋪（Loop Tiling/快取區塊化）：將矩陣分割成能放進L1/L2快取的小區塊來進行計算。
資料打包（Data Packing）：在內部重新排列資料，使記憶體存取模式變得連續。
活用SIMD：使用AVX-512中的 _mm512_fmadd_ps 等FMA（Fused Multiply-Add）指令，在一個時脈週期內完成大量乘加運算。

以下展示一個使用C++和SIMD Intrinsics（內建函式）簡化版的向量內積（Dot Product）範例。

 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


#include <immintrin.h> // 供AVX指令使用

// 使用AVX2的FP32高速內積
float dot_product_avx2(const float* a, const float* b, int n) {
 __m256 sum256 = _mm256_setzero_ps();
 int i = 0;

 // 一次處理8個元素（256位元 = 32位元組 = 8 * 4位元組）
 for (; i <= n - 8; i += 8) {
 __m256 va = _mm256_loadu_ps(a + i);
 __m256 vb = _mm256_loadu_ps(b + i);
 // FMA指令: sum256 = va * vb + sum256
 sum256 = _mm256_fmadd_ps(va, vb, sum256);
 }

 // 將SIMD暫存器內的值進行水平相加
 float result[8];
 _mm256_storeu_ps(result, sum256);
 float dot = result[0] + result[1] + result[2] + result[3] +
 result[4] + result[5] + result[6] + result[7];

 // 處理剩餘部分
 for (; i < n; ++i) {
 dot += a[i] * b[i];
 }
 return dot;
}

光是這個小小的技巧，就能比樸素的實作獲得數倍至十幾倍的速度提升。

7. 跨越硬體高牆：整合CUDA與Metal後端

雖然只有純C++實作也能在CPU上有一定的運行表現，但要以實用的速度（例如：每秒生成20個Token以上）來運行LLM等巨大模型，GPU的平行計算能力是不可或缺的。因此，我們在引擎中導入後端（Backend）的抽象層。

7.1 後端抽象化

利用C++的多型（Polymorphism），讓我們能切換運算的執行器（Executor）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


class Backend {
public:
 virtual ~Backend() = default;
 virtual void alloc_buffer(Tensor* t) = 0;
 virtual void free_buffer(Tensor* t) = 0;
 virtual void copy_to_device(Tensor* t) = 0;
 virtual void copy_to_host(Tensor* t) = 0;

 // 執行各種運算
 virtual void compute_add(Tensor* src0, Tensor* src1, Tensor* dst) = 0;
 virtual void compute_mul_mat(Tensor* src0, Tensor* src1, Tensor* dst) = 0;
};

7.2 NVIDIA CUDA 後端實作

為了活用NVIDIA的GPU，我們使用CUDA C++擴充功能來實作後端。雖然可以自己寫核心（Kernel），但關於矩陣乘法，活用NVIDIA提供的最高階函式庫「cuBLAS」才是上策。

 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


#include <cublas_v2.h>
#include <cuda_runtime.h>

class CUDABackend : public Backend {
private:
 cublasHandle_t handle;

public:
 CUDABackend() {
 cublasCreate(&handle);
 }

 ~CUDABackend() {
 cublasDestroy(handle);
 }

 void compute_mul_mat(Tensor* src0, Tensor* src1, Tensor* dst) override {
 // CUDA預設為行優先（Column-Major），因此參數需要特別注意
 const float alpha = 1.0f;
 const float beta = 0.0f;

 int m = src0->ne[0];
 int k = src0->ne[1];
 int n = src1->ne[1]; // 假設src1已被轉置

 cublasSgemm(handle, CUBLAS_OP_T, CUBLAS_OP_N,
 m, n, k,
 &alpha,
 (const float*)src0->data, k,
 (const float*)src1->data, k,
 &beta,
 (float*)dst->data, m);
 cudaDeviceSynchronize();
 }
};

CUDA記憶體與主機（CPU）記憶體之間的資料傳輸（cudaMemcpy）非常耗時，因此在設計上非常重要的一點是：在推論過程中應盡可能將所有的權重（重み張量）與中間張量保存在VRAM中。

7.3 Apple Silicon (Metal) 後端

近年來，Mac的M1/M2/M3晶片（Apple Silicon）作為AI推論機非常優秀。其原因在於「統一記憶體（Unified Memory）」。由於CPU和GPU共享同一塊記憶體區域，因此完全不需要像前述CUDA那樣透過PCIe匯流排進行高成本的主機與設備間記憶體傳輸。

要從C++呼叫Metal，可以將Objective-C++（.mm 檔案）當作橋樑，或是利用metal-cpp函式庫。我們使用Metal的Compute Shader（在.metal檔案中以類似C++的語法撰寫）來編寫核心（Kernel）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


// Metal著色器 (kernel.metal)
#include <metal_stdlib>
using namespace metal;

kernel void mul_mat_kernel(
 device const float* A [[buffer(0)]],
 device const float* B [[buffer(1)]],
 device float* C [[buffer(2)]],
 constant uint3& dims [[buffer(3)]],
 uint2 gid [[thread_position_in_grid]]
) {
 uint m = dims.x; uint k = dims.y; uint n = dims.z;
 uint row = gid.y; uint col = gid.x;

 if (row < m && col < n) {
 float sum = 0.0;
 for (uint i = 0; i < k; ++i) {
 sum += A[row * k + i] * B[i * n + col]; // 簡化版
 }
 C[row * n + col] = sum;
 }
}

在Apple Silicon環境中，還提供了名為MPS（Metal Performance Shaders）的矩陣乘法專用最佳化函式庫，在實際應用中使用它能跑出驚人的推論速度。

8. Transformer模型特有的處理：Attention與KV Cache

像LLaMA 2/3或GPT等最先進的LLM，都是基於Transformer架構。為了用C++實作它，必須建構出由以下數學式所表示的「Scaled Dot-Product Attention」。

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V $$

此外，在自迴歸型（Autoregressive）的Token生成中，必須保留過去Token的計算結果（Key與Value）。我們稱之為「KV快取（Key-Value Cache）」。

graph TD T["當前Token (Current Token)"] --> Q["Query"] T --> K["Key"] T --> V["Value"] K --> KCache["附加至KV快取 (Append to KV Cache)"] V --> VCache["附加至KV快取 (Append to KV Cache)"] Q --> Dot1["Q * K_Cache^T"] KCache --> Dot1 Dot1 --> Scale["縮放 (Scale 1/sqrt(d))"] Scale --> Softmax["Softmax"] Softmax --> Dot2["SoftmaxOut * V_Cache"] VCache --> Dot2 Dot2 --> Out["上下文向量 (Context Vector)"]

在KV快取的記憶體分配上，也會預先在記憶體池中保留最大上下文長度（例如4096或8192 Tokens）的記憶體空間，並採用類似環狀緩衝區（Ring Buffer）的方式來運作。這樣就能防止在每個生成步驟重新分配記憶體。

另外，針對位置編碼（Positional Encoding），我們將實作近年來成為主流的「RoPE（Rotary Position Embedding）」。這是一種將位置資訊作為複數空間旋轉向量嵌入的手法，在C++中對 sin 及 cos 函式呼叫的最佳化（例如建立尋找表 Lookup Table 等）是影響效能的關鍵。

9. 透過模型量化（Quantization）達成極限最佳化

如果將大型模型（例如70億參數的LLaMA模型）維持在FP32（32位元浮點數）載入，光是權重就會消耗約28GB的記憶體（VRAM）。再把KV快取和推論用緩衝區算進去，很容易就超過30GB，一般的消費級GPU根本無法執行。

因此，「量化（Quantization）」就成了不可或缺的技術。這也是GGML格式的精髓所在。

量化是指刻意降低權重精度的技術。

FP16 (16-bit): 大小減半。精度幾乎沒有下降。
INT8 (8-bit): 大小變成1/4。僅有微小下降。
INT4 (4-bit): 大小變成1/8。若使用獨特的區塊化（Blocking）與縮放因子（Scaling Factor），即可進行具實用性的推論。

在推論引擎端，會從記憶體讀出被壓縮為INT4（或INT8）的權重，在載入到CPU或GPU的暫存器後，立刻解壓縮（Dequantize）回FP16或FP32再進行計算。

令人驚訝的是，即使增加了計算量，減少從記憶體讀取的資料量反而能讓速度更快。這是因為在現代硬體中，推論任務的瓶頸不在於「計算力（Compute Bound）」，而在於「記憶體頻寬（Memory Bandwidth Bound）」。如果是實作了INT4量化的C++引擎，即使是只有8GB VRAM的MacBook Air等設備，也能流暢地運行本機端的LLM。

10. 效能調校：NUMA架構與執行緒池

當使用CPU進行推論時，多執行緒化是必須的。但如果只是單純啟動多個 std::thread，並不能算是最佳做法。

在現代的多插槽（Multi-socket）伺服器或Ryzen Threadripper等高階CPU上，採用了**NUMA（Non-Uniform Memory Access）**架構。從某個CPU核心存取實體上較近的記憶體（本地記憶體）速度很快，但存取綁定在其他處理器上的記憶體則會變得極慢。

在進階的C++推論引擎中，會靈活運用以下技巧：

執行緒綁定（Thread Pinning）：將各個執行緒固定在特定的CPU核心（設定親和性 Affinity），防止上下文切換導致快取失效。
感知NUMA的記憶體分配（NUMA-aware Allocation）：在處理資料的執行緒所在的同一個NUMA節點上分配記憶體。
工作竊取型執行緒池（Work-stealing Thread Pool）：將計算圖的各個節點分割成細小的任務，並實作能讓閒置執行緒自動奪取任務執行的有效率排程器。

透過活用這些技巧，能將CPU使用率緊緊貼在100%附近，跑出接近理論值的吞吐量。

11. 總結：用C++的「肌肉」驅動AI的樂趣

Python確實很方便。在研發和製作原型時，沒有任何語言能比得上它的生產力。然而，當完成的模型要轉移到「在真實世界中，有效率地、在各種設備上運行」的階段時，C++出場的時刻就到了。

直接操作記憶體的位元組陣列，用SIMD指令將暫存器操到極限，一邊與GPU的VRAM頻寬搏鬥一邊打造出的推論引擎，看著它在終端機上陸續生成自然的文字（Token）時，那種成就感，是呼叫Python框架中 model.generate() 時絕對無法體會到的「身為工程師純粹的喜悅」。

AI技術往往容易變成「黑盒子（Black Box）」，但透過自己親手用C++寫下從張量運算到記憶體分配的所有過程，可以深刻理解LLM究竟是如何「思考」的，洞悉其真正的機制。

如果你具備C++的基礎知識，且對現在的AI技術有著強烈的興趣，請務必挑戰開發自製的推論引擎。GGML和llama.cpp的原始碼，絕對會是你最棒的活教材。

來吧，拋開Python沉重的執行階段，用C++的肌肉讓最先進的AI跑起來吧！

如何在本地環境中最快地微調 TinyLLaMA

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

1. 前言：為什麼現在要選擇 TinyLLaMA 與本地部署？

大型語言模型 (LLM) 的進化正以驚人的速度發展，隨之而來的是模型參數數量也持續膨脹至數千億規模。儘管 GPT-4 或 Claude 3 這樣超巨大的模型擁有無與倫比的效能，但對於企業而言，推論和訓練所需的運算成本，以及使用外部 API 時對安全性與資料隱私的擔憂，已成為巨大的障礙。特別是在處理高度機密的內部資料或個人資訊的業務中，基於合規性（如 GDPR 或 APPI 等）的考量，將資料傳送至雲端上的公開 LLM API 往往是不被允許的。

因此，小型語言模型 (SLM: Small Language Models) 與在本地環境中進行區域網路運作正逐漸受到矚目。其中，「TinyLLaMA」雖然僅有 1.1B（11 億）參數的精簡大小，卻使用了約 3 兆個 Token 的龐大資料集進行預訓練，與同級別的模型相比，展現出驚人的效能。

本文將提供一份完整指南，教您如何在本地環境（本地伺服器或工作站）中，針對公司專屬任務「最快且高效」地對 TinyLLaMA 進行微調 (Fine-Tuning)。從數學背景到最新的最佳化技術，再到具體的 PyTorch 實作程式碼，我們將進行全面性的解說。

2. TinyLLaMA 的架構與特徵

TinyLLaMA 沿用了 Meta 公司開發的 LLaMA (Large Language Model Meta AI) 架構。在將參數數量控制在 1.1B 的同時，因為使用了與 LLaMA 2 相同的技術堆疊，其特徵在於生態系統的相容性非常高。

主要架構元件

RMSNorm (Root Mean Square Normalization): 省略了傳統 LayerNorm 計算中減去平均值的步驟，是一種提升了計算效率的正規化方法。在保持訓練穩定性的同時提升了吞吐量。
SwiGLU 激勵函數: 在全連接層 (Feed Forward Network, FFN) 中，採用了 SwiGLU 來取代傳統的 ReLU 或 GELU。這在數學上可表示如下： $$ \text{SwiGLU}(x, W, V) = \text{Swish}(xW) \otimes (xV) $$ 此處，$\otimes$ 表示逐元素乘積（Hadamard 乘積），而 Swish 函數為 $\text{Swish}(z) = z \cdot \sigma(\beta z)$。這大幅提升了模型的表達能力。
RoPE (Rotary Position Embedding): 結合了絕對位置編碼與相對位置編碼優點的方法。在序列長度擴展時，也具備高度的泛化能力。
Grouped Query Attention (GQA): 介於多頭注意力機制 (Multi-Head Attention, MHA) 與多查詢注意力機制 (Multi-Query Attention, MQA) 之間的方法，透過將 Key 和 Value 的注意力頭進行分組，節省了記憶體頻寬，並顯著提升了推論速度。

以下的 Mermaid 圖表展示了 TinyLLaMA 的整體資料流與 Transformer 區塊的結構。

graph TD A["輸入文字"] --> B["分詞器 (BPE)"] B --> C["嵌入層"] C --> D["Transformer 區塊 (TinyLLaMA 為 22 層)"] D --> E["RMSNorm (最終)"] E --> F["線性投影 (詞彙表大小)"] F --> G["輸出機率 (Softmax)"] subgraph "Transformer 區塊剖析" D1["輸入隱藏狀態"] --> D2["RMSNorm"] D2 --> D3["分組查詢注意力機制 (GQA)"] D3 --> D4["殘差相加"] D4 --> D5["RMSNorm"] D5 --> D6["SwiGLU 全連接層"] D6 --> D7["殘差相加"] D7 --> D8["輸出至下一層"] D1 -.-> D4 D4 -.-> D7 end

3. 微調的突破：LoRA 與 QLoRA

在本地環境中進行全參數微調，即使是 1.1B 的模型，為了保存最佳化器的狀態與梯度，也會消耗數十 GB 的 VRAM（視訊記憶體）。為了在有限的資源下有效率地進行訓練，必須使用的是 PEFT (Parameter-Efficient Fine-Tuning) 方法中的「LoRA」以及其量化擴展「QLoRA」。

3.1 LoRA (Low-Rank Adaptation) 的數學背景

LoRA 是一種將預訓練好的權重矩陣固定（凍結），並將其權重更新量（$\Delta W$）近似為兩個低秩小矩陣相乘的方法。

假設預訓練的權重為 $W_0 \in \mathbb{R}^{d \times k}$。在全參數微調中，會直接更新 $W_0$ 使其成為 $W_0 + \Delta W$，但在 LoRA 中，會將更新矩陣 $\Delta W$ 分解如下：

$$ \Delta W = B \times A $$

在此，$B \in \mathbb{R}^{d \times r}$，$A \in \mathbb{R}^{r \times k}$，而 $r$ 是稱為秩 (Rank) 的超參數，為一個滿足 $r \ll \min(d, k)$ 的極小值（通常是 8、16、32 等）。

前向傳播的計算如下所示：

$$ h = W_0 x + \Delta W x = W_0 x + B A x $$

在初始狀態下，矩陣 $A$ 會以常態分佈（高斯分佈）進行隨機初始化，而矩陣 $B$ 則會以零矩陣初始化。這樣一來，訓練開始時的 $\Delta W$ 將為零，可以從完全保留基礎模型輸出的狀態開始訓練。

graph LR X["輸入向量 x"] --> W0["凍結的預訓練權重 (W_0)"] X --> A["可訓練的 LoRA 矩陣 A (r x k)"] A --> B["可訓練的 LoRA 矩陣 B (d x r)"] W0 --> Add["向量相加"] B --> Add Add --> Y["輸出向量 h"]

3.2 QLoRA (Quantized LoRA) 的創新性

QLoRA 進一步推廣了 LoRA 的方法，將基礎模型 $W_0$ 以 4-bit 精度（NormalFloat 4, NF4）進行量化後再載入記憶體。這大幅降低了 VRAM 的消耗量。

QLoRA 整合了三個關鍵技術：

4-bit NormalFloat (NF4) 量化: 針對服從常態分佈的權重所最佳化，為理論上最佳的資料型態。
Double Quantization (雙重量化): 透過將量化常數（縮放因子）本身也進行量化，進一步節省記憶體。
Paged Optimizers: 利用 NVIDIA 的統一記憶體功能，當 VRAM 不足時，將最佳化器的狀態暫時轉移至 CPU 的 RAM 上的機制。

藉此，通常需要 16GB 至 24GB VRAM 的微調，現在即使是在消費級 GPU（如 RTX 3060 12GB 或 RTX 4070 等）上也能游刃有餘地執行。

4. 本地環境的硬體需求與設定

在使用 QLoRA 對 TinyLLaMA (1.1B) 進行微調時，硬體需求可以降得非常低。

軟體環境建置

以下為假設使用 Ubuntu 22.04 LTS 環境的設定步驟。請使用 Python 3.10 或更新版本。

1
2
3
4
5
6
7
8
9


# 建立並啟動虛擬環境
python3 -m venv tinyllama_env
source tinyllama_env/bin/activate

# 安裝 PyTorch (適用於 CUDA 12.1)
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

# 安裝 Transformer 相關函式庫
pip install transformers datasets peft trl accelerate bitsandbytes

5. 為了最快微調的最佳化技術

為了不只是執行腳本，而是「最快」完成微調，必須結合以下最佳化方法。

5.1 Flash Attention 2

標準的注意力機制對於序列長度 $N$ 來說，時間與空間複雜度為 $O(N^2)$。Flash Attention 2 透過最佳化 GPU 的 SRAM 與 HBM (High Bandwidth Memory) 之間的記憶體存取，在不增加計算量的情況下解決了 IO 瓶頸，將訓練速度提升了數倍，並大幅減少了記憶體消耗。

5.2 Gradient Checkpointing (梯度檢查點)

這是一種不將前向傳播中計算的所有中間激活值儲存在 VRAM 中，而是僅儲存一部分，並在反向傳播需要時重新計算的方法。雖然計算時間會增加約 20%，但可以大幅減少記憶體消耗量，進而可以設定更大的批次大小，最終提升整體的吞吐量。

5.3 Mixed Precision Training (混合精度訓練) 與 Bfloat16

為了最大化利用 GPU 的 Tensor Core，在訓練時的計算使用 bfloat16 (Brain Floating Point)。與 float16 相比，由於其指數部的位元長度與 float32 相同，發生上溢 (Overflow) 或下溢 (Underflow) 的風險極低，訓練會更加穩定。

6. 實作：TinyLLaMA 的 QLoRA 微調程式碼

接下來，我們將解說包含了上述所有最佳化的最快微調 PyTorch 腳本。在這裡，我們將使用 Hugging Face 的 trl (Transformer Reinforcement Learning) 函式庫中的 SFTTrainer。

6.1 資料集準備與模型載入

 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


import torch
from datasets import load_dataset
from transformers import (
 AutoModelForCausalLM,
 AutoTokenizer,
 BitsAndBytesConfig,
 TrainingArguments
)
from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training
from trl import SFTTrainer

# 1. 指定模型與分詞器
model_id = "TinyLlama/TinyLlama-1.1B-Chat-v1.0"

# 2. QLoRA 用的 4-bit 量化設定
bnb_config = BitsAndBytesConfig(
 load_in_4bit=True,
 bnb_4bit_use_double_quant=True,
 bnb_4bit_quant_type="nf4",
 bnb_4bit_compute_dtype=torch.bfloat16 # 使用 bfloat16 進行計算
)

# 3. 載入模型 (啟用 Flash Attention 2)
print("Loading model...")
model = AutoModelForCausalLM.from_pretrained(
 model_id,
 quantization_config=bnb_config,
 device_map="auto",
 use_flash_attention_2=True # 最快化的關鍵
)

# 4. 載入分詞器
tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
tokenizer.pad_token = tokenizer.eos_token
tokenizer.padding_side = "right" # 為了避免 fp16/bf16 訓練時的錯誤，設定為 right

6.2 套用 LoRA 適配器與資料集格式化

 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


# 5. k-bit 訓練的準備與啟用梯度檢查點
model.gradient_checkpointing_enable()
model = prepare_model_for_kbit_training(model)

# 6. LoRA 的設定
peft_config = LoraConfig(
 r=16, # 秩
 lora_alpha=32, # 縮放因子
 lora_dropout=0.05,
 bias="none",
 task_type="CAUSAL_LM",
 target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"] # 將所有 Linear 層設為目標可提升效能
)

model = get_peft_model(model, peft_config)
model.print_trainable_parameters()
# 輸出範例: trainable params: 14,286,848 || all params: 1,114,335,232 || trainable%: 1.282%

# 7. 載入資料集 (此處以日文 Instruction 資料集為例)
# 實際上會載入本地環境中的私有 JSONL 檔案等
dataset = load_dataset("kunishou/databricks-dolly-15k-ja", split="train")

def format_instruction(sample):
 """
 配合 ChatML 格式或提示詞模板來格式化字串
 """
 prompt = f"<|im_start|>user\n{sample['instruction']}"
 if sample.get("input", "") != "":
 prompt += f"\n{sample['input']}"
 prompt += f"<|im_end|>\n<|im_start|>assistant\n{sample['output']}<|im_end|>"
 return {"text": prompt}

dataset = dataset.map(format_instruction)

6.3 執行訓練

 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


# 8. 設定訓練參數
training_args = TrainingArguments(
 output_dir="./tinyllama-lora-output",
 per_device_train_batch_size=8, # 若 VRAM 充裕可再調高
 gradient_accumulation_steps=2, # 實質上的批次大小 = 8 * 2 = 16
 optim="paged_adamw_32bit", # 透過 Paged Optimizer 節省 VRAM
 save_steps=100,
 logging_steps=10,
 learning_rate=2e-4,
 fp16=False,
 bf16=True, # 混合精度訓練 (bfloat16)
 max_grad_norm=0.3,
 max_steps=500, # 測試用的 500 步。正式上線請改用 epoch 數指定
 warmup_ratio=0.03,
 group_by_length=True,
 lr_scheduler_type="cosine",
)

# 9. 透過 SFTTrainer 開始訓練
trainer = SFTTrainer(
 model=model,
 train_dataset=dataset,
 peft_config=peft_config,
 dataset_text_field="text",
 max_seq_length=1024, # 配合預期的輸入長度進行調整
 tokenizer=tokenizer,
 args=training_args,
)

print("Starting training...")
trainer.train()

# 10. 儲存 LoRA 適配器
trainer.model.save_pretrained("./tinyllama-lora-final")
tokenizer.save_pretrained("./tinyllama-lora-final")
print("Training complete and model saved.")

7. 效能評估與疑難排解

在本地環境執行訓練時，經常遇到的問題與解決方案。

發生 OOM (Out Of Memory):
- 將 per_device_train_batch_size 降至 1。
- 增加 gradient_accumulation_steps 以維持實質批次大小。
- 將 max_seq_length 從 2048 縮短至 1024 或 512。
Loss 無法下降或發散:
- 學習率 (learning_rate) 可能設定過高。請試著從 2e-4 降到 5e-5 左右。
- 若使用的是 Float16 而非 Bfloat16，可能發生了梯度下溢。請確認是否設定了 bf16=True。
推論時產生奇怪的字串:
- 請確認 padding_side="right" 是否設定正確。另外，必須確認資料集的格式（如 <|im_start|> 等特殊 Token）是否與基礎模型在預訓練時一致。

8. 微調後的模型部署 (Deployment)

微調完成後，儲存的並非「整個基礎模型」，而是僅有數 MB 至數十 MB 的「LoRA 適配器（差異權重）」。為了能高速進行推論，必須將此 LoRA 權重合併（整合）至原始的基礎模型中，並匯出為單一模型。

模型合併腳本

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


import torch
from peft import AutoPeftModelForCausalLM
from transformers import AutoTokenizer

output_dir = "./tinyllama-lora-final"

# 以 FP16/BF16 載入模型與適配器
model = AutoPeftModelForCausalLM.from_pretrained(
 output_dir,
 device_map="auto",
 torch_dtype=torch.bfloat16
)
tokenizer = AutoTokenizer.from_pretrained(output_dir)

# 合併權重並儲存
merged_model = model.merge_and_unload()
merged_model.save_pretrained("./tinyllama-merged", safe_serialization=True)
tokenizer.save_pretrained("./tinyllama-merged")
print("Model merged and saved successfully!")

透過 vLLM 啟動極速推論伺服器

在本地環境部署時，為了將推論速度 (Tokens per second) 最大化，強烈建議使用 vLLM 或 TGI (Text Generation Inference)，而不是 Hugging Face 標準的 pipeline。vLLM 使用了 PagedAttention 技術，可防止 GPU 記憶體碎片化，並大幅提升平行請求的處理能力。

以下的 Mermaid 圖表展示了從訓練到部署推論伺服器的管線 (Pipeline)。

graph TD A["原始私有資料"] --> B["預處理與格式化 (JSONL)"] B --> C["QLoRA 微調 (SFTTrainer)"] C --> D["LoRA 適配器權重 (.safetensors)"] D --> E["與基礎 TinyLLaMA 1.1B 合併"] E --> F["合併後的模型"] F --> G["透過 vLLM 伺服器部署"] G --> H["API 端點 / 使用者介面 (如聊天機器人)"]

使用 vLLM 啟動 API 伺服器只需以下 1 行指令即可完成。

1
2
3
4
5
6


python -m vllm.entrypoints.openai.api_server \
 --model ./tinyllama-merged \
 --host 0.0.0.0 \
 --port 8000 \
 --max-model-len 2048 \
 --dtype bfloat16

如此一來，便能在本地環境中建構與 OpenAI API 相容的端點，讓您能安全且高速地運用本地 AI。

9. 總結

本文針對參數數量僅有 1.1B、輕量卻擁有高效能的「TinyLLaMA」，解說了如何在本地環境中最快且最高效利用記憶體來進行微調的方法。

透過 LoRA / QLoRA，即使在消費級 GPU 也能進行正式的 LLM 微調。
靈活運用 Flash Attention 2 與 Gradient Checkpointing，將訓練時間與 VRAM 消耗最佳化至極限。
透過活用 vLLM 進行部署，在正式環境中也能實現高吞吐量。

在本地運作的 Local LLM，不僅能保護資料的機密性，更是能以低成本建構專注於特定領域（法務、醫療、公司內部規定等）之專業 AI 的最強武器。請務必參考本指南，試著培育出專屬於貴公司的 TinyLLaMA 吧。

AI時代的程式設計師該如何生存？

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

AI時代的程式設計師該如何生存？寫程式的終結與新工程學的開端

2026年的今天，軟體開發的現場正處於前所未有的劇變期。就在幾年前，「AI 寫程式」的概念充其量只停留在生成樣板程式碼（Boilerplate）或自動補全函式等程式設計師的「輔助工具」角色。然而，隨著大型語言模型（LLM）的驚人進化，情況發生了根本性的翻轉。現代的 AI 已不再只是個「聰明的打字機」，只要提供需求定義文件，它就能化身為「自主型初階工程師」，具備瞬間且自主地將從前端到後端邏輯、資料庫結構設計，甚至是建構 CI/CD 管線等整個系統組合起來的能力。

在這樣的時代，我們「程式設計師」或「軟體工程師」該如何生存？在「寫程式」這個行為本身的經濟價值正迅速通貨緊縮的當下，只懂得特定程式語言語法（Syntax）、熟悉特定框架 API 的「寫碼工（Coder）」，正快速地被市場淘汰。

本文將從技術、數學以及哲學的觀點，極為詳細地探討 AI 時代程式設計師的生存策略。這不僅僅是單純的職涯論，而是對軟體工程這門學問本身的重新定義。

1. 抽象化（Abstraction）的歷史與「程式設計」的重新定義

回顧軟體工程的歷史，可以發現它始終是一部「抽象化（Abstraction）」的歷史。我們一直都在建構能用更接近人類的語言，來描述更複雜系統的抽象層。

早期的計算機科學家使用打孔卡片直接操作實體硬體的開關，以機器語言（0和1的排列）向電腦下達指令。之後，組合語言出現了，讓人們可以用較易理解的助記符號（Mnemonic）來操作硬體。隨著時代進步，C 語言、Fortran 等高階語言問世，成功封裝了記憶體管理或 CPU 暫存器等硬體複雜的細節。接著出現的 Java, Python, Ruby, TypeScript 等現代語言，讓程式設計師不再需要專注於「如何讓電腦運作（How）」，而能更專注於「想讓電腦做什麼（What）」。

AI（LLM）的出現，是這段抽象化歷史中最新、也是最大的一次典範轉移。如果說程式語言的進化是「隱藏硬體」，那麼 LLM 的進化就是「隱藏語法（Syntax）」。

graph TD A["機器碼 / 打孔卡片 (1940年代)"] --> B["組合語言 (1950年代)"] B --> C["編譯型高階語言 (1970年代)"] C --> D["託管 / 腳本語言 (1990年代)"] D --> E["透過 LLM 的自然語言 (2020年代)"] E --> F["自主型 AI 代理 (2026-)"] style E fill:#f9f,stroke:#333,stroke-width:2px style F fill:#fbb,stroke:#333,stroke-width:2px

開發者需要一邊擔心記憶體流失一邊操作指標，或是為了解析 JSON 而寫幾百行樣板程式碼的時代已經結束了。使用自然語言（中文或英文）這種對人類來說抽象度最高的語言來定義系統，已成為 2026 年「程式設計」的標準。

2. 生產力的數學模型：乘上指數型成長的浪潮

讓我們用數學模型來量化評估 AI 帶來的生產力提升。傳統軟體開發中，個人的生產力 $P_{traditional}$ 可以被模型化為個人技能水準 $S$、領域經驗 $E$ 以及工具效率 $T$ 的線性組合。

$$ P_{traditional} = c_1 \cdot S + c_2 \cdot E + c_3 \cdot T $$

然而，在活用 AI 的現代開發中，AI 的能力 $A(t)$ 成為了放大人類能力的「強大槓桿（Multiplier）」。由於 AI 的能力會隨著時間 $t$ 呈指數型成長（AI 版的摩爾定律），因此 AI 時代的生產力 $P_{AI}(t)$ 可以用以下方程式來表示：

$$ P_{AI}(t) = \alpha \cdot S_{core} \cdot e^{\beta \cdot A(t)} $$

這裡的各個變數代表以下意義：

$\alpha$: 基礎的人類生產力係數
$S_{core}$: 無法被 AI 取代的「人類核心技能」（架構設計、對商業需求的理解、倫理判斷等）
$A(t)$: 時間 $t$ 時 AI 模型的絕對能力（參數數量、上下文視窗、推論能力）
$\beta$: 展現能多有效發揮 AI 工具的係數（提示工程的品質，或與 AI 協作流程的完善程度）

從這個公式推導出的一個重要洞察是，在 $A(t)$ 呈指數型增加的世界中，單純的打字速度或背誦特定語言等傳統型技能，對整體生產力的影響將變得極小。 取而代之的是，用來乘上指數型 AI 成長的係數 $\beta$，以及涵蓋 AI 無法觸及領域的 $S_{core}$，將成為決定工程師市場價值的決定性因素。

3. 任務的自動化機率（Probability of Automation）

那麼，哪些任務將被自動化，又有哪些任務會保留在人類手中呢？某個任務 $T$ 被 AI 完全自動化的機率 $P_{auto}(T)$，可以用以下公式定義：

$$ P_{auto}(T) = 1 - \exp\left(-\lambda \cdot \frac{\text{Predictability}(T)}{\text{Complexity}(T) \times \text{Context Dependency}(T)}\right) $$

$\text{Predictability}(T)$: 任務的可預測性（過去的資料中存在多少模式）
$\text{Complexity}(T)$: 任務的複雜性
$\text{Context Dependency}(T)$: 任務所依賴的「隱含上下文（領域特有知識或人際關係）」的強度
$\lambda$: AI 的技術進步率

像是撰寫 API 的路由處理、製作簡單的 CRUD 畫面等，可預測性高且上下文依賴性低的任務，$P_{auto} \approx 1$，將幾乎完全被自動化。另一方面，「如何安全地整合現有遺留系統與新的微服務」、「如何設計一個既滿足法務部門要求又不損害使用者體驗的驗證流程」這類上下文依賴性極高的任務，則難以被自動化。

4. 從語法（Syntax）回歸到架構（Architecture）

明確劃分 AI 擅長的事物與人類擅長的事物，是生存的絕對條件。

graph LR Sub1["AI 的卓越領域"] Sub2["人類的卓越領域"] A["從規格生成程式碼"] --> Sub1 B["語法錯誤與 Bug 修復"] --> Sub1 C["樣板 / 測試生成"] --> Sub1 D["日誌分析與模式匹配"] --> Sub1 E["系統架構設計"] --> Sub2 F["解決模糊的需求"] --> Sub2 G["跨團隊協商"] --> Sub2 H["倫理判斷 / 責任"] --> Sub2

AI 在「局部最佳化」方面已凌駕人類。在撰寫單一函式、單一類別或單一模組的速度和準確性上，人類毫無勝算。然而，AI 對於「全域最佳化」或「上下文缺失（Missing Context）」卻非常脆弱。

未來的程式設計師必須將角色從「寫程式的勞工」，轉變為「協調編排 AI 生成的無數元件的架構師」。俯瞰整個系統，微服務的邊界該畫在哪裡、如何配合商業語境來解決 CAP 定理中可用性與一致性的權衡、如何控制技術債。這些都是只有理解全貌與商業目標的人類才能勝任的高階智力工作。

5. 需求定義才是「真正的提示工程（Prompt Engineering）」

最近常聽到的「提示工程」一詞，往往被誤解為「欺騙 AI 以獲得預期輸出的駭客技巧」。然而，軟體開發中提示工程的本質，毫無疑問是**「高階的需求定義（Requirements Engineering）」**。

為了用自然語言對 AI 下達指令，並讓它輸出如預期的軟體，必須嚴密地將以下要素文字化：

目的（Why）: 為什麼需要這個功能？商業價值是什麼？
限制條件（Constraints）: 效能需求（延遲、吞吐量）、安全性需求、成本限制。
邊緣案例（Edge Cases）: 使用者輸入預期外內容時的回退（Fallback）處理。
介面（Interfaces）: 與現有系統的整合規格。

模糊的指令（提示）只能孕育出模糊且脆弱的系統。深入訪談「客戶真正想要的東西」、整理相互矛盾的需求，並製作出邏輯上毫無破綻的規格書（提示）的能力。這才是 AI 時代最強的「寫碼技能」。程式設計師面對的將不再是程式碼編輯器，而是 Notion 或 Markdown 檔案，花費在用文字精準描述系統應有樣貌的時間將會增加。

6. 領域知識（Domain Knowledge）的壓倒性優勢

由於 AI 已經學習了全世界的開源程式碼與公開文件，因此對一般的 Web 技術與演算法非常熟悉。然而，有些資料是 AI 無法存取的。那就是「你公司特有的商業規則」，以及「深植於特定業界（醫療、金融、製造等）的領域知識」。

舉例來說，假設某家醫療新創公司正在開發電子病歷系統。AI 知道「如何用 React 製作表格 UI」或「HL7 FHIR 的一般資料結構」。但是，它並沒有學習到「在 A 醫院的特定看診科別中，醫師以什麼順序瀏覽患者資料，以及什麼樣的 UI 才能將醫療疏失的風險降到最低」這種隱性知識。

在技術本身逐漸商品化（大眾化）的世界中，工程師的真正價值將誕生於「科技」與「商業領域」的交會處。不再只靠技術能力一決勝負，而是擁有醫療、金融、物流、娛樂等特定領域的深厚專業知識，並能使用 AI 這個強大工具來解決該領域課題的人才，將引領未來的市場。

7. 軟體開發的「電車難題」：誰來負責？

隨著對 AI 的依賴度升高，我們將面臨重大的哲學與倫理問題。也就是軟體工程中「責任歸屬」的問題。

如果 AI 自主生成的程式碼在正式環境中引發嚴重的 Bug，導致企業損失數億元，或者在攸關人命的醫療系統中發生故障，該由誰來承擔責任？是開發 AI 模型的企業嗎？還是輸入提示的工程師？我們無法將 AI「解僱」或「逮捕」。

作為承擔系統對社會造成影響之「法律與倫理責任（Accountability）」的主體，「人類」的角色無論技術如何進步都不會消失。倒不如說，程式碼生成過程越是黑箱化，人類作為系統「最終批准者（Approver）」與「監督者（Supervisor）」所背負的責任就越重。

審核 AI 提出的架構或程式碼是否符合安全標準、是否存在倫理問題（是否包含偏見）、是否遵守合規性，並給出最終的通行許可。這種「承擔責任」的行為本身，將成為工程師重要工作的一部分。

8. AI 結對程式設計與認知負荷（Cognitive Load）的管理

在與 AI 共事的過程中，人類「認知負荷（Cognitive Load）」的性質也正在改變。從零開始寫程式時的認知負荷，與「閱讀並審查」AI 生成的數百行未知程式碼時的認知負荷是完全不同的。

根據心理學的認知負荷理論，在處理不符合現有基模（腦海中的知識結構）的複雜資訊時，人類的工作記憶會很快耗盡。AI 生成的程式碼，有時包含了人類想不到的高階最佳化，但同時也可能包含無視上下文的「幻覺（Hallucination）」。

為了防止這種情況，必須將對 AI 的審查流程系統化。

sequenceDiagram participant H as "人類工程師 (架構師)" participant A as "AI 代理" participant S as "CI/CD & 測試" H->>A: "定義嚴格的需求與限制" A->>H: "提出架構與初始程式碼" Note over H,A: 審查階段：高認知負荷 H->>A: "評論設計選擇，要求重構" A->>S: "生成最終程式碼並推送" S-->>H: "自動化測試結果與靜態分析" H->>H: "最終批准與承擔責任"

人類必須將「快速閱讀，並瞬間看穿邏輯缺陷（Code Reading & Auditing）」的技能提升到極致，這甚至比「撰寫」技能更重要。測試驅動開發（TDD）的重要性在 AI 時代更加倍增。在讓 AI 寫程式之前，由人類或另一個 AI 寫出嚴謹的測試程式碼，並讓 AI 不斷修改程式碼直到通過測試，這種方法將成為主流。

9. 具體的生存策略：從明天開始該學什麼？

基於以上的分析，在此提出程式設計師在 AI 時代生存的具體行動計畫：

徹底重新學習技術的「基礎」: 框架的用法交給 AI 就好。但是，對作業系統的運作原理、網路協定（TCP/IP, HTTP/3）、資料庫的內部結構（B-Tree, 交易隔離等級）、資料結構與演算法的深入理解是絕對必要的。為了判斷 AI 的輸出是否正確，堅實的計算機科學基礎不可或缺。
精通雲端架構與分散式系統: 不要只關注個別程式碼，而是專注於如何組合 AWS, GCP, Azure 等雲端資源來建構可擴展的系統。理解 Terraform 等 IaC（Infrastructure as Code）的概念，培養將整個系統設計為程式碼的能力。
成為商業領域的專家: 深入學習自己所屬產業的商業模式、法律法規、使用者的行為心理。跨越工程師的框架，具備接近產品經理（PM）的視角。
磨練溝通與引導（Facilitation）的技巧: 解決人與人之間的「模糊性」並達成共識的過程，是 AI 無法取代的。與利害關係人對話、發現真正課題的軟實力，將成為最有價值的技能。
把 AI 當作「同事」徹底利用: 不要害怕 AI 工具的進化，而是將其作為最強大的武器來運用。在日常中頻繁使用最新的 LLM 或 AI 寫碼代理，累積「AI 在哪裡會失敗、如何調整提示才能發揮最高效能」的「隱性知識」。

結論：不要害怕，駕馭浪潮吧

AI 帶來的程式設計自動化，並不代表程式設計師這個職業的「死亡」。相反地，它是一場將我們從修復錯字、排除環境建構問題、撰寫無聊樣板程式碼等軟體開發中「非本質的勞動」解放出來的**「文藝復興」**。

歷史上，自動織布機出現時、試算表軟體（Excel）出現時，也曾蔓延著工作將會消失的悲觀論調。但現實是，隨著生產力的飛躍性提升，創造了新的需求，並誕生了更高階的工作。軟體世界也將發生同樣的事。因為「能以低廉成本打造系統」，軟體將滲透到過去因成本考量而無法資訊化的所有領域，工程師需要解決的課題（What）將無限擴張。

我們程式設計師現在正獲得一個機會，從寫程式的工匠，進化為指揮 AI 這個強大智慧的「交響樂團指揮家」。與其畏懼科技的浪潮而停留在岸邊，不如儘早駕馭這股浪潮，啟程前往創造更大、更有價值系統的旅程。AI 時代，正是真正意義上的「工程學」展開的時代。

使用C++開發小規模AI模型（如TinyLLaMA）的步驟指南

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

使用C++開發小規模AI模型（如TinyLLaMA）的步驟指南

近年來，在本地環境中執行大型語言模型（LLM）的關注度急遽上升。特別是像 TinyLLaMA（1.1B參數）這樣的小規模模型，即使在資源受限的邊緣裝置或一般筆記型電腦（包含 Windows 環境）上，也能以實用的速度進行推論。雖然使用 Python 和 PyTorch 進行開發是目前的主流，但若要追求極致的效能與記憶體節省，結合 C++ 與基於 C 語言的張量函式庫「ggml」已成為業界的標準。

本文將提供非常詳細的開發步驟，解說如何從零開始建構（或深入理解現有 llama.cpp 的內部結構）一個使用 C++ 載入 TinyLLaMA 並進行文字生成的推論引擎。

1. 為什麼選擇C++與ggml？

在 AI 的訓練階段，擁有高靈活性與豐富生態系的 Python 佔有絕對的優勢。然而，在部署與「推論（Inference）」階段，基於以下理由，C++ 成為了強大的選擇：

減少額外負擔（Overhead）: 可以完全消除 Python 的全域直譯器鎖（GIL）以及執行時期的額外負擔。
記憶體效率與 Arena 分配（Arena Allocation）: 由於可以手動控制記憶體的配置與釋放，能防止垃圾回收（Garbage Collection）所造成無法預測的效能突波。
直接存取硬體: 能夠直接呼叫 AVX-512、AVX2、ARM NEON 等 SIMD 內建函式（Intrinsics），將 CPU 的運算能力發揮到極致。
排除依賴關係: ggml 是一個零依賴（Zero dependencies）的 C/C++ 函式庫，只要有編譯器，即使在 Windows 的 MSVC 環境下也能輕鬆編譯。

2. 架構全貌

推論管線（Pipeline）整體的流程如下方 Mermaid 圖表所示。這是一連串從使用者的輸入文字開始，直到最終生成下一個 Token 的過程。

graph TD A["使用者輸入文字"] --> B["BPE 分詞器"] B --> C["Token IDs 陣列"] C --> D["嵌入層查找"] D --> E["Transformer 區塊"] E --> F["RMSNorm"] F --> G["LM Head 層"] G --> H["Logits 陣列"] H --> I["採樣模組"] I --> J["下一個 Token ID"] J --> K["反分詞器"] K --> L["輸出文字區塊"] J -.-> |"附加到上下文"| C

因為是自迴歸模型，輸出的 Token 會再次被加入到上下文中，作為預測下一個 Token 的輸入進行循環（圖中虛線部分）。

3. 模型格式與記憶體映射 (mmap)

處理巨大神經網路權重時，最大的障礙在於磁碟 I/O 與記憶體消耗。在 C++ 實作中，我們透過**記憶體映射（mmap）**來解決這個問題。

3.1 記憶體映射的機制與 Windows 上的實作

使用 mmap 可以將檔案內容直接映射到處理程序的虛擬記憶體空間中。

零拷貝（Zero-copy）: 資料會從磁碟直接讀取到核心的分頁快取（Page Cache）中，不會在使用者空間產生多餘的拷貝。
按需載入（Page Fault）: 只有在 CPU 實際存取該記憶體位址的瞬間，才會發生分頁錯誤（Page Fault），並僅將需要的區塊（通常是 4KB）載入到實體記憶體中。

在 Windows 環境中，我們使用 Win32 API 的 CreateFileMapping 和 MapViewOfFile 來取代 POSIX 的 mmap。

sequenceDiagram participant OS["Windows 作業系統"] participant RAM["實體記憶體"] participant App["C++ 應用程式"] App->>OS: "CreateFileMapping / MapViewOfFile" OS-->>App: "虛擬記憶體位址指標" App->>App: "在指標處讀取張量資料" OS->>RAM: "分頁錯誤 / 從磁碟載入分頁" RAM-->>App: "準備好進行 SIMD 運算的資料"

3.2 GGUF 格式的二進位結構

從 Hugging Face 等平台的 .safetensors 格式轉換而來的 GGUF (GPT-Generated Unified Format)，是專為推論打造的終極格式。它具有以下嚴謹的二進位佈局（Binary Layout）：

Magic Bytes: 0x46554747 (GGUF)。
Version: 格式的版本號碼。
Tensor Count & Metadata Count: 張量數量與 Metadata 的鍵值對（Key-Value Pairs）數量。
Metadata (Key-Value Pairs): 帶有字串長度前綴的鍵（Key）以及具有型別的值（Value）。
Tensor Info: 每個張量的名稱、維度數、資料型別（如 FP16, Q4_K 等），以及在檔案內的偏移位置（Offset）。
Padding: 為了讓張量資料對齊特定邊界（通常是 32 或 64 位元組）而插入的填充資料。這對於使用 SIMD 指令（特別是 AVX）進行高速記憶體存取來說不可或缺。
Tensor Data: 已經對齊的實際權重資料陣列。

4. TinyLLaMA的數學基礎與C++演算法

TinyLLaMA 為了提升效率，採用了一些進階的架構設計。以下將解說為了在 C++ 中正確實作這些設計的數學公式表示。

4.1 RMSNorm (Root Mean Square Normalization)

省略了 LayerNorm 中的平均值置中操作，僅進行變異數的縮放，藉此降低計算成本。

$$ \text{RMSNorm}(x) = \frac{x}{\sqrt{\frac{1}{d}\sum_{i=1}^{d} x_i^2 + \epsilon}} \odot \gamma $$

$d$ 是維度數，$\gamma$ 是訓練好的縮放張量。在 C++ 中實作時，首先使用 AVX2 的 _mm256_fmadd_ps 等指令高速計算陣列的平方和，再乘上反平方根（如 _mm256_rsqrt_ps 指令）來進行最佳化。

4.2 RoPE (Rotary Position Embedding)

這是一項將 Token 的位置資訊視為在張量空間中的旋轉（Rotate）並加以應用的技術。可以將其看作在複數平面上的旋轉，對於向量 $x$ 中相鄰的維度對 $(x_1, x_2)$ 套用以下的旋轉：

$$ \text{RoPE}(x, m) = \begin{pmatrix} x_{1} \cos(m\theta) - x_{2} \sin(m\theta) \\ x_{1} \sin(m\theta) + x_{2} \cos(m\theta) \end{pmatrix} $$

這裡的 $m$ 是 Token 的絕對位置索引，$\theta$ 是預先計算好的基礎頻率。在 ggml 中，只需在建構推論圖時加入 ggml_rope 運算子，就會平行執行。

4.3 Grouped-Query Attention (GQA)

在一般的多頭注意力機制（Multi-Head Attention, MHA）中，Query、Key 和 Value 各自擁有相同數量的注意力頭（Head）。然而，TinyLLaMA 為了大幅減少記憶體頻寬與 KV Cache 的消耗，採用了 Grouped-Query Attention (GQA)。

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{Q K^T}{\sqrt{d_k}}\right) V $$

在 GQA 中，多個 Query 頭會共用一個 Key/Value 頭。在 C++ 實作中，在執行矩陣乘法 ggml_mul_mat 之前，必須先執行將 KV 張量依照 Query 數量進行廣播（Broadcast）的操作。

4.4 SwiGLU 激勵函式

在前饋神經網路（Feed-Forward Network, FFN）層中，使用的是 SwiGLU 而非 GELU。

$$ \text{SwiGLU}(x) = \text{Swish}(x W_{\text{gate}}) \otimes (x W_{\text{up}}) $$ $$ \text{Swish}(z) = z \cdot \sigma(z) = z \cdot \frac{1}{1 + e^{-z}} $$

在計算圖中，會結合使用 ggml_silu 運算子與 ggml_mul 來表現。

5. 使用ggml建構計算圖與記憶體管理

ggml 採用「Define-and-Run」的方法，也就是先為推論建構靜態的計算圖，之後再對其進行評估（Evaluate）。

5.1 ggml_context 與 Arena Allocator

ggml 最獨特的一點在於「Arena Allocation」，它在推論迴圈內完全不進行動態的記憶體配置（如 malloc 或 new）。在初始化時，會先保留一塊巨大的連續記憶體區域（Arena），每當呼叫 ggml_new_tensor 等函式時，這塊區域的指標就會遞增。當推論的一個步驟完成後，只需將配置指標重設回初始位置，就能立即完成下一個推論步驟的記憶體配置準備。

5.2 計算圖建構的具體範例

在每個推論步驟中，都會在記憶體上組合出如下的計算圖。

graph TD A["Tokens 輸入 ID"] --> B["嵌入層查找"] B --> C["ggml_rms_norm"] C --> D["Q / K / V 投影"] D --> E["ggml_rope 位置編碼"] E --> F["儲存 KV Cache"] E --> G["載入 KV Cache"] G --> H["自注意力機制"] H --> I["縮放與 Softmax"] I --> J["注意力輸出"] J --> K["輸出投影"] K --> L["添加殘差"]

6. 量子化 (Quantization) 與 Windows / SIMD 最佳化

若以 FP16 來處理 TinyLLaMA (1.1B)，大約需要 2.2GB 的記憶體，但透過 4 位元量子化（如 Q4_K），可以大幅壓縮至約 600MB 左右。

6.1 區塊量子化架構

ggml 並非將整個張量統一進行量子化，而是以「區塊（Block）」為單位進行。在 Q4_0 格式中，會將 32 個 FP16 數值組成一個區塊。

縮放因子 (Scale Factor): 1 個 FP16 數值（2 位元組）
量子化資料: 32 個 4 位元數值（16 位元組）藉此能將局部異常值（Outlier）的影響降到最低。

6.2 利用 AVX2 加速內積計算

在針對 Windows 環境中最新的 x86 CPU 進行編譯時，可以善用 /arch:AVX2 等編譯器旗標，並透過以下流程進行 SIMD 處理：

載入 (Load): 從記憶體將 4 位元量子化資料載入至 256 位元的 AVX 暫存器中。
展開與解包 (Unpack): 利用位元遮罩（Bitmask）與移位運算，將 4 位元數值展開為 Int8 或 Int16。
反量子化 (Dequantize): 乘上縮放因子將其轉換為浮點數。
FMA 運算: 將結果與激勵值（Activation）使用 _mm256_fmadd_ps (Fused Multiply-Add) 平行執行乘加運算。

7. KV Cache的實作細節

在自迴歸生成中，為了省略過去 Token 的 Key 和 Value 計算，「KV Cache」是不可或缺的功能。

在 C++ 中實作的重點如下：

預先配置張量: 初始化一個對應最大上下文長度（例如：2048 Tokens）的巨大張量作為 KV Cache（建議使用 FP16）。
偏移拷貝 (Offset Copy): 當對位置 $N$ 的 Token 進行計算後，將該步驟得到的 K 和 V 向量，使用 ggml_cpy 等方式儲存到 KV Cache 張量的第 $N$ 列中。
注意力機制時建立視圖 (View): 在計算注意力時，建立一個只指向第 0 到第 $N$ 個 Token 部分的「視圖」，並將其傳遞給矩陣乘法操作。

8. BPE Tokenizer 與解碼

將輸入字串視為 UTF-8 位元組序列，並與預先定義好的詞彙表（Vocabulary）進行比對。在 C++ 中，為了加速詞彙表的搜尋，通常會實作 Trie 樹（前綴樹） 或使用優先權佇列（Priority Queue）的演算法。

從 LM Head 輸出的 Logits 中，會使用 Temperature 參數來縮放機率，再透過 Top-K 提取或 Top-P（Nucleus Sampling）方法來縮小候選範圍，最後使用亂數來決定最終的下一個 Token。

9. 建立C++專案（Windows / PowerShell 環境）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


cmake_minimum_required(VERSION 3.14)
project(TinyLLaMACpp)

set(CMAKE_CXX_STANDARD 17)

# 針對 Windows (MSVC) 的最佳化與 AVX2 旗標設定
if(MSVC)
 add_compile_options(/O2 /arch:AVX2 /fp:fast)
 add_link_options(/STACK:8388608)
else()
 add_compile_options(-O3 -march=native -ffast-math)
endif()

add_library(ggml OBJECT ggml/ggml.c ggml/ggml-alloc.c)
target_compile_definitions(ggml PRIVATE GGML_USE_AVX2 GGML_USE_F16C GGML_USE_FMA)

add_executable(main main.cpp)
target_link_libraries(main ggml)

PowerShell 中的編譯指令範例：

1
2
3
4


mkdir build
cd build
cmake .. -G "Visual Studio 17 2022" -A x64
cmake --build . --config Release

10. 總結

使用 C++ 與 ggml 從零開始實作如 TinyLLaMA 這類小規模 AI 模型的推論引擎，是揭開深度學習黑盒子、並學習低階硬體控制之美的絕佳機會。讓我們一邊充分體會利用記憶體映射進行的零拷貝載入、SIMD 最佳化、建構 KV Cache 等系統程式設計的精髓，一邊開拓邊緣 AI（Edge AI）的未來吧。

【RAG 實作入門】讓本機 AI 讀取自己文件的教學

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

前言

近年來，大型語言模型（LLM）的進化令人矚目，以 ChatGPT 和 Claude 為首的許多 AI 已經滲透到我們的生活和業務中。然而，一般的 LLM 存在著明顯的弱點。那就是它們只知道「訓練時的公開資訊」。對於公司內部規定、個人筆記、未公開的專案資料等「私有文件」相關的提問，它們自然無法回答。如果硬要它們回答，就會增加產生與事實不符、似是而非的謊言（幻覺，Hallucination）的風險。

因此，目前在世界各地爆發性普及的技術架構就是 RAG（Retrieval-Augmented Generation，檢索增強生成）。透過使用 RAG，可以從外部資料庫動態地提供專有知識給 LLM，讓它能基於這些知識產生準確且有根據的回答。

此外，在處理企業領域或個人機密資訊時，將資料傳送到 OpenAI 等雲端 API 在資安政策上通常是不被允許的。這時就需要結合本機 AI（在自己的電腦或地端伺服器上獨立運作的 LLM）來建構「本機 RAG（Local RAG）」。

本文將從 RAG 的基礎理論開始，徹底解說使用 Python 實作本機 RAG 的具體方法、數學背景（向量檢索的原理），以及讓系統上線運作的進階技巧。

1. RAG 的整體架構

RAG 並非單一的 AI 模型，而是多個元件協同運作的系統架構。大致可分為「攝取（資料匯入）階段」與「檢索與生成階段」兩個部分。

以下的 Mermaid 圖表展示了 RAG 系統的整體樣貌。

graph TD subgraph "攝取階段 (事前準備)" Doc["專屬文件 (PDF, TXT 等)"] --> Loader["文件載入器"] Loader --> Splitter["文字分割 (分塊)"] Splitter --> EmbedModel1["嵌入模型 (Embedding)"] EmbedModel1 --> VectorDB["向量資料庫"] end subgraph "推論階段 (使用者提問時)" User["使用者的問題 (查詢)"] --> EmbedModel2["嵌入模型 (Embedding)"] EmbedModel2 --> QueryVector["查詢向量"] QueryVector --> Search["相似度檢索 (向量檢索)"] VectorDB --> Search Search --> Context["相關分塊擷取 (上下文)"] User --> PromptBuilder["提示詞建構"] Context --> PromptBuilder PromptBuilder --> LocalLLM["本機 LLM"] LocalLLM --> Answer["最終回答生成"] end

攝取階段（事前準備）

讀取文件：讀取 PDF、Word、純文字檔等非結構化資料。
分塊（文字分割）：為了符合 LLM 的輸入限制（上下文視窗大小）並提高檢索精準度，將長篇文章分割成有意義的區塊（Chunk）。
嵌入（向量化）：將分割後的區塊輸入至嵌入模型（Embedding Model），轉換成數百到數千維的數值陣列（向量）。
儲存至資料庫：將轉換後的向量與原始文字資料關聯起來，儲存到向量資料庫（Vector DB）中。

推論階段（執行時）

查詢向量化：使用與事前準備相同的嵌入模型，將使用者提出的問題進行向量化。
相似度檢索：在查詢向量與資料庫中的文件向量之間進行相似度計算，取得在語意上最接近（關聯性最高）的前幾筆文字區塊。
建構提示詞：將取得的相關文字作為「上下文（背景知識）」與使用者的問題結合，建立提供給 LLM 的輸入提示詞。
生成回答：接收到擴充提示詞的 LLM，根據附加的上下文資訊生成回答。

2. 深入理解向量檢索與嵌入（Embeddings）

RAG 的核心在於「向量檢索（語意檢索）」。傳統的關鍵字檢索（如 BM25）是基於單詞的完全比對或出現頻率，而向量檢索則是基於「語意的相似性」。例如，「狗」與「小狗」、「PC」與「個人電腦」，即使單字不同，只要語意相近就能被檢索出來。

什麼是嵌入模型（Embedding Model）？

嵌入模型是一種神經網路，它接收自然語言的文字作為輸入，並輸出固定長度的密集向量（Dense Vector）。常見的模型（例如 text-embedding-3-small 或開源的 multilingual-e5-large）會將文字對映到 384 維或 1024 維的實數向量。

在這個多維空間（潛在空間）中，語意越相似的句子，在座標空間上的距離就越近。

相似度計算的數學背景：餘弦相似度

當向量資料庫在檢索相關文件時，最常使用的距離指標是餘弦相似度（Cosine Similarity）。與歐幾里得距離（空間上的絕對距離）不同，餘弦相似度關注的是「兩個向量之間的夾角」。因為它較不易受文章長度（向量的範數）影響，所以非常適合用於文字的相似度計算。

用數學公式表示的話，向量 $\mathbf{A}$ 和 $\mathbf{B}$ 的餘弦相似度如下：

$$ \text{Cosine Similarity}(\mathbf{A}, \mathbf{B}) = \cos(\theta) = \frac{\mathbf{A} \cdot \mathbf{B}}{\|\mathbf{A}\| \|\mathbf{B}\|} = \frac{\sum_{i=1}^{n} A_i B_i}{\sqrt{\sum_{i=1}^{n} A_i^2} \sqrt{\sum_{i=1}^{n} B_i^2}} $$

$\mathbf{A} \cdot \mathbf{B}$ 代表內積（Dot Product）。
$\|\mathbf{A}\|$ 代表向量 $\mathbf{A}$ 的 L2 範數（長度）。
$n$ 是向量的維度數。

餘弦相似度的值介於 -1 到 1 之間。

接近 1：兩個向量的方向幾乎相同（語意非常相似）。
接近 0：兩個向量互相垂直（毫無關聯）。
接近 -1：兩個向量的方向完全相反（語意相反）。

最近的向量資料庫（Chroma、FAISS、Qdrant 等）採用了被稱為 HNSW（Hierarchical Navigable Small World）的近似最近鄰搜尋（ANN）演算法，經過最佳化後，即使從數百萬筆向量資料中，也能在毫秒級別內檢索出餘弦相似度高的文件。

3. 建構本機 RAG 的技術堆疊

為了建構完全不依賴雲端的本機 RAG，我們將活用開源生態系統。以下介紹推薦的技術堆疊。

語言模型 (LLM)
- 工具：Ollama 或 Llama.cpp
- 模型：Llama-3-8B-Instruct、Gemma-2-9B-It、Qwen2-7B-Instruct 等輕量且高效能的開源模型。針對日文任務，適合使用經過日文微調的 Llama-3-ELYZA-JP-8B 等。
嵌入模型 (Embedding)
- 模型：intfloat/multilingual-e5-large 或 BAAI/bge-m3。若要在本機執行，通常會從 Hugging Face 下載並透過 Sentence-Transformers 執行。
向量資料庫 (Vector DB)
- ChromaDB：基於 Python，設定極為簡單。最適合用於本機開發。
- FAISS：Meta 開發的高速向量檢索函式庫。
- Qdrant / Milvus：適用於更大規模且正式的生產環境。
編排框架 (Orchestration Framework)
- LangChain：用於串聯各個元件（Chain）的業界標準。
- LlamaIndex：特別專注於 RAG 的資料連接框架。

這次我們將使用最容易導入的組合：LangChain + ChromaDB + Ollama + HuggingFaceEmbeddings 來進行實作。

4. 實作教學：使用 Python 建構完整的本機 RAG

接下來，我們將實際撰寫 Python 程式碼來建構本機 RAG。請先在電腦上安裝 Ollama 並讓它在背景執行。同時，請先在 Ollama 上拉取（pull）好模型（例如：ollama run llama3）。

Step 1: 安裝必要的函式庫

1
2


pip install langchain langchain-community langchain-huggingface
pip install chromadb sentence-transformers pypdf

Step 2: 實作程式碼全貌

以下是讀取 PDF 檔案、將其向量化並讓本機 LLM 進行問答的完整 Python 腳本。

 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


import os
from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_huggingface import HuggingFaceEmbeddings
from langchain_community.vectorstores import Chroma
from langchain_community.llms import Ollama
from langchain_core.prompts import PromptTemplate
from langchain.chains import RetrievalQA

def main():
 # 1. 讀取文件
 print("正在讀取文件...")
 # 指定要讀取的 PDF 路徑
 file_path = "sample_company_policy.pdf"
 loader = PyPDFLoader(file_path)
 documents = loader.load()

 # 2. 文字分割（Text Splitting）
 # 為了不破壞文章語意，分割成適當的大小
 text_splitter = RecursiveCharacterTextSplitter(
 chunk_size=500, # 每個分塊的最大字元數
 chunk_overlap=50, # 前後分塊的重疊字元數（防止上下文斷層）
 separators=["\n\n", "\n", "。", "、", " ", ""]
 )
 chunks = text_splitter.split_documents(documents)
 print(f"已分割成 {len(chunks)} 個分塊。")

 # 3. 初始化嵌入模型 (Local HuggingFace Model)
 # 使用對日文等支援度高的多語系模型
 print("正在載入嵌入模型...")
 embeddings = HuggingFaceEmbeddings(
 model_name="intfloat/multilingual-e5-large",
 model_kwargs={'device': 'cpu'} # 若有 GPU 可改為 'cuda' 或 'mps'
 )

 # 4. 建構向量資料庫 (Chroma)
 print("正在建構向量資料庫...")
 persist_directory = "./chroma_db"
 vectorstore = Chroma.from_documents(
 documents=chunks,
 embedding=embeddings,
 persist_directory=persist_directory
 )
 # 建立檢索器（Retriever）。設定為取得前 3 筆關聯文件
 retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

 # 5. 初始化本機 LLM (Ollama)
 print("正在連接至本機 LLM...")
 # 請先透過 'ollama pull llama3' 等指令取得模型
 llm = Ollama(model="llama3")

 # 6. 定義提示詞模板
 prompt_template = """你是一位精通公司規定與內部資訊的優秀助理。
請「僅」使用以下的上下文（背景資訊），詳細回答使用者的問題。
如果從上下文中找不到答案，請誠實地回答「從提供的資訊中無法得知」，不要隨意猜測。

【上下文】
{context}

【問題】
{question}

【回答】:
"""
 PROMPT = PromptTemplate(
 template=prompt_template,
 input_variables=["context", "question"]
 )

 # 7. 建構 RAG Chain
 qa_chain = RetrievalQA.from_chain_type(
 llm=llm,
 chain_type="stuff",
 retriever=retriever,
 return_source_documents=True, # 設定是否回傳資訊來源
 chain_type_kwargs={"prompt": PROMPT}
 )

 # 8. 執行提問
 query = "請告訴我關於遠端工作時的交通費補助條件。"
 print(f"\n問題: {query}\n")

 result = qa_chain.invoke({"query": query})

 print("【回答】")
 print(result['result'])
 print("\n---")
 print("【參考的資訊來源】")
 for doc in result['source_documents']:
 print(f"- 第 {doc.metadata.get('page', '未知')} 頁: {doc.page_content[:50]}...")

if __name__ == "__main__":
 main()

程式碼重點解說

RecursiveCharacterTextSplitter: 這是處理自然語言分割時最被推薦的分割器。它會依序嘗試段落 (\n\n)、換行 (\n)、句號 (。) 進行分割，盡可能在維持語意完整性的情況下，將文字分割至指定的 chunk_size 內。透過設定 chunk_overlap，可以防止上下文的交界處被截斷而流失資訊。
HuggingFaceEmbeddings: intfloat/multilingual-e5-large 是一個支援多國語言、非常強大的開源嵌入模型。不需要使用雲端 API（如 OpenAI 的 text-embedding-ada-002 等），即可在離線狀態下於本機記憶體中將文字向量化。
ChromaDB: 因為它是在記憶體內或本機儲存空間（基於 SQLite）中運作，所以不需要架設複雜的資料庫伺服器。透過指定 persist_directory，可以在下次執行時跳過向量化的過程，直接從磁碟讀取資料庫。

5. 進階 RAG 技巧（Advanced RAG Techniques）

雖然上述教學中建構的基礎 RAG 系統（Naive RAG）也能運作，但若在生產環境中要求較高的回答準確度，就需要導入以下進階技巧。

5.1 混合檢索 (Hybrid Search)

向量檢索雖然擅長捕捉「語意」，但有時卻不擅長處理「特定的專有名詞」、「產品型號」、「員工 ID」等精確的關鍵字檢索。因此，可以將基於向量檢索的語意檢索與使用 BM25 演算法的關鍵字檢索平行執行，再將兩者的結果進行評分與整合（例如使用 Reciprocal Rank Fusion; RRF 等技術），如此一來能大幅減少漏檢的情況。

5.2 重新排序 (Re-ranking)

向量檢索速度很快，但它並不一定能準確評估上下文的語意適合度。為了提升檢索準確度，一般的流程如下：

初步檢索 (First-stage Retrieval)：從向量資料庫中，廣泛且初步地取得約 20 到 30 筆相關分塊。
重新評估 (Re-ranking)：使用另一個較為笨重、被稱為 Cross-Encoder 的機器學習模型（例如：bge-reranker 等），輸入使用者查詢與取得的分塊配對，重新計算語意適合度的分數。
篩選：僅挑選分數最高的前 3 到 5 筆作為最終的上下文，傳遞給 LLM 的提示詞。

透過這種方法，可以防止無關的雜訊資訊傳入 LLM，大幅提升回答的精準度（Precision）。

graph LR Query["查詢"] --> VSearch["向量檢索 (前 20 筆)"] VSearch --> Reranker["重排模型 (Cross-Encoder)"] Query --> Reranker Reranker --> TopK["高精準度的前 3 筆"] TopK --> LLM["LLM 生成"]

5.3 語意分塊與父文件檢索

還有一種被稱為「語意分塊 (Semantic Chunking)」的技術，不是根據固定的字元數死板地分割文字，而是由 AI 偵測文章語意的轉折點來進行分割。此外，「父文件檢索 (Parent Document Retriever)」技術則是為了檢索而將文字切割成非常小的單位（如句子等）以實現高精準度的檢索，但在提供給 LLM 時，則是將包含該句子的「原始大段落（父文件）」交給 LLM，藉此提供充足的上下文背景。

6. 運作本機 RAG 時的挑戰與對策

在本地環境建構並維運 RAG 時，會面臨一些特有的挑戰。

VRAM（顯示卡記憶體）耗盡：若要讓本機 LLM 以實用的速度（每秒數十個 Token）運作，必須將模型載入 GPU 的 VRAM 中。要以 fp16（16 位元浮點數）執行 8B 等級的模型大約需要 16GB 的 VRAM。但透過**量化（Quantization）**技術（例如 GGUF 或 AWQ 格式，將其壓縮至 4bit 或 8bit 等），即使是 8GB 的 VRAM（如一般的電競電腦等）也能以足夠快的速度運作。Llama.cpp 或 Ollama 預設都有支援這些量化格式。
上下文視窗的限制：如果檢索後取得的上下文數量過多，可能會超過 LLM 的輸入上限（Token 限制），或者模型會忘記資訊中間部分的內容（Lost in the middle 現象）。因此，調整提取的分塊數量，以及導入前述的重新排序（Re-ranking）技術進行嚴格篩選是不可或缺的。
資料的新鮮度管理：當來源文件被更新時，必須同步更新或刪除（CRUD 操作）向量資料庫中相對應的向量資料。因為 ChromaDB 支援基於文件 ID 的更新操作，所以管理檔案的雜湊值（Hash），並撰寫批次處理程式來僅同步差異部分是比較實用的做法。

總結

RAG（檢索增強生成）是一個強大的典範轉移，它能將 AI 從一般的通用助理進化為「你的專屬專家」或「專精於公司內部業務的達人」。

我們了解到，即使在無法使用雲端服務、具有高度機密性要求的情況下，透過組合 Ollama、LangChain、ChromaDB 等開源生態系統，也能相對容易地建構出完整的「本機 RAG」環境。

請務必以上述解說的向量空間數學基礎，以及文字分割、重新排序等進階方法為基礎，嘗試使用您擁有的資料來開發專屬的 AI 系統。本機 AI 的進化速度非常驚人，您今天所建構的系統，只需在明天換上更聰明的輕量級模型，就能在瞬間提升效能。

本部落格未來也會繼續發布關於 AI 技術與 RAG 的深入探討文章。如果您有任何問題或回饋，歡迎在留言區告訴我們。

ChatGPT・Gemini・Claude API徹底比較！該如何選擇？

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

ChatGPT・Gemini・Claude API徹底比較！該如何選擇？

AI技術的發展日新月異，特別是在大型語言模型（LLM: Large Language Model）領域，OpenAI的ChatGPT（GPT系列）、Google的Gemini，以及Anthropic的Claude正展開激烈的三足鼎立之爭。2026年的今天，各家公司以數月甚至數週為單位推出新的模型與API功能，對於開發者及企業IT架構師而言，「該將哪個API整合到產品中」的問題，已成為左右專案成功與否的極關鍵決策。

本文將針對這三大AI供應商的API，不僅列舉規格，更從開發者視角，深入比較與解說架構設計、詳細的計費結構、延遲（Latency）的數學分析、使用Python與Node.js的具體實作範例，乃至於提示快取（Prompt Caching）等最新的成本最佳化手法。

期盼本文能成為讀者的完整指南，協助您為自身的使用案例挑選出最合適的LLM API，並建構出具備可擴展性且符合成本效益的AI應用程式。

1. 各LLM API的哲學與設計理念

在技術選型時，首先了解各家公司是以何種理念來建構模型與API，是非常重要的。

1.1 OpenAI (ChatGPT)

OpenAI以「實現通用人工智慧（AGI）」為使命，始終引領著業界的實質標準（De facto standard）。提供GPT-4o、GPT-4o-mini，以及專注於推論的o1模型等，滿足多樣使用案例的模型。其生態系統最為成熟，無論是官方或非官方的函式庫與文件都最為豐富。

1.2 Google (Gemini)

Google秉持「AI First」，以將自家基礎設施（TPU網路）發揮到極致的可擴展性為武器。Gemini 1.5 Pro/Flash最大特色在於擁有高達200萬個Token的壓倒性上下文長度（Context Window），能一次處理長篇文件或數小時的影片、音訊。與Google Cloud (Vertex AI)的強大整合能力，對企業而言也極具吸引力。

1.3 Anthropic (Claude)

Anthropic是由前OpenAI成員所創立的企業，採用獨特的「合憲AI（Constitutional AI）」安全性途徑。Claude 3.5 Sonnet與Opus以其高度的推論能力、程式碼生成能力，以及最重要的是「如同人類般自然的對話」與「極少的幻覺（Hallucination）」，獲得了許多開發者的狂熱支持。

2. 模型家族規格徹底比較

比較2026年目前的主力模型規格。

供應商	主力模型	最大上下文長度	主要優勢	推薦使用案例
OpenAI	GPT-4o	128K	速度、視覺辨識、語音支援	互動式應用程式、通用任務
OpenAI	o1-preview	128K	高階邏輯推論、數學、程式設計	複雜演算法生成、研究用途
Google	Gemini 1.5 Pro	2,000K	超長文處理、多模態（影片・語音）	巨大程式碼庫分析、影片摘要
Google	Gemini 1.5 Flash	2,000K	低延遲、高吞吐量、壓倒性的低成本	即時處理、大量資料批次處理
Anthropic	Claude 3.5 Sonnet	200K	程式設計能力、自然的文章生成	軟體開發輔助、高階客服支援
Anthropic	Claude 3.5 Haiku	200K	超高速回應、高性價比	邊緣AI、即時聊天機器人

3. 深入探討架構：API請求的幕後運作

當我們呼叫LLM的API時，後端到底進行了什麼樣的處理？為最佳化效能，我們必須理解此架構。

以下的Mermaid圖表展示了從用戶端發送API請求，到以串流（Streaming）方式返回Token的整體流程。

graph TD A["用戶端應用程式"] -->|HTTP/REST or gRPC| B["API閘道器"] B --> C["負載平衡器"] C --> D["推論叢集"] D --> E["分詞器 (BPE / SentencePiece)"] E --> F["KV快取與注意力機制"] F --> G["Transformer區塊 (前向傳遞)"] G --> H["輸出層 (Logits)"] H --> I["採樣器 (Temperature, Top-p, Top-k)"] I --> J["反分詞器"] J -->|串流回應 (區塊)| A

3.1 Tokenization（分詞）演算法

輸入API的文字會在內部被分割為稱為「Token」的單位。

OpenAI (tiktoken): 採用Byte-Pair Encoding (BPE)。特別是在英文方面能極高效率地壓縮，但在日文或中文等非字母語言中，Token數量往往會暴增。
Google (Gemini): 採用SentencePiece（Unigram Language Model）。對多語言支援度高，即便是日文或中文文字，也傾向於能以較少的Token數來表示。
Anthropic (Claude): 使用客製化版本的BPE。強化了多語言支援，Claude 3之後日文與中文的Token效率也有了大幅改善。

4. 延遲與效能的數學分析

在即時應用程式中，延遲（Latency）直接關係到使用者體驗（UX）。LLM API的延遲 $T_{total}$ 可在數學上建立如下模型：

$$ T_{total} = T_{network} + T_{TTFT} + (N \times T_{TPOT}) $$

此處各變數的含義如下：

$T_{network}$: 網路的來回通訊時間（RTT）。
$T_{TTFT}$ (Time To First Token): 生成第一個字元所需的時間。很大程度上取決於與提示詞長度（輸入Token數）平方成正比的注意力（Attention）運算成本。
$N$: 輸出的Token總數。
$T_{TPOT}$ (Time Per Output Token): 生成單一Token所需的時間。由於是自迴歸（Autoregressive）模型，會依賴先前的輸出進行串行運算。

4.1 自注意力機制的運算複雜度

Transformer架構中的自注意力（Self-Attention）運算複雜度，會相對於輸入序列長度 $L$ 呈二次函數增長。

$$ \text{Complexity} = O(L^2 \cdot d) $$

此處 $d$ 為嵌入向量（Embedding Vector）的維度數。受限於此，通常提示詞一旦變長，$T_{TTFT}$ 就會急遽惡化。然而，Google的Gemini 1.5採用了「Ring Attention」與「Block-wise Compute」等創新最佳化架構，即便輸入高達200萬Token的長文，也成功將生成第一個Token的時間控制在合理範圍（數秒至數十秒）內。

5. 計費體系與成本最佳化策略

API的成本基本上是根據輸入Token數與輸出Token數來計算的。

$$ Cost = (Tokens_{in} \times Rate_{in}) + (Tokens_{out} \times Rate_{out}) $$

不過，最新的API導入了能大幅降低成本的新機制。

5.1 提示快取 (Prompt Caching)

每次發送龐大的系統提示詞，或是透過RAG搜尋出的大量文件，都會耗費極大成本。為解決此問題，各家公司提供了快取功能。

在Anthropic（Claude）與Google（Gemini）中，透過快取特定文字區塊，能大幅降低（最高90%）輸入成本。

使用快取時的成本模型如下：

$$ Cost_{cached} = (Tokens_{cache\_write} \times Rate_{cache\_write}) + (Tokens_{cache\_read} \times Rate_{cache\_read}) + (Tokens_{out} \times Rate_{out}) $$

此處的 $Rate_{cache\_read}$ 約被設定為一般 $Rate_{in}$ 的10%〜25%。因此，我們能夠以低廉的成本維運聊天機器人，同時讓其常駐數萬行程式碼作為背景知識。

5.2 批次API (Batch API)

針對不需即時性的任務（如日誌分析、大量資料分類等），OpenAI與Anthropic提供了批次API。透過將請求打包發送，並在24小時內接收結果，便可以一般API費用的半價（50%折扣）使用此強大機制。

6. 開發者體驗（DX）與SDK比較

從開發效率的觀點，比較各家提供的SDK（Software Development Kit）。

6.1 OpenAI API

最被廣泛使用，對第三方函式庫（如LangChain, LlamaIndex等）的支援也最快。此外，透過結構化輸出（Structured Outputs）功能，保證回傳100%符合JSON Schema的結果，讓系統整合變得非常容易。

6.2 Anthropic API (Claude)

SDK介面設計洗鍊，其TypeScript的型別定義等受到極佳評價，非常易於操作。特別是Message API的結構直觀，包含多張圖片的多模態請求也能簡單撰寫。

6.3 Google Gemini API

分為透過Google Cloud Vertex AI存取，以及透過AI Studio存取（Google Gen AI SDK）兩種方式，初學者可能會稍微感到混亂。然而，面向企業的Vertex AI SDK與GCP的IAM（身分與存取權管理系統）完全整合，能建構極為安全的開發環境。

7. 實戰！使用Python實作多API整合測試

在此，我們將使用Python，同時向OpenAI、Anthropic、Gemini三個API發送非同步請求，並實作一個比較延遲的腳本。

 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


import asyncio
import time
import os
from openai import AsyncOpenAI
from anthropic import AsyncAnthropic
import google.generativeai as genai

# 初始化客戶端
openai_client = AsyncOpenAI(api_key=os.environ.get("OPENAI_API_KEY"))
anthropic_client = AsyncAnthropic(api_key=os.environ.get("ANTHROPIC_API_KEY"))
genai.configure(api_key=os.environ.get("GEMINI_API_KEY"))

prompt = "請針對量子電腦的基礎，以及它對現今密碼學技術帶來的影響，為初學者進行淺顯易懂的解說。"

async def fetch_openai():
 start_time = time.time()
 response = await openai_client.chat.completions.create(
 model="gpt-4o",
 messages=[{"role": "user", "content": prompt}],
 max_tokens=1024
 )
 elapsed = time.time() - start_time
 return "OpenAI (GPT-4o)", elapsed, response.choices[0].message.content

async def fetch_anthropic():
 start_time = time.time()
 response = await anthropic_client.messages.create(
 model="claude-3-5-sonnet-20240620",
 messages=[{"role": "user", "content": prompt}],
 max_tokens=1024
 )
 elapsed = time.time() - start_time
 return "Anthropic (Claude 3.5 Sonnet)", elapsed, response.content[0].text

async def fetch_gemini():
 start_time = time.time()
 model = genai.GenerativeModel('gemini-1.5-pro')
 # 使用Gemini Python SDK的非同步方法
 response = await model.generate_content_async(prompt)
 elapsed = time.time() - start_time
 return "Google (Gemini 1.5 Pro)", elapsed, response.text

async def main():
 print("正在向各LLM API發送請求...")

 # 平行執行三個API
 results = await asyncio.gather(
 fetch_openai(),
 fetch_anthropic(),
 fetch_gemini()
 )

 for provider, latency, text in results:
 print(f"--- {provider} ---")
 print(f"Latency: {latency:.2f} seconds")
 print(f"Response (Excerpt): {text[:100]}...\n")

if __name__ == "__main__":
 asyncio.run(main())

執行此腳本，即可輕鬆測量出在實際網路環境中，哪個模型能以最快速度（最小化$T_{total}$）做出回應。

8. 使用Node.js實作工具呼叫 (Tool Calling)

為了讓LLM不僅僅是聊天機器人，而是能與外部系統串聯的「AI代理（AI Agent）」，工具呼叫（Tool Calling或Function Calling）是不可或缺的。以下是使用Node.js（TypeScript）讓OpenAI API呼叫天氣API的範例。

 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


import OpenAI from "openai";

const openai = new OpenAI({
 apiKey: process.env.OPENAI_API_KEY,
});

async function runAgent() {
 const tools = [
 {
 type: "function",
 function: {
 name: "get_weather",
 description: "取得指定城市的目前天氣。",
 parameters: {
 type: "object",
 properties: {
 location: {
 type: "string",
 description: "城市名稱（例如: 東京, 紐約）",
 },
 },
 required: ["location"],
 },
 },
 },
 ];

 const response = await openai.chat.completions.create({
 model: "gpt-4o",
 messages: [{ role: "user", "content": "今天東京天氣如何？需要帶傘嗎？" }],
 tools: tools,
 tool_choice: "auto",
 });

 const message = response.choices[0].message;

 if (message.tool_calls) {
 const toolCall = message.tool_calls[0];
 console.log(`LLM要求呼叫工具: 函式名稱 = ${toolCall.function.name}`);

 const args = JSON.parse(toolCall.function.arguments);
 console.log(`參數: ${args.location}`);

 // 在此實作呼叫實際天氣API（例如: OpenWeatherMap）的處理
 // const weather = await fetchWeatherFromAPI(args.location);

 // 將取得的結果再次傳遞給LLM以生成最終回答
 }
}

runAgent().catch(console.error);

Claude 3.5 Sonnet與Gemini 1.5 Pro也具備同等的工具呼叫功能，儘管在Schema定義方式上有些微差異，但基本流程是共通的。

9. RAG vs Long Context Window：該採用哪一種？

目前在企業AI架構中，最大的爭論之一就是「為了匯入外部知識，該使用RAG（檢索增強生成），還是直接全部丟進巨大的上下文長度（Long Context）中？」。

RAG (Retrieval-Augmented Generation) 的優勢與挑戰

優勢: 成本低（僅將需要的區塊放入提示詞中）、容易鎖定回答的根據（來源）。
挑戰: 依賴語意搜尋的準確度，因此不適合上下文散落在多份文件中的高階推論任務（例如：「請根據去年所有會議紀錄，按時間軸分析A專案延遲的根本原因」）。

Long Context (如Gemini 1.5 Pro的200萬Token)

優勢: 沒有因為搜尋而遺漏資訊的風險。在「大海撈針（Needle In A Haystack: NIAH）」測試中，Gemini 1.5 Pro或Claude 3.5 Sonnet都能以99%以上的準確率萃取出資訊。
挑戰: Token消耗量龐大導致成本增加、延遲（$T_{TTFT}$）增加。

結論: 2026年的最佳實務是**「混合式途徑（Hybrid Approach）」**。針對日常的Q&A，使用搭載向量資料庫的RAG；而對於需要進行複雜分析或全面檢閱程式碼等特定任務，則利用結合提示快取的Long Context，此為目前的主流設計。

10. 多模態處理能力比較

次世代的AI應用程式不僅需要處理文字，還要求能直接理解圖片、語音及影片的能力。

sequenceDiagram participant User as "使用者" participant Client as "前端應用程式" participant API as "LLM API (多模態)" User->>Client: 上傳影片與文字提示詞 Client->>API: 傳送影片Bytes/URI + 文字 Note over API: 影片分塊與音訊分離 Note over API: 多模態嵌入模型 API-->>Client: 回傳文字摘要與時間戳記 Client-->>User: 顯示分析結果

OpenAI (GPT-4o): 圖像辨識準確度極高，非常擅長讀取手寫草圖或複雜圖表。此外，利用Realtime API所實現的超低延遲（數百毫秒）原生語音對話功能也十分強大。
Google (Gemini 1.5 Pro): 在影片分析領域具有壓倒性優勢。 能直接輸入1小時的影片檔案（影格群＋音訊），並針對「在12分45秒時，畫面最右側人物所拿資料的標題是什麼？」這類精準提問做出回答。
Anthropic (Claude 3.5 Sonnet): 圖像辨識（Vision）能力與GPT-4o同等優秀。在「給予UI截圖並要求生成此畫面的React元件程式碼」等前端開發輔助方面，能發揮無與倫比的強大實力。

11. 企業級的安全性與合規性

當企業在正式環境中使用LLM API時，最擔憂的往往是「自家資料是否會被用於AI訓練」以及「是否符合合規性要求」。

這3家公司都明言，透過API傳送的資料（提示詞與回應）不會被用於模型訓練（Zero Data Retention / No Training on Customer Data）（※免費的消費者用Web聊天介面不在此限）。

若要求更高級別的安全性：

OpenAI: 透過Azure OpenAI Service，可利用Microsoft企業級的安全性、SLA，以及Azure Private Link所提供的封閉網路連線。
Google: 透過Google Cloud Vertex AI，可利用VPC Service Controls進行嚴密的網路隔離，並支援CMEK（客戶管理加密金鑰）的資料保護。
Anthropic: 透過AWS Bedrock或Google Cloud Vertex AI使用，可搭乘雲端供應商堅固的安全基礎設施。

12. 結論：依使用案例而定的終極選擇指南

經過如此多面向的比較，關於「最終該選哪一個？」的結論，其實取決於您的使用案例。

複雜的軟體開發・程式碼生成・高階推論: 👑 贏家: Claude 3.5 Sonnet (Anthropic) 在理解程式碼上下文、重構（Refactoring）以及撰寫自然且具備人性的文章方面，目前展現出最佳表現。API的易用性與提示快取帶來的成本效益也極為出色。
超長篇文件分析・影片/音訊批次處理: 👑 贏家: Gemini 1.5 Pro (Google) 高達200萬Token的上下文長度是無可取代的武器。在需要掌握資料全貌的任務（如分析數百頁的PDF手冊或總結長時間的會議錄影）中，Gemini無人能出其右。
通用性・執行速度・穩定的結構化輸出 (JSON): 👑 贏家: GPT-4o / GPT-4o-mini (OpenAI) 能妥善處理各式各樣的任務，對第三方工具的支援也最豐富。若需要利用Structured Outputs進行確實的JSON解析，或是使用o1模型進行超高階邏輯推論，OpenAI生態系統是不可或缺的。

llama.cpp 使用方法與 C++ 客製化入門

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

近年來，大型語言模型 (LLM) 的進化非常驚人，其應用範圍每天都在擴大。然而，要在本機環境中運行具有數十億、數百億參數的模型，通常需要配備龐大 VRAM 的高階 GPU。打破這種「硬體壁壘」，並在一般 PC、Mac 甚至 Raspberry Pi 等設備上實現 LLM 實用推理的，正是 llama.cpp。

本文不僅介紹單純的命令列工具用法，還將針對工程師進行極為詳細的解說，內容涵蓋其基礎技術 ggml 的架構、Transformer 和量化的數學背景，以及如何利用 C++ API 將 LLM 嵌入到獨立應用程式中並進行客製化。

1. llama.cpp 與 ggml 概要

llama.cpp 是由 Georgi Gerganov 開發，使用 C/C++ 編寫的輕量級 LLM 推理引擎。它最初是為了在 Apple Silicon (M1/M2 Mac) 上高速運行 Meta 的 LLaMA 模型而誕生的，但現在已經支援各種架構和模型。

它最大的特點是無外部依賴的純 C/C++ 實作。它不需要 Python 或 PyTorch 等龐大的生態系統，可以編譯為單一執行檔，因此部署非常容易。

這個 llama.cpp 的核心是張量運算函式庫 ggml。ggml 是從零開始設計的，旨在將 CPU（以及部分 GPU）上的機器學習矩陣運算優化到極致。

1.1 為什麼 llama.cpp 這麼快？

活用記憶體映射 (mmap)：在將模型權重載入記憶體時，透過利用作業系統的 mmap，可以避免全部載入 RAM，從而實現快速啟動和節省記憶體。
徹底優化 SIMD 指令：它利用了 AVX2、AVX-512、ARM NEON、Apple AMX 等 CPU 特有的指令集，實現了矩陣乘法的超高速化。
量化 (Quantization)：將 16-bit 浮點數 (FP16) 的權重壓縮為 4-bit、5-bit、8-bit 的整數，從而消除記憶體頻寬的瓶頸（詳情後述）。

2. 數學背景：Transformer 與量化 (Quantization)

為了深入理解 llama.cpp，我們需要了解它所計算的數學公式，以及它是如何對計算進行近似的。

2.1 Transformer 的推理過程

LLaMA 等模型採用了自迴歸型 (Auto-regressive) 的 Transformer 解碼器架構。文字生成的核心是 Self-Attention (自我注意力) 機制。

對於作為輸入的隱藏狀態矩陣 $X \in \mathbb{R}^{N \times d}$，查詢 $Q$、鍵 $K$、值 $V$ 都是透過與權重矩陣的乘積來計算的。

$$ Q = X W_Q, \quad K = X W_K, \quad V = X W_V $$

在此，Attention 的輸出定義如下：

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V $$

在 llama.cpp 的推理迴圈中，瓶頸在於這些巨大的矩陣 $W_Q, W_K, W_V$ 或前饋神經網路 (FFN) 的權重矩陣與向量 $X$（在生成階段由於每次處理一個 Token，因此 $N=1$）的乘積，也就是 GEMV (General Matrix-Vector Multiplication)。

2.2 量化 (Quantization) 的數學基礎

在記憶體存取頻寬成為瓶頸的推理中，使用較小的位元數來表示權重參數的量化是不可或缺的。在此說明 llama.cpp 中廣泛使用的區塊單位量化（例如 Q4_K 或 Q4_0）的基本原理。

舉例來說，考慮 FP16 權重矩陣 $W$ 的一部分，長度為 $B$（通常為 32 或 64）的區塊 $w = [w_1, w_2, \dots, w_B]$。我們將此區塊近似為 4-bit 整數 $q_i \in [-8, 7]$ 和單一的縮放因子 $\Delta$（FP16 或 FP32）。

$$ w_i \approx \Delta \times q_i $$

$\Delta$ 是根據區塊內的最大絕對值決定的。

$$ \Delta = \frac{\max_i |w_i|}{7} $$

當使用量化後的權重計算內積 $y = w \cdot x$ 時，如果將輸入向量 $x$ 也同樣量化為 $x_i \approx \Delta_x \times q_{x, i}$，則：

$$ y = \sum_{i=1}^{B} w_i x_i \approx \Delta \Delta_x \sum_{i=1}^{B} q_i q_{x, i} $$

這個 $\sum q_i q_{x, i}$ 的部分變成了純整數運算，可以使用 SIMD 指令進行極為高速的平行計算。這就是 llama.cpp 能在 CPU 上達到驚人速度的數學機關。

3. 架構與推理流程

為了理解 llama.cpp 的內部運作，我們使用以下的 Mermaid 圖表來展示整體系統的架構和資料流向。

graph TD A["使用者輸入 (字串)"] --> B["llama.cpp Tokenizer"] B --> C["Token ID (int32 陣列)"] C --> D["上下文緩衝區 (KV Cache)"] D --> E["ggml 計算圖"] E --> F["Transformer 層"] subgraph "ggml 引擎" F --> G["Self-Attention (RoPE)"] G --> H["前饋神經網路"] H --> F end F --> I["Logits (詞彙表大小)"] I --> J["採樣器 (Temperature, Top-K, Top-P)"] J --> K["選定的 Token ID"] K --> L["llama.cpp Detokenizer"] L --> M["輸出字串"] K -. "自迴歸迴圈" .-> D

文字生成是一個自迴歸迴圈，每輸出一個 Token，它就會作為下一個輸入被加入到 KV Cache 中，然後再次通過計算圖。

4. 環境建置與編譯方法

在將 llama.cpp 嵌入到 C++ 專案之前，讓我們先嘗試編譯其原始碼。

4.1 複製儲存庫

1
2


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

4.2 使用 CMake 進行編譯

當作為 C++ 專案嵌入到其他應用程式時，使用 CMake 是最標準的做法。透過啟用各個平台的加速器（後端），可以加快計算速度。

僅 CPU（基本編譯）：

1
2
3


mkdir build && cd build
cmake ..
cmake --build . --config Release -j 8

使用 NVIDIA GPU (CUDA) 時：

1
2
3


mkdir build && cd build
cmake .. -DGGML_CUDA=ON
cmake --build . --config Release -j 8

使用 Apple Silicon (Metal) 時：

1
2
3


mkdir build && cd build
cmake .. -DGGML_METAL=ON
cmake --build . --config Release -j 8

編譯成功後，會在 build/bin/ 目錄下產生 llama-cli 等執行檔，以及用於後述 C++ API 連結的 llama 函式庫（和 ggml 函式庫）。

5. C++ 客製化入門：llama.cpp API 的使用

從這裡開始將解說本文的重點：如何透過 C++ 程式碼控制 llama.cpp。如果不僅僅是使用命令列工具，而是要將 LLM 嵌入到自己的應用程式（例如遊戲引擎、桌面應用程式、嵌入式系統等），就必須直接呼叫 C++ API。

llama.cpp 主要透過名為 llama.h 的標頭檔提供 C 語言介面。從 C++ 呼叫時同樣使用此介面。

5.1 必要最少的 Include 與設定

在自己的專案中使用 llama.cpp 時，請 Include 以下內容。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


#include "llama.h"
#include <iostream>
#include <vector>
#include <string>
#include <stdexcept>

// 錯誤處理用的巨集
#define LLAMA_ASSERT(x) \
 do { \
 if (!(x)) { \
 std::cerr << "Assertion failed: " << #x << std::endl; \
 std::terminate(); \
 } \
 } while (0)

5.2 載入模型與初始化上下文

首先，載入 .gguf 格式的模型檔案，並分配用於推理的上下文（記憶體空間和 KV Cache）。

 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


int main(int argc, char ** argv) {
 if (argc < 2) {
 std::cerr << "Usage: " << argv[0] << " <model.gguf>" << std::endl;
 return 1;
 }
 std::string model_path = argv[1];

 // 1. 初始化後端（CPU/GPU 等環境設置）
 llama_backend_init();

 // 2. 獲取模型參數的預設設定
 llama_model_params model_params = llama_model_default_params();
 model_params.n_gpu_layers = 35; // 卸載到 GPU 的層數

 // 3. 載入模型
 llama_model * model = llama_load_model_from_file(model_path.c_str(), model_params);
 if (model == nullptr) {
 std::cerr << "Failed to load model" << std::endl;
 return 1;
 }

 // 4. 設定上下文參數
 llama_context_params ctx_params = llama_context_default_params();
 ctx_params.n_ctx = 2048; // 最大上下文大小 (Token 數)
 ctx_params.n_threads = 8; // 用於推理的 CPU 執行緒數

 // 5. 建立上下文
 llama_context * ctx = llama_new_context_with_model(model, ctx_params);
 if (ctx == nullptr) {
 std::cerr << "Failed to create context" << std::endl;
 llama_free_model(model);
 return 1;
 }

 std::cout << "Model and context loaded successfully!" << std::endl;
 // ... 後續的處理

5.3 提示詞的 Token 化 (Tokenization)

LLM 並不是直接理解文字，而是將其作為整數 ID（Token）的序列來處理。因此需要將輸入字串轉換為 Token。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


 std::string prompt = "Q: 日本的首都是哪裡？\nA:";
 std::vector<llama_token> tokens_list;
 tokens_list.resize(prompt.length() + 4); // 預留充裕的緩衝區大小

 // 是否在開頭加入特殊 Token（如 BOS: Begin of Sequence 等）
 bool add_special = true;
 // 將字串轉換為 Token ID 陣列
 int n_tokens = llama_tokenize(
 model,
 prompt.c_str(),
 prompt.length(),
 tokens_list.data(),
 tokens_list.size(),
 add_special,
 false // parse_special
 );

 if (n_tokens < 0) {
 // 緩衝區不足時需要重新分配並重試的處理（為了簡化在此省略）
 std::cerr << "Failed to tokenize prompt" << std::endl;
 return 1;
 }
 tokens_list.resize(n_tokens);

5.4 推理迴圈與採樣

將 Token 輸入到模型中，獲取下一個 Token 的機率分佈 (Logits)，然後從中進行採樣以決定下一個 Token，如此建構一個迴圈。

 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


 // 要生成的最大 Token 數
 const int max_gen_tokens = 100;

 // 初始化批次評估用的結構體
 llama_batch batch = llama_batch_init(512, 0, 1);

 // 將提示詞的 Token 加入批次
 for (size_t i = 0; i < tokens_list.size(); i++) {
 llama_batch_add(batch, tokens_list[i], i, { 0 }, false);
 }
 // 設定僅在提示詞的最後一個 Token 輸出 Logit (預測結果)
 batch.logits[batch.n_tokens - 1] = true;

 // 初次評估（將提示詞餵給模型）
 if (llama_decode(ctx, batch) != 0) {
 std::cerr << "llama_decode() failed" << std::endl;
 return 1;
 }

 int n_cur = batch.n_tokens; // 目前的上下文長度
 int n_decode = 0;

 std::cout << "\nOutput: ";

 // 初始化採樣器上下文（Temperature, Top-K, Top-P 等設定）
 llama_sampler * smpl = llama_sampler_chain_init(llama_sampler_chain_default_params());
 llama_sampler_chain_add_top_k(smpl, 40);
 llama_sampler_chain_add_top_p(smpl, 0.9f, 1);
 llama_sampler_chain_add_temp(smpl, 0.7f);
 llama_sampler_chain_add_dist(smpl, 1234); // 種子值

 while (n_decode < max_gen_tokens) {
 // 1. 採樣：根據目前的上下文預測下一個 Token
 llama_token new_token_id = llama_sampler_sample(smpl, ctx, -1);

 // 2. 如果 Token 是 EOS (End of Sequence) 則結束迴圈
 if (llama_token_is_eog(model, new_token_id)) {
 break;
 }

 // 3. 將 Token 解碼為字串 (文字) 並顯示
 char buf[128];
 int n_chars = llama_token_to_piece(model, new_token_id, buf, sizeof(buf), 0, false);
 if (n_chars > 0) {
 std::cout << std::string(buf, n_chars) << std::flush;
 }

 // 4. 將新生成的 Token 準備為下一個批次
 llama_batch_clear(batch);
 llama_batch_add(batch, new_token_id, n_cur, { 0 }, true);

 // 5. 模型評估（更新 KV Cache 並預測下一個）
 if (llama_decode(ctx, batch) != 0) {
 std::cerr << "Failed to evaluate" << std::endl;
 break;
 }

 n_cur += 1;
 n_decode += 1;
 }

 std::cout << std::endl;

 // 清理
 llama_sampler_free(smpl);
 llama_batch_free(batch);
 llama_free(ctx);
 llama_free_model(model);
 llama_backend_free();

 return 0;
}

這段程式碼使用 llama.cpp 的基本 API 實作了自訂的推理迴圈。它使用 llama_batch 結構體來管理 Token 群，並透過 llama_decode 執行神經網路的前向傳播 (Forward Pass)。

6. 進階客製化案例：透過 C++ 進行 Logit 操作與懲罰控制

如果不只是單純的文字生成，而是強制輸出特定格式（例如僅限 JSON），或是控制不輸出特定的禁止詞彙時，我們可以在 C++ 端直接操作採樣前的 Logit (Logits)。

可以獲取模型在輸出每個 Token 之前，原始分數（轉換為機率前的值）的陣列。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 在推理之後、進行採樣之前，取得原始的 Logit 陣列
float * logits = llama_get_logits_ith(ctx, batch.n_tokens - 1);
int n_vocab = llama_n_vocab(model);

// 禁止 Token 的 ID 列表（以 1234, 5678 為例）
std::vector<llama_token> forbidden_tokens = { 1234, 5678 };

// 將禁止 Token 的出現機率設為 0 (將 Logit 設為負無窮大)
for (llama_token bad_tok : forbidden_tokens) {
 logits[bad_tok] = -INFINITY;
}

如此一來，透過直接處理 C++ API，我們就能實現透過 LangChain 或 Python 難以做到或開銷過大的**「在每個推理週期進行微秒級的介入」**。

7. 效能調校的秘訣

在完成 C++ 實作後，這裡介紹幾個為了實際應用而將速度提升至極限的檢查點。

批次處理的優化： 當同時處理來自多個使用者的請求時，可以在 llama_batch 中包含多個序列，並一次呼叫 llama_decode（Continuous Batching）。這能讓記憶體存取共用，從而大幅提升吞吐量。
啟用 Flash Attention： 透過在上下文參數中設定 ctx_params.flash_attn = true;，可以在減少記憶體使用量的同時加快 Attention 計算。在處理長上下文（數萬個 Token）時，這是必須的設定。
NUMA 支援： 在多插槽的伺服器環境中，在 llama_backend_init() 之前正確設定 NUMA，可以減少記憶體存取的延遲。

8. 結語

本文從 llama.cpp 的數學背景開始，詳細解說了其架構，以及如何活用 C++ API 來建構自訂的推理引擎。

雖然 Python 的生態系統在製作原型時非常方便，但在部署到邊緣裝置、嵌入到遊戲或要求即時處理的正式環境中，基於 C/C++ 的 llama.cpp 的直接控制展現了壓倒性的優勢。

大家也務必親自動手編寫 C++ 程式碼，體驗在本機環境中自由操控 LLM 的樂趣。

參考連結集

llama.cpp Official Repository

ggml - Tensor Library

Attention Is All You Need (Vaswani et al., 2017)

【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 世界吧。

AI on kenji.blog

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

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

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

2. Windows Copilot Runtime 與架構全貌

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

4. 開發環境設定

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

5.1 C# 實作中的架構解說

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

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

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

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

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

7.3 背景工作與 OS 的整合

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

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

無須Python！只用C++打造AI推論引擎

1. 前言：為什麼要放棄Python，改用C++製作AI推論引擎？

2. 推論引擎架構全貌

3. 記憶體管理的奧秘：記憶體池與SIMD對齊

3.1 對齊（Alignment）的重要性

4. 張量資料結構與步幅的魔法

5. 建立計算圖（DAG）與延遲評估

6. 數學與最佳化的核心：矩陣乘法 (GEMM)

6.1 CPU上的快取區塊化與SIMD最佳化

7. 跨越硬體高牆：整合CUDA與Metal後端

7.1 後端抽象化

7.2 NVIDIA CUDA 後端實作

7.3 Apple Silicon (Metal) 後端

8. Transformer模型特有的處理：Attention與KV Cache

9. 透過模型量化（Quantization）達成極限最佳化

10. 效能調校：NUMA架構與執行緒池

11. 總結：用C++的「肌肉」驅動AI的樂趣

如何在本地環境中最快地微調 TinyLLaMA

1. 前言：為什麼現在要選擇 TinyLLaMA 與本地部署？

2. TinyLLaMA 的架構與特徵

主要架構元件

3. 微調的突破：LoRA 與 QLoRA

3.1 LoRA (Low-Rank Adaptation) 的數學背景

3.2 QLoRA (Quantized LoRA) 的創新性

4. 本地環境的硬體需求與設定

推薦硬體規格

軟體環境建置

5. 為了最快微調的最佳化技術

5.1 Flash Attention 2

5.2 Gradient Checkpointing (梯度檢查點)

5.3 Mixed Precision Training (混合精度訓練) 與 Bfloat16

6. 實作：TinyLLaMA 的 QLoRA 微調程式碼

6.1 資料集準備與模型載入

6.2 套用 LoRA 適配器與資料集格式化

6.3 執行訓練

7. 效能評估與疑難排解

8. 微調後的模型部署 (Deployment)

模型合併腳本

透過 vLLM 啟動極速推論伺服器

9. 總結

AI時代的程式設計師該如何生存？

AI時代的程式設計師該如何生存？寫程式的終結與新工程學的開端

1. 抽象化（Abstraction）的歷史與「程式設計」的重新定義

2. 生產力的數學模型：乘上指數型成長的浪潮

3. 任務的自動化機率（Probability of Automation）

4. 從語法（Syntax）回歸到架構（Architecture）

5. 需求定義才是「真正的提示工程（Prompt Engineering）」

6. 領域知識（Domain Knowledge）的壓倒性優勢

7. 軟體開發的「電車難題」：誰來負責？

8. AI 結對程式設計與認知負荷（Cognitive Load）的管理

9. 具體的生存策略：從明天開始該學什麼？

結論：不要害怕，駕馭浪潮吧

使用C++開發小規模AI模型（如TinyLLaMA）的步驟指南

使用C++開發小規模AI模型（如TinyLLaMA）的步驟指南

1. 為什麼選擇C++與ggml？

2. 架構全貌

3. 模型格式與記憶體映射 (mmap)

3.1 記憶體映射的機制與 Windows 上的實作

3.2 GGUF 格式的二進位結構

4. TinyLLaMA的數學基礎與C++演算法

4.1 RMSNorm (Root Mean Square Normalization)

4.2 RoPE (Rotary Position Embedding)

4.3 Grouped-Query Attention (GQA)