Local AI on kenji.blog

如何在本地環境中最快地微調 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 吧。

使用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 的深入探討文章。如果您有任何問題或回饋，歡迎在留言區告訴我們。

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

Local AI on kenji.blog

如何在本地環境中最快地微調 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. 總結

使用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)

4.4 SwiGLU 激勵函式

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

5.1 ggml_context 與 Arena Allocator

5.2 計算圖建構的具體範例

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

6.1 區塊量子化架構

6.2 利用 AVX2 加速內積計算

7. KV Cache的實作細節

8. BPE Tokenizer 與解碼

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

10. 總結

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

前言

1. RAG 的整體架構

攝取階段（事前準備）

推論階段（執行時）

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

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

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

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

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

Step 1: 安裝必要的函式庫

Step 2: 實作程式碼全貌

程式碼重點解說

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

5.1 混合檢索 (Hybrid Search)

5.2 重新排序 (Re-ranking)

5.3 語意分塊與父文件檢索

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

總結

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

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

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

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

2.1 建議硬體配置

2.2 WSL2 (Windows Subsystem for Linux 2) 設定

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

3.1 兩個階段：Prefill 與 Decode

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

4.1 基於參數大小的基礎 VRAM

4.2 量化 (Quantization) 的魔法

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

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

5.1 安裝與執行

5.2 使用 Modelfile 建立客製化 AI