Grote taalmodellen uitgelegd: hoe LLM's werken en hoe u uw eigen kunt gebruiken op Kubernetes

Een duidelijke Engelse handleiding voor grote taalmodellen: wat ze zijn, hoe ze feitelijk onder de motorkap werken en hoe u uw eigen modellen kunt gebruiken op Kubernetes. Geschreven voor zowel niet-technische managers als ingenieurs: blader door de analogieën en duik vervolgens in de YAML wanneer u klaar bent om te implementeren.

1. Wat is een groot taalmodel eigenlijk?

Stel je de automatische aanvulling op je telefoon voor. Je typt 'Ik bel je als ik er ben' en er wordt 'thuis' voorgesteld. Dat is een klein taalmodel: het heeft veel sms-berichten gezien en geleerd welke woorden vaak volgen. A Groot Taalmodel is hetzelfde idee, opgeschaald met een factor miljoenen – niet getraind op uw teksten, maar op een groot deel van het openbare internet, boeken, code en documentatie.

Het woord "groot" doet echt werk. Deze modellen bevatten miljarden interne nummers (de zogenaamde parameters) die tijdens de training worden afgestemd. Als mensen zeggen dat een model '7B' of '70B' is, bedoelen ze 7 miljard of 70 miljard parameters. Meer parameters betekenen over het algemeen meer mogelijkheden – en een grotere behoefte aan geheugen en rekenkracht.

Een nuttig mentaal model voor managers: een LLM is een onvermoeibare, zeer belezen afgestudeerde assistent. Het heeft meer gelezen dan enig mens ooit zou kunnen, schrijft snel en verveelt zich nooit – maar het zegt soms met volledig vertrouwen dingen die gewoonweg verkeerd zijn, en het heeft geen herinnering aan gisteren, tenzij je het eraan herinnert.

2. Hoe ze eigenlijk werken

Onder de motorkap liggen vijf ideeën. Je hebt geen wiskunde nodig om ze te volgen; ze hebben allemaal een alledaagse analogie.

2.1 Tokens — tekst in stukjes hakken

Modellen lezen geen hele woorden. Ze breken tekst in tokens: gewone stukjes karakter. "Kubernetes" zou kunnen worden Kub + ernetes; ‘lopen’ zou kunnen zijn run + ning. Grofweg, 1 token ≈ 0,75 Engelse woorden, dus 1.000 tokens zijn ongeveer 750 woorden. Dit is commercieel van belang: de gehoste APIs-factuur per token en die van een model contextvenster (hoeveel het in één keer kan "zien") wordt gemeten in tokens.

2.2 Inbedding – woorden omzetten in betekeniscoördinaten

Elk token wordt omgezet in een lange lijst met getallen – een inbedden – dat de betekenis ervan vertegenwoordigt als een punt in de ruimte. Woorden die op soortgelijke wijze worden gebruikt, komen bij elkaar terecht. "Koning" en "koningin" zitten dicht bij elkaar; "koning" en "banaan" zitten ver uit elkaar. Dit is hoe een machine die alleen rekenkunde doet, kan manipuleren betekenis: betekenis is omgezet in geometrie.

2.3 De Transformer en ‘aandacht’ – de doorbraak van 2017

De architectuur achter elke moderne LLM is de Transformator. De belangrijkste truc wordt genoemd aandacht: bij het verwerken van een woord kijkt het model terug naar elk ander woord in de zin en beslist welke relevant zijn. In "De trofee paste niet in de koffer omdat Het was te groot", zorgt aandacht ervoor dat het model erachter komt dat "het" verwijst naar de trofee en niet naar de koffer. Aandacht is de reden waarom deze modellen zo goed omgaan met context, nuance en langeafstandsreferenties - en waarom ze zoveel rekenkracht nodig hebben, omdat elk woord rekening houdt met elk ander woord.

2.4 Training — drie fasen

1. Vooropleiding: het model krijgt miljarden zinnen te zien waarbij het laatste woord verborgen is en wordt gevraagd het te raden. Begrijp het verkeerd, verleg de parameters, herhaal – biljoenen keren. Dit is waar het grammatica, feiten, redeneerpatronen en code absorbeert. Het is ook het dure onderdeel, dat in GPU-tijd miljoenen ponden kost.
2. Fijnafstemming: Het onbewerkte model wordt vervolgens getraind op samengestelde voorbeelden van nuttig vraag-en-antwoordgedrag, zodat het fungeert als een assistent in plaats van als een automatische aanvulling.
3. Uitlijning (RLHF): Ten slotte rangschikken mensen de antwoorden van het model en wordt die feedback gebruikt om het nuttiger, eerlijker en veiliger te maken. Dit is de reden waarom een ​​chatmodel schadelijke verzoeken afwijst en een consistente toon aanneemt.

2.5 Inferentie – hoe het u antwoordt

Wanneer u een prompt verzendt, genereert het model het antwoord één teken tegelijk: het voorspelt het meest waarschijnlijke volgende token, voegt het toe, voorspelt vervolgens het volgende, enzovoort - zoals een snelle, goed gelezen persoon woord voor woord schrijft zonder eerst de hele zin te plannen. Een instelling genaamd temperatuur bepaalt hoe avontuurlijk het is: lage temperatuur geeft veilige, herhaalbare antwoorden (goed voor code en extractie); hoge temperatuur geeft creatieve, gevarieerde antwoorden (goed voor brainstormen). Dit token-voor-token-proces wordt aangeroepen gevolgtrekking, en het is het deel waarvoor u betaalt tijdens de productie: bij elk verzoek worden GPU-cycli verbrand.

