La pile SLM verticale : GPU, entraînement et couche applicative pour une IA spécialisée en 2026

Le 1er juillet 2026, le PDG de Palantir, Alex Karp, s'est installé sur le plateau de Squawk Box sur CNBC et a dit ce que tous les acheteurs d'IA en entreprise pensaient sans que personne disposant d'une tribune ne l'ait dit à voix haute : « Quelque chose a complètement déraillé dans la façon dont l'IA est vendue. » Son diagnostic était précis. Les entreprises paient pour des tokens qui ne produisent aucune valeur opérationnelle. Les poids des modèles entraînés sur leurs données propriétaires, leur véritable intelligence concurrentielle, repartent vers les laboratoires. Et le modèle tarifaire est conçu pour vous maintenir dépendant, pas pour vous rendre capable.

La réponse de Karp, c'est la souveraineté : contrôlez votre calcul, les poids de vos modèles, votre pile de données et votre avantage. Ce n'est pas une position philosophique. C'est une décision d'architecture. Et l'architecture qu'elle désigne porte un nom : la pile SLM verticale.

Cet article explique à quoi ressemble cette pile, comment construire chaque couche, et pourquoi un fondateur qui a un cas d'usage précis peut surpasser un modèle de pointe généraliste sur son propre problème, pour une fraction du coût.

Pourquoi le modèle au token est en train de se fissurer

L'économie de la location d'intelligence à un laboratoire de pointe avait du sens en 2023. Les modèles semblaient magiques, construire le sien coûtait une fortune et les écarts de benchmark entre grands et petits modèles étaient énormes. Aucune de ces trois conditions n'est vraie en 2026.

Les modèles à poids ouverts (Llama 3.2, Phi-4-mini, Gemma 3) sont désormais 16 fois moins chers par token que les API de pointe et les égalent ou les dépassent souvent sur des tâches étroites et bien définies. L'infrastructure de fine-tuning qui exigeait une équipe d'ingénieurs ML il y a deux ans tourne aujourd'hui sur une seule A100 en un après-midi. Et le monde de l'entreprise a commencé à faire ses calculs. Les fils Reddit et les canaux Discord où les ingénieurs ML parlent franchement racontent la même histoire : pour la classification, l'extraction, le résumé, la génération de code dans un périmètre défini et la sortie structurée (qui couvrent environ 80 % des charges de travail IA réelles en entreprise), un modèle de 7B affiné bat un modèle de 70B piloté par prompt à la fois en précision, en latence et en coût.

L'écart de coût n'est pas marginal. C'est un ordre de grandeur. Et il se creuse à mesure que le volume augmente. Une startup qui traite 500,000 appels d'API par mois fait face à $10,000–$40,000 de factures de tokens, ou à $300–$600 en auto-hébergeant un SLM affiné. Cet écart paie deux ingénieurs.

Qu'est-ce qu'un petit modèle de langage, au juste ?

Les SLM sont des modèles de langage de 1 à 15 milliards de paramètres. Cela ressemble à une distinction technique, mais les conséquences pratiques sont concrètes : ils tournent sur un seul GPU (voire sur CPU dans certaines configurations), s'affinent en quelques heures plutôt qu'en semaines, tiennent dans des environnements en périphérie et des déploiements sur site, et produisent une inférence en 80–300 ms au lieu de plusieurs secondes.

Les principaux SLM à poids ouverts en 2026 sont :

• Phi-4-mini (3.8B, Microsoft) : actuellement en tête des benchmarks dans la catégorie 3–4B. Tourne avec ~3 Go de VRAM, fenêtre de contexte de 128K, en tête sur MMLU et le raisonnement mathématique. Exceptionnel pour les tâches de raisonnement structuré avec une empreinte réduite.
• Gemma 3 (2B / 7B, Google) : licence commerciale solide, optimisé pour le cloud et la périphérie. Particulièrement adapté à la compréhension de documents et au suivi d'instructions sur plusieurs tours.
• Llama 3.2 (1B / 3B, Meta) : conçu pour le déploiement en périphérie, sur mobile et sur appareils embarqués. Le modèle de 1B tourne sur le CPU d'un téléphone. Excellent pour le routage, la classification et l'extraction légère.
• Mistral 7B / Mixtral 8x7B : solides en génération de code et en suivi d'instructions. L'architecture MoE clairsemée de Mixtral lui donne une puissance bien supérieure à son nombre de paramètres actifs.

