【2026 最新】LLM 採樣參數怎麼調？Temperature、Top-p、Top-k、Min-p 四組 A/B Test

把 Temperature 從 1.0 降到 0.2，回答就會更準嗎？不一定。你可能只是讓模型更常抽到同一顆「目前機率最高的球」；如果那顆球本來就是錯的，低溫只會讓錯誤更穩定。更麻煩的是，你在介面填的數字，可能先被模型設定、Agent 工具、API gateway 或推論引擎改寫，最後根本不是後端真正使用的值。

這篇 LLM 採樣參數教學要交付兩樣東西：一個能分清 Temperature、Top-p、Top-k、Min-p 的抽球心智模型；以及四組只改一個變因、可以自己重跑的 A/B Test。讀完後，你不只會「調數字」，還會知道怎麼追出數字的所有權、如何選評分指標，以及何時該停止調 sampler，回頭檢查 prompt、模型或工具協定。

先說清楚驗證範圍：下文四組矩陣是讀者可重跑的實驗設計；本文不報告 AlphaLab 本機 benchmark 結果。本文實際核對的是官方模型卡、推論引擎文件與原始碼、OpenCode 的正式版與開發分支差異，以及採樣研究的支持與反證。

如果你已經在驗收本機 Agent，可搭配 Qwen3.8-27B 本機 Agent 六關協定；如果連量化檔與記憶體還沒決定，先讀 GGUF 量化指南。本文只處理模型成功啟動之後的「下一個 token 怎麼選」。

LLM 採樣參數一句話心智模型：依引擎順序調權重、剪候選，再抽 token

LLM 每次生成一個 token，都會先替詞彙表裡的候選項目打分。你可以把它想成一個裝滿彩球的桶子：球上的數字代表相對勝算；採樣流程會依引擎既定順序調整權重、裁剪候選，最後從仍可選的 token 中抽一個。

採樣＝依引擎順序調整權重、裁剪候選，再從可選 token 中抽一個

它調整生成路徑，不負責判斷內容是否正確。

Temperature：在正溫度下縮放 logits，不直接設定固定候選數

Temperature 會把 logits 除以溫度後再正規化。小於 1 時，高分 token 的相對優勢被放大；大於 1 時，機率分布變平，尾端候選比較有機會被抽到。它不是「正確度」滑桿：當最高分候選不正確時，低溫也可能更穩定地重複錯誤。vLLM 的 SamplingParams 文件把 0 定義成 greedy；一旦進入 greedy，由隨機抽樣造成的變異會消失，但其他執行層非決定性仍可能存在，也不代表答案已被驗真。

Top-k：依第 k 名切出候選門檻

Top-k 的規則最直觀：不論分布長什麼樣，每一步都以第 k 名附近切掉較低分 token。概念上是保留最高的 k 個，但邊界剛好同分時，不同實作可能留下超過 k 個，不能把候選數量一概寫死。它的優點是名額門檻清楚；缺點是固定 k 不看當下信心。有時前 5 顆已涵蓋幾乎全部機率，有時第 21 顆仍很合理，固定門檻都不會在意。

Top-p：保留累積機率達到 p 的最小集合

Top-p 又叫 nucleus sampling。它從最高機率開始往下加，直到累積機率達到門檻，因此候選數量會隨模型當下的信心伸縮。原始 nucleus sampling 論文研究的是開放式文字生成與退化問題；這不能直接外推成「Top-p 會提高所有任務的事實正確率」。

Min-p：用最強候選當相對門檻

Min-p 會留下機率至少達「最高機率 × min_p」的 token。若最高候選非常強，門檻一起升高；若分布較平，更多候選可留下。這種相對門檻與 Top-p 的累積門檻不同。Hugging Face 生成文件也以最高 token 機率的倍數定義它。

但不要把 Min-p 寫成已被證實的「新一代最佳 sampler」。原始 Min-p 論文主張它能改善創作品質與多樣性；後續的批判性重分析則指出，現有證據不足以證明 Min-p 優於基線。對實作者最穩健的結論是：把它當成一個可測的候選規則，不是升級按鈕。

為什麼同一組數字，換引擎就可能不是同一個實驗？

因為 sampler 有順序。vLLM 目前的取樣流程是先套 Temperature，再做 Min-p，接著 Top-k／Top-p，最後抽樣；可在其Sampler 原始碼文件核對。llama.cpp b10488 的 common source defaults則把 Temperature 放在 Top-k、Top-p、Min-p 之後。前一步改過機率，後一步看到的候選集合就可能不同。

