GLM-5.3-Flash Vision : Envoyer des images à un modèle à 1M de contexte

GLM-5.3-Flash : vision native et contexte d’un million de tokens

La plupart des modèles de vision vous obligent à choisir entre image et texte. GLM-5.3-Flash accepte les images comme des blocs de contenu dans une fenêtre de contexte de 1 048 576 tokens, avec tout le texte dont vous avez besoin dans la même requête.

Essayez Apidog aujourd’hui

Cette combinaison — entrée d’image native et vaste contexte — permet des flux de travail qu’aucune de ces capacités ne rend possibles seule. Voici la charge utile à utiliser, les cas d’usage pertinents et les limites à prendre en compte.

Une vision native, pas un adaptateur

Les précédents modèles de vision de Z.ai étaient séparés : GLM-5V-Turbo et GLM-4.6V possédaient chacun leur identifiant et leur point d’accès. GLM-5.3, lui, achemine la vision via des adaptateurs.

GLM-5.3-Flash est le premier modèle GLM-5 dont les images sont une entrée de première classe, dans le même appel et le même contexte que le texte.

En pratique, vous disposez de :

• un seul identifiant de modèle ;
• une seule ligne de facturation ;
• un seul ensemble de limites de débit ;
• une seule fenêtre de contexte pour les images et le texte.

Pour les anciennes approches, consultez notre guide d’API GLM-5V-Turbo et notre guide GLM-4.6V.

Construire la charge utile

L’image est envoyée dans un bloc de contenu typé. content n’est donc plus une chaîne, mais un tableau :

from openai import OpenAI
import os

client = OpenAI(
    [REDACTED CREDENTIAL],
    base_url="https://api.z.ai/api/paas/v4/",
)

response = client.chat.completions.create(
    model="glm-5.3-flash",
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "What is wrong with this layout on mobile?"},
                {
                    "type": "image_url",
                    "image_url": {"url": "https://example.com/mobile-view.png"},
                },
            ],
        }
    ],
)

print(response.choices[0].message.content)

Pour une image locale ou privée, utilisez une URL de données base64 :

import base64
from pathlib import Path

def image_block(path: str) -> dict:
    data = base64.b64encode(Path(path).read_bytes()).decode("utf-8")
    suffix = Path(path).suffix.lstrip(".").replace("jpg", "jpeg")
    return {
        "type": "image_url",
        "image_url": {"url": f"data:image/{suffix};base64,{data}"},
    }

Chaque image doit être son propre bloc :

content = [
    {"type": "text", "text": "Image 1 is the design. Image 2 is what we built. List the differences."},
    image_block("design.png"),
    image_block("built.png"),
]

L’ordre est important : le modèle lit le tableau séquentiellement. Placez le contexte avant les images et identifiez explicitement chaque image lorsque vous en envoyez plusieurs.

La configuration initiale et l’authentification sont détaillées dans notre guide d’API.

Flux de travail utiles

Déboguer avec une capture d’écran

C’est le cas d’usage le plus évident, et celui mis en avant par Z.ai. Sa documentation décrit un modèle capable d’observer des interfaces, des rendus et des retours d’interaction — davantage un scénario d’agent de programmation qu’une simple description d’image.

Envoyez le rendu défectueux et le code source dans la même requête :

