5 articles tagués avec « enterprise »

La plupart des architectures d'identité d'entreprise n'ont pas commencé comme ce qu'elles sont aujourd'hui. Elles ont démarré en 1999 avec Active Directory, ont accumulé des intégrations LDAP au cours de la décennie suivante, et sont désormais à mi-chemin d'une migration vers l'identité cloud via Microsoft Entra ID — portant le poids de chaque couche qui l'a précédée.

Nous avons construit notre plateforme de zéro. Nous n'avons jamais eu de domaine on-premises. Nous n'avons jamais configuré LDAP. Nous avons sauté directement à la pile de protocoles que les entreprises passent des années et des sommes importantes à essayer d'atteindre. Cet article explique ce que nous avons choisi, pourquoi, et comment l'architecture d'identité résultante se compare au standard d'entreprise.

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.