L'idée clé, c'est qu'aucun de ces modèles ne battra GPT-5 sur un benchmark généraliste. Là n'est pas la question. Un modèle de 3.8B affiné sur 50,000 exemples de votre tâche précise battra GPT-5 sur cette tâche, pour 1/30 du coût et avec une latence 10 fois plus faible.

La pile verticale à trois couches

Construire une capacité d'IA spécialisée que vous possédez de bout en bout implique des décisions délibérées sur trois couches : le calcul, l'entraînement et l'application. La plupart des fondateurs qui ont essayé et échoué les ont traitées indépendamment. Elles ne le sont pas. Chaque couche contraint et rend possible les autres.

Couche 1 : GPU (calcul)

La couche GPU est celle où la plupart des fondateurs soit surinvestissent, soit font le mauvais pari d'architecture. La bonne nouvelle, c'est que les besoins matériels pour un SLM vertical en 2026 sont bien plus faibles qu'il y a seulement 18 mois.

Pour affiner un modèle de 7B avec LoRA ou QLoRA (l'approche standard), il vous faut une seule A100 de 80GB ou deux A6000. Coût dans le cloud : $2–$4/heure. Un entraînement complet sur 10,000 exemples prend 2 à 6 heures. Total : moins de $25 par entraînement. Ce n'est pas une dépense d'investissement : c'est un coût variable que vous payez quand vous réentraînez.

Pour l'inférence, un modèle de 7B quantifié (INT4/INT8) sert 100 à 500 requêtes simultanées sur une seule A10G (24GB de VRAM, ~$1.50/heure). À cette échelle, l'auto-hébergement est presque toujours moins cher que les appels d'API dans les 30 à 60 jours suivant le déploiement.

Pour les besoins en périphérie ou sur site, fréquents dans la santé, le juridique et le secteur public, la catégorie de modèles de 1–3B tourne sur des cartes grand public NVIDIA RTX 4090 (~$2,000) ou sur Apple Silicon M3 Ultra. Aucune dépendance au cloud, aucune sortie de données, aucune exposition en matière de conformité.

Guide de choix du niveau de GPU

• Modèle de 1–3B, périphérie ou sur site : RTX 4090, Apple M3 Ultra, NVIDIA Jetson
• Modèle de 7B, fine-tuning et mise en service dans le cloud : A10G (inférence), A100 (entraînement)
• Modèle de 13B : 2× A100 ou H100 pour l'entraînement ; A100 pour l'inférence quantifiée
• Traitements par lots / asynchrones : les instances spot réduisent le coût d'entraînement de 60 à 70 %

Couche 2 : entraînement (pipeline de fine-tuning)

C'est la couche qui apporte le véritable avantage concurrentiel. Le modèle de base est public. Tout le monde peut partir de Llama ou de Phi. Ce que les autres ne peuvent pas reproduire, ce sont vos données d'entraînement : les exemples propres à votre domaine, les cas limites et les formats de sortie qui inscrivent votre savoir opérationnel dans les poids du modèle.

Alex Karp l'a formulé sans détour : les laboratoires de pointe « volent les poids et l'avantage » des entreprises qui utilisent leurs API, car chaque requête et chaque signal de correction que vous fournissez en utilisant une API cloud contribue, directement ou indirectement, à améliorer leur modèle. Quand vous possédez votre pipeline de fine-tuning, ce signal reste le vôtre.

Le workflow de fine-tuning standard :

1. Constituez un jeu de données propre à la tâche. Il vous faut entre 1,000 et 50,000 paires instruction–réponse de haute qualité pour la tâche précise. La qualité l'emporte sur la quantité. 2,000 exemples étiquetés par des experts surpassent systématiquement 50,000 exemples bruités. Partez de vos productions existantes (documents, décisions et données structurées passés), utilisez un modèle de pointe pour générer à moindre coût des données d'entraînement synthétiques, puis validez un échantillon à la main.
2. Appliquez un fine-tuning LoRA / QLoRA. L'adaptation de faible rang (Low-Rank Adaptation) gèle la plupart des poids du modèle de base et n'entraîne qu'un petit ensemble de matrices d'adaptation, généralement 0.1 à 1 % du nombre total de paramètres. C'est ainsi qu'on affine un modèle de 7B sur un seul GPU sans manquer de mémoire. Outils : la bibliothèque PEFT de Hugging Face, Unsloth (2 à 5 fois plus rapide), Axolotl pour les pipelines complexes.
3. Évaluez rigoureusement avant de livrer. Constituez un jeu d'évaluation réservé de 200–500 exemples avec des étiquettes de référence. Suivez la précision sur la tâche, le taux d'hallucination et le respect du format. Un modèle précis à 95 % sur votre jeu d'évaluation mais qui échoue sur des cas limites en production est pire qu'un modèle à 90 % dont les modes de défaillance sont connus.
4. Mettez en place un rythme de réentraînement. La valeur du modèle se démultiplie quand vous le réentraînez sur les sorties et corrections de production. Une boucle de réentraînement mensuelle ou trimestrielle, alimentée par des données d'usage réel, crée un avantage qui s'élargit avec le temps. C'est le cœur de l'avantage vertical : chaque cycle rend votre modèle meilleur sur votre tâche précise, tandis que les API génériques restent génériques.

Couche 3 : couche applicative

La couche applicative est l'endroit où votre modèle se connecte aux vrais workflows, et où se prennent la plupart des décisions produit. Réussir cette couche, c'est ce qui sépare une démo qui marche d'un système de production auquel les utilisateurs font confiance.

Comme votre SLM est étroit par conception, la couche applicative doit gérer clairement le périmètre. Un SLM de documentation clinique ne doit pas tenter de répondre à des questions médicales générales. Un extracteur de contrats ne doit pas tenter de donner un avis juridique. La couche applicative fait respecter cette limite, par la structure du prompt, la validation des sorties et la logique de routage.

• Infrastructure de mise en service : vLLM et Ollama sont les deux serveurs d'inférence open source dominants en 2026. vLLM gère une mise en service multi-tenant à haut débit avec PagedAttention. Ollama est plus simple à exploiter et excellent pour un usage mono-tenant ou développeur. Les deux prennent en charge les modèles quantifiés et des API compatibles OpenAI : le code existant qui appelle OpenAI peut donc être redirigé vers votre SLM auto-hébergé en changeant une seule ligne d'URL.
• Application d'une sortie structurée : pour les tâches métier, vous voulez presque toujours du JSON ou une sortie structurée. Utilisez un décodage contraint par grammaire (Outlines, Guidance ou la sortie structurée intégrée de vLLM) pour garantir que le modèle renvoie une sortie valide et conforme au schéma. Cela élimine la source la plus fréquente de défaillances en aval.
• Augmentation par récupération : une pile SLM + RAG est souvent plus puissante qu'un grand modèle seul. Le SLM se charge du raisonnement et de la génération ; la couche de récupération l'ancre dans des documents actuels et propriétaires. C'est particulièrement efficace dans les contextes juridiques, financiers et de santé, où la fraîcheur et la fidélité aux documents comptent plus qu'une large connaissance du monde.
• Couche de routage : en production, l'architecture la plus intelligente route les requêtes avec discernement. Les tâches simples et fréquentes vont au SLM. Les tâches complexes, ambiguës ou rares sont escaladées vers un modèle de pointe via une API. Un classifieur de 1B peut prendre cette décision de routage en moins de 10 ms. Résultat : 70 à 80 % des requêtes sont servies par votre SLM rapide et bon marché, les 20 à 30 % restants étant escaladés. Votre coût moyen par requête baisse de 85 à 90 % tandis que la qualité reste élevée.

Les cas d'usage verticaux où cette pile l'emporte nettement

L'approche SLM verticale n'est pas universellement meilleure qu'un modèle de pointe. Elle est nettement meilleure pour une catégorie précise de problèmes : des tâches fréquentes, bien définies et riches en données, dans un domaine doté d'un savoir propriétaire.

La souveraineté de l'IA n'est pas une idéologie : c'est une architecture

Le manifeste en neuf points de Palantir sur la souveraineté de l'IA, publié la veille de l'entretien de Karp sur CNBC, se lit comme une provocation. C'est en réalité un document d'architecture. Son argument central est pratique : le « tokenmaxxing », ce modèle économique qui facture au token une intelligence générale, encourage les mauvaises choses. Il encourage les scripts jetables plutôt que les systèmes robustes, la dépendance plutôt que la capacité, et le volume de consommation plutôt que la qualité du résultat.

Le partenariat entre Palantir et Nvidia annoncé la même semaine est l'expression commerciale de cette thèse : un « système d'exploitation d'IA souverain » qui donne aux institutions le contrôle de leur calcul, de leurs modèles et de leur pile de données sous la forme d'un produit intégré. Que vous l'achetiez à Palantir ou que vous le construisiez vous-même, la direction est la même : possédez la pile.

Pour les fondateurs, la conséquence est simple. Si la capacité d'IA de votre produit est un appel à une API externe, vous n'avez aucun avantage défendable. N'importe quel concurrent peut faire le même appel. Si votre capacité est un modèle affiné, entraîné sur des données propriétaires et tournant sur une infrastructure que vous contrôlez, c'est un véritable actif concurrentiel, qui se renforce à chaque cycle de réentraînement et devient d'autant plus difficile à reproduire que vous le faites tourner longtemps.

Quand la pile verticale est le mauvais choix

La pile SLM verticale n'est pas toujours la bonne. Elle exige un investissement initial en curation de données, en infrastructure d'entraînement et en discipline opérationnelle que toutes les équipes ne sont pas en mesure de consentir. Trois situations où vous devriez rester sur l'API :

• Vous cherchez encore votre adéquation produit-marché. Si la définition de votre tâche change d'une semaine à l'autre, le fine-tuning est un effort perdu. Construisez avec une API jusqu'à ce que la tâche soit stable et bien comprise. Construisez ensuite le SLM.
• Vous n'avez pas encore assez de données étiquetées. Un fine-tuning sur moins de 500 exemples produit généralement des modèles instables. Si vous ne pouvez pas collecter ou générer plus de 1,000 exemples de haute qualité, utilisez du few-shot prompting avec un modèle de pointe et investissez en parallèle dans la collecte de données.
• Votre tâche exige réellement une large connaissance du monde. La synthèse de recherches, le travail créatif ouvert et les tâches qui demandent d'intégrer un contexte réel varié favorisent toujours les grands modèles de pointe. L'approche SLM excelle en profondeur, pas en étendue.

Par où commencer

Pour la plupart des fondateurs, le point d'entrée pratique est un fine-tuning pilote sur une seule tâche à fort volume, que vous pouvez mesurer précisément et dont les critères de réussite sont clairs. Choisissez une tâche pour laquelle vous payez actuellement $3,000–$10,000/mois en coûts d'API. Faites le calcul avec un SLM de 7B affiné. Le business case sera généralement évident dès le premier calcul.

Les trois questions pour savoir si vous êtes prêt pour un SLM vertical

• 1. Avez-vous une seule tâche bien définie qui tourne à fort volume (plus de 10,000 requêtes par mois) ?
• 2. Avez-vous, ou pouvez-vous générer, plus de 2,000 exemples étiquetés de cette tâche ?
• 3. La souveraineté des données, la latence ou le coût comptent-ils assez pour justifier 2 à 4 semaines d'ingénierie ?

Si vous avez répondu oui aux trois, vous êtes prêt à construire la première couche de votre pile verticale. Le reste en découle.

L'idée centrale de Karp, à savoir que quelque chose a complètement déraillé dans la façon dont l'IA est vendue, est moins une critique d'OpenAI et d'Anthropic que le constat d'un marché à un point d'inflexion. L'infrastructure pour construire en vertical est désormais accessible. Les modèles à poids ouverts sont assez bons. L'économie est convaincante. Il ne reste qu'à décider de construire quelque chose qui vous appartient plutôt que de louer quelque chose dont vous dépendez.

Related Posts

Pourquoi l'IA est difficile : les vrais problèmes que rencontrent les fondateurs une fois la démo fonctionnelle1 juillet 2026

Claude Code dans le développement : l'outil de programmation IA le plus puissant de 202624 juin 2026

La commande /loop de Claude Code : comment l'utiliser pour des workflows de développement plus intelligents en 20263 juillet 2026