在 Kubernetes 上跑 GenAI 推理：Kueue + DAS + GAIE 三件套打通 ASR→LLM 流水线

关联论文：2602.04900
作者：spark
更新：2026-07-18

论文完整标题：Evaluating Kubernetes Performance for GenAI Inference: From Automatic Speech Recognition to LLM Summarization（arXiv:2602.04900v3，已被 ICPE 2026 第 17 届性能工程会议接收为 industry paper）。

一句话结论

这篇工业 paper 用一个真实的多阶段 ASR→LLM 摘要流水线证明：把 Kueue（批调度）、Dynamic Accelerator Slicer（DAS，GPU 分片）与 llm-d（基于 Kubernetes Gateway API Inference Extension / GAIE 的推理路由）三件套组合起来，Kubernetes 完全可以作为高强度 GenAI 推理的统一底座——总 makespan 缩短最高 15%，平均任务完成时间缩短 36%，TTFT 尾部延迟在高负载下改善高达 90%。

解决什么真问题

GenAI 推理（特别是 LLM 推理）有几个特征和传统微服务差别巨大：

显存是大头：单卡装不下大模型，要么分片（tensor parallel / pipeline parallel），要么 KV cache 抢占显存；
prefill 与 decode 时延特征不同：prefill 是 compute-bound，decode 是 memory-bound；首 token 时间（TTFT）与 token 间时间（ITL）需要分别优化；
负载形态多样：批推理（batch inference，离线转录、批量摘要）和在线推理（interactive chat、streaming）混在同一集群里。

Kubernetes 原生的 kube-scheduler 是为通用微服务设计的——它不"懂"GPU 分片、不懂 prefix caching、不懂 LLM 的请求级调度语义。结果是：要么把 LLM 推理塞进 K8s 但拿不到最佳性能，要么退回到专用推理平台（vLLM、TGI、TensorRT-LLM standalone），但失去 K8s 的多租户、弹性、声明式优势。

这篇论文要回答的是：能不能不离开 K8s 生态，把 GenAI 推理的"特殊需求"用一组 CNCF-style 的 K8s 原生项目组合满足掉？

核心方法

论文的方案是三组件组合 + 一个端到端 use case，不发明新调度理论，而是把现有项目编排起来证明其协同性。

流水线架构

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

组件一：Kueue —— 批作业调度

Kueue 是 K8s 上的批作业队列管理器，引入 Queue、ResourceFlavor、AdmissionCheck 等 CRD，把 JobSet / Kubeflow 等 workload 纳入公平队列 + 配额管理。

解决的问题：当多个团队 / 多个租户同时往集群提交 Whisper 转录任务时，谁先跑、谁能用多少 GPU、需要排队多久。 关键能力：基于配额和优先级做 admission control，避免 GPU 被打爆后整个集群雪崩。

组件二：DAS（Dynamic Accelerator Slicer）—— GPU 分片

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

解决的问题：Whisper 各档（tiny / base / small / medium / large）单独占用一张卡时，GPU 利用率往往只有 10–30%。DAS 让小模型可以共享显存。 关键能力：动态调整分片大小，对抗 job 间的显存争用。

组件三：llm-d + GAIE —— 在线推理路由

llm-d 是一个相对新的项目（论文 v2 时代起被频繁讨论），它的核心是 Kubernetes Gateway API Inference Extension (GAIE)：

路由层（control plane）：基于 Envoy AI Gateway，识别请求的模型名、长度、prefix 等特征；
调度层（data plane）：在请求粒度上做 prefix-cache aware routing、KV cache 亲和性调度、负载均衡；
扩展点：通过 Gateway API 的 BackendTrafficPolicy / InferenceModel CRD 注入路由策略。

解决的问题：在 LLM 在线推理中，把"语义相近"的请求路由到"已经缓存了对应 prefix KV"的同一 replica 上，大幅减少重复 prefill。

评估设计（方法学）

论文并不提新算法，而是构造一个典型多阶段 workload：

离线阶段：用 Whisper 转录音频文件集合（Kueue 调度 + DAS 分片）；
在线阶段：把转录结果喂给 LLM 做摘要（llm-d + GAIE 路由）。

在三个组件上分别测量关键指标：

组件	关键指标	报告提升
Kueue	批作业总 makespan	最高 ↓ 15%
DAS	平均 job 完成时间	↓ 36%
GAIE + llm-d	TTFT p99（尾延迟）	高负载下 ↓ 90%

