大家好,我是 Ai 學習的老章
Kimi 也算我們的常客,尤其是 K2 模型,十分亮眼,目前也是我 Agent 常配模型之一
昨晚 ,剛剛模型文件開源,技術博客也發布了,本文做個梳理。
K2 Thinking 實測
先看幾個網友實測:
啟用 Kimi 工具調用,直接生成數學和物理解釋動畫
將公式渲染進行量子場論的動畫推理
太空侵略者游戲
K2 Thinking 簡介
kimi-k2-thinking模型是具有通用 Agentic 能力和推理能力的思考模型,它擅長深度推理,并可通過多步工具調用,幫助解決各類難題。
什么讓它與眾不同:
? 原生 INT4 量化 → 2 倍快速推理
占用內存減半,無精度損失
256K 上下文,支持 200-300 次工具調用
![]()
Kimi K2 Thinking 上下文長度為 256k。(從常規的 Kimi K2 的 128k 提升而來),總參數 1T,激活參數 32B
官方釋放的基準測試結果:
在 HLE (44.9%) 和 BrowseComp (60.2%) 上達到 SOTA
最多可以執行 200 – 300 個連續的工具調用 無需人工干預
在推理、自主搜索和編程方面表現出色
![]()
需要指出的是,Kimi 非常自信的與最強的閉源模型進行對比,在多個基準中結果反超閉源模型。
下面是更全面的對比結果,確實不需要與其他開源模型比參數了:
![]()
artificialanalysis.ai 也對 Kimi K2 Thinking 做了基準測試,結果也十分優秀
? Kimi K2 Thinking 在 2-Bench Telecom 代理工具使用基準測試中獲得了 93% 的成績,這是一個 agentic tool 基準測試,模型作為客戶服務代理進行操作。在長期代理上下文中的工具使用是 Kimi K2 Instruct 的強項,而新的 Thinking 變體在此方面取得了顯著進步。
![]()
K2 Thinking 本地部署
K2 Thinking 的模型文件只有 594GB
![]()
https://huggingface.co/moonshotai/Kimi-K2-Thinking
K2 Instruct 和 K2 Instruct 0905 的大小則超過 1TB,為何 Thinking 之后 594GB 呢?
這是因為 K2 Thinking 使用 INT4 精度而非 FP8,Moonshot 在后訓練階段使用量化感知訓練來實現這一點,這意味著推理和訓練的效率提升。使用 INT4 的一個潛在原因是,Blackwell 的 NVIDIA GPU 不支持 FP4,因此 INT4 更適合在較陳舊的硬件上實現效率提升。
vLLM Day 0 支持 K2 Thinking 的部署,命令如下
# 安裝
uv venv
source .venv/bin/activate
uv pip install -U vllm --pre --extra-index-url https://wheels.vllm.ai/nightly --extra-index-url https://download.pytorch.org/whl/cu129 --index-strategy unsafe-best-match # for xformers
# 部署
vllm serve moonshotai/Kimi-K2-Thinking \
--trust-remote-code \
--tensor-parallel-size 8 \
--enable-auto-tool-choice \
--tool-call-parser kimi_k2 \
--reasoning-parser kimi_k2 \
## `--reasoning-parser` 標志指定用于從模型輸出中提取推理內容的推理解析器。
要啟動 Kimi-K2-Thinking 需要 8 個 141GB 的 H200/H20,成本還是蠻高的,不過即便再量化,估計向下空間也不大了吧?已經 int4 了,還能怎樣。
推薦使用 解碼上下文(DCP)并行部署,添加 --decode-context-parallel-size number 來啟用解碼上下文并行:
vllm serve moonshotai/Kimi-K2-Thinking \
--trust-remote-code \
--tensor-parallel-size 8 \
--decode-context-parallel-size 8 \
--enable-auto-tool-choice \
--tool-call-parser kimi_k2 \
--reasoning-parser kimi_k2 \
配合 DCP 后,優勢顯著(43% 更快的 Token 生成,26% 更高的吞吐量),同時幾乎沒有缺點(中位數延遲改善微乎其微)
指標
TP8
TP8+DCP8
變更
改進 (%)
請求吞吐量 (req/s)
1.25
1.57
+25.6%
輸出標記吞吐量 (tok/s)
+43.1%
平均 TTFT(秒)
+16.0%
中位數 TTFT(秒)
后面我會拿之前的用例詳細測試一下,同時也把 Claude code 后臺模型改成 K2 Thinking 多用一用
如有能再量化同時保障效果不打大折扣,把部署成本控制在 4 卡就好了,我也可以本地部署試試了。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.