KnoAI 技术站

主题

CNCF 迎来新 Silver 成员：当企业将 AI 从训练推向推理，云原生基础设施正经历“主权化”与“成本敏感性”的双重重构 ​

SoftBank Corp. 与 Crusoe 的加入，表面是 CNCF 会员扩容的常规新闻，实则折射出一个关键拐点：AI 工作负载正从「实验室级 GPU 密集型训练」，系统性迁移到「生产级、高吞吐、低延迟、多租户共置」的推理服务阶段；而支撑这一迁移的底层基础设施，不再仅追求“能跑 vLLM”，更要求“可审计、可隔离、可计费、可主权管控”——云原生已从容器编排工具集，升维为 AI 时代的 SRE 治理协议栈。

背景动机：为什么是现在？——从“GPU 资源荒”到“推理 SLO 瘟疫” ​

2024–2025 年，头部互联网与金融企业普遍完成大模型训练基建（如自建千卡 A100/H100 集群），但很快陷入“训练很酷、推理很痛”的困境：

  • 资源碎片化：单个 LLM 推理服务（如 Llama-3-70B + vLLM）常需 4–8 张 A10G，但实际 QPS 波动剧烈（早高峰 vs 午休），静态分配导致 GPU 利用率长期低于 30%；
  • SLO 不可控：P99 延迟从 120ms 突增至 2.3s（因同节点其他 Pod 触发 NVLink 内存带宽争抢）；
  • 主权合规缺口：某跨国银行在华推理服务被要求“模型权重不出境、日志元数据本地留存、GPU 调度链路可审计”，但现有 K8s Device Plugin + kube-scheduler 扩展机制缺乏细粒度策略注入能力。

SoftBank Corp.（日本最大电信运营商，运营超 200 万边缘节点）与 Crusoe（专注低碳算力调度的美国初创，用废弃天然气发电驱动 GPU 集群）的联合入会，并非偶然。二者分别代表两大刚需：

  • SoftBank：需要在 5G MEC 边缘节点上，以 sub-10ms 网络延迟调度 vLLM 实例，且满足日本《个人信息保护法》（APPI）对推理请求 trace 的强制留存要求；
  • Crusoe：需在电价波动剧烈的离网场景下，实现 GPU 资源“按毫秒计费 + 热迁移容错”，其自研的 crusoe-device-plugin 已支持 nvidia.com/gpu:power-capped 和 nvidia.com/gpu:thermal-throttle-aware 两类扩展资源类型。

这标志着：AI 推理已不再是“附加功能”，而是 K8s 集群的头等公民（First-Class Workload）——它倒逼调度器、设备插件、可观测性栈、安全策略层全面升级。

核心技术：让 vLLM 在 K8s 上真正“生产就绪”的三把钥匙 ​

CNCF 新成员贡献的核心代码并非宏大框架，而是直击推理运维痛点的轻量级增强。我们以 SoftBank 提交的 k8s-device-policy-controller 为例，解析其如何解决“GPU 共享下的 SLO 可保障性”问题。

🔑 1. 基于 DeviceProfile 的 GPU 硬隔离策略（非 CUDA MIG） ​

传统方案依赖 NVIDIA MIG（Multi-Instance GPU），但 MIG 有硬约束：A100 必须切为 7×1g.5gb 或 4×3g.20gb，无法灵活适配 vLLM 的 2g/4g/6g 显存需求。SoftBank 提出的 DeviceProfile CRD，允许声明式定义显存+带宽+NVLink 组合策略：

yaml
# deviceprofile.yaml
apiVersion: devices.k8s.io/v1alpha1
kind: DeviceProfile
metadata:
  name: vllm-4g-2nvlink
spec:
  selector:
    matchLabels:
      device-type: nvidia.com/gpu
  resources:
    - name: nvidia.com/gpu
      quantity: "1"
      constraints:
        memory: "4Gi"          # 严格限制显存分配上限
        nvlink-bandwidth: "12GB/s"  # 保证最小 NVLink 带宽
        exclusive: true        # 禁止与其他 Pod 共享同一 GPU

配合其 device-policy-controller，该策略会在 Pod 创建时注入 nvidia.com/gpu.memory.limit 和 nvidia.com/gpu.nvlink.min annotation，并触发 nvidia-container-toolkit 动态生成 --shm-size=2g --ulimit memlock=-1 等运行时参数。

🔑 2. 推理专属调度器：vllm-scheduler —— 基于 Token 吞吐量的亲和性调度 ​

Crusoe 贡献的 vllm-scheduler 不再只看 requests.nvidia.com/gpu，而是通过 webhook 获取 vLLM 实例的实时 prefill_throughput（预填充吞吐）与 decode_throughput（解码吞吐）指标，实现跨节点的“吞吐最优匹配”：

yaml
# pod-with-vllm-scheduling.yaml
apiVersion: v1
kind: Pod
metadata:
  name: vllm-llama3-70b
  annotations:
    scheduling.k8s.io/vllm-prefill-target: "1200 tokens/s"
    scheduling.k8s.io/vllm-decode-target: "850 tokens/s"