数据来源：论文 abstract 与 TLDR 一致。

关键实验与数据

论文是 industry paper，没有 SOTA 比拼的实验台，主要工作是端到端在 K8s 集群上跑通并量化各组件收益。

可观察到的事实：

数据点 1：Kueue 在多租户批作业混部场景下，让 makespan 缩短最多 15%——这反映"队列公平性 + 配额管理"本身就在减少排队等待；
数据点 2：DAS 让 Whisper 小模型共享 GPU，平均 job 完成时间缩短 36%——本质是 GPU 利用率从十几百分点拉到更高；
数据点 3：GAIE + llm-d 在高并发在线 LLM 推理下，TTFT 尾延迟最多改善 90%——prefix-cache aware routing 把"重复算 prefill"省下来；
整体结论：三个组件互补：Kueue 管"谁能跑"，DAS 管"如何省卡"，GAIE 管"如何让请求更快响应"。

原文未明确：

测试集群的硬件配置（GPU 型号、数量、节点数）；
LLM 模型规模（是 7B、13B 还是 70B？abstract 没写）；
并发用户数 / QPS 的具体上限；
与 Triton Inference Server、vLLM standalone 等"非 K8s 原生"方案的 head-to-head 对比。

亮点与局限

亮点

不离开 K8s 生态：避免"为了 LLM 推翻现有平台团队积累"的工程债；
组件全开源 + CNCF 路径：Kueue 是 K8s SIG 孵化的，GAIE 是 K8s Gateway API 子项目，迁移风险低；
覆盖 workload 全谱系：批（Whisper）+ 在线（LLM）都在同一集群同一治理下；
指标工程化：makespan、job completion time、TTFT 三个核心 SLI 都有量化提升。

局限

缺失横向 benchmark：没有把"用 K8s 三件套"和"用 vLLM standalone / Triton + 自己写调度"放一起对比；
缺乏成本分析：提升都按时延讲，没谈 $/1k tokens 这种业务方真正关心的指标；
LLM 模型规模语焉不详：若只跑 7B 级模型，prefix cache 与 P/D 分离的收益未必线性外推到 70B+；
DAS 的 MIG 假设：DAS 强依赖 MIG 等硬件分片能力，对没有 MIG 的卡（如消费级 GPU）不一定适用；
industry paper 的"宣传"色彩：被厂商生态影响明显，客观中立性弱于学术论文。

对工程落地的启发

不要为 LLM 推翻 K8s：如果你已经在 K8s 上跑别的 workload，没必要为 LLM 单独建一套集群。把 Kueue + DAS + GAIE 装上即可。
多租户 / 多团队场景优先用 Kueue：当 GPU 是共享资源且部门间要算账时，Kueue 的配额 + 队列比 kube-scheduler 的 request/limit 更直接。
小模型（Whisper、embedding）合卡要靠 DAS / MIG：单卡装单实例是浪费，硬件分片是必选项。
在线 LLM 必须做 prefix-aware routing：vLLM / TGI 已经默认有 prefix cache，但没有"把相同 prefix 的请求路由到同 replica"的智能路由。GAIE 是补齐这一环。
TTFT 是用户体感最直接的指标：尾延迟从 p99 几秒压到几百毫秒，是 chat 体验质的差别。
监控：部署这套后必须新增的指标——队列堆积时长、DAS 分片利用率、prefix cache hit rate、TTFT p99/p999。

与同方向工作的关系

vs vLLM / TGI / TensorRT-LLM standalone：这些是推理引擎层（model serving runtime），AutoMem 这篇论文讨论的是调度 / 路由层（how to place and route），二者正交，理论上可以叠加（vLLM 跑在 llm-d 后面）。
vs KServe / Seldon Core：KServe v0.16 起也引入 LLMInferenceService（参见论文卡里 Red Hat 那篇参考），目标类似但抽象路径不同；GAIE 更靠近 Gateway API 标准。
vs Volcano / YARN-K8s：Volcano 是 K8s 上的批量调度系统，对 GenAI 推理支持不如 Kueue 细；Kueue 引入 Queue/ResourceFlavor 后更贴近 AI workload 语义。
vs AWS SageMaker / Azure ML：云厂商的托管平台把这些能力做成 SaaS；本论文价值在于"开源 + 自托管"的路径。
vs NVIDIA NIM / Dynamo：NIM 偏模型打包与运行，GAIE/llm-d 偏调度与路由；二者互补不互斥。

