Vous pouvez exécuter un modèle de langage performant sur votre ordinateur portable dès maintenant. Pas un modèle basique — un vrai. Llama 3.1 8B fonctionne avec 16 Go de RAM. Mistral 7B fonctionne avec moins. La configuration prend une heure. L’écart de performance entre les appels locaux et les API cloud est plus petit que vous ne le pensez.
La plupart des développeurs supposent que les LLM locaux sont soit lents, limités, soit nécessitent un GPU qu’ils n’ont pas. Cette hypothèse vous coûte de l’argent chaque mois. Elle vous coûte également en latence, en préoccupations de confidentialité et en capacité de personnaliser le comportement sans attendre l’approbation d’un fournisseur d’API.
Voici ce qui fonctionne réellement, et ce qui ne fonctionne pas.
Choisir le Bon Modèle pour Votre Matériel
La taille du modèle et votre RAM disponible ne sont pas des variables indépendantes. La mémoire GPU non plus, si vous en avez une.
Une règle empirique qui tient dans la pratique : un modèle a besoin d’environ 2 octets de VRAM par paramètre lorsqu’il est chargé en pleine précision, et d’environ 0,5 octet par paramètre en quantification 4 bits. Cela signifie que Llama 3.1 8B (8 milliards de paramètres) a besoin d’environ 4 Go de VRAM sous forme 4 bits, ou 16 Go en pleine précision.
Pour 16 Go de RAM totale (sans GPU dédié) : Mistral 7B ou Llama 3.1 8B fonctionnent de manière fiable. Les deux tournent à des vitesses utilisables avec quantification. Phi-3 5B est excessif en termes de capacités — il est bon si vous avez besoin d’une empreinte mémoire inférieure à 4 Go.
Pour 32 Go de RAM ou plus, ou tout GPU avec 8 Go de VRAM ou plus : Llama 3.1 70B devient viable. C’est là que vous commencez à voir des améliorations significatives de qualité par rapport aux modèles plus petits.
Pour les machines uniquement équipées de CPU : Attendez-vous à une inférence plus lente, pas à une inférence inutilisable. Un CPU moderne à 8 cœurs exécutant Mistral 7B en quantification 4 bits génère du texte à environ 5–10 tokens par seconde. C’est assez lent pour être remarqué, mais pas assez lent pour abandonner complètement l’approche.
Installation et Exécution avec Ollama
Ollama est le chemin le plus rapide pour passer de zéro à un modèle en cours d’exécution. Téléchargez-le, exécutez trois commandes, terminé.
# Installez Ollama depuis ollama.ai, puis :
ollama pull mistral:7b
ollama run mistral:7bC’est tout. Vous avez maintenant un modèle en cours d’exécution sur localhost:11434. Le premier pull télécharge environ 4–5 Go (pour Mistral en forme quantifiée). Les exécutions suivantes se chargent instantanément depuis le disque.
Si vous souhaitez l’appeler par programme depuis Python ou Node :
import requests
import json
prompt = "Explain how transformer attention works in one paragraph."
response = requests.post(
"http://localhost:11434/api/generate",
json={
"model": "mistral:7b",
"prompt": prompt,
"stream": False
}
)
result = json.loads(response.text)
print(result["response"])
Ceci est fonctionnellement identique à un appel API OpenAI en termes de structure — vous envoyez du texte, vous recevez du texte en retour. La différence est que le modèle s’exécute sur votre machine et ne coûte rien par token.
Ollama gère la quantification du modèle automatiquement. Par défaut, il utilise la quantification 4 bits, ce qui réduit l’utilisation de la mémoire d’environ 75 % avec une perte de qualité minimale. Vous pouvez forcer la pleine précision avec ollama pull mistral:fp16 si vous avez la VRAM, mais vous n’avez généralement pas besoin de le faire.
Quand les Modèles Locaux Sous-performent (et Comment le Savoir)
Les modèles locaux sont bons. Ils ne remplacent pas directement Claude ou GPT-4o pour toutes les tâches.
Mistral 7B fonctionne bien pour : la génération de code, la résumé, la classification, l’extraction structurée. Il échoue visiblement sur : le raisonnement à long contexte (tout ce qui nécessite une pensée cohérente sur plus de 20 paragraphes), la logique en plusieurs étapes où les étapes antérieures s’accumulent, et les tâches nécessitant des connaissances du monde explicites publiées après la date d’entraînement du modèle.
La solution pratique : benchmarkez votre cas d’utilisation spécifique. Ne supposez pas l’échec. J’ai testé Mistral 7B sur une tâche de classification de clients et il a égalé la précision de GPT-3.5 pour 1/100ème du coût. Sur une autre tâche — extraire un sentiment nuancé de documents financiers — il a obtenu 15 % de moins. Le contexte est important.
Vous saurez quand un modèle rencontre des difficultés : sortie incohérente, phrases répétées, changements de sujet soudains, ou raisonnement correct qui contredit sa propre déclaration antérieure. Ce n’est pas toujours subtil. Quand vous les remarquez, passez à la variante 70B ou ajoutez plus de contexte via RAG.
Compromis de la Quantification : Vitesse vs. Précision
La quantification compresse un modèle en représentant les nombres avec moins de bits. La quantification 4 bits utilise 4 bits par paramètre au lieu de 32, réduisant le modèle d’environ 8 fois.
La perte de qualité est réelle mais pas catastrophique pour la plupart des tâches. Llama 3.1 8B en quantification 4 bits obtient environ 95–98 % des performances en pleine précision sur des benchmarks standards (MMLU, HumanEval). Cet écart s’élargit légèrement sur les tâches de langage nuancé.
Le gain de vitesse est substantiel : la quantification 4 bits ajoute souvent une inférence 20–30 % plus rapide sur CPU car la bande passante mémoire devient moins un goulot d’étranglement. Sur GPU, la différence est plus faible mais toujours mesurable.
Commencez avec le 4 bits (par défaut d’Ollama). Si la qualité de la sortie est décevante, vous pouvez toujours télécharger une variante de plus haute précision et réessayer — les modèles se chargent en quelques secondes une fois téléchargés.
Créer un Flux de Travail LLM Local : Exemple Pratique
Disons que vous traitez des tickets de support et que vous extrayez des données structurées (priorité, catégorie, urgence).
import requests
import json
def classify_ticket(ticket_text):
prompt = f"""Classify this support ticket and respond ONLY with JSON.
Ticket: {ticket_text}
Respond with this format:
{{
"priority": "high" | "medium" | "low",
"category": "billing" | "technical" | "account",
"urgency_minutes": number,
"summary": "one-sentence summary"
}}"""
response = requests.post(
"http://localhost:11434/api/generate",
json={"model": "mistral:7b", "prompt": prompt, "stream": False}
)
result = json.loads(response.text)["response"]
return json.loads(result) # Parse the JSON from model output
ticket = "Customer says login stopped working after password reset. Need access by EOD."
print(classify_ticket(ticket))
Cela fonctionne. Mistral 7B produit de manière fiable du JSON valide pour les tâches d’extraction structurée — mieux que ce que l’on pourrait attendre d’un modèle 7B. La latence sur un CPU moderne est de 2 à 4 secondes de bout en bout. C’est plus lent qu’un appel API cloud (qui pourrait être de 0,5 à 1 seconde), mais vous l’exécutez hors ligne et ne payez rien par inférence.
Une Chose à Faire Aujourd’hui : Tester Votre Plafond Matériel
Téléchargez Ollama. Exécutez ollama pull mistral:7b. Exécutez le modèle. Vérifiez l’utilisation de la RAM système et du CPU pendant qu’il s’exécute — top sur Mac/Linux ou le Gestionnaire des tâches sur Windows.
Vous verrez exactement quelle marge il vous reste avant d’atteindre la limite. Ce chiffre vous indique si vous pouvez exécuter confortablement des modèles 7B, si vous devez passer à des modèles plus petits, ou si un modèle 70B est à votre portée. Aucune hypothèse nécessaire. Juste des données.
