kimi-k3.1-pro-highspeed API：curl 与 Python 调用

要做什么

kimi-k3.1-pro-highspeed 是 kimi-k3.1-pro 的高速版：响应更快，单价更高。它走 POST /v1/chat/completions，不走图片、视频用的异步 /v1/tasks 队列。本文给出一条能直接跑通的 curl 请求、对应的 Python 写法、流式、JSON 模式和工具调用，最后用同条件的配对请求回答一个实际问题：快这一档值不值得多付钱。

文中所有响应都是 2026-10-30 对线上接口实际请求得到的，没有沿用旧口径。本文是已发布英文稿的中文配对稿，事实以当次复测为准。

前提： 在控制台创建 API key，请求头带 Authorization: Bearer sk-<你的key>。

确认模型 id

GET /v1/models 返回的 id 是 kimi-k3.1-pro-highspeed，注意 3.1 里有点，不要写成 kimi-k3-1-...（那是文章 slug 的写法）。

kimi-k3.1-pro-highspeed

模型页与 /api/pricing 给出的规格：100 万 Token 上下文，单次最多输出 131,072 Token；思考始终开启，reasoning_effort 可选 low、high、max，默认 max；支持流式、JSON 模式（json_object 与 json_schema）和函数工具。

最小可跑示例（curl，JSON 模式）

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-<你的key>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k3.1-pro-highspeed",
    "reasoning_effort": "low",
    "max_tokens": 2000,
    "response_format": {"type": "json_object"},
    "messages": [{"role": "user", "content": "Return a JSON object with keys city and population_millions for Tokyo. JSON only."}]
  }'

实际响应（HTTP 200，耗时 4.97 秒），节选：

{
  "model": "kimi-k3.1-pro-highspeed",
  "choices": [{
    "index": 0,
    "message": {
      "role": "assistant",
      "content": "{\"city\":\"Tokyo\",\"population_millions\":37.4}",
      "reasoning_content": "..."
    },
    "finish_reason": "stop"
  }],
  "usage": {"prompt_tokens": 151, "completion_tokens": 84,
            "completion_tokens_details": {"reasoning_tokens": 54}}
}

content 是干净的 JSON，思考过程单独放在 reasoning_content。84 个输出 Token 里有 54 个是思考，思考 Token 按输出计费。

Python 写法

import json
import requests

resp = requests.post(
    "https://api.hiapi.ai/v1/chat/completions",
    headers={"Authorization": "Bearer sk-<你的key>"},
    json={
        "model": "kimi-k3.1-pro-highspeed",
        "reasoning_effort": "low",
        "max_tokens": 2000,
        "response_format": {"type": "json_object"},
        "messages": [{
            "role": "user",
            "content": "Return a JSON object with keys city and population_millions for Tokyo. JSON only.",
        }],
    },
    timeout=180,
)
resp.raise_for_status()
choice = resp.json()["choices"][0]
if choice["finish_reason"] == "length" and not choice["message"]["content"]:
    raise RuntimeError("思考用完了整个 max_tokens，请调大 max_tokens")
print(json.loads(choice["message"]["content"]))

流式输出

在请求里加 "stream": true 和 "stream_options": {"include_usage": true}。实测一次短请求，数据块的顺序是：

先是一串只带 reasoning_content 的增量（31 块），
再是带 content 的增量（8 块，首块同时带 role），
一个 finish_reason: "stop" 的空增量，
一个 choices 为空、只带 usage 的末尾数据块，
最后是 data: [DONE]。

import json
import requests

with requests.post(
    "https://api.hiapi.ai/v1/chat/completions",
    headers={"Authorization": "Bearer sk-<你的key>"},
    json={
        "model": "kimi-k3.1-pro-highspeed",
        "reasoning_effort": "low",
        "max_tokens": 2000,
        "stream": True,
        "stream_options": {"include_usage": True},
        "messages": [{"role": "user", "content": "Say hello in one short sentence."}],
    },
    stream=True,
    timeout=180,
) as r:
    r.raise_for_status()
    for line in r.iter_lines(decode_unicode=True):
        if not line or not line.startswith("data: ") or line.endswith("[DONE]"):
            continue
        chunk = json.loads(line[6:])
        if not chunk["choices"]:
            print("\nusage:", chunk["usage"])
            continue
        delta = chunk["choices"][0]["delta"]
        if delta.get("content"):
            print(delta["content"], end="", flush=True)

