李学端（意琦行） | AI Infra / Kubernetes / GPU Scheduling

前一篇《Ascend vNPU 实战：从原生 Docker 到 Ascend Docker Runtime》已经跑通了 vNPU 的两种用法，本文继续把这套能力接进 Kubernetes，用 HAMi 统一管理 vNPU。

本文以 Ascend 310P3（Atlas 300I Pro）为例，介绍昇腾 NPU vNPU 的基本使用方法。 内容包括从原生 Docker 开始，演示手动创建 vNPU 并挂载到容器，以及 Ascend Docker Runtime 下的静态挂载和动态虚拟化。

上一篇 https://www.lixueduan.com/posts/ai/27-why-pd-disaggregation/ 介绍了为什么要把 Prefill 和 Decode 拆开。本文继续往下走，在单节点 GPU 环境中搭建一个可以从头复现的 PD 分离 Demo，先用最小实现把整个链路跑通。

本文不引入复杂组件，只使用 vLLM 和一个轻量 Proxy，把 Prefill 与 Decode 两个阶段串起来。

Demo 主要看两件事：

• PD 分离后的请求执行流程，观察同一个请求如何依次经过 Proxy、Prefill 和 Decode；
• PD 分离中的 KV Cache 数据流，确认 Prefill 生成的 KV Cache 如何通过 KV Connector/NIXL 交给 Decode。

KubeClipper 1.7.0 发布了。

本次版本新增 API 驱动的 Operation v2，移除了旧的 NATS Operation 投递链路，集群创建、扩容、删除等操作统一使用新的 Operation v2。新增 kcctl status 和 kcctl doctor 平台诊断命令，新增了对 Kubernetes 1.37 版本的支持，并对镜像仓库管理、离线镜像加载和部署预检查进行了优化。

LLM 推理服务的性能瓶颈，不只在模型大小和 GPU 算力。副本增加后，请求落到哪个实例、长 Prompt 是否干扰流式输出、KV Cache 能否复用，都会直接影响延迟、吞吐和成本。

其中，Prefill/Decode 分离（PD 分离）是把两类截然不同的计算负载拆到独立资源池中的方案。本文从问题出发，说明它解决什么、代价是什么，以及何时不该使用它。

模型服务运行后，固定副本数很难同时兼顾突发请求和资源利用率。请求增加时需要扩容，流量回落后又希望及时缩容。

本文通过一个简单 Demo，为 KServe 模型服务接入 KEDA，根据 vLLM 的请求指标自动调整副本数，并验证服务从 1 -> 2 -> 1 的扩缩容过程。