Объяснение больших языковых моделей: как работают LLM и как запустить свои собственные модели на Kubernetes

Простое руководство по большим языковым моделям — что это такое, как они на самом деле работают и как запустить свои собственные модели на Kubernetes. Написано как для нетехнических менеджеров, так и для инженеров: просмотрите аналогии, а затем перейдите к YAML, когда будете готовы к развертыванию.

1. Что такое большая языковая модель на самом деле?

Представьте себе автозаполнение на вашем телефоне. Вы набираете «Я позвоню вам, когда доберусь», и появляется предложение «домой». Это крошечная языковая модель: она просмотрела множество текстовых сообщений и узнала, какие слова за какими следуют. А Большой Языковая модель — это та же идея, увеличенная в миллионы раз, обученная не на ваших текстах, а на большом фрагменте общедоступного Интернета, книгах, коде и документации.

Слово "большой" делает реальную работу. Эти модели содержат миллиарды внутренних чисел (называемых параметры), которые настраиваются во время тренировки. Когда люди говорят, что модель «7B» или «70B», они имеют в виду 7 миллиардов или 70 миллиардов параметров. Больше параметров обычно означает больше возможностей — и больший аппетит к памяти и вычислениям.

Полезная ментальная модель для менеджеров: LLM — неутомимый и очень начитанный помощник выпускника. Он прочитал больше, чем когда-либо мог бы сделать любой человек, быстро рисует и никогда не скучает — но иногда с полной уверенностью утверждает вещи, которые просто неправильны, и он не помнит вчерашнего дня, если вы ему не напомните.

2. Как они на самом деле работают

Под капотом пять идей. Чтобы понять их, вам не нужна математика — у каждого есть повседневная аналогия.

2.1 Токены — разбиение текста на части

Модели не читают целые слова. Они разбивают текст на жетоны: общие фрагменты символов. «Kubernetes» может стать Kub + ernetes; "бег" может быть run + ning. Грубо, 1 токен ≈ 0,75 английских слов, поэтому 1000 токенов — это около 750 слов. Это имеет коммерческое значение: стоимость размещенного API за токен и стоимость модели контекстное окно (сколько он может «видеть» одновременно) измеряется в токенах.

2.2 Вложения — превращение слов в координаты значения

Каждый токен преобразуется в длинный список чисел — встраивание — это представляет его значение как точку в пространстве. Слова, используемые сходным образом, оказываются рядом друг с другом. «Король» и «королева» сидят близко друг к другу; «король» и «банан» сидят далеко друг от друга. Вот как машина, которая занимается только арифметикой, может манипулировать значение: смысл превратился в геометрию.

2.3 Трансформер и «внимание» — прорыв 2017 года

Архитектура каждого современного LLM — это Трансформатор. Его ключевой трюк называется внимание: при обработке слова модель просматривает каждое второе слово в предложении и решает, какие из них релевантны. В «Трофей не поместился в чемодан, потому что это было слишком большим», внимание — это то, что позволяет модели понять, что «оно» относится к трофею, а не к чемодану. Внимание — это то, почему эти модели так хорошо обрабатывают контекст, нюансы и ссылки на большие расстояния — и почему им нужно так много вычислений, потому что каждое слово учитывает каждое другое слово.

2.4 Обучение — три этапа

1. Предварительная подготовка: модели показывают миллиарды предложений со скрытым последним словом и просят угадать его. Ошибитесь, подтолкните параметры, повторите — триллионы раз. Здесь он впитывает грамматику, факты, модели рассуждения и код. Это также самая дорогая часть, которая во времена GPU стоила миллионы фунтов.
2. Тонкая настройка: затем необработанная модель обучается на тщательно подобранных примерах полезного поведения в виде вопросов и ответов, поэтому она действует как помощник, а не как автозаполнение.
3. Выравнивание (RLHF): наконец, люди ранжируют ответы модели, и эта обратная связь используется, чтобы сделать модель более полезной, честной и безопасной. Вот почему модель чата отклоняет вредоносные запросы и использует последовательный тон.

2.5 Вывод — как он вам отвечает

Когда вы отправляете запрос, модель генерирует ответ. один жетон за раз: он предсказывает наиболее вероятный следующий токен, добавляет его, затем прогнозирует следующий и так далее — как быстрый, начитанный человек, пишущий слово за словом, не планируя предварительно все предложение. Настройка под названием температура контролирует, насколько это рискованно: низкая температура дает безопасные, повторяемые ответы (хорошо для кода и извлечения); высокая температура дает творческие и разнообразные ответы (хорошо для мозгового штурма). Этот процесс «токен за токеном» называется вывод, и это та часть, за которую вы платите в процессе производства — каждый запрос сжигает циклы GPU.

