本章拆開 embedding 的三件事：怎麼從 token ID 變成向量、向量空間怎麼承載語意、embedding 是怎麼學出來的。

本章目標

讀完本章後、你應該能：

1. 解釋 embedding layer 在 LLM 中的位置。
2. 看到「embedding dimension = 4096」時、知道指什麼。
3. 解釋 RAG / semantic search 為什麼用 embedding similarity。
4. 區分 word2vec、句子 embedding、contextual embedding 的差別。

Embedding Layer：從 token ID 到向量

Embedding layer（嵌入層）的核心結構是「一個 lookup table、把 token ID（整數）map 到向量」。形式上是一個 (vocab_size, hidden_dim) 的矩陣 E：

1token_id = 12345
2embedding = E[12345]   ← 取出第 12345 row、得到 hidden_dim 維向量

Gemma 4 31B 的 embedding matrix：

• vocab_size = 256,000
• hidden_dim = 5120
• 總參數 = 256,000 × 5120 ≈ 1.3 billion

光是 embedding layer 就佔 31B 中的 1.3B（約 4%）。70B 模型的 embedding layer 更大、可達 2B 以上。

實作上 embedding lookup 比矩陣乘法便宜（只是查表）、但記憶體佔用顯著。

向量空間：用 hidden_dim 維空間編碼語意

Embedding 的設計目標是「讓相似 token 在向量空間中靠近、不相似的遠」。具體用內積 或 cosine similarity 衡量相似度：

1cosine_sim(a, b) = (a · b) / (||a|| × ||b||)

訓練後的 embedding 會展現語意結構：

• embedding(cat) 跟 embedding(kitten) 內積大。
• embedding(cat) 跟 embedding(algorithm) 內積小。
• 著名的「king - man + woman ≈ queen」現象（word2vec 時代發現、Transformer 上也成立）。

這個性質讓 embedding 能做：

• Semantic search：把 query 跟 documents 都轉成 embedding、用 cosine similarity 找相似的。
• RAG：把 codebase chunks embed、用 query embedding 找相關片段。
• Clustering：embedding 上跑 k-means、把語意相近的 document 分組。
• Anomaly detection：embedding 離 cluster 中心遠的就是異常。

Embedding 怎麼學出來

Embedding layer 跟其他 layer 一樣、是訓練過程中學出來的。具體機制：

1. 訓練初期 embedding 是隨機初始化。
2. Forward pass 用這些 embedding 跑模型、預測下一個 token。
3. 預測錯了、loss 大、backprop 算 gradient、更新 embedding。
4. 反覆 trillion token 訓練、embedding 收斂到能表達語意。

訓練機制讓「常在類似 context 出現的 token」拿到相似的 embedding。例如 cat 跟 kitten 在訓練資料中常出現在類似句子（「The ___ is sleeping」「I have a pet ___」等）、模型最佳化的方向會自然讓兩者的 embedding 接近。

這就是「distributional semantics」（分佈式語意）的核心假設：字詞的意義由它周圍的字詞決定（“You shall know a word by the company it keeps”, J. R. Firth, 1957）。

Word2Vec：embedding 的早期實作

Word2Vec（Mikolov et al., 2013）是 embedding 的經典實作、影響後續所有 NLP。它的核心是「用淺層網路專門學 embedding」、不做下游任務：

• Skip-gram：給一個中心字、預測周圍字。
• CBOW：給周圍字、預測中心字。

訓練後 embedding 展現語意結構（包括「king - man + woman ≈ queen」這個著名實驗、近年研究指出該類比有 cherry-picking 質疑、Linzen 2016 / Nissim et al. 2020、是入門啟發、非嚴格 evidence）。Word2Vec 在大型語意理解場景已被 contextual embedding 取代、但在「靜態查表、邊緣計算、輕量 baseline」等情境仍有用、不是完全淘汰。

Word-level vs Contextual Embedding

Word-level embedding（Word2Vec、GloVe 等）每個字一個固定向量、不考慮 context：

• bank 在「river bank」跟「bank account」中拿到同樣的 embedding。
• 簡單、可預先計算、查表快。
• 限制：無法區分多義詞。

Contextual embedding（BERT、GPT 等 Transformer-based）的向量隨 context 改變：

• bank 在「river bank」跟「bank account」中拿到不同的向量。
• 模型每層輸出都可視為一種 contextual embedding、越深越抽象。
• 缺點：需要跑完整模型、不能預先計算。

LLM 內部用的是 contextual embedding。輸入端的 embedding layer 是 word-level（每個 token ID 對應固定向量）、但經過 attention 後變成 context-dependent。

Sentence / Paragraph Embedding

句子或段落級別的 embedding 是把整段文字壓成一個向量、用於 retrieval 與分類任務。常見實作：

Embedding 模型 跟 chat model 是不同訓練流程：

• Chat model 學「下個 token 機率分佈」。
• Embedding model 學「整段文字壓成一個向量、用 cosine similarity 衡量語意相似度」。

兩者底層架構都是 Transformer、但訓練 objective 不同、得到的向量空間不通用。

向量空間互不相容

不同 embedding 模型的向量空間互不相容：

• nomic-embed-text 輸出 768 維向量。
• OpenAI text-embedding-3-small 輸出 1536 維向量。
• 兩者各自的座標軸有獨立意義、不能拿 nomic 的向量跟 OpenAI 的向量算 cosine。

實務啟示：

1. 換 embedding 模型要重建 vector database。
2. 一個 retrieval 系統用同一個 embedding 模型 throughout、混用會壞。
3. 模型升級時要 backfill 舊資料。

Embedding similarity 的失效情境

Embedding similarity 在多數 retrieval / semantic search 場景能用、但有幾類已知失效模式、影響 RAG / @codebase 的回答品質：

實作層級的修法多半是 hybrid retrieval（embedding + BM25 / TF-IDF 各跑一次、合併分數）或加 reranker 做最終排序、純依賴 cosine similarity 風險高的場景值得納入這層。

位置編碼：把順序資訊加進 embedding

純 embedding layer 沒有「順序資訊」、[cat, dog] 跟 [dog, cat] 的 embedding 序列只是 order 不同的 set。Transformer 用 positional encoding 把位置資訊加進去。

主流位置編碼方法：

RoPE 是 2026 年的主流選擇。詳細展開見 3.3 Transformer 架構。

Tied vs Untied Embedding

「Tied embedding」指「input embedding（token → vector）跟 output projection（hidden → logits）共用同一個矩陣」。實作上 input embedding 矩陣 E 的 shape 是 (vocab_size, hidden_dim)、output projection 矩陣的 shape 是 (hidden_dim, vocab_size)；tied 模式直接用 E^T（轉置）當 output projection、省下一份 (vocab_size, hidden_dim) 大小的權重。GPT-2 系列預設 tied、節省參數。

「Untied embedding」是兩者各自獨立、各自訓練。Llama 系列預設 untied、品質略好（兩個矩陣可以各自最佳化）、但 embedding layer 跟 output layer 都要存。

實務上、大模型（30B+）幾乎都採 untied、用較多參數換較高品質；小模型（1B 以下）為了壓縮參數量仍會 tied。

Embedding 在 LLM forward pass 中的位置

LLM 的 forward pass 概略：

 1tokens (整數序列)
 2  ↓ embedding lookup
 3embeddings (向量序列、shape: [seq_len, hidden_dim])
 4  ↓ + positional encoding
 5positioned embeddings
 6  ↓ Transformer block × N
 7final hidden states
 8  ↓ output projection
 9logits (shape: [seq_len, vocab_size])
10  ↓ softmax
11機率分佈

每個 Transformer block 內部都對向量做變換、向量維度保持 hidden_dim 不變、只有 input embedding 跟 output projection 在 vocab_size 跟 hidden_dim 之間轉換。

下一章

下一章：3.2 attention 機制、Transformer 的招牌技術。

本章從「為什麼需要 attention」開始、拆 scaled dot-product attention 公式、再展開 multi-head attention 跟 causal masking、最後接到 KV cache 與長 context 場景。

本章目標

讀完本章後、你應該能：

1. 用 Q / K / V 三個角色解釋 attention 在算什麼。
2. 看到 attention 公式時、能解讀每個運算的角色。
3. 解釋 multi-head attention 跟 single-head 的取捨。
4. 把 KV cache 跟 attention 公式對上。

為什麼需要 attention

LLM 處理「下一個 token 該是什麼」、需要綜合 prompt 中前面所有 token 的資訊。早期解法（RNN、LSTM）用「序列狀態」串接、每個 token 只看到上一步的 hidden state。缺點：

1. 長距離依賴難：訊息傳遞要跑過所有中間 token、容易遺失。
2. 無法並行：每步依賴上一步、訓練速度有瓶頸。

Attention 的核心突破是「每個 token 直接看所有前面的 token、無需透過中間 hidden state 傳遞」。每個 token 用 attention scores 決定「該關注哪些前面 token」、用這些 token 的向量加權求和、形成自己的 context-aware 表示。

Attention 帶來三個性質：兩個是優勢、一個是代價：

• 優勢一、長距離依賴變直接：attention 直接連到任何位置、不再需要透過 RNN 的中間 hidden state 接力。
• 優勢二、可以並行：不同 token 的 attention 計算彼此獨立、訓練時整段序列一次跑完。
• 代價、O(n²) 計算複雜度：seq_len = n 時要算 n × n 個 attention scores、長 context 場景成本暴增、見後面的 KV cache 與 Flash Attention 段。

Q / K / V 三個角色

Attention 給每個 token 三個向量、各自有不同角色：

其中 X 是 input embedding、W_Q、W_K、W_V 是三個 learnable 權重矩陣。

直覺：

• 每個 token 同時當「找東西的人」（query）跟「被找的東西」（key + value）。
• Query 跟其他 token 的 Key 內積、得到「該關注每個 token 多少」的分數。
• 用這些分數對所有 token 的 Value 加權求和、得到當前 token 的 context-aware 表示。

Scaled Dot-Product Attention：核心公式

Attention（Vaswani et al., 2017）的核心公式：

1Attention(Q, K, V) = softmax(Q @ K^T / sqrt(d_k)) @ V

逐步拆解：

1. Q @ K^T：所有 query 跟所有 key 兩兩內積、得到 (seq_len, seq_len) 矩陣。矩陣 [i][j] 等於「token i 該關注 token j 多少」的原始分數。
2. / sqrt(d_k)：scale by sqrt of key dimension。若沒有這步、d_k 大時 softmax 會極端化、訓練不穩。
3. softmax(...)：對每一 row 做 softmax、把分數正規化成機率分佈、保證「每個 token 對所有前面 token 的注意力總和 = 1」。
4. @ V：用 attention 機率對所有 token 的 V 加權求和、得到 (seq_len, d_v) 的輸出。每個輸出 row 是該 token 整合了前面所有 token 資訊的 context-aware 表示。

這個公式叫 scaled dot-product attention、是 Transformer 的核心運算。

Multi-Head Attention：多個 attention 並行

Multi-head attention 的核心想法是「跑 N 個獨立的 attention、每個 head 各自有自己的 W_Q / W_K / W_V、結果 concatenate 再過一個線性層」：

1head_i = Attention(Q W_Q_i, K W_K_i, V W_V_i)
2MultiHead(Q, K, V) = Concat(head_1, ..., head_h) @ W_O

幾何意義：每個 head 學「關注一種 pattern」。例如：

• Head 1 可能學到「關注名詞的修飾語」。
• Head 2 可能學到「關注前後標點」。
• Head 3 可能學到「關注 quotation 邊界」。

實驗發現不同 head 確實學到可解釋的功能（雖然多數 head 的功能難以直觀標籤）。在主流規模（hidden_dim ≥ 768、num_heads ≥ 8）下、multi-head 比 single-head 表達能力強；極小模型（hidden_dim < 256）下 multi-head 收益遞減、有時 single-head 更穩定。

主流 LLM 的 head 數：

關係：hidden_dim = num_heads × head_dim。每個 head 處理 head_dim 維、parallel 跑完再 concatenate 回 hidden_dim。

Causal Mask：只看前面、不看後面

LLM 是 autoregressive、生成 token N 時只能看 token 0 到 N-1、不能看後面（後面還沒生）。Attention 機制要「擋掉未來位置」、用 causal mask 實現：

1masked_scores[i][j] = scores[i][j]   if j ≤ i
2                    = -∞              if j > i

把未來位置的 attention score 設為 -∞、softmax 後機率為 0、等於完全忽略未來。

實作上 mask 是一個下三角矩陣、訓練跟推論時都套用、但角色不同：

• 訓練時的 causal mask：讓 decoder 能「一次 forward pass 算所有 N 個 token 的 loss」、parallel 訓練。沒有 mask 就要對每個位置跑 N 次 forward（位置 i 只給 token 0 ~ i-1）、訓練速度掉一個量級。這是 Transformer 取代 RNN 在訓練效率上的關鍵。
• 推論時的 causal mask：每生新 token 只看前面已生的 token、不能 peek 未來。實際因為 token 是按順序生成的、未來位置本來就還沒存在、mask 更像是「沿用訓練階段的同套運算結構、避免訓練 / 推論 mismatch」。

「Decoder-only LLM」（GPT、Llama 系列）用 causal mask 做自回歸生成；「Encoder-only LLM」（BERT 等）不用 causal mask、可看雙向 context、適合分類 / NER 等理解任務、不走自回歸生成路徑；「Encoder-Decoder」（T5、BART）encoder 看雙向、decoder 用 causal mask、可生成、是另一條典型架構。

KV Cache：避免重複計算

KV Cache 是 attention 機制下的關鍵優化。回到 attention 公式：

1Attention(Q, K, V) = softmax(Q @ K^T / sqrt(d_k)) @ V

生成 token N 時：

• Q 是 token N 對應的 query（新的）。
• K、V 是 token 0 到 N-1 的 key / value（前面都算過）。

如果每生一個 token 都重新算 K、V、會浪費大量計算。KV cache 把 K、V 存起來、下次生 token N+1 時：

• Q 是 token N+1 的新 query。
• K、V 是 cache + 新 token 的 K、V。

只算 token N+1 對應的 K、V 新值、跟既有 cache concat。每生一個 token 的計算量從 O(n²) 降到 O(n)。

