Corriger l'erreur "Model Not Found" (model_not_found) de l'interface compatible OpenAI de HiAPI

Symptôme du problème

Lorsque vous appelez l'interface compatible OpenAI de HiAPI (POST /v1/chat/completions) et que l'id model fourni n'est pas reconnu ou ne peut pas être routé par HiAPI, l'interface renvoie HTTP 400, avec dans le corps de la réponse le code d'erreur model_not_found, qui ressemble à ceci :

{
  "error": {
    "message": "The requested model does not exist or is not available. Check the exact model ID with GET /v1/models and try again. If the issue persists, contact support with request ID: ...",
    "type": "hiapi_error",
    "code": "model_not_found",
    "request_id": "..."
  }
}

Notez que cela n'a rien à voir avec un « problème de clé ». Si votre clé API est elle-même invalide ou expirée, HiAPI renvoie HTTP 401 + permission_denied, et non model_not_found :

{
  "error": {
    "code": "permission_denied",
    "message": "This API key is invalid. Check that it is correct or use another API key and try again. If the issue persists, contact support with request ID: ...",
    "type": "hiapi_error",
    "request_id": "..."
  }
}

Si vous voyez permission_denied, corrigez d'abord la clé, sans vous soucier de l'id du modèle. Ce qui suit ne concerne que model_not_found.

Causes fréquentes

Classées par probabilité décroissante de survenance réelle :

1. Faute d'orthographe / de casse dans l'id du modèle, ou slug de la barre d'adresse copié directement. L'id du modèle est sensible à la casse et contient souvent des points, des tirets et des barres obliques (par exemple seedream-5.0-lite et non seedream-5-0-lite). Copier le slug de la page du modèle depuis la barre d'adresse du navigateur pour l'utiliser comme id est la source la plus fréquente de cette erreur — le slug court de l'URL de la page du modèle n'est pas nécessairement égal à l'id réel de l'API.

2. Ce modèle n'est pas du tout un modèle de conversation, il passe par une autre interface. La plupart des modèles d'image / vidéo / audio sur HiAPI ne prennent en charge que l'interface de tâches asynchrones POST /v1/tasks ; quant aux modèles de raisonnement comme gpt-5.6 / gpt-6, ils ne prennent en charge que POST /v1/responses. Si vous les envoyez à /v1/chat/completions, l'interface les rejette avec invalid_request (HTTP 400) :

   {
     "error": {
       "message": "The request is incomplete or incorrectly formatted. Please check it and try again...",
       "type": "hiapi_error",
       "param": "",
       "code": "invalid_request",
       "request_id": "..."
     }
   }
   

   Chaque modèle renvoyé par GET /v1/models comporte un champ supported_endpoint_types, qui est la seule référence pour savoir « quelle interface utiliser pour ce modèle » (voir ci-dessous).

3. Le modèle a été retiré ou renommé. L'id est parfaitement correct, mais il ne figure plus dans la liste actuelle /v1/models — les anciens id des notes ou du cache peuvent être périmés.

4. Problème de clé / de permissions confondu avec un problème de modèle. Lorsque la clé du compte est invalide, l'erreur est permission_denied (401), et non model_not_found (400). Distinguez d'abord le type d'erreur par son code, puis corrigez en conséquence.

Étapes de correction

1. Obtenez d'abord la liste à jour et l'id exact : appelez GET https://api.hiapi.ai/v1/models avec votre clé. C'est le catalogue en temps réel, et c'est précisément ce que le message d'erreur vous invite à vérifier — son autorité prime sur tout id codé en dur dans votre code ou vos notes.

