從迴圈開始。文字變成 token。Token 通過 Transformer。注意力機制決定哪些先前的 token 重要。執行階段會保留 KV 快取，這樣模型就不必每次都重新計算整個對話。然後模型選取下一個 token，然後重複這個過程。
一份實用指南，說明 LLM 如何運作、模型如何一次思考一個 token，以及如何在本地端執行它們。
一旦這個迴圈搞清楚了，硬體和軟體的選擇就會變得更容易推理。VRAM、量化、上下文長度、聊天模板、解碼、RAG、推理引擎和模型選擇，全都源自於相同的機制。
從迴圈開始：Token 輸入，機率輸出，一次一個下一個 token。權重告訴模型它學到了哪些模式。上下文告訴它它正在看什麼。KV 快取是讓迴圈可用的工作記憶體。硬體、執行階段和模型選擇，只有在理解模型遵守的記憶體、上下文和格式化規則後才有意義。
目標是先讓本地端 LLM 的機制直觀易懂，然後為你提供一條實用路徑，通往硬體、執行階段、推理服務，以及截至 2026 年 5 月 21 日的當前 LLM 研究。
重點
這是一份以模型為先的指南。它從機制開始：推理、token、Transformer、注意力、KV 快取、預填充、解碼、解碼控制、模型套件、聊天模板、模型類型、長上下文、RAG、Agent、微調和多模態模型。
之後，它進入本地端部署層：本地端真正的意義、量化、VRAM 計算、硬體分級、執行階段選擇、推理服務模式、授權、模型選擇、隱私、故障排除、基準測試、設定路徑和實際使用案例。
這個順序很重要。你應該在選擇 GPU 之前，先了解為什麼長提示詞會耗費記憶體。你應該在評判一個模型之前，先了解為什麼聊天模板很重要。你應該在在意每秒 token 數之前，先了解解碼為什麼是順序的。
關於更深層的硬體和軟體路徑，我有一個三部分的系列，教你自行託管 LLM / 本地端 AI：
前兩篇解釋了硬體容量和頻寬的計算。第三篇解釋了將該硬體轉化為可用推理的軟體層。這篇文章先為你奠定模型端的基礎，然後在機制清楚後，再回頭指向那些部署層。
LLM 實際做的是什麼
執行模型稱為推理。對於標準的僅解碼器 LLM，推理是同一個迴圈不斷重複：
- 將你的文字轉換成 token。
- 將這些 token 輸入模型。
- 為每個可能的下一個 token 計算分數。
- 使用解碼策略選擇一個 token。
- 將該 token 附加到序列中。
- 重複直到模型停止、使用者停止，或達到 token 限制。
模型並不是一次性寫出整個答案。它是一次產生一個 token。每個新的 token 都會成為序列的一部分，影響下一個 token。
在數學上，模型是一個學習過的函數：
f(theta, sequence) -> 下一個 token 的機率分佈
其中：
- theta 代表模型權重。
- sequence 代表提示詞加上到目前為止產生的 token。
- Logits 是 softmax 之前的原始分數。
- Probabilities 是 softmax 之後的歸一化分數。
- Decoding 將這些機率轉換為一個被選中的 token。
這就是為什麼本地端生成速度是以每秒 token 數來衡量的。你的系統反覆執行前向傳播，選擇或取樣一個 token，更新 KV 快取，然後繼續。
這裡的感知很重要。長時間的預填充意味著在出現第一個詞之前會有長時間的停頓。緩慢的解碼意味著答案串流緩慢。本地端開發者通常會執著於解碼速度，因為這是使用者能感覺到的，但預填充時間才是當你貼上一份 10K token 的文件時會造成困擾的。
Tokens
LLM 不會將原始文字視為單詞。它們看到的是 token：在內部以整數 ID 表示的文字小區塊。
一個 token 可能是：
- 一個完整的單詞："hello"
- 一個單詞片段："inter"、"national"、"ization"
- 一個標點符號
- 一個前面有空白的字串
- 一個位元組級的備援
- 一個特殊控制標記，例如 <|user|>、<|assistant|>、<s> 或 </s>
Tokenizer 將文字映射到 token ID，並將 token ID 映射回文字。常見的 tokenizer 系列包括 BPE 風格的 tokenizer 和 SentencePiece 風格的 tokenizer。不同的模型系列使用不同的 tokenizer，這一點很重要。一份 4,000 字的文檔，在某個 tokenizer 中可能是 5,000 個 token，而在另一個 tokenizer 中可能是 7,500 個 token。
詞彙量大小也很重要。詞彙量較大的 tokenizer 可以將某些文字壓縮成較少的 token，但它也會改變嵌入和輸出投影的大小。這就是為什麼每秒 token 數在不同模型系列之間並非完全可以比較的原因之一。
Token 很重要，因為它們決定了：
- 有多少文字可以放進上下文視窗。
- KV 快取會變得多大。
- 在提示詞處理期間你需要付出多少延遲。
- 多語言或程式碼密集的文字是否有效率。
- 模型是否正確地看到特殊的聊天標記。
模型的上下文視窗是它一次可以關注的最大 token 數量。在 2026 年，常見的本地端可運行模型範圍從 8K 和 32K 上下文，到伺服器級系統中的 128K、256K，甚至 1M token 的上下文。
但是，支援的上下文長度並不意味著便宜、快速或同等準確的上下文。一個理論上可以處理 128K token 的模型，可能在 64K 時就會變慢，並在 100K 時失去連貫性。始終測試你實際計劃使用的上下文長度。
Token 是工作的單位。一旦你理解了這一點，長上下文就不再神奇，而是開始看起來像一張你可以估算的帳單。
有用的練習：試試我的 Tokenizer 示範應用程式，看看文字是如何即時被分解成 token 的。
Transformer
大多數現代 LLM 都是基於 Transformer 架構。大多數本地端聊天 LLM 是僅解碼器 Transformer：它們在回顧先前 token 的同時預測下一個 token。
以上所有內容，包括 token、權重、配置和聊天模板，都是為底層的真正引擎所做的設定。Transformer 是移動數字的骨架。
一個簡化的 Transformer 層包含：
- Token 嵌入：Token ID 變成向量。
- 位置資訊：模型需要 token 順序。許多現代 LLM 使用 RoPE（旋轉位置編碼），它通過旋轉表示來編碼位置。
- 自注意力：每個 token 表示回顧先前的 token 表示，並決定哪些重要。
- MLP / 前饋區塊：一個密集的非線性計算，擴展和壓縮表示。大部分參數都在這裡。
- 層歸一化和殘差連接：這些穩定深度網路，並幫助資訊流經許多層。
- 輸出投影：最終的隱藏狀態變成詞彙表上的 logits。
將這個配方疊加幾十次或幾百次，你就得到了一個語言模型。
Transformer 回顧：Token 變成向量，注意力連接序列，MLP 重塑表示，RoPE 保持位置正確，最終投影將最後的隱藏狀態轉換為下一個 token 的 logits。
注意力
注意力是 token 決定哪些先前的 token 對下一個預測重要的方式。這也是本地端推理對記憶體如此敏感的原因之一。
經典的 MHA（多頭注意力）為許多頭儲存單獨的鍵/值狀態。它給了模型靈活性，但使 KV 快取變大。
現代本地端模型通常使用更高效的注意力設計：
- MQA：多個查詢頭共用一個鍵/值頭。記憶體效率高，但可能表達能力較差。
- GQA：查詢頭群組共用鍵/值頭。這是許多當前本地端模型中常見的中間地帶。
- MHA：完整的多頭注意力。可能很強大，但長上下文會迅速變得昂貴。
現代核心，如 FlashAttention 和 SDPA 風格的實現，減少了注意力的記憶體流量，並讓 GPU 保持忙碌。一個具有良好注意力核心的執行階段，即使在同一模型和硬體上，也可能比沒有它的執行階段快得多。
這就是為什麼兩個 7B 模型在長上下文下表現可能非常不同的原因。參數數量並非全部。一個 7B MHA 模型在 128K 上下文下可能會耗盡 24 GB GPU，而一個具有相同標稱上下文的 7B GQA 模型可能還有剩餘空間。
在比較模型時，請查看注意力類型、KV 頭數、上下文長度和執行階段支援，而不僅僅是參數數量。
KV 快取
KV 快取是模型在生成過程中的工作記憶體。它儲存先前 token 的鍵/值注意力狀態，這樣模型就不必在每個產生的 token 上從頭重新計算整個歷史。
沒有 KV 快取，生成效率會極低。有了 KV 快取，生成變得可用，但快取消耗的記憶體與以下成正比：
tokens x layers x kv_heads x head_dim x precision x 2
這個 x 2 是針對鍵和值。
對於較舊的 Llama 風格的 7B MHA 模型，一個有用的經驗法則是 FP16 KV 快取大約每個 token 0.5 MiB。這意味著 4K token 僅 KV 快取就可能花費約 2 GiB。在 32K token 時，你可能會看到僅 KV 快取就達到 16 GiB。
較新的 GQA/MQA 模型大大減少了這一點。一些執行階段也支援 FP8 或 INT8 KV 快取。這通常是 2026 年我為本地端使用者推薦的實際壓縮底線。
不要將低於 8 位元的 KV 快取視為預設值。研究系統，如 KIVI、KVQuant 和更新的壓縮快取核心，顯示 2 位元到 4 位元的 KV 可以透過仔細的演算法、校準和自訂核心來運作。這與在桌面執行階段中隨意切換 Q4 KV 開關不同。低於 8 位元時，請在編碼、工具呼叫、JSON、長上下文檢索以及需要精確先前 token 的任務上，仔細進行基準測試。
也不要將 KV 快取量化與推測性解碼混淆。DFlash 和 DDTree（通常非正式地簡稱為 DTree）通過草擬未來的 token 並驗證它們來攻擊解碼延遲。它們可以提高速度，但不會消除 KV 快取的記憶體開銷。
這就是為什麼一個模型在空白提示詞下可以容納，但在載入長文件時會崩潰的原因。權重裝下了。工作記憶體沒有。
預填充與解碼
LLM 推理有兩種不同的效能狀態：預填充和解碼。
預填充處理你提供給模型的提示詞。如果你貼上一份 20,000 token 的文件，模型必須先處理這 20,000 個 token，才能產生第一個答案 token。預填充相對來說可以並行處理，因此 GPU 可以有效地處理它，但它仍然可能代價高昂。
你在等待第一個 token 出現時所花費的時間，通常是預填充時間。
解碼一次生成一個新的 token。每個生成的 token 都依賴於到目前為止的序列，因此解碼更具順序性。這就是串流打字效果產生的地方，而且通常是決定模型感覺快還是慢的階段。
長提示詞會懲罰預填充。長答案會懲罰解碼。長對話會同時懲罰兩者，因為 KV 快取會增長。
在聊天會話中，每一輪都會添加到快取中。如果你讓一個對話運行到 16K token，那麼在每個新產生的 token 上，你都要付出所有 16K token 的記憶體代價。這就是為什麼保持無限歷史的聊天 UI 最終會變慢或崩潰的原因。
解碼
在模型產生 logits 之後，它實際上還沒有寫出任何東西。它只是對每個可能的下一個 token 進行了評分。解碼是將這些分數轉換為一個實際 token、將該 token 附加到上下文、並重複迴圈的策略。
執行階段或推理引擎可以通過幾種方式選擇 token。它可以每次都選擇機率最高的 token。它可以從一組縮小的、可能的 token 中進行取樣。它可以懲罰重複。它可以停在一個分隔符號處。它可以使用固定的種子，使相同的提示詞產生可重現的行為。
這些選擇不會改變模型權重，但它們會改變模型的語氣、確定性、創造力、風險概況以及陷入迴圈的傾向。
重要的旋鈕回答了三個實際問題：
- 隨機性：允許多大的變化？
- 尾部範圍：取樣器可以深入到多低機率的 token？
- 邊界：什麼可以防止迴圈、漫無邊際、架構破壞或失去控制的輸出？
對於精確工作，從狹窄的設定開始：低溫度、短的最大 token 限制、明確的停止序列，以及當輸出必須匹配 JSON 或架構時使用受限解碼。對於創意工作，給取樣器更多空間，使用更高的溫度、top-p，並在之後對多個候選進行排名。對於程式碼，保持第一次傳遞保守，只有在你故意探索時才對替代方案進行取樣。
貪婪解碼並不總是更準確。它通常很脆弱。貪婪解碼器可能會陷入迴圈或產生通用的答案，因為它從不探索替代方案。對於評估，請使用確定性設定。對於構思，讓模型自由發揮。
模型套件包含什麼
一個可運行的本地端 LLM 不僅僅是一個大的權重檔案。一個模型套件通常包含：
- 架構/配置：層數、隱藏大小、注意力類型、RoPE 設定、詞彙量大小、特殊 token 和上下文長度。
- 權重：學習到的參數，通常儲存為 safetensors、GGUF、GPTQ、AWQ、EXL2 或另一個執行階段特定的格式。
- Tokenizer：將文字轉換為 token ID 以及將 token ID 轉換回文字的規則。
- 聊天模板：系統、使用者、助手、工具和推理訊息的精確標記。
- 生成配置：溫度、top-p、停止 token、重複懲罰和最大 token 數的預設值。
- 授權和模型卡：關於模型如何使用法律和操作說明。
權重是最大的檔案，但它們不是整個模型。如果 tokenizer、配置或聊天模板錯誤，相同的權重可能會感覺像是壞掉了。
套件部分告訴你哪些東西必須一起傳遞。下一部分解釋為什麼聊天模板是人們最常弄壞的部分。
聊天模板
一個聊天模型是使用特定的對話格式訓練的。例如，它可能期望如下內容：
<|system|> 你是一個有用的助手。 <|user|> 解釋 KV 快取。 <|assistant|>
另一個模型可能期望：
[BOS] [INST] 解釋 KV 快取。 [/INST]
另一個可能使用 ChatML 風格的標記。另一個可能需要特殊的推理 token。另一個可能需要工具呼叫的 XML 或 JSON 包裝器。
使用錯誤的格式可能導致亂碼、角色混淆、系統提示被忽略、提示詞重複、拒絕奇怪、工具呼叫中斷、錯誤的基準測試結果，以及得出模型很笨的結論，而實際的錯誤是模板。
最佳實踐：
- 使用 Transformers 時，使用 tokenizer 的 apply_chat_template。
- 在基於 Harbor 的前端、llama.cpp、LM Studio、vLLM 或 SGLang 中使用模型特定的模板。
- 檢查模型是基礎、指令、聊天、推理還是工具微調的。
- 確保 BOS/EOS token 是正確的。
- 保持系統提示簡短，除非它們需要很長。
- 對於工具使用，遵循模型/執行階段所期望的確切架構。
如果你正在構建一個允許使用者切換模型的應用程式，你也需要模板切換。硬編碼一個模板格式，然後載入一個期望不同格式的模型，是造成本地端模型評估不佳的常見原因。
將模板視為 API 合約。如果你弄錯了，你實際上並不是在測試你認為你在測試的模型。
模型類型
並非所有 LLM 都針對相同的行為進行了調整。
對於大多數使用者來說，預設的起點應該是最近一個適合聊天/指令調整的模型，其大小可以舒適地放入記憶體。
不要從基礎模型開始，除非你知道原因。基礎模型完成你的提示詞，而不是回答它。它們對研究人員、微調人員以及構建自訂管道的人有用。對其他人來說，它們令人沮喪。
如果你問一個基礎模型「法國的首都是什麼？」，它可能會繼續說「巴黎的人口是多少？」而不是回答「巴黎」。
實際的區別很簡單：
- 基礎模型：適用於預訓練研究、微調和自訂管道。
- 指令模型：適用於直接遵循指令。
- 聊天模型：適用於帶有角色格式化的多輪對話。
- 推理模型：適用於任務受益於額外思考 token 和驗證的情況。
- 工具調整模型：適用於結構化呼叫、JSON 或函數使用很重要的情況。
本地端的真正意義
一個本地端 LLM 是一個其權重和推理執行階段由你控制的模型。你決定運行哪個模型、如何運行、它看到哪些資料，以及輸出如何處理。
這種自由伴隨著工作。你現在是運維團隊。你負責下載、更新、相容性、記憶體限制和安全性。當出現問題時，沒有支援工單可以提交。只有你、日誌和文件。
本地端可以意味著：
- 在手機上運行一個 2B 參數模型。
- 在消費級 GPU 上運行一個 7B 到 14B 模型。
- 在高階工作站上運行一個 30B 到 70B 模型。
- 在一個或多個資料中心 GPU 上運行一個稀疏 MoE 模型。
- 使用 vLLM、SGLang、TensorRT-LLM、llama.cpp、Harbor、LM Studio 或自訂 PyTorch 堆疊進行私有部署。
關鍵點：本地端並不自動意味著離線、私有、安全、便宜或開源。它只意味著你自己在運行模型。一個本地端應用程式仍然可以回傳資料。一個模型可以是開放權重，但不是開源。一個模型可以是本地端，但載入起來不安全。一個量化模型可以放進記憶體，但回答得很差。
當你需要隱私、低延遲、自訂行為、離線操作或規模化的成本控制時，這種權衡是值得的。當你需要絕對最佳的模型品質但又沒有匹配的硬體時，這就不值得了。在這種情況下，託管 API 是正確的工具。
當你理解一個方程式時，本地端 LLM 是實用的：
本地端 LLM 成功 = 模型適合度 + 正確的提示詞格式 + 良好的執行階段 + 實際的評估。
其他一切都是細節。細節很重要。
量化
量化以較低的精度儲存權重，以減少記憶體並有時提高吞吐量。
2026 年本地端使用者的經驗法則：
- FP16/BF16：當記憶體充足時的最佳品質。將其用作評估的基準線。
- Q8 / INT8：對許多任務來說幾乎無損，但仍然很大。當你有 VRAM 並希望最小化品質損失時，這是不錯的選擇。
- Q6 / Q5：品質優良，節省適中。這是一個強有力的中間地帶。
- Q4：許多聊天和文件工作流程的預設消費者甜蜜點。
- Q3 / Q2：僅在必須容納更大模型時使用。數學、程式碼、結構化輸出和工具使用會首先退化。
權重量化與 KV 快取量化不同。權重量化縮小模型。KV 快取量化縮小即時上下文記憶體。
對於 KV 快取，將 FP16/BF16 視為乾淨的基準線，將 FP8/INT8 視為實際的本地端壓縮底線。低於 8 位元的是研究密集型且對工作負載敏感的。只有在對你的實際提示詞進行測量品質後才使用它。
量化失敗首先出現在數學、多步驟推理、程式碼正確性、工具使用可靠性、JSON/架構遵循、細微指令遵循和長上下文檢索中。
一個較小但精度較高的模型可以擊敗一個被壓縮到太少位元的較大模型。不要崇拜參數數量。一個 Q6 的 7B 模型可以在推理任務上擊敗一個 Q2 的 13B 模型，同時使用更少的記憶體並運行得更快。
檔案格式與載入安全性
Safetensors 是一種安全的張量序列化格式，旨在儲存張量而不使用 Python pickle 行為。盡可能使用 safetensors，特別是對於 PyTorch/Transformers 模型。
避免來自不受信任來源的隨機 .bin 檔案。基於 PyTorch pickle 的載入可以在反序列化期間執行任意程式碼。本地端 AI 安全規則第一條：不要讓陌生人的模型檔案成為陌生人的程式碼執行。
GGUF 是 llama.cpp 生態系統的二進位模型格式。當你想要 llama.cpp、CPU 推理、Apple Silicon 推理、簡單的本地端伺服器、可攜式量化模型或像 LM Studio 這樣的桌面工具時，使用 GGUF。
ONNX 對於標準化部署和特定硬體加速很有用，特別是在通常的 PyTorch 堆疊之外。如果你要部署到 Intel NPU、ARM 設備或自訂加速器，ONNX 通常是阻力最小的路徑。
TensorRT-LLM 是 NVIDIA 針對生產 GPU 部署的高效能推理路徑。它很強大，但比 llama.cpp 或 Harbor 更複雜。你通常需要將檢查點轉換為 TensorRT 引擎，這需要時間和 GPU 記憶體，但一旦構建完成，會產生優秀的吞吐量。
EXL2 / GPTQ / AWQ 格式在專注於 GPU 的本地端推理社群中很常見，特別是為了將更大的模型塞進單一 GPU。
檔案格式的選擇不僅僅是外觀問題。它決定了哪些執行階段可以載入模型，你可以使用什麼量化，以及它運行得有多快。
執行階段與推理服務模式
執行階段是載入模型並執行推理的軟體。在 2026 年，本地端 LLM 執行階段生態系統成熟、有用，但有些碎片化。
對於一個人進行本地端實驗，從 Harbor、LM Studio 或 llama.cpp 開始。當你想要一個完整的本地端堆疊，將前端、後端和支援服務整合在一起時，Harbor 是最佳選擇。LM Studio 是最簡單的桌面優先路徑。llama.cpp 是可攜式低層級的主力。
對於團隊或私有服務，請查看 vLLM 或 SGLang。對於最大的 NVIDIA 生產效能，請調查 TensorRT-LLM。對於瀏覽器或行動部署，請查看 MLC 或 WebLLM。
執行階段的選擇通常會將你鎖定在一個格式生態系統中。llama.cpp 意味著 GGUF。vLLM 和 SGLang 通常意味著 safetensors 或 Hugging Face 檢查點。TensorRT-LLM 意味著 ONNX 或優化引擎。先選擇執行階段，然後找到正確格式的模型。
有三種實用的推理服務模式。
單使用者本地端意味著一個桌面應用程式、CLI 堆疊或為一個人服務的命令列伺服器。Harbor、LM Studio、llama.cpp 伺服器、ExLlama/TabbyAPI 和小型 Transformers 腳本都屬於這裡。目標是快速迭代：比較行為、速度、記憶體使用和提示詞格式，而無需構建一個運維平台。
團隊或私有 API 意味著在工作站或伺服器上提供一個 OpenAI 相容的端點。vLLM、SGLang、TensorRT-LLM 和 llama.cpp 伺服器都會根據模型大小和吞吐量需求出現在這裡。一旦多個人或作業共用一個模型，你就需要監控、提示詞/版本管理、路由和實際的延遲測量。
生產環境部署是另一回事。現在，對話中包含了連續批次處理、前綴快取、推測解碼、分頁注意力、張量並行、管線並行、量化服務、結構化輸出、負載平衡、GPU 使用率、延遲百分位數、提示快取、准入控制、日誌記錄、故障轉移、隱私和成本控制。
在生產規模下，「我能載入模型嗎？」是簡單的問題。困難的問題是：「在真實流量下，我能可靠地提供服務嗎？」
本地模型的 VRAM 計算
主要有三個記憶體消耗者：
- 模型權重
- KV 快取
- 執行時期開銷
粗略的權重記憶體公式如下：
weight_memory ~= parameters x bytes_per_parameter
有用的近似值：
- FP16/BF16：大約每個參數 2 個位元組。
- INT8/Q8：大約每個參數 1 個位元組。
- Q4：大約每個參數 0.5 個位元組，加上格式開銷。
然後加上：
- 執行時期開銷：框架緩衝區、CUDA 開銷、記憶體碎片和臨時張量。
- KV 快取：隨著活躍上下文中的每個 Token 而增長。
- 批次/並發記憶體：每個並發請求都需要自己的快取。
- 視覺編碼器記憶體：圖像也會變成 Token。
- 推測解碼記憶體：草稿模型、草稿頭或額外的驗證結構並非免費。
- 適配器記憶體：LoRA 適配器很小，但仍然是真實存在的。
MoE 模型增加了一個複雜因素。一個模型可能每個 Token 只啟動其參數的一小部分，但未啟動的專家通常仍然需要存放在記憶體中的某個地方。活躍參數影響計算成本。總參數仍會影響載入和容量規劃。
一個實際的估算看起來像：
total_memory = quantized_weights KV_cache_for_context runtime_overhead batch_or_concurrency_overhead safety_margin
這裡有一個陷阱：一個 Q4 的 13B 模型在 8K 上下文下可能很容易容納，但在 32K 下會失敗，因為 KV 快取增加了四倍。權重沒有變化。變化的是上下文。
保留 10% 到 20% 的備用空間。在 VRAM 使用率達到 99% 的情況下運行，無異於自找記憶體不足錯誤和碎片化故障。
實際硬體等級
以下是 2026 年實用的經驗法則，假設採用量化推理和合理的上下文長度。確切結果取決於執行時期、量化、模型架構、注意力類型、上下文長度以及作業系統/驅動程式開銷。
對於 2026 年大多數嚴肅的本地用戶來說，16 GB 是舒適的最低 GPU 等級，24 GB 是 CP 值最高的發燒友等級，而 48 GB 以上則是更強本地世界開啟的門檻。
效能取決於記憶體頻寬、GPU FLOPs、VRAM 容量、KV 快取大小、注意力實現、量化、批次大小、提示長度、生成長度和執行時期的成熟度。
解碼階段通常受限於記憶體頻寬：GPU 會反覆串流權重，而每個位元組進行的計算相對較少。預填充階段則更受計算限制，因為它可以平行處理提示。這就是為什麼兩張具有相同 VRAM 容量的顯示卡，如果其中一張的記憶體頻寬高得多，它們的 Token 速度可能會有很大差異。
最痛苦的本地設定是那種模型幾乎能容納但又必須將部分層級卸載到 CPU 的情況。技術上它可能可以運行，但 Token 速度可能會急遽下降。CPU 卸載對於實驗來說是可以接受的，但不是一種效能策略。
選擇適合的模型
實際問題不是「最好的模型是什麼？」，而是「在你的硬體上，能最出色地完成你實際工作負載的最小模型是什麼？」
從一個最新的 instruct/chat 模型開始，該模型能舒適地容納你實際需要的上下文長度。如果你的 VRAM 或統一記憶體是 8 GB 到 12 GB，從小型模型開始。如果是 16 GB 到 24 GB，先測試 7B 到 14B 級別的模型。如果你有 48 GB 或更多，更大的密集模型和 MoE 模型就變得可行。
在你愛上某個檢查點之前，先使用這個記憶體檢查關卡：
weights + KV cache + runtime overhead <= 80% to 90% of available memory
然後，在不同的候選模型上運行相同的 20 到 50 個提示。包含你的真實任務：程式碼編輯、文件問答、JSON 輸出、摘要、工具調用、長上下文，或任何你實際需要的東西。衡量答案品質、延遲、記憶體使用、模板可靠性以及失敗模式。
一個實際的模型選擇通常歸結為五個檢查：
- 任務契合度：聊天、程式碼、文件、Agent、多模態、邊緣或微調。
- 記憶體契合度：權重、KV 快取、執行時期開銷和安全邊際。
- 介面契合度：Tokenizer、聊天模板、停止 Token、工具架構和推理模式。
- 執行時期契合度：你的執行時期是否良好支援此架構、量化、上下文長度和服務模式？
- 許可證契合度：你能否在你計劃使用的地方實際使用它？
排行榜對於發現新模型很有用。它們不能取代你自己的評估。你的工作負載才是最重要的基準。
對於一個簡單的本地助手，選擇一個最新的 7B 到 14B instruct 模型、Q4/Q5 量化、正確的聊天模板、8K 到 32K 上下文，以及 Harbor、LM Studio 或 llama.cpp。優先考慮響應速度，而不是模型大小。
對於一個本地程式碼助手，如果你有足夠的 VRAM，選擇一個 14B 到 32B 的、具備程式碼能力的模型。使用低溫度、倉庫檢索、測試執行和基於補丁的工作流程。沒有工具的程式碼模型只能算半個產品。
對於一個私人文件助手，選擇一個強大的 instruct 模型、一個本地嵌入模型、一個重新排序器、一個 RAG 管道、引用強制執行以及中等到長上下文。不要貼上一份 200 頁的 PDF 就指望它自己搞定。
對於一個推理設定，選擇一個經過推理調整的模型，預算更多 Token，使用低到中等溫度，添加驗證，並為數學、程式碼或搜尋使用工具。推理模型會消耗更多 Token。請相應地規劃預算。
對於一個低資源設定，選擇一個 1B 到 4B 模型、Q4/Q5、簡短提示、結構化任務、檢索或工具，以及一個緊密的輸出架構。當任務受到限制時，小型模型會變得有用。
什麼控制速度
每秒 Token 數並非由單一因素控制。它是模型大小、記憶體頻寬、計算能力、注意力內核、上下文長度、量化、批次處理和執行時期品質的綜合結果。
主要的槓桿是：
- 記憶體頻寬：解碼階段通常會反覆串流模型權重，因此頻寬主導了單用戶的 Token 速度。
- GPU FLOPs：預填充和大批次使用更多的平行計算，因此 FLOPs 在那裡更重要。
- VRAM 容量：如果模型或 KV 快取溢出到 CPU，效能可能會崩潰。
- 注意力實現：FlashAttention、SDPA、分頁注意力和特定於執行時期的內核會改變速度和記憶體行為。
- 量化：更小的權重減少了記憶體移動，但激進的量化可能會損害品質，有時還會增加反量化開銷。
- 批次大小和並發：批次處理提高了吞吐量，但每個活躍序列都需要 KV 快取。
- 提示長度：長提示增加了預填充時間。
- 生成長度：長答案暴露了解碼速度。
- 推測解碼：EAGLE 風格的方法、MTP、DFlash 和 DDTree 在支援的情況下，可以對每個目標 Pass 驗證多於一個的草稿 Token。
最痛苦的設定是「幾乎能容納」的設定。一個將層級或快取溢出到 CPU 的模型技術上可能可以運行，但 Token 速度可能會從可用下降到慘不忍睹。
在你計劃使用的確切執行時期、量化、上下文長度、提示形狀和工作負載上進行基準測試。一個 BF16 的排行榜數字告訴不了你你的 Q4 本地堆棧實際體驗會是什麼感覺。
長上下文
長上下文聽起來很神奇：在一個提示中包含 128K、256K 甚至 1M 個 Token。它很有用，但也有實際的代價。
更多的上下文意味著更多的 KV 快取記憶體、更慢的提示處理、更多的注意力計算、更難的評估，以及更多不相關文本分散模型注意力的方式。品質也可能隨距離而衰減。一個模型可能很好地處理長文檔的結尾，卻忽略了埋在開頭附近的關鍵細節。
將長上下文用於全文檔分析、程式碼庫切片、法律或技術審查、轉錄摘要、多文件推理，以及在檢索錯失上下文時作為 RAG 的備用方案。
不要將長上下文視為檢索的替代品。它是一個補充。對大型語料庫使用 RAG，對最終選定的證據使用長上下文。
一些實用的習慣會有所幫助：
- 將關鍵指令放在開頭附近和結尾附近。
- 使用章節標題和分隔符。
- 要求引用來源片段。
- 壓縮不相關的歷史記錄。
- 使用摘要記憶體而不是無限的聊天歷史。
將長上下文視為昂貴的注意力，而不是免費的筆記本。
多模態
多模態本地模型除了文本之外，還可以接受圖像，有時也包括音頻或視頻。現代開源模型生態系統越來越多地包含這些模型。
其隱藏成本在於非文本輸入也會變成 Token。視覺編碼器會增加記憶體消耗。圖像塊會佔用上下文。音頻和視頻可能會使輸入預算激增。多模態模板也比純文本模板更容易出錯。
一張高解析度的單張圖像可能在上下文視窗中消耗數千個 Token。如果你在本地運行一個多模態模型，請像計算文本 Token 一樣計算圖像 Token。它們來自同一個預算。
小型 VLM 可能會產生幻覺，虛構視覺細節。OCR 可靠性各不相同。圖表和表格仍然很困難。對於嚴肅的文件或圖像工作流程，請使用真實樣本進行評估。不要因為一個簡單照片的演示就相信它能完美抽取發票資訊。
2026 年的本地模型場景
模型場景變化很快。截至 2026 年 5 月 21 日，本地 LLM 用戶應該從模型家族和生態系統的角度思考，而不是尋找一個「最好的模型」。
Qwen 3.5 / Qwen 3.6 是一個重要的開源模型家族，因為它涵蓋了整個範圍：適合筆記型電腦的小型模型、適合工作站的中型密集模型、適合多 GPU 服務的 MoE 模型、FP8 變體、長上下文、多語言工作、程式碼、工具和 Agent 工作流程。實際的要點很簡單：當你想要一個涵蓋筆記型電腦實驗和嚴肅本地服務的生態系統時，Qwen 是一個強大的預設選擇。
Gemma 4 之所以重要，是因為 Google DeepMind 正在推動該系列走向實用的本地部署：高效的邊緣模型、更大的密集和 MoE 選項、多模態、較大模型的長上下文、廣泛的語言支援、更強的程式碼/Agent 行為以及 Apache 2.0 許可證。這種組合使得在商業使用和設備端部署很重要時，值得對其進行測試。
Kimi / Moonshot AI、GLM / Z.ai、DeepSeek、MiniMax 和 Mistral 也是需要追蹤的核心家族。Kimi 在長週期程式碼、多模態推理、工具使用和 Agent 工作流程方面具有相關性。GLM 對於程式碼 Agent、長週期任務、MoE 系統和以部署為導向的模型發布很重要。DeepSeek 仍然具有影響力，因為其大型 MoE 系統、多頭潛在注意力、DeepSeekMoE、FP8 服務路徑、稀疏注意力以及高吞吐量自託管。MiniMax 值得關注，因為它專注於實際的 Agent 工作負載和推理高效的 MoE 模型。Mistral 仍然很重要，因為它的產品線涵蓋了通用、程式碼、推理、多模態和專業用例，並且部署支援強勁。
Nemotron 3 是 NVIDIA 的開源模型家族，專為 NVIDIA 硬體上的生產級 Agent 系統而設計。該系列包括 Nano、Super 和 Ultra 尺寸，採用混合 Mamba-Transformer MoE 設計，並與 TensorRT-LLM、NIM、Dynamo、Blackwell NVFP4/FP8 路徑以及企業 Agent 部署緊密相關。對待它不要像對待一個隨意的桌面聊天家族，而要將其視為 NVIDIA 希望開源服務堆棧發展方向的信號。
開源 AI 不再只是 Llama 與其他一切之爭。你正在選擇一個生態系統：權重、許可證、Tokenizer、模板、量化、執行時期支援、服務路徑、社群工具和故障模式。
Qwen 27B 密集模型
Qwen 3.5 / 3.6 27B (Dense) 是本地用戶最實用的公開權重選項之一，這些用戶關心程式碼、多語言工作、工具使用、思考/非思考模式以及長上下文。Qwen 3.5 27B 和 Qwen 3.6 27B 模型卡描述了與 OpenAI 相容的服務路徑、思考模式預設值、工具使用以及長達 262,144 個 Token 的上下文長度，並可通過 YaRN 在支援的框架中擴展更長的上下文。
對於 2x RTX 3090 的設定，當執行時期針對程式碼、Agent 或多語言覆蓋正確配置時，Qwen 是一個強大的預設選擇。
推理研究
2026 年的前沿不僅是模型品質，也關乎推理效率。PagedAttention 解決了服務中的 KV 快取記憶體浪費問題。FP8 KV 快取現在是 vLLM 等系統中的一個實用執行時期功能。DFlash 和 DDTree 探索了使用塊擴散草稿模型和草稿樹的推測解碼。NVFP4 在 NVIDIA 硬體上也值得關注，因為它改變了支援堆棧的實際部署討論。
其中一些已可投入生產。有些仍處於研究階段。有些只有在你的執行時期乾淨地支援它時才有意義。不要將論文中的加速視為桌面應用程式中的一個簡單核取方塊。
故障模式與修復
大多數本地 LLM 的故障並不神秘。它們通常來自記憶體適配、格式問題、執行時期支援、解碼設定或檢索品質。
記憶體不足： 權重、KV 快取、執行時期開銷或批次大小無法容納。使用更小的模型、減少上下文、降低批次/並發、選擇更好的量化，或保留更多備用空間。
亂碼或角色混淆： 聊天模板、Tokenizer、BOS/EOS Token、推理模式切換或工具架構有誤。在責怪模型品質之前，先檢查模型卡和執行時期模板。
首個 Token 慢： 預填充成本高。縮短提示、使用前綴快取、改善檢索、減少上下文，或使用更快的執行時期。
串流輸出慢： 解碼是瓶頸。檢查記憶體頻寬、量化、CPU 溢出、注意力後端、推測解碼支援，以及模型是否對硬體來說太大了。
文件回答不佳： 檢索可能失敗了。檢查解析的文字、區塊邊界、元數據、top-k 檢索、重新排序和引用依據。
JSON 或工具調用不佳： 使用更低的溫度、約束解碼、更嚴格的架構、更好的範例，以及針對工具使用調整過的模型。
重複循環： 降低溫度或 top-p、增加重複懲罰、檢查停止 Token，並確保模板不會導致模型將自己的答案視為新的提示。
從最平凡的檢查開始。它們修復的問題比更換模型更多。
如何發展你的堆棧
初學者：最簡單的有用設定
使用 Harbor 或 LM Studio、一個最新的 4B 到 9B instruct 模型、Q4 量化、8K 到 32K 上下文以及一個內建的聊天 UI。下載同一尺寸類別的兩到三個模型，並在相同的提示上進行比較。
目標：學習提示技巧、比較模型、理解速度和記憶體，並在一開始避免自訂程式碼。
中級：開發者設定
使用 llama.cpp 或 Transformers、GGUF 或 safetensors、一個與 OpenAI 相容的本地伺服器、一個簡單的 RAG 管道和一個小型評估集。從你真正的應用程式或腳本調用你的本地伺服器，而不僅僅使用聊天 UI。
目標：構建本地應用程式、測試檢索、衡量品質，並從 localhost 提供服務。
進階：私有服務設定
使用 vLLM 或 SGLang、一個或多個 GPU、一個與 OpenAI 相容的 API、監控、提示/版本管理、一個評估套件、帶重新排序的 RAG 以及工具沙箱。
目標：為真實用戶或內部工作流程提供服務、優化吞吐量和延遲，並維護安全和可觀察性。
專家：自訂優化
使用 TensorRT-LLM、自訂內核、專門的執行時期、量化實驗、推測解碼、多 GPU 並行、微調、蒸餾和生產評估。
目標：用工程時間換取推理效率，以更低的成本獲得更高的規模化品質。
隱私並非自動獲得
本地 LLM 改善了隱私，因為提示和輸出可以保留在你的硬體上。但「本地」並不自動意味著「安全」。
威脅包括惡意模型檔案、基於 pickle 的權重載入、不受信任的 trust_remote_code、檢索文檔中的提示注入、工具調用濫用、透過日誌洩露秘密、桌面應用程式的遙測、瀏覽器擴充功能或外掛程式、高風險設定中的模型幻覺、許可證違規以及微調期間的資料污染。
一個可行的本地 AI 安全基線包含四個習慣：
- 謹慎載入： 優先從信譽良好的來源使用 safetensors 或 GGUF，避免不受信任的 .bin 檔案，不要隨意啟用
trust_remote_code。 - 設定邊界運行： 使用非特權用戶、用於 Agent 的容器或沙箱，並在離線隱私至關重要時停用網路存取。
- 保護秘密： 將憑證遠離提示和 RAG 索引，檢查桌面應用程式的遙測設定，並在執行前驗證工具調用。
- 版本控制重要事項： 追蹤模型、提示、適配器、執行時期和量化版本，並記錄足夠的資訊用於除錯，同時避免造成隱私災難。
本地 AI 安全主要是無聊的營運紀律。這也正是你避免下載一個隨機檢查點、以 root 身份運行它，並將本地 AI 變成本地入侵的方法。
真正重要的基準測試
對你將實際運行的堆棧進行基準測試。一個模型的 BF16 排行榜分數並非你在 Q4 本地環境中的實際情況。
衡量品質、延遲、記憶體、可靠性和運作契合度：
- 品質： 在你真實任務上的正確性，而不僅僅是通用基準測試。
- 延遲： 首個 Token 時間、解碼每秒 Token 數和端到端時間。
- 記憶體： 權重記憶體、KV 快取增長、峰值 VRAM 以及負載下的備用空間。
- 格式化： 聊天模板正確性、JSON/架構成功率、工具調用可靠性和停止 Token 行為。
- 檢索： 引用忠實度、答案依據、遺漏證據時的行為以及重新排序器的影響。
- 運維： 啟動時間、預熱行為、崩潰恢復、日誌記錄、隱私和版本追蹤。
建立一個包含 30 到 100 個代表性提示的小型評估集。包含預期答案或評分標準、延遲和記憶體測量、失敗類別、專用於 RAG 的依據檢查、相關的 JSON 合規性檢查以及對模糊任務的人工審查。
然後比較模型。不要讓排行榜為你選擇本地堆棧。
使用本地模型進行程式碼開發
程式碼是本地 LLM 的最佳用例之一，因為提示通常包含私有程式碼、延遲很重要、迭代頻繁、API 成本可能快速增長，而且本地模型可以與編輯器、Shell、grep、測試執行器和補丁工作流程整合。
最強大的本地程式碼設定不是一個赤裸裸的聊天機器人。它是一個具備程式碼能力的 instruct 模型，連接到目標倉庫上下文、對程式碼庫的檢索、檔案路徑、相關片段、測試執行和一個補丁循環。
保持解碼確定性或低溫度。要求補丁而不是模糊的建議。自動運行測試。保留一個包含真實 Bug 和任務的小型評估集，這樣你就能判斷一個新模型是否真的更好。
不要讓本地模型在沒有審查的情況下重寫大型程式碼庫。「本地」並不會讓程式碼 Agent 變得明智。它只會讓上下文私有、循環更便宜，以及讓整合更易於控制。
本地 Agent 需要護欄
當一個本地 LLM 能夠使用工具時，它會變得有用得多：檔案搜尋、Shell 命令、瀏覽器自動化、資料庫、程式碼執行、行事曆、票務系統、內部 API、向量資料庫、家庭自動化、機器人或邊緣設備。
工具使用改變了安全模型。一個會產生幻覺的聊天機器人很煩人。一個有檔案系統存取權限的 Agent 可以刪除東西。一個有瀏覽器存取權限的 Agent 可以洩露秘密。一個有 Shell 存取權限的 Agent 可以在你來不及閱讀日誌之前就破壞機器。
本地 Agent 安全包含四個層級。嚴格限定 Agent 範圍，只給它實際需要的目錄、API、網路存取和憑證。約束執行，使用沙箱、容器、最小權限用戶、對破壞性操作進行確認，以及經過架構驗證的工具參數。將輸入視為惡意，因為檢索到的文件、網頁、票證和電子郵件可能包含提示注入。保留審計軌跡，記錄工具調用、模型版本、提示和批准，同時避免將秘密傾倒到日誌中。
結構化輸出有幫助，但它們不是一個安全邊界。JSON 架構、約束解碼和函數簽名使工具調用更容易驗證。它們並不能證明模型理解了請求、選擇了安全的操作，或者避免了注入的指令。
對於嚴肅的工具使用，將策略檢查放在模型外部。
RAG 勝過巨型提示
RAG 代表檢索增強生成。與其把所有資訊塞進提示，不如從知識庫中檢索相關區塊，然後只將這些區塊提供給模型。
一個好的本地 RAG 系統通常包含文件匯入、解析、分塊、嵌入、向量索引、檢索、重新排序、提示構建、答案生成、依據檢查和評估。每個階段都是一個可能的失敗點。
糟糕的解析會將表格變成垃圾。糟糕的分塊會將答案分割到不同邊界。糟糕的檢索會返回不相關的段落。糟糕的重新排序會把正確答案埋在排名第 20 的位置。一個好模型無法可靠地從它從未接收到的證據中回答問題。
大多數糟糕的 RAG 系統並非因為 LLM 不好。它們糟糕是因為分塊、檢索、重新排序和評估。
分塊策略是無聲殺手。 固定大小且無重疊的區塊可能會分割句子並失去上下文。語義分塊或帶有父文檔檢索的層次分塊通常效果更好，但沒有通用的答案。你必須根據你的實際文檔來評估區塊大小、重疊和分割規則。
一個好的重新排序器可以挽救平庸的檢索。沒有重新排序器能修復在匯入過程中丟失答案的區塊。
文件與知識工作
對於私人文件，本地 LLM 表現出色：會議記錄摘要、合約審查、技術文件問答、研究筆記綜合、電子郵件草擬、政策搜尋、內部支援助手和合規工作流程，所有這些都受益於將原始資料保留在擁有它的機器或組織附近。
工作流程很簡單但要求嚴格。仔細解析文件、保留頁面和章節元數據、語義分塊、使用嵌入和重新排序器、要求引用、將答案與來源和一般推理分開，並評估引用忠實度。
不要假設模型知道你的文件內容。它只知道你放入提示或檢索到上下文中的內容。
對於會議記錄，保留說話者標籤和時間戳。對於合約審查，按條款或章節分塊，而不是按任意的 Token 計數。對於技術文件問答，在檢索到的區塊中包含頁碼或章節錨點，以便模型能夠準確引用來源。
對於文件工作，你的解析器和檢索器與模型同樣重要。
邊緣部署
小型模型在手機、筆記型電腦、機器人、IoT 閘道器、工廠設備、車輛、醫療設備、離線現場設備和瀏覽器應用程式中越來越有用。邊緣不僅僅是工作站的縮小版。它有一組不同的限制條件。
完整的翻譯如上。
邊緣部署受到低記憶體、低功耗、熱限制、間歇性連線、隱私需求、即時延遲、小型上下文視窗以及可預測的備援行為所限制。在這些裝置上，一個小巧可靠的模型勝過一個龐大脆弱的模型。
一個實用的邊緣設定通常使用 0.5B 到 4B 的模型、積極的權重量化、簡短的提示詞、固定的架構、搭配工具的工作流程、本地嵌入、快取，以及不必要的對話歷史。
當連線中斷時，一個能持續運作的本地模型，比一個會失敗的大型模型更有價值。本地 AI 的未來不僅是強大的工作站模型，也是能在資料附近執行有用工作的小型模型。
本機 LLM 操作手冊
在你信任本地模型用於實際工作之前，請將此作為最後一道關卡。
選擇與配適： 選擇適合任務的模型系列，閱讀授權條款，確認硬體需求，選擇量化等級，並估算完整記憶體帳單。不要只停在權重大小。要包含 KV 快取、執行時期開銷、批次/並發以及安全餘裕。
載入與格式化： 優先選擇來自可靠來源的 safetensors 或 GGUF，避免未經信任的 pickle 為基礎的檔案，驗證 tokenizer 和對話模板，有目的地設定上下文長度，並根據任務選擇解碼參數。如果模板錯誤，評估就無效。
評估與操作： 使用代表性的提示詞進行測試，測量第一個 token 的時間和解碼速度，追蹤峰值記憶體，在加入 RAG 之前先評估檢索，在加入 Agent 之前先對工具進行沙盒測試，只有在較簡單的方法失敗後才進行微調。
對所有重要事項進行版本控管： 模型、量化、執行時期、提示詞、對話模板、適配器、嵌入模型、重新排序器、評估集以及硬體設定檔。只有當你能夠重現你所執行的內容時，本地系統才更容易控制。
微調
微調透過在額外資料上訓練來改變模型行為。對於本地使用者來說，最重要的方法是 LoRA 和 QLoRA。
LoRA 凍結基礎模型，並訓練小型低秩適配器權重。這能減少可訓練參數，並讓你維護多個輕量級適配器。QLoRA 則透過將凍結的 4-bit 量化模型微調進 LoRA 適配器來擴展此方法。
當你需要一致的寫作風格、領域特定的輸出格式、重複的分類或提取行為、工具呼叫格式的可靠性、專業的助手角色、RAG 無法解決的領域適應，或是更好的小型模型在狹窄任務上的效能時，就進行微調。
不要先微調。嘗試這個順序：修正對話模板、更好的提示詞、更好的模型、更好的解碼、RAG、重新排序、少樣本範例，然後才是微調。
大多數看起來像「模型不理解我的領域」的問題，實際上是「我的提示詞模糊不清」、「我的模板錯誤」或「我的檢索有問題」。
一個好的微調計畫包括乾淨的資料、訓練/驗證/測試分割、基準評估、明確的目標行為、安全審查、過擬合檢查、回歸評估、適配器版本控管、授權審查以及撤回計畫。
開放權重不代表開源
在 2026 年，「開放模型」這個詞常常被草率使用。你應該區分開放權重、原始碼可取得、開源以及本地相容。
開放權重通常代表你可以下載權重。它並不自動代表你可以商業使用模型、自由修改、在其輸出上訓練、以任何規模部署，或是忽略署名要求。
原始碼可取得代表程式碼或權重是可見的。它不一定代表授權是開源的。
開源 AI 模型是更強的主張。OSI 的開源 AI 定義將 AI 系統視為包含架構、參數/權重、推論程式碼，以及足夠的用來導出參數的資料資訊和程式碼。這比「權重在 Hugging Face 上」的門檻高得多。
有些授權看起來寬鬆，但包含限制：不得競爭使用、不得在輸出上訓練、不得超過特定規模部署、地理排除、署名要求、專利條款，或是對衍生作品有類似 copyleft 的義務。
規則： 在商業使用任何模型之前，閱讀模型卡和授權條款。一個模型可以很出色、可下載且可在本地執行，但同時也可能不適合你的法律或部署限制。
詞彙表
模型與調整術語
- 活躍參數 (Active Parameters)： 在 MoE 模型中，只有部分參數用於給定的 token。一個模型可能擁有數千億總參數，但每個 token 的活躍參數遠少於此。
- 適配器 (Adapter)： 一個小型可訓練模組，通常透過 LoRA 加入基礎模型。
- 基礎模型 (Base Model)： 一個未經特別調整用於對話或指令遵循的預訓練模型。
- 微調 (Fine-Tuning)： 針對目標領域或輸出風格，改變模型行為的額外訓練。
- 指令模型 (Instruct Model)： 一個經過調整以遵循指令的模型。
- LoRA / QLoRA： 使用低秩適配器的高效微調方法，QLoRA 透過量化基礎模型進行訓練。
- MoE： 混合專家。一種稀疏架構，其中只有選定的專家子網路在每個 token 上激活。
- 權重 / 參數 (Weights / Parameters)： 模型內部的學習數值。
推論機制
- BOS / EOS： 序列開頭和序列結尾的 token。
- 對話模板 (Chat Template)： 用來表示系統、使用者、助手和工具訊息的格式化方式。
- 上下文視窗 (Context Window)： 模型一次能處理的最大 token 數量。
- 解碼 (Decode)： 模型逐個生成新 token 的階段。
- DFlash： 一種 2026 年的投機解碼方法，使用區塊擴散進行平行草稿生成。
- DDTree / DTree： 一種投機解碼方法，從區塊擴散分佈建立草稿樹並高效驗證。
- GQA / MQA： 注意力機制的變體，能減少 KV 快取大小並提升推論效率。
- 推論 (Inference)： 執行模型以產生輸出。
- KV 快取 (KV Cache)： 儲存先前 token 的鍵/值注意力狀態。
- 預填充 (Prefill)： 模型在生成之前處理輸入提示詞的階段。
- RoPE： 旋轉位置編碼，現代 LLM 中常見的位置編碼方法。
- 投機解碼 (Speculative Decoding)： 一種加速技術，由較便宜的草稿模型提出 token，再由目標模型驗證。
- Token 化器 (Tokenizer)： 將文字轉換為 token ID 及反向轉換的元件。
- Top-p / Top-k / 溫度 (Temperature)： token 生成的取樣控制項。
檢索、檔案與服務
- AWQ： 活化感知權重量化。
- 嵌入模型 (Embedding Model)： 將文字轉換為向量以進行搜尋/檢索的模型。
- FP8 KV 快取： 某些執行時期支援的實用 8-bit KV 快取壓縮模式。
- GGUF： 由 llama.cpp 大量使用的模型檔案格式。
- 分頁注意力 (PagedAttention)： vLLM 風格服務使用的 KV 快取記憶體管理技術。
- 量化 (Quantization)： 降低數值精度以節省記憶體並提升效率。
- RAG： 檢索增強生成。檢索相關的外部上下文並提供給模型。
- 重新排序器 (Reranker)： 根據相關性對檢索到的段落進行重新排序的模型。
- Safetensors： 一種更安全的張量序列化格式，避免基於 pickle 的執行風險。
結語
本機 LLM 生態系統包括緊湊的邊緣模型、強大的 7B 到 32B 消費級模型、大型 MoE 開放權重系統、多模態模型、長上下文模型、本機推理模型、成熟的推論執行時期，以及日益強大的私有服務堆疊。
但基本原則並未改變：模型一次預測一個 token、token 不是單詞、權重不等於整個模型、對話模板很重要、KV 快取是隱藏的記憶體帳單、量化是一種取捨、長上下文不是免費的、RAG 的品質取決於檢索、微調需要評估，而本地隱私仍然需要安全紀律。
你不需要神話來好好執行本地模型。你需要知道什麼適合記憶體、模型預期什麼模板、執行時期如何運作，以及你的評估是否與你關心的任務匹配。
本機 LLM 大多是記憶體計算加上格式設定加上評估。把這些做對，其餘的堆疊就會變得更容易理解。
下次再見。
-Ahmad
