Commencez par le matériel, pas par l’engouement autour des modèles
Le moyen le plus rapide de choisir un Local LLM est de partir de la machine que vous possédez déjà. La popularité du modèle compte, mais un modèle qui ne peut pas se charger ou qui fonctionne à une vitesse inutilisable n’est pas utile. Les premières données à prendre en compte sont la VRAM, la RAM système, le système d’exploitation, le fait que la mémoire soit unifiée ou non, et votre volonté d’utiliser ou non le CPU offload. Ce n’est qu’après cela que vous devriez comparer les familles de modèles.
Un bon flux de recommandation de Local LLM sépare trois questions : peut-il se charger, sera-t-il utilisable, et est-il adapté à la tâche. Le chargement dépend des poids, de la quantization, du KV cache et de la surcharge du runtime. L’utilisabilité dépend de la vitesse et de la stabilité. L’adéquation à la tâche dépend du fait que le modèle soit optimisé pour le code, le chat général, les mathématiques, la vision ou le travail en contexte long.
Choisissez le cas d’usage avant de choisir le plus grand modèle
Des tâches différentes favorisent des modèles différents. Une tâche de codage nécessite un entraînement au code, une compréhension des dépôts, un bon suivi des instructions et une mise en forme stable. Une tâche de rédaction nécessite le contrôle du ton et la cohérence en format long. Une tâche de vision nécessite une architecture multimodale et un encodeur d’images. Une tâche de mathématiques ou de raisonnement peut nécessiter une famille de modèles optimisée pour la résolution de problèmes étape par étape.
C’est pourquoi le même matériel peut produire des recommandations différentes lorsque l’utilisateur passe de Général à Codage ou Vision. Le site ne devrait pas classer aveuglément selon les téléchargements ou le nombre de paramètres. Il devrait d’abord filtrer les modèles adaptés au matériel, puis classer les options restantes selon le cas d’usage et les préférences.
Comprendre le rôle de la quantization
La plupart des utilisateurs locaux exécutent des modèles quantifiés plutôt que des poids en pleine précision. La quantization réduit l’utilisation de la mémoire et rend les modèles pratiques sur du matériel grand public. Q4 est souvent l’option axée d’abord sur la compatibilité, Q5 et Q6 peuvent améliorer la qualité avec un coût mémoire plus élevé, et Q8 est plus proche de la qualité complète mais beaucoup plus lourd. Le bon choix dépend de la marge restante après les poids et le KV cache.
L’expression "que puis-je exécuter" n’a donc pas une seule réponse par modèle. Un modèle peut être exécutable en Q4 mais pas en Q8, utilisable avec un contexte 4K mais pas 32K, ou correct en GPU complet mais lent avec offload. Une page de recommandation utile devrait afficher la quantization sélectionnée et le détail de la mémoire, pas seulement le nom du modèle.
Les configurations Mac, Windows, Linux et CPU-only diffèrent
Les utilisateurs Windows et Linux avec des GPU discrets pensent généralement d’abord à la VRAM. Les utilisateurs Apple Silicon pensent en mémoire unifiée, car le GPU et le CPU partagent le même pool mémoire. Les utilisateurs CPU-only doivent être encore plus conservateurs, car la mémoire système peut être importante mais la vitesse en tokens peut être faible. Le même chiffre de 32GB signifie des choses différentes selon ces configurations.
Un outil devrait refléter cette différence. Sur Mac, il devrait réserver de la mémoire pour macOS et les applications. Sur les GPU discrets, il devrait réserver de la VRAM pour l’affichage, la surcharge du framework et le KV cache. Sur les machines CPU-only, il devrait recommander de petits modèles et définir des attentes en matière de vitesse plutôt que de prétendre que la RAM système résout tout à elle seule.
Un flux de décision pratique
D’abord, saisissez votre VRAM ou votre mémoire unifiée. Ensuite, choisissez votre système d’exploitation. Troisièmement, choisissez le cas d’usage. Quatrièmement, choisissez la préférence : qualité, équilibre de compatibilité ou marge de contexte. Puis examinez uniquement les modèles compatibles. Si les résultats sont trop petits, augmentez la mémoire ou acceptez l’offload. Si les résultats sont trop lents, privilégiez des modèles plus petits entièrement sur GPU.
Cette approche évite aux utilisateurs de copier des recommandations de modèles aléatoires depuis les réseaux sociaux. Une recommandation qui fonctionne sur un GPU 24GB peut être mauvaise pour un ordinateur portable 8GB. Un modèle excellent pour le codage peut être inutile pour une rédaction occasionnelle. Local LLM devrait transformer ces compromis en une liste classée claire avec des liens Hugging Face vers les pages réelles des modèles.
FAQ
Puis-je exécuter un Local LLM sans GPU ? Oui, mais généralement avec des modèles plus petits et une vitesse plus faible. CPU-only est idéal pour les tests, les notes sensibles à la confidentialité ou les tâches hors ligne légères.
Devrais-je toujours choisir le plus grand modèle qui tient en mémoire ? Non. Un modèle plus petit qui tient entièrement sur GPU peut être plus rapide et plus agréable qu’un modèle plus grand qui tient à peine.
Pourquoi les recommandations changent-elles avec le temps ? Les fichiers de modèles Hugging Face, les téléchargements, les quantizations et les publications de la communauté changent souvent, donc les données de modèles mises en cache devraient être actualisées régulièrement.