[AI 基建周报] 6月26日 - 7月2日：llm-d v0.8.1 多层 KV 卸载进生产、SGLang v0.5.14 DeepSeek-V4 吞吐 5x、Kubernetes DRA v1.35 正式 GA

要点：Dynamic Resource Allocation（DRA）在 Kubernetes v1.35 中正式 GA，提供结构化的异构硬件资源动态申请与分配机制；NVIDIA 已将 dra-driver-nvidia-gpu 迁移至 Kubernetes SIGs 统一维护，官方支持力度进一步提升；CNCF 博客同步发布深度解析，覆盖 DRA 工作原理与 GPU 动态分配实践路径。

为什么重要：此前 Device Plugin 模型粒度粗、无法表达资源拓扑与共享语义，导致 GPU 等异构资源调度灵活性严重不足；DRA GA 意味着平台团队终于有了受官方长期支持的标准 API 来替代临时方案，而 NVIDIA driver 进入 SIGs 维护则降低了上游跟进成本与供应商锁定风险。

适用场景：运行 GPU / 加速器工作负载的 AI 训练、推理集群，以及需要对异构硬件（网卡、FPGA 等）做细粒度资源分配的平台；对 GPU 资源共享、拓扑感知调度有强需求的多租户集群尤为适用。

注意事项：DRA 与旧版 Device Plugin 并非同一模型，现有基于 Device Plugin 的 GPU 分配方案需制定迁移计划，不能无缝原地切换；升级至 v1.35 前需确认集群中已有 ResourceClaim / ResourceClass 等 DRA 相关 CRD 及 RBAC 策略不冲突；dra-driver-nvidia-gpu 迁入 SIGs 后版本号与发布节奏可能与原 NVIDIA 渠道不同，落地前须核对驱动版本兼容矩阵。

行动建议：预发验证后升级：先在非生产 GPU 集群验证 DRA + dra-driver-nvidia-gpu 完整链路，确认现有 Device Plugin 工作负载迁移路径后再推生产。

要点：Volcano v1.14.3 发布，集中修复五个生产级缺陷：HAMi vGPU 在中大规模集群下调度失败（#5434）、Ascend vNPU 健康检查错误使用非 Allocatable 资源（#5437）、scalar in-queue 资源记账毫单位计算错误（#5503）、Network-Topology-Aware 调度软模式对 job/subjob 处理异常（#5513），以及释放 Pod 时 device 相关注解未清除导致的资源信息残留（#5486）。

为什么重要：vGPU/vNPU 调度失败和资源记账错误会直接导致 AI 训练任务堆积或 GPU 资源被误判占用，在多租户 GPU 集群中影响面广；device 注解未清除则可能引发后续调度决策错误。跑 HAMi 或昇腾硬件的平台团队若停留在旧版本，上述问题均为静默失效，难以从日志直接定位。

适用场景：使用 HAMi vGPU 或华为昇腾 vNPU 的 AI/ML 训练集群，尤其是节点数较多的中大规模集群；以及依赖 Network-Topology-Aware 软模式调度分布式作业的场景。

注意事项：本次为纯 bugfix 版本，无 API 变更，升级风险低；但建议升级后在预发环境验证 scalar 资源配额数值是否与升级前一致（毫单位修复可能导致 in-queue 统计值发生变化），避免影响已有队列准入策略；同时确认现存 Pod 的 device 注解是否已按预期清除，必要时手动核查存量注解。

行动建议：使用 HAMi vGPU 或昇腾 vNPU 的集群建议尽快跟进升级（稳定性补丁），其余场景预发验证后升级。

要点：Kueue v0.18.2 和 v0.17.6 同步发布，主要修复四类问题：1）DRA 中携带 matchAttribute 或 device config 的 workload 被错误拒绝（#12471）；2）TAS 独立 nomination 引发拓扑域冲突导致 workload 长时间 pending（#12521/#12523）；3）MultiKueue 场景下 Kubernetes Job 状态残留及 Pod workload 误触 Cluster Autoscaler 扩容（#12380/#12272）；4）RayJob/RayCluster/RayServe 启用 GCS fault tolerance 时 Redis cleanup 资源未计入配额（#12395）。v0.17.6 回移了除 DRA 修复外的同类补丁。

