Ce que nous faisons · expertise

Intelligence artificielle

Vos modèles chez vous, vos données n'en sortent jamais.

Inférence et affinage sur votre infrastructure : dimensionnement GPU, architecture de service, agents et protocole MCP. Nous privilégions les réponses sourcées — une réponse qui ne cite pas son document n'est pas exploitable dans un métier régulé.

vLLMTritonKServeKubeflowMCPpgvector
Modes adaptés
Audit & architecture · Régie
Chaîne d'inférence
KServe · LeaderWorkerSet · vLLM
Accélérateurs
NVIDIA GPU Operator, sur votre matériel
Poids des modèles
Déposés dans un volume interne, montés en lecture seule
Sortie réseau du service
Aucune, par défaut
Modèles de fondation
Nous n'en entraînons pas

Méthode

Le dimensionnement décide du nombre de machines.

Le dimensionnement se calcule avant de choisir un modèle, et il décide du budget matériel. Les poids doivent tenir en mémoire d'accélérateur à côté du cache d'attention, qui grandit avec le nombre de sessions simultanées et la longueur du contexte. Tant que les poids tiennent sur un GPU, une réplique est un pod et une carte. Quand ils n'y tiennent plus, on les répartit sur plusieurs cartes d'une même machine. Quand ils ne tiennent plus dans une machine, il faut plusieurs machines pour servir un seul modèle.

C'est là que Kubernetes seul ne suffit plus. Un Deployment ne sait pas que quatre pods forment un modèle : il les ordonnance séparément, en redémarre un sans les autres, et un groupe à moitié placé ne sert rien du tout. LeaderWorkerSet traite le groupe comme l'unité — un meneur, des suiveurs, placés, redémarrés et mis à l'échelle ensemble. C'est la pièce qui rend une réplique multi-nœuds réellement exploitable, et c'est pour cela qu'elle est installée dans la plateforme avant d'en avoir besoin.

La chaîne que nous exploitons est celle-ci : KServe pour la déclaration du service, LeaderWorkerSet pour les répliques réparties, le NVIDIA GPU Operator pour les pilotes, le plugin de périphérique et la métrologie DCGM, vLLM comme moteur d'inférence, une passerelle Envoy en entrée avec un ordonnanceur conscient du tokenizer. Elle tourne sur l'infrastructure d'un client, décrite en GitOps, aux côtés du stockage Ceph, de PostgreSQL opéré par CloudNativePG et d'OpenBao.

Le manifeste ci-contre en est extrait, et un de ses détails porte l'essentiel : le point de contrôle est déjà quantifié en FP8 lorsque nous le déposons. Ce n'est pas une note de qualité, c'est une décision de dimensionnement. L'empreinte disque et mémoire tombe de moitié environ, le démarrage ne comporte plus de passe de quantification, et le schéma choisi — poids en flottant huit bits par canal, activations dynamiques par jeton — est plus serré que celui que le moteur appliquerait de lui-même. Les poids arrivent par un travail de téléchargement dans un volume interne, montés ensuite en lecture seule : au démarrage, le service ne va rien chercher sur Internet.

Ce que cela produit se mesure mal, et se mesure quand même. Sur une mission d'exploitation documentaire, l'équipe cliente a estimé à 1 h (1) le temps rendu à chaque collaborateur équipé. C'est une estimation déclarative, sur un seul client, et elle ne se généralise pas.

platform-apps/kserve/model-serving/… KServe · LLMInferenceService · YAML
apiVersion: serving.kserve.io/v1alpha2
kind: LLMInferenceService
metadata:
  name: …
