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

La plupart des modèles de vision vous demandent de choisir. Vous pouvez envoyer une image, ou vous pouvez envoyer beaucoup de texte, mais le modèle qui excelle dans l'un fait rarement aussi bien dans l'autre.

GLM-5.3-Flash ne vous force pas à choisir. Il accepte les images comme des blocs de contenu au sein d'une fenêtre de contexte de 1 048 576 tokens, dans la même requête que tout le reste. Cette combinaison, l'entrée d'image native plus un million de tokens d'espace, ouvre des flux de travail qu'aucune de ces capacités n'active seule.

Ce guide couvre la charge utile, les flux de travail qui valent la peine d'être construits, et les parties qui restent encore à prouver.

Native, pas basée sur des adaptateurs

Les travaux de vision antérieurs de Z.ai étaient livrés sous forme de modèles séparés. GLM-5V-Turbo et GLM-4.6V étaient des points d'extrémité distincts avec des identifiants de modèle distincts, et les utiliser signifiait router le trafic d'images ailleurs que votre trafic de texte. GLM-5.3, le grand frère de ce modèle, route la vision via des adaptateurs plutôt que de la gérer nativement.

GLM-5.3-Flash est le premier modèle de la série GLM-5 où les images sont une entrée de première classe pour le même modèle, dans le même appel, partageant le même contexte.

En pratique, cela signifie un seul identifiant de modèle, une seule ligne de facturation, un seul ensemble de limites de débit, et, surtout, une seule fenêtre de contexte contenant à la fois votre image et votre texte. Si vous utilisez une ancienne approche, notre guide d'API GLM-5V-Turbo et notre guide GLM-4.6V couvrent ces modèles.

La charge utile

L'entrée d'image fonctionne via des blocs de contenu typés. Au lieu que content soit une chaîne de caractères, il devient un tableau :

from openai import OpenAI
import os

client = OpenAI(
    api_key=os.environ["ZAI_API_KEY"],
    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 les images locales ou privées, 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}"},
    }

Plusieurs images signifient plusieurs blocs. Il n'y a pas de raccourci pour un tableau d'URL :

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 donc le texte introductif avant les images auxquelles il fait référence, et étiquetez explicitement les images lorsque vous en envoyez plusieurs. "L'image 1 est le design" donne au modèle un point d'ancrage pour sa réponse.

La configuration de base et l'authentification sont couvertes dans notre guide d'API.

Flux de travail à construire

Débogage par capture d'écran

Le cas le plus évident, et celui sur lequel Z.ai s'appuie. Ses propres documents décrivent le modèle observant "les interfaces, les résultats de rendu et le feedback d'interaction", ce qui est un cadre d'agent de codage plutôt que de description de photo.

Envoyez le rendu cassé et la source qui l'a produit 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"```jsx\n{component_source}\n```"},
]

Le modèle raisonne sur le rendu réel plutôt que sur votre description de celui-ci. Cela élimine l'étape la plus coûteuse en informations dans la plupart des conversations de débogage front-end, qui est un humain traduisant un problème visuel en mots.

Comparaison de designs

Deux images et une question. Utile en CI comme vérification douce des régressions visuelles, où un outil de différence vous dit que des pixels ont changé et un modèle vous dit si le changement est important.

Soyez réaliste quant à la fiabilité ici. Un modèle comparant des captures d'écran est un jugement, pas une affirmation. Utilisez-le pour trier les différences qu'un humain devrait examiner, et non pour bloquer un déploiement seul.

Documents et leurs spécifications

C'est là que le contexte de 1M trouve sa place. Mettez une longue spécification dans le prompt sous forme de texte et un artefact rendu sous forme d'image, puis demandez s'ils concordent.

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 dans un seul prompt n'est pas quelque chose que vous pourriez faire avec un modèle avec une fenêtre de 128K et une vision basée sur des adaptateurs. C'est la nouvelle capacité réelle.

Les notes de version de Z.ai mentionnent également les flux de travail de documents de bureau et de recherche financière comme cibles pour le comportement d'agent du modèle.

Graphiques et tableaux de bord

Lire une image de graphique et renvoyer des données structurées est une tâche d'extraction standard. Demandez du JSON et validez-le :

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

Validez la sortie par rapport à un schéma plutôt que de lui faire confiance. La lecture de graphiques est précisément le type de tâche où un modèle produit des chiffres erronés avec confiance, et la validation structurelle détecte les erreurs de forme même lorsqu'elle ne peut pas détecter les erreurs de valeur.

Pour l'extraction de documents dédiée, un spécialiste peut toujours surpasser un généraliste. GLM-OCR pour la compréhension de documents couvre cette voie.

Vidéo et fichiers

La documentation de Z.ai liste l'entrée vidéo et fichier aux côtés des images, en utilisant le même mécanisme de bloc de contenu.

Soyez prudent avec cela. Le support vidéo dans ce modèle est nouveau, peu documenté et légèrement exercé en public par rapport à l'entrée d'image, que beaucoup de gens ont maintenant exécutée. Le support du fournisseur varie également : une capacité de modèle n'est pas la même chose qu'une fonctionnalité disponible sur la passerelle que vous utilisez.

Si la vidéo est importante pour votre application, testez-la directement avec vos propres médias et votre propre fournisseur avant de concevoir autour. Ne traitez pas une ligne dans un tableau de capacités comme une fonctionnalité opérationnelle.

