KServe 工作流程：从 InferenceService 到 vLLM 服务
内容提要
KServe是基于Kubernetes的AI推理平台，分为控制面和数据面。用户提交InferenceService后，Webhook校验配置，Controller根据modelFormat匹配ServingRuntime，合并配置创建Deployment、Service和HTTPRoute。Pod启动时注入PVC存储，HuggingFaceServer自动选择vLLM作为推理后端，加载模型并执行推理。请求经Envoy Proxy转发至Predictor Pod，由vLLM在GPU上完成推理。
延伸解读
模型格式与推理后端解耦
InferenceService 中的 modelFormat 仅用于匹配 ServingRuntime，并不限定推理引擎。例如声明 huggingface 格式后，KServe 可能选择 HuggingFaceServer，而该服务器内部又会根据 GPU 镜像和模型架构自动选用 vLLM 作为后端。这种解耦设计让用户无需关心具体推理引擎，只需描述模型格式和资源需求，KServe 负责选择合适的运行时和引擎。
存储注入的两种方式
storageUri 指定模型来源，但实际注入方式取决于协议。使用 pvc:// 时，Pod Mutating Webhook 直接注入 PVC 卷并挂载到 /mnt/models；使用 hf:// 时，则会注入 init container 先从 Hugging Face Hub 下载模型，再通过共享卷提供给模型容器。理解这一区别有助于排查模型加载失败或存储配置问题。
控制面与数据面分离
KServe 将控制面（Controller、Webhook）与数据面（Envoy Proxy、Predictor Pod）分离。在线请求只经过数据面，不经过 Controller，因此 Controller 的故障不会影响已就绪服务的推理流量。但 Controller 仍持续监控 Deployment 和 HTTPRoute 状态，并回写 InferenceService 状态，确保服务生命周期管理。
Q&A
KServe 的整体架构是怎样的？
KServe 是基于 Kubernetes 的 AI 推理平台，整体分为控制面和数据面。控制面负责创建和维护推理服务，包括处理 InferenceService、匹配 ServingRuntime、创建 Deployment、Service 和 HTTPRoute 等；数据面由实际运行模型和处理请求的资源组成，包括 Envoy Proxy 和 Predictor Pod，负责请求转发和模型推理。
KServe 控制面从提交 InferenceService 到服务就绪的流程是什么？
流程包括：1. 用户提交 InferenceService；2. Webhook 默认化并校验配置；3. Controller 根据 modelFormat 匹配 ServingRuntime；4. 合并配置并写入存储注解；5. 创建 Deployment、Service 和 HTTPRoute；6. Pod Mutating Webhook 注入 PVC；7. Kubernetes 调度 Pod、挂载 PVC 并分配 GPU；8. Pod 启动并加载模型，Controller 更新状态。
KServe 中 InferenceService 和 ServingRuntime 的关系是什么？
InferenceService 描述模型服务需要什么，包括模型格式、模型地址、启动参数和资源需求；ServingRuntime 定义模型服务器镜像和启动方式，并声明支持的模型格式。KServe Controller 根据 InferenceService 中的 modelFormat 自动匹配对应的 ServingRuntime，并将两者配置合并，最终创建模型服务。
KServe 如何自动选择 vLLM 作为推理后端？
在 Qwen Demo 中，InferenceService 指定 modelFormat 为 huggingface，KServe 匹配到 ClusterServingRuntime kserve-huggingfaceserver。该 Runtime 使用 HuggingFaceServer 镜像，其 backend 默认为 auto。当 GPU 镜像中包含 vLLM 且模型架构在 vLLM 支持列表中时，HuggingFaceServer 会自动创建 vLLM 后端并加载模型。
KServe 数据面如何处理在线推理请求？
客户端请求先到达 Envoy Proxy，Envoy Proxy 根据 HTTPRoute 规则匹配，并通过 backendRef 指向 Service/qwen-llm-predictor，将请求转发到 Ready 的 Predictor Pod。Pod 内 HuggingFaceServer 接收请求，由 vLLM 后端在 GPU 上执行推理，响应沿原链路返回。在线请求不经过 KServe Controller。
KServe 中 Pod 是如何挂载模型存储的？
InferenceService 中的 storageUri 指定模型存储地址，如 pvc://qwen-model。Controller 将该地址写入 Pod 模板注解，Pod 创建时，KServe Pod Mutating Webhook 读取注解，解析出 PVC 名称，并注入 PVC volume 和挂载到 /mnt/models 的 volumeMount。如果使用 hf:// 地址，则会注入 Storage Initializer init container 从 Hugging Face Hub 下载模型。
KServe 中 Webhook 和 Controller 分别承担什么职责？
Webhook 位于资源写入 Kubernetes API 的入口，负责默认化和校验配置，以及 Pod 创建时注入存储配置。KServe Controller 持续 Watch InferenceService，通过 Reconcile 循环匹配 Runtime、合并配置、创建工作负载和网络入口，并观察底层资源状态回写 InferenceService 状态。