代價是 KV cache 隨 context window 線性增長、長 context 場景吃記憶體。Gemma 4 31B 在 32GB Mac 上實用 context 約 8 ~ 16K tokens、超過會 swap。記憶體吃緊時的 KV cache 量化（K=Q8 / V=Q4）原理與 context / 併發取捨見 模組五 5.2 KV cache 量化策略、整體 VRAM 預算見 5.0 VRAM + RAM 分層預算。

Flash Attention：記憶體高效實作

Flash Attention（Dao et al., 2022）是 attention 的 GPU 高效實作。標準 attention 在記憶體中具體實作 (seq_len, seq_len) 矩陣、長 context 時記憶體爆炸（10K context = 100M 個 float）。

Flash Attention 用「tiling + recompute」技巧、把 attention 拆成 block 算、不具體實作完整 attention matrix。記憶體佔用從 O(n²) 降到 O(n)、速度也快 2 ~ 4 倍。

Apple Silicon 上的對應實作可能稱為 Metal FlashAttention 或類似名稱、Ollama、LM Studio、oMLX 等本地推論伺服器逐步整合。

Flash Attention 何時收益有限：

• 短 context 場景：seq_len < 1K 時、attention matrix 本身就小、Flash Attention 的記憶體節省無感。
• CPU 推論：Flash Attention 的 tiling 設計針對 GPU memory hierarchy（HBM ↔ SRAM）、CPU 上的記憶體層級不同、收益遠小於 GPU。
• 配合 GQA 的場景：GQA 已大幅減少 KV cache、Flash Attention 的相對收益縮小。

Grouped Query Attention（GQA）

Grouped Query Attention 是 multi-head attention 的變體、減少 KV cache 佔用。核心想法：「不同 head 共用 K、V、只有 Q 各自獨立」。

Llama 3 / Gemma 4 / Qwen3 都用 GQA、把 KV cache 大小減半到三分之一、長 context 場景受益。

為什麼 speculative decoding 在 code 場景加速明顯：attention 並行性的支撐

加速本身來自 speculative decoding / MTP、attention 在這條路徑上的角色是「提供並行驗證所需的計算結構」：

• Speculative decoding 一次驗證 N 個 token、需要 attention 同時處理 N 個 query 對前面所有 K/V。
• Attention 機制天生可並行、一次 forward pass 驗證 N 個 token 跟驗證 1 個 token 的時間接近（瓶頸是讀權重而非算 attention）。
• 寫 code 場景 drafter 接受率高（code 的 pattern 容易預測）、加速明顯。

理解這點、能解釋為什麼 MTP 對 coding 比創意寫作加速更明顯：差別不在 attention 本身、在「drafter 預測的接受率」這個 sampling 層的變數。

下一章

下一章：3.3 Transformer 架構、把 attention 跟 embedding 組裝成完整模型。

理解整個架構後、看 LLM paper 中的「residual stream」「pre-norm vs post-norm」「FFN」「MoE」等術語都能對到具體位置。

本章目標

讀完本章後、你應該能：

1. 畫出一個 Transformer block 的結構。
2. 解釋 positional encoding 的角色與選擇。
3. 看到 RMSNorm、SwiGLU 等術語時、知道是 layer norm / activation 的變體。
4. 解釋為什麼現代 LLM 普遍用 decoder-only 架構。

Encoder vs Decoder：兩種 Transformer

原始 Transformer paper 提出 encoder-decoder 結構、用於機器翻譯：

• Encoder：處理 input sequence、產生 contextual embedding。雙向 attention（每個 token 可看所有 token）。
• Decoder：根據 encoder 輸出 + 已生成 tokens、產生下一個 token。Causal attention（只看前面）。

後續發展出三種主流變體：

寫 code 場景接觸到的所有主流 LLM（GPT、Claude、Gemma、Llama、Qwen）都是 decoder-only、只用 causal attention、用「文字接龍」方式做所有任務（chat、寫 code、翻譯都統一成「給前面文字、生成後面文字」）。

本章其他部分聚焦 decoder-only 結構。

整體 forward pass

Decoder-only Transformer 的 forward pass：

 1input tokens [t1, t2, ..., tn]
 2  ↓ embedding lookup
 3embeddings [e1, e2, ..., en]   (shape: seq_len × hidden_dim)
 4  ↓ + positional encoding（如 RoPE）
 5positioned embeddings
 6  ↓ Transformer block 1
 7  ↓ Transformer block 2
 8  ↓ ...
 9  ↓ Transformer block N（30 ~ 80 層）
10final hidden states
11  ↓ final layer norm
12normalized states
13  ↓ output projection
14logits [vocab_size]
15  ↓ softmax
16下個 token 的機率分佈

每個 Transformer block 內部結構（後面展開）。

Transformer Block：架構核心

一個 Transformer block 包含兩個 sub-layer、各自前後加 layer norm 跟 residual connection。現代 LLM 用的「pre-norm」結構：

 1input x
 2  ↓
 3norm 1 (RMSNorm)
 4  ↓
 5multi-head attention（causal）
 6  ↓
 7+ x（residual connection）
 8  ↓
 9中間結果 y
10  ↓
11norm 2 (RMSNorm)
12  ↓
13FFN（feed-forward network）
14  ↓
15+ y（residual connection）
16  ↓
17output

兩個關鍵組件：

1. Multi-head attention：見 3.2、Q/K/V 來源同 sequence 的部分見 self-attention 卡。
2. FFN（feed-forward network）：兩層 linear layer + 非線性 activation。

每個 sub-layer 前後加 residual connection：把 sub-layer 的輸出加回 input、形成「主流」。這個結構讓 gradient 容易在深層網路中傳遞、解決 gradient vanishing 問題。

Feed-Forward Network（FFN）

符號 legend：以下公式中 @ 表矩陣乘法、⊙ 表逐元素乘（Hadamard product）、x 是 hidden vector。

FFN 是 Transformer block 中的第二個 sub-layer、結構是「升維 → activation → 降維」：

1FFN(x) = activation(x @ W1) @ W2

其中：

• W1 shape: (hidden_dim, intermediate_dim)
• W2 shape: (intermediate_dim, hidden_dim)
• intermediate_dim 通常是 hidden_dim 的 2.5 ~ 4 倍

例：Llama 3 8B、hidden_dim 4096、intermediate_dim 14336（約 3.5x）。FFN 是模型大部分參數的來源（attention 的 W_Q/K/V 只佔少數）。

intermediate_dim 比例的邊界：低於 2.5x 時 FFN 的「升維 → 過 activation → 降維」表達能力不足、模型 capacity 跟訓練資料 fit 變差；高於 4x 時邊際參數收益遞減、且推論成本線性增加、不划算。SwiGLU / GeGLU 因為內部有兩個 projection、實作上 intermediate_dim 會略低（約 2/3）抵消多出來的參數量。

Activation 選擇：

SwiGLU / GeGLU 屬於 gated linear unit (GLU) 家族、用兩個 linear projection、其中一個過 activation 當 gate：

1SwiGLU(x) = (x @ W1) ⊙ SiLU(x @ W3) @ W2

SiLU(x) = x × sigmoid(x)（Swish 的別名）、產出「平滑版的 ReLU」。實驗發現 GLU 家族比純 GELU 略好、是現代 LLM 主流。

Layer Normalization：穩定訓練

Layer normalization（layer norm）的核心定義是「把每個 token 的 hidden vector 重新正規化到 mean=0、variance=1、再用 learnable scale / shift 調整」：

1LayerNorm(x) = γ ⊙ (x - mean(x)) / sqrt(var(x) + ε) + β

其中 γ、β 是 learnable 參數。

LLM 用的變體：

RMSNorm 比標準 LayerNorm 簡單、計算稍快、品質接近、在大型 LLM（>7B）上是主流；小模型 / 訓練不穩定需要強正規化的場景下、LayerNorm 仍有實際貢獻。

Pre-Norm vs Post-Norm

Layer norm 的位置有兩個選擇：

• Post-norm（原始 Transformer paper）：先做 attention / FFN、再加 residual、再 layer norm。深層網路訓練不穩、但搭配特殊 init / warmup / 較淺層數（< 12 層）仍可用、encoder-only 模型（BERT）跟特定 transformer variant 仍走這條。
• Pre-norm（現代 LLM 主流）：先 layer norm、再做 attention / FFN、再加 residual。訓練穩定、深層網路才能訓得起來。

大型現代 LLM（Llama / Gemma / Qwen / GPT-3+）幾乎都用 pre-norm。Post-norm 在淺層 encoder 或需要 strict bottleneck 的場景仍有實際用途。

Residual Connection（殘差連接）

Residual connection 的核心定義是「sub-layer 的輸出加回它的 input」：output = sublayer(x) + x。這個結構由 ResNet（He et al., 2015）首先廣泛採用、Transformer 跟現代深度網路都用。跨層持續傳遞的 hidden state 主通道見 residual stream。

效果：

1. Gradient 直接傳遞：backward pass 中 gradient 可直接從深層流回淺層、避免 vanishing。
2. Identity 是 default：若 sub-layer 學壞、residual 確保至少不退步（output = x）。
3. Residual stream 概念：模型內部可視為一個「主流」、每層 sub-layer 對它做 incremental update。這個視角是現代可解釋性研究（mechanistic interpretability）的核心。

Positional Encoding：把順序加進去

Embedding 章節提到 attention 機制本身沒有順序資訊。Positional encoding 把位置資訊注入、讓 [cat, dog] 跟 [dog, cat] 有區別。主流方法：

Sinusoidal（原始 Transformer）

用 sin / cos 不同頻率生成位置向量、加進 token embedding：

1PE(pos, 2i) = sin(pos / 10000^(2i/d_model))
2PE(pos, 2i+1) = cos(pos / 10000^(2i/d_model))

固定值、不訓練。早期 GPT 用、後續被學習式取代。

Learned Positional Embedding

訓練一個 (max_seq_len, hidden_dim) 的矩陣、每個位置一個 embedding、加進 token embedding。GPT-2 用、簡單但有 max_seq_len 限制。

Rotary Position Embedding（RoPE）

RoPE（Su et al., 2021）的核心想法是「不加位置 embedding、而是把 Q 跟 K 在每個 attention head 內做位置相關的旋轉」：

1RoPE(Q, position) = 把 Q 的 2D 子空間按 position 旋轉特定角度

旋轉的直覺：兩個 token 在 RoPE 旋轉後做內積、結果只跟「兩者的位置差」相關、跟「絕對位置」無關。所以 RoPE 的內積天然編碼相對位置、attention 看到的是「token i 跟 token j 相隔多遠」、不是「token i 在第 N 個位置」。

優點：

• 相對位置：attention 看的是兩個 token 的相對距離、不是絕對位置。
• 無 max_seq_len：理論上可外推到任意長度（實務 degradation：超過訓練長度 4x 後品質明顯下降、超過 8x 後幾乎無用、要搭配 RoPE scaling / YaRN 等技巧）。
• 可訓練 + 不需要額外參數：旋轉角度固定、不增加模型參數。

Llama 系列、Gemma 系列、Qwen 系列都用 RoPE、目前主流。

ALiBi（Attention with Linear Biases）

ALiBi 的核心想法是「在 attention scores 加一個位置 bias、距離越遠 bias 越負」、attention 自然傾向關注近處。MosaicML 的 MPT 系列用、長 context 外推性質佳。

長 Context 的擴展技巧

LLM 在訓練長度（如 8K）以外的 context 上品質會 degradation。擴展長 context 的方法：

主流 LLM 在預訓練後做這些 scaling、把 context window 從 8K / 32K 擴展到 128K / 1M。代價是長 context 上的精度逐步下降、實用上界 < 聲稱上界。

詳見 context window 卡片。

Output Projection：從 hidden 到 logits

Forward pass 最後一步是把最終 hidden states 投射到 vocab size、得到 logits：

1logits = final_hidden_states @ W_output

W_output shape: (hidden_dim, vocab_size)。

Gemma 4 31B 的 output projection 參數約 1.3B（hidden 5120 × vocab 256,000）、跟 input embedding 同量級。如果 tied（共用權重）就只算一次；現代 LLM 多半 untied、兩者獨立。

Output 後接 softmax 轉成下個 token 的機率分佈、進入 sampling 流程。

Mixture of Experts（MoE）

Mixture of Experts 是 FFN 的擴展、把單個 FFN 換成 N 個 expert、每個 token 只 route 到 K 個 expert（K « N）。例如 Mixtral 8x7B：

• 每層有 8 個 expert FFN。
• 每個 token 由 router 選 2 個 expert 處理。
• 總參數約 47B、但每個 token 只啟動 12B 左右。

優點：總參數可超大、推論時實際算力只用一小部分。缺點：記憶體仍要載入全部 expert、訓練更複雜。

DeepSeek-V3、Qwen2-MoE、Mixtral 等是知名 MoE 模型。寫 code 場景的 Apple Silicon Mac 上 MoE 較少當主力、原因是「總參數要塞進統一記憶體（容量壓力大）」但「速度受限的是啟用權重的頻寬（速度反而可能還好）」、容量 vs 頻寬的 trade-off 跟 dense 模型不同。PC 獨立 GPU 場景可以走 CPU 卸載專家層的路徑、見 MoE CPU 卸載。

MoE 的常見失敗模式：

• Router collapse：訓練時所有 token 都 route 到同幾個 expert、其他 expert 完全沒學到東西。修法是加 auxiliary loss 鼓勵 load balancing。
• Load imbalance：推論時某些 expert 太熱門、batch 內排隊；某些 expert 閒置浪費。Production deployment 要監控 per-expert utilization。
• Memory 壓力高於 dense：總參數塞滿記憶體、但推論時實際算量只用其中一部分、容量利用率低。記憶體預算吃緊時 dense 模型反而較合適。

為什麼 LLM 是 decoder-only

現代 LLM 普遍用 decoder-only 架構、背後有幾個理由：

1. 任務統一性：「文字接龍」框架可以包進對話、寫 code、翻譯、摘要等所有任務。
2. 訓練效率：causal mask 讓所有位置可以並行訓練（每個 token 都當訓練目標）。
3. In-context learning：decoder-only 在 few-shot prompting 上特別強。

GPT-3 證明這套之後、整個產業靠攏 decoder-only。Encoder-decoder（T5 系列）仍有研究價值、但商業 LLM 主流都是 decoder-only。

下一章

下一章：3.4 訓練流程、解釋這些權重怎麼學出來。

本章從預訓練的 next-token prediction 開始、進入 instruction tuning、最後展開 RLHF 與其替代方案。寫 code 場景的使用者通常不會自己跑這些訓練、但理解流程能解釋模型行為跟版本差異。