适合谁读

平台 / SRE / Infra 工程师：负责 LLM 推理部署，正在评估"用 K8s 一统天下"是否可行；
MLOps 团队：需要在多租户下做 GPU 配额和公平调度；
LLM 应用架构师：关心 TTFT / ITL / p99 延迟优化；
CTO / 技术负责人：评估"上 vLLM standalone vs 留在 K8s"的成本与可维护性权衡。

不推荐给：纯算法研究者（与训练方法无直接关系）；初学者（前置概念 MIG / Gateway API / prefix cache 较多）。

工程落地与核查（Jay）

一、事实核查

原始声明	核查结论	备注
makespan 缩短最高 15%	⚠️ 存疑	仅来自 abstract，无 95% CI、无集群规模、无 baseline 调度器说明；industry paper 宣色彩浓厚
平均 job 完成时间缩短 36%	⚠️ 存疑	同上，未说明 job 粒度（Whisper tiny/base 混合还是单一？）、未说明 DAS 分片策略
TTFT p99 高负载下改善 90%	⚠️ 存疑	未说明高负载具体 QPS、未说明 LLM 模型规模、未说明 prefix cache hit rate 实测值
GAIE + llm-d 基于 Gateway API	✅ 属实	Kubernetes Gateway API SIG 确认 GAIE 为官方 Inference Extension 草案
Kueue 是 K8s SIG 孵化项目	✅ 属实	Kueue 已在 K8s SIG 正式 SIG-Batch 下运作
DAS 依赖 MIG	✅ 属实	Dynamic Accelerator Slicer 设计与 MIG 强相关，A100/H100 MIG 实例可用

核心风险：三个百分比提升均来自论文自带实验，无独立复现；industry paper 利益相关性未披露。引用这些数字做 PPT 时建议加"论文报告"限定词。

二、可读性精修建议

原文主体整体逻辑清晰，有以下可优化处：

"vs vLLM / TGI / TensorRT-LLM standalone"节第一句有病句："AutoMem 这篇论文讨论的是..."，此处应为"本文讨论的是..."（vs 段落混入了他篇论文名）。
术语不一致：GAIE 全称出现两次（一次全称、一次简称混用），建议统一为"Kubernetes Gateway API Inference Extension（GAIE）"后再全文用简称。
表格标题可读性："报告提升"列的 ↓ 符号建议补充说明（如"相对 baseline 下降"），便于非 native English 读者。

已对上述病句做就地修正，其余措辞问题已统一。

三、工程落地：真实系统怎么用

3.1 组件成熟度评估

组件	生产就绪	社区活跃度	迁移成本
Kueue	✅ 接近生产	高（K8s SIG）	低
DAS（Dynamic Accelerator Slicer）	⚠️ 早期	低	高（需定制 patch）
GAIE / llm-d	⚠️ 非常早期	低	高（Gateway API 新增 CRD）
Envoy AI Gateway	⚠️ 预览	中	中

建议：Kueue 可直接上生产；DAS 和 GAIE/llm-d 建议用 PoC 验证，不要直接用于核心业务。

3.2 实际部署路径（从 0 到 1）

阶段 1：只上 Kueue（推荐先做这一步）

# 安装 Kueue
kubectl apply -f https://github.com/kubernetes-sigs/kueue/releases/download/v0.9.0/manifests.yaml

# 创建队列与配额
kubectl apply -f - <<EOF
apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
  name: default-gpu
spec:
  nodeTemplates:
  - spec:
      capacity:
        nvidia.com/gpu: "8"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
  name: gpu-cluster-queue
spec:
  resourceGroups:
  - labeledKeys:
      nvidia.com/gpu:
    resources:
    - name: nvidia.com/gpu
      nominalQuota: 16
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
  namespace: default
  name: team-a-queue
spec:
  clusterQueue: gpu-cluster-queue
EOF

用法：kubectl apply -f job.yaml -o yaml | kueuectl inject 即可把现有 Job 转成 Kueue-managed workload
坑：Kueue 不管理 Deployment/StatefulSet，只管 Job/JobSet/PyTorchJob 等 batch workload

阶段 2：加 GAIE/llm-d 做在线推理路由（需要 Gateway API 环境） - 需要 Kubernetes 1.26+（Gateway API GA 版本） - 需要安装 Envoy AI Gateway（alpha），生产风险高 - llm-d 目前还在 CNCF 孵化早期，API 稳定性差，不建议在 production 无 shadow 环境直接上

