Kimi K3 與 Claude Fable 5 目前都可透過 Crazyrouter 的 OpenAI-compatible API 呼叫。若只比較模型名稱或單一問答，很難判斷兩者在實際開發工作中的差異。
本次測試以四類需要可驗證結果的任務進行比較：偏置硬幣停止時間、碰撞與彈簧物理題、Python 日誌聚合，以及五人排班約束推理。結果顯示，兩款模型沒有出現單方面全面勝出的情況：Fable 5 回應速度較快，Kimi K3 在數學推導的中間驗證較穩定；兩者產生的 Python 程式碼在提高輸出上限後，均通過相同的本地測試。
測試時間為 2026 年 7 月 17 日。先透過 GET /v1/models 確認下列模型 ID 存在：
xujfcn
kimi-k3
claude-fable-5
正式請求統一使用：
Base URL： https://cn.crazyrouter.com/v1
Endpoint： POST /v1/chat/completions
temperature：0.2
第一輪 max_tokens：4000
程式碼補測 max_tokens：7000
第一輪為每個模型四項任務，共八次請求。由於程式碼題在第一輪均被截斷，因此再以精簡提示詞與較高輸出上限各補測一次。
本次評估不只看 HTTP 狀態碼，也檢查：
finish_reason 是 stop 還是 length；| 任務 | Kimi K3 | Claude Fable 5 |
|---|---|---|
偏置硬幣直到出現 HHTH |
最終值與中間狀態均正確 | 最終值正確，但中間回代有算術錯誤 |
| 非彈性碰撞後壓縮彈簧 | 正確，約 0.2212 m |
正確，約 0.221 m |
| Python 日誌聚合，4000 tokens | 被截斷 | 被截斷 |
| Python 日誌聚合，7000 tokens | 8/8 斷言通過 | 8/8 斷言通過 |
| 五人排班約束推理 | 唯一解正確 | 唯一解正確 |
第一輪四項任務的平均延遲為：
Kimi K3：108.0 秒
Claude Fable 5：37.1 秒
這是本次請求的觀測值，不代表固定 SLA。上游負載、快取狀態與併發量都可能造成差異。
第一題設定為：硬幣正面機率 3/5、反面機率 2/5，持續投擲直到第一次出現 HHTH，且允許模式重疊。
這題需要建立前綴自動機：
S0：空前綴
S1：H
S2：HH
S3：HHT
S4：HHTH（吸收狀態）
狀態方程為：
E0 = 1 + pE1 + qE0
E1 = 1 + pE2 + qE0
E2 = 1 + pE2 + qE3
E3 = 1 + qE0
正確期望值是：
E[T] = 715/54
≈ 13.2407407407
Kimi K3 正確回代出：
E1 = 625/54
E2 = 475/54
E3 = 170/27
同時，它又使用模式 border 公式與公平硬幣特例進行獨立驗證，三種方法得到一致結果。
Fable 5 也得到正確的最終值 715/54，但在回代段將兩個狀態寫成：
E3 = 421/135
E2 = 1517/270
這兩個值與其前面列出的方程式不一致。因此，本題不能只用最後一行答案判定；若後續流程會使用中間狀態，Fable 5 的輸出仍需要額外檢查。
這也是本次測試中 Kimi K3 最明顯的優勢：不是最後數字不同，而是推導與自我驗證較一致。
物理題包含兩個連續階段：2 kg 小車以 6 m/s 撞上靜止的 3 kg 小車，碰撞為完全非彈性；組合體接著在摩擦因數 0.20 的水平面上壓縮 500 N/m 彈簧。
碰撞階段使用動量守恆：
V = (2 × 6) / (2 + 3)
= 2.4 m/s
碰撞前後動能分別為 36.0 J 與 14.4 J，因此損失 21.6 J。
壓簧階段只能使用碰撞後的 14.4 J：
14.4 = 1/2 × 500 × x² + 0.20 × 5 × 9.8 × x
250x² + 9.8x - 14.4 = 0
x ≈ 0.2212 m
Kimi K3 與 Fable 5 都正確處理了能量邊界，也指出錯誤使用彈性碰撞假設會得到約 0.360 m 的虛高壓縮量。Fable 5 額外說明彈性碰撞會讓兩車分離；Kimi K3 則檢查了 60% 的動能損失比例。兩者在本題均通過。
程式碼題要求實作：
aggregate(records, start, end)
輸入日誌可能包含同一 request_id 的重試、帶 Z 的 ISO-8601 時間、缺少 cache_read_tokens 的紀錄，以及成功或失敗狀態。函式必須取最後一次重試，使用半開區間 [start,end) 統計，並按照失敗數、平均延遲和 request ID 排序明細。
第一輪將 max_tokens 設為 4000，兩款模型的結果都是：
finish_reason = length
Kimi K3 的推理內容消耗了大量 token，最後沒有形成完整可見程式碼；Fable 5 已產生主要實作，但回應尾端同樣被截斷。
因此，這一輪不能直接下結論說哪個模型不會寫程式。更精確的說法是：兩款模型都沒有在該輸出上限內完成可交付結果。
提高輸出上限並縮短提示詞後，結果如下：
| 模型 | 延遲 | completion tokens | 結果 |
|---|---|---|---|
kimi-k3 |
145.2 秒 |
5,199 |
8/8 斷言通過 |
claude-fable-5 |
46.6 秒 |
3,710 |
8/8 斷言通過 |
兩份程式碼都在 Python 3.11 執行成功，驗證項目包括：
重試紀錄覆蓋舊結果
半開區間右邊界不計入
缺少 cache 欄位時使用 0
空輸入不發生除零
失敗數與平均延遲排序
相同時間戳的穩定選擇
Kimi K3 的版本更偏防禦式，會將時間統一轉換成 UTC；Fable 5 的版本較短，資料分組與排序也更直接。兩者本地測試結果相同，但 Fable 5 的交付速度較快。
最後一題要求將 Ada、Bo、Cici、Deng、Eli 安排在週一至週五，並滿足六項條件，包括 Ada 不在週一或週五、Bo 早於 Deng 且不相鄰、Cici 是 Ada 的隔天，以及 Eli 不在週二。
兩款模型都得到唯一解：
| 週一 | 週二 | 週三 | 週四 | 週五 |
|---|---|---|---|---|
| Eli | Bo | Ada | Cici | Deng |
排除邏輯是：Ada 在週二會迫使 Cici 出現在被禁止的週三；Ada 在週四時，剩餘條件會將 Eli 推到週二。因此 Ada 只能在週三，Cici 在週四，再由 Bo 與 Deng 的先後及間隔條件確定其他三人。
兩款模型的推理過程都能人工審查，本題沒有顯著品質差距。
第一輪 usage 統計如下：
Kimi K3 completion tokens：13,975
Kimi K3 reasoning tokens：約 12,500
Fable 5 completion tokens：10,187
本次未回報 reasoning tokens
Kimi K3 使用較多推理 token，與數學題中較完整的自我檢查相符，但也造成兩個工程上的代價：
因此，模型選型不應只看答案是否正確，也要同時觀察：
finish_reason
可見 content 長度
completion tokens
reasoning tokens
程式碼測試結果
根據這次測試，Fable 5 適合優先用於：
Kimi K3 則可保留在：
若是長程式碼，第一個應該調整的是輸出預算，而不是立刻更換模型。兩者在 4000 tokens 都被截斷，在 7000 tokens 都能通過相同的測試。
這是一組小樣本測試，不是長期 benchmark。它可以支持以下觀察：
但它不能證明 Kimi K3 在所有數學題中都更準確，也不能證明 Fable 5 永遠快上三倍。若要用於正式選型，應將每一類任務重複 20 至 50 次，觀察成功率、截斷率、P50/P95/P99 延遲、首 token 時間，以及每個通過任務的實際成本。
這次比較沒有一款模型全面勝出。
Kimi K3 比較像是願意投入更多推理預算、但需要更長等待時間的模型；Claude Fable 5 則以較快交付為優勢，但重要推導仍應搭配回代或程式驗證。
如果工作負載是高頻、可測試的程式碼與結構化任務，可以先從 Fable 5 開始；若工作內容偏精確數學推導，或中間狀態會被後續流程重用，Kimi K3 值得保留。
對實際系統而言，最重要的結論不是選哪個名字，而是建立驗證鏈：
檢查 finish_reason
確認可見內容完整
為長輸出預留足夠 max_tokens
對程式碼執行自動化測試
必要時做模型重試或切換
API Base URL：https://cn.crazyrouter.com/v1
完整站內原文：
https://crazyrouter.com/zh/blog/kimi-k3-vs-claude-fable-5-hard-reasoning-benchmark-2026
建議記錄的欄位包括：requested_model、returned_model、finish_reason、completion_tokens、reasoning_tokens、總耗時與本地測試結果。
本文使用 Crazyrouter 公網圖床的 PNG 圖片，已驗證可回傳 HTTP 200；沒有使用本地圖片路徑或需要登入的圖片地址。
看影片追技術