Как вызывать gpt-6.1 Sol через HiAPI: curl, Python и потоковая проверка на практике (руководство на китайском)

Цель и предпосылки статьи

Прочитав эту статью, вы запустите gpt-6.1 Sol одним HTTP-запросом — это текстовая модель из семейства GPT-6.1 Sol на HiAPI, ориентированная на сложное программирование, анализ документов и многошаговые рассуждения, — и получите потоковый ответ. Вы получите готовые к копированию примеры на curl и Python, а также три самые частые ловушки: эндпоинт — /v1/responses (а не /v1/chat/completions), потоковый режим обязателен, а input должен быть массивом.

Предпосылки: API-ключ HiAPI. Создайте его на странице API-ключей и храните в безопасности; в каждом запросе он передаётся через Authorization: Bearer sk-<ваш ключ>.

gpt-6.1 Sol — чисто текстовая модель (диалог / рассуждения / программирование), изображения не генерирует. Описание возможностей и онлайн-тест — на странице модели gpt-6.1 Sol.

Минимальный рабочий пример

Семейство Sol использует Responses API: POST /v1/responses. Два жёстких правила, без любого из них будет 400:

1. "stream": true — модель поддерживает только потоковый режим, stream:false будет отклонён.
2. input — это массив объектов сообщений — при включённом потоковом режиме передача простой строки вызовет ошибку input: has incorrect type.

curl

curl -N https://api.hiapi.ai/v1/responses \
  -H "Authorization: Bearer sk-<ваш ключ>" \
  -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-<ваш ключ>"

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)

Надёжнее диспетчеризировать по полю type внутри JSON (а не разбирать строку event:): каждый SSE-кадр состоит из двух строк — event: <type> и data: <json> — достаточно фильтровать строки data: и читать event["type"].

Ключевые моменты для продакшена

• Есть только потоковый режим. Непотокового варианта нет, stream:false сразу даёт 400. Клиент с самого начала должен проектироваться вокруг SSE: таймаут на чтение, переподключение / повтор при обрыве потока.
• Не передавайте max_output_tokens. Этот профиль выполнения не принимает данный параметр (ошибка not supported by this execution profile). Чтобы управлять длиной, ограничивайте её в prompt или системных инструкциях. Модель может выдать за один раз до ~128 тыс. токенов, но этот лимит нельзя задать параметром.
• Системный промпт передаётся в верхнеуровневом 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. Чем ниже уровень, тем меньше reasoning-токенов тратится — а reasoning-токены тарифицируются как output и появляются в финальном событии в usage.output_tokens_details.reasoning_tokens. Задачи, решаемые на низком уровне, не запускайте на высоком.
• Для структурированного вывода используйте text.format. Модель поддерживает строгий режим JSON Schema (strict) — удобно для стабильной выдачи разбираемого JSON, а не надежды на формат через prompt.
• Поддерживается вызов инструментов (function calling). Доступны верхнеуровневые tools + tool_choice, а также возврат результатов инструментов в диалог для продолжения рассуждений — подходит для agent-сценариев.
• Многораундовый диалог: просто добавляйте предыдущие сообщения user и assistant по порядку в массив input и отправляйте следующий запрос.
• Ошибка аутентификации — 401. Неверный или отозванный ключ возвращает 401 с кодом permission_denied ("This API key is invalid."). В этом случае сразу выбрасывайте ошибку, не повторяйте — повтор не исправит неверный ключ; request_id из тела ответа пригодится техподдержке для диагностики.
• Тарификация по токенам. Input и output тарифицируются отдельно, цена output заметно выше input; входные токены из кэша дешевле; reasoning-токены входят в output и оплачиваются вместе с ним (поэтому снижение reasoning.effort — это прямая экономия); при однократном вводе свыше ~272 тыс. токенов включается более дорогой тариф длинного контекста. Конкретные цифры смотрите в реальном времени на странице тарифов, не зашивайте цены в код.

Запись реального теста: один фактически выполненный запрос

Примеры в статье не скопированы из документации — с помощью curl выше был реально вызван /v1/responses (reasoning.effort: low, промпт "Объясни одним предложением, что такое ограничение частоты запросов API"), и наблюдалось следующее:

• usage в финальном событии response.completed: input_tokens=31, output_tokens=28, total_tokens=59, из них output_tokens_details.reasoning_tokens=0 — при низком уровне и простом вопросе reasoning-токенов может быть 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
Неверный ключ	401	permission_denied	This API key is invalid. (с request_id)

Правило диагностики одной фразой: при 400 проверьте эти три вещи — эндпоинт /v1/responses, stream равен true, input является массивом. Подавляющее большинство "не работает" — это одна из этих трёх причин.

Полезные ссылки

• Страница модели gpt-6.1 Sol — возможности, параметры и онлайн-тест
• Документация HiAPI — обзор API и другие модели
• Страница тарифов — актуальные цены с оплатой по факту использования
• Ещё выбираете? Смотрите GPT-6 Astra vs GPT-5.6 Sol: как выбрать, а также страницу модели GPT-6 Astra, также работающей через Responses API

Частые вопросы

Можно ли подключиться напрямую через официальный SDK OpenAI? gpt-6.1 Sol работает по протоколу Responses API, формат интерфейса с ним совместим, но в примерах статьи используется самый лёгкий вариант — чистый HTTP (requests + stream=True), без зависимости от какого-либо SDK; скопируйте и запускайте. Главное — base URL указывает на https://api.hiapi.ai и передаётся ключ HiAPI.

Почему при передаче stream:false всегда 400? Так задумано, это не баг. Семейство Sol поддерживает только потоковый режим, stream должен быть true, иначе возвращается invalid_parameter (stream: must be true). Переделайте клиент на чтение SSE.

Как управлять длиной вывода? Нельзя использовать max_output_tokens? Нельзя, при передаче будет 400. Укажите требования к длине в instructions (например, "отвечай одним предложением") или ограничьте в prompt.

Как снизить расходы? В первую очередь понижайте reasoning.effort (reasoning-токены тарифицируются как output, низкий уровень экономит напрямую); переиспользуйте системный промпт, чтобы входные токены попадали в кэш и были дешевле; избегайте единовременной передачи сверхдлинного контекста, вызывающей дорогой тариф. Актуальные цены — на странице тарифов.