Récupérer après une déconnexion de flux LLM

Récupérer après une déconnexion de flux LLM : guide de production avec décision explicite, artefact réutilisable, tests d’échec, signaux d’exploitation et limites sourcées.

Récupérer après une déconnexion de flux LLM : guide de production avec décision explicite, artefact réutilisable, tests d’échec, signaux d’exploitation et limites sourcées.

Réponse directe

Implémentez Récupérer après une déconnexion de flux LLM comme un contrat de contrôle de fiabilité, pas comme une configuration ponctuelle. Figez protocole, owner, preuves et rollback avant le trafic. Points de contrôle : first_event, partial_output, terminal_event, replay_policy.

La conclusion est fixée par la table de contrat et l’exemple déterministe. llm-stream-disconnect-recovery ne passe pas en rollout si un contrôle dur manque de preuve réseau, de relecture durable ou d’owner.

Périmètre et responsabilités

Séparez la tâche client du plan de contrôle. Le client possède son fichier ou sa variable ; la passerelle possède authentification, routage, limites, comptabilité et tentatives ; le fournisseur possède son protocole natif et ses capacités volatiles. Une réponse texte ne prouve qu’un seul chemin.

L’article possède la décision, les risques et la preuve ; la documentation vivante garde les commandes et étapes d’interface volatiles. On obtient ainsi un arbre de capacités sans doubler l’owner d’une intention.

Le registre owner de cette page est llm-stream-disconnect-recovery ; ses contrôles figés sont first_event, partial_output, terminal_event, replay_policy. Chaque valeur est vérifiée à la limite réseau ou durable, jamais déduite d’un libellé commercial.

Artefact pratique: Récupérer après une déconnexion de flux LLM

Ce registre de revue est l’artefact livrable. Les valeurs techniques explicites permettent de comparer configuration, preuve réseau et état durable sans capture d’écran.

Contrôle Décision fixée Preuve
stream_identity one_attempt_id_per_connection logical_request_id + attempt_id + provider_request_id
first_effective_event record_exact_transition event_type + timestamp + bytes_received
partial_output incomplete_not_success last_event_type + buffered_item_ids + incomplete_marker
tool_arguments decode_only_after_terminal_boundary call_id + fragment_sequence + completion_event
replay policy_depends_on_side_effect_risk replay_decision + new_attempt_id + prior_attempt_link
billing retain_each_attempt_and_final_settlement attempt_usage + terminal_state + charge_record

Exemple déterministe

L’exemple utilise des placeholders et des entrées déterministes. Remplacez seulement les identifiants validés, jamais les secrets ou données client, et gardez le snapshot exact.

CONNECTING -> STREAMING -> TERMINAL_SUCCESS
     |             |  \
     |             |   -> DISCONNECTED_AFTER_PARTIAL -> INCOMPLETE
     |             -> CLIENT_CANCELLED -> CANCELLED
     -> DISCONNECTED_BEFORE_FIRST_EVENT -> RETRY_ELIGIBLE?

Never concatenate output from two attempt IDs.
Never execute partial tool arguments.

Niveaux de vérification

Exécutez les contrôles dans l’ordre. Un succès tardif ne compense pas une limite absente ; chaque tentative doit rejoindre une requête logique.

  1. Figer client, politique de passerelle, alias de modèle, routes et référence observable. Preuve pour stream_identity : appliquer one_attempt_id_per_connection et conserver logical_request_id + attempt_id + provider_request_id.
  2. Exécuter une sonde positive déterministe et conserver réponse, request ID, route, état terminal et usage. Preuve pour first_effective_event : appliquer record_exact_transition et conserver event_type + timestamp + bytes_received.
  3. Exécuter le cas négatif, limite ou déconnexion associé et vérifier la couche d’échec. Preuve pour partial_output : appliquer incomplete_not_success et conserver last_event_type + buffered_item_ids + incomplete_marker.
  4. Répéter sur le vrai protocole ; ne pas déduire le support natif d’un endpoint voisin. Preuve pour tool_arguments : appliquer decode_only_after_terminal_boundary et conserver call_id + fragment_sequence + completion_event.
  5. Déployer sur une cohorte bornée avec owner, expiration, seuil d’arrêt et rollback. Preuve pour replay : appliquer policy_depends_on_side_effect_risk et conserver replay_decision + new_attempt_id + prior_attempt_link.
  6. Relire configuration et comptabilité durables ; supprimer accès et données temporaires. Preuve pour billing : appliquer retain_each_attempt_and_final_settlement et conserver attempt_usage + terminal_state + charge_record.

Défaillances à éviter

Chaque point suivant bloque la publication. HTTP 200, tableau de bord ou démonstration ne remplacent pas ces contrôles.

  • blind_reconnect — Si blind_reconnect apparaît, arrêtez le rollout et appliquez owner, preuves et rollback ; une sonde réussie ne l’annule pas.
  • partial_success — Si partial_success apparaît, arrêtez le rollout et appliquez owner, preuves et rollback ; une sonde réussie ne l’annule pas.
  • cross_attempt_splice — Si cross_attempt_splice apparaît, arrêtez le rollout et appliquez owner, preuves et rollback ; une sonde réussie ne l’annule pas.
  • partial_tool_execution — Si partial_tool_execution apparaît, arrêtez le rollout et appliquez owner, preuves et rollback ; une sonde réussie ne l’annule pas.

Signaux et conditions d’arrêt

Observez ensemble succès et dommage. Le seuil vient de la politique du workload ; fixez SLO et dénominateur avant la fenêtre.

Signal Seuil Action
disconnect_before_first_event_rate workload_SLO_threshold inspect_connect_and_header_phases
disconnect_after_partial_rate workload_SLO_threshold mark_incomplete_and_stop_auto_retry
stream_without_terminal_event 0_success_classifications reclassify_and_investigate
cross_attempt_fragment_count 0 disable_recovery_path

Limites de Modelflare

Modelflare centralise routage compatible et natif, clés limitées, groupes, usage et échecs. Un canal ne prouve pas tous les champs, alias, engagements de conservation, régions ou fallbacks. Vérifiez en natif et prenez le règlement durable comme vérité financière.

C’est une méthode d’implémentation, pas une certification, conclusion juridique, historique d’uptime ou benchmark universel. Revérifiez contrat, modèles, prix, conservation et régions à T-1 ; déplacez la date si un fait central change.

Poursuivre dans le cluster

Le parent traite la décision large, le sibling l’étape suivante et la documentation la configuration actuelle. Les liens de corps sont nécessaires car le CMS géré n’a pas de related-slug.

Questions fréquentes

Récupérer après une déconnexion de flux LLM : Une requête réussie suffit-elle ?

Non. Cas négatif, rollout borné, relecture durable et arrêt sont des gates distincts.

Récupérer après une déconnexion de flux LLM : Faut-il figer modèles et prix des mois avant ?

Non. Utilisez placeholders ou snapshots et revérifiez à T-1.

Récupérer après une déconnexion de flux LLM : Quelles preuves conserver ?

IDs sans données sensibles, version, temps, état, usage, charge finale et décision.

Sources et date de vérification

Sources vérifiées le 2026-08-07. Elles définissent contrats et principes, pas les routes non testées ni l’état futur.