AWS kuttet GPU-en i åttedeler 6. august 2026, og det endrer hvordan nordiske skyteam bør tenke om AI-infrastruktur. Amazon Elastic Container Service (ECS) fikk støtte for fractional GPU-scheduling med nye EC2 G6f-instanser, der en arbeidslast kan reservere så lite som 1/8 av en NVIDIA L4 Tensor Core GPU med 3 GB dedikert GPU-minne. For team som allerede følger utviklingen i skytjenester og har betalt for hele GPU-er bare for å kjøre små inferensmodeller, batch-jobber eller grafikkoppgaver, er dette den første virkelig finkornede GPU-tildelingen AWS har levert i ECS.

Nyheten kommer midt i en periode der skyregninger for GPU-kapasitet har blitt en av de største kostnadspostene for AI-satsende selskaper i Norden. Samtidig som FinOps-team rapporterer at store deler av skyforbruket går til spille, gir AWS nå kundene et verktøy for å matche GPU-kapasitet mot faktisk behov i stedet for å runde opp til en hel GPU per container. Dette er ikke bare en teknisk detalj i en produktkunngjøring. Det er et signal om hvor AWS tror etterspørselen etter GPU-ressurser er på vei.

Hvordan fractional GPU-scheduling fungerer i ECS

Mekanismen er enklere enn navnet antyder. En utvikler definerer en ECS-oppgave og setter GPU-ressursverdien til et desimaltall i stedet for et heltall. AWS beskriver det selv presist: utviklere kan be om en fraksjonert GPU ved å sette GPU=0,125, GPU=0,25 eller GPU=0,5 i containerdefinisjonen til en ECS-oppgavedefinisjon, ifølge Amazon Web Services’ (AWS) offisielle produktkunngjøring. ECS plasserer deretter oppgaven på en G6f-instans som har en GPU-profil som matcher forespørselen.

GPU-partisjonering på maskinvarenivå

Det som skiller G6f fra eldre løsninger for GPU-deling, er at partisjoneringen skjer i maskinvaren, ikke gjennom tidsdeling i programvarelaget. Hver G6f-instans eksponerer en fast GPU-skive, enten 1/8, 1/4 eller 1/2 av en NVIDIA L4, med dedikert GPU-minne og dedikert regnekapasitet. AWS’ egen utviklerdokumentasjon slår fast at G6f-instanser gir maskinvarepartisjonerte fraksjoner av en NVIDIA L4 GPU, der hver instans eksponerer en fast GPU-skive med dedikert GPU-minne og beregningskraft. Det betyr at to containere som deler samme fysiske GPU ikke konkurrerer om samme minnepool slik tradisjonell GPU-virtualisering ofte har gjort.

Fra desimaltall til plassering i klyngen

Desimalverdiene 0,125, 0,25 og 0,5 behandles som fraksjonerte GPU-forespørsler og plasseres på instanser med tilsvarende GPU-partisjon, ifølge AWS’ ECS-dokumentasjon. Det praktiske resultatet er at et team kan kjøre åtte små inferenstjenester på samme fysiske GPU, der hver tjeneste får sin egen garanterte skive i stedet for å dele en hel GPU uforutsigbart. ECS Managed Instances og vanlige EC2-kapasitetsleverandører støtter konfigurasjonen, og en og samme kapasitetsleverandør kan blande fraksjonerte G6f-instanser med fullstørrelses GPU-instanser som g5 eller g6.

G6f-instansene: spesifikasjoner og størrelser

AWS har foreløpig publisert konkrete tall for de minste og mellomste G6f-størrelsene. Tabellen under viser hva som er bekreftet fra AWS’ egen dokumentasjon og fra tredjepartskilder som følger instanskatalogen tett. Der tall ikke er offentliggjort, er det markert tydelig i stedet for å anslås.

InstansGPU-andelvCPUGPU-minne
g6f.large1/8 (0,125)23 GB
g6f.xlarge1/8 (0,125)43 GB
g6f.2xlarge1/4 (0,25)86 GB
g6f.4xlarge1/2 (0,5)Ikke bekreftet i tilgjengelige kilder12 GB

Mønsteret er tydelig: hver gang instansstørrelsen dobles, dobles også GPU-andelen og minnet som følger med. En full NVIDIA L4 GPU har 24 GB minne, så en g6f.large med 3 GB tilsvarer nøyaktig en åttedel av det, mens g6f.4xlarge med 12 GB tilsvarer halvparten. Det er dette forholdet som gjør “fractional” til et presist tall og ikke en markedsføringsterm.

