Comment appeler gpt-6.1 Sol via HiAPI : curl, Python et test de streaming en conditions réelles (tutoriel en chinois)

Objectif et prérequis de cet article

À la fin de cet article, vous aurez fait tourner gpt-6.1 Sol avec une seule requête HTTP — le modèle texte de la famille GPT-6.1 Sol sur HiAPI, spécialisé dans la programmation complexe, l'analyse de documents et le raisonnement multi-étapes — et vous obtiendrez le texte en retour streaming. Vous disposerez d'exemples curl et Python directement copiables, ainsi que des trois pièges les plus fréquents : l'endpoint est /v1/responses (et non /v1/chat/completions), le streaming est obligatoire, et input doit être un tableau.

Prérequis : une clé API HiAPI. Créez-la et conservez-la soigneusement sur la page des clés API, et envoyez-la à chaque requête via Authorization: Bearer sk-<votre clé>.

gpt-6.1 Sol est un modèle purement texte (conversation / raisonnement / programmation), il ne génère pas d'images. Pour les capacités et l'essai en ligne, voir la page du modèle gpt-6.1 Sol.

Exemple minimal fonctionnel

La famille Sol passe par la Responses API : POST /v1/responses. Deux règles strictes, il en manque une et c'est une erreur 400 :

1. "stream": true —— le modèle ne supporte que le streaming, stream:false sera rejeté.
2. input est un tableau d'objets message —— une fois le streaming activé, passer une chaîne brute renvoie input: has incorrect type.

curl

curl -N https://api.hiapi.ai/v1/responses \
  -H "Authorization: Bearer sk-<votre clé>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6.1-sol",
    "input": [
      {
        "type": "message",
        "role": "user",
        "content": [
          { "type": "input_text", "text": "Explique en une phrase ce qu'est une limitation de débit d'API." }
        ]
      }
    ],
    "stream": true
  }'

-N désactive la mise en tampon de sortie de curl, ce qui vous permet de voir en temps réel les Server-Sent Events (SSE) arriver un par un. Le flux est une suite de lignes event: / data: ; le contenu que vous cherchez apparaît dans les fragments response.output_text.delta, et est répété intégralement dans l'événement final response.completed.

La forme abrégée "input": [{"role":"user","content":"……"}] fonctionne aussi ; la forme normative type/input_text ci-dessus est plus robuste pour combiner du multimodal ou du multi-tours, il est recommandé de l'utiliser par défaut.

Python

Pas besoin de SDK, HiAPI est du simple HTTP, il suffit d'utiliser requests avec stream=True :

import json
import requests

API_KEY = "sk-<votre clé>"