本章目標

讀完本章後、你應該能：

1. 解釋 base model 跟 instruction-tuned model 的訓練差異。
2. 解釋 RLHF 為什麼影響 LLM 的對話風格。
3. 區分 SFT、RLHF、DPO、LoRA 在訓練流程中的位置。
4. 理解「fine-tuning 為什麼可能讓模型變差」。

階段 1：Pre-training（預訓練）

Pre-training 的核心目標是「從大量未標註文字學語言模型」、用 next-token prediction 當訓練 objective。

流程

1. 資料：trillion token 級別的網路文字、書籍、code、論文。常見資料集如 Common Crawl、RefinedWeb、The Pile、Stack、Wikipedia。
2. 任務：「給前 N 個 token、預測第 N+1 個 token」。
3. Loss：cross-entropy loss、衡量模型預測機率分佈跟實際下一個 token（one-hot）的差距、由 backpropagation 算出 gradient 更新權重。詳細展開見 2.1 機率與資訊論。
4. 訓練量：數十億 GPU-hour、數百到數萬個 GPU 並行、訓練數週到數月。
5. 結果：base model、會做文字接龍、但對話能力有限。

為什麼 next-token prediction 這麼有效

「給前文預測下一個 token」看起來是簡單任務、但要做好需要：

• 理解語法、文法。
• 理解語意、世界知識。
• 理解 reasoning（推理鏈中的下一步是 token、模型要會推理才能準確預測）。
• 理解 multi-step task（複雜程式碼跟複雜文章的下一個 token 也是 next-token problem）。

LLM 的「智能」很大程度是 next-token prediction 在大資料上的 emergent property（湧現特性）。

預訓練成本

訓練前沿 LLM 的成本：

預訓練是 LLM 訓練成本的 95%+。後續 fine-tuning 跟 RLHF 的成本是預訓練的零頭。

階段 2：Supervised Fine-Tuning（SFT、指令微調）

SFT 的核心目標是「在 base model 上、用「指令-回答」對資料微調、讓模型會跟著指令走」。

流程

1. 資料：人類標註或 AI 生成的「prompt - response」對、數萬到數百萬個樣本。
2. 任務：跟 pre-training 同樣是 next-token prediction、但只對 response 部分算 loss（prompt 部分不算）。
3. Loss：cross-entropy、只在 response token 上計算。
4. 訓練量：相對小、幾天到一週、單機可訓。
5. 結果：instruction-tuned model、會跟著 prompt 走、回答使用者問題。

SFT 的關鍵性

Base model 雖然有大量知識、但「問問題、給答案」的交互模式對它不自然。SFT 後同一個模型行為大改：

• Base model：問「寫一個 Python fibonacci」可能得到「寫一個 Python fibonacci。寫一個 JavaScript fibonacci。寫一個…」（純文字接龍）。
• Instruction-tuned：問同樣問題、得到實際 function。

寫 code 場景的所有模型都是 instruction-tuned 後的版本。Coding-tuned（如 Qwen3-Coder）是 SFT 階段大量加入 code 對話資料的特化版本。

Instruction Tuning 的資料來源

• Human-annotated：人類寫 prompt + 回答、品質高但成本高。Anthropic、OpenAI、Meta 都有自己的標註團隊。
• AI-generated：用更強的 model（如 GPT-4）生成 prompt + 回答、品質依賴 source model。Alpaca、Vicuna 是早期例子。
• Synthetic：規則生成 + LLM 改寫。Magpie、Self-Instruct 等方法。

主流模型多半混合上述三種來源。

階段 3：Alignment（對齊）

Alignment 的核心目標是「進一步調整模型、讓回答符合「helpful、harmless、honest」三個維度」。SFT 後的模型可能說出有害內容、誇大事實、給平庸答案；alignment 階段解決這些問題。

RLHF：Reinforcement Learning from Human Feedback

RLHF 是 alignment 的經典方法（Ouyang et al., 2022、InstructGPT 論文）、三步驟：

Step 1：Reward Model

1. 收集 prompt、用模型生成多個 response。
2. 人類對 response 做 pairwise 排序（「A 比 B 好」）。
3. 訓練一個 reward model、輸入 (prompt, response)、輸出一個分數、最大化「人類偏好高的 response 拿高分」。

Step 2：用 PPO 最佳化模型

1. Policy = 當前的 LLM（在 RL 框架下、模型輸出的 token 分佈被視為「策略」、所以稱為 policy）。
2. 用 RL（通常用 PPO 演算法、Proximal Policy Optimization、一種限制每步參數更新幅度的 RL 演算法、訓練比較穩）最佳化 policy、讓 reward model 給的分數最大化。
3. 加 KL constraint：policy 不能偏離 base SFT model 太遠（用 KL divergence、推導見 2.1 機率與資訊論）、避免 reward hacking。

Step 3：迭代

可以再收集人類反饋、再訓 reward model、再 RL；多輪迭代。

RLHF 後的模型在 helpfulness、harmlessness 上明顯提升、但流程複雜、訓練不穩、reward model 易被 hack。

DPO：Direct Preference Optimization

DPO（Rafailov et al., 2023）是 RLHF 的替代方案、跳過 reward model、直接用人類偏好資料 fine-tune policy：

1loss = -log(σ(β × (log π(y_w|x)/π_ref(y_w|x) - log π(y_l|x)/π_ref(y_l|x))))

其中：

• y_w：人類偏好的 response。
• y_l：人類較不喜歡的 response。
• π：當前 policy。
• π_ref：reference model（通常 SFT model）。

公式的直觀解讀：對每對 (好回答, 差回答)、拉高 π 給好回答的相對機率（比 π_ref 高）、壓低 π 給差回答的相對機率（比 π_ref 低）、β 控制偏離 π_ref 的力度。σ 是 sigmoid、把整體 score 壓到 (0, 1) 區間。

DPO 比 RLHF 簡單、不用訓 reward model、不用 RL 演算法、訓練穩定、在「離線偏好資料量充足 + 偏好相對穩定」的場景是 2024 ~ 2026 主流選擇。Llama 3、Gemma 4 等都用 DPO 或變體。

其他替代方案

主流前沿 LLM 用 SFT + DPO（或變體）的組合；資料量足夠 + 偏好穩定時 DPO 較佳、需要 online 人類反饋或 reward shaping（複雜環境互動、多輪偏好調整）的場景下 PPO 仍有實際空間、特別是 reasoning model（DeepSeek-R1 等）的後訓練階段。

Fine-tuning：在 instruction-tuned model 上做特化

「Fine-tuning」這個詞在 LLM 社群有兩層意思：

1. SFT 階段（前面提的）：base model → instruction-tuned model。
2. 下游 fine-tuning：使用者在 instruction-tuned model 上、用自己的資料再 fine-tune、做特定領域特化。

下游 fine-tuning 的常見方法：

Full Fine-tuning

更新模型所有參數。需要大量 GPU、Gemma 4 31B 全參數 fine-tune 要 8 × H100 起。品質好、但成本高、容易過擬合小資料。

LoRA（Low-Rank Adaptation）

LoRA（Hu et al., 2021）的核心想法是「凍結 base model 權重、只訓練一組小的 adapter 矩陣」：

1W_new = W_frozen + α × A @ B

其中 A、B 是低秩矩陣（rank=4 ~ 64）、總參數遠少於 full fine-tune。

優點：

• 記憶體佔用 1/10 ~ 1/100。
• 訓練快得多。
• 多個 LoRA adapter 可以共用同一個 base model、推論時切換。
• 不會破壞 base model（凍結）。

LoRA 是 consumer 級硬體做 fine-tuning 的主流選擇。32GB Mac + MLX 可以跑 7B / 14B 模型的 LoRA fine-tuning。

LoRA 何時不適用 / 必須走 full fine-tune：

• 大幅行為改變：要把模型從通用 chat 轉成完全不同的人設 / 風格 / 領域。LoRA rank 容量有限（rank=4 ~ 64 對應幾百萬 ~ 幾千萬參數）、裝不下整體行為的大幅改寫；rank 拉到 256+ 後 LoRA 的記憶體優勢消失。
• 跨 domain transfer：base model 是 general English、想 fine-tune 到醫學 / 法律等需要重學 vocab 跟結構的 domain。LoRA 只調整現有 layer 的偏移、難以從零學新 domain；通常要先做 continued pre-training（full fine-tune）再 LoRA。
• 跟量化推論的相容性：base model 用 Q4 推論時、要先 dequantize 才能加上 LoRA delta、會導致 latency / memory 增加；production 場景常用 QLoRA + 在推論時 merge 回 base、避免每次推論都拆兩段。

QLoRA

QLoRA = Quantized LoRA、把 base model 量化到 4-bit、再做 LoRA。記憶體進一步降低、犧牲少量品質。

為什麼 fine-tuning 可能讓模型變差

下游 fine-tuning 對寫 code 場景的多數使用者價值有限、原因：

1. 過擬合：fine-tune 資料量小、模型可能學到 spurious pattern、在 fine-tune 領域外能力下降。
2. Catastrophic forgetting：學新資料時忘記舊知識、原本會的東西變差。
3. 資料品質決定上限：fine-tune 資料品質低、模型學到低品質回答。
4. Alignment 退化：fine-tune 可能破壞 RLHF / DPO 階段建立的「helpful、harmless」性質。

寫 code 場景優先用 instruction-tuned 通用模型（Gemma 4、Qwen3-Coder 等）、需要特化再評估 RAG 或 prompt engineering、最後才考慮 fine-tuning。三條路的取捨判讀見 4.1 RAG 原理。

In-Context Learning：fine-tuning 的替代品

In-context learning（ICL）的核心想法是「不更新模型權重、只在 prompt 中給範例、讓模型 generalize」。

• Zero-shot：直接給任務描述、不給範例。
• Few-shot：給幾個 input-output 範例、再給新 input。
• Chain-of-thought：要求模型把推理過程寫出來、再給答案。

GPT-3 paper 顯示大模型有強 ICL 能力、不用 fine-tune 就能做新任務。現代 LLM 進一步強化 ICL、加上 long context、agent loop、function calling 等技術、覆蓋大部分原本需要 fine-tune 的場景。

實務啟示：「想做新任務、先試 prompt engineering、不夠再試 RAG、最後才考慮 fine-tuning」。fine-tuning 是最重的投資、適合放在最後驗證、prompt engineering 跟 RAG 跑完仍不夠才動。

訓練資料污染（Data Contamination）

訓練資料污染指「benchmark 的測試集出現在預訓練資料中」、模型「記住答案」而非真正能解問題。

問題：

• 公開 benchmark（SWE-bench、MMLU 等）的測試題常出現在 GitHub / 論壇、進入預訓練資料。
• 模型在這些 benchmark 上分數可能高估真實能力。

解決：

• SWE-bench Verified：OpenAI 篩選過、相對乾淨的子集。
• HELM：Stanford 的 holistic 評估、含污染檢測。
• 新 benchmark：每隔一段時間出新 benchmark、用尚未被 LLM「看過」的資料。
• 自己跑 benchmark：用自己工作流的真實任務評估、繞過所有污染問題。

詳見 SWE-bench 卡片 跟 模組零 0.6 判讀框架 的框架二（量化宣稱三變數）。

下一章

下一章：3.5 sampling 與 decoding 策略、模型輸出後怎麼挑下一個 token。

本章拆開主流 sampling 策略的機制、各自適合的場景、以及 temperature、top_p 這些常見參數在這條鏈上的位置。

本章目標

讀完本章後、你應該能：

1. 解釋 temperature=0 跟 temperature=0.8 的具體差別。
2. 區分 top-k、top-p、min-p 三者的機制。
3. 看到 repetition_penalty=1.1 設定時、知道它解什麼問題。
4. 解釋為什麼確定性測試要設 temperature=0 + seed。

從 logits 到下個 token

複習一下 LLM 輸出端的鏈：

1final hidden states → output projection → logits → temperature → softmax → 機率分佈
2→ sampling 策略 → 下個 token

各環節在 sampling 中的位置：

實際參數順序視推論伺服器實作而異、但概念上是這條鏈。

Greedy Decoding：永遠選機率最大

Greedy decoding 的核心定義是「每步選 softmax 後機率最大的 token」：

1next_token = argmax(probabilities)

特性：

• 確定性：同 prompt 永遠生同樣輸出。
• 快：不用 sampling、不用算 cumulative probabilities。
• 缺點：傾向選最常見 pattern、輸出單調；常陷入 repetition loop。

實務用途：

• Reproducible 評估：跑 benchmark、自動測試。
• 單元測試：確保模型輸出可預測。
• 某些 reasoning chain：選最有信心的下一步。

效果上等同 temperature=0、許多推論伺服器把兩者當同義詞。

Beam Search：保留 top-K 條候選序列

Beam search 的核心想法是「每步保留累積機率最大的 K 條序列、每條繼續展開、最後選整體機率最高的」。K 叫 beam size。

特性：

• 全局較優：不只看當步、考慮整段序列。
• 適合「有正確答案」的任務：翻譯、摘要、code 生成。
• 缺點：對 open-ended 生成（聊天、創意寫作）會 collapse 到平庸、缺乏多樣性。

具體失效症狀：K=5 在 chat 場景常產生「Sure!」「Thank you」「That’s a great question」這種高頻 boilerplate、各 beam 探索的方向都收斂到相似的平庸開頭、明明 logit 分佈本來該保留的多樣性被 beam 平均化掉。

Chat / 對話場景多半不用 beam search、用 sampling 策略保留多樣性。

Temperature：調分佈尖銳度

Temperature 的機制在 模組二 2.1 已經詳細展開。簡單回顧：

1adjusted_logits = logits / temperature
2probabilities = softmax(adjusted_logits)

實務經驗：

• 寫 code 場景設 0.2 ~ 0.4 較穩。
• 創意任務（寫故事、brainstorming）設 0.8 ~ 1.0。
• Reproducible 測試設 0 + 固定 seed。
• T > 1.5 失效症狀：產出開始出現拼字錯誤、語法破洞、UTF-8 byte 混亂、甚至跨語言突然切換；極端 T 等同近 uniform 分佈、模型結構被當作 dice。

Temperature 在 sampling 鏈上的位置（行 26 的流程鏈）跟其他過濾步驟有疊加順序、值得展開：

