Vitesse d'inférence GLM-5 sur WaveSpeed : Latence et débit

Je voulais une réponse rapide en rédigeant un e-mail d’intégration. GLM-5 semblait intelligent, mais le premier token prenait assez longtemps pour que je me retrouve à fixer le curseur. Pas une catastrophe, juste une petite pause qui revenait sans cesse. C’est généralement le signal qui me pousse à vérifier ce qui se passe réellement.

Je m’appelle Dora. J’ai effectué une série de tests simples pour voir combien de vitesse d’inférence GLM-5 je pouvais extraire sans transformer mon flux de travail en projet scientifique. Rien de sophistiqué, juste assez pour ressentir la différence dans un vrai contexte de travail, pas en laboratoire.

Méthodologie de test (matériel, paramètres, longueurs de prompt)

J’ai essayé trois chemins d’accès :

• ​WaveSpeed​ : une couche d’accélération légère que je teste, qui gère la mise en forme des requêtes et la mise en cache côté client/passerelle.
• ​API Z.ai directe : le chemin direct vers GLM-5 via le fournisseur.
• ​OpenRouter​ : un intermédiaire qui transfère vers le fournisseur du modèle avec quelques fonctionnalités supplémentaires.

Matériel et contexte

• Client local : MacBook Pro (M2 Max, 64 Go de RAM). Réseau sur fibre stable (≈500 Mbps en téléchargement, ≈30 ms vers les endpoints US courants).
• Côté serveur : pas de serveur personnalisé, uniquement des appels client, sauf pour WaveSpeed, qui fait tourner une petite passerelle locale pour gérer la mise en cache et la mise en forme des lots.

Paramètres maintenus constants sauf indication contraire

• Modèle : GLM-5 (chat/completions), temperature 0,2, top_p 0,9, max_tokens 512.
• Streaming activé, car c’est ainsi que je travaille réellement.
• Tentatives de reconnexion désactivées sauf pour les erreurs réseau.

Prompts utilisés

• Court : 60–80 tokens (une instruction concise avec 2–3 contraintes).
• Moyen : ~350 tokens (brouillon d’e-mail avec notes de marque et exemples).
• Long : ~1 500 tokens (un petit brief avec contexte produit, notes de ton et listes à faire/ne pas faire).

J’ai effectué 25 itérations par condition et enregistré :

• Temps jusqu’au premier token (TTFT) : de l’envoi de la requête au premier token diffusé.
• Débit (tokens/s) : taux de sortie en streaming une fois les tokens démarrés.
• Un interrupteur pour le « mode réflexion » (traces de raisonnement du fournisseur).

Métriques clés

Temps jusqu’au premier token (TTFT)

Les prompts courts se situaient entre 250 et 400 ms sur les bons chemins. Les prompts moyens poussaient le TTFT vers 450–700 ms. Les prompts longs dépassaient une seconde sauf si la mise en cache intervenait. La progression n’était pas linéaire : on avait l’impression que les surcharges de mise en file d’attente et de validation importaient autant que la longueur du prompt.

Ma réaction : moins de 400 ms se ressent comme réactif ; tout ce qui dépasse une seconde me sort du flux. Quand j’édite du texte en direct, ce premier token compte davantage que le débit final.

Tokens par seconde (débit)

Une fois le streaming lancé, j’observais 35–70 tok/s sur les runs sans réflexion. C’est confortablement rapide pour du texte, limite pour des diffs de code. Le débit baissait sur les sorties longues, ce que je soupçonne être dû à la mise en forme côté serveur et aux passes de sécurité plutôt qu’à la vitesse pure du modèle.

Mode réflexion vs mode sans réflexion

Avec le « mode réflexion » activé, le TTFT augmentait de 30 à 80 %, et le débit était parfois divisé par deux. La prose était plus cohérente sur les prompts délicats, mais pour la rédaction quotidienne je n’en avais pas besoin. Ça ne m’a pas fait gagner du temps au début, mais après quelques runs, j’ai remarqué que ça réduisait l’effort mental sur les éditions complexes. Sur les tâches simples, je le laisse désactivé.

Comment l’accélération WaveSpeed s’applique à GLM-5

WaveSpeed n’a pas touché aux poids du modèle. Il a fait deux choses simples et utiles de mon côté du câble : réduire le travail redondant et mettre en forme les requêtes pour que le fournisseur puisse aller plus vite. Sur GLM-5, cela s’est traduit par un meilleur TTFT sur les prompts répétés et de petits gains sur les prompts moyens.

ParaAttention et techniques de mise en cache