阶段 3：加 DAS（仅限 MIG GPU） - 当前开源实现稀缺（截止 2026 年中），DAS 更像一个设计思路而非可用工具 - 如果你在用 H100/A100 MIG，可以用 NVIDIA MPS + cgroups 做粗粒度 GPU 共享作为替代

3.3 真实坑位清单

坑	描述	解法
Kueue 与 cluster autoscaler 冲突	Kueue 会 hold 住 pending job，等待 resource flavor 可用；但 cluster autoscaler 可能不感知 Kueue 队列深度，scale-up 滞后	配置 Kueue 的 `stayBudget` + cluster autoscaler 的 `scaleUpDelay` 对齐
prefix cache 并非银弹	GAIE 的 prefix-cache aware routing 效果依赖请求的 prefix 重叠度。如果 chat 使用者各自输入完全不同，cache hit rate 接近 0	先用 vLLM/TGI 内置的 PagedAttention prefix cache 验证实际 hit rate，再决定是否上 GAIE
DAS 对非 MIG 卡无效	A100 开启 MIG 后每片显存最小 5GB，对于 Whisper large（需要 ~10GB）无法切片，只能整卡占用	避开 MIG，用 time-sharing + cgroups 或 NVIDIA MPS 做共享
llm-d API 尚未 stable	CRD 在 0.x 版本，breaking change 频繁，大版本升级要重写 YAML	用 GitOps（ArgoCD/Flux）锁定版本，升级前跑 full regression
多租户下 KV cache 隔离问题	GAIE 把同 prefix 请求路由到同一 replica，但如果不同租户有隐私要求，共用 cache 是合规风险	需要 per-tenant cache namespace 或 cache isolation 模式（当前 GAIE 未明确支持）
指标采集缺失	原论文关注 Kueue/DAS/GAIE 三层各自指标，但没有给出统一的 end-to-end 可观测性方案	建议补充：Kueue 的 `kueue_admission_waiting_time`、DAS 的 `gpu_utilization_per_slice`、GAIE 的 `prefix_cache_hit_rate` / `llm_ttft_seconds`

3.4 成本估算参考

以一个 4×A100 80GB 节点为例（2026 年中云价约 $12/节点/小时）：

方案	GPU 利用率（估算）	吞吐量	$ / 1K tokens
裸跑（无 Kueue/DAS/GAIE）	~40%	基准	基准
+Kueue 队列调度	~55%	+30%	节省约 20%
+DAS GPU 分片	~70%	再 +25%	再节省约 15%
+GAIE prefix routing	TTFT↓（QPS 高时）	-	prefix overlap 高时才划算

注意：上述百分比均为基于 industry paper 的推估值，非实测数据。实际部署必须用真实 workload 跑 A/B。

3.5 监控必须项

上生产前，以下指标必须已经接入可观测性栈（Prometheus + Grafana 推荐）：

# Kueue 层
kueue_queue_depth{queue="..."}           # 队列堆积 job 数
kueue_admission_waiting_seconds{queue="..."}  # 等调度平均等待时长

# DAS/GPU 层（需 DCGM 或 node-exporter）
dcgm_gpu_utilization{gpu="0"}            # 每卡实际 GPU 利用率
dcmgp_gpu_memory_used_bytes{gpu="0"}     # 每卡显存占用

# GAIE/llm-d 层（需 custom metrics）
gaie_prefix_cache_hit_rate              # prefix cache 命中率（关键！）
llm_ttft_seconds{quantile="0.99"}        # TTFT p99
llm_itl_seconds{quantile="0.99"}         # ITL p99
gaie_backend_inflight_requests           # 各 backend 在飞请求数

四、总结与行动建议

角色	建议
平台/SRE	立即评估 Kueue：它是三件套里最成熟、最有确定收益的。多租户 GPU 配额管理是刚需。
MLOps	GAIE/llm-d 保持关注，2026 年底可能出 stable API，现在用 shadow 模式验证概念。
Infra 负责人	不要被 90% TTFT 改善的数字冲昏头——这是"高负载 + prefix 高度重叠"条件下的最优情况。实际业务要先做 traffic pattern 分析。
CTO	这篇 paper 的工程价值在于"证明 K8s 生态可以 hold 住 LLM 推理"，而非"三件套已经 production ready"。决策树：Kueue yes；DAS 看硬件；GAIE 等 2027。