为什么重要：TAS 调度冲突和 MultiKueue 状态残留会直接造成 workload 卡 pending 或配额核算错误，影响批处理作业吞吐；Pod workload 误触 CA 扩容则带来不必要的节点开销和成本浪费；RayJob 的 Redis cleanup 配额漏记会让配额管控形同虚设。对依赖这些功能的平台团队而言，不升级意味着在生产中踩已知、可复现的稳定性坑。

适用场景：使用 DRA 设备调度、TAS 拓扑感知调度、MultiKueue 多集群分发，或集成 Ray（RayJob/RayCluster/RayServe）并开启 GCS fault tolerance 的集群；跑 AI/ML 批处理或大规模并行作业的平台团队优先受益。

注意事项：v0.17.x 用户可升至 v0.17.6 获得回移修复，无需跨大版本；升级前确认当前使用的功能是否命中上述 issue，升级后重点验证 TAS 调度分配是否正常、MultiKueue Job 最终状态是否清理干净、Ray workload 配额消耗是否符合预期；DRA matchAttribute 修复仅在 v0.18.2，若依赖该特性须升至 v0.18.x。

行动建议：尽快跟进（稳定性补丁）：命中 TAS/MultiKueue/RayJob 场景的团队应在预发验证基本功能后尽快升级对应版本。

要点：KAI-Scheduler v0.16.2 发布，包含三项 bug 修复：1）Pod 缓存内存持续增长问题，通过仅保留调度必要字段、剔除大型 env 字面值与 managed fields 解决；2）分数 GPU 内存分配场景下 MinNodeGPUMemoryMiB 计算错误（#1795）；3）isNonPreemptableOverquota 抢占检查时错误使用集群最小 GPU 尺寸而非最大值导致判断偏差（#1792）。

为什么重要：Pod 缓存内存泄漏在大规模集群或高频调度场景下会持续消耗调度器内存直至 OOM；GPU 内存计算错误与抢占逻辑误判则会导致分数 GPU 资源调度不准确、高优先级作业抢占行为异常，直接影响 GPU 集群利用率与作业 SLA。

适用场景：运行 KAI-Scheduler 的 GPU 集群，尤其是使用分数 GPU（fractional GPU）内存分配、或开启抢占策略、或集群 Pod 数量较大导致调度器内存压力明显的生产环境。

注意事项：升级前建议在预发环境验证抢占策略行为是否与预期一致，因 #1792 修正了抢占判断逻辑，修复后的行为与旧版本存在差异；同时观察调度器进程内存趋势，确认缓存增长问题得到收敛；当前 release notes 未列出破坏性变更，但抢占逻辑修正属于行为变更，需结合业务作业优先级配置做回归验证。

行动建议：预发验证抢占行为后尽快升级（内存泄漏与调度正确性均为生产级问题）

要点：OpenTelemetry Collector Contrib v0.155.0 发布：新增 alpha 阶段 cardinality guardian processor（#47368），可拦截 metrics 基数爆炸；pkg/ottl 引入 LambdaExpression API 与 stringify_all editor，扩展管道内数据变换能力；exporter/load_balancing 针对 traceID 路由大幅降低 CPU 与内存分配（#48983），processor/k8s_attributes 修复容器重启后 pod 标识符内存无限增长（#48398）。

为什么重要：基数爆炸是大规模 metrics 采集中最常见的成本失控根源，cardinality guardian processor 提供了一个 Collector 侧的防护阀，使平台团队无需依赖后端存储限流即可提前截断高基数标签；k8s_attributes 内存泄漏修复直接影响容器频繁重启的动态集群的 Collector 稳定性，积压已久的内存增长问题得到解决。

适用场景：适用于大规模 Kubernetes 集群中部署了 OTel Collector 并面临 metrics 基数管控压力的平台团队；使用 load_balancing exporter 做 traceID 亲和路由的链路采集场景，以及容器重启频繁（如 CronJob、短生命周期 Pod）导致 k8s_attributes processor 内存持续攀升的集群。

注意事项：cardinality guardian processor 处于 alpha 阶段，接口与行为可能变动，不建议直接用于生产关键路径；注意两处破坏性变更：schemagen 已迁移至 opentelemetry-collector 主仓库（若有 CI 依赖需同步调整），signalfx exporter 停止默认计算 per-core cpu.* metrics，使用 SignalFx 后端的团队需确认 dashboard 及告警规则中是否依赖这些指标，升级前务必检查。