1. Temperature 先動分佈尖銳度：高 T 把分佈拉平、低 T 拉尖。
2. 再過 top-p / top-k / min-p：在拉平 / 拉尖後的分佈上做候選過濾。
3. 兩者相乘的常見坑：高 T（如 1.5）+ 低 top-p（如 0.5）= 「分佈被拉平、然後只挑前幾名」、實際出現的多樣性反而被壓縮、容易出現語義跳動。穩健做法：固定其中一個（多半是 top-p=0.9）、調另一個。
4. Reasoning model 的特殊性：o1、DeepSeek-R1 等內建 chain-of-thought 的模型、官方建議 T=0 或 1.0、調 T 會破壞 reasoning trace 連貫性。

Top-K Sampling

Top-K sampling 的核心定義是「只考慮機率最大的 K 個 token、其他設 0、重新正規化後取樣」：

11. 對機率排序、取最大的 K 個。
22. 其他設 0。
33. 重新正規化（讓總和為 1）。
44. 從正規化分佈取樣。

K 控制候選範圍：

缺點：K 是固定值、無法適應分佈尖銳度。當分佈尖銳時（一個 token 機率 90%）、K=40 包括很多近 0 機率的雜訊；當分佈平坦時（每個 token 機率 1%）、K=40 過於限制。具體失效症狀：在 code 生成情境、模型對「下一個 token 是 )」極度確定（95%+ 機率）時、K=40 把後面 39 個近零雜訊也納入候選、偶爾 sample 出語法錯的字元；改用 top-p 或 min-p 可避開。

Top-P / Nucleus Sampling

Top-P sampling（也叫 nucleus sampling、Holtzman et al., 2019）的核心想法是「動態決定候選集大小」：

11. 對機率從大到小排序。
22. 從大到小累加、直到累積機率 ≥ P（如 0.9）。
33. 只保留這些 token、其他設 0。
44. 重新正規化、取樣。

例：

• 分佈尖銳（一個 token 機率 95%）：P=0.9 可能只選 1 ~ 2 個 token。
• 分佈平坦（top 10 各 5%）：P=0.9 可能選 15 ~ 20 個 token。

P 的常用值：

在 chat / coding 場景下 top-p 是主流選擇、比 top-K 彈性；reproducible 評估則回到 greedy（T=0）、不用 sampling。多數推論伺服器預設 top_p=0.9。

Min-P：自適應閾值 sampling

Min-P sampling（2024 ~）的核心想法是「設一個機率閾值、最大機率 token × P_min 以下的全部去掉」：

11. 找出最大機率 p_max。
22. 閾值 = p_max × P_min（如 0.1）。
33. 機率 < 閾值的 token 全部設 0、重新正規化。

特性：

• 自動適應分佈尖銳度（用比例而非絕對值）。
• 比 top-P 更穩定、近一兩年在開源社群興起。
• LM Studio、llama.cpp 等支援。

P_min 常用值：

Repetition Penalty

Repetition penalty 的核心想法是「對已出現的 token 降低機率、避免無限重複」：

1adjusted_logit(token) = logit(token) / repetition_penalty   if token 已出現
2                      = logit(token)                          if token 沒出現

P 大於 1 時、已出現 token 的 logit 被降低、後續 sampling 較難選到。

代價：寫 code 場景下、if、for、return 等關鍵字常出現、太高的 repetition penalty 會壞掉 code。寫 code 場景 penalty 設低（1.0 ~ 1.05）或關閉；creative writing 場景則設 1.1 ~ 1.2、避免段落 / 句子層級的重複。

Seed：固定 sampling 的隨機性

Sampling 用 random number generator 取樣。設定 seed 讓 RNG 確定性、相同 prompt + 相同 seed 給相同輸出：

1{
2  "temperature": 0.7,
3  "top_p": 0.9,
4  "seed": 42
5}

實務用途：

• Reproducible 評估：跑 benchmark 要可重複。
• A/B 測試：對比不同 prompt 在同 seed 下的差異。
• Debug：重現一個錯誤輸出。

注意：seed 不是所有伺服器都支援、OpenAI API 是 best-effort（同 seed 不保證完全一致）、本地伺服器多半支援嚴格 seed 控制。

Logit Bias：強制 / 排除特定 token

Logit bias 的機制是「對特定 token 的 logit 加減一個固定值」：

1adjusted_logit(token) = logit(token) + bias(token)

用途：

• 強制特定 token：bias = +100、softmax 後機率近 1。
• 完全禁止：bias = -100、softmax 後機率近 0。
• 微調傾向：bias = ±5、輕微傾斜。

實務用例：

