Définir le résultat utile avant de chercher du débit
En interaction, mesurez l’attente du premier token et celle de la réponse complète. Pour un corpus hors ligne, mesurez le temps nécessaire à obtenir toutes les sorties attendues. Dans les deux cas, fixez la règle d’acceptation : exactitude sur des réponses connues, qualité d’un classement ou extraction de champs vérifiée. Un JSON syntaxiquement valide peut encore contenir une réponse fausse.
Séparez l’attente en file, le traitement et le trajet complet observé par votre client lorsque vos outils le permettent. Une mesure interne au moteur n’a pas les mêmes bornes que celle de l’application. La documentation des métriques vLLM distingue notamment attente, premier token et durée totale : conservez cette distinction dans vos relevés, quel que soit le moteur retenu.
Sources techniques : vLLM — métriques de requêtes et de latence
Transformer vos requêtes en critères de choix
Préparez des entrées courtes, habituelles et longues avec des identifiants stables. Conservez modèle, tokenizer, gabarit de conversation et paramètres de génération. Comptez les tokens réellement transmis, y compris l’historique et les documents ajoutés par l’application. Inscrivez séparément batch demandé, concurrence envoyée et requêtes effectivement traitées simultanément : ce ne sont pas nécessairement les mêmes nombres.
| Entrée à fixer | Mesure et unité | Conséquence pour le choix |
|---|---|---|
| Prompt complet et limite de sortie | Tokens d’entrée et de sortie par requête | Vérifier les longs cas et les réponses coupées à la limite |
| Requêtes simultanées et rythme d’arrivée | Requêtes actives, en attente et terminées | Déterminer la charge soutenable avec le délai exigé |
| Précision, quantification et cache | Pic mémoire par GPU, en octets ou Gio | Écarter les réglages qui dépassent la mémoire sur la charge prévue |
| Règle de qualité et références | Sorties acceptées / sorties attendues ; métrique métier | Comparer seulement les variantes qui respectent le même critère |
| Périmètre du chronomètre | Premier token, réponse complète ou corpus : secondes | Comparer des durées ayant les mêmes bornes |
| Calendrier jusqu’aux fichiers récupérés | Fenêtre totale, en heures ou jours | Choisir ensuite un forfait de 3, 7 ou 30 jours |
Mesurer la mémoire avec contexte et concurrence
Pour un modèle autorégressif qui génère token par token, le cache KV conserve des états d’attention. Sa taille dépend du modèle et des tokens conservés. Un cache dynamique peut croître pendant la génération ; un cache statique réserve une taille maximale. Certaines couches à fenêtre glissante limitent cette croissance. Testez donc les longueurs et la concurrence prévues avec la stratégie réellement utilisée.
La quantification des poids et celle du cache sont deux choix distincts. Par exemple, bitsandbytes remplace certaines couches linéaires par des versions quantifiées ; cela ne décrit pas toutes les allocations de votre exécution. Après un changement de précision, vérifiez à nouveau mémoire et qualité au lieu de supposer que l’ensemble du pic diminue dans la même proportion.
Avec PyTorch, relevez séparément le pic des tenseurs alloués et celui de la mémoire réservée par l’allocateur. Ne les additionnez pas. Indiquez le GPU mesuré et l’unité : 1 Gio correspond à 2³⁰ octets. Ces compteurs ne représentent pas nécessairement toute l’occupation du périphérique. Le dossier mémoire détaille leurs limites.
Sources techniques : Hugging Face Transformers 5.17 — stratégies de cache KV · Hugging Face Transformers 5.17 — quantification bitsandbytes · PyTorch 2.14 — gestion et compteurs de mémoire CUDA
Un essai mesurable sur 300 documents
Exemple à réaliser avec votre corpus autorisé : extraire date, montant et catégorie de 300 documents. Relisez les valeurs attendues, précisez le traitement des champs absents et fixez le seuil d’acceptation avant l’essai. Le nombre de documents décrit le protocole ; aucun temps, score ou débit n’est présumé.
- Figez les 300 identifiants, la révision du modèle, les prompts, les limites de tokens et la règle de parsing. Gardez les documents longs identifiables dans le bilan.
- Exécutez une référence avec une requête à la fois. Séparez chargement, échauffement et mesure ; conservez les prédictions et les erreurs par document.
- Augmentez ensuite un seul paramètre : batch pour un traitement groupé, ou concurrence pour un moteur de requêtes. Gardez les mêmes entrées et critères de qualité.
- Pour chaque passage, relevez durée, pic mémoire, nombre d’identifiants retrouvés sans doublon et sorties acceptées. Répétez les mesures et conservez les valeurs brutes avec leur dispersion.
- Si une variante échoue, consignez le motif : mémoire, troncature, format ou qualité. Un batch réduit ou une reprise crée une décision à documenter, pas un échec à effacer.
Sources techniques : IteraGPU — protocole détaillé de comparaison à qualité équivalente
Utiliser les ressources IteraGPU Lab v1 au bon périmètre
Le notebook et son script compagnon proposent un calcul de poids et une mesure sur un petit réseau synthétique. Leur code de mesure a été exécuté sur une RTX 5070 locale avec PyTorch 2.11.0, sur une petite configuration en float32. Cet essai vérifie ce cas d’exécution ; il ne mesure ni un LLM, ni un cache KV, ni les GPU du catalogue sur vos requêtes.
Utilisez le notebook pour comprendre les compteurs, puis mesurez votre charge réelle avec son environnement. Le protocole de qualité et le tableau brut servent à préparer la comparaison. Les sorties du notebook distribué et les lignes de résultats du CSV restent vierges ; la procédure n’installe aucun modèle ni pilote. Lisez les prérequis du README avant l’exécution.
- Notebook de mémoire IteraGPU Lab v1
Calculs et petit réseau synthétique pour comprendre la mesure mémoire.
- Protocole de qualité à compléter
Entrées fixes, acceptation des sorties et comparaison des essais.
- Tableau brut vierge
Une ligne par passage réel, avec paramètres, mesures et verdict.
- Prérequis et limites de IteraGPU Lab v1
Instructions et portée précise de l’essai local déjà réalisé.
Passer des mesures à une offre
Votre fiche de choix doit réunir environnement compatible, mémoire par carte, contexte, concurrence, qualité atteinte et délais mesurés. Comparez les configurations qui répondent à ces critères, puis les forfaits de 3, 7 et 30 jours selon le calendrier complet : préparation, traitement, évaluation, reprises et export. Le calculateur du dossier benchmarks utilise le forfait entier et des corpus utiles réellement validés.
Conservez cette fiche et les versions du code dans votre carnet. Vous choisissez vos logiciels et vos traitements ; IteraGPU ne procède pas à une inspection du contenu de vos fichiers, prompts ou calculs. Un choix d’environnement à la commande exprime votre besoin de préparation : il ne constitue pas une preuve que votre modèle a déjà été installé ou testé.
Questions pratiques
24 Go suffisent-ils pour mon modèle d’inférence ?
La capacité de 24 Go ne suffit pas à répondre sans connaître le modèle et la charge. Vérifiez ensemble poids, allocations d’exécution, contexte et requêtes simultanées. La configuration doit terminer les cas longs avec la qualité demandée ; une taille de fichier ou une estimation des poids seule ne le démontre pas.
Quel débit faut-il comparer pour un corpus hors ligne ?
Comparez d’abord la durée nécessaire pour terminer et évaluer le même corpus. Si vous publiez un débit, donnez le nombre de sorties utiles acceptées, le temps retenu et les erreurs. Un débit en tokens par seconde sans longueur de réponse ni contrôle qualité ne suffit pas à départager deux configurations.
Un dépassement mémoire impose-t-il de changer de GPU ?
Un dépassement mémoire demande d’abord d’identifier le réglage et l’entrée qui l’ont provoqué. Vous pouvez examiner batch, concurrence, longueur ou précision, en conservant l’objectif du projet. Toute réduction qui change les documents traités ou les réponses attendues impose une nouvelle vérification qualité ; davantage de mémoire peut être nécessaire si ces contraintes doivent être conservées.
Le notebook fourni valide-t-il mon application d’inférence ?
Le notebook fourni ne valide pas votre application : il mesure un petit réseau synthétique et explique les compteurs mémoire. L’essai local documenté porte seulement sur ce cas. Votre application doit être évaluée avec son modèle, ses entrées, son environnement et ses propres critères d’acceptation avant toute conclusion de capacité ou de performance.