Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
Vous avez probablement déjà vécu cette situation : après avoir regardé une vidéo YouTube et entré une commande d'installation de modèle dans le terminal, l'écran s'est figé. Si les LLM locaux plantent sur un ancien MacBook de 8 Go ou 16 Go, ou sur un ordinateur portable d'entrée de gamme, ce n'est pas par manque de cœurs de calcul. La véritable cause est que le runtime tente de lire des données dépassant les limites alors que la bande passante de la mémoire est extrêmement étroite. En évaluant la bande passante de l'appareil et en ajustant uniquement la taille du contexte, vous pouvez faire fonctionner un modèle d'assistance au code même sur un ancien appareil.
Les versions récentes de macOS et d'Ubuntu empêchent l'installation arbitraire de paquets dans le Python système. Dès que vous lancez pip install, il s'arrête en affichant l'erreur PEP 668 (error: externally-managed-environment). Si, par paresse, vous forcez le contournement de la protection système avec le drapeau (--break-system-packages), les outils de base du système finiront par se mélanger et vous obligeront à tout réinitialiser. Utilisez plutôt pipx, qui prend en charge l'isolation des environnements virtuels indépendants, pour installer l'outil de diagnostic.
Déployez l'outil de diagnostic open-source llmfit, développé par Alex Jones, de manière isolée pour extraire les caractéristiques de votre matériel.
`bash
brew install pipx
pipx ensurepath
pipx install llmfit
mkdir -p ~/local-ai-workspace/{configs,logs,scripts}
llmfit --json system > ~/local-ai-workspace/logs/system_specs.json
`
Une fois cette procédure terminée dans le terminal, la capacité de la mémoire RAM de l'appareil et les informations sur le bus mémoire sont organisées dans le fichier system_specs.json en une minute, sans toucher aux bibliothèques système.
Le processus par lequel un modèle de langage local génère du texte est une tâche séquentielle qui produit le caractère suivant en consultant les tokens précédents. À chaque étape, les milliards de poids du modèle doivent être lus entièrement depuis le bus mémoire. En d'autres termes, la vitesse perçue n'est pas déterminée par la fréquence du GPU, mais par la valeur de la bande passante de la mémoire.
La vitesse de sortie en tokens par seconde (TPS) se calcule selon la formule suivante :
TPS approx rac{ ext{Memory Bandwidth (GB/s)}}{ ext{Model Weights Size (GB)} + ext{KV Cache per Step (GB)}} imes etaLe terme dans la formule représente l'efficacité de la bande passante effective (MBU) du runtime, qui se situe généralement autour de 0,65.
Si vous chargez entièrement un modèle 7B quantifié sur 4 bits (environ 4,5 Go) sur une RAM de bureau DDR4 standard dont la bande passante est d'environ 45 Go/s, la vitesse de calcul stagne à . Le texte apparaît au compte-gouttes, ce qui est particulièrement frustrant pour une utilisation d'assistance professionnelle. En revanche, si vous le chargez sur un modèle RTX 4060 de 8 Go avec une bande passante de 288 Go/s ou sur une mémoire unifiée de la série M dépassant 100 Go/s, vous obtenez 35 à 40 tokens par seconde, surpassant largement la vitesse de frappe en temps réel.
Après avoir vérifié les caractéristiques de votre appareil, le choix des modèles se limite à deux options :
Qwen2.5-Coder-7B-Instruct (Q4_K_M) d'une taille de 4,7 Go. Il dépasse les 35 TPS sur un MacBook à mémoire unifiée de 16 Go ou avec un GPU dédié de 8 Go de VRAM.Llama-3.2-3B-Instruct (Q4_K_M) d'une taille de 2,0 Go. Même dans un environnement DDR4 sur un ordinateur portable à faible consommation, il consomme moins de RAM et produit régulièrement environ 15 TPS.Même après avoir réussi à lancer le modèle, le processus s'arrête discrètement après quelques questions-réponses. Le message Exit Code 137 affiché dans le terminal signifie que le gestionnaire de mémoire du système d'exploitation (le tueur OOM de Linux ou JetSam de macOS) a arrêté de force le processus (SIGKILL) en raison d'un manque de RAM.
Dans le cas de l'utilisation d'un GPU externe, un problème encore plus ennuyeux se produit : le repli silencieux sur le processeur (Silent CPU Fallback). Lorsque la limite de la VRAM est dépassée, au lieu d'interrompre le processus, une partie des couches de calcul est déportée vers la RAM système beaucoup plus lente. L'utilisation du GPU chute alors brutalement et le système rampe à une vitesse d'environ 1 token par seconde.
Le coupable est le cache KV (Key-Value), qui consomme de la RAM à mesure que la conversation s'allonge. Avec l'architecture Llama-3, si le contexte est étendu à 32 768 (32K) tokens, 4,0 Go supplémentaires sont alloués uniquement pour la mémoire cache, en plus des 4,5 Go des poids du modèle. C'est une structure qui plantera inévitablement sur un appareil de 8 Go. En limitant cette longueur à 4 096 (4K) tokens, la capacité du cache est réduite à 512 Mo, évitant ainsi les plantages même dans un environnement de 8 Go.
Voici la procédure pour vérifier l'état actuel et fixer la limite.
Tout d'abord, entrez ollama ps dans le terminal. Si l'élément PROCESSOR affiche une répartition telle que 30%/70% CPU/GPU au lieu de 100% GPU, cela signifie que la VRAM a déjà été dépassée et que le processus a basculé vers la RAM lente.
Créez un fichier de configuration pour figer la taille du contexte. Ouvrez ~/local-ai-workspace/configs/Modelfile.coder et écrivez le contenu suivant :
`dockerfile
FROM qwen2.5-coder:7b
PARAMETER num_ctx 4096
PARAMETER temperature 0.2
`
Compilez avec le modèle personnalisé dans le terminal :
`bash
ollama create custom-coder:7b -f ~/local-ai-workspace/configs/Modelfile.coder
`
Une fois la compilation terminée, entrez sudo purge dans le terminal sur macOS pour vider le cache disque, et nettoyez les instances WSL inutilisées sur Windows avec wsl --shutdown, afin de sécuriser au moins 2 Go de RAM disponible par défaut.
Afin d'empêcher que le code source de l'entreprise ou vos projets personnels ne fuites à l'extérieur, lier le point de terminaison de service du modèle uniquement à la boucle locale (127.0.0.1).
Créez le fichier ~/local-ai-workspace/scripts/serve_secure.sh et ajoutez-y le code suivant :
`bash
#!/bin/bash
export OLLAMA_HOST="127.0.0.1:11434"
export OLLAMA_ORIGINS="http://127.0.0.1:*,http://localhost:*"
ollama serve > ~/local-ai-workspace/logs/ollama_runtime.log 2>&1 &
`
Après avoir exécuté le script, vérifiez si l'adresse de réception affichée est bien 127.0.0.1:11434 lorsque vous entrez lsof -i :11434 | grep LISTEN dans le terminal. Si vous voyez 0.0.0.0:11434, qui peut être accédé de l'extérieur, vous devez fermer le processus immédiatement.
Pour l'intégration, utilisez l'extension VS Code Continue.dev. Ouvrez le fichier de configuration (~/.continue/config.json) pour séparer le modèle de chat et le modèle de saisie semi-automatique.
`json
{
"models": [
{
"title": "Local Qwen2.5-Coder (Chat)",
"provider": "ollama",
"model": "custom-coder:7b",
"apiBase": "http://127.0.0.1:11434"
},
{
"title": "Local Llama3.2 (Summary)",
"provider": "ollama",
"model": "llama3.2:3b",
"apiBase": "http://127.0.0.1:11434"
}
],
"tabAutocompleteModel": {
"title": "Local Autocomplete",
"provider": "ollama",
"model": "qwen2.5-coder:1.5b",
"apiBase": "http://127.0.0.1:11434"
},
"allowAnonymousTelemetry": false
}
`
Assignez le modèle 7B (dont le contexte vient d'être limité) aux questions-réponses et spécifiez qwen2.5-coder:1.5b, un modèle ultra-léger de 1 Go, pour la saisie semi-automatique par onglet. Le délai de saisie semi-automatique disparaît ainsi.
La vérification s'effectue en coupant Internet. Ouvrez le terminal en étant hors ligne (Wi-Fi désactivé) et envoyez directement une requête :
`bash
curl -s -X POST http://127.0.0.1:11434/api/generate -d '{
"model": "llama3.2:3b",
"prompt": "Test de réseau isolé local",
"stream": false
}' | grep "response"
`
Si une réponse JSON normale est renvoyée alors que le réseau est bloqué, la configuration de l'environnement de développement s'exécutant en toute sécurité au sein des ressources de votre propre ordinateur portable, sans dépendance au cloud externe, est terminée.