Priser og fakturering per sekund

AWS har ikke publisert en fullstendig, enhetlig prisliste for alle G6f-størrelser i alle regioner. Det eneste konkrete tallpunktet som er verifisert, kommer fra tredjepartssiden CloudPrice, som noterer 0,95 dollar i timen for g6f.4xlarge i regionene US East (Virginia), US East (Ohio) og US West (Oregon). Dette er ikke en offisiell AWS-listepris, men et tredjeparts prissporingstall, og det bør leses som en indikasjon snarere enn en garantert sats for europeiske regioner.

Det som derimot er offisielt bekreftet, er faktureringsmodellen. EC2-forbruk faktureres i ettsekunds-intervaller med et minimum på 60 sekunder, uavhengig av om instansen kjører en full GPU eller en fraksjonert skive. For team som kjører korte, sporadiske inferenskall, betyr det at kostnadsbildet nå følger faktisk GPU-bruk mye tettere enn før, der en hel GPU-instans kunne stå delvis ledig store deler av døgnet.

Fra MIG til maskinvarepartisjonering: den korte historien om GPU-deling

GPU-deling i skyen har gått gjennom flere faser. Først kom enkel tidsdeling, der flere prosesser tok turer på samme GPU uten garantert minneisolasjon. NVIDIA introduserte senere Multi-Instance GPU (MIG) på Ampere- og Hopper-arkitekturer, som ga faste partisjoner på enkelte av de største datasenter-GPU-ene. Problemet har vært at MIG historisk har vært forbeholdt de dyreste GPU-modellene, noe som har gjort finkornet deling irrelevant for team som kjører mindre inferensarbeid på billigere kort som L4.

G6f flytter den samme ideen ned til et mer kostnadseffektivt GPU-segment. I stedet for å kreve at kunder kjøper en hel L4 for en oppgave som bruker en brøkdel av kapasiteten, lar AWS nå ECS-planleggeren legge flere mindre arbeidslaster på samme fysiske kort med dedikert minne per skive. Det er ikke en revolusjon i GPU-arkitektur, men det er en betydelig utvidelse av hvor finkornet AWS lar kundene kjøpe GPU-kraft i et containermiljø.

Full GPU mot fractional GPU: forskjellene i praksis

Tabellen under oppsummerer de konkrete, bekreftede forskjellene mellom en vanlig full-GPU-instans og den minste fraksjonerte G6f-varianten.

EgenskapFull GPU-instans (f.eks. g6.xlarge)Fractional GPU (g6f.large)
GPU-andel1 hel NVIDIA L4 GPU1/8 av en NVIDIA L4 GPU
GPU-minne24 GB3 GB, dedikert
IsolasjonsmodellHele GPU-en tilhører én oppgaveMaskinvarepartisjonert skive med eget minne og egen regnekraft
FaktureringPer sekund, minimum 60 sekunderPer sekund, minimum 60 sekunder
Planlegging i ECSHeltallsverdi i GPU-ressursDesimalverdi (0,125 / 0,25 / 0,5) i GPU-ressurs

Den viktigste forskjellen er ikke prisen per time, men hvor presist en organisasjon nå kan matche GPU-kapasitet til faktisk arbeidslast. Et team som tidligere måtte velge mellom å overprovisjonere en hel GPU eller la flere prosesser konkurrere om samme kort uten minnegaranti, har nå et tredje alternativ med forutsigbar ytelse.

Container-sikkerhet: hva betyr isolasjon på maskinvarenivå

For sikkerhetsansvarlige er det maskinvarebaserte partisjoneringsprinsippet det som gjør G6f interessant, mer enn selve kostnadsbesparelsen. Fordi hver GPU-skive har dedikert minne og dedikert regnekapasitet, unngår AWS flere av de klassiske multi-tenant-problemene som har plaget programvarebasert GPU-deling: en container kan ikke lese restdata fra en annen containers GPU-minne fordi minnet aldri deles i utgangspunktet.

