在 Kubernetes 上跑 LLM 又嫌性能不行——一篇工业论文说:用 Kueue + DAS + GAIE 三件套,TTFT 尾延迟压 90%

  • 关联论文：2602.04900

如果你是平台 / SRE / MLOps 工程师,或者你是 LLM 应用的架构师,过去几年大概率在做一个进退两难的取舍:

到底要不要为了 LLM 单独搭一套推理平台?

  • 选项 A:把 LLM 塞进现有的 Kubernetes 集群——好处是多租户、弹性、声明式一套搞定,坏处是kube-scheduler 不懂 GPU 分片、不懂 prefix cache、TTFT 尾延迟爆表;
  • 选项 B:用 vLLM / TGI / TensorRT-LLM standalone——好处是性能强,坏处是失去 K8s 的多租户账本、HPA、GitOps,运维两套平台并行;
  • 选项 C:用 SageMaker / Azure ML——好处是一键搞定,坏处是被云厂商锁死、$ / 1K tokens 高、源码不可审计。

你大概率以为:"在 K8s 上跑 LLM,就是要牺牲性能换生态。"

但 2026 年 2 月被 ICPE 2026 工业 track 接收的论文 《Evaluating Kubernetes Performance for GenAI Inference》(arXiv 2602.04900v3),正面反驳这个假设:

把 Kueue(批调度)+ DAS(GPU 分片)+ GAIE(在线路由)三件套组合,K8s 完全可以作为高强度 GenAI 推理的统一底座——总 makespan 缩短最高 15%,平均 job 完成时间缩短 36%,TTFT 尾部延迟在高负载下改善高达 90%。

最关键的是:三个组件全部基于 K8s SIG 官方生态 + CNCF 路径,不发明新调度理论,不要求你离开 K8s——你今天就能在自己集群上 PoC 一遍。

今天这篇科普用 5 分钟把它讲透:为什么"小组合"比"换平台"更值钱?哪些坑现在不能踩?

一、GenAI 推理在 K8s 上最痛的"调度盲区"长什么样

在说论文之前,先把痛点摆清楚。

LLM 推理(尤其是 ASR→LLM 流水线)和传统微服务的资源需求差别巨大:

  1. 显存是大头——单卡装不下大模型,要么 tensor parallel / pipeline parallel 分片,要么 KV cache 抢占显存;
  2. prefill / decode 时延特征不同——prefill 是 compute-bound,decode 是 memory-bound;首 token 时间(TTFT)与 token 间时间(ITL)需要分别优化;
  3. 负载形态多样——批推理(batch inference,离线转录、批量摘要)和在线推理(interactive chat、streaming)混在同一集群;
  4. prefix cache 可以复用,但需要智能路由——同一个系统提示词被反复请求,理论上可以省下 prefill,但需要"把相同 prefix 的请求路由到已缓存的 replica"。

K8s 原生的 kube-scheduler 是为通用微服务设计的——它不"懂"GPU 分片、不懂 prefix caching、不懂 LLM 的请求级调度语义。结果是:

  • 要么把 LLM 塞进 K8s 但拿不到最佳性能;
  • 要么退到 vLLM / TGI standalone,但失去 K8s 的多租户 + 弹性 + 声明式 API,运维两套平台并行。

这是 2026 年所有中大型 AI 团队的基础设施焦虑。

二、ICPE 论文的反直觉结论:不换平台,补三件套

论文的核心结论非常直接:

不用新调度理论,就用 K8s 生态里三个已存在的组件(Kueue + DAS + GAIE)组合起来,在同一集群里同时跑 Whisper 离线 + LLM 在线,三件事同时变好:批作业总时间缩短最多 15%、小模型 job 完成时间缩短 36%、TTFT p99 高负载下改善 90%。

实测数据(均来自论文 abstract,均为论文自报告,无独立复现):

  • Kueue 调度 + Whisper:多租户批作业混部场景下,总 makespan 缩短最多 15%——本质是"队列公平性 + 配额管理"减少排队等待;
  • DAS + Whisper 共享 GPU:平均 job 完成时间缩短 36%——本质是把单卡单实例(Whisper 各档只用 10–30% GPU)拉到高利用率;
  • GAIE + llm-d 在线 LLM 路由:TTFT p99 在高负载下改善 90%——本质是 prefix-cache aware routing 把重复 prefill 省下来;
  • 整体结论:三个组件互补——Kueue 管"谁能跑",DAS 管"如何省卡",GAIE 管"如何让请求更快响应"。