payload = {
    "model": "gpt-6.1-sol",
    "input": [
        {
            "type": "message",
            "role": "user",
            "content": [
                {"type": "input_text", "text": "Explique en une phrase ce qu'est une limitation de débit d'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)

Il est plus robuste de dispatcher selon le champ type présent dans le JSON (plutôt que d'analyser la ligne event:) : chaque trame SSE comporte deux lignes — event: <type> et data: <json> — il suffit de filtrer les lignes data: et de lire event["type"].

Points clés pour la production

• Un seul mode : le streaming. Il n'existe pas de variante non-streaming, stream:false renvoie directement 400. Le client doit être conçu dès le départ autour de SSE : ajoutez un timeout de lecture, et prévoyez reconnexion / nouvelle tentative en cas de coupure.
• Ne passez pas max_output_tokens. Ce profil d'exécution n'accepte pas ce paramètre (erreur not supported by this execution profile). Pour contrôler la longueur, contraintez-la dans le prompt ou les instructions système. Le modèle peut produire jusqu'à environ 128 000 tokens par appel, mais cette limite ne peut pas être fixée via un paramètre.
• Le prompt système se place dans instructions au niveau racine (chaîne de caractères), et non dans un message :

{
  "model": "gpt-6.1-sol",
  "instructions": "Tu es un assistant concis, réponds en une seule phrase.",
  "input": [
    { "type": "message", "role": "user",
      "content": [{ "type": "input_text", "text": "Qu'est-ce qu'un webhook ?" }] }
  ],
  "reasoning": { "effort": "low" },
  "stream": true
}

• Utilisez reasoning.effort pour équilibrer profondeur de raisonnement et coût. gpt-6.1 Sol est un modèle de raisonnement, reasoning.effort prend cinq niveaux : low / medium / high / xhigh / max, avec medium par défaut. Plus le niveau est bas, moins de tokens de raisonnement sont consommés — et les tokens de raisonnement sont facturés comme de la sortie, ils apparaissent dans usage.output_tokens_details.reasoning_tokens de l'événement final. N'activez pas un niveau élevé pour des tâches résolubles à bas niveau.
• Pour une sortie structurée, utilisez text.format. Le modèle prend en charge le mode strict de JSON Schema, idéal pour produire de manière stable un JSON analysable, plutôt que de compter sur le prompt en espérant le bon format.
• Appels d'outils (function calling) pris en charge. tools et tool_choice au niveau racine sont disponibles, et il est possible de renvoyer le résultat d'un outil dans la conversation pour poursuivre le raisonnement, adapté aux scénarios d'agent.
• Conversation multi-tours : ajoutez les messages user et assistant précédents dans l'ordre au tableau input, puis envoyez la requête suivante.
• Un échec d'authentification renvoie 401. Une clé erronée ou révoquée renvoie 401, code permission_denied (« This API key is invalid. »). Dans ce cas, levez directement l'erreur, ne réessayez pas — réessayer ne corrige pas une clé incorrecte ; le request_id du corps de réponse sert au support technique pour l'investigation.
• La facturation se fait au token. input et output sont facturés séparément, le prix unitaire de l'output est nettement supérieur à celui de l'input ; les tokens d'entrée en cache sont moins chers ; les tokens de raisonnement sont comptés dans l'output et facturés avec lui (donc baisser reasoning.effort revient directement à économiser) ; au-delà d'environ 272 000 tokens d'entrée par appel, on entre dans un palier tarifaire de contexte long plus élevé. Les chiffres exacts font foi en temps réel sur la page tarifs, ne codez pas les prix en dur.

Journal de test : une requête réellement exécutée

Les exemples de cet article ne sont pas recopiés de la documentation — nous avons réellement appelé /v1/responses avec le curl ci-dessus (reasoning.effort: low, prompt « Explique en une phrase ce qu'est une limitation de débit d'API »), et observé :

• Le usage de l'événement final response.completed : input_tokens=31, output_tokens=28, total_tokens=59, dont output_tokens_details.reasoning_tokens=0 — à bas niveau et sur une question simple, les tokens de raisonnement peuvent être 0, le coût se limite presque à la sortie visible.
• Le texte arrive dans le flux par incréments response.output_text.delta, et l'événement final permet d'obtenir le résultat complet d'un coup via response.output[0].content[0].text ; les deux méthodes fonctionnent.
• Le corps de réponse contient l'écho de reasoning.effort, service_tier, prompt_cache_retention et d'autres champs, confirmant que l'effort et le cache sont bien pris en compte.

Nous avons également déclenché réellement plusieurs erreurs courantes, pour faciliter votre diagnostic comparatif (toutes issues de retours réels) :

Ce que vous avez mal fait	HTTP	code	message
Envoyé à /v1/chat/completions	400	unsupported_protocol	Model does not support this protocol
Passé stream:false	400	invalid_parameter	stream: must be true
Passé max_output_tokens	400	invalid_parameter	max_output_tokens: is not supported by this execution profile
input passé en chaîne	400	invalid_parameter	input: has incorrect type
clé invalide	401	permission_denied	This API key is invalid. (avec request_id)

Moyen mnémotechnique de dépannage en une phrase : en cas de 400, vérifiez d'abord ces trois points — l'endpoint est-il /v1/responses, stream est-il true, input est-il un tableau. La grande majorité des « ça ne marche pas » relèvent de l'une de ces trois règles.

Liens utiles

• Page du modèle gpt-6.1 Sol —— capacités, paramètres et essai en ligne
• Documentation HiAPI —— vue d'ensemble des API et d'autres modèles
• Page tarifs —— prix unitaires en temps réel de la facturation à l'usage
• Vous hésitez encore sur le choix ? Voir GPT-6 Astra vs GPT-5.6 Sol : comment choisir, ainsi que la page du modèle GPT-6 Astra, qui passe également par la Responses API

FAQ

Peut-on se connecter directement avec le SDK officiel OpenAI ? gpt-6.1 Sol utilise le protocole Responses API, dont la forme d'interface est compatible, mais les exemples de cet article utilisent le HTTP brut le plus léger (requests + stream=True), sans aucune dépendance à un SDK, copiables et exécutables tels quels. L'essentiel est de pointer la base URL vers https://api.hiapi.ai et d'utiliser la clé HiAPI.

Pourquoi stream:false renvoie-t-il toujours 400 ? C'est voulu par conception, ce n'est pas un bug. La famille Sol ne supporte que le streaming, stream doit valoir true, sinon elle renvoie invalid_parameter (stream: must be true). Modifiez le client pour lire les SSE.

Comment contrôler la longueur de sortie ? On ne peut pas utiliser max_output_tokens ? Non, le passer renvoie 400. Indiquez la contrainte de longueur dans instructions (par exemple « réponds en une seule phrase »), ou contraintez-la dans le prompt.

Comment réduire les coûts ? Baissez en priorité reasoning.effort (les tokens de raisonnement sont facturés comme de la sortie, un niveau bas économise directement) ; réutilisez le prompt système pour que l'entrée touche le cache et soit moins chère ; évitez de tout envoyer en un seul contexte ultra-long qui déclenche le palier tarifaire élevé. Les prix unitaires en temps réel figurent sur la page tarifs.