Samtidig finnes det ingen offentlig dokumentasjon fra AWS eller tredjeparter som beskriver formelle sikkerhetssertifiseringer, side-kanal-analyser eller uavhengige penetrasjonstester av G6f-partisjoneringen per oktober 2026. Det betyr at team som planlegger å kjøre arbeidslaster fra flere kunder eller avdelinger på samme fysiske G6f-vert, bør behandle den hardware-partisjonerte isolasjonen som et sterkt utgangspunkt, ikke som en ferdig revidert sikkerhetsgaranti. Dette er spesielt relevant for nordiske finans- og helseaktører som er underlagt strenge krav til dataisolasjon i delt infrastruktur.

Markedssammenligning: Azure og Google Cloud sine svar

Både Microsoft og Google har egne tilnærminger til delt GPU-kapasitet, typisk gjennom NVIDIA-teknologi som vGPU-profiler og tidsdelte planleggingsmodeller i deres respektive Kubernetes-tjenester. Det finnes imidlertid ingen oppdatert, offentlig sammenlignbar tabell per oktober 2026 som direkte motstiller Azures og Google Clouds fraksjonerte GPU-partisjonsstørrelser, priser og isolasjonsmodeller mot AWS’ G6f-lansering. Konkrete tall for en slik sammenligning er derfor ikke tilgjengelige akkurat nå, og en reell vurdering krever at kundene selv tester mot egne prisavtaler i hver sky.

Det som derimot er tydelig, er at G6f plasserer seg i en bredere trend der alle de tre store skyleverandørene jobber med å gjøre GPU-kapasitet billigere å få tak i for mindre arbeidslaster. Les mer om hvordan prisene for H100-GPU-er har utviklet seg mellom AWS, Azure og GCP for å se hvor mye prispress som allerede finnes i det øvre GPU-segmentet. G6f flytter samme konkurranselogikk ned i et billigere og mer tilgjengelig segment.

Hvorfor dette betyr noe for Norge og Norden

Nordiske selskaper har i 2026 bygget ut AI-kapasitet raskere enn de klarer å styre kostnadene, ifølge gjentatte FinOps-rapporter fra skyleverandørene selv. Fraksjonert GPU-scheduling gir mindre norske og svenske AI-team, som sjelden har samme skala som amerikanske hyperskalere, et verktøy for å kjøre produksjonsinferens uten å betale for kapasitet de aldri bruker fullt ut. En liten modellserveringstjeneste som i dag kjører på en hel L4-instans med 20-30 prosent faktisk GPU-utnyttelse, kan i teorien flyttes til en 1/4- eller 1/2-partisjon og dele resten av kortet med andre tjenester.

Det er også relevant i lys av debatten om datasenterkapasitet og strømforbruk i Norden. Når flere arbeidslaster kan dele samme fysiske GPU i stedet for at hver skal ha sin egen, reduseres i teorien antall GPU-er som må kjøpes, strømforsynes og kjøles for et gitt volum av AI-trafikk. Det er et argument som vil interessere både kostnadsstyring og den pågående diskusjonen om datasentres strømavtrykk i regionen.

Hvilke arbeidslaster passer best til fractional GPU

AWS beskriver fraksjonerte profiler som en måte å matche GPU-kapasitet til arbeidslaster som ikke trenger en hel GPU, med særlig relevans for mindre GPU-akselererte inferens- og grafikkoppgaver. I praksis er det tre kategorier som skiller seg ut som gode kandidater.

  • Småskala inferens for språkmodeller med få milliarder parametere, der minnebehovet holder seg innenfor 3-6 GB per instans.
  • Batch-jobber for bildebehandling eller videotranskoding som kjører kort og sporadisk, der fakturering per sekund gir reell besparelse.
  • Utviklings- og testmiljøer der team trenger GPU-tilgang for å validere kode, men ikke trenger full produksjonskapasitet.

Når full GPU fortsatt er riktig valg

Store språkmodeller med tosifret antall milliarder parametere, trening av egne modeller og arbeidslaster som krever maksimal minnebåndbredde, passer fortsatt best på fullstørrelses GPU-instanser eller på de større akselererte instansfamiliene. Fractional GPU løser et kapasitetsproblem i den nedre enden av skalaen, ikke et problem med å trene store modeller raskere.

ECS, EKS og Kubernetes: hvor passer fractional GPU inn

Lanseringen er foreløpig begrenset til ECS og ECS Managed Instances, ikke EKS. For team som allerede har bygget sin plattformstrategi rundt Kubernetes, betyr det at valget mellom ECS og EKS akkurat nå også blir et valg om hvor finkornet GPU-tildeling man får tilgang til. Sammenlign dette mot hvordan EKS, AKS og GKE skiller seg fra hverandre på pris og funksjonalitet før en beslutning tas om hvilken orkestreringsplattform som skal bære AI-arbeidslastene fremover.