3. В чем LLM хороши и плохи

Знание краев инструмента предотвращает дорогостоящие ошибки.

Исправление для большинства из них RAG (генерация с расширенным поиском): вместо того, чтобы доверять памяти модели, вы извлекаете соответствующие документы из своих собственных систем и вставляете их в подсказку, чтобы модель отвечала из ваших данных. Вот как вы создаете чат-бота на своей внутренней вики без придумывания модели.

4. Словарь, расшифрованный

5. Зачем использовать собственный LLM?

Размещенные API (OpenAI, Anthropic и другие) — это самый быстрый способ начать и они превосходны. Но есть четыре причины, по которым организации предпочитают самостоятельно размещать модели с открытым весом, такие как Llama, Mistral, Qwen или Gemma:

• Конфиденциальность данных и соответствие требованиям. Конфиденциальные данные никогда не покидают вашу сеть, что важно для здравоохранения, финансов, юриспруденции и государственного сектора.
• Стоимость в масштабе. При превышении определенного стабильного объема запросов стоимость токена GPU, которым вы владеете, может оказаться дешевле, чем оплата API.
• Контроль и стабильность. Модель никогда не меняется под вашим руководством, и вы не подпадаете под ограничения или ограничения ставок поставщика.
• Задержка и автономное использование. Вывод рядом с вашим приложением или локально, без зависимости от Интернета.

Компромисс заключается в том, что теперь вы владеете оборудованием, масштабированием и надежностью. — и это именно то, в чем хорош Kubernetes.

6. Аппаратная реальность (прочитайте это перед развертыванием)

Грузы LLM должны помещаться в памяти GPU (VRAM). Грубое практическое правило:

В реальных развертываниях доминируют два обслуживающих механизма:

• Ollama — самый простой съезд. Отлично подходит для разработки, внутренних инструментов и узлов CPU или одиночного GPU. Извлекает квантованные модели одной командой.
• vLLM — производственная рабочая лошадка. Высокая пропускная способность, группирует множество запросов и предоставляет API, совместимый с OpenAI поэтому ваш существующий код работает с изменением URL-адреса в одну строку. (Hugging Face TGI — близкая альтернатива.)

7. Развертывание собственного LLM на Kubernetes

Все нижеследующее предполагает наличие кластера как минимум с одним узлом GPU и Плагин устройства NVIDIA установлен, что предоставляет GPU в качестве планируемого ресурса. nvidia.com/gpu. Мы будем строить его по частям.

7.1 Пространство имен и место для хранения весов модели

Файлы моделей имеют большой размер (гигабайты) и загружаются медленно, поэтому мы кэшируем их на PersistentVolumeClaim вместо повторного запуска при каждом перезапуске модуля.

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 Вариант А — Ollama (легкий старт)

Ollama идеально подходит для первого развертывания или внутреннего инструмента. При этом используется один GPU; удалить nvidia.com/gpu ограничение на запуск только CPU на мощном узле.

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

После запуска модуля поместите модель в кеш и пообщайтесь с ней:

# 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 Вариант B — vLLM (производительная производительность, OpenAI-совместимость)

Для реального трафика vLLM эффективно обслуживает множество одновременных запросов и использует диалект OpenAI API. Закрытые модели (например, Llama) нуждаются в маркере Hugging Face, хранящемся как секрет.

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

Поскольку vLLM совместим с OpenAI, для кода приложения требуется только URL-адрес внутри кластера — никаких изменений в 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 Раскрытие информации с помощью 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 Масштабирование — и чем оно отличается от GPU

Вы можете автомасштабировать, но помните каждой реплике нужен свой целый GPU — в простом случае вы не можете частично поделиться одним устройством, и нет смысла масштабировать его за пределы тех GPU, которые у вас физически есть. Масштабируйтесь по сигналу очереди или скорости запросов (KEDA в этом отношении превосходна), а не по 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. Прагматичный контрольный список внедрения

1. Прототип на размещенном API для проверки варианта использования перед покупкой GPU.
2. Выберите модель с открытыми весами. который подходит для вашего оборудования (начните с модели 7–8B, квантованной).
3. Начните с Ollama для внутреннего пилота; выпускник vLLM когда вам нужна пропускная способность.
4. Добавить RAG над вашими собственными документами, чтобы избавиться от галлюцинаций и поддерживать актуальность ответов.
5. Держите человека в курсе везде, где неправильный ответ влечет за собой реальную цену.
6. Измерение стоимости вывода и задержки по запросу — это ваша истинная юнит-экономика.