• 強制輸出 JSON 格式：對 { 加 bias 在開頭。
• 避免特定詞：對敏感詞加負 bias。
• 約束輸出：限制只能用特定 vocabulary。

OpenAI、Ollama 等多數推論伺服器支援 logit_bias 參數。

Structured Output / Constrained Decoding

Structured output 的核心想法是「sampling 時加 grammar 約束、強制輸出符合特定結構（JSON、SQL、regex 等）」。實作方法：

• JSON mode：每步只允許「能讓 JSON 仍合法」的 token。
• Grammar-based：用 BNF / lark / etc. 定義語法、sampling 時 reject 違反語法的 token。
• Token mask：依當前狀態決定哪些 token 合法、不合法的 logit 設 -∞。

實務工具：

• llama.cpp 的 grammar 參數。
• Outlines、LMQL 等 framework。
• OpenAI 的 response_format: { type: "json_schema" }。

寫 code 場景中、structured output 對「要可解析的輸出」（如 commit message 格式、structured API call）很有用。

Decoding 策略對體感的影響

下表是寫 code 場景下、不同 decoding 配置的體感：

實務建議：寫 code 場景下 temperature=0.2 ~ 0.4、top_p=0.9 ~ 0.95、其他保留預設就好。Continue.dev 等 IDE 整合多半自動調整。

下一章

下一章：3.6 tokenization 算法、補完 input / output 端的細節。

本章拆開四個主流 tokenization 算法（BPE、WordPiece、Unigram、SentencePiece）、解釋 vocabulary 怎麼學出來、為什麼中文 / 中日韓字幾乎一字一 token、tokenizer 為什麼影響 speculative decoding 的相容性。

本章目標

讀完本章後、你應該能：

1. 解釋 BPE（Byte-Pair Encoding）的工作原理。
2. 看到不同 model 切同段文字得到不同 token 數時、知道原因。
3. 解釋為什麼 drafter 跟 target 必須共用 tokenizer。
4. 看到 vocab_size = 256,000 vs 128,256 時、知道差異在哪。

Tokenization 的設計目標

理想 tokenizer 要同時滿足：

1. 覆蓋率高：能 encode 任何文字、不會「碰到沒見過的字壞掉」。
2. 效率高：常見字串切成少數 token、節省 context 與計算。
3. 語意保留：保留有意義的 sub-word 邊界（「unhappy」切成 un + happy 比 unh + appy 好）。
4. 跨語言公平：英文跟中文 / 日文 / 阿拉伯文等都用合理數量的 token。

不同算法在這四個目標上有不同取捨。

早期方法：word-level 跟 char-level

Word-level Tokenization

最簡單的方法是「用空白跟標點切」、每個 word 一個 token。

優點：直觀。

缺點：

1. Vocabulary 爆炸：英文有幾百萬個 word forms（含複數、時態、複合詞等）。
2. OOV（out-of-vocabulary）：新詞、typo、URL、混合語言完全壞掉。
3. 中文 / 日文沒有空白：要先做 word segmentation。

現代 LLM 已淘汰 word-level、主流改用 subword 系列。

Char-level Tokenization

另一個極端是「每個 character 一個 token」。

優點：vocabulary 小、無 OOV。

缺點：序列變很長（一句話幾十到幾百 char、效率低）、模型要從很基礎學起、訓練不效率。

現代 LLM 也跳過純 char-level、改用 subword 折衷。

折衷：Subword Tokenization

主流方案是「subword tokenization」：常見字串當一個 token、罕見字串切成更小單位（甚至到 char 級別）。三個主流算法：

Vocabulary size 跟 special tokens 是這幾個算法產出的 tokenizer 共同的概念維度。

BPE：Byte-Pair Encoding

BPE（Sennrich et al., 2016）的核心想法是「貪婪地合併最常出現的字元對」、迭代到 vocabulary 達到目標大小。

訓練流程

1. 初始 vocabulary：所有 character。
2. 統計訓練語料中、所有相鄰 character pair 的頻率。
3. 把頻率最高的 pair 合併成一個新 token、加進 vocabulary。
4. 用新 vocabulary 重新 tokenize 語料、重複 step 2-3。
5. 直到 vocabulary 達到目標大小（如 50,000、100,000）。

例：

1初始：l o w e r → 5 個 token
2步驟 1：合併 'l' + 'o' = 'lo'、變成 lo w e r → 4 個 token
3步驟 2：合併 'lo' + 'w' = 'low'、變成 low e r → 3 個 token
4步驟 3：合併 'e' + 'r' = 'er'、變成 low er → 2 個 token

訓練後、lower 就是 2 個 token。

Byte-level BPE

原始 BPE 在 character level 運作、但「character」依語言而異（Unicode 字元複雜）。Byte-level BPE 在 byte level 運作、任何文字都可以 encode 成 byte 序列、自然支援多語言。

GPT-2 / GPT-3 / GPT-4 / Llama 系列都用 byte-level BPE。

Tiktoken：OpenAI 的高效實作

Tiktoken 是 OpenAI 開源的 BPE 高效實作、Python 套件。可以拿來算「這段文字在 GPT-4 上是多少 token」：

1import tiktoken
2enc = tiktoken.encoding_for_model("gpt-4")
3tokens = enc.encode("Hello, world!")
4print(len(tokens))   # 4

Tiktoken 是估算 OpenAI API 費用的標準工具。其他模型有各自的 tokenizer 套件（Llama 的 sentencepiece、Hugging Face 的 transformers.AutoTokenizer）。

WordPiece：BERT 的選擇

WordPiece（Schuster & Nakajima, 2012、後來 Google 用在 BERT）跟 BPE 類似、但合併策略不同：

• BPE：合併「最頻繁出現的 pair」。
• WordPiece：合併「合併後 likelihood 最大化的 pair」（更貴的計算、但理論上更好）。

實務差異微小。BERT 系列用 WordPiece、現代 LLM 大多回到 BPE 系列。

Unigram：機率式 subword

Unigram（Kudo, 2018）是另一條主流 subword 算法、跟 BPE 的「greedy 從下往上合併」相反、它從一個很大的 candidate vocabulary 開始、用機率模型逐步刪掉 likelihood 貢獻最小的 token：

1. 起點：一個包含大量 candidate subword 的初始 vocab（可從訓練資料抓所有 substring）。
2. 用 EM 算法估每個 candidate 的機率、把整段文字 tokenize 成 likelihood 最大的 segmentation。
3. 評估「刪掉某個 candidate 後 total likelihood 損失多少」、刪掉損失最小的一批。
4. 重複到 vocab 達目標大小。

跟 BPE 的本質差異：

• BPE：每個輸入文字只有一個切法（merge 規則決定）、結果是 deterministic。
• Unigram：每個輸入可能對應多個合法 segmentation、訓練時用機率挑、推論時取 top-1。這個性質讓 Unigram 天然支援 subword regularization（訓練時隨機取不同 segmentation、增強 robustness）。

Unigram 是 SentencePiece 預設算法、T5、Gemma 系列訓練時用。實務上 Unigram 跟 BPE 的最終 tokenization 接近、選擇看「訓練時要不要做 subword regularization」。

SentencePiece：Google 的開源實作

SentencePiece（Kudo & Richardson, 2018）是 Google 開源的 tokenization 套件、可實作 BPE 或 Unigram 算法、設計上：

• 語言無關：把輸入當 byte 流處理、不假設「word boundary 是空白」。
• 無前處理：不用先切 word、適合中文 / 日文等無空白語言。
• 可逆：tokenize → detokenize 完全還原原文。

Gemma 系列、PaLM、T5 用 SentencePiece。實務上跟 BPE 表現接近、差異主要在「對中日韓文等無空白語言更友善」。

Vocabulary 大小

各 LLM 的 vocabulary 大小：

Vocabulary 大小的取捨：

Gemma 4 的 256K vocab 是現代 LLM 中較大的、目的之一是多語言支援。

同段文字在不同 tokenizer 上的差異

實測「The quick brown fox jumps over the lazy dog」：

差異不大。但中文「敏捷的棕色狐狸跳過懶狗」：

Llama 2 的 32K vocab 對中文支援差、Llama 3 / Gemma 4 改善很多。實務影響：中文 prompt 在 Llama 2 上吃 context 多、Gemma 4 較友善。

Tokenizer 跟模型相容性

Speculative decoding 要 target 跟 drafter 共用 tokenizer、因為兩者必須對「下個 token」的概念一致：

• Gemma 4 31B + Gemma 4 E4B：同 tokenizer、可以配對。
• Gemma 4 + Llama：不同 tokenizer、配不起來。

理解這點、能解釋為什麼 LM Studio 的 draft model UI 自動過濾相容候選、為什麼 Ollama 的 gemma4:31b-coding-mtp-bf16 model tag 內含 drafter 而不能自己組合不同家族。

Special Tokens

除了 vocabulary 中的「正常」token、還有特殊 token：

• <BOS> / <bos>：Beginning of sequence、prompt 起點。
• <EOS> / <eos>：End of sequence、生成結束。
• <PAD>：Padding、batch 訓練時補齊長度。
• <UNK>：Unknown token（現代 BPE 少用、因為 byte-level 覆蓋所有字元）。
• <|im_start|> / <|im_end|>：ChatML 格式中區隔每段訊息的邊界 token。
• ChatML 中的 role 名稱（system / user / assistant）寫在 <|im_start|> 之後當作文字內容、不是獨立 token；模型靠「<|im_start|> + 後接 role 字串」這個 pattern 識別說話者。

聊天 LLM 的 prompt 實際長相是用 special tokens 標記 role 跟訊息邊界，而非純文字：

1<|im_start|>system
2You are a helpful assistant.<|im_end|>
3<|im_start|>user
4Hello!<|im_end|>
5<|im_start|>assistant

不同模型的 chat template 不同、Ollama / Continue.dev 等工具自動處理、但若自己呼叫 API 要注意 template 對不對。

Tokenization 引發的 bug

Tokenizer 設計的副作用：

Glitch Tokens

某些 token 在訓練資料中很少出現、模型對它們的行為怪異。Reddit 上著名的 SolidGoldMagikarp 就是 GPT-2 / GPT-3 的 glitch token、模型遇到會出現奇怪反應。原因：tokenizer 學了這個 token、但訓練資料中幾乎沒上下文、模型沒學到它的語意。

數字 tokenization

早期 BPE 對數字的處理不一致：1234 可能切成 123 + 4、1235 可能切成 12 + 35。模型對「數字加法」表現差跟這個有關。

現代 LLM 多半把每個 digit 各自當一個 token（一致 tokenization）、改善數學能力。

Code 的 indentation

寫 code 場景的 tokenizer 要妥善處理 indentation。早期 LLM 把多個空白合併成一個 token、code 結構壞掉；現代 LLM（特別是 coding-specialized）把 4 空白 / 8 空白等常見 indentation 各自當一個 token。

跟 context window 的關係

Context window 的單位是 token、不是字。1M token 的 context window 在英文約等於 750K 字、在中文約 1M 字（看 tokenizer）。

實務啟示：

• 「128K context」在不同 tokenizer 上實際容量不同。
• 計算 API 費用要用該模型的 tokenizer 算 token 數。
• 中文 prompt 用 Llama 2 比 Llama 3 / Gemma 4 吃 context 多。

下一章

下一章：3.7 想學更深：推薦公開課程。

本章寫的是「跨語言能力為什麼這樣分佈」「該如何依場景選語言」的原理層。具體模型在 2026/5 的中文 / 多語言 benchmark 不在本章——這些隨新模型版本變、用本章的雙因素 framework 重新評估就好。

本章目標

讀完本章後、你應該能：

1. 解釋為什麼模型在不同語言上表現不一致、有哪兩個獨立因素。
2. 看到 tokenizer 對中文「一字切 N token」時、知道對 context cost 跟能力的影響。
3. 判讀「該翻英寫 prompt 還是維持中文」的取捨。
4. 解釋為什麼跨語言 reasoning 比 monolingual reasoning 容易失敗。

為什麼模型對不同語言表現不一致：雙因素

模型對不同語言的表現受兩個獨立因素疊加影響：

因素 1：Tokenizer Vocab Coverage

Tokenizer 把文字切成 token、tokenizer vocab 大小指 tokenizer 認識的 token 種類數（vocab 越大、能切得越細、越能用單一 token 表達常見字）。不同 tokenizer 對不同語言的切割密度不同：

• 英文中心的 tokenizer（如 Llama 2 的 32K vocab）對 vocab 沒涵蓋的中文字會 fallback 到 byte 級切割（UTF-8 一個中文字常用 3 個 byte、所以變 3 個 token）。
• 多語言 tokenizer（如 Gemma 4 的 256K vocab）把常見中文字當獨立 token 收進來、對中文多半一字一 token、跟英文接近。

完整的 BPE / WordPiece / Unigram / SentencePiece 算法見 3.6 tokenization 算法。

Tokenizer 影響三件事：

• Context 成本：同樣 prompt 在不同 tokenizer 上吃 token 量級不同、API 費用、context window 利用率都跟著差。
• Token 粒度：粗粒度 tokenizer 對某語言的「字」切割不細、影響模型對該語言細微差異的辨識。
• 訓練效率：tokenizer 切得好、模型每個 token 學到更多語意、訓練收斂快。

因素 2：訓練資料分佈

模型預訓練資料的語言佔比決定模型「學了多少」這個語言：

• Common Crawl 等主流預訓練資料英文佔 70%+、中文約 1-3%、其他語言更少。
• 即使 tokenizer 對某語言支援好、訓練資料少仍會限制模型在該語言上的能力。

訓練分佈影響三件事：

• 事實準確度：訓練資料少 → 該語言的事實覆蓋低 → hallucination 多。
• Reasoning 深度：複雜推理需要大量該語言範例支撐、訓練少就退化。
• 風格自然度：訓練少的語言、模型輸出語法 OK 但 idiom / 慣用搭配偏直譯。

雙因素的獨立性

兩個因素獨立、各自影響不同維度：

判讀模型某語言能力時、兩個因素都要評估、單看一個會誤判。「Gemma 4 vocab 對中文好」不代表「中文表現一定好」、還要看訓練資料佔比。「OpenAI 訓練資料量大」不代表「對所有語言都好」、還要看 tokenizer 設計。

Tokenizer Vocab 對非英文的影響

Tokenizer vocab 設計直接決定中文 context 成本量級、差距可達兩倍以上。具體看 tokenizer 對中文的影響（以下為各 tokenizer 對該句的近似切割、實測會 ±20%、用作量級對照、不含 system prompt / response budget）：

數字差異看似不大、累積起來影響顯著：

• 128K context 的「實際容量」：以中文每字平均 token 數估算、Llama 2（約 2.2 字 / token 的反比、即一字 ≈ 2-3 token）對中文約 6K 中文字、Gemma 4（接近一字一 token）對中文約 14K 中文字、差兩倍以上（估算未含 system prompt + response budget、實際可用更少）。
• API 費用：同樣中文 prompt、Llama 2 費用是 Gemma 4 的兩倍以上（按 token 收費的話）。
• 長 prompt 的 prefill 時間：token 多 prefill 慢、TTFT 受影響。

但這只是其中一個因素。Tokenizer 改進不會自動讓模型「懂」這個語言——還要訓練資料配合。Llama 3 vocab 比 Llama 2 大很多、但對中文表現的提升不只是 vocab 帶來的、也是訓練資料多語言比例提升的結果。

訓練資料分佈：語言佔比決定能力

Web 文字的語言分佈嚴重不平衡。Common Crawl 跟同類資料源的語言佔比約：

• 英文：60-70%
• 中文：2-5%
• 西班牙文、葡萄牙文、日文、法文、德文：各 1-3%
• 其他幾百種語言：合計 < 10%

模型預訓練多半反映這個分佈。即使「主打多語言」的模型、英文仍是主導。

實務影響：

• 事實準確度：問模型「台灣某縣市的人口」這類本地化問題、中文回答的準確度通常低於英文回答同個問題（即使翻譯為相同 query）。
• Reasoning 深度：複雜中文推理（如解中文奧數題）、模型可能「翻譯成英文 reasoning、再翻回中文」、中間步驟跳過、答案合理但推理鏈不通。
• 風格 / 慣用語：中文輸出可能語法 OK、但 idiom 與慣用搭配偏直譯、詞彙選擇偏「翻譯腔」。
• 長尾事實：訓練資料少的語言、長尾事實更容易 hallucinate。

判讀模型在某語言上的能力強弱、看訓練資料佔比是主要訊號。Qwen 系列訓練資料大量中文、中文能力強；Llama 系列訓練資料英文為主、即使最新版中文表現仍弱於 Qwen 在中文上的表現。

兩因素的獨立性對實務的影響

雙因素獨立、實際模型多半落在某個組合狀態：

Gemma 4 / Qwen3 / Llama 3 主流開源旗艦：

• Tokenizer：多語言、vocab 256K 級、中文 token 效率接近英文。
• 訓練資料：中英都有大量比例、Qwen 中文比例高、Llama 英文比例高。
• 結果：中文能力接近 native level、跨語言能力差距縮小。

OpenAI / Anthropic 雲端旗艦：

• Tokenizer：tiktoken 等、中文 token 效率中等。
• 訓練資料：規模極大、所有語言絕對量都多（即使相對佔比低）。
• 結果：中英都強、絕對能力受訓練規模支撐。

早期 Llama 2 / 純英文模型：

• Tokenizer：32K 英文中心、中文切散。
• 訓練資料：英文主導、其他語言極少。
• 結果：中文勉強可讀、不建議用於對輸出品質有要求的工作場景。

判讀新模型對某語言能力時、先看這兩個因素、再參考實測——比直接看 benchmark 數字準。

中文 Prompt 何時該翻英：機會成本判讀

寫 code 場景常見問題「該用中文還是英文寫 prompt」、答案取決於三個變數：

變數 1：模型在中英的能力差距

主流開源旗艦（Gemma 4 / Qwen3 / Llama 3）中英差距已縮小、寫 code 場景中英 prompt 表現接近。早期 / 較小模型差距大、英文 prompt 較穩。

判讀：用較強模型可以維持中文、用較弱模型考慮翻英。

變數 2：翻譯成本

翻譯成本包括：時間、認知負擔、可能的精度損失。

• 簡短 prompt（補完、寫單個 function）：翻英成本低、可考慮。
• 長 prompt（描述複雜需求、多個檔案 context）：翻英成本高、維持中文較划算。
• 含技術術語的 prompt：英文是 LLM 訓練的主流、術語維持英文較好（即使句子是中文也保留英文 keyword）。

變數 3：輸出語言要求

• 要中文回答（如寫中文 docs、跟中文團隊溝通）：維持中文 prompt 一致性較好。
• 要英文回答（如 commit message、open source PR）：英文 prompt 自然引導英文輸出、不需 explicit instruct。

綜合判讀

寫 code 場景的多數情境（主流模型 + 短 prompt + 維持原語言輸出）：直接用中文寫即可、不必特別翻英。例外：

• 用較弱模型（< 14B）、英文較穩。
• 特殊領域（法律、醫療、學術）、英文資料豐富、翻英可能更穩。
• Domain-specific reasoning（數學、邏輯）、英文訓練資料多、翻英可能改善 reasoning 鏈。

「直覺說該翻英」常是過度小心、實測通常發現中文跟英文 prompt 表現接近、翻譯成本浪費。

Commit / Docstring / 註解的語言選擇取捨

寫 code 場景的「該用什麼語言」決策多半取決於非模型因素：

Commit Message

• 團隊一致性：團隊都用英文就英文、都用中文就中文。
• 長期保留：commit message 進 git 歷史、長期保留、跨團隊成員 / 外部貢獻者讀。
• 可讀性受眾：團隊有非中文 reader 就英文、純中文團隊用中文也 OK。
• 隱私 / 合規：commit 進 git、可能進 public repo、敏感資訊不該寫進去（不論語言）。

模型對中英 commit message 都能寫、選擇主要看團隊跟 repo 屬性、不是看模型偏好。

Docstring

• 語言生態慣例：Python / JavaScript 開源社群慣例是英文 docstring；JetBrains / 微軟在地化文件多中文。
• API consumer：API 給誰用、用什麼語言。
• 自動化工具：docs generator、type checker、IDE hint 對英文 docstring 支援較成熟。

程式內註解

• 團隊母語 vs 國際慣例：團隊母語寫註解最自然、國際慣例（特別 open source）多英文。
• 複雜邏輯：用最能精確表達的語言寫、不一定要英文。
• TODO / FIXME：跟團隊慣例一致。

這些決策本質上是團隊跟生態問題、不是 LLM 問題。LLM 對中英都能 handle、選哪個取決於 downstream 讀者。

跨語言 Reasoning 的失敗訊號

跨語言 reasoning（如中文 prompt 要求模型用中文推理過數學題、或用中文回答需要英文事實 retrieval 的問題）容易出現幾種失敗：

內部翻譯失敗

模型「中文 prompt → 內部翻譯成英文 reasoning → 翻回中文輸出」、中間步驟跳過、中文輸出看起來合理但推理鏈不通。

判讀訊號：要求模型「請用中文逐步推理」、模型輸出推理鏈不連貫、步驟跳躍。

緩解：強制 step-by-step prompt、或乾脆翻英 prompt 拿英文輸出、再人工譯回中文。

訓練語言切換

模型在某語言上 reasoning 訓練不足、即使理解 query、輸出推理深度受限。

判讀訊號：中文 query 拿到淺薄答案、同樣 query 翻英拿到深入答案。

緩解：複雜推理任務用英文 prompt + 英文輸出、最後再翻譯。

Tokenizer 引發的細節遺失

中文一字切多個 token 時、模型可能在 token 邊界誤判語意、輸出細節不準。

判讀訊號：細節錯（罕用字 OOV 被切成 byte / 數字本身切分不一致導致算術出錯）、英文同義問題不會錯。

緩解：對細節敏感的任務（數字、日期、人名）強調確認、或翻英降低 tokenizer 誤判機率。

何時跨語言 reasoning 不會失敗 / 何時翻英無收益

上述三類失敗模式不會均勻發生在所有跨語言任務上、實際觸發條件是「深度推理 + 語言 specific 事實 retrieval」雙條件命中。以下情境通常翻英沒收益、留在中文 prompt 反而省事：

• Code 補完、語法重構、加 type annotation：code 本身就跨語言、模型不需要「翻譯」code、中文 prompt 直接寫即可。
• 短 QA、context-rich prompt：問題本身就含完整 context（如「這段程式碼做什麼」+ code）、模型不需要做 retrieval、reasoning 深度需求低。
• 格式 / 結構轉換：JSON 轉 YAML、Markdown 重排、tabular 整理 — 任務機械化、跟語言關係小。
• 單檔 refactor：選定範圍內的改寫、不需跨檔 retrieval、推理深度受 context 限制而非語言。
• commit message / docstring 草稿：套用 template 性質、模型輸出語言跟 prompt 一致較自然。

需要翻英的場景集中在「深度推理（多步邏輯 / 數學）」+「需要 retrieval 語言 specific 事實（如某個 framework 的 API、特定論文細節、英文社群討論）」這兩條都命中時、其他場景翻譯成本是浪費。

Code 跟自然語言的不對稱

Code 本身是「英文偏向」的：keyword（if、for、return）、變數名（多半 ASCII）、API（多半英文）。LLM 對 code 的能力跨語言差距較小——code 本身就跨語言、模型不需要「翻譯」code。

但「code + 自然語言」的混合場景仍受自然語言訓練分佈影響：

• 寫 code + 中文 docstring：模型寫 code 表現一致、寫 docstring 受訓練分佈影響。
• 解釋 code 給人聽：用哪種語言解釋、受該語言訓練分佈影響。
• 改寫 code 註解：改 code 行為一致、改自然語言部分受訓練分佈影響。

判讀「該不該翻英」時、要區分「code 部分」跟「自然語言部分」。Code 部分中英差距小、自然語言部分中英差距視模型而定。

何時過時 / 何時不過時

不會過時的部分：

• Tokenizer + 訓練分佈雙因素 framing。
• 跨語言能力受結構性限制的本質（不只是「模型不夠強」）。
• 三個變數判讀（能力差距、翻譯成本、輸出語言要求）。
• 跨語言 reasoning 失敗模式的分類。
• Code 跟自然語言的不對稱觀察。

會變的部分：

• 具體模型在特定語言上的當下能力（會隨新模型版本變、Gemma 5 / Qwen4 等出來會再變）。
• 各 tokenizer 的 vocab 大小（會調整）。
• 訓練資料的多語言比例（業界正在改善）。
• 哪些模型「中文能力好」的具體 ranking。

看到新模型時、回到雙因素 framework 評估：tokenizer vocab 多大、中文 token 效率如何、訓練資料中文佔比、實測中文表現是否符合預期——這個 framework 不變、評估結果會隨模型版本更新。

下一章

下一章：3.8 Reasoning models、看 2024-2026 的 test-time compute paradigm。完整公開課推薦見 3.10 想學更深。

本章不重複 chain-of-thought 跟 test-time compute 卡片的定義、聚焦「reasoning model 怎麼運作、怎麼跟本地工作流結合」。

本章目標

讀完本章後、你應該能：

1. 解釋「reasoning model」相對 instruct model 的訓練差異。
2. 看到 <think>...</think> 標記或「extended thinking」field 時、知道是 reasoning trace、怎麼解讀。
3. 判斷一個任務該用 reasoning model 還是 instruct model。
4. 對自己的硬體預算估算「能不能本地跑 reasoning model」、選哪個。

Paradigm shift：從 scaling pretrain 到 scaling test-time

LLM 能力提升的兩條歷史路徑：

12020-2023 時期：scale pretrain compute
2  GPT-3 → GPT-4：模型大 5-10×、訓練 compute 大 50-100×
3  策略：更多參數 + 更多訓練 token = 更好的 base model
4
52024-2026 時期：scale test-time compute
6  GPT-4 → o1：模型大小接近、但推論時花 5-50× 算力
7  策略：base model 不變、訓練「推理能力」+ 推論時動態擴展 reasoning trace

兩條路線不對立、是疊加：reasoning model 本身仍跑在大 base model 上、reasoning RL 是再加一層後訓練。Cost trade-off 對比的 framing 跟對使用者錢包的影響、見 test-time compute 卡片。本章接下來聚焦「reasoning model 的訓練流程」跟「本地選型」、不重複 paradigm 層的對比。

關鍵理解：reasoning model 不是「更聰明的 GPT-4」、是「同等聰明 base model + 學會把算力花在 reasoning 上」。底層 base model 依然是 Transformer、所有前面章節（attention、FFN、sampling）原理不變。

Reasoning model 的訓練流程

DeepSeek-R1 是第一個公開細節的開源 reasoning model、其 paper 揭示的訓練流程具有代表性：

 1Stage 1: Cold-start SFT
 2  用幾千份「高品質 long reasoning trace」資料 fine-tune base model
 3  目標：讓模型學會「該怎麼想」的 format
 4
 5Stage 2: Reasoning-focused RL
 6  Reward：最終答案正確（math / code / logic 等可機械驗證的任務）
 7  Policy：把 reasoning trace 越拉越長、越能正確、reward 越高
 8  約束：保留語言流暢度（不能 reasoning trace 變成亂碼）
 9  → 模型自發學會「困難問題想更久」
10
11Stage 3: SFT on reasoning + non-reasoning data
12  把 reasoning RL 學到的能力跟一般 instruct 能力 mix
13  避免「只會 reasoning、不會聊天」
14
15Stage 4: Final RLHF / DPO（可選）
16  跟 instruct model 同樣的 alignment 階段、refine helpfulness

關鍵特性：

1. Stage 2 的 reward 機械可驗證：math 答案、code unit test、logic 答案 — 不需要 human preference、所以可大量擴展訓練資料
2. Reasoning trace 是「emerge」出來的：訓練不直接告訴模型「該怎麼想」、只給「答案對不對」、模型自己摸索出最佳 reasoning strategy
3. 跨任務 transfer 有限：reasoning model 在訓練分佈內任務（math、coding）強、跨到開放域對話、提升較小

DeepSeek-R1 distill 系列 是另一條路：用 R1 full 模型產生 reasoning trace、再 SFT 一個小 base model（如 Qwen2.5-32B）— 讓較小模型也有 reasoning 能力、但跳過昂貴的 RL 階段。

Reasoning trace 的格式

主流 reasoning model 在推論時輸出 reasoning trace 的格式：

 1DeepSeek-R1 / Qwen-QwQ：用特殊 token 標記
 2  <think>
 3  讓我先列出已知條件...先試 case 1...結果矛盾、改試 case 2...
 4  </think>
 5  最終答案：X
 6
 7OpenAI o1：對使用者隱藏
 8  API 只回最終答案、但計費 reasoning token
 9  使用者看不到 reasoning trace 內容
10
11Claude 3.7 thinking：extended thinking field
12  API response 含 `extended_thinking` 跟 `text` 兩個 field
13  IDE / chat 介面通常折疊顯示 thinking 內容

實作層的關鍵考量：

1. Tokenizer 對 reasoning token 的處理：<think> 等特殊 token 在 vocab 中被保留、tokenizer 識別後不切碎
2. Context budget 分配：reasoning trace 通常 1000-10000 token、要預留 context window 容量
3. Streaming 行為：reasoning trace streaming 時、使用者看到「模型在想」、TTFT 變短但「first useful output」變長
4. Stop sequence：sampling 階段 </think> 或對應結束 token 是 reasoning trace 的 terminator

本地可跑的 reasoning model

2026/5 時、本地寫 code 工作流可考慮的 reasoning model：

事實查核註：模型大小、量化體積、reasoning trace 長度是 2026/5 主流版本的常見數量級；具體數字隨量化等級、context 配置、任務類型而變、引用前以對應 model card 跟自己 llama-bench 跑為準。

選型判讀（個人 dev 場景）：

1. 24GB Mac（M4 Pro）：可跑 14B distill、或 32B distill Q4 緊張、context 開小
2. 32GB Mac（M4 Pro 升級）：跑 32B distill 舒服、context 32K+ 可開
3. 48GB+ Mac（M4 Max）：跑 32B distill 寬鬆、可考慮 QwQ-32B 配 64K context
4. 16GB+ VRAM PC：跑 14B distill；32B distill 屬 dense 架構（不是 MoE）、要用 dense CPU offload（部分層放 RAM、靠 PCIe 走、tok/s 受 PCIe 頻寬限制）、跟 MoE CPU offload 是不同的戰術
5. 24GB+ VRAM PC（5090）：跑 32B distill 寬鬆

適合 reasoning model 的任務

Reasoning model 的優勢任務有明確 pattern：

不適合用 reasoning model 的任務（用 instruct model 即可）：

判讀反射：先問「這任務有沒有客觀正確答案 + 是否需要多步推理」、兩者都 yes 才用 reasoning model。

Reasoning model + tool use

Reasoning model 跟 tool use 結合是 2026 新趨勢、典型形態：

1模型在 reasoning trace 中發現「需要驗證一個事實」
2  ↓
3呼叫 tool（calculator / web search / code interpreter）
4  ↓
5拿到結果、繼續 reasoning
6  ↓
7最終答案

代表場景：

1. Coding agent + reasoning：reasoning 階段規劃 refactor 步驟、tool use 階段執行 file edit、reasoning 階段檢查結果
2. Math / data analysis：reasoning 階段拆問題、code interpreter 跑 calculation、reasoning 階段解讀
3. Web 研究：reasoning 階段列出該查的事實、web search、reasoning 階段彙整

挑戰：

1. Reasoning trace + tool result 都進 context：context 用量爆炸快、需要 long context 模型（見 4.11 Long context engineering）
2. Tool use 訓練跟 reasoning 訓練是兩件事：本地 distill 模型 tool use 能力 = 對應 base model 的 tool use 能力、不一定強
3. Error recovery：reasoning 階段假設錯了、tool 回 error、模型要會 backtrack（agent loop 失敗模式）

實務上、本地 reasoning + agent 是「值得試、但仍處早期」階段；雲端 R1 / o3 / Claude thinking + Claude Code / Cursor 是現階段更穩的組合。

跟 instruct model 共存的混用策略

寫 code 場景的合理混用配置：

 1Default model（Continue.dev primary）：instruct model
 2  Qwen3-Coder-30B-Instruct / Gemma 4 31B Instruct
 3  日常 autocomplete、解釋、簡單 refactor
 4
 5Reasoning model（Continue.dev secondary、手動切）：local reasoning
 6  DeepSeek-R1-Distill-Qwen-32B / QwQ-32B
 7  困難 bug、algorithm、複雜 refactor 規劃
 8
 9Cloud fallback（手動切）：雲端旗艦
10  Claude 3.7 Sonnet thinking / GPT-5 / o3
11  本地 reasoning 卡住、或極困難任務

Continue.dev 的 multi-model config 可同時設多個、UI 下拉切換、不用重啟 server。安全 / 隱私面：reasoning trace 可能含敏感推理過程、跨雲端 / 本地邊界判讀同 6.4。

何時過時 / 何時不過時

不會過時的部分：

• Test-time compute 作為一個獨立 scaling 維度的概念
• Reasoning trace 結構（pre-answer reasoning + answer）
• 「適合 reasoning vs instruct」的判讀框架
• 「機械可驗證的 reward + RL」是 reasoning training 的核心
• Reasoning model + tool use 的設計取捨

會變的部分：

• 具體 reasoning model（R1 → R2 → …、o1 → o3 → …、會持續迭代）
• Reasoning trace 的具體格式（<think>、extended thinking field、未來可能標準化）
• 本地可跑的模型選項（distill 系列會持續更新）
• Reasoning 跟 agent 結合的最佳實踐（仍在演化）
• 是否會出現 reasoning paradigm 的下一個替代（如 neurosymbolic、multi-agent reasoning）

新 reasoning model 出來時、回到本章的 framing：訓練流程是否同 R1 pattern、reasoning trace 怎麼產出、本地能否跑、適用任務是否同樣 pattern — 多數新模型仍會 fit 進這個框架。

下一章

下一章：3.9 Speculative decoding 內部、看另一個推論時加速的技術細節。

讀完本章後、看到「speculative decoding 加速 2.5×」這類聲稱時、能判斷可信度、能對自己工作流估算實際收益、能挑對 drafter。

本章目標

1. 解釋為什麼 speculative decoding 能在「不降品質」前提下加速。
2. 區分 drafter-based、MTP、EAGLE 三條主流路線。
3. 用 acceptance rate 估算實際加速倍率。
4. 判斷一個 drafter / target 配對是否值得用。
5. 看到 llama-bench 結果時、判讀「speculative speed」對自己場景的意義。

為什麼能加速：memory bandwidth bound 的縫隙

回顧 LLM 推論的瓶頸：forward pass 每生一個 token 要把整份模型權重從記憶體讀到處理器一次、所以 memory bandwidth 是上限。每次讀的時候、處理器有大量算力是閒置的（modern GPU / Apple Silicon 算力遠超頻寬）。

Speculative decoding 攻擊這個閒置：

 1單純 autoregressive 推論：
 2  每 token：讀整份權重 → 算 forward → 出 1 個 token
 3  讀權重 N 次、生 N 個 token
 4  瓶頸 = memory bandwidth × N
 5
 6Speculative decoding（K=4）：
 7  Drafter 一次生 4 個候選 token（drafter 小、讀它的權重快）
 8  Target 一次驗證 4 個位置（並行算 forward、權重只讀 1 次）
 9  若全部接受、生 4-5 個 token（含 bonus）
10  讀 target 權重次數從 4 降到 1、平均 token 成本顯著降

關鍵理解：

1. Target model 的 forward pass 對 K 個位置是並行的：一次讀權重、做矩陣乘法時把 K 個位置同時算（batch dimension 變大）
2. 算力是免費資源：原本閒置的算力被用來「同時算多個位置」、不增加 memory bandwidth 消耗
3. 正確性保證：sampling 階段的接受 / 拒絕邏輯確保最終輸出分佈跟「純 target 自回歸生成」一致 — speculative decoding 不降品質、只省時間

演算法核心：sampling 階段的接受邏輯

詳細的接受機制（簡化版）：

 1給定：drafter D、target T、context prefix x、speculative length K
 2
 3Step 1：D 從 x 生 K 個候選 token：d_1, d_2, ..., d_K
 4        對每個位置算 D(d_i | x, d_1..i-1) 機率
 5
 6Step 2：T 對 (x, d_1, d_2, ..., d_K) 做一次 forward pass、得到每個位置的 T 分佈
 7        T_1 = T(· | x)
 8        T_2 = T(· | x, d_1)
 9        ...
10        T_K = T(· | x, d_1..K-1)
11        T_{K+1} = T(· | x, d_1..K)   ← bonus token 位置
12
13Step 3：從前往後處理：
14        for i = 1 to K:
15          r = uniform random in [0, 1]
16          if r < min(1, T_i(d_i) / D(d_i)):
17            accept d_i           ← d_i 在 T 下機率 ≥ D 下機率、接受
18          else:
19            reject、sample 替代 token from (T_i - D)+ normalized
20            break
21
22Step 4：若全 K 個接受、再 sample 一個 bonus token from T_{K+1}

關鍵性質（數學上可證明）：

1. 最終輸出分佈 ≡ 純 target 自回歸：不管 drafter 多爛、speculative decoding 的輸出在統計上跟「就用 T 從頭生」完全相同 — 不是「近似」、是「等價」
2. Drafter 越接近 target、acceptance rate 越高：但即使 drafter 完全亂猜、輸出仍正確、只是沒加速
3. 每 step 至少生 1 個 token：最差情況第一個就拒絕、用 T 取代、退化成單純 T 自回歸

加速倍率 = K × acceptance rate 的限制

理論加速分析：

1Step 平均生 token 數 = E[接受長度] + 1（bonus 若有）
2                    ≈ K × acceptance_rate （簡化估算）
3
4每 step 主要成本：
5  Drafter K 次小 forward + Target 1 次大 forward
6  ≈ K × T_drafter + T_target
7  ≈ T_target × (1 + K × C)   where C = T_drafter / T_target
8
9加速倍率 ≈ K × acceptance_rate / (1 + K × C)

實際例子（Gemma 4 31B target + Gemma 4 E4B drafter、K=5）：

• T_drafter / T_target ≈ 4B / 31B ≈ 0.13
• K = 5、acceptance rate ≈ 0.7（同 family、estimate）
• 加速倍率 ≈ 5 × 0.7 / (1 + 5 × 0.13) ≈ 3.5 / 1.65 ≈ 2.1×

對照 LM Studio / llama.cpp 實測常見的「2-3×」加速、推導合理。

什麼破壞加速：

1. Drafter 太大：C 接近 1、(1 + K × C) 爆增、淨收益消失
2. Acceptance rate 太低：K × acceptance 達不到 1 + K × C、淨收益負
3. K 設太大：drafter 後面 token acceptance rate 急降、且每步成本 K × T_drafter 線性增加

三條主流變體

Drafter-based（經典 speculative decoding）

Leviathan et al. 2022 / Chen et al. 2023 提出：

• 方式：獨立訓練一個小 drafter model、跟 target 同 family / 同 tokenizer
• 代表：Gemma 4 31B + E4B、Llama 3.1 405B + 8B、Qwen3 30B + 1.5B
• 優點：相對成熟、各推論伺服器（llama.cpp、vLLM）廣泛支援
• 缺點：要訓 / 維護兩個 model；drafter 跟 target 必須完全相容

MTP（Multi-Token Prediction）

DeepSeek-V3 / Gemma 4 等內建：

• 方式：訓練 target 時、output 端額外加 K 個 head、每個 head 學「預測 N+1, N+2, …, N+K」
• 代表：DeepSeek-V3（MTP=4）、Gemma 4 coding 變體
• 優點：不需獨立 drafter、head 跟 target 完全同分佈、acceptance rate 高（通常 0.7-0.85）
• 缺點：需要 target model 訓練時就支援、現存模型不能後加

EAGLE（Extrapolation Algorithm for Greater LLM Efficiency）

Li et al. 2024 / EAGLE-2 / EAGLE-3：

• 方式：drafter 用 target 內部的 hidden state（不是 token embedding）當輸入、預測下一個位置的 token 機率、逼近 target 的分佈。因為 drafter 看的是 target 已經處理過的 feature、acceptance rate 比純 token-based drafter 高
• 代表：EAGLE-2、EAGLE-3 應用在 Llama 系列
• 優點：acceptance rate 通常更高（0.8+）、且 drafter 可以很小
• 缺點：實作較複雜、需要 access target 的 hidden state、推論伺服器支援度較窄

事實查核註：MTP / EAGLE 的具體 acceptance rate 跟加速倍率依模型、任務、量化、推論伺服器實作而異、引用前以各推論伺服器 release notes 跟自己 llama-bench 結果為準。

怎麼挑 drafter

實務判讀：

挑 drafter 的反例（不該配）：

1. 跨 family：Llama 3 + Qwen3 — tokenizer 不一致、無法配對
2. 跨 generation：Llama 2 + Llama 3 — vocab 不同
3. 太大 drafter：target 8B + drafter 3B — drafter 成本接近 target、淨收益小
4. 量化不對稱：target Q4 + drafter Q8 — drafter 不必比 target 精度高、浪費記憶體

怎麼測自己的加速倍率

llama-bench 是 llama.cpp 官方 benchmark 工具：

1# 純 target 推論
2llama-bench -m gemma-4-31b-Q4_K_M.gguf -p 512 -n 128
3
4# 加 drafter（speculative decoding）
5llama-bench -m gemma-4-31b-Q4_K_M.gguf \
6            --draft-model gemma-4-e4b-Q4_K_M.gguf \
7            --n-predict 128 --speculative-draft 5

看的指標：

• tg128 (純 target)：純自回歸生 128 token 的 tokens/s
• tg128 (with draft)：speculative decoding 模式的 tokens/s
• 加速倍率：後者 / 前者

實際工作流的 acceptance rate 跟 benchmark 上可能不同（取決於任務）、benchmark 是上限估算。

跟其他加速技巧的關係

關鍵注意：Speculative decoding + batching 同時開的支援度差 — 推論伺服器多半要選一個。個人 dev 場景 batch size = 1、用 speculative 是合理選擇；高併發 production 場景多半選 batching。

何時不適合用 speculative decoding

1. Batch size > 1 場景：跟 batching 衝突、加速可能反向
2. Reasoning model：reasoning trace 的 token 多樣化、drafter 很難猜對、acceptance rate 低（多數 reasoning model 不用 speculative）
3. Drafter 不存在或不合：勉強配差 family 的 drafter 反而拖慢
4. 記憶體吃緊：drafter 也要載入、可能擠掉 KV cache budget、其他地方變慢

何時過時 / 何時不過時

不會過時的部分：

• 「Memory bandwidth bound 留下算力閒置」的根本觀察
• 接受 / 拒絕 sampling 邏輯（數學上等價於純 target）
• Acceptance rate × K 是加速倍率主要 driver
• Drafter / target 必須 tokenizer 相容
• 跟 batching 衝突的 trade-off

會變的部分：

• 具體變體（drafter-based / MTP / EAGLE → 未來可能新方法）
• 各推論伺服器的支援度（llama.cpp、vLLM、TGI 都在演化）
• 模型廠商是否內建 MTP（目前 Gemma 4、DeepSeek 等先行、未來普及）
• Reasoning model 是否會有 reasoning-aware speculative 變體

下一步

下一步：模組三的內容到此完整、進入 模組四 應用層原理 看 LLM 作為系統元件的設計取捨。

本章目標

讀完本章後、你應該能：

1. 解釋「grammar 強制」是在 sampling 階段哪一步做的。
2. 區分 JSON schema / regex / CFG 三種 grammar 的適用場景。
3. 看 XGrammar / outlines / llama.cpp grammar 等實作、能對應到本章 framing。
4. 判讀「constrained decoding 加速還是拖慢」的具體場景。

Sampling 階段的位置

回顧 LLM 輸出流程（見 3.5）：

1[forward pass] → logits（vocab_size 維、每個 token 一個實數）
2       ↓ apply temperature（logits / T）
3       ↓ apply constrained decoding（本章聚焦）  ← grammar mask
4       ↓ softmax → probability distribution
5       ↓ top-p / top-k / sampling
6       ↓ next token

Constrained decoding 在 softmax 之前插入 grammar mask：

1For each position：
2  1. Grammar 算當前位置的「合法 token 集合」（vocab 子集）
3  2. 對不在合法集的 token、logit 設 -∞
4  3. Softmax 後、不合法 token 機率為 0
5  4. Sampling 只可能選到合法 token

關鍵理解：grammar 不改變模型本身、不改變 logits 數值（除了 mask 部分）、只是限制 sampling 空間。

三種主流 grammar

JSON Schema

1{
2  "type": "object",
3  "properties": {
4    "name": {"type": "string"},
5    "age": {"type": "integer", "minimum": 0}
6  },
7  "required": ["name"]
8}

LLM 輸出必須是合法 JSON 且符合 schema。實作：

1當前已生：'{"name": "alice", '
2  ↓ 算下一個合法 token：
3  - 必須繼續產合法 JSON
4  - schema 還沒填 age（optional）但 name 已填、所以 } 合法、"age" 也合法
5  - 不合法：'{' / ']' / 任意其他 key
6  ↓ Token mask 套用
7  → 模型只能選 } 或 "age"