Timingen er heller ikke tilfeldig. Mens AWS ruller ut finere GPU-granularitet i ECS, nærmer Kubernetes 1.34 seg full avvikling, med 27. oktober 2026 som dato for når den ikke lenger mottar noe støtte overhodet. Les mer om hva Kubernetes 1.34s avvikling betyr for team på EKS, AKS og GKE om klyngene dine fortsatt kjører den versjonen. For team som uansett må migrere Kubernetes-versjon nå, er det et naturlig tidspunkt å også vurdere om GPU-arbeidslaster hører hjemme i ECS i stedet.

Slik setter du opp fractional GPU i en ECS-oppgave

Konfigurasjonen skjer i containerdefinisjonen til en vanlig ECS-oppgavedefinisjon. I stedet for å spesifisere en hel GPU, settes ressursverdien til ønsket brøk. Et forenklet eksempel på hvordan dette ser ut i praksis:

{
  "family": "inferens-tjeneste",
  "containerDefinitions": [
    {
      "name": "modell-server",
      "image": "123456789012.dkr.ecr.eu-north-1.amazonaws.com/modell:latest",
      "resourceRequirements": [
        {
          "type": "GPU",
          "value": "0.25"
        }
      ],
      "memory": 2048,
      "cpu": 1024
    }
  ],
  "requiresCompatibilities": ["EC2"]
}

Verdien 0,25 ber om en fjerdedels GPU-skive, og ECS plasserer oppgaven på en vert som har en g6f-instans med den profilen tilgjengelig. Samme kapasitetsleverandør kan samtidig håndtere andre oppgaver som ber om 0,125 eller 0,5, eller oppgaver som krever en hel GPU på en vanlig g5- eller g6-instans. Dette gjør det mulig å blande arbeidslastprofiler i samme klynge uten å måtte drifte separate verter for hver GPU-størrelse.

Hva AWS selv sier om lanseringen

AWS har valgt å kommunisere endringen gjennom produktdokumentasjon snarere enn gjennom uttalelser fra navngitte talspersoner, noe som er vanlig for mindre, tekniske tjenesteoppdateringer. Selskapets offisielle produktvarsel beskriver funksjonen presist: “Amazon Elastic Container Service (Amazon ECS) now supports fractional GPU scheduling with Amazon EC2 G6f instances, enabling you to run your workloads on GPU partitions as small as one-eighth of an NVIDIA L4 Tensor Core GPU with 3 GB of GPU memory,” skriver Amazon Web Services (AWS) i kunngjøringen fra august 2026.

I den tekniske dokumentasjonen utdyper AWS hvordan plasseringslogikken fungerer: “Decimal values (0.125, 0.25, 0.5) are treated as fractional GPU requests and place on instances with the corresponding fractional GPU partition,” ifølge Amazon Web Services’ (AWS) ECS-utviklerdokumentasjon. Selskapet bekrefter også at blandet drift er en del av designet: “You can include both fractional GPU instances (G6f) and full GPU instances (such as g5 or g6) in the same capacity provider,” skriver AWS videre, noe som underbygger at fractional GPU er tenkt som et tillegg til eksisterende GPU-flåter, ikke en erstatning for dem.

Teknisk dokumentasjon fra tredjeparter som følger AWS’ instanskatalog tett, inkludert AWS’ egne eksempelrepositorier på GitHub og driftsverktøyet Cast AI, bekrefter samme spesifikasjonstall som AWS’ egen dokumentasjon, noe som gir ekstra trygghet om at tallene i denne artikkelen stemmer med det som faktisk er rullet ut.

Markedseffekt og kostnadsstyring i praksis

Den direkte markedseffekten er vanskelig å tallfeste før flere kunder har publisert reelle kostnadsdata, men mekanismen peker i en klar retning. Når fakturering følger en brøkdel av en GPU i stedet for hele enheter, flyttes insentivet fra å kjøpe kapasitet i store blokker til å dimensjonere arbeidslaster presist. Det er nøyaktig den typen finkornet styring FinOps-team har bedt om i flere år, og det kommer på et tidspunkt der AI-relaterte skykostnader allerede er under hardt press i mange nordiske organisasjoner.

