Matrice d’inférence LLM locale sur Mac M4 (2026) : llama.cpp vs Ollama — contexte, batch et bande passante mémoire

Si vous enchaînez génération et récupération (RAG), commencez par notre matrice RAG locale (chunks, batch d’embedding, quotas) afin que l’indexeur et le runtime de chat ne se disputent pas le même enveloppe RAM. Pour comparer les offres sans compte, ouvrez la page d’achat et croisez avec les grilles sur la page tarifs — utile dès que vous séparez charge interactive et jobs longs.

Limites matérielles

Le Mac mini M4 s’appuie sur une mémoire unifiée : GPU, Neural Engine et cœurs CPU partagent le même pool physique. C’est excellent pour limiter les copies, mais cela signifie que fenêtre de contexte, cache KV et taille de batch constituent un seul budget. En pratique, la pression de pointe dépend surtout des jetons actifs en vol : prompts plus longs, batch plus larges et conversations parallèles grossissent l’ensemble de travail que le contrôleur mémoire doit garder « chaud ».

Apple communique des chiffres de bande passante mémoire par famille de puces ; pour les LLM locaux, le décodage soutenu dépend souvent de la vitesse à laquelle poids et octets KV sont lus, plus que d’un seul slogan « TFLOPS ». Passer de 8 k à 32 k tokens de contexte sur le même modèle ne « consomme pas seulement plus de RAM » : vous modifiez la résidence des tenseurs KV et le cycle d’occupation des noyaux Metal. Si le Moniteur d’activité affiche une pression mémoire élevée alors que les tokens défilent encore, vous êtes en général au-delà du coude de la courbe : baissez la quantification, réduisez num_ctx ou le nombre de sessions avant de chasser la build flash-attention du jour.

Sur format mini, la marge thermique se juge en régime établi : viser des runs d’au moins dix minutes avec la charge réelle (bureau ouvert). Préfetch agressif et gros batch peuvent plafonner avant un benchmark minute.

Choix GGUF et de la quantification

GGUF reste le format d’échange de référence pour les stacks dérivées de llama.cpp ; Ollama consomme en sous-main des poids compatibles. En 2026, beaucoup d’équipes multilingues ou orientées code ancrent le défaut sur Q4_K_M ou Q5_K_M : qualité perceptive souvent proche du FP16 pour de nombreuses tâches, avec moins d’octets par paramètre donc moins de pression sur la bande passante. Les quantifications IQ (IQ4_XS, etc.) peuvent gagner quand la mémoire unifiée serre, mais validez sur vos prompts d’éval : les régressions apparaissent d’abord sur le JSON d’outils, les grands tableaux et les langues rares.

Les MoE ont moins de paramètres actifs que le total, mais des pics subsistent au chargement d’experts. Épinglez révision, quant et template dans les runbooks pour éviter GGUF / tokenizer désynchronisés.

Concurrence et taille de batch

llama.cpp expose batching et offload explicitement : contexte via -c / --ctx-size, batch via -b / --batch-size (et -ub quand disponible), couches GPU via -ngl (ou équivalents serveur). Augmenter le batch améliore souvent le débit de préremplissage mais gonfle le pic mémoire pendant cette phase ; des batch minuscules sous-remplissent le GPU. Boucle de réglage pragmatique : figez la cible de contexte, balayez {128, 256, 512, 1024}, retenez la plus grande valeur qui laisse une marge confortable (sur 24 Go, viser souvent ≥ 8–12 Go libres si le bureau reste ouvert).

Ollama échange une partie des leviers bruts contre la simplicité opérationnelle. Définissez les défauts modèle dans un Modelfile (PARAMETER num_ctx, num_batch, num_gpu selon build) et cadrez le parallélisme avec des variables comme OLLAMA_NUM_PARALLEL. Chaque slot parallèle multiplie la résidence KV au pic : traitez-le comme plusieurs serveurs llama.cpp sur un seul accélérateur. Pour du trafic API irrégulier, limitez le parallélisme et filez côté client plutôt que de laisser le démon accepter tout ce qui déclenche la compression mémoire.

Checklist mise en prod — inférence locale

• Manifeste modèle : nom GGUF, quant, empreinte (SHA-256), template tokenizer, version runtime (commit llama.cpp ou version app Ollama).
• Enveloppe mémoire : démarrage à froid, première requête, puis soak 10 min avec concurrence réaliste ; noter pic RSS et swap.
• Politique de contexte : plafond num_ctx par environnement et limite dure côté client sur les tokens de prompt.
• Balayage batch : enregistrer le -b / num_batch gagnant avec latence de préremplissage p95.
• Repli automatisé : quant plus légère ou contexte plus court si pression mémoire > seuil pendant > 60 s.
• Observabilité : journaux horodatés (tokens prompt/générés, erreurs), rotation sous ~/Library/Logs ou répertoire service.

FAQ stabilité

Pourquoi le débit s’effondre après quelques minutes ? Souvent moyenne thermique ou compression mémoire après des pics de concurrence. Relancez avec moins de sessions parallèles et vérifiez qu’aucun job système (Spotlight, Time Machine, indexation Xcode) ne monopolise disque et CPU.

Ollama a mis à jour — qui a bougé ma latence ? Le démon et les blobs modèle évoluent ensemble. Épinglez versions en production et miroitez les blobs sur un chemin interne si la conformité l’exige.

Un batch plus gros est-il toujours meilleur ? Non : au-delà du coude, peu de gain sur le préremplissage mais risque d’OOM avec des longueurs de prompts mélangées. Préférez des batch bornés et le découpage des prompts système géants.

Faut-il désactiver Metal pour déboguer ? Seulement brièvement : le CPU aide à isoler des problèmes de template ou de précision mais ment sur la capacité. Utile pour bissecter, pas pour dimensionner.