預設來源也不同。vLLM v0.27.1 的 SamplingParams 類別預設為 Temperature 1.0、Top-p 1.0、Top-k 0、Min-p 0；OpenAI server 若載入模型 generation_config.json，仍可能覆寫它們。llama.cpp b10488 的 common_params_sampling預設為 0.8、0.95、40、0.05，啟動參數或 request 也可覆寫。這些都不是模型廠商替所有任務推薦的最佳值，更不能跨引擎直接把數字當成同一個 treatment。

參數所有權：你填的值，到底經過哪六層？

當回答和預期不同，先別急著再調一輪。把生成鏈拆成六層：

1. 模型層：模型 revision、chat template 與 repository 裡的 generation_config.json。
2. 推論引擎層：llama.cpp、vLLM 或其他 runtime 的版本、啟動參數、預設值與 sampler 順序。
3. Client／Agent 層：介面或 Agent 是否為特定模型補上 Temperature、Top-p 等預設。
4. SDK 層：欄位是原生支援、放在 extra_body，還是因 schema 驗證而被丟掉。
5. Gateway 層：代理服務是否允許、忽略、正規化或覆寫供應商特有欄位。
6. 有效請求層：最後送出的 JSON、server log 或可觀測端點實際顯示什麼。

所有權的優先序沒有跨工具通用規則，必須看該版本原始碼或 resolved config。這也是 Agent Observability真正有用的地方：不是「有 log 就好」，而是能從 UI 一路追到有效 request。

2026 年 8 月的 OpenCode × Qwen 案例

截至 2026 年 8 月 19 日，npm 的 OpenCode latest 仍是 v1.18.18。這版的模型轉換程式碼會檢查轉成小寫的 model.api.id：只要含 qwen就準備 Top-p 1；模型另有宣告支援 Temperature 時，也準備 0.55。在標準欄位選擇階段，agent 明寫的值先於這組內建值；但後續 plugin 或 provider-specific raw options 仍可能再改。2026 年 8 月 18 日合併的 修正 commit已從開發分支移除兩個 Qwen 特例；本文查核時，npm 的 latest 與 GitHub latest release 都仍指向 v1.18.18，而該 tag 不含這筆修正。

同時，Qwen3.8-27B 官方模型卡的固定 revision對 thinking 與 non-thinking 模式給出不同建議：thinking 為 Temperature 1.0、Top-p 0.95、Top-k 20、Min-p 0；non-thinking 為 0.7、0.8、20、0。這不證明其中任何一組對你的任務最優，卻精準說明兩件事：模型模式會改 baseline；Client 內建值也可能與新版模型卡不同。

所以查 sampler 時要記錄「版本＋來源」，不要只截一張設定頁。正式版、開發分支與文件可能短暫不同步；更新工具後，也應把同一個 request fixture 重播一次。

開始前：先做一張不會互相污染的實驗卡

四組測試都使用同一條規則：先採模型卡或已驗證 baseline，只改一個 sampler。若每格只跑 10 次，最多把結果視為探索性 smoke test；樣本數應由失敗率、效果大小與所需不確定性決定。每次保存完整輸入與輸出，不只留平均分。

每筆 run 至少要寫下：模型名稱與 revision、chat template hash、runtime 與版本、完整 sampler 順序、system／user prompt、max tokens、seed、thinking／reasoning 模式、結構化輸出設定、原始 request、原始 response、成功與否。若使用量化模型，量化檔與 KV cache 設定也要固定；speculative decoding／MTP、batch 與 concurrency 也不能在 A、B 之間變動。同一個 task／replicate 讓 A、B 使用配對 seed，並隨機交錯執行順序；不要先跑完 A、隔天才跑 B，把服務更新或機器狀態誤認成 sampler 效果。其他旋鈕即使固定在 baseline，也仍會與 treatment 互動，因此結論只適用於這條已記錄的 sampler chain，不代表該演算法在所有組合下的純效果。

固定 seed 方便除錯，但不要把單一 seed 當成模型行為。vLLM 的重現性文件明確把可重現條件綁在相同硬體與版本等控制上，且預設不保證重現。正式比較應使用同一組多個 seed；若引擎不保證跨批次一致，就不要混用不同 serving 條件。

A/B Test 1：Temperature × 程式任務

