Contexte et contraintes matérielles

Le point de départ est un jeu de pré‑prompts de 35 KB utilisé avec le modèle Opus d’Anthropic. L’auteur a tenté de les exécuter sur un serveur local équipé d’un AMD Ryzen AI MAX+ 395 de 128 Go de RAM. Le système d’exploitation occupe 32 Go, le reste étant dédié à l’inférence du modèle 27 B paramètres via Ollama. Cette configuration impose une limite stricte de mémoire disponible pour le moteur de génération, contrairement aux API frontier qui allouent dynamiquement plusieurs dizaines de gigaoctets.

Le contraste de context window est crucial : les fournisseurs cloud offrent souvent plus de 8 k tokens (voire 32 k) alors que le modèle local d’Ollama, selon la version 27 B, ne supporte que 4 k tokens. Un pré‑prompt de 35 KB dépasse rapidement ce seuil, provoquant des erreurs de dépassement de mémoire ou de troncature silencieuse.

Échecs de migration et diagnostics

Lors des premiers tests, les prompts qui s’exécutaient sans problème sur l’API frontier se sont désintégrés sous Ollama. Le journal d’erreur indique out of memory dès que le nombre de tokens dépasse la capacité allouée. Le problème n’est pas uniquement la RAM : le GPU intégré du Ryzen AI ne possède pas de mémoire vidéo dédiée, ce qui contraint le backend à utiliser la RAM système, augmentant la latence et la fragmentation.

Une autre cause identifiée est le format de tokenisation. Les modèles d’Anthropic utilisent un tokenizer propriétaire qui génère moins de tokens pour le même texte que le tokenizer LLaMA‑2 employé par Ollama. Ainsi, un même fichier texte occupe plus de tokens dans Ollama, aggravant le dépassement de la fenêtre contextuelle.

Solutions techniques appliquées

# Exemple de découpage manuel du prompt
split -b 3000 prompt.txt part_
for f in part_*; do
  ollama run llama2:27b -p "$(cat $f)"
done

Le découpage du prompt en blocs de 3 000 bytes (environ 2 k tokens) a permis de contourner le problème de fenêtre, mais introduit une surcharge de gestion d’état entre les blocs. L’auteur a expérimenté le re‑enchainement de contexte en injectant les réponses précédentes comme system messages, ce qui augmente le nombre total de tokens et risque de nouveau l’échec.

Une alternative consiste à réduire la taille du modèle (ex. 7 B) pour libérer de la RAM, mais cela diminue la capacité de compréhension des prompts complexes, entraînant des réponses incohérentes.

Implications de sécurité et limites

Le déplacement vers un modèle auto‑hébergé élimine le risque de retraitement des données utilisateur par les fournisseurs cloud, répondant aux préoccupations de confidentialité exprimées dans l’article source. Cependant, la migration introduit de nouveaux vecteurs de risque : une mauvaise gestion de la mémoire peut entraîner des fuites de données en clair dans les fichiers de swap, et l’absence de filtres de sécurité intégrés aux API frontier expose l’utilisateur à des réponses potentiellement dangereuses.

En l’état, la solution la plus fiable reste d’ajuster le pipeline de prompt engineering : condenser les instructions, exploiter des few‑shot plus courts, et recourir à des embeddings externes pour stocker le contexte hors‑ligne. Sans ces adaptations, la migration de prompts volumineux vers Ollama sur le matériel décrit reste fragile et peu scalable.