Exécuter des modèles de langage sur sa propre machine : puces Apple Silicon, quantification et ce qui tient vraiment en mémoire

Il y a un moment précis où les modèles de langue locaux cessent d’être une curiosité pour devenir vraiment utiles. Ce moment arrive quand vous réalisez qu’un modèle qui tourne sur votre portable, sans clé API, sans limite de débit et sans facturation au token, est assez bon pour une tâche que vous confiiez auparavant à un modèle frontalier. Ce seuil a beaucoup évolué. Cet article est le complément matériel et dimensionnement de Local AI in 2026, qui traitait des environnements d’exécution eux-mêmes. Une grande partie du travail que les développeurs font réellement avec les modèles de langue: résumer, extraire, classer, reformuler et répondre à des questions sur un document sous leurs yeux: s’exécute désormais parfaitement sur le matériel que vous possédez déjà.

Pourquoi la bande passante mémoire est déterminante

Générer un token avec un transformer nécessite de lire pratiquement chaque poids du modèle. C’est l’opération fondamentale, répétée pour chaque token produit. Si le modèle occupe 8 Go en mémoire et que votre matériel peut transférer 400 Go par seconde, le plafond arithmétique est d’environ 50 tokens par seconde, quelle que soit la vitesse du processeur, car celui-ci passe l’essentiel de son temps à attendre l’arrivée des poids.

Ce seul fait explique la plupart des bizarreries apparentes des performances d’inférence locale. Il explique pourquoi Apple Silicon s’en sort si bien malgré des chiffres de calcul brut modestes : la mémoire unifiée offre une bande passante élevée vers un large espace. Il explique pourquoi un GPU grand public avec une mémoire rapide mais petite surclasse une carte de station de travail dotée d’une mémoire plus lente. Il explique aussi pourquoi la quantification produit des accélérations spectaculaires : diviser par deux le nombre d’octets par poids divise par deux les données à déplacer, et la vitesse double à peu près.

Lorsque vous choisissez du matériel pour l’inférence locale, la bande passante mémoire et la capacité mémoire sont les deux chiffres à comparer. Tout le reste est secondaire.

Ce qui tient dans la mémoire dont vous disposez

Le dimensionnement est un calcul simple. Prenez le nombre de paramètres en milliards, multipliez par le nombre d’octets par paramètre induit par la quantification, et ajoutez environ 20 pour cent pour le cache clé-valeur et la surcharge d’exécution. En 4 bits, cela représente environ 0,55 octet par paramètre en pratique, une fois pris en compte les métadonnées que les formats de quantification transportent.

Notez que la fenêtre de contexte n’est pas gratuite. Les contextes longs font croître le cache clé-valeur de façon substantielle, et un contexte de 32k sur un modèle de taille moyenne peut ajouter plusieurs gigaoctets à lui seul. Si un modèle se charge correctement puis échoue au milieu d’un long document, le cache en est presque toujours la cause.

Quel est le coût en qualité de la quantification

La quantification réduit la précision des poids. La précision de référence habituelle est le 16 bits, et les variantes 8, 5 et 4 bits échangent de la précision contre de la mémoire et de la vitesse. Si le 4 bits est devenu le choix par défaut, c’est parce que la baisse de qualité est faible et inégalement répartie : elle touche à peine les tâches langagières simples et se manifeste surtout dans le raisonnement en plusieurs étapes, l’arithmétique et la génération de code.

Le conseil pratique est d’exécuter le plus grand nombre de paramètres qui tient en 4 bits plutôt qu’un modèle plus petit en précision supérieure. Un modèle 14B en 4 bits surpassera généralement un modèle 8B en 8 bits bien qu’ils occupent une mémoire similaire, car le nombre de paramètres apporte plus de capacité que la précision dans la plage qui importe.

Démarrage sans cérémonie

L’outillage est devenu vraiment agréable. Sur Apple Silicon, les frameworks basés sur Metal offrent une accélération GPU native sans configuration. Sous Linux et Windows avec une carte NVIDIA, les mêmes runtimes fonctionnent via CUDA. Dans les deux cas, vous pouvez générer des tokens en quelques minutes.

# Pull a quantised model and talk to it. Most local runtimes expose an
# OpenAI compatible endpoint, which means existing client code just works.

ollama pull llama3.1:8b-instruct-q4_K_M
ollama run llama3.1:8b-instruct-q4_K_M "Summarise this in three bullets: ..."

# Serve it on localhost with an OpenAI compatible API
ollama serve

# Point any existing client at it by changing the base URL
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3.1:8b-instruct-q4_K_M",
    "messages": [{"role": "user", "content": "Extract every date from this text."}],
    "temperature": 0.2
  }'

Ce point de terminaison compatible OpenAI est le détail qui rend les modèles locaux pratiques plutôt qu’académiques. Le code existant qui dialogue avec une API hébergée n’a généralement besoin que d’un changement d’URL de base pour s’exécuter sur un modèle local, ce qui signifie que vous pouvez comparer un modèle local à un modèle de pointe sur votre charge de travail réelle en un après-midi au lieu de réécrire une intégration.

# Route by difficulty: local model for volume, frontier API for hard cases.
# The heuristic matters less than having one at all.

from openai import OpenAI

local    = OpenAI(base_url="http://localhost:11434/v1", api_key="not-needed")
frontier = OpenAI()   # reads the real key from the environment

def classify(text: str, hard: bool = False):
    client = frontier if hard else local
    model  = "gpt-5" if hard else "llama3.1:8b-instruct-q4_K_M"

    return client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": text}],
        temperature=0,
    )

# Escalate only when the local model is uncertain or the input is long
def needs_frontier(text: str, local_confidence: float) -> bool:
    return local_confidence < 0.7 or len(text) > 20_000

Là où les modèles locaux perdent vraiment

Il serait malhonnête de présenter cela comme un remplacement direct. Les modèles locaux sont nettement moins bons pour le raisonnement long en plusieurs étapes, pour maintenir de très longs contextes de manière cohérente, pour générer du code correct pour des bibliothèques peu familières, et pour suivre des instructions complexes à contraintes multiples sans dériver. Si votre tâche implique de raisonner sur une centaine de pages, ou d’écrire du code qui doit être juste du premier coup, l’écart est réel et vous le ressentirez.

Ils perdent aussi en débit soutenu. Une seule machine servant un utilisateur, c’est bien. Une seule machine servant deux cents utilisateurs simultanés, c’est un problème d’ingénierie différent, et à ce stade, l’économie d’une API hébergée redevient raisonnable.

La position pragmatique

L’inférence locale n’est plus un exercice de hobbyiste, mais ce n’est pas non plus un remplacement en bloc des modèles hébergés. Le cadrage utile est que vous disposez maintenant d’un niveau rapide, gratuit et privé pour le gros volume de travail simple, et d’un niveau payant pour les requêtes vraiment difficiles. La plupart des équipes découvrent que la répartition penche fortement vers le niveau gratuit une fois qu’elles la mesurent honnêtement. Passez un après-midi à exécuter vos prompts réels sur un modèle 8B sur la machine devant vous, et laissez les résultats plutôt que le marketing décider où chaque requête doit aller.