行动建议：预发验证后升级：优先验证 signalfx exporter 指标变更与 schemagen 依赖影响，k8s_attributes 内存泄漏修复和 load_balancing 性能优化对动态集群有实质收益，建议跟进本版本。

要点：Kepler 完成架构重构，重点提升数据中心场景下 GPU 与 CPU 功耗测量精度；本次重构聚焦于能耗采集层的准确性，使 Kubernetes 工作负载级别的电力消耗数据更可信；同步发出社区参与号召，邀请贡献者共建能耗可观测生态。

为什么重要：数据中心电力消耗已占全球用电量 1.5%（2024 年数据），平台团队在缺乏精准功耗指标的情况下无法做有效的绿色容量规划或 FinOps 成本归因；重构后 GPU 功耗测量精度提升，对 AI/ML 推理与训练集群尤为关键，可为多租户电力成本分摊提供更可靠的基础数据。

适用场景：适合运行 GPU 工作负载（如 AI 推理、模型训练）的集群，以及有绿色计算合规要求或需要按工作负载做能耗成本归因的多租户平台环境。

注意事项：架构重构意味着内部采集逻辑变化，升级前需核验现有 Kepler 暴露的 Prometheus metrics 名称与标签是否兼容，避免破坏已有能耗告警与 Dashboard；GPU 功耗采集依赖底层硬件驱动（如 NVML）权限，落地前确认节点驱动版本与权限配置满足要求；当前处于新特性阶段，建议先在非生产集群验证测量数据准确性。

行动建议：仅评估关注，在测试集群部署验证 GPU/CPU 功耗指标准确性，待社区反馈稳定后再纳入生产能耗观测栈

要点：Dragonfly v2.5.0 新增 Dragonfly Client 原生支持直接从 Hugging Face 和 ModelScope 拉取模型仓库，无需额外适配层；模型分发能力正式纳入其 P2P 加速的云原生分发层。

为什么重要：大规模 AI 集群在冷启动或模型版本切换时，节点并发拉取 Hugging Face / ModelScope 模型会打爆出口带宽、拖慢 Pod 就绪；Dragonfly 的 P2P 机制可将流量分散到节点间互传，平台团队无需自建模型缓存代理即可获得带宽收益。

适用场景：适合在 Kubernetes 上跑推理或训练任务、节点数较多（>10）且频繁拉取大体积模型（GB 级）的集群；尤其适用于已部署 Dragonfly 做镜像加速、希望复用同一套分发基础设施覆盖模型分发的平台团队。

注意事项：facts 中未披露破坏性变更细节，升级前需比对 v2.5.0 release notes 确认 Dragonfly Client 配置字段是否有变化；Hugging Face / ModelScope 访问依赖外网或私有镜像站，需提前确认网络策略和鉴权（token）在新版 Client 中的传入方式；建议在非生产环境先验证模型下载完整性与 P2P 回源逻辑。

行动建议：预发验证后升级——已用 Dragonfly 做镜像加速的团队优先评估，验证模型下载链路后再推生产。

要点：SGLang v0.5.14 发布：DeepSeek-V4 在 GB300（SM100）上吞吐提升 5x（相同交互性约束下）；新增 LPLB 线性规划负载均衡器（#24515）与 Waterfill MoE expert parallelism 调度；KDA CuteDSL prefill kernel 在 SM100 上比 Triton 快 1.08–1.52x（#27488），int8 checkpoint pool 大幅扩充 KDA/GDN 前缀缓存容量（#28185）；新增 GLM-5.2、LiquidAI LFM2.5、Kimi-K2.7-Code 等模型支持，MSCCL++ 迁移至 upstream mscclpp 并支持 collective 自动调优（#22734），AMD ROCm 新增 breakable CUDA graph（#28173），Ascend NPU 支持 DeepSeek-V4（#25144）。

为什么重要：MoE 大模型部署的核心瓶颈之一是 expert 负载不均与 prefill 吞吐受限——LPLB 和 Waterfill 调度直接针对多节点 expert parallelism 下的负载倾斜，int8 checkpoint pool 则在不增加显存的前提下扩大前缀缓存命中率；对于已上 GB300 或 ROCm 集群的平台团队，此版本是 DeepSeek-V4 生产化的关键里程碑。