最关键的是:不发明新调度理论,不要求你离开 K8s——你已有的 K8s 集群装三个组件,就能在不引入第二套平台的前提下,把 GenAI 推理推到生产级别。

三、怎么 work:Kueue + DAS + GAIE 三件套详解

如果你直接把 vLLM 丢进 K8s,前面提到的"调度盲区"照样存在。ICPE 这篇论文用三件套把盲区逐一击穿:

第 1 件:Kueue——批作业的公平队列 + 配额

Kueue 是 K8s SIG-Batch 下的批作业队列管理器。它引入 Queue / ResourceFlavor / AdmissionCheck 等 CRD,把 JobSet / Kubeflow 等 batch workload 纳入公平队列 + 配额管理。

解决的痛点:当 5 个团队同时往集群提交 Whisper 转录任务时,谁先跑、谁能用多少 GPU、需要排队多久——Kueue 的配额 + 优先级 admission control 避免 GPU 被打爆后整个集群雪崩。

关键能力: - 基于配额的 admission check(避免超额占用); - 公平排队 + 优先级抢占; - 与现有 JobSet / Kubeflow / PyTorchJob 集成(无需重写 workload)。

第 2 件:DAS(Dynamic Accelerator Slicer)——GPU 分片共享

DAS 把一块物理 GPU(如 H100 MIG 或 A100 MIG)切成多个逻辑 accelerator,让多个小模型推理 job 共用同一块卡而不互相干扰。

解决的痛点:Whisper tiny/base/medium 各档单独占一张卡时,GPU 利用率往往只有 10–30%——DAS 让小模型共享显存。

关键能力: - 动态调整分片大小; - 对抗 job 间的显存争用; - 前提:依赖 MIG / NVSwitch 等硬件分片能力,A100/H100 MIG 实例可用。

第 3 件:GAIE + llm-d——在线推理的 prefix-cache 路由

llm-d 是基于 Kubernetes Gateway API Inference Extension(GAIE)的推理路由层:

  • 路由层(control plane):基于 Envoy AI Gateway,识别请求的模型名、长度、prefix 等特征;
  • 调度层(data plane):在请求粒度上做 prefix-cache aware routing——把"语义相近"的请求路由到"已经缓存了对应 prefix KV"的同一 replica,大幅减少重复 prefill;
  • 扩展点:通过 Gateway API 的 BackendTrafficPolicy / InferenceModel CRD 注入路由策略。

解决的痛点:vLLM / TGI 默认有 prefix cache,但没有"把相同 prefix 的请求路由到同 replica"的智能路由;GAIE 是补齐这一环。

            批作业(offline)              在线服务(online)
              ┌─────────┐                  ┌────────────────┐
   audio ───▶ │  Whisper│ ──transcripts──▶ │  LLM summary   │ ──▶ text
              │ (DAS +  │                  │ (llm-d +        │
              │  Kueue) │                  │  GAIE 路由)     │
              └─────────┘                  └────────────────┘

四、为什么这件事对 2026 年的 GenAI 平台团队至关重要

如果你是下面任一种角色,ICPE 这篇几乎就是必读:

  • 平台 / SRE / Infra 工程师:负责 LLM 推理部署,正在评估"用 K8s 一统天下"是否可行——这篇给出不离开 K8s 也能保住性能的工程答案;
  • MLOps 团队:需要在多租户下做 GPU 配额和公平调度——Kueue 是事实标准路径;
  • LLM 应用架构师:关心 TTFT / ITL / p99 延迟优化——GAIE 的 prefix-aware routing 是为数不多的实战方案;
  • CTO / 技术负责人:评估"上 vLLM standalone vs 留在 K8s"的成本与可维护性权衡——这论文给的是第三条路;
  • 不太适合:纯算法研究者(与训练方法无直接关系);K8s 零基础的初学者(前置概念 MIG / Gateway API / prefix cache 较多)。

最关键的一句话:LLM 推理平台不需要为 GenAI 单独搭一套——K8s 生态里三个已存在的组件,就能同时覆盖批作业 + 在线推理 + GPU 共享 + prefix 路由。

五、五处落地风险别踩

风险 1:三个百分比提升均来自论文自带实验,无独立复现

makespan 缩短 15% / job 完成时间缩短 36% / TTFT 改善 90% 这三个数字全部来自论文 abstract,均为论文自报告——industry paper 利益相关性未披露,引用时建议加"论文报告"限定词。落地前必须用你自己的 workload 和集群规模复测一遍。

