k8s调度gpu

集群管理员，需要在worker节点上安装设备驱动，并运行对应的设备插件。

为了让 K8s 识别并使用 GPU，这两个条件必须同时满足：

• NVIDIA驱动（NVIDIA Drivers）：操作系统与GPU 硬件通信的底层基础，它让操作系统能够识别并控制 GPU 。

• NVIDIA Device Plugin：K8s的插件（节点上以daemonset形式部署），负责将GPU资源上报给K8s集群（nvidia.com/gpu），并让Pod可以请求和使用这些资源 。

具体表现在：

kubectl describe node node10上能显示扩展资源：

对于扩展资源gpu，请求和限制必须一样。

requests:

nvidia.com/gpu: 1

limits:

nvidia.com/gpu: 1

---

为帮助我们在k8s中便捷配置、管理GPU，英伟达推出了gpu operator ,具备以下能力

• NVIDIA 驱动程序（以启用 CUDA）

每个节点上以pod形式安装，kubectl exec -it -n gpu-operator nvidia-driver-daemonset-xxxxx -- nvidia-smi， 或者sudo chroot /run/nvidia/driver nvidia-smi(因为驱动文件被挂载到主机这个目录下)； 另外如果主机上安装了nvidia-smi驱动，gpu operator将不会在该节点上部署driver pod.

• k8s device plugin
• NVIDIA Container Toolkit、
• 使用 GFD 的自动节点标记
• 基于 DCGM 的监控

以下使用默认helm charts配置安装 gpu operator：

helm install --wait --generate-name \

-n gpu-operator --create-namespace \

nvidia/gpu-operator \

--version=v24.9.2

以上为worker节点配置了最常见的容器gpu加速， gpu operator还支持配置虚拟机gpu加速、管理vgpu设备, 如果你的k8s集群要管控云原生虚拟机(kubevirt)[https://github.com/kubevirt/kubevirt],需要先按照文档步骤设置节点标签kubectl label node <node-name> --overwrite nvidia.com/gpu.workload.config=vm-passthrough.

2. vllm production-stack

2.1 vllm的原理

为了理解请求，LLM 需要了解字词之间的关系以及如何在字词之间建立关联，与人类使用语义和推理来理解字词不同，LLM 是通过数学运算来“推理”的， 面对大量用户请求时， 需要消耗大量显存。

vllm是伯克利大学开源的吞吐量最强、最容易使用的推理引擎。

从本质上讲，vLLM作为一组指令工作，通过持续“批处理”用户请求，鼓励KV Cache创建快捷方式。

① KV Cache： 是一种短期内存存储， 它是将每个token(词元)所对应的值保存到缓存中, 以空间换时间的方式支持快速推理。

② 连续批处理：是一种可同时处理多个查询的技术（将先前计算的查询词元创建快捷方式），。

借助vLLM，LLM可以将批处理请求中重复部分的词元字符串（“what is the capital of”）保存在短期记忆（KV 缓存）中，并发送一个“翻译请求”，而不是两个单独的请求。

2.2 vllm production-stack

LMCache大语言模型推理引擎的扩展，目标是减小首字延迟TTFT，提高吞吐量。

LMCache与vllm结合产生了 vllm production-stack， 通过这个项目可以得到：

• 无需更改任何应用代码， 就能从单个vLLM实例扩展到分布式vLLM部署
• 通过网页仪表盘监控指标
• 基于请求路由和KVCache卸载带来的性能提升

① KV Cache感知路由： 确保具有相同prompt前缀的后续请求被路由到同一实例，从而最大化 KV 缓存的利用率并提高性能。

② KVCache卸载
将大量KV Cache从GPU显存移动到CPU或磁盘，从而实现更多潜在的KV Cache命中， 在helm charts中要应用lmcache-vllm镜像。

3. glm4.7-flash

glm4.7-flash是一个 30B-A3B MoE 模型， 号称30B级别中最强的模型。

按照上文显存估算： 权重值大概60GB， 可部署在4卡24G 4090上。

官方提示glm这货需要使用transformers框架, 最新的vllm-openai:latest镜像无 transformers框架，使用vllm-openai:latest会报错。

故需要我们自己建立一个镜像，dockerfile也很简单(基础镜像不是lmcache-vllm， 不带显存卸载能力)：

FROM vllm/vllm-openai:latest

RUN apt-get update && \

apt-get install -y git && \

rm -rf /var/lib/apt/lists/*

# 安装支持 GLM-4.7-Flash 的最新版 transformers

RUN pip install --no-cache-dir git+https://github.com/huggingface/transformers.git \

-i https://mirrors.aliyun.com/pypi/simple/

# docker build -t12205599/vllm-glm47:fixed -f Dockerfile

# docker push 12205599/vllm-glm47:fixed

使用vllm production-stack时，要注关注 helm charts value文件：

下面使用4卡4090部署1个glm4.7-flash模型实例。

# glm4.7-flash.yaml

root@k8sctrl1:/home/czf/vllm-llm# cat glm47-flash.yaml

routerSpec:

imagePullPolicy: "IfNotPresent"

nodeSelectorTerms:

- matchExpressions:

- key: nvidia.com/gpu.workload.config

operator: In

values:

- "vm-passthrough"

env:

- name: TZ

value: "Asia/Shanghai"

servingEngineSpec:

runtimeClassName: "nvidia"

imagePullPolicy: "IfNotPresent"

extraVolumes:

- name: dshm

emptyDir:

medium: Memory

sizeLimit: "30Gi"

extraVolumeMounts:

- name: dshm

mountPath: /dev/shm

modelSpec:

- name: "glm47-flash"

repository: "12205599/vllm-glm47"

tag: "fixed"

modelURL: "ZhipuAI/GLM-4.7-Flash"

replicaCount: 1

requestCPU: 16

requestMemory: "150Gi"

requestGPU: 4

shmSize: "30Gi"

pvcStorage: "120Gi"

pvcAccessMode: ["ReadWriteMany"]

storageClass: "csi-cephfs-models-sc" # 自动创建pvc

pvcAnnotations:

helm.sh/resource-policy: "keep" # helm uninstall 之后不要删除pvc

vllmConfig:

tensorParallelSize: 4 # 不要使用6卡

maxModelLen: 120000

extraArgs:

- "--gpu-memory-utilization"

- "0.90"

- "--tool-call-parser"

- "glm45"

- "--reasoning-parser"

- "glm45"

- "--enable-auto-tool-choice"

env:

- name: VLLM_USE_MODELSCOPE

value: "true"

- name: HF_ENDPOINT

value: "https://hf-mirror.com" # 当必须联网时 使用hf国内镜像站点

- name: NCCL_DEBUG

value: "INFO"

- name: NCCL_P2P_DISABLE

value: "1"