7 articles tagués avec « ai »

La plupart des déploiements IA d'entreprise font tôt la même erreur d'architecture : donner à chaque équipe une clé d'API directe vers OpenAI ou Anthropic et considérer le travail fait. Le résultat est prévisible — aucune visibilité sur les coûts, aucun contrôle d'accès, aucune piste d'audit, et des données sensibles envoyées aux API cloud sans le moindre garde-fou.

Une vraie passerelle IA d'entreprise change la forme du problème. Au lieu de nombreuses équipes parlant à de nombreuses API, vous avez un seul endpoint qui gère le routage, la limitation de débit, l'expurgation des données personnelles, le cache et l'observabilité. Les équipes la consomment de la même manière, que le modèle tourne sur votre propre matériel ou sur le parc GPU d'un fournisseur cloud.

Cet article couvre la conception complète d'une telle passerelle, construite sur Kubernetes avec LiteLLM comme couche de proxy, Ollama et vLLM pour l'inférence locale, et Presidio pour la protection des données personnelles — avec une configuration réelle qui tourne en production.

La plupart des articles comparant vLLM et Ollama présument que vous avez un GPU. Les benchmarks montrent une utilisation impressionnante de la VRAM. Les schémas d'architecture incluent des pilotes CUDA. La recommandation — vLLM gagne — vient avec un astérisque implicite : à condition d'avoir le matériel pour.

Nous ne l'avions pas. Notre cluster d'inférence, c'est quatre ThinkPads, chacun avec un i7-8565U (4 cœurs, 8 threads, jusqu'à 4,6 GHz en turbo), 16 Go de RAM, et aucun GPU d'aucune sorte. Nous avons d'abord utilisé Ollama. Puis nous l'avons remplacé par vLLM. Voici le compte-rendu honnête de cette migration : ce qui a cassé, ce qui s'est amélioré, et à quoi ressemblent réellement les compromis quand vous faites tourner de l'inférence LLM sur des CPU x86 grand public.

Chaque article sur l'IA d'entreprise se termine de la même façon. Utilisez Amazon Bedrock. Utilisez Azure OpenAI Service. Utilisez Google Vertex AI. Ces plateformes offrent conformité de niveau entreprise, confidentialité des données et garanties de non-entraînement.

Le conseil est correct — pour les organisations qui peuvent utiliser une infrastructure cloud américaine.

Un nombre important et croissant d'organisations ne le peut pas. Certaines à cause du coût. Beaucoup à cause de la réglementation. Quelques-unes parce que leurs données ne peuvent littéralement pas franchir une frontière selon la loi qui régit leur secteur.

Cet article s'adresse à ces organisations. Il couvre deux problèmes distincts — la souveraineté des données et le coût — et les options concrètes disponibles pour chacun.

Ollama est la façon dont la plupart des équipes exécutent un grand modèle de langage localement pour la première fois. Vous l'installez en cinq minutes, lancez ollama pull mistral, et vous avez une API fonctionnelle. Cela ressemble à de la magie.

Puis vous essayez de servir dix utilisateurs à la fois. Ou cent. Ou vous devez auditer chaque requête pour la conformité. Ou votre équipe juridique demande où vont les données. C'est là que vous réalisez qu'Ollama a été conçu pour tout autre chose.

Un modèle sort de l'entraînement à 28 Go. Tu le télécharges à 4.7 Go. Qui a fait la compression entre les deux — et pourquoi ?

Ce post répond à cette question, et explique comment les modèles open-source circulent depuis les labos de recherche jusqu'à ton cluster.

Un modèle 7B en FP32, c'est 28 Go de RAM. Mes ThinkPads en ont 16 à 32. Impossible de charger le modèle — sans parler de faire de l'inférence.

La quantization a résolu ce problème. Pas en sacrifiant la qualité — en changeant la façon dont les poids sont stockés.

Faire tourner des LLM sur du matériel CPU bare-metal vous force à comprendre les chiffres derrière les fichiers de modèles. Cet article documente comment nous raisonnons sur la taille des modèles, la quantification et le service d'inférence sur minicloud — et le changement concret que nous avons fait : remplacer phi4-mini par Qwen 2.5 7B sur les trois instances Ollama.