問題：較低 Temperature 是否讓這個固定修 bug 任務更常通過測試？選一個有明確 failing tests 的小型函式，固定 repository commit、prompt、context 與測試指令。A 使用模型卡 Temperature；B 只把 Temperature 往下移一檔，其他 sampler 完全不動。模型產生的程式必須在無網路、有限時間與權限的隔離環境執行，不可直接放進日常開發機或正式系統。

• 主指標：完整 unit tests 通過率。
• 次指標：編譯／語法失敗率、超出範圍的檔案修改、每次成功所需 token。
• 不要用：「看起來比較有自信」或單次答案長短。

如果 B 的文字更一致但 unit tests 沒改善，結論不是「低溫比較準」，而是「低溫讓這個模型在這個 fixture 上變得更一致」。想把這類任務做成長期回歸測試，可沿用 Context Compaction 驗收裡固定 fixture、分層計分的做法。

A/B Test 2：Top-p × 有來源摘要

問題：改變 nucleus 大小，會如何影響摘要的涵蓋與無根據陳述？準備一篇固定原文與一張事先人工寫好的 fact sheet。A 使用 baseline Top-p；B 只降低 Top-p，Temperature、Top-k、Min-p 與 prompt 不變。

• 主指標：必要事實涵蓋率與 unsupported claim 數量。
• 次指標：字數限制通過率、重複句、關鍵限定語是否保留。
• 盲評：先隱藏 A／B 標籤再評流暢度，避免數字預期影響判斷。

Top-p 只控制可抽候選，不會自動把輸出綁回來源。若兩組都出現無根據陳述，下一步通常是改 prompt、加入引用對齊或結構化抽取，不是繼續把 p 壓低。

A/B Test 3：Top-k × Tool Calling

問題：固定候選上限，會不會改變正確工具與參數的選擇？準備三個名稱相近但用途不同的 mock tools，以及可自動判斷的 20 個任務。A 使用模型卡 Top-k；B 只改成引擎文件定義的「停用 Top-k」值，先確認你的 runtime 對 0 或 -1 的語意。所有工具都只能寫入測試 sandbox；寄信、付款、刪檔等不可逆動作要用無副作用 mock，不能真的執行。

• 第一關：選對 tool name。
• 第二關：arguments 通過 JSON schema，且值正確。
• 第三關：工具結果接回後，最終任務真的完成。

結構化輸出可約束 JSON、regex 或 grammar；vLLM 文件列出的功能就是例子。但「格式合法」不等於「選對工具」，所以 schema pass 與 task pass 必須分欄。想先理解模型、runtime、harness 三層責任，可讀 AI Agent Harness 新手指南。

A/B Test 4：Min-p × 受限創作

問題：相對門檻是否在保留硬性限制時，改變作品多樣性？準備同一個創作 prompt，例如「120 字內、第二人稱、不得出現三個禁詞、結尾要回扣第一句」。A 把 Min-p 關閉；B 只開一個小幅實驗值，例如 0.05，Temperature 固定不動。這個 B 值是測試 treatment，不是跨模型推薦。

• 硬指標：字數、禁詞、視角與結尾限制通過率。
• 多樣性：去除標點後的重複開頭率、成對相似度，或獨立評審是否看出明顯模板化。
• 品質：盲評勝率與評審一致度；不要只交給同一個 LLM judge。

若 B 比 A 更有變化但限制通過率下降，就得到一個 trade-off，而不是「Min-p 勝出」。若差異小於評審分歧，也應誠實寫成未分勝負。

可直接改用的 vLLM 請求模板

下面假設你已在本機啟動 OpenAI-compatible endpoint。先把 MODEL_ID改成 GET /v1/models回傳的 ID，再用模型卡 baseline 填入四個 sampler。每次只改一個欄位，並把 request 與 response 成對保存：

curl -sS http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "MODEL_ID",
    "messages": [{"role": "user", "content": "在此貼上固定測試題"}],
    "temperature": 1.0,
    "top_p": 0.95,
    "top_k": 20,
    "min_p": 0,
    "seed": 42,
    "max_tokens": 512
  }'

這組數字取自本文查核時的 Qwen3.8 thinking 建議，只是示範如何建立 baseline；換模型、切 non-thinking 或更換 chat template 時，要回到對應模型卡重建。若 client SDK 不認得 top_k或 min_p，可依 runtime 文件改用額外 body 欄位，並在 proxy／server log 確認沒有被丟棄。另要注意，vLLM v0.27.1在設定 speculative decoding 時會拒絕非零 Min-p；先固定或關閉這個變因，不要把 request error 當成模型表現。