Là où il échoue

La multimodalité native n'est pas la même chose que la multimodalité fiable. Quatre modes de défaillance méritent d'être connus avant de déployer quelque chose.

Chiffres confiants à partir de graphiques. Lire des valeurs sur une ligne tracée est la tâche la plus susceptible de produire une réponse fluide, précisément formatée, mais fausse. La validation de schéma détecte une sortie mal formée ; elle ne peut pas détecter un nombre plausible qui est simplement incorrect. Si les chiffres sont importants, obtenez-les à partir des données sous-jacentes plutôt que d'une image de celles-ci.

Petit texte. Les captures d'écran d'interfaces utilisateur denses, les tableaux dans des captures basse résolution et le code dans des images compressées se dégradent tous. La réduction d'échelle pour économiser des tokens aggrave cela, il y a donc une tension directe entre le levier de coût et la précision. Rognez sur la région d'intérêt au lieu de réduire tout le cadre.

Précision spatiale. Les modèles décrivent bien la mise en page et la mesurent mal. "Le bouton chevauche l'entrée" est généralement juste. "Le bouton est 12 pixels trop à gauche" ne l'est généralement pas.

Confusion d'ordre et de référence. Avec plusieurs images dans une même requête, le modèle peut attribuer un détail à la mauvaise image. Étiquetez-les explicitement dans les blocs de texte, et maintenez un nombre faible lorsque la précision est importante.

Aucun de ces éléments n'est unique à GLM-5.3-Flash. Ce sont les limites standard des modèles de langage visuel, et le score de 57 sur l'Indice d'Intelligence ne l'en exempte pas. Concevez le flux de travail de manière à ce qu'une mauvaise réponse soit détectée plutôt que d'être suivie d'effet.

Coût

Les images consomment des tokens de contexte et sont facturées comme des entrées. Il n'y a pas de supplément d'image séparé.

Au prix catalogue, cela représente 0,15 $ par million de tokens d'entrée, ou 0,075 $ pendant la promotion de lancement valide jusqu'au 9 septembre 2026. Les images haute résolution consomment un nombre significatif de tokens, la résolution est donc un levier de coût : réduisez l'échelle avant d'envoyer, sauf si le détail fin est le but de la requête.

reasoning_effort est par défaut à max, ce qui facture le raisonnement comme des tokens de sortie. Pour une extraction simple d'une image, low est généralement le bon réglage et est matériellement moins cher. Notre ventilation des prix couvre ces deux leviers.

Maîtriser les coûts des images

Les images sont facturées comme des tokens d'entrée, donc la résolution est un levier de coût direct, et l'optimisation évidente entre en conflit avec les notes de précision ci-dessus.

Un ordre des opérations réalisable :

1. Rognez avant de mettre à l'échelle. Envoyer la région pertinente en pleine résolution est plus efficace qu'envoyer tout l'écran à moitié. Vous perdez du contexte dont le modèle n'avait pas besoin et conservez le détail qu'il lui faut.
2. Adaptez la résolution à la question. "La mise en page est-elle cassée ?" survit à une réduction d'échelle agressive. "Que dit ce message d'erreur ?" ne le fait pas.
3. Ne renvoyez pas les images inchangées. Dans une conversation multi-tours, une image envoyée une fois est déjà dans le contexte. La rattacher à chaque tour vous la fait payer à chaque tour.
4. Définissez reasoning_effort délibérément. Il est par défaut à max, et le raisonnement est facturé en sortie. L'extraction simple en a rarement besoin.

L'objet usage sur chaque réponse vous donne le nombre réel de tokens par appel, ce qui est le seul moyen de savoir ce qu'une image a réellement coûté plutôt que de le deviner à partir de sa taille de fichier.

Test des appels multimodaux

Les requêtes multimodales sont désagréables à tester manuellement. Une URL de données base64 fait des milliers de caractères, ce qui rend une commande curl illisible et pratiquement impossible à réexécuter en l'éditant. Les réponses sont du texte libre, il est donc facile de passer à côté des régressions.

Deux habitudes aident. Gardez un petit ensemble fixe d'images de référence et de réponses attendues, afin de pouvoir savoir quand le comportement change. Et validez l'extraction structurée par rapport à un schéma plutôt que de l'examiner à l'œil.

Apidog est un excellent endroit pour cela. Stockez les charges utiles d'images dans une requête sauvegardée au lieu d'une commande shell, conservez la clé API comme variable d'environnement, et attachez des assertions au JSON que vos prompts d'extraction renvoient. Lorsque vous changez de modèle ou qu'un fournisseur met à jour quelque chose, réexécuter la suite vous indique si le chemin de vision se comporte toujours comme prévu plutôt que de vous laisser le découvrir par un utilisateur.

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, ce qui est couvert dans notre comparaison.

Combien d'images par requête ? Plusieurs, chacune comme son propre bloc image_url. La limite pratique est votre budget de contexte.

URL ou base64 ? Les deux fonctionnent. Utilisez une URL publique lorsque l'image est déjà hébergée et accessible ; utilisez base64 pour les images locales ou privées.

Accepte-t-il la vidéo ? Z.ai documente l'entrée vidéo, mais c'est nouveau et peu exercé. Vérifiez d'abord avec vos propres médias et votre fournisseur.

Les images sont-elles facturées différemment ? Pas de supplément. Elles consomment des tokens d'entrée, donc la résolution affecte le coût.