Eks Genai

GenAI on Amazon EKS

End-to-end opinionated guidance for running generative AI / LLM workloads on Amazon EKS, structured as a 6-layer stack from compute hardware up through the AI gateway. This skill is opinionated: it recommends one AWS-canonical reference stack — the JARK stack (JupyterHub + Argo + Ray + Karpenter) extended with vLLM serving and a LiteLLM gateway — and surfaces the alternatives plus the customer-context flags that justify deviating.

Two sources are the canonical foundation and every recommendation must align with one or both: the EKS AI/ML Best Practices guide and the awslabs/ai-on-eks reference implementation. For "how do I run a single EKS cluster well" (compute, networking, upgrades) use eks-best-practices; for designing/building the cluster itself use eks-design / eks-build. This skill is the GenAI workload layer on top.

When to Use This Skill

Activate when the user wants to:

• Choose GenAI hardware — NVIDIA GPU (p5/g6/g6e) vs AWS Neuron (Trainium/Inferentia)
• Serve an LLM (vLLM, Ray Serve, Triton, KServe) or run distributed training/fine-tuning on EKS
• Design GPU/Neuron scheduling (Karpenter NodePools, device plugins, EFA, Capacity Blocks, Spot)
• Pick ML storage (FSx for Lustre, Mountpoint S3 CSI, EFS, S3 Vectors) or wire GPU/Neuron observability
• Stand up an AI gateway (LiteLLM/Envoy), RAG pipeline, or agentic platform on EKS
• Optimize GenAI cost (Neuron migration, Spot+checkpoint, KV-cache tiering, consolidation)

Don't use this skill for:

• SageMaker-only or Bedrock-only (no self-hosting) — defer to ML/Bedrock guidance; this skill covers Bedrock only as a gateway target alongside self-hosted models
• "Is EKS the right base?" not yet decided — run container-service selection first
• Generic cluster design/build with no AI/ML workload → eks-design / eks-build
• Self-service golden paths / Internal Developer Platform for ML teams (Backstage templates, ML-pipelines-as-a-service, multi-tenant self-serve) → eks-platform-engineering. This skill is the GenAI workload layer (how to serve/train the model); platform-engineering is the self-service delivery layer (how teams request it). Ray Serve can appear in both — use this skill for the serving architecture, that one for the golden-path wrapper.
• Generic Kubernetes concepts (Claude knows these)

The 6-Layer Stack

Layer 6  AI Gateway / App   LiteLLM · Envoy AI Gateway · RAG · Bedrock AgentCore · Strands
Layer 5  Observability      DCGM Exporter · Neuron Monitor · Prometheus/Grafana · AMP/AMG
Layer 4  Storage            FSx for Lustre · Mountpoint S3 CSI · EFS · S3 Vectors
Layer 3  Frameworks         Ray + KubeRay · vLLM · Triton/Dynamo · Kubeflow/KServe (JARK)
Layer 2  Cluster/Scheduler  Karpenter · NVIDIA + Neuron device plugins · EFA · Capacity Blocks
Layer 1  Compute/Hardware   NVIDIA GPU (p5/g6/g6e) · AWS Neuron (Trainium/Inferentia)

Walk the customer bottom-up (Layer 1 → 6) on first engagement; revisit top-down for optimization. Each layer below gives the decision rule; depth is in the references.

Layer 1 — Compute / Hardware (the single most-impactful decision)

For Transformer-family LLMs, evaluate AWS Neuron first when the workload permits it; it often wins on price-performance. Do not reflexively pick NVIDIA GPU (the most common SA mistake).

• Default to AWS Neuron (Trn2/Trn1 training, Inf2 inference) when the model is Transformer-family (Llama, Mistral, Qwen, Falcon) + framework is PyTorch/vLLM + cost-conscious + the team can absorb a 1-2 week compilation ramp. Up to ~50% cost-to-train (Trainium) / ~40% better price-performance (Inferentia2).
• Default to NVIDIA GPU (g6/g6e inference, p5/p5e training) for fastest time-to-first-success, CUDA-only dependencies, novel/non-Transformer architectures, or multi-modal models.

Right hardware = f(workload type × model family × latency × cost posture × team skill × timeline) — never one dimension alone. Full instance matrix + MIG/time-slicing: compute-hardware.md.

Layer 2 — Cluster / Scheduler

Karpenter is the only recommended autoscaler for GPU/Neuron (Cluster Autoscaler is not). Provision two NodePools (GPU + Neuron) from day one so future hardware migration is a cost experiment, not a re-architecture. Use EKS-optimized accelerated AMIs (Bottlerocket/AL2023) so drivers are pre-installed. Multi-node training needs EFA + NUMA pinning + static CPU manager (bandwidth halves without them) and NCCL/MPI in the image. Use the Neuron device plugin for EKS Auto Mode and dynamic Karpenter provisioning; the DRA driver (K8s 1.34+) is supported on Karpenter static-capacity NodePools, managed node groups, and self-managed nodes (not Auto Mode, not dynamic provisioning). Guarantee planned training capacity with Capacity Blocks for ML. Spot rule: training only with checkpoint/resume; inference On-Demand. Details: cluster-and-scheduling.md.

Layer 3 — Orchestration / Frameworks (most opinionated layer)