看到失敗症狀，應該先動哪一顆旋鈕？

• 同一句話一直重複：先檢查停止條件、prompt、history 與 repetition／presence penalty；不要假設降 Temperature 能治本。
• 格式壞掉：先用 JSON schema、grammar 或 tool parser 固定協定，再談 sampler。
• 事實錯誤但語氣很穩：加來源、檢索與可自動驗證的 rubric；Temperature 不是真偽開關。
• 創作太像模板：先在固定硬性限制下比較 Temperature 或候選截斷，每次只改一個。
• 設定完全沒反應：先追 effective request、模型模式與 sampler 順序，別盲調更多數字。
• Agent 第一輪成功、第二輪失敗：檢查 tool-call history 與 harness，而不是把全部責任推給 sampler。

重複懲罰不是第五種候選截斷器。它會依先前出現過的 token 改 logits；過強時會壓低先前出現 token 的相對分數，因此測試時應另外檢查必要重複、專有名詞、程式碼與多語輸出。Qwen3.8 模型卡也提醒，較高 presence penalty 可能導致語言混用與效能下降。若問題是冗長而非取樣，可參考 Output Style＋Eval的做法，把「是否完成」「是否精簡」拆成獨立評分，不要只靠生成旋鈕猜。

一個較容易歸因的逐一調參範例

以下是本文的實驗起點，不是跨模型最佳順序。

1. 先定義通過：為任務建立 unit test、fact sheet、schema 或創作限制。
2. 釘死執行鏈：模型 revision、template、runtime、量化、seed 集合與原始 request 全部留檔。
3. 採用官方 baseline：模型卡有分模式建議就照模式；沒有才從引擎預設開始，但明確記錄來源。
4. 先測 Temperature：不改候選截斷，觀察穩定性與成功率。
5. 再測一種截斷：Top-p、Top-k、Min-p 一次只選一種；不要把三個旋鈕一起收緊。
6. 最後才碰 penalties：只有看到重複症狀時才加入，並重新檢查語言、程式碼與專有名詞。
7. 升級後重播：模型、client 或 runtime 任一版本變動，都用同一 fixture 驗證 effective values 與分數。

常見問題 FAQ

Temperature 越低，幻覺越少嗎？

不保證。它可能降低輸出變化，卻不會新增來源或驗證機制；最高機率候選若是錯的，低溫仍會穩定選錯。

Temperature 設 0 就完全可重現嗎？

不能跨環境保證。Greedy 減少抽樣隨機性，但硬體、kernel、batch、runtime 版本與浮點運算差異仍可能改變結果。

Top-p 和 Top-k 應該同時開嗎？

引擎可能允許，但兩者串接後會共同縮小候選，且順序可能影響結果。建立 baseline 時先照模型卡；做因果比較時一次只改一個。

Min-p 一定比 Top-p 好嗎？

沒有足夠證據支持這個通用結論。它是不同的相對門檻，應在你的模型、任務與評分器上測試。

為什麼我在 UI 改了值，輸出完全沒變？

可能是 client 沒送出、SDK 丟棄、gateway 不支援、server 覆寫、模型模式不同，或固定 seed 加上任務本身已高度確定。先查原始 request 與 server 端有效設定。

每一格跑 10 次就夠嗎？

沒有固定答案；10 次只能提供非常有限的探索性訊號。稀有失敗、差距很小或任務異質性高時，需要更多樣本與不確定性區間；不要只報平均值。

Tool calling 最重要的是低 Temperature 嗎？

通常應先驗收 schema、tool parser、正確工具選擇與第二輪回接。低溫不能修好壞掉的協定。

換模型時可以沿用同一張設定卡嗎？

可以沿用測試方法，不能直接沿用結論。重新讀模型卡、確認 thinking 模式、template 與 runtime 支援，再建立新 baseline。

最後帶走的 5 個重點

• Temperature 縮放 logits，改變機率分布的尖／平程度；Top-k、Top-p、Min-p 用不同規則剪候選。
• 採樣參數控制生成路徑，不替回答驗真。
• 同一組數字在不同引擎、順序與模型模式下，不一定代表同一個實驗。
• 先追 effective request，再做單變因、多次、可自動評分的 A/B Test。
• 最好的設定不是最小的數字，而是對指定任務有可重跑證據的設定。