Grandes modelos de linguagem explicados: como funcionam os LLMs e como executar os seus próprios no Kubernetes

Um guia em inglês simples para modelos de linguagem grande — o que são, como realmente funcionam nos bastidores e como executar o seu próprio no Kubernetes. Escrito tanto para gerentes não técnicos quanto para engenheiros: dê uma olhada nas analogias e, em seguida, acesse o YAML quando estiver pronto para implantar.

1. O que é realmente um modelo de linguagem grande?

Imagine o preenchimento automático no seu telefone. Você digita "Ligo para você quando chegar" e sugere "casa". Esse é um modelo de linguagem minúsculo: ele viu muitas mensagens de texto e aprendeu quais palavras tendem a seguir quais. UM Grande Modelo de Linguagem é a mesma ideia ampliada por um fator de milhões – treinada não em seus textos, mas em uma grande fatia da Internet pública, livros, códigos e documentação.

A palavra "grande" está fazendo um trabalho de verdade. Esses modelos contêm bilhões de números internos (chamados parâmetros) que são ajustados durante o treinamento. Quando as pessoas dizem que um modelo é "7B" ou "70B", elas querem dizer 7 bilhões ou 70 bilhões de parâmetros. Mais parâmetros geralmente significam mais capacidade — e um maior apetite por memória e computação.

Um modelo mental útil para gestores: um LLM é um assistente de pós-graduação incansável e muito lido. Ele leu mais do que qualquer ser humano jamais conseguiria, rascunha rapidamente e nunca fica entediado - mas às vezes afirma com total confiança coisas que estão simplesmente erradas e não tem memória de ontem, a menos que você lembre.

2. Como eles realmente funcionam

Sob o capô, há cinco ideias. Você não precisa de matemática para segui-los – cada um tem uma analogia cotidiana.

2.1 Tokens — cortar texto em pedaços

Os modelos não leem palavras inteiras. Eles quebram o texto em fichas: pedaços comuns de caracteres. "Kubernetes" pode se tornar Kub + ernetes; "correr" pode ser run + ning. Aproximadamente, 1 token ≈ 0,75 palavras em inglês, então 1.000 tokens equivalem a cerca de 750 palavras. Isso é importante comercialmente: fatura de APIs hospedada por token e um modelo janela de contexto (quanto ele pode “ver” de uma vez) é medido em tokens.

2.2 Embeddings – transformando palavras em coordenadas de significado

Cada token é convertido em uma longa lista de números — um incorporação - que representa seu significado como um ponto no espaço. Palavras usadas de maneira semelhante acabam próximas umas das outras. “Rei” e “rainha” sentam-se juntos; “rei” e “banana” ficam distantes um do outro. É assim que uma máquina que só faz aritmética pode manipular significado: o significado foi transformado em geometria.

2.3 O Transformador e a “atenção” — o avanço de 2017

A arquitetura por trás de cada LLM moderna é a Transformador. Seu truque principal é chamado atenção: ao processar uma palavra, o modelo analisa todas as outras palavras da frase e decide quais são relevantes. Em “O troféu não cabia na mala porque isto era muito grande", atenção é o que permite ao modelo descobrir que "isso" se refere ao troféu, não à mala. Atenção é por que esses modelos lidam tão bem com contexto, nuances e referências de longo alcance - e por que eles precisam de tanta computação, porque cada palavra atende a todas as outras palavras.

2.4 Treinamento — três etapas

1. Pré-treinamento: o modelo vê bilhões de frases com a última palavra oculta e é solicitado a adivinhá-la. Entenda errado, altere os parâmetros, repita – trilhões de vezes. É aqui que ele absorve gramática, fatos, padrões de raciocínio e código. É também a parte cara, custando milhões de libras no período GPU.
2. Afinação: o modelo bruto é então treinado com base em exemplos selecionados de comportamento útil de perguntas e respostas, de modo que funciona como um assistente em vez de um preenchimento automático.
3. Alinhamento (RLHF): finalmente, os humanos classificam as respostas do modelo e esse feedback é usado para torná-lo mais útil, honesto e seguro. É por isso que um modelo de chat recusa solicitações prejudiciais e adota um tom consistente.

2.5 Inferência – como ela responde a você

Quando você envia um prompt, o modelo gera a resposta um token de cada vez: prevê o próximo token mais provável, anexa-o, depois prevê o próximo e assim por diante - como uma pessoa rápida e bem lida escrevendo palavra por palavra sem planejar primeiro a frase inteira. Uma configuração chamada temperatura controla o quão aventureiro é: a baixa temperatura fornece respostas seguras e repetíveis (bom para código e extração); a alta temperatura fornece respostas criativas e variadas (boas para brainstorming). Este processo token por token é chamado inferência, e é a parte pela qual você paga na produção – cada solicitação queima ciclos GPU.

