Le routage AI peut supprimer un choix de modèle de chaque demande de génération, mais il peut également masquer la raison pour laquelle un modèle a été sélectionné. Le routeur de modèles de Runway résout un modèle éligible à partir d'une politique enregistrée et renvoie les paramètres choisis. Avant de prendre cette décision dans un flux de travail API créatif, auditez les coûts, la latence, la qualité, la reprise après panne et les crédits réalisés avec une seule entrée contrôlée.
Comparez dans APOB un parcours vidéo multimodèle aux critères explicites
Il s'agit d'un protocole de test sécurisé avec des tableaux de résultats vierges, et non d'une affirmation selon laquelle des essais à sec ou des générations payantes ont été exécutés pour cet article. Les pages Runway ont été vérifiées le 11 septembre 2026. Utilisez une configuration jetable, conservez les informations d'identification hors des captures d'écran et n'oubliez pas que la suppression d'une configuration de routeur est permanente. APOB est inclus uniquement en tant que contexte de création multi-modèle manuel ; il n'est pas décrit comme un routeur automatique.
Rédigez la politique avant de choisir un modèle
Séparez le projet en voies préliminaires et finales. Chaque voie obtient une modalité, des entrées acceptées, des contraintes de sortie, un plafond de crédit et une préférence d'optimisation. La publication de la feuille en premier empêche une équipe de réécrire la politique après avoir apprécié un résultat.
Voie de brouillon
La voie de brouillon répond à une question créative à moindre coût ou rapidement : le mouvement de la caméra fonctionne-t-il, l'action du produit peut-elle être lue ou la composition de référence soutient-elle l'histoire ? Définissez la résolution minimale acceptable, la durée, les besoins audio et le type de référence.
N’exigez pas par habitude les qualités de livraison finale. Une ébauche qui atteint son objectif d’apprentissage peut être poursuivie même si elle n’est pas expédiée.
Voie finale
La voie finale nécessite un contrat visuel approuvé : résolution, durée, audio, format d'image, comportement de référence, mouvement, détails de la marque et coût de révision acceptable. Ajoutez la destination et le réviseur. La « meilleure qualité » est trop vague pour une politique de routage.
Si une capacité requise n’est pas négociable, faites-en une condition d’éligibilité plutôt que d’espérer que la préférence en matière de qualité choisisse un modèle compatible.
Plafond de crédits
Définissez un budget maximum pour un travail et indiquez s'il s'applique à une estimation à sec, à une seule génération ou à l'ensemble de la boucle de révision. Enregistrez l'unité exactement telle que la documentation actuelle la présente.
Le guide de tarification officiel de Runway indique que le travail en acheminement utilise le tarif normal du modèle sélectionné et renvoie le coût du crédit réalisé. Revérifiez les tarifs actuels avant de courir ; ne copiez pas un numéro daté dans une police permanente.
Capacités autorisées
Répertoriez la modalité et les entrées requises, puis créez une liste blanche explicite uniquement si l'équipe a approuvé des modèles particuliers. La présentation officielle des routeurs de modèles explique que le routeur filtre d'abord les modèles éligibles, puis applique une préférence d'optimisation.
Gardez la politique suffisamment petite pour être comprise. Une longue liste d'autorisation avec des contraintes contradictoires transforme la sélection automatique en une charge de maintenance opaque.
Voie | Tâche | Capacité requise | Plafond | Préférence | Propriétaire |
|---|---|---|---|---|---|
Brouillon | Répondez à une question créative | Coût ou latence | |||
Finale | Produire un clip prêt à être révisé | Qualité |
Interrogez le routeur sans dépenser de crédits
Exécutez trois requêtes d’essai par ailleurs identiques : coût, latence et qualité. Conservez les mêmes invites, références, contraintes de sortie, liste d'autorisation, plafond, version d'API et configuration du routeur. Un essai à sec est une inspection de politique, pas un résultat généré.
Préférence de coût
Définissez la préférence d'optimisation sur le coût et capturez le modèle résolu, les paramètres, les informations d'éligibilité, les champs de coût estimé ou retourné documentés par l'interface et l'horodatage. Ne changez pas le plafond pour faire passer la demande.
Le routeur de modèles de piste peut sélectionner un modèle différent à mesure que la disponibilité ou les informations du catalogue changent. Enregistrez la réponse, pas une attente.
Préférence de latence
Répétez la demande avec la latence comme seul changement de stratégie. Comparez le modèle et les paramètres résolus avec la réponse en termes de coûts. Ne mesurez pas le temps d’aller-retour du réseau et appelez cela latence de génération ; le test n'a pas rendu de clip.
Si la réponse est identique, enregistrez ce résultat sans en déduire que le coût et la latence sont toujours équivalents.
Préférence de qualité
Exécutez la troisième requête avec la qualité comme seul champ modifié. L'étiquette exprime une préférence de routeur pour l'ensemble éligible ; il n’établit pas de score indépendant de qualité visuelle.
Conservez les trois réponses brutes. Un tableau récapitulatif est utile, mais le corps de la réponse constitue la preuve lorsque quelqu'un demande pourquoi le routeur de modèle d'IA a choisi un modèle.
Paramètres résolus
Normalisez chaque réponse dans le même registre : ID de politique, préférence, contraintes éligibles, modèle choisi, durée résolue, résolution ou ratio, crédits estimés en cas de retour, avertissements et horodatage. Ne publiez pas d’informations d’identification, ne demandez pas de signatures, d’URL d’actifs privés ou de données personnelles.
Le guide de génération officiel de Runway documente le flux de simulation et la transparence des réponses. Suivez le schéma actuel plutôt que les exemples copiés à partir d'un article plus ancien.
Exécution à sec | Préférence | Modèle résolu | Paramètres résolus | Champ de crédit | Remarques |
|---|---|---|---|---|---|
UNE | Coût | ||||
B | Latence | ||||
C | Qualité |
Forcez la branche sans modèle admissible
Une politique de routage est incomplète jusqu'à ce que son chemin de défaillance soit testé. Utilisez une configuration jetable ou une contrainte de demande qui ne laisse délibérément aucun modèle éligible. Ne supprimez pas une configuration de production simplement pour créer des preuves.
Déclencheur d’échec
Choisissez un déclencheur réversible : un plafond irréaliste bas, une liste d'autorisation qui entre en conflit avec l'entrée requise ou une combinaison de fonctionnalités non offerte par les modèles autorisés. Écrivez l'échec attendu avant d'envoyer l'essai à sec.
Capturez le type d’erreur exact et le message autorisé à être conservé. Une demande échouée est une preuve utile ; il ne doit pas exposer de clés ou d'URL privées.
Élargissement de la liste d’autorisation
Première option de récupération : ajoutez un modèle approuvé à la liste blanche tout en préservant le brief et le plafond. Répétez l’essai à sec et notez si l’éligibilité revient. Cela teste la flexibilité de la gouvernance sans déplacer le budget.
Ne pas élargir à « tous les modèles », à moins qu’il ne s’agisse d’une décision politique explicite. La reprise devrait rester révisable.
Modification du plafond
Deuxième option : augmenter le plafond d'un cran approuvé tout en conservant les capacités et la liste d'autorisation fixes. Enregistrez la limite précédente et la nouvelle, le propriétaire et la raison. L'étape révèle si l'échec était financier plutôt que technique.
N’utilisez jamais une estimation à sec comme garantie. Le rapprochement en direct doit ensuite comparer les crédits réalisés restitués.
Simplification de l’entrée
Troisième option : assouplir une contrainte d'entrée ou de sortie non essentielle (durée, résolution, audio ou type de référence) sans modifier l'objectif de l'histoire. Marquez le compromis créatif sur la demande.
L'ordre de récupération doit être prédéterminé : élargir la liste d'autorisation, modifier le plafond, adoucir les entrées ou arrêter. Si aucun ne préserve le brief, un chemin de modèle direct ou un autre flux de travail est plus sûr qu'une dégradation silencieuse.
Rapprochez le modèle choisi après la génération
Approuvez une seule stratégie pour une génération active minimale. Confirmez que la demande ne contient aucune information d'identification ou média non approuvé dans le dossier de preuve. Enregistrez la réponse d’essai à sec avant d’envoyer la demande payante.
Route estimée
Copiez le modèle choisi, les paramètres résolus et le champ de crédit affiché à partir de l'essai final. Ajoutez un hachage ou une étiquette de tâche qui le lie à la demande en direct. Si l'API ne promet pas de réservation, étiquetez l'itinéraire « estimation » et non « verrouillé ».
Cette distinction est importante car les conditions de catalogue, d’éligibilité ou de service peuvent changer entre les appels.
Route réelle
Une fois terminé, capturez le modèle renvoyé et les paramètres résolus. Comparez-les champ par champ avec le devis. Une différence n’est pas automatiquement un défaut ; c'est la dérive de routage que le propriétaire de la politique doit comprendre.
Conservez la sortie uniquement lorsque ses droits médiatiques et ses exigences de sécurité sont satisfaits. L'audit ne constitue pas une autorisation de générer du contenu sensible ou sans propriétaire.
Crédits consommés
Enregistrez le coût du crédit réalisé à partir de la réponse et comparez-le avec le champ et le plafond de simulation. Ne calculez pas un prix à l’échelle de la plateforme à partir d’un seul travail. Datez la ligne et liez la documentation sur les tarifs des pistes actuelle.
Si le travail dépasse l’écart autorisé par l’équipe, suspendez l’itinéraire plutôt que de faire la moyenne de la surprise dans les budgets futurs.
Note de dérive
Écrivez une phrase : « L'itinéraire estimé et l'itinéraire réel correspondent » ou répertoriez les champs exacts qui diffèrent. Indiquez si le résultat a satisfait au contrat de création et combien de minutes de révision cela a nécessité.
Un itinéraire peu coûteux qui entraîne des révisions répétées peut faire échouer le flux de travail même en respectant le plafond par génération. Le routage de qualité coût nécessite à la fois des preuves API et de travail humain.
Adoptez une charte de routage ou restez explicite
La décision n’est pas « une bonne automatisation » ou un « bon choix manuel ». Choisissez la plus petite politique qui reste prévisible et maintenable pour l'équipe.
Quand utiliser le routeur
Adoptez le routeur lorsque plusieurs modèles éligibles peuvent satisfaire le cahier des charges, que la préférence choisie représente une véritable priorité commerciale, que la transparence de l'exécution à sec est suffisante, que la reprise après panne est limitée et que les crédits réalisés restent dans les limites de la politique. Attribuez un propriétaire de configuration et une date de nouveau test.
Ne laissez pas une configuration abandonnée devenir une infrastructure invisible. Enregistrez qui peut modifier les listes autorisées, les plafonds et les capacités.
Quand choisir directement un modèle
Choisissez un modèle direct lorsqu'un client a approuvé un modèle spécifique, que la reproductibilité compte plus que l'optimisation, que le routeur modifie fréquemment les paramètres ou que l'ensemble éligible se réduit à une seule option. Un choix explicite peut être la politique d’automatisation la plus honnête.
Utilisez le même registre de demandes et de coûts afin que les deux chemins restent comparables.
Quand utiliser deux voies
Utilisez un routeur à faible coût ou à faible latence pour les brouillons et un modèle approuvé directement pour les finales. Pour les créateurs qui préfèrent une interface visuelle, le APOB AI Video Generator fournit un flux de travail multimodèle documenté, et l'APOB AI Video Editor prend en charge le transfert de création ultérieur. APOB n'est pas un routeur automatique équivalent.
L'avantage du plan à deux voies est l'intention visible : l'exploration est flexible ; la livraison est contrôlée.
Fréquence de nouveau test
Revérifiez la charte lorsque Runway modifie les documents de routage, les modèles pris en charge, les règles de prix, les préférences, les champs de réponse ou le comportement de configuration ; lorsque la surface du modèl’APOB change ; ou lorsque le budget ou les normes de livraison de l’équipe évoluent. Le journal des modifications de l’API Runway est la source horodatée de la disponibilité du routeur.
Conservez ensemble la feuille de politique, les trois essais à sec, la panne forcée, la séquence de récupération, un rapprochement en direct et la décision. Ce paquet rend le routage AI vérifiable. Si les preuves ne peuvent pas expliquer un modèle choisi et son coût, restez explicite jusqu'à ce que cela soit possible.
Sources
Soyez le premier à aimer ceci.
Pas de carte de crédit requise
