LLM locaux pour le code : Meilleures recommandations

Lisa Ernst · 06.10.2025 · Technologie · 5 min

Cet aperçu présente les LLM de code locaux actuels qui peuvent être exécutés sur votre propre matériel sans connexion au cloud. Les critères décisifs sont les benchmarks vérifiables, les exigences matérielles (VRAM/RAM) et les fonctionnalités telles que le Code Infilling. Nous faisons le point sur la situation et montrons quel modèle convient à quelle machine.

Quelle: Eigene Darstellung

Introduction & Fondamentaux

Par « local », nous entendons l'exécution complète d'un modèle sur votre propre matériel, par exemple via des runners comme Ollama ou directement via llama.cpp/vLLM. Ollama permet un Pull/Run facile, même avec des quantifications. Quantisierung (par exemple GGUF Q4_K_M) réduit significativement les besoins en mémoire, généralement avec une perte de qualité modérée.

Pour l'application pratique, les aspects suivants sont importants :

• Infilling/FIM: Remplissage ciblé des lacunes dans le code, pris en charge par des modèles comme StarCoder2 et CodeGemma.
• Fenêtre de contexte: La capacité d'inclure des fichiers ou des projets plus longs. Qwen2.5-Coder offre ici jusqu'à 128K tokens.
• Budget d'exécution: Des règles empiriques approximatives pour Ollama sont les suivantes : les modèles 7B nécessitent au moins 8 Go de RAM/VRAM, les modèles 13B 16 Go et les modèles 70B 64 Go.

La motivation pour l'exécution locale réside dans la confidentialité, la reproductibilité, le travail hors ligne et le contrôle des coûts. Des fabricants comme BigCode/Hugging Face, Alibaba/Qwen et DeepSeek accélèrent le rythme et la transparence. Des outils comme Ollama abaissent les barrières d'entrée grâce à un Pull/Run et une quantification (GGUF/4-bit) faciles. Des extensions comme Continue intègrent des modèles locaux directement dans VS Code/JetBrains.

État actuel & Modèles

Depuis 2024, il y a eu des développements significatifs dans le domaine des LLM de code locaux :

• StarCoder2 (3B/7B/15B): Ce modèle a introduit l'entraînement FIM sur The Stack v2 et une fenêtre de contexte de 16K. La variante 15B übertrifft modèles de taille similaire sur de nombreux benchmarks, comme décrit dans dieser Veröffentlichung décrit.
• Qwen2.5-Coder (0.5B–32B): Rapporte des résultats State-of-the-Art (SOTA) sur les benchmarks de code ouverts. La variante Instru ct 32B vise explicitement le « SOTA open source » sur EvalPlus, LiveCodeBench et BigCodeBench.
• DeepSeek-Coder-V2: Introduit une conception MoE. La version V2-Lite (16B, active 2.4B) offre un contexte de 128K et est conçue pour une utilisation locale. La plus grande variante V2 (236B, active 21B) mène de nombreux benchmarks de code, mais ne convient pas au matériel grand public.
• CodeGemma (2B/7B): Se concentre sur l'Infilling efficace. La variante 7B est bien documentée, y compris la configuration 4-bit et les tokens FIM.

Pour des comparaisons équitables, des benchmarks à faible contamination s'établissent comme LiveCodeBench (glissant) et EvalPlus (HumanEval+/MBPP+). Hugging Face fournit des informations supplémentaires à ce sujet.

Quelle: nutstudio.imyfone.com

Une représentation visuelle des meilleurs LLM locaux pour la programmation.

Application pratique & Intégration

Le choix du modèle approprié dépend fortement du matériel disponible et de la tâche prévue :

• Ordinateur portable/8–12 Go VRAM: Qwen2.5-Coder-7B ou CodeGemma-7B. Ces modèles offrent un Infilling puissant et une faible latence, surtout en mode 4-bit.
• 16 Go VRAM: StarCoder2-15B-Instruct ou DeepSeek-Coder-V2-Lite (16B aktiv 2.4B). Un bon équilibre entre qualité et vitesse.
• 24 Go+ VRAM: Qwen2.5-Coder-32B-Instruct. Ce modèle est ouvert, puissant et offre une grande fenêtre de contexte.
• CPU-only/petit iGPU: Gemma/CodeGemma ou plus petit Qwen-Coder Varianten. Google démontre explicitement l'exécution CPU avec Ollama.

Pour la pratique, l'intégration IDE est recommandée avec Continue (VS Code/JetBrains) en combinaison avec un Ollama-Server. Il est conseillé d'utiliser activement l'Infilling au lieu de simplement « chatter », et d'effectuer des comparaisons A/B avec EvalPlus - ou LiveCodeBench-Problemen pour votre propre domaine.

Analyse & Évaluation

