Kimi K3 på AWS: HyperPod vs EKS deployment

Åbne modeller som Kimi K3 giver frihed til at vælge, hvor og hvordan man kører sine AI-arbejdslaster. Den frihed har en pris, som jeg ser hos stort set alle mine kunder: der findes ikke én officiel driftssti, sådan som man er vant til med lukkede modeller fra en enkelt udbyder. I stedet skal teamet selv tage stilling til, hvilken AWS-tjeneste der matcher deres kapacitet, deres erfaring med Kubernetes, og hvor meget de vil investere i selv at administrere infrastrukturen.

AWS beskriver i deres blogindlæg, at SageMaker HyperPod er bygget til teams, der vil have en administreret, resilient klyngeoplevelse uden selv at stå for det underliggende orkestreringslag. Ifølge AWS håndterer tjenesten automatisk genoprettelse ved hardwarefejl, hvilket er kritisk, når store modeller som Kimi K3 kører på tværs af mange GPU-noder over lang tid. Mister man en node midt i en træning eller en lang inferensproces, er automatisk failover ifølge AWS forskellen mellem lang nedetid og et hurtigt skift; jeg har ikke selv målt det på Kimi K3, men det stemmer med, hvad jeg har set HyperPod levere på andre modeller.

HyperPod er desuden designet til at understøtte de distribuerede træningsmønstre, som store modeller kræver, herunder parallelisering på tværs af noder. For teams uden dyb Kubernetes-ekspertise er det ifølge AWS' egen beskrivelse den mest direkte vej til at få Kimi K3 op at køre i produktionsskala, fordi meget af det operationelle overhead allerede er løst af tjenesten selv.

Til gengæld betyder den administrerede tilgang mindre fleksibilitet. Man arbejder inden for de rammer, HyperPod stiller op, og har ikke samme frihedsgrad til at tilpasse orkestreringslaget, som man ville have med en fuld Kubernetes-installation.

Amazon EKS repræsenterer den modsatte ende af spektret: fuld kontrol over orkestreringen, men også fuldt ansvar for at konfigurere og vedligeholde den. Her deployerer man Kimi K3 som containeriserede arbejdslaster i et Kubernetes-miljø, hvor teamet selv styrer scheduling, netværk, ressourceallokering og skalering.

Jeg kører selv min egen infrastruktur, så jeg genkender argumentet: for organisationer, der allerede har investeret i Kubernetes, giver EKS mening, fordi Kimi K3 dermed kan indgå i den samme drifts- og overvågningsstak som resten af virksomhedens applikationer. Det betyder også, at man kan genbruge eksisterende CI/CD-pipelines, observability-værktøjer og adgangsstyring i stedet for at introducere endnu et administreret miljø ved siden af.

Prisen for den fleksibilitet er kompleksitet. Ifølge AWS' beskrivelse skal teamet selv håndtere GPU-scheduling, netværkskonfiguration mellem noder og genoprettelse ved fejl, opgaver som HyperPod løser automatisk. For et team uden erfaren Kubernetes-drift kan det betyde en betydelig implementeringsindsats, før Kimi K3 overhovedet kører stabilt.

Det reelle valg handler sjældent om, hvilken tjeneste der er bedst i absolut forstand. Jeg ser det som et spørgsmål om, hvilken kompleksitet organisationen allerede har erfaring med at håndtere, og hvor meget kontrol den har brug for over orkestreringslaget.

Vælger man HyperPod, køber man sig fri af meget af det operationelle arbejde, som ellers følger med at drive store modeller i produktion. Man får hurtigere vej til drift, men mindre fleksibilitet til at skræddersy miljøet.

Vælger man EKS, får man fuld kontrol og mulighed for at integrere Kimi K3 i en eksisterende Kubernetes-baseret infrastruktur. Til gengæld kræver det, at teamet enten allerede har den Kubernetes-erfaring, der skal til, eller er villig til at opbygge den.

I mit arbejde med kunder er svaret typisk afhængigt af, om de allerede har en Kubernetes-praksis stående, eller om de starter fra bunden med AI-infrastruktur. Har man ikke allerede en Kubernetes-organisation, er HyperPod ofte den hurtigste og mest forudsigelige vej til produktion.

Jeg ser i mit arbejde med større AI-projekter, at valget af infrastruktur ofte får langt mindre opmærksomhed end valget af selve modellen, selvom det er infrastrukturbeslutningen, der i sidste ende afgør, hvor hurtigt og hvor stabilt en model som Kimi K3 kommer i drift. En åben model giver frihed, men den frihed flytter ansvaret for driftssikkerhed over på virksomheden selv, uanset om man vælger den administrerede eller den selvstyrede vej.

For danske virksomheder, der overvejer at tage åbne modeller som Kimi K3 i brug, er den vigtigste øvelse derfor ikke kun at vurdere modellens kvalitet, men også ærligt at kortlægge, hvilken driftskapacitet organisationen faktisk har. Har man et modent Kubernetes-team, kan EKS give en mere integreret og fleksibel løsning på sigt. Mangler man den erfaring, er en administreret tjeneste som HyperPod den mere realistiske vej til at få modellen i stabil, skaleret drift uden at skulle opbygge en hel driftsorganisation fra bunden først. Kilde: AWS' blogindlæg om deployment af Kimi K3 på SageMaker HyperPod og EKS.