當你在 ChatGPT、Claude 或 DeepSeek 輸入一段話、模型在幾百毫秒內就開始一個字一個字回覆—這個過程感覺很簡單、實際上是現代運算中最精細的工程之一。本文整理 AI 工程師 Akshay Pachaar 的完整推論流程解析、從 tokenization、embedding、attention、到 prefill／decode 兩階段、KV cache、量化、與 DeepSeek V4 為何把快取體積砍到原本 10%。
核心心智模型：LLM 只是「猜下一個 token」、然後反覆做
大型語言模型本質上只做一件事：預測下一個 token。它接收你輸入的 token 序列、計算下一個 token 的機率分布、抽樣產生一個 token、把該 token 接到輸入末尾、再預測下一個—不停重複、直到模型輸出停止符或達到上限。
整個推論流程的關鍵問題不是「它怎麼預測」、而是「為什麼第二個 token 比第一個快很多？」這個答案、會牽出現代 LLM 服務最重要的兩個概念：prefill 與 decode 兩階段、以及 KV cache。
Step 1：Tokenization 把文字變數字
神經網路不讀文字、只讀向量。所以你的提示詞首先會經過 tokenization、被切成一塊一塊的「token」、每個 token 對應一個整數 ID。現代 LLM 多數採用 BPE（Byte Pair Encoding、位元對編碼）：從原始字元出發、把最常一起出現的字元對逐次合併、最後得到約 5 萬個常用 token 的詞彙表。
這一步的影響比多數人想像得大。在 tokenizer 訓練資料中比重低的語言、會被切成更多 token、推論成本就上升、速度就變慢。中文、繁體中文在許多英文導向的 tokenizer 中、每個字常被拆成 2 至 3 個 token、這是中文使用者推論成本偏高的根本原因之一。
Step 2：Embedding 把整數變向量、再注入位置資訊
每個 token 的整數 ID 會去查一張巨大的「embedding 表」。如果模型詞彙是 50K、隱藏維度是 4096、這張表的形狀就是 [50000, 4096]。每個 token 取出一行向量、就是它的 4096 維表徵。
這些向量不是隨機的—訓練時模型會把語意相近的 token 推到同一片空間區域、king 和 queen 在某個方向相鄰、python（語言）和 javascript 在另一個方向相鄰、python 和 snake（蟒蛇）又在第三個方向相鄰。
位置資訊也在這一步被注入、因為 attention 機制本身不知道哪個 token 在前哪個在後。當前主流模型多採用 RoPE（Rotary Position Embedding、旋轉位置編碼）、依 token 位置旋轉向量、把順序資訊隱含在向量本身。
Step 3：Self-Attention 是 Transformer 的核心
向量序列接著進入 32 層（或更多）transformer 層、每層做兩件事：用 self-attention 在 token 之間混合資訊、再用 feed-forward 在每個 token 內部混合資訊。
Self-attention 的運作是：每個 token 透過三個學習得到的權重矩陣 Wq、Wk、Wv、產生 query（查詢）、key（鍵）、value（值）三個向量。每個 token 用自己的 query 對其他所有 token 的 key 做內積、得到「該 token 應從別的 token 拉多少資訊進來」的權重、再以此加權混合 value。
這就是 attention 的魔法：每個 token 自行決定要看上下文中的哪幾個位置、把有用的資訊拉進自己的向量。32 層疊起來、模型就能跨越上千 token 追蹤指涉。Attention 後接的 feed-forward 網路、則承擔模型大部分的「知識」、attention 負責搬運資訊、feed-forward 負責處理資訊。
Prefill 與 Decode：同個 GPU、兩種完全不同的瓶頸
這是本篇最關鍵的分界。生成一段 200 字的回覆、實際上是兩個性質完全不同的任務、跑在同一張 GPU 上。
Prefill 階段—當你送出提示詞、模型必須先把所有輸入 token 跑過一次、才能生成第一個 token。這一步可以「並行」處理所有輸入 token：每個 token 的 Q、K、V 同時計算、attention 是大型矩陣對矩陣乘法。GPU 為這種運算而生、運算單元（Tensor Cores）滿載、瓶頸在「算力」。這個階段的延遲指標叫 TTFT（Time to First Token、首字延遲）。
Decode 階段—第一個 token 出來後、模型切換模式。產生第 51 個 token 時、它只需要計算這個新 token 的 Q、K、V、過去 50 個 token 的 K、V 都已算過、不必重來。問題是：每個 token 計算量很小、但 GPU 仍要從顯存把整個模型權重與整段 KV 歷史載入、做一次微小運算、再丟回去。瓶頸從「算力」翻轉到「記憶體頻寬」。這個階段的延遲指標叫 ITL（Inter-Token Latency、token 間延遲）、它決定了模型「打字」感受快不快。
所以 prefill 是 compute-bound、decode 是 memory-bound—同樣的模型、同樣的硬體、卻有完全不同的效能特性。
KV Cache：讓 LLM 推論可行的關鍵優化
Decode 階段「不重算過去 token 的 K、V」、靠的就是 KV cache。每個 transformer 層維護兩個張量、分別存所有歷史 token 的 K 與 V、新 token 算出 K、V 後就 append 進去、attention 時直接讀整段歷史。
沒有 KV cache、生成 1,000 個 token 的回覆每一步都要重算整個成長中的序列、複雜度二次方爆炸。有了 KV cache、長生成可以加速 5 倍以上。但代價是：cache 住在 GPU 顯存裡、每多生成一個 token、cache 就增大一份。13B 規模的模型、每個 token 約佔 1MB；4K 上下文就燒掉 4GB 顯存、單純存放這個 cache。
這就是「長上下文很慢、很貴」的真正原因—不是模型「想」不過來、而是 cache 把顯存吃光、單張 GPU 能服務的同時用戶數隨之大跌。常見的優化手段包括：把 cache 量化成 INT8 或 INT4、用 sliding window 丟掉太舊的 token、用 grouped-query attention（GQA）讓多個 attention head 共用 K、V、或像 vLLM 採用的 PagedAttention 把 cache 分頁管理（類似作業系統管理記憶體）。
DeepSeek V4 的快取革命：1M context 下砍到原本 10%
量化和分頁把 KV cache 當成「固定成本」優化。DeepSeek 2025 年底預覽的 V4 系列走更激進的路線：直接重新設計 attention、讓 cache 從一開始就很小。
V4 採用混合機制、結合稀疏與密集兩種壓縮 attention 變體、兩者都在高度壓縮過的 KV 流上運作。在百萬 token 上下文下、V4-Pro 報告 KV cache 體積僅前代的約 10%、每 token 計算量僅約 27%。意義不只是「DeepSeek 又便宜了」、而是 KV cache 已成為整個 LLM 領域被優化的瓶頸—當 attention 機制本身被重新設計來縮小 cache、代表整個技術社群的「限制條件」已徹底位移。
對台灣讀者更實用的訊息是：DeepSeek V4-Flash 已上 Ollama Cloud 與美國主機（參見 abmedia 4/24 報導）、Claude Code、OpenClaw 已可一鍵串接、不必自架就能驗證新一代 attention 在長上下文場景的優勢。
Quantization：用精度換速度與顯存
訓練需要高精度、推論不需要。多數正式部署改用 FP16 或 BF16 取代 FP32、立即把顯存與 throughput 加倍。更激進的做法把權重量化為 INT8、甚至 INT4。
數字直觀：7B 參數模型在 FP32 下需 28GB、FP16 下 14GB、INT8 下 7GB、INT4 下僅 3.5GB。這就是為什麼一般筆電顯卡也能跑 7B 模型。GPTQ 與 AWQ 等方法會挑選每個通道的縮放係數、讓有損壓縮造成的品質損失最小化—設計得好的 INT4、在多數標竿上的表現只比原版差 1 個百分點以內。
把所有步驟串起來：一段提示詞的完整旅程
把上面所有環節串起來、一次推論的完整路徑是：（1）Tokenize—文字變整數 ID。（2）Embed—ID 變向量、注入位置資訊。（3）Prefill—所有層對所有輸入 token 並行運算、屬於 compute-bound、KV cache 被建立、第一個輸出 token 生成。（4）Decode loop—每次只投影新 token 的 Q、對 cache 中的 K、V 做 attention、跑 feed-forward、抽樣輸出、把新 K、V 寫回 cache、屬於 memory-bound。（5）Detokenize—token ID 轉回字元、串流輸出到螢幕。
vLLM、TensorRT-LLM、Text Generation Inference 等服務框架在這個迴圈外加上連續批次（不同用戶的 token 可在同一個 GPU step 中交錯）、speculative decoding（小模型先打草稿、大模型驗證）、與精細的記憶體管理—這就是單張 GPU 服務數十用戶的方法。
給開發者的實務 takeaway：你該關心 TTFT 還是 ITL？
當推論流程的全貌清楚、幾個實務判斷會自然浮現：
長提示詞會放大 TTFT、長輸出會放大 ITL—它們壓力來源不同、別把優化資源放在錯的指標上。Context 不是免費的、上下文加倍不只翻倍計算、還會壓縮 KV cache 可容納的批次大小。量化是當前最高槓桿的旋鈕、FP16 換到 INT8 經常能砍掉一半延遲、品質損失極小。GPU 使用率（utilization）也常是誤導指標—prefill 階段把 GPU 拉滿、decode 階段可能只用 30%、解法不是更多算力、而是更快的記憶體或更小的 cache。
Transformer 架構吸引最多目光、但推論效能其實活在「無聊的細節」裡：記憶體配置、cache 管理、位元寬度。當有人說「這個模型很慢」、下一個問題該問的不是「換 GPU」、而是「慢在『開始』還是『串流』？」—答案決定整個優化路徑。
這篇文章 LLM 推論完整教學：KV cache 與 DeepSeek V4 的快取革命 最早出現於 鏈新聞 ABMedia。
