Comment tester l'API GLM-5.3-Flash dans Apidog

Tester GLM-5.3-Flash avec une collection Apidog réutilisable

Échanger un LLM dans votre application ne demande qu’une ligne de code, mais peut modifier fortement la latence, le coût des jetons, la stabilité du format de sortie, les appels d’outils et le traitement des images.

GLM-5.3-Flash illustre bien ces compromis : il coûte environ neuf fois moins cher que GLM-5.3, accepte nativement les images, mais génère environ deux fois moins vite. Pour savoir quel modèle convient à votre application, testez vos propres requêtes sur les deux.

Essayez Apidog dès aujourd’hui

Ce guide montre comment créer une collection de tests réutilisable pour l’API GLM-5.3-Flash dans Apidog : texte, images, appels d’outils, assertions et comparaison avec GLM-5.3.

Pourquoi ne pas utiliser uniquement curl ?

Vous pouvez tester ce point de terminaison avec curl ; notre guide d’API fournit un exemple complet. Mais deux problèmes apparaissent rapidement.

Les charges utiles d’images Base64 sont illisibles. Une capture d’écran encodée en URL de données peut contenir des milliers de caractères. Une commande collée dans le terminal devient difficile à lire, à modifier et à réexécuter.

Rien n’est vérifié automatiquement. Une réponse curl confirme seulement que l’appel a réussi. Elle ne garantit pas que les champs utilisés par votre application sont présents, ni que le modèle n’a pas tronqué sa réponse.

Une collection enregistrée règle ces deux problèmes : la charge utile reste modifiable et les assertions sont exécutées à chaque lancement.

Configurer l’environnement

Créez un environnement contenant les valeurs susceptibles de changer. Gardez surtout l’ID du modèle dans une variable afin de pouvoir rediriger toute la collection vers un autre modèle.

Variable	Valeur
base_url	https://api.z.ai/api/paas/v4
api_key	Votre clé Z.ai
model	glm-5.3-flash

Stockez la clé dans une variable d’environnement plutôt que directement dans les en-têtes de requête. Elle restera ainsi absente des collections exportées ou partagées.

Requête 1 : complétion de texte

Créez une requête POST vers {{base_url}}/chat/completions.

En-têtes :

Authorization: Bearer {{api_key}}
Content-Type: application/json

Corps :

{
  "model": "{{model}}",
  "messages": [
    {"role": "user", "content": "Reply with exactly: OK"}
  ],
  "reasoning_effort": "low"
}

reasoning_effort vaut max par défaut sur ce modèle. Le raisonnement étant facturé comme des jetons de sortie, utilisez low pour un simple test de connectivité.

Ajoutez les assertions suivantes :

• Le code de statut est égal à 200.
• choices[0].message.content existe.
• choices[0].finish_reason est égal à stop.
• usage.total_tokens existe.

L’assertion sur finish_reason est essentielle. Une valeur length indique que la réponse a atteint la limite de sortie au lieu d’être terminée. Comme la limite maximale annoncée pour ce modèle varie selon les sources, vérifiez explicitement ce cas.

Requête 2 : appel d’image

Cette requête vérifie la capacité native de traitement d’images de GLM-5.3-Flash, que GLM-5.3 ne possède pas.

Le point de terminaison reste identique, mais content devient un tableau de blocs typés :

{
  "model": "{{model}}",
  "messages": [
    {
      "role": "user",
      "content": [
        {"type": "text", "text": "Quelle est la couleur de la forme dominante dans cette image ? Répondez en un seul mot."},
        {"type": "image_url", "image_url": {"url": "{{test_image_url}}"}}
      ]
    }
  ],
  "reasoning_effort": "low"
}

Ajoutez test_image_url à l’environnement et faites-la pointer vers une image publique et stable dont vous connaissez la réponse. Une question déterministe sur une image fixe transforme cette démonstration en véritable test de régression.

Pour une image locale, le même champ accepte une URL de données Base64. Stockez-la comme variable d’environnement :

data:image/png;base64,iVBORw0KGgo...

Assertions recommandées :

• Le code de statut est égal à 200.
• choices[0].message.content contient la réponse attendue.
• usage.prompt_tokens est supérieur à celui de la requête textuelle seule.

Les images consomment des jetons d’entrée. Si le nombre de jetons d’invite n’augmente pas, l’image n’a probablement pas été traitée, même si l’API renvoie 200.

Consultez notre guide de vision GLM-5.3-Flash pour les détails du chemin de vision et ses principaux modes de défaillance.

Requête 3 : appel d’outils

Si votre application utilise les appels de fonctions, testez-les séparément. Le format des appels d’outils est particulièrement sensible aux changements de version du modèle ou du fournisseur.

{
  "model": "{{model}}",
  "messages": [
    {"role": "user", "content": "Le service checkout-api est-il sain ?"}
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_deployment_status",
        "description": "Renvoie le statut actuel d'un déploiement nommé.",
        "parameters": {
          "type": "object",
          "properties": {
            "service": {"type": "string", "description": "Le nom du service."}
          },
          "required": ["service"]
        }
      }
    }
  ]
}