spec:
  containers:
  - name: vllm-server
    image: vllm/vllm-openai:0.4.2
    resources:
      requests:
        nvidia.com/gpu: "4"
      limits:
        nvidia.com/gpu: "4"
    env:
    - name: VLLM_ENABLE_PREFIX_CACHING
      value: "true"

调度器会查询 Prometheus 中 vllm_gpu_decode_tokens_per_second_total{pod=~"vllm.*"} 指标，优先将该 Pod 调度至当前 decode 吞吐 > 900 tokens/s 的节点（避免冷节点因缓存未热导致 P99 延迟飙升）。

SoftBank 补全了 K8s 原生监控的致命盲区——NVLink 不是“网络接口”，但却是 vLLM 多卡通信的生命线。其 gpu-metrics-exporter 通过 nvidia-smi -q -d NVLINK 解析，暴露如下指标：

# HELP gpu_nvl_link_bandwidth_gbps NVLink bandwidth in Gbps (per link)
# TYPE gpu_nvl_link_bandwidth_gbps gauge
gpu_nvl_link_bandwidth_gbps{pod="vllm-llama3-70b-7f8c4",container="vllm-server",gpu="0",link="0"} 14.2
gpu_nvl_link_bandwidth_gbps{pod="vllm-llama3-70b-7f8c4",container="vllm-server",gpu="0",link="1"} 0.0  # link 1 is down → 触发告警

结合 Prometheus rule，可定义 SLO：avg_over_time(gpu_nvl_link_bandwidth_gbps{pod=~"vllm.*"}[5m]) < 8.0 → 自动驱逐该 Pod 并重调度。

运维建议：SRE 团队必须立即落地的 4 项检查清单 ​

基于上述技术演进，我们向中高级 SRE 提出可执行、可验证的落地建议（非理论空谈）：

  1. 【紧急】审计现有 GPU Pod 的 securityContext
    检查是否启用 allowPrivilegeEscalation: false + runAsNonRoot: true。vLLM 0.4+ 已支持非 root 运行，但大量 Helm Chart 仍默认 runAsUser: 0。执行：

    bash
    kubectl get pods -A -o jsonpath='{range .items[?(@.spec.containers[*].resources.requests["nvidia.com/gpu"])]}{.metadata.namespace}{" "}{.metadata.name}{" "}{.spec.securityContext.runAsUser}{"\n"}{end}' | grep " 0$"

  2. 【高优】部署 device-profile-controller 并禁用 MIG（除非业务强依赖）
    MIG 会锁死 GPU 架构，阻碍弹性扩缩。在 A100/H100 集群上，用 nvidia-smi -mig 0 关闭 MIG，改用 DeviceProfile 管理显存粒度。

  3. 【标准】为所有 vLLM Service 配置 PodDisruptionBudget + topologySpreadConstraints

    yaml
    topologySpreadConstraints:
- maxSkew: 1
  topologyKey: topology.kubernetes.io/zone
  whenUnsatisfiable: DoNotSchedule
  labelSelector:
    matchLabels:
      app: vllm-inference

    防止单可用区故障导致整个推理集群不可用。

  4. 【长期】构建“推理 SLO 看板”：聚合 vLLM metrics + K8s events + GPU telemetry
    关键指标必须联动：vllm_request_success_ratio（业务层） × gpu_nvl_link_bandwidth_gbps（硬件层） × kube_pod_status_phase{phase="Pending"}（调度层）。单一维度告警已失效。

延伸阅读：超越会员新闻的技术纵深 ​

  • 🔗 CNCF SIG-AI 2026 Roadmap：明确将 GPU Scheduling Policy API（KEP-3821）列为 v1.31 核心特性，SoftBank 是主要作者之一；
  • 📚 Crusoe 白皮书：Thermal-Aware GPU Orchestration：揭示 GPU 温度每升高 10°C，FP16 计算吞吐下降 17%，而 nvidia-smi -q -d TEMPERATURE 从未被 K8s scheduler 读取；
  • ⚙️ 动手实验：在 Kind 集群中快速验证 DeviceProfile（需 NVIDIA Container Toolkit 1.14+）：
    bash
    git clone https://github.com/softbank-k8s/device-policy-controller.git
kubectl apply -k device-policy-controller/config/default/
kubectl apply -f examples/vllm-4g-profile.yaml

最后一句判断：CNCF Silver 会员的更新，从来不是关于“谁加入了”，而是关于“谁定义了下一阶段的生产水位线”。当 SoftBank 要求 GPU 调度必须满足 APPI 审计，当 Crusoe 要求 GPU 计费精度达毫秒级——他们不是在提交 PR，而是在重写云原生的宪法序言：Infrastructure is not neutral. It is policy, encoded.
（基础设施绝非中立。它是被编码的政策。）