Un catalogue de modèles d’IA n’est utile que lorsqu’il aide une équipe à prendre une décision de production. Une page remplie de noms de modèles ne suffit pas. Les développeurs doivent savoir quel fournisseur possède le modèle, quelle famille d’endpoints l’application appellera, quel groupe ou niveau de route servira le trafic, si la ligne est actuellement disponible et comment le prix est mesuré avant que la première vraie requête utilisateur ne passe par là.
Ce guide du catalogue de modèles d’IA a été vérifié le 24 juin 2026 par rapport aux pages publiques de Flatkey, à l’API de tarification Flatkey en direct, aux recherches Ahrefs enregistrées et à la documentation officielle de catalogues de modèles de Microsoft, Google, Vercel et OpenAI. Considérez chaque nombre de catalogues, statut, famille d’endpoints et champ de tarification comme un instantané à un moment donné. Avant le trafic de production, rouvrez la tarification Flatkey, confirmez la ligne exacte du modèle et exécutez un test de route à faible risque.
L’objectif pratique est simple : transformer la navigation dans les modèles en revue reproductible. Si votre équipe peut lire le fournisseur, l’endpoint, le groupe, le statut, le prix et le propriétaire dans le même enregistrement de catalogue de modèles d’IA, la décision de modèle devient plus facile à approuver pour l’ingénierie, la finance, le support et les achats.
Réponse rapide : comment lire un catalogue de modèles d’IA
Lisez un catalogue de modèles d’IA de gauche à droite : d’abord le fournisseur, puis l’endpoint, le groupe, le statut, le prix et enfin le test de route. Cet ordre évite aux équipes de choisir un nom de modèle qui semble attractif, mais qui ne peut pas être appelé en toute sécurité via l’endpoint, le groupe ou la politique budgétaire réellement utilisés par l’application.
| Champ du catalogue | Ce qu’il vous indique | Décision à prendre | Vérification Flatkey |
|---|---|---|---|
| Fournisseur | Qui fournit ou héberge la route du modèle. | Ce fournisseur peut-il répondre à vos attentes en matière de fonctionnalités, de risque et de support ? | Confirmez l’enregistrement du vendeur et toute note de ligne propre au fournisseur. |
| ID du modèle | La chaîne exacte que votre application demandera. | L’application peut-elle utiliser cet ID sans dérive d’alias ni documentation obsolète ? | Copiez la ligne du modèle depuis /pricing, pas de mémoire. |
| Famille d’endpoints | La forme du protocole : chat, responses, génération d’images, vidéo, Gemini, Anthropic ou une autre route. | Le SDK actuel, le corps de requête, le mode streaming et le parseur de réponse conviennent-ils ? | Vérifiez la famille d’endpoints prise en charge avant de changer l’URL de base. |
| Groupe | Le niveau de route ou le pool de ressources qui sert la requête. | Quel groupe doit gérer le staging, la production, le fallback ou le trafic sensible aux coûts ? | Comparez le libellé exact du groupe et le ratio de groupe avant le lancement. |
| Statut | Si la dernière vérification du catalogue est propre, non prise en charge ou non résolue. | Cette ligne doit-elle recevoir du trafic de production, un smoke test ou aucun trafic ? | Ne considérez pas une ligne visible comme disponible tant que le statut et un test de requête ne concordent pas. |
| Unité de tarification | Comment l’usage est facturé : input, output, cache, image, vidéo, seconde ou unité fixe de type job. | Quelle formule budgétaire et quel quota appliquer ? | Examinez séparément les champs de type tokens et les champs de prix hors tokens. |
| Test de route | Si le modèle fonctionne pour le chemin exact de la fonctionnalité. | L’ingénierie, la finance et le support peuvent-ils accepter le résultat ? | Exécutez une requête en staging, puis inspectez l’usage, le coût, le statut et les logs. |
Instantané actuel du catalogue de modèles d’IA Flatkey
L’instantané de l’API de tarification Flatkey en direct utilisé pour cet article a renvoyé success: true le 24 juin 2026. Il exposait 637 lignes de catalogue, 23 enregistrements de vendeurs, cinq libellés de groupes utilisables et six familles d’endpoints. La version de tarification de premier niveau dans la réponse était a42d372ccf0b5dd13ecf71203521f9d2.
| Champ de l’instantané | Valeur au 24 juin 2026 | Comment l’utiliser |
|---|---|---|
| Total des lignes de catalogue | 637 | Utilisez le catalogue de modèles d’IA comme source au niveau de la ligne, pas comme liste statique de fournisseurs. |
| Enregistrements de vendeurs | 23 | L’identité du fournisseur compte pour les décisions de support, de conformité et de fallback. |
| Familles d’endpoints | openai, gemini, image-generation, anthropic, openai-response, openai-video |
La famille d’endpoints vous indique si le format de requête actuel peut fonctionner. |
| Statuts de disponibilité | available, official_unsupported, unknown_failure |
Le statut doit orienter le filtrage du trafic et la priorité des smoke tests. |
| Lignes disponibles | 132 | Exigent tout de même un test de route pour votre endpoint, groupe, prompt et quota. |
| Lignes officiellement non prises en charge | 37 | Ne les utilisez pas en production sans un statut vérifié plus récent. |
| Lignes en échec inconnu | 468 | Traitez-les comme non résolues tant que les preuves de route, de compte, d’amont ou de statut n’ont pas été vérifiées. |
La page d’accueil publique de Flatkey positionne le produit autour d’une clé API unique, de l’URL de base compatible OpenAI https://router.flatkey.ai/v1, d’une tarification claire, d’une facturation unifiée et d’un tableau de bord unique pour les clés, l’usage et le routage. Ces promesses rendent le catalogue de modèles d’IA utile sur le plan opérationnel, mais elles ne suppriment pas la nécessité de vérifier la ligne précise que votre produit appellera.
Lisez les fournisseurs avant les noms de modèles
Les noms de modèles circulent entre vendeurs, passerelles, documentations et alias. L’identité du fournisseur est le premier champ stabilisateur. Elle vous indique qui fournit la route du modèle, quel compte ou amont peut être impliqué, d’où viennent les attentes de support et si le modèle relève d’un plan fournisseur direct, d’une route de passerelle ou d’un parcours d’évaluation restreint.
Les catalogues cloud officiels prennent le même problème au sérieux. Microsoft Foundry Models sépare les modèles vendus par Azure des modèles partenaires et communautaires, et demande aux clients d’examiner les descriptions de modèles, les model cards, la documentation et les conditions légales avant de sélectionner un modèle. Google Model Garden permet aux équipes de filtrer par collections de modèles et fournisseurs, puis d’ouvrir les model cards pour plus de détails. La leçon pour tout catalogue de modèles d’IA est la même : le fournisseur n’est pas décoratif ; il fait partie du contrat d’exploitation.
Pour une évaluation Flatkey, notez :
- Fournisseur ou vendeur : l’enregistrement de vendeur associé à la ligne.
- Ligne du modèle : l’ID exact du modèle visible dans la tarification Flatkey.
- Propriétaire : l’équipe, la fonctionnalité, le client ou le responsable budgétaire qui demande le modèle.
- Raison de la sélection : qualité, coût, latence, modalité, contexte, utilisation d’outils, image, vidéo ou comportement de fallback.
- Route de remplacement : ce que l’application doit utiliser si le statut de la ligne du fournisseur change.
Lisez les endpoints comme des contrats, pas comme des libellés
Une famille d’endpoints indique à votre application la forme de requête et de réponse à attendre. Un modèle qui apparaît sous une famille d’endpoints openai peut convenir à un flux de SDK compatible OpenAI. Un modèle qui apparaît sous anthropic, gemini, image-generation, openai-response ou openai-video peut nécessiter un corps de requête, un parseur, un comportement de streaming, un chemin de gestion de fichiers ou une interprétation de l’usage différents.
C’est pourquoi un catalogue de modèles d’IA utile doit être lu avec le plan de migration. Si votre application utilise déjà un client compatible OpenAI, commencez par le workflow de migration d’API compatible OpenAI : changez l’URL de base en staging, gardez l’ID du modèle explicite, exécutez une petite requête, inspectez la réponse, puis examinez les logs et le coût. Ne supposez pas que chaque ligne de modèle prend en charge tous les styles d’endpoints.
| Famille d’endpoints | Ce qu’il faut vérifier | Mode d’échec courant |
|---|---|---|
openai |
URL de base, ID du modèle, format des messages, streaming, appels d’outils, mode JSON, champs d’usage. | L’appel SDK réussit syntaxiquement, mais utilise une ligne de modèle qui ne prend pas en charge la fonctionnalité. |
openai-response |
Corps de requête de style Responses, analyse de la sortie, comportement des outils, entrée multimodale. | Des hypothèses de chat completions se retrouvent dans un workflow de style Responses. |
anthropic |
Forme de requête Messages, gestion du prompt système, comportement des entrées image, champs d’usage. | Un corps de style OpenAI est envoyé à une route de style Anthropic sans adaptation. |
gemini |
Forme de requête Gemini, entrée multimodale, paramètres de sécurité, analyse de la réponse. | La sélection du modèle ignore les différences de fonctionnalités ou de réponses propres au fournisseur. |
image-generation |
Règles d’image en entrée, taille de sortie, qualité, modération, format et nombre de résultats acceptés. | La budgétisation par nombre de requêtes masque les coûts de qualité d’image et de nouvelles tentatives. |
openai-video |
Durée, ratio d’aspect, état de job asynchrone, polling, gestion des échecs et unité d’usage. | Les jobs vidéo sont traités comme des appels texte synchrones bon marché. |
Lisez les groupes comme une politique de route et de coût
Dans une passerelle unifiée, un groupe n’est pas qu’un libellé. Il peut représenter un niveau de route, un pool de ressources, un chemin de compte ou une politique de tarification. L’instantané Flatkey du 24 juin exposait des libellés de groupes utilisables, notamment Economy, Standard, Claude Economy, Claude Official et Seedance2.0 Official. La réponse incluait aussi des descriptions de groupes et des ratios de groupes.
Lorsque vous lisez un catalogue de modèles d’IA, les groupes répondent à des questions auxquelles un nom de modèle ne peut pas répondre :
- Quel groupe le staging doit-il utiliser ? Une route à faible risque peut suffire pour les tests d’intégration.
- Quel groupe la production doit-elle utiliser ? La production peut nécessiter un chemin fournisseur, un profil de coût ou une attente de support différents.
- Quel groupe le fallback doit-il utiliser ? Une route de fallback doit être compatible avec les exigences de qualité, de latence et de budget.
- Quel groupe la finance doit-elle examiner ? Les ratios au niveau du groupe peuvent modifier le coût effectif pour le même nom de modèle.
- Quel groupe les achats doivent-ils approuver ? Une route directe ou officielle peut exiger des preuves différentes de celles d’une route economy.
La bonne habitude consiste à enregistrer le groupe dans la décision de modèle, pas seulement l’ID du modèle. Une ligne de modèle qui semblait raisonnable dans un groupe peut avoir un coût ou un chemin d’exploitation différent dans un autre groupe.
Lisez les prix par unité avant de comparer les lignes
Les champs de tarification sont faciles à mal lire, car différentes familles de modèles exposent différentes unités. Les modèles texte séparent souvent l’input, l’input en cache et l’output. Les lignes image et vidéo peuvent ajouter des paramètres de qualité, des unités de médias générés, la durée de job ou des champs de type prix fixe du modèle. La page de tarification publique d’OpenAI, par exemple, sépare les prix d’input, d’input en cache et d’output par 1M tokens pour ses modèles. Google Model Garden indique que l’usage de modèles open source peut impliquer des frais de calcul pour le tuning et le déploiement. Microsoft Foundry indique que les déploiements serverless sont généralement facturés selon les entrées et sorties API, souvent en tokens, tandis que le calcul managé utilise des heures de cœurs de machines virtuelles.
Pour une revue de catalogue de modèles d’IA Flatkey, séparez les formes de tarification avant de comparer les lignes :
| Forme de tarification | Champs à inspecter | Question budgétaire |
|---|---|---|
| Texte de type tokens | model_ratio, completion_ratio, cache_ratio |
La fonctionnalité dépensera-t-elle davantage en prompts, outputs, contexte en cache ou nouvelles tentatives ? |
| Chat multimodal | Famille d’endpoints, tokens d’entrée, tokens de sortie, entrées image/vidéo, comportement du cache. | Les entrées non textuelles modifient-elles le coût effectif ? |
| Génération d’images | Ligne du modèle, famille d’endpoints, paramètres de sortie, nombre de nouvelles tentatives, nombre d’images acceptées. | Que coûte une image acceptée après les échecs et les modifications ? |
| Génération de vidéos | Ligne du modèle, durée, qualité, état du job, politique de nouvelle tentative, model_price si présent. |
Le quota peut-il arrêter des jobs coûteux avant un incident budgétaire ? |
| Route ajustée par groupe | Libellé de groupe, ratio de groupe, route de production, route de fallback. | L’équipe compare-t-elle le groupe qu’elle utilisera réellement ? |
Pour un workflow de coûts plus approfondi, utilisez le guide de comparaison des prix des modèles d’IA après avoir présélectionné des lignes. Ce guide du catalogue de modèles d’IA vous aide d’abord à décider quelles lignes méritent une analyse de tarification.
Lisez le statut avant le trafic de production
Une ligne de catalogue visible n’est pas la même chose qu’une route prête pour la production. Dans l’instantané Flatkey du 24 juin, seules 132 des 637 lignes avaient available comme dernier statut de disponibilité. Les lignes restantes étaient réparties entre official_unsupported et unknown_failure. Cela ne signifie pas que chaque ligne non résolue est inutilisable de façon permanente ; cela signifie que la ligne a besoin de preuves de route actuelles avant de transporter du trafic utilisateur.
Utilisez le statut comme barrière :
- Available : exécutez un smoke test en staging pour votre endpoint, groupe, corps de requête et forme de prompt exacts.
- Official unsupported : ne lancez pas de trafic de production sauf si une source plus récente prouve que le statut a changé.
- Unknown failure : vérifiez si le problème vient du statut amont, des permissions du compte, de la configuration de route, de la région, du quota ou d’un échec transitoire.
- Aucun statut clair : traitez la ligne comme non approuvée jusqu’à ce qu’un test de tableau de bord ou d’API crée une preuve.
- Statut modifié : mettez à jour l’enregistrement de décision de modèle et informez le propriétaire avant de rediriger les utilisateurs.
Le champ de statut est aussi un contrôle financier. Une route de fallback qui passe silencieusement d’une ligne propre à bas coût à une ligne non résolue ou plus coûteuse peut transformer une expérience de modèle en incident. Gardez le statut, le groupe et le prix ensemble dans chaque revue de catalogue de modèles d’IA.
Un workflow Flatkey pour la revue du catalogue
Utilisez ce workflow lorsqu’une équipe demande à ajouter ou modifier un modèle derrière une clé unique.
- Ouvrir le catalogue actuel : commencez par la tarification Flatkey et copiez la ligne exacte.
- Enregistrer le fournisseur et le groupe : n’approuvez pas une ligne uniquement à partir du nom du modèle.
- Confirmer la famille d’endpoints : faites correspondre la route à votre SDK, corps de requête, plan de streaming et parseur.
- Vérifier le statut : ne routez le trafic de production qu’après concordance entre le statut et une requête en direct.
- Classer l’unité de tarification : token, cache, image, vidéo, durée, prix fixe ou route ajustée par groupe.
- Exécuter un test à faible risque : envoyez une requête en staging via
https://router.flatkey.ai/v1ou la famille de routes pertinente. - Examiner l’usage et le coût : inspectez le tableau de bord pour les preuves de modèle, d’usage, de coût, de statut et de routage.
- Définir le quota et le propriétaire : reliez la ligne à une clé, un responsable budgétaire, une limite, une alerte et une route de rollback.
- Enregistrer la décision : conservez ensemble la ligne du catalogue, la date, le statut, le groupe, les champs de prix, le résultat du test et la validation du propriétaire.
C’est aussi le passage de relais clair entre ingénierie et finance. L’ingénierie prouve que la route fonctionne. La finance prouve que l’unité et le propriétaire sont cohérents. Le support prouve que la décision de modèle peut être expliquée lorsqu’un client demande pourquoi une fonctionnalité a changé.
Modèle : enregistrement de revue du catalogue de modèles d’IA
Gardez un enregistrement compact pour chaque ligne de modèle qui atteint le staging ou la production. Cela transforme la navigation dans le catalogue de modèles d’IA en habitude opérationnelle.
Enregistrement de revue du catalogue de modèles d’IA
Date de revue :
Demandeur :
Fonctionnalité ou workflow :
Environnement : développement / staging / production / batch / orienté client
Ligne du modèle :
Fournisseur ou vendeur :
Famille d’endpoints :
Groupe :
Statut de disponibilité :
Champs de tarification :
Unité attendue : tokens d’entrée / tokens de sortie / entrée en cache / image / vidéo / durée / job fixe
Test de route :
Chemin de requête :
SDK ou client :
Réponse acceptée : oui / non
Usage visible : oui / non
Coût visible : oui / non
Quota attaché : oui / non
Propriétaire :
Responsable budgétaire :
Responsable support :
Route de fallback :
Condition de rollback :
Date de prochaine revue :
Erreurs courantes dans les catalogues de modèles d’IA
| Erreur | Pourquoi elle crée un risque | Meilleure revue |
|---|---|---|
| Choisir uniquement par nom de modèle | Les alias, fournisseurs, familles d’endpoints et groupes peuvent différer. | Approuvez la ligne exacte : fournisseur, endpoint, groupe, statut, prix, propriétaire. |
| Supposer que compatible OpenAI signifie que chaque fonctionnalité fonctionne | L’utilisation d’outils, le streaming, les images, la vidéo et les formats de réponse peuvent varier selon la route. | Exécutez un smoke test au niveau de la fonctionnalité avant le lancement. |
| Ignorer les libellés de groupes | Le même nom de modèle peut avoir un coût ou un comportement de route différent selon le groupe. | Enregistrez le groupe de production et comparez les ratios de groupes. |
| Traiter un statut non résolu comme inoffensif | Les échecs inconnus peuvent masquer des problèmes de route, de permission, d’amont ou de compte. | Bloquez le trafic jusqu’à ce que le statut et les preuves de requête soient propres. |
| Comparer les prix sans les unités | Les tokens d’entrée, tokens de sortie, tokens en cache, images et jobs vidéo ne se budgètent pas de la même façon. | Classez l’unité de tarification avant d’utiliser un tableau de comparaison. |
Quand un catalogue unifié de modèles d’IA aide le plus
Un catalogue de modèles d’IA unifié aide le plus lorsque votre produit couvre déjà plusieurs fournisseurs, modalités ou responsables opérationnels. Un prototype mono-fournisseur peut souvent commencer à partir d’une page de documentation officielle. Un produit d’IA en production a généralement besoin d’une vue plus durable : GPT, Claude, Gemini, DeepSeek, Qwen, modèles d’images, modèles vidéo, groupes de routage, statut, quotas, usage et coût dans une seule boucle de revue.
Flatkey est conçu pour les équipes qui veulent une clé API unique, une URL de base compatible, une tarification et une facturation unifiées, ainsi qu’un tableau de bord unique pour les clés, l’usage et le routage. La revue du catalogue est l’endroit où cette valeur devient concrète. Vous pouvez comparer des lignes, choisir une route, tester l’endpoint, attacher un quota et conserver les preuves d’usage dans un seul chemin opérationnel au lieu de disperser la décision entre portails fournisseurs et feuilles de calcul.
La bonne étape suivante n’est pas de faire confiance aveuglément à une ligne. Commencez par la page actuelle de tarification des modèles, copiez le modèle et le groupe exacts, testez la route en staging, puis obtenez une clé lorsque vous êtes prêt à évaluer le workflow dans votre propre application.
FAQ
Qu’est-ce qu’un catalogue de modèles d’IA ?
Un catalogue de modèles d’IA est une liste consultable de lignes de modèles avec suffisamment de contexte pour choisir, tester et exploiter un modèle. Un catalogue utile doit exposer le fournisseur, l’ID du modèle, la famille d’endpoints, le groupe ou niveau de route, le statut de disponibilité, l’unité de tarification et les preuves de documentation ou de tableau de bord.
Pourquoi le fournisseur est-il important dans un catalogue de modèles d’IA ?
L’identité du fournisseur vous indique qui fournit ou héberge la route, quelles conditions et attentes de support peuvent s’appliquer, et quelle revue de fallback ou d’achats est nécessaire. Le nom du modèle seul ne suffit pas pour une approbation de production.
Comment comparer les familles d’endpoints ?
Comparez les familles d’endpoints selon la forme de requête, la compatibilité SDK, le comportement de streaming, la prise en charge des outils, les entrées multimodales, l’analyse des réponses et les champs d’usage. Une ligne qui fonctionne pour le chat peut ne pas fonctionner pour les requêtes image, vidéo, Gemini, Anthropic ou de style Responses.
Qu’est-ce qu’un groupe de modèles ?
Un groupe de modèles est un libellé de route ou de ressource qui peut affecter le coût, le chemin amont, les attentes de support ou le comportement de fallback. Dans Flatkey, lisez le groupe avec l’ID du modèle et les champs de prix avant d’approuver une route.
À quelle fréquence les équipes doivent-elles revérifier un catalogue de modèles d’IA ?
Revérifiez avant chaque lancement en production, changement de modèle, changement de fallback, revue importante des prix ou suivi d’incident. Les catalogues de modèles d’IA changent rapidement, donc les instantanés datés ne doivent pas être traités comme des garanties permanentes de disponibilité ou de tarification.
Étape finale de revue du catalogue
Avant qu’une ligne de modèle n’atteigne la production, attribuez un propriétaire à chaque champ de l’enregistrement du catalogue de modèles d’IA. L’ingénierie possède l’adéquation de l’endpoint et les tests de route. La finance possède l’unité de prix et le budget. Le support possède l’impact côté client. La plateforme possède les quotas, le fallback et le rollback. C’est ainsi qu’un catalogue devient une infrastructure au lieu d’un menu de modèles.
Pour exécuter la version Flatkey de la revue, ouvrez la tarification Flatkey, sélectionnez une ligne de modèle, confirmez le fournisseur, l’endpoint, le groupe, le statut et l’unité de prix, puis obtenez une clé et testez la route avant d’augmenter le trafic.



