AWS har rullet en MLflow-integration ud i Amazon SageMaker AI, der samler benchmark- og optimeringssporet for generativ AI ét sted. Når et benchmark- eller et optimeret inference recommendation-job startes, kan resultaterne nu strømme direkte ind i en SageMaker MLflow App i realtid. Ikke som et bagefter-resumé. Live. Det kan være det, der tipper valget mellem p4d og g5 i morgen, eller får et team til at afbryde et job før spildtimerne løber.

For teams, der i dag holder styr på forsøg i regneark og i tilfældige JSON-logs, er pointen konkret: Få reproducerbare resultater ind i en fælles grænseflade uden manuel fletning. Og sammenlign jobs side om side på den samme skærm. Mindre friktion, færre tabte noter, mere sporbarhed.

Hvorfor det betyder noget nu

Generativ AI-inference har mange drejeknapper: instans-typer, containere, batch-størrelser, parallelisering og teknikker som speculative decoding. Ifølge AWS’ egen gennemgang ender teams ofte med at evaluere dusinvis af kombinationer, og det tager tid. Mange syr det sammen i hånden til sidst for at kunne forklare, hvad der virkede, og hvorfor. Den nye integration skærer i det arbejde ved at lade SageMaker AI sende både metrics, parametre og grafer direkte til MLflow, mens jobbet kører.

Tempoet ændrer sig også. Når latency og throughput tikker ind løbende, kan man prioritere tidligere eller afbryde det, der ikke peger den rigtige vej. Det er lavpraktisk — og sådan beslutninger ofte træffes i drift.

Hvad integrationen helt konkret gør

Opsætningen er ligetil: Opret en MLflow App i SageMaker Studio. Giv job-rollen rettigheden sagemaker-mlflow:* på app’ens ARN. Og send en MlflowConfig med, når benchmark- eller recommendation-jobbet oprettes. Så streamer metrics, parametre og charts automatisk ind i MLflow-appen i realtid — uden ekstra limkode.

Flere jobs kan målrettes det samme MLflow-experiment. Konsekvensen er, at data lander under samme eksperimentnavn og kan vælges side om side i MLflow. Ingen manuel fletning for at få en ærlig sammenligning.

Sådan bliver eksperimenter til beslutninger

Når flere benchmark- eller recommendation-jobs sendes til det samme eksperiment, bliver sammenligningerne konsistente: samme navngivning, metadata og artefakter — og færre sene aftener med CSV-eksporter. Det er især vigtigt, når man skal forklare, hvorfor en g5.12xlarge med kernel-tuning blev valgt over en p4d.24xlarge med aggressiv speculative decoding. Man kan folde run’et ud, se parametrene, klikke sig gennem graferne og spore, hvilke ændringer der faktisk flyttede noget.

Mange har forsøgt at bygge tilsvarende i notebooks og interne dashboards. Forskellen her er, at det er integreret og mindre skrøbeligt. Man kan vende tilbage måneder senere og finde konteksten intakt.

Hvad inference recommendations faktisk måler

SageMaker AI’s optimerede inference recommendation-jobs analyserer modellens arkitektur og workload-krav. De afprøver flere GPU-instans-typer, anvender målrettede optimeringer og returnerer konfigurationer, der kan rulles ud — med validerede performance-målinger. Ifølge dokumentationen testes der på rigtig GPU-infrastruktur, så tallene kan bruges direkte i arkitekturvalg.

Optimeringerne er målstyrede: Ønskes throughput, kan teknikker som speculative decoding bringes i spil; er lavere latency målet, justeres kernels og planlæggere derefter. Det giver et mere nuanceret billede af pris kontra ydelse på tværs af instanser. Det afskaffer ikke alt manuelt arbejde, men det afgrænser feltet og gør de næste tests mere målrettede.

Fra uger til dage i praksis

Tre konsekvenser går igen. For det første bliver beslutningssløjfen kortere, fordi live-metrics gør det muligt at stoppe og prioritere tidligere. For det andet reduceres manuel datasamling, fordi hvert run bærer sine egne parametre, artefakter og grafer med sig. For det tredje kan pipelines operationaliseres: Benchmark og recommendation kan indgå i release-cyklussen, ikke som ad hoc-øvelser ved modelskifte.