Default to the JARK stack + vLLM. vLLM is the default LLM inference engine (PagedAttention, OpenAI-compatible, GPU + Neuron via neuronx-distributed-inference); Ray + KubeRay is the default for distributed training and multi-replica serving. Reach for Triton (multi-framework/TensorRT), Dynamo (disaggregated prefill/decode), Kubeflow (full MLOps), or KServe (scale-to-zero) only when their specific flag applies. Decision table: inference-serving.md and distributed-training.md.

Layer 4 — Storage

Default → Mountpoint for S3 CSI for inference (lazy-load weights, per-pod cache) + FSx for Lustre for training (sub-ms, EFA-connected, S3 DRA for checkpoint offload). Use EFS only for shared multi-model weights, and S3 Vectors for cost-efficient RAG vector storage. Critical rule: FSx in the same AZ as the GPU/Neuron nodes — cross-AZ latency dwarfs FSx's native performance. Pre-warm FSx before launching Spot capacity. Details: storage.md.

Layer 5 — Observability

GenAI observability adds three first-class concerns over standard EKS: accelerator utilization/memory, per-token/per-request latency, and per-workload cost attribution. Stack: NVIDIA DCGM Exporter (GPU) + AWS Neuron Monitor (Trn/Inf) → Prometheus → Grafana, with vLLM metrics (TTFT, time-per-output-token, queue time). Use Amazon Managed Prometheus + Managed Grafana in production; keep observability pods off the GPU/Neuron nodes. Details: observability.md.

Layer 6 — AI Gateway / Application

For multi-model (self-hosted + Bedrock) serving, a gateway is non-negotiable. Default → LiteLLM (OpenAI-compatible proxy, per-tenant rate limiting + token cost accounting, Langfuse tracing); Envoy AI Gateway when you need L7 routing at ingress. For RAG, default the vector store to Bedrock Knowledge Bases (or S3 Vectors for cost) unless self-managed is required. For agents, default to Bedrock AgentCore (managed) or Strands Agents SDK for self-hosted. Details: ai-gateway.md, agentic-and-rag.md.

The Opinionated Reference Stack

The AWS-canonical default, shipped end-to-end in awslabs/ai-on-eks and the GenAI-on-EKS workshops:

Pointing customers at the awslabs/ai-on-eks blueprints is the fastest credible path from idea to production. The current NVIDIA workshop validates this stack on EKS Auto Mode (K8s 1.34, a workshop-pinned snapshot; deploy the latest supported EKS version) with g6e (L40S), vLLM + KubeRay, Strands Agents, LMCache, and kube-prometheus-stack + AMP. Concrete versions and use-case → blueprint mapping: reference-implementations.md.

Security Baseline (non-negotiable)

Every GenAI-on-EKS recommendation MUST include: EKS Pod Identity / IRSA for pod credentials (never static keys); ECR image scanning; secrets via Secrets Manager/Parameter Store + Secrets Store CSI (never baked into images); model artifact provenance (image signing or Hugging Face checksum verification); private subnets for GPU/Neuron nodes with VPC endpoints for S3/Bedrock; audit logging to CloudTrail/CloudWatch; and Pod Security Admission restricted + CIS-hardened AMI for regulated/shared clusters. Details and compliance regimes: security-and-compliance.md.

Cost Optimization

Savings levers in priority order: (1) Capacity Blocks for planned multi-day training; (2) Neuron over GPU for supported architectures; (3) Spot + Karpenter + checkpointing for fault-tolerant training; (4) MIG / time-slicing for shared dev clusters; (5) Karpenter consolidation for off-peak inference; (6) KV-cache tiering + S3 lazy-load. Always give directional ranges with caveats — never point estimates. Details: kv-cache-and-cost.md.

Top Guardrails (the high-cost mistakes)

• Don't default to NVIDIA GPU — evaluate Neuron first for Transformer LLMs.
• Don't use Spot for training without checkpoint/resume — guaranteed cost-burn.
• Don't recommend Cluster Autoscaler for new GenAI clusters — Karpenter only.
• Never suggest Karpenter can purchase or create a Capacity Block (or ODCR) — it only consumes pre-existing reservations. The customer buys the CB manually; Karpenter launches into it.
• Don't put FSx for Lustre cross-AZ from the compute nodes.
• Don't skip NUMA pinning + static CPU manager on EFA multi-node training.
• Don't pull model weights from Hugging Face at every pod start — pre-cache to S3/FSx.
• Don't skip the AI gateway for multi-model deployments, or the security baseline ever.
• Don't give point cost estimates — directional ranges with caveats only.

How to Use the References

Progressive disclosure — the essentials are above; load a reference only when the task needs that depth:

Sources

• Best Practices for AI/ML Workloads on Amazon EKS · AI/ML Networking · AI/ML Storage · AI/ML Performance
• awslabs/ai-on-eks — canonical reference implementation (JARK, inference-ready-cluster, training, neuron, gateways blueprints)
• EKS for AI/ML · Manage Neuron devices on EKS · EFA with EKS
• Guidance for Scalable Model Inference and Agentic AI on Amazon EKS
• Workshops: GenAI on EKS using NVIDIA GPU · using AWS Neuron · Advanced Agentic AI on EKS