Decode（生成）

進階更新日期：2026/08/30日

畫面上的回答為什麼逐步出現？

在聊天介面送出問題後，模型通常不會等完整答案全部完成才一次顯示。你會看到文字陸續出現；在模型內部，這段工作是以 Token 為單位逐步進行。

Prefill 先處理完整輸入，準備第一個新 Token 所需的結果。接下來進入 Decode：模型根據 Prompt 與已經產生的內容，計算下一個 Token，再把它加入 Context，繼續計算下一步。

這個循環會持續到模型產生停止標記、符合 App 設定的停止條件，或到達輸出長度上限。

標準 LLM 的回答具有前後依賴：下一個 Token 要參考前面已經產生的 Token。模型還不知道尚未生成的內容，因此不能直接把同一段回答的所有未來 Token 一次算完。

例如，模型產生「台北」之後，下一步會把「台北」也納入前文，再決定後面是「市」、「車站」或其他 Token。每一步的結果都會改變下一步看到的 Context。

KV Cache 會保留前文可重用的運算結果，避免每一步都重新處理整段內容。Decode 仍要依序執行，但不必把所有舊 Token 從頭計算一次。

在單人、一次處理一個請求的 Local LLM 情境中，Decode 每一步只新增一個 Token，卻仍要使用模型各層所需的權重。常見影響因素包括：

因素	對 Decode 的影響
模型大小與權重精度	模型越大，通常每一步要讀取與計算的資料越多；量化可以減少權重資料量，但仍需要 Runtime 的高效率實作。
記憶體頻寬	Decode 會反覆使用模型權重與 KV Cache，因此經常比 Prefill 更容易受到記憶體頻寬限制。
Context 與 KV Cache	Prompt 與已生成內容越長，需要保存及參考的資料通常越多，可能降低速度或造成記憶體不足。
執行軟體與硬體分工	Runtime 如何使用 CPU、GPU、記憶體與最佳化核心，會改變實際速度。
批次與同時請求數	多個請求一起處理可以提高整體吞吐量，單一使用者的 Token 間等待時間卻可能增加。
輸出 Token 數	直接增加需要執行的循序步驟，讓完整回答花更久；它不會單獨決定每秒生成速度。

「Decode 通常較受記憶體頻寬影響」是常見單人推論的起點，不是適用所有模型與設定的定律。批次、模型架構、Context、推測式生成與硬體分工都可能改變瓶頸。

工具可能使用以下名稱：

可以用「輸出 Token 數 ÷ Generation Token/s」粗略估算 Decode 時間。例如，以 20 Token/s 產生 200 個 Token，約需 10 秒。模型載入、Prefill、文字轉成 Token、取樣與介面傳輸不包含在這個簡化估算裡。

不同模型可能使用不同的斷詞方式，因此不能只用 Token/s 比較回答閱讀速度或模型能力。要比較硬體或 Runtime，應固定完整模型、量化、Context、輸出長度與執行設定。

Prefill 影響模型處理輸入與準備第一個輸出的速度；Decode 影響後續 Token 出現的速度。兩者使用相同模型，對硬體資源的利用方式不同。

因此，Prompt Processing 很快，不代表 Text Generation 也會同樣快。Benchmark 應分別記錄 pp 與 tg，再依實際工作中的輸入及輸出長度判斷。

「Decode 是把模型檔案解壓縮或載入記憶體。」 不是。模型載入發生在推論開始前；Decode 是模型產生輸出 Token 的階段。

「GPU 峰值算力越高，Decode 就一定等比例變快。」 不一定。單人 Decode 經常受記憶體頻寬、權重大小、KV Cache 與 Runtime 影響。若要一起比較 Prompt Processing 與文字生成速度，可閱讀〈LLM 的 Prompt 處理速度與文字生成速度都是看 GPU 有多快嗎？〉。

「Prefill 很快，Decode 也一定很快。」 不一定。兩個階段的工作方式與常見瓶頸不同，應分開測量。

試著回答以下問題，來確認是否已學會。不確定答案的話，再回到對應段落複習。打勾狀態是方便你在這個頁面一一確認用，不會被儲存。