På skala tæller selv små forbedringer i p95 eller udnyttelse ofte mere end endnu en lang tråd om modelvalg i Slack.

Udfordringer og de mindre pæne kanter

Rettighederne er brede: job execution-rollen skal have sagemaker-mlflow:* på MLflow-appens ARN. Det gør opsætning nem, men rejser spørgsmål om mindst mulige privilegier og governance. Kilderne beskriver ikke en indbygget, smallere politik. Praktisk næste skridt: involver platform-teamet, brug resource-level conditions hvor muligt, og skitser en scoped policy med de nødvendige MLflow-handlinger på den konkrete App-ARN — før produktion.

Der er også en mulig lock-in-smag. AWS dokumenterer streaming til en SageMaker MLflow App. Kilderne omtaler ikke streaming til eksterne eller on-prem MLflow-servere, så multi-cloud-opsætninger er et åbent spørgsmål. Dertil kommer omkostningerne: benchmarking på rigtig GPU-hardware koster og kræver kvoter, som kan ramme loftet på ubelejlige tidspunkter.

Kom i gang uden at brænde weekenden

En kort rute: Opret MLflow App i SageMaker Studio. Tilføj sagemaker-mlflow:* på app-ARN’en til job-rollen. Start med et lille benchmark-job, hvor MlflowConfig sættes eksplicit, og eksperimentnavn og run-navne får en bevidst struktur. Gentag med et recommendation-job, der tester to-tre instans-typer og én optimeringsdimension ad gangen.

Minimal MlflowConfig-eksempel (tilpas værdierne til jeres MLflow App):

{
  "MlflowConfig": {
    "MlflowAppArn": "arn:aws:sagemaker:REGION:ACCOUNT:mlflow-app/APPNAME",
    "ExperimentName": "qwen2-05b-lat-vs-thr-q3",
    "RunName": "p4d-sd-bsz16"
  }
}
Send samme ExperimentName på alle relevante jobs. Skift RunName pr. konfiguration, så side-om-side-sammenligning i MLflow giver mening.

Struktur i kaosset
Giv eksperimenter faste navne, der spejler formålet, eksempelvis “qwen2-05b-latency-vs-throughput-q3”. Brug run-navne, der indkoder instans-type, container og nøgleoptimering — “p4d-sd-hightemp-bsz16” er kedeligt, men effektivt. Versionér artefakter, og læg korte noter i run’et, mens I stadig kan huske, hvorfor batch 32 var valgt. Det føles som overkill første dag og som ilt tredje uge.
Vær også eksplicit med mål: “optimer for pris”, “minimer p95”, “maksimer tokens pr. sekund”. Recommendation-jobbene arbejder efter et enkelt mål ad gangen. Det tvinger en prioritering, som gør valget nemmere, når tallene peger i forskellige retninger.

Drift mens det kører
Lange jobs kan overvåges direkte i MLflow UI, hvor metrics opdaterer løbende. Det flytter support-arbejdet: Alarmer kan sættes på afvigelser i throughput under et benchmark, dokumentér hvornår en konfiguration flader ud, og eskalér før GPU-timer løber. Det erstatter ikke cost-værktøjer, men skærer ventetid væk.

Quota-håndtering kommer i spil. Planlæg vinduer for store jobs, og hold øje med, om parallelle benchmarks konkurrerer om de samme instanser. Real-time indblik gør det lettere at vælge, hvad der får køpladsen, når kapaciteten er knap.

Kroner, øre og tre fornuftige scenarier
Benchmarking på rigtige GPU’er koster. Men det flytter beslutninger fra gæt til tal. Tre scenarier giver særligt mening: proof-of-concept for at finde tidlige smertepunkter; pre-prod sizing mellem dyr P4-klasse og billigere G4-linje; og løbende opskalering, hvor samme model genmåles mod nye containere og drivere. I alle tre tilfælde hjælper live-streaming, fordi man kan afbryde og omdirigere, før kostkurven løber.
Kort tjekliste før I trykker start: bekræft Service Quotas for valgte instanser, sæt budget-alarmer, tag alle runs med projekt- og miljø-tags, begræns parallelle jobs i første runde, og aftal en cut-off-regel i MLflow (fx stop, hvis p95 overstiger baseline efter N konfigurationer). Dokumentationen opgiver ikke TCO-tal for kombinationen af recommendations og MLflow-streaming, så regn på jeres egne workloads.

