Explication des grands modèles de langage : comment fonctionnent les LLM et comment exécuter les vôtres sur Kubernetes

Un guide en anglais simple sur les grands modèles linguistiques : ce qu'ils sont, comment ils fonctionnent réellement sous le capot et comment exécuter les vôtres sur Kubernetes. Écrit pour les responsables non techniques et les ingénieurs : parcourez les analogies, puis accédez au YAML lorsque vous êtes prêt à déployer.

1. Qu'est-ce qu'un grand modèle de langage, réellement ?

Imaginez la saisie semi-automatique sur votre téléphone. Vous tapez « Je vous appellerai quand je reçois » et cela suggère « à la maison ». Il s’agit d’un petit modèle de langage : il a vu beaucoup de messages texte et a appris quels mots ont tendance à suivre lesquels. UN Grand Le modèle linguistique est la même idée multipliée par plusieurs millions – formé non pas sur vos textes mais sur une grande partie de l'Internet public, des livres, du code et de la documentation.

Le mot "grand" fait un vrai travail. Ces modèles contiennent des milliards de nombres internes (appelés paramètres) qui sont réglés pendant l'entraînement. Lorsque les gens disent qu'un modèle est « 7B » ou « 70B », ils veulent dire 7 milliards ou 70 milliards de paramètres. Plus de paramètres signifie généralement plus de capacités et un plus grand appétit pour la mémoire et le calcul.

Un modèle mental utile pour les managers : un LLM est un assistant diplômé infatigable et très instruit. Il a lu plus que n'importe quel humain, rédige rapidement et ne s'ennuie jamais - mais il énonce parfois des choses avec une totale confiance qui sont tout simplement fausses, et il n'a aucun souvenir d'hier à moins que vous ne le lui rappeliez.

2. Comment ils fonctionnent réellement

Sous le capot se cachent cinq idées. Vous n’avez pas besoin de mathématiques pour les suivre – chacun a une analogie quotidienne.

2.1 Jetons — découper du texte en morceaux

Les modèles ne lisent pas des mots entiers. Ils décomposent le texte en jetons: morceaux communs de caractères. "Kubernetes" pourrait devenir Kub + ernetes; "courir" pourrait être run + ning. À peu près, 1 jeton ≈ 0,75 mots anglais, donc 1 000 jetons représentent environ 750 mots. Cela est important sur le plan commercial : la facture des API hébergés par jeton et le prix d'un modèle fenêtre contextuelle (ce qu'il peut « voir » à la fois) est mesuré en jetons.

2.2 Embeddings — transformer les mots en coordonnées de sens

Chaque jeton est converti en une longue liste de nombres - un intégration - qui représente sa signification en tant que point dans l'espace. Les mots utilisés de manière similaire se retrouvent les uns à côté des autres. « Le roi » et la « reine » sont assis l'un à côté de l'autre ; « roi » et « banane » sont très éloignés. C'est ainsi qu'une machine qui ne fait que de l'arithmétique peut manipuler signification: le sens s'est transformé en géométrie.

2.3 Le Transformateur et « l'attention » — la percée de 2017

L'architecture derrière chaque LLM moderne est la Transformateur. Son astuce clé s'appelle attention: lors du traitement d'un mot, le modèle examine tous les autres mots de la phrase et décide lesquels sont pertinents. Dans « Le trophée ne rentrait pas dans la valise car il était trop grand", l'attention est ce qui permet au modèle de comprendre que "cela" fait référence au trophée, pas à la valise. L'attention est la raison pour laquelle ces modèles gèrent si bien le contexte, les nuances et les références à longue portée - et pourquoi ils ont besoin de tant de calcul, car chaque mot s'occupe d'un autre mot.

2.4 Formation — trois étapes

1. Pré-formation : le modèle voit des milliards de phrases avec le dernier mot caché et est invité à le deviner. Faites des erreurs, modifiez les paramètres, répétez – des milliards de fois. C’est là qu’il absorbe la grammaire, les faits, les schémas de raisonnement et le code. C’est aussi la partie la plus chère, coûtant des millions de livres en temps GPU.
2. Réglage fin: le modèle brut est ensuite formé sur des exemples sélectionnés de comportements de questions et réponses utiles, de sorte qu'il agit comme un assistant plutôt que comme un système de saisie semi-automatique.
3. Alignement (RLHF) : enfin, les humains classent les réponses du modèle et ces commentaires sont utilisés pour le rendre plus utile, honnête et sûr. C'est pourquoi un modèle de chat refuse les demandes nuisibles et adopte un ton cohérent.

2.5 Inférence – comment elle vous répond