3. Em que os LLMs são bons e ruins

Conhecer as arestas da ferramenta evita erros caros.

A solução para a maioria deles é RAG (geração aumentada de recuperação): em vez de confiar na memória do modelo, você busca documentos relevantes de seus próprios sistemas e os cola no prompt, para que o modelo responda dos seus dados. É assim que você constrói um chatbot em seu wiki interno sem que o modelo invente coisas.

4. O vocabulário, decodificado

5. Por que executar seu próprio LLM?

APIs hospedados (OpenAI, Anthropic e outros) são a maneira mais rápida de começar e são excelentes. Mas há quatro razões pelas quais as organizações optam por auto-hospedar um modelo de peso aberto, como Llama, Mistral, Qwen ou Gemma:

• Privacidade e conformidade de dados. Os dados confidenciais nunca saem da sua rede – importantes para os setores de saúde, finanças, jurídico e público.
• Custo em escala. Acima de um certo volume de solicitação constante, um GPU que você possui pode ser mais barato por token do que pagar um API.
• Controle e estabilidade. O modelo nunca muda abaixo de você e você não está sujeito aos limites de taxas ou depreciações de um fornecedor.
• Latência e uso offline. Inferência junto à sua aplicação ou no local sem dependência de internet.

A compensação é que agora você possui o hardware, o dimensionamento e a confiabilidade – que é exatamente o que o Kubernetes faz bem.

6. A realidade do hardware (leia isto antes de implantar)

Os pesos de uma LLM devem caber na memória GPU (VRAM). Uma regra básica:

Dois mecanismos de serviço dominam as implantações reais:

• Ollama - a rampa de acesso mais fácil. Ótimo para desenvolvimento, ferramentas internas e nós CPU ou GPU únicos. Extrai modelos quantizados com um comando.
• vLLM - o carro-chefe da produção. Alto rendimento, agrupa muitas solicitações e expõe um API compatível com OpenAI portanto, seu código existente funciona com uma alteração de URL de uma linha. (Hugging Face TGI é uma alternativa próxima.)

7. Implantando sua própria LLM na Kubernetes

Tudo abaixo pressupõe um cluster com pelo menos um nó GPU e o Plug-in de dispositivo NVIDIA instalado, o que expõe GPUs como o recurso programável nvidia.com/gpu. Vamos construí-lo peça por peça.

7.1 Um namespace e um local para armazenar pesos de modelo

Os arquivos de modelo são grandes (gigabytes) e o download é lento, por isso os armazenamos em cache em um PersistentVolumeClaim em vez de puxar novamente a cada reinicialização do 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 Opção A — Ollama (início fácil)

Ollama é ideal para uma primeira implantação ou uma ferramenta interna. Isso funciona com um GPU; exclua o nvidia.com/gpu limite para executar apenas CPU em um nó robusto.

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

Quando o pod estiver em execução, coloque um modelo no cache e converse com ele:

# 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 Opção B — vLLM (rendimento de produção, compatível com OpenAI)

Para tráfego real, o vLLM atende muitas solicitações simultâneas com eficiência e fala o dialeto OpenAI API. Modelos fechados (como Llama) precisam de um token Hugging Face, armazenado como um segredo.

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

Como o vLLM é compatível com OpenAI, o código do aplicativo só precisa do URL no cluster – sem alterações no 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 Expondo com um 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 Dimensionamento — e por que é diferente com GPUs

Você pode dimensionar automaticamente, mas lembre-se cada réplica precisa de seu próprio GPU inteiro - você não pode compartilhar um fracionadamente no caso simples, e não faz sentido escalar além dos GPUs que você possui fisicamente. Escale em uma fila ou sinal de taxa de solicitação (KEDA é excelente aqui) em vez de 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. Uma lista de verificação pragmática de implementação

1. Protótipo em um API hospedado para validar o caso de uso antes de comprar GPUs.
2. Escolha um modelo de pesos abertos que se adapta ao seu hardware (comece com um modelo 7–8B, quantizado).
3. Comece com Ollama para um piloto interno; graduar-se para vLLM quando você precisar de rendimento.
4. Adicionar RAG sobre seus próprios documentos para eliminar alucinações e manter as respostas atualizadas.
5. Mantenha um humano informado sempre que uma resposta errada acarreta um custo real.
6. Meça o custo de inferência e a latência por solicitação - essa é a sua verdadeira economia unitária.