Cloudflare Workers AI Batch Inference est utile quand le résultat peut arriver plus tard, mais que l’entreprise doit savoir quelles entrées ont été traitées et quelles sorties sont utilisables. Sortir le travail d’une requête interactive supprime l’utilisateur en attente. Cela ne supprime pas le suivi de l’achèvement.
Utilisez l’inférence asynchrone par lots pour des charges limitées dont les résultats peuvent être récupérés plus tard. Tenez un registre applicatif avec versions sources, références de soumission et résultats individuels, puis rapprochez les sorties avant leur application. Une requête en file prouve sa soumission, pas l’achèvement de chaque élément métier.
Imaginez un catalogue fournisseur nécessitant des brouillons de descriptions à partir de fiches produits approuvées. L’équipe peut attendre, mais ne doit ni publier du texte pour un produit retiré ni écraser une description plus récente. Ces règles entourent l’inférence indépendamment de la planification des appels au modèle.
Cet article décrit une proposition de traitement. Il ne promet ni délai d’achèvement, ni disponibilité d’un modèle précis, ni économie par rapport à l’inférence interactive.
Cloudflare Workers AI Batch Inference commence par un registre
L’Asynchronous Batch API de Cloudflare est documentée en bêta. Elle accepte du travail d’inférence à traiter plus tard et fournit un identifiant pour récupérer les résultats. Vérifiez modèles et limites actuels avant de développer, sans supposer que tout modèle interactif accepte le même parcours par lots.
L’application a également besoin de ses identifiants. Une référence fournisseur explique une soumission d’inférence ; une référence métier explique pourquoi elle existe. Reliez-les sans les considérer comme interchangeables.
Pour le catalogue, consignez identifiant produit, révision source, tâche demandée, révision du prompt et destination prévue. Si le produit change pendant l’inférence, l’application pourra reconnaître un résultat correspondant à une entrée ancienne.
| Champ du registre | Utilité | Échec qu’il aide à expliquer |
|---|---|---|
| Référence de tâche métier | Relie l’exécution à une demande métier | L’opérateur ne retrouve pas le responsable |
| Élément et révision source | Identifie l’entrée traitée | Résultat appliqué à des données plus récentes |
| Référence de soumission | Relie la requête d’inférence | Travail envoyé mais réponse perdue |
| Résultat de validation | Consigne si la sortie est utilisable | Requête terminée avec texte inadapté |
| Résultat à destination | Consigne si le résultat a été appliqué | Brouillon utilisable absent de la file de révision |
Figer le contrat d’entrée avant la soumission
Stockez une description reproductible des entrées. Elle peut référencer des révisions immuables plutôt que recopier les documents entiers. Un enquêteur doit pouvoir établir ce que le modèle a reçu sans dépendre du dossier actuel, désormais modifié.
Définissez le traitement des dossiers supprimés après l’instantané. Pour un produit retiré, il peut être correct de garder les preuves tout en refusant la publication. Pour un produit actualisé pendant l’exécution, programmez la révision actuelle séparément plutôt que de présenter l’ancienne sortie comme actuelle.
Conservez les révisions du prompt et du schéma de sortie avec la tâche. Une modification de prompt au milieu d’un grand catalogue doit produire une nouvelle version de traitement traçable. Sinon, une incohérence apparente du modèle peut être un changement applicatif non documenté.
Découpez le travail en unités que l’application peut rapprocher. La bonne unité dépend des règles de mise à jour à destination, pas seulement du volume maximal accepté par l’API. Une unité impossible à examiner ou répéter indépendamment devient coûteuse à récupérer.
Distinguer soumission, inférence et application
Un modèle d’état utile sépare travail préparé, soumis, retourné, validé et appliqué. Ajoutez explicitement échec et incertitude. Ne réduisez pas tout le cycle à un booléen nommé done.
Quand la réponse de soumission se perd, l’application peut ignorer si le service a accepté le travail. Une sortie d’inférence peut échouer à la validation. Après validation réussie, la destination peut encore refuser le brouillon. Chaque situation exige une action différente.
| État observé | Prochaine action sûre | Raccourci dangereux |
|---|---|---|
| Préparé, jamais soumis | Soumettre selon la politique convenue | Marquer l’élément terminé |
| Soumission incertaine | Examiner référence et registre de soumission | Renvoyer toutes les entrées à l’aveugle |
| Résultat retourné | Valider contenu et révision source | Publier immédiatement |
| Résultat périmé | Garder les preuves et traiter la source actuelle si nécessaire | Écraser le dossier modifié |
| Destination en refus | Résoudre le problème à destination | Générer plus de texte sans comprendre le refus |
Le modèle d’état doit être compréhensible par le responsable du catalogue. L’opérateur a besoin d’une explication concrète telle que « brouillon généré pour une révision obsolète », pas d’une exception brute sans contexte métier.
Concevoir une collecte qui supporte l’interruption
La collecte doit pouvoir redémarrer. Enregistrez sa progression avant la sortie du processus et rendez sa répétition sans danger. Un redémarrage ne doit pas perdre l’association entre contenu retourné et élément source.
Utilisez une interrogation bornée ou une autre méthode de récupération prise en charge par le contrat API actuel. Consignez la dernière observation de la requête et son contenu. Distinguez un résultat absent d’un collecteur qui ne fonctionne plus.
Si un résultat contient plusieurs éléments, rapprochez chacun de la liste d’entrée attendue. Identifiez dossiers manquants, répétés et inattendus. Ne prenez pas la position de sortie pour une identité lorsque l’application peut conserver une référence explicite d’élément.
La documentation REST des lots Workers AI est la référence d’implémentation. Toute politique de planification applicative décrite ici relève de votre conception, pas d’une garantie fournisseur sur le délai d’achèvement.
Valider avant de créer des données métier
Pour les descriptions, des contrôles structurels peuvent confirmer champs attendus et longueur permise. Les contrôles métier doivent aussi vérifier l’existence du produit, l’admissibilité de la révision source et l’absence d’affirmations produit sans fondement.
Une révision humaine peut faire partie du parcours à destination. Consignez la version générée approuvée, l’approbateur et les modifications avant publication. Une approbation liée uniquement à l’identifiant produit devient ambiguë si le texte est régénéré.
Gardez les sorties inutilisables examinables selon la politique de conservation. Un rejet peut révéler un champ source absent ou un défaut de prompt. Tout supprimer immédiatement peut empêcher de corriger la cause, tandis que tout garder indéfiniment crée une exposition inutile.
Réessayer la plus petite unité sûre
Classez les échecs avant de réessayer. Un échec temporaire d’inférence peut justifier une nouvelle tentative. Une source retirée, un schéma invalide ou une destination refusée exige généralement une autre réponse. Les répétitions automatiques ne résolvent pas une décision métier manquante.
Séparez nouvelle inférence et nouvelle tentative à destination. Si le brouillon est valide mais la file de révision temporairement indisponible, réutilisez le brouillon accepté lorsque c’est sûr. Relancer l’inférence peut produire un autre texte et un nouveau problème de révision sans réparer la destination.
Cloudflare documente les garanties de livraison Queues pour les applications entourant ce travail d’une file. Si vous en ajoutez une, explicitez les doublons. Son comportement de livraison ne rend pas automatiquement répétable une écriture en aval.
Avant mise en service, interrompez le collecteur, répétez une livraison et simulez une expiration à destination. Les preuves d’acceptation doivent montrer les lignes de registre modifiées et pourquoi aucun produit n’a été publié deux fois ou actualisé depuis une source périmée.
Chiffrer le parcours complet du catalogue
Demandez une estimation en GBP incluant préparation des entrées, registre, collecte, validation et intégration de destination. L’appel d’inférence n’est qu’une partie du travail. L’effort croît avec l’irrégularité des sources et la difficulté à rapprocher les résultats incertains.
Les hypothèses récurrentes doivent comprendre mises à jour sources, sorties refusées et retraitement, pas seulement la taille initiale. Vérifiez les tarifs Workers AI actuels pour le modèle et le parcours par lots choisis avant d’annoncer un coût.
| Facteur de coût | Question préalable à l’estimation |
|---|---|
| Préparation des entrées | Chaque élément est-il reproductible depuis une révision de référence ? |
| Validation | Quels contrôles sont déterministes et lesquels exigent une révision ? |
| Retraitement | Quels changements déclenchent un nouveau brouillon ? |
| Collecte et support | Qui détecte les résultats absents et les résout ? |
| Intégration de destination | Les brouillons approuvés sont-ils applicables avec des références stables ? |
Un pilote utile traite un sous-ensemble représentatif jusqu’aux dossiers de destination révisés. Il doit montrer interruption et reprise autant que débit normal. L’équipe obtient ainsi des preuves pour la prochaine phase et une estimation d’usage plus crédible.
Nous pouvons cadrer ce parcours avec notre pilote d’intégration IA . Demandez une proposition de traitement par lots avec format source, exigences de sortie, révision et destination. Ces détails déterminent si l’inférence par lots résout le véritable problème opérationnel.
Questions fréquentes
Quand utiliser l’inférence asynchrone par lots ? Quand les résultats peuvent arriver plus tard et la charge peut être suivie sans utilisateur en attente. Brouillons de catalogue, synthèses hors ligne et embeddings peuvent convenir selon les modèles actuellement pris en charge et la validation applicative.
Mis en file signifie-t-il terminé ? Non. C’est un état de soumission, pas un résultat métier vérifié. Suivez séparément achèvement de l’inférence, validation de sortie et application à destination.
Tous les modèles Workers AI fonctionnent-ils par lots ? Ne le supposez pas. Vérifiez documentation actuelle et catalogue de modèles pour le parcours choisi avant de développer ou chiffrer. La fonctionnalité est documentée en bêta au moment de la révision.
Que faire si les sources changent pendant le lot ? Comparez le résultat avec la révision source consignée à la soumission. S’il est périmé, n’écrasez pas le dossier récent. Gardez les preuves et traitez la révision actuelle si le besoin métier demeure.
Faut-il relancer tout le lot après une panne ? Uniquement après avoir établi que c’est sûr. Préférez rapprocher les résultats individuels et répéter la plus petite unité appropriée. Une panne à destination n’exige pas forcément une autre inférence.
Comment budgéter le projet ? Incluez préparation, suivi, collecte, validation, révision et intégration. Estimez l’usage récurrent à partir du modèle choisi et d’hypothèses mesurées sur entrées, sorties et retraitement. La facture d’inférence n’est pas le coût total d’exploitation.
Que doit prouver un pilote de lots ? Il doit montrer que les entrées attendues deviennent des résultats traçables et validés, et que les éléments périmés ou échoués sont correctement traités. Interrompez la collecte, répétez une livraison et testez une panne à destination avant de déclarer le parcours prêt.