适用场景：运行 DeepSeek-V4 等 MoE 大模型、追求高并发 prefill 吞吐的 GB300/SM100 集群；使用 AMD ROCm 或昇腾 NPU 的多硬件混合推理平台；有长前缀共享（代码补全、RAG）需求、希望提升 KV Cache 命中率的在线服务场景。

注意事项：MSCCL++ 已迁移至 upstream mscclpp 包（#22734），依赖此组件的部署需同步更新依赖并重新验证 collective 通信性能；LPLB 和 Waterfill 为新调度路径，生产上线前须在目标拓扑（节点数、expert 数）下做压力测试确认无调度抖动；int8 checkpoint pool 与现有 KV Cache 配置可能存在参数冲突，升级后需核验 --kv-cache-dtype 及相关内存配额设置。

行动建议：预发环境验证 MSCCL++ 依赖迁移与新调度路径后再升级，GB300/ROCm/Ascend 用户优先级较高

要点：TensorRT-LLM v1.3.0rc20 完成 DeepSeek-V4 端到端准备，涵盖 IndexerTopK、MoE routing、sparse cache manager 及 disagg transceiver 批量集成；新增 MXFP8 W8A8 Linear/MoE 和 Marlin NVFP4 MoE/Linear（Hopper），并支持 Blackwell cross-attention FlashInfer TRT-LLM Gen kernels 与多模态 encoder CUDA Graph wrapper。同版本修复了 disagg cache transceiver teardown 及 draft KV cache 过度分配两处生产级缺陷。

为什么重要：DeepSeek-V4 的 MoE routing 与 sparse cache manager 集成意味着平台团队可在 TRT-LLM 框架内获得官方级别的大规模 MoE 推理支持，无需自行维护 fork；MXFP8/NVFP4 精度支持可在 Hopper/Blackwell 卡上进一步压低显存占用与推理成本，是高并发 MoE 服务的关键杠杆。draft KV cache 过度分配修复直接影响内存利用率，disagg transceiver teardown 修复则关系到 prefill/decode 分离架构的稳定性。

适用场景：适用于已部署或计划部署 DeepSeek-V4 / 大规模 MoE 模型的 H100/H200（Hopper）及 Blackwell GPU 集群；使用 prefill-decode 分离（disaggregated serving）或投机解码（speculative decoding）的高吞吐推理服务；有多模态编码器推理需求且希望通过 CUDA Graph 降低调度开销的工作负载。

注意事项：BREAKING CHANGE：chat_template 已改为 opt-in（#14646），直接升级会导致依赖默认 chat_template 的推理流程静默失效，需逐一核查服务入口配置；TensorRT backend 将在下一版本正式移除，仍依赖该 backend 的流水线须尽快制定迁移计划；RC 版本尚未 GA，不应直接上生产，应在测试/预发环境完整验证 MoE routing、KV cache 行为及多模态路径后再评估跟进节奏。

行动建议：RC 勿上生产，仅测试环境验证；重点核验 chat_template opt-in 变更与 TensorRT backend 依赖，为正式版升级铺路

要点：vLLM v0.24.0rc2 针对 PR #46628 修复了 P/D Disaggregation（Prefill/Decode 分离部署）与 DP Supervisor（Data Parallel Supervisor）配合使用时的 bug，属于集成层面的正确性修复。

为什么重要：P/D Disaggregation 是大规模推理集群降低 TTFT 与提升吞吐的关键架构，与 DP Supervisor 联动时若存在 bug 会导致调度异常或请求失败；此次修复意味着同时启用这两项特性的团队可以获得更稳定的集成行为，是 v0.24.0 正式版前的必要质量收敛。

适用场景：适用于已经或计划同时启用 Prefill/Decode 分离部署与 Data Parallel Supervisor 的推理集群，尤其是对延迟敏感、需要高并发扩展的大模型在线服务场景。

注意事项：当前为 RC 版本，不建议直接上生产；验证时需重点覆盖 P/D Disaggregation + DP Supervisor 同时开启的路径，确认请求路由、负载均衡及故障恢复行为符合预期；若团队未使用上述两特性的组合，此补丁影响有限，可等待正式 GA 版本。