Les fabricants mettent souvent en avant le « SOTA ouvert » (Qwen) ou le « meilleur de sa catégorie » (StarCoder2), ce qui est partiellement étayé par des benchmarks, mais inclut également des aspects marketing. Il est donc conseillé de jeter un œil à mehrere Quellen . La communauté rapporte des expériences mitigées : alors que certains célèbrent les configurations locales, d'autres signalent une qualité fluctuante dans les tâches d'édition, souvent conditionnée par le Prompting, les contextes et l'intégration de l'éditeur, comme hier discuté.

Vérification des faits : Preuves vs. Allégations

• Prouvé :
  • 7B/13B/70B les directives RAM approximatives chez Ollama sont largement confirmées dans la pratique.
  • StarCoder2 offre un entraînement FIM, un contexte 16K et des résultats 15B solides par rapport à des modèles de taille similaire (Quelle).
  • Qwen2.5-Coder 32B-Instruct revendique le SOTA sur les benchmarks de code ouverts et couvre des tailles de 0.5B à 32B, jusqu'à 128K de contexte.
  • DeepSeek-Coder-V2-Lite: MoE avec 16B (actif 2.4B), 128K de contexte. La grande variante V2 montre des valeurs très élevées sur les benchmarks de code, mais n'est pas destinée au matériel grand public.
  • CodeGemma 7B: Les tokens FIM sont documentés, l'exécution 4-bit est possible avec environ 9 Go.
• Non clair/Nuancé :
  • « 1 Go de VRAM par milliard de paramètres » est une règle empirique de la communauté qui varie fortement en fonction de la quantification, de la longueur du contexte et de l'Offload. Les documentations des modèles/runners sont plus précises ici ( Qwen, Ollama).
• Faux/Trompeur :
  • « La quantification rend les modèles inutilisables. » Dans de nombreux workflows de codage, le 4-bit est un bon compromis. Les pertes de qualité dépendent du modèle, de la tâche et de la longueur du contexte ( CodeGemma, Qwen).

Quelle: pieces.app

Un diagramme comparant les performances de différents modèles LLM dans le domaine du codage.

Conclusion & Perspectives

Pour la recherche du « meilleur LLM local pour le codage », il existe aujourd'hui de véritables options de choix. Pour 24 Go+ de VRAM, Qwen2.5-Coder-32B-Instruct est la première adresse parmi les modèles ouverts. Sur 16 Go de VRAM, StarCoder2-15B-Instruct offre un Infilling très complet et des performances stables. Dans le segment 7B, Qwen2.5-Coder-7B et CodeGemma-7B sont des choix pragmatiques : rapides, économes et bien documentés. DeepSeek-Coder-V2-Lite marque des points avec l'efficacité MoE et un grand contexte, à condition qu'il soit bien quantifié et intégré.

Analyse de la valeur ajoutée

Pondération : Performance 60 %, Adéquation aux ressources locales 20 %, Fonctionnalités IDE/FIM+Contexte 10 %, Licence 10 %. Les estimations de performance sont basées sur les benchmarks/documents de modèle cités.

• Qwen2.5-Coder-32B-Instruct: 8.4/10 – Performance ouverte la plus élevée, grande fenêtre de contexte ; nécessite plus de VRAM, mais puissant pour les tâches complexes.
• Qwen2.5-Coder-14B-Instruct: 8.4/10 – Très bon rapport qualité/prix, largement utilisable, licence Apache-2.0.
• DeepSeek-Coder-V2-Lite (16B, aktiv 2.4B): 8.0/10 – MoE efficace, contexte 128K ; utilisable fortement quantifié.
• StarCoder2-15B-Instruct: 7.9/10 – Puissant en FIM, contexte 16K, entraînement transparent ; robuste pour l'édition/complétion.
• Qwen2.5-Coder-7B-Instruct: 8.0/10 – Adapté aux mobiles/ordinateurs portables, bonne qualité avec faible latence ; idéal pour les éditions en ligne.
• CodeGemma-7B: 7.5/10 – Léger, FIM très correct, bonne documentation/configurations ; puissant pour l'autocomplétion rapide.

Quiconque souhaite commencer aujourd'hui installe Ollama, tire Qwen2.5-Coder-7B ou StarCoder2-15B, active Continue dans VS Code et utilise consciemment l'Infilling. On en profite immédiatement, sans se lier à un fournisseur de cloud.

Questions ouvertes

La robustesse de la qualité du code à travers différents langages de programmation et frameworks reste une question ouverte. Les Rolling Benchmarks abordent les fuites de données, mais ne sont pas une garantie complète ( LiveCodeBench, Hugging Face). Quelles métriques sont le plus fortement corrélées avec la productivité réelle dans l'éditeur (Édition/Refactoring/Contexte de dépôt) ? Aider publie des benchmarks d'édition/refactoring, mais une standardisation est encore en suspens. Pour le matériel local, des questions subsistent concernant la configuration optimale de Quant/Offload, ici, les guides des runners et les microbenchmarks personnels sont utiles ( Qwen, Ollama).

Quelle: openxcell.com

Une représentation de l'intégration des LLM dans le processus de développement.