风险 2:Kueue 不管 Deployment/StatefulSet,只管 batch workload

Kueue 的 admission check 只对 Job / JobSet / PyTorchJob 等 batch workload 生效——Deployment / StatefulSet 跑在线推理,Kueue 管不到。这是 Kueue 的硬边界,必须用 GAIE/llm-d 做在线路由层的补充。

风险 3:DAS 强依赖 MIG 等硬件分片能力

DAS 在 A100/H100 上工作良好(开启 MIG),但在消费级 GPU 或老型号卡上不一定适用。论文也未给出"非 MIG 场景下 DAS 的替代方案"——如果你是消费级卡集群,DAS 这层收益可能没摘要里说的那么大。

风险 4:GAIE 与 llm-d 仍在非常早期

  • GAIE:Kubernetes Gateway API Inference Extension,2026 年中仍处于 alpha / 草案阶段,API 稳定性差;
  • llm-d:CNCF 孵化早期,0.x 版本 CRD 频繁 breaking change;
  • 建议:PoC 验证可以上,核心生产业务不建议直接用——用 GitOps(ArgoCD / Flux)锁定版本,升级前跑 full regression。

风险 5:prefix cache 并非银弹

GAIE 的 prefix-cache aware routing 效果依赖请求的 prefix 重叠度。如果你的 chat 用户各自输入完全不同,cache hit rate 接近 0,prefix 路由无收益。建议先用 vLLM/TGI 内置的 PagedAttention prefix cache 实测 hit rate,再决定是否上 GAIE。

延伸阅读 - 论文:arXiv 2602.04900(《Evaluating Kubernetes Performance for GenAI Inference: From Automatic Speech Recognition to LLM Summarization》,ICPE 2026 industry paper 接收) - Kueue:Kubernetes SIG-Batch 官方项目(Kueue 0.9+) - DAS:Dynamic Accelerator Slicer 设计 / MIG 实例分片 - GAIE:Kubernetes Gateway API Inference Extension(Envoy AI Gateway 后端) - llm-d:基于 GAIE 的 LLM 推理路由(早期 CNCF 孵化项目) - 同方向对比:vLLM / TGI / TensorRT-LLM standalone(model serving layer);KServe v0.16+ LLMInferenceService;Volcano(K8s 批量调度,对 GenAI 支持不如 Kueue)

三个标题变体

  1. LLM 推理别再开第二套平台——Kueue + DAS + GAIE 三件套让 K8s 同时扛批 + 在线,TTFT p99 压 90%
  2. 在 Kubernetes 上跑 GenAI 又嫌性能不行——这篇 ICPE 2026 工业 paper 说"Kueue 排队 + DAS 分卡 + GAIE 路由"就够
  3. 不发明新调度理论——ICPE 2026 论文用三个 K8s 现成组件,把 LLM 推理批 makespan 缩 15%、GPU 利用率拉满

小红书风格卡片文案(可直接发布)

☁️ LLM 推理别再开第二套平台了

是不是很多团队都在痛苦:

🔹 把 LLM 塞进 K8s → kube-scheduler 完全不懂 GPU / 不懂 prefix cache 🔹 用 vLLM standalone → 失去多租户账本、失去 GitOps、运维两套平台 🔹 用 SageMaker → 被云厂商锁死、$ / 1K tokens 高

2026 年 2 月这篇 ICPE 2026 工业 paper(arXiv 2602.04900)给出第三条路 💡:

不发明新调度理论 就用 K8s 生态里三个现成组件 在同一个集群同时跑批 + 在线

🔧 三件套:

① Kueue——批作业公平队列 + GPU 配额管理(谁先跑、配多少) ✅ makespan 缩短最高 15%

② DAS——GPU 分片共享(一张 H100 切多份给小模型用) ✅ 平均 job 完成时间缩短 36%

③ GAIE + llm-d——在线 LLM prefix-cache 智能路由(把同 prefix 路由到同 replica) ✅ TTFT p99 高负载下改善 90%

📊 实测覆盖:Whisper 转录 → LLM 摘要的端到端 ASR→LLM 流水线

这件事对平台 / SRE / MLOps / 架构师都是必读 👀 真正的彩蛋是:三个组件全部基于 K8s SIG 官方生态 / CNCF 路径,不需要你离开 K8s 📡

📖 论文:arXiv 2602.04900(ICPE 2026 industry paper,已被接收) 🏷️ #Kubernetes #LLM #K8s #GenAI #推理平台 #MLOps #vLLM #GPU #开源 #AI前沿 #2026