K3 一律推理
K3 使用頂層 `reasoning_effort`，支援 `low`、`high`、`max`。不要把 K2.x 的 `thinking` 設定直接複製到 K3 請求。
繁體中文
KIMI K3 / 推理預填
預填答案，不要預填錯推理區塊
Kimi K3 一律會思考。Partial Mode 會接續給定的 assistant 前綴，而推理輸出與最終內容可能是不同欄位。空回覆、400、思考外洩與下一輪脈絡遺失，常常都出在這條邊界。
Kimi 官方 Chat Completions 文件說明 K3、Partial Mode 與 K2.x 的差異，但不同供應商仍可能有自己的支援範圍。
先看契約
推理和預填是兩條不同的邊界
Kimi 文件寫得很明確。社群文章可以提供供應商和 SillyTavern 的線索，但不能證明有通用繞過方式。
Partial Mode 接續內容
在 `messages` 末尾放入 `assistant` 訊息並設為 `partial: true`，即可引導輸出前綴。這不是官方記載的私有推理注入方式。
供應商也是測試變數
閘道可能重新命名、丟棄或拒絕 `partial`、`reasoning_effort`、`reasoning_content`。先關閉預填做同一 prompt 的對照，再修改角色卡。
欄位地圖
K3 與 K2.x 不是同一個 thinking 開關
先看模型家族，再選欄位。這張表用來排錯，不代表閘道一定會透傳所有欄位。
| 問題 | Kimi K3 | Kimi K2.x |
|---|---|---|
| 能關閉 thinking 嗎？ | 不能。K3 一律推理。 | 依模型而定。K2.6 記載 enabled 或 disabled；K2.7-code 固定 enabled。 |
| 推理控制 | 頂層 `reasoning_effort`：low、high、max。 | `thinking.type`，預設值依模型而定。 |
| 保留歷史 | K3 使用 preserved thinking。供應商要求時要回傳完整 assistant turn。 | K2.x 記載 `thinking.keep`，不同模型規則不同。 |
| 預填 | Partial Mode 加 `partial: true` 接續最後的 assistant 前綴。 | 查看模型與供應商文件，不要從 K3 範例推定支援。 |
若 K3 請求出現 `thinking: { type: "enabled" }`，請移除，除非供應商明確記載轉換層。
預填檢查
先跑乾淨對話，再加入前綴
一個受控的小測試，可以分辨 prompt、回應映射、歷史和供應商問題。保持模型與端點不變，一次只改一個變數。
最小 Partial Mode 結構
{
"model": "kimi-k3",
"messages": [
{"role": "user", "content": "Return a status object."},
{"role": "assistant", "content": "{\"status\":", "partial": true}
],
"reasoning_effort": "low",
"stream": false
}程式碼展示欄位關係，不是 SillyTavern 通用 preset。不要把 API 金鑰放進程式碼。
- 01
1. 確認模型家族
核對供應商目前列出的模型 slug。官方 Kimi API 的 K3 別名是 `kimi-k3`，閘道可能使用其他別名。
- 02
2. 發出一次乾淨請求
移除 `partial`，使用一般 user 訊息，只設定文件中的 K3 推理欄位。保存最終 `content` 以及回傳的 `reasoning_content`。
- 03
3. 加入短 assistant 前綴
在最後一則 assistant 訊息放入短前綴並設為 `partial: true`。先用 `{"status":` 這類格式提示，不要先塞長角色扮演區塊。
- 04
4. 帶回完整 assistant turn
下一輪依供應商文件保留完整 assistant 訊息。不要把 reasoning block 拼進 content 前綴。
供應商與前端
OpenAI 相容只是形狀，不是保證
SillyTavern 支援自訂 OpenAI 相容端點；沒有 models 介面時也能手動填寫模型 ID。真正決定 K3 欄位能否保留的是端點。
| Moonshot 官方 | 閘道或 SillyTavern 路徑 | |
|---|---|---|
| 模型 | `kimi-k3` | 嚴格使用供應商目前的 alias。 |
| 推理 | `reasoning_effort` low、high、max | 確認是否透傳、改名或丟棄。 |
| Partial Mode | assistant 前綴加 `partial: true` | 確認該模型和路徑是否接受欄位。 |
| 回應歷史 | 依要求保留 assistant 訊息 | 確認 reasoning 與 content 是否分開保留。 |
| SillyTavern 設定 | 使用文件指定的 API 來源 | Test Message 和 Bypass API status check 可協助隔離前端檢查。 |
現象到測試
讓錯誤決定下一步改什麼
這些測試會縮小排查範圍。社群報告可以提出假設，但你選定的供應商請求與回應才是證據。
匯入 K2.x preset 後 400
推理結構錯誤
移除 `thinking` 和 K2.x 歷史欄位，改用 K3 的 `reasoning_effort` 與供應商目前 alias。
看到思考後沒有答案
回應映射或歷史
檢查串流 delta 和非串流欄位，不要只保留 `content`，要按要求帶回完整 assistant 物件。
預填後變成拒答或怪回覆
Partial Mode 或供應商
關閉 `partial` 對比乾淨回應，確認該模型和路徑的文件確實支援預填。
思考文字出現在最終回答
渲染邊界
將 `reasoning_content` 與 `content` 分開顯示，不要合併兩個欄位。
下一輪遺失脈絡
歷史被截斷或編輯
記錄送出的 messages，保留完整 assistant 物件，並檢查供應商上下文上限。
思考時間很長
推理強度、prompt 或額度
嘗試供應商記載的較低強度，縮短測試歷史，再和關閉預填的結果比較。
更少設定的路徑
先讓 Kimi 貼著資料回答
如果你要查看角色設定、API 文件或研究頁面，Tabbit 可以選擇即時模型並保持資料在視野中。這個瀏覽器任務不必先接端點，SillyTavern 仍適合角色卡和擴充功能。
01
保持頁面或檔案開啟
用目前頁面、螢幕截圖或本機檔案作為上下文，不必先構造 prefill 請求體。
02
查看即時模型選擇器
清單中可用時選擇 Kimi-K3。截圖只是介面範例，實際權限取決於你的版本和方案。
03
比較一次乾淨回答
用側欄快速提問，或比較多個回覆。在回到供應商 Partial Mode 測試前，先建立基線。
推理預填 FAQ
下一輪出問題前先看答案
Kimi K3 支援 assistant prefill 嗎？+
官方 API 記載 Partial Mode。在 `messages` 末尾加入 assistant 訊息並設為 `partial: true`，讓 K3 接著前綴生成。具體供應商仍需個別核對。
可以預填 Kimi K3 的 reasoning_content 嗎？+
不要直接假設可以。文件中的 Partial Mode 預填的是 assistant 輸出前綴，推理輸出是另一條回應邊界，供應商可能拒絕或改寫注入嘗試。
應該送 thinking 還是 reasoning_effort？+
K3 使用頂層 `reasoning_effort`，支援 `low`、`high`、`max`。`thinking` 物件屬於 K2.x 範例，不是所有 Kimi 模型通用的開關。
為什麼預填請求回傳空回答？+
關閉預填，先發一次乾淨請求，確認 `content` 與 `reasoning_content` 是否分開回傳。同時檢查下一次請求是否保留完整 assistant 訊息。
為什麼 SillyTavern 顯示 400？+
檢查模型 alias、端點、JSON 結構和供應商支援。先移除照搬的 K2.x 欄位與不支援的 sampler，再修改 prompt。
只有 Moonshot 支援預填嗎？+
Reddit 討論中有人表示自己只在 Moonshot 找到支援，但這是使用者觀察，不是通用供應商規則。請以你使用路徑的目前文件為準。
先看清邊界，再選擇工作流
使用官方 K3 欄位，拿短前綴測試 Partial Mode，並保留供應商要求的 assistant turn。若問題來自網頁或檔案，開啟 Tabbit，從即時清單選擇 Kimi-K3。
支援 macOS 和 Windows。模型存取與額度取決於目前版本和方案。