Des LLM locaux.
Bien dimensionnés.
Du modèle adapté au service d’IA suivi : DAXS prépare l’infrastructure LLM locale, vérifie le matériel en charge réelle et intègre la solution à votre informatique existante.
Un serveur d’IA commence par le profil de charge.
Un modèle de langage local peut préparer des textes internes, aider à ébaucher du code ou contribuer à la recherche de connaissances. Pour obtenir une solution utile, qualité du modèle, flux autorisés et utilisation attendue doivent s’accorder. DAXS recense ces exigences, prépare l’infrastructure et assure installation, intégration et exploitation convenue, avec votre informatique ou comme prestation délimitée.
Tâche et qualité
Quelles questions, langues, documents ou tâches de programmation la solution doit-elle maîtriser ? Un court échange et l’analyse de longs documents nécessitent des modèles et contextes différents.
Utilisation et attente
Combien de demandes arrivent simultanément ? Quand la première réaction doit-elle commencer et combien de temps la réponse complète peut-elle prendre ? Des demandes individuelles occasionnelles et un service d’équipe utilisé en continu nécessitent des réserves différentes.
Données et exploitation
Quelles sources et fonctions sont autorisées ? Où peuvent résider modèle, index de recherche, journaux et sauvegardes ? Qui suit mises à jour et erreurs, et quelle solution de retour faut-il prévoir ?
Relier application, inférence et exploitation.
L’interface utilisateur n’est qu’une partie du système. En amont se trouvent contrôles d’identité et d’accès ; en aval, service d’inférence, stockage des modèles et éventuellement recherche de connaissances ou interfaces d’entreprise. Supervision, mises à jour et restauration font partie du même plan.
Le schéma présente une architecture possible, sans représenter un réseau client réel. Un reverse proxy peut sécuriser TLS et l’entrée. L’application doit néanmoins appliquer les droits utilisateurs. Les API des modèles sont limitées aux réseaux et fonctions nécessaires ; un port d’inférence accessible ne constitue pas encore un service d’entreprise complet.
Au-delà de la taille du fichier du modèle.
Pour le choix, nous examinons poids, besoins d’exécution, contexte, parallélisme et parcours complet des données. Un GPU peut disposer d’assez de mémoire tout en étant inadapté au temps de réponse visé. À l’inverse, un modèle plus petit bien choisi peut répondre au besoin de manière plus économique.
| Composant | Ce que nous vérifions | Pourquoi cela compte |
|---|---|---|
| GPU et VRAM | Architecture, pilotes, moteur d’inférence, formats de calcul pris en charge, capacité mémoire et bande passante. | Poids et cache KV occupent de la mémoire. Calcul et transferts mémoire influencent différentes phases ; une valeur TOPS annoncée ne décrit pas seule l’application. |
| Un ou plusieurs GPU | Répartition du modèle, connexions entre GPU, liaison PCIe, énergie et refroidissement. | La VRAM ne devient pas automatiquement une mémoire commune librement utilisable. Répartition et synchronisation doivent être prises en charge par la pile choisie ; des GPU supplémentaires peuvent créer de nouveaux goulets d’étranglement. |
| CPU et RAM système | Environnement d’exécution, tokenisation, préparation des données, processus parallèles et éventuellement inférence CPU ou déport. | Le déport peut rendre un modèle exécutable mais modifie son profil de performances. Les transferts RAM/GPU peuvent ralentir la réponse. Même un serveur GPU nécessite des réserves CPU et RAM adaptées. |
| NVMe et stockage | Versions des modèles, temps de chargement, index, données importées, journaux, capacité libre et sauvegardes. | Les SSD NVMe rapides facilitent le chargement des modèles et certaines opérations sur les données. La génération de tokens d’un modèle entièrement en mémoire GPU dépend surtout du calcul, de la mémoire et de l’environnement d’exécution. |
| Réseau et alimentation | Connexion, flux autorisés, place, besoin électrique, chaleur dissipée et accès de maintenance. | Le meilleur composant de calcul isolé aide peu si, en charge réelle, le service est limité par la température, l’organisation ou l’accès aux données. |
Une aide au calcul, sans recommandation d’achat.
La borne inférieure des seuls poids s’estime approximativement par nombre de paramètres × bits par poids ÷ 8 . Un modèle hypothétique de huit milliards de paramètres avec quatre bits par poids représente mathématiquement quatre gigaoctets, soit environ 3,73 Gio.
S’ajoutent métadonnées de quantification, éventuelles parties du modèle à précision supérieure, cache KV, espaces de travail et environnement d’exécution. Cette valeur ne détermine donc pas la VRAM suffisante pour votre application. Pour les architectures à experts, il faut aussi distinguer calcul actif et totalité des poids à conserver.
Une courte réponse et un service d’équipe demandent des tests différents.
La fenêtre de contexte comprend les informations qu’un modèle peut prendre en compte pour une requête : selon l’application, instructions, historique, extraits documentaires récupérés et sortie prévue. Une grande fenêtre nominale ne garantit ni matériel adapté ni exploitation fiable des informations.
Cache KV
Le cache clé-valeur conserve des états intermédiaires de l’attention. Son besoin dépend notamment de l’architecture du modèle, du type de données, du contexte réellement occupé et des séquences actives simultanément. Davantage de contexte et de parallélisme accroissent souvent nettement la mémoire nécessaire.
Prefill et décodage
Le prefill traite le contexte d’entrée ; le décodage produit les tokens suivants. Ces phases sollicitent différemment le matériel. De longs documents peuvent allonger le délai avant le premier token, même si la sortie semble ensuite fluide.
Traitement par lots et file d’attente
Le traitement groupé peut accroître le débit total, tout en faisant attendre davantage certains utilisateurs. Capacité réservée, files, limites et planification du parallélisme font donc partie de la conception.
Nous mesurons le cas d’usage réel.
Un pilote comprend des demandes courtes et longues représentatives ainsi que des accès simultanés. Nous examinons le délai avant le premier token, le temps de réponse complet, le débit de sortie, la file, le taux d’erreur et la mémoire utilisée. Les tokens par seconde ne sont comparables qu’avec version du modèle, quantification, contexte, charge et conditions de mesure.
La pile suit le modèle et l’usage.
Ollama, llama.cpp et vLLM sont des composants possibles. Choix et configuration dépendent des modèles pris en charge, du matériel, du parallélisme souhaité, de l’exploitation et de l’intégration. Nous vérifions les versions concrètes ; une commande d’installation générale ne définit pas une architecture de production.
Ollama
Une entrée possible pour gérer et déployer les modèles localement. Stockage, modèles autorisés, contexte, parallélisme et sécurisation du service doivent convenir à l’environnement.
llama.cpp
Un composant flexible pour des modèles adaptés sur différents moteurs CPU/GPU, avec formats quantifiés et fonctionnement serveur. Prise en charge matérielle, répartition et fonctions API réellement nécessaires sont vérifiées en pratique.
vLLM
Une option pour des profils d’inférence serveur et de charge adaptés. Ordonnancement, cache KV, lots et éventuels GPU multiples sont réglés ensemble. Un débit global supérieur n’implique pas une attente plus courte pour chaque requête.
Conteneur, machine virtuelle ou hôte dédié ?
Les conteneurs peuvent regrouper des versions logicielles de manière reproductible. Une VM peut isoler davantage l’environnement sur les plans organisationnel et technique. Le choix dépend de l’affectation des appareils, des pilotes, de la maintenance et des procédures existantes. Une API compatible facilite la connexion mais ne remplace pas un test avec votre application.
Quand Proxmox avec GPU passthrough convient-il ?
Le GPU passthrough affecte un GPU physique adapté à une VM. Plateforme et firmware, groupes IOMMU, pilotes hôte et invité, ainsi que comportement de réinitialisation doivent notamment convenir. Nous vérifions la combinaison concrète avant tout engagement.
Un GPU affecté n’est pas automatiquement partageable avec souplesse entre plusieurs VM. vGPU et affectation directe sont des concepts distincts avec leurs prérequis et éventuelles licences. Maintenance, sauvegarde et changement d’hôte demandent aussi un processus adapté ; une garantie générale de migration à chaud serait inappropriée.
Infrastructure et virtualisation · Évaluer une migration Proxmox
Le modèle adapté doit réussir la tâche.
Nous comparons les modèles sur des exemples autorisés de l’usage futur : questions métier en allemand, extraits de documents, requêtes multilingues ou tâche de script concrète. Un modèle de programmation et un modèle d’embeddings remplissent des fonctions différentes. Pour rechercher les connaissances, moteur de recherche, embeddings et modèle de réponse doivent s’accorder.
La quantification réduit souvent la mémoire nécessaire. Ses effets sur qualité des réponses, appels d’outils et vitesse sont testés dans le format choisi. Un modèle plus grand n’est pas automatiquement meilleur ou plus économique. Un contexte maximal long ne prouve pas davantage que chaque information y sera utilisée de façon fiable.
- Licence : vérifier précisément poids choisis, usage commercial, redistribution et mentions nécessaires ; un téléchargement simple ne remplace pas cette vérification.
- Version : consigner modèle, quantification, tokenizer et environnement d’exécution de manière traçable.
- Recette : vérifier adéquation métier, réponses non autorisées, qualité linguistique et erreurs avec un ensemble de questions reproductible.
- Modifications : tester d’abord les nouveaux modèles, conserver un retour utilisable et reconstruire les index de manière adaptée si les embeddings changent.
Local, externe ou une combinaison adaptée.
Le matériel propre peut convenir avec une charge adaptée, des exigences de données claires et un cadre d’exploitation disponible. Un service externe peut mieux répondre à un usage fluctuant, des capacités de modèle particulières ou une capacité d’exploitation propre limitée. L’hybride combine des tâches et flux délimités.
La comparaison comprend acquisition ou consommation, énergie et refroidissement, licences, intégration, mises à jour, suivi, réserve et effets des pannes. Un traitement local ne garantit pas automatiquement sécurité ou conformité RGPD : modèles, embeddings, télémétrie, mises à jour, outils externes et journaux doivent aussi convenir au concept de données.
Nous préparons d’abord un pilote limité avec des exigences mesurables. Son résultat guide extension, adaptation ou alternative plus simple. Pour les bases complémentaires, voir Cloud et SaaS.
Un service suivi nécessite des responsabilités traçables.
DAXS peut préparer et installer matériel et logiciels, les connecter aux identités et applications existantes et assurer l’exploitation convenue. Cela comprend suivi de disponibilité et ressources, gestion des versions, erreurs et documentation. Disponibilité et circuits de réponse nécessaires sont convenus concrètement.
Nous définissons les configurations, composants applicatifs, index et éventuels modèles adaptés à sauvegarder. Poids de modèles récupérables et données opérationnelles sensibles ont des besoins de sauvegarde différents. Un test de restauration fait partie d’un concept d’exploitation adapté.
Recueil des exigences, proposition d’architecture, test modèle/charge, flux documentés et recommandation traçable pour matériel, mode d’exploitation et prochaines intégrations.
Ce que nous clarifions ensemble.
Quelle quantité de VRAM faut-il pour un LLM local ?
Cela dépend du modèle et de sa quantification, de l’environnement d’exécution, du contexte et des requêtes simultanées. Le fichier du modèle seul ne suffit pas. Nous testons la tâche souhaitée, y compris requêtes longues et pointes de charge, avant de recommander une configuration concrète.
Un deuxième GPU accélère-t-il automatiquement le traitement ?
Non. La pile choisie doit prendre en charge la répartition. Connexions entre GPU, synchronisation et architecture du modèle influencent le résultat. Davantage de mémoire peut permettre l’exécution sans accélérer chaque réponse.
Peut-on utiliser un serveur Proxmox existant ?
Cela peut convenir si matériel, groupes IOMMU, pilotes et affectation GPU sont adaptés. Il faut aussi des réserves pour les autres services et des procédures de maintenance, sauvegarde et restauration adaptées. Nous vérifions concrètement la plateforme existante.
Les documents internes servent-ils à entraîner le modèle ?
Ce n’est souvent pas nécessaire pour une recherche de connaissances. Le RAG recherche les extraits pertinents et autorisés, puis les transmet au modèle comme contexte. Modifier les poids est une autre mesure, à justifier séparément.
Quand un service externe est-il plus économique ?
Un service externe peut mieux convenir en cas d’utilisation faible ou très variable, d’exigences particulières de modèle ou de capacité d’exploitation insuffisante. Nous comparons coûts, flux de données, qualité et exploitation sur la durée prévue.
Suivre ensemble modèles, charge et coûts.
Outre utilisation GPU et temps de réponse, nous étudions le coût par tâche utile. Avant déploiement, chaque mise à jour de modèle est comparée sur les tests validés. Taux d’erreur, files, limites mémoire et pannes nécessitent des responsables identifiés et un retour. Un service externe de remplacement n’est envisagé que si catégorie de données et validation l’autorisent.
Parlons de votre cas d’usage.
Que faut-il simplifier, quelles données sont concernées et quels systèmes existent déjà ? Nous en déduisons une entrée pertinente et une prochaine étape limitée.