行动建议：rc 勿上生产，仅在测试环境中验证 P/D Disaggregation 与 DP Supervisor 集成路径，为 v0.24.0 GA 发布做好回归基线准备。

要点：llm-d v0.8.0 将多模态服务、批量网关（batch gateway）、流量控制（flow control）正式升级为生产就绪；llm-d-kv-cache v0.9.0 新增 HMA（Heterogeneous Memory Allocation）、多层 KV 卸载（CPU→存储）及 Mooncake connector，大幅拓展 KV Cache 的异构内存管理能力；核心组件完成重命名：llm-d-inference-scheduler → llm-d-router-endpoint-picker，llm-d-routing-sidecar → llm-d-router-disagg-sidecar，GPU/ROCm/XPU 平台统一切换至上游 vLLM v0.23.0 官方镜像。

为什么重要：KV Cache 长期是大模型推理集群的内存瓶颈，多层卸载与 HMA 支持使平台团队可将 KV 数据下沉至 CPU 内存乃至存储层，显著降低高并发下的 GPU 显存压力；批量网关与流量控制 GA 意味着离线/在线混合负载在 Kubernetes 上有了经官方背书的生产路径，减少自研调度胶水层的维护成本。

适用场景：适用于在 Kubernetes 上运行 vLLM 推理服务且有多模态、批量推理或高并发流量整形需求的集群；新增的 FileDiscovery 插件（RL/Slurm 非 Kubernetes 模式）也适合混合调度环境中需要将 llm-d 路由能力延伸到非 K8s 节点的场景。

注意事项：核心组件重命名（llm-d-inference-scheduler、llm-d-routing-sidecar）是破坏性变更，所有引用旧组件名的 Helm values、ConfigMap、监控告警规则、CI 脚本须在升级前全面替换；vLLM 镜像切换至 v0.23.0 上游官方镜像，需确认自定义镜像层或私有 registry 同步就绪；多层 KV 卸载与 HMA 为新特性，建议先在预发环境压测验证内存回收与延迟表现，再逐步推广至生产。

行动建议：预发验证后升级：优先在预发环境完成组件重命名适配与 vLLM 镜像同步，验证 KV 卸载与批量网关稳定性后，再滚动上生产；v0.8.1 补丁已跟进，建议直接以 v0.8.1 为升级目标版本。

要点：Ray 2.56.0 重构了 Serve LLM 的请求处理与 token 流式响应路径（#62667–#63167），同步将 vLLM 升级至 0.22.0，并新增 ConsistentHashRouter（会话粘性路由）和 CapacityQueueRouter（容量队列路由）；Ray Core 引入 GPU domain-aware placement groups（label locality，#61442），支持按拓扑感知约束分配 GPU 资源；初步支持 Kubernetes v1.35 in-place Pod 扩缩容（IPPR，#55961），同时 RDT 新增并发单边传输多 ObjectRef 能力（#61773）。

为什么重要：LLM 推理场景下请求处理与流式传输耦合是 Serve 长期吞吐瓶颈，解耦后可减少 token 首包延迟抖动；GPU domain-aware 调度解决多机多卡拓扑不对齐导致的通信开销问题，对 tensor-parallel / pipeline-parallel 训练任务尤为关键；IPPR 支持让平台团队在不重启 Pod 的前提下垂直扩缩 Ray worker，降低长运行任务中断风险。

适用场景：部署 vLLM 推理服务并需要会话粘性或容量限流的 Ray Serve 集群；使用多 GPU 节点做分布式训练且对 NVLink/InfiniBand 拓扑敏感的集群；已运行 Kubernetes v1.35 并希望为 Ray worker 启用原地垂直扩缩容的平台环境。

注意事项：vLLM 同步升至 0.22.0，需提前核查与现有模型配置及自定义插件的兼容性；IPPR 功能标注为初步支持，依赖 Kubernetes v1.35 且该特性本身仍处于 Kubernetes 演进阶段，生产慎用；ConsistentHashRouter 和 CapacityQueueRouter 为新增路由策略，需回归测试现有路由配置是否受影响；升级前在预发环境对 Serve LLM 流式路径进行端到端压测，验证延迟改善符合预期。

行动建议：预发验证后升级：重点回归 vLLM 兼容性与 Serve LLM 流式路径，IPPR 仅在测试环境评估，不建议直接在生产启用