3. Waar LLM's goed en slecht in zijn

Het kennen van de randen van het gereedschap voorkomt dure fouten.

De oplossing voor de meeste hiervan is RAG (ophaalbare generatie): in plaats van het geheugen van het model te vertrouwen, haalt u relevante documenten uit uw eigen systemen en plakt u deze in de prompt, zodat het model antwoordt uit uw gegevens. Zo bouw je een chatbot over je interne wiki zonder dat het model dingen verzint.

4. De woordenschat, gedecodeerd

5. Waarom uw eigen LLM gebruiken?

Gehoste API's (OpenAI, Anthropic en andere) zijn de snelste manier om te starten en zijn uitstekend. Maar er zijn vier redenen waarom organisaties ervoor kiezen om zelf een model met open gewichten te hosten, zoals Llama, Mistral, Qwen of Gemma:

• Gegevensprivacy en naleving. Gevoelige gegevens verlaten uw netwerk nooit: belangrijk voor de gezondheidszorg, de financiële sector, de juridische sector en de publieke sector.
• Kosten op schaal. Boven een bepaald stabiel verzoekvolume kan een GPU die u bezit per token goedkoper zijn dan het betalen van een API.
• Controle en stabiliteit. Het model verandert nooit onder u, en u bent niet onderworpen aan tarieflimieten of beëindigingen van een leverancier.
• Latentie en offline gebruik. Gevolgtrekking naast uw toepassing, of on-premises zonder internetafhankelijkheid.

De wisselwerking is dat u bent nu eigenaar van de hardware, schaalbaarheid en betrouwbaarheid – en dat is precies waar Kubernetes goed in is.

6. De hardwarerealiteit (lees dit voordat u het implementeert)

De gewichten van een LLM moeten in het GPU-geheugen (VRAM) passen. Een grove vuistregel:

Twee dienende motoren domineren echte implementaties:

• Ollama - de gemakkelijkste oprit. Ideaal voor ontwikkeling, interne tools en CPU- of single-GPU-nodes. Haalt gekwantiseerde modellen op met één opdracht.
• vLLM – het productiewerkpaard. Hoge doorvoer, groepeert veel verzoeken en stelt een OpenAI-compatibele API zodat uw bestaande code werkt met een URL-wijziging van één regel. (Hugging Face TGI is een goed alternatief.)

7. Uw eigen LLM implementeren op Kubernetes

Alles hieronder gaat uit van een cluster met ten minste één GPU-knooppunt en de NVIDIA-apparaatplug-in geïnstalleerd, waardoor GPUs als de planbare bron wordt weergegeven nvidia.com/gpu. We bouwen het stukje voor stukje op.

7.1 Een naamruimte en een plaats om modelgewichten op te slaan

Modelbestanden zijn groot (gigabytes) en langzaam te downloaden, dus we cachen ze op een PersistentVolumeClaim in plaats van opnieuw te trekken bij elke herstart van de 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 Optie A — Ollama (de gemakkelijke start)

Ollama is ideaal voor een eerste implementatie of een interne tool. Dit draait het met één GPU; verwijder de nvidia.com/gpu limiet om alleen CPU op een krachtig knooppunt uit te voeren.

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

Zodra de pod draait, trek je een model naar de cache en chat je ermee:

# 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 Optie B — vLLM (productiedoorvoer, OpenAI-compatibel)

Voor echt verkeer verwerkt vLLM veel gelijktijdige verzoeken efficiënt en spreekt het OpenAI API-dialect. Gated modellen (zoals Llama) hebben een Hugging Face-token nodig, opgeslagen als een geheim.

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

Omdat vLLM OpenAI-compatibel is, heeft de applicatiecode alleen de URL in het cluster nodig – geen SDK-wijzigingen:

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 Het blootstellen met een Ingress

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 Schalen — en waarom dit anders is bij GPUs

U kunt automatisch schalen, maar onthoud dit elke replica heeft zijn eigen volledige GPU nodig - in het eenvoudige geval kun je er geen fractioneel delen, en het heeft geen zin om verder te schalen dan de GPU's die je fysiek hebt. Schaal op basis van een wachtrij- of verzoeksnelheidssignaal (KEDA is hier uitstekend) in plaats van 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. Een pragmatische uitrolchecklist

1. Prototype op een gehoste API om de use case te valideren voordat u GPU's koopt.
2. Kies een model met open gewichten die bij uw hardware past (begin met een 7–8B-model, gekwantiseerd).
3. Begin met Ollama voor een interne pilot; afstuderen aan vLLM wanneer u doorvoer nodig heeft.
4. Voeg RAG toe over uw eigen documenten om hallucinaties te verminderen en de antwoorden actueel te houden.
5. Houd een mens op de hoogte overal waar een verkeerd antwoord reële kosten met zich meebrengt.
6. Meet de inferentiekosten en latentie per verzoek – dat is uw echte eenheidseconomie.