Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
Vous avez probablement déjà connu la déception d'déployer un modèle à haute précision en vous fiant uniquement aux scores des benchmarks. Dès que la capacité VRAM est dépassée, une partie des poids est rejetée vers la RAM système, et le swapping sur le bus PCIe fait chuter la vitesse de génération à moins d'un token par seconde. Sur une configuration RTX 4090, l'utilisation du format GGUF Q4_K_M consomme 18,3 Go de mémoire pour les poids et un total de 22,1 Go de VRAM avec un contexte de 8K pour tourner enfin de manière stable.
Le total de la mémoire doit être calculé en additionnant la mémoire des poids, le cache KV et les surcharges du framework pour obtenir un résultat correct. Les poids s'obtiennent en multipliant le nombre de paramètres par les bits effectifs de quantification, puis en divisant par 8, tandis que le format EXL2 4.0 bpw consomme 0,50 octet par paramètre. En ajoutant à cela le cache KV qui augmente selon la longueur du contexte et une surcharge de framework d'au moins 1,5 Go, il faut disposer d'une marge d'au moins 2 Go pour éviter les erreurs OOM.
La première étape consiste à vérifier la capacité VRAM de votre GPU et à calculer les taux d'occupation des poids et du cache KV. La deuxième étape consiste à télécharger les fichiers du modèle au format GGUF Q4_K_M ou EXL2 4.0 bpw et à les intégrer dans votre environnement local. La troisième étape consiste à vérifier directement en 30 minutes si la vitesse de génération des tokens se maintient à plus de 30 tokens par seconde lors de l'insertion d'un prompt de 8K ou plus. Ce processus vous permet de choisir un modèle qui tourne réellement sur votre matériel, sans vous laisser aveugler par les chiffres des benchmarks.
Lorsqu'on demande à des modèles open source de moins de 30B de générer des structures JSON complexes, ils commettent des erreurs en oubliant les crochets ou en insérant des balises Markdown. Si tout le pipeline backend s'arrête parce que le modèle a fourni une réponse aberrante, il est impossible de dormir la nuit. Il faut coder en amont des sécurités pour forcer la syntaxe dès l'étape de génération des tokens et intercepter les erreurs de parsing au niveau de l'application.
Sous l'environnement llama.cpp, il faut appliquer la grammaire GBNF et utiliser Guided Decoding dans vLLM pour empêcher totalement la génération de tokens non conformes au schéma. En associant la bibliothèque Pydantic pour lier la sortie du modèle au modèle de données, et en cas de JSONDecodeError, on réinjecte le contenu erroné dans l'historique de conversation pour créer une boucle de rétroaction qui l'incite à se corriger lui-même. Pour éviter les boucles infinies, il est indispensable de limiter les tentatives à 3, et si cela échoue toujours, d'utiliser une architecture Fallback renvoyant un objet de mode sécurisé statique.
La première étape consiste à utiliser Pydantic pour créer une classe de schéma de validation intégrant les champs obligatoires et les types de données. La deuxième étape consiste à combiner des expressions régulières et des blocs de gestion des exceptions pour extraire uniquement la véritable chaîne JSON de la réponse brute du modèle et intercepter les erreurs de parsing en temps réel. La troisième étape consiste à intégrer une logique de nouvelle tentative avec la bibliothèque tenacity, et en cas d'échec persistant, à renvoyer des données Fallback statiques pour empêcher l'interruption du service. L'implémentation de cette structure permet de porter le taux de conformité du schéma d'appel d'outils à plus de 95 %.
Lors de la génération automatique de code d'interface web ou de l'extraction de données à partir d'un fichier de transcription massif, les modèles de moins de 30B révèlent leur limite en omettant tout le contenu intermédiaire. Il est nécessaire de contraindre le modèle dans le prompt système pour l'empêcher d'ajouter des excuses inutiles ou des commentaires Markdown superflus, et de faire en sorte qu'il produise des résultats strictement conformes à la structure souhaitée.
Il faut intégrer le schéma de sortie et les contraintes dans le système de prompt pour le faire travailler comme un compilateur. Les documents de plusieurs dizaines de pages doivent être découpés en unités de 2 000 tokens en fonction de la longueur de contexte de sécurité maximale du modèle, et pour éviter la perte de données aux frontières, les 200 derniers tokens du chunk précédent doivent être superposés au début du chunk suivant. Un résultat exploitable n'est obtenu qu'après une phase de type Map pour extraire individuellement les données de chaque chunk, suivie d'une phase de type Reduce pour les fusionner en une seule structure.
La première étape consiste à créer un modèle de prompt système pour bloquer l'affichage de salutations et y intégrer des contraintes spécifiques telles que l'utilisation de classes Tailwind CSS. La deuxième étape consiste à découper le document d'entrée selon une approche de fenêtre glissante incluant une zone de chevauchement de 10 %. La troisième étape consiste à concevoir une LLMProviderInterface appliquant le Strategy Pattern pour achever une couche d'abstraction permettant de remplacer facilement le moteur de modèle en cas de besoin. L'application de ce processus permet d'économiser plus de 5 heures de temps de débogage superflu par semaine.