Lorsque vous envoyez une invite, le modèle génère la réponse un jeton à la fois: il prédit le prochain jeton le plus probable, l'ajoute, puis prédit le suivant, et ainsi de suite - comme une personne rapide et instruite écrivant mot par mot sans planifier d'abord la phrase entière. Un paramètre appelé température contrôle à quel point c'est aventureux : la basse température donne des réponses sûres et reproductibles (bon pour le code et l'extraction) ; une température élevée donne des réponses créatives et variées (bon pour le brainstorming). Ce processus jeton par jeton est appelé inférence, et c'est la partie que vous payez en production : chaque requête brûle des cycles GPU.

3. Dans quels domaines les LLM sont bons et mauvais

Connaître les bords de l'outil évite des erreurs coûteuses.

Le correctif pour la plupart d'entre eux est RAG (génération augmentée par récupération): au lieu de faire confiance à la mémoire du modèle, vous récupérez les documents pertinents de vos propres systèmes et les collez dans l'invite, afin que le modèle réponde à partir de vos données. C'est ainsi que vous créez un chatbot sur votre wiki interne sans que le modèle n'invente les choses.

4. Le vocabulaire, décodé

5. Pourquoi exécuter votre propre LLM ?

Les API hébergés (OpenAI, Anthropic et autres) sont le moyen le plus rapide de démarrer et sont excellents. Mais il existe quatre raisons pour lesquelles les organisations choisissent d'auto-héberger un modèle à pondération ouverte tel que Llama, Mistral, Qwen ou Gemma :

• Confidentialité et conformité des données. Les données sensibles ne quittent jamais votre réseau, ce qui est important pour les secteurs de la santé, de la finance, du droit et du public.
• Coût à grande échelle. Au-dessus d’un certain volume de demandes stable, un GPU que vous possédez peut être moins cher par jeton que de payer un API.
• Contrôle et stabilité. Le modèle ne change jamais sous vos ordres et vous n'êtes pas soumis aux limites tarifaires ou aux dépréciations d'un fournisseur.
• Latence et utilisation hors ligne. Inférence à côté de votre application ou sur site sans dépendance à Internet.

Le compromis est que vous possédez désormais le matériel, l'évolutivité et la fiabilité – c’est exactement ce pour quoi Kubernetes est bon.

6. La réalité matérielle (lisez ceci avant de déployer)

Les poids d'un LLM doivent tenir dans la mémoire du GPU (VRAM). Une règle générale :

Deux moteurs de service dominent les déploiements réels :

• Ollama — la rampe d'accès la plus simple. Idéal pour le développement, les outils internes et les nœuds CPU ou GPU uniques. Extrait des modèles quantifiés avec une seule commande.
• vLLM - le cheval de bataille de la production. Haut débit, regroupe de nombreuses requêtes et expose un API compatible OpenAI afin que votre code existant fonctionne avec un changement d'URL sur une seule ligne. (Hugging Face TGI est une alternative proche.)

7. Déployer votre propre LLM sur Kubernetes

Tout ce qui suit suppose un cluster avec au moins un nœud GPU et le Plugin de périphérique NVIDIA installé, ce qui expose les GPU en tant que ressource planifiable nvidia.com/gpu. Nous allons le construire pièce par pièce.

7.1 Un espace de noms et un emplacement pour stocker les poids des modèles

Les fichiers de modèles sont volumineux (gigaoctets) et lents à télécharger. Nous les mettons donc en cache sur un Réclamation de volume persistant plutôt que de ré-extraire à chaque redémarrage du pod.

apiVersion: v1
kind: Namespace
metadata:
  name: llm
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: model-cache
  namespace: llm
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi          # weights are big; size generously
  # storageClassName: fast-ssd   # use an SSD class if your cluster offers one

7.2 Option A — Ollama (le démarrage facile)

Ollama est idéal pour un premier déploiement ou un outil interne. Cela l'exécute avec un GPU ; supprimer le nvidia.com/gpu limite pour exécuter CPU uniquement sur un nœud costaud.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ollama
  namespace: llm
  labels:
    app: ollama
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ollama
  template:
    metadata:
      labels:
        app: ollama
    spec:
      containers:
        - name: ollama
          image: ollama/ollama:latest
          ports:
            - containerPort: 11434
          resources:
            requests:
              cpu: "2"
              memory: 8Gi
            limits:
              nvidia.com/gpu: 1        # remove this line for CPU-only
              memory: 16Gi
          volumeMounts:
            - name: models
              mountPath: /root/.ollama
          readinessProbe:
            httpGet:
              path: /
              port: 11434
            initialDelaySeconds: 10
            periodSeconds: 10
      volumes:
        - name: models
          persistentVolumeClaim:
            claimName: model-cache
