AIConformance-1.36.yaml

# Kubernetes AI Conformance Checklist
# Notes: This checklist is based on the Kubernetes AI Conformance document.
# Participants should fill in the 'status', 'evidence', and 'notes' fields for each requirement.

metadata:
  kubernetesVersion: v1.36
  platformName: "[Platform Name]"
  platformVersion: "[Platform Version]"
  vendorName: "[Vendor Name]"
  websiteUrl: "[Website URL]"
  repoUrl: "[Repository URL]"
  documentationUrl: "[Documentation URL]"
  productLogoUrl: "[Documentation URL]"
  description: "[Description]"
  contactEmailAddress: "[Contact Email Address]"

spec:
  accelerators:
    - id: driver_runtime_management
      description: "Provide a verifiable mechanism for ensuring that compatible accelerator drivers and corresponding container runtime configurations are correctly installed and maintained on nodes with accelerators. Once the accelerator supports exposing driver and runtime version information as part of DRA, then the platform should use the DRA mechanism for verification."
      level: SHOULD
      status: ""
      evidence: []
      notes: ""
    - id: gpu_sharing
      description: "For accelerators that support static GPU sharing, provide well-defined mechanisms for at least one GPU sharing strategy to improve utilization for workloads that do not require a full dedicated GPU. If hardware-level partitioning is supported, then these fractional GPU resources should be exposed as schedulable resources. If software-based sharing (e.g. time-slicing) is supported, then oversubscription of GPUs should be allowed. Forward-looking: Once the accelerator supports static GPU sharing as part of DRA, the platform should expose the DRA mechanism to allow users to leverage static GPU sharing. Once the accelerator supports dynamic GPU sharing as part of DRA and the partitionable devices feature is GA, the platform should expose the DRA mechanism to allow users to leverage dynamic GPU sharing."
      level: SHOULD
      status: ""
      evidence: []
      notes: ""
    - id: virtualized_accelerator
      description: "For accelerators that support virtualized accelerator technologies (e.g. vGPU), provide well-defined mechanisms for these to be exposed and managed, maintaining consistency with physical fractional GPUs. Forward-looking: Once the accelerator supports virtualized accelerator technologies as part of DRA, then the platform should use the DRA mechanism."
      level: SHOULD
      status: ""
      evidence: []
      notes: ""
  networking:
    - id: ai_inference
      description: "Support the Kubernetes Gateway API with an implementation for advanced traffic management for inference services, which enables capabilities like weighted traffic splitting, header-based routing (for OpenAI protocol headers), and optional integration with service meshes."
      level: MUST
      status: ""
      evidence: []
      notes: ""
    - id: advanced_inference_ingress
      description: "Support an implementation of the Gateway API Inference Extension (GAIE), which can route requests to models hosted on Kubernetes. The implementation supports serving LLMs and making advanced routing decisions (e.g., K/V cache-aware routing) based on metrics and capabilities advertised by the underlying model serving platform."
      level: SHOULD
      status: ""
      evidence: []
      notes: ""
    - id: high_performance_networking
      description: "If high performance pod-to-pod communication is needed, then provide well-defined mechanisms for these specialized network resources to be managed and exposed such that their characteristics should be discoverable to enable informed scheduling or workload configuration and to enable pods to attach to multiple network interfaces. Platforms should use DRA as the mechanism to manage and expose these specialized network resources (e.g., DRANET)."
      level: SHOULD
      status: ""
      evidence: []
      notes: ""
    - id: disaggregated_inference
      description: "Support the deployment and operation of disaggregated inference architectures. To be conformant, the platform should demonstrate that it can successfully install and run a disaggregated inference solution (e.g., vLLM, SGLang, llm-d, or Dynamo, with separate instances for distinct phases like prefill and decode). Disaggregated serving splits phases such as prefill and decode into separately scalable components so each phase can match different compute/memory/network needs, improving GPU utilization and tail latency while enabling higher throughput under mixed and bursty LLM workloads."
      level: SHOULD
      status: ""
      evidence: []
      notes: ""
  schedulingOrchestration:
    - id: gang_scheduling
      description: "The platform must allow for the installation and successful operation of at least one gang scheduling solution that ensures all-or-nothing scheduling for distributed AI workloads (e.g. Kueue, Volcano, etc.) To be conformant, the vendor must demonstrate that their platform can successfully run at least one such solution."
      level: MUST
      status: ""
      evidence: []
      notes: ""
    - id: cluster_autoscaling
      description: "If the platform provides a cluster autoscaler or an equivalent mechanism, it must be able to scale up/down node groups containing specific accelerator types based on pending pods requesting those accelerators."
      level: MUST
      status: ""
      evidence: []
      notes: ""
    - id: pod_autoscaling
      description: "If the platform supports the HorizontalPodAutoscaler, it must function correctly for pods utilizing accelerators. This includes the ability to scale these Pods based on custom metrics relevant to AI/ML workloads."
      level: MUST
      status: ""
      evidence: []
      notes: ""
  observability:
    - id: accelerator_metrics
      description: "For supported accelerator types, the platform must allow for the installation and successful operation of at least one accelerator metrics solution that exposes fine-grained performance metrics via a standardized, machine-readable metrics endpoint. This must include a core set of metrics for per-accelerator utilization and memory usage. Additionally, other relevant metrics such as temperature, power draw, and interconnect bandwidth should be exposed if the underlying hardware or virtualization layer makes them available. The list of metrics should align with emerging standards, such as OpenTelemetry metrics, to ensure interoperability. The platform may provide a managed solution, but this is not required for conformance."
      level: MUST
      status: ""
      evidence: []
      notes: ""
    - id: ai_service_metrics
      description: "Provide a monitoring system capable of discovering and collecting metrics from workloads that expose them in a standard format (e.g. Prometheus exposition format). This ensures easy integration for collecting key metrics from common AI frameworks and servers."
      level: MUST
      status: ""
      evidence: []
      notes: ""
  security:
    - id: secure_accelerator_access
      description: "Ensure that access to accelerators from within containers is properly isolated and mediated by the Kubernetes resource management framework (device plugin or DRA) and container runtime, preventing unauthorized access or interference between workloads."
      level: MUST
      status: ""
      evidence: []
      notes: ""
  operator:
    - id: robust_controller
      description: "The platform must prove that at least one complex AI operator with a CRD (e.g., Ray, Kubeflow) can be installed and functions reliably. This includes verifying that the operator's pods run correctly, its webhooks are operational, and its custom resources can be reconciled."
      level: MUST
      status: ""
      evidence: []
      notes: ""