Nyheden kort
Amazon SageMaker introducerer Instance preference lists til både AI Training Jobs og Processing Jobs. Ifølge AWS kan man angive “an ordered list of up to five acceptable instance types”, og tjenesten “automatically evaluates your list in priority order and launches on the first type with available capacity” (kilde: AWS ML Blog, link). Målet er hurtigere jobstart, når en foretrukken GPU-type er optaget.
Den praktiske konsekvens, som AWS selv fremhæver, er færre hjemmebyggede workarounds: “This removes the manual retry loops, complex monitoring scripts…” (kilde: AWS ML Blog). Budskabet er enkelt: ét jobindsendelse, flere acceptable instansvalg, automatisk fallback.
Hvad betyder det teknisk
Kernen er tre elementer dokumenteret af AWS: understøttelse i både Training og Processing, en prioriteret liste med op til fem instanstyper pr. job, og automatisk opstart på den første type med ledig kapacitet (kilde: AWS ML Blog). AWS kobler det direkte til perioder med spidsbelastning, hvor pinned konfigurationer skaber kø og forsinker arbejde som “nightly re-training pipelines, production fine-tuning runs, and scheduled data processing”.
Det er en deklarativ grænseflade: man opgiver et godkendt sæt, og platformen matcher mod kapacitet ved opstart. AWS formulerer effekten som “faster job starts” og “higher capacity utilization” (kilde: AWS ML Blog). Noten om højere udnyttelse bør læses snævert som bedre fordeling på tværs af godkendte alternativer, ikke som ekstra GPU’er ud af ingenting.
Hvad der ikke er beskrevet
Der er åbne punkter i AWS-bloggen: ingen liste over regioner ved lancering, ingen detaljer om understøttede instansfamilier, ingen standard-timeouts eller retry-politikker, hvis ingen af de fem typer bliver ledige (kilde: gennemlæsning af AWS ML Blog). Det samme gælder eksplicit støtte for spot/preemptible.
Der mangler også CLI/SDK-eksempler på request/response og typiske fejlscenarier. De forhold er ikke behandlet i kilden og bør derfor regnes som ubesvarede, indtil AWS publicerer dokumentation.
Praktiske konsekvenser for teams
Eksempel 1, eksperimentering: Et forskerhold sender et træningsjob, der normalt kører på en L4-baseret type. Hvis L4 er optaget, kan det starte på et godkendt A10-alternativ fra listen. Resultatet er hurtigere start og kortere feedback-loop. Kilden beskriver gevinsten ved at undgå kø, ikke specifikke typer; eksemplet er en anvendelsesvinkel, ikke et produktløfte.
Eksempel 2, natlig retraining: En planlagt kørsel, der tidligere fejlede kl. 02 med InsufficientCapacityError, kan nu få en chance for at lande på et andet godkendt valg og dermed færdiggøre til morgenen. AWS nævner netop den type forsinkelser for natlige pipelines (kilde: AWS ML Blog).
Hvad det ikke løser
Funktionen skaffer ikke ny kapacitet. Den gør bare jobstart mere elastisk inden for det sæt, der er valgt (kilde: AWS ML Blog). Hvis hele regionen er tom for de valgte typer, er der stadig ventetid eller fejl.
Snilld: Når instanstypen kan skifte run til run, øges behovet for synlighed i monitoreringen. Batchstørrelse, GPU-RAM og I/O-adfærd kan variere på tværs af familier og påvirke varighed og pris pr. run. Det kræver bevidste policyvalg, ikke bare en bred liste.
Konsekvenser under peak
AWS beskriver, at teams ofte spreder jobindsendelser på flere typer manuelt for at finde huller i kapaciteten, og at retryscripts er skrøbelige og ikke spiller godt med reserverede ordninger som Flexible Training Plans (FTP) (kilde: AWS ML Blog). Pointen med den nye funktion er at give samme effekt i én indsendelse.
Snilld: Det flytter arbejdet fra improvisation til opskrift. God praksis er at definere acceptable alternativer pr. workload fremfor at lade en fælles “one size fits all”-liste styre alt.
Implementeringscheckliste
Forslag til første bølge af validering (ikke AWS-dokumentation):
- Definér pr. workload to-tre realistiske alternativer, ikke fem vilkårlige. Hold listen kort og bevidst.
- Mål performance-afvigelse: kør samme træning tre gange på tre forskellige godkendte typer og log wall-clock, GPU-udnyttelse og omkostning pr. run.
- Fastlæg en cost-guardrail: maks. pris pr. time eller maks. procent-afvigelse fra baseline, før fallback må vælges.
- Timeout-politik: beslut en lokal grænse for hvor længe et job må vente på de første én til to valg, før lavere prioritet accepteres.
Konkrete testcases, som kan afsløre problemer tidligt:
- Memory-bound træning: vælg en model/batch-size, der næsten fylder GPU-RAM på primær type. Tjek at fallback ikke tvinger batch-size ned og dermed forlænger tiden uforholdsmæssigt.
- I/O-tung preprocessing: kør et dataforberedelsesjob med høje læse/skrive-krav. Sammenlign disk-/net-IO på alternativerne for at undgå falske gevinster ved ren GPU-kapacitet.
- Distribueret træning: hvis jobbet bruger flere noder, test om netværksbåndbredde og kollektiv kommunikation (all-reduce) ændrer skaleringskurven på tværs af de valgte typer.
Drifts- og økonomiperspektivet
Snilld: For platformteams kan en lille ændring i startlogikken give mindre natteopsyn og færre “stuck” tickets. Men governance er nøglen. Uden cost- og performance-guardrails kan en bred liste udløse dyrere run-times.
På kapacitetssiden peger AWS på potentiel “higher capacity utilization” (kilde: AWS ML Blog). Det kan betyde færre kunstige køer, når en enkelt familie er presset. Det siger ikke noget om region-dækning eller pris; det handler om at bruge det, der er ledigt, hurtigere.
Sammenligning og kontekst
Der er ikke indarbejdet verificeret, aktuel dokumentation om tilsvarende funktionalitet hos GCP Vertex AI eller Azure ML i dette udkast. Derfor ingen direkte sammenligning her.
Hvad man bør spørge AWS om
Følgende punkter er uafklarede i blogindlægget og relevante for implementering:
- Regioner og instansfamilier ved lancering samt plan for udbredelse.
- Understøttelse af spot/preemptible i prioriteringslister og håndtering af afbrydelser.
- Standard-timeouts og retry-adfærd, når alle fem valg er optaget.
- CLI/SDK-eksempler, inkl. fejlscenarier og returstrukturer.
- Interaktion med Flexible Training Plans, inkl. rækkefølge mellem reservation og on-demand samt eventuelle billing-detaljer.
Sådan gribes funktionen an
Start småt: sæt lister på få, velvalgte jobs med tæt monitorering. Dokumentér acceptable alternativer pr. workload, definér cost-/performance-guardrails, og mål forskelle systematisk. Gentagelser af kendte fordele (færre retry-scripts og kortere ventetid) fremgår allerede af AWS-kilden; fokus bør nu være på lokal evidens.
Snilld: Den største fejl er at lade listen være for bred. Den næststørste er ikke at måle konsekvenserne per run. Begge kan undgås med en enkel policy og to uger med målrettede tests.
