Benchmarks

Comment la mesure a été faite

Tout a tourné dans Docker sur une seule machine, chaque composant épinglé à ses propres cœurs afin que rien ne se dispute le CPU.

• Les deux passerelles se placent devant le même upstream avec une configuration de modèle identique : aucune n'a le chemin le plus facile.
• Chaque passerelle tourne comme sa propre documentation le recommande : LiteLLM selon son guide de production, avec autant de workers que de vCPU ; Wäg avec ses réglages par défaut. Le cache de réponses est désactivé des deux côtés.
• Les tests en boucle fermée mesurent le débit maximal. Les tests en boucle ouverte émettent à cadence fixe et comptent la latence à partir de l'instant d'envoi prévu : une passerelle qui met en file d'attente ne peut donc pas le dissimuler.
• Chaque réponse est validée : statut, structure du corps et, pour les flux, le nombre de fragments attendu et sa terminaison. Tout le reste compte comme une erreur, jamais comme une réponse rapide.
• Chaque scénario est exécuté trois fois et les tableaux affichent la médiane. Sans passerelle dans le chemin, la même charge atteint environ 90 000 req/s, bien au-delà des deux passerelles : les résultats sont donc limités par la passerelle, pas par le harnais.

Empreinte

Ce que coûte chaque passerelle avant de servir quoi que ce soit : mémoire au repos, temps de démarrage, taille de l'image et latence ajoutée à une requête unique face à un upstream instantané.

Ce que cela signifie : La mémoire décide du nombre de réplicas qui tiennent sur un nœud, et la taille de l'image de la rapidité d'un déploiement. Avec 3,8 Mo résidents et une image de 123 Mo, Wäg tient dans un sidecar et est prêt avant l'expiration d'un health check ; 2,3 Go et 11 secondes, c'est un pod autour duquel il faut planifier.

La latence ajoutée correspond au p50 de la passerelle moins le p50 mesuré sans passerelle dans le chemin.

Avec un upstream réaliste

Un vrai modèle répond en centaines de millisecondes : des milliers de requêtes sont donc en vol simultanément. Ici l'upstream prend 300 ms et les requêtes arrivent à cadence fixe quoi que fasse la passerelle. À 2 000 req/s, environ 600 requêtes sont en cours à tout instant.

Ce que cela signifie : C'est la forme du trafic réel : un modèle répond en centaines de millisecondes et des milliers de requêtes sont en vol. Une passerelle qui met en file d'attente transforme une réponse de 300 ms en plusieurs secondes, et personne ne le voit avant le pic. Wäg reste au plancher jusqu'à 2 000 req/s avec moins d'un tiers de son budget CPU. LiteLLM met déjà en file d'attente à 1 000 et échoue sur 8 % des requêtes à 2 000.

L'upstream seul prend 300 ms : c'est le plancher. Tout ce qui le dépasse est du temps passé en file d'attente dans la passerelle. La colonne × se lit toujours de la même façon : plus la valeur est élevée, plus Wäg est devant. C'est Wäg ÷ LiteLLM pour le débit et LiteLLM ÷ Wäg pour la latence.

Débit et latence

Boucle fermée face à un upstream instantané : le coût pur de la passerelle, sans latence de modèle derrière laquelle se cacher. Ce sont les chiffres nécessaires à un plan de capacité. Ce ne sont pas la raison de choisir un plan de contrôle.

4 vCPU, sans base de données

1 vCPU, sans base de données

Ce que cela signifie : Cela détermine le nombre de réplicas nécessaires à un niveau de trafic, donc le coût d'exploitation de la passerelle. Pour Kubernetes, c'est le tableau à 1 vCPU qu'il faut lire : c'est l'efficacité par cœur qu'un pod obtient réellement.

Streaming, charges utiles, embeddings, bascule

4 vCPU, sans base de données. Les flux comptent 50 tokens espacés de 5 ms ; le test d'endurance envoie 200 flux par seconde de réponses d'environ 1,2 seconde pendant trois minutes.

Ce que cela signifie : Streaming, prompts longs, embeddings et bascule : c'est là qu'une charge de production passe son temps. Lisez les colonnes d'erreurs avant celles de débit : une requête échouée est une requête utilisateur échouée, pas une requête lente.

Le chiffre des charges de 64 Ko atteint le plafond du harnais : sans passerelle dans le chemin, la même charge atteint 3 711 req/s de corps de 64 Ko sur un cœur. La valeur de Wäg y est donc un minorant, pas un maximum.

Ce que ceci ne montre pas

Tout benchmark décrit un montage. Voici les limites de celui-ci.

• Les valeurs absolues dépendent de l'hôte. Les deux passerelles ont tourné sur la même machine avec des cœurs épinglés : la comparaison entre elles tient, mais attendez-vous à des valeurs absolues différentes sur votre propre matériel.
• Le harnais qui a piloté ces mesures n'est pas publié : vous ne pouvez donc pas les répéter commande par commande. La méthode ci-dessus est décrite assez précisément pour reconstruire un équivalent.
• LiteLLM publie presque chaque semaine. Ces chiffres ont été mesurés avec v1.104.2, la version stable actuelle. Dès qu'une version modifie le chemin de transmission, nous relançons la mesure et publions ce que nous trouvons.
• LiteLLM a été configuré d'après son guide de production, non par ses mainteneurs. Une meilleure configuration existe peut-être ; si vous en trouvez une, nous relancerons la mesure et republierons.
• Les deux passerelles ont tourné sur une seule machine avec des cœurs épinglés. Rien ici ne mesure le comportement à travers un réseau, sous l'ordonnancement de Kubernetes ou avec des voisins bruyants.