教程

如何通过 HiAPI 调用 gpt-6.1 Sol：curl、Python 与流式实测（中文教程）

2026年10月20日

本文目标与前提

读完本文，你会用一条 HTTP 请求跑通 gpt-6.1 Sol——HiAPI 上 GPT-6.1 Sol 家族里主打复杂编程、文档分析与多步骤推理的文本模型，拿到流式返回的文本。你会得到可直接复制的 curl 与 Python 示例，以及三个最容易踩坑的点：接口是 /v1/responses（不是 /v1/chat/completions）、必须开启流式、input 必须是数组。

前提： 一个 HiAPI API Key。在 API 密钥页创建并妥善保管，每次请求都通过 Authorization: Bearer sk-<你的 key> 发送。

gpt-6.1 Sol 是纯文本模型（对话 / 推理 / 编程），不出图。能力说明与在线试用见 gpt-6.1 Sol 模型页。

最小可跑示例

Sol 家族走 Responses API：POST /v1/responses。两条硬规则，少一条就报 400：

"stream": true —— 模型只支持流式，stream:false 会被拒。
input 是消息对象数组 —— 开了流式后传一个裸字符串会报 input: has incorrect type。

curl

curl -N https://api.hiapi.ai/v1/responses \
  -H "Authorization: Bearer sk-<你的 key>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6.1-sol",
    "input": [
      {
        "type": "message",
        "role": "user",
        "content": [
          { "type": "input_text", "text": "用一句话解释什么是 API 速率限制。" }
        ]
      }
    ],
    "stream": true
  }'

-N 关掉 curl 的输出缓冲，这样你能实时看到 Server-Sent Events（SSE）逐条返回。流是一串 event: / data: 行，你要的正文出现在 response.output_text.delta 分片里，并在终态的 response.completed 事件里完整重复一遍。

简写形式 "input": [{"role":"user","content":"……"}] 也能跑通；上面的 type/input_text 规范写法在拼接多模态或多轮时更稳，推荐默认用它。

Python

不需要 SDK，HiAPI 就是普通 HTTP，用 requests 开 stream=True 即可：

import json
import requests

API_KEY = "sk-<你的 key>"

payload = {
    "model": "gpt-6.1-sol",
    "input": [
        {
            "type": "message",
            "role": "user",
            "content": [
                {"type": "input_text", "text": "用一句话解释什么是 API 速率限制。"}
            ],
        }
    ],
    "stream": True,
}

with requests.post(
    "https://api.hiapi.ai/v1/responses",
    headers={
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json",
    },
    json=payload,
    stream=True,
    timeout=120,
) as resp:
    resp.raise_for_status()

    text = ""
    for line in resp.iter_lines(decode_unicode=True):
        if not line or not line.startswith("data:"):
            continue
        event = json.loads(line[len("data:"):].strip())
        etype = event.get("type")
        if etype == "response.output_text.delta":
            text += event["delta"]
        elif etype == "response.completed":
            usage = event["response"]["usage"]
            print(f"\n[tokens: in={usage['input_tokens']} "
                  f"out={usage['output_tokens']} total={usage['total_tokens']}]")

print(text)

按 JSON 里自带的 type 字段分发（而不是去解析 event: 那一行）更稳：每个 SSE 帧是两行——event: <type> 和 data: <json>——只过滤 data: 行、读 event["type"] 就够了。

生产环境要点

只有流式一种模式。 没有非流式变体，stream:false 直接 400。客户端从一开始就要围绕 SSE 设计：加读超时，断流后重连 / 重试。
不要传 max_output_tokens。 这个执行档位不接受该参数（报 not supported by this execution profile）。要控制长度，就在 prompt 或系统指令里约束。模型单次最多可输出约 12.8 万 token，但这个上限不能通过参数去设。
系统提示放顶层 instructions（字符串），而不是塞进某条 message：

{
  "model": "gpt-6.1-sol",
  "instructions": "你是一个简洁的助手，只用一句话回答。",
  "input": [
    { "type": "message", "role": "user",
      "content": [{ "type": "input_text", "text": "什么是 webhook？" }] }
  ],
  "reasoning": { "effort": "low" },
  "stream": true
}