spec:
  model:
    # Local copy staged by the download Job (avoids the presets' 1Gi
    # storage-initializer cap). Mounted at /mnt/models by the controller.
    #
    # Pre-quantized FP8 build rather than the BF16 repo quantized at load:
    # 8-bit float weights (channel-wise, static) with per-token dynamic
    # activations, which is a tighter scheme than the per-tensor default
    # vLLM applies for --quantization fp8. And no quantization pass
    # during startup.
    uri: pvc://…
    name: …
  replicas: 1
  # Managed gateway + route + EPP scheduler (the llm-d data path via the
  # envoy GatewayClass installed by platform-apps/envoy-gateway).
  router:
    gateway: {}
    route: {}
  template:
    containers:
      - name: main
        image: vllm/vllm-openai:v0.24.0
        resources:
          limits:
            nvidia.com/gpu: "1"
        # Injected via the llmd preset's VLLM_ADDITIONAL_ARGS launch-script hook.
        env:
          - name: VLLM_ADDITIONAL_ARGS
            value: "--kv-cache-dtype fp8 --enable-auto-tool-choice …"
Manifeste de service d'inférence extrait d'un dépôt GitOps que nous exploitons. Rédigé avant publication : noms d'hôte, de cluster, de volume et de modèle servi retirés, requêtes et limites processeur et mémoire retirées. Les commentaires sont ceux du dépôt. Un détail d'exploitation ne tient pas dans l'extrait : l'ordonnanceur qui route selon le tokenizer monte le même volume de poids, et ce volume n'accepte qu'un nœud à la fois — l'ordonnanceur doit donc être placé sur le nœud de la charge, faute de quoi il se bloque au montage. Ce genre de contrainte n'apparaît qu'en production.

Périmètre

Ce que nous faisons, ce que nous ne faisons pas.

Tout commence par le matériel disponible et par la nature réelle des documents.

Ce que nous faisons

  • Dimensionner : modèle, nombre de cartes, mémoire, cache d'attention, débit visé — avec le calcul écrit et ses hypothèses, pas une fourchette.
  • Déployer la chaîne sur votre matériel : KServe, vLLM, LeaderWorkerSet pour les répliques réparties, GPU Operator, files d'attente et quotas par équipe.
  • Choisir et appliquer un schéma de quantification, et mesurer ce qu'il coûte en qualité sur vos propres documents.
  • Affiner un modèle ouvert sur vos données, sur votre infrastructure, sans que le jeu d'entraînement quitte votre périmètre.
  • Construire des réponses sourcées : chaque réponse cite le document dont elle vient, condition d'usage dans un métier régulé.
  • Exposer les outils par MCP, avec le même contrôle d'accès et le même journal que le reste du socle.

Ce que nous ne faisons pas

  • Nous n'entraînons pas de modèle de fondation. Nous partons de modèles ouverts publiés par d'autres, et nous disons lesquels et sous quelle licence.
  • Nous ne revendons pas sous notre marque l'API d'un fournisseur tiers, et nous ne faisons pas transiter vos données par un service dont nous ne portons pas la juridiction.
  • Nous ne jugeons pas un modèle sur un classement public : l'évaluation se fait sur vos documents, avec vos métiers, et son protocole est écrit.

Missions

Deux engagements comparables.

Décrits par le dispositif mis en place et par ce qu'il a produit.

Data & IA · mission ponctuelle

Groupe industriel

Une chaîne d'ingestion qui accepte les documents tels qu'ils arrivent, un socle de tables ouvertes interrogeable en SQL, une indexation sémantique — et une règle côté restitution : une réponse sans document source n'est pas une réponse.

TrinoApache IcebergOCRpgvectorMCP

Cloud souverain · en cours

Montpellier Métropole

Un cloud interne de données et d'inférence, déployé sous maîtrise publique : les modèles tournent sur l'infrastructure de la collectivité, et les journaux restent de son côté.

KubernetesvLLMKeycloakPostgreSQLMinIO

Voir les quatre missions

Prendre contact

Commencer par le matériel et les documents.

Avant de parler de modèle, nous regardons trois choses : le matériel dont vous disposez, la nature réelle de vos documents, et ce que votre politique de journalisation autorise. Le dimensionnement se calcule ; il ne se devine pas, et il ne se copie pas d'un autre client.