这一次流式请求的首字节时间 3.28 秒，总耗时 5.56 秒。因为思考内容先到，界面上看到正文之前会有一段只有 reasoning_content 的空档，做打字机效果时要决定是否展示思考块。

工具调用

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-<你的key>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k3.1-pro-highspeed",
    "reasoning_effort": "low",
    "max_tokens": 2000,
    "tool_choice": "auto",
    "tools": [{"type": "function", "function": {
      "name": "get_weather",
      "description": "Get current weather for a city",
      "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]}}}],
    "messages": [{"role": "user", "content": "What is the weather in Osaka right now?"}]
  }'

实际结果（HTTP 200，5.5 秒）：finish_reason 为 tool_calls，tool_calls[0].function.name 是 get_weather，arguments 是 "{\"city\":\"Osaka\"}"，content 为空字符串。把工具结果回传时，按模型页的要求保留完整的 assistant 消息，包括 reasoning_content 和 tool_calls，不要只回传其中一部分。

高速版和标准版：同条件实测

同一条 JSON 模式请求，reasoning_effort: "low"，在同一台机器上交替请求两个 id，各 3 次：

次数	`kimi-k3.1-pro-highspeed`	`kimi-k3.1-pro`
1	4.97 秒	7.80 秒
2	4.68 秒	5.92 秒
3	5.25 秒	6.41 秒

高速版稳定在 4.7 到 5.3 秒，标准版在 5.9 到 7.8 秒。英文稿早些时候做过 4 组配对，结果是 4.5 到 5.5 秒对 6.6 到 11.5 秒，方向一致。这只是单一网络路径上的小样本，不是基准测试，输出长度每次也不同（高速版 74 到 84 个输出 Token，标准版 90 到 112 个），也会影响耗时。

价格以 /api/pricing 的费率为准：高速版的输入、输出费率都是标准版的 2.0 倍（输出实测比值 1.99998，是取整造成的），缓存输入费率相同（1.0 倍）。具体美元单价见定价页，本文不写死。

怎么取舍：

用户在等的低延迟调用（交互式 Agent 每一跳、聊天框、工具调用循环）：本次实测约快 1.2 到 1.6 倍，单价 2 倍。有人在屏幕前等的时候，这笔钱通常值得。
批处理、离线或后台任务：标准版产出相同类型的结果，Token 单价只有一半，用 kimi-k3.1-pro。
很长且命中缓存的提示词：两档缓存输入同价，多付的部分主要落在未命中缓存的输入和输出（含思考 Token）上。
两档的回答质量我们没有系统比较，不作结论。

实测中发现的注意事项

传 temperature 会被拒绝。 发送 "temperature": 0.2，返回 HTTP 400：{"error":{"code":"invalid_parameter","message":"temperature: is outside allowed values","type":"invalid_request_error"}}。省略 temperature 和 top_p，两者在模型页的约定里固定为 1 和 0.95。如果你的 SDK 默认会带上这些参数，要先去掉。
思考算在 max_tokens 里。 即使是 low，上面的请求里仍有一半以上的输出 Token 是思考。max_tokens 留足余量，并处理 finish_reason: "length" 且 content 为空的情况。
事实类字段别指望模型记忆。 同一条 Tokyo 人口的提示词，高速版 3 次都返回 37.4，标准版三次分别是 37.4、37.0 和 14.0。14.0 很可能是按都道府县口径回答的，37 左右是都市圈口径。样本很小，不说明哪一档更准，但说明提示词里要写明统计口径，需要准确数字时应由你的数据源提供，而不是让模型回忆。
切换档位只需要改 model 字符串，上面的请求体在两个 id 上都能原样运行。