Assertions :

• choices[0].message.tool_calls existe et n’est pas vide.
• choices[0].message.tool_calls[0].function.name est égal à get_deployment_status.
• choices[0].finish_reason est égal à tool_calls.

Vérifier le nom de la fonction permet de détecter un modèle qui appelle le mauvais outil, et pas seulement l’absence totale d’appel.

Si vous générez les définitions depuis une API existante, notre guide sur la conversion d’une spécification OpenAPI en outils d’agent explique comment éviter de rédiger manuellement les schémas.

Comparer GLM-5.3 et GLM-5.3-Flash

Grâce à la variable model, la comparaison est rapide :

1. Dupliquez l’environnement.
2. Remplacez model par glm-5.3.
3. Exécutez la même collection.
4. Comparez les résultats.

Concentrez-vous sur trois critères :

• Exactitude. Les assertions passent-elles toujours ? La requête d’image échouera avec GLM-5.3, qui ne prend pas les images en charge nativement. Il s’agit d’un résultat attendu, pas d’un test défectueux.
• Latence. Apidog affiche le temps de réponse par requête. GLM-5.3 devrait terminer plus vite les sorties longues : environ 86 jetons par seconde contre 49 pour Flash.
• Coût. L’objet usage fournit prompt_tokens et completion_tokens. Multipliez-les par le tarif de chaque modèle pour obtenir un coût réel par requête. Notre guide des tarifs présente les prix actuels, tandis que la comparaison complète des modèles détaille leurs points forts.

Surveillez aussi completion_tokens selon la valeur de reasoning_effort. Avec la valeur par défaut max, les jetons de raisonnement sont facturés comme des jetons de sortie. Une réponse visible très courte peut donc cacher un volume important de jetons. Exécutez la même invite avec low, high et max pour mesurer le besoin réel de votre charge de travail.

Tester un déploiement local

Si vous auto-hébergez les poids, vLLM et SGLang exposent tous deux des points de terminaison compatibles OpenAI. Remplacez base_url par l’URL de votre serveur et réutilisez la même collection.

C’est l’un des usages les plus utiles de cette suite. Une version quantifiée peut réussir un test de chat basique tout en échouant sur les schémas d’outils ou les entrées d’image — précisément les problèmes qui apparaissent en production.

Notre guide du déploiement local couvre la partie infrastructure.

Intégrer la collection dans la CI

Lorsque la collection est stable, exécutez-la selon un calendrier ou dans votre pipeline CI.

Déclencheurs utiles :

• Avant une migration de modèle, comme signal de validation ou de blocage.
• Selon un calendrier, pour détecter les changements côté fournisseur.
• Après une mise à jour de dépendances, car un SDK peut modifier la sérialisation des requêtes.

Les fournisseurs peuvent mettre à jour un modèle derrière un ID qui reste identique. Une exécution planifiée révèle ces changements avant qu’ils ne soient signalés par un utilisateur.

Tester les cas limites

Après les scénarios de base, ajoutez :

• Une requête avec la longueur de contexte réellement utilisée. Un comportement à 500 K jetons ne peut pas être déduit d’un test à 5 K.
• Une entrée malformée pour exercer la gestion des erreurs.
• Une réponse de limite de débit, si vous pouvez en provoquer une, afin de vérifier les réessais.
• Plusieurs images dans une requête, si votre application le nécessite. Chaque image doit avoir son propre bloc image_url.
• Le streaming, si vous l’utilisez, car sa réponse diffère d’une complétion standard.

Conclusion

La valeur ne réside pas dans chaque requête, mais dans leur répétabilité. Un choix de modèle que vous pouvez retester en trente secondes reste vérifiable lorsque les prix changent le 9 septembre, lorsque Z.ai publie une nouvelle révision ou lorsque vous envisagez un autre fournisseur.

Apidog est gratuit pour commencer. L’importation d’un schéma compatible OpenAI permet de générer une grande partie de cette configuration sans créer chaque requête manuellement.

La collection obtenue transforme le prochain changement de modèle en comparaison mesurable plutôt qu’en pari.

FAQ

• Ai-je besoin d’un forfait Apidog payant ? Non. Les collections avec variables d’environnement et assertions fonctionnent avec le forfait gratuit.
• Comment tester une image Base64 sans rendre le corps illisible ? Stockez l’URL de données dans une variable d’environnement et utilisez {{test_image_url}} dans le corps.
• Puis-je tester le point de terminaison coding-plan de la même manière ? Oui. Remplacez base_url par https://api.z.ai/api/coding/paas/v4. Ce point de terminaison diffère de l’API standard, comme l’explique notre guide Claude Code et Cline.
• Ces tests fonctionnent-ils avec d’autres fournisseurs ? En grande partie. OpenRouter, Cloudflare Workers AI et Vercel AI Gateway proposent des interfaces compatibles OpenAI. Il suffit de modifier base_url et l’espace de noms de l’ID du modèle.
• Comment vérifier une réponse non déterministe ? Testez la structure et les contraintes plutôt que le texte exact : présence des champs, types, nombre de jetons, finish_reason et présence de sous-chaînes attendues.