• ParaAttention (mes notes) : Au lieu de regrouper des requêtes sans rapport, WaveSpeed parallélise les fragments compatibles avec l’attention à l’intérieur d’un seul long prompt lorsqu’il détecte une structure récurrente. En pratique, il réutilisait le préambule (système + exemples partagés) et ne transmettait que le delta. Je ne peux pas vérifier les mécanismes internes, mais l’effet ressemblait à une réutilisation partielle du KV au niveau de la passerelle.
• Mise en cache : Elle mémorisait les embeddings pour le préambule du prompt et les courtes templates système. Lorsque j’itérais sur la même tâche avec de légères modifications, le TTFT baissait de ~120–180 ms. Sur les prompts froids, le bénéfice était plus faible (~40 ms) mais toujours perceptible.

Limites rencontrées

• Le premier run à froid est toujours limité par l’upstream. Pas de miracle.
• Si je modifiais plus de ~20 % du prompt, le cache n’aidait pas.
• Le mode réflexion neutralisait largement les gains : la trace de raisonnement se comportait comme un flux séparé.

Comparaison : WaveSpeed vs API Z.ai directe vs OpenRouter

C’est là que les petites différences comptent.

• API Z.ai directe : Consistante. Variance la plus faible dans le TTFT. Quand j’avais besoin de démarrages prévisibles pour des démos, c’était mon choix. Sur les prompts longs, la pénalité TTFT était réelle mais stable.
• OpenRouter : TTFT légèrement plus élevé en moyenne, un peu plus de variance, mais configuration facile et flexibilité de routage. Pratique quand je jongle avec plusieurs modèles. La documentation est solide : voir les guides OpenRouter.

• Couche WaveSpeed : Meilleur TTFT sur les prompts chauds et les entrées moyennes, probablement grâce à la mise en cache et à la mise en forme des requêtes. Sur les prompts longs vraiment froids, elle était à égalité avec le direct.

Aucun de ces chemins n’a modifié le comportement fondamental de GLM-5. Ils ont changé la rapidité avec laquelle je sentais le modèle « se réveiller », et la fluidité de l’itération.

Si vous devez choisir :

• Besoin de performances stables et moins de points de défaillance ? Passez directement par le fournisseur. Référence : la documentation API ZhipuAI.
• Besoin du routage multi-modèles ou de clés partagées entre outils ? OpenRouter convient, acceptez quelques millisecondes supplémentaires.
• Vous itérez sur des prompts similaires toute la journée ? Une couche d’accélération légère rapporte davantage en sérénité mentale qu’en vitesse brute.

Conseils d’optimisation pour les charges de travail en production

Ce qui a vraiment aidé en pratique :

• Préchauffez le préambule : Gardez les prompts système et les exemples partagés stables. Mettez-les en cache, même côté client. Mes économies de TTFT : ~100–200 ms sur les répétitions.
• Taillez la queue : Limitez max_tokens à ce dont vous avez vraiment besoin. Réduire un plafond de 1 000 tokens à 400 a économisé 10–20 % du temps total sur mes brouillons.
• Privilégiez les tentatives structurées : Si vous devez relancer, reprenez les streams, ne les redémarrez pas. Les retries aveugles tuaient le TTFT.
• Contrôlez la variabilité : temperature ≤0,3 pour la production. Une entropie plus faible réduisait les passes serveur et rendait le débit plus stable.
• Différez le mode réflexion : Activez-le uniquement sur les prompts qui échouent historiquement. Je cartographie les « prompts difficiles » et bascule l’indicateur par route.
• Découpez le contexte long en amont : Résumez les références une fois, stockez le résumé et réutilisez-le. Les deuxième et troisième runs se sentent nettement plus légers.
• Surveillez la tokenisation : Différents SDK tokenisent légèrement différemment. Verrouillez le client et mesurez à nouveau : j’ai observé des régressions fantômes rien que de cette source.
• Mesurez le p95, pas seulement le p50 : Les queues irrégulières causent le lag visible dont les utilisateurs se souviennent.

Données brutes de benchmark (tableau)

Voici le snapshot de mes runs (25 itérations par ligne). Tous les chiffres sont approximatifs mais représentatifs de ce que j’ai ressenti au clavier.

Notes

• « Préambule chaud » signifie que le système + les exemples partagés étaient mis en cache par la passerelle.
• Le débit est mesuré après le premier token. Temps total = TTFT + tokens_out / débit.
• Le réseau était stable : quand j’ai testé sur un Wi‑Fi d’hôtel, tout s’était dégradé de 10–20 %.

Une dernière observation : réduire de 150 ms le TTFT comptait davantage pour moi qu’ajouter 5 tok/s, car cela réduisait la petite attente qui déclenche le changement de contexte. Ce n’est pas une règle universelle, c’est juste ainsi que mon cerveau gère les streams.