Comment mesurer la latence de Mercury 3 au-delà des jetons par seconde

Mesurez Mercury 3 du début de la tâche jusqu’à ce que sa sortie soit exploitable. Notez le délai avant la première réponse, le délai avant la réponse complète et la durée totale, outils compris. Le nombre de jetons par seconde décrit une partie de la génération ; il peut ne pas tenir compte de l’attente avant la sortie ni du travail nécessaire une fois le modèle terminé.

Utilisez un petit exemple de test avec des critères d’acceptation explicites, et consignez le prompt, les fichiers d’entrée, l’environnement des outils et les réglages du modèle. Cela suffit pour établir le comportement de base et mettre au jour les goulots d’étranglement. Élargissez l’essai uniquement lorsqu’un échec ou une décision difficile nécessite davantage d’éléments.

Quels horodatages dois-je recueillir ?

Utilisez un chronomètre monotone côté client pour mesurer les durées et indiquez si la diffusion en continu est activée. Si vous comparez des fournisseurs, gardez constantes les conditions d’établissement de la connexion et de réutilisation de celle-ci. Ne déduisez pas le comportement au premier jeton d’une requête sans diffusion en continu.

Comment choisir un prompt de test équitable ?

Choisissez une tâche réelle et bien délimitée : extraire des champs précis d’un document approuvé ou apporter une petite modification à une copie d’un dépôt. Gardez les entrées et la sortie requise identiques d’une exécution à l’autre. Notez l’identifiant du modèle, le réglage d’effort et la limite de sortie afin que les résultats restent interprétables.

La présentation de Mercury 3 explique pourquoi les chiffres de débit des fournisseurs ne remplacent pas cette mesure au niveau de la tâche.

Quel est l’effet des outils sur le résultat ?

Distinguez le temps d’attente du modèle du temps d’exécution des outils. Une lecture lente sur un NAS, la navigation entre les pages ou une recherche externe peut dominer une tâche en plusieurs étapes. Comptabilisez les nouvelles tentatives, les arguments d’outil erronés et les lectures répétées de fichiers au lieu d’ignorer le temps consacré aux tentatives infructueuses.

Utilisez la liste de vérification du harnais d’agent pour déterminer quel composant est responsable de chaque délai. Si l’appel au modèle ne représente qu’une petite partie de la tâche, améliorer l’accès au stockage ou la conception de la tâche peut être plus utile que de changer d’architecture de génération.

De combien d’exécutions ai-je besoin ?

Une exécution suffit pour vérifier la connectivité et détecter les problèmes manifestes de justesse. Quelques répétitions cohérentes peuvent révéler d’importantes différences pratiques, mais ne justifient pas des affirmations précises sur la fiabilité ni des percentiles de queue stables. Recueillez davantage d’observations uniquement si les enjeux du déploiement ou une décision de performance serrée le justifient.

Signalez toujours les échecs. Une exécution rapide réussie, choisie parmi plusieurs tentatives infructueuses, ne constitue pas une preuve représentative. Le guide de vérification ciblée des flux de travail propose une méthode légère de validation.

Que faut-il indiquer en plus de la latence ?

Indiquez si le résultat a été validé, les frais d’utilisation concernés, les appels d’outils et les corrections manuelles. Précisez l’environnement et la date. Si une exécution a dépassé le délai autorisé, consignez-la comme un dépassement de délai au lieu de lui attribuer un score de vitesse flatteur.

Pour les fichiers NAS, conservez le jeu de données de test et le résultat accepté dans des répertoires distincts. Utilisez la comparaison des architectures pour interpréter les mesures, et le guide de préparation des fichiers pour limiter l’exposition des données du projet pilote.

Foire aux questions

Peut-on comparer directement les jetons par seconde de différents tokeniseurs ?

Interprétez ces chiffres avec prudence. Les définitions des jetons, le contenu généré et les conditions de mesure peuvent varier d’un fournisseur à l’autre.

Que faire si l’API ne prend pas en charge la diffusion en continu ?

Mesurez la durée de la réponse complète et la réalisation de la tâche. Ne prétendez pas mesurer le délai avant le premier jeton si votre client ne peut pas l’observer.

Faut-il exclure les exécutions échouées ?

Non. Consignez les délais d’attente dépassés, les nouvelles tentatives et les résultats rejetés, car ils influent sur le temps d’exécution et le coût réels.

Ai-je besoin d’un grand benchmark avant un projet pilote ?

Non. Commencez par une petite tâche représentative et élargissez les mesures uniquement lorsqu’une incertitude importante le justifie.

Articles connexes

• Mercury 3 expliqué : pourquoi les modèles de langage à diffusion sont importants pour des flux de travail d’IA rapides
• Modèles de langage à diffusion ou autorégressifs : lesquels conviennent le mieux à votre flux de travail d’IA personnel ?

Sources

• Annonce officielle et documentation du modèle — www.inceptionlabs.ai
• Documentation technique et référence — docs.inceptionlabs.ai

Couverture : image officielle de l’annonce de Mercury 3. Source de l’image.