大型语言模型解释：法学硕士如何工作以及如何在 Kubernetes 上运行自己的语言模型

大型语言模型的简明英语指南 — 它们是什么、它们在幕后如何实际工作以及如何在 Kubernetes 上运行您自己的语言模型。为非技术经理和工程师等编写：浏览类比，然后在准备部署时放入 YAML。

1. 什么是大型语言模型？

想象一下手机上的自动完成功能。你输入“我一到就给你打电话”，它会提示“回家”。这是一个微小的语言模型：它已经看到了大量的文本消息，并了解了哪些单词倾向于跟随哪些单词。一个 大的 语言模型是将相同的想法放大数百万倍——不是根据文本进行训练，而是根据公共互联网、书籍、代码和文档的大部分进行训练。

这个词 “大的” 正在做实实在在的工作。这些模型包含数十亿个内部数字（称为 参数）在训练期间进行调整。当人们说模型是“7B”或“70B”时，他们的意思是 70 亿或 700 亿个参数。更多参数通常意味着更多功能，以及对内存和计算的更大需求。

对管理者有用的心理模型： 法学硕士是一位不知疲倦、博览群书的研究生助理。 它的阅读量比任何人类都多，起草速度很快，而且永远不会感到无聊——但它有时会完全自信地陈述一些完全错误的事情，并且除非你提醒它，否则它不会记住昨天的事情。

2. 它们的实际工作原理

在幕后有五个想法。你不需要数学来理解它们——每一个都有一个日常类比。

2.1 Tokens——将文本切成碎片

模型不会阅读整个单词。他们将文本分解成 代币：常见的字符块。 “Kubernetes”可能会成为 Kub + ernetes; “跑步”可能是 run + ning。大致， 1 个 token ≈ 0.75 个英语单词，所以 1,000 个标记大约是 750 个单词。这在商业上很重要：托管 API 按令牌计费，以及模型的 上下文窗口 （它一次可以“看到”多少）以代币来衡量。

2.2 嵌入——将单词转化为意义的坐标

每个标记都被转换成一长串数字——一个 嵌入 ——这代表了它作为空间中的一个点的含义。以相似方式使用的单词最终会彼此接近。 “国王”和“王后”坐在一起； “国王”和“香蕉”坐得很远。这就是一台只做算术的机器可以进行操作的方式 意义：意义已转化为几何。

2.3 Transformer 与“关注”——2017 年的突破

每个现代法学硕士背后的架构都是 变压器。它的关键技巧称为 注意力：在处理一个单词时，模型会回顾句子中的每个其他单词并决定哪些单词是相关的。在“奖杯无法放入手提箱，因为 它 太大了”，注意力让模型知道“它”指的是奖杯，而不是手提箱。注意力是为什么这些模型能够很好地处理上下文、细微差别和远程引用，以及为什么它们需要如此多的计算，因为每个单词都会涉及到其他单词。

2.4 训练——三个阶段

1. 预训练： 该模型会显示数十亿个句子，其中最后一个单词被隐藏，并被要求猜测它。出错了，微调参数，重复数万亿次。这是它吸收语法、事实、推理模式和代码的地方。这也是最昂贵的部分，花费了数百万英镑的 GPU 时间。
2. 微调： 然后，原始模型会根据有用的问答行为的精选示例进行训练，因此它的作用就像助手而不是自动完成功能。
3. 对准（RLHF）： 最后，人类对模型的答案进行排名，并使用反馈来使其更加有用、诚实和安全。这就是聊天模型拒绝有害请求并采用一致语气的原因。

2.5 推理——它如何回答你

当您发送提示时，模型会生成回复 一次一个令牌：它预测最有可能的下一个标记，附加它，然后预测下一个，依此类推——就像一个快速、阅读能力强的人逐字写作而不首先计划整个句子一样。一个名为 温度 控制它的冒险程度：低温给出安全、可重复的答案（有利于编码和提取）；高温给出了创造性的、多样化的答案（有利于头脑风暴）。这个逐个令牌的过程称为 推理，这是您在生产中支付的部分 - 每个请求都会消耗 GPU 周期。

3. LLM 的优缺点

了解工具的边缘可以防止代价高昂的错误。

大多数问题的解决方法是 RAG（检索增强生成）：您不信任模型的内存，而是从自己的系统中获取相关文档并将其粘贴到提示中，以便模型回答 根据您的数据。这就是您如何在内部 wiki 上构建聊天机器人，而无需模型进行弥补。

4. 词汇，解码

5. 为什么要经营自己的法学硕士？

托管 API（OpenAI、Anthropic 等）是最快的启动方式，而且非常出色。但组织选择自行托管开放权重模型（例如 Llama、Mistral、Qwen 或 Gemma）有四个原因：

• 数据隐私与合规性。 敏感数据永远不会离开您的网络——对于医疗保健、金融、法律和公共部门非常重要。
• 规模成本。 在一定的稳定请求量之上，您拥有的 GPU 的每个代币可能比支付 API 更便宜。
• 控制与稳定性。 该模型在您的领导下永远不会改变，并且您不受供应商的速率限制或弃用的约束。
• 延迟和离线使用。 在您的应用程序旁边或本地进行推理，不依赖于互联网。

权衡是 您现在拥有硬件、扩展性和可靠性 ——这正是 Kubernetes 所擅长的。

6. 硬件现实（在部署之前阅读本文）

LLM 的权重必须适合 GPU 内存 (VRAM)。粗略的经验法则：

两个服务引擎在实际部署中占主导地位：

• 奥拉玛 — 最简单的入口匝道。非常适合开发、内部工具以及 CPU 或单 GPU 节点。使用一个命令即可提取量化模型。
• 法学硕士 ——生产主力。高吞吐量，批处理许多请求，并公开 OpenAI 兼容 API 因此，您现有的代码只需更改一行 URL 即可工作。 （Hugging Face TGI 是一个接近的选择。）

7. 在 Kubernetes 上部署自己的 LLM

以下所有内容均假设集群至少有一个 GPU 节点，并且 NVIDIA 设备插件 已安装，它将 GPU 公开为可调度资源 nvidia.com/gpu。我们将一点一点地构建它。

7.1 命名空间和存储模型权重的地方

模型文件很大（千兆字节）并且下载速度很慢，因此我们将它们缓存在 持续成交量索赔 而不是在每次 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 选项 A — 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

Pod 运行后，将模型拉入缓存并与其聊天：

# 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，并且扩展超出您实际拥有的 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. 从奥拉马开始 对于内部飞行员；毕业到 法学硕士 当您需要吞吐量时。
4. 添加RAG 查看您自己的文件，以减少幻觉并保持最新的答案。
5. 让人类了解情况 任何错误的答案都会带来真正的成本。
6. 衡量推理成本和延迟 根据要求——这就是您真正的单位经济效益。