content = [
    {"type": "text", "text": "This component renders incorrectly below 400px. Here is the screenshot and the source."},
    image_block("bug-mobile.png"),
    {"type": "text", "text": f"```
{% endraw %}
jsx\n{component_source}\n
{% raw %}
```"},
]

Le modèle analyse le rendu réel au lieu de dépendre de la description d’un humain. Vous éliminez ainsi une étape coûteuse : traduire un problème visuel en mots.

Comparer des designs

Envoyez deux images et demandez une comparaison. En CI, un outil de différence détecte les pixels modifiés tandis que le modèle estime si le changement est significatif.

Utilisez cette sortie pour trier les régressions à faire vérifier par un humain, pas pour bloquer seul un déploiement. Une comparaison de captures d’écran reste un jugement, pas une preuve.

Vérifier un document par rapport à sa spécification

C’est ici que la fenêtre de contexte d’un million de tokens devient réellement utile. Placez une longue spécification sous forme de texte et l’artefact généré sous forme d’image :

content = [
    {"type": "text", "text": f"Specification:\n\n{spec_text}"},
    {"type": "text", "text": "Below is the generated report. Does it satisfy every requirement above? List gaps."},
    image_block("generated-report.png"),
]

Une spécification de 40 pages et une image peuvent tenir dans le même prompt. Ce flux n’est pas possible de la même façon avec un modèle limité à 128K tokens et doté d’une vision basée sur des adaptateurs.

Les notes de version de Z.ai citent également les documents bureautiques et la recherche financière parmi les scénarios visés par le comportement d’agent.

Extraire des graphiques et des tableaux de bord

Demandez une structure JSON et validez-la systématiquement :

content = [
    {"type": "text", "text": "Extract the series in this chart as JSON: [{label, values: [...]}]. Return only JSON."},
    image_block("quarterly.png"),
]

La validation par schéma détecte les erreurs de structure, mais pas les nombres plausibles et incorrects. Pour les données importantes, utilisez les données sources plutôt qu’une image du graphique.

Pour l’extraction documentaire spécialisée, un modèle dédié peut rester supérieur à un généraliste. Voir GLM-OCR pour la compréhension de documents.

Vidéo et fichiers

La documentation de Z.ai mentionne les entrées vidéo et fichier avec le même mécanisme de blocs de contenu.

Restez prudent : ces fonctions sont récentes, moins documentées et moins testées publiquement que l’entrée d’image. De plus, la capacité annoncée par le modèle n’est pas forcément disponible sur la passerelle utilisée.

Si la vidéo est essentielle à votre application, testez-la avec vos propres médias et votre propre fournisseur avant de concevoir votre architecture autour de cette fonction.

Limites et modes d’échec

La multimodalité native ne garantit pas des résultats fiables. Prévoyez au minimum ces quatre problèmes :

Chiffres incorrects dans les graphiques. Le modèle peut produire une réponse fluide et bien formatée tout en lisant mal une valeur. Un schéma valide ne garantit pas une valeur correcte. Utilisez les données sous-jacentes lorsque la précision compte.

Texte trop petit. Les interfaces denses, les tableaux basse résolution et le code compressé se dégradent rapidement. Rognez la région d’intérêt au lieu de réduire toute l’image.

Précision spatiale limitée. Le modèle décrit généralement bien une relation comme « le bouton chevauche le champ », mais mesure mal un écart précis comme « 12 pixels trop à gauche ».

Confusion entre les images. Avec plusieurs images, un détail peut être attribué au mauvais visuel. Ajoutez des libellés dans les blocs de texte et limitez le nombre d’images lorsque la précision est critique.

Ces limites ne sont pas propres à GLM-5.3-Flash. Elles sont communes aux modèles de langage visuel, et le score de 57 sur l’Indice d’Intelligence ne les élimine pas. Concevez vos flux pour qu’une erreur soit détectée avant de déclencher une action.

Coût

Les images consomment des tokens d’entrée et sont facturées comme tels. Il n’existe pas de supplément séparé pour les images.

Au tarif catalogue, le coût est de 0,15 $ par million de tokens d’entrée, ou 0,075 $ pendant la promotion de lancement valable jusqu’au 9 septembre 2026.

Les images haute résolution peuvent consommer beaucoup de tokens. La résolution est donc un levier de coût important. Réduisez-la lorsque les détails fins ne sont pas nécessaires.

reasoning_effort vaut max par défaut et le raisonnement est facturé comme des tokens de sortie. Pour une extraction simple, low est souvent suffisant et nettement moins cher. Notre guide des prix détaille ces deux leviers.

Maîtriser le coût des images

Les images étant facturées comme des tokens d’entrée, l’optimisation de la résolution doit être arbitrée avec la précision attendue.

Appliquez cet ordre :

• Rognez avant de réduire l’échelle. Envoyez la région pertinente en pleine résolution plutôt que tout l’écran à moitié réduit.
• Adaptez la résolution à la question. Une réduction agressive peut convenir pour vérifier une mise en page, mais pas pour lire un message d’erreur.
• Ne renvoyez pas les images inchangées. Dans une conversation multi-tours, une image déjà envoyée appartient au contexte. La rattacher à chaque tour la fait facturer à nouveau.
• Définissez reasoning_effort explicitement. L’extraction simple nécessite rarement max.

L’objet usage de chaque réponse fournit le nombre réel de tokens consommés. C’est la seule façon de connaître le coût effectif d’une image au lieu de l’estimer à partir de sa taille de fichier.

Tester les appels multimodaux

Les tests manuels sont difficiles : une URL de données base64 produit des milliers de caractères et les réponses en texte libre masquent facilement les régressions.

Deux pratiques sont particulièrement utiles :

1. Conservez un petit jeu fixe d’images de référence et de réponses attendues.
2. Validez toute extraction structurée avec un schéma.

Apidog convient bien à ce workflow. Enregistrez les charges utiles d’image dans une requête, stockez la clé API dans une variable d’environnement et ajoutez des assertions au JSON produit par vos prompts.

Après un changement de modèle ou une mise à jour du fournisseur, relancez la suite pour vérifier que le comportement de vision reste stable.

FAQ

GLM-5.3 prend-il également en charge les images ?

Pas nativement. GLM-5.3 achemine la vision via des adaptateurs séparés. Flash est le modèle nativement multimodal. Voir notre comparaison.

Combien d’images peut-on envoyer par requête ?

Plusieurs, chacune dans son propre bloc image_url. La limite pratique dépend de votre budget de contexte.

Faut-il utiliser une URL ou du base64 ?

Les deux fonctionnent. Utilisez une URL publique pour une image déjà hébergée et accessible, et base64 pour une image locale ou privée.

La vidéo est-elle prise en charge ?

Z.ai documente l’entrée vidéo, mais cette fonction est récente et peu testée. Vérifiez-la avec vos propres médias et votre fournisseur.

Les images sont-elles facturées différemment ?

Non. Elles consomment des tokens d’entrée, la résolution influence donc directement le coût.