大型語言模型解釋：LLM 的工作原理以及如何在 Kubernetes 上執行您自己的語言模型

大型語言模型的簡明英語指南 - 它們是什麼、它們在幕後如何實際工作以及如何在 Kubernetes 上執行您自己的語言模型。為非技術經理和工程師等編寫：瀏覽類比，然後在準備部署時放入 YAML。

1. 什麼是大型語言模型？

想象一下手機上的自動完成功能。你輸入“我一到就給你打電話”，它會提示“回家”。這是一個微小的語言模型：它已經看到了大量的文字訊息，並瞭解了哪些單詞傾向於跟隨哪些單詞。一個 大的 語言模型是將相同的想法放大數百萬倍——不是根據文字進行訓練，而是根據公共網際網路、書籍、程式碼和文件的大部分進行訓練。

這個詞 “大的” 正在做實實在在的工作。這些模型包含數十億個內部數字（稱為 引數）在訓練期間進行調整。當人們說模型是“7B”或“70B”時，他們的意思是 70 億或 700 億個引數。更多引數通常意味著更多功能，以及對記憶體和計算的更大需求。

對管理者有用的心理模型： LLM 是一位孜孜不倦、博覽群書的研究生助理。 它的閱讀量比任何人類都多，起草速度很快，而且永遠不會感到無聊——但它有時會完全自信地陳述一些完全錯誤的事情，並且除非你提醒它，否則它不會記住昨天的事情。

2. 它們的實際工作原理

在幕後有五個想法。你不需要數學來理解它們——每一個都有一個日常類比。

2.1 Tokens——將文字切成碎片

模型不會閱讀整個單詞。他們將文字分解成 代幣：常見的字元塊。 “Kubernetes”可能會變成 Kub + ernetes; “跑步”可能是 run + ning。大致， 1 個 token ≈ 0.75 個英語單詞，所以 1,000 個標記大約是 750 個單詞。這在商業上很重要：託管的 APIs 每個代幣的賬單以及模型的 上下文視窗 （它一次可以“看到”多少）以代幣來衡量。

2.2 嵌入——將單詞轉化為意義的座標

每個標記都被轉換成一長串數字——一個 嵌入 ——這代表了它作為空間中的一個點的含義。以相似方式使用的單詞最終會彼此接近。 “國王”和“王后”坐在一起； “國王”和“香蕉”坐得很遠。這就是一臺只做算術的機器可以進行操作的方式 意義：意義已轉化為幾何。

2.3 Transformer 與“關注”——2017 年的突破

每個現代 LLM 背後的架構都是 變壓器。它的關鍵技巧稱為 注意力：在處理一個單詞時，模型會回顧句子中的每個其他單詞並決定哪些單詞是相關的。在“獎盃無法放入手提箱，因為 它 太大了”，注意力讓模型知道“它”指的是獎盃，而不是手提箱。注意力是為什麼這些模型能夠很好地處理上下文、細微差別和遠端引用，以及為什麼它們需要如此多的計算，因為每個單詞都會涉及到其他單詞。

2.4 訓練——三個階段

1. 預訓練： 該模型會顯示數十億個句子，其中最後一個單詞被隱藏，並被要求猜測它。出錯了，微調引數，重複數萬億次。這是它吸收語法、事實、推理模式和程式碼的地方。這也是最昂貴的部分，在 GPU 時間內花費了數百萬英鎊。
2. 微調： 然後，原始模型會根據有用的問答行為的精選示例進行訓練，因此它的作用就像助手而不是自動完成功能。
3. 對準（RLHF）： 最後，人類對模型的答案進行排名，並使用反饋來使其更加有用、誠實和安全。這就是聊天模型拒絕有害請求並採用一致語氣的原因。

2.5 推理——它如何回答你

當您傳送提示時，模型會生成回覆 一次一個令牌：它預測最有可能的下一個標記，附加它，然後預測下一個，依此類推——就像一個快速、閱讀能力強的人逐字寫作而不首先計劃整個句子一樣。一個名為 溫度 控制它的冒險程度：低溫給出安全、可重複的答案（有利於編碼和提取）；高溫給出了創造性的、多樣化的答案（有利於頭腦風暴）。這個逐個令牌的過程稱為 推理，這是您在生產中支付的部分 - 每個請求都會消耗 GPU 週期。

3. LLM 的優點和缺點

瞭解工具的邊緣可以防止代價高昂的錯誤。

大多數問題的解決方法是 RAG（檢索增強生成）：您不信任模型的記憶體，而是從自己的系統中獲取相關文件並將其貼上到提示中，以便模型回答 根據您的資料。這就是您如何在內部 wiki 上構建聊天機器人，而無需模型進行彌補。

4. 詞彙，解碼

5. 為什麼要執行自己的LLM？

託管 API（OpenAI、Anthropic 等）是最快的啟動方式，而且非常出色。但組織選擇自行託管開放權重模型（例如 Llama、Mistral、Qwen 或 Gemma）有四個原因：

• 資料隱私與合規性。 敏感資料永遠不會離開您的網路——對於醫療保健、金融、法律和公共部門非常重要。
• 規模成本。 在一定的穩定請求量之上，您擁有的 GPU 每個代幣可能比支付 API 更便宜。
• 控制與穩定性。 該模型在您的領導下永遠不會改變，並且您不受供應商的速率限制或棄用的約束。
• 延遲和離線使用。 在您的應用程式旁邊或本地進行推理，不依賴於網際網路。

權衡是 您現在擁有硬體、擴充套件性和可靠性 ——這正是 Kubernetes 所擅長的。

6. 硬體現實（在部署之前閱讀本文）

LLM 的權重必須適合 GPU 記憶體 (VRAM)。粗略的經驗法則：

兩個服務引擎在實際部署中占主導地位：

• Ollama — 最簡單的入口匝道。非常適合開發、內部工具和 CPU 或單 GPU 節點。使用一個命令即可提取量化模型。
• vLLM ——生產主力。高吞吐量，批處理許多請求，並公開 相容 OpenAI 的 API 因此，您現有的程式碼只需更改一行 URL 即可工作。 （Hugging Face TGI 是一個接近的選擇。）

7. 在Kubernetes上部署自己的LLM

以下所有內容均假設叢集至少有一個 GPU 節點並且 NVIDIA 裝置外掛 已安裝，它將 GPUs 公開為可排程資源 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 縮放——以及為什麼它與 GPUs 不同

您可以自動縮放，但請記住 每個副本都需要自己的整個 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. 衡量推理成本和延遲 根據要求——這就是您真正的單位經濟效益。