用 reasoning.effort 平衡推理深度与成本。 gpt-6.1 Sol 是推理型模型，reasoning.effort 支持 low / medium / high / xhigh / max 五档，默认 medium。档位越低，花的推理 token 越少——而推理 token 是按输出计费的，会出现在终态事件的 usage.output_tokens_details.reasoning_tokens。能用低档解决的任务别开高档。
需要结构化输出时用 text.format。 该模型支持 JSON Schema 严格模式（strict），适合让它稳定吐出可解析的 JSON，而不是靠 prompt 祈祷格式。
支持工具调用（function calling）。 顶层 tools + tool_choice 可用，并支持把工具结果续回对话继续推理，适合 agent 场景。
多轮对话：把之前的 user 和 assistant 消息按顺序追加进 input 数组再发下一次请求即可。
鉴权失败是 401。 key 错误或被吊销返回 401、code permission_denied（"This API key is invalid."）。这种要直接抛错、别重试——重试修不好一个错的 key，返回体里的 request_id 给技术支持排查用。
计费按 token 走。 input 与 output 分别计价，output 单价明显高于 input；缓存命中的输入 token 更便宜；推理 token 计入 output 一起算钱（所以降 reasoning.effort 就是直接省钱）；当单次输入超过约 27.2 万 token 时会进入更高的长上下文价档。具体数字以定价页实时为准，别在代码里写死价格。

实测记录：一次真实跑通的请求

本文的示例不是照抄文档——用上面的 curl 真实调了一次 /v1/responses（reasoning.effort: low，提示词是"用一句话解释什么是 API 速率限制"），观察到：

终态 response.completed 事件的 usage：input_tokens=31、output_tokens=28、total_tokens=59，其中 output_tokens_details.reasoning_tokens=0——低档 + 简单问题时推理 token 可以是 0，成本几乎只有可见输出那部分。
文本在流中以 response.output_text.delta 增量到达，终态里能从 response.output[0].content[0].text 一次性拿到完整结果；两种取法都行。
返回体里带 reasoning.effort 回显、service_tier、prompt_cache_retention 等字段，确认了 effort 与缓存是真实生效的。

把几种常见报错也实打实触发了一遍，方便你对照排查（均为真实返回）：

你做错了什么	HTTP	code	message
发到了 `/v1/chat/completions`	400	`unsupported_protocol`	Model does not support this protocol
传了 `stream:false`	400	`invalid_parameter`	stream: must be true
传了 `max_output_tokens`	400	`invalid_parameter`	max_output_tokens: is not supported by this execution profile
`input` 传成字符串	400	`invalid_parameter`	input: has incorrect type
key 无效	401	`permission_denied`	This API key is invalid.（附 `request_id`）

一句话排错口诀：报 400 先查这三样——接口是不是 /v1/responses、stream 是不是 true、input 是不是数组。 绝大多数"调不通"都是这三条里的一条。

常见问题

能用 OpenAI 官方 SDK 直接连吗？ gpt-6.1 Sol 走的是 Responses API 协议，接口形状与之兼容，但本文示例用的是最轻的裸 HTTP（requests + stream=True），不依赖任何 SDK，照抄即可跑。关键是 base URL 指向 https://api.hiapi.ai、带上 HiAPI 的 key。

为什么我传 stream:false 一直 400？ 这是设计使然，不是 bug。Sol 家族只支持流式，stream 必须为 true，否则返回 invalid_parameter（stream: must be true）。把客户端改成读 SSE 即可。

怎么控制输出长度？不能用 max_output_tokens？ 不能，传了会 400。请在 instructions 里写明长度要求（如"只用一句话回答"），或在 prompt 里约束。

怎么降低花费？ 优先调低 reasoning.effort（推理 token 按输出计费，低档直接省）；复用系统提示让输入命中缓存更便宜；避免把超长上下文一次性塞进去触发高价档。实时单价见定价页。