在 Kubernetes 上启动一个推理服务并不难。如果只有一个模型，vLLM + Deployment 确实够了。但服务多起来以后，模型从哪里加载、使用哪个 Runtime、GPU 怎么分配、服务怎么暴露，每个服务都要重复处理一遍，配置很快就会散落在一堆 YAML 里。KServe 解决的不是怎么启动 vLLM，而是怎么用统一的方式管理这些模型服务。
本文从零安装 KServe Standard 模式和 Envoy Gateway，通过本地 PVC 部署 Qwen2.5-0.5B-Instruct 模型。
事情是这样的。
前几天有读者跟我反馈，说博客变慢了。
不是偶尔卡一下，是点开文章以后，文字出来了，图片还要在原地转上好几秒。
我自己试了几次，确实不对劲。更奇怪的是，前不久我才压缩过图片。
一个纯静态博客，为什么会突然慢成这样？
上一篇我们用 Kueue + NVIDIA 原生 DRA 跑通了 GPU 整卡配额：Job 先进入队列，Kueue 判断配额够不够，够了再放行给调度器。
但整卡只是第一步。真实的 GPU 集群里，一张 GPU 往往不会只给一个 Pod 用，HAMi 可以继续按显存和算力切成 vGPU。问题也跟着来了：切完之后，队列系统还能不能知道每个任务用了多少？能不能做到两个任务放行、第三个因为显存或算力配额不够继续排队？
这篇就围绕这个问题跑一遍：HAMi 把 GPU 切给 Pod，Kueue 在 Job 准入阶段先把 vGPU、显存和算力配额算清楚。重点不是“能不能切卡”，而是“切完之后还能不能管起来”。
前面两篇：Kubernetes 官方出品：一个 Controller 搞定 Job 排队和资源配额 和 终于搞懂 Kueue：5 个核心对象一次讲透 把 Kueue 的基本玩法和核心对象走了一遍，不过 Demo 都跑在 CPU 上。
真到 GPU 集群里，大家更关心的是另一个问题：
Kueue 能不能管理 DRA 模式下的 GPU？
这一篇就把它跑通。NVIDIA DRA Driver 负责把整卡 GPU 发布成 DeviceClass / ResourceSlice，Kueue 在 Job 准入阶段读取 DRA 设备申请，判断这个 Job 能不能进入队列。
对 DRA 不熟悉的同学，可以先看这篇：DRA P1：DRA 能解决什么问题？从部署到使用的完整体验
很多人刚接触 Kueue 时最大的困惑，不是 YAML 怎么写，而是看着一堆 CRD：ResourceFlavor、ClusterQueue、LocalQueue、Cohort、Workload，不知道它们之间到底是什么关系。本文不会逐个照着 API 文档介绍字段，而是把这五个对象放到同一条资源准入链路中，一次讲清楚它们各自负责什么、为什么要存在，以及它们之间如何协作。
多个团队共用一个 Kubernetes 集群，A 团队提交了一批训练任务，几十张 GPU 很快就被占满；B 团队新提交的 Job 只能一直 Pending。 因为，而是 Kubernetes 原生采用"先到先得"的调度方式，没有 Job 队列，也没有多租户配额管理。
Kueue 正是 Kubernetes 官方为此提供的解决方案。它不替换 kube-scheduler，只负责 Job 的排队和准入，在此基础上实现资源配额管理和公平调度。
