生产环境大模型推理：从 Deployment 到 KServe 的演进

先交代背景我用原生 Kubernetes Deployment 跑 vLLM 跑了小半年内部挂着 Qwen、DeepSeek 好几个开源模型部署流程很简单——GPU 节点、一个 Deployment、一个 Service容器崩溃就杀掉重启。那段时间我也一度觉得KServe 这种重框架是不是过度设计直到后来要同时维护多个模型版本、要按请求量缩容到零、要给新模型灰度流量才发现原生 Deployment 根本招架不住。这篇文章就从我踩过的坑出发聊聊为什么生产环境里KServe 仍然是比“一个 Deployment 跑 vLLM”更优的解法。1. 从 vLLM 到 Deployment为什么“一条 YAML”搞定不了生产1.1 vLLM 解决了什么问题Deployment 又解决了什么问题先说 vLLM 本身。它目前是把开源大模型跑上 GPU 性价比最高的推理引擎之一核心是 PagedAttention 和 Continuous Batching。PagedAttention 解决了 KV Cache 显存碎片化的问题连续批处理解决了小请求打不满 GPU 算力的问题所以同样一张 L20 或 A10用 vLLM 能比原生 Transformers 管线多承载数倍并发。这也是为什么“vLLM 部署 DeepSeek”“vLLM 部署 Qwen”这类话题能成为社区热词——大家不是想换服务框架而是想把开源模型的性能榨出来。Deployment 解决的是另一层问题进程的“死活”和“刷新”。Kubernetes 的 Deployment 保证容器崩溃后能拉起新实例更新镜像或模型参数时可以用 RollingUpdate 逐个替换 Pod配合 Service调用方拿到的始终是一个稳定的 ClusterIP。这些东西对于一个跑通了的、流量稳定的内部服务来说完全够用。但注意Deployment 和 vLLM 是两层完全不同的抽象。vLLM 解决“模型推理效率”Deployment 解决“进程生命周期”。真正的生产问题往往不在这两层里而在它们之上流量怎么灰度、弹性怎么伸缩、多个模型怎么隔离、GPU 成本怎么控制。这些才是 KServe 出场的理由。1.2 原生 Deployment 跑 vLLM 的具体形态如果只维护一个模型YAML 大概长这样apiVersion: apps/v1 kind: Deployment metadata: name: vllm-deepseek spec: replicas: 1 selector: matchLabels: app: vllm-deepseek template: metadata: labels: app: vllm-deepseek spec: containers: - name: vllm image: vllm/vllm-openai:v0.27.1 command: [python3, -m, vllm.entrypoints.openai.api_server] args: - --model/data/deepseek-model - --served-model-namedeepseek - --max-model-len8192 resources: limits: nvidia.com/gpu: 1 volumeMounts: - name: model mountPath: /data volumes: - name: model persistentVolumeClaim: claimName: model-pvc --- apiVersion: v1 kind: Service metadata: name: vllm-deepseek spec: selector: app: vllm-deepseek ports: - port: 8000 targetPort: 8000客户端比如 Chatbox填http://service-ip:8000/v1就能直接对话。这种形态的价值在于简单没有多余组件出问题直接看 vLLM 日志P99 首 Token 延迟也容易定位。我测过在单卡 L20 上跑 Qwen 系列Deployment 直连的启动速度甚至比 KServe 快几十秒因为 KServe 至少要等 queue-proxy 注入、配置拉取、Ingress 路由就绪。这几十秒在实验阶段无所谓生产上只要不发布影响也不大。所以“一个 Deployment 就能跑 vLLM”这个说法完全成立它不是伪命题它只是一个“够用但不够好用”的起点。1.3 当模型数量变多Deployment 的边界在哪里一旦模型开始变多Deployment 的问题会集中爆发。模型版本管理是第一个坑。旧的 DeepSeek 副本和新版同时存在时Deployment 只能靠两个不同的 workload 支撑Service 层面没有按比例的流量分配要么全切新、要么全切旧无法灰度验证效果。你可能说用 Istio VirtualService 也能做灰度但那是另一套手工配置而且和 Deployment 的发布过程没有联动。弹性伸缩是第二个坑。vLLM 的 Pod 一旦被 HPA 强行拉起模型加载需要几十秒到几分钟GPU 显存如果没预留调度器只会把新 Pod 放到下一台有空闲显存的节点。这个等待在流量尖峰来临时是致命的。更麻烦的是HPA 基于 CPU 的伸缩对大模型推理几乎无效必须取 vLLM 暴露的令牌生成速率、排队请求数等指标而这些指标需要自己搭 Prometheus adapter 接入。成本控制是第三个坑。Deployment 模式下副本数只能手动改半夜没人调用时 GPU 照样在空转。大模型推理的 GPU 很贵scale-to-zero 对内部开发环境是实打实的省钱工具。我见过一个团队三个模型各挂一个 7x24 的 Deployment一个月 GPU 账单下来财务直接找上门。这不是夸张是真实发生的事。所以原生 Deployment 的边界不在于“跑不起来”而在于它把所有上层能力都留给了你发布策略、弹性策略、路由策略、成本策略全都要自己写。KServe 就是把这一层平台能力标准化了。2. KServe 的设计思路从“一组 Pod”到“推理平台”2.1 KServe 不只是一个 CRD大部分人第一次接触 KServe 是从InferenceService这个 CRD 开始的。写法上确实只是多了一个自定义资源但它的本质是把“模型 运行时 路由 弹性 灰度 监控”打包成了平台语义。KServe 脱胎于原来的 KFServing后来捐赠给云原生计算基金会。它的核心设计是控制面和数据面分离控制面是 KServe Controller负责把InferenceServiceCRD 翻译成底层的 Deployment、Service、VirtualService数据面是实际跑模型 Pod 里的 queue-proxy 和模型容器。理解这个分层很重要因为它决定了 KServe 的扩展方式和排错路径。每个InferenceService的 Pod 里不仅有你指定的 vLLM 或 SGLang 容器还会自动注入两个 sidecarqueue-proxy 负责接收流量、统计并发数和请求量把指标暴露给 Knative autoscalermodel-agent 在一些场景下负责模型拉取和健康检查。控制面的 Knative Serving 则负责给 Pod 分配 revision并根据扩缩容策略调整副本数量。2.2 KServe 的 vLLM Runtime 是如何工作的KServe 把 vLLM 封装成了标准 runtime不需要自己写模型服务的适配代码。你只需要在InferenceService里声明modelFormat.name: vllmKServe 就会用 vllm/vllm-openai 镜像创建 Pod并自动拼接 vLLM 的启动参数。这里可以展开一点 vLLM 内部的enginecore与scheduler、executor交互流程因为很多人问“为什么 KServe 启动模型这么慢”。vLLM 进程里有一个 engine core 作为控制大脑scheduler 负责从请求队列里挑选可以被连续批处理的序列executor 负责把任务分发到 GPU worker 上执行。模型加载和 KV cache 初始化都发生在引擎启动阶段对一个大模型来说这几分钟是无法绕开的。KServe 只是把这套引擎塞进 Pod它不会缩短 vLLM 自身的启动时间但可以通过 readiness probe 和流量保持把“模型还没就绪”的请求挡在外面。另外需要注意KServe 不对 vLLM 的镜像、CUDA 版本、显卡做额外校验。镜像里是否带模型这个问题也经常有人问vllm/vllm-openai镜像只包含运行时代码不包含模型权重。模型必须放在 PVC、S3 或 HTTP 可达的路径上启动时通过--model指定。这个规则和直接用 Deployment 完全一样不要以为上了 KServe 就能自动下载模型。2.3 KServe 的弹性与灰度和 Deployment 有什么本质区别Deployment 的伸缩单位是“副本”KServe 的伸缩单位是“请求”。queue-proxy 会统计每个 Pod 当前正在处理的并发请求数和每秒请求数Knative 的 autoscaler 会根据这些指标以及你设置的 concurrency 目标值计算出期望副本数。这就解决了“vLLM 推理不能只看 CPU”的难题。灰度方面KServe 的InferenceService支持 canary 流量配置。你可以把新版本 vLLM 的权重设成 5%让少量真实请求先跑新引擎同时保留旧版本负责剩余流量。对比原生 Deployment 的 RollingUpdatecanary 不是“逐个替换”而是“按比例分流”失败时把 canary 流量归零即可回滚成本低很多。为了更直观我把两种模式放在一起对比维度原生 Deployment ServiceKServe InferenceService弹性伸缩指标CPU/自定义 HPA需要额外开发concurrency/rpsqueue-proxy 内置缩容到零不支持支持 KPA scale-to-zero流量灰度RollingUpdate 或依赖网关手工配置canary 按百分比字段模型服务适配需要自己封装镜像和启动脚本内置 vLLM/SGLang runtime健康检查需自己配置 startup/readiness统一 readiness 流量标记多模型管理多个 workload 手动组织CRD 路由统一管理监控成本自己接 metricsqueue-proxy 内置 Prometheus 指标这个表格也是我每次跟团队介绍 KServe 时必放的。它把抽象问题变成了具体的选型问题告诉别人你付出的“多一层框架”成本到底换来了什么。3. 从 Deployment 平滑迁移到 KServe实操路径3.1 前置环境Knative、Ingress 与 GPU 节点KServe 的生产安装不是一条kubectl apply就能完成的它依赖 Knative Serving 做 serverless 容器能力也依赖一个入口网关把外部请求转发到 queue-proxy。安装顺序建议是先装 Knative Serving再装 KServe 控制器最后配置入口网关。网关可以选择 Istio、Kourier 或 Contour社区默认是 Istio因为 KServe 的 VirtualService 灰度路由在 Istio 上最成熟。如果集群里没装 IstioKourier 也能跑但 canary 功能的配置细节会有些差异。你要确认集群里有 GPU 节点并且节点上有对应的 device pluginnvidia.com/gpu资源能被 scheduler 识别。如果用的是 L20 这类卡注意 vLLM 镜像里的 CUDA 版本要和驱动兼容。这步可以直接沿用你之前跑 Deployment 的镜像和参数减少变量。我见过不少人迁移失败原因不是 KServe 配错了而是基础环境里 GPU 资源没声明好导致 Pod 一直 Pending。3.2 用 InferenceService 托管 vLLM 的最小 YAML下面是一个社区常见的 vLLM InferenceService 写法 (以较新版本 KServe 为例)apiVersion: serving.kserve.io/v1beta1 kind: InferenceService metadata: name: deepseek-vllm annotations: serving.kserve.io/deploymentMode: Serverless spec: predictor: model: modelFormat: name: vllm storageUri: pvc://model-pvc/deepseek-model runtimeVersion: v0.27.1 resources: limits: nvidia.com/gpu: 1 args: - --max-model-len8192 - --served-model-namedeepseek这个 CRD 创建后KServe 会自动创建一个与 CRD 同名的 Deployment镜像就是v0.27.1的 vllm/vllm-openai参数按args拼接。看到这里你应该明白了KServe 底层还会生成 Deployment但它比手写 Deployment 多出了 queue-proxy 注入、服务网格流量路由和自动伸缩配置。查看部署状态用kubectl get inferenceservice deepseek-vllm输出里会有 URL、Ready 状态和最新版本。等待状态变成 Ready 之后用kubectl get pods -l serving.kserve.io/inferenceservicedeepseek-vllm可以看到实际 Pod 列表。3.3 模型存储与 vLLM 参数的常见选择storageUri支持pvc://、s3://、http(s)://。小团队最省事的做法是 PVC把模型文件放到节点磁盘或网络存储上模型多了之后S3 或对象存储更划算因为多个 InferenceService 可以复用桶里的模型文件不用每个副本都备份一份。vLLM 的几个关键参数需要根据显卡显存调。--max-model-len直接决定 KV cache 复用策略设得过大启动时报显存不足设得过小长对话会被截断。--gpu-memory-utilization通常设为 0.85~0.95给 CUDA context 留一点余量。--tensor-parallel-size在多卡场景下才设置单卡别加否则反而增加通信开销。还有一个容易被忽略的细节--served-model-name要和客户端请求里的 model 字段保持一致。用 Chatbox 连接时如果模型名对不上会在 404 或者 invalid model 的错误里卡很久。我在 KServe 上部署 GLM 系列时就犯过这个错日志里一点异常都没有纯粹是名字不匹配。3.4 配置弹性与灰度从 scale-to-zero 到 canary要让 KServe 真正发挥比 Deployment 强的价值autoscaler 配置必须调。举一个典型配置spec: predictor: autoscaler: minReplicas: 0 maxReplicas: 4 scaleMetric: rps target: 10minReplicas为 0 意味着没有请求时 Pod 会缩掉下次第一个请求会被 Knative activator 拦截并排到后台拉起新 Pod首请求会有模型加载延迟但对于内部低频调用完全可以接受。scaleMetric用 rps 或 concurrency 都行比 CPU 指标更适合 LLM。GPU 资源建议在 KServe 的 autoscaler annotation 里声明 GPU 类型避免调度器在伸缩时把 Pod 放到没有 GPU 的节点上。灰度发布这样配spec: predictor: canary: trafficPercent: 5然后更新spec.predictor.model的 storageUri、runtimeVersion 或 argsKServe 会基于新配置生成一个新版本的 worker并把 5% 流量路由过去。验证稳定后把canary.trafficPercent改为 0再删掉 canary 字段完成正式切换。在实操中我建议把模型请求路径画一条线外部请求 → Ingress 网关 → Knative activator → queue-proxy → vLLM engine。但凡觉得“KServe 比 Deployment 慢半拍”多半是这条链上的某一环还没就绪。ISVC 的status.url就是这条链的入口地址调它没问题再往链路深处查。4. 常见问题与排查KServe vLLM 避坑实录4.1 vLLM 镜像版本与模型启动错误vLLM 的版本对部署影响很大。社区里关于“vLLM 新版本性能下降”的讨论通常来自默认参数变化或新特性引入的 bug。解决方案很简单把runtimeVersion锁在一个你验证过的版本上升级前单独跑一轮连续批处理压力测试。GLM、Qwen 这类模型对 tokenizer 版本敏感镜像里自带的 tokenizer 不一定和权重目录里的 tokenizer 完全一致尽量让--tokenizer与--model指向同一目录。具体到版本选择比如你在 KServe 里加载 qwen3-embedding-0.6b选v0.27.1这类经过验证的稳定镜像通常没问题如果你要上 GLM 5.3 这样的新模型建议先去官方 Release 页面看模型架构是否有专门的适配版本不要盲目追新。固定的版本策略能省掉很多“镜像换了之后指标不对”的排查时间。常见启动错误是 OOMKilled。vLLM 启动时会估算 KV cache 大小如果显存不足会直接退出。排查时先看两件套max-model-len是否过大、gpu-memory-utilization是否超过实际显存。L20 这类 48GB 显存的卡跑 14B 量化模型通常没问题但别把max-model-len拉到 32768 还不改量化精度。另一个经验是在 KServe 里跑多个模型副本时每个副本的显存预留要按模型最大上下文算不能按推理时平均用量算。4.2 queue-proxy 与指标采集不生效KServe 自动伸缩依赖 queue-proxy 暴露的 metrics。如果 Prometheus 没抓到 queue-proxy 的指标autoscaler 会退化为直接使用minReplicas或人工配置。排查顺序确认 Pod 里 queue-proxy 容器处于 Running检查 queue-proxy 是否监听 9090 端口确认 Prometheus 的 ServiceMonitor 选中了对应命名空间。坑在于KServe 默认的 metrics 端口在不同版本里可能变化最好以你部署版本对应的官方文档为准。还有一个高频坑KServe 创建的 Service 端口是 80转发到 Pod 的 queue-proxy 端口实际 vLLM 的 8000 端口在 queue-proxy 内部被代理。如果你在 Pod 里直接kubectl port-forward 8000想看 vLLM 日志有时会发现访问不到因为外部流量根本不走 8000。想看 vLLM 本身的指标或日志直接看容器日志或 exec 进容器再 curl localhost 的 8000 端口。4.3 vLLM 内部机制相关的问题排查很多人问 vLLM enginecore 与 scheduler、executor 交互流程这其实能从日志里看到。启动阶段enginecore 会加载模型权重、初始化 KV cache并把注意力计算任务交给 executor。调度阶段scheduler 根据请求序列长度、可用 KV cache 块、优先级生成批次executor 执行后返回 logits再由采样层产出 token。搞清楚这个流程对排查性能问题很有帮助。比如“并发一高就变慢”如果日志显示 scheduler 老是在等 executor 返回说明 GPU 算力或显存带宽喂不上了如果日志显示排队请求数量多但 GPU 利用率不高可能是--max-num-seqs默认值太小。KServe 不会帮你调这些参数但你可以在args里直接传--max-num-seqs、--swap-space之类的参数。遇到“KServe 跑起来比裸 vLLM 慢”的疑问先别急着怪框架多半是引擎参数没有适配你的流量模型。4.4 部署中常见的几个“是不是我环境的问题”Windows 能跑 vLLM 吗官方镜像和 KServe 都是 Linux 容器化的思路vLLM 本身没有 Windows 支持直接放弃。vllm/vllm-openai镜像里带模型吗不带。镜像只包含引擎代码和依赖库。用 SGLang 还是 vLLM两者都是高性能推理引擎KServe 都有对应 runtime。如果你已经在 vLLM 上调过参迁移到 KServe 完全没必要换引擎如果追求低延迟或特定模型架构支持可以评估 SGLang。我用 Chatbox 直连原来的 vLLM 服务地址迁移到 KServe 后连不上怎么办检查 InferenceService 的status.url把 Chatbox 的 base URL 改成 KServe 生成的入口地址注意路径可能需要补/v1。再整理一张速查表现象原因处理Pod CrashLoopBackOff显存不足或 vLLM 参数冲突调低--max-model-len/--gpu-memory-utilization外部请求 503模型还没就绪或 activator 未就绪看 Pod 状态、readiness 日志缩容不生效minReplicas 设成 1 或 metrics 没采集到把 minReplicas 设为 0检查 queue-proxy 指标canary 流量不切分网关与 VirtualService 冲突检查实例对应的 VirtualService 创建是否被覆盖5. 到底什么时候才需要 KServe5.1 可以继续用 Deployment 的场景如果你的团队只有一两个模型模型几乎不更新流量稳定没有弹性需求也没有多团队共用一块 GPU 集群的压力那么 Deployment Service 依然是最轻的解法。我见过不少内部工具就这么跑维护成本极低。这类场景里引入 KServe 反而会增加学习成本和排障链路得不偿失。5.2 建议迁移到 KServe 的信号下面几个信号只要中两个就可以认真评估 KServe开始给外部用户或业务方提供 API需要 SLA 与监控模型一个月要迭代好几次还想在不中断服务的前提下灰度验证GPU 成本被财务盯上要求夜间低峰自动缩容多个团队都要部署模型但不想互相影响需要有命名空间级别的隔离和配额。迁移时的建议是先用一个非核心模型跑通 KServe保留原 Deployment 作为 fallback。等 canary、服务网格路由、监控都熟练之后再逐步把核心模型迁进来。不要一次性把所有服务都迁到 KServe这个框架的上手曲线虽然不算陡但运维习惯的转变需要时间。5.3 从 Deployment 到 KServe我自己的判断框架我个人在实际操作中的体会是KServe 解决的不是“能不能跑”的问题而是“跑得漂不漂亮”的问题。如果只求能跑Deployment 足够如果希望推理服务变成平台能力让模型上线像提交一份配置一样简单那 KServe 值得投入。踩过几次坑之后现在的默认做法是把新模型一律通过 KServe 发布把 Deployment 方式留给临时调试和一次性实验。这样两种模式的边界很清楚也不会让团队背上不必要的框架包袱。迁移的第一周可能都在和网关、指标、CRD 状态打交道但一旦把链路理顺后续每个模型的发布速度会明显快过手写 Deployment 加 Service 的时代。