模型推理服务与普通Web服务在资源消耗模式上存在明显差异。一个训练好的模型可能长时间没有请求，但一旦有请求到来，又需要在极短时间内完成前向计算，这对底层基础设施的弹性能力提出了很高要求。如果始终维持固定数量的Pod，GPU节点会在空闲时段被白白占用；如果手动调整副本数，又很难跟上流量波动。KServe正是针对这一场景设计的Kubernetes推理服务框架，它把Serverless理念引入模型部署，让推理服务可以按需伸缩，甚至在没有流量时缩减到零个副本。
要理解KServe的自动伸缩，需要先看清它在Kubernetes生态中的位置。KServe的前身是KFServing，它不直接替代Kubernetes的Deployment或Service，而是在上层抽象出InferenceService资源。这个资源描述模型来源、推理运行时、资源规格以及流量策略，KServe Controller负责把该抽象转换为底层Kubernetes对象。默认情况下，这些底层对象包括一个Knative Service，而Knative又依赖Istio或类似的网络层来管理流量。正是因为这套组合，KServe获得了Serverless能力，包括自动伸缩、缩容到零、流量灰度等。
KServe的核心组件与Serverless基础
KServe的架构可以拆成几个关键部分：InferenceService自定义资源、KServe Controller、推理运行时以及底层的Knative和Istio组件。InferenceService是用户最常接触的API对象，它用一个声明式配置定义推理服务的完整生命周期。用户不需要手动创建Deployment、Service或Ingress，只需要提交一个YAML文件，KServe Controller就会自动完成后续所有工作。
推理运行时是KServe中负责实际加载模型并执行推理的组件。常见的运行时包括Triton Inference Server、TorchServe、TensorFlow Serving、MLServer等。KServe通过标准化的协议与这些运行时交互，例如V2推理协议或Open Inference Protocol。不同运行时可以适配不同框架导出的模型，而KServe为它们提供统一的流量管理和伸缩策略。这种设计使得模型服务团队可以专注于模型本身，而不必为每个模型单独搭建一套服务框架。
Serverless能力的核心来自Knative Serving。Knative Serving在Kubernetes之上实现了请求驱动的计算模型，它可以根据到达的请求数量自动调整Pod数量。当没有请求时，Knative会把服务的副本数缩到零；当第一个请求到来时，它又会自动扩容并路由流量。对于推理服务来说，这意味着模型加载可以延迟到首次请求时进行，虽然会增加冷启动延迟，但能够避免长期占用昂贵的GPU资源。
KServe自动伸缩的指标与策略
KServe的自动伸缩行为主要由Knative的Pod Autoscaler控制，它支持两种主要的扩缩容指标：并发数和请求速率。并发数指标衡量的是每个Pod同时处理的请求数量，适合推理延迟相对稳定的场景。请求速率指标则统计每秒钟到达的请求数，适合吞吐量波动较大的服务。用户可以通过注解来选择使用哪种指标，并设置目标值。例如，设置目标并发数为10，表示每个Pod最多同时处理10个请求，超过该值时Knative就会增加副本。
除了指标类型，缩容到零是KServe自动伸缩中非常关键的能力。默认情况下，Knative会在服务没有请求的若干秒后将副本数缩减到零。这个时间可以通过注解调整，例如设置缩容延迟为60秒。对于模型推理服务，缩容到零可以节省大量资源，但也带来冷启动问题。当新的请求到来时，系统需要先启动Pod、加载模型文件、初始化推理引擎，然后才能处理请求，这个过程可能从几秒到几十秒不等。
KServe还支持基于GPU利用率的自动伸缩，但这通常需要额外的指标适配器。在Kubernetes中，原生的HPA可以基于CPU和内存指标扩缩容，而GPU指标需要安装专门的监控组件，例如NVIDIA DCGM Exporter配合Prometheus Adapter。KServe通过Knative的指标接口可以接入这些自定义指标，让伸缩决策更贴近推理服务的真实资源消耗。不过对于推理场景，基于并发数往往比基于GPU利用率更直接，因为模型推理的瓶颈通常是计算单元而非GPU内存。
配置KServe自动伸缩的YAML示例
下面是一个典型的InferenceService配置示例，它部署一个基于Triton的模型推理服务，并设置了自动伸缩参数。这个YAML展示了如何通过注解控制并发数、缩容延迟以及资源请求。
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
name: resnet50
annotations:
autoscaling.knative.dev/target: "5"
autoscaling.knative.dev/metric: "concurrency"
autoscaling.knative.dev/scale-down-delay: "60s"
autoscaling.knative.dev/min-scale: "0"
autoscaling.knative.dev/max-scale: "10"
spec:
predictor:
triton:
storageUri: "s3://model-bucket/resnet50"
runtimeVersion: "23.05-py3"
resources:
limits:
nvidia.com/gpu: 1
cpu: "4"
memory: 8Gi
requests:
nvidia.com/gpu: 1
cpu: "2"
memory: 4Gi
在这个配置中，autoscaling.knative.dev/target设置为5，表示每个Pod的目标并发数为5个请求。metric设置为concurrency，即使用并发数作为伸缩依据。scale-down-delay为60秒，意味着服务在连续60秒没有请求后才会缩容到零。min-scale为0允许完全缩容，而max-scale为10限制最大副本数，防止异常流量导致无限扩容。资源限制中指定了一块GPU，这对模型推理是必需的。
如果希望使用请求速率作为指标，只需要修改注解即可。例如将metric改为rps，并将target设置为每秒请求数。需要注意的是，不同版本的Knative对指标名称的支持略有差异，在使用前应确认集群中Knative的版本。此外，KServe还支持通过ConfigMap设置全局默认的自动伸缩参数，这样所有未显式声明注解的InferenceService都会继承这些默认值。
冷启动与模型加载的优化思路
缩容到零带来的最大挑战是冷启动延迟。当一个推理服务从零副本开始接收请求时，Pod调度、镜像拉取、模型文件下载或挂载、推理引擎初始化等步骤都会消耗时间。对于体积较大的模型，模型加载可能成为冷启动中最耗时的环节。为了缓解这个问题，可以采用模型预热策略，即在服务启动时提前加载模型到内存或GPU显存中，或者在缩容时保留一个最小副本数，避免完全缩容带来的冷启动。
另一种思路是使用本地缓存或持久卷来加速模型文件的访问。如果模型存储在S3等对象存储中，首次拉取可能非常慢。将模型预置到节点本地磁盘或者使用ReadOnlyMany类型的PVC，可以显著减少冷启动时间。在KServe中，可以通过设置storageUri指向PVC，或者使用模型缓存组件提前分发模型。对于GPU推理，还可以利用NVIDIA的MIG技术将一块大GPU切分为多个小实例，每个实例运行一个轻量推理服务，这样即使某个实例缩容到零，其他实例仍可复用同一块物理GPU，提升资源利用率。
自动伸缩的准确性也受到指标采集周期和扩缩容算法的影响。Knative的Pod Autoscaler默认每两秒采集一次指标，并根据突发流量进行快速扩容，但缩容则相对保守，以避免频繁上下抖动。对于推理服务，过于激进的缩容可能导致请求被拒绝或排队超时。因此，在实际生产环境中，需要根据模型推理延迟和请求模式，仔细调整目标并发数、缩容延迟和最大最小副本数，在资源成本与服务质量之间找到平衡。
KServe的Serverless自动伸缩能力为模型推理服务提供了一种高效的资源管理方式。它把模型部署从静态的Pod管理提升为按请求驱动的弹性架构，让团队能够在Kubernetes上以更低的成本运行大量模型服务。理解其底层指标、配置参数以及冷启动特性，是在生产环境中用好KServe的关键。
KServeServerless推理自动伸缩修改时间：2026-08-23 16:11:03