Regex

1\d{3}-\d{4}-\d{4}  # 台灣 phone number 格式

LLM 輸出必須符合 regex。實作：

1當前已生：'09'
2  ↓ 算下一個合法 token：
3  - regex 期望 \d 接下來
4  - 合法 token：'0'-'9' 開頭的 token
5  - 不合法：字母、符號
6  ↓ Token mask

CFG（Context-Free Grammar）

用 BNF / EBNF 描述合法語法：

1expr   ::= term ("+" term)*
2term   ::= number | "(" expr ")"
3number ::= [0-9]+

LLM 輸出必須符合此 grammar。實作：

1當前已生：'(1+2'
2  ↓ CFG 算當下合法 next token：
3  - 已 match 部分 term + "+" + term
4  - 合法：")" 或 "+" 開始新 term
5  - 不合法：字母、其他符號
6  ↓ Token mask

CFG 是最強表達力、但實作最複雜。SQL / 程式碼 generation 多用 CFG-based grammar。

XGrammar 的 pre-compile 機制

XGrammar（Dong et al., 2024）是 2024-2025 主流的高效實作。核心優化：

 1Naive 實作（如 outlines 早期版）：
 2  每次 sampling 都重算 grammar state
 3  每個 token 都跑一次 grammar parse
 4  → 開銷大、可能拖慢 generation
 5
 6XGrammar 優化：
 7  1. Pre-compile grammar → 確定性 DFA / push-down automaton
 8  2. Cache 每個 grammar state 的「合法 token mask bitmap」
 9  3. Sampling 時 O(1) 查表得到 mask