For plattformteam betyr det også en ny variabel i kapasitetsplanleggingen. Å planlegge for fraksjonerte GPU-er krever bedre forståelse av faktisk minnebruk per arbeidslast enn å bare runde opp til nærmeste hele GPU-instans. Team som ikke har denne innsikten ennå, risikerer å feilberegne hvor mange tjenester som trygt kan dele samme fysiske kort, og ender opp med enten overbooking av GPU-minne eller unødvendig lav tetthet.

Fem prognoser: hvor går fractional GPU-skyen videre

Basert på hvordan AWS historisk har rullet ut lignende granularitetsforbedringer, og på det generelle prispresset i GPU-markedet, er det mulig å skissere noen sannsynlige utviklingstrekk uten å garantere datoer AWS selv ikke har bekreftet.

  • Flere GPU-familier enn L4 vil sannsynligvis få fraksjonerte varianter etter hvert som AWS validerer modellen på et bredere sett med maskinvare.
  • Azure og Google Cloud vil mest sannsynlig svare med egne finkornede GPU-partisjoneringsmodeller for sine respektive containertjenester, selv om tidspunkt og detaljer foreløpig ikke er offentlig bekreftet.
  • EKS-støtte for samme fraksjonerte GPU-modell er et naturlig neste steg gitt at ECS allerede har funksjonen, men AWS har ikke publisert noen tidslinje for dette.
  • FinOps-verktøy og kostnadsdashboard vil trolig bygge inn egen rapportering for GPU-brøk per arbeidslast, slik at team kan se utnyttelsesgrad på delt maskinvare direkte.
  • Flere uavhengige sikkerhetsgjennomganger av hardware-partisjonert GPU-isolasjon er ventet etter hvert som flere regulerte sektorer, inkludert finans og helse i Norden, vurderer å kjøre delte GPU-verter.

Det mest sannsynlige utfallet er at fractional GPU blir et standardverktøy i kostnadsoptimalisering på samme måte som Spot-instanser og Savings Plans allerede er det, snarere enn en nisjefunksjon som få bruker. Den store usikkerheten ligger i hvor raskt konkurrentene følger etter, og hvor fort sikkerhetsdokumentasjonen rundt isolasjonsmodellen blir mer offentlig tilgjengelig.

Ofte stilte spørsmål

Hva er AWS ECS fractional GPU scheduling?
Det er en funksjon lansert 6. august 2026 som lar ECS-oppgaver reservere en brøkdel av en GPU, i stedet for en hel GPU, gjennom nye EC2 G6f-instanser basert på NVIDIA L4.

Hvilke GPU-brøker kan jeg be om?
Tre verdier er støttet: 0,125 (1/8 GPU), 0,25 (1/4 GPU) og 0,5 (1/2 GPU), spesifisert som en desimalverdi i ressurskravene til containerdefinisjonen.

Hvor mye GPU-minne får jeg på den minste G6f-instansen?
g6f.large og g6f.xlarge gir begge 3 GB dedikert GPU-minne ved en 1/8-partisjon, mens g6f.2xlarge gir 6 GB ved en 1/4-partisjon.

Fungerer fractional GPU med EKS?
Nei, funksjonen er per oktober 2026 kun bekreftet for Amazon ECS og ECS Managed Instances. AWS har ikke publisert en tidslinje for støtte i EKS.

Hva koster en G6f-instans?
AWS har ikke publisert en fullstendig offisiell prisliste. Tredjepartskilden CloudPrice noterer 0,95 dollar i timen for g6f.4xlarge i tre amerikanske regioner, men dette er ikke en bekreftet AWS-listepris for europeiske regioner.

Er fractional GPU sikkert for flere kunder på samme fysiske vert?
GPU-partisjoneringen er maskinvarebasert med dedikert minne per skive, noe som er sterkere enn programvarebasert tidsdeling. Det finnes imidlertid ingen offentlig uavhengig sikkerhetssertifisering av modellen per oktober 2026.

Kan jeg blande fractional og fullstørrelses GPU-instanser i samme klynge?
Ja. AWS bekrefter at en og samme kapasitetsleverandør kan inkludere både fraksjonerte G6f-instanser og fullstørrelses GPU-instanser som g5 eller g6.

Hvordan faktureres fraksjonerte GPU-instanser?
Som alt annet EC2-forbruk faktureres de i ettsekunds-intervaller med et minimum på 60 sekunder, uavhengig av hvor stor GPU-andel instansen bruker.