2. Consultez supported_endpoint_types pour déterminer l'interface. Chaque entrée de modèle ressemble à ceci :

   { "id": "gpt-image-2/text-to-image", "object": "model", "owned_by": "custom", "supported_endpoint_types": ["task"] }
   

   • task → utilisez l'asynchrone POST /v1/tasks, pas chat/completions ;
   • openai → utilisez POST /v1/chat/completions (c'est la voie décrite dans cet article) ;
   • openai-response → utilisez POST /v1/responses.

3. Renvoyez la requête avec l'id exactement tel qu'il figure dans la liste. Les modèles multi-tâches portent dans la liste un suffixe de type de tâche (comme /text-to-image, /image-to-video) ; utilisez l'id complet tel qu'il est écrit dans la liste, et non le slug brut de l'URL de la page du modèle.

4. Choisissez la bonne interface : si le type est task, passez à /v1/tasks ; si le type est openai-response, passez à /v1/responses. Changer d'interface résout le problème en une fois, bien mieux que de réessayer des id à répétition sur chat/completions.

5. Si le code d'erreur est en réalité permission_denied (401), le problème vient de votre clé, pas de l'id du modèle — réinitialisez ou remplacez séparément la clé API.

Exemple de vérification minimal

Pour diagnostiquer cette erreur, la première commande est toujours GET /v1/models — elle est gratuite, sans effet de bord, et vérifie deux choses d'un coup : si la clé fonctionne, si cet id existe réellement et quelle interface utiliser.

curl -s https://api.hiapi.ai/v1/models \
  -H "Authorization: Bearer $HIAPI_API_KEY"

• Réponse 200 + liste des modèles → la clé est bonne, vérifiez ensuite dans la liste l'id et son supported_endpoint_types ;
• Réponse 401 + permission_denied → c'est un problème de clé, corrigez d'abord la clé.

Après avoir confirmé qu'un modèle est de type task, la bonne méthode d'appel est l'interface de tâches unifiée (l'id brut du modèle suffit, il est routable même sans le suffixe de type de tâche) :

curl -s -X POST https://api.hiapi.ai/v1/tasks \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-image-2",
    "input": { "prompt": "a red apple on a white table" }
  }'

Notez que /v1/tasks crée réellement une tâche facturée et renvoie un taskId dès qu'elle accepte la requête ; il s'agit donc d'un « appel officiel après correction », et non d'un outil pour tester la connectivité à la légère — pour une simple vérification de connectivité, utilisez le GET /v1/models ci-dessus. Si l'id n'est pas disponible, l'erreur de /v1/tasks adopte une autre structure plate (différente de chat/completions) :

{ "code": 400, "data": null, "error_code": "MODEL_UNAVAILABLE", "message": "model not available via /v1/tasks" }

Liens internes associés

• Documentation de l'API Chat Completions —— référence complète des requêtes / réponses et du comportement d'erreur de l'interface compatible OpenAI.
• Documentation de présentation des modèles —— pour comprendre le catalogue de modèles et comment retrouver l'id exact.
• Documentation de l'API de création de tâches —— référence des champs model, input, callback de /v1/tasks.
• Place de marché des modèles —— parcourir tous les modèles disponibles.
• Page de tarification —— vérifier la disponibilité et le prix en temps réel de chaque modèle.

FAQ

Q : J'ai copié l'id directement depuis l'URL de la page du modèle, pourquoi ne fonctionne-t-il pas ? R : L'URL de la page du modèle contient souvent un slug court, alors que l'id réel de l'API (en particulier pour les modèles multi-tâches) comporte un suffixe de type de tâche, par exemple gpt-image-2/text-to-image. Référez-vous à l'id renvoyé par GET /v1/models, et non à la barre d'adresse du navigateur.

Q : GET /v1/models/{id} renvoie HTTP 200 pour un id inexistant, est-ce un bug ? R : Non. L'interface de requête d'un modèle unique renvoie 200 même si l'id n'existe pas, mais le corps de la réponse contient une structure invalid_request_error / model_not_found, et non un code de statut 404/400. Pour cette interface, ne vous fiez pas uniquement au code de statut HTTP, regardez le body. Le comportement de l'interface de liste GET /v1/models et de /v1/chat/completions est quant à lui décrit ci-dessus.

Q : J'utilise le SDK OpenAI pointé vers HiAPI, et j'obtiens model_not_found, est-ce un problème du côté d'OpenAI ? R : Non. Dès que le base_url du SDK compatible OpenAI pointe vers HiAPI, la résolution du modèle est entièrement prise en charge par HiAPI. model_not_found signifie que HiAPI n'a pas pu faire correspondre l'id que vous avez fourni à un modèle enregistré ; corrigez selon les étapes ci-dessus.

Q : Comment déterminer rapidement quelle interface utiliser pour un modèle ? R : Consultez le supported_endpoint_types de ce modèle dans GET /v1/models : s'il contient task, utilisez POST /v1/tasks ; s'il contient openai, utilisez POST /v1/chat/completions ; s'il contient openai-response, utilisez POST /v1/responses.

Q : Les codes d'erreur de /v1/tasks et de /v1/chat/completions sont-ils identiques ? R : Non. /v1/chat/completions utilise des codes en minuscules (comme model_not_found, invalid_request) enveloppés dans {"error": {...}} ; /v1/tasks utilise un error_code en majuscules (comme MODEL_UNAVAILABLE) placé dans un objet plat {"code","message","data","error_code"}. Lorsque vous écrivez la gestion des erreurs pour les deux interfaces, ne supposez pas qu'une seule implémentation convient aux deux.