Sikkerhed og governance uden drama
MLflow-experiments giver et pænt audit-spor: run-parametre, tidsstempler, checkpoints og artefakter lever videre og kan genfindes. Det er praktisk i revisioner og når en ændring skal spores tilbage til et specifikt run. Overvej adgang: Hvem må oprette eksperimenter, hvem må slette, og hvor længe bevares run-data? Kilderne beskriver ikke en skarp mindst-privilegier-politik for sagemaker-mlflow:*, så det bør strammes i hvert miljø, før produktionsbrug.
Logbevaring og tagging er lavthængende frugter. Faste tags per projekt, per model og per version gør senere oprydning markant nemmere. Det er sjældent sjovt at gøre bagudrettet.

Alternativerne i dag
Mange teams bruger i dag regneark og særskilte logging-løsninger. Nogle har MLflow i egen drift eller kombinerer Prometheus og interne dashboards. Det kan virke, men kræver lim og vedligehold. Fordelen ved SageMaker-integrationen er, at benchmark- og recommendation-data fødes direkte ind i samme eksperiment uden scripts. Ulempen er potentielt lock-in — og at streaming til eksterne MLflow-servere ikke er dokumenteret i kilderne.
Standard MLflow uden streaming kan selvfølgelig stadig noget. Men så samler man data ved jobslut — og beslutningerne kommer typisk senere, end de behøver.

Kilder, bekræftet og åbne spørgsmål
Følgende er eksplicit bekræftet i AWS’ egen gennemgang: at SageMaker AI kan streame metrics, parametre og grafer fra benchmark- og recommendation-jobs direkte til en SageMaker MLflow App i realtid; at man skal oprette en MLflow App i Studio, give job-rollen sagemaker-mlflow:* på app-ARN og sende en MlflowConfig ved joboprettelse; samt at flere jobs kan målrettes samme MLflow-eksperiment for side-om-side-sammenligning uden manuel data-wrangling. Det fremgår også, at målet er at reducere datasiloer, accelerere iterationer og styrke reproducerbarhed.

Hvad bør ske den næste måned
Lav en lille pilot: Vælg én model, ét formål og to-tre instans-kandidater. Sæt MLflow App op, giv rollen de krævede rettigheder, og kør først et benchmark-job, derefter et recommendation-job — begge med bevidst navngivning og stramme mål. Evaluer gevinster i sparet tid, klarere beslutninger og mindre manuel fletning — ikke kun i millisekunder.
Spørg samtidig platform- og sikkerhedsteams om to ting: hvordan IAM-politikkerne kan snævres ind med conditions og scope, og om der er en plan for streaming-krav, hvis I på sigt vil køre MLflow uden for SageMaker. Læg en arkiveringspolitik for run-data, så miljøet ikke mudrer til efter to kvartaler.

En note om hvad der kommer
Modelstørrelser stiger, og Mixture-of-Experts-modeller fylder mere i materialet fra feltet. Det gør hardware- og optimeringsvalg mere komplekse, ikke mindre. Derfor ligner bevægelsen mod reproducerbare, strømmende benchmarks et varigt skift. Hold øje med AWS’ release-noter for afklaringer om eksterne MLflow-servere, mere granular streaming og omkostningsstyring.
Man opdager først forskellen, når man sidder med det — og stopper det første fejlslagne run før frokost, ikke efter fyraften.

Kilder

• Streaming benchmark and recommendation results to MLflow with Amazon SageMaker AI
• Amazon SageMaker AI optimized inference recommendation jobs
• Tencent Releases Hy3: An Open 295B Mixture-of-Experts (MoE) Model with 21B Active Parameters and 256K Context