10  4. Mask 用 bitwise op 套用到 logits

效果：grammar 套用 overhead 趨近 0、甚至因為跳過 boilerplate token 反而加速：

1無 grammar 生 JSON：
2  {     " n a m e "     : " a l i c e " ...
3  ←     每個 token 都跑 forward pass    →
4
5有 grammar 生 JSON：
6  跳過固定 token（{ " : 等）、直接生關鍵字串
7  forward pass 次數減少
8  → 實測加速 1.5-3×

主流推論伺服器（vLLM、SGLang、TensorRT-LLM）2025 後預設用 XGrammar。

性能取捨：加速還是拖慢

常見誤解：「constrained decoding 拖慢生成」。實際看實作：

判讀：用主流推論伺服器（vLLM / SGLang）+ XGrammar 路線、constrained decoding 通常加速；自己寫 naive 實作可能拖慢。

跟 function calling 的關係

兩個概念可獨立、也可疊用：

主流商業 API（Anthropic / OpenAI / Gemini）的 function calling 通常內部已用 constrained decoding、開發者無感。本地推論用 vLLM / SGLang + XGrammar 也是預設組合。

失敗模式

1. Grammar 太嚴讓模型「該說的話說不出來」

1Schema 強制 type 是 enum ["A", "B", "C"]
2但真實答案是「none of the above」
3→ 模型強制選 A/B/C、輸出語義錯誤

緩解：enum 加 fallback option（“unknown” / “none”）、schema 別過度約束

2. CFG 太複雜、編譯失敗 / 慢

1復雜 CFG（如完整 SQL grammar）pre-compile 數秒
2production cold start 多花這數秒

緩解：cache compiled grammar、用較簡單 grammar 版本（如「INSERT only」而非完整 SQL）

3. Grammar 跟 model 訓練分佈不符

1Schema 要求很罕見的 JSON 結構
2模型訓練沒見過這結構
3即使 grammar 強制合法、語義可能空洞

緩解：grammar 用模型訓練過的形態（function call spec、common JSON）、自定義 schema 加 few-shot example

4. Streaming 跟 grammar 衝突

1Streaming 邊生邊輸出
2Grammar 中段 token 可能要 backtrack 修正
3streaming UX 跳字

緩解：用 incremental-parsing grammar（XGrammar 支援）、避免 backtrack 場景

5. Constrained decoding 蓋過 function calling 訓練

1模型訓練用 OpenAI function spec、應用強制套 Anthropic tools 的 grammar
2模型輸出「合法但語意空洞」（schema 對、欄位胡亂填）

緩解：grammar spec 跟模型訓練 spec 一致、別人工維護兩份不同 schema

何時不該用 constrained decoding

1. 自由 / 創意輸出：寫作、brainstorming、grammar 限制模型表達
2. 可靠的 model + simple format：模型本身能穩定輸出 JSON、grammar overhead 不必要
3. Grammar 太嚴有語義錯：見失敗模式 1
4. Streaming + 複雜 grammar：streaming UX 受影響

主流實作詳細

何時過時 / 何時不過時

不會過時的部分：

• Constrained decoding 在 sampling 哪一步插入（softmax 之前）的 framing
• 三種 grammar 類型（JSON schema / regex / CFG）的分類
• Token mask 機制（不合法 token logit 設 -∞）
• 「正確實作下加速、不是拖慢」的反直覺結論
• 5 大失敗模式分類

會變的部分：

• XGrammar / outlines 等實作的具體效能跟功能
• 主流推論伺服器的預設 grammar engine
• JSON schema spec 標準化（新版會出）
• Function calling + constrained decoding 是否會被 native multimodal 取代

下一章

下一章：3.11 想學更深、整個模組三理論基礎走完。

本章跟模組二 2.4 數學基礎公開課 互補：那邊是數學工具、這邊是 LLM 理論機制。兩者組合涵蓋從零基礎到能跟業界研究接軌的完整路線。

路線總覽

階段 1：3Blue1Brown LLM 視覺化系列

Grant Sanderson 的「Neural Networks」+「But what is a GPT?」系列、視覺化動畫解釋 Transformer 內部運作。

為什麼從這裡開始：影片把抽象的 attention、embedding、residual stream 變成可視覺化的幾何運動。看完這個系列、本模組前 4 章的概念都能 grasp 到直觀層次。

前置條件：高中代數 + 對矩陣有基本概念。已有 ML / Neural Network 基礎的讀者可跳過 Essence of Linear Algebra、直接看 Neural Networks 5 集系列。

連結：YouTube 上搜尋 3Blue1Brown Neural Networks、官方頻道是 youtube.com/c/3blue1brown。每集 15 ~ 30 分鐘、總共約 4 小時。

階段 2：Andrej Karpathy 的 Neural Networks: Zero to Hero

Andrej Karpathy（OpenAI 前研究員、Tesla 前 AI 主管）的 YouTube 系列、在「動手實作 LLM」場景下是最完整的公開教材之一。完整實作從 micrograd（自己刻 autograd）到 GPT-2 訓練。

前置條件：Python 基礎、PyTorch 基本語法、看懂模組二的 chain rule 與 backprop 概念（2.2 calculus）。沒寫過 PyTorch 的讀者建議先做完 PyTorch 60 分鐘 tutorial 再進。

核心集數

為什麼這系列重要

• 講者深度高：Karpathy 講解的節奏細到可以跟著手刻、實作完能對 Transformer 每個 module 的角色有具體理解。
• 完整可執行 code：每個影片都有 GitHub repo、可跟著跑。
• 從零實作：不依賴黑箱 framework、所有東西都自己刻、理解深度。
• 涵蓋完整：autograd → MLP → CNN → Transformer → 完整 GPT-2 訓練。

完成這系列、你能：

• 對應到模組三 3.2 attention 跟 3.3 transformer-architecture 的每個 module、解釋它在 code 中的角色。
• 用 PyTorch 從零實作一個簡單 LLM。
• 看懂主流 LLM 的 architecture code（Llama、Mistral 等）。

連結：YouTube 搜尋 Karpathy Neural Networks Zero to Hero、官方索引在 karpathy.ai。

預估時間：完整跑完 30 ~ 50 小時（含跟著寫 code）、4 ~ 8 週投入。

階段 3：Stanford CS224N Natural Language Processing with Deep Learning

Stanford 的 NLP + Deep Learning 旗艦課、由 Chris Manning、Tatsu Hashimoto 等講授。每年更新材料、在「LLM 系統教學」場景下是最完整的學術課程之一。

前置條件：微積分（chain rule、partial derivative）、線性代數（matrix multiplication、eigenvalue）、Python + PyTorch。沒有這些基礎建議先補完模組二再進。

內容

• Word vectors（word2vec、GloVe）
• RNN、LSTM、GRU
• Attention、Transformer
• BERT、GPT、T5
• 預訓練、fine-tuning、RLHF
• Multimodal、tool use、agent
• 最新 LLM 進展

為什麼選這門

• 教材深度：每堂課有 slides + 推薦 paper、可深入研究。
• 作業扎實：5 個 programming assignment、從 word2vec 到實作 Transformer。
• 每年更新：跟最新研究進展對齊。

連結：Stanford CS224N 課程網站。YouTube 上有歷年錄影。

預估時間：跟著影片 + 作業約 80 ~ 120 小時、10 週投入。

階段 4：Stanford CS336 Language Modeling from Scratch

2024 年 Stanford 新開的 LLM 從零訓練課、後續每年更新。Percy Liang、Tatsu Hashimoto 講授、涵蓋從資料到部署的完整 LLM lifecycle。引用時請註明你看的是哪一年的版本（內容逐年更新、跨年版本可能有差異）。

前置條件：完成 CS224N 或同等課程、有 distributed training 概念、了解 GPU memory hierarchy。屬於進階課、不適合作為 LLM 入門起點。

內容

• 訓練資料：收集、過濾、deduplication
• Tokenizer 訓練
• 模型架構選擇
• 大規模分散式訓練
• 評估方法
• Alignment（SFT、DPO、RLHF）
• Inference 優化
• 部署、安全

為什麼這門特別

• 完整 lifecycle：少數涵蓋「資料 → 訓練 → 評估 → 部署」全鏈的課。
• 業界視角：講者跟前沿實驗室（Anthropic、Stanford CRFM 等）合作密切。
• 最新內容：2024 開課、覆蓋最新 LLM 技術。

連結：Stanford CS336 課程網站。YouTube 上有錄影。

預估時間：80 ~ 100 小時、10 週投入。

階段 5：Stanford CS25 Transformers United

Stanford 的 Transformer 專題課、每集邀請業界 / 學界專家、涵蓋 Transformer 在不同領域的應用。每年更新、講者更迭。

涵蓋領域

• Transformer 各種變體（Vision Transformer、Audio Transformer 等）
• Diffusion + Transformer
• Long context 技術
• Mixture of Experts
• 多模態 LLM
• Agent / Tool use
• 最新研究進展

為什麼有價值

• 業界視角：講者多是 OpenAI、Anthropic、Google DeepMind、Meta 等實驗室的核心研究員。
• 跟前沿同步：每年內容隨主題更新。
• 適合「想知道現在發生什麼」：補課堂教學跟不上的最新進展。

連結：YouTube 搜尋 Stanford CS25 Transformers United。

預估時間：每集 1 小時、可挑感興趣的看、不一定看完整系列。

階段 6：MIT 6.S191 Introduction to Deep Learning

MIT 入門 DL 課、每年寒假開課並錄影上傳。涵蓋 RNN、CNN、Transformer、Diffusion、LLM 等廣度。

• 深度：較 Stanford CS224N 淺、適合入門。
• 廣度：覆蓋 DL 所有主要分支、不只 NLP。
• 更新頻率：每年新版、跟最新進展。

連結：introtodeeplearning.com。

預估時間：每集 1 小時、約 7 ~ 10 集、總時數 10 ~ 15 小時。

階段 7：DeepLearning.AI Specializations

Andrew Ng 創辦的 DeepLearning.AI 提供多個 LLM 相關 specialization、Coursera 上有付費 + 免費 audit 選項。

推薦課程

Short courses 特別推薦：免費 + 短、跟最新工具同步。例：

• ChatGPT Prompt Engineering for Developers
• LangChain for LLM Application Development
• Building Systems with the ChatGPT API
• Functions, Tools and Agents with LangChain
• Fine-tuning LLMs
• Pretraining LLMs

連結：deeplearning.ai 的 short courses 頁面。

階段 8：Hugging Face NLP Course

Hugging Face 官方教材、實作取向。涵蓋 Transformers library、tokenizer 訓練、模型 fine-tuning、deployment。

• 連結：huggingface.co/learn/nlp-course
• 特性：免費、用 Hugging Face 生態系實作、適合工程師
• 章節：12 章、約 30 ~ 40 小時

完成這門課、你能用 Transformers library 做：

• 載入跟用任何 Hugging Face 模型
• 自己訓練 tokenizer
• Fine-tune 模型（含 LoRA）
• 部署到 Inference Endpoints

必讀 Papers

讀完課程後、跟最新研究進度的方式是讀 paper。以下是 LLM 領域的「必讀經典」、按時間順序：

讀 paper 的順序建議：先讀 abstract + intro + conclusion 抓研究問題與結論、再看 method 細節、最後看 experiment 與 ablation。初學者可優先讀 Transformer 原始 paper + GPT-2 + Chinchilla + InstructGPT 四篇、覆蓋「架構 / 預訓練 / scaling / alignment」骨架；Flash Attention、MoE 等工程細節 paper 可後補。

訂閱 arXiv cs.CL、cs.LG daily list、或關注 Hugging Face Daily Papers、X / Twitter 上的 ML researcher、能持續跟最新進展。

書籍補充

Jay Alammar 的 The Illustrated Transformer、The Illustrated GPT-2 等部落格文章、是視覺化解釋的經典。免費、google 直接搜尋。

建議的時間投入

寫 code 場景的使用者通常用「3Blue1Brown + Karpathy zero-to-hero + 跟最新 paper」這個組合就能跟 LLM 進展接軌、約 6 ~ 12 週投入。想做研究 / 自己訓練模型、再進入 Stanford CS336、CS224N、必讀 paper 等正式學習路徑。

建議的學習順序

對「想理解 LLM 內部、不打算自己訓練」的工程師：

1. 看 3Blue1Brown GPT 系列（1 ~ 2 週）
2. 看 Karpathy Let's build GPT from scratch（1 週）
3. 看 Karpathy Let's reproduce GPT-2（2 週）
4. 看 Stanford CS25 感興趣的集數（自由）

對「想做 LLM 應用開發」的工程師：

1. 同上
2. • DeepLearning.AI short courses（LangChain、RAG、Agents、Prompt Engineering）
3. • Hugging Face NLP Course

對「想做 LLM 訓練 / fine-tuning」的研究者：

1. 同上
2. • Karpathy 完整 zero-to-hero 系列
3. • Stanford CS224N（系統補課）
4. • Stanford CS336（完整 lifecycle）
5. • 必讀 paper

小結

讀到這裡、本系列指南就完整收尾。你應該能：

• 在 Mac 上跑本地 LLM 寫 code（模組零 + 模組一）
• 判讀任何 LLM 相關資訊（模組零 0.6 五個框架）
• 理解 LLM 推論的數學基礎（模組二）
• 理解 LLM 內部運作機制（模組三）
• 知道想再深入該往哪走（本章 + 模組二 2.4）

回到 LLM 寫 code 實務指南首頁 看完整地圖。

本章預設讀者熟悉線性代數（矩陣乘法、向量內積）跟微積分（gradient、chain rule）。沒讀過模組二的讀者、可以先讀本章看哪些術語陌生再回頭補。

本章目標

讀完本章後、你應該能：

1. 解釋「一個 layer 在做什麼」用線性代數的話。
2. 區分 activation function 的常見選擇（ReLU、GELU、SiLU）的差異。
3. 解釋為什麼神經網路需要非線性 activation。
4. 看到「N-layer Transformer」時、能對應到模型結構。

單一 neuron：linear + activation

單一 neuron（神經元）的核心定義是「對輸入做線性組合、再經過非線性函式」：

1output = activation(w · x + b)

其中：

• x：輸入向量
• w：權重向量
• b：bias（純量）
• w · x：內積
• activation：非線性函式（如 ReLU、sigmoid、tanh）

直覺：先把輸入做加權求和、再用非線性函式扭曲一下。沒有非線性、堆 N 個 neuron 等同於一個線性變換、表達能力有限。

Layer：把 N 個 neuron 並排

Layer（層）的核心定義是「把多個 neuron 並排處理同一個輸入」、結構上等同於矩陣乘法 + 向量加 bias + 逐元素 activation：

1output = activation(W @ x + b)

其中：

• W：權重矩陣、shape (output_dim, input_dim)
• x：輸入向量、shape (input_dim,)
• b：bias 向量、shape (output_dim,)
• W @ x：矩陣乘法
• 結果 output：shape (output_dim,)

例：input dim = 4096、output dim = 4096 的 layer、權重矩陣有 16,777,216 個參數。

這種「activation(W @ x + b)」結構叫 linear layer、fully-connected layer、或 dense layer、是神經網路最基本的 building block。

Activation Function：引入非線性

Activation function（激活函式）的核心責任是「在每個 layer 後引入非線性、讓網路能表達複雜函式」。沒有它、N 個線性 layer 等同於一個線性 layer。

主流 activation function：

Transformer 內部主要用 GELU 或 SiLU。Sigmoid 跟 tanh 在深度 30+ 的網路中容易造成 gradient vanishing、Transformer 系列因此採用 GELU / SiLU；淺層網路（< 10 層）兩者影響較小、Sigmoid / tanh 仍可用。

Softmax 是特殊 activation、用在輸出層把 logits 轉成機率分佈、不在中間 layer 用。

Multi-Layer Network：串接 N 個 layer

Multi-layer network（多層網路）的核心結構是「N 個 layer 串接、前一層的 output 是下一層的 input」：

1h₁ = activation₁(W₁ @ x + b₁)
2h₂ = activation₂(W₂ @ h₁ + b₂)
3...
4output = activation_N(W_N @ h_{N-1} + b_N)

「深度」（depth）指 layer 數量。Transformer LLM 的 layer 數通常 30 ~ 80：

每層都是線性變換 + activation；堆疊起來表達能力強。但深度高也意味著訓練難度高（gradient vanishing / explosion）、需要 residual connection 跟 layer norm 等技術配合。

Forward Pass：從 input 算到 output

Forward pass（前向傳播）的核心定義是「資料從 input 流經各層、產生 output 的計算過程」。每個 layer 順序做矩陣乘法 + activation。

LLM 的 forward pass 概略流程：

1input tokens → embedding layer → 數十個 Transformer block → output layer → logits

每個 Transformer block 內部又包含 attention + feed-forward + 兩個 layer norm。詳細展開見 3.3 Transformer 架構。

寫 code 場景的推論完全是 forward pass、不涉及 backward pass。每生一個 token 跑一次 forward pass、由 memory bandwidth 決定速度上限。

Backward Pass：從 loss 算 gradient

Backward pass（反向傳播）的核心定義是「用 chain rule、從 loss 倒推每個權重的 gradient」。它是訓練神經網路的基礎。

流程：

1. Forward：input → output → loss。
2. Backward：從 loss 開始、逐層算 local gradient、用 chain rule 累積。
3. Update：用 gradient 更新權重（gradient descent）。

實作上、PyTorch / MLX 等 framework 用 autograd 自動算 backward、開發者只寫 forward。

推論時無 backward pass、所以推論的記憶體跟算力需求遠低於訓練。

Bias：可選的常數項

Bias 的核心定義是「neuron 的 w · x + b 中的 + b」、讓 neuron 的輸出可以平移。

在 hidden_dim ≥ 4096 規模下、bias 對品質的邊際貢獻被觀察為近零、近年大型 LLM 普遍取消 bias 參數：

• Llama 系列、Gemma 系列、Qwen 系列都把 bias 設為 0、不訓練 bias 參數。
• 理由：實驗發現此規模下拿掉 bias 對品質影響微小、但能省記憶體與計算。

某些早期 LLM（GPT-2 等）跟舊架構仍用 bias、小規模網路 / 特殊任務下 bias 仍有實際貢獻。看模型 config 可知這個模型是否含 bias 參數。

Hidden Layer 與 Hidden Dimension

Hidden layer 的核心定義是「介於 input layer 跟 output layer 之間的中間 layer」。Hidden dimension（hidden_dim、d_model）是這些 layer 的輸出向量維度、規格見前一節 Multi-Layer Network 的表格。

Hidden dim 是模型「表達能力」的主要維度之一。每個 token 在模型內部都是一個 hidden_dim 維向量、layer 越大越能編碼複雜資訊。

為什麼需要這麼多 parameter

LLM 參數量主要來自 layer 數 × 每層權重矩陣大小、其中 FFN 層約佔 2/3。每個 layer 的權重矩陣大小是 hidden_dim × hidden_dim（feed-forward layer 通常 hidden_dim × 4 × hidden_dim、4 倍的由來見 3.3 Transformer 架構）、加上 attention 的 Q/K/V projection 等、單一 layer 已有上億參數。

Gemma 4 31B 約 50 layer、每層約 600M 參數、合計約 31B。70B / 405B 模型也是類似結構放大。

參數數量越多、模型「能學到的 pattern」越多。預訓練資料 trillion token 級別、需要大模型才能完整「記住」這些 pattern。實務上邊際收益隨參數量遞減（同代架構下參數翻倍、benchmark 提升通常 < 5%）、且推論成本線性增加；這就是為什麼 31B / 70B 級別停滯一段時間後、業界把焦點轉向 MoE 等「不增加每 token 算量」的擴張路徑。

何時這套基礎不適用

本章的「neuron → linear layer → forward / backward pass」假設「純 dense Transformer」架構、實務上有幾類架構走不同的計算路徑、判讀新架構時要對應調整：

判讀新架構時、先把它跟本章的 dense Transformer baseline 對照、找出在哪一步岔開（哪個 layer 結構、forward 順序、parameter sharing）、再深入差異點。

下一章

下一章：3.1 embedding 空間、從「token 怎麼變成向量」開始。