KServe 集成 KEDA：基于 VLLM 指标自动扩缩容
模型服务运行后，固定副本数很难同时兼顾突发请求和资源利用率。请求增加时需要扩容，流量回落后又希望及时缩容。
本文通过一个简单 Demo，为 KServe 模型服务接入 KEDA，根据 vLLM 的请求指标自动调整副本数，并验证服务从 1 -> 2 -> 1 的扩缩容过程。
李学端（意琦行）｜AI Infra / Kubernetes Engineer
专注 Kubernetes、GPU Infrastructure 与 AI Infra专注 Kubernetes、GPU Infrastructure 与 AI Infra
GPT-5.6 之后，Superpowers 可以卸载了
之前我写过一篇文章 OpenSpec + Superpowers，SDD+TDD 双驱动 AI 编程工作流，记录了我当时把 OpenSpec 和 Superpowers 组合成一套工作流的尝试。
那时候我觉得这两个东西搭在一起还挺顺，OpenSpec 负责需求和 Spec 对齐，Superpowers 负责计划、TDD、子 Agent 实现和代码审查。
后来，我发现社区里很多人也在用这套工作流，先写需求和设计，拆任务，再实现和验证，大家都在试图给 Agent 加一套更稳定的工作方法。
KServe + HAMi：一张 GPU 如何运行多个推理服务
前面已经用 KServe 跑起了 Qwen，但一个小模型独占一张 GPU 有些浪费。这篇则是在此基础上引入 HAMi，通过 HAMi 实现 GPU 共享，让多个小模型共用一张 GPU。
KServe 工作流程：从 InferenceService 到 VLLM 服务
上一篇完成了 KServe 的安装，并通过 InferenceService 跑通了一个 Qwen 模型服务。
当时提交的 InferenceService 只包含模型格式、存储地址、GPU 资源和启动参数，KServe 却创建出了 Deployment、Service 和 HTTPRoute。这份 YAML 中没有容器镜像，那么 KServe 如何选中 HuggingFaceServer，Pod 中又为什么会运行 vLLM？
这一篇先看 KServe 的整体架构和核心 CRD，再结合上一篇的 qwen-llm，梳理从提交 InferenceService 到请求进入 vLLM 的完整流程。
以下内容基于 KServe 0.18，部署模式为 Standard。
一个 Deployment 就能跑 VLLM，为什么还需要 KServe？
在 Kubernetes 上启动一个推理服务并不难。如果只有一个模型，vLLM + Deployment 确实够了。但服务多起来以后，模型从哪里加载、使用哪个 Runtime、GPU 怎么分配、服务怎么暴露，每个服务都要重复处理一遍，配置很快就会散落在一堆 YAML 里。KServe 解决的不是怎么启动 vLLM，而是怎么用统一的方式管理这些模型服务。
本文从零安装 KServe Standard 模式和 Envoy Gateway，通过本地 PVC 部署 Qwen2.5-0.5B-Instruct 模型。
我的博客，被 47 万次请求刷慢了
事情是这样的。
前几天有读者跟我反馈，说博客变慢了。
不是偶尔卡一下，是点开文章以后，文字出来了，图片还要在原地转上好几秒。
我自己试了几次，确实不对劲。更奇怪的是，前不久我才压缩过图片。
一个纯静态博客，为什么会突然慢成这样？