之前我写过一篇文章 OpenSpec + Superpowers，SDD+TDD 双驱动 AI 编程工作流，记录了我当时把 OpenSpec 和 Superpowers 组合成一套工作流的尝试。
那时候我觉得这两个东西搭在一起还挺顺，OpenSpec 负责需求和 Spec 对齐，Superpowers 负责计划、TDD、子 Agent 实现和代码审查。
后来，我发现社区里很多人也在用这套工作流，先写需求和设计，拆任务，再实现和验证，大家都在试图给 Agent 加一套更稳定的工作方法。
前面已经用 KServe 跑起了 Qwen，但一个小模型独占一张 GPU 有些浪费。这篇则是在此基础上引入 HAMi，通过 HAMi 实现 GPU 共享，让多个小模型共用一张 GPU。
上一篇完成了 KServe 的安装，并通过 InferenceService 跑通了一个 Qwen 模型服务。
当时提交的 InferenceService 只包含模型格式、存储地址、GPU 资源和启动参数，KServe 却创建出了 Deployment、Service 和 HTTPRoute。这份 YAML 中没有容器镜像，那么 KServe 如何选中 HuggingFaceServer，Pod 中又为什么会运行 vLLM？
这一篇先看 KServe 的整体架构和核心 CRD，再结合上一篇的 qwen-llm，梳理从提交 InferenceService 到请求进入 vLLM 的完整流程。
以下内容基于 KServe 0.18，部署模式为 Standard。
在 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、显存和算力配额算清楚。重点不是“能不能切卡”，而是“切完之后还能不能管起来”。