---
apiVersion: v1
kind: Service
metadata:
  name: ollama
  namespace: llm
spec:
  selector:
    app: ollama
  ports:
    - port: 80
      targetPort: 11434

Une fois le pod exécuté, placez un modèle dans le cache et discutez avec lui :

# pull a quantized model into the PVC (one-off)
kubectl -n llm exec deploy/ollama -- ollama pull llama3

# ask it something from inside the cluster
kubectl -n llm exec deploy/ollama -- \
  ollama run llama3 "Explain Kubernetes in one sentence."

7.3 Option B — vLLM (débit de production, compatible OpenAI)

Pour le trafic réel, vLLM répond efficacement à de nombreuses requêtes simultanées et parle le dialecte OpenAI API. Les modèles fermés (comme Llama) ont besoin d'un jeton Hugging Face, stocké en tant que secret.

apiVersion: v1
kind: Secret
metadata:
  name: hf-token
  namespace: llm
type: Opaque
stringData:
  token: "hf_xxxxxxxxxxxxxxxxxxxxxxxx"   # your Hugging Face access token
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-mistral
  namespace: llm
  labels:
    app: vllm-mistral
spec:
  replicas: 1
  selector:
    matchLabels:
      app: vllm-mistral
  template:
    metadata:
      labels:
        app: vllm-mistral
    spec:
      containers:
        - name: vllm
          image: vllm/vllm-openai:latest
          args:
            - "--model"
            - "mistralai/Mistral-7B-Instruct-v0.3"
            - "--max-model-len"
            - "8192"
            - "--gpu-memory-utilization"
            - "0.90"
          ports:
            - containerPort: 8000
          env:
            - name: HUGGING_FACE_HUB_TOKEN
              valueFrom:
                secretKeyRef:
                  name: hf-token
                  key: token
          resources:
            limits:
              nvidia.com/gpu: 1
          volumeMounts:
            - name: cache
              mountPath: /root/.cache/huggingface
          readinessProbe:
            httpGet:
              path: /health
              port: 8000
            initialDelaySeconds: 60      # first start downloads weights
            periodSeconds: 15
            failureThreshold: 40
      volumes:
        - name: cache
          persistentVolumeClaim:
            claimName: model-cache
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-mistral
  namespace: llm
spec:
  selector:
    app: vllm-mistral
  ports:
    - port: 80
      targetPort: 8000

Étant donné que vLLM est compatible avec OpenAI, le code de l'application n'a besoin que de l'URL du cluster — aucune modification du SDK :

curl http://vllm-mistral.llm.svc.cluster.local/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mistralai/Mistral-7B-Instruct-v0.3",
    "messages": [{"role": "user", "content": "Summarise our refund policy."}],
    "temperature": 0.2
  }'

7.4 L'exposer avec une entrée

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: llm-api
  namespace: llm
  annotations:
    nginx.ingress.kubernetes.io/proxy-read-timeout: "300"   # long generations
spec:
  ingressClassName: nginx
  rules:
    - host: llm.internal.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: vllm-mistral
                port:
                  number: 80

7.5 Mise à l'échelle — et pourquoi c'est différent avec les GPU

Vous pouvez effectuer une mise à l'échelle automatique, mais n'oubliez pas chaque réplique a besoin de son propre GPU entier - vous ne pouvez pas en partager un de manière fractionnée dans le cas simple, et il ne sert à rien d'évoluer au-delà des GPU dont vous disposez physiquement. Évoluez sur une file d'attente ou un signal de taux de requête (KEDA est excellent ici) plutôt que CPU.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: vllm-mistral
  namespace: llm
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: vllm-mistral
  minReplicas: 1
  maxReplicas: 4          # never exceed the number of GPUs in the cluster
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
  # For real LLM scaling, prefer KEDA on a queue depth or
  # requests-per-second metric exported by vLLM, not CPU.

8. Une liste de contrôle de déploiement pragmatique

1. Prototype sur un API hébergé pour valider le cas d'utilisation avant d'acheter des GPU.
2. Choisissez un modèle à poids ouverts qui correspond à votre matériel (commencez par un modèle 7-8B, quantifié).
3. Commencez avec Ollama pour un pilote interne ; diplômé à vLLM lorsque vous avez besoin de débit.
4. Ajouter RAG sur vos propres documents pour réduire les hallucinations et garder les réponses à jour.
5. Gardez un humain au courant partout où une mauvaise réponse entraîne un coût réel.
6. Mesurer le coût et la latence d’inférence par demande - c'est votre véritable économie unitaire.