大型语言模型的简明英语指南 — 它们是什么、它们在幕后如何实际工作以及如何在 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 训练——三个阶段
- 预训练: 该模型会显示数十亿个句子,其中最后一个单词被隐藏,并被要求猜测它。出错了,微调参数,重复数万亿次。这是它吸收语法、事实、推理模式和代码的地方。这也是最昂贵的部分,花费了数百万英镑的 GPU 时间。
- 微调: 然后,原始模型会根据有用的问答行为的精选示例进行训练,因此它的作用就像助手而不是自动完成功能。
- 对准(RLHF): 最后,人类对模型的答案进行排名,并使用反馈来使其更加有用、诚实和安全。这就是聊天模型拒绝有害请求并采用一致语气的原因。
2.5 推理——它如何回答你
当您发送提示时,模型会生成回复 一次一个令牌:它预测最有可能的下一个标记,附加它,然后预测下一个,依此类推——就像一个快速、阅读能力强的人逐字写作而不首先计划整个句子一样。一个名为 温度 控制它的冒险程度:低温给出安全、可重复的答案(有利于编码和提取);高温给出了创造性的、多样化的答案(有利于头脑风暴)。这个逐个令牌的过程称为 推理,这是您在生产中支付的部分 - 每个请求都会消耗 GPU 周期。
3. LLM 的优缺点
了解工具的边缘可以防止代价高昂的错误。
| 真正擅长 | 小心 |
|---|---|
| 起草、重写和总结文本 | 幻觉 — 发明看似合理但虚假的事实、引文或 API |
| 解释概念并回答常见问题解答 | 知识截止 - 它不知道训练日期之后发生的事件 |
| 编写和审查代码 | 精确的算术和计数(使用工具/计算器代替) |
| 分类、提取和重新格式化数据 | 任何未经审查而确信错误答案都是危险的事情 |
大多数问题的解决方法是 RAG(检索增强生成):您不信任模型的内存,而是从自己的系统中获取相关文档并将其粘贴到提示中,以便模型回答 根据您的数据。这就是您如何在内部 wiki 上构建聊天机器人,而无需模型进行弥补。
4. 词汇,解码
| 学期 | 用简单的英语来说是什么意思 |
|---|---|
| 参数(7B/70B) | 调整后的内部数字。更多=更智能但更重。 |
| 上下文窗口 | 它一次可以在工作记忆中保存多少文本(以标记为单位)。 |
| 推理 | 运行模型以获得答案——您的经常性计算成本。 |
| 量化 | 压缩模型(例如压缩为 4 位),使其适合较小的 GPU,但质量会受到较小影响。 |
| 微调 | 根据您自己的例子进行进一步培训,以专门化行为。 |
| 抹布 | 在查询时向模型提供文档,以便模型根据事实而不是记忆来回答。 |
| 显存 | GPU内存。可以运行哪些模型的最大限制。 |
5. 为什么要经营自己的法学硕士?
托管 API(OpenAI、Anthropic 等)是最快的启动方式,而且非常出色。但组织选择自行托管开放权重模型(例如 Llama、Mistral、Qwen 或 Gemma)有四个原因:
- 数据隐私与合规性。 敏感数据永远不会离开您的网络——对于医疗保健、金融、法律和公共部门非常重要。
- 规模成本。 在一定的稳定请求量之上,您拥有的 GPU 的每个代币可能比支付 API 更便宜。
- 控制与稳定性。 该模型在您的领导下永远不会改变,并且您不受供应商的速率限制或弃用的约束。
- 延迟和离线使用。 在您的应用程序旁边或本地进行推理,不依赖于互联网。
权衡是 您现在拥有硬件、扩展性和可靠性 ——这正是 Kubernetes 所擅长的。
6. 硬件现实(在部署之前阅读本文)
LLM 的权重必须适合 GPU 内存 (VRAM)。粗略的经验法则:
| 型号尺寸 | 全精度 (FP16) | 量化(4 位) |
|---|---|---|
| 7–8B(例如 Mistral 7B、Llama 3 8B) | ~16 GB 显存 | ~5–6 GB 显存 |
| 13–14B | ~28 GB 显存 | ~10 GB 显存 |
| 70B | ~140 GB(多 GPU) | ~40 GB 显存 |
两个服务引擎在实际部署中占主导地位:
- 奥拉玛 — 最简单的入口匝道。非常适合开发、内部工具以及 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. 务实的推出清单
- 托管 API 上的原型 在购买 GPU 之前验证用例。
- 选择一个开放重量模型 适合您的硬件(从 7-8B 模型开始,量化)。
- 从奥拉马开始 对于内部飞行员;毕业到 法学硕士 当您需要吞吐量时。
- 添加RAG 查看您自己的文件,以减少幻觉并保持最新的答案。
- 让人类了解情况 任何错误的答案都会带来真正的成本。
- 衡量推理成本和延迟 根据要求——这就是您真正的单位经济效益。