Kimi K2.5 Thinking/Instant 与视觉工具配置

一句话结论

K2.5 的 Thinking 与 Instant 不是只改一个文本提示：官方对两种模式给出不同 temperature，并要求通过 API/extra_body 显式切换；第三方部署还需核对 chat template、reasoning_content 和 provider parser。

适用场景

• 适合的任务：文本/图像/视频对话、视觉分析、编码 Agent、搜索与多步工具调用。

• 不适合的任务：把 Thinking 参数和 Instant 参数混用，或在未验证 provider 的情况下直接上线工具写入。

• 适用的模型版本：Kimi K2.5；官方 API、vLLM/SGLang/KTransformers 版本可能使用不同字段。

• 适用的客户端、Agent 或 API：Kimi API、OpenAI/Anthropic-compatible API、Kimi Code、vLLM/SGLang。

• 推荐的推理档位和参数：Thinking temperature=1.0, top_p=0.95；Instant temperature=0.6, top_p=0.95；上下文长度 256k；max_tokens 按任务设置。

可直接使用的内容

import openai

client = openai.OpenAI(api_key="<KIMI_API_KEY>", base_url="<KIMI_BASE_URL>")
messages = [
    {"role": "system", "content": "You are Kimi, an AI assistant created by Moonshot AI."},
    {"role": "user", "content": "分析这张图片，列出可验证事实、异常和下一步检查。"}
]

# Thinking mode: official API
thinking = client.chat.completions.create(
    model="kimi-k2.5",
    messages=messages,
    temperature=1.0,
    top_p=0.95,
    max_tokens=8192,
    extra_body={"thinking": {"type": "enabled"}},
)

# Instant mode: official API
instant = client.chat.completions.create(
    model="kimi-k2.5",
    messages=messages,
    temperature=0.6,
    top_p=0.95,
    max_tokens=4096,
    extra_body={"thinking": {"type": "disabled"}},
)

对 vLLM/SGLang，官方仓库说明 Instant 可用 extra_body={"chat_template_kwargs":{"thinking":False}}；部署前先用 Kimi Vendor Verifier 检查。

测试/工作流步骤

1. 固定同一输入，分别测试 Thinking/Instant 的延迟、token、正确性和工具调用。

2. 视觉任务记录原始图片/视频、媒体编码、尺寸、请求字段和输出；不要只记录文本。

3. 对第三方 provider 跑 Vendor Verifier/KVV 和多轮 tool-call，比较官方 API 输出。

4. 检查多轮 assistant message 是否正确保存 reasoning_content；删除显式 null，避免污染 chat template。

5. 压测时验证 200/429、空响应、超时、EOS 提前终止和重试幂等。

原始证据与数据

• 官方仓库给出 Thinking temperature=1.0、Instant temperature=0.6、top_p=0.95，并区分官方 API 与 vLLM/SGLang 切换字段。

• 官方模型 summary：MoE、总参数 1T、激活参数 32B、256K context、原生 vision。

• 官方推荐部署引擎包括 vLLM、SGLang、KTransformers；Transformers 最低版本 4.57.1。

• 官方要求/示例展示 reasoning_content，并提醒多轮 thinking/tool call 要正确处理中间状态。

适用边界

• 参数是官方起始推荐，不保证特定 provider、任务或量化模型最优。

• extra_body 字段在不同 API/engine 可能不同；不要把官方 API 字段直接发送到所有 OpenAI-compatible 服务。

• reasoning_content 不是用户可见解释，应按 provider 文档保存/过滤；显式 null 可能被模板渲染成文本。

• 工具调用、EOS/grammar 和限流属于端到端系统问题，模型 benchmark 不能覆盖。

来源摘录或观察（仅做合规短引）

官方仓库建议用 Kimi Vendor Verifier 核验部署；这是开放模型 provider 差异的重要实践。