Repartage — contenu de Philippe ANEL
⚡ Près de trois fois plus rapide que vLLM sur le premier token. Près de deux fois plus que llama.cpp en CUDA. Avec un moteur qui n'utilise pas CUDA.
RTX 4080, petit modèle, prompt court, une requête à la fois : c'est mesuré, publié, rejouable chez vous.
🧠 Herbert, mon moteur d'inférence, écrit ses noyaux GPU au démarrage, pour la forme exacte du modèle et pour la carte qu'il a devant lui. Du SPIR-V pour Vulkan, sans shader compilé à l'avance ni bibliothèque du constructeur.
📊 Les chiffres. Qwen3.5-0.8B, prompt court : premier token en 6,5 ms pour Herbert, 12 pour llama.cpp CUDA, 19 pour vLLM. vLLM est fait pour servir beaucoup de requêtes à la fois : sur 4 000 tokens, l'écart avec lui disparaît ; sur le 4B, vLLM répond 3,7 % plus tôt.
⚖️ Les autres cas. Au prefill du 4B en f16 : égalité avec llama.cpp CUDA à son meilleur réglage. Sur l'Arc 140V d'un portable Intel, en f16 : Herbert est plus lent au prefill, jusqu'à ×0,57. Au décodage, il reste devant llama.cpp sur toutes les cartes.
Pourquoi il gagne ? J'ai désactivé ses réglages un par un. Sur les prompts moyens et longs, c'est surtout le découpage du prompt en grands blocs. Sur un prompt très court, ces réglages n'expliquent qu'une petite partie de l'avance : le reste vient des noyaux eux-mêmes.
Dans l'article : cinq GPU de trois constructeurs ; deux formats de poids, toujours comparés à format égal ; mes prédictions, écrites avant les mesures ; ce qui fait l'avance d'Herbert, mesuré en désactivant ses réglages un par un.
📦 Le moteur en bf16 et en f16, les scripts et les données brutes sont en ligne, en trois dépôts sous licence MIT. Si un chiffre vous semble faux, vous avez de quoi le vérifier.
👉 L'article complet, sur mon site : https://lnkd.in/eXe5CuhQ
Si ça vous parle, un partage ou un commentaire m'aident vraiment à faire connaître ce travail 🙏
On descend d'un cran.
Sources LinkedIn
- Profil : Pierre Jean Duvivier dit Sage (LinkedIn)
- Auteur partagé : Philippe ANEL (LinkedIn)
Laisser un commentaire