KServe 源码拆解第 7 篇明确 3 条扩缩容路径，说明大模型推理竞争已从模型能力延伸到 GPU 利用率。

这是什么

它解决的是流量变化时增减 Pod（Kubernetes 中承载推理进程的容器），并在低谷释放昂贵 GPU。普通网页服务拉起进程即可接流量；推理服务还要下载 GB 级模型、装入显卡，因此扩慢会延误请求，缩晚又会持续计费。

KServe 提供三种机制：KPA（按并发量或请求数扩缩）采用 Knative 模式，支持缩到 0，即完全不保留实例；Pod 自动扩缩器 HPA 适合 Standard 模式，主要观察 CPU 和内存，且至少保留一个实例；事件驱动扩缩器 KEDA 同样可在 Standard 模式运行，接入 Prometheus、OpenTelemetry 等外部指标。

关键不在三条命令，而在同一组副本上下限、并发目标等字段，会被控制器翻译成不同配置对象，并在应用阶段拦截不兼容组合。

行业怎么看

积极意义在于，KServe 没有强迫团队押注单一扩缩器，而是把请求量、基础资源和业务事件分别纳入容量管理。运营者可以按流量形态、已有监控体系与成本目标组合方案。

风险也很清楚：KPA 缩到 0 后，模型下载、GPU 加载和进程启动可能造成冷启动，频繁归零会把成本压力变成延迟压力。CPU 利用率也不必然等于 GPU 忙碌程度，KEDA 虽然灵活，却增加了事件源、指标质量和故障链路的维护负担。

对普通人的影响

对企业 IT：稳定常驻负载通常更接近 HPA，稀疏请求更看重 KPA 归零，已有 Prometheus 或 OpenTelemetry 指标体系的团队则更容易采用 KEDA。收益能否兑现，仍取决于请求分布与指标口径。

对个人职场：基础设施岗位的职责会从手工调配资源，转向设计容量指标、设置副本边界和评估冷启动。企业仍需同时理解业务流程与 GPU 成本。

对消费市场：更高的 GPU 利用率有机会降低 AI 功能的单位调用成本，尤其适合低频功能。价格不会仅因引入扩缩容就自动下降，模型